Merise TD2 - MLD/MPD - Correction
Mise en oeuvre des Modèles Logiques et Physique de Données
(1) On révise un peu...
Dans la pratique, la relation est en fait la table, un T-uple est une ligne (ou enregistrement), et
les attributs sont les colonnes.
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 le Cours et le TD 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 .
(2) Entité du MCD -> MLD
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.
<==> CLIENT ( id_client , Nom_Client, Tel_client)
(3) Transformation des relations MCD -> MLD -> MPD
Donnez les transformations MCD vers MLD puis vers MPD pour les relations suivantes :
1. 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.
S.I. :
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 , Quantité)
MPD :
2. 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.
S.I. :
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 :
3. Association Réflexive de cardinalité (X,1) - (X,n), avec X=0 ou X=1.
Premier cas : cardinalité (X,1) - (X,n), avec X=0 ou X=1.
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, #emp_id_employe)
#emp_id_employe est l'identifiant (id_Employe) du supérieur hiérarchique direct de l'employé considéré.
MPD :
4. Association Réflexive de cardinalité (X,n) - (X,n), avec X=0 ou X=1.
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 :
5. Relation binaire aux cardinalités (0,1) - (1,1).
La Clé Primaire de la table à la cardinalité (0,1) devient une Clé Etrangère dans la table à la cardinalité
(1,1) :
S.I. :
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 :
(4) Transformation du MCD NEWSLETTER vers MLD et MPD.
1. Donnez le MLDR de l'exercice 5 du TD1.
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)
2. Donnez le MPD correspondant.
3. Quelles précautions prendre lors de l'implantation du modèle physique si on utilise pas une base de
données totalement relationnelle ?
La table MOTIVATIONS est très simple à créer : elle comporte deux champs, ID_MOTIVATIONS et
INTITULE . ID_MOTIVATIONS est la Clé Primaire.
ABONNES comporte les 12 champs du schéma. ID_ABONNES est la clé primaire.
ID_MOTIVATIONS est une clé étrangère provenant de MOTIVATIONS , c'est à dire que sa valeur
doit être toujours égale à une valeur de ID_MOTIVATIONS de MOTIVATIONS . L'intérêt majeur des
clés étrangères est surtout d'éviter les redondances, sources d'erreurs.
Pour les bases non totalement relationnelles : Il appartiendra au développeur de vérifier lors de
chaque insertion dans ABONNES que l'ID_MOTIVATIONS fournis fais partie des valeurs
existantes de ID_MOTIVATIONS de MOTIVATIONS . De même, lors de chaque suppression
d'un enregistrement de MOTIVATIONS , il faudra vérifier qu'aucun enregistrement d'
ABONNES n'utilise la valeur d'ID_MOTIVATION correspondante.
S_INSCRIT comporte deux champs, ID_ABONNES et ID_RUBRIQUE . ID_ABONNES et
ID_RUBRIQUE sont clé primaire de S_INSCRIT : S_INSCRIT a comme clé primaire la
concaténation de ces deux champs. C'est à dire que tout couple ( ID_ABONNES , ID_RUBRIQUE )
de S_INSCRIT est unique. ID_ABONNES est aussi clé étrangère de ABONNES dans S_INSCRIT , et
ID_RUBRIQUE est clé étrangère de RUBRIQUE dans S_INSCRIT .
Une telle table est communément appelée " Table de Lien ". L'intérêt d'une telle table est que pour
chaque ID_ABONNES donné, il est aisé de retrouver tous les ID_RUBRIQUE associés, et vice et
versa.
Pour les bases non totalement relationnelles : Il faudra vérifier lors de chaque insertion dans
S_INSCRIT que le couple ( ID_ABONNES , ID_RUBRIQUE ) n'existe pas déjà dans la table
S_INSCRIT , que ID_ABONNES existe dans ABONNES et que ID_RUBRIQUE existe dans
RUBRIQUE . De même, pour chaque suppression d'un abonné, il faudra supprimer tous les
couples ( ID_ABONNES , ID_RUBRIQUE ) ayant l'ID_ABONNE correspondant. Pareil pour
toute suppression de RUBRIQUE .
RUBRIQUE est elle aussi très simple à créer : elle comporte deux champs, ID_RUBRIQUE et
NOM_RUBRIQUE . ID_RUBRIQUE est la Clé Primaire.
NEWSLETTERS comprend les 5 champs du schéma. ID_NEWSLETTER est la clé primaire.
ID_RUBRIQUE est une clé étrangère provenant de RUBRIQUE.
Pour les bases non totalement relationnelles : Il faudra vérifier lors de chaque insertion dans
NEWSLETTER que ID_RUBRIQUE existe dans RUBRIQUE . De plus, pour chaque
suppression d'une rubrique, il faudra s'interroger sur le sort réservé à chaque newsletter de cette
rubrique : les détruire ou les archiver.
