Merise : le modèle conceptuel de données

Le MCD décrit les informations du domaine et leurs liens, sans se soucier du SGBD. Ses éléments : entités, associations, propriétés, identifiants et cardinalités.

Entité et propriétés

Une entité est une famille d’objets du domaine qui ont les mêmes propriétés (CLIENT, ARTICLE, COMMANDE). Une occurrence est un exemple précis (la cliente Alice).

┌────────────────────┐
│       CLIENT       │
├────────────────────┤
│ #num_client        │   # = identifiant
│ nom                │
│ email              │
│ adresse            │
└────────────────────┘

Élément	Règle
Nom	Au singulier, en majuscules (CLIENT, pas CLIENTS)
Identifiant	Propriété (ou groupe) qui désigne une seule occurrence ; souligné ou précédé de `#`
Propriétés	Informations élémentaires (atomiques) de l’entité

L’identifiant doit être stable et unique : un numéro attribué par le système (num_client) est préférable à un attribut qui peut changer (nom, e-mail).

Propriétés calculées : à éviter

Ne pas mettre dans le MCD une valeur qui se calcule à partir d’autres : le total d’une commande se déduit des lignes ; l’âge se déduit de la date de naissance.

À éviter	À modéliser
`age`	`date_naissance`
`total_commande`	quantité et prix des articles
`nombre_commandes`	rien (on compte par une requête)

Stocker un calcul crée une redondance qui peut devenir incohérente (voir Normalisation).

Association

Une association exprime un lien entre des entités. Son nom est un verbe à l’infinitif ou conjugué (PASSER, CONTENIR, APPARTENIR).

┌──────────────┐  (0,N)       (1,1)  ┌────────────────┐
│    CLIENT    │────── PASSER ───────│    COMMANDE    │
├──────────────┤                     ├────────────────┤
│ #num_client  │                     │ #num_commande  │
│ nom          │                     │ date_commande  │
│ email        │                     │ statut         │
└──────────────┘                     └────────────────┘

Une association n’a pas d’identifiant propre : elle est identifiée par la combinaison des identifiants des entités qu’elle relie.

Cardinalités

Une cardinalité s’écrit (min, max) et se place entre l’association et l’entité. Elle indique combien de fois, au minimum et au maximum, une occurrence de l’entité participe à l’association.

Valeurs	Sens
`min` = 0	La participation est facultative
`min` = 1	La participation est obligatoire
`max` = 1	Au plus une fois
`max` = N	Plusieurs fois

Cardinalités courantes : (0,1), (1,1), (0,N), (1,N).

Lire une cardinalité

Pour PASSER entre CLIENT et COMMANDE :

Côté CLIENT : (0,N) : un client passe de zéro à plusieurs commandes (un nouveau client n’a encore rien commandé).
Côté COMMANDE : (1,1) : une commande est passée par exactement un client.

Méthode de lecture : se placer sur une entité, lire « une occurrence de [entité] [verbe de l’association] (min,max) occurrence(s) de [l’autre entité] ».

Types d’associations selon les cardinalités maximales

Type	Cardinalités max	Exemple
Un à plusieurs (1,N)	`1` d’un côté, `N` de l’autre	Un client passe plusieurs commandes
Plusieurs à plusieurs (N,N)	`N` des deux côtés	Une commande contient plusieurs articles ; un article figure dans plusieurs commandes
Un à un (1,1)	`1` des deux côtés	Un client a un compte de connexion

Association porteuse de propriétés

Dans une association plusieurs à plusieurs, certaines informations ne dépendent ni de l’une ni de l’autre entité seule, mais du couple : elles se placent dans l’association.

┌────────────────┐ (1,N)                (0,N) ┌──────────────┐
│    COMMANDE    │────── CONTENIR ────────────│   ARTICLE    │
├────────────────┤  quantite                  ├──────────────┤
│ #num_commande  │  prix_unitaire             │ #reference   │
│ date_commande  │                            │ libelle      │
│ statut         │                            │ prix         │
└────────────────┘                            └──────────────┘

La quantité commandée dépend de la commande ET de l’article : elle appartient à l’association CONTENIR. De même prix_unitaire : le prix de l’article peut changer, mais la commande conserve le prix payé à la date de l’achat (d’où une propriété distincte de prix de l’article).

Le MCD complet du fil rouge

┌──────────────┐ (0,N)      (1,1) ┌────────────────┐ (1,N)             (0,N) ┌──────────────┐
│    CLIENT    │──── PASSER ──────│    COMMANDE    │──── CONTENIR ───────────│   ARTICLE    │
├──────────────┤                  ├────────────────┤   quantite              ├──────────────┤
│ #num_client  │                  │ #num_commande  │   prix_unitaire         │ #reference   │
│ nom          │                  │ date_commande  │                         │ libelle      │
│ email        │                  │ statut         │                         │ prix         │
│ adresse      │                  └────────────────┘                         │ stock        │
└──────────────┘                                                             └──────────────┘

Lecture :

Un client passe 0 à N commandes ; une commande est passée par 1 client.
Une commande contient 1 à N articles (une commande vide n’a pas de sens) ; un article figure dans 0 à N commandes.

Représenter un MCD avec du texte

Écrire un MCD en texte permet de le versionner avec le code. L’outil Mocodo génère un diagramme à partir d’une description :

CLIENT: num_client, nom, email, adresse
PASSER, 0N CLIENT, 11 COMMANDE
COMMANDE: num_commande, date_commande, statut
CONTENIR, 1N COMMANDE, 0N ARTICLE: quantite, prix_unitaire
ARTICLE: reference, libelle, prix, stock

Voir Méthode, outils et pièges. La syntaxe exacte (notation des identifiants, cardinalités 0N, 11) est précisée dans la documentation de l’outil.

Règles de bonne conception

Une entité = un concept du domaine ; ses propriétés décrivent cette entité et rien d’autre.
Une propriété apparaît à un seul endroit (sinon : redondance).
Les associations portent des verbes, les entités des noms.
Pas de propriété multi-valuée (liste de numéros de téléphone dans une propriété) : créer une entité.
Pas de propriété calculable.
Chaque entité a un identifiant.
Toujours justifier chaque cardinalité par une règle de gestion.

Exemples de modélisation à éviter

Erreur	Exemple	Correction
Propriété multi-valuée	`telephones` : « 0601…, 0102… »	Entité TELEPHONE reliée au client
Entité qui n’en est pas une	Entité DATE avec une propriété « jour »	Propriété `date_commande` de COMMANDE
Association sans verbe signifiant	LIEN, RELATION	PASSER, CONTENIR, ÉCRIRE
Information répétée	Adresse du client dans COMMANDE et dans CLIENT	Une seule fois dans CLIENT (la commande peut conserver une adresse de livraison si c’est une donnée distincte)
Cardinalité inversée	CLIENT `(1,1)` côté PASSER	CLIENT `(0,N)` : un client passe plusieurs commandes
Identifiant fragile	E-mail comme identifiant	Numéro technique + contrainte d’unicité sur l’e-mail

Un exemple pas à pas : ajouter les livraisons

Nouvelle règle de gestion : « Une commande est livrée à une adresse ; un client peut avoir plusieurs adresses de livraison. »

L’adresse devient une entité (ADRESSE : #num_adresse, rue, code_postal, ville) car elle a plusieurs propriétés et plusieurs occurrences par client.
Un client a plusieurs adresses ; une adresse appartient à un client : association POSSÉDER CLIENT (0,N) — ADRESSE (1,1).
Une commande est livrée à une adresse : association LIVRER COMMANDE (1,1) — ADRESSE (0,N).

La propriété adresse de CLIENT disparaît : elle est remplacée par une entité liée.

Dépannage

Symptôme	Piste
Je ne sais pas placer une propriété	Demander : « de quoi dépend-elle ? » : d’une entité (propriété de l’entité), d’un couple (propriété de l’association)
Association `(1,1)–(1,1)`	Les deux entités n’en font peut-être qu’une : les fusionner
`(0,N)–(0,N)` partout	Cardinalités trop vagues : les préciser avec les règles de gestion
Une entité sans association	Entité isolée : oubli d’un lien, ou entité inutile
Deux associations entre les mêmes entités	Normal si le sens métier diffère (LIVRER et FACTURER) ; sinon les fusionner
MCD illisible	Disposer les entités pour éviter les croisements, découper par domaine