Du MCD au MLD : les règles de passage au modèle logique
Vous avez construit un modèle conceptuel de données et l'examen vous demande le schéma relationnel ? Le passage du MCD au MLD obéit à des règles de transformation précises, toujours les mêmes, qu'il suffit d'appliquer méthodiquement. C'est l'une des compétences les plus rentables de l'UE 8 du DCG : voici les règles de base, les cas particuliers et un cas type corrigé.
Du conceptuel au logique : pourquoi deux modèles ?
Le MCD (modèle conceptuel de données), construit avec la méthode Merise, décrit la réalité de gestion indépendamment de toute considération technique : des entités (CLIENT, PRODUIT, COMMANDE), des associations nommées par des verbes (un client PASSE une commande) et des cardinalités (min, max).
Le MLD (modèle logique de données) traduit ce schéma en un format exploitable par un SGBD : chaque entité devient une table, chaque attribut devient une colonne, et l'identifiant de l'entité devient la clé primaire, soulignée dans la notation en intension. Restent les associations : c'est là qu'interviennent les règles de passage.
Les deux règles fondamentales
Règle 1 - Association hiérarchique (1,n) : la clé primaire du côté « 1 » migre comme clé étrangère du côté « n ». Exemple : une commande est passée par un seul client, un client passe plusieurs commandes. NumeroClient (clé primaire de CLIENT) migre dans la table COMMANDE comme clé étrangère, notée #NumeroClient. Retenez le sens : la table qui « connaît » son unique partenaire reçoit la clé étrangère.
Règle 2 - Association non hiérarchique (n,n) : on crée une table intermédiaire (table d'association) dont la clé primaire est la concaténation des clés primaires des deux entités. Exemple : un auteur écrit plusieurs livres et un livre peut avoir plusieurs auteurs ; on crée la table ECRIRE(#NumAuteur, #ISBN). Les attributs portés par l'association (une date, une quantité, une remise) atterrissent dans cette table.
Les cas particuliers à connaître
L'identification relative (entité faible). Certaines entités ne peuvent pas être identifiées de manière autonome : leur identifiant n'a de sens qu'en complément de celui d'une entité forte. Le cas classique : la chambre d'hôtel. La chambre 101 existe dans plusieurs hôtels ; CHAMBRE est donc identifiée relativement à HOTEL, via une association identifiante repérée par la cardinalité (1,1) entre parenthèses. Dans le MLD, la clé primaire devient composite : CHAMBRE(NumHotel, NumChambre, Superficie, Prix), où NumHotel est à la fois partie de la clé primaire et clé étrangère vers HOTEL.
L'association réflexive. Elle relie une entité à elle-même : un employé est dirigé par au plus un autre employé (0,1) et peut en diriger plusieurs (0,n). Dans le MLD, cela donne une auto-référence : EMPLOYE(NumEmploye, Nom, Prenom, Poste, #NumDirecteur), où #NumDirecteur référence la clé primaire de la même table.
L'héritage (spécialisation/généralisation). Quand une entité mère se décompose en sous-entités spécialisées, trois stratégies existent : une table par sous-type avec clé étrangère vers la table mère (la plus courante), une seule table avec un attribut discriminant « Type » (simple mais colonnes vides), ou une table par classe concrète (attributs communs dupliqués, donc redondance).
L'agrégation (pseudo-entité). Concept rare mais déjà tombé à l'examen : quand une association doit elle-même participer à une autre association, on la promeut au rang de pseudo-entité pour pouvoir la relier à d'autres entités.
Un exemple concret : l'agence de voyages VacancesPlus
L'agence VacancesPlus (cas fictif) gère des clients, des destinations et des séjours. Un client peut réserver plusieurs séjours ; un séjour peut être réservé par plusieurs clients : association n,n, avec date, nombre de personnes et taux de remise enregistrés à la réservation. Un séjour concerne une seule destination, mais une destination propose plusieurs séjours : association 1,n.
Application des règles, en notation en intension (clé primaire soulignée, clé étrangère précédée de #) :
- CLIENT(NumClient, Nom, Prenom, Rue, CP, Ville, Email)
- DESTINATION(CodeDest, Libelle)
- SEJOUR(CodeSejour, NbrMaxi, Prix, DateDepart, Duree, #CodeDest)
- RESERVER(#NumClient, #CodeSejour, DateReservation, NbPersonne, TauxRemise)
SEJOUR reçoit #CodeDest (règle 1 : un séjour = une destination). RESERVER est la table d'association de la n,n (règle 2) : sa clé primaire concatène #NumClient et #CodeSejour, et elle héberge les attributs de l'association.
Les erreurs fréquentes
- Placer la clé étrangère du mauvais côté dans une 1,n : la clé migre du côté « n » (la table dont chaque ligne est liée à une seule occurrence de l'autre), jamais du côté « 1 ».
- Oublier la table d'association pour une n,n : sans table intermédiaire, la base ne peut pas stocker les liens multiples. C'est l'erreur éliminatoire la plus courante.
- Égarer les attributs de l'association : DateReservation ou Quantite appartiennent à la table d'association, pas aux entités.
- Confondre identification relative et simple 1,n : dans l'identification relative, la clé étrangère fait partie de la clé primaire (clé composite) ; dans une 1,n classique, elle reste une colonne ordinaire.
FAQ
Comment savoir où placer la clé étrangère dans une association 1,n ?
Posez la question dans les deux sens : « une commande concerne combien de clients ? » (un seul) et « un client passe combien de commandes ? » (plusieurs). La clé étrangère va dans la table côté « n », ici COMMANDE, qui mémorise ainsi son unique client.
Que devient une association porteuse d'attributs ?
Si elle est de type n,n, ses attributs rejoignent la table d'association créée (exemple : TauxRemise dans RESERVER). C'est l'un des points systématiquement vérifiés par les correcteurs.
Que signifient le soulignement et le symbole # dans un schéma relationnel ?
Par convention, la clé primaire est soulignée et les clés étrangères sont précédées du symbole #. Dans une table d'association, la clé primaire est composée d'attributs qui sont aussi des clés étrangères : ils cumulent les deux notations.
Entraînez-vous
Mini-cas. Une association sportive gère ses activités. Chaque adhérent (numéro, nom, prénom, email) peut s'inscrire à plusieurs activités ; pour chaque inscription, on enregistre la date et le mode de paiement. Chaque activité (code, libellé, tarif annuel) est encadrée par un seul moniteur ; un moniteur (numéro, nom, diplôme) peut encadrer plusieurs activités.
- Identifiez les associations et leurs cardinalités.
- Écrivez le MLD complet en notation en intension.
- Justifiez l'emplacement de chaque clé étrangère.
Afficher le corrigé
1. Associations et cardinalités. ADHERENT (0,n) - INSCRIRE - (0,n) ACTIVITE : un adhérent s'inscrit à zéro ou plusieurs activités, une activité accueille zéro ou plusieurs adhérents - association n,n, porteuse des attributs DateInscription et ModePaiement. MONITEUR (1,n) - ENCADRER - (1,1) ACTIVITE : une activité est encadrée par exactement un moniteur, un moniteur encadre une ou plusieurs activités - association hiérarchique 1,n.
2. MLD en intension.
- ADHERENT(NumAdherent, Nom, Prenom, Email)
- MONITEUR(NumMoniteur, Nom, Diplome)
- ACTIVITE(CodeActivite, Libelle, TarifAnnuel, #NumMoniteur)
- INSCRIRE(#NumAdherent, #CodeActivite, DateInscription, ModePaiement)
3. Justification. #NumMoniteur migre dans ACTIVITE car l'association ENCADRER est de type 1,n : chaque activité « connaît » son unique moniteur (règle 1, la clé étrangère va du côté 1,1). INSCRIRE est une table d'association car INSCRIRE est n,n (règle 2) : sa clé primaire est la concaténation de #NumAdherent et #CodeActivite, et elle accueille les attributs portés par l'association (date d'inscription, mode de paiement), qui ne dépendent ni de l'adhérent seul ni de l'activité seule mais du couple.