Un modèle conceptuel de données (MCD) décrit les informations d’un système et leurs liens, sans se préoccuper de la technologie qui les stockera. Le modèle logique de données (MLD) traduit ce schéma abstrait en une structure compatible avec un système de gestion de base de données. Ces deux étapes, issues de la méthode Merise, restent le point de départ de la conception de bases de données dans la plupart des cursus francophones.
Entités, attributs et associations : le vocabulaire du MCD
Le MCD repose sur trois briques. Une entité représente un objet du monde réel que le système doit mémoriser : un client, un produit, une commande. Chaque entité porte des attributs, c’est-à-dire les propriétés qu’on veut stocker (nom, prénom, référence, date).
Une association relie deux entités ou plus. Elle décrit un événement ou un lien : « un client passe une commande », « un étudiant s’inscrit à un cours ». L’association peut elle-même porter des attributs (la date de commande, la note obtenue).
Chaque association est qualifiée par des cardinalités. Elles indiquent combien de fois une occurrence d’entité peut participer à l’association. Les notations courantes sont 0,1 – 1,1 – 0,n – 1,n. Lire une cardinalité revient à poser la question : « pour une occurrence de cette entité, combien d’occurrences de l’autre entité sont possibles au minimum et au maximum ? »
- 0,n signifie qu’une occurrence peut ne participer à aucune relation, ou à un nombre illimité.
- 1,1 signifie qu’une occurrence participe exactement une fois, obligatoirement.
- 1,n signifie au moins une participation, sans limite haute.
Comprendre les cardinalités évite la majorité des erreurs de modélisation. Un mauvais choix ici se répercute sur toutes les étapes suivantes.
Du MCD au MLD : les règles de transformation
Le passage du MCD au MLD suit des règles mécaniques. Ce n’est pas une étape créative, c’est une traduction. Le MLD produit un schéma relationnel composé de tables, de colonnes et de clés.
Entités vers tables
Chaque entité devient une table. Ses attributs deviennent des colonnes. L’identifiant de l’entité devient la clé primaire de la table, c’est-à-dire la colonne (ou le groupe de colonnes) qui identifie de façon unique chaque ligne.
Associations et cardinalités
Le traitement d’une association dépend de ses cardinalités. Pour une association de type 1,n (un client passe plusieurs commandes), on ajoute la clé primaire de l’entité côté « 1 » comme clé étrangère dans la table côté « n ». La table Commande reçoit alors une colonne id_client.
Pour une association de type n,n (un étudiant s’inscrit à plusieurs cours, un cours accueille plusieurs étudiants), on crée une table intermédiaire. Cette table porte les clés primaires des deux entités en clés étrangères, et éventuellement les attributs propres à l’association (la note, la date d’inscription). La clé primaire de cette table intermédiaire est souvent la combinaison des deux clés étrangères.
Pour une association de type 1,1, la clé étrangère migre dans l’une des deux tables. Le choix se fait selon la logique métier.
MCD et MLD comme socle avant SQL et NoSQL
Plusieurs cursus français positionnent désormais le couple MCD/MLD comme une première étape obligatoire avant d’aborder la comparaison entre bases relationnelles et bases NoSQL. Le module « Bases de données et systèmes d’information » du Cnam illustre cette approche : le programme commence par le modèle entité-association et la normalisation, puis consacre un second volet aux bases non relationnelles et aux architectures distribuées.
Cette évolution pédagogique change la façon d’apprendre le MCD. Il ne s’agit plus de maîtriser un formalisme figé, mais de comprendre pourquoi on structure des données avant de choisir un moteur de stockage. Un MCD bien construit permet d’évaluer si un schéma relationnel classique convient, ou si une base orientée documents ou graphes serait plus adaptée au besoin.
Pour un étudiant, cela signifie que le temps passé sur le MCD n’est pas du temps « perdu » sur une méthode ancienne. C’est un investissement qui s’applique ensuite quel que soit le type de base de données visé.
Erreurs fréquentes dans la modélisation entité-association
La première erreur consiste à confondre entité et attribut. Un code postal est un attribut de l’entité Client, pas une entité à part, sauf si le système doit stocker des informations propres aux codes postaux (ville associée, zone de livraison). La règle : si un élément n’a qu’un seul attribut et n’est relié à rien d’autre, il reste un attribut.
La deuxième erreur porte sur les cardinalités. Déclarer une relation 0,n des deux côtés alors qu’un côté est en réalité 1,n produit un MLD trop permissif. La base autorisera alors des lignes orphelines, des commandes sans client par exemple.
La troisième erreur est de sauter le MCD pour dessiner directement des tables. Le résultat fonctionne souvent pour un petit projet, mais toute évolution du schéma devient coûteuse parce qu’on n’a pas documenté les règles métier. Le MCD sert précisément à formaliser ces règles avant de les figer dans une structure technique.
Outils de modélisation MCD et MLD pour étudiants
Plusieurs outils gratuits permettent de dessiner un MCD et de générer automatiquement le MLD associé. Le choix dépend surtout du contexte d’apprentissage.
- Looping est un logiciel léger, très répandu dans les formations françaises. Il gère nativement le formalisme Merise et génère le script SQL à partir du MLD.
- Draw.io (désormais diagrams.net) est un outil en ligne généraliste. Il ne vérifie pas les cardinalités, mais il suffit pour produire des schémas propres à rendre en exercice.
- MySQL Workbench part du MLD plutôt que du MCD, ce qui le rend plus adapté à la phase de conception physique qu’à la modélisation conceptuelle.
- JMerise est une alternative open source pensée pour Merise, avec génération du MLD et du script SQL.
L’outil importe moins que la méthode. Un MCD dessiné sur papier avec des cardinalités justes vaut mieux qu’un schéma logiciel truffé d’erreurs de conception.
Le MCD et le MLD restent des compétences évaluées dans la majorité des examens de bases de données en France. Leur maîtrise conditionne la capacité à concevoir un schéma qui tient dans le temps, qu’il s’agisse ensuite de SQL ou d’un autre paradigme de stockage.
