Merise : du MCD au modèle logique

Le MLD (modèle logique de données) traduit le MCD en tables (relations) : chaque table a des colonnes, une clé primaire et éventuellement des clés étrangères. La notation courante :

CLIENT (#num_client, nom, email, adresse)
COMMANDE (#num_commande, date_commande, statut, _num_client)

Notation	Sens
#colonne ou souligné	Clé primaire
_colonne ou colonne précédée de # en italique	Clé étrangère (selon l’ouvrage)
colonne	Colonne ordinaire

Les conventions de notation varient : indiquer une légende. Dans cette rubrique, # marque la clé primaire et _ une clé étrangère.

Règle 1 : toute entité devient une table

Les propriétés deviennent des colonnes ; l’identifiant devient la clé primaire.

CLIENT (#num_client, nom, email, adresse)
ARTICLE (#reference, libelle, prix, stock)
COMMANDE (#num_commande, date_commande, statut)

Règle 2 : association « un à plusieurs » ((x,1) d’un côté, (x,N) de l’autre)

L’identifiant du côté « N » n’est pas à ajouter : c’est l’entité du côté (·,1) qui reçoit une clé étrangère vers l’entité du côté (·,N).

Pour PASSER : COMMANDE a la cardinalité (1,1) → COMMANDE reçoit la clé étrangère num_client :

CLIENT (#num_client, nom, email, adresse)
COMMANDE (#num_commande, date_commande, statut, _num_client)

Mémo : la clé étrangère va du côté où la cardinalité maximale vaut 1.

Cardinalité côté de l’entité qui reçoit	Clé étrangère
(1,1)	Obligatoire (NOT NULL)
(0,1)	Facultative (peut être NULL)

Règle 3 : association « plusieurs à plusieurs » ((x,N) des deux côtés)

L’association devient une table associative dont la clé primaire est composée des clés des deux entités ; les propriétés de l’association deviennent des colonnes.

COMMANDE (#num_commande, date_commande, statut, _num_client)
ARTICLE (#reference, libelle, prix, stock)
LIGNE_COMMANDE (#_num_commande, #_reference, quantite, prix_unitaire)

La table LIGNE_COMMANDE a pour clé primaire le couple (num_commande, reference) : une commande ne peut pas contenir deux fois le même article (sinon, on ajouterait un numéro de ligne).

Règle 4 : association « un à un » ((x,1) des deux côtés)

Trois possibilités :

Option	Quand
Clé étrangère dans l’une des tables (avec contrainte UNIQUE)	Cas général : choisir le côté (1,1) s’il existe, sinon le côté où la participation est la plus fréquente
Fusionner les deux entités en une table	Les deux entités n’en forment qu’une
Table associative	Association porteuse de propriétés, ou cardinalités (0,1) des deux côtés

CLIENT (#num_client, nom, email)
COMPTE (#num_compte, identifiant, mot_de_passe_hache, _num_client UNIQUE NOT NULL)

Règle 5 : association ternaire (ou plus)

Toujours une table associative dont la clé primaire regroupe les clés de toutes les entités reliées :

DONNER (#_num_enseignant, #_code_cours, #_code_classe, volume_horaire)

Règle 6 : association réflexive

Selon les cardinalités :

Cardinalités	Traduction
(0,1) d’un côté, (0,N) de l’autre (hiérarchie)	Clé étrangère auto-référente
(0,N) des deux côtés	Table associative avec deux clés vers la même table

EMPLOYE (#matricule, nom, poste, _matricule_manager)     -- _matricule_manager référence EMPLOYE
PARRAINAGE (#_matricule_parrain, #_matricule_filleul, date)

Règle 7 : identifiant relatif

La clé primaire de l’entité faible inclut la clé de l’entité dont elle dépend :

COMMANDE (#num_commande, date_commande)
LIGNE_COMMANDE (#_num_commande, #num_ligne, _reference, quantite)

Au niveau physique, on remplace souvent la clé composée par un identifiant technique (id) auquel on ajoute une contrainte d’unicité (UNIQUE (num_commande, num_ligne)) : c’est plus simple à référencer.

Règle 8 : généralisation et spécialisation

Trois stratégies pour PERSONNE (parent) avec CLIENT et EMPLOYE (enfants) :

Stratégie	Description	Avantages	Inconvénients
Une seule table	Une table PERSONNE avec toutes les colonnes et une colonne type	Simple, requêtes rapides	Colonnes inutilisées (NULL), contraintes difficiles
Une table par classe fille	CLIENT et EMPLOYE contiennent aussi les colonnes du parent	Pas de jointure	Duplication des colonnes du parent, requêtes sur « toutes les personnes » compliquées
Table parente + tables filles	PERSONNE (commun) ; CLIENT et EMPLOYE (spécifique) avec clé primaire = clé étrangère vers PERSONNE	Normalisé, souple	Jointures

PERSONNE (#num_personne, nom, email)
CLIENT (#_num_personne, adresse_facture, points_fidelite)        -- clé primaire = clé étrangère
EMPLOYE (#_num_personne, poste, date_embauche)

La troisième option est la plus fidèle au MCD ; la première est souvent le bon compromis quand les différences sont faibles. Les bases de documents (MongoDB) acceptent naturellement des documents de formes différentes dans une même collection.

Le MLD complet du fil rouge

CLIENT (#num_client, nom, email, adresse)
COMMANDE (#num_commande, date_commande, statut, _num_client)
ARTICLE (#reference, libelle, prix, stock)
LIGNE_COMMANDE (#_num_commande, #_reference, quantite, prix_unitaire)

Table	Clé primaire	Clés étrangères
CLIENT	num_client
COMMANDE	num_commande	num_client → CLIENT
ARTICLE	reference
LIGNE_COMMANDE	(num_commande, reference)	num_commande → COMMANDE, reference → ARTICLE

Contraintes d’intégrité référentielle

Une clé étrangère garantit qu’elle référence une ligne existante. Le comportement lors d’une suppression ou d’une modification est à décider table par table :

Action	Effet à la suppression de la ligne référencée
RESTRICT / NO ACTION	Refuse la suppression si des lignes dépendent
CASCADE	Supprime aussi les lignes dépendantes
SET NULL	Met la clé étrangère à NULL (si elle est facultative)
SET DEFAULT	Valeur par défaut

Exemples : supprimer une commande supprime ses lignes (CASCADE) ; supprimer un client qui a des commandes est refusé (RESTRICT) ; supprimer un article déjà commandé est refusé (l’historique doit rester cohérent).

Vérifier le MLD

• Chaque table a une clé primaire.
• Chaque association « un à plusieurs » est traduite par une clé étrangère du bon côté.
• Chaque association « plusieurs à plusieurs » a sa table associative.
• Aucune colonne multi-valuée ni calculable.
• Les colonnes dépendent de la clé entière et de rien d’autre (voir Normalisation).

Dépannage

Symptôme	Piste
Clé étrangère du mauvais côté	Elle va du côté où la cardinalité maximale vaut 1
Deux clés étrangères qui se réfèrent mutuellement	Association (1,1)–(1,1) : fusionner les tables
Table associative sans clé primaire	Clé primaire composée des clés étrangères
Un article apparaît plusieurs fois dans une même commande	Clé primaire composée : une ligne par article ; ou ajouter num_ligne si le doublon est légitime
Beaucoup de colonnes NULL	Héritage en table unique mal adapté : séparer
Nom de colonne ambigu	Préfixer par la table (num_client plutôt que id dans le MLD ; au niveau physique, id partout est aussi courant)

Ubuntu 24.04 et 26.04 : différences à connaître

Aucune.

Pour aller plus loin

• Modèle relationnel (Wikipédia)
• Suite : Normalisation

Dans la même rubrique

• Introduction et démarche
• Le modèle conceptuel de données
• MCD avancé
• Du MCD au modèle logique
• Normalisation
• Du modèle physique au SQL
• Méthode, outils et pièges