Le MCD, le MLD et le MPD ne sont pas trois livrables indépendants. Ce sont trois niveaux de lecture d’une même réalité : la structure de données d’un système d’information. La rupture de traçabilité entre ces niveaux est la première source de dette technique dans les projets de bases de données relationnelles. La majorité des anomalies de modélisation naissent dans la transition MCD vers MLD, là où les cardinalités sont interprétées sans validation métier.
Validation métier du passage MCD vers MLD : le maillon faible des projets
Le MCD capture des entités, des associations et des cardinalités. Le MLD traduit ces éléments en tables, clés primaires et clés étrangères. Entre les deux, une décision technique silencieuse se produit : la migration des clés étrangères dépend directement des cardinalités.
Une cardinalité 1,N mal qualifiée en phase conceptuelle génère une clé étrangère dans la mauvaise table au niveau logique. Le problème ne se manifeste qu’en production, quand les requêtes SQL renvoient des résultats incohérents ou quand l’application autorise des insertions qui violent les règles métier.
Chaque association du MCD gagne à être validée par une phrase métier explicite avant de produire le MLD. Par exemple, pour une association entre CLIENT et COMMANDE avec une cardinalité 1,N côté CLIENT : « Un client passe au moins une commande, une commande appartient à un seul client. »
Si le métier répond « non, un client peut exister sans commande », la cardinalité doit passer à 0,N. Ce changement modifie potentiellement la contrainte NOT NULL sur la clé étrangère dans le MLD.
Les cas limites sont rarement discutés. Une association ternaire dans le MCD (trois entités reliées par une même association) se transforme en table de jointure dans le MLD, avec trois clés étrangères. Si personne ne demande au métier si les trois entités sont toujours requises simultanément, la table de jointure risque d’accepter des combinaisons absurdes.
Clés naturelles et clés artificielles : un arbitrage qui se joue entre MLD et MPD
Le MCD ne parle pas de clés. Il identifie des attributs et désigne un identifiant pour chaque entité. Le MLD traduit cet identifiant en clé primaire, et c’est à ce stade que le choix entre clé naturelle et clé artificielle (surrogate) doit être posé.
Beaucoup d’équipes reportent ce choix au MPD, ce qui crée un décalage. Si le MLD utilise un numéro de sécurité sociale comme clé primaire d’une table PERSONNE, toutes les tables liées héritent de cette clé comme clé étrangère. Changer d’avis au moment du MPD pour passer à un identifiant auto-incrémenté oblige à reprendre l’ensemble des relations.
- Clé naturelle : lisible par le métier, mais sensible aux changements de format (numéro de contrat, code postal). À réserver aux entités dont l’identifiant est stable et normalisé.
- Clé artificielle (auto-increment, UUID) : découple l’identifiant technique de la donnée métier. Préférable quand l’identifiant naturel risque d’évoluer ou contient des caractères variables.
- Clé composite : deux attributs ou plus forment la clé primaire, fréquente dans les tables de jointure issues d’associations N,M. Attention à l’impact sur les index et les performances au niveau MPD.
Le choix de la clé doit être acté dans le MLD, pas dans le MPD. Le MPD ne fait qu’implémenter ce choix dans un SGBD cible avec des types de données, des index et des contraintes spécifiques.
Du MLD au MPD : ce qui change réellement selon le SGBD
Le MLD est indépendant du système de gestion de bases de données. Le MPD, lui, est spécifique. C’est la traduction du MLD dans la syntaxe et les contraintes d’un SGBD précis (PostgreSQL, MySQL, Oracle, SQL Server).
Ce qui se décide au niveau MPD et pas avant :
- Les types de données concrets (VARCHAR(255) vs TEXT, INT vs BIGINT, TIMESTAMP vs DATETIME).
- Les stratégies d’indexation : index B-tree sur les clés étrangères, index partiel sur des colonnes filtrées, index GIN pour la recherche plein texte.
- Le partitionnement des tables volumineuses et les tablespaces.
- Les contraintes CHECK et les triggers qui traduisent des règles métier non exprimables par la seule structure relationnelle.
Une erreur fréquente consiste à injecter des préoccupations de MPD dans le MLD. Typer une colonne en JSONB dans un MLD revient à coupler le modèle logique à PostgreSQL. Le MLD doit rester neutre vis-à-vis du SGBD pour conserver sa fonction de point de validation intermédiaire.
Traçabilité MCD-MLD-MPD : méthode concrète de correspondance
Maintenir la correspondance entre les trois modèles suppose un référentiel partagé. Chaque entité du MCD doit être traçable vers une table du MLD, puis vers un objet physique du MPD. En pratique, un tableau de correspondance simple suffit.
| Niveau MCD | Niveau MLD | Niveau MPD |
|---|---|---|
| Entité CLIENT | Table client | CREATE TABLE client (…) ENGINE=InnoDB |
| Association PASSER (1,N) | FK id_client dans table commande | INDEX idx_commande_client ON commande(id_client) |
| Association CONCERNER (N,M) | Table de jointure commande_produit | PRIMARY KEY (id_commande, id_produit) |
Ce tableau se maintient tout au long du projet. Quand le métier modifie une cardinalité dans le MCD, la modification se propage au MLD puis au MPD de manière systématique. Sans ce suivi, les modèles divergent en quelques sprints.
Versionner les modèles comme du code
Les fichiers de modélisation (formats propriétaires ou scripts DDL) gagnent à être versionnés dans le même dépôt que le code applicatif. Un diff entre deux versions du MLD met en évidence les colonnes ajoutées, les clés étrangères supprimées et les changements de cardinalité. Cette pratique réduit les régressions lors des migrations de schéma.
Relier MCD, MLD et MPD n’est pas un exercice académique réservé à la phase de conception initiale. C’est une discipline de projet qui protège la cohérence du système de données sur toute sa durée de vie.
Chaque cardinalité validée avec le métier au niveau MCD se traduit par une clé étrangère fiable au niveau MLD, puis par un schéma physique optimisable sans surprise. Les équipes qui sautent l’étape de validation intermédiaire finissent par corriger en production ce qu’elles auraient pu résoudre sur un diagramme.
