Modèle Logique/Relationnel de Données (MLD/MRD) Merise
5 min de lecture
Dans cet article, on va parler du MLD (Modèle Logique de Données) et du MRD (Modèle Relationnel de Données).
Le MLD est la suite normale et directe du MCD dans le processus Merise. Son but est de transformer le MCD en un modèle qui pourra être implémenté dans une base de données relationnelle.
On parlera plus tard du MRD, mais globalement : c'est la même chose que le MLD !
🤔 Qu'est-ce que le MLD ?
Le MLD est un schéma qui va nous permettre de représenter les données que l'on a récupérées dans le MCD, mais en ajoutant des détails techniques.
Il va nous permettre de représenter les différentes données que l'on a, regroupée dans une table, ainsi que les relations entre elles au travers de clés étrangères, de clés primaires et de tables de jointure.
Contrairement au MCD, le MLD n'est pas destiné à être compris par le client.
🔍 Exemple de MLD
Reprenons le premier exemple de MCD, dans l'article précédent :
On a ici un MCD qui représente trois entités :
- Entité 1
- Entité 2
- Entité 3
À partir de ce MCD, on va pouvoir créer un MLD.
Voici à quoi il ressemble :
On a ici un MLD qui représente trois tables :
- table_1
- table_2
- table_3
Mais surtout : on a ajouté des clés primaires, des clés étrangères et une table de jointure !
Pour le moment ça semble bizarre voire magique, on va prendre le temps de décortiquer tout ça.
Transformation du MCD en MLD
Comme dit plus tôt, le MLD découle directement du MCD.
Il va donc reprendre les mêmes entités et attributs que le MCD, mais en ajoutant des détails techniques.
Termes
À partir du MLD, on va commencer à parler de table et de colonne.
On parlera aussi de clé primaire et de clé étrangère !
Pour pouvoir le transformer en MLD, il y a plusieurs éléments à prendre en compte :
- Attributs :
- Les attributs qui sont en gras et soulignés (discriminants) dans le MCD, deviennent des clés primaires dans le MLD.
- Les attributs qui sont en gras (attributs uniques) deviennent des colonnes uniques dans le MLD.
- Les attributs qui ne sont pas en gras deviennent des colonnes dans le MLD.
- Relations :
- On supprime les relations du MCD pour laisser place à des clés étrangères dans le MLD.
- Est-ce que la cardinalité maximale est de 1 ou de N ?
- Est-ce que la relation est dite réflexive ?
Commençons par les entités et leurs attributs, on verra les cardinalités après 😉
Convertir les entités et attributs
Pour cette étape, ça va être très simple !
On vient reprendre notre MCD correspondant à la gestion d'un groupe de musique :
Les seules choses que nous avons à faire sont :
- Remplacer les entités par des tables
- Remplacer les attributs par des colonnes
Types de données
Dans le MLD, on ne précise pas encore les types de données des colonnes.
On serait tenté de le faire dès maintenant, mais ce serait ne pas respecter la méthode Merise et l'intérêt du MLD.
On le fera plus tard, dans le MPD (Modèle Physique de Données) !
Voici donc les tables et colonnes que l'on obtient :
Pour l'instant, on a juste remplacé les entités par des tables et les attributs par des colonnes. Il nous reste plus qu'à ajouter les clés primaires et les clés étrangères !
Convertir les relations
Pour convertir les relations, il faut d'abord se poser la question de la cardinalité maximale de chaque relation.
Il y a deux possibilités :
- One to Many (1,N)
- Many to Many (N,N)
Un troisième cas existe, dans le cas où la relation est réflexive (une entité se relie à elle-même).
➡️ One to Many
Dans le cas d'une relation One to Many, on va ajouter une clé étrangère dans la table qui est du côté de la relation One (1).
Dans notre cas, on a une relation One to Many entre Événement et l'héritage (Concert et Répétition).
Mais il n'y a pas de cardinalité ici !
Effectivement, aucune cardinalité n'est présente entre l'héritage et l'entité générique !
Dans ce cas précis, on considère que l'héritage est une relation One to Many.
C'est-à-dire :
- Événement peut être spécialisé par Concert ou Répétition (0,2 de manière implicite)
- Concert doit spécialiser un et un seul Événement (1,1 de manière implicite)
- Répétition doit spécialiser un et un seul Événement (1,1 de manière implicite)
On va donc ajouter une clé étrangère dans les tables concert et rehearsal qui va faire référence à la clé primaire de la table event.
Et là : tu remarqueras que les clés étrangères sont en italique et sont préfixées par un # !
On constate également que des flèches sont apparues entre les tables.
Ces flèches nous permettent de visualiser le sens de la relation entre les tables, en partant de la table contenant la clé étrangère vers la table contenant la clé primaire.
🔀 Many to Many
Pour cette deuxième possibilité, il est impossible de stocker une clé étrangère dans l'une des deux tables.
Il faut alors créer une table de jointure qui va faire le lien entre les deux tables.
Cette table se caractérise par :
- Son nom :
- Généralement composé des deux tables qu'elle relie, séparées par un
_(ex:table_1_table_2) - Peut aussi être un nom plus explicite, comme
table_1_action_table_2
- Généralement composé des deux tables qu'elle relie, séparées par un
- Ses colonnes :
- Deux colonnes qui vont faire référence aux clés primaires des deux tables qu'elle relie
- Les potentielles autres colonnes qui sont spécifiques à la relation
Ici, nous avons une relation Many to Many entre les tables musician et event.
Une table de jointure a donc été créée, qui s'appelle musician_participates_event.
Cette table contient deux colonnes qui font référence aux clés primaires des tables musician et event.
Pourquoi il n'y a pas de clé primaire dans la table de jointure ?
Il n'est pas nécessaire d'ajouter une clé primaire dans la table de jointure.
Pour rendre unique chaque enregistrement, on viendra (plus tard !) créer une clé unique sur les deux colonnes qui fait référence aux clés primaires des tables qu'elle relie.
C'est ce qu'on appelle une clé composite.
🔄 Relations réflexives
Dans notre situation, nous n'avons pas de relation réflexive.
Mais le premier exemple donné sur cet article possède une relation réflexive sur l'entité Entité 3.
Pas besoin de revenir tout en haut de l'article, je te le remets juste ici :
Dans cet exemple, on retrouve une relation réflexive entre l'entité Entité 3 et elle-même.
Cette relation est définie avec une cardinalité 0,1 - 0,N.
On appliquera la même logique que pour une relation One to Many que l'on a vu plus haut.
On retrouvera donc une clé étrangère dans la table table_3 qui va faire référence à la clé primaire de la même table.
🎉 MLD final
Et voilà, on a terminé notre MLD !
Oui, pour de vrai 😁
Voici à quoi il ressemble :
MLD et MRD
Le MLD et le MRD sont deux choses différentes, mais qui se ressemblent beaucoup.
Le MLD est un modèle logique de données, qui est un schéma graphique.
Le MRD, lui, est un modèle relationnel de données, qui est un schéma textuel.
Les informations présentes seront les mêmes, seule la forme change.
Si c'est quasiment pareil, pourquoi faire le MRD ?
Le MRD n'est pas obligatoire, mais il permet une représentation plus linéaire.
À toi de voir si tu souhaites le faire ou non, mais il est souvent plus simple à lire !
Pour notre MLD final, voici à quoi il ressemblerait en MRD :
musician(id_musician, lastname, firstname, instruments, email, password)
musician_participates_event(#id_musician, #id_event)
event(id_event, datetime, location)
concert(id_concert, price, #event_id)
rehearsal(id_rehearsal, #event_id)
Conclusion
Par rapport au MCD, le MLD est beaucoup plus rapide à réaliser. (en même temps, tous les choix ont été faits avant !)
Ce schéma permet de visualiser les relations entre les différentes tables de manière simple et efficace, sans avoir à se soucier des détails techniques.
Mais pour le moment, on n'a pas encore parlé des types de données des colonnes, ni des index à créer sur les tables...
Rendez-vous pour la prochaine et dernière étape : le MPD (Modèle Physique de Données) ! 🚀