La methode Merise

La méthode MERISE
 La méthode MERISE
A) cycle d’abstraction :
Définir les principaux concepts manipulés par l’organisation aux 3 niveaux:
Niveau conceptuel :
 Correspond à la définition des finalités de l’entreprise en explicitant sa raison d’être.
 Traduit, à travers un ensemble de règles de gestion, les objectifs et les contraintes qui
pèsent sur l’entreprise.
• A pour but la formalisation des données et traitements nécessaires au SI sans aborder
les aspects d'organisation.
Réponse à la question : QUOI ?
Niveau Organisationnel
 Définir l’organisation qu’il est souhaitable de mettre en place dans l’entreprise pour
atteindre les objectifs visés.
• Apporter à la formalisation conceptuelle les notions de temps, de lieux et d'acteurs,
Réponse aux questions : QUAND ? OU ? et QUI ?
Niveau Technique
 Sont intégrés les moyens techniques nécessaires au projet. Ils s’expriment en termes de matériels
ou de logiciels
• Définir les solutions techniques répondant aux besoins soulevés lors des étapes précédentes. Il
Réponse à la question : COMMENT
 Niveau conceptuel
A) cycle d’abstraction :
Définir les principaux concepts manipulés par l’organisation aux 3 niveaux:
MODÈLES
NIVEAUX
DONNÉES
TRAITEMENTS
CONCEPTUEL
Modèle conceptuel MCD
Modèle conceptuel
MCT
ORGANISATIONNEL
Modèle logique
MLD
Modèle organisationnel MOT
OPÉRATIONNEL
Modèle physique
MPD
Modèle opérationnel MOPT
Modèle Conceptuel de Traitement
(MCT)
 Son objectif est la description de la transformation des
informations.
 Se base sur plusieurs notions :
• Activité : décrit perception globale du fonctionnement du
système, et est, par le fait, complexe.
• Traitement : décrit l’un des composants de l’activité du
système.
• Action : décrit une fonctionnalité atomique dans un
traitement (consultation, mise à jour…).
4
Modèle Conceptuel de Données (MCD)
Quand : dans l’´etude préalable : MCD de l’existant et ébauche du MCD de la
nouvelle solution ; dans l’´etude détaillée : MCD complet de la nouvelle
solution.
Préalable : avoir explicité les règles de gestion, avoir établi un diagramme des
flux, avoir construit un dictionnaire des données
Caractéristiques : Représentation graphique des données à un niveau
conceptuel, c’est-`a-dire, sans se préoccuper ni des contraintes d’organisation,
ni du gestionnaire de bases de données utilisé, ni des traitements ;
Particulièrement adapté aux Bases de Données relationnelles.
MCD Merise : correspond au modèle Entité - Association.
 Version simple:
Modèle de données Entité-Association
 Concepts utilisés:
1 - ENTITE :
Concept :
- pourvu d'une existence propre
- conforme aux besoins de gestion de l'entreprise
Il peut représenter une notion concrète : CLIENT
ou une notion abstraite : COMPTE CLIENT
Synonymes : INDIVIDU, OBJET
2- ASSOCIATION :
Lien sémantique entre deux ou plusieurs entités.
Le lien n'est pas orienté : les commandes comportent des produits
veut dire également que les produits peuvent être commandés.
Souvent nommé par un verbe ou un substantif.
Synonyme : RELATION
 Concepts utilisés (Suite):
3- PROPRIETE :
Donnée élémentaire permettant de décrire une entité ou une association.
Cette donnée peut se mesurer par une valeur.
Synonyme : ATTRIBUT
REGLES DE BASE
Une même propriété ne peut pas figurer sur deux objets différents
Une entité possède au moins une propriété (son identifiant : par exemple le N° de
commande)
Une association peut ne pas avoir de propriétés
 Concepts utilisés (Suite):
Le schéma "en épaisseur"
 Les cardinalités:
La cardinalité est une notion OBLIGATOIRE du modèle qui permet de résoudre la
question de l'anomalie de la commande 1246 qui aurait pris la liberté de ne point
comporter de produits.
C'est donc l'expression d'une CONTRAINTE (une "loi") perçue sur le monde, et
que l'on écrit dans le modèle. Par exemple, "il n'est pas possible qu'une commande
ne concerne aucun produit".
Comme il s'agit d'exprimer des lois, on ne peut pour ce faire qu'utiliser une autre loi.
POUR UNE OCCURRENCE DE CETTE ENTITE, combien y a t'il d'occurrences de
l'association auxquelles cette occurrence d'entité participe, au plus et au moins ?
 Les cardinalités (Suite):
Pour calculer la cardinalité, se POSITIONNER sur l'entité concernée
et regarder EN FACE combien de fois l'une de ses occurrences
participe à l'association.
Puis se DEPLACER du côté de l'autre entité et faire la même chose
dans l'autre sens.
CARDINALITES MINIMUM :
Valeur
Définition
Exemple
O
Une occurrence de l'entité peut exister
sans participer à l'association
un produit peut ne pas être
commandé
1
Une occurrence de l'entité participe
nécessairement au moins une fois à une
occurrence d'association
toute commande concerne au
moins un produit
 Les cardinalités (Suite):
CARDINALITES MAXIMUM :
Valeur
Définition
Exemple
1
Une occurrence de l'entité
participe au plus une fois
un employé travaille au plus
dans un service
N
Une occurrence de l'entité peut
participer plusieurs fois
une commande peut concerner
plusieurs produits
CONFIGURATIONS POSSIBLES :
O,1
Une occurrence participe au moins 0 fois et au plus 1 fois à l'association
1,1
Une occurrence participe exactement 1 fois à l'association
0,N
Une occurrence peut ne pas participer ou participer plusieurs fois
1,N
Une occurrence participe au moins 1 fois, voire plusieurs
 Les cardinalités (Suite):
RELATIONS OBLIGATOIRES
Notation E-A
1,1 <-> 1,1
1,N <-> 1,N
Explication
TOUTE occurrence de A a un
homologue UNIQUE parmi les
occurrences de B et
réciproquement
TOUTE occurrence de A a AU
MOINS un homologue parmi
les occurrences de B et
réciproquement
Relation ensembliste
 Les cardinalités (Suite):
RELATIONS OPTIONNELLES
Notation E-A
0,N <-> 0,1
1,N <-> 0,N
Explication
UNE occurrence de A peut avoir 0,1,N
vis-à-vis.
UNE occurrence de B est limitée à 0 ou
1 homologue
TOUTE occurrence de A a AU MOINS un
homologue.
Mais UNE occurrence de B peut ne pas
en avoir, en avoir 1 ou plusieurs.
Relation ensembliste
 Les identifiants
IDENTIFIANT D’ENTITE :
Propriété PARTICULIERE de l'entité telle que pour chacune des valeurs de cette
propriété, il existe une occurrence UNIQUE de l'entité.
IDENTIFIANT D'ASSOCIATION :
Une association N'A PAS D'IDENTIFIANT explicite : l'association dépend des
entités qu'elle relie.
Son identifiant se déduit par calcul du produit cartésien des identifiants des
entités associées.
Remarques
Dans le 1er modèle la commande n'a pas d'existence propre : elle est vue comme
un pur événement qui associe un client et un produit. On ne lui a pas attaché de
description (comme une date par exemple) bien que ceci aurait été possible.
Cela veut dire que la commande n'est pas en tant que telle "un objet de gestion"
dans ce système. Il peut s'agir d'une partie du système d'information pour les
ateliers de production de l'entreprise qui s'intéressent principalement a la
fabrication du produit. Ils ont simplement besoin de savoir que les produits, une
fois fabriqués sont destinés à certains clients : il suffit de savoir qui achète quoi.
Dans le second modèle au contraire, la commande est un objet central et c'est
pourquoi elle est identifiée : pour le moins on souhaite mémoriser ces
commandes, les retrouver EN TANT QUE TELLES et les distinguer. Peut être
sommes nous dans un service financier ou au service des livraisons.
Remarques
On peut tirer de ce petit exemple une leçon de modélisation essentielle : pour un
"problème" donné (des clients, des commandes et des produits), il n'existe pas
une "solution" unique qui soit correcte. La conception n’est pas une science exacte
pour 2 raisons :
* Tout d'abord le résultat dépend de l'objectif que l'on poursuit : quels
sont les BESOINS en information ? Autrement dit quel est le PROJET visé par le
système d'information ?
sur le
* Ensuite, un modèle exprime nécessairement un certain POINT DE VUE
monde.
Par conséquent, l'exigence minimale de tout concepteur est d'indiquer le point de
vue à partir duquel il parle, de façon à ce que ses lecteurs puissent le discuter.
Conséquences :
- le "BON" modèle est celui qui est PARTAGE par la collectivité des
personnes intéressées dans le PROJET.
- le "BON" modèle est celui qui sert de support a la discussion : un
instrument de DIALOGUE et d'INTERACTION.
 Dimensions d'une association
On appelle DIMENSION d'une association le nombre d'entités qu'elle relie.
On dit souvent : son nombre de "pattes".
Cas particulier : l'association dite "réflexive"
Supposons nous ayons besoin de savoir quels sont, parmi nos employés, ceux
qui sont mariés entre eux (pour ne pas donner par exemple 2 fois le cadeau à
leurs enfants) :
Une association "réflexive" est une association qui lie des occurrences d'une
même entité entre elles (c'est un cas particulier de la dimension 2) .
REGLES RELATIVES AUX ENTITES
Une entité possède au moins une propriété : son identifiant
la réservation de places de train est un système complexe qui met en jeu des trains, des
wagons, des parcours, des places, des catégories de places et bien sûr le temps (dates,
heures ...). Les réservations doivent évidemment être identifiées (ne serait-ce que pour ne
pas attribuer 2 fois la même place à 2 personnes différentes).
Au restaurant, au contraire, la connaissance de la table et de la date peuvent suffire à
tenir lieu de l'objet réservation. C'est simplement une table indisponible sur laquelle on
mettra un carton pour s'en souvenir.
Chacune des propriétés d'une entité doit caractériser toute occurrence de cette entité
de la même manière
Exemple : (Limites du modèle E-A)
Dans une bibliothèque, on gère des ouvrages. Les uns sont achetés en librairie et
les autres (spécimens) offerts gratuitement par les éditeurs.
La propriété "Prix de vente" n'a pas de sens pour les spécimens.
On peut imaginer se tirer d'affaire en convenant de mettre la valeur du prix à 0
lorsque l'ouvrage est un spécimen.
C'est ce que feront tous les informaticiens bricoleurs et qu'il ne faut pas faire. En
effet un ouvrage qui n'a pas de prix n'est pas un ouvrage dont le prix est égal à 0.
L'inconvénient de cette façon de faire est que, lorsque nous rechercherons des
informations spécifiques aux ouvrages qui se vendent, par exemple leur
fournisseur, il faudra :
- examiner toutes les occurrences d'ouvrages,
- pour chacune, regarder si par hasard le prix de vente n'est pas égal à 0
(Spécimen)
- si c'est le cas ne pas s'en occuper pour faire la même chose avec l'occurrence
suivante de la collection.
Évidemment, on n'est pas encore très contents. Parce que, tout
de même, livres et spécimens ne sont pas si différents que cela.
Ce serait mieux si on pouvait dire ce qu'ils ont de commun, une
sorte d'entité SUR des entités. Cet outil n'existe pas dans le
modèle E-A, version de base. Nous appellerons cette
construction une GENERALISATION/SPECIALISATION ou
HERITAGE.
(Que l’on verra dans l’orientation objet !)
REGLES RELATIVES AUX ASSOCIATIONS
a) S'il existe une occurrence d'association, alors il existe
nécessairement une occurrence de chacune des entités associées.
b) Deux occurrences d'une entité ne peuvent participer à la même occurrence
de l'association (sauf si l'association est réflexive)
REGLES RELATIVES AUX PROPRIETES
a) Une même propriété ne peut figurer que sur UN SEUL
objet (que ce soit une entité ou une association); Sinon
REDONDANDE
b) Une propriété doit être ELEMENTAIRE, atomique, de telle sorte
qu'on ne puisse pas la décomposer. Dans les BD relationnelles,
cette règle est connue sous le nom de 1ère Forme Normale (de
CODD).
c) Une propriété doit dépendre PLEINEMENT (I.E : de la totalité) de
l'identifiant.
Dans les BD relationnelles, cette règle est connue sous le nom de
2ème Forme Normale (et présuppose la 1ère).
d) Une propriété doit dépendre DIRECTEMENT de l'identifiant (i.e.
sans passer par l'intermédiaire d'une autre propriété).
Dans les BD relationnelles, cette règle est connue sous le nom de
3ème Forme Normale (et présuppose les deux précédentes).
Elle vise à empêcher des redondances et permet de mettre au jour une entité
qui était imbriquée dans un objet (entité ou association)
CONSEILS
1
Analyser l'existant et constituer le dictionnaire des
données
2
Epurer les données : synonymes, polysèmes
3
Dégager les entités naturelles grâce aux identifiants
4
Rattacher les propriétés aux entités
5
Recenser les associations entre entités et leur rattacher
leurs éventuelles propriétés
6
7
8
9
Déterminer les cardinalités de chaque couple entité association
Décomposer si possible à l'aide des contraintes d'intégrité
fonctionnelle
Vérifier le modèle : s'assurer de la conformité aux règles
de construction
Normaliser le modèle : s'assurer qu'il est au moins en
3ème Forme Normale