Analyse Modèle Conceptuel des Données fascicule n°4

SOMMAIRE

LE MODÈLE CONCEPTUEL DES DONNÉES............................................................2

I) CONCEPTS DE BASE..................................................................................................................................2
I.1) La propriété..............................................................................................................................................2
Caractéristiques :........................................................................................................................................2
Les propriétés dans le mcd.........................................................................................................................3
I.2) L’objet......................................................................................................................................................4
Caractéristiques..........................................................................................................................................4
Représentation............................................................................................................................................4
I.3) La relation.................................................................................................................................................5
Caractéristiques..........................................................................................................................................5
Représentation............................................................................................................................................5
Exemples de relations................................................................................................................................6
I.4) Les cardinalités.........................................................................................................................................9
Caractéristiques..........................................................................................................................................9
Représentation............................................................................................................................................9
Les différents cas envisageables................................................................................................................9

II) LES RELATIONS PARTICULIERES....................................................................................................10

II.1) La relation réflexive..............................................................................................................................10
II.2) La contrainte d’intégrité fonctionnelle.................................................................................................12

III) COHERENCE ET CHOIX DE MODELISATION..............................................................................15

III.1) La cohérence des cardinalités..............................................................................................................15
III.2) Le choix entre propriété, objet et relation...........................................................................................15

IV) DEMARCHE PRATIQUE D’ELABORATION DU MCD..................................................................17

V) LA VERIFICATION DU MODELE........................................................................................................18

VI) LES DOCUMENTS DU MCD.................................................................................................................22

CPN Page 1 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

Le modèle conceptuel des données

Le modèle conceptuel des données est la représentation de l’ensemble des données

mémorisables sans tenir compte, ni des aspects techniques, ni des aspects organisationnels, ni
des aspects dynamiques. On représente ici le ‘QUOI’ du système, seules les règles de gestion
(contraintes) sont prises en compte. Inversement, l’utilisation future des données n’est
aucunement prise en considération pour l’élaboration de ce modèle.
L’objectif du MCD est donc de modéliser les données élémentaires inventoriées dans le
dictionnaire des données en faisant apparaître les relations qui les unissent.

Le MCD est donc la représentation structurée des données exprimant, avec

un haut niveau d’invariance, l’activité d’un organisme en termes d’objets et
de relations.

Cette modélisation se fait en utilisant le formalisme entité-relation normalisé en 1982 par

l’ISO et enrichi depuis.
Ce formalisme repose sur quatre concepts de base :
- la propriété,
- l’objet,
- la relation,
- les cardinalités.

I) CONCEPTS DE BASE

I.1) La propriété

Une propriété est la plus petite quantité d’information manipulée par le

Système d’Information.

Elle correspond à la rubrique évoquée dans le cadre du recueil de l’existant. Elle est
encore appelée ‘caractéristique’ ou ‘attribut’.

CARACTÉRISTIQUES :
- elle est définie par son nom,
- elle a une signification pour l’organisation,
- elle possède un domaine de valeurs possibles.

Exemple :

CPN Page 2 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

Nom  Nb_pieces
Signification  Nombre de pièces du bâtiment
Domaine des valeurs  De 1 à 100

Le degré d’atomicité de la propriété est fonction des choix de gestion de l’organisation.

En effet, si l’on considère les informations concernant l’adresse d’un client, on peut gérer
cette adresse différemment en fonction des règles de gestion que l’on choisit.

Exemple :
On gère des clients dont les adresses sont de la forme :
- 128 avenue CODD 75015 Paris
On peut considérer cette adresse comme une seule propriété. Elle sera donc gérée comme
un tout indissociable, on pourra facilement y accéder.
On peut cependant, si on s’intéresse dans le système d’information aux communes de
résidence des clients et leurs codes postaux, décomposer cette donnée (l’adresse) en plusieurs
propriétés plus petites.
Les informations concernant les adresses des clients pourront donc être décomposées en
trois propriétés distinctes:
- N_rue pour le numéro et la rue 128 avenue CODD
- Code_postal pour le code postal de la ville 75015
- Ville pour le nom de la ville PARIS

LES PROPRIÉTÉS DANS LE MCD

Toutes les propriétés du dictionnaire des données ne se trouvent pas dans le MCD.
Exemple :
Considérons un prix total qui est le résultat de la multiplication d’un prix unitaire par une
quantité. La connaissance de ces deux données est donc nécessaire et suffisante pour obtenir
le prix total. En première approche, il n’est donc pas nécessaire de conserver ce prix puisque,
si l’on souhaite l’obtenir, le Système d’Information Informatisé saura le calculer et nous le
restituer.

Les données calculées ne figurent donc pas parmi les propriétés du MCD.

Il est cependant possible que certaines d’entre elles soient ajoutées dans la suite du
processus de conception en vue d’optimiser la solution proposée (système futur).

Le principe de non-redondance appliqué lors de l’élaboration du MCD,

interdit de faire figurer une propriété plus d’une fois dans le modèle.

Le regroupement des propriétés donne naissance à un objet.

CPN Page 3 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

I.2) L’objet

Un objet est un ensemble de propriétés représentant un intérêt pour le

Système d’Information

CARACTÉRISTIQUES
- Il est défini par un nom.
- Il peut avoir plusieurs occurrences.
- Il a une existence propre.
- Il traduit une préoccupation de gestion.
- Il est identifiable. Pour cela il possède une propriété particulière qui permet sa
détermination sans possibilité d’erreur : son identifiant.
- Cet identifiant ne peut déterminer qu’une occurrence d’objet et une seule.
- Une propriété qualifie un objet et un seul, ce qui revient à dire qu’on ne peut trouver
un même nom de propriété dans deux objets différents.
- Une propriété d’un objet dépend de l’identifiant de l’objet et de lui seul.
- A une occurrence d’un objet correspond une valeur et une seule d’une propriété
associée.
Ces deux dernières caractéristiques feront l’objet d’un développement dans la suite du
cours.

REPRÉSENTATION
Exemple : un objet PRODUIT est identifié par un numéro de produit (num-prod) et décrit
par les propriétés :
- nom-prod (nom du produit),
- poids-prod (poids du produit),
- coul-prod (couleur du produit).

PRODUIT Nom de l’objet

Identifiant num-prod
nom-prod Propriétés
poids-prod
coul-prod

Dans le modèle, l’identifiant sera placé en tête des propriétés décrivant l’objet et il sera
souligné (convention).
Un objet est donc un ensemble d’éléments ayant des caractéristiques communes.
Une occurrence d’un objet est un élément particulier appartenant à cet ensemble.

CPN Page 4 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

Exemple : deux occurrences de l’objet PRODUIT.

1754 1945
CIMENT PLATRE
50 25
GRIS BLANC

I.3) La relation

La relation est une association sur une collection de ‘n’ objets.

Elle formalise un lien logique de dépendance entre ces objets.

CARACTÉRISTIQUES
- Contrairement à l’objet, la relation n’a pas d’existence propre ; son existence est
conditionnée par celle des objets qu’elle associe. Elle n’a donc pas d’identifiant
propre, et ce dernier est constitué par la concaténation des identifiants des objets qui
lui sont associés.
- Le nombre d’objets que la relation associe est appelé dimension de la relation. Cette
dimension n’est pas limitée. On dit qu’une relation peut être binaire ou n-aire.
- Une relation peut être porteuse ou non de propriétés. Si elle est porteuse de
propriétés, celles-ci dépendent des identifiants des différents objets qui lui sont
associés.
- Une occurrence de la relation représente la réalisation d’une association de tous les
identifiants des objets qui participent à cette relation, et des propriétés éventuelles
portées par la relation.

REPRÉSENTATION
Dans le modèle entité-relation, une relation se symbolise par une ellipse entourant son
nom.
La relation est en général la traduction de verbes du langage de l’organisation.
Exemples : - un fournisseur vend des produits,
- des produits sont vendus par un fournisseur.

Lien vers l’objet VENDRE Lien vers l’objet

- Afin de ne pas imposer un sens de lecture à la relation, on emploie en général des

verbes à l’infinitif. On peut éventuellement utiliser un substantif issu du verbe.
- Il est déconseillé de recourir à une numérotation des relations qui a pour effet de
rendre le modèle particulièrement difficile à interpréter.

CPN Page 5 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

EXEMPLES DE RELATIONS

a) Relation non porteuse de propriétés

FOURNISSEUR PRODUIT
num-four num-prod
VENDRE nom-prod
nom-four
poids-prod
tel-four coul-prod

Relation
Objet Objet
De cette relation, on peut en extraire les occurrences : diagramme d’occurrences.

1945
PLATRE
124
25
DUPONT
99.97.34.59 BLANC

1754
CIMENT
50

145 GRIS

MARTIN
99.56.32.32
179
SABLE
100
GRIS

- L’association entre l’objet FOURNISSEUR et l’objet PRODUIT peut être considérée

comme un prédicat qui prend la valeur VRAI ou FAUX.
- Chaque fois que le prédicat prend la valeur VRAI, on est en présence d’une
occurrence de la relation.
- L’objet FOURNISSEUR possède deux occurrences correspondant aux identifiants
124 et 145.
- L’objet PRODUIT possède trois occurrences correspondant aux identifiants 1945,
1754 et 179.

On peut donc avoir en théorie 2 fois 3 soit 6 associations (produit cartésien des
ensembles). Le prédicat représenté par la relation VENDRE ne prend la valeur VRAI que
dans quatre cas sur les six possibles.

Le Fournisseur 124 vend le Produit 1945 ⇒ VRAI

CPN Page 6 jj/10/OO
Analyse Modèle Conceptuel des Données fascicule n°4

Le Fournisseur 124 vend le Produit 1754 ⇒ VRAI

Le Fournisseur 124 vend le Produit 179 ⇒ FAUX
Le Fournisseur 145 vend le Produit 1945 ⇒ FAUX
Le Fournisseur 145 vend le Produit 1754 ⇒ VRAI
Le Fournisseur 145 vend le Produit 179 ⇒ VRAI
Il existe donc bien quatre occurrences de la relation VENDRE.

Le diagramme des occurrences est un peu lourd à manier. Il ne faut cependant pas hésiter
à y avoir recours pour contrôler une association qui n’apparaît pas évidente.

b) Relation porteuse de propriétés

Nous avons vu que certaines propriétés peuvent être portées par la relation dès lors que
ces propriétés dépendent des identifiants des objets associés par la relation.
Considérons l’exemple précédent et les règles de gestion suivantes :
- des fournisseurs différents peuvent vendre un même produit à des prix différents,
- on désire mémoriser le prix de vente du produit ou les différents prix de vente si le
produit est vendu par plusieurs fournisseurs.
Soient les fournisseurs DUPONT et MARTIN qui vendent du CIMENT respectivement à
25 et 28 F.
Si l’on veut ajouter ce prix du produit (pri-prod) dans les propriétés à gérer, on constate
que ce prix dépend bien à la fois du produit mais également du fournisseur.
Cette propriété ‘pri-prod’ sera donc portée par la relation.
FOURNISSEUR PRODUIT
num-four num-prod
VENDRE
nom-four nom-prod
pri-prod poids-prod
tel-four coul-prod

Lorsque la relation est porteuse de propriétés, l’ellipse est séparée en deux par un trait
horizontal et les propriétés sont indiquées sous ce trait.
1945
Si l’on considère
124 de plus que : 32
PLÂTRE
25
DUPONT
99.97.34.59 25 BLANC
Le Fournisseur DUPONT vend du PLÂTRE à 32 F
Le Fournisseur MARTIN vend du SABLE à 15 F
1754
Le diagramme des occurrences devient alors :
CIMENT
50

145 GRIS
28
MARTIN
99.56.32.32 15
CPN Page 7 jj/10/OO
179
SABLE
100
GRIS
Analyse Modèle Conceptuel des Données fascicule n°4

c) Relations partageant les mêmes objets

ORGANISER
PERSONNE JEU
num-pers num-jeu
nom-pers nom-jeu
tel-pers JOUER

Une personne peut organiser des jeux et participer éventuellement à certains d’entre eux,
voire à d’autres jeux organisés par d’autres personnes.

CPN Page 8 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

I.4) Les cardinalités

Les cardinalités d’une relation représentent les nombres minimim et

maximum d’occurrences de la relation pour une occurrence de l’objet
associé.

CARACTÉRISTIQUES
Quatre quantifications différentes sont utilisées.

(1,n) - A 1’occurrence de l’objet concerné correspond de 1 à n occurrences de la

relation (n>=2).
(1,1) - A 1’occurrence de l’objet concerné correspond 1 et 1 seule occurrence de la
relation.
Dans les deux cas précédemment cités, l’objet ne peut exister sans participer à la relation
puisqu’il y aura toujours au minimum une occurrence de la relation pour chaque occurrence
de l’objet.
(0,n) - A 1’occurrence de l’objet concerné correspond de 0 à n occurrences de la
relation (n>=2).
(0,1) - A 1’occurrence de l’objet concerné correspond 0 ou 1 occurrence de la
relation.
Dans ces deux derniers cas, une occurrence de l’objet peut exister sans pour autant
participer à la relation.

REPRÉSENTATION
Les cardinalités minimales et maximales se placent, souvent entre parenthèses, à
proximité de l’objet et du lien concernés.

Cardinalités
FOURNISSEUR PRODUIT
minimales
num-four num-prod
(1,n) (1,1)
VENDRE nom-prod
nom-four
poids-prod
tel-four coul-prod
Cardinalités
maximales

LES DIFFÉRENTS CAS ENVISAGEABLES

FOURNISSEUR PRODUIT
A B
num-four num-prod
(0,n) (1,n)
VENDRE nom-prod
nom-four (1,1)
(0,1) poids-prod
tel-four coul-prod
C D

CPN Page 9 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

A) Un fournisseur vend de 0 à n produits, ce qui signifie que l’on peut gérer des
fournisseurs même s’ils ne nous vendent pas de produits. Autrement dit, une
occurrence de fournisseur peut ne pas participer à la relation VENDRE mais peut
aussi y participer plusieurs fois.
B) Un produit peut être vendu par 1 à n fournisseurs, ce qui signifie que l’on s’autorise
à acheter un même produit à plusieurs fournisseurs différents. Autrement dit, un
produit participe au moins une fois à la relation VENDRE.
C) Un fournisseur vend de 0 à 1 produit. Même si cette situation est très peu
vraisemblable, on peut quand même envisager sa modélisation.
D) Un produit est vendu par un fournisseur et un seul, ce qui signifie que l’on
spécialise les approvisionnements en sélectionnant un seul fournisseur par produit.

On constate que les différentes cardinalités choisies dépendent des règles de gestion en
vigueur dans l’organisme.

II) LES RELATIONS PARTICULIERES

II.1) La relation réflexive

Une relation réflexive est une relation qui relie une occurrence d’un objet à
une autre occurrence du même objet.

Exemple n°1 :
Une personne commande de 0 à n autres personnes.

(0,n) Commande
PERSONNE
num-pers COMMANDER
nom-pers
tel-pers
(0,1) Commandée

Une personne est commandée par 0 ou 1 personne, ce qui signifie qu’une personne
donnée a au plus un chef direct, mais le PDG n’a pas de chef (cardinalité minimum = 0).
Cette relation indique une hiérarchie, elle impose donc un sens de lecture, il est donc
nécessaire de préciser le sens de lecture sur les liens.

CPN Page 10 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

Exemple n°2 :
Soit la relation PARENT interprétée dans le sens père ou mère de :

(0,n) Parent de
PERSONNE
num-pers PARENT
nom-pers
prénom-pers
(0,2) Enfant de

Dans ce cas précis, on sait que le nombre de parents biologiques ne peut être qu’au plus
de deux, on peut donc tolérer la cardinalité (0,2) sur le lien bien que celle-ci ne fasse pas
partie des quatre cardinalités généralement utilisées.

Le diagramme des occurrences de cette relation peut être représenté sous la forme
suivante :

num-pers nom-pers prénom-pers num-pers nom-pers prénom-pers

1 Dupont Pierre 3 Dupont Paul

2 Dupont Jeanne 4 Martin Louise

4 Martin Louise 6 Martin René

8 Martin Albert 7 Martin Julie

Mr et Mme Pierre et Jeanne Dupont sont les parents de Paul Dupont et de Martin Louise
(qui est gérée par son nom d’épouse).
Madame Louise Martin a deux enfants René et Julie. Son époux décédé n’est pas géré.

CPN Page 11 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

Exemple n°3 :
Une relation peut être réflexive sur un objet de la collection qu’elle relie et pas sur un
autre.

PERSONNE (0,n) époux DATE

num-pers (0,n)
nom-pers
MARIER JJ/MM/AA
tel-pers
(0,n) épouse

Une personne peut se marier plusieurs fois à des dates différentes. Dans l’absolu, un même
couple de personnes peut se marier, divorcer et se remarier.

Exemple n°4 :
Une relation peut être doublement réflexive pour exprimer une hiérarchie dans le temps.

(0,n) (0,n) DATE

PERSONNE Commande date début
num-pers
COMMANDER
nom-pers JJ/MM/AA
tel-pers date fin
(0,n) Commandée (0,n)

Une personne peut en commander plusieurs autres entre deux dates précises.

II.2) La contrainte d’intégrité fonctionnelle

Une contrainte d’intégrité fonctionnelle ou CIF traduit la détermination complète d’un
objet à partir d’un autre.

La CIF est le cas particulier de relation binaire, non porteuse de propriété, et

ayant sur une des deux pattes une cardinalité (1,1)

FOURNISSEUR REPRESENTANT
num-four (0,n) (1,1) num-rep
EMPLOYER nom-rep
nom-four
cat-rep
sect-rep
tel-four

Un représentant travaille pour un et un seul fournisseur.

Cette relation est donc une CIF et devient :

FOURNISSEUR REPRESENTANT
CPN Page 12 jj/10/OO
num-four (0,n) (1,1) num-rep
CIF nom-rep
nom-four
cat-rep
sect-rep
tel-four
Analyse Modèle Conceptuel des Données fascicule n°4

Deux CIF particulières peuvent être signalées.

- La contrainte d’intégrité fonctionnelle bijective (CIFB)

FACTURE RÈGLEMENT
num-fac (1,1) (1,1) num-regl
CIF date-regl
date-fac
mode-regl
montant fac

Toutes les factures font systématiquement l’objet d’un règlement. Il n’existe donc pas de
facture sans son règlement associé.
Ce cas particulier implique de réétudier en détail les règles de gestion de façon à contrôler
que les cardinalités sont bien exactes et que cet ensemble de propriétés ne forme pas en fait
qu’un seul et même objet.

- La contrainte d’intégrité fonctionnelle bijective facultative

FACTURE RÈGLEMENT
num-fac (0,1) (1,1) num-regl
CIF date-regl
date-fac
mode-regl
montant fac

Dans ce cas, certaines factures peuvent ne pas encore avoir été réglées, par contre chaque
règlement correspond bien à une facture.

Les contraintes d’intégrité fonctionnelle sont intéressantes car elles permettent de

simplifier certaines relations n-aires.

Exemple n°1 :

CPN Page 13 jj/10/OO

 MATIÈRE
num-mat
Analyse Modèle Conceptuel des Données fascicule n°4
nom-mat

(0,n) STAGE
PROFESSEUR
num-prof num-stag
(1,n) (1,n)
ENSEIGNER niv-stag
nom-prof
vol-stag

Etudions les différentes cardinalités de la relation ternaire ENSEIGNER de l’exemple

n°1.

PROFESSEUR (1,n)
La cardinalité minimale indique que le professeur enseigne au moins une matière à un
stage (on ne gère donc pas d’enseignant qui n’enseigne pas).
La cardinalité maximale indique qu’un professeur peut enseigner à plusieurs stages et/ou
plusieurs matières.
MATIÈRE (0,n)
La cardinalité minimale indique qu’une matière peut ne faire l’objet d’aucun
enseignement.
La cardinalité maximale indique qu’une matière peut être enseignée par plusieurs
professeurs et/ou à plusieurs stages.
STAGE (1,n)
La cardinalité minimale indique qu’un stage bénéficie au minimum de l’enseignement
d’une matière par un professeur.
La cardinalité maximale indique qu’un stage bénéficie de l’enseignement de plusieurs
matières et/ou de plusieurs professeurs.
Un stage peut donc avoir une seule matière enseignée par deux ou trois professeurs.

Soit la règle de gestion suivante : un professeur enseigne une matière et une seule.

Une occurrence de l’objet PROFESSEUR détermine bien sans ambiguïté une occurrence
de l’objet MATIÈRE. Il existe donc une contrainte d’intégrité fonctionnelle entre l’objet
MATIÈRE et l’objet PROFESSEUR.

L’association de MATIÈRE à la relation ENSEIGNER n’est donc plus nécessaire. En

effet, si l’on sait qui enseigne, on saura par voie de conséquence ce qui est enseigné puisque
un professeur n’enseigne qu’une matière et une seule.

le modèle devient donc :

MATIÈRE

(0,n) num-mat
CIF nom-mat

(1,1)
CPN PROFESSEUR Page 14 STAGE jj/10/OO
num-prof (1,n)
(1,n) num-stag
ENSEIGNER
nom-prof niv-stag
vol-stag
Analyse Modèle Conceptuel des Données fascicule n°4

La relation ENSEIGNER traduit donc maintenant avec précision les règles de gestion
suivantes :
- un professeur enseigne à un ou plusieurs stages,
- un stage a un ou plusieurs enseignants,
- un professeur n’enseigne qu’une matière.
On est toujours capable de déterminer la matière enseignée pour un stage.

III) COHERENCE ET CHOIX DE MODELISATION

III.1) La cohérence des cardinalités

CONTRACT-ASS-VH

(1,1) num-cont
SOUSCRIRE caract-cont

(1,n)
CLIENT VÉHICULE

num-cli (0,n) (1,1) num-stag

POSSÈDER
nom-cli niv-stag
vol-stag

Un client possède des véhicules pour lesquels il souscrit des contrats d’assurance.
Objet CLIENT :
Pour une occurrence de l’objet CLIENT, il y a au moins une occurrence de la relation
SOUSCRIRE, ce qui signifie que chaque client géré a au moins souscrit un contrat
d’assurance voiture.
Pour une occurrence de l’objet CLIENT, il peut ne pas y avoir d’occurrence de la relation
POSSEDER, ce qui signifie qu’un client peut ne pas avoir de voiture.
Il y a donc une incohérence entre ces deux cardinalités.
Il faut que ces deux cardinalités soient identiques (0,N) ou (1,N) en fonction des règles de
gestion.

III.2) Le choix entre propriété, objet et relation

Exemples de gestion de date :
CPN Page 15 jj/10/OO
Analyse Modèle Conceptuel des Données fascicule n°4

Une date peut être gérée comme toute autre propriété, dès lors qu’elle ne fait pas
référence à une notion d’historique.

PERSONNE

num-pers
Une date de naissance représente une propriété de
nom-pers
l’objet personne
date-nais-pers

Soit la gestion d’une partie des informations d’un vidéoclub :

K7
CLIENT
code-k7 (0,n) EMPRUNTER (0,n)
num-cli
Titre-k7 Date-emp
nom-cli
theme-k7
adr-cli

Avec ce modèle, à une association particulière entre un client et une K7, on ne peut
mémoriser qu’une date d’emprunt (Date-emp).
Ce qui fait que, si un client emprunte plusieurs fois la même K7, on ne peut garder que la
dernière date d’emprunt (les autres dates, écrasées à chaque mise à jour, sont définitivement
perdues). On parle dans ce cas de dynamique partielle (les différents états du modèle ne sont
pas conservés).
Pour garder une trace de ces dates, le modèle peut être modifié en créant un objet
EMPRUNT.
K7
EMPRUNT
code-k7 (0,n) (1,n)
CONCERNER num-emp
Titre-k7 date-emp
theme-k7

(1,1)
CLIENT
num-cli (0,n)
CIF
nom-cli
adr-cli

Ce modèle est bien adapté pour gérer le cas où une même K7 a été emprunté plusieurs
fois par le même client, mais il y a création d’une propriété num-emp, ce qui ne correspond
peut-être pas aux règles de gestion de l’organisme.

On peut également envisager de créer un objet DATE (c’est généralement la solution

employée lorsque l’on souhaite traiter des notions d’historique).
K7 CLIENT
code-k7 (0,n) (0,n) num-cli
CONCERNER
Titre-k7 nom-cli
theme-k7 adr-cli
CPN Page 16 jj/10/OO
(0,n)
DATE
date
Analyse Modèle Conceptuel des Données fascicule n°4

On parle dans ce cas de dynamique totale (les différents états du modèle sont
conservés).

IV) DEMARCHE PRATIQUE D’ELABORATION DU MCD

① Recenser les données.

Le MCD repose sur le dictionnaire des données (du système à modéliser) élaboré lors du
recueil de l’existant ainsi que sur les règles de gestion qui lui sont associées.
Dans un premier temps les données calculées sont écartées de la modélisation.

② Repérer les identifiants existants et dégager les objets naturels.

Parmi les propriétés constituant un objet, l’une d’entre elles au moins ou un groupe de
plusieurs d’entre elles, doit permettre de caractériser chacune des occurrences de l’objet de
façon unique. Cette ou ces propriétés constituent l’identifiant de l’objet.
Afin d’éviter d’avoir à énoncer plusieurs propriétés pour définir une occurrence de
l’objet, il peut-être utile de créer un identifiant qui ne figurait pas dans les propriétés initiales.
Exemples : numéro de bâtiment, de livre, de produit etc.

③ Rattacher à ces objets les propriétés en dépendance fonctionnelle

avec leur identifiant.
Les objets obtenus doivent avoir une cohérence interne et une indépendance les uns vis-à-
vis des autres.

④ Créer les relations qui unissent les objets.

Ces relations sont créées à partir des règles de gestion recensées.

⑤ Placer les propriétés dépendant de plusieurs objets dans les relations

qui les associent.
Si une propriété ne dépend pas uniquement de l’identifiant d’un objet c’est qu’elle
dépend des identifiants de plusieurs objets et donc qu’elle se trouve dans la relation qui
associe ces objets.

⑥ Etudier les propriétés restantes afin de les introduire dans des

relations.
Les propriétés restantes n’ont pas pu être intégrées dans des objets. C’est qu’elles
appartiennent certainement à des relations. Elles vont donc aider à trouver ces relations.

CPN Page 17 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

⑦ Déterminer les cardinalités de chaque couple objet-relation

Ces cardinalités, là encore, sont directement issues des règles de gestion recensées.

⑧ Simplifier le modèle à l’aide des CIF.

⑨ Vérifier le modèle.

V) LA VERIFICATION DU MODELE
L’application systématique des règles de vérification permet de s’assurer de la conformité
du modèle élaboré.

Règle n°1 : Atomicité des propriétés

Toute propriété doit être élémentaire, c’est-à-dire non décomposable.

Règle n° 2 : Unicité des propriétés

Une propriété ne peut qualifier qu’un seul objet ou une seule relation.

FOURNISSEUR PRODUIT
n°-insee-four (0,n) (1,1) num-prod
VENDRE
nom-four nom-prod
tel-four caract-prod
NON nom-four

Règle n°3 : Identifiants et dépendances fonctionnelles

Chaque objet doit posséder un identifiant et un seul. Les propriétés qui caractérisent un
objet doivent dépendre exclusivement de l’identifiant de cet objet.
Si une propriété dépend de plusieurs identifiants, elles doit être placée dans la relation qui
associé les objets de ces identifiants.

FOURNISSEUR PRODUIT
n°-insee-four (0,n) (1,1) num-prod
nom-four VENDRE nom-prod
prix-prod
Dans le cas ci-dessus, le prix du produit est lié au produit. A un produit particulier
correspond un et un seul prix.

FOURNISSEUR PRODUIT
VENDRE (1,1)
n°-insee-four (0,n) Prix-prod num-prod
nom-four nom-prod

CPN Page 18 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

Dans le cas ci-dessus, le prix du produit dépend à la fois du produit et du fournisseur. A

un même produit peut correspondre plusieurs prix.

Règles n°4 : Unicité de l’objet dans une relation

A une occurrence d’une relation, il ne doit exister qu’une occurrence de chacun des objets
participant à la relation.
Seule exception : la relation réflexive.

FOURNISSEUR PRODUIT
n°-insee-four (0,n) VENDRE (0,n) num-prod
nom-four qté-prod nom-prod
tel-four caract-prod

DUPOND 50 CIMENT
MARTIN 25 PLATRE NON
SABLE

DUPOND 50 CIMENT

MARTIN 25 PLATRE OUI

25 SABLE

CPN Page 19 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

Règle n°5 : Non option

La participation d’un objet à une relation ne peut pas être optionnelle.
Pour chaque occurrence d’une relation, il doit obligatoirement exister une valeur et une
seule des identifiants des objets participant à la relation.

MATIERE
num-mat

(0,n) STAGE
PROFESSEUR
num-stag
num-prof (0,n) (0,n)
ENSEIGNER
nbre-heures

num-prof num-mat num-stag nbre-heures

1 1 1 50
2 2 3 100
3 3 1 20
5 4 50

Il ne peut pas ne pas y avoir de professeur pour une matière enseignée à un stage. Même
si à un moment donné, on sait que l’on doit enseigner 50 heures de la matière n° 5 au stage
n° 4 et que l’on ne sait pas encore qui va le faire.
Il faut donc changer le modèle.

MATIERE
(0,n) CONCERNER
num-mat
nbre-heures
(0,n)
(0,n) STAGE
PROFESSEUR
(0,n) (0,n) num-stag
num-prof
ENSEIGNER

CPN Page 20 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

Règle n°6 : Imbrication d’objets.

Si une propriété dépend de l’identifiant de l’objet qui la porte mais également d’une autre
propriété de cet objet, cela signifie que l’on est en présence d’un objet imbriqué. Il faut alors
l’extraire.

Exemple : Des représentants appartiennent à des sociétés dont on souhaite mémoriser le

numéro de SIRET et le chiffre d’affaires.

REPRESENTANT
num-rep
nom-rep
tel-rep
nom-société
siret-société
chi-aff

Toutes les propriétés non clé dépendent de la clé, mais il existe également les
dépendances fonctionnelles suivantes :

siret-société → nom-société
siret-société → chi-aff

Il existe donc un objet imbriqué.

REPRESENTANT SOCIETE
num-rep (1,1) (1,n) siret-société
nom-rep CIF nom-société
tel-rep chi-aff

Règle n°7 : Unicité de valeur

Pour une occurrence d’un objet, chaque propriété de cet objet ne peut avoir qu’une valeur
et une seule (sinon il faut créer un nouvel objet).

CPN Page 21 jj/10/OO

Analyse Modèle Conceptuel des Données fascicule n°4

PERSONNE
num-pers
nom-pers
prénom-pers
num-véhicule

Si l’on souhaite pouvoir gérer plusieurs véhicules par personne, il faut créer un nouvel
objet.

PERSONNE VÉHICULE
num-pers (1,n) (1,1) num-véhicule
POSSEDER
nom-pers
prénom-pers

VI) LES DOCUMENTS DU MCD

Les documents à prévoir à l’issue du MCD sont de deux types.

Les documents obligatoires :

- le dictionnaire des données mis à jour,
- le Modèle Conceptuel des Données (brut).

Les documents facultatifs :

- les fiches individuelles de description des données,
- les fiches descriptives des objets,
- les fiches descriptives des relations,
- le récapitulatif des objets et des relations.

CPN Page 22 jj/10/OO