Un MCD décrit les données et leurs liens sans imposer de structure technique ; le MLD organise ensuite ces informations en tables, clés et relations. En comprenant cette différence MCD et MLD, puis en appliquant quelques règles de transformation, vous pourrez construire des bases cohérentes et vous entraîner avec des exercices corrigés pour débutants.
L’article en bref
Le MCD aide à comprendre le besoin métier ; le MLD prépare son organisation dans une base relationnelle. Des règles simples et des exemples guidés rendent le passage de l’un à l’autre plus concret.
- Deux modèles complémentaires : distinguer la description métier de l’organisation en tables relationnelles.
- Les notions essentielles : repérer entités, associations, attributs, identifiants et cardinalités.
- Le passage au MLD : appliquer les règles de transformation selon les cardinalités observées.
- La pratique guidée : vérifier les acquis avec des exercices corrigés et des schémas relationnels.
La méthode devient plus claire dès que chaque règle est reliée à un besoin concret.
MCD et MLD : deux étapes de la modélisation de données
Imaginez une agence immobilière qui veut suivre ses propriétaires, ses logements et ses locations. Avant de choisir un logiciel ou de créer des tables, elle doit clarifier les informations à gérer et les liens entre elles : c’est le rôle du modèle conceptuel de données, ou MCD.
Le modèle logique de données, ou MLD, reprend cette description et l’organise sous forme relationnelle. Il précise les tables, leurs colonnes, les clés primaires et les clés étrangères qui permettront de relier les enregistrements.
| Point de comparaison | MCD | MLD |
|---|---|---|
| Question principale | Quelles données et quels liens représentent le besoin ? | Comment organiser ces données en relations ? |
| Éléments courants | Entités, attributs, associations, cardinalités | Tables, colonnes, clés primaires et étrangères |
| Niveau de description | Conceptuel, proche du métier | Logique, proche de la structure relationnelle |
| Exemple immobilier | Un propriétaire confie des biens à une agence | PROPRIETAIRE, BIEN, LOCATAIRE, BAIL |
La différence MCD et MLD en un exemple
Dans le MCD d’une agence, PROPRIÉTAIRE et BIEN sont des entités reliées par une association telle que « confier en gestion ». Le schéma exprime ainsi une règle métier : un propriétaire peut confier plusieurs biens.
Dans le MLD, cette règle se traduit par des relations et des clés. La table BIEN peut contenir l’identifiant du propriétaire comme clé étrangère ; chaque ligne de bien indique alors à quel propriétaire elle est rattachée. Le MCD explique le besoin, le MLD prépare sa mise en œuvre.
Entité-association, identifiants et relation et cardinalité
Un MCD s’appuie notamment sur le modèle entité-association. Une entité représente un objet à décrire, comme un client, un photocopieur ou un contrat ; ses attributs en précisent les caractéristiques, et son identifiant permet de distinguer chaque occurrence.
Une association exprime un lien entre des entités. La relation et cardinalité indiquent combien d’occurrences peuvent ou doivent participer à ce lien : par exemple, un client peut louer plusieurs photocopieurs, tandis qu’un photocopieur donné est rattaché à une seule location dans le scénario étudié.
- Entité : un élément métier suivi séparément, comme CLIENT.
- Attribut : une propriété, comme nom ou adresse.
- Identifiant : une valeur unique, par exemple id_client.
- Association : un lien porteur de sens, comme LOUER.
- Cardinalité : le minimum et le maximum de participations au lien.
Lire les cardinalités sans inverser les rôles
Dans le cas d’une société de location, la cardinalité Client (1,n) auprès de LOUER signifie qu’un client est associé à une ou plusieurs locations. La cardinalité Photocopieur (1,1) signifie que chaque photocopieur participe exactement une fois à cette association dans le modèle considéré.
Ces valeurs décrivent une règle métier, pas une convention technique. Si un photocopieur peut être loué successivement à plusieurs clients au fil du temps, il faut modéliser les locations comme des occurrences distinctes, généralement avec leurs dates, plutôt que d’imposer une seule association permanente entre client et appareil.
Transformation MCD en MLD : les règles de passage
La transformation MCD en MLD suit des règles régulières. Il est utile de commencer par les entités, puis de traiter les associations en fonction de leurs cardinalités ; cette démarche limite les oublis de clés et les duplications inutiles.
- Chaque entité devient une table. Ses attributs deviennent des colonnes et son identifiant devient la clé primaire.
- Pour une association de type un-à-plusieurs, la clé primaire du côté « un » migre généralement comme clé étrangère dans la table du côté « plusieurs ».
- Pour une association plusieurs-à-plusieurs, créer une table intermédiaire contenant les clés des entités liées. Ces clés forment souvent une clé primaire composée.
- Ajouter les attributs de l’association à la table qui la représente. Une date de location, par exemple, appartient à la relation de location si elle décrit cet événement.
- Vérifier les contraintes : unicité, valeurs obligatoires et règles métier qui ne se déduisent pas des seules clés.
La notation utilisée ci-dessous place la clé primaire entre crochets et précède les clés étrangères de la mention FK. La présentation peut varier selon les cours, mais le principe reste identique.
Quand une association devient-elle une table ?
Une association plusieurs-à-plusieurs nécessite une table intermédiaire afin de représenter toutes les combinaisons possibles. Si un étudiant peut suivre plusieurs cours et qu’un cours accueille plusieurs étudiants, la table INSCRIPTION relie les deux et peut aussi porter la date d’inscription.
À l’inverse, dans un lien un-à-plusieurs simple, la clé étrangère est généralement placée du côté qui peut être associé à plusieurs occurrences. Une association dotée de propriétés propres ou soumise à des règles particulières peut toutefois justifier une table dédiée : le modèle doit traduire le fonctionnement réel.
Exercice corrigé pour débutants : location de photocopieurs
Une entreprise loue des photocopieurs à ses clients et associe chaque location à un contrat de maintenance. Pour un exercice simplifié, on suppose qu’un client possède au moins un appareil loué et que chaque photocopieur est rattaché à un seul client à un instant donné.
Le MCD comprend les entités CLIENT et PHOTOCOPIEUR reliées par l’association LOUER. Si la location et sa maintenance ne sont pas historisées séparément, le schéma relationnel minimal peut s’écrire ainsi :
CLIENT ([id_client], nom, adresse, téléphone)
PHOTOCOPIEUR ([id_photocopieur], modèle, date_mise_en_service, id_client FK, numéro_contrat, date_debut_maintenance)
La clé id_client dans PHOTOCOPIEUR matérialise le lien vers CLIENT. Pour conserver plusieurs contrats successifs ou suivre les interventions, il est préférable de créer des tables CONTRAT et INTERVENTION plutôt que d’entasser ces informations dans la table de l’appareil.
Exercices corrigés pour débutants : agence immobilière et hôpital
Exercice 1 : propriétaires, biens et baux
Une agence gère des appartements ou maisons pour des propriétaires. Chaque bien possède une adresse et un prix de location ; les conditions de gestion, comme la durée et le pourcentage, concernent le contrat conclu pour ce bien. Un bien peut être loué à différents locataires au fil du temps, chaque location étant décrite par un bail.
Un schéma relationnel cohérent pour ce périmètre est le suivant :
PROPRIETAIRE ([id_proprietaire], nom, prénom, adresse, téléphone)
BIEN ([id_bien], adresse, type_bien, surface, prix_location, id_proprietaire FK)
CONTRAT_GESTION ([id_contrat_gestion], id_bien FK, durée, pourcentage)
LOCATAIRE ([id_locataire], nom, prénom, adresse, téléphone)
BAIL ([num_bail], id_bien FK, id_locataire FK, date_debut, date_fin)
Cette proposition suppose qu’un bien dépend d’un seul propriétaire et qu’un contrat de gestion est conservé séparément pour chaque bien. Si plusieurs propriétaires peuvent détenir un même bien, il faudra ajouter une table de liaison, par exemple DETENTION, avec les clés des deux tables concernées.
Exercice 2 : séjours hospitaliers et interventions
Un patient peut effectuer plusieurs séjours ; chaque séjour concerne une chambre et peut comporter plusieurs interventions. Chaque intervention est dirigée par un médecin. En choisissant un identifiant distinct pour chaque séjour et chaque intervention, les associations deviennent lisibles dans le MLD.
PATIENT ([id_patient], nom, prénom, adresse, caisse_assurance)
CHAMBRE ([num_chambre], étage, service)
MEDECIN ([id_medecin], nom, prénom, spécialité)
SEJOUR ([num_sejour], date_arrivée, date_départ, id_patient FK, num_chambre FK)
INTERVENTION ([code_intervention], date_intervention, nom, num_sejour FK, id_medecin FK)
La clé étrangère id_patient dans SEJOUR traduit le fait qu’un patient peut avoir plusieurs séjours. Les clés num_sejour et id_medecin dans INTERVENTION relient chaque intervention au séjour concerné et au médecin responsable.
Vérifier son MLD et organiser les travaux pratiques
Un schéma plausible ne suffit pas : il doit aussi permettre de répondre aux questions attendues. Pour une chaîne de cinémas, par exemple, des tables SEANCE et SALLE permettent de compter les spectateurs par film ou d’estimer le remplissage, tandis qu’une table de liaison entre FILM et ACTEUR représente leur association plusieurs-à-plusieurs.
- Chaque table possède-t-elle une clé primaire stable et unique ?
- Chaque clé étrangère correspond-elle à une association du MCD ?
- Les associations plusieurs-à-plusieurs sont-elles représentées par une table de liaison ?
- Les attributs sont-ils placés dans la table qui décrit réellement l’information ?
- Les requêtes demandées peuvent-elles être formulées à partir des relations prévues ?
Pour s’entraîner progressivement, commencez par des situations courtes comme une location ou une gestion de patients, puis augmentez le nombre d’associations. Des travaux pratiques organisés en plusieurs sujets peuvent aider à appliquer la transformation MCD en MLD et à vérifier les formes normales, qui servent notamment à limiter les redondances.
Si les exercices sont remis via GitHub Classroom, le parcours habituel consiste à associer son compte à la classe, accepter le devoir, récupérer le dépôt privé créé pour l’exercice, y ajouter schéma et explications, puis envoyer les modifications. Le dépôt permet à l’enseignant de consulter le travail ; les consignes précises de remise restent celles de la classe.
Questions fréquentes sur le MCD et le MLD
Quelle est la différence essentielle entre MCD et MLD ?
Le MCD décrit les données métier, leurs attributs et leurs associations. Le MLD traduit cette description en tables relationnelles, avec clés primaires et clés étrangères.
Une association du MCD devient-elle toujours une table ?
Non. Une association plusieurs-à-plusieurs devient généralement une table intermédiaire. Dans un lien un-à-plusieurs, une clé étrangère suffit souvent, sauf si l’association possède des attributs ou des contraintes qui justifient une table dédiée.
À quoi servent les cardinalités dans un MCD ?
Elles indiquent le nombre minimal et maximal de participations d’une entité à une association. Elles permettent de comprendre les règles métier et orientent la transformation du MCD en MLD.
Dans quel ordre faut-il construire le MLD ?
Créez d’abord une table par entité, puis placez les clés étrangères selon les cardinalités. Terminez par les tables de liaison nécessaires et vérifiez que le schéma permet de répondre aux besoins exprimés.
Je suis Julien Marceau, rédacteur spécialisé en communication et marketing B2B. J’aide les dirigeants, indépendants et responsables com à y voir clair : de l’objet publicitaire à la campagne digitale, je décortique les méthodes qui marchent, sans jargon ni promesses en l’air. Mon truc : des guides concrets qu’on peut appliquer dès le lendemain.
