MERISE: The French Database Modeling Superpower That Could Save Your Data Model

You saved my life. There’s not one day when I don’t use MERISE.

An experienced developer told me this six months after attending my masterclass. When a senior pro says this with half a year of hindsight, it’s not just politeness. It’s because they’ve seen how much damage a lack of methodology can do in the long run.

The Death of Data Modeling? 🔗

Lately, I’ve noticed a frustrating trend. Many schools are skipping data modeling entirely. Developers are jumping straight into coding, modeling on the fly or by feel. They start with an empty IDE and a create table statement.

The problem is that while code and infrastructure are transient, data is what anchors the business. Business rules and processes might evolve, but your core business objects rarely change. You don’t switch from selling ice cream to teaching math overnight. If you don’t model those core objects correctly from the start, you are building on shifting sands.

The result of skipping modeling is always the same: costly architectural errors discovered only when the system is already under load and too expensive to refactor.

What is MERISE? 🔗

MERISE is a structured approach born in France in the late 70s. It’s built on a simple truth: IT serves the business, not the other way around. It provides a common language between developers and business experts.

The strength of this method lies in its rigorous transition between levels of abstraction, as shown in the diagram below:

It works through three distinct levels:

1. Conceptual Data Model (CDM): Pure business logic. No IDs, no tech.
2. Logical Data Model (LDM): The relational structure.
3. Physical Data Model (PDM): The implementation, including PostgreSQL types, indexes, views triggers, stored functions and procedures…

This separation is its superpower. You validate the business rules before writing a single line of SQL.

The Ad-Hoc Modeling Trap: The Address Example 🔗

Let’s look at something as common as addresses. Most developers just throw an address column into a student table. In my masterclass, I demonstrate that there isn’t just one way to do it. Depending on the business needs, you might choose different paths.

If you start with a simple attribute, you are stuck:

But wait, what if a student has several addresses (like a home address and a campus address)? You need to handle multiplicity:

Then you might realize ome students have more than one home addresse because their parents got divorced, so you need to move addresses to a separate entity:

Finally, for large systems where you need to report by region or avoid typos in city names, you move towards a fully normalized model:

If you don’t use a method like MERISE to discuss these trade-offs with the business early on, you’re just guessing. And guessing in production is expensive.

Why It Works 🔗

The cardinalities (those 0,n or 1,1 notations) are actually encoded business rules. They force you to ask the right questions: Can a customer exist without an address? Can an address belong to multiple customers?

The benefits are clear:

• Catch errors early: It is easier to fix a line on a diagram than to migrate a terabyte of data.
• Common language: The business stakeholders actually understand the CDM.
• Better decisions: You understand the performance trade-offs before implementation.
• Documentation built-in: The model is the documentation.

Conclusion 🔗

MERISE isn’t just a French academic relic. It’s a superpower for anyone who wants to build robust, maintainable databases. You don’t need to be French to use it, you just need to care about your data.

Want to learn MERISE? I teach masterclasses on database modeling where we dive deep into these concepts. Drop me a message if you want to stop modeling by feel and start modeling for success.