docs/merise #20
@ -69,7 +69,7 @@ Pour pouvoir le transformer en MLD, il y a plusieurs éléments à prendre en co
|
||||
|
||||
Commençons par les **entités** et leurs **attributs**, on verra les cardinalités après 😉
|
||||
|
||||
### Convertir les entités et attributs
|
||||
## 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 :
|
||||
@ -94,7 +94,7 @@ 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
|
||||
## Convertir les relations
|
||||
|
||||
Pour convertir les relations, il faut d'abord se poser la question de la cardinalité maximale de chaque relation.
|
||||
|
||||
@ -105,7 +105,7 @@ Il y a deux possibilités :
|
||||
|
||||
Un troisième cas existe, dans le cas où la relation est réflexive _(une entité se relie à elle-même)_.
|
||||
|
||||
#### One to Many
|
||||
### ➡️ 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)_.
|
||||
|
||||
@ -130,3 +130,34 @@ Et là : tu remarqueras que les **clés étrangères** sont en italique et sont
|
||||
|
||||
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`
|
||||
- **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**.
|
||||
|
||||
<Callout type="question" title="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**.
|
||||
</Callout>
|
||||
|
||||
### 🔄 Relations réflexives
|
||||
BIN
app/public/images/merise/mld-3.webp
Normal file
BIN
app/public/images/merise/mld-3.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Loading…
Reference in New Issue
Block a user