II.3.2.2. Modèle Logique de Données
(MLD)
Le Modèle Logique de Données (MLD) est la suite
du processus Merise. Son but est de nous rapprocher au plus près du
modèle physique. Pour cela, nous partons du modèle Conceptuel de
Données et nous lui enlevons les relations, mais pas n'importe comment,
il faut en effet respecter certaines règles.
Règle 1 :
Toute entité devient une table dans laquelle les
attributs deviennent des colonnes. L'identifiant de l'entité constitue
alors la clé primaire de la table.
Exemple: Médecin
(id_med,nom_med,postnom_med,sexe_med,....)
Règle 2:
Dans le cas de deux entités reliées par une
association de type 1 : n, on ajoute une clé
étrangère dans la table côté 0, 1 ou 1, 1, vers la
clé primaire de la table côté 0, n ou 1, n. les attributs
de l'association glissent vers la table côte 0, 1 ou 1, 1. Et si la
cardinalité est 1, 1 alors la clé étrangère ne peut
recevoir de valeur NULL (autrement dit, vide interdit).
Exemple :
Voici un modèle conceptuel de départ :
Elever
Mères
Numero_mère
Nom_mère
Prénom_mère
Enfants
Numero_enfant
Nom_enfant
Prénom_enfant
(1, n)
(1, 1)
Fig.II.9: Règles 2 MCD
Voici le Modèle Logique des Données
découlant du Modèle conceptuel précédent :
Mères
Numero_mère
Nom_mère
Prénom_mère
Enfants
Numero_enfant
Nom_enfant
Prénom_enfant
#Numero_mère
Règles 3 :
Fig.II.10: Règles 2 MLD
Dans le cas de deux entités reliées par une
association de type 1 : 1, on ajoute, aux deux tables, une clé
étrangère vers la clé primaire de l'autre. Afin d'assurer
la cardinalité maximale de 1, on ajoute une contrainte d'unicité
sur chacune de ces clés étrangères (la colonne
correspondante ne peut prendre que des valeurs distinctes). Les attributs de
l'association sont alors repartis vers l'une des deux tables. Et si la
cardinalité est 1, 1 alors la clé étrangère
concernée ne peut recevoir la valeur NULL (autrement dit, vide
interdit).
Cette alternative est sans doute préférable, car
plus évolutive (si le type 1 :1 est un jour converti en un autre
type).
Remarque :
D'autres techniques sont parfois proposées pour la
règle 3 (fusionner les tables, utiliser une clé primaire
identique) mais en pratique elles ne sont pas exploitables dans le cas
général
Règle 4 :
Une association entre deux entités de type n : m
est traduite par une table supplémentaire (parfois appelée table
de jointure) dont la clé primaire est composée de deux
clés étrangères vers les clés primaires des deux
tables en association. Les attributs de l'association deviennent des colonnes
de cette table.
Illustration :
Comme dans notre exemple précedent, l'association
consulter qui relie deux entités dont médecin et patient qui
sont de cardinalité père - père, l'association consulter
devient une table avec comme clé primaire la concatenation de la
clé de l'entité médecin et patient.
ü Médecin
(id_med,Nom_med,postnom_med,...)
ü Consulter (#id_med,#id_pat,date)
ü Patient (Id_pat,Nom_pat,Prenom_pat,..)
Règle 5:
Une association non binaire est traduite par une table
supplémentaire dont la clé primaire est composée d'autant
de clés étrangères que d'entités. Les attributs de
l'association deviennent des colonnes de cette table.
| 
