Merise est une méthode créée en France dans les années 1980, qui sépare le cycle de décision (cycle de vie) en trois niveaux : conceptuel (quoi), logique (comment) et physique (avec quel support). Pour la **donnée**, Merise propose le formalisme du MCD (Modèle Conceptuel de Données), transformé en MLD (Modèle Logique de Données) puis en MPD (Modèle Physique de Données). Cette approche normalisée garantit la traçabilité et la robustesse des bases de données relationnelles. ISOSET enseigne Merise comme un socle incontournable de la conception de SI.

• MCD (Conceptuel) – indépendant de toute technologie, exprime les données métier.
• MLD (Logique) – structure relationnelle avec clés primaires/étrangères.
• MPD (Physique) – spécifique au SGBD (types, index, partitions).

Le MCD représente les données du point de vue métier, sous forme d’entités (noms) et d’associations (verbes). Une **entité** décrit un objet ou un événement (ex: CLIENT, PRODUIT). Une **association** représente une relation entre entités (ex: PASSER_COMMANDE). Les **cardinalités** (minimale et maximale) expriment la participation : (0,1), (1,1), (0,n), (1,n). Le MCD est graphique et sans notion de clé.

# Exemple MCD (notation entité-association)
CLIENT (n°client, nom, adresse)
COMMANDE (n°commande, date, montant)
PASSER (CLIENT : 1,1 --- COMMANDE : 0,n)  // un client passe 0..n commandes
COMPORTER (COMMANDE : 1,1 --- PRODUIT : 1,n)  // une commande contient 1..n produits

Les attributs sont listés sans précision de type. On peut distinguer les identifiants (numéro client, code produit). Les associations binaires, ternaires, les hiérarchies sont également modélisables. ISOSET aide les entreprises à formaliser leurs règles de gestion en MCD.

Le MLD transforme le MCD en un schéma relationnel (tables). Chaque entité devient une table ; chaque association « many‑to‑many » (cardinalité côté * ou n) devient une table d’associations. On y ajoute les clés primaires (PK) et les clés étrangères (FK). C’est le moment de la normalisation (1NF, 2NF, 3NF). Le MLD est indépendant du SGBD mais respecte le modèle relationnel.

# Table CLIENT (PK n°client)
CREATE TABLE CLIENT (
    n_client INT PRIMARY KEY,
    nom VARCHAR(50),
    adresse VARCHAR(100)
);

# Table COMMANDE (PK n°commande, FK n_client)
CREATE TABLE COMMANDE (
    n_commande INT PRIMARY KEY,
    date DATE,
    montant DECIMAL(10,2),
    n_client INT,
    FOREIGN KEY (n_client) REFERENCES CLIENT(n_client)
);

# Table LIGNE_COMMANDE (association) – PK composite
CREATE TABLE LIGNE_COMMANDE (
    n_commande INT,
    code_produit INT,
    quantite INT,
    PRIMARY KEY (n_commande, code_produit),
    FOREIGN KEY (n_commande) REFERENCES COMMANDE(n_commande),
    FOREIGN KEY (code_produit) REFERENCES PRODUIT(code_produit)
);

ISOSET forme à la transformation systématique MCD->MLD, avec des exercices sur des cas concrets (gestion de bibliothèque, comptabilité, RH).

Le MPD concrétise le MLD pour un SGBD spécifique. On ajoute :

• Types de données concrets – VARCHAR(255), INTEGER, TIMESTAMP (diffère selon SGBD).
• Index – B‑tree, hash, full‑text, pour accélérer les requêtes.
• Contraintes – CHECK, DEFAULT, NOT NULL.
• Options physiques – tablespace, partitionnement (range, list), clé de partition.
• Vues matérialisées, synonymes, etc. – optimisation des requêtes fréquentes.

# MPD PostgreSQL (ajout d’index et partition)
CREATE INDEX idx_client_nom ON CLIENT(nom);
CREATE INDEX idx_commande_date ON COMMANDE(date);
ALTER TABLE COMMANDE PARTITION BY RANGE (date);
CREATE TABLE COMMANDE_2025 PARTITION OF COMMANDE
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

Le MPD est également utilisé pour la réorganisation, l’analyse de performance et l’estimation du volume de stockage. ISOSET enseigne à concevoir le MPD selon le SGBD cible (PostgreSQL, MySQL, Oracle).

• Entité seule → une table (attributs ⇒ colonnes, identifiant ⇒ clé primaire).
• Association 1‑N (cardinalités 1,1 et 0,n) – la clé étrangère se place du côté N.
• Association N‑N (cardinalités 0,n des deux côtés) – table d’association contenant les deux clés étrangères (PK composite).
• Association 1‑1 (rare) – on fusionne les deux tables ou on ajoute FK avec contrainte d’unicité.
• Attributs d’association – deviennent colonnes de la table d’association.
• Hiérarchies (héritage) – plusieurs stratégies (table unique, table par classe, table par sous‑classe).

# Exemple de table d’association (N‑N)
Etudiant (PK id_etudiant) ->  <- Cours (PK id_cours)
Table inscription (id_etudiant, id_cours, note, date_inscription)
PK(id_etudiant, id_cours)

• PowerAMC (SAP PowerDesigner) – outil historique, très complet, permet la rétro‑ingénierie et la génération de code SQL.
• Win’Design – outil spécifique à Merise, utilisé encore dans certaines DSI.
• Draw.io (diagrams.net) – avec des librairies Merise (entité‑association).
• PlantUML et Mermaid – format textuel pour versionner les modèles (ER diagram).
• DbSchema, DBeaver – visualisation inverse depuis une base existante.

ISOSET initie les jeunes à la modélisation avec des outils simples (Draw.io) avant d’aborder les solutions professionnelles.

La normalisation est souvent appliquée lors du passage au MLD. Les principes :

• 1NF – tous les attributs sont atomiques (pas de multivalués).
• 2NF – pas de dépendance partielle sur une clé primaire composite.
• 3NF – pas de dépendance transitive (un attribut non‑clé ne doit pas dépendre d’un autre attribut non‑clé).
• BCNF – raffinement de la 3NF pour certains cas.

Une base bien normalisée évite les anomalies de mise à jour (insertion, suppression, modification). ISOSET forme à la mise en pratique de la normalisation sur des cas d’école et métiers.

• Règles de gestion : un Emprunteur peut emprunter plusieurs Livres. Un Livre peut être emprunté plusieurs fois (historique). Un Emprunt a une date d’emprunt et une date de retour prévue.
• MCD – Entités : EMPRUNTEUR, LIVRE ; Association EMPRUNT (cardinalités 1,n de chaque côté). Attributs de l’association : date_emprunt, date_retour_prevue.
• MLD – Tables EMPRUNTEUR (id_emp PK), LIVRE (id_livre PK), EMPRUNT (id_emp FK, id_livre FK, date_emprunt, date_retour_prevue) avec PK composite (id_emp, id_livre, date_emprunt).
• MPD – types : INT, VARCHAR(100), DATE ; index sur date_emprunt ; partition par année si volumes importants.

# Script MPD PostgreSQL pour la bibliothèque
CREATE TABLE emprunteur (
    id_emp SERIAL PRIMARY KEY,
    nom VARCHAR(100) NOT NULL,
    email VARCHAR(200) UNIQUE
);
CREATE TABLE livre (
    id_livre SERIAL PRIMARY KEY,
    titre VARCHAR(200) NOT NULL,
    isbn VARCHAR(13)
);
CREATE TABLE emprunt (
    id_emp INT,
    id_livre INT,
    date_emprunt DATE,
    date_retour_prevue DATE,
    PRIMARY KEY (id_emp, id_livre, date_emprunt),
    FOREIGN KEY (id_emp) REFERENCES emprunteur(id_emp),
    FOREIGN KEY (id_livre) REFERENCES livre(id_livre)
);
CREATE INDEX idx_emprunt_date ON emprunt(date_emprunt);

• Commencer toujours par le MCD – ne pas sauter cette phase conceptuelle même en méthodes agiles.
• Valider le MCD avec les utilisateurs métier – c’est le contrat avant de passer en logique.
• Choisir judicieusement les identifiants (clés primaires) – privilégier les clés techniques (auto‑incrément) plutôt que les codes métier modifiables.
• Documenter les règles de passage – pourquoi telle association devenue table ? pourquoi telle normalisation ?
• Tester le MPD avec un jeu de données réaliste – observer les temps de réponse, ajuster les index.
• Versionner les modèles – avec un outil de gestion de configuration (Git, SVN) pour les fichiers XML/plantUML.

Les témoignages d’anciens élèves d’ISOSET soulignent l’importance de Merise : *« Avant la méthode Merise, je créais des bases au hasard. Aujourd’hui, je formalise le MCD, je passe au MLD et j’implémente le MPD proprement. Plus d’erreurs de conception ! »*