Le MCD (modèle conceptuel de données) décrit les entités et les associations d’un système d’information sans se soucier de la technologie de stockage. Le MLD (modèle logique de données) traduit ce schéma conceptuel en tables, clés primaires et clés étrangères exploitables par un SGBDR. Maîtriser le passage de l’un à l’autre constitue le noyau dur des évaluations en bases de données, que ce soit en BTS SIO, en licence informatique ou dans les modules du CNAM.
Cardinalités et associations : la mécanique qui fait perdre des points au MCD
La plupart des erreurs en examen ne viennent pas d’un oubli d’entité, mais d’une mauvaise lecture des cardinalités. Avant de dessiner quoi que ce soit, il faut comprendre ce que signifient les couples (0,1), (1,1), (0,n) et (1,n) placés de chaque côté d’une association.
Prenons un énoncé classique : « Un fournisseur peut proposer plusieurs produits, et un produit peut être proposé par plusieurs fournisseurs. » L’association PROPOSER relie les entités FOURNISSEUR et PRODUIT avec des cardinalités (1,n) de chaque côté. Ce type d’association de type n:n génère, au passage vers le MLD, une table intermédiaire.
Si l’énoncé précise qu’un produit n’est fourni que par un seul fournisseur, la cardinalité côté PRODUIT devient (1,1). Cette simple différence change radicalement le MLD : la clé étrangère migre directement dans la table PRODUIT, et aucune table intermédiaire n’est créée.
Piège fréquent : confondre cardinalité minimale et maximale
Un étudiant qui lit « un client peut ne pas avoir de commande » doit poser une cardinalité minimale à 0 côté CLIENT (0,n). Écrire (1,n) reviendrait à imposer qu’un client ait au moins une commande, ce qui contredit l’énoncé. Ce détail, souvent survolé, fait basculer une copie de la moyenne à un point en dessous.
Règles de passage du MCD au MLD : trois cas à connaître par coeur
Le passage du modèle conceptuel au modèle logique suit des règles mécaniques. Les examinateurs vérifient que ces règles sont appliquées sans improvisation.
- Association 1:n – la clé primaire de l’entité côté « 1 » migre comme clé étrangère dans la table côté « n ». Exemple : si un service emploie plusieurs salariés, la table SALARIE reçoit une colonne #id_service.
- Association n:n – une table associative est créée. Elle contient les clés primaires des deux entités (qui forment ensemble sa clé primaire composée) et les éventuels attributs portés par l’association. Exemple : la table PROPOSER(#id_fournisseur, #id_produit, prix_unitaire).
- Association 1:1 – la clé primaire d’une des deux entités migre comme clé étrangère dans l’autre table. Le choix de la table réceptrice dépend de la cardinalité minimale : on place la clé étrangère du côté (1,1) plutôt que du côté (0,1), pour éviter les valeurs NULL.
Ces trois cas couvrent la quasi-totalité des exercices d’examen. Toute hésitation sur le sens de migration d’une clé étrangère se résout en relisant la cardinalité maximale.
Exercice commenté : modéliser la gestion de contrats fournisseurs
Voici un énoncé type, inspiré des TD universitaires sur les appels d’offres. Un service achats gère des contrats avec des fournisseurs. Chaque contrat concerne un seul fournisseur, mais un fournisseur peut avoir plusieurs contrats. Un contrat porte sur un ou plusieurs produits, et un produit peut figurer dans plusieurs contrats.
Construction du MCD
Trois entités se dégagent : FOURNISSEUR (id_fournisseur, raison_sociale, adresse), CONTRAT (id_contrat, date_signature, montant_total), PRODUIT (id_produit, designation, reference).
L’association SIGNER relie FOURNISSEUR et CONTRAT. Un fournisseur signe plusieurs contrats (1,n), un contrat est signé par un seul fournisseur (1,1). L’association CONCERNER relie CONTRAT et PRODUIT avec des cardinalités (1,n) de chaque côté, ce qui en fait une association n:n. L’attribut « quantité » est porté par cette association.
Traduction en MLD
En appliquant les règles de passage :
FOURNISSEUR(id_fournisseur, raison_sociale, adresse)
CONTRAT(id_contrat, date_signature, montant_total, #id_fournisseur)
PRODUIT(id_produit, designation, reference)
CONCERNER(#id_contrat, #id_produit, quantite)
La table CONCERNER matérialise l’association n:n. Sa clé primaire composée empêche un même produit d’apparaître deux fois dans le même contrat. La colonne #id_fournisseur dans CONTRAT traduit l’association 1:n, conformément à la règle de migration vers le côté « n ».
Du MLD au MPD : ce que les examens demandent en plus
Certains sujets ajoutent une étape supplémentaire : le modèle physique de données (MPD). Le MPD précise les types de données (VARCHAR, INTEGER, DATE), les contraintes d’intégrité (NOT NULL, UNIQUE, CHECK) et les index.
La différence entre MLD et MPD tient en une phrase : le MLD décrit la structure, le MPD décrit l’implémentation. En examen, cela se traduit par la rédaction des instructions CREATE TABLE en SQL.
Pour l’exercice précédent, la table CONCERNER donnerait :
CREATE TABLE CONCERNER (id_contrat INT, id_produit INT, quantite INT NOT NULL, PRIMARY KEY (id_contrat, id_produit), FOREIGN KEY (id_contrat) REFERENCES CONTRAT(id_contrat), FOREIGN KEY (id_produit) REFERENCES PRODUIT(id_produit));
Les examinateurs vérifient trois points : la déclaration correcte de la clé primaire composée, les contraintes de clé étrangère avec REFERENCES, et la cohérence des types de données avec le domaine métier (une quantité est un entier, pas un VARCHAR).
Merise, entité-association ou UML : adapter sa notation à l’énoncé
Les exercices corrigés disponibles en ligne utilisent majoritairement le formalisme Merise. Les formations récentes intègrent aussi la notation entité-association (Chen) et les diagrammes de classes UML. Le fond reste identique : identifier des entités, définir des attributs, qualifier des associations par leurs cardinalités, puis traduire le tout en tables relationnelles.
La différence porte sur la notation graphique. Merise utilise des rectangles pour les entités et des ovales ou losanges pour les associations. UML utilise des classes avec des multiplicités notées différemment (1..*, 0..1). Lire l’énoncé pour identifier le formalisme attendu évite de perdre des points sur la forme alors que le raisonnement est correct.
Des outils comme Looping permettent de dessiner un MCD en formalisme Merise et de générer automatiquement le MLD puis le script SQL. Pour réviser, construire le modèle à la main puis comparer avec la sortie de l’outil reste la méthode la plus fiable pour repérer ses erreurs de cardinalité ou de migration de clé.
Le dernier réflexe à adopter avant de rendre une copie : relire chaque clé étrangère du MLD et vérifier qu’elle correspond à une cardinalité maximale « n » dans le MCD. Si une clé étrangère ne trouve pas sa justification dans le schéma conceptuel, il y a une incohérence quelque part.
