MySQL - cours 1

Les bases de données relationnelles

Pourquoi MySQL?

Pour et contre de MySQL :

Pour :

- rapide

- simple

- facile à administrer

- populaire et très répandu

Contre :

-simple. Parfois trop.

- manque certaines fonctionalités avancées (stored proc, sub-select, etc.)

- non ACID (Atomicity Consistency Isolation Durability)

Autres options :

Libres :

• Postgresql

• Firebird (Interbase)
• Sqlite
• etc.

Commerciales :

• Oracle
• MS SQL-Server
• SyBase
• Informix
• etc.

Théorie sur les BD

Type de BD :

- "physique" : l'exemple d'une bibliothèque

- un systeme de fichiers

- clé/valeur : DBM (dbmopen,etc.)

- Relationel : SQL

Concept de BD, table, relation :

Base de données :

Un ensemble de table, une collection d'information.

Table :

Contient les informations à propos d'un groupe d'entité, un groupe de ''chose".

Champ :

Aussi appelé "colonne" : contient un type d'information sur la "chose"

Enregistrement :

Désigne les données sur une entité dans la table

Comment construire la structure de ses tables?

Supposons qu'on veut se construire une base de données pour conserver l'information sur sa collection de disques. Un exemple de structure de table qu'on pourrait penser utiliser :

Mais!

Beaucoup de problème avec cette structure : on répète de l'information, on perd du contrOOle sur les données, etc.

Pour mieux concevoir ses base de données, il faut prendre du recul et penser en dehors du modèle des tables/champs. On pense en terme d'entités, d'attributs, de relations.

Entité :

représente un genre de chose qu'on veut stocker.

Attributs :

Une propriété de l'entité dont on parle.

Relations :

Quel lien existe-t-il entre deux entités de notre modèle?

Concrètement, ca nous permet de remodeler notre structure de disques et la penser en terme d'entités.

Ainsi, comme on traite d'une collection de disques, on peut supposer qu'on à au moins une entité dans notre modèle :

Penser en terme d'entités, d'attributs et de relations nous permet de procéder à l'opération qui nous amène à un bon design de base de données ; la normalisation.

Les formes normales : la normalisation.

La normalisation, c'est le processus qui nous permet d'éliminer les répétitions, les redondances et les incohérence dans notre modèle de données. Le concept vient de E. Codd, chercheur chez IBM. La normalisation se fait par « étapes » : on cherche à atteindre les « formes normales »

La première forme normale

Tous les attributs d'une entité doivent faire référence à une seule valeur.

Donc, pour atteindre la « premiere forme normale », on vérifie qu'aucun attributs dans notre modèle ne contiennent une liste de données. Dans notre cas, on se rend compte qu'on a 2 entités : des disques et des chansons.

Normalisons le champs «chansons»:

Nos 2 entités sont en « relations » : pour chaque CD on peut faire correspondre une série de chansons. Pour « faire » la connection entre les 2 entités, on a besoin d'un identifiant unique : il s'agit d'un attribut qui est unique à une instance d'une entité, qui n'est pas NULL et qui a une valeur qui ne bougera pas pendant toute la durée de vie de l'entité dans la base de donnée.

L'identifiant unique permet de référer à un enregistrement dans une relation. Ainsi, notre modele aura un identifiant pour chaque disque, et un identifiant unique à chaque chanson.

La relation entre nos 2 entités est de type « un-à-plusieurs » : c'est la plus répandu.

Normalisation : seconde forme normale

Pour qu'une entité soit dite dans la seconde forme normale, on doit faire en sorte que tous les attributs de notre entités soient uniques à cette entité.

Concrètement : il faut éliminer les répétitions. Dans notre exemple, c'est le champ « groupe ».

S'il y a répétitions, c'est que notre modèle comprend aussi un autre genre de « chose » : il faut une autre entité « groupe » :

On a alors un autre genre de relation : « plusieurs-à-plusieurs ». Un groupe peut avoir un ou plusieurs albums, et un album peut avoir été produit par un ou plusieurs groupes (ou artistes...)

Comment faire ca?

Intégrer cette relation au modèle en utilisant à terme une table qui ne servira qu'à ca.

Ou

Revoir notre modèle de facon à intégrer cette relation. Dans notre cas :

Un artiste produit un ou plusieurs chansons, un disque contient une ou plusieurs chansons. La relation entre l'entité « groupe » et l'entité « disque » se fait via l'entité « chanson ».

La même mécanique doit être appliqué pour la maison de disque.

La troisième forme normale

Dans la 3e forme normale, on doit faire en sorte qu'aucun attribut d'une entité n'ait de valeur qui dépend de la valeur d'un autre attribut.

Supposons qu'on a stocké l'adresse de la cie de disque, avec un attribut « province » et un attribut « code de province ». Ces 2 attributs dépendent l'un de l'autre : on ne peut changer l'un sans changer l'autre sinon notre modèle devient incohérent. Pour régler ca : une autre entité!

Passer des entités aux tables : le modèle physique

Penser en terme d'entité, d'attributs et de relations nous aide à débrousailler les éléments à intégrer dans notre modèle de données. Il est ensuite très simple de passer au modèle « physique », c'est-à-dire aux tables dans une BD, en suivant ces règles :

• Les entités deviennent des tables

• Les attributs deviennent des colonnes, ou des champs dans la table

• Les identifiants uniques correspondent à la clé primaire : ce champ doit être unique, ne peut pas Emtre NULL et ne doit plus Emtre modifier après la création

• Les relations deviennent des « clés étrangères » (foreign keys). Ce qui, sous MySQL, ne correspond à ... rien. C'est une faiblesse de MySQL.

On peut alors écrire le code SQL qui permet de définir les tables (on laisse tomber l'adresse de la cie de disque) :

CREATE TABLE cd (
  cd_id         INT NOT NULL PRIMARY KEY,
  cie_disque    INT,
  titre         VARCHAR(50));
CREATE TABLE chanson (
  chanson_id    INT NOT NULL PRIMARY KEY,
  titre         VARCHAR(50),
  duree         TIME
  cd            INT,
  groupe        INT  );
CREATE TABLE groupe (
  groupe_id     INT NOT NULL PRIMARY KEY,
  nom           VARCHAR(50)
);
CREATE TABLE cie_disque (
  cie_disque_id INT NOT NULL PRIMARY KEY,
  nom
);