Cours merise le modèle logique de donnée (MLD)

Cours merise le modèle logique de donnée (MLD), tutoriel & guide de travaux pratiques merise en pdf.

Aprè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.
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.
<==> CLIENT (id_client, Nom_Client, Tel_client)

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) :
Exemple de Système d’Information (SI) :
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é.
COMMANDE (id_Commande, Date_commande)
PRODUIT (id_Produit, libelle)
COMPOSE (id_Commande, id_Produit, qantité)

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.
ETUDIANT (id_Etudiant, Nom_Etudiant)
NIVEAU (id_Niveau, Nom_Niveau)
LANGUE (id_Langue, Nom_Langue)
PARLE (id_Etudiant, id_Niveau, id_Langue)

5 : Association Réflexive

• 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).

………