On a tous vécu ce moment où un MCD proprement dessiné sur papier ou dans un outil de modélisation finit en script SQL bancal, avec des colonnes oubliées ou des relations mal traduites. Le passage du modèle conceptuel de données au code SQL n’est pas une formalité : chaque raccourci pris à cette étape se paie en incohérences dans la base de production. Voici comment aborder cette transformation méthodiquement, en gardant intacte chaque information du modèle d’origine.
Traduire les entités en tables SQL : les pièges sur les attributs
La règle de base paraît simple : une entité du MCD devient une table, chaque attribut devient une colonne, et l’identifiant de l’entité devient la clé primaire. Sur le terrain, les oublis se nichent dans les détails.
Un attribut composite (une adresse découpée en rue, code postal, ville) doit être éclaté en autant de colonnes distinctes. Si on le laisse dans une seule colonne texte, on perd la capacité de filtrer par ville ou par code postal. Le MCD signalait cette décomposition, le SQL doit la respecter.
Les attributs multivalués posent un autre problème. Un client qui possède plusieurs numéros de téléphone ne peut pas stocker ces valeurs dans une seule colonne sans violer la première forme normale. La solution : créer une table dédiée (par exemple telephones_clients) reliée par une clé étrangère vers la table clients. C’est une table qui n’existait pas dans le MCD en tant qu’entité, mais qui découle directement d’un attribut.
Types de données et contraintes NOT NULL
Le MCD ne précise généralement pas les types SQL. C’est au moment de la transformation qu’on décide si un attribut « date de naissance » sera un DATE, un DATETIME ou un VARCHAR mal choisi. Chaque attribut obligatoire dans le modèle conceptuel doit recevoir une contrainte NOT NULL dans le script SQL.
Ne pas poser ces contraintes revient à autoriser des lignes incomplètes dans la base, ce qui contredit le modèle d’origine. On perd de l’information non pas parce qu’une donnée disparaît, mais parce qu’on autorise son absence là où le MCD l’interdisait.
Associations et cardinalités : la mécanique de traduction MCD vers MLD puis SQL
C’est ici que la majorité des erreurs surviennent. Le traitement d’une association dépend entièrement de ses cardinalités, et le passage par le MLD (modèle logique de données) sert précisément à formaliser ces choix avant d’écrire la moindre ligne de SQL.
Association avec cardinalité 1,N
Quand une entité A est liée à une entité B par une association de type 1,N (un client passe plusieurs commandes, mais chaque commande appartient à un seul client), la clé primaire du côté « 1 » migre comme clé étrangère dans la table du côté « N ». Pas besoin de table intermédiaire. La table commandes reçoit une colonne id_client référençant la table clients.
Association avec cardinalité N,M
Une association de type N,M (plusieurs étudiants suivent plusieurs cours) ne peut pas se résoudre par une simple clé étrangère. On crée une table d’association (parfois appelée table de jonction) dont la clé primaire est composée des clés primaires des deux entités liées.
Le point que beaucoup négligent : si l’association porte elle-même des attributs dans le MCD (par exemple une note pour un étudiant dans un cours donné), ces attributs deviennent des colonnes de la table d’association. Les oublier, c’est perdre de l’information.
- Vérifier que chaque attribut porté par une association N,M figure bien comme colonne dans la table de jonction
- Définir la clé primaire composite sur les deux clés étrangères (sauf cas particulier nécessitant un identifiant technique supplémentaire)
- Ajouter les contraintes de clé étrangère avec
ON DELETEetON UPDATEpour refléter les règles métier du MCD
Association avec cardinalité 1,1
Les associations 1,1 sont plus rares et leur traduction varie. On peut fusionner les deux entités en une seule table ou placer la clé étrangère dans l’une des deux tables. Le choix dépend du contexte métier. Si les deux entités ont des cycles de vie différents (un employé et son badge d’accès, par exemple), garder deux tables reste préférable.
Héritage et spécialisation : traduire les sous-types en SQL
Le MCD permet de modéliser l’héritage entre entités (une entité « personne » avec des sous-types « salarié » et « prestataire »). Le SQL relationnel standard ne gère pas l’héritage nativement, ce qui oblige à choisir parmi trois stratégies.
Une table unique avec un attribut discriminant regroupe toutes les colonnes de tous les sous-types dans une même table. Simple à interroger, mais les colonnes spécifiques à un sous-type restent vides pour les lignes des autres sous-types. On gagne en simplicité de requêtes, on perd en rigueur de structure.
La deuxième approche crée une table par sous-type, chacune contenant ses propres attributs plus une clé étrangère vers la table mère. Les données communes restent dans la table mère, les données spécifiques dans les tables filles. C’est la traduction la plus fidèle au MCD.
La troisième option supprime la table mère et duplique les attributs communs dans chaque table fille. Performant pour les lectures ciblées, mais toute modification d’un attribut commun doit se répercuter dans toutes les tables. Les retours varient sur ce point selon la taille du projet et la fréquence des mises à jour.
Vérification finale du script SQL : checklist avant exécution
Avant de lancer le script CREATE TABLE, une relecture systématique évite les pertes silencieuses. Comparer le nombre de tables SQL au nombre d’entités du MCD ne suffit pas, puisque les attributs multivalués et les associations N,M génèrent des tables supplémentaires.
- Compter les colonnes de chaque table et les confronter aux attributs du MCD/MLD correspondant
- Vérifier que chaque clé primaire du MLD est bien déclarée comme
PRIMARY KEY - S’assurer que chaque clé étrangère référence la bonne table et la bonne colonne
- Contrôler que les contraintes d’unicité (par exemple un numéro de sécurité sociale unique par personne) sont bien présentes
- Tester l’insertion d’un jeu de données minimal pour détecter les rejets inattendus ou les colonnes manquantes
Un script SQL qui s’exécute sans erreur ne signifie pas qu’il est fidèle au modèle. Seule une insertion réelle de données de test révèle les écarts entre ce que le MCD décrivait et ce que la base accepte. Prendre le temps de cette vérification, c’est s’épargner des migrations correctives coûteuses une fois la base en production.
