Conversion d’un diagramme E/R en structure de tables relationnelles

Yves MARCOUX - EBSI - Université de Montréal

Procédure

Chaque entité donne lieu à une table de même nom. Chaque attribut de l’entité devient un champ de même nom dans cette table. Si, parmi ces champs, il y en a qui peuvent former une clé primaire « naturelle », alors on les choisit comme clé primaire. Autrement, on ajoute (provisoirement, du moins) un champ dont la seule raison d’être est de constituer une clé primaire pour la table.
Pour chaque relation 1-N, on ajoute une clé externe dans la table correspondant à l’entité du côté N vers la table correspondant à l’entité du côté 1.
Chaque attribut de cardinalité N (il s’agit forcément d’un attribut d’entité) donne lieu à une table de même nom (nom rendu unique d’une façon quelconque si nécessaire^*). Il est recommandé (mais non obligatoire) d’ajouter le suffixe occ au nom de la table pour mettre en évidence que la table correspond à un attribut à occurrences multiples (c’est-à-dire de cardinalité N). Cette table contient trois champs :
1. Le premier (appelons-le NO) est un numéro automatique servant de clé primaire.
2. Le deuxième (appelons-le Val) contient les valeurs d’attribut comme telles.
3. Le dernier (appelons-le noObj) est une clé externe vers la table correspondant à l’entité à laquelle l’attribut est lié dans le diagramme E/R.
Chaque fiche de cette table s’interprète ainsi : la valeur présente dans le champ Val est une des valeurs d’attribut applicables à l’objet pointé par le champ noObj^†.
Chaque relation N-N donne lieu à une table de même nom ne contenant pour le moment, comme champs, que deux clés externes, chacune vers une des deux tables correspondant aux entités liées. La clé primaire de cette table est la combinaison des deux clés externes.
Chaque relation 1-1 donne lieu à une clé externe d’une des tables liées par la relation vers l’autre. L’une ou l’autre des deux tables peut être choisie pour héberger la nouvelle clé externe, cependant, par souci d’économie d’espace, on choisira en général celle des deux tables qui risque d’avoir le moins d’enregistrements. Par exemple, dans une bibliothèque où un usager ne pourrait emprunter qu’un seul livre, on choisirait de placer la clé externe correspondant à la relation 1-1 entre les usagers et les livres du côté des usagers, car il y a normalement beaucoup plus de livres que d’usagers.

La nouvelle clé externe doit être indexée sans doublon. Au moment de la création de la relation dans le SGBDR, ce dernier comprendra qu’il s’agit d’une relation 1-1.
Les attributs de relation donnent chacun lieu à un nouveau champ de même nom, situé à la même place que la relation, c’est-à-dire dans la table « du côté N » pour une relation 1-N, et dans la table correspondant à la relation pour une relation N-N.
Réévaluer les choix de clés primaires en fonction de tous les champs disponibles dans chaque table (et modifier les clés externes en conséquence si on fait des changements). Cette étape est pertinente étant donné que les relations 1-N et leurs attributs peuvent avoir ajouté des champs à certaines tables. Ces nouveaux champs pourraient constituer, en combinaison avec d’autres champs, des clés primaires « naturelles », ce qui permettrait d’éliminer les clés primaires ajoutées « artificiellement » à l’étape 1.
Choisir un type de données précis pour chacun des champs de chacune des tables.
Déterminer quels champs sont obligatoires (les autres étant donc facultatifs).

^* Exercice : Dans quelles circonstances une telle désambiguïsation est-elle nécessaire ?

^† Exercice : Comment peut-on décrire le nombre de fiches présentes dans la table à un moment donné ?