INGENIERIE DES SYSTEMES

D’INFORMATION (ISI) /MERISE

TABLE DES MATIERES

CHAPITRE I : SYSTEMES D’INFORMATION ............................................................................................... 3

1. Notion de système........................................................................................................................... 3

2. Notion d’Information :..................................................................................................................... 4

3. Notion de système d’information (SI) d’une organisation : ............................................................ 4

4. Système d’information automatisable ............................................................................................ 6

5. Les différentes méthodes de conception des systèmes d’information. ......................................... 7

CHAPITRE 2 : PRESENTATION DE MERISE................................................................................................ 9

1. Principes généraux : ........................................................................................................................ 9

2. les 3 composantes de Merise ........................................................................................................ 10

CHAPITRE 3 : DIAGRAMME DES FLUX ................................................................................................... 13

1. Domaine d’activité et activité d’une entreprise ............................................................................ 13

2. Flux ................................................................................................................................................ 13

3. Champ d’étude .............................................................................................................................. 13

4. Acteur : .......................................................................................................................................... 14

CHAPITRE 4 : ELABORATION DU MCD ................................................................................................... 16

1. Les concepts de base : ................................................................................................................... 16

2. Construction du MCD .................................................................................................................... 21

CHAPITRE 5 : LE MODELE RELATIONNEL DE DONNEES (MRD).............................................................. 28

1. Introduction : ................................................................................................................................. 28

2. Règles de passage du MCD au MRD (ou MLDR) ............................................................................ 28

2
 CHAPITRE I : SYSTEMES D’INFORMATION

1. Notion de système
Définition1 : Un système est un tout constitué d’éléments unis par des
relations, leurs propriétés et les valeurs que peuvent prendre ces dernières
ainsi que son activité et l’organisation qui en découle.
Ex. : L’entreprise peut être vue comme un système composé d’éléments tels
que des « employés », des « services », des « produits », etc. Les propriétés
décrivant ces éléments peuvent être « le matricule de l’employé », son
« nom », la « référence » du produit, sa « désignation » etc. Entre ces
éléments, on trouve des relations, telle la relation « est rattaché » entre un
employé et son service, la relation « est stocké » entre un produit et son
dépôt de stockage. Les propriétés de ces relations seront du type « date
d’entrée dans le services », « quantité stockée »…
Définition2 : Un système est un ensemble d’éléments matériels ou
immatériels (hommes, machines, méthodes, règles, etc.) en interaction
transformant par un processus des éléments (les entrées) en d’autres
éléments (les sorties).
Ex. : une chaudière transforme, par combustion, du charbon en chaleur.
On obtiendra plus au mois de chaleur selon les réglages qu’on effectuera sur
la chaudière et plus au moins longtemps selon la quantité de charbon.
L’opérateur qui effectue les réglages et qui contrôle le flux de charbon en
entrée constitue un système de pilotage qui par ses commandes au système
physique (à la chaudière) cherche à satisfaire un objectif (tel niveau de
chaleur).
Nous n’envisageons ici que des systèmes constitués par des organisations et
fonctionnant en vue de la réalisation de certains objectifs
Un tel système physique ou système opérant transforme un flux physique
d’entrées (matières premières, flux financiers) en un flux physique de
sorties (produits finis, flux financier).

Entrées Sorties
Système opérant

Exemple :
Règlements à fournisseurs Règlements des clients

Flux financiers
Système opérant (SO)

Produits achetés Produits vendus

Par ailleurs un système de gestion ou système de pilotage procède au
pilotage (à la régulation et au contrôle) du système opérant en décidant du
comportement de celui-ci en fonction des objectifs fixés.
Ce système se compose par exemple de la Direction financière de la
direction commerciale de la direction de la production etc. Il reçoit du SO
des informations sur l’état du système (dont certaines, les variables
essentielles, lui permettant de mesurer l’écart avec les objectifs) et réagit
par des décisions (commandes) sur le processus du système opérant (SO)
par régulation des flux (fixation des cadences de production, décision de
lancer une nouvelle gamme de produits ou de modifier le prix de vente de
tel article, etc.)

2. Notion d’Information :
- L’information est l’objet à la base de la communication des
connaissances
- L’information est un renseignement qui améliore notre connaissance
sur un sujet quelconque
(tout ce qui peut se représenter, s’écrire, se dire pour être communiqué
entre hommes et ou entre machines constitue de l’information (sens large).

3. Notion de système d’information (SI) d’une organisation :

Le SI est composé d’éléments divers (employés, ordinateur, règles,
méthodes,…) chargés de stocker et de traiter les informations relatives au
système opérant afin de les mettre à la disposition du système de pilotage.
Il peut en outre recevoir de celui-ci des décisions destinées à son propre
pilotage. Enfin il peut émettre vers le système opérant des informations
inter-action, c'est-à-dire qu’il peut réagir sur le système opérant (SO) (par
exemple le S.O. ne pourra livrer le client que s’il obtient du système
d’information l’information que le produit est en stock).

4
 Système de l’entreprise

Système de
pilotage (décisions)

Environnement
Système d’information

Flux de biens et Système opérant

service

Informations

5
Le système d’information comprendra des images formalisées des flux du
système opérant (bons de commandes, de livraison, factures, etc.) et des
données comptables utilisées par exemple par le contrôle de gestion.
Le système d’information est en liaison d’une part avec un environnement
interne (SO et système de pilotage (SP)) et d’autre part avec un
environnement externe (clients, fournisseurs, etc.). Ces deux
environnements constituent l’univers extérieur (UE) du système
d’information.
Le système d’information est la mémoire de l’organisation : il comporte à ce
titre un aspect statique :
- Enregistrement des faits survenus dans l’univers extérieur (UE) dans
un ensemble mémorisé qu’on pourrait qualifier de base d’information
- Enregistrement des structures de données, règles et contraintes de
l’UE de manière formalisée dans un ensemble mémorisé qu’on
pourrait qualifier de modèle de données.
Il comporte également un aspect dynamique :
- Possibilité de mise à jour des données mémorisées dans la base
d’information
- Possibilité (pour un système adaptable) de changer les structures,
règles et contraintes du modèle de données suite à des changements
survenus dans l’UE et en reflet de ceux-ci. Cette partie active du
système d’information constitue le processeur d’information
(autrement dit le sous système qui traite l’information). Le
processeur d’information peut être constitué d’hommes et de
machines.

4. Système d’information automatisable

Dans un système les actions « programmées » (avec ou sans ordinateurs)
sont des actions qui déterminent de manière unique les sorties à partir des
entrées.
Ex : la connaissance du total des quantités sorties et du total des quantités
entrées détermine de manière unique le nouveau stock d’un produit. Il
existe une règle unique, parfaitement explicitable (formalisable)
permettant de déduire le nouveau stock de l’ancien à partir des quantités
entrées et sorties. Autrement dit le nouveau stock (les sorties) est
déterminé par la connaissance des entrées (total quantité entrée et total
quantité sortie du produit).
Nous disons que le système est déterminé. Les entrées E déterminant les
sorties S de manière unique : S = f(E)

6
Un système peut se trouver en situation d’information incomplète. Dans ce
cas une même entrée E peut conduire à plusieurs sorties possibles S, S1, S2,
etc. le choix de la sortie effectivement réalisée se fait par une décision.
Ex. : s
Système de décisions
E S1
S2

La connaissance du niveau du stock ne détermine pas les quantités à

commander au fournisseur. Le service achat devra effectuer un choix. Des
éléments non formalisables (intuition, expérience professionnelle, intérêts
personnels, habitudes etc.) peuvent intervenir dans un choix.
Le processus qui, dans un système, transforme les entrées en sortie peut
comporter :
- Des actions programmées
- Des choix (décisions).
Pour être automatisable :
Un système d’information doit être formalisable : la connaissance des
entrées doit permettre de déterminer les sorties par des règles de
transformation explicitables
- Seules seront automatisables les parties du système d’information qui
ne contiennent que des actions programmées (les sous systèmes
formalisables).
Les choix ne sont pas formalisables et donc non automatisables.
Les choix appartiennent à l’homme. Il est toutefois possible de transformer
des choix en actions programmées en ayant recours à un modèle.
Ex : les décisions de réapprovisionnement peuvent s’effectuer par
utilisation d’un modèle de gestion des stocks tel que : si stock < 500 alors
commander 2000.
Dans ce cas, la décision est prise une fois pour toutes (par l’homme) à
l’avance et chaque fois que le stock tombera en dessous de 500 on
appliquera le modèle en commandant 2000, ce qui n’est pas autre chose
qu’une action programmée puisque la connaissance du stock détermine de
manière unique la quantité à commander (0 si stock >=500, 2000 si stock<
500).

5. Les différentes méthodes de conception des systèmes d’information.

On appelle méthode de conception ou de réalisation de système
d’information un ensemble structuré de démarches permettant de définir et
de mettre en place un système information.
Il existe 3 méthodes de conception des SI.

7
5.1 Les méthodes cartésiennes :
Les méthodes cartésiennes constituent la 1ère génération des méthodes de
conception des systèmes d’information. Elles sont basées sur les concepts et
techniques de décomposition hiérarchique des processus et des flux de
données. Elles sont adaptées à l’étude des systèmes constitués par un
nombre limité d’éléments en interaction.
Ex : la méthode SADT (Structured Analysis and Design Technic).

5.2 Les méthodes systémiques

Ces méthodes de conception de système d’information sont basées sur le
fait que les données de gestion manipulées en entreprise sont relativement
stables, dans la mesure où elles sont compatibles au métier exercé par
l’entreprise. Les méthodes systémiques considèrent l’entreprise comme un
système composé de 3 sous-systèmes : le système de pilotage, le système
opérant et le système d’information. La modélisation est centrée sur la
modélisation des données.
Ex : MERISE ; E/R (Entity-Relationship) de Chen

5.3 Les méthodes orientées objet

Les méthodes orientées objet contrairement aux méthodes antérieures
combinent les notions de données et de fonction. Cette combinaison aboutit
à la notion d’objet qui est le concept principal des méthodes orientées objet.
Un objet est défini par ses caractéristiques (données) mais aussi par les
manipulations dont il est susceptible de faire l’objet (fonctions).
Ex : OMT (Objet Managemet Technic) ; la méthode de Booch.

8
CHAPITRE 2 : PRESENTATION DE MERISE
Merise (méthode d’étude et de réalisation informatique par les sous
ensembles (ou pour les systèmes d’entreprises)) est née vers 1978-1979, à
la suite d’une vaste consultation lancée en 1977 par le Ministère de
l’industrie pour choisir plusieurs sociétés de service et de conseil en
informatique et le CETE (Centre d’Etudes Techniques de l’Equipement)
d’Aix-en-Provence afin de mettre au point une méthode de troisième
génération de conception réalisation de système d’information. Le CTI
(Centre Technique d’Informatique) fut alors maître d’œuvre du projet
MERISE.

1. Principes généraux :
La vocation de Merise est double : d’une part Merise représente une
méthode de conception de système d’information et d’autre part Merise
propose une démarche méthodologique de développement de système
d’information.
Les atouts majeurs de merise en tant que méthode de conception sont :
- Une approche globale du système d’information menée parallèlement
et simultanément sur les données et les traitements ;
- Une description du système d’information par niveaux : niveau
conceptuel, niveau organisationnel, niveau logique et niveau physique
ou opérationnel,
- Une description du système d’information utilisant un formalisme de
représentation précis, simple et rigoureux pour la description des
données. Ce formalisme est normalisé au plan international par l’ISO
(International Standard Organization) sous le nom de : modèle
« Entité Relation »,
- Une description très riche du niveau conceptuel fondée sur les
invariants du système d’information permettant ainsi de construire
un nouveau système d’information sur des bases solides
indépendantes de l’organisation et des choix techniques
d’automatisation.
- Enfin, la représentation visuelle, notamment des modèles
conceptuels, contribue dans une large mesure à l’établissement d’un
dialogue constructif entre tous les partenaires qui collaborent pour
concevoir ensemble le nouveau système d’information.
Merise, comme nous l’avons dit, c’est aussi une démarche de
développement de système d’information. Les points forts de la méthode
dans ce domaine sont les suivants :
9
 - Un découpage du processus de développement en quatre étapes :
 Etude préalable
 Etude détaillée
 Réalisation
 Mise en œuvre

Il correspond au cycle de vie d’un système d’information. L’ensemble

des résultats produits à chaque étape constitue le cycle de décision.
- Une description détaillée de la structure de travail à mettre en place
pour mener à bien le développement du système d’information. Cette
structure est composée d’un comité directeur, d’un groupe projet et
d’un comité utilisateur. La mission et la composition de chaque
groupe d’intervenants sont précisées dans le cadre de la méthode.

2. les 3 composantes de Merise

Une méthode de conception de système d’information s’inscrit dans 3
dimensions exprimant :

2.1 La démarche ou cycle de vie :

La dénomination de ce cycle traduit le caractère « vivant » du système
d’information présentant une conception, une gestation, une naissance, une
croissance, une évolution, une mort… puis une renaissance.
Merise propose de découper le processus de développement d’un système
d’information en quatre étapes :

- L’étude préalable : cette étude, courte dans le temps, qui débute par
l’analyse de la situation existante permet de proposer une
architecture globale de la solution, en tenant compte des orientations
de gestion, d’organisation et de choix techniques validées par le
comité directeur du projet. Le dossier d’étude préalable est produit à
l’issue de cette étape ;
- L’étude détaillée : elle est menée après l’étude préalable et a pour
objectif de décrire complètement, au plan fonctionnel, la solution à
réaliser. Les phases de traitement sont spécifiées en décrivant les
données saisies, modifiées et restituées ainsi que la description des
traitements exécutés sur ces données. Elle comprend 2 phases :
 La conception générale
 La conception détaillée et se conclut par le dossier de
spécifications détaillées.

10
 - La réalisation : son but est d’obtenir les logiciels correspondant au
dossier de spécifications détaillées. Cette étape est elle-même
décomposées en deux phases :
 l’étude technique, qui complète l’étude détaillée par la prise en
compte de tout l’environnement technique informatique
 La production de logiciel qui permet d’obtenir le logiciel testé sur
jeu d’essai.
- La mise en œuvre : son but est d’exécuter toutes les actions
(formation, documentation, installation de matériels, initialisation
des données, réception…) qui permettront d’aboutir au lancement du
système auprès des utilisateurs.
Par ailleurs il est recommandé d’utiliser, dès l’étude préalable, le
maquettage et le prototypage, pour donner une représentation plus
concrète des principaux sous-ensembles de la solution proposée.

2.2. Les raisonnements ou cycle d’abstraction :

Merise propose de décrire un système d’information suivant différents
niveaux d’abstraction allant de l’abstrait vers le concret. A chaque niveau
correspond une préoccupation du concepteur du système d’information sur
la description des données et des traitements. Ces niveaux de description
peuvent se regrouper en deux ensembles. Tout d’abord le niveau
conceptuel et le niveau organisationnel correspondant à la préoccupation
de description du système d’information indépendamment des aspects
techniques liés à l’informatisation. Merise propose pour ces 2 niveaux des
modèles de description de données et de traitement. Ensuite les niveaux
logique et physique de description d’un système d’information prenant en
compte la technologie informatique de la solution retenue pour
l’informatisation.
(Schéma à insérer ici (sur niveau de description).

2.3 La maîtrise du projet ou cycle de décision.

Le déroulement simultané de la démarche et des raisonnements doit être
maîtrisé. Dans chaque modèle, à chaque étape, des choix doivent être
effectués. Vers quel projet veut on aller, quels moyens veut ont lui affecter ?
La mise en œuvre de la méthode Merise se traduit en plus, par une
succession de choix permettant d’une part de contrôler la durée globale de
la conception-réalisation, d’autre part de définir un système en harmonie
avec les objectifs généraux de l’entreprise.

11
Dans la pratique, le cycle de décision est intégré dans le cycle de vie. Cela se
traduit par des résultats types à l’issue de chaque étape et par des décisions
attendues.

12
CHAPITRE 3 : DIAGRAMME DES FLUX

1. Domaine d’activité et activité d’une entreprise

La première étape de la construction d’un système d’information d’une
entreprise consiste à bien identifier ses domaines d’activité. En fait, à
chaque finalité de l’entreprise est associé un domaine d’activité.

Le découpage en domaine d’activité est un élément quasi invariant de

l’entreprise, il représente ainsi une base solide pour la construction du
système d’information. Comme exemples de domaines d’activités
classiques, nous pouvons citer :
 Le domaine d’activité commercial
 Le domaine d’activité de la production,
 Le domaine d’activité des ressources humaines

Chaque domaine d’activité est décomposé en grande fonction, appelée

activité, par exemple, l’activité recrutement et l’activité déroulement de
carrière pour le domaine d’activité du personnel.

2. Flux
Un flux est la représentation de l’échange d’informations entre deux
activités, ou entre une activité et un partenaire extérieur à l’entreprise.

Un flux est caractérisé par son nom et la liste des données qui le compose,
par exemple : commande (n° commande, date commande…) les flux
échangés peuvent être aussi des flux de matière, des flux financiers ou
d’autres flux. Dans le cadre des systèmes d’information, seuls en général
sont décrits les flux de données.

3. Champ d’étude
Le champ d’étude (ou domaine d’étude) représente les domaines d’activité
et ou les activités qui composent le système à étudier. C’est un sous
ensemble cohérant d’activités de l’entreprise.
Ex : le domaine d’étude « Gestion commerciale » est composé de :
- Gestion des commandes
- Gestion des factures
- Gestion des comptes clients

13
Recommandation
Dans la mesure du possible, il faut viser à minimiser les échanges entre un
domaine d’étude et son environnement extérieur. Dans le cas ou il existe un
grand nombre de flux avec par exemple un autre domaine, il faut
s’interroger s’il ne faut pas modifier le contour du champ d’étude afin
d’intégrer partiellement ou complètement les domaines concernés.

4. Acteur :
Un acteur est une entité organisationnelle identifiable par les missions qu’il
remplit dans le cadre du champ d’étude défini.
Un acteur dont les missions se situent à l’intérieur du champ d’étude est
qualifié d’acteur interne. Par raccourci on l’appelle acteur. Un acteur dont
les missions se situent en dehors du champ d’étude mais qui échange des
informations avec un acteur interne est qualifié d’acteur externe. Pour
accomplir ses missions, un acteur (interne) dispose de ressources
matérielles et éventuellement de ressources logicielles.
Ex : une agence locale disposant d’un logiciel de gestion sur serveur PC
accessible par 4 postes via un réseau local.
Le diagramme de flux représente les flux échangés entre :
 Les acteurs du domaine d’étude
 Les acteurs du domaine d’étude et les partenaires extérieurs ou
domaine extérieur au domaine d’étude.
Formalisme

Acteur flux
flux
Acteur
interne
externe flux Acteur
interne

flux
flux

Acteur
Acteur flux
interne
externe

14
Les flèches orientées correspondent aux flux (de l’émetteur vers le
récepteur). Les ellipses en pointillé ou trait discontinu correspondent aux
acteurs externes et les ellipses en trait plein aux acteurs internes. Il est
possible d’indiquer la chronologie des échanges en numérotant les flux.

15
 CHAPITRE 4 : ELABORATION DU MCD

1. Les concepts de base :

1.1 Entité

Une entité ou individu est la représentation dans le système d’information

d’un objet matériel ou immatériel de l’UE.

Une entité est un objet pourvue d’une existence propre et conforme aux
choix de gestion de l’entreprise.

Formalisme NOM DE L’ENTITE

Ex. :

CLIENT COMMANDE PRODUIT

1.2. Relation

Définition : une relation entre entités est une association perçue dans le réel
entre deux ou plusieurs entités. Une relation est dépourvue d’existence
propre.

Formalisme :

Entité 2
Entité 1

Nom de la relation

Entité n
Entité 3
Ex. :

CLIENT COMMANDE PRODUIT

Commander produit
Passer commande
16
1.3 Propriété :
Une propriété (ou attribut) est une donnée élémentaire que l’on perçoit sur
une entité ou sur une relation entre objets.
Formalisme :
Le nom de la propriété est inscrit à l’intérieur de l’entité.
Ex : numéro client, nom client et prénom client sont des propriétés de
l’entité client.

CLIENT
Numclient
Nom
Prénom

1.4 type et occurrence

a) un type est un ensemble d’éléments ayant les mêmes caractéristiques
(entité-type, relation type, propriété –type). Un type d’entité ou entité-type
est une classe d’entités particulières ayant des propriétés analogues.

b) Occurrence d’une entité

Une occurrence d’une entité est un élément individualisé appartenant à
cette entité.

Ex : Oumar est une occurrence de l’entité client.

c) Occurrence d’une relation

Une occurrence d’une relation est une relation individualisée constituée
d’une et d’une seule occurrence des entités participant à la relation
Considérons la relation « affecter à » à laquelle participent les entités salarié
et service.

SALARIE SERVICE
Affecté à
matricule numservice
nom Date affectation intitulé

17
Ex. d’occurrences

SALARIE SERVICE
Affecté à
A01 125
OUMAR 18/01/05 comptabilité

SALARIE
Affecté à
A12
MARIAM 15/03/12

SALARIE SERVICE
Affecté à
A02 124
AMADOU 04/02/09 commercial

Nous avons 3 occurrences de la relation « affecté à ».

d) Occurrence d’une propriété
une occurrence d’une propriété est une valeur prise par cette propriété.

Comptabilité, commercial sont les occurrences de la propriété intitulé

service.

1.5 Cardinalités
La cardinalité d’une entité par rapport à une relation s’exprime par 2
nombres appelés cardinalité minimale et cardinalité maximale, dont les
définitions suivent :
La cardinalité minimale (égale 0 ou 1) est le nombre de fois minimum
qu’une occurrence d’une entité participe aux occurrences de la relation.
Si la cardinalité minimale est égale à 0, c’est qu’il existe parmi toutes les
occurrences de l’entité au moins une occurrence ne participant pas aux
occurrences de la relation. Ainsi on peut concevoir qu’il existe dans l’objet
client des occurrences ne participant pas à la relation passer commande, ce
qui revient à dire que l’on peut être client sans n’avoir jamais rien
commandé.

Si la cardinalité minimale est 1, ceci correspond au fait que chaque

occurrence de l’entité participe toujours à une occurrence de relation. Dans
18
 notre exemple, ceci traduirait le fait que chaque client a passé au moins une
commande.

La cardinalité maximale (égale à 1 ou n) indique le nombre de fois

maximum qu’une occurrence de l’entité participe aux occurrences de la
relation.

Formalisme

ENTITE
Relation

Cardinalité
Cardinalité
maximale 1 ou N
minimale 0 ou 1

Ex. :

CLIENT COMMANDE
Passer commande

qtecommandée
0,n 1,1

Un client peut ne pas passer de Une commande est tjrs passée

commande (client potentiel) par un client

Un client peut passer au plus n

Une même commande est
commandes
passée au plus par un seul client

1.6 Identifiant
a) Identifiant d’une entité
C’est une propriété particulière de l’entité telle qu’à chaque valeur de la
propriété corresponde une et une seule occurrence de l’entité.
Ex : numéro matricule étudiant pour identifier un étudiant.
Numéro d’immatriculation pour identifier une voiture

19
S’il existe pour un même objet plusieurs possibilités, dans un MCD, on en
retiendra un seul.
Ex : si l’on considère un fichier de véhicules on peut avoir pour l’identifiant
de l’entité VEHICULE le choix entre :
 Le numéro d’immatriculation
 Le numéro de série du moteur.
Dans ce type d’exemple, il s’agira pour le concepteur de retenir l’identifiant
correspondant au mieux à l’entité à modaliser, en tenant compte des choix
de gestion de l’entreprise.

Formalisme
L’identifiant est repéré dans la liste des propriétés de la manière suivante.
 L’identifiant figure en 1er position dans la liste des propriétés
 L’identifiant est souligné.

Ex :
PRODUIT
NumProduit
Libellé
Prix

b) Identifiant d’une relation :

C’est l’identifiant obtenu par concaténation des identifiants des entités
participant à la relation
ex :

PRODUIT COMMANDE
Commander produit

codeprod numcommande
qtecommandée date
designation
prix

L’identifiant de la relation est codeprod, numcommande, l’identifiant d’une

relation n’est en général pas inscrit dans la relation.

c) Dimension d’une relation

C’est le nombre d’entité participant à la relation. Une relation entre 2
entités est appelée relation binaire. Une relation entre 3 entités est appelée
relation ternaire.

Une relation entre n entités est appelée : relation n-aire.

20
Relation réflexive
C’est une relation d’une entité sur elle-même.
Ex : considérons l’entité personne représentant tous les individus identifiés
au RAVEC et essayons de représenter la relation mariage.

PERSONNE 0,n (se marier) Mariage

numRavec
date
nom
0,n (être ou avoir
été marié)

Cette représentation permet de prendre en compte les faits suivants :

- Une personne peut rester célibataire (cardinalité 0)
- Une personne peut se marier n fois à des dates différentes
(cardinalités n).

2. Construction du MCD
2.1 Introduction :
Nous allons faire comprendre la méthode à l’aide d’un exemple.
Le système contient essentiellement des propriétés figurant sur les bons de
commande.

21
 BON DE COMMANDE

NoBon :……………………………………………Date :………………………………………..

Nom client :………………………………………………………………………………………
Adresse :…………………………………………………………………………………………….
Nom Représentant :…………………………………………………………………………….

Réf Désignation Qte PU Montant

TOTAL

A la suite d’interviews des différents postes de travail du système

d’information existant, on rassemble des exemplaires de tous les
documents utilisés ainsi que les descriptions des divers fichiers en usage
actuellement (si le système d’information actuel est déjà automatisé).

2.2 Règles de gestion

Les règles de gestion(RG) du MCD précisent les contraintes qui doivent être
respectées par le modèle. Dans notre exemple, nous avons les RG suivantes :
RG1 : Un client peut passer une ou plusieurs commandes ou aucune
commande.
RG2 : une commande peut concerner un ou plusieurs produits
RG3 :une commande est passée à un représentant qui n’est pas toujours le
même pour un client donné.

2.3 Le Dictionnaire de données

Le dictionnaire de données est l’ensemble des données élémentaires
pertinentes du domaine d’étude.

a) donnée élémentaire.
Une donnée est élémentaire si elle ne résulte pas d’une concaténation de
données.
22
Une donnée est élémentaire si les caractères qui la composent ne peuvent
être utilisés isolement.
Ex : l’adresse, composée de la rue, de la ville et du code postal est une
donnée non élémentaire. Par contre si une donnée composite est toujours
utilisée globalement, on la considère alors comme élémentaire.
Ex : si adresse composée de la rue, de la porte, du quartier est toujours
utilisée globalement, on la considère comme donnée élémentaire.

b) synonymie et polysémie
On cherche à épurer la liste des données donc à lever certaines ambiguïtés
liées à des problèmes de synonymie et ou de polysémies.

La synonymie : il s’agit de repérer les données identifiées différemment

dans la liste et qui ont le même sens ; on n’en retiendra bien sûr qu’une
seule.
Ex : numéro produit dans une commande et référence produit dans une
facture. Si ces deux données recoupent la même réalité, il faut n’en retenir
qu’une seule.

La polysémie : il s’agit de repérer les données ayant la même orthographe

mais recouvrant des réalités différentes. Il faut alors attribuer des noms
différents à ces données.
Ex : la donnée date correspond à la date de commande, à la date de
livraison, à la date de facturation.

Il faut pour éviter la polysémie, affecter un libellé à chacune d’elles :

datecde, datelivraison, datefacture.

c) donnée calculée :
Une donnée calculée est une donnée qu’il est possible d’obtenir a partir de
données élémentaires, en appliquant une règle de gestion. Il n’est donc pas
utile de retenir cette donnée dans la base puisqu’on peut l’obtenir à tout
moment, sauf dans 2 cas :
- Lorsque les données figurant dans la règle de gestion sont
susceptibles d’évoluer.
- Ex : montant = quantité * prixunit
Prixunit peut évoluer (après MAJ on aura plus la valeur initiale de
montant)
- Lorsque le calcul de la donnée calculée conduit à conserver un
nombre important (voire inutile) de valeurs de données dans la base.

23
 C’est souvent le cas de donnée de type solde (solde client, solde d’un
compte stock).
Ex : solde client = somme (montant TTC) – somme (montant réglé)

Le DD est représenté sous forme de tableau et comporte les colonnes :

désignation ou signification des données, code ou nom des données, type ou
format, nature et parfois règle de calcul. Les règles de calcul peuvent être
données en bas du DD.

DD pour notre projet

Désignation Code Type Nature

Numéro bon de commande N°bon N E
Date commande date D E
Code client & codeclient AN E
Adresse client nomclient A E
Ville client adresse AN E
Code client ville A E
Code postal cp AN E
Code représentant & coderep AN E
Nom représentant nomrep A E
Référence produit ref AN E
Désignation produit design A E
Quantité commandée qte N E
Prix unitaire prixunit N E
Montant ligne montant N C(1)
Total commande Total N C(2)

N : numérique : D : Date, A : alphabétique

AN : alphanumérique ; E : élémentaire ; C : Calculé
(1) Montant = qte*prixunit
(2) Total = somme (montant)
& Codeclient et coderep sont des codes qu’on a crée pour identifier des
entités évidentes client et représentant

2.4 Les dépendances fonctionnelles (DF)

a) Dépendance fonctionnelle entre 2 propriétés :

On dit que 2 propriétés a et b sont reliées par une DF : a→b si la
connaissance de la valeur de a détermine une et une seule valeur de b.
24
Ex : codeclient → nomclient
La DF peut porter sur la concaténation de plusieurs propriétés.
(Numbon + réf) →qte.

b) DF élémentaire (DFE):
on dit qu’il ya DFE entre les propriétés a et b si aucune partie de a ne
détermine b.
(codeclient+prénom) → nomclient n’est pas élémentaire puisque
codeclient → nomclient par contre (numbon + réf) → qte est une DFE.

c) DFE directe : on dit que la propriété b dépend fonctionnellement de a par

une DFED si cette dépendance est élémentaire et s’il n’existe pas de
propriété c telle que a → c et c → b. Autrement dit on élimine toute
transitivité.
Ex : numprof → codematière
codematière → nommatière
numprof → nommatière.

Les 2 1ères DF sont directes, mais la 3ème ne l’est pas en raison de la

transitivité
Numprof → codematière → nommatière.

2.5 Graphe des DF

On extrait du DD la liste des propriétés qui ne sont ni concaténées ni
calculées.
Dans notre exemple on retient toutes les données sauf montant et total qui
sont calculées.
Ont établit la liste des DF dont le domaine de départ ne contient qu’une
seule propriété non concaténée à partir de l’examen des documents et des
identifiants évidents.
Cette liste peut se visualiser sur un graphe comme suit :
numbon ref

qte
date corep
design pu
codeclient

nomrep
codeclient adresse ville bp

25
La propriété qte est isolée.
S’il reste des propriétés isolées, on cherche des DF qui conduisent à ces
propriétés à partir de propriétés concaténées. Si on n’en trouve pas pour
une propriété celle-ci reste isolée.

On utilise ici la DF : numbon + ref → qte

numbon ref

qte

On cherchera toutefois à s’assurer que les propriétés isolées ne

correspondent pas à des entités isolées pour lesquelles il faudrait imaginer
un identifiant permettant d’ajouter les DF qui faisaient défaut.

On obtient ensuite la liste de toutes les DF qui découlent du graphe obtenu

par le jeu des propriétés des DF. On utilise en particulier la transitivité et la
pseudo transitivité.
On obtient la fermeture des DF. ref
numbon
qte

date corep design pu

codeclient

nomrep
codeclient adresse ville bp

On élimine les transitivités

On obtient la structure d’accès théorique (SAT) ou couverture minimale qui
représente les divers chemins d’accès aux données.

numbon ref

qte
date corep
design pu
codeclient
26

nomrep
codeclient adresse ville bp
 2.6 Etablissement du MCD

Les arcs terminaux obtenus à partir des propriétés élémentaires définissent

les entités. Les origines de ces arcs sont les identifiants.
Les arcs restants mettent en évidence les relations. Les propriétés non
isolées restantes sont affectées à des relations. Les RG doivent permettre de
trouver les cardinalités.

PRODUIT
COMMANDE
1,n Se compose de
0,n Ref
Numbon qte Design
date
1,1 pu

1,1 Passe commande

0,n
CLIENT REPRESENTANT

codeclient corep
nom nomrep
obtient 0,n
adresse
ville
bp

Il faut s’assurer que les règles de vérification normalisation et

décomposition sont respectées.

27
CHAPITRE 5 : LE MODELE RELATIONNEL DE DONNEES (MRD)

1. Introduction :
Il ne faut surtout pas confondre les relations du modèle relationnel avec les
relations du modèle entités/relations à partir duquel nous avons construit
notre MCD.
Dans le modèle entité/relation une relation exprime une association entre
entités.
Dans le modèle relationnel, il s’agit d’association de propriétés. Les
relations sont couramment appelées les tables.

2. Règles de passage du MCD au MRD (ou MLDR)

a) Règle pour les entités
- L’entité se transforme en relation ou table
- L’identifiant de l’entité devient la clé primaire de la table
- Les propriétés de l’entité deviennent des attributs de la table

b) Règles pour les relations

Cas de la relation type pere-fils
0,n 0,1
A R B
1,n 1,1

A est l’entité père, B est l’entité fils

L’identifiant de l’entité père devient attribut de la table fils. Cet attribut est
aussi appelé clé étrangère.

Cas des autres relations

0,n 0,n
A R B
1,n 1,n

La relation R devient une table. L’identifiant de la relation R devient la clé

primaire de la table.
Les propriétés de la relation R deviennent les attributs de la table.

28