Merise

Goal

Data modelling in Merise produces the schema of a relational database from a model the domain experts can read and correct.

The decision it supports is the structure of persistent data, as in any data modelling. The first of the three successive models is built with the business and uses only the words of the business; the two that follow are derived from it by transformation rules and then by the constraints of the product chosen. The deliverable is the sequence of the three models, together with the data dictionary that documents them.

For a reader working in English or German the method arrives as vocabulary before it arrives as a method. Merise's terms circulate in French-speaking Switzerland through professional culture, so MCD, MLD and MPD turn up in a meeting, in a specification or in the documentation of a system inherited from a francophone team. Reading a MCD and matching it to an entity-relationship diagram is a reading skill before it is a construction skill.

Usage

When to use it

• An existing application documented in Merise: read the MCD delivered with it before any decision to reuse or migrate.
• Counterparts trained in Merise: model in the notation the room can criticise rather than in the one it would have to learn.
• Designing a relational schema: the passage from MCD to MLD gives the tables and the keys through rules that can be checked.
• A link carrying data of its own or joining more than two entities: the MCD writes it as it stands, one cardinality per leg, without naming an intermediate entity straight away.
• A French-language specification that asks for a MCD: the request names the artefact expected.

When not to use it

• An English-speaking team or toolchain: the notation will not be read there, take the entity-relationship diagram.
• A model destined for object-oriented code: the MCD carries no operations, take the UML class diagram.

Description

The three models

The MCD describes the domain without assuming a technology or an organisation of the work. It carries entities, each with an identifier and its properties, and named associations linking those entities. Each branch joining an entity to an association is a patte, a leg. It is a data model: it aims at an implementable structure.

The MLD expresses the same domain as relations in Codd's sense, that is, as tables with a primary key and foreign keys. It stays independent of the product that will host the database. It is derived from the MCD by the method's transformation rules.

The MPD describes those relations as they exist on a given database management system, with the types, lengths, indexes and storage choices that system imposes and allows. It belongs to the database administrator, like the physical level of any data model.

Two words that change meaning

Merise calls the named link between two entities an association and reserves the word relation for a table of the relational model. English-language practice splits the same two words differently: the crow's-foot tradition calls the link a relationship and, following Codd, calls the table a relation. The trap sits in the middle. A francophone colleague who says relation means a table; the same colleague rendering that word as "relationship" hands over the link instead.

Cardinality is written at both ends

Each leg of an association carries a pair of bounds separated by a comma, the minimum then the maximum: 0,1, 1,1, 0,n or 1,n. The pair written on the side of an entity says how many times one occurrence of that entity takes part in the association. It therefore reads by going down the leg towards the association.

On the relationship between an insured person and their health-insurance policy, the MCD reads Insured Person (0,n) - holds - (1,1) Policy. The 0,n is on the Insured Person side and says that an insured person takes part zero to several times, so holds zero to several policies. The 1,1 is on the Policy side and says that a policy takes part exactly once, so is held by exactly one insured person.

Crow's foot and UML answer the same question from the other side. The mark set at one end there counts the occurrences of the entity found at that end, seen from one occurrence of the entity opposite. For this same fact, UML writes 0..* on the Policy side and 1 on the Insured Person side. Merise writes 0,n on the Insured Person side and 1,1 on the Policy side. Same numbers, ends swapped. Song, Evans and Park name these two conventions Look Here and Look Across, after a distinction Ferg had drawn a few years earlier: the Merise bound says how many times one occurrence of the entity beside it takes part; the crow's-foot and UML bound says how many occurrences of that same entity attach to one occurrence of the other.

A model transposed by copying the bounds where they stand produces a schema that asserts the opposite of the domain, while remaining a valid model that nothing flags. The check that avoids this costs nothing: state the rule out loud in the words of the business ("an insured person holds zero to several policies") and verify that the sentence comes out identical from both drawings.

Typography separates the two systems: Merise writes a comma, 0,n; UML writes a double dot, 0..*. Merise requires the complete pair on every leg from the MCD onwards: the minimum is never deferred there.

An association can link more than two entities. A ternary association then carries three legs and three pairs of bounds. Crow's foot does not express that configuration and forces it to be broken up in advance; the MCD writes it as it stands and leaves the transformation to deal with it.

An association carries its own properties

A Merise association can carry properties just as an entity does: it is then an association porteuse de propriétés, a property-bearing association. Between Policy and Benefit, the association Covers carries the effective date and the co-payment rate, and no intermediate entity appears in the MCD.

The crow's-foot tradition offers no such device. A many-to-many relationship has no side on which to place a foreign key and no box in which to lodge an attribute, so the analyst has to name an intermediate entity, give it an identifier and assign it that data. The decision is taken at the conceptual level, by hand.

Merise moves that moment. The MCD records that these two things are linked and that the link carries a date and a rate, without settling that the link is itself a thing. The transformation to the MLD produces the table, mechanically. Both schools arrive at the same schema; they differ on the point in the process where the analyst commits.

For a reviewer coming from crow's foot, a MCD whose association carries properties is complete, and inserting an intermediate entity by hand duplicates work the transformation will do on its own. For whoever builds the MCD, a property belongs on an association only if it depends on the pair: a co-payment rate depending on the benefit alone would belong to the Benefit entity, and leaving it on the association would copy it onto every policy, which breaks second normal form, something data modelling handles through normalisation.

From MCD to MLD

Each entity of the MCD becomes a relation: its identifier becomes the primary key, its properties become the attributes. The associations follow their cardinality. These rules aim at tables and keys: faced with a document store, a graph or a columnar database, the MCD remains usable and only the passage to the MLD gives way to the model proper to the engine chosen.

The first rule explains where the foreign key sits in an insurer's schema: the Policy carries 1,1, so it is the policy table that receives the insured person's AVS number.

The passage introduces no information. Every decision it applies has already been taken in the MCD and validated with the business. That is where the method concentrates its effort. A wrong cardinality in the MCD comes out as a wrong schema, and the transformation checks nothing.

In tool-supported work the MLD is often not drawn as a separate document. Modelling workbenches compute the logical schema internally and generate the data definition language from an annotated MCD. The three models describe what the technique does and in what order; the three diagrams drawn by hand belong to its teaching.

What the MCD adds to the conceptual level

The gap comes down to one thing: a MCD is a conceptual data model that has already done part of the logical level's work. A practitioner who delivers their MCD as a conceptual data model delivers a document more constrained than that level asks for, which does no harm. The risk runs the other way: to receive a conceptual data model and treat it as a MCD is to assume cardinalities nobody has validated.

There remains the collision of names. The MCD is a model of data, with its entities, its cardinalities and the implementable structure it aims at. A concept model sits upstream and fixes the meaning of the terms of the business. When someone says "conceptual model", the question that saves a meeting is whether they mean vocabulary or entities and cardinalities.

The processing branch

Merise also models what the organisation does with its data, on a parallel branch advancing at the same pace as the data branch. The MCT (modèle conceptuel des traitements, conceptual processing model) describes the activity independently of who performs it and with what means, around three notions: the event that triggers, the operation that runs and the process that chains them. The MOT (modèle organisationnel des traitements, organisational processing model) takes the same processing and distributes it across workstations, places and times. The method organises the whole through three cycles, of life, of decision and of abstraction.

The state of practice

Merise is no longer current international practice. It remains on the syllabus of French higher education, where the passage from MCD to MLD is taught in the BTS and BUT computing diplomas. The systems it was used to build are still documented and maintained in its terms. It is close to absent from English-language practice: the academic literature compares Merise with SSADM, the British method of the same period, a comparison that exists because the two traditions never crossed.

SAP has announced the end of mainstream maintenance for PowerDesigner on 1 January 2027, the last commercial workbench of any scale to carry Merise as a first-class notation. PowerAMC, the name under which the same product was sold on the francophone market, is no longer distributed. What remains is Mocodo, Looping and JMerise, free and aimed first at teaching.

For a business analyst the consequence is a reading skill. A MCD received with an application, a colleague saying MCD for the conceptual level, a specification asking for a modèle conceptuel de données: none of these calls for adopting the method, all of them call for being able to read it.

AI considerations

The most useful service a language model renders on a MCD is transposition, in both directions, between a MCD, an entity-relationship diagram and a class diagram. It is worth asking for because the cardinality inverts and because transposing by hand is where the error occurs. Two precautions govern it. The first: name the starting convention, since the same bounds form a valid model in either convention and nothing in the drawing says which one is in use. The second concerns the training corpus, mostly English-language and therefore dominated by the crow's-foot convention, towards which the output leans.

Two further services are safe. A language model applies the MCD to MLD rules without error, but a modelling workbench does it better: it does not fill a gap in the model with a guess. A language model also transcribes into structured text a MCD that exists only as an image in old documentation, which makes an inherited model workable again.

The limit is the one every data modelling exercise meets and it bears on counting. Whether a policy may or may not cover several people is a fact the organisation holds and no corpus contains. Any cardinality a machine proposes is a hypothesis to be validated with a domain expert.

Examples

The domain is that of a Swiss health insurer: a policy covers a set of benefits, and each coverage takes effect on a date and carries a co-payment rate.

The MCD reads Policy (0,n) - Covers - (0,n) Benefit, the association Covers itself carrying the effective date and the co-payment rate. The 0,n on the Policy side says that a policy covers zero to several benefits; the one on the Benefit side says that a benefit appears in zero to several policies. No entity bears the name Coverage at this stage; nobody has had to decide that the coverage is one.

Two transformation rules apply together: both legs in 0,n make the association a relation, and the properties it carries become that relation's attributes. The MLD then carries Coverage (#Policy number, #Benefit code, Effective date, Co-payment rate), whose primary key is formed of the two identifiers, each remaining a foreign key towards its own relation. This is the table the crow's-foot tradition would have made appear as soon as the conceptual data model was drawn, under the name of a Coverage entity.

The effective date and the co-payment rate sit on the association because they depend on the pair. Neither belongs to the policy alone, several of whose benefits may start on different dates, nor to the benefit alone, whose rate varies from one contract to the next. That dependency on the pair makes the association property-bearing and imposes the composite primary key.

Visualizations

The position of the cardinality can be checked by eye. The pair of bounds sits on the leg, near the entity, and reads by going down towards the association: a reader who takes on that reflex stops mistaking the side, whichever notation they learned first. The inversion itself becomes perceptible only by placing the two drawings side by side on the same fact, because each drawing taken on its own is consistent.

The passage from MCD to MLD reads the same way in the shape: the association that carried properties is drawn as a box like the entities, and its two legs become the two halves of its primary key.

Cost

Tooling

A whiteboard is enough for a first sketch of a MCD, which gets corrected standing up with the business. General-purpose diagramming tools, diagrams.net, Lucidchart or Visio, give a clean drawing: nothing in them checks a cardinality or generates a MLD. The tools dedicated to the method make the difference on the transformation. Mocodo produces a MCD from a textual description and suits teaching or version-controlled documentation. Looping and JMerise draw the MCD, apply the transformation rules and generate the script that creates the database. The same product, sold as PowerAMC on the francophone market and then as PowerDesigner, long held that role in the enterprise, on a repository shared by the three models. The criterion for choosing stays the one that governs any data modelling: a drawing tool is enough as long as the model is a basis for discussion, a workbench becomes necessary the moment it has to stay synchronised with a real database.

Sources

• Hubert Tardieu, Arnold Rochfeld, René Colletti, La méthode Merise: principes et outils, Les Éditions d'Organisation (1983): the founding text of the method, which defines its levels of abstraction, the MCD and its transformation rules.
• Arnold Rochfeld, Hubert Tardieu, "MERISE: An information system design and development methodology", Information & Management, vol. 6 (1983), pp. 143-159: the first account of the method in English, by one of its authors, on its origin and its intent.
• David Avison, "MERISE: A European Methodology for Developing Information Systems", European Journal of Information Systems, vol. 1, no. 3 (1991), pp. 183-191: a presentation of the method for an English-reading audience, which places it against SSADM.
• Il-Yeol Song, Mary Evans, E. K. Park, "A Comparative Analysis of Entity-Relationship Diagrams", Journal of Computer and Software Engineering, vol. 3, no. 4 (1995), pp. 427-459: the formal comparison of entity-relationship notations, including the Look Across and Look Here conventions used here, a distinction due to Stephen Ferg.
• SAP, Product Availability Matrix, SAP PowerDesigner: the end of mainstream maintenance announced for 1 January 2027.