Dossier "SAM l'Informaticien" du 08 au 21 Janvier 2001 par Stéphane Lambert
près avoir conçu le
Modèle Conceptuel de Donnée (MCD), il est maintenant temps de le
transposer en Modèle Logique de Données Relationnelles (MLDR). Ce
MLDR est en fait le dernier pas vers le Modèle Physique de
donnée(MPD), c'est à dire la description de la base qui va être
crée. Et là , deux solutions s'ouvrent à vous : soit vous laissez à
un programme le soin de transformer votre MCD, soit vous le faîtes
vous-même. Dans les deux cas, il est utile d'avoir un minimum de
connaissance théorique sur le sujet. Après avoir définis les notions
de clé primaire et de clé étrangère, nous étudierons plus
particulièrement aujourd'hui les 6 règles strictes, nécessaires et
suffisantes pour passer d'un MCD à un MLDR, et nous les appliquerons
ensuite au schéma de Newsletter que nous avons écris la dernière
fois.
Préliminaires : le Modèle
Logique de Donnée (MLD)
Il s'agit du
passage entre le Modèle Conceptuel de Donnée et l'implémentation
physique de la base. Le MLD est lui aussi indépendant du matériel et
du logiciel, il ne fait que prendre en compte l'organisation des
données. C'est d'ailleurs le point primordial de la modélisation :
si l'organisation des données est relationnelle (si elles sont
"liées" entre elles), alors le MLD est Relationnel et devient le
MLDR, ou Modèle Logique de Donnée Relationnel. Pour la petite
histoire, le MLDR a été inventé par Codd en 1970, et repose sur la
Théorie Ensembliste...
Un peu de vocabulaire : Les données sont stockées dans des relations. Une relation est un ensemble de T-uple, et un T-uple est définis par un ou plusieurs
attributs. Dans la pratique, la
relation est en fait la table, un
T-uple est une ligne (ou
enregistrement), et les attributs
sont les colonnes.
Exemple de la table NEWSLETTER :
Cette table est décrite par :
NEWSLETTER
(id_newsletter, Sujet, DateEnvoie, Contenu, #id_rubrique)
Chaque enregistrement doit être identifié de manière unique (voir la notion d'identifiant abordée dans l'article précédent). L'attribut qui permet d'identifier de façon unique chaque ligne est appelée la Clé Primaire. Elle peut être composée, c'est à dire comprendre plusieurs attributs. Ici, il s'agit de l'attribut id_newsletter.
La table Newsletter comprend un attribut provenant de la
table RUBRIQUES, l'attribut id_rubrique. Cet attribut
est appelé Clé Etrangère.
Dans le formalisme, la clé primaire est soulignée, et la clé
étrangère est précédée du signe #. D'où l'écriture définitive :
MATABLE (Cle_Primaire, Colonne1, Colonne2,
#Cle_Etrangere)
Dans notre exemple :
Rubrique
(id_rubrique, Nom)
Newsletter (id_newsletter,
Sujet, DateEnvoie, Contenu, #id_rubrique)
Ici, id_rubrique est la Clé Primaire de la table RUBRIQUE, et est une Clé Etrangère dans la table NEWSLETTER.
Une fois assimilée ces notions de clés primaires et de clés étrangères, nous pouvons maintenant énoncer les règles suivantes :
1 : Une entité se transforme en une relation (table)
Toute entité du MCD devient une relation du MLDR, et donc
une table de la Base de Donnée. Chaque propriété de l'entité devient
un attribut de cette relation, et dont une colonne de la table
correspondante. L'identifiant de l'entité devient la Clé Primaire de la relation (elle est donc
soulignée), et donc la Clé
Primaire de la table correspondante.
<==>
2 : Relation binaire aux cardinalités (X,1) - (X,n), X=0
ou X=1
La Clé Primaire
de la table à la cardinalité (X,n) devient une Clé Etrangère dans la table à la
cardinalité (X,1) :
Un employé a une et une seule société. Une société a 1 ou n employés.
Modèle Conceptuel de Donnée (MCD) :
Modèle Logique de Donnée Relationnelle (MLDR) :
EMPLOYE (id_Employe, Nom_Employe, #id_Societe)
SOCIETE (id_Societe, Nom_Societe)
Modèle Physique de Donnée (MPD), ou schéma de base :
3 : Relation binaire aux cardinalités (X,n) - (X,n), X=0
ou X=1
Il y a création d'une table supplémentaire ayant
comme Clé Primaire une clé
composée des identifiants des 2 entités. On dit que la
Clé Primaire de la nouvelle table
est la concaténation des Clés
Primaires des deux autres tables.
Si la relation est
porteuse de donnée, celles ci deviennent des attributs pour la
nouvelle table.
Une commande est composée de 1 ou n produits distincts en certaine quantité. Un produit est présent dans 0 ou n commandes en certaine quantité.
MCD :
MLDR :
COMMANDE (id_Commande, Date_commande)
PRODUIT (id_Produit, libelle)
COMPOSE (id_Commande, id_Produit, qantité)
MPD :
4 : Relation n-aire (quelles que soient les
cardinalités).
Il y a création d'une table
supplémentaire ayant comme Clé
Primaire la concaténation
des identifiants des
entités participant à la relation.
Si la relation est porteuse
de donnée, celles ci deviennent des attributs pour la nouvelle
table.
Un étudiant parle une ou plusieurs langues avec un niveau. Chaque langue est donc parlée par 0 ou n étudiants avec un niveau. Pour chaque niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.
MCD :
MLDR : ETUDIANT (id_Etudiant, Nom_Etudiant)
NIVEAU (id_Niveau, Nom_Niveau)
LANGUE (id_Langue, Nom_Langue)
PARLE (id_Etudiant, id_Niveau, id_Langue)
MPD :
5 : Association Réflexive. 6 : Relation binaire aux cardinalités (0,1) -
(1,1). CONCLUSION Stéphane Lambert
Spécialisé dans le
développement Web, Stéphane LAMBERT
La Clé Primaire
de l'entité se dédouble et devient une Clé Etrangère dans la relation ou
nouvelle table. Exactement comme si l'entité se dédoublait et
était reliée par une relation binaire (X,1) - (X,n) (Cf règle 2).
S.I. :
Prenons l'exemple d'une société organisée de manière
pyramidale : chaque employé a 0 ou 1 supérieur hiérarchique
direct. Simultanément, chaque employé est le supérieur
hiérarchique direct de 0 ou plusieurs employés.
MCD :
MLDR
:
EMPLOYE (id_Employe, Nom_Employe,
#id_Sup_Hierarchique)
#id_Sup_Hierarchique est
l'identifiant (id_Employe) du supérieur hiérarchique direct
de l'employé considéré.
MPD :
De même, tout
se passe exactement comme si l'entité se dédoublait et était
reliée par une relation binaire (X,n) - (X,n) (Cf règle 3). Il y a
donc création d'une nouvelle table.
S.I.
:
Prenons cette fois l'exemple d'une
organisation de type familiale : chaque personne a 0 ou n
descendants directs (enfants), et a aussi 0 ou n descendants
directs (enfants).
MCD :
MLDR
:
PERSONNE (id_Personne, Nom_Personne)
PARENTE (#id_Parent, #id_Enfant)
#id_Parent est l'identifiant (id_Personne) d'un
ascendant direct de la personne. #id_Enfant est
l'identifiant (id_Personne) d'un descendant direct de la
personne.
La table PARENTE sera en fait l'ensemble des
couples (parents-enfants) présent dans cette famille.
MPD :
La Clé
Primaire de la table à la cardinalité (0,1) devient une
Clé Etrangère dans la table à la
cardinalité (1,1) :
Dans ce centre de vacances, Chaque animateur
encadre en solo 0 ou 1 groupe, chaque groupe étant encadré par
un et un seul animateur.
MCD :
MLDR :
ANIMATEUR (id_Animateur, Nom_Animateur)
GROUPE (id_Groupe, Nom_Groupe, #id_animateur)
MPD :
Ces 6 règles
représentent TOUS les cas que vous pourrez rencontrer. Il ne faut
surtout pas se laisser impressionner par le nombre de schémas, ni se
laisser intimider par le coté inhabituel du processus de
modélisation. Il est très simple à acquérir. En fait, au bout de
quelques modélisations et d'un ou deux développements, vous vous
rendrez compte que finalement tout ceci est très logique et d'une
évidence rare... Et surtout, surtout, votre base de donnée
correspondra EXACTEMENT au système d'information décris dans le
cahier des charges. De plus, écrire le MCD, le valider avec votre
client, puis en déduire le MLDR et donc le Modèle Physique vous fera
rentrer complètement dans le chantier. Vous irez ensuite beaucoup
plus vite, avec très peu de risque d'être hors sujet. Après, la
majorité du travail restant ne sera plus qu'une question de
requètes, de mise en forme et d'ergonomie, avec une bonne gestion
d'Entrée/Sortie de l'information...
Allez, si vous êtes
encore avec moi, vous avez bien mérité la fin de l'analyse de notre
Newsletter du mois de décembre :
Entraîne le MLDR
suivant :
MOTIVATIONS ( id_Motivation, Intitule)
ABONNES ( id_Abonne, #id_Motivation, Nom, Prenom, Age,
Sexe, Profession, Rue, CodePostal, Ville, Telephone, Email)
S_INSCRIT ( id_Abonne, id_Rubrique)
RUBRIQUES (
id_Rubrique, Nom_Rubrique)
NEWSLETTERS (
id_Newsletters, #id_Rubrique, Sujet, DateEnvoie, Contenu)
Qui nous mène au Modèle Physique de Donnée (MPD) ou
schéma de la
Base :
http://www.vediovis.fr/
a fondé VEDIOVIS PRODUCTIONS
en Mai 2000.
Son expérience couvre essentiellement les sites à
fortes audiences,
institutionnels ou
audiovisuels.
vediovis.fr