Chapitre III : Le Modèle Conceptuel des Données (MCD)

I- Concepts du MCD
I-1 Les propriétés
I-2 Les entités ou objets
I-3 Les relations ou associations
I-4 Les règles d’usage
I-5 Contrainte d’intégrité fonctionnelle

II- Etude de Cas: Construction pas à pas

II-1 Dictionnaire de données
II-2 Les dépendances fonctionnelles
II-3 Elaboration du MCD
 I- Concepts du MCD
Le Modèle Conceptuel des Données introduit la notion d’entités, de relations et
de propriétés. Nous allons commencer par voir certains aspects « théoriques »
avant de plonger dans la pratique.

Le MCD décrit de façon formelle les données utilisées par le système

d’information.
La représentation graphique, simple et accessible, permet à un non
informaticien de participer à son élaboration.

Les éléments de base constituant un modèle conceptuel des données sont :

 les propriétés ;

 les entités ;

 les relations.
2/2
 I-1 Les propriétés
Les propriétés sont les informations de base du système d’information.
Un client possède un numéro de client, un nom, un prénom, habite à une
adresse précise, etc. Ces informations élémentaires essentielles sont des
propriétés.
Les propriétés disposent d’un type. Elles peuvent être numériques,
représenter une date, leur longueur peut être aussi définie.
Les types ne sont pas décrits au niveau conceptuel

I-2 Les entités ou objets

Comme il est aisé de le constater, les
clients sont définis par certaines
propriétés (numéro, nom,
prénom…). Le fait de les regrouper
amène naturellement à créer une
entité Clients. Le symbolisme retenu
est le suivant :
3/3
I-2-a L’identifiant
Une de ces propriétés a un rôle bien précis, c’est l’identifiant nommé aussi la clé.

L’identifiant permet de connaître de façon sûre et unique l’ensemble des

propriétés qui participent à l’entité.
Il faut donc trouver, ou inventer, une propriété qui lorsque sa valeur est
connue permet la connaissance de l’ensemble des valeurs qui s’y rattachent
de façon formelle.
Ainsi, lorsque le numéro du client est connu, son nom, son prénom et toutes
les valeurs des autres propriétés qui s’y rattachent sont connues de façon
sûre et unique.

Au niveau du
formalisme, cette
propriété se souligne.

4/3
 I-3 Les relations ou associations
Nous avons vu que les entités regroupaient un ensemble d’informations
élémentaires. Les entités sont souvent liées entre elles.

Par exemple : Un client peut commander des articles.

Dans cette phrase, on distingue deux entités (clients et articles) et un

verbe (commander) qui indique un lien entre clients et articles.
Formalisons cette phrase avec Merise.

5/2
I-3-a Les cardinalités
Elles expriment le nombre de fois ou l’occurrence d’une entité participe aux
occurrences de la relation.
Dans notre exemple on peut se poser les questions suivantes :
−Combien de fois au minimum un client peut il commander un article ?
−Combien de fois au maximum un client peut il commander un article ?

À la première question, nous pouvons répondre qu’un client, pour être

client, doit commander au moins un article.
À la deuxième question, nous pouvons répondre qu’un client peut
commander plusieurs articles.
Voici comment symboliser cet état :

6/3
Il faut que nous nous posions les mêmes questions pour l’article :
−Combien de fois au minimum un article peut il être commandé par un client ?
−Combien de fois au maximum un article peut il être commandé par un client ?

Pour le minimum, nous pouvons l’interpréter de la façon suivante :

A-t-on des articles qui ne peuvent jamais être commandés ?
Si nous répondons oui dans ce cas la cardinalité minimale est 0.

Pour le maximum :
A-t-on des articles qui peuvent être commandés plusieurs fois ?
Nous pouvons espérer que oui, dans ce cas la cardinalité maximale sera n.

7/3
Définitions :
La cardinalité minimale (0 ou 1) exprime le nombre de fois minimum qu’une
occurrence d’une entité participe aux occurrences d’une relation.
La cardinalité maximale (1 ou n) exprime le nombre de fois maximal qu’une
occurrence d’une entité participe aux occurrences de la relation.

Remarque : Si le maximum est connu, il faut inscrire sa valeur.

Par exemple, si dans les règles de gestion le client n’a le droit de
commander qu’un maximum de 3 articles en tout et pour tout, dans ce
cas là les cardinalités s’exprimeront de cette façon : 1,3.

Autre exemple :
Modélisons le fait qu’une mère élève des enfants.
Nous avons deux entités Mères et Enfants et une relation élever

8/2
 Des cardinalités :
− Une mère peut élever un ou plusieurs enfants.
− Un enfant peut être élevé par une et une seule mère.

REMARQUE :

Bien sûr, tout est question d’interprétation. Au sein d’une équipe de

développement, il peut y avoir des divergences de point de vue. Pour les
cardinalités, il faut être le plus logique possible, se référer aux règles de gestion
édictées par le commanditaire de l’application et se rappeler la maxime suivante :
"Qui peut le plus peut le moins".

9/1
I-3-b Les relations porteuses

Définition :
Une relation est dite porteuse lorsqu’elle contient des propriétés.
Imaginons que l’on veuille connaître la quantité d’articles commandés par
clients, nous nous rendons compte qu’il faut utiliser une nouvelle propriété
Quantité. Cette nouvelle propriété dépend de clients, d’articles ou des deux ?

La bonne réponse est que Quantité dépend des deux entités.

10/3
 Si nous désirons connaître la date d’achat, il nous suffit de créer une entité
Date à la relation Commander.

Remarques: Notion de dimension :

− Une relation faisant intervenir deux entités est dite binaire ou de dimension 2.
− Une relation faisant intervenir trois entités est dite ternaire ou de dimension 3.

11/2
I-3-c Les relations réflexives

Définition :
Une relation réflexive est une relation d’une entité sur elle-même.

Par exemple, on désire modéliser le fait qu’un employé peut diriger d’autres
employés.

À la lecture de ce schéma, nous interprétons donc qu’un employé peut

diriger zéro ou plusieurs personnes et qu’un employé est dirigé par un et
un seul autre employé.

12/2
 I-4 Règles d’usages
 Toute entité doit comporter un identifiant.

 Toutes les propriétés de l’entité dépendent fonctionnellement de

l’identifiant.
C’est à dire que connaissant la valeur de l’identifiant, nous connaissons
de façon sûre et unique la valeur des propriétés associées.

 Le nom d’une propriété ne doit apparaître qu’une seule fois dans le

modèle conceptuel des données.

 Les propriétés résultantes d’un calcul ne doivent pas apparaître dans le

modèle conceptuel des données.

13/3
 Cas pratique :
Reprenons le graphe concernant le cas du camping vu au chapitre précédent
et réalisons le modèle conceptuel qui en découle.

Le MCD pas à pas :

Par rapport au graphe, nous pouvons remarquer trois sources de
dépendances fonctionnelles : CodeArticle , Date , NumCli

Chacune de ces sources peut représenter une entité : Articles, Date, Clients

14/2
 Renseignons maintenant les entités avec leurs propriétés respectives :

Traçons les relations :

Nous savons qu’une quantité d’articles est achetée par un client à une
date donnée. Nous voyons qu’il existe une relation entre les trois entités.

nous pouvons lire qu’au minimum un article est acheté dans une certaine
15/2
quantité, par au minimum un client à une date donnée.
I-5 Notion de contrainte d’intégrité fonctionnelle
Définition
Une contrainte d’intégrité fonctionnelle (ou CIF) est définie par le fait qu’une des
entités de l’association est complètement déterminée par la connaissance d’une
ou de plusieurs entités participant à cette même association.

Nous pouvons lire qu’une salle peut contenir zéro ou plusieurs ordinateurs et
qu’un ordinateur existe dans une et une seule salle. Dans le cas d’une
association binaire comme celleci, une contrainte d’intégrité fonctionnelle
existe à partir du moment ou une cardinalité de type 1,1 existe.

16
II- Conception d’un MCD pas à pas
Pas à pas, nous allons créer un Modèle Conceptuel des Données en partant d’un
cas fictif.
Un restaurateur, vous demande de lui réaliser un logiciel de gestion des
commandes de repas. Voici les indications qu’il vous donne :
Il souhaite pouvoir gérer certaines informations concernant ses employés : nom,
prénom, adresse complète, téléphone et diplômes.
Au niveau de la prise de commande, il souhaite savoir si elle porte sur le service de
midi ou celui du soir et à quelle date elle a été passée.
Pour certains calculs statistiques, il souhaite aussi savoir quelle table a passé la
commande et quel serveur l’a prise.
La carte du restaurant propose l’ensemble des plats d’entrées, principaux et desserts.
Les menus proposés sont un assemblage des plats à la carte.
Les boissons comme les sodas, les eaux minérales ou les cafés sont gérés de façon
simpliste juste par leur libellé et leur prix de vente.
Chaque serveur prenant une commande saisit l’ensemble des informations sur un
Pocket PC qui transmet la commande via Wifi sur un ordinateur central. 17
À l’aide de ces quelques informations basiques, essayons de réaliser le modèle
conceptuel Et commencons par un dictionnaire des données simplifié.

II-1 Le dictionnaire des données

Nom Format Longueur Type
E C
Numéro employé Num.
Nom employé Alphab. 30 X
Prénom employé Alphab. 30 X
Adresse employé Alphab. 40 X
Code Postal employé Alphanum. 5 X
Ville employé Alphab. 40 X
Téléphone employé Alphanum. 15 X
Diplômes des employés Alphab. 30 X
Numéro de la table Num. X
Capacité Num. X
18
 Nom Format Longueur Type
E C
Numéro de la boisson Num. X
Désignation de le boisson Alphab. 20 X
Prix de vente de la boisson Num. X
Numéro du menu Num. X
Libellé du menu Alphab. 30 X
Prix de vente du menu Num. X
Numéro du plat Num. X
Libellé du plat Alphab. 30 X
Prix de vente du plat Num. X
Numéro de type de plat Num.
Désignation du type de plat Alphab. 20 X
(entrée, plat
principal, dessert)
Type de service (midi ou soir) Alphab. 4 X
Date de prise de commande Date X
Numéro de la commande Num. X
19
 II-2 Les dépendances fonctionnelles

II-2-a Dépendances élémentaires

Numéro employé → (Nom employé, Prénom employé, Adresse employé,
Code Postal employé, Ville employé, Téléphone employé).

Numéro de la boisson → (Désignation de la boisson, Prix de vente de la boisson).

Numéro du menu → (Libellé du menu, Prix de vente du menu).

Numéro du plat → (Libellé du plat, Prix de vente du plat).

Numéro de type de plat → Désignation du type de plat.

Numéro de la table → Capacité.

20
II-2-b Dépendances isolées
− Diplômes des employés.
− Type de service (midi ou soir).
− Date de prise de commande.
− Numéro de la commande.

 Traitement des dépendances isolées

Pour les diplômes, deux possibilités s’offrent à nous :
− Soit nous notons seulement un diplôme par employé.
− Soit nous notons tous les diplômes d’un employé.
Dans le premier cas, la résolution du problème est simple :
Numéro employé → Diplôme.
Dans le deuxième cas, nous pouvons gérer la possibilité d’avoir soit un
diplôme soit plusieurs diplômes. Comme dit le proverbe : "Qui peut le
plus peut le moins".
Nous allons donc utiliser la deuxième alternative en ajoutant même une propriété
Date d’obtention :

(Numéro employé, diplôme) → Date d’obtention. 21

Pour la désignation du type de plat, nous pouvons être sûrs que lorsque l’on
connaît un numéro de plat on connaît de façon sûre et unique un type de plat.
Numéro du plat → Type de plat.
Nous pouvons ressentir que tout tourne autour d’un numéro de commande.
En fait, une commande est prise par un serveur, concerne une table, est
réalisée à une date donnée, sur un type de service et comprend des plats
et/ou des menus et/ou des boissons et comportera des quantités associées.

Numéro de la commande → Date de prise de commande.

Numéro de la commande → Type de service.

Numéro de la commande → Numéro employé.

Numéro de la commande → Numéro de la table.

(Numéro de la commande, Numéro de la boisson) → Quantité.

(Numéro de la commande, Numéro du plat) → Quantité.

(Numéro de la commande, Numéro du menu) → Quantité. 22

 II-3 Élaboration du Modèle Conceptuel des Données
Maintenant, considérons que nos dépendances fonctionnelles sont décrites et
commençons à générer pas à pas le Modèle Conceptuel des Données.

 Nous pouvons dire qu’un employé peut posséder zéro ou plusieurs diplômes
obtenus à une date précise, et qu’un diplôme peut être possédé par un ou
plusieurs employés. Par exemple le bac pro cuisine est un diplôme pouvant être
détenu par plusieurs employés.

23
 À un plat correspond un et un seul type de plat, c’est soit une entrée, soit
un plat de résistance, soit un dessert. À l’inverse pour une entrée il peut y
avoir un ou plusieurs plats différents.

 Nous voyons ici qu’un menu peut être constitué d’au minimum un plat et
d’au maximum plusieurs. Par contre, un plat peut ne pas faire partie d’un
menu.

24
 Nous pouvons considérer qu’un employé peut prendre zéro (le cuisinier par
exemple) ou plusieurs commandes. Par contre, une commande est prise par un
et un seul employé.

25
Une commande concerne une et une seule table et une table peut passer
une ou plusieurs commandes.

26
 Une commande est passée à une et une seule date et à une date donnée il
peut y avoir une ou plusieurs commandes passées.

 Une commande dépend d’un seul service (midi ou soir) et durant un

service une ou plusieurs commandes peuvent être passées.

27
 Une commande peut contenir zéro ou plusieurs boissons dans des quantités
différentes et une boisson peut faire partie de zéro ou de plusieurs commandes
dans des quantités différentes.

28
 Une commande peut contenir zéro ou plusieurs menus dans des quantités
différentes et un menu peut faire partie de zéro ou de plusieurs commandes
dans des quantités différentes.

 Une commande peut contenir zéro ou plusieurs plats dans des quantités
différentes et un plat peut faire partie de zéro ou de plusieurs commandes dans
des quantités différentes.

29
Voici la représentation globale du modèle conceptuel.

30