La méthode Merise expliquée : MCD, MLD, MPD et cardinalités

Avant d’écrire la moindre requête SQL, il faut concevoir sa base de données : quelles tables, quelles colonnes, quels liens ? En France, la méthode de référence pour cette étape s’appelle Merise. Née dans les années 1970-80, elle reste largement enseignée et utilisée pour modéliser un système d’information de façon rigoureuse. Ce guide en présente les principes et les modèles clés, sans jargon inutile.

Qu’est-ce que Merise ?

Merise est une méthode d’analyse et de conception des systèmes d’information. Son idée centrale : séparer clairement les données (ce qu’on stocke) et les traitements (ce qu’on en fait), et progresser par niveaux d’abstraction — du plus conceptuel (le « quoi ») au plus technique (le « comment »). Pour la conception d’une base de données, on retient surtout la partie « données », structurée en trois modèles successifs : conceptuel, logique, puis physique.

Le MCD : modèle conceptuel de données

Le MCD est le cœur de Merise. Il décrit les données de façon abstraite, indépendamment de toute technologie, à travers deux notions :

• Les entités : les « objets » du monde réel qu’on veut représenter (un Client, un Produit, une Commande). Chaque entité possède des propriétés (le client a un nom, une adresse…) et un identifiant qui la distingue.
• Les associations : les liens entre entités (un Client passe une Commande). Une association peut elle aussi porter des propriétés.

On représente tout cela par un schéma : des rectangles pour les entités, des ovales ou losanges pour les associations qui les relient. C’est une vue métier, compréhensible même par un non-informaticien.

Les cardinalités

Élément essentiel du MCD, les cardinalités précisent « combien de fois » une entité participe à une association. Elles s’écrivent sous la forme minimum, maximum à chaque extrémité du lien :

Par exemple, entre Client et Commande : un client peut passer de 0 à n commandes (0,n), mais une commande appartient à exactement un client (1,1). Ces cardinalités déterminent la nature de la relation — c’est ce qui, plus tard, dictera la structure des tables.

Le MLD : modèle logique de données

Le MLD traduit le MCD en structure de tables, en appliquant des règles de passage systématiques. Les principales :

• Chaque entité devient une table, ses propriétés deviennent des colonnes, son identifiant devient la clé primaire.
• Une association de type « un à plusieurs » (comme Client–Commande) se traduit en ajoutant une clé étrangère : la table Commande reçoit l’identifiant du client.
• Une association « plusieurs à plusieurs » (par exemple Commande–Produit) devient une table à part entière, qui contient les clés des deux entités reliées.

À ce stade, on obtient un schéma relationnel : des tables, des colonnes, des clés primaires et étrangères — la charpente exacte de la future base.

Le MPD : modèle physique de données

Le MPD est la dernière étape : la traduction du MLD dans un SGBD précis (Oracle, MySQL, PostgreSQL…). On y ajoute les détails techniques : les types de données exacts de chaque colonne, les index, les contraintes, et finalement le code CREATE TABLE qui crée réellement la base. C’est le point de jonction entre la conception Merise et le SQL.

Merise en pratique aujourd’hui

Merise a été conçue avant l’ère des méthodes agiles, et sa version complète (avec toute la partie traitements) peut sembler lourde pour de petits projets. Mais sa partie « données » — MCD, cardinalités, passage au relationnel — reste d’une grande utilité, et c’est un socle enseigné dans toutes les formations françaises en informatique. Dans le monde anglo-saxon, on utilise plutôt le formalisme entité-association (E-A) ou UML, très proches dans l’esprit : les concepts d’entité, de relation et de cardinalité s’y retrouvent.

En résumé

Merise structure la conception d’une base en trois modèles : le MCD décrit les données de façon abstraite (entités, associations, cardinalités), le MLD les traduit en tables et clés, et le MPD les implémente dans un SGBD concret. Cette progression du conceptuel au physique évite de se lancer tête baissée dans la création de tables et garantit une base cohérente et bien pensée. Une fois le modèle établi, place à la mise en œuvre : les contraintes d’intégrité et les requêtes SQL.