Compare commits

..

No commits in common. "961d3d93ae66db51e90ef6caf041dde19b9f5385" and "4b806374819fcd728846ac1f0537262ae8e7ead8" have entirely different histories.

10 changed files with 4 additions and 148 deletions

View File

@ -50,9 +50,9 @@ On a ici un MCD qui représente trois **entités** :
Chacune de ces entités a plusieurs **attributs** qui lui sont propres :
- **Entité 1** : code entité 1, attribut 2, attribut 3
- **Entité 2** : code entité 2, attribut 2, attribut 3
- **Entité 3** : code entité 3, attribut 2, attribut 3
- **Entité 1** : code identité 1, attribut 2, attribut 3
- **Entité 2** : code identité 2, attribut 2, attribut 3
- **Entité 3** : code identité 3, attribut 2, attribut 3
<Callout type="question" title="Pourquoi le premier attribut est en gras et souligné ?">
Dans le MCD, un attribut en gras est un attribut **unique**.
@ -72,7 +72,6 @@ Ici, on a :
- **Entité 1** 0,N - Contenir - 0,N **Entité 2**
- **Entité 1** 1,1 - Posséder - 0,N **Entité 3**
- **Entité 3** 0,N - Diriger - 0,1 **Entité 3**
Mais qu'est-ce que ça veut dire tout ça ?
@ -94,8 +93,6 @@ Toujours dans l'exemple précédent, on comprend donc que :
- **Entité 2** peut être contenue entre 0 et N **Entité 1**
- **Entité 1** doit posséder 1 et 1 seule **Entité 3**
- **Entité 3** peut être possédée entre 0 et N **Entité 1**
- **Entité 3** peut diriger entre 0 et N **Entité 3**
- **Entité 3** peut être dirigée par 0 ou 1 **Entité 3**
<Callout type="note" title="Les différentes valeurs">
La plupart du temps, nous allons retrouver les valeurs suivantes :
@ -112,22 +109,6 @@ Toujours dans l'exemple précédent, on comprend donc que :
Si la valeur n'est pas connue à l'avance ou qu'aucune limite n'est nécessaire, on utilisera alors **N**.
</Callout>
## Les relations réflexives
En regardant notre exemple, on se rend compte que l'entité **Entité 3** est reliée à elle-même par une relation.
C'est ce qu'on appelle une **relation réflexive**.
C'est un cas particulier qui va nous permettre de créer une relation entre une entité et elle-même,
sans avoir à créer une nouvelle entité.
### Situation concrète
Prenons un exemple concret avec une entité **Catégorie**.
Si l'on souhaite qu'une catégorie puisse regrouper plusieurs sous-catégories _(et que ces sous-catégories puissent elles-mêmes regrouper d'autres sous-catégories)_,
on va créer une relation réflexive entre la catégorie et elle-même.
De cette manière, on va pouvoir créer une hiérarchie entre les catégories.
## Retour sur notre dictionnaire de données
Maintenant que l'on sait comment fonctionne un MCD, on va pouvoir retourner sur notre dictionnaire de données pour le formaliser en MCD.

View File

@ -4,129 +4,4 @@ description: Plongez dans le MLD et MRD de Merise pour transformer votre modèle
tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
---
import Callout from "@/components/Callout";
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 :
![Exemple de MCD](/images/merise/mcd-basic.webp)
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 :
![Exemple de MLD](/images/merise/mld-basic.webp)
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.
<Callout type="note" title="Termes">
À partir du MLD, on va commencer à parler de **table** et de **colonne**.
On parlera aussi de **clé primaire** et de **clé étrangère** !
</Callout>
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 :
![MCD final](/images/merise/mcd-4.webp)
Les seules choses que nous avons à faire sont :
- Remplacer les **entités** par des **tables**
- Remplacer les **attributs** par des **colonnes**
<Callout type="warning" title="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)_ !
</Callout>
Voici donc les tables et colonnes que l'on obtient :
![Exemple de MLD sans relations](/images/merise/mld-1.webp)
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")_.
<Callout type="question" title="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)_
</Callout>
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**.
![Exemple de MLD avec relation One to Many](/images/merise/mld-2.webp)
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**.
En cours de rédaction...

Binary file not shown.

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 23 KiB