On reçoit un besoin métier formulé en trois phrases floues, et on doit livrer un schéma de base de données propre. Entre les deux, le passage par le MCD puis le MLD reste la méthode la plus fiable pour ne rien oublier et ne rien inventer.
Cet article détaille comment extraire les entités d’un cahier des charges concret, poser des cardinalités vérifiables et convertir le résultat en tables relationnelles sans erreur de structure.
Extraire les entités d’un besoin métier réel
Prenons une situation courante : un responsable logistique demande un outil pour suivre les colis entre entrepôts. Son brief tient en une page et mélange règles de gestion, souhaits d’interface et contraintes réglementaires. La première étape n’est pas de dessiner des boîtes sur un diagramme.
On commence par isoler les noms récurrents dans le brief. Chaque nom qui revient plusieurs fois (colis, entrepôt, transporteur, bon de livraison) est un candidat sérieux pour devenir une entité du MCD. Les verbes associés (expédier, réceptionner, affecter) pointent vers des associations entre ces entités.
Un piège fréquent consiste à créer une entité pour chaque mot du cahier des charges. Si « adresse » n’apparaît que comme attribut d’un entrepôt et ne porte jamais ses propres propriétés distinctes, elle reste un simple attribut, pas une entité séparée. La règle opérationnelle : une entité possède un identifiant propre et au moins un attribut qui ne dépend que d’elle.
Construire un MCD qui reflète les règles de gestion
Une fois les entités candidates listées, on passe aux cardinalités. C’est là que les retours varient le plus d’un projet à l’autre, parce que les cardinalités traduisent directement les règles métier, et celles-ci changent selon l’organisation.
Poser les cardinalités sans deviner
Pour chaque association, on pose deux questions concrètes au métier :
- Un colis peut-il être affecté à plusieurs transporteurs en même temps, ou un seul à la fois ? La réponse donne la cardinalité côté transporteur (0,1 ou 0,N).
- Un transporteur peut-il ne gérer aucun colis à un instant donné ? Si oui, la cardinalité minimale est 0, pas 1.
- Un bon de livraison concerne-t-il toujours exactement un entrepôt de départ et un d’arrivée, ou peut-il regrouper plusieurs origines ? Ce cas change la structure de l’association.
Chaque cardinalité doit être validée par une phrase métier, pas déduite par le modélisateur. Si personne côté métier ne sait répondre, c’est un signal : la règle de gestion n’est pas stabilisée, et le modèle doit le refléter (cardinalité large, quitte à restreindre plus tard).
Attributs et identifiants du modèle conceptuel
L’identifiant d’une entité dans le MCD n’est pas forcément un numéro auto-incrémenté. On cherche d’abord un identifiant naturel issu du métier : numéro de bon de livraison, code entrepôt interne, référence transporteur. L’identifiant technique (clé primaire numérique) viendra au moment du passage au MLD.
Pour les attributs, on applique la règle de dépendance fonctionnelle : chaque attribut ne dépend que de l’identifiant de son entité. Si un attribut dépend d’une combinaison d’entités (par exemple, la date d’expédition dépend du couple colis-transporteur), il se place sur l’association, pas sur une entité.
Passage du MCD au MLD : les règles de conversion concrètes
Le MLD traduit le modèle conceptuel en tables relationnelles. Ce passage suit des règles mécaniques, mais leur application génère régulièrement des erreurs quand on va trop vite.
Associations et clés étrangères selon les cardinalités
Le principe central : la cardinalité détermine où migre la clé étrangère.
- Association 1,1 – 0,N : la clé primaire du côté N migre comme clé étrangère dans la table du côté 1,1. Pas de table intermédiaire.
- Association 0,N – 0,N : on crée une table associative dont la clé primaire est la concaténation des deux clés étrangères. Les attributs portés par l’association deviennent des colonnes de cette table.
- Association 1,1 – 1,1 : cas rare. On fusionne souvent les deux entités en une seule table, sauf contrainte métier explicite.
Ne jamais créer de table associative pour une relation 1,N : c’est l’erreur la plus courante chez les débutants. Elle produit des jointures inutiles et complique les requêtes sans apporter de valeur.
Typage des attributs au niveau logique
Au stade du MLD, chaque attribut reçoit un type de données. On ne choisit pas encore le type SQL exact (c’est le rôle du MPD), mais on précise la nature : texte, entier, date, booléen, décimal. Cette étape permet de repérer les incohérences. Un code postal stocké en entier perdra le zéro initial des départements corses ou parisiens : il faut un type texte.
MCD et MLD face aux architectures NoSQL
Une question revient souvent : faut-il encore passer par le MCD/MLD quand le projet cible une base document (type MongoDB) ou un entrepôt cloud ?
La modélisation conceptuelle garde toute sa valeur, même hors du relationnel. Le MCD sert à clarifier le domaine métier indépendamment de la technologie. On identifie les entités, leurs liens et les règles de gestion. Cette carte reste utile quel que soit le moteur de stockage final.
En revanche, le passage au MLD change de nature. Dans une base document, on ne normalise pas de la même façon : on modélise en fonction des requêtes prévues, pas en fonction des dépendances fonctionnelles. Un document JSON peut embarquer (imbriquer) des données qu’on aurait séparées en tables distinctes dans un schéma relationnel. Le MCD aide à savoir quelles données existent et comment elles se relient. Le choix d’imbriquer ou de référencer se fait ensuite selon les patterns d’accès.
Gouvernance et évolution de schéma dès la modélisation
Les projets récents de data engineering intègrent la question de la traçabilité des modifications de schéma dès la phase de modélisation. Un MLD figé dans un document Word et jamais mis à jour perd sa valeur en quelques mois.
L’approche actuelle consiste à versionner le modèle logique comme du code, et à valider chaque évolution de schéma par des mécanismes automatisés. Des outils comme Great Expectations ou Pydantic permettent de détecter une dérive de schéma avant qu’elle ne casse une chaîne de données en production.
Le MCD et le MLD ne sont pas des livrables figés. Ce sont des documents vivants qui accompagnent le projet. Un modèle conceptuel révisé après chaque atelier métier, couplé à un MLD versionné et testé, réduit le nombre de corrections tardives sur la base de données.
