Un MCD diagram représente les données d’un système d’information sous forme d’entités, d’associations et de cardinalités. Le schéma relationnel, lui, traduit cette représentation conceptuelle en tables, colonnes et clés exploitables par un SGBD. Les deux modèles décrivent les mêmes données, mais à des niveaux d’abstraction différents, et leur confusion reste l’une des erreurs les plus fréquentes en conception de bases de données.
MCD diagram : un modèle qui parle aux métiers, pas aux machines
Le modèle conceptuel de données s’inscrit dans la méthode Merise. Il décrit ce que le système doit stocker, sans se préoccuper de la façon dont un moteur de base de données va le faire. Les briques de base sont les entités (client, commande, produit), les associations qui relient ces entités, et les cardinalités qui précisent combien d’occurrences participent à chaque relation.
Un attribut dans un MCD porte un nom métier compréhensible par un chef de projet ou un responsable fonctionnel. L’identifiant d’une entité (par exemple le numéro client) sert uniquement à garantir l’unicité, pas à organiser physiquement des index ou des jointures.
Le MCD ne mentionne ni clé primaire, ni clé étrangère, ni type de données SQL. C’est précisément cette neutralité technique qui lui donne sa valeur : il devient un support de dialogue entre équipes métier et équipes techniques, là où un schéma relationnel ne parle qu’aux développeurs.
Schéma relationnel : la traduction technique du MCD
Le schéma relationnel (ou modèle logique de données, MLD) est le résultat d’une transformation du MCD. Chaque entité devient une table, chaque attribut devient une colonne, et l’identifiant de l’entité devient la clé primaire de la table.
La différence la plus visible concerne les associations. Dans un MCD, une association « passer » entre un client et une commande est un objet graphique autonome, avec ses propres attributs éventuels. Dans le schéma relationnel, cette association disparaît en tant qu’objet distinct : elle se matérialise par une clé étrangère dans la table concernée, ou par une table de jonction si la cardinalité est de type plusieurs-à-plusieurs.
Règles de passage du MCD au schéma relationnel
- Une entité du MCD produit une relation (table) dont la clé primaire est l’identifiant de l’entité. Tous les attributs de l’entité deviennent des colonnes de cette table.
- Une association avec une cardinalité de type 1,n se traduit par la migration de la clé primaire du côté « 1 » vers le côté « n », sous forme de clé étrangère. Aucune table supplémentaire n’est créée.
- Une association avec une cardinalité n,m génère une table de jonction dont la clé primaire est composée des clés primaires des deux entités associées. Les attributs portés par l’association deviennent des colonnes de cette table intermédiaire.
Ces règles sont déterministes : un même MCD produit un unique schéma relationnel, ce qui permet d’automatiser la transformation avec des outils de modélisation.
Entité, table, relation : le vocabulaire qui crée la confusion
Le terme « relation » est l’un des pièges les plus tenaces. En modélisation conceptuelle (MCD), on parle d’association pour désigner le lien entre deux entités. En modèle relationnel, le mot « relation » désigne une table. Confondre les deux revient à mélanger un lien logique métier et une structure physique de stockage.
Autre source de flou : le mot « attribut » existe dans les deux modèles, mais son rôle change selon le niveau d’abstraction. Dans le MCD, un attribut est une propriété descriptive (nom, date de naissance, montant). Dans le schéma relationnel, ce même attribut devient une colonne typée (VARCHAR, DATE, DECIMAL) avec des contraintes techniques (NOT NULL, UNIQUE, DEFAULT).
La distinction entre identifiant (MCD) et clé primaire (schéma relationnel) suit la même logique. L’identifiant garantit l’unicité au niveau conceptuel. La clé primaire ajoute des implications physiques : index automatique, contrainte d’intégrité référentielle, support des jointures SQL.
Vérification du MCD par simulation de cas réels
Un MCD correct sur le papier peut masquer des anomalies fonctionnelles détectables uniquement à l’usage. Des méthodes de contrôle récentes recommandent de simuler des cas concrets d’insertion, de suppression et de modification directement sur le MCD, avant même le passage au schéma relationnel.
L’objectif est de repérer trois types de problèmes :
- Les données orphelines, créées quand la suppression d’une entité laisse des enregistrements liés sans référence valide dans une autre entité.
- Les créations forcées, quand l’ajout d’un enregistrement dans une association oblige à inventer un enregistrement fictif dans une entité parente pour respecter une cardinalité minimale de 1.
- Les dépendances mal modélisées, quand un attribut dépend d’un autre attribut non identifiant, signe d’un manquement aux formes normales.
Ce travail de validation métier, mené idéalement en atelier avec les parties prenantes du projet, révèle des cardinalités manquantes ou des entités oubliées que la seule lecture du diagramme ne permet pas de voir.
MCD et NoSQL : la question de la pertinence du modèle conceptuel
Le MCD a été conçu pour alimenter des bases de données relationnelles. Avec la montée du NoSQL (bases orientées documents, clé-valeur, graphes), la modélisation ne part plus des entités mais des patterns d’accès. On structure les données en fonction de la manière dont l’application va les lire, quitte à dénormaliser volontairement.
Dans ce contexte, le schéma relationnel perd sa position de cible unique de la transformation. Le MCD reste pertinent comme outil de compréhension du domaine métier, mais le passage vers le stockage physique emprunte un chemin différent : agrégation de données dans un même document, tolérance à la redondance, cohérence dite « eventual consistency ».
Apprendre la distinction MCD / schéma relationnel garde son utilité pédagogique pour comprendre la normalisation et les dépendances fonctionnelles. Transposer mécaniquement cette distinction à un projet NoSQL serait en revanche une erreur de méthode.
Le MCD décrit le « quoi » d’un système d’information ; le schéma relationnel décrit le « comment » pour une base SQL. Passer de l’un à l’autre est une traduction, pas une interprétation : les règles sont formalisées et le résultat est reproductible. Garder cette séparation nette entre niveau conceptuel et niveau logique reste le meilleur garde-fou contre les bases de données mal structurées, quel que soit le moteur utilisé.
