Modélisation d'une base de données

4. Tables d'une base de données

Une fois que l'on est satisfait de son modèle, on peut traduire le diagramme entité-relation final en un diagramme des tables, qui correspondent alors à ce qui sera implémenté concrètement dans la base de donnée relationnelle afin de réaliser le modèle. Ce diagramme sert alors aussi de schéma pour la base de donnée concrète.

Une table est constituée de champs, avec un nom et un type de donnée, et d'entrées, ou lignes, contenant une valeur pour chaque champ.

Entités et clés primaires

Lors de cette étape, chaque entité devient une table, dont les champs correspondent aux attributs de l'entité.

De plus, on ajoute habituellement à chaque table un champ supplémentaire nommé clé primaire. C'est un champ contenant par exemple un nombre entier généré automatiquement de manière unique pour chaque nouvelle entrée dans la table. Ce nombre n'est jamais réutilisé par la suite, même si l'entrée concernée est effacée. C'est comme un "compteur" pour les entrées de la table, permettant de se référer de manière claire et sans ambiguïté à une entrée donnée. On peut choisir un autre type pour une clef primaire comme un texte à condition que sa valeur soit bien unique pour chaque entrée. Par exemple, le code international à 2 ou trois lettres pour chaque pays. Dans certains cas, on peut même choisir une combinaison de plusieurs champs pour former une clef une clef primaire.

Dans l'exemple ci-dessous, on représente la table correspondant à l'entité Artiste avec son unique attribut nom et sa clé primaire (CP). À ce stade, il est indispensable que les noms de tables et de champs ne soient constitués que de lettres non accentuées et du caractère "_" ("caractère souligner"). Conventionnellement, les noms de champs sont uniquement en minuscules, tandis qu'un nom de table peut commencer par une majuscule.

NB: on peut aussi indique "PK" au lieu de "CP" pour la clé primaire, comme abréviation de l'anglais "primary key".

Relations et clés étrangères

Enfin, on doit traduire les relations vers les tables:

 

• pour une relation 1-à-1, on fusionne normalement les deux entités liées en une seule table, vu qu'une seule entrée suffit à décrire les deux entités liées
• pour une relation 1-à-plusieurs, on ajoute dans la table correspondant au côté "plusieurs" de la relation un champ spécial permettant d'indiquer avec quelle instance de l'entité du côté "1" de la relation une instance est liée (un champ suffit vu qu'il n'y a qu'une seule instance en relation de ce côté-là). Cela se fait grâce à une clé étrangère (indiquée comme CE, ou bien FK provenant de l'anglais "foreign key"), qui est simplement une référence à la clé primaire de l'autre côté de la relation. Une flèche indique le chemin d'une clé étrangère vers la clé primaire correspondante.
• pour une relation plusieurs-à-plusieurs, on crée une table supplémentaire, dont les deux champs sont des clés étrangères, qui ensemble constituent une clé primaire pour la relation (chaque combinaison de clés étrangères ne peut apparaître qu'une seule fois).

Ce qui précède devrait être plus clair avec un exemple.

Ci-dessus, les tables Morceau, Artiste, et Genre représentent des entités. Chacune possède sa clé primaire ainsi que des champs pour les attributs de l'entité. De plus, la table Morceau contient un champ de clé étrangère, concrétisant la relation 1-à-plusieurs avec l'entité Artiste: Un morceau peut être en relation avec uniquement un artiste, via la clé étrangère, mais plusieurs morceaux peuvent "pointer" vers le même artiste!

Enfin, la table MorceauGenre concrétise une relation plusieurs-à-plusieurs. Une entrée de cette table est constituée d'une paire de clé étrangères, "pointant" vers un morceau et un genre. Ainsi, un même morceau peut être lié à plusieurs genres, et un genre peut être lié à plusieurs morceaux, chaque lien correspondant à une entrée. Cependant, un même lien n'apparaît qu'une seule fois, donc une paire de clé étrangères devient simultanément la clé primaire de cette table un peu spéciale.

NB: si on a nommé la relation, on peut utiliser le nom de relation comme nom de table, plutôt que de combiner les noms des deux entités liées comme dans l'exemple ci-dessus.