MCD, MLD, MPD : trois questions différentes
Le modèle conceptuel des données, ou MCD, décrit les entités, leurs propriétés et leurs associations avec des cardinalités. Il répond à une question de métier : quelles informations sont liées, et selon quelles règles ? Il ne dépend pas encore d’un moteur particulier.
Le modèle logique des données, ou MLD, organise ces informations selon le modèle retenu, ici relationnel : relations, clés primaires et clés étrangères. Le modèle physique des données, ou MPD, précise ensuite l’implantation dans un système comme MariaDB, avec les types et contraintes adaptés.
Poser les règles avant de tracer le schéma
Pour cet exemple original, chaque livre appartient à une seule catégorie. Une catégorie peut exister même si aucun livre ne lui est encore rattaché. Ces deux phrases sont des choix de modélisation ; dans une autre bibliothèque, un livre pourrait avoir plusieurs catégories et le modèle changerait.
Nous retenons deux entités : LIVRE, identifié par id_livre, et CATEGORIE, identifiée par id_categorie. L’association « appartient à » reçoit une cardinalité (1,1) côté LIVRE : chaque livre participe exactement une fois. Côté CATEGORIE, la cardinalité (0,n) permet zéro ou plusieurs livres.
Une cardinalité se lit pour une occurrence de l’entité à côté de laquelle elle est placée. Relis toujours ta phrase métier : « pour un livre, combien de catégories ? ». Cette habitude évite d’inverser les deux côtés parce qu’un dessin semble plus naturel.
Le MLD de notre exemple
Dans ce cas un-à-plusieurs, l’identifiant de la catégorie devient une clé étrangère dans LIVRE. C’est la ligne d’un livre qui doit permettre de retrouver son unique catégorie. Ajouter plutôt une unique colonne id_livre à CATEGORIE ne représenterait pas tous les livres d’une catégorie.
CATEGORIE(id_categorie, libelle)
clé primaire : id_categorie
LIVRE(id_livre, titre, id_categorie)
clé primaire : id_livre
clé étrangère : id_categorie → CATEGORIE.id_categorie
catégorie obligatoire pour chaque livreTester le modèle avec quelques cas
Imagine une catégorie sans livre : le modèle doit la permettre. Imagine deux livres dans la même catégorie : chacun porte le même id_categorie, sans répéter le libellé dans chaque ligne. Enfin, imagine un livre sans catégorie : notre règle l’interdit, et l’implantation physique devra respecter cette obligation.
Si un livre peut désormais avoir plusieurs catégories, les cardinalités deviennent plusieurs-à-plusieurs. Il faut une relation de liaison entre livres et catégories, plutôt que plusieurs colonnes categorie1, categorie2 et categorie3. Le changement vient du besoin, pas d’une préférence pour un schéma plus compliqué.
Pour continuer, écris trois règles métier sur un autre domaine et vérifie des cas permis et interdits avant de passer au SQL. Tu apprendras ainsi à défendre ton modèle, pas seulement à recopier un dessin. Les cas particuliers, associations porteuses de propriétés et contraintes supplémentaires demandent un travail plus approfondi.