La méthode
La méthode Merise, expliquée
Merise sépare ce que les données sont de la façon dont elles seront rangées. On décrit d'abord le domaine, sans penser aux tables, puis on en déduit la base. Voici la méthode, avec un seul exemple suivi du début à la fin.
D'où vient Merise
Merise est une méthode française d'analyse et de conception des systèmes d'information, mise au point à la fin des années 1970 à la demande du ministère de l'Industrie. Elle est encore enseignée en France, en BTS, en BUT et à l'université, parce qu'elle met des mots précis sur une question qui ne vieillit pas : de quoi parle-t-on, et comment le ranger.
Pour les données, Merise avance par niveaux. Le modèle conceptuel décrit le domaine. Le modèle logique en tire des tables. Le modèle physique ajoute les types d'un moteur précis. Chaque niveau se déduit du précédent par des règles, ce qui veut dire qu'une erreur de conception se voit avant d'avoir écrit la moindre ligne de SQL.
Le dictionnaire des données
Tout commence par la liste des informations à gérer : le dictionnaire des données. Chaque propriété y est écrite une seule fois, avec un nom et un type. C'est la règle d'unicité : une donnée appartient à un seul endroit du modèle, sinon elle finira recopiée, donc contradictoire.
Prenons une bibliothèque. Les données utiles : le numéro d'adhérent, le nom de l'adhérent, le titre d'un livre, son ISBN, et la date d'un emprunt.
Un piège classique. Noter « nom » deux fois, une fois pour
l'adhérent et une fois pour l'auteur, ce sont deux propriétés différentes. Nommez-les
distinctement, nomAdherent et nomAuteur, et la suite du
modèle vous le rendra.
Les entités
Une entité est un objet du domaine dont on veut garder des informations : un adhérent, un livre, une salle. Elle porte des attributs, pris dans le dictionnaire, et parmi eux un identifiant qui distingue une occurrence de toutes les autres.
Dans notre bibliothèque, deux entités suffisent pour commencer.
L'identifiant peut être composé de plusieurs attributs quand un seul ne suffit pas : une séance de cinéma, par exemple, s'identifie par la salle et l'horaire.
Les associations
Une association relie des entités. Elle porte un verbe, parce qu'elle décrit ce qui se passe entre elles : un adhérent emprunte un livre. Une association peut elle aussi porter des attributs, quand l'information n'appartient ni à l'une ni à l'autre des entités reliées.
La date d'un emprunt en est l'exemple parfait : elle n'est ni une propriété de l'adhérent, ni une propriété du livre. Elle n'existe que parce que les deux se rencontrent.
Les cardinalités, le cœur du modèle
Chaque patte entre une entité et une association porte un couple de nombres, la cardinalité. Elle se lit depuis l'entité, et répond à une question précise :
Une occurrence de cette entité participe au minimum combien de fois, et au maximum combien de fois, à cette association ?
Quatre couples suffisent dans l'immense majorité des cas.
| Couple | Lecture |
|---|---|
| 0,1 | peut ne pas participer, et au plus une fois |
| 1,1 | participe exactement une fois, ni plus ni moins |
| 0,n | peut ne pas participer, ou participer plusieurs fois |
| 1,n | participe au moins une fois, et peut-être beaucoup |
Sur notre exemple : un adhérent peut n'avoir jamais emprunté, ou avoir emprunté souvent, donc 0,n. Un exemplaire de livre, lui, est emprunté par un adhérent et un seul à la fois, donc 1,1.
L'erreur la plus fréquente. Lire la cardinalité dans le mauvais sens, c'est-à-dire depuis l'association. Placez-vous toujours sur l'entité, et demandez-vous combien de fois une seule de ses occurrences apparaît dans l'association. Le reste du modèle en dépend, car c'est cette lecture qui décide où ira la clé étrangère.
Du MCD au modèle relationnel
Le passage au modèle logique suit des règles mécaniques. Il n'y a rien à inventer : si le MCD est juste, les tables le sont.
Règle 1 : chaque entité devient une table
Ses attributs deviennent des colonnes, son identifiant devient la clé primaire.
Règle 2 : une association avec un côté 1,1 ou 0,1 donne une clé étrangère
La clé étrangère se place du côté du maximum 1. Dans notre exemple,
c'est le livre qui participe une seule fois, donc c'est la table
Livre qui reçoit le numéro de l'adhérent. Les attributs de l'association
la suivent : la date d'emprunt atterrit dans Livre.
Règle 3 : une association n des deux côtés devient une table
Quand les deux pattes portent un maximum n, aucune des deux tables ne peut accueillir l'autre. L'association devient alors une table à part entière, dont la clé primaire est composée des identifiants des entités reliées. Ses attributs deviennent ses colonnes.
Si la bibliothèque gardait l'historique, un livre aurait été emprunté plusieurs fois,
la patte deviendrait 0,n des deux côtés, et Emprunter deviendrait une
table :
Du modèle relationnel au SQL
Reste à choisir un moteur. C'est seulement là qu'apparaissent les types concrets :
un texte devient VARCHAR(255) ou TEXT, un entier devient
INT, une date devient DATE. Le modèle conceptuel, lui,
n'a jamais eu à les connaître.
Pratiquer la méthode
Merise s'apprend en modélisant, pas en lisant. C'est pour cela que Meriz existe : vous dessinez le MCD, l'outil vérifie les règles au fur et à mesure, puis il applique lui-même les règles de passage et vous montre le MLD, le MPD et le SQL qui en découlent. Vous voyez donc immédiatement l'effet d'une cardinalité sur la base finale, ce qui est la façon la plus rapide de comprendre pourquoi elle compte.