Institut Universitaire et Stratégique de

l’Estuaire
Estuary Academic and Strategic Institute (IUEs/Insam)
Sous la tutelleacadémique des Universités de Dschang et de
Buéa.

LECTURE NOTES ON MERISE

Specialty: software Engineering

(level one)

COURSE FACILITATOR: Mr. FOTSO

Academic Year: 2021/2022

1
Introduction
MERISE is a French method born in the 70s, originally developed by Hubert
Tardieu. It was then put forward in the 80s, at the request of the Ministry of
Industry who wanted a method of designing the Databases and information.
MERISE is therefore a method of analysis and design of Databases and
information systems based on the principle of separation of data and
processes. It has a number of models (or schemas) that are spread over 3
levels:
• The conceptual level,
• The logical or organizational level,
• The physical level.

In this course, we will mostly be interested in certain diagrams allowing the

design of a relational database then its realization on a RDBMS.
This is the development of the conceptual data model (CDM) which is a
graphical and structured representation of the data stored by an IS. The CDM
is based on two main concepts: entities and associations, hence its second
name: the Entity-Association design.
The development of the CDM goes through the following steps:
• The implementation of management rules (if they are not given to you),
• Development of the data dictionary,
• The search for functional dependencies between these data,
• Development of the CDM (creation of entities then associations and addition
of cardinalities)
I. Management Rules
Before you start creating your tables (or even your entities and associations to
stay in a conceptual vocabulary), you need to collect the needs or requirements
of the future users of your application. And from these needs, you must be able
to establish the data management rules to keep.

Take the example of a developer who has to computerize the IS of a library. We

set the following management rules:
• For each book, you must know the title, the year of publication, a summary
and type (novel, poetry, science fiction, ...).
• A book can be written by anyone (in the case of an anonymous work), one or
2
 more authors whose name, first name, date of birth and country of origin are
known.
• Each copy of a book is identified by a reference consisting of letters and
numbers and can only be published in one and only one edition.
• A registrant is identified by a number and one must memorize his name, first
name, address, telephone and e-mail address.
• A registrant may make zero, one or more loans that each relate to one and
only one copy. For each loan, we know the date and the time allowed (in
number of days).

These rules are sometimes given to you but you may have to establish them
yourself in two cases:
• You may be both prime contractor and contracting authority (project
manager or IS developer) , and you develop an application for your account and
/ or according to your own instructions.
• What happens most often: the future users of your project have not been
able to provide you with these rules with enough precision; that is why you will
need to interview them to establish these rules yourself. Never forget that as a
developer, you have a duty to assist the project owner if necessary.

II. Data dictionary

This is an intermediate step that can be important, especially if you are more than
one working on the same database, a large volume.
The data dictionary is a document that gathers all the data that you will have to
keep in your database (and that will appear in the CDM). For each data, it
indicates:
• The mnemonic code: this is a wording designating a datum (for example
"titre_l" for the title of a book)
• The designation: this is a statement describing what the data corresponds to (eg
"book title")
• The type of data:
o A or Alphabetic: when the data is composed only of alphabetic characters (from
'A' to 'Z' and 'a' to 'z')
o N or Numeric: when the data is composed only of numbers (integer or real)
o AN or Alphanumeric: when the data can be composed of both alphabetic and
numerical characters

3
o Date: when the data is a date (in YYYY-MM-DD format)
o Boolean: True or False
• Size: it is expressed in number of characters or numbers. In the case of a date in
YYYY-DD-MM format, the number of characters, ie 10 characters, is also counted.
For the Boolean type, there is no need to specify the size (this depends on the
implementation of the RDBMS).
• And sometimes additional remarks or observations (for example if a data is
strictly greater than 0, etc.).
Let's take the example of our library and the loan management system that we
are responsible for computerizing. After the study of the management rules, we
can establish the following data dictionary:
Mnemonic Designation type Size
code Remark
id_c Digital ID of a customer N 30
name_c Name of a customer text 30
F_name_c First name of a customer text 30
Street_c Street where lives a customer text 50
City_c City where lives a customer text
Pc_c Postal code of a registered memo 10
Tel_c Mobile phone number of a customer Number 10
email_c Email address of a customer memo 40
Date_of_b_c Date of birth of the customer Date/ time In y-m-d

Notes:

The data in the CDM (and thus in the data dictionary) must be, in most cases, elementary:
They must not be calculated: the calculated data must be obtained, by calculation, from
elementary data which, they, are kept in base. However, there are some cases where it is relevant to
keep, for optimization reasons, a calculated data, the amount of an order for example. However, the
intermediate calculated data will not be kept except in the case of a legal obligation (this is the case
for example, for example, where the components may have a variable price over time). Indeed, it
avoids redoing the calculations several times for a result that will remain fixed.
They must not be composed: the composite data must be obtained by the concatenation of
basic data kept in base. For example, an address is obtained from a street, a city and a postal code:
these are the last three data that are kept and therefore that will appear in the CDM (and in the data
dictionary).
When one never performs a calculation on a numerical data, this one must be of type AN (it is the
case for example for a telephone number).

III. Functional dependencies

4
Functional Dependency
Functional Dependency is a constraint between two sets of attributes in
relation to a database. A functional dependency is denoted by an arrow (→).
If an attribute A functionally determines B, then it is written as A → B.

For example, employee_id → name means employee_id functionally

determines the name of the employee. As another example in a timetable
database, {student_id, time} → {lecture_room}, student ID and time
determine the lecture room where the student should be.
What does functionally dependent mean?
A function dependency A → B means for all instances of a particular value of
A, there is the same value of B.
For example in the below table A → B is true, but B → A is not true as there
are different values of A for B = 3.
A B
------
1 3
2 3
4 0
1 3
4 0
Trivial Functional Dependency
X → Y is trivial only when Y is subset of X.
Examples

ABC → AB
ABC → A

IV. The Conceptual Data Model (CDM)

a) The Entities

5
Each entity is unique and is described by a set of properties still called
attributes or characteristics. One of the properties of the entity is the identifier.
This property must have unique occurrences and must be a source of
functional dependencies with all other properties of the entity. Often, we use
an integer datum that increments for each occurrence, or a unique code
specific context.

The formalism of an entity is as follows:

So, if we take our previous data dictionary, we schematize for example an entity "Author" like
this:

From this entity, we can find the following management rule: an author is identified by a
unique number (id_a) and is characterized by a name, a first name and a date of birth.

An entity may have no, one or more occurrences. To illustrate this term of "occurrence" that
has already been used several times, here is an example of a table of occurrences of the entity
Author:

id_a nom_a prenom_a date_naissance_a

1 Hugo Victor 1802-02-26
2 Rimbaud Arthur 1854-10-20
3 de Maupassant Guy 1850-08-05

b) Association

An association defines a semantic link between one or more entities. Indeed, the definition of
links between entities makes it possible to translate a part of the management rules that have
not been satisfied by the simple definition of the entities.

6
The formalism of an association is as follows:

Generally the name of the association is a verb defining the link between the entities that are
linked by the latter. For example :

Here the association "to be born" translates the two following management rules:

An author was born in one and only one country,

In one country, no one or more authors are born.

You will notice, that this association is characterized by these annotations 1,1 and 0, N which
allowed us to define the rules of previous management. These annotations are called
cardinalities.

Cardinality is defined as this:

minimum, maximum

The most common cardinalities are: 0, N; 1, N; 0.1; 1.1. We can however come across
management rules imposing cardinalities with particular values, but this is quite exceptional
and the presence of these cardinalities will require the implementation of additional
treatments.

The identifier of an association having cardinalities 0, N / 1, N on both sides is obtained by

the concatenation of the entities participating in the association. Imagine the following
association:

Here an author writes at least one or more books and for each book the number of chapters written
by the author is known (the total number of chapters for each book is also known).

7
The association "to write" can thus be identified by the concatenation of the properties id_a and id_l.
Thus, the pair id_a, id_l must be unique for each occurrence of the association. We can also define
the following functional dependency:

id_a, id_l → nb_chapters

It is said that nb_chapitres (number of chapters written by an author, for a book) is a data carried by
the association "to write". This association is therefore an association carrying data.

For an association with at least a cardinality of type 0,1 or 1,1, consider at first that the latter ca not
carry data and that it is identified by the identifier of the entity carrying the cardinality 0 , 1 or 1,1.

We will come back in more detail on the notion of identification of an association during the
transition to the logic model.
c) Development of the CDM
With all this knowledge, it is therefore possible for us to develop the complete CDM from the data
present in the data dictionary:

8
Notes:

Often, for the same set of management rules, several solutions are possible at the conceptual
level. For example, nothing required us here to create a Type entity. A single piece of data carried by
the Book entity might have been suitable as well.
For the CDM to be semantically valid, any entity must be connected to at least one association.
Entities and properties can be historized. In this case we put a (H) at the end of the name of the
entity or the property that we want to record (this makes it possible to specify that we will archive all
the modifications on a given entity or property). This must also meet a management rule.
There are paid and free modeling tools for MERISE (powerAMC, OpenModelSphere, AnalyzeSI,
JMerise, etc).
In this case, we could also have kept a date of receipt of books, calculated from the date of rental
and the duration of it. This is an example of calculated data whose conservation may be relevant
(especially to facilitate the sending of reminders).
V) Modeling of a database at the logical level and transition to SQL

9
in this part, we will see how to establish a data model at the logical (or relational) level from a
conceptual model, then is how to move from the table creation stage (this implies having a prior
knowledge of the queries). SQL for creating tables).
A) The transition from CDM to LDM
1) Relations

The Data Logic Model (LDM) is composed only of so-called relationships. These
relationships come from both MCD entities and associations in some cases. These
relationships will allow us to create our tables at the physical level.

A relationship is composed of attributes. These attributes are elementary data coming from
the properties of the various entities but also from the identifiers and the data carried by
certain associations.

A relationship has a name that usually corresponds to that of the entity or association that
corresponds to it. It also has a primary key that unambiguously identifies each occurrence of
this relationship. The primary key can be composed of one or more attributes, it is an
implementation of the notion of identifier of the entities and associations which is reflected at
the relational level.

Here is a first example of a relationship (from the "Edit" entity of our previous MCD):
Edition (id_ed, name_ed)
Legend :
x : relation
x : primary key
Notes:

This first MLD is represented textually. It is this representation that is found in many higher
education courses. However, there is an equivalent graphical representation.
It is important to accompany a textual MLD with a legend (the latter having no standardized
formalism). This is also required in some formations.

There is another type of key called foreign key. The foreign key is an attribute of a relation that refers
to the primary key of another relation (these two keys will have to have the same type of data).

Let's complete our first example with another relationship where a foreign key appears:
Edition (id_ed, name_ed)
Exemplaire (ref_e, id_ed#)

Legend :
x : relation
x : primary key
x# : foreign key
Notes:

At the relational level, we should rather speak of a candidate key that unambiguously identifies an

10
occurrence of the relationship for the primary keys. Similarly, we should designate a foreign key by
an inclusion constraint to a candidate key. For the sake of simplicity, we will keep the terms of
primary and foreign keys.
By convention, we precede or follow the foreign key of the symbol #. This is not an obligation from
the moment the legends are sufficiently precise.
Here the foreign key present in the relation "Copy" refers to the primary key of the relation
"Edition".
A relationship may have none, one or more foreign keys but always has one and only one primary
key.

Finally, you can also meet the term cardinality of the relation which means here the number of
occurrences of a relation (or number of entries in the corresponding table) and the term of degree of
the relation which corresponds to the number of attributes of a relationship.
2) Conversion rules
As already mentioned, the relations of the LDM come from the entities of the MCD and certain
associations. We will now discuss these conversion rules more precisely.
Rule 1 - Conversion of an Entity
As a general rule, any MCD entity becomes a relationship whose key is the identifier of that entity.
Each property of the entity becomes an attribute of the corresponding relationship.
There are, however, some special cases that you will see in the paragraph.
Rule 2 - conversion of associations having only cardinalities of type 0/1, N

Write (id_a #, id_l #)

Legend:
x: relation
x: primary key
x #: foreign key
In the case of associations carrying data, the carried data become attributes of the corresponding
relation. If we take this example again:

Rule 3 - conversion of associations having at least one type 1.1 cardinality

Several possibilities are available to us for this case. The most common conversion rule today is to
add a foreign key in the relation that corresponds to the entity on the side of this cardinality 1,1. This
foreign key will therefore refer to the key of the relation corresponding to the second entity linked by
the association.

Let's take an example from the association "to be from" and from the entities "Author" and

11
"Country":

Country (p_name)
Author (id_a, name_a, firstname_a, date_birth_a, name_p #)

Legend:
x: relation
x: primary key
x #: foreign key

When applying this conversion rule, two restrictions apply:

The association cannot be a data carrier. The data carried are in direct functional dependencies
with the identifier of the entity whose corresponding key will be referenced by a foreign key in
another relation.
The association must be binary (ie connect only two entities and not more).

When two entities are both connected with cardinality 1,1 by the same association, the foreign key
can be placed on any side. By convention, one chooses to place it on the side of the relation
corresponding to the entity having the most connections with the others. Some consider that two
entities are connected by an association with cardinality 1,1 on both sides, must necessarily merge.
This rule relies once again on the notion of direct functional dependencies but is not always
respected (it is sometimes semantically preferable to keep a distinction between the two entities).

Another (less common) solution consists in creating an associative relation whose key is this time
composed only of the foreign key which refers to the identifier of the entity on the opposite side to
cardinality 1,1.

If we go back to the same example, here is what we should get:

Country (p_name)
Author (id_a, name_a, firstname_a, date_birth_a)
BeOriginaryDe (id_a #, name_p #)

Legend:
x: relation
x: primary key
x #: foreign key

In this case, the association can carry data. The latter will thus become attributes of the associative
relation as in the case of 0.1 / N cardinalities.

Needless to say, the first solution is better than the latter in terms of optimization and simplification
of requests.

12
Rule 4 - conversion of associations with at least one cardinality of type 0,1
(and other cardinalities of type 0,1 / N)
As for cardinalities 1,1, an association with a cardinality of 0,1 must be binary, and the two
same possibilities are available to us:
Create the foreign key in the relation corresponding to the entity on the side of the
cardinality 0,1. Remember that in this case, the association can not be data carrier.
Create an associative relationship that would be identified in the same way as for
cardinality 1,1.
However, in the context of a cardinality 0,1, we will see that it is not always preferable to
favor the first method as it is the case for cardinality 1,1.

For example, imagine that a book can belong to 0 or 1 categories, we obtain the following
CDM:

Some will say that all father-son binary associations with cardinalities 1, N / 0, N - 1.1 / 0.1 are
characterized by the existence of a functional dependency between the identifier of the father entity.
(here id_cat) and the child entity (here id_l). This functional dependence would be schematized as
follows:

id_l → id_cat

In this case, it makes sense to translate the CDM this way (first method):

Category (id_cat, libelle_cat)

Book (id_l, title_l, year_l, resume_l, id_cat #)

Legend:
x: relation
x: primary key
x #: foreign key

However, even if the DBMS allow it (with the default NULL value), it is not normally allowed to have a
foreign key with no value for which we would find the occurrence in the relation we are referring to.

This is why others think (with reason) that it is better to create an associative relation in this way
(second method):

Category (id_cat, libelle_cat)

Book (id_l, title_l, year_l, resume_l)
Belonging (id_l #, id_cat #)

Legend:
x: relation
13
x: primary key
x #: foreign key

The relevance of one or the other method varies according to the number of occurrences
characterized by the cardinality 0 or the cardinality 1. Indeed, when the occurrences with the
cardinality 1 are more numerous than the occurrences with the cardinality 0, the first method is
preferable. In the opposite case, it is the second method which is the most adapted.

Finally, in the case where a binary association has both a cardinality 0,1 and a cardinality 1,1 (which is
rarely the case), it is preferable that the foreign key is on the side of the relation corresponding to
the entity located on the side of cardinality 1,1.

VI ELABORATION of the LDM and transition to SQL

With these different conversion rules, we can already convert our entire CDM:

Country (id_p, name_p)

Author (id_a, name_a, firstname_a, date_birth_a, id_p #)
TypeBook (id_t, libelle_t)
Book (id_l, title_l, year_l, resume_l, id_t #)
Write (id_a #, id_l #)
Edition (id_ed, name_ed)
Copy (ref_e, id_ed #, id_l #)
Registered (id_i, name_i, prenom_i, date_naissance_i, street_i, city_i, cp_i, email_i, tel_i,
tel_portable_i)
Loan (id_em, date_em, delais_em, id_i #, ref_e #)

Legend:
x: relation
x: primary key
x #: foreign key

As you can see, the schema of the base is already done. The rules for switching to SQL are quite
simple:

every relationship becomes a table

each attribute of the relation becomes a column of the corresponding table
each primary key becomes a PRIMARY KEY
every foreign key becomes a FOREIGN KEY

Here is what it would give:

Sélectionnez
CREATE TABLE Pays (
id_p INT NOT NULL,
nom_p VARCHAR(50),
PRIMARY KEY (id_p)
);

CREATE TABLE Auteur (

id_a INT NOT NULL,
nom_a VARCHAR (30),
prenom_a VARCHAR (30),
date_naissance_a DATE,

14
 id_p INT NOT NULL,
FOREIGN KEY (id_p) REFERENCES Pays(id_p),
PRIMARY KEY (id_a)
);

CREATE TABLE TypeLivre (

id_t INT NOT NULL,
libelle_t VARCHAR (30),
PRIMARY KEY (id_t)
);

CREATE TABLE Livre (

id_l INT NOT NULL,
titre_l VARCHAR (254),
annee_l VARCHAR (4),
resume_l TEXT,
id_t INT NOT NULL,
FOREIGN KEY (id_t) REFERENCES TypeLivre(id_t),
PRIMARY KEY (id_l)
);

CREATE TABLE Rediger (

id_a INT NOT NULL,
id_l INT NOT NULL,
FOREIGN KEY (id_a) REFERENCES Auteur(id_a),
FOREIGN KEY (id_l) REFERENCES Livre (id_l),
PRIMARY KEY (id_a, id_l)
);

CREATE TABLE Edition (

id_ed INT NOT NULL,
nom_ed VARCHAR (254),
PRIMARY KEY (id_ed)
);

CREATE TABLE Exemplaire (

ref_e VARCHAR(254) NOT NULL,
id_ed INT NOT NULL,
id_l INT NOT NULL,
FOREIGN KEY (id_ed) REFERENCES Edition (id_ed),
FOREIGN KEY (id_l) REFERENCES Livre(id_l),
PRIMARY KEY (ref_e)
);

CREATE TABLE Inscrit (

id_i INT NOT NULL,
nom_i VARCHAR (30),
prenom_i VARCHAR (30),
date_naissance_i DATE,
rue_i VARCHAR(50),
ville_i VARCHAR(50),
cp_i VARCHAR (5),
tel_i VARCHAR(15),
tel_portable_i VARCHAR(15) ,
email_i VARCHAR(100),
PRIMARY KEY (id_i)
);

CREATE TABLE Emprunt (

id_em INT NOT NULL,
date_em DATE,

15
 delais_em INT DEFAULT 0,
id_i INT NOT NULL,
ref_e VARCHAR (254) NOT NULL,
FOREIGN KEY (id_i) REFERENCES Inscrit(id_i),
FOREIGN KEY (ref_e) REFERENCES Exemplaire(ref_e),
PRIMARY KEY (id_em)
);

Note: It is possible to not have to manage the incrementation of the identifiers by itself during
INSERT with most DBMS.

Example of auto-incrementation under MySQL:

CREATE TABLE TypeLivre (

id_t INT AUTO_INCREMENT,
libelle_t VARCHAR (30),
PRIMARY KEY (id_t)
);

Under PostgreSQL :

CREATE TABLE TypeLivre (

id_t SERIAL,
libelle_t VARCHAR (30),
PRIMARY KEY (id_t)
);

16