Compare commits
3 Commits
6560e90e08
...
9bb09898b0
| Author | SHA1 | Date | |
|---|---|---|---|
| 9bb09898b0 | |||
| 659bcf94d9 | |||
| 780b002de0 |
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Dictionnaire de données pour Merise
|
||||
description: Apprends à créer un dictionnaire de données pour Merise
|
||||
title: Dictionnaire de Données Merise
|
||||
description: Explorez le dictionnaire de données dans Merise, essentiel pour structurer et documenter les informations de votre système.
|
||||
tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
|
||||
---
|
||||
|
||||
@ -14,13 +14,18 @@ Pour cet article et les suivants, on va se reposer sur une mise en situation fic
|
||||
|
||||
## Brief avec le client
|
||||
|
||||
Le client est un petit groupe local qui doit faciliter l'organisation interne pour la gestion de ses différentes activités (répétitions, concerts, etc.).
|
||||
Le client est un groupe qui doit faciliter l'organisation interne pour la gestion de ses différentes activités (répétitions, concerts, etc.).
|
||||
Il souhaite donc créer une application pour gérer les informations suivantes :
|
||||
|
||||
- **Membre** : Nom, prénom, instruments, adresse e-mail, mot de passe
|
||||
- **Musicien** : Nom, prénom, instruments, adresse e-mail, mot de passe
|
||||
- **Concert** : Date et heure, lieu, tarif
|
||||
- **Répétition** : Date et heure, lieu
|
||||
|
||||
Le client a aussi précisé que le mot de passe doit faire plus de 12 caractères, et que l'adresse e-mail doit être unique.
|
||||
|
||||
En ce qui concerne les répétitions et les concerts, il nous a indiqué que tous les musiciens ne sont pas forcément présents à chaque répétition ou concert.
|
||||
Il faut donc prévoir un moyen pour savoir qui est présent à chaque répétition et concert.
|
||||
|
||||
Pour le moment, on ne va pas se soucier de la technique, mais juste de lister les données que l'on doit stocker dans la base de données.
|
||||
On va donc créer un tableau qui va nous permettre de lister toutes les données que l'on doit stocker dans notre base de données.
|
||||
|
||||
@ -65,18 +70,18 @@ Tu risques de retrouver ton client en train de convulser sur le sol : **pas glop
|
||||
|
||||
Voici donc le dictionnaire de données que l'on va créer pour notre application :
|
||||
|
||||
| Nom de la donnée | Format | Longueur | Contraintes | Document(s) |
|
||||
| --------------------------- | -------------- | -------- | ------------------- | ----------- |
|
||||
| Nom | Alphabétique | 30 | Obligatoire | Membre |
|
||||
| Prénom | Alphabétique | 30 | Obligatoire | Membre |
|
||||
| Instruments | Alphabétique | 30 | Obligatoire | Membre |
|
||||
| Adresse e-mail | Alphanumérique | 50 | Obligatoire, unique | Membre |
|
||||
| Mot de passe | Alphanumérique | > 12 | Obligatoire | Membre |
|
||||
| Date et heure de concert | Date | - | Obligatoire | Concert |
|
||||
| Lieu de concert | Alphabétique | 50 | Obligatoire | Concert |
|
||||
| Tarif | Numérique | - | - | Concert |
|
||||
| Date et heure de répétition | Date | - | Obligatoire | Répétition |
|
||||
| Lieu de répétition | Alphabétique | 50 | Obligatoire | Répétition |
|
||||
| Nom de la donnée | Format | Longueur | Contraintes | Document |
|
||||
| --------------------------- | -------------- | -------- | ------------------- | ---------- |
|
||||
| Nom | Alphabétique | 30 | Obligatoire | Musicien |
|
||||
| Prénom | Alphabétique | 30 | Obligatoire | Musicien |
|
||||
| Instruments | Alphabétique | 30 | Obligatoire | Musicien |
|
||||
| Adresse e-mail | Alphanumérique | 50 | Obligatoire, unique | Musicien |
|
||||
| Mot de passe | Alphanumérique | > 12 | Obligatoire | Musicien |
|
||||
| Date et heure de concert | Date | - | Obligatoire | Concert |
|
||||
| Lieu de concert | Alphabétique | 50 | Obligatoire | Concert |
|
||||
| Tarif | Numérique | - | - | Concert |
|
||||
| Date et heure de répétition | Date | - | Obligatoire | Répétition |
|
||||
| Lieu de répétition | Alphabétique | 50 | Obligatoire | Répétition |
|
||||
|
||||
Voilà, on a notre dictionnaire de données !
|
||||
|
||||
|
||||
207
app/data/docs/merise/mcd/page.md
Normal file
207
app/data/docs/merise/mcd/page.md
Normal file
@ -0,0 +1,207 @@
|
||||
---
|
||||
title: Modèle Conceptuel de Données (MCD) Merise
|
||||
description: Comprenez le MCD dans Merise, une étape clé pour représenter les données de manière abstraite et cohérente.
|
||||
tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
|
||||
---
|
||||
|
||||
On va enfin pouvoir commencer à réaliser notre premier schéma : le **MCD** _(Modèle Conceptuel de Données)_ !
|
||||
|
||||
Mais déjà... qu'est-ce que c'est que ce MCD ?
|
||||
|
||||
## Qu'est-ce que le MCD ?
|
||||
|
||||
Le **MCD** est un schéma qui va nous permettre de représenter les données que l'on a récupérées dans le dictionnaire de données.
|
||||
|
||||
Il va nous permettre de représenter les différentes données que l'on a, regroupée dans un rectangle nommé **entité**, ainsi que les relations entre elles.
|
||||
On devra également indiquer les **cardinalités** de chaque relation entre les **entités**.
|
||||
|
||||
Tout comme le dictionnaire de données, ce schéma doit rester compréhensible par le client.
|
||||
Il doit donc être le plus simple possible, et ne pas contenir de détails techniques.
|
||||
|
||||
Pour ce schéma _(ainsi que les suivants)_, on va utiliser le logiciel **Looping**.
|
||||
|
||||
## Définitions
|
||||
|
||||
Tu l'auras remarqué, ici on ne parle pas de "table" ou de "colonne".
|
||||
On va exploiter d'autres termes comme **entité**, **attribut** ou **relation**.
|
||||
|
||||
Voici un petit lexique pour t'aider à comprendre :
|
||||
|
||||
| Terme | Définition |
|
||||
| ------------------------------------------------------- | ------------------------------------------------------------------------------------- |
|
||||
| **Entité** | Représentation d'un regroupement de données _(rectangle)_ |
|
||||
| **Attribut** | Donnée précise d'une entité |
|
||||
| **Relation** | Lien entre deux entités _(bulle ovale/arrondie)_, accompagné d'un verbe à l'infinitif |
|
||||
| **Cardinalité** | Nombre d'occurrences _(minimum et maximum)_ d'une entité par rapport à une autre |
|
||||
| **Discriminant** _(ou **déterminant**/**identifiant**)_ | Attribut qui permet d'identifier une entité de manière unique _(ex: matricule)_ |
|
||||
|
||||
C'est tout un lexique à apprendre, mais pas de panique tu vas vite t'y habituer !
|
||||
|
||||
## Exemple de MCD
|
||||
|
||||
Forcément, les définitions sans donner un exemple ça n'aide pas beaucoup à comprendre...
|
||||
Voici un petit exemple tout simple de MCD pour illustrer tout ça :
|
||||
|
||||
|
||||
|
||||
On a ici un MCD qui représente trois **entités** :
|
||||
|
||||
- **Entité 1**
|
||||
- **Entité 2**
|
||||
- **Entité 3**
|
||||
|
||||
Chacune de ces entités a plusieurs **attributs** qui lui sont propres :
|
||||
|
||||
- **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**.
|
||||
S'il est souligné en plus d'être en gras, c'est qu'il s'agit d'un **discriminant** _(ou déterminant/identifiant)_.
|
||||
|
||||
Il permet d'identifier de manière unique une entité.
|
||||
Comme le MCD n'est **pas technique**, on n'utilisera pas le terme de **clé primaire** ou **ID**.
|
||||
{% /callout %}
|
||||
|
||||
Et pour terminer, on remarque aussi que certaines de nos entités sont reliées entre elles par des **relations**.
|
||||
Les relations se caractèrisent par :
|
||||
|
||||
- Une bulle ovale ou arrondie contenant un verbe à l'infinitif _(par exemple : "posséder")_
|
||||
- Des **cardinalités** qui vont indiquer le nombre d'occurrences d'une entité par rapport à une autre.
|
||||
|
||||
Ici, on a :
|
||||
|
||||
- **Entité 1** 0,N - Contenir - 0,N **Entité 2**
|
||||
- **Entité 1** 1,1 - Posséder - 0,N **Entité 3**
|
||||
|
||||
Mais qu'est-ce que ça veut dire tout ça ?
|
||||
|
||||
## Les cardinalités
|
||||
|
||||
Les cardinalités sont un élément essentiel du MCD.
|
||||
Elles vont nous permettre de définir le nombre d'occurrences d'une entité par rapport à une autre.
|
||||
|
||||
Une cardinalité est définie par deux valeurs :
|
||||
|
||||
1. Le **minimum** d'occurrences
|
||||
2. Le **maximum** d'occurrences
|
||||
|
||||
On va donc avoir des cardinalités de la forme : **X,Y**.
|
||||
|
||||
Toujours dans l'exemple précédent, on comprend donc que :
|
||||
|
||||
- **Entité 1** peut contenir entre 0 et N **Entité 2**
|
||||
- **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**
|
||||
|
||||
{% callout type="note" title="Les différentes valeurs" %}
|
||||
La plupart du temps, nous allons retrouver les valeurs suivantes :
|
||||
|
||||
- **0**
|
||||
- **1**
|
||||
- **N**
|
||||
|
||||
**N** signifie "N'importe quel nombre" _(0, 1, 2, 3, ...)_.
|
||||
Mais dès que l'on connait le nombre exact, on peut le mettre à la place de **N**.
|
||||
|
||||
Par exemple : **1,5** signifie "1 à 5" et **0,3** signifie "0 à 3".
|
||||
|
||||
Si la valeur n'est pas connue à l'avance ou qu'aucune limite n'est nécessaire, on utilisera alors **N**.
|
||||
{% /callout %}
|
||||
|
||||
## 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.
|
||||
|
||||
Pour rappel, voici notre dictionnaire de données :
|
||||
|
||||
| Nom de la donnée | Format | Longueur | Contraintes | Document |
|
||||
| --------------------------- | -------------- | -------- | ------------------- | ---------- |
|
||||
| Nom | Alphabétique | 30 | Obligatoire | Musicien |
|
||||
| Prénom | Alphabétique | 30 | Obligatoire | Musicien |
|
||||
| Instruments | Alphabétique | 30 | Obligatoire | Musicien |
|
||||
| Adresse e-mail | Alphanumérique | 50 | Obligatoire, unique | Musicien |
|
||||
| Mot de passe | Alphanumérique | > 12 | Obligatoire | Musicien |
|
||||
| Date et heure de concert | Date | - | Obligatoire | Concert |
|
||||
| Lieu de concert | Alphabétique | 50 | Obligatoire | Concert |
|
||||
| Tarif | Numérique | - | - | Concert |
|
||||
| Date et heure de répétition | Date | - | Obligatoire | Répétition |
|
||||
| Lieu de répétition | Alphabétique | 50 | Obligatoire | Répétition |
|
||||
|
||||
### Les entités
|
||||
|
||||
On va donc créer trois entités :
|
||||
|
||||
- **Musicien**
|
||||
- **Concert**
|
||||
- **Répétition**
|
||||
|
||||
Ces entités vont contenir les attributs que l'on a récupérés dans le dictionnaire de données.
|
||||
|
||||
On se retrouve pour le moment avec un MCD qui ressemble à ça :
|
||||
|
||||
|
||||
On est déjà pas trop mal, il nous reste plus qu'à ajouter les relations entre les entités et les cardinalités !
|
||||
|
||||
### Les relations
|
||||
|
||||
On va donc ajouter les relations entre les entités.
|
||||
|
||||
Sachant qu'un musicien peut participer à plusieurs concerts, et qu'un concert peut avoir plusieurs musiciens, on va créer une relation entre les deux entités.
|
||||
On va donc créer une relation **"Participer"** entre les entités **Musicien** et **Concert**.
|
||||
|
||||
On en fera une relation **0,N** - **1,N**.
|
||||
|
||||
Pour la répétition, on va faire la même chose !
|
||||
On va créer une relation **"Répéter"** entre les entités **Musicien** et **Répétition**.
|
||||
|
||||
À la fin, on se retrouve avec un MCD qui ressemble à ça :
|
||||
|
||||
|
||||
Et c'est tout ! Notre MCD est terminé... enfin presque !
|
||||
|
||||
### Aller plus loin
|
||||
|
||||
Si on souhaite aller plus loin, on peut ajouter de l'héritage.
|
||||
|
||||
{% callout type="note" title="Rapide point sur l'héritage" %}
|
||||
L'héritage _(ou aussi appelé **spécialisation** ou **généralisation**)_ est un concept qui va nous permettre de factoriser les propriétés identiques dans une entité commune. Cette entitée est appelée **entité générique** _(ou **sur-type**)_.
|
||||
|
||||
Les entités qui héritent de l'entité générique sont appelées **entités spécialisées** _(ou **sous-types**)_.
|
||||
{% /callout %}
|
||||
|
||||
En regardant bien notre MCD, on se rend compte que les entités **Concert** et **Répétition** ont des attributs communs :
|
||||
|
||||
- Date et heure
|
||||
- Lieu
|
||||
|
||||
La seule différence est que le concert a un tarif, contrairement à la répétition.
|
||||
On va donc pouvoir créer une entité **générique** que l'on appelera **Événement**.
|
||||
|
||||
Cette entité générique va contenir les attributs communs aux deux entités, et on va faire hériter les entités **Concert** et **Répétition** de cette entité.
|
||||
On se retrouve donc avec ces trois entités _(**Événement**, **Concert** et **Répétition**)_ :
|
||||
|
||||
|
||||
{% callout type="question" title="Pourquoi ne pas stocker le type d'événement ?" %}
|
||||
Effectivement, on aurait pu stocker le type d'événement dans l'entité **Événement** !
|
||||
Il s'agit d'une autre approche qui est tout à fait valable.
|
||||
|
||||
Cependant, il est plus simple de créer une entité générique qui va nous permettre de factoriser les attributs communs et éviter de devoir rendre plusieurs attributs nullables en fonction du type d'événement.
|
||||
|
||||
On renforce ainsi l'intégrité de la base de données.
|
||||
{% /callout %}
|
||||
|
||||
Le MCD final ressemble donc à ça :
|
||||
|
||||
|
||||
Si tu souhaites télécharger le MCD que l'on vient de créer, tu peux le faire ici : [MCD Merise pour Looping](/downloads/merise/band-manager.loo).
|
||||
|
||||
## Conclusion
|
||||
|
||||
En conclusion, le MCD dans Merise est un outil indispensable pour structurer et visualiser les données de manière claire et cohérente.
|
||||
|
||||
Grâce à des entités, des attributs, des relations et des cardinalités, le MCD permet de représenter les informations de façon abstraite, tout en restant compréhensible pour le client.
|
||||
|
||||
Prochaine étape : le **MLD** _(Modèle Logique de Données)_ et le **MRD** _(Modèle Relationnel de Données)_ !
|
||||
7
app/data/docs/merise/mld/page.md
Normal file
7
app/data/docs/merise/mld/page.md
Normal file
@ -0,0 +1,7 @@
|
||||
---
|
||||
title: Modèle Logique/Relationnel de Données (MLD/MRD) Merise
|
||||
description: Plongez dans le MLD et MRD de Merise pour transformer votre modèle conceptuel en une structure relationnelle optimisée.
|
||||
tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
|
||||
---
|
||||
|
||||
En cours de rédaction...
|
||||
@ -1,213 +0,0 @@
|
||||
---
|
||||
title: Introduction à Merise
|
||||
description: Parlons un peu de Merise, la fameuse méthodologie de modélisation pour la conception de bases de données.
|
||||
tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
|
||||
---
|
||||
|
||||
On va enfin pouvoir commencer à réaliser notre premier schéma : le **MCD** _(Modèle Conceptuel de Données)_ !
|
||||
|
||||
Mais déjà... qu'est-ce que c'est que ce MCD ?
|
||||
|
||||
## Qu'est-ce que le MCD ?
|
||||
|
||||
Le **MCD** est un schéma qui va nous permettre de représenter les données que l'on a récupérées dans le dictionnaire de données.
|
||||
|
||||
Il va nous permettre de représenter les différentes données que l'on a, regroupée dans un rectangle nommé **entité**, ainsi que les relations entre elles.
|
||||
On devra également indiquer les **cardinalités** de chaque relation entre les **entités**.
|
||||
|
||||
Tout comme le dictionnaire de données, ce schéma doit rester compréhensible par le client.
|
||||
Il doit donc être le plus simple possible, et ne pas contenir de détails techniques.
|
||||
|
||||
Pour ce schéma _(ainsi que les suivants)_, on va utiliser le logiciel **Looping**.
|
||||
|
||||
## Définitions
|
||||
|
||||
Tu l'auras remarqué, ici on ne parle pas de "table" ou de "colonne".
|
||||
On va exploiter d'autres termes comme **entité**, **attribut** ou **relation**.
|
||||
|
||||
Voici un petit lexique pour t'aider à comprendre :
|
||||
|
||||
| Terme | Définition |
|
||||
| --------------------------------------- | ------------------------------------------------------------------------------------- |
|
||||
| **Entité** | Représentation d'un regroupement de données _(rectangle)_ |
|
||||
| **Attribut** | Donnée précise d'une entité |
|
||||
| **Relation** | Lien entre deux entités _(bulle ovale/arrondie)_, accompagné d'un verbe à l'infinitif |
|
||||
| **Cardinalité** | Nombre d'occurrences _(minimum et maximum)_ d'une entité par rapport à une autre |
|
||||
| **Discriminant** _(ou **déterminant**)_ | Attribut qui permet d'identifier une entité de manière unique _(ex: matricule)_ |
|
||||
|
||||
C'est tout un lexique à apprendre, mais pas de panique tu vas vite t'y habituer !
|
||||
|
||||
## Premières entités
|
||||
|
||||
Commençons par créer notre MCD avec les données que l'on a récupérées dans le dictionnaire de données !
|
||||
En reprenant notre tableau précédent, on constate que l'on a :
|
||||
|
||||
- **Pomme de terre**
|
||||
- **Salarié**
|
||||
- **Vente**
|
||||
|
||||
Dans un premier temps, concentrons-nous sur les deux premières entités : **Pomme de terre** et **Salarié**.
|
||||
|
||||
On va donc créer deux rectangles, un pour chaque entité.
|
||||
Dans chacune d'elles, on va ajouter les attributs que l'on a récupérés dans le dictionnaire de données.
|
||||
|
||||
On se retrouve donc avec un schéma similaire à celui-ci :
|
||||
|
||||
|
||||
|
||||
On a donc deux entités : **Pomme de terre** et **Salarié**.
|
||||
Chacune d'elles contient les attributs que l'on a récupérés dans le dictionnaire de données.
|
||||
|
||||
Avant d'aller plus loin, on va analyser ce qu'on a fait.
|
||||
|
||||
### Entité "Pomme de terre"
|
||||
|
||||
L'entité **Pomme de terre** contient les attributs suivants :
|
||||
|
||||
- **Variété** : Nom de la variété de la pomme de terre
|
||||
- **Stock** : Quantité de pommes de terre en stock
|
||||
|
||||
### Entité "Salarié"
|
||||
|
||||
L'entité **Salarié** contient les attributs suivants :
|
||||
|
||||
- **Matricule** : Numéro d'immatriculation du salarié
|
||||
- **Nom** : Nom du salarié
|
||||
- **Prénom** : Prénom du salarié
|
||||
|
||||
## Spécificité des attributs d'entité
|
||||
|
||||
C'est un bon début, mais il nous manque des choses !
|
||||
Il est essentiel de pouvoir identifier une ressource de manière unique.
|
||||
|
||||
Côté base de données on parle souvent de **clé primaire** _(ou **primary key**)_, mais souvenons-nous que notre document doit rester compréhensible par le client.
|
||||
On parlera donc de **discriminant** _(ou **déterminant**)_.
|
||||
|
||||
Si on regarde notre entité **Pomme de terre**, on peut se rendre compte que l'on n'a pas d'attribut qui permet d'identifier une pomme de terre de manière unique.
|
||||
On va donc ajouter un nouvel attribut : **Code pomme de terre**.
|
||||
|
||||
Ce terme se veut simple et compréhensible par le client, mais il est important de lui expliquer que ce code est unique pour chaque pomme de terre.
|
||||
On va donc ajouter cet attribut à notre entité **Pomme de terre**.
|
||||
|
||||
Pour l'entité **Salarié**, on a déjà un attribut qui permet d'identifier un salarié de manière unique : **Matricule**.
|
||||
On va donc le garder tel quel, en le considérant comme un **discriminant**.
|
||||
|
||||
On va donc mettre à jour notre MCD avec les nouveaux attributs :
|
||||
|
||||
|
||||
|
||||
Et déjà, c'est beaucoup mieux !
|
||||
|
||||
{% callout type="warning" title="Discriminant et ID" %}
|
||||
|
||||
Tu l'auras remarqué, je n'ai pas utilisé le terme `ID` pour désigner le **discriminant**.
|
||||
La raison est simple : le terme `ID` est souvent utilisé pour désigner un identifiant **technique**.
|
||||
|
||||
Il ne s'agit pas d'une donnée réelle à proprement parler, mais d'un identifiant qui va nous permettre de retrouver une donnée dans la base de données.
|
||||
|
||||
Le client n'ayant pas besoin de savoir ce qu'est un identifiant technique, on va préférer utiliser le terme **discriminant** ou **déterminant**.
|
||||
|
||||
{% /callout %}
|
||||
|
||||
## Données uniques et discriminants
|
||||
|
||||
Je fais un rapide point entre les données uniques et discriminants !
|
||||
Les deux attributs sont **uniques**, mais n'ont pas la même signification.
|
||||
|
||||
Dans l'exemple donné plus tôt avec l'attribut **Matricule**, il s'agit d'un **discriminant naturel**. Dans ce cas précis, il s'agit d'une **donnée réelle** _(métier)_ qui permet d'identifier un salarié de manière unique.
|
||||
|
||||
Maintenant, prenons l'exemple d'un compte utilisateur sur un site web avec :
|
||||
|
||||
- **Email** : Adresse email de l'utilisateur
|
||||
- **Mot de passe** : Mot de passe de l'utilisateur
|
||||
|
||||
On serait tenté de se dire que l'adresse email est un discriminant du fait que cette donnée se doit d'être unique.
|
||||
Pourtant, ce n'est pas le cas.
|
||||
|
||||
La raison est simple : l'adresse email peut être **modifiée par l'utilisateur**.
|
||||
|
||||
Un discriminant se veut **unique**, **fixe** et **non modifiable**.
|
||||
En gros, les mêmes contraintes que pour une **clé primaire** _(même si on ne doit pas utiliser ce terme dans un MCD)_.
|
||||
|
||||
Maintenant, à quoi ça ressemble dans un MCD ?
|
||||
|
||||
### Représentation graphique entre discriminant et unique
|
||||
|
||||
Une donnée unique se représente par une écriture **épaisse** sur le nom de l'attribut d'une entité.
|
||||
On sait qu'il s'agit d'une donnée unique, mais pas forcément d'un discriminant.
|
||||
|
||||
Le discriminant reprend cette même écriture, mais ajoute un **soulignement** sur le nom de l'attribut.
|
||||
|
||||
|
||||
|
||||
## Relations entre entités
|
||||
|
||||
Oui, on passe déjà aux relations entre entités !
|
||||
Et si jamais tu te poses la question : "Et **Vente** alors ?"... et bien on en parle juste maintenant !
|
||||
|
||||
Dans notre situation, une vente relie les entités **Pomme de terre** et **Salarié**.
|
||||
On va donc créer une nouvelle entité : **Vente**.
|
||||
|
||||
Dans notre cas, on sait qu'une vente est réalisée par un salarié et concerne une ou plusieurs pommes de terre.
|
||||
C'est donc maintenant que l'on peut parler de **cardinalité** !
|
||||
|
||||
### Écriture et lecture des cardinalités
|
||||
|
||||
La cardinalité est un élément essentiel dans la modélisation de données. Elle permet de définir le nombre d'occurrences d'une entité par rapport à une autre.
|
||||
|
||||
Une cardinalité se compose de deux valeurs :
|
||||
|
||||
- **Minimum** : Nombre minimum d'occurrences _(0, 1, ...)_
|
||||
- **Maximum** : Nombre maximum d'occurrences _(1, 2, N, ...)_
|
||||
|
||||
{% callout type="question" title="C'est quoi ce `N` ?" %}
|
||||
|
||||
`N` représente une valeur **illimitée**.
|
||||
|
||||
Dans le cas d'une vente, on ne limite pas le nombre maximale de variétés de pommes de terre vendues lors d'une transaction.
|
||||
On peut donc dire que le nombre de variétés de pommes de terre vendues est **illimité**.
|
||||
|
||||
{% /callout %}
|
||||
|
||||
## Définition de nos cardinalités
|
||||
|
||||
Il est temps d'en finir avec notre MCD et ces histoires de cardinalités !
|
||||
|
||||
Voici comment on va définir nos cardinalités :
|
||||
|
||||
- **Pomme de terre** et **Vente** :
|
||||
- Une pomme de terre peut être vendue plusieurs fois, mais pas forcément _(0,N)_
|
||||
- Une vente concerne au moins une pomme de terre, jusqu'à une infinité de pommes de terre _(1,N)_
|
||||
- **Salarié** et **Vente** :
|
||||
- Un salarié peut réaliser plusieurs ventes, mais pas forcément _(0,N)_
|
||||
- Une vente est réalisée par un et un seul salarié _(1,1)_
|
||||
|
||||
En ajoutant des verbes **à l'infinitif** pour expliquer la relation entre les entités, on obtient :
|
||||
|
||||
|
||||
|
||||
Et là, on est presque bon !
|
||||
Il nous manque juste un petit détail : la **quantité** vendue d'une variété de pomme de terre au cours d'une vente.
|
||||
|
||||
## Relations N-N
|
||||
|
||||
Si on regarde de plus prêt notre relation **INCLURE** entre **Pomme de terre** et **Vente**, on se rend compte qu'il s'agit d'une relation **N-N** _(Many to Many)_.
|
||||
|
||||
Ce type de relation permet l'ajout d'attributs à la relation elle-même.
|
||||
Lors de l'étape suivante _(MLD)_, on verra comment gérer ce type de relation.
|
||||
|
||||
Ici, on va pouvoir ajouter un nouvel attribut à notre relation : **Quantité**.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
Gros morceau, n'est-ce pas ? 😅
|
||||
|
||||
## Ressources supplémentaires
|
||||
|
||||
- [La vérité sur les id - Jean Prulière](https://jeanpruliere.medium.com/la-v%C3%A9rit%C3%A9-sur-les-id-507134adda12)
|
||||
|
||||
---
|
||||
|
||||
Prochaine étape, on parle du **MLD** _(Modèle Logique de Données)_ !
|
||||
7
app/data/docs/merise/mpd/page.md
Normal file
7
app/data/docs/merise/mpd/page.md
Normal file
@ -0,0 +1,7 @@
|
||||
---
|
||||
title: Modèle Physique de Données (MPD) Merise
|
||||
description: Apprenez à créer le MPD dans Merise, la dernière étape pour concrétiser votre base de données sur un SGBD.
|
||||
tags: [Backend, Merise, BDD, MCD, MLD, MPD, SQL]
|
||||
---
|
||||
|
||||
En cours de rédaction...
|
||||
@ -47,11 +47,12 @@ export const navigation: NavigationSection[] = [
|
||||
type: navigationsTypes.CERTIFICATIONS,
|
||||
position: "auto",
|
||||
links: [
|
||||
{ title: "Résumé", href: "/certifications/dwwm", subitems: [] },
|
||||
{ title: "Résumé du titre", href: "/certifications/dwwm", subitems: [] },
|
||||
{
|
||||
title: "Activité Type 1",
|
||||
href: "/certifications/dwwm/at1",
|
||||
subitems: [
|
||||
{ title: "Résumé de l'AT", href: "/certifications/dwwm/at1" },
|
||||
{ title: "CP 1", href: "/certifications/dwwm/at1/cp1" },
|
||||
{ title: "CP 2", href: "/certifications/dwwm/at1/cp2" },
|
||||
{ title: "CP 3", href: "/certifications/dwwm/at1/cp3" },
|
||||
@ -62,6 +63,7 @@ export const navigation: NavigationSection[] = [
|
||||
title: "Activité Type 2",
|
||||
href: "/certifications/dwwm/at2",
|
||||
subitems: [
|
||||
{ title: "Résumé de l'AT", href: "/certifications/dwwm/at2" },
|
||||
{ title: "CP 5", href: "/certifications/dwwm/at2/cp5" },
|
||||
{ title: "CP 6", href: "/certifications/dwwm/at2/cp6" },
|
||||
{ title: "CP 7", href: "/certifications/dwwm/at2/cp7" },
|
||||
@ -79,6 +81,7 @@ export const navigation: NavigationSection[] = [
|
||||
title: "React",
|
||||
href: "/docs/react",
|
||||
subitems: [
|
||||
{ title: "Introduction", href: "/docs/react" },
|
||||
{ title: "Initialisation", href: "/docs/react/initialisation" },
|
||||
{ title: "Syntaxe JSX", href: "/docs/react/jsx" },
|
||||
{ title: "Premier composant", href: "/docs/react/premier-composant" },
|
||||
@ -99,8 +102,11 @@ export const navigation: NavigationSection[] = [
|
||||
title: "Merise",
|
||||
href: "/docs/merise",
|
||||
subitems: [
|
||||
{ title: "Introduction", href: "/docs/merise" },
|
||||
{ title: "Dictionnaire de données", href: "/docs/merise/dictionnaire-de-donnees" },
|
||||
{ title: "Modèle Conceptuel de Données", href: "/docs/merise/modele-conceptuel-de-donnees" },
|
||||
{ title: "Modèle Conceptuel de Données", href: "/docs/merise/mcd" },
|
||||
{ title: "Modèle Logique de Données", href: "/docs/merise/mld" },
|
||||
{ title: "Modèle Physique de Données", href: "/docs/merise/mpd" },
|
||||
],
|
||||
},
|
||||
],
|
||||
|
||||
BIN
app/public/downloads/merise/band-manager.lo1
Normal file
BIN
app/public/downloads/merise/band-manager.lo1
Normal file
Binary file not shown.
BIN
app/public/downloads/merise/band-manager.loo
Normal file
BIN
app/public/downloads/merise/band-manager.loo
Normal file
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 7.6 KiB After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.8 KiB After Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
BIN
app/public/merise/mcd-basic.webp
Normal file
BIN
app/public/merise/mcd-basic.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Loading…
Reference in New Issue
Block a user