Contenu du cours

1. Introduction
Objectif du cours
A quoi sert une méthode
2. Merise
1. Vue d’ensemble de la démarche
2. Le M.C.D (Modèle conceptuel de données)
3. Le M.C.T (Modèle conceptuel de traitements)
4. Le M.O.T (Modèle organisationnel de
traitements)
5. Le M.L.D (Modèle logique de données)

1
 1 - Introduction
1.1 Objectif du cours
 Initier les étudiants à la modélisation des Systèmes
d’Information en utilisant Merise.
 Structuration de la démarche informatique,
 Méthodes d’analyse et de conception,
 Méthodes de modélisation
Quelques méthodes :
 MERISE, MERISE/2
 SADT (Structured - Analysis - Désign - Technique )
 SART (Structured - Analysis - Real - Time)
 OMT (Object Modeling Technique)
 UML ( bien que UML n'est pas une méthode mais un
langage de modélisation unifiée )

2
 1.2 - Introduction
1.2 A quoi sert une méthode
Une méthode définit une démarche reproductible qui
produit des résultats fiables.

Une méthode d’élaboration de logiciels décrit comment

modéliser et construire des systèmes logiciels de
manière fiable et reproductible.
De manière générale, une méthode définit :
 Des éléments de modélisation,

 Une représentation graphique,

 Du savoir-faire et des règles

3
 1.2 - Introduction
Avec, en autre, les objectifs suivants :
 Se donner toutes les chances de mener à bien un projet
informatique,
 Établir un plan projet réaliste en définissant, estimant et
planifiant les moyens à mettre en œuvre,
 Maîtriser le projet en mesurant son avancement et les
écarts éventuels avec les engagements pris,
 S'assurer que la qualité définie est respectée.

Et une évidence :
Le système d'information des entreprises actuelles est devenu l'un
des principaux piliers sur lesquels repose l'ensemble de l'activité.
Impossible donc de traiter ce domaine de manière
approximative.

4
 2.1 – Vue d’ensemble - Merise

Vue d’ensemble de la démarche Merise

(Méthode d’Étude et Réalisation Informatique pour les Systèmes de l’Entreprise)

5
 2.1 – Vue d’ensemble - Merise
1. Vue d’ensemble de la démarche
Qu’est ce que Merise ?
Création : 1978-1979
Plus qu’une méthode d’analyse informatique, une démarche
de construction des Systèmes d’information.

A quoi sert Merise ?

 En ce qui concerne les données : A identifier le nombre
et la nature des tables, les articulations et la ventilation des
informations entre ces tables, afin que l'ensemble soit le
plus efficace et évolutif possible,
6
 2.1 – Vue d’ensemble - Merise

 Pour les traitements : A identifier les fonctionnalités

selon une approche "top / down" ("du général au
particulier"), leur découpages et leurs enchaînements.

Merise est un travail d'anticipation : Elle sert à préparer les

développements informatiques et à chiffrer (en coût, en
temps et en énergie) ces chantiers, quelle que soit leur
échelle.

7
 2.1 – Vue d’ensemble - Merise
La démarche ou cycle de vie d'un SI:
Merise permet de mener l'étude d'un projet à travers
différents modèles qui constituent le cycle d'abstraction.
La démarche est un guide général pour dérouler un projet
informatique. Cette démarche préconisée par merise
comporte trois grandes périodes :

Conception Réalisation Maintenance

La démarche pour la conception et réalisation propose un

processus découpé en étapes comme suit :
8
Conception

Réalisation

Maintenance
9
1. Le schéma directeur
C'est un document de synthèse qui est établi par la
direction informatique et validé par la direction générale.
Il définit le cadre général de développement du SI en
terme d'objectifs et de contraintes. Il détermine :
• Le découpage en domaines
• Les orientations d'information
• Les axes organisationnels
• La politique matérielle et logicielle
• La planification globale du développement
• Les cadres budgétaires
10
 L'analyse et l'évaluation
critique du fonctionnement
du SI actuel
Etude
préalable
L'élaboration de solutions
futures

Il se décompose en phases suivantes:

11
 Analyse de Rapport de
l'existant l'existant

Conception
de solutions

Evaluation Dossier de
des solutions choix

12
2.1 Analyse de l'existant
Il a pour objectif de :
• Comprendre et formaliser le fonctionnement du
système actuel
• Diagnostiquer ses dysfonctionnement sur les
plans de la gestion, de l'organisation et des
solutions techniques.
Il faut élaborer les diagrammes suivants :

13
• Le diagramme de flux qui permet de délimiter
les systèmes et l'identification des activités
principales du domaine
• MOT qui décrit globalement le fonctionnement
du système actuel
• MLD : connaitre et décrire les fichiers
informatisés et les bases de données existants

14
2.2 La conception
Il s'agit de la conception de solutions permettant
d'élaborer et informatiser des solutions de
fonctionnement du futur SI.
Les modèles dans cette phase de conception
sont : MCD, MOD, MOT ie les modèles futur du
SI

15
2.3 Evaluation des solutions
Son objectif est d'évaluer chacune des solutions
élaborées dans la phase précédente sur les
aspects fonctionnels, organisationnels,
techniques, financiers, charges de
développement et planning.

16
3. Etude détaillée
Viendra pour étendre l'étude préalable avec pour
objectif :
• La description de tous les processus composant
le fonctionnement du futur système
• La définition exhaustive des informations
utilisées et mémorisées

17
• La spécification complète des tâches à effectuer
en particulier pour celles à informatiser
• La description des procédures exceptionnelles,
les phases transitoires et le fonctionnement
dégradé

18
Dans cette étude, les modèles à élaborer sont :
Extension du MCD
Extension du MCT
Extension du MOD
Extension du MOT

19
4. Etude technique
Constitue le complément des spécifications
informatiques nécessaires pour assurer la
réalisation du système. Il a pour objectif de définir :
• La structure physique des données (fichier ou
base de données
• Les programmes, modules ou composants à
réaliser

20
• Les procédures techniques de sécurité
• La planification de la réalisation
Les modèles : MLD, MPD, MLT, MPT
5. Réalisation ou production logiciel
Il s'agit de la réalisation concrète dans des
langages, l'ensemble de ses spécifications
6. Mise en œuvre
Rendre opérationnel le SI

21
22
La modélisation
conceptuelle

23
 2.2 – M.C.D - Merise

A. Le M.C.D (Modèle conceptuel de

données)

24
Le M.C.D (Modèle conceptuel de données) est
la représentation statique, sous forme
schématique, de l'ensemble des donnée du
système à étudier.
Ce schéma est conçu pour être très stable dans
le temps.

25
Exemple

26
Son objectif : définir (identifier) toutes les
données utilisées, les regrouper en ensembles
appelés entités, et de lier ces entités par des
relations, dans un modèle définit et
compréhensible par toute personne connaissant
la "syntaxe" du MCD.
Le MCD regroupe les informations à traiter, le
"QUOI" du système et constitue la future BD.

27
2. L'élaboration du MCD :
1. Catalogue des données (discours parlé ou écrit
de l'utilisateur)
2. Épuration (polysèmes et synonymes)
3. Détermination des entités
4. Détermination et affectation des propriétés
5. Recensement des associations avec,
éventuellement, les propriétés non encore affectées
6. Détermination des cardinalités

28
 Ensemble
d'informa Modélisation MCD
tions

3. Concepts de base

Entité : Modélisation des objets concrets ou

abstraits, ayant une existence et une raison
d'être, utilisés dans le système d'information.

29
Une entreprise est un système. Et dans cette
entreprise nous trouvons les éléments suivants :
Les salariés
Les clients
Les produits
Les fournisseurs
Les livraisons
etc

30
Une école est un système. Et il y a les objets qui
font partie de son système :
Les élèves
Les enseignants
Les matières
Les classe
Les emplois du temps
etc

31
Une entité est pourvue d’une existence propre et
est conforme aux choix de gestion de
l’entreprise.
• Une entité peut être un acteur : client, usine,
produit => pourvue d’une existence intrinsèque.
• Une entité peut être un flux : commande,
livraison => existe par l’intermédiaire d’acteurs.

32
Exemple : soit la phrase :
Le client SANOU a passé la commande C012
contenant les articles A11 et A23.
Dans cette phrase nous distinguons les objets
suivants qui seront modélisés en entité :
Client, commande et article.

33
Représentation graphique de l'entité

34
Les propriétés :
Une entité est un élément du monde réel et doit
avoir des informations la caractérisant.
Par exemple chaque client doit avoir un nom,
une adresse et une ville.

35
Une propriété est la modélisation d'une
information présentée dans le discours.
• Chaque propriété prend des valeurs qui sont
appelées occurrences de la propriété,
• Chaque propriété a un domaine de définition
(ensemble de valeurs possibles),
• Chaque propriété se rattache toujours à une
entité.

36
37
Identification d’une Entité :
C’est une propriété (ou ensemble de propriétés)
particulière qui permet d’identifier de façon
unique une occurrence de l’entité.
• Pour être identifiant, la ou le groupe de
propriétés ne doit pas prendre plusieurs fois la
même valeur sur l’ensemble des occurrences de
l’entité.

38
• L’identifiant figure en premier dans la liste des
propriétés
• Il est souligné

39
Association (ou Relation)
La relation modélise l'association entre deux ou
plusieurs entités. La représentation graphique
d'une relation est la suivante :

40
Dans le discours, les verbes dans les phrases
expriment les relations entre les entités.
Exemple :
"Le client passe une ou plusieurs commandes".
Passer exprime la relation entre les deux entités.

41
Dimension d'une relation

42
Cas des associations de dimension "1" (dites "réflexives") :

43
Une relation peut elle avoir des propriétés ?
Une relation possède une propriété si cette
propriété dépend fonctionnellement des
identifiants des entités participantes à la relation.

44
Soient les propriétés suivantes :
• NumEns
• NomEns
• NumMat
• NomMat
• Coef
• NumClas
On sait que le coefficient de la matière change
en fonction de la classe et de la matière.
Le coefficient dépend de deux propriétés,
NumClas et NumMat.
45
D'où le MCD :

46
Occurrence d'une entité
Une entité est un objet qui existe, par exemple
enseignant, élève et matière.
Une occurrence est un cas ou exemple dans le
monde réel.
Entité Occurrences

47
Cardinalité d’une Association
C'est le nombre de participation des occurrences
d'une entité aux occurrences d'une relation.
Les cardinalités s'expriment par deux valeurs : La
cardinalité minimale et la cardinalité maximale.

48
Ex1 : Un client passe une ou plusieurs commande

49
 Les dépendances fonctionnelles
1. But des DF
Le but des DF est de vérifier et de s'assurer que
la future base de données est correctement
construite ie ni souffrir de redondance, ni
d'incohérence.
Elles peuvent être utilisées au niveau des tables
directement ou au niveau de la conception de la
BD comme dans le MCD de merise.
50
Soit le MCD suivant :

La propriété NoteExamen ne doit pas figurer dans

l'entité Etudiant.
Les DF vont nous aider à placer la propriété
NoteExamen dans le bon endroit. Après application
des DF, nous aurons le MCD suivant :
51
La propriété NoteExamen a été donc placée au
niveau de la relation "Avoir"

52
2. Qu'est ce qu'une DF ?
Une BD peut être construite de deux façons :
 Soit selon un processus de conception, c'est le
cas de la méthode merise, nous devons élaborer
le MCD
 Soit à travers un processus de décomposition
d'une table contenant tous les attributs et puis
nous décomposons cette table universelle en
plusieurs tables sans perte d'informations.

53
Un attribut ou groupe d'attributs y dépend
fonctionnellement d'un attribut x, si étant donnée
une valeur de x, il lui correspond une et une seule
valeur de y.
Exemple : dans l'entité voiture suivante, les DF
existent.
NumImat Couleur
Type Marque
Type Puissance
(Type, marque ) Puissance

54
Puissance Type
Type Couleur
Sont des DF non correctes.
Ces trois DF sont elles correctes ?
1. RefProd QtéCom
2. NumCom QtéCom
3. (NumCom, RefProd) QtéCom

55
Pour appliquer les DF à notre MCD, nous ferons
la représentation suivante :

La propriété Quantité commandée dépend de la

référence du produit et du numéro de la
commande.
56
3. Propriété des DF
Elles permettent de dégager d'autres DF à partir
d'un groupe de DF existant.
Les DF obéissent à plusieurs règles ou propriétés.
 Réflexivité
Soient x et y des groupes de propriété sachant que
y est un sous groupe de x :
Donc x y ie tout ensemble d'attribut détermine
lui-même ou une partie de lui-même.
Ex : (type, marque, puissance) (marque, puissance)

57
 Augmentation
Soient x et y deux groupes de propriété x
X y xz yz
Si x détermine y, les deux ensembles d'attributs
peuvent être enrichis par un même troisième.
Ex :
type puissance nous avons toujours
(type, couleur) (puissance, couleur)

58
 Transitivité
x y et y z alors x z
Ex :
NumImat type et type puissance
On déduit alors que
NumImat puissance

59
 Union
x y et x z alors x y, z

 Pseudo-transitivité
x y et wy z alors wx z

 Décomposition
x y et z est inclus dans y alors x z

60
4. Dépendance élémentaire
Une DF est qualifiée de élémentaire si une DF de la
forme
X A,
Où A est une propriété unique n'appartenant pas à X et
X qui est un groupe de propriétés où il n'existe pas un
sous groupe X' de telle façon que X' A
Ex1 : cette DF
(Type, marque) puissance
n'est pas élémentaire car une partie du groupe (type,
marque) ici type détermine la puissance
61
Ex2 : cette DF
(RefProd, NumCom) QtéCom
est élémentaire parce que la quantité commandée
dépend de la totalité du groupe et non d'une partie.
Ex3 :
MatEtud Nom, Prénom
n'est pas une DF élémentaire parce que la partie à droite
de la DF n'est pas unique. Il s'agit d'un groupe de
propriétés. Pour que cette DF soit élémentaire, on peut
la réécrire de cette façon :
MatEtud Nom, et MatEtud Prénom
62
5. Graphe des DF
Une façon simple et lisible de représenter les DF
élémentaires est de le représenter graphiquement

Désignation PU Date Num

Com Cli

Num
RefProd
Com

QtéCom
63
 2.3 – M.C.T - Merise

B. Le M.C.T (Modèle conceptuel de

traitements)

64
 2.3 – M.C.T - Merise

Généralités
• L’élaboration du Modèle Conceptuel des
Traitements (MCT) s’appuie sur les travaux
réalisés lors du recueil de l’existant.
• Les notions de processus, de flux, d’acteur
prennent toute leur importance puisqu’elles sont
le point de départ du MCT.

65
 2.3 – M.C.T - Merise

• Si les processus ont été déterminés à partir du

recueil et de l’étude des documents de
l’entreprise, on va maintenant s’intéresser
également aux traitements qui ont permis de les
obtenir.
• De cette orientation nouvelle, découle une
approche complémentaire de la notion de
processus.

66
 2.3 – M.C.T - Merise

Un processus est un enchaînement synchronisé

d’opérations (traitements) représentant une unité
de préoccupation homogène de l’organisation.

Le MCT a pour objectif de représenter

formellement cet enchainement dans le SI, ie
identifier son fonctionnement.

67
Pour cela, il décrit formellement les activités
exercées par chaque processus déterminé lors
du recueil de l’existant. Cette description se fait
indépendamment de toute considération
organisationnelle.
Les différents processus (paie, facturation,
livraison, ...) vont être décrits sans se soucier de
savoir QUI les réalise, QUAND et OÙ ils sont
réalisés.
68
La modélisation des traitements est tournée vers
la prise en compte des échanges du processus
avec son environnement (autres processus,
acteurs internes ou externes à l’organisation).

69
Considérons un processus qui permet la
réalisation de devis.
Ce processus, avant d’être sollicité par un
événement extérieur, est au repos. Il reçoit un
stimulus de l’extérieur : une demande de devis
faite par un client.
Cette demande (événement déclencheur)
entraîne la réaction du processus qui entreprend
alors un traitement pour y répondre.
70
La suite d’opérations entreprise aboutit à une
réponse globale du processus à la sollicitation
extérieure. Cette réponse se présente sous la
forme d’un devis à destination du client.
La réaction du processus à l’événement
déclencheur étant terminée, celui-ci revient à
l’état de repos et attend une nouvelle sollicitation
pour s’activer à nouveau.

71
72
 2.3 – M.C.T - Merise

Formalisme du MCT :

Ce formalisme repose sur quatre concepts de base :

• l’événement,

• l’opération,

• le résultat et ses règles d’émission,

• la synchronisation.

73
 2.3 – M.C.T - Merise
Evénement / Résultat

Evénement SI Résultat

L’événement est un fait nouveau pour le SI ou le

processus concerné.
Il est externe au processus, provoque une réaction
de celui-ci (exécution d’une ou plusieurs opérations)
qui peut se traduire par l’émission de résultats.

74
 Caractéristiques
• Il est porteur d’information,
• il possède
un code (pour le nommer),
un libellé (pour le décrire),
un commentaire (pour l’expliquer).
Exemple :
Arrivée d’une commande, réception de
marchandise, réponse d’un client.

75
Exemple : Une société fabrique des produits
spécifiques sur commande. Le client fait une
demande de devis. A la réception de la demande,
un dossier de production est ouvert et un devis
réalisé. Le devis est envoyé au client, à la réception
de l’accord du client, le dossier de production est
complété et la production lancée. Le produit
accompagné d’un bon de livraison est expédié au
client. On ne s’intéresse qu’aux processus Devis et
Fabrication
76
77
 2.3 – M.C.T - Merise
L'opération

Une opération est un ensemble d’actions

(traitements) accomplie par le processus en réaction
à un ou plusieurs événements déclencheurs.
Initialisée, l’opération prend en compte les
informations fournies par les événements
déclencheurs, les traite, met à jour les données
mémorisées et prépare les résultats de sortie (qui
sont de nouveaux événements).

78
 2.3 – M.C.T - Merise

ELABORER DEVIS
Calcul des heures
de production
Calcul des
fournitures
Ouverture dossier
production
Planification
Edition devis
Expédition devis

79
 2.3 – M.C.T - Merise
Condition d'émission

Une condition d’émission est une formalisation

traduisant les règles de gestion à laquelle est
soumise l’émission du résultat d’une opération.

Exemples :
si stock < 100 alors compte-rendu et commande,
si délai > trois mois alors relance,
si place disponible alors réservation.

80
Exemple : Lors de la réception d’un bon de
commande, le magasinier contrôle son stock. Si le
stock est suffisant, il donne la marchandise, met à
jour le stock et classe le bon de commande; Si le
stock est insuffisant, il met le bon de commande en
attente et commande les matériaux manquants.

81
82
 2.3 – M.C.T - Merise
La synchronisation

La synchronisation est la représentation d’une

condition (expression booléenne) qui, préalablement
au déclenchement d’une opération doit être vérifiée.
Elle utilise une combinaison de commutateurs
logiques ET et OU,

83
 2.3 – M.C.T - Merise
Acteur

Répondre à la question suivante :

• Avec qui le SI fait des échanges avec son
environnement?
Par exemple, avec qui les vendeurs font des
échanges ?
Nous ne nous intéresserons qu'aux acteurs
externes : le client
Formalisme d'un acteur : Nom acteur

84
 2.3 – M.C.T - Merise
L'état

• Commande en attente
• Commande traitée
• Demande d'inscription en attente
• Demande d'inscription acceptée
L'état modélise une situation dans le SI à un instant t.

85
2.3 – M.C.T - Merise

86
2.3 – M.C.T - Merise

87
Les règles à respecter
• Un processus est toujours déclenché par un
événement qui lui est extérieur.
• Un acteur émet au moins un événement ou reçoit
au moins un résultat ( un acteur qui n’émet et ne
reçoit rien, n’a pas lieu d’exister).
• Un événement au moins provient d’un acteur (il
n’y a pas d’activation sans une sollicitation
extérieure).

88
• Un résultat provient d’au moins une opération
(il n’y a pas de génération spontanée).
• Tout résultat a au moins un destinataire acteur
ou opération (il n’y a pas de résultat qui ne sert
à rien).
• Une opération est déclenchée par au moins un
événement (il n’existe pas de déclenchement
aléatoire).

89
• Une synchronisation lie au moins deux
événements ou résultats par une expression
logique (voir les conventions de notation ci-
dessous).
• Une opération ne peut être interrompue par
l’attente d’un événement. Si c’est le cas, il faut
la scinder, la deuxième opération ainsi créée
s’appuyant sur l’événement en attente.

90
 2.3 – M.C.T - Merise

Exercice :

TD : Cas concret

91
 2.2 – M.C.D - Merise

La modélisation
organisationnelle

92
 2.4 – M.O.T - Merise

Le M.O.T (Modèle Organisationnel de

Traitements)

93
 2.4 – M.O.T - Merise

Le modèle organisationnel des traitements

(MOT) est une représentation de l'activité de
l'organisme étudié qui prend en compte :
• La représentation des traitements entre
l'homme et la machine;
• La période de déroulement de chaque tache;

94
 2.4 – M.O.T - Merise

• Répartition de la responsabilité de ces

traitements (taches) au niveau des
microstructures : services, départements,
divisions, poste de travail, bureaux, …
Pour chaque tâche, nous devons répondre aux
questions suivantes :

95
 2.4 – M.O.T - Merise
Qui fait quoi ?
 Analyse des postes de travail.
 Partage des traitements entre l’homme et la
machine.
 Type d’individu qui réalisera les traitements.
Quand ?
 Influence du temps et comment structurer les
traitements en conséquence.
Où ?
 Comment les traitements sont-ils organisés dans
l’espace ?
96
 2.4 – M.O.T - Merise

Formalisme du MOT :

97
 2.4 – M.O.T - Merise

Formalisme du MOT :

Le MOT reprend les concepts du MCT, parfois

réadaptés, auxquels sont ajoutés de nouveaux
concepts tels que :
le poste de travail : entité physique comprenant
des ressources sur un lieu donné et un
responsable.

98
 2.4 – M.O.T - Merise

la tâche/opération : affectation des traitements

d’une opération conceptuelle à une unité
organisationnelle de type site ou service.

la procédure organisationnelle : enchaînement

de traitements (tâches et/ou phases) affectés à
un ou plusieurs sites ou services au sein d’un
même processus.

99
 2.4 – M.O.T - Merise

Le MOT cerne l'activité de chaque poste de travail

(informatique ou non), et de chaque service, en
tenant compte du "planning", du type de ressources
(manuel, automatisé), du type de support (document
écrit, magnétique etc.)

MOT = MCT + lieu + moment + nature

100
 2.4 – M.O.T - Merise

Lieu : qui exécute ? Acteurs.

Moment : Quand exécute t-on l’opération ?
Agencement temporel.
Nature : Manuelle, Automatique, Interactive

101
 2.4 – M.O.T - Merise
Construction du MOT :
Faire le choix des postes, en spécifiant les
ressources humaines et informatiques
Décomposer chaque opération conceptuelle en
opérations organisées, les ordonner, les affecter
aux postes, préciser les différentes
caractéristiques (degré d’automatisation, délai
de réponse, mode de travail)

102
 2.4 – M.O.T - Merise

S’assurer de la faisabilité des opérations

organisées par rapport aux ressources
composant le poste
Préciser les différentes phases
Évaluer l’ergonomie générale de chaque poste
de travail par rapport à l’ensemble des phases à
assurer
Envisager des solutions alternatives:
variantes de procédures
103
Soit le MOT suivant :

104
 2.4 – M.O.T - Merise
Voici un cas concret :
Construisons les modèles de traitement de
l’organisme de formation X qui suit les règles
suivantes :
Règle 1 : en fonction des pré-requis du stage,
l’inscription est acceptée ou refusée,
Règle 2 : les clients doivent transmettre les
annulations d’inscription par écrit 10 jours avant le
démarrage de la formation,
Règle 3 : la société X se réserve le droit d’annuler ou
reporter une session 10 jours avant son démarrage,
Règle 4 : si le nombre de stagiaires est supérieur à 5,
la session est maintenue et les convocations sont
envoyées.

105
 2.4 – M.O.T - Merise
Que pouvons-nous en déduire ?
 Une demande d’inscription provoque soit une
inscription, soit un refus.
 Une annulation n’est prise en compte que si elle
est transmise 10 jours avant le début de la
session.
 Si 10 jours avant le début de la session, le nombre
de candidats est supérieur à 5, les convocations
sont envoyés aux participants. Dans le cas
contraire, la session sera annulée et reportée à
une autre date.

106
 2.4 – M.O.T - Merise
A partir de ces éléments, nous pouvons construire un
diagramme des messages :

107
 2.4 – M.O.T - Merise
Enchaînons à présent les messages, en indiquant les
conditions d’enchaînement :

108
 2.4 – M.O.T - Merise
Le modèle conceptuel des traitements par processus :

109
 2.2 – M.C.D - Merise

La modélisation
logique

110
 2.5 – M.L.D - Merise

Le M.L.D (Modèle Logique de Données)

111
2.5 – M.L.D - Merise

112
 2.5 – M.L.D - Merise
C'est grâce à toutes les opérations précédentes que
l'ensemble des tables de la base de donnée vont
pouvoir être structurées de manière simple et très
rapide :
le M.C.D, ayant été corrigé à la fin de l'étape du
M.O.T, ce sont les cardinalités maximales qui vont
jouer le rôle essentiel.
La transformation consiste à appliquer des règles de
passage
113
 2.5 – M.L.D - Merise
Règle 1
MCD MLD
Entité Table
Propriété Attribut
Identifiant Clé primaire

114
 2.5 – M.L.D - Merise
Règle 2
Relation binaire (0,n) – (1,1) ou (1,n) – (1,1)

MCD

MLD

115
 2.5 – M.L.D - Merise
Règle 3
Relation binaire (0,1) – (1,1)

MCD

MLD

116
 2.5 – M.L.D - Merise
Règle 4
Relation binaire (0,1) – (0,1)

MCD

MLD

117
 2.5 – M.L.D - Merise
Règle 5 : Relation binaire
(0,n) – (0,n) ou (1,n) – (,n) ou (1,n) – (0,n)

MCD

MLD

118
 2.5 – M.L.D - Merise
Règle 6 : Relation ternaire ou plus

MCD

MLD

119
 2.5 – M.L.D - Merise
Règle 7 : Relation réflexive (0,n) – (0,1)

MCD

MLD

120
 2.5 – M.L.D - Merise
Règle 8 : Relation réflexive (0,n) – (0,n)

MCD

MLD

121
Modéliser les données, comment ?
• La méthode de structuration des données
proposée repose sur le modèle Entité/Relation,
qui est censée dégager des ensembles de
données et des relations de sens
qu’entretiennent ces ensembles,
• Le modèle conceptuel de données est une
relation simplifiée de la réalité,

122
Son objet est de mettre en lumière les
caractéristiques essentielles du système
d’information observé,
• Une fois le modèle établi et validé par rapport à
la réalité observée, il existe des règles
permettant de le transformer en fichiers ou en
bases de données.

123
 2.2 – M.C.D - Merise
Voici un cas concret :
Une entreprise X vend des véhicules toutes
marques qu’elle stocke dans de grands entrepôts.
Dans un même entrepôt, nous pouvons trouver
plusieurs marques de véhicules, cependant, pour
des raisons de logistiques, le gérant de la société X
a exigé de ses employés qu’une marque ne puisse
se trouver que dans un seul entrepôt. Chaque
attaché commercial gère son propre portefeuille de
clients. L’entreprise X souhaite établir des
statistiques commerciales sur ses ventes de
véhicules : nombre de véhicules achetés par un
client, chiffre d’affaire réalisé par une marque, mais
aussi sur les marques entreposées dans un
entrepôt.
124
Objet :
Vente de véhicules toute marque
Application :
Statistiques commerciales
Résultats attendus :
 Nombre de véhicules achetés par un client ?
 Chiffre d’affaire réalisé par une marque ?
 Quelles sont les marques entreposées dans
un entrepôt ?

125
Données :
 Nom de marque
 Nom de dépôt
 Nom du type
 Puissance fiscale
 Nom du responsable commercial pour une marque
 Prix unitaire d’un type de véhicule
 Adresse de dépôt
 Nom, adresse du client
 Quantité d’une vente
 Date d’une vente

126
Nom de l’attaché commercial
 Adresse de l’attaché commercial

Contraintes sur les données :

 Un dépôt peut-être multi-marques,

 Une marque ne se trouve que dans un seul entrepôt,
 Un attaché gère plusieurs clients,
 Un client est géré par un seul attaché

127
 2.2 – M.C.D - Merise
1. Repérer les entités :
Les entités sont les objets de gestion essentiels du
système d’information.
L’entité est une ensemble dont chaque élément est un
élément particulier.
Dans notre exemple, que gère t-on ?
En première lecture, 3 entités ressortent :
1. Les types de véhicule,
2. Les clients,
3. Les dépôts.

128
 2.2 – M.C.D - Merise
2. Attribuer à chaque entité son identifiant et ses
propriétés :
Chacune de ces entités possède des caractéristiques,
qui sont appelées propriétés :
 Une propriété ne doit figurer qu’à un seul endroit du
modèle,
 Elle doit être significative
Parmi ces propriétés, il peut y en avoir une ou plusieurs
qui permettent de définir sans ambiguïté un élément
parmi l’ensemble des éléments : l’identifiant.
L’identifiant sert à désigner sans ambiguïté une
occurrence de l’entité.
Comment allons-nous construire l’entité TYPE DE
VEHICULE ? 129
 2.2 – M.C.D - Merise
Identifiant : Nom du type
Propriétés : Prix
Puissance fiscale
Nom de marque

Il faut alors vérifier qu’à toute valeur prise par l’identifiant

ne correspond qu’une valeur de chaque propriété. Nous
appelons cette règle : la règle d’énumération.

Ici, pour une valeur prise par un nom de type

(identifiant), nous n’avons qu’une valeur de puissance
fiscale.
130
 2.2 – M.C.D - Merise

Constituons l’entité DEPOT :

Identifiant : Nom de dépôt
Propriétés : Adresse de dépôt

131
 2.2 – M.C.D - Merise
Pour l’entité CLIENT, il est légitime de modéliser :
Identifiant : Code client
Propriétés : Nom du client
Adresse du client
Nom attaché commercial
Adresse attaché
Il faut ensuite vérifier que toutes les propriétés d’une
entité dépendent directement de l’identifiant. Nous
appelons cette règle : la règle de dépendance directe.
Pour l’entité CLIENT, il convient donc de se poser la
question suivante :
L’adresse de l’attaché commercial est-elle une propriété
du client ou de l’attaché commercial ? 132
 2.2 – M.C.D - Merise

Il convient donc de modéliser ainsi :

Entité : CLIENT ATTACHE
Identifiant :Code Client Nom de l’attaché commercial
Propriétés :Nom du client Adresse de l’attaché commercial
Adresse du client
133
 2.2 – M.C.D - Merise
2. Attribuer à chaque entité son identifiant et ses
propriétés :
Pour l’entité TYPE DE VEHICULE, nous avons défini
une propriété Nom de marque. Cependant, le
responsable commercial est dépendant de la marque.
MARQUE est donc une entité cachée.
Il convient donc de modéliser ainsi :
Entité : MARQUE TYPE DE VEHICULE
Identifiant :Nom de marque Nom du type
Propriétés :Responsable commercial Prix
Puissance fiscale

134
 2.2 – M.C.D - Merise
3. Définition des relations entre les Entités et
cardinalité :
 Relation entre MARQUE et DEPOT :

135
 2.2 – M.C.D - Merise

(1,1) : Une marque est entreposée dans un seul

entrepôt.
(1,N) : Dans un entrepôt sont entreposées une ou
plusieurs marques.
136
 2.2 – M.C.D - Merise
3. Dépendances fonctionnelles entre Entités (DF) :
La relation qui lie un TYPE DE VEHICULE à une MARQUE
est «appartenir». Il s’agit d’une relation hiérarchique : à un
type de véhicule donné ne correspond qu’une seule
marque, et à une marque correspond plusieurs type de
véhicule. Ici, TYPE DE VEHICULE détermine totalement
MARQUE.
Nous appelons cette relation fonctionnelle (DF), et elle se
note de la manière suivante :
TYPE DE VEHICULE -> MARQUE
Qu’en est-il de ATTACHE COMMERCIAL et de CLIENT ?

137
 2.2 – M.C.D - Merise
CLIENT -> ATTACHE COMMERCIAL
(A un client ne correspond qu’un attaché commercial)

Il faut ensuite vérifier que toutes les propriétés d’une

entité dépendent directement de l’identifiant. Nous
appelons cette règle : la règle de dépendance directe.
Pour l’entité CLIENT, il convient donc de se poser la
question suivante :
L’adresse de l’attaché commercial est-elle une propriété
du client ou de l’attaché commercial ?

138
 2.2 – M.C.D - Merise
4. Relations entre 3 Entités :
Regardons à présent le problème des quantités
élémentaires de ventes.
Cette données est une propriété de la relation « vendre
», liant CLIENT et TYPE DE VEHICULE : la quantité ne
prend de sens que si l’on connaît conjointement le client
et le type.
Cependant, pour qu’il n’y ait qu’une seule occurrence de
quantité, il est nécessaire d’introduire un « chronomètre
» dans notre système d’information :

139
2.2 – M.C.D - Merise

140
 2.2 – M.C.D - Merise
4. Relations entre 3 Entités :
Les cardinalités se lisent alors :
 Pour un type de véhicule, il peut y avoir de 0 à N
relations « vendre », autrement dit il peut y avoir
plusieurs ventes pour un même type de véhicule,
 Pour un client, il peut y avoir 0 à N relations
« vendre », en d’autres termes, il peut y avoir plusieurs
ventes pour un même client.
 A une date, il peut y avoir 0 à N relations « vendre ».
Ce qui se traduit par : certains jours, il y a plusieurs
ventes.

141
 2.2 – M.C.D - Merise

A une occurrence de la relation « vendre » correspond un

triplet (MARQUE, CLIENT, DATE) et un seul.
142
 2.2 – M.C.D - Merise
5. Vérifier la règle de pleine dépendance :
Les propriétés d’un relation doivent dépendre de la totalité
des entités qu’elle relie.
 Pour chaque propriété d’une relation, toutes les entités
liées par la relation doivent servir à son identification.
Exemple :
Supposons que nous ayons à gérer des taux de remise
dépendant à la fois du TYPE DE VEHICULE et du CLIENT,
il serait erroné de faire figurer ce taux de remise dans la
relation « vendre », puisque ce taux ne dépend pas de
DATE. Il conviendrait dans ce cas de créer une nouvelle
relation « a pour remise ».
De plus, on serait conduit à une grande redondance
d’information, puisque l’on stockerait plusieurs fois un
même taux de remise. 143
6. Synthèse et compléments :
1. Vérifier si le modèle est bien construit :
a. Contrôler l ’ensemble du modèle en vérifiant que
chaque propriété se trouve en un seul endroit du
modèle.
b. Contrôler chaque Entité en vérifiant :
 Que chaque Entité possède un identifiant,
 Que chaque propriété est significative,
 La règle d’énumération,
 La règle de dépendance directe

144
 2.2 – M.C.D - Merise
c. Contrôler chaque relation en vérifiant :
 Q’une occurrence de relation ne lie qu’une et une
seule occurrence de chacune des Entités qu’elle
relie,
 La règle d’énumération
 Que chaque propriétés portée par une relation
dépend de la totalité des entités qu’elle relie (règle
de dépendance).
2. Vérifier si le modèle est capable de produire les
résultats attendus.

145
2.2 – M.C.D - Merise

146