SYSTEMES INFORMATIQUES

Merise | 1

999 &
GENIE LOGICIEL

Analyse et Conception des Systèmes

d‘Information
2021-2022

Dr Raogo KABORE
 Merise | 2

Bibliographie

La méthode MERISE, Principes et outils

H. TARDIEU, A. ROCHFELD, R. COLLETTI, Les éditions d’organisation, 1979.

Ingénierie des systèmes d'information MERISE deuxième génération (4eme édition)

D. NANCI, B. ESPINASSE, éditions Vuibert. 2001

Conception des bases de données relationnelles : Concepts, méthodes et cas corrigés. 2001
J. AKOKA, I. Comyn-Wattiau

La méthode MERISE. Tome 2 : Démarche et pratiques

Les éditions d’organisation, 1985. Tardieu, Rochfeld, Colletti, Panet, Vahée.

Ingéniérie des systèmes d’information

sous la direction de Corine Cauvet et Camille Rosenthal-Sabroux, Hermes, 2001.

Webographie

http://www.loria.fr/~jloncham/enseignement-fr.html
 Merise | 3

SOMMAIRE

I. INTRODUCTION _________________________________________________________ 5
Définition _____________________________________________________________________ 5
Historique _____________________________________________________________________ 5
II. LES 3 DIMENSIONS DE LA METHODE MERISE _________________________________ 7
Le cycle d'abstraction ____________________________________________________________ 7
Le cycle de vie __________________________________________________________________ 9
Le cycle de décision ____________________________________________________________ 10
Plans types ___________________________________________________________________ 10
Plan type de l’étude préalable: production du cahier des charges _______________________________ 11
Plan type de l’étude détaillée: production de spécifications ____________________________________ 12
LA COURBE DU SOLEIL __________________________________________________________ 13
III. Le modèle conceptuel des traitements (MCT) ________________________________ 18
LE CONCEPT D'EVENEMENT ______________________________________________________ 18
processus ____________________________________________________________________ 18
Opération ____________________________________________________________________ 18
La synchronisation _____________________________________________________________ 18
Construction du MCT ___________________________________________________________ 19
Méthode de construction________________________________________________________ 20
Exemple de MCT _______________________________________________________________ 20
Gestion des approvisionnements _________________________________________________________ 20

IV. LE MODELE CONCEPTUEL DES DONNEES (MCD) ______________________________ 24

CONCEPTS ____________________________________________________________________ 24
ENTITÉ ______________________________________________________________________________ 24
RELATION ____________________________________________________________________________ 25
CARDINALITES ________________________________________________________________________ 25
Contrainte d’Intégrité Fonctionnelle (CIF) ___________________________________________________ 28
TECHNIQUES DE MODELISATION __________________________________________________ 29
SYNTHESE DES DEMARCHES PRESENTEES ___________________________________________________ 29
MODELISATION DIRECTE ________________________________________________________________ 30
MODELISATION ASCENDANTE. ___________________________________________________________ 31
NORMALISATION ______________________________________________________________________ 35

V. MODELE ORGANISATIONNEL DE TRAITEMENT _______________________________ 40

Point de départ ________________________________________________________________ 40
Procédure ____________________________________________________________________ 40
Phase _______________________________________________________________________________ 40
Poste de travail ________________________________________________________________________ 40
La nature du traitement: ________________________________________________________________ 41
La période d’exécution _________________________________________________________________ 41
 Merise | 4

Événement ___________________________________________________________________________ 41
Autres concepts (synchronisations, règles d’émission) ________________________________________ 41
Formalisme ___________________________________________________________________ 42
Exemple de MOT ______________________________________________________________ 43
Tableau de décomposition en phases: _____________________________________________________ 43
MOT ________________________________________________________________________________ 44
Fiche de description de phase ____________________________________________________________ 45

VI. Le modèle logique de données __________________________________________ 46

RÈGLES DE TRANSFORMATION DU MCD AU MLD (MRD) _______________________________ 46
Transformation des entités ______________________________________________________________ 46
Transformation des relations binaires du type (x,n) – (x,1) _____________________________________ 46
Transformation des relations binaires du type (x,1) – (x,1) [x=0 ou 1]_____________________________ 47
Transformation des relations binaires du type (x,n) – (x,n) _____________________________________ 49
Transformation des relations ternaires _____________________________________________________ 49
Transformation de plusieurs relations entre 2 entités _________________________________________ 49
Transformation des relations réflexives ____________________________________________________ 51
RÉCAPITULATIF : _______________________________________________________________ 52
Représenter une association binaire 1,1 - 1,n________________________________________________ 52
Représenter une association binaire (0 ou 1) , n - (0 ou 1), n non porteuse de propriétés : ___________ 52
Représenter une association binaire 1,1 - 1,n____________________________ Erreur ! Signet non défini.
Représenter une association binaire (0 ou 1) , n - (0 ou 1), n non porteuse de propriétés : _ Erreur ! Signet
non défini.
Représenter une association binaire 1,1 - 0,1 : _______________________________________________ 53
Représenter une association ternaire 0,n - 0,n - 0,n : _________________________________________ 54
 Merise | 5

I. INTRODUCTION

DEFINITION
MERISE signifie Méthode d'Etude et de Réalisation Informatique par Sous-Ensembles.

MERISE est une Méthode Systémique d'Analyse, Conception et de Réalisation des Systèmes d'Informa-
tion.

Méthode : Ensemble de modèles et une démarche.

Système D'Information : Sous-système d'un système d'organisation.

Analyse : Etude et évaluation du système actuel.

Conception : Etude, proposition, évaluation du système futur.

Réalisation : Conception détaillée et réalisation logicielle du système futur.

HISTORIQUE

1970 Modèle Relationnel de Codd.

Années 70 Premiers prototypes de SQL
1976 Modèle Entité Association de Chen
1974-78 Le noyau de MERISE est établi par une équipe d’ingénieurs et de chercheurs
aixois.
1978 Développement de MERISE : méthode française de conception de systèmes
d’information, sous l’égide du ministère de l’industrie.
1979 Conception du système d’information, construction de la base de données, H.
Tardieu, D. Nanci, D. Pascot (préfacé par J.-L. Le Moigne), Editions
d’Organisation.
1979 Première version de SQL, proposé par ORACLE.
1983 La méthode MERISE - Tome 1 : principes et outils. H. Tardieu, A. Rochfeld,
R. Colletti. Éditions d’Organisation.
1985 La méthode MERISE - Tome 2 : démarche et pratique. H. Tardieu, A.
Rochfeld, R. Colletti, G. Panet, G. Vahée. Éditions d’ Organisation.
1986 SQL ANSI (American National Standard Institute)
 Merise | 6

1989 SQL-1, ISO et ANSI (International Standard Organisation)

1989 La méthode MERISE - Tome 3 : gamme opératoire. A. Rochfeld, J. Moréjon.
Édition d’Organisation.
ère
1992 Ingéniérie des systèmes d’information : MERISE. 1 édition. D. Nanci, B.
Espinasse. Sybex.
1992 SQL-2, ISO et ANSI
fin années 90 PHP-MySQL
1999 SQL-3, ISO et ANSI

2001 Ingénierie des systèmes d’information : MERISE. 4 édition. D. Nanci, B.

Espinasse. Vuibert.
2006 Oracle Database XE

En 2001, la méthode MERISE était encore la méthode de conception de systèmes d’information la plus
largement pratiquée en France.
MERISE a pris en compte les évolutions de l’informatique et continue de s’adapter aux nouvelles techno-
logies : architectures clients/serveur, interfaces graphiques, démarche de développement rapide, ap-
proche objet, applications intra/internet.
Aujourd’hui, la méthode MERISE correspond encore globalement aux savoir-faire actuels en ingénierie
des systèmes d’information de gestion.
MERISE constitue un standard de fait en conception des systèmes d’information

Au fil du temps, la méthode Merise de base (appelée Merise 1) se transforma en Merise 2 (intégrant des
éléments tels que contraintes, héritage, types, sous-types), puis en Merise 3 aussi appelée méthode
OOM, pour Orientations Objet dans Merise, qui est une variante de Merise, proposant une approche
réellement orientée objet, à base d'une encapsulation données-traitements validable.

Nous nous limiterons en ce qui nous concerne aux concepts fondamentaux de Merise 1 qui constituent le
socle de cette méthode d’analyse.
 Merise | 7

II. LES 3 DIMENSIONS DE LA METHODE MERISE

La démarche de développement proposée par MERISE s’inscrit dans trois dimensions :

Le cycle de vie : c’est le découpage du projet en trois périodes: conception, réalisation et maintenance.
Le cycle de vie rejoint le cycle en V. 

Le cycle de décision : c’est la liste de tous les moments où une décision est prise sur le projet (décision
de faire le projet après une étude préalable, décision de valider l’analyse fonctionnelle et de passer à
l’architecture, validation de la recette, etc.) 

Le cycle d’abstraction : c’est l’organisation structurelle des données et des traitements. On va surtout
s’intéresser au cycle d’abstraction. 

LE CYCLE D'ABSTRACTION

Le cycle d’abstraction est découpé en quatre niveaux : conceptuel, organisationnel, logique et physique.

Le niveau conceptuel : il exprime des choix fondamentaux de gestion (recherche d’éléments stables
indépendamment des moyens à mettre en œuvre, de leurs contraintes et de leur organisation). Répond à
la question : QUOI. 

Le niveau organisationnel : il exprime les choix d’organisation de ressources humaines et matérielles,

au travers notamment de la définition d’acteurs et de postes de travail. Répond aux questions : QUI, OU,
QUAND. 

Le niveau logique : il exprime les choix de moyens et de ressources informatiques, en faisant abstraction
de leurs caractéristiques techniques précises. C’est le niveau du modèle relationnel (moyen informatique :
base de données relationnelle), du diagramme des classes et des diagrammes de séquence objets
(moyen informatique : langage orienté objet). Répond à la question : COMMENT. 

Le niveau physique : il traduit les choix techniques et la prise en compte de leurs spécificités. C’est le
niveau du code dans un langage particulier

Distinction entre données et traitement

Le cycle d’abstraction est basé sur une distinction entre les données et les traitements. C’est la dichotomie
fondamentale de MERISE.

Elle est directement issue de l’approche base de données

 Merise | 8

Niveaux DONNEES TRAITEMENTS

CONCEPTUEL MCD MCT

Modèle conceptuel des données Modèle conceptuel des traitements

QUOI Signification des informations sans Activité du domaine sans préciser les
contraintes techniques, ressources et leur organisation
organisationnelle ou économique.

Modèle entité – association

ORGANISATIONNEL MOD MOT

Modèle organisationnel des Modèle organisationnel des

données traitements

QUI, OU, QUAND Signification des informations avec
contraintes organisationnelles et
économiques. (Répartition et
quantification des données ; droit des
utilisateurs)
LOGIQUE MLD
Fonctionnement du domaine avec les
ressources utilisées et leur organisa-
tion
(répartition des traitements sur les
postes de travail)
MLT

Modèle logique des données Modèle logique des traitements

COMMENT Description des données tenant Fonctionnement du domaine avec les

compte de leurs conditions ressources et leur organisation
d’utilisation (contraintes d’intégrité, informatique.
historique, techniques de
mémorisation).

Modèle relationnel
PHYSIQUE MPD MPT

Modèle physique des données Modèle physique des traitements

Architecture technique des pro-
COMMENT Description de la (ou des) base(s) de grammes
données dans la syntaxe du Système
de Gestion des données (SG.Fichiers
ou SG Base de Données)

Optimisation des traitements

(indexation, dénormalisation,
triggers).
 Merise | 9

LE CYCLE DE VIE

Le cycle de vie est découpé en trois périodes: la conception, la réalisation et la maintenance.

LE CYCLE DE VIE
ETAPES DE LA DEMARCHE EXPLICATIONS

Schéma Définition des orientations générales du développement à

directeur moyen terme des systèmes d’information

Étude Proposition et évaluation de solutions d’organisation et de

préalable solutions techniques pour le SI d’un domaine.
Conception
Cette étape porte sur un sous-ensemble représentatif du
domaine étudié.

Spécifications complètes du futur SIO (Système d’Information Organisa-

Étude tionnel - Métier) du point de vue de
détaillée l’utilisateur (point de vue externe).

Elle comporte deux phases :

 la conception générale (extension de l’étude préalable à

tout le domaine)

 la conception détaillée ( description complète de chacune

des tâches à automatiser).

Spécifications complètes du futur SII (Système d’Information Informatisé

Étude – Application informatique) du point de vue du
technique réalisateur (point de vue interne).

Réalisation
Production Écriture des programmes, générations des fichiers ou des bases
logicielle de données, tests.

Mise en Installation de l’application informatique, vérification du bon

service fonctionnement, mise en place de la nouvelle organisation,
formation des utilisateurs.

Maintenance Maintenance Rectification des anomalies, améliorations, évolutions.

 Merise | 10

LE CYCLE DE DECISION

Le cycle de décision représente l’ensemble des choix qui doivent être faits durant le déroulement du cycle
de vie.

Étapes de la démarche Résultats Décisions

Schéma directeur MOA Plan de développement des SI Approbation et mise en

application
Étude préalable MOA Dossier des choix, n solutions Choix d’une solution ou arrêt
.
Étude détaillée MOE Spécifications fonctionnelles Accord des utilisateurs sur les
spécifications fonctionnelles

Étude technique MOE Spécifications techniques pour Accord des réalisateurs sur les
la réalisation spécifications techniques

Réalisation logicielle MOE Système réalisé en ordre de Recette provisoire :

marche conformité du système

Mise en service MOE Système installé dans Recette définitive : système en

l’organisation service

Maintenance MOE Système maintenu Recette simplifiée : fin de

maintenance

MOA = Maîtrise d'ouvrage, entité qui définit le projet

MOE = Maîtrise d'œuvre est l'entité retenue par le maître d'ouvrage pour réaliser le projet

PLANS TYPES

Les étapes de la démarche du cycle de vie donnent lieu à la production de documents.

Comme toute autre méthode, la méthode MERISE propose des plans types pour tous les documents
prévus par la méthode.

L’étude préalable et de l’étude détaillée sont les deux études qui sont les plus spécifiques à MERISE car
elles font intervenir l’essentiel du cycle d’abstraction.

On présente ci-dessous les plans type de ces deux étapes.

 Merise | 11

Plan type de l’étude préalable: production du cahier des charges

1. Recueil

 Préparation et réalisation des interviews

 Recherche de la documentation
 Description et bilan de l’existant

2. Conception

Élaboration des divers scénarios

 Élaboration des MCD et MCT

 Maquette et prototype
 Élaboration du cahier des charges fonctionnel

3. Qualité

 Définition des exigences qualité globale

 Définition des exigences qualité par fonction

4. Chiffrage

 Estimation prévisionnelle des charges, coût, délais

 Planning prévisionnel

Résultats obtenus :
 Cahier des charges fonctionnel
 Dossier de choix
 Merise | 12

Plan type de l’étude détaillée: production de spécifications

1. Recueil complémentaire

 Préparation et réalisation des interviews des utilisateurs

 Recherche de la documentation
 Actualisation de l’étude préalable

2. Conception

 Mise à jour des MCD et MCT

 Élaboration du MOT
 Description des états et des écrans
 Validation croisée MCD / MOT
Élaboration du MLD

3. Qualité

 Définition des facteurs qualité

4. Chiffrage

 Estimations globale et détaillée

 Plannings global et détaillé

Résultats obtenus :

 Dossier des spécifications fonctionnelles

 Plan de développement logiciel
 Merise | 13

LA COURBE DU SOLEIL
 Merise | 14

III. MATRICE ET DIAGRAMME DES FLUX.OU

MODELE CONCEPTUEL DE COMMUNICATION (MCC)

Les échanges de données ou de messages entre les acteurs du système d’information sont résumés dans
une matrice ou un diagramme des flux (aussi appelé modèle conceptuel de communications).
Le Diagramme de flux est une représentation graphique des acteurs et des flux échangés

Un acteur peut modéliser:

 un partenaire extérieur à l’organisation: client, fournisseur,...
 un domaine d’activité de l’organisation précédemment identifié: la comptabilité, la ges-
tion du personnel,...
 un ensemble d’activités: liquidation, contrôle,...
 un élément structurel de l‘organisation: service, unité géographique, unité fonction-
nelle,...

Un acteur externe représente tout élément extérieur à l’organisation et échangeant des flux avec le do-
maine d’étude
Un acteur interne peut être une personne physique ou morale appartenant au système, capable d’échan-
ger des informations avec les autres acteurs ou partenaires
 modélise un élément structurel du domaine d’étude
 reflète un choix d’organisation

Exemple: Emile Zapata (une personne), le comptable (une fonction), le poste de saisie numéro 5 (poste
de travail), le service commercial

Exemple de matrice des flux :

Vers Service com- Service expédition Service facturation Client

mercial
De
Service commer- Commande
cial
Service expédition Avis expédition Livraison à facturer Bon de livraison
Service facturation Facture
Client Réclamation Paiement
éventuelle
 Merise | 15

Exemple de diagramme des flux : Service

factura-
Livraison à facturer tion

Commande
Service Service
commer expédi-
-cial Avis d’expédition tion
Facture

Paiement

Bon de livraison
Client

Réclamation

Quand l’étude se place au niveau conceptuel (le niveau conceptuel s’intéresse à des principes stables,
indépendants de l’organisation pratique), les flux qui résultent de l’organisation du travail ne doivent pas
être retenus. On élimine notamment les flux internes informants, qui ne font que transférer une infor-
mation sans entraîner le déclenchement d’un traitement (l’hypothèse est que ces flux sont potentiellement
remplacés par une base de données accessible aux acteurs).

Exemple de diagramme sans flux organisationnels informants (le transfert de l’avis d’expédition ne dé-
clenche aucun traitement, sa seule utilité est de mettre l’information à disposition des commerciaux) :

Service
Livraison à facturer
factura-
Commande tion
Service Service
commer expédi-
tion Facture
-cial
Réclamation Paiement

Bon de livraison
Client
 Merise | 16

GRAPHE ORDONNE DES FLUX ET TRAITEMENTS.

Règles de construction du graphe ordonné de flux

1. Les flux ne sont pas ordonnés

 Pour représenter un système de flux ordonnés :
 Numérotation des flux
2. Les opérations et les activités ne sont pas décrites
 Ex: on ne dit pas comment le service Facturation s’y prend pour faire une facture
 Certaines conditions logiques ne sont pas décrites
 Formalisme des diagrammes d’activités (UML) ou MCT/MOT (Merise)
3. Les flux entre acteurs extérieurs sont ignorés

A partir de la matrice ou du diagramme des flux, MERISE propose d’ordonner les flux dans un graphe.

Exemple de graphe ordonné des flux conceptuels (la réclamation est supposée provenir d’une erreur de
livraison ou de facturation) :

Commande

Livraison à BL
facturer

Facture

Réclamation
Paiement

Le graphe ordonné permet ensuite de positionner les traitements : le passage d’un flux à un autre néces-
site un traitement (non représenté s’il se situe à l’extérieur de l’entreprise, du domaine ou du processus
étudié) et chaque flux entrant doit être est traité. Un même traitement n’apparaît qu’une fois dans le mo-
dèle.
 Merise | 17

Traitements
Exemple de passage du graphe aux traitements :

Commande

Le même traitement
d’expédition conduit aux deux
Expédition flux résultants

Livraison à
facturer
BL
Ici, en pointillés, les actions
menées hors entreprise (chez le
client), dont seules les
Facturation conséquences sont traitées.

Paiement Réclamation
Facture On ajoute les résultats
mettant fin aux
traitements.

Encaissement
Trait. réclamation

Paiement enregistré
Réclamation traitée
 Merise | 18

IV. LE MODELE CONCEPTUEL DES TRAITEMENTS (MCT)

Le modèle conceptuel des traitements permet de traiter la dynamique du système d'information, c'est-à-
dire les opérations qui sont réalisées en fonction d'événements.
Ce modèle permet donc de représenter de façon schématique l'activité d'un système d'information sans
faire référence à des choix organisationnels ou des moyens d'exécution, c'est-à-dire qu'il permet de définir
simplement ce qui doit être fait, mais il ne dit pas quand, comment ni où...
Un modèle conceptuel des traitements (MCT) peut se déduire du graphe des flux, en y associant des
échéances, des résultats qui ne constituent pas des flux et des règles de gestion. Un modèle conceptuel
des traitements est indépendant de l’organisation de l’entreprise.

LE CONCEPT D'EVENEMENT

Un événement représente un changement dans l'univers extérieur au système d'information, ou dans le

système d'information lui-même.
un événement externe est un changement de l'univers extérieur
un événement interne est un changement interne au système d'information
On représente un événement par une ellipse en trait plein pour les événements internes à l'organisation,
en trait pointillé pour les événements externes.

PROCESSUS
Un processus est un sous-ensemble de l'activité de l'entreprise, cela signifie que l'activité de l'entreprise
est constituée d'un ensemble de processus. Un processus est lui-même composé de traitements regrou-
pés en ensembles appelés opérations.

OPERATION
Une opération est un ensemble d'actions exécutées par le système suite à un événement, ou à une con-
jonction d'événements.
Cet ensemble d'actions est in interruptible, c'est-à-dire que les événements ne sont pas pris en compte
(ils ne sont pas forcément ignorés pour autant) tant que l'opération n'a pas été accomplie.

LA SYNCHRONISATION
La synchronisation d'une opération définit une condition booléenne sur les événements contributifs devant
déclencher une opération. Il s'agit donc de conditions au niveau des événements régies par une condition
logique réalisée grâce aux opérateurs :
OU
ET
NON
 Merise | 19

CONSTRUCTION DU MCT
Le modèle conceptuel des traitements permet de représenter schématiquement la gestion des événe-
ments :

Formalisme

Evènements
-Interne ( résultats précédents )
-Externe ( hors référentiel) :
A B C -Flux ( commande,livraison)
-Temporisation ( 31/12 inventaire)
-Décision arbitraire. Ensemble d’opérations
Déclenché par au
moins un évènement
extérieur
Synchronisation
A ET (B OU C)

Processus
NOM OPERATION Opération

Ensemble des traitements élémen-

taires non interruptible, déclenché
REGLES DE GESTION par au moins 1 évènement et pro-
duisant au moins un résultat.

REGLES D'EMISSION

Résultats
R1 R2 R3
Valeur ajoutée par une opération
- Concret ( création d’objet )
- Abstrait ( pas de création d’objet)
 Merise | 20

METHODE DE CONSTRUCTION
 Identifier les règles de gestion
 Rechercher les ruptures (temps, décision)
 Construire le MCT

EXEMPLE DE MCT

Gestion des approvisionnements

L'acheteur envoie une demande d'approvisionnement aux fournisseurs possibles.

Selon leurs prix, ils choisissent un fournisseur.
Etablissement d'un bon de commande.
Après livraison, contrôle des articles et retour si problème(s).Sinon, articles stockés et bon à payer établi
par le magasin.
A la réception de la facture, si la correspondance facture-bon à payer est bonne alors chèque.
 Merise | 21

Il fait alors choisir un fournisseur

Une fois les articles commandés, on les attend.

 Merise | 22

Une fois les articles commandés, on les attend.

Une fois les articles commandés, on les attend.

 Merise | 23

Si la marchandise est bonne, il faut la payer.

 Merise | 24

V. LE MODELE CONCEPTUEL DES DONNEES (MCD)

Le Modèle Conceptuel de données (MCD) sert à décrire les données du Système d’Information.
Il permet de représenter les données de manière facilement compréhensible à l'aide des concepts d'enti-
tés et de relations.

CONCEPTS

ENTITÉ

Une Entité est un objet abstrait ou concret ayant une existence propre.
Un Entité est porteuse de propriétés.
La propriété est le plus petit élément d'information manipulé par l'entreprise par exemple le nom du sta-
giaire.
La propriété qui permet de repérer une Entité est un identifiant. La valeur de la propriété doit être unique
par exemple le matricule du stagiaire
 Merise | 25

RELATION

Une relation représente une association entre un certain nombre d'Entités (de 1 à n) qui forment sa col-
lection. Elle peut être porteuse de propriétés.
Une relation n'a d'existence que par rapport à celle des Entités.
Elle possède un nom.
L'identifiant d'une relation est la concaténation des identifiants des Entités participant à la relation.

Exemple de relation :

CARDINALITES

La cardinalité d'une relation exprime le nombre de fois où une occurrence d'Entité participe à la
relation.
Cardinalité minimum : c'est le nombre minimum de fois où chaque occurrence d'un Entité participe
à la relation
- une cardinalité minimum est 0 correspond à une relation partielle.
- une cardinalité minimum de 1 signifie qu'une occurrence d'Entité participe nécessairement à la relation
(relation totale).
Cardinalité maximum : c'est le nombre maximum de fois où chaque occurrence d'un Entité parti-
cipe à la relation
- une cardinalité maximum de 1 signifie qu'une occurrence d'Entité participe au plus à 1 occurrence de la
relation.
- une cardinalité maximum de n signifie que toute occurrence d'Entité participe éventuellement à n occur-
rences de la relation.
 Merise | 26

Les relations peuvent être :

unaires : collection d’une Entité

binaires : collection de deux Entités
ternaires : collection de trois Entités, etc.

Exemple de relation unaire

 Merise | 27

Exemple d’une relation binaire de type non père-fils

(Cette relation est la même que la précédente mais avec des cardinalités différentes, elle a donc une
signification différente).

Exemple de relation ternaire

 Merise | 28

Contrainte d’Intégrité Fonctionnelle (CIF)

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.

Exemple

Nous pouvons lire qu’une session est suivie par zéro ou plusieurs stagiaires et qu’un stagiaire suit une et
une seule session. Dans le cas d’une association binaire comme celle-ci, une contrainte d’intégrité fonc-
tionnelle existe à partir du moment où une cardinalité de type 1,1 existe.
 Merise | 29

TECHNIQUES DE MODELISATION

SYNTHESE DES DEMARCHES PRESENTEES

DD = Dictionnaire de données
DF = Dépendances Fonctionnelles
GDF = Graphe de Dépendances Fonctionnelles
 Merise | 30

MODELISATION DIRECTE

Les Entités et les relations sont repérées directement à partir du discours :

 Un nom devient une Entité
 Un verbe devient une relation.

Exemple : Stages de formation à l’ESATIC

L’ESATIC est un établissement d’enseignement supérieur qui organise régulièrement des stages en Tech-
nologies de l’Information et de la Communication (TIC).
Un stagiaire ne peut bénéficier que d’un seul stage pour permettre au plus grand nombre de pouvoir se
former conformément aux désidératas du Gouvernement.
Les stages sont subdivisés en plusieurs modules pour faciliter l’assimilation des différentes notions abor-
dées. Les formateurs de l’ESATIC étant très polyvalents, un formateur peut assurer la formation dans
plusieurs modules.
Représentez le Modèle Conceptuel des Données (MCD) des stages de formation à l’ESATIC

Règle 1 : un stagiaire s’inscrit à un stage

Règle 2 : les stages sont composés de plusieurs modules
Règle 3 : un formateur enseigne plusieurs modules

Entités : stagiaires, stage, modules, formateurs

Relations : s’inscrire, composer, enseigner
 Merise | 31

MODELISATION ASCENDANTE.

Le Dictionnaire de Données (DD)

Le dictionnaire des données est un document qui permet de recenser, de classer et de trier toutes les
informations (les données) collectées lors des entretiens ou de l’étude des documents (Ecrans, Etats,.
Structures des fichiers et des Bases de données existant,…).

Ensuite on épure le dictionnaire (synonymes - noms différents recouvrant la même propriété : salarié et
employé -, polysèmes - même nom pour deux informations différentes : date pour date-facture et date-
commande,...).

Type
Nom de la Règle de Règle de
Format Longueur Elémen- Calculé Document
donnée calcul gestion
taire

Nom de la donnée
Cette cellule recevra une donnée par exemple : Nom client.

Format
Ici sera indiqué le format de la donnée.
Format génériques des données
 Le type alphabétique (rien que des caractères).
 Le type alphanumérique (des caractères, des chiffres…).
 Le type numérique (les nombres).
 Le type date.
 Le type logique (0-1,Vrai-Faux,
 Oui-Non).

Longueur
La longueur approximative ou exacte de la donnée sera indiquée, par exemple : 30.
 Merise | 32

Type
Une croix sera inscrite dans la colonne pour indiquer si la donnée est élémentaire ou calculée.

Règle de calcul
Ici sera indiquée de manière claire la formule ou le calcul nécessaire à appliquer pour obtenir la donnée.

Règle de gestion
Dans cette zone sera indiquée, si nécessaire, la règle de gestion inhérente à la donnée.

Document
La rubrique document permet de saisir le document dans lequel a été trouvée la donnée.

Les dépendances fonctionnelles (DF)

Dépendance fonctionnelle : il y a dépendance fonctionnelle entre deux propriétés lorsque la connaissance

d'une valeur d'une propriété P1 permet de déterminer une et une seule valeur d'une autre propriété P2.
On dit que P2 dépend fonctionnellement (ou est en dépendance fonctionnelle) de P1.
la dépendance fonctionnelle est notée P1 --> P2;
exemple : codeclient ---> nomclient ;

En revanche nomclient ne détermine pas le code client.

Dépendances fonctionnelles composées

Une dépendance fonctionnelle qui comporte plusieurs attributs est dite composée.

Voici un exemple de dépendance fonctionnelle composée :

(Numéro Coureur, Numéro course) → (temps)
Connaissant le numéro du coureur et le numéro de la course, nous connaissons de façon certaine le
temps chronométré d’un coureur précis sur une course précise.

Dépendance fonctionnelle élémentaire

Une dépendance fonctionnelle A → B est élémentaire s’il n’existe pas une donnée C, sous-ensemble
de A, décrivant une dépendance fonctionnelle de type C → B

Par exemple :
RéférenceProduit → Désignation
NuméroCommande, RéférenceProduit → Quantité
NuméroCommande, RéférenceProduit → Désignation
La première dépendance fonctionnelle est correcte car ayant deux rubriques elle est élémentaire.
 Merise | 33

La deuxième dépendance fonctionnelle est correcte également car la connaissance d’un numéro de com-
mande et d’une référence produit nous permet de connaître la quantité commandé du produit. Elle est
aussi élémentaire car c’est la connaissance du couple (NuméroCommande, RéférenceProduit) et pas
seulement d’un des éléments qui permet la connaissance de la quantité.

La troisième dépendance fonctionnelle n’est pas élémentaire car il existe à l’intérieur d’elle RéférencePro-
duit →Désignation qui était déjà une dépendance fonctionnelle élémentaire. Pour connaître la Désigna-
tion, NuméroCommande est dans ce cas superflu.

Dépendance fonctionnelle élémentaire directe

On dit que la dépendance fonctionnelle A → B est directe s’il n’existe aucun attribut C tel que l’on puisse
avoir A → C et C → B. En d’autres termes, cela signifie que la dépendance fonctionnelle entre A et B ne
peut pas être obtenue par transitivité.

Exemple : Dans l’hypothèse d’une classe avec un seul élève

NumClasse → NumElève
NumEleve → NomElève
NumClasse → NomElève

La troisième dépendance fonctionnelle n’est pas directe car nous pourrions écrire :
NumClasse → NumElève → NomElève

Méthodologie d’élaboration des dépendances fonctionnelles

L’élaboration des dépendances fonctionnelles est réalisée à l’aide du dictionnaire des données. La dé-
marche consiste à rechercher :

 les dépendances fonctionnelles formées par deux rubriques, élémentaires et directes ;

 les dépendances fonctionnelles composées.

Graphe des dépendances fonctionnelles (GDF)

Le graphe des dépendances fonctionnelles épure le dictionnaire en ne retenant que les données non
déduites et élémentaires et il permet une représentation spatiale de ce que sera le futur modèle concep-
tuel des données.

Il s'agit d'ordonner, pour avoir une vision synthétique, le résultat de l'analyse des DF faite précédemment.
 Merise | 34

Modèle conceptuel des données brut

A partir du GDF on établit le MCD brut.

Les principes de base sont :

1- Les ‘arbres’ donnent les Entités

2- Les sommets des 'arbres' donnent les identifiants
3- Les feuilles donnent les propriétés
4- Les ‘concaténations’ donnent les relations de type non Père-Fils
5- Les Df inter-sommets donnent les DF ou CIF inter-Entités
6- Une propriété ayant plusieurs sommets devient une Entité
 Merise | 35

NORMALISATION

La normalisation a pour objectif d'éliminer les redondances dans la base ainsi que les anomalies de mise
à jour.

Les Entités et les relations porteuses de propriétés doivent vérifier les règles suivantes :

Première forme normale (1ère FN)

 Toutes les propriétés sont élémentaires et il existe un identifiant. Sinon on décompose une pro-
priété en plusieurs propriétés et/ou on crée une propriété identifiante.

 Les propriétés sont non répétitives

Exemple de 1ère FN

V
V
 Merise | 36

Deuxième forme normale (2FN)

Une Entité ou une relation est en 2FN si

 Elle est en 1FN

 Toute propriété dépend de l'identifiant par une dépendance fonctionnelle (DF) élémentaire.
Donc chaque propriété dépend de tout l'identifiant et non pas d'une partie.
Sinon on décompose en plusieurs Entités.

Exemple de 2ème FN

Modélisation qui n'est pas en 2ème FN

Il existe une dépendance fonctionnelle entre IdIntervenant et TypeIntervenant

Il existe une dépendance fonctionnelle entre IdIntervenant, IdAnnee et TotalCommission
 Merise | 37

Type Intervenant

Troisième forme normale (3FN)

Une Entité ou une relation est en 3FN si

 Elle est en 2FN

 Toute propriété doit dépendre de l'identifiant par une DF directe.

Donc tous les attributs non identifiants sont indépendants entre eux.
Sinon on décompose en deux Entités.

Exemple de 3 FN

Modélisation qui n'est pas en 3FN

Modélisation en 3FN
 Merise | 38

3
Exemple : construction du MCD à partir d'un bon de commande

N°Bon______ Date______
Code client ____________
Nom__________________
Adresse________________________________
Nom Vendeur __________

Réf Libellé Quantité Prix Montant

___ ________ _______ ___ _______
___ ________ _______ ___ _______
___ ________ _______ ___ _______

Total______
 Merise | 39

Après avoir établi le DD et la liste des DF on obtient le GDF suivant

IdCmde IdProduit

Qté

Nom vendeur Date Cde IdClient Libellé produit Prix

Nom client Adresse

Le MCD correspondant est le suivant

 Merise | 40

VI. MODELE ORGANISATIONNEL DE TRAITEMENT

Le modèle organisationnel des traitements s'attache à décrire les propriétés des traitements non traitées
par le modèle conceptuel des traitements, c'est-à-dire :
 le temps
 les ressources
 le lieu

Le modèle organisationnel des traitements consiste donc à représenter le modèle conceptuel des traite-
ments dans un tableau dont les colonnes sont la durée, le lieu, les responsables et ressources nécessaires
à une action.

POINT DE DEPART
Les règles de gestion définies dans le nouveau MCT, les nouvelles règles d'organisation :
- quel poste de travail assure le traitement ? (QUI ?)
- contraintes de temps dues à l’organisation? (QUAND ?)
- traitement manuel ou automatisé ? (COMMENT ?)
Le MOT est plus précis que le schéma de circulation de documents vu dans l’analyse de l’existant.

PROCEDURE

Chaque opération conceptuelle du MCT est décomposée en un ensemble de phases.

Phase
Phase : ensemble de tâches dont l’enchaînement est « non interruptible » compte tenu de l’organisation
mise en place. Toutes les tâches d’une phase se déroulent
– sur un même poste de travail (unité de lieu),
– à un moment déterminé (unité de temps),
– avec des moyens homogènes - manuel ou automatique - (unité d'action).
Ex : chaque jour à 16h le secrétariat exécute la phase ‘saisie du dossier de candidature’ sur micro; liste
des tâches : saisie des données, m.à.j. du fichier informatique ‘Candidatures’, classement du dossier pa-
pier.

Poste de travail
Le poste de travail est caractérisé par :
- une fonction à assurer (gestion des stocks …),
- un lieu géographique,
- un ensemble de moyens/ressources (personnel, matériel).
Similaire aux acteurs du modèle acteurs/flux.
 Merise | 41

La nature du traitement:
- manuel,
- conversationnel (traitement unitaire immédiat),
- par lots ou ‘batch’ (traitement différé d’un lot de données).

La période d’exécution
Des contraintes de temps dues à l’organisation sont introduites (date, durée…).
Ex: chaque jour à 17h, édition des factures.

Événement
En plus des événements conceptuels on ajoute les événements organisationnels.
- événements de déclenchement de phase.
Ex: date d’exécution d’une tâche.
- événements internes traduisant des liens entre phases (événements intermédiaires, états
d’attente).
Ex: dossier saisi.

Autres concepts (synchronisations, règles d’émission)

Identiques au MCT; prennent en compte les règles d’organisation.

 Merise | 42

FORMALISME
 Merise | 43

EXEMPLE DE MOT

Gestion des sinistres dans une assurance

A l'arrivée d'une déclaration d'accident, le responsable du service gestion des sinistres (QUI) décide de la
recevabilité et note son avis sur la déclaration.
Il transmet la déclaration annotée au secrétariat du service qui saisit les éléments essentiels sur ordina-
teur.

En fin de journée(QUAND), on édite les demandes d'expertise et les notifications de refus.

Au retour de l'expertise, quelques jours plus tard, on enregistre sur un terminal(COMMENT) la réponse
de l'expert. On classe la réponse dans le dossier assuré.
Au retour de la facture du garage, on vérifie si le rapport de l'expert est arrivé; on enregistre la facture et
on édite immédiatement le chèque destiné au client.

Tableau de décomposition en phases:

 Merise | 44

MOT
 Merise | 45

Fiche de description de phase

 Merise | 46

VII. LE MODELE LOGIQUE DE DONNEES

Le Modèle Logique des Données (MLD) est une étape intermédiaire pour passer du modèle E/A, qui
est un modèle sémantique, vers une représentation physique des données : fichiers, SGBD hiérarchique,
SGBD réseau, SGBD relationnel.
Nous nous limitons au seul MLD relationnel, qui prépare le passage aux SGBD relationnels.

RÈGLES DE TRANSFORMATION DU MCD AU MLD (MRD)

Nous allons définir les règles de transformation pour le passage du MCD au MLD, en respectant les dif-
férents cas qui se posent.

Transformation des entités

Toute entité est transformée en table. Les propriétés de l'entité deviennent les attributs de la table. L'iden-
tifiant de l'entité devient la clé primaire de la table.

Exemple:

Transformation des relations binaires du type (x,n) – (x,1)

Afin de représenter la relation, on duplique la clé primaire de la table basée sur l'entité à cardinalité (x,n)
dans la table basée sur l'entité à cardinalité (x,1). Cet attribut est appelé clé étrangère. Les deux tables
sont liées par une flèche nommée selon la relation, qui pointe de la table à clé étrangère vers la table qui
contient la clé primaire correspondante.
 Merise | 47

Exemple
:

L'attribut No_Auteur qui est clé primaire de la table Auteur, devient clé étrangère dans la table Livre.

Transformation des relations binaires du type (x,1) – (x,1) [x=0 ou 1]

Nous devons distinguer plusieurs cas. Sachant qu'une relation binaire du type (1,1)-(1,1) ne doit pas exis-
ter il nous reste les 2 cas suivants:

Relation binaire (0,1)-(1,1)

On duplique la clé de la table basée sur l'entité à cardinalité (0,1) dans la table basée sur l'entité à cardi-
nalité (1,1).

Exemple :

Le No_Client, qui est clé primaire de la table Client, devient clé étrangère dans la table
Carte_Membre.
 Merise | 48

Relation binaire (0,1)-(0,1)

On duplique la clé d'une des tables dans l'autre. Lorsque la relation contient elle-même des propriétés,
celles-ci deviennent également attributs de la table dans laquelle a été ajoutée la clé étrangère.

Exemple :

Soit on migre la clé primaire de la table Entreprise dans la table Salarié, soit on fait l'inverse.
 Merise | 49

Transformation des relations binaires du type (x,n) – (x,n)

On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires des 2
tables. Lorsque la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table
supplémentaire.

Exemple :

On crée une table Porter, qui contient comme clé primaire une clé composée de No-Commande et
Code_Article. Elle contient également la propriété Quantité issue de la relation Porter.

Transformation des relations ternaires

On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires de
toutes les tables reliées. Cette règle s'applique de façon indépendante des différentes cardinalités. Lors-
que la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire.

Exemple :

La table Enseigner contient une clé composée de No_Enseignant, Code_Matière et Nom_Classe.

Transformation de plusieurs relations entre 2 entités

 Merise | 50

Les règles générales s'appliquent

Exemple:

La relation habiter du type (x,n)-(x,1), est traduite par la migration de l'attribut Adresse dans la table Per-
sonne. La relation posséder du type (x,n)-(x,n) est traduite par la création d'une table supplémentaire du
même nom. Cette table contient comme clé primaire composée, les clés des deux tables reliées Personne
et Maison. On a donc simplement appliqué 2 fois de façon indépendante les règles de transfert MCD 
MLD.
 Merise | 51

Transformation des relations réflexives

Nous appliquons les règles générales avec la seule différence que la relation est 2 fois reliée à la même
entité

Exemple 1:

Comme il s'agit d'une relation (x,n)-(x,n), une table supplémentaire est créée. Cette table contient comme
clé primaire composée, la clé des "deux" entités reliées. Comme la même entité est liée 2 fois à la relation,
on ne peut pas utiliser 2 fois le même nom pour la clé. Dans ce cas il convient d'utiliser des rôles dans le
MCD, et d'intégrer le rôle dans le nom d'une des clés migrées dans le MLD.

Exemple 2:

Comme il s'agit d'une relation (0,1)-(0,1), nous avons en général le choix en ce qui concerne quelle entité
contiendra la clé étrangère. Comme cette relation est liée deux fois à la même entité, il est évident que
nous devons dupliquer la clé primaire, tout en veillant que le même nom de clé ne sera pas utilisé pour la
clé primaire et la clé étrangère. Dans notre exemple, tous les hommes mariés, ont comme valeur de la clé
étrangère la matricule de leur épouse actuelle. Pour les hommes non mariés et les femmes, la clé étran-
gère est sans valeur. On pourrait bien sûr utiliser la modélisation inverse avec une clé étrangère NO_MA-
TRICULE_MARI, qui indique pour chaque femme mariée, la matricule de son mari.
 Merise | 52

RÉCAPITULATIF :

Représenter une association binaire 1,1 - 1,n

MCD

MRD

ENTITE_1(E1_Identifiant, #E2_Identifiant, E1-Propriété_1, E1-Propriété_2)

ENTITE_2(E2_Identifiant_2, E2_Propriété_1, E2_Propriété_2)

Représenter une association binaire (0 ou 1) , n - (0 ou 1), n non por-

teuse de propriétés :

MCD

MRD

ENTITE_1(E1_Identifiant, E1-Propriété_1, E1-Propriété_2)

ENTITE_2(E2_Identifiant_2, E2_Propriété_1, E2_Propriété_2)
ASSOCIATION(#E2_Identifiant_2, #E1_Identifiant_1)
 Merise | 53

Représenter une association binaire 1,1 - 0,1 :

MCD

MRD

ENTITE_1(E1_Identifiant, #E2_Identifiant_2 E1-Propriété_1, E1-Propriété_2)

ENTITE_2(E2_Identifiant_2, E2_Propriété_1, E2_Propriété_2)
 Merise | 54

Représenter une association ternaire 0,n - 0,n - 0,n :

MCD

MRD

ENTITE_1(E1_Identifiant, E1-Propriété_1, E1-Propriété_2)

ENTITE_2(E2_Identifiant_2, E2_Propriété_1, E2_Propriété_2)
ENTITE_3(E3_Identifiant, E3_Propriété_1, E3_Propriété_2)
ASSOCIATION(#E2_Identifiant_2, #E1_Identifiant_1, #E3_Identifiant)