MERISE: Les Principes de Base

• VUE DU S.I. A TRAVERS UNE

APPROCHE SYSTEMIQUE
• APPROCHE PAR NIVEAUX
• APPROCHE DONNEES-TRAITEMENTS
• MODELISATION
• LA DEMARCHE PAR ETAPES…

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Approche par niveaux
Les quatre niveaux de description ou niveaux
d’abstraction:

• NIVEAU CONCEPTUEL: Ce qu’il faut faire

• QUOI ?
• NIVEAU ORGANISATIONNEL: La manière de faire
• QUI ?, QUAND ?, COMBIEN ?, OU ?
• NIVEAU LOGIQUE: Choix des moyens et ressources
• AVEC QUOI ? QUELS OUTILS ?
• NIVEAU PHYSIQUE: Les moyens de le faire
• COMMENT ?

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Niveaux d’abstraction
Etat ancien Etat futur

Niveau MCD, MCT

conceptuel

Niveau MOD, MOT

organisationnel

Niveau MLD, MLT

logique

Niveau Tables, code

physique système physique

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Exemple : assurance auto
• Conceptuel
– Le client effectue une demande de service à la compagnie pour
assurer son véhicule. Cette dernière lui propose un devis
• Organisationnel:
– Un client effectue une demande de service à l’agence de son choix,
par courrier, pour assurer un véhicule. Un agent de service
concerné, si le client est fiable (consultation d’un fichier central
inter assurances), prend contact par téléphone pour une visite à
domicile (après 17 heures) afin d’examiner plus précisément ses
besoins et établir un devis
• Technique
– Le fichier central inter assurances est accessible par internet. Les
agences sont connectées au siège de la compagnie par liaison
ADSL. Chaque agence dispose de micro-ordinateurs Pentium 256
Mo et peut traiter ses données en local grâce au SGBD Access
M. Hamzaoui Informatique de gestion, économie et gestion, 2005.
 Les Modèles
au niveau Organisationnel/Logique
• Le Modèle logique de données: M.L.D.
– Le modèle CODASYL si une orientation base de
données réseau est choisie
– Le modèle RELATIONNEL si une orientation base de
données relationnelle est choisie
– Le modèle HIERARCHIQUE
• Le Modèle Organisationnel des Traitements: M.O.T
– permet de représenter par procédure les phases et les
tâches effectuées par chaque poste de travail

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Les Modèles
au niveau Physique ou Opérationnel

• Le Modèle Physique des Données : M.P.D

• spécifie les organisations physiques de données

• Le Modèle Physique des Traitements: M.P.T

• décrit les traitements réalisés pour chaque
transaction (temps réel) ou chaque unité de
traitement (temps différé)

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 L e s C o n c e p t s d e M E R IS E
N iveau de Concepts M anipulés
description
D onnées Traitem ents
C o n c e p tu e l ? Entité/ Processus
Individu O pération
? Évènement/
? A ssociation Résultat
? Propriétés ? Synchronisation
? Contrainte
M .C .D
? Règles de gestion
M .C .T
Organisationnel ? Modèle relationnel Procédure
/ Logique Tables, Attributs
? Modèle Codasyl Phase
Record, Champs, Set Tâche
? Modèle hiérarchique
M .L . D M .O .T
? Tables, ? Record,
Physique/ Tuple, Article,
A p p lication
Opérationnel A ttribut Champs, U n ité de traitem e n t
s Set ? Temps réel :
? Langage ? Langages Transaction
S Q L spécifiques
S G B D ? Temps différé :
Programme Batch
M .P.D M .P . D M .P .T .

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Validation: Niveaux et Modèles

Modèles
Niveaux
DONNEES TRAITEMENTS
Conceptuel Modèle Conceptuel des Activités
(MCA)
MCD Validation MCT

Organisationnel Validation
MOD MOT

Logique MLD Validation MLT

Physique/ Validation
MPD MPT
Opérationnel

Trois voies de validation

? Par les règles de gestion
? Mise En Cohérence des modèles
? Description des Evènments/Résultats
M. Hamzaoui Informatique de gestion, économie et gestion, 2005.
 Exemple :
Description de la mise en place d’un prêt

• Un client se présente dans une agence de la banque pour

demander des informations sur les prêts
• Il est reçu par un agent commercial avec lequel il dialogue
sur son besoin
• L’agent commercial, après étude des différentes formules,
lui établit un devis qui n’a pas de valeur contractuelle
• Le devis peut être modifié plusieurs fois, jusqu’à ce que le
client soit satisfait ou abandonne son idée d’emprunt
• Lorsque le client est décidé, il effectue une demande de
prêt

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Exemple (suite):
Description de la mise en place d’un prêt

• Après consultation d’un organisme de

surveillance, l’agent commercial refuse ou établit
une proposition, à caractère contractuel
• Le client dispose d’un délai de réflexion avant
d’accepter la proposition
• Après acceptation, le service administratif met en
place le prêt: demande d’hypothèque auprès d’un
notaire, information de l’organisme de tutelle,
comptabilisation de l’échéancier, déblocage des
fonds
• Le client rembourse le prêt à chaque échéance

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 MCD: Objectifs

• Le MCD ou modèle Entité/Association

– est un modèle chargé de représenter sous forme
graphique les informations manipulées par le système
(l’entreprise)
– décrit les données gérées sans tenir compte des choix:
• d’organisation, d’automatisation, ou techniques
– décrit les choix de gestion en précisant la signification
des invariants, leur structure et leurs liens
– exprime le QUOI sur les données
C/C : Le MCD fournit une image invariante du
SI en termes de données
M. Hamzaoui Informatique de gestion, économie et gestion, 2005.
 Que raconte le schéma ?
Acteurs internes Ordre de livraison Acteurs externes
MAGASIN Bon de livraison TRANSPORTEUR

Dde de facturation Demande de livraison

CLIENT
FACTURATION Facture

Chèque_ Bordereau
Double facture

CAISSE BANQUE
Bordereau de remise de chèque

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 ASSOCIATION: Les cardinalités

Un cours est enseigné par au moins un enseignant (1,…) ou par plusieurs (…,n)

ENSEIGNANT Enseigner 1,n COURS

Nom 0,n Type_Ens Num_Cours
Prénom Titre_Cours
Âge ….
…

Un enseignant peut n’enseigner aucun cours (0,…), ou plusieurs (…,n)

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 ASSOCIATION: Les contraintes

• Certaines contraintes ne sont pas représentables par le seul formalisme

de base (entité, association, propriétés, cardinalités) mais correspond à
une règle que doit satisfaire le modèle pour être fidèle et cohérent avec
l ’activité à représenter
• Exemple: Pour une période d ’emploi du temps, un professeur ne fait
un cours que dans une seule salle (CIF)
• Typologie des contraintes:
– contraintes d ’intégrité fonctionnelle (CIF)
– contrainte ensembliste
– contrainte de valeur
– contrainte structurelle
– options de gestion

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Types de contraintes

Il y a en general deux sortes de contraintes à exprimer :

- la première porte sur des ensembles (on parle alors de

contraintes ensemblistes)
ensemblistes et correspond aux propriétés suivantes :

T X = P U ©

totalité exclusion égalité partition unicité inclusion

- la seconde porte sur des fonctions (on parle de contraintes

procédurales)
durales à vérifier.

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Les contraintes ensemblistes:
Exemple
PERSONNE DEPOSER DEMANDE PRET
0,n 0,1

0,n T

REMBOURSER PRET
0,1

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Les contraintes ensemblistes:
Exemple
Soit:
– Les personnes qui ont établi une demande de prêt
– Les personnes qui remboursent des prêts
• Ces 2 sous ensembles peuvent imposer des
contraintes entre eux:
– Toutes les personnes déposent et/ou remboursent un prêt: ou
inclusif (Totalité)
– Aucune personne ne peut déposer une demande et rembourser un
prêt: exclusion
– Toute personne, soit dépose une demande de prêt, soit rembourse
un prêt: la partition
– Toute personne remboursant un prêt a déposé une demande :
l’inclusion (indiquer le sens de lecture par une flèche)
M. Hamzaoui Informatique de gestion, économie et gestion, 2005.
 Normalisation
• Les formes normales s’appliquent aux entités et aux relations
• Elles ont pour objectif de vérifier la non redondance de
l ’information dans le modèle et de proposer les
transformations applicables sans perte d ’informations
• 1ere forme normale:
– Une entité ou une association ne contient pas de propriété répétitive
ou décomposable
• 2ème forme normale (pas de dépendance partielle)
– Toute propriété non identifiante dépend de la totalité de l ’identifiant
• 3ème forme normale (pas de dépendance transitive)
– Toute propriété non identifiante dépend directement de l ’identifiant,
et non d’une propriété non identifiante

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Méthodologie de construction du MCD:
à partir du Dictionnaire de Données (DD)
1. Analyse de l’existant et constitution d’une ébauche de DD
2. Epuration des polysèmes
3. Epuration des synonymes
4. Dégager les entités naturelles grâce à leur identifiant
5. Rattacher à ces entités leurs propriétés grâce aux DF (agrégation)
6. Placer les infos restantes dans ces associations entre ces entités
7. Etudier les associations non porteuses d’informations
8. Placer les cardinalités
9. Simplifier le modèle à l’aide des CIF
dictionnaire
10. Contrôler le modèle produit
schéma +
M. Hamzaoui Informatique de gestion, économie et gestion, 2005.
 Exercice
Le recensement de propriétés concernant un compte client a permis de
relever les phrases suivantes:
• Un client est identifié par un numéro, un nom, une adresse. Si un client
est une personne physique, on se renseigne sur son pays de naissance
et sa date de naissance; si le client est une personne morale, on se
renseigne sur son code Entreprise et N° de CNSS. Tout client possède
1 à plusieurs comptes.
• Un compte est identifié par un numéro et possède un nom, un solde et
une date d ’ouverture. Il est lié à 1 ou plusieurs produits (chèque, carte
bancaire,…). Un produit est décrit par un numéro, un nom, un prix
unitaire. Un compte est rattaché à un et un seul client.
• L ’ouverture d ’un compte est provoquée par une demande de produit,
pour une quantité précise, à une date donnée.
• D. NANCI, B. ESPINASSE, « Ingéniérie des systèmes d’information :
Merise ; deuxième génération », 4e édition, Editions Vuilbert, 2001,
ISBN 2-7117-8674-9
M. Hamzaoui Informatique de gestion, économie et gestion, 2005.
 Univers du discours --> MLD
XXXX YYYY
1,n 0,n
Représenter AAAA
Domaine

Modèle Conceptuel
Traduire
Implémenter YYYY
XXXX
PK_YYYY
PK_XXXX
ID_Y
ID_X
Ordinateur AAAA
PK_AAAA
ID_X
ID_Y

Modèle Logique
M. Hamzaoui Informatique de gestion, économie et gestion, 2005.
 Modèle relationnel (Codd 1973)
• Un modèle est dit relationnel dans la mesure où il permet
de parcourir la structure des données empruntant des
chemins non prédéfinis, constitués en dynamique par des
requêtes
• Les concepts du modèle relationnel découlent de la théorie
des ensembles
• A ce type de modèle sont associées les notions suivantes:
– domaine
– table relationnelle
– attribut
– tuple (ou n-uplet)

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

 Exemple :
Pour des motivations différentes, des abonnés s’inscrivent dans des
rubriques pour recevoir de manière périodique des newsletters. La
pratique a montré qu’une newsletter ne peut contenir qu’une et une
seule rubrique. Il vous est demandé le MCD, MLD et MPD.
Aide :
- Définir les entités ( tables =relations) et associations. Pour chaque
entité, on vous donnera le choix de proposer les T-uples (formés
d’attributs = propriétés pour les entités)
- Les cardinalités
- Clés primaires (identifiant pour les entités)

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

• Solution : Newsletter

Entraîne le MLDR suivant :

MOTIVATIONS ( id_Motivation, Intitule)

ABONNES ( id_Abonne, #id_Motivation, Nom, Prenom, Age, Sexe, Profession,
Rue, CodePostal, Ville, Telephone, Email)
S_INSCRIT ( id_Abonne, id_Rubrique)
RUBRIQUES ( id_Rubrique, Nom_Rubrique)
NEWSLETTERS ( id_Newsletters, #id_Rubrique, Sujet, DateEnvoie, Contenu)
M. Hamzaoui Informatique de gestion, économie et gestion, 2005.
 MPD:

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.

• CONCLUSION
Les 6 règles représentent TOUS les cas que vous pourrez
rencontrer. Il ne faut surtout pas se laisser impressionner
par le nombre de schémas, ni se laisser intimider par le
coté inhabituel du processus de modélisation. Il est très
simple à acquérir. En fait, au bout de quelques
modélisations et d'un ou deux développements, vous vous
rendrez compte que finalement tout ceci est très logique et
d'une évidence rare... Et surtout, surtout, votre base de
donnée correspondra EXACTEMENT au système
d'information décris dans le cahier des charges. De plus,
écrire le MCD, le valider avec votre client, puis en déduire
le MLDR et donc le Modèle Physique vous fera rentrer
complètement dans le chantier. Après, la majorité du
travail restant ne sera plus qu'une question de requêtes, de
mise en forme et d'ergonomie, avec une bonne gestion
d'Entrée/Sortie de l'information...
Bonne Chance

M. Hamzaoui Informatique de gestion, économie et gestion, 2005.