%% nav-debut : généré par gen_navigation.py, ne pas modifier à la main %%
> [!nav]
> ↩ [[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/Modèle conceptuel de Données|Accueil · Modèle conceptuel de Données]]
%% nav-fin %%
[[Modélisation Conceptuelle des données]]
# Introduction
Avant de créer une base de données, il faut la penser.
Il ne faut pas commencer par ouvrir un logiciel.
Il faut d’abord comprendre :
- quelles données sont utiles ;
- comment elles sont liées ;
- quelles règles elles doivent respecter.
Le **Modèle Conceptuel de Données**, ou **MCD**, sert à représenter ces informations.
Il décrit les données d’un système.
Il ne décrit pas encore les tables SQL.
Il ne décrit pas encore les types de données.
Il se place au niveau conceptuel.
```mermaid
flowchart LR
A[Réalité du besoin] --> B[Analyse]
B --> C[MCD]
C --> D[Schéma relationnel]
D --> E[Base de données]
```
>[!important]
>Le MCD est une étape essentielle.
>
>Si le MCD est faux, la base de données sera mal conçue.
---
## 1. Pourquoi faire un MCD ?
Un MCD permet de formaliser les données nécessaires à un projet.
Il permet aussi de représenter les liens entre ces données.
Il sert de pont entre :
- le besoin du client ;
- la future base de données.
```mermaid
flowchart TD
A[Besoin exprimé par le client] --> B[Données nécessaires]
B --> C[Modèle Conceptuel de Données]
C --> D[Schéma relationnel]
D --> E[Tables SQL]
```
>[!note]
>Le MCD ne représente pas encore les tables.
>
>Les tables seront obtenues plus tard avec le schéma relationnel.
---
## 2. Exemple support : une DVDthèque
Nous voulons créer une application pour gérer une DVDthèque.
L’application doit permettre de gérer :
- les films ;
- les genres ;
- les personnes ;
- les emprunteurs ;
- les emprunts.
### Besoin exprimé
Pour chaque film, on veut connaître :
- son titre ;
- sa durée ;
- son résumé ;
- son année de réalisation ;
- son genre ;
- ses acteurs ;
- ses réalisateurs.
Pour chaque personne, on veut connaître :
- son nom ;
- son prénom ;
- sa date de naissance.
Une même personne peut être acteur et réalisateur.
Pour chaque emprunteur, on veut connaître :
- son nom ;
- son prénom ;
- son téléphone ;
- son adresse.
Pour chaque emprunt, on veut connaître :
- le film emprunté ;
- l’emprunteur ;
- la date d’emprunt ;
- la date de retour.
```mermaid
flowchart TD
A[DVDthèque] --> B[Films]
A --> C[Personnes]
A --> D[Genres]
A --> E[Emprunteurs]
A --> F[Emprunts]
B --> B1[Titre]
B --> B2[Durée]
B --> B3[Résumé]
B --> B4[Année]
C --> C1[Nom]
C --> C2[Prénom]
C --> C3[Date de naissance]
F --> F1[Date d'emprunt]
F --> F2[Date de retour]
```
---
## 3. Les quatre concepts du formalisme Entité–Association
Le MCD utilise le formalisme **Entité–Association**.
Ce formalisme repose sur quatre notions principales.
```mermaid
mindmap
root((MCD))
Propriétés
Entités
Associations
Cardinalités
```
---
# 4. Les propriétés
## 4.1 Définition
Une **propriété** est une information élémentaire.
Elle décrit une donnée simple.
>[!definition]
>Une propriété modélise une information élémentaire utilisée dans le système étudié.
### Exemples
Dans une DVDthèque, les propriétés peuvent être :
- `Titre`
- `Durée`
- `Résumé`
- `Nom_Emprunteur`
- `Prénom_Emprunteur`
- `Téléphone_Emprunteur`
- `Date_Emprunt`
---
## 4.2 Une propriété doit être unique
Une propriété ne doit apparaître qu’une seule fois dans un MCD.
Si deux propriétés ont le même nom, il faut se poser une question.
S’agit-il vraiment de la même information ?
### Exemple
`Nom` peut désigner :
- le nom d’un emprunteur ;
- le nom d’un acteur ;
- le nom d’un réalisateur.
Il vaut mieux écrire :
- `Nom_Emprunteur`
- `Nom_Individu`
>[!warning]
>Une propriété ambiguë rend le MCD difficile à comprendre.
>
>Il faut utiliser des noms précis.
---
## 4.3 Occurrence d’une propriété
Une **occurrence** est une valeur possible d’une propriété.
### Exemple
Pour la propriété `Nom_Emprunteur`, on peut avoir :
| Propriété | Occurrences |
|---|---|
| `Nom_Emprunteur` | Dubois |
| `Nom_Emprunteur` | Martin |
| `Nom_Emprunteur` | Planque |
>[!note]
>La propriété est le nom de l’information.
>
>L’occurrence est une valeur concrète.
---
# 5. Les entités
## 5.1 Définition
Une **entité** regroupe des objets de même nature.
>[!definition]
>Une entité modélise un ensemble d’objets de même nature manipulés dans le système d’information.
### Exemples
Dans une DVDthèque, on peut trouver les entités suivantes :
- `Film`
- `Genre`
- `Individu`
- `Emprunteur`
```mermaid
flowchart LR
A[Entité Film] --> B[Titre]
A --> C[Durée]
A --> D[Résumé]
A --> E[Année de réalisation]
```
---
## 5.2 Une entité est décrite par des propriétés
Une entité possède des propriétés.
### Exemple : entité `Film`
```text
Film
- ID_Film
- Titre
- Durée
- Résumé
- Année_de_réalisation
```
### Exemple : entité `Emprunteur`
```text
Emprunteur
- ID_Emprunteur
- Nom_Emprunteur
- Prénom_Emprunteur
- Téléphone_Emprunteur
- Adresse_Emprunteur
```
---
## 5.3 Occurrence d’une entité
Une occurrence d’entité est un objet concret.
### Exemple
L’entité `Emprunteur` peut avoir plusieurs occurrences.
| ID_Emprunteur | Nom | Prénom | Téléphone | Ville |
|---|---|---|---|---|
| 1 | Dubois | Jean | 03.22.36.36.25 | Amiens |
| 2 | Martin | Philippe | 03.20.06.60.60 | Lille |
| 3 | Latoile | Bernard | 03.20.36.64.89 | Lille |
Chaque ligne est une occurrence.
---
# 6. L’identifiant
## 6.1 Définition
Un **identifiant** permet de reconnaître une occurrence de manière unique.
>[!definition]
>Un identifiant est une propriété, ou un groupe de propriétés, qui permet d’identifier une occurrence de façon unique.
### Exemple
Deux emprunteurs peuvent avoir le même nom.
Deux emprunteurs peuvent même avoir le même prénom.
Il est donc préférable d’utiliser un identifiant technique.
```text
ID_Emprunteur
```
Cet identifiant est unique.
```mermaid
flowchart TD
A[Emprunteur] --> B[ID_Emprunteur]
A --> C[Nom_Emprunteur]
A --> D[Prénom_Emprunteur]
A --> E[Téléphone_Emprunteur]
B --> F[Identifie une seule occurrence]
```
>[!tip]
>Dans un MCD, l’identifiant est souvent placé en premier dans l’entité.
>
>Il est aussi souligné dans les représentations classiques.
---
# 7. Les associations
## 7.1 Définition
Une **association** représente un lien entre une ou plusieurs entités.
>[!definition]
>Une association modélise un lien entre des entités du système d’information.
### Exemple
Un emprunteur emprunte un film.
Il existe donc une association entre :
- `Emprunteur`
- `Film`
```mermaid
flowchart LR
A[Emprunteur] --> B{Emprunter}
B --> C[Film]
```
---
## 7.2 Une association peut avoir des propriétés
Une association peut porter ses propres informations.
### Exemple
L’association `Emprunter` possède :
- `Date_Emprunt`
- `Date_Retour`
Ces propriétés ne décrivent pas seulement l’emprunteur.
Elles ne décrivent pas seulement le film.
Elles décrivent l’acte d’emprunter.
```mermaid
flowchart LR
A[Emprunteur] --> B{Emprunter}
C[Film] --> B
B --> D[Date_Emprunt]
B --> E[Date_Retour]
```
>[!important]
>Une propriété doit être placée au bon endroit.
>
>Si elle décrit le lien, elle appartient à l’association.
---
# 8. La dimension d’une association
La dimension correspond au nombre d’entités reliées par une association.
## 8.1 Association binaire
Une association binaire relie deux entités.
### Exemple
Un emprunteur emprunte un film.
```mermaid
flowchart LR
A[Emprunteur] --> B{Emprunter}
B --> C[Film]
```
---
## 8.2 Association réflexive
Une association réflexive relie une entité à elle-même.
### Exemple
Un employé peut être le supérieur d’un autre employé.
```mermaid
flowchart LR
A[Employé] --> B{Être le supérieur de}
B --> A
```
---
## 8.3 Association ternaire
Une association ternaire relie trois entités.
### Exemple
Un client loue une voiture auprès d’un commercial.
```mermaid
flowchart TD
A[Client] --> D{Louer}
B[Voiture] --> D
C[Commercial] --> D
```
>[!warning]
>Les associations ternaires sont plus difficiles à vérifier.
>
>Il faut s’assurer que les trois entités sont vraiment nécessaires.
---
# 9. Les cardinalités
## 9.1 Définition
Les **cardinalités** indiquent combien de fois une occurrence d’entité peut participer à une association.
>[!definition]
>Une cardinalité est un couple de nombres.
>
>Elle indique le minimum et le maximum de participations d’une occurrence d’entité à une association.
La forme générale est :
```text
minimum, maximum
```
Exemples :
- `0,1`
- `0,n`
- `1,1`
- `1,n`
---
## 9.2 Cardinalité minimale
La cardinalité minimale peut être :
| Valeur | Sens |
|---|---|
| `0` | La participation est facultative |
| `1` | La participation est obligatoire |
---
## 9.3 Cardinalité maximale
La cardinalité maximale peut être :
| Valeur | Sens |
|---|---|
| `1` | Une seule participation au maximum |
| `n` | Plusieurs participations possibles |
---
## 9.4 Les quatre cardinalités classiques
| Cardinalité | Signification |
|---|---|
| `0,1` | Zéro ou une participation |
| `0,n` | Zéro, une ou plusieurs participations |
| `1,1` | Une et une seule participation |
| `1,n` | Une ou plusieurs participations |
---
## 9.5 Exemple avec les emprunts
Règles de gestion :
- Un emprunteur est enregistré lorsqu’il emprunte au moins une fois.
- Un emprunteur peut emprunter plusieurs films.
- Un film peut ne jamais être emprunté.
- Un film peut être emprunté plusieurs fois.
```mermaid
flowchart LR
A[Emprunteur] -- "1,n" --> B{Emprunter}
B -- "0,n" --> C[Film]
```
>[!example]
>Un emprunteur participe au moins une fois à l’association `Emprunter`.
>
>Un film peut participer zéro fois ou plusieurs fois.
---
# 10. Association hiérarchique
Une association hiérarchique est une association binaire avec une cardinalité `0,1` ou `1,1`.
### Exemple
Un contrat est signé par un seul client.
Un client peut signer plusieurs contrats.
```mermaid
flowchart LR
A[Client] -- "0,n" --> B{Signer}
B -- "1,1" --> C[Contrat]
```
Ici, si on connaît le contrat, on connaît le client.
Il existe donc une dépendance fonctionnelle :
```text
N°Contrat → ID_Client
```
>[!warning]
>Dans une association hiérarchique forte, les propriétés de l’association doivent souvent être déplacées vers l’entité du côté `1,1`.
---
# 11. Construire un MCD
La construction d’un MCD se fait en plusieurs étapes.
```mermaid
flowchart TD
A[Lire le besoin] --> B[Créer le dictionnaire de données]
B --> C[Épurer le dictionnaire]
C --> D[Identifier les entités]
D --> E[Identifier les associations]
E --> F[Ajouter les cardinalités]
F --> G[Vérifier le MCD]
```
---
## 11.1 Étape 1 : créer le dictionnaire de données
Le dictionnaire de données liste toutes les données utiles.
### Exemple brut
| Donnée |
|---|
| nom de l’emprunteur |
| prénom de l’emprunteur |
| téléphone |
| adresse |
| titre du film |
| durée |
| résumé |
| année |
| nom acteur |
| prénom acteur |
| date de naissance acteur |
| genre |
---
## 11.2 Étape 2 : épurer le dictionnaire
Il faut nettoyer le dictionnaire.
On doit traiter :
- les synonymes ;
- les polysèmes ;
- les propriétés calculées.
---
### Les synonymes
Deux noms différents peuvent désigner la même information.
### Exemple
```text
Email = Courriel = Adresse électronique
```
Il faut choisir un seul nom.
---
### Les polysèmes
Un même mot peut désigner plusieurs informations.
### Exemple
`Date_Achat` peut signifier :
- la date d’achat par le client ;
- la date d’achat au fournisseur.
Il faut alors créer deux propriétés différentes.
```text
Date_Achat_Client
Date_Achat_Fournisseur
```
---
### Les propriétés calculées
Une propriété calculée peut être obtenue à partir d’autres propriétés.
### Exemple
```text
Total_HT = Quantité × Prix_Unitaire_HT
```
En général, on ne stocke pas `Total_HT`.
>[!warning]
>Stocker une propriété calculée peut créer des incohérences.
>
>Si on la conserve, il faut prévoir des contrôles.
---
# 12. Placer les propriétés au bon endroit
Une propriété doit dépendre de l’identifiant de l’entité ou de l’association où elle se trouve.
## 12.1 Propriété dans une entité
Si une propriété décrit une entité, elle va dans cette entité.
### Exemple
`Année_de_réalisation` décrit un film.
Elle va donc dans `Film`.
```text
Film
- ID_Film
- Titre
- Durée
- Résumé
- Année_de_réalisation
```
---
## 12.2 Propriété dans une association
Si une propriété décrit un lien, elle va dans l’association.
### Exemple
`Date_Emprunt` décrit l’emprunt d’un film par un emprunteur.
Elle va donc dans `Emprunter`.
```mermaid
flowchart LR
A[Emprunteur] --> B{Emprunter}
C[Film] --> B
B --> D[Date_Emprunt]
B --> E[Date_Retour]
```
---
# 13. Modéliser correctement le temps
La notion de temps est souvent difficile.
Une date peut être :
- une propriété d’une entité ;
- une propriété d’une association ;
- parfois une entité.
Il faut analyser le besoin.
---
## 13.1 Exemple : date de réalisation
L’année de réalisation caractérise le film.
Elle appartient donc à `Film`.
```text
Film
- ID_Film
- Titre
- Année_de_réalisation
```
---
## 13.2 Exemple : date d’emprunt
La date d’emprunt caractérise l’action d’emprunter.
Elle appartient donc à l’association `Emprunter`.
```mermaid
flowchart LR
A[Emprunteur] --> B{Emprunter}
C[Film] --> B
B --> D[Date_Emprunt]
```
---
## 13.3 Pourquoi ajouter la date d’emprunt à l’identification ?
Supposons :
- l’emprunteur n°12 emprunte le film n°45 le 12/01/2004 ;
- le même emprunteur emprunte le même film le 10/04/2004.
Si l’association est identifiée seulement par :
```text
ID_Emprunteur + ID_Film
```
alors les deux emprunts ont le même identifiant.
C’est un problème.
Il faut ajouter la date d’emprunt.
```text
ID_Emprunteur + ID_Film + Date_Emprunt
```
Ainsi, les deux emprunts sont distingués.
>[!important]
>Pour conserver l’historique, il faut que chaque emprunt soit identifiable.
---
# 14. Vérifier un MCD
Une fois le MCD construit, il faut le vérifier.
```mermaid
flowchart TD
A[MCD construit] --> B[Vérifier les propriétés]
B --> C[Vérifier les entités]
C --> D[Vérifier les associations]
D --> E[Vérifier les formes normales]
E --> F[Supprimer les redondances]
F --> G[Ajouter les contraintes d'intégrité]
```
---
## 14.1 Vérifier les propriétés
Chaque propriété doit respecter deux règles.
>[!check]
>Une propriété apparaît une seule fois dans le MCD.
>
>Une propriété ne doit pas être calculée, sauf cas particulier.
---
## 14.2 Vérifier les entités
Chaque entité doit avoir un identifiant.
>[!check]
>Une entité sans identifiant est incorrecte.
---
## 14.3 Vérifier les associations
Il faut vérifier que toutes les entités de l’association sont nécessaires.
### Exemple
Dans une association ternaire, chaque occurrence doit nécessiter les trois entités.
Si une entité n’est pas nécessaire, le modèle doit être simplifié.
---
# 15. Les formes normales
Les formes normales permettent de vérifier la qualité du MCD.
En première année, les trois premières formes normales suffisent souvent.
```mermaid
flowchart LR
A[1ère forme normale] --> B[2ème forme normale]
B --> C[3ème forme normale]
```
---
## 15.1 Première forme normale
>[!definition]
>Une entité ou une association est en première forme normale si chaque propriété est atomique.
Une propriété atomique ne contient qu’une seule valeur.
### Mauvais exemple
```text
Film
- ID_Film
- Titre
- Noms_Acteurs
```
`Noms_Acteurs` peut contenir plusieurs noms.
Ce n’est pas atomique.
### Correction
Il faut créer une entité `Individu`.
Puis relier `Film` et `Individu`.
```mermaid
flowchart LR
A[Film] --> B{Tourner}
B --> C[Individu]
```
---
## 15.2 Deuxième forme normale
>[!definition]
>Une entité ou association est en deuxième forme normale si elle est en première forme normale et si toutes ses propriétés dépendent de tout l’identifiant.
Cette règle concerne surtout les associations.
### Exemple
Une commande contient des produits.
```mermaid
flowchart LR
A[Commande] --> B{Concerner}
B --> C[Produit]
B --> D[Quantité]
B --> E[Prix_HT]
```
Si le prix dépend uniquement du produit, alors il ne doit pas être dans l’association.
Il doit être placé dans `Produit`.
```mermaid
flowchart LR
A[Commande] --> B{Concerner}
B --> C[Produit]
B --> D[Quantité]
C --> E[Prix_HT]
```
---
## 15.3 Troisième forme normale
>[!definition]
>Une entité ou association est en troisième forme normale si elle est en deuxième forme normale et si toutes ses propriétés dépendent directement de l’identifiant.
Il ne doit pas y avoir de dépendance indirecte.
### Mauvais exemple
```text
Film
- ID_Film
- Titre
- Catégorie_Public
- Age_Minimum
```
Si `Age_Minimum` dépend de `Catégorie_Public`, alors il faut créer une entité `Catégorie`.
### Correction
```mermaid
flowchart LR
A[Film] -- "1,1" --> B{Appartenir}
B -- "0,n" --> C[Catégorie]
C --> D[Age_Minimum]
```
---
# 16. La redondance de l’information
Une redondance existe quand une information est présente plusieurs fois.
Elle peut créer des incohérences.
### Exemple
Un client signe un contrat.
Le contrat concerne une voiture.
Il est inutile d’ajouter directement une association `Louer` entre `Client` et `Voiture` si cette information est déjà connue par le contrat.
```mermaid
flowchart TD
A[Client] --> B{Signer}
B --> C[Contrat]
C --> D{Concerner}
D --> E[Voiture]
```
>[!warning]
>Une association redondante doit être supprimée.
>
>Mais seulement si elle n’apporte aucune information supplémentaire.
---
# 17. Les contraintes d’intégrité
Un MCD ne suffit pas toujours.
Certaines règles ne se voient pas directement dans le schéma.
Il faut alors ajouter des contraintes d’intégrité.
>[!definition]
>Une contrainte d’intégrité est une règle ajoutée au MCD pour éviter des incohérences.
---
## 17.1 Exemple : formation
Un employé peut donner une formation.
Un employé peut recevoir une formation.
Mais un employé ne doit pas recevoir une formation qu’il donne.
```mermaid
flowchart LR
A[Employé] --> B{Donner}
B --> C[Formation]
A --> D{Recevoir}
D --> C
```
### Contrainte à ajouter
```text
Un employé qui donne une formation ne peut pas recevoir cette même formation.
```
---
## 17.2 Exemple : QCM
Un QCM a une durée totale.
Plusieurs matières peuvent être abordées.
Chaque matière a un temps imparti.
La somme des temps impartis ne doit pas dépasser la durée du QCM.
```mermaid
flowchart LR
A[QCM] --> B{Aborder}
B --> C[Matière]
B --> D[Temps_imparti]
A --> E[Durée]
```
### Contrainte à ajouter
```text
Pour un QCM donné :
Somme des temps impartis ≤ Durée du QCM
```
---
# 18. Exemple complet : MCD simplifié de la DVDthèque
Voici une représentation simplifiée du MCD de la DVDthèque.
```mermaid
flowchart TD
G[Genre] -- "0,n" --> A{Avoir}
A -- "1,1" --> F[Film]
F -- "0,n" --> T{Tourner}
T -- "0,n" --> I[Individu]
F -- "0,n" --> R{Réaliser}
R -- "0,n" --> I
E[Emprunteur] -- "1,n" --> EM{Emprunter}
EM -- "0,n" --> F
EM --> DE[Date_Emprunt]
EM --> DR[Date_Retour]
```
---
## 18.1 Entités principales
```text
Genre
- ID_Genre
- Nom_Genre
```
```text
Film
- ID_Film
- Titre
- Durée
- Résumé
- Année_de_réalisation
```
```text
Individu
- ID_Individu
- Nom_Individu
- Prénom_Individu
- Date_Naissance
```
```text
Emprunteur
- ID_Emprunteur
- Nom_Emprunteur
- Prénom_Emprunteur
- Téléphone_Emprunteur
- Adresse_Emprunteur
```
---
## 18.2 Associations principales
```text
Avoir
- relie Film et Genre
```
```text
Tourner
- relie Film et Individu
```
```text
Réaliser
- relie Film et Individu
```
```text
Emprunter
- relie Emprunteur et Film
- Date_Emprunt
- Date_Retour
```
---
# 19. À retenir
>[!summary]
>Un MCD sert à représenter les données d’un système.
>
>Il se construit avant la base de données.
>
>Il utilise le formalisme Entité–Association.
>
>Il repose sur quatre notions :
>
>- propriétés ;
>- entités ;
>- associations ;
>- cardinalités.
>[!summary]
>Une bonne propriété est :
>
>- unique ;
>- claire ;
>- non ambiguë ;
>- atomique ;
>- placée au bon endroit.
>[!summary]
>Une bonne entité possède :
>
>- un nom au singulier ;
>- un identifiant ;
>- des propriétés qui dépendent de cet identifiant.
>[!summary]
>Une bonne association représente :
>
>- un lien utile ;
>- entre une ou plusieurs entités ;
>- avec parfois des propriétés propres.
---
# 20. Méthode rapide pour construire un MCD
```mermaid
flowchart TD
A[1. Lire le besoin] --> B[2. Lister les données]
B --> C[3. Nettoyer le dictionnaire]
C --> D[4. Trouver les entités]
D --> E[5. Placer les propriétés]
E --> F[6. Trouver les associations]
F --> G[7. Ajouter les cardinalités]
G --> H[8. Vérifier les formes normales]
H --> I[9. Supprimer les redondances]
I --> J[10. Ajouter les contraintes]
```
---
# 21. Exercices d’application
## Exercice 1
On veut gérer une bibliothèque.
On souhaite connaître :
- les livres ;
- les auteurs ;
- les lecteurs ;
- les emprunts.
Un livre possède :
- un titre ;
- une année de publication ;
- un ISBN.
Un auteur possède :
- un nom ;
- un prénom.
Un lecteur possède :
- un nom ;
- un prénom ;
- une adresse mail.
Un lecteur peut emprunter plusieurs livres.
Un livre peut être emprunté plusieurs fois.
Chaque emprunt possède :
- une date d’emprunt ;
- une date de retour prévue ;
- une date de retour réelle.
### Questions
1. Listez les propriétés.
2. Proposez les entités.
3. Proposez les associations.
4. Ajoutez les cardinalités.
5. Identifiez les contraintes d’intégrité possibles.
---
## Exercice 2
On veut gérer des commandes clients.
Un client passe des commandes.
Une commande contient plusieurs produits.
Un produit peut apparaître dans plusieurs commandes.
Pour chaque ligne de commande, on veut connaître la quantité commandée.
### Questions
1. Pourquoi `Quantité` doit-elle être dans l’association ?
2. Quelle association faut-il créer entre `Commande` et `Produit` ?
3. Quelles cardinalités proposez-vous ?
4. Le prix du produit doit-il être dans `Produit` ou dans l’association ? Justifiez.
---
# 22. Mini-glossaire
| Terme | Définition courte |
|---|---|
| MCD | Modèle Conceptuel de Données |
| Propriété | Information élémentaire |
| Entité | Ensemble d’objets de même nature |
| Occurrence | Exemple concret d’une propriété ou d’une entité |
| Identifiant | Propriété qui identifie une occurrence |
| Association | Lien entre entités |
| Cardinalité | Nombre minimum et maximum de participations |
| Contrainte d’intégrité | Règle ajoutée pour éviter les incohérences |
| Forme normale | Règle de qualité du modèle |
---
# 23. Conclusion
Le MCD est une étape de conception.
Il oblige à comprendre le besoin avant de créer la base.
Il limite les erreurs futures.
Il rend la structure des données plus claire.
Il prépare le passage au schéma relationnel.
>[!important]
>Un bon MCD se construit avec méthode.
>
>Il se vérifie.
>
>Il se discute.
>
>Il se corrige avant toute création de base de données.
%% nav-debut : généré par gen_navigation.py, ne pas modifier à la main %%
> [!nav]
> ↩ [[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/Modèle conceptuel de Données|Accueil · Modèle conceptuel de Données]]
%% nav-fin %%