Merise

Objectif

La modélisation des données selon Merise sert à obtenir le schéma d'une base de données relationnelle à partir d'un modèle que les experts du domaine peuvent lire et corriger.

La décision soutenue est celle de la structure des données persistantes, comme pour toute modélisation des données. Le premier des trois modèles successifs se construit avec le métier et n'emploie que ses mots; les deux suivants s'en déduisent par des règles de transformation puis par les contraintes du produit retenu. Le livrable est la suite des trois modèles, accompagnée du dictionnaire des données qui les documente.

Le vocabulaire de Merise circule en Suisse romande par la culture professionnelle francophone. Savoir lire un MCD et le rapprocher d'un diagramme entités-relations est donc, en environnement francophone, une compétence de lecture avant d'être une compétence de construction.

Usage

Quand l'utiliser

• Application existante documentée en Merise: lire le MCD livré avec elle avant toute décision de reprise ou de migration.
• Interlocuteurs formés à Merise: modéliser dans la notation que la salle sait critiquer plutôt que dans celle qu'elle doit apprendre.
• Conception d'un schéma relationnel: le passage du MCD au MLD donne les tables et les clés par des règles vérifiables.
• Lien qui porte ses propres données ou joint plus de deux entités: le MCD l'écrit tel quel, avec une cardinalité par patte, sans nommer tout de suite une entité intermédiaire.
• Cahier des charges francophone qui demande un MCD: la commande nomme l'artefact attendu.

Quand ne pas l'utiliser

• Équipe ou chaîne d'outils anglophone: la notation n'y sera pas lue, prendre le diagramme entités-relations.
• Modèle destiné à un code orienté objet: le MCD ne porte pas d'opérations, prendre le diagramme de classes UML.

Description

Les trois modèles

Le MCD décrit le domaine sans supposer ni technologie ni organisation du travail. Il porte des entités, chacune munie d'un identifiant et de ses propriétés, et des associations nommées qui relient ces entités. Chaque branche reliant une entité à une association s'appelle une patte. C'est un modèle de données: il vise une structure implémentable.

Le MLD exprime le même domaine en relations, au sens de Codd, c'est-à-dire en tables munies d'une clé primaire et de clés étrangères. Il reste indépendant du produit qui hébergera la base. Il se déduit du MCD par les règles de transformation de la méthode.

Le MPD décrit ces relations telles qu'elles existent sur un système de gestion de base de données donné, avec les types, les longueurs, les index et les choix de stockage que ce système impose et permet. Il appartient à l'administrateur de base de données, comme le niveau physique de tout modèle de données.

Deux mots qui changent de sens

Merise appelle association le lien nommé entre deux entités, et elle réserve le mot relation à une table du modèle relationnel. La tradition des pattes-de-corbeau fait l'inverse: elle nomme relation le lien entre deux entités. La confusion se produit à la première phrase échangée entre deux praticiens de formations différentes.

La cardinalité s'écrit aux deux extrémités

Chaque patte d'une association porte un couple de bornes séparées par une virgule, le minimum puis le maximum: 0,1, 1,1, 0,n ou 1,n. Le couple écrit du côté d'une entité dit combien de fois une occurrence de cette entité participe à l'association. Il se lit donc en descendant la patte vers l'association.

Sur la relation entre un assuré et sa police d'assurance-maladie, le MCD s'écrit Assuré (0,n) - détient - (1,1) Police. Le 0,n est du côté de l'Assuré et dit qu'un assuré participe zéro à plusieurs fois, donc qu'il détient zéro à plusieurs polices. Le 1,1 est du côté de la Police et dit qu'une police participe exactement une fois, donc qu'elle est détenue par exactement un assuré.

Les pattes-de-corbeau et UML répondent à la même question depuis l'autre bord. La marque posée à une extrémité y compte les occurrences de l'entité qui s'y trouve, vues depuis une occurrence de l'entité d'en face. Pour ce même fait, UML écrit 0..* du côté de la Police et 1 du côté de l'Assuré. Merise écrit 0,n du côté de l'Assuré et 1,1 du côté de la Police. Mêmes nombres, extrémités échangées. Song, Evans et Park nomment ces deux conventions Look Here et Look Across, d'après une distinction que Ferg avait posée quelques années plus tôt: la borne de Merise dit combien de fois participe une occurrence de l'entité à côté de laquelle elle est écrite; celle des pattes-de-corbeau et d'UML dit combien d'occurrences de cette même entité se rattachent à une occurrence de l'autre.

Un modèle transposé en recopiant les bornes à leur place produit un schéma qui affirme l'inverse du domaine, tout en restant un modèle valide que rien ne signale. Le contrôle qui l'évite ne coûte rien: énoncer la règle à voix haute dans les mots du métier (« un assuré détient zéro à plusieurs polices ») puis vérifier que la phrase sort identique des deux dessins.

La typographie sépare les deux systèmes: Merise écrit la virgule, 0,n; UML écrit le double point, 0..*. Merise impose le couple complet sur chaque patte dès le MCD: le minimum n'y est jamais différé.

Une association peut relier plus de deux entités. Une association ternaire porte alors trois pattes et trois couples de bornes. Les pattes-de-corbeau n'expriment pas cette configuration et obligent à la décomposer d'avance; le MCD l'écrit telle quelle et laisse la transformation s'en charger.

L'association porte ses propres propriétés

Une association de Merise peut porter des propriétés au même titre qu'une entité: c'est une association porteuse de propriétés. Entre Police et Prestation, l'association Couvre porte la date d'effet et le taux de participation, et aucune entité intermédiaire n'apparaît au MCD.

La tradition des pattes-de-corbeau n'offre pas ce recours. Une relation plusieurs-à-plusieurs n'a aucun côté où poser une clé étrangère ni aucune case où loger un attribut, si bien que l'analyste doit nommer une entité intermédiaire, lui donner un identifiant et lui attribuer ces données. La décision est prise au niveau conceptuel, à la main.

Merise déplace ce moment. Le MCD enregistre que ces deux choses sont liées et que le lien porte une date et un taux, sans trancher que le lien est lui-même une chose. La transformation vers le MLD produit la table, mécaniquement. Les deux écoles aboutissent au même schéma; elles diffèrent sur le point du processus où l'analyste s'engage.

Pour un relecteur venu des pattes-de-corbeau, un MCD dont une association porte des propriétés est complet, et y insérer une entité intermédiaire à la main double le travail que la transformation fera seule. Pour celui qui construit le MCD, une propriété n'a sa place sur une association que si elle dépend du couple: un taux de participation qui ne dépendrait que de la prestation appartiendrait à l'entité Prestation, et le laisser sur l'association le recopierait sur chaque police, ce qui est une violation de deuxième forme normale, que la modélisation des données traite par la normalisation.

Du MCD au MLD

Chaque entité du MCD devient une relation: son identifiant devient la clé primaire, ses propriétés deviennent les attributs. Les associations, elles, suivent leur cardinalité. Ces règles visent des tables et des clés: devant une base documentaire, en graphe ou en colonnes, le MCD reste utilisable et seul le passage au MLD cède la place au modèle propre au moteur retenu.

La première règle explique la place de la clé étrangère dans le schéma d'un assureur: la Police porte 1,1, donc c'est la table de la police qui reçoit le numéro AVS de l'assuré.

Le passage n'introduit aucune information. Toute décision qu'il applique a déjà été prise dans le MCD et validée avec le métier, où se concentre l'effort de la méthode. Une cardinalité fausse au MCD ressort en schéma faux, et la transformation ne vérifie rien.

Dans le travail outillé, le MLD n'est souvent pas dessiné comme un document distinct. Les ateliers de modélisation calculent le schéma logique en interne et engendrent le langage de définition de données depuis un MCD annoté. Les trois modèles décrivent ce que fait la technique et dans quel ordre; les trois diagrammes tracés à la main appartiennent à son enseignement.

Ce que le MCD ajoute au niveau conceptuel

L'écart tient à une seule chose: un MCD est un modèle de données conceptuel qui a déjà fait une partie du travail du niveau logique. Un praticien qui livre son MCD comme modèle de données conceptuel livre un document plus contraint que ce que ce niveau demande, ce qui est sans dommage. Le sens inverse porte le risque: recevoir un modèle de données conceptuel et le traiter comme un MCD, c'est supposer des cardinalités que personne n'a validées.

Reste la collision de sigles. Le MCD est un modèle de données, avec ses entités, ses cardinalités et la structure implémentable qu'il vise. Le modèle de concepts se tient en amont et fixe le sens des termes du métier. Quand un interlocuteur dit « modèle conceptuel », la question qui économise une réunion est de savoir s'il parle de vocabulaire ou d'entités et de cardinalités.

La partie traitements

Merise modélise aussi ce que l'organisation fait de ses données, sur une branche parallèle qui avance au même rythme que celle des données. Le modèle conceptuel des traitements (MCT) décrit l'activité indépendamment de qui l'exécute et avec quels moyens, autour de trois notions: l'événement qui déclenche, l'opération qui s'exécute et le processus qui les enchaîne. Le modèle organisationnel des traitements (MOT) reprend les mêmes traitements et les répartit entre les postes de travail, les lieux et les moments. La méthode organise l'ensemble par trois cycles, de vie, de décision et d'abstraction.

L'état de la pratique

Merise n'est plus la pratique internationale courante. Elle reste au programme de l'enseignement supérieur français, où le passage du MCD au MLD s'enseigne en BTS et en BUT informatique. Les systèmes qu'elle a servi à bâtir sont encore documentés et maintenus dans ses termes. Elle est en revanche presque absente de la pratique anglophone: la littérature académique compare Merise à SSADM, la méthode britannique de la même époque, parce que les deux traditions ne se sont pas croisées.

SAP a annoncé pour le 1^er janvier 2027 la fin de la maintenance principale de PowerDesigner, dernier atelier commercial d'ampleur à porter Merise en premier rang. PowerAMC, nom sous lequel le même produit était vendu sur le marché francophone, n'est plus distribué. Restent Mocodo, Looping et JMerise, gratuits et d'abord destinés à l'enseignement.

Pour un business analyste, la conséquence est une compétence de lecture. Un MCD reçu avec une application, un collègue qui dit MCD pour désigner le niveau conceptuel, un cahier des charges qui réclame un modèle conceptuel de données: aucun de ces cas ne demande d'adopter la méthode, tous demandent de savoir la lire.

Considérations IA

Le service le plus utile qu'un modèle de langue rende sur un MCD est la transposition, dans les deux sens, entre un MCD, un diagramme entités-relations et un diagramme de classes. Il en vaut la peine parce que la cardinalité s'inverse et que la transposition à la main est l'endroit où l'erreur se produit. Deux précautions le gouvernent. La première: nommer la convention de départ, puisque les mêmes bornes forment un modèle valide dans les deux conventions et que rien dans le dessin ne dit laquelle est employée. La seconde tient au corpus d'entraînement, majoritairement anglophone et donc dominé par la convention des pattes-de-corbeau, vers laquelle la sortie penche.

Deux autres services sont sûrs. Un modèle de langue applique les règles de passage du MCD au MLD sans se tromper, mais un atelier de modélisation le fait mieux: il ne comble pas une ambiguïté du modèle par une supposition. Un modèle de langue transcrit aussi en texte structuré un MCD qui n'existe qu'en image dans une documentation ancienne, ce qui rend un modèle hérité manipulable.

La limite est celle de toute modélisation des données et elle porte sur le dénombrement. Qu'une police puisse ou non couvrir plusieurs personnes est un fait que l'organisation détient et qu'aucun corpus ne contient. Toute cardinalité proposée par une machine est une hypothèse à valider auprès d'un expert du domaine.

Exemples

Le domaine est celui d'un assureur-maladie suisse: une police couvre un ensemble de prestations, et chaque couverture prend effet à une date et ouvre droit à un taux de participation.

Le MCD s'écrit Police (0,n) - Couvre - (0,n) Prestation, l'association Couvre portant elle-même la date d'effet et le taux de participation. Le 0,n du côté de la Police dit qu'une police couvre zéro à plusieurs prestations; celui du côté de la Prestation dit qu'une prestation figure dans zéro à plusieurs polices. Aucune entité ne porte le nom de Couverture à ce stade; personne n'a eu à décider que la couverture en était une.

Deux règles de passage s'appliquent ensemble: les deux pattes en 0,n font de l'association une relation, et les propriétés qu'elle porte en deviennent les attributs. Le MLD porte alors Couverture (#N° de police, #Code prestation, Date d'effet, Taux de participation), dont la clé primaire est formée des deux identifiants, chacun restant clé étrangère vers sa propre relation. C'est la table que la tradition des pattes-de-corbeau aurait fait apparaître dès le dessin du modèle de données conceptuel, sous le nom d'entité Couverture.

La date d'effet et le taux de participation se posent sur l'association parce qu'ils dépendent du couple. Aucun des deux n'appartient à la police seule, dont plusieurs prestations peuvent partir à des dates différentes, ni à la prestation seule, dont le taux varie d'un contrat à l'autre. Cette dépendance au couple fait l'association porteuse et impose la clé primaire composée.

Visualisations

La position de la cardinalité se contrôle à l'œil. Le couple de bornes se trouve sur la patte, près de l'entité, et se lit en descendant vers l'association: un lecteur qui prend ce réflexe ne se trompe plus de bord, quelle que soit la notation qu'il a apprise en premier. L'inversion, elle, ne devient perceptible qu'en plaçant les deux dessins côte à côte sur le même fait, parce que chaque dessin pris isolément est cohérent.

Le passage du MCD au MLD se lit de même sur la forme: l'association qui portait des propriétés se dessine comme une case au même titre que les entités, et ses deux pattes deviennent les deux moitiés de sa clé primaire.

Coût

Outils

Un tableau blanc suffit à la première ébauche d'un MCD, qui se corrige debout avec le métier. Les outils de schéma généralistes, diagrams.net, Lucidchart ou Visio, donnent un dessin propre: rien n'y contrôle une cardinalité ni n'engendre un MLD. Les outils dédiés à la méthode font la différence sur la transformation. Mocodo produit un MCD à partir d'une description textuelle et convient à un usage d'enseignement ou de documentation versionnée. Looping et JMerise dessinent le MCD, appliquent les règles de passage et engendrent le script de création de la base. Le même produit, vendu sous le nom PowerAMC sur le marché francophone puis sous celui de PowerDesigner, a longtemps tenu ce rôle en entreprise, sur un dépôt commun aux trois modèles. Le critère de choix reste le même que pour toute modélisation des données: l'outil de dessin suffit tant que le modèle sert de support de discussion, l'atelier devient nécessaire dès qu'il doit rester synchronisé avec une base réelle.

Sources

• Hubert Tardieu, Arnold Rochfeld, René Colletti, La méthode Merise: principes et outils, Les Éditions d'Organisation (1983): le texte fondateur de la méthode, qui définit les niveaux d'abstraction, le MCD et ses règles de passage.
• Arnold Rochfeld, Hubert Tardieu, « MERISE: An information system design and development methodology », Information & Management, vol. 6 (1983), pp. 143-159: le premier exposé de la méthode en anglais, par l'un de ses auteurs, sur l'origine et l'intention.
• David Avison, « MERISE: A European Methodology for Developing Information Systems », European Journal of Information Systems, vol. 1, n° 3 (1991), pp. 183-191: une présentation de la méthode pour un lectorat anglophone, qui la situe face à SSADM.
• Il-Yeol Song, Mary Evans, E. K. Park, « A Comparative Analysis of Entity-Relationship Diagrams », Journal of Computer and Software Engineering, vol. 3, n° 4 (1995), pp. 427-459: la comparaison formelle des notations entités-relations, dont les conventions Look Across et Look Here que ce texte reprend, distinction due à Stephen Ferg.
• SAP, Product Availability Matrix, SAP PowerDesigner: la fin de la maintenance principale annoncée au 1^er janvier 2027.