La vérification de la cohérence entre un MCD et un MLD ne se résume pas à compter les tables. Elle consiste à s’assurer que chaque décision de modélisation au niveau conceptuel se retrouve fidèlement traduite au niveau logique, sans perte d’information ni introduction de règles implicites non formulées. C’est à ce point de jonction que se concentrent la majorité des anomalies dans les projets de bases de données relationnelles.
MCD et MLD : deux niveaux de lecture du même système d’information
Le modèle conceptuel de données décrit les entités du domaine (CLIENT, COMMANDE, PRODUIT), leurs attributs et les associations qui les relient, avec leurs cardinalités. Il est indépendant de tout système de gestion de base de données.
Le modèle logique de données traduit ces éléments en tables, colonnes, clés primaires et clés étrangères. Chaque entité du MCD devient une table. Chaque identifiant d’entité devient une clé primaire. Les associations, selon leurs cardinalités, donnent naissance soit à une clé étrangère dans une table existante, soit à une table de liaison.
Entre ces deux niveaux, aucune décision n’est neutre. La règle de passage des cardinalités vers les clés étrangères est mécanique en apparence, mais elle suppose que les cardinalités du MCD aient été posées correctement. Un MLD cohérent ne peut pas corriger un MCD mal formulé.
Règles de passage MCD vers MLD : les points de contrôle
Vérifier le passage d’un MCD à un MLD revient à appliquer systématiquement trois règles de transformation, puis à contrôler que chaque association a bien été traitée.
- Association 1,N : la clé étrangère se place du côté de l’entité dont la cardinalité maximale est 1. Si CLIENT (1,N) passe COMMANDE (1,1), la clé étrangère CLIENT_ID se retrouve dans la table COMMANDE. L’inverser est une erreur fréquente qui génère des doublons ou des valeurs NULL inexplicables.
- Association N,N : elle génère obligatoirement une table de liaison. Cette table contient au minimum les deux clés primaires des entités reliées, qui forment ensemble sa clé primaire composite. Si des attributs portent l’association dans le MCD, ils deviennent des colonnes de cette table de liaison.
- Association 1,1 : deux approches sont valides – fusionner les deux entités en une seule table, ou placer la clé étrangère dans l’une des deux tables avec une contrainte UNIQUE. Le choix doit être explicite et justifié dans le modèle.
Un point de contrôle souvent négligé concerne les attributs porteurs d’association. Dans le MCD, une association N,N peut avoir ses propres attributs (par exemple, une quantité dans une association entre COMMANDE et PRODUIT). Si ces attributs n’apparaissent pas dans la table de liaison du MLD, l’information est perdue.
Identifier les incohérences entre entités et tables
La première vérification consiste à s’assurer que toute entité du MCD correspond à exactement une table dans le MLD, et inversement. Une entité sans table signifie une perte de données. Une table sans entité correspondante signifie une décision implicite non tracée.
La deuxième vérification porte sur les cardinalités minimales. Une cardinalité minimale de 1 dans le MCD signifie qu’une ligne doit obligatoirement être associée à une autre. Au niveau logique, cela se traduit par une contrainte NOT NULL sur la clé étrangère. Si la clé étrangère est nullable alors que la cardinalité minimale était 1, le modèle logique contredit le modèle conceptuel.
Ce point est plus subtil qu’il n’y paraît. Une clé étrangère nullable n’exige pas de ligne correspondante lorsque sa valeur est NULL. Une règle métier formulée dans le MCD peut donc être silencieusement désactivée dans le MLD si cette correspondance n’est pas vérifiée.
Contraintes CHECK et NULL : la cohérence ne s’arrête pas aux clés étrangères
Un MLD cohérent va au-delà de la simple traduction des associations. Les règles de gestion portées par les attributs du MCD doivent elles aussi trouver une expression logique.
Une contrainte CHECK peut exprimer une règle portant sur une ligne (par exemple, qu’une date de fin est postérieure à une date de début). Mais une contrainte CHECK qui retourne NULL n’échoue pas : si la colonne concernée peut être nulle, la contrainte ne s’applique pas réellement. Il faut combiner CHECK et NOT NULL pour garantir qu’une règle s’applique effectivement.
Les règles qui impliquent plusieurs lignes (par exemple, qu’un client ne peut pas avoir deux commandes actives simultanées) ne se modélisent pas avec un CHECK simple. Elles nécessitent soit une contrainte UNIQUE sur la combinaison de colonnes appropriée, soit une clé étrangère, soit une logique applicative documentée dans le MLD.
Tracer la cohérence entre MCD et MLD dans la pratique
La vérification de la cohérence entre les deux modèles est plus fiable quand elle s’appuie sur une correspondance explicite, entité par entité et association par association. Un tableau de traçabilité simple suffit : colonne MCD (entité ou association), colonne MLD (table ou clé étrangère générée), colonne règle appliquée, colonne contrainte correspondante.
Cette approche permet de repérer rapidement les oublis. Si une ligne du MCD n’a pas de correspondance dans le MLD, la traduction est incomplète. Si une table du MLD n’a pas de ligne dans le MCD, une décision a été prise hors modèle et doit être justifiée.
Les outils de modélisation comme PowerDesigner permettent de générer automatiquement un MLD à partir d’un MCD et d’effectuer une vérification syntaxique du modèle. Ces vérifications automatiques détectent les entités sans identifiant, les associations sans cardinalité ou les attributs dupliqués. Elles ne remplacent pas la vérification métier : elles confirment que le modèle est formellement valide, pas qu’il reflète fidèlement les règles de gestion.
La cohérence entre MCD et MLD repose en définitive sur une discipline de traçabilité : chaque règle métier formulée au niveau conceptuel doit avoir une expression explicite au niveau logique, sous forme de contrainte de clé, de NOT NULL ou de CHECK. Les règles sans traduction restent des intentions non garanties par la base de données.
