Note de cours de MERISE Ralaivao

Chapitre I - INTRODUCTION
La conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble de
l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permettant de
mettre en place un modèle sur lequel on va s'appuyer. La modélisation consiste à créer une représentation
virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse.
La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs
modèles (conceptuels, logiques & organisationnels et physiques). La séparation des données et des
traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent
remanié, tandis que les traitements le sont plus fréquemment.
La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale lancée en 1977 par le
ministère français de l'Industrie dans le but de choisir des sociétés de conseil en informatique afin de
définir une méthode de conception de systèmes d'information. Les deux principales sociétés ayant mis au
point cette méthode sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet, et le CETE
(Centre d'Etudes Techniques de l'Equipement).
Merise étant une méthode de conception et de développement de système d’information, l’objectif de ce
chapitre est d’introduire la notion de système d’information et d’en proposer une description formelle.
1. Le système d’information dans l’entreprise
L’entreprise est un système complexe dans lequel transitent de très nombreux flux d’informations. Sans
un dispositif de maîtrise de ces flux, l’entreprise peut très vite être dépassée et ne plus fonctionner avec
une qualité de service satisfaisante. L’enjeu de toute entreprise qu’elle soit de négoce, industrielle ou de
services consiste donc à mettre en place un système destiné à collecter, mémoriser, traiter et distribuer
l’information (avec un temps de réponse suffisamment bref). Ce système d’information assurera le lien
entre deux autres systèmes de l’entreprise : le système opérant et le système de pilotage.
- Le système de pilotage décide des actions à conduire sur le système opérant en fonction des objectifs
et des politiques de l’entreprise,
- Le système opérant englobe toutes les fonctions liées à l’activité propre de l’entreprise : facturer les
clients, régler les salariés, gérer les stocks, …
Une telle décomposition prend bien en compte :
- la différence de besoin en matière d’information des modules opérants et pilotes,
- la nécessité pour le système d’information de ne pas se contenter de transmettre les informations mais
d’en changer le niveau de synthèse.
Dans certaines organisations, on peut trouver des formes plus intégrées du système d’information. Cette
intégration peut se faire soit au niveau du système opérant, soit au niveau du système de pilotage.
- Un système d’information intégré au système opérant ne décrit plus le fonctionnement du système
opérant mais il est intégré à ce fonctionnement. Par exemple dans un système de GPAO (Gestion de
Production assistée par Ordinateur), les décisions de pilotage sont directement traduites en des décisions
d’exécution de règles incluses dans une gamme opératoire.
- Un système d’information intégré au système de pilotage doit permettre d’engranger les décisions prises
lors de diverses situations afin de rendre le pilotage plus intelligent. Ces Systèmes Interactifs d’Aide à la
Décision (S.I.A.D) ont une architecture proche de celle des systèmes experts et font donc largement appel
pour leur conception aux techniques de l’intelligence artificielle.
2. Architecture & conception d’un système d’information
Le système d’information doit décrire (on dit encore représenter) le plus fidèlement possible le
fonctionnement du système opérant. Pour ce faire, il doit intégrer une base d’information dans laquelle
seront mémorisés la description des objets, des règles et des contraintes du système opérant. Cette base
étant sujette à des évolutions, le système d’information doit être doté d’un mécanisme (appelé processeur
d’information) destiné à piloter et à contrôler ces changements.
Relativement à la conception d’un système d’information, l’architecture induit une double conception :
- celle de la base d’information (aspect statique)
- celle du processeur de traitement (aspect dynamique)
1
Note de cours de MERISE Ralaivao
Pour aider le concepteur dans ces deux tâches, la méthode Merise propose un ensemble de formalismes et
de règles destinées à modéliser de manière indépendante les données et les traitements du système
d’information. Ces modèles ne sont qu’une base de réflexion pour le concepteur et un moyen de
communication entre les divers acteurs du système d’information dans l’entreprise. Seule la validation de
l'ensemble se fera en commun.

3. Système d’information et système informatique

Parmi les informations qui appartiennent au système d’information, certaines doivent ou peuvent faire
l’objet d’un traitement automatisé grâce aux outils informatiques. Pour assurer la cohérence du système
d’information, la méthode Merise propose une démarche d’informatisation comportant les étapes
suivantes :
- le schéma directeur : dont le rôle est de définir, de manière globale, la politique d’organisation et
d’automatisation du système d’information. Pour ce faire, il est nécessaire de répertorier l’ensemble des
applications informatiques existantes à modifier et à développer.
Pour rendre contrôlable et modulable ce développement, il est nécessaire de découper le système
d’information en sous-ensembles homogènes et relativement indépendant. Ces sous-ensembles sont
appelés domaines. Par exemple, on peut trouver le domaine
« Approvisionnement », le domaine « Personnel ». Les résultats attendus à la fin de cette étape sont une
définition précise des domaines, une planification du développement de chaque domaine et un plan
détaillé, année par année, des applications qui doivent être réalisées.
- l’étude préalable par domaine: qui doit aboutir à une présentation générale du futur système de
gestion (modèles des données et des traitements) en indiquant les principales novations par rapport au
système actuel, les moyens matériels à mettre en œuvre, les bilans
coût – avantage. Cette étude est réalisée en 4 phases :
- une phase de recueil qui a pour objectif d’analyser l’existant afin de cerner les
dysfonctionnements et les obsolescences les plus frappantes du système actuel.
- une phase de conception qui a pour objectif de formaliser et hiérarchiser les orientations
nouvelles en fonction des critiques formulées sur le système actuel et d’autre part des politiques et
des objectifs de la direction générale. Cela revient à modéliser le futur système avec une vue
pertinente de l'ensemble.
- une phase d’organisation dont l’objectif est de définir le système futur au niveau organisationnel:
qui fait quoi ?
- une phase d’appréciation dont le rôle est d’établir les coûts et les délais des solutions définies
ainsi que d’organiser la mise en œuvre de la réalisation. A cet effet un découpage en projets est
effectué.
- l’étude détaillée par projet qui consiste d’une part à affiner les solutions conçues lors de l’étude
préalable et d’autre part à rédiger, pour chaque procédure à mettre en œuvre, un dossier de spécifications
détaillé décrivant les supports (maquettes d’états ou d’écran) ainsi que les algorithmes associés aux règles
de gestion… A l’issue de cette étude, il est possible de définir le cahier des charges utilisateurs qui
constitue la base de l’engagement que prend le concepteur vis à vis des utilisateurs. Le fonctionnement
détaillé du futur système, du point de vue de l’utilisateur, y est entièrement spécifié.
- la réalisation dont l’objectif est l’obtention des programmes fonctionnant sur un jeu d’essais approuvés
par les utilisateurs.
- la mise en œuvre qui se traduit par un changement de responsabilité : l’équipe de réalisation va en effet
transférer la responsabilité du produit à l’utilisateur. Cette étape intègre en particulier la formation des
utilisateurs. Après une période d’exploitation de quelques mois, la recette définitive de l’application est
prononcée.
- la maintenance qui consiste à faire évoluer les applications en fonction des besoins des utilisateurs, de
l’environnement et des progrès technologiques.
Le schéma suivant reprend les étapes décrites ci-dessus.
Cette démarche lourde et parfois complexe est adaptée à l’automatisation de « gros systèmes
d’information ». Pour des informatisations plus modestes, elle peut être perçue comme un carcan, et il

2
Note de cours de MERISE Ralaivao
convient donc de l’adapter afin de retenir uniquement les concepts et/ou les étapes appropriées aux
besoins.

4. Démarche
La méthode MERISE présente sa démarche en trois axes présentant trois cycles de préoccupation
différente mais complémentaire : le cycle d’abstraction, le cycle de décision et le cycle de vie.

Ce cours sera axé sur les formalismes et concepts de Merise utiles aux descriptions statique et dynamique
du système d’information à automatiser. Relativement à ces descriptions (encore appelées modèles) la
méthode Merise préconise 3 niveaux d’abstraction dans son cycle d’abstraction :
- le niveau conceptuel qui décrit la statique et la dynamique du système d’information en se préoccupant
uniquement du point de vue du gestionnaire.
- les niveaux logique et organisationnel décrivent la nature des ressources qui sont utilisées pour
supporter la description statique et dynamique du système d’information. Ces ressources peuvent être
humaines et/ou matérielles et logicielles.
- les niveaux physique et opérationnel dans lequel on choisit les techniques d’implantation du système
d’information (données et traitements)
Du fait de ce découpage (qui a été introduit pour faciliter l’analyse d’un problème) seul le premier niveau
est réellement indépendant de toute considération technologique : logicielle ou matérielle. Par exemple, si
les données du futur système d’information doivent être gérées par un SGBD, c’est au niveau
organisationnel que le choix du type du SGBD (relationnel, réseau ou objets) devra être effectué. La
description statique du système d’information à ce niveau sera donc basée sur l’organisation des bases
relationnelles, ou réseau, ou objets. Le troisième niveau est encore plus dépendant de l’aspect
technologique puisqu’il cherchera à optimiser l’implantation. Il suppose donc une connaissance très
pointue de l’architecture et des fonctions du SGBD qui gérera le système d’information.

3
Note de cours de MERISE Ralaivao

5. Le cycle d’abstraction et les modèles de MERISE

La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information
fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en
prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des
traitements, il faut vérifier la concordance entre données et traitement afin de vérifier que toutes les
données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.
Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information:

L'expression des besoins aboutit au MCC (Modèle conceptuel de la communication) qui définit les flux
d'informations à prendre compte.
L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le
MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.
Le modèle organisationnel consiste à définir le MLD (Modèle logique des données) qui représente un
choix logiciel pour le système d'information et le MOT (Modèle organisationnel des traitements)
décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).
Enfin, le modèle physique reflète un choix matériel pour le système d'information.

6. Conclusion et objectif du cours

Même si la méthode MERISE étant, avant tout, une méthode de conception de systèmes d’information, et
non de systèmes informatiques, il apparaît aujourd’hui que les systèmes d’information sont largement
gérés par des applications informatiques. Les modèles MERISE doivent donc être utilisés pour faciliter le
développement de ces applications en s’appuyant sur les technologies logicielles actuelles telles que les
bases de données relationnelles et/ou l’architecture client-serveur.
De plus, il apparaît que les méthodes traditionnelles, composées d’étapes menées séquentiellement depuis
l’analyse du besoin jusqu’à la recette, présentent l’inconvénient d’être rigides et peu réactives. Ainsi, le
temps écoulé entre les spécifications et la phase de livraison est parfois tellement important que les
besoins ont changé de nature. Pour pallier ces défauts, il faut envisager des démarches qui impliquent
beaucoup plus l’utilisateur dans le processus global d’informatisation et qui procèdent par affinements
successifs. Ainsi, une démarche basée sur des méthodes traditionnelles, comme MERISE pour l’aspect
conceptuel, et plus modernes, comme le RAD pour produire des prototypes, pourrait s’avérer être un
compromis avantageux pour la conception d’applications informatiques.

4
Note de cours de MERISE Ralaivao

Chapitre II – ANALYSE PREALABLE

1. Objectifs
L’analyse préalable consiste, à partir de la situation existante concernant le domaine, à proposer une
solution future. Pour cela, elle doit :
- Préciser les frontières du domaine d’étude en évitant toute redondance tout en préservant la
cohérence globale des besoins et des solutions ;
- Modéliser les solutions types en définissant l’impact des solutions sur l'organisation (services,
cellules, postes, ...) et en mesurant les gains et les charges à prévoir.
- Planifier les études détaillées, les développements et les migrations.
Les résultats attendus de l’Etude préalable sont donc :
• des modèles précisant l'organisation des données ;
• la répartition des tâches hommes / moyens informatique dans le déroulement du processus ;
• le détail des actions dans le cadre d'une solution organisationnelle et technique.

2. Démarche
L’analyse préalable comporte trois étapes :
- l’analyse de l’existant où l’on étudie le fonctionnement du système actuel avant de le critiquer ;
- la conception de l’avant-projet où l’on définit les orientations générales (gestion, organisation,
technique) des solutions possibles ;
- le choix de la solution à retenir.
3. Analyse de l’existant
a. Etude de l’existant
L'étude de l'existant a pour objectifs de prendre connaissance dans le détail le domaine à étudier en
recensant l'ensemble exhaustif des objectifs poursuivis par l'entreprise dans ce domaine.
Ces détails seront obtenus à partir des interviews auprès des entités auprès desquelles se fait l'étude de
l'existant : la direction (présentation d'une vue globale et de l'ensemble des objectifs dans le domaine) et
les postes de travail (connaissances détaillées sur le poste en question).
Le système d’information actuel est étudié à l’aide :
- de la description des postes de travail en faisant ressortir les tâches effectuées, leur durée, leur
fréquence, etc.
- de la description des documents
- de la description des données (fiches, fichiers, base de données, etc.)
- d’interviews des utilisateurs.
Une synthèse de ces éléments est présentée sous forme d’un diagramme tâches-documents (ou diagramme
spatio-temporel) ou d’un diagramme de flux.

5
Note de cours de MERISE Ralaivao
Réception Commandes Service Commercial Magasin Sce Facturation

Commande écrite ou
Appel téléphonique

T1

BC BC

T2

BC
BC

T3 T4

AE AE BC BC

T5

CF CF F

T1 : Création du bon ce commande (BC)

T2 : Enregistrement commande et visa du bon de commande
T3 : Préparation et envoi commande et création de l’avis d’expédition (AE)
T4 : Envoi du bon de commande pour établir la facture
T5 : Création de la facture (F) et de sa copie (CF)

b. Critique de l’existant
Cette étape fournit un état de la situation actuelle et tente de faire apparaître (objectivement) les défauts et
les qualités de ce qui existe déjà. Cette critique peut déboucher sur la remise en cause des structures, des
postes, des hommes, des documents, … Elle permet ainsi :
- l’identification des atouts (points forts) du système existant ;
- la recherche des aspects à améliorer ;
- la mise en évidence des insuffisances actuelles (points faibles) et de leurs causes.
6
Note de cours de MERISE Ralaivao

4. Conception de l’avant-projet
Cette étape est également appelée « Ebauche de solutions ». Il s’agit d’établir une ou plusieurs
propositions de solution globale, permettant de pallier aux carences repérées lors de la critique de
l’existant. Il faut faire apparaître les axes fondamentaux des solutions proposées et les moyens à mettre
en œuvre pour arriver à atteindre les objectifs fixés tout en respectant les contraintes relatives aux
orientations de gestion, d’organisation et techniques. Ces solutions devront en plus résoudre les points
faibles identifiés précédemment tout en sauvegardant ses points forts.

5. Solution à retenir
Le choix de la solution à retenir commence par une étude individuelle de chacune des solutions proposées
suivie d’une étude comparative.
a. Etude individuelle
Chaque proposition est étudiée individuellement. On présente :
- le schéma de circulation de l’information souhaité
- le MCD futur (les données étant relativement stables dans le temps)
- le MCT futur (la remarque précédente étant valable à un degré moindre, de nouvelles procédures
peuvent être mises en place)
- une estimation des volumes d’informations à traiter
- une évaluation des logiciels à acquérir
- le budget correspondant à l’achat du matériel et à sa maintenance.
b. Etude comparative
Une étude comparative des différentes propositions permet d’effectuer le choix définitif.
Ce choix peut s’effectuer en tenant compte de :
- la réponse aux objectifs fixés
- du coût
- la faisabilité technique (matériels, logiciels, délais) et humaine (recrutement et formation).

6. Le dossier du choix
L’étude préalable s’achève avec l’élaboration d’un dossier présentant l’existant, les objectifs à atteindre,
la description des différentes propositions étudiées et la justification du choix.
Le dossier final de synthèse comprendra :
- Une introduction rappelant le déroulement de l'étude et les objectifs à respecter ;
- Présentation générale du futur système de gestion
- Conséquences sur l'organisation de l'entreprise
- Moyens matériels à mettre en œuvre
- Les scénarios de mise en œuvre
- Les chiffres clés
- L'analyse de l'impact du plan sur les moyens humains
- Le plan de charge concernant le développement du système.

7
Note de cours de MERISE Ralaivao

Chapitre III – MODELE CONCEPTUEL DES DONNEES

1. Objectifs
Le modèle conceptuel de données constitue une description globale des données manipulées dans
l'organisme, tous les acteurs et tous documents confondus. En effet, il est la représentation de l'ensemble
des données mémorisables du domaine, sans tenir compte des aspects techniques et économiques du
stockage et de l'accès, sans se référer aux conditions d'utilisation par tel ou tel traitement.Le MCD a pour
but de modéliser les données (aspectstatique) mémorisées dans le système d’information.

2. Concepts et formalismes
Les concepts manipulés dans ce modèle sont :
- l'entité,
- l’association,
- les propriétés,
- les cardinalités.
*L'entité :
Une entité est pourvue d'une existence propre et conforme aux choix de gestion de l'entreprise.
Les éléments d'un ensemble d'entité sont appelés OCCURRENCE. Chaque occurrence est repérée par un
identifiant qui est une propriété particulière d'un objet. Il ne saurait exister deux occurrences de cet objet
pour lesquelles cet identifiant pourrait prendre une même valeur.
* L’association :
L’association est une relation entre deux ou plusieurs entités.
* Propriété ou attribut
Une propriété est une donnée élémentaire présente dans l’univers de discours.
* Cardinalité
C'est le nombre minimum et maximum de fois qu'une occurrence de l'entité participe aux occurrences de
l’association.

3. Démarche
Dans l’étude préalable, on établit le MCD de l’existant et une ébauche du MCD de la nouvelle solution.
Dans l’étude détaillée, on établit le MCD complet de la nouvelle solution.
Préalablement, il faut :
- expliciter les règles de gestion,
- avoir établi un diagramme des flux,
- avoir construit un dictionnaire des données

4. Règles àvérifier
Règles à vérifier sur les entités
1. Toute propriété est élémentaire ;
2. Une propriété ne doit pas être “instable”, pas “calculable” ;
3. Toute propriété d’une instance aura au plus une valeur ;
4. Une propriété doit permettre d’éviter la redondance des valeurs sur l’ensemble des instances
5. Toute entité possède un identifiant ;
6. Toute propriété dépend (directement) de l’identifiant ;
7. Toute propriété dépend de tout l’identifiant ;

Règles à vérifier sur les associations

1. Une association est une relation que les règles de gestion établissent entre deux entités (ou plus).
2. Une occurrence d’une association est une instance del’association dans le monde réel.
3. Une association peut posséder des propriétés.
4. L’identifiant d’une association est la concaténation des identifiantsdes entités qu’elle relie.

8
Note de cours de MERISE Ralaivao
Règles à vérifier sur les cardinalités
La cardinalité d’une entité par rapport à une associations’exprime sous forme d’un couple :(cardinalité
minimale : cardinalité maximale). La cardinalité minimale est le nombre minimal de fois où
uneoccurrence d’un objet participe aux occurrences del’association ; elle vaut très souvent 0 ou 1. La
cardinalité maximale est le nombre maximal de fois où uneoccurrence d’un objet participe aux
occurrences del’association ; elle vaut 1, un entier fixé ou n.

5. Vérification d’un MCD

Vérifier :
• les règles sur les entités ;
• les règles sur les associations ;
• les règles globales suivantes :
1. Une propriété ne figure qu’une fois dans le MCD ;
2. Les propriétés calculées ne figurent pas dans le MCD (maisil faut s’assurer qu’avec le MCD on puisse
les calculer) ;
3. On ne fait pas figurer les associations qui se déduisent partransitivité.

9
Note de cours de MERISE Ralaivao

Chapitre IV–MODELE CONCEPTUEL DES TRAITEMENTS

1. Objectifs
Le MCT est une représentation schématique de l’activité d’une entreprise indépendamment des choix
d’organisation et des moyens d’exécution.

On s’intéresse donc à la partie dynamique du Système d’Information c’est‐à‐dire les traitements. Ceux‐ci sont la
traduction en actions des règles de gestion de l’entreprise.

2. Définition des concepts

• Un processus est un sous‐ensemble de l’activité de l’entreprise dont les points d’entrée et de sortie sont stables
et indépendants de l’organisation ;

• Une opération est un ensemble d’actions exécutables sans interruption ;

• Un événement est une sollicitation (externe ou interne) du Système d’Information auquel celui‐ci doit réagir ;

• Une synchronisation d’événements est une condition logique nécessaire au déclenchement d’une opération ;

• Un résultat est le produit d’une opération, événement interne qui peut être événement déclencheur d’autres
opérations.

3. Démarche
Dans l’étude préalable, on établit le MCT de l’existant et une ébauche du MCT de la nouvelle solution est
proposée.On achève le MCT complet de la nouvelle solutiondans l’étude détaillée.

Au préalable, il faut :
 avoir explicité les règles de gestion ;
 avoir établi un diagramme des flux, c’est‐à‐dire une représentation graphique de la circulation des
informations entre les différents acteurs de l’entreprise ;
Comme une opération est une suite ininterrompue d’actions, aucun événement externe ne peut l’interrompre et
aucunrésultat interne à une opération ne peut conditionner la suitede ses actions.

Remarque : Une application réelle est souvent constituée d’unejuxtaposition de petits MCT.

On part du diagramme des tâches‐documents et éventuellement d’un diagramme des flux pour identifier les
événements, les processus, les opérations, les actions et les résultats.

Exemple : Dans une administration, les promotions sont traitées selon les règles de gestion suivante :
1. toute demande doit subir un examen préalable pour savoir si elle est recevable ;
2. l’examen d’une demande recevable ne peut se faire qu’après rapport du supérieur hiérarchique ;
3. après examen du dossier, la demande sera accordée ou refusée.
Première représentation de l’activité : le diagramme des flux (circulation chronologique des informations entre
les intervenants).
10
Note de cours de MERISE Ralaivao

4. Formalisme

11
Note de cours de MERISE Ralaivao

Exemple :

Demande de Compléments de
promotion dossier
a c
b

a ou (b et c)

EXAMEN PREALABLE
‐ Vérification du dossier

‐ Vérification de la recevabilité

Refusée Recevable Incomplète

Demande en
attente
Demande rejetée
Demande Rapport du chef
recevable

EXAMEN APPROFONDI
‐ Vérification du rapport

‐ Appréciation
Acceptée Refusée

Demande Demande
acceptée refusée

12
Note de cours de MERISE Ralaivao

Chapitre V – VALIDATION

1. Objectifs
La validation est une étape intermédiaire entre le niveau conceptuel et les niveaux logique et organisationnel.

Les deux modèles conceptuels relatifs aux données et aux traitements ont été élaborés d’une manière
indépendante l’un de l’autre.

L’objectif principal de la validation est de vérifier l’exactitude et la complétude du MCD par rapport aux
opérations conceptuelles constituant le MCT. C’est également une phase de confrontation entre les concepts
utilisés dans les deux modèles.

2. Définition
Un modèle externe est un modèle conceptuel des données relatif à une opération conceptuelle (OPC). On
commence par déterminer les modèles externes (ME). Il s’agit du sous‐ensemble du MCD nécessaire à l’exécution
de cette OPC.

3. Démarche
On commence par déterminer les modèles externes (ME). On a ainsi un ME par OPC. Les ME utilisent les mêmes
concepts que le MCD (entités, associations, propriétés, identifiants, cardinalités). Ces ME sont fusionnés et l’étape
suivante consiste à vérifier que ces ME (fusionnés) sont déductibles du MCD élaboré précédemment. Aux besoins,
des modifications sont à apporter au MCD (ajout de propriétés, changement des cardinalités, décomposition
d’association, …)

Le MCD résultant de ces transformations est appelé MCD validé.

13
Note de cours de MERISE Ralaivao

Chapitre VI – MODELE LOGIQUE DES DONNEES

1. Objectifs
Le MCD est indépendant du choix de logiciel de gestion des données. En pratique, on a le choix entre un
logiciel de gestion de base de données (SGBD) et un logiciel de gestion de fichier (SGF). Ce choix doit
tenir compte de l’état de l’Art en matière d’organisation des données, des contraintes organisationnelles et
des moyens existants ou à acquérir par l’organisme. Le nouveau MLD devra tenir en compte les limites et
les possibilités de ce logiciel, sans toutefois entrer dans les détails techniques de méthodes de stockage et
d’accès qui relèvent du niveau physique.
Nous nous intéressons particulièrement aux bases de données relationnelles.

2. Définitions
Une Base de données est une collection de données organisée sous forme d’objets reliés entre eux. Ces données
sont partagées entre plusieurs applications et plusieurs utilisateurs.

Une Base de données relationnelle est une collection de données regroupées dans des relations (ou tables)
reliées entre elles. Celles‐ci sont formées par un certain nombre d’attributs (ou champs ou propriété) qui sont les
noms des colonnes des tables.

3. Règles de passage du MCD au MLD relationnel

 Concernant les ENTITES

- Toute entité se transforme en une table.
- L’identifiant de l’entité devient la clé primaire de la table.
- Les propriétés de l’entité deviennent des attributs de la table.
 Concernant les ASSOCIATIONS
o Cas des associations type père-fils
(Cardinalité du père 0,n ou 1,n – cardinalité du fils 0,1 ou 1,1)
- L’entité « père » devient une table.
- L’entité « fils » devient une table.
- L’identifiant de l’entité « père » devient attribut de la table « fils » ; cet attribut est aussi
appelé clé étrangère.
- Les propriétés éventuelles de l’association deviennent des attributs de la table « fils ».
Exemple
CLIENT PASSE COMMANDE

- ReferClient - N°commande

- Nom client - Date commande

o Cas des autres associations

(Cardinalité des entités associées 0,n ou 1,n)
- Chaque entité devient une table, l’identifiant de l’entité devient la clé de la table.
- L’association devient une table, l’identifiant de l’association (formé par la composition des
identifiants des entités, cf Règle de validation n°4) devient la clé primaire de cette table.
- Les propriétés éventuelles de l’association deviennent des attributs de la table « fils ».

14
Note de cours de MERISE Ralaivao
Exemple
FOURNISSEUR offre ARTICLE

- N°Fournisseur - Prix Achat - Réf. Article

- Nom fournisseur Qté Dispo - Désignation

 Concernant les IDENTIFICATIONS RELATIVES

C’est le cas où une occurrence d’une entité (entité dépendante) n’a pas d’existence propre que par
rapport à une autre entité (entité principale). Alors, l’identifiant de l’entité principale s’ajoute à
celui de l’entité dépendante.
Exemple :
HOTEL comprend CHAMBRE

- N°Hotel - N°Chambre

- Nom hotel Prix

 Concernant les ASSOCIATIONS REFLEXIVES

C’est le cas où une association lie des occurrences d’une même entité.
Exemple :

EMPLOYE Chef de

- Matricule

- Nom

4. Optimisation du MLD
Le MLD ainsi obtenu est un modèle brut qu’on peut toujours optimiser selon les besoins, les
performances attendues et les différentes contraintes relatives aux choix d’organisation. Cette
optimisation peut être dictée par les gains de place (codification et/ou recodification des données), par les
gains de temps (dénormalisation, création de « redondance », …) ou par la normalisation (transformation
du MLD en formes normales).
 Dépendance fonctionnelle : une propriété A est fonctionnellement dépendante d’une propriété B si la
connaissance de la valeur de A détermine celle de B.
 Première Forme Normale (1FN) : Toutes les propriétés doivent être fonctionnellement dépendantes
de l’identifiant.
 Deuxième Forme Normale (2FN) : Toutes les autres propriétés d’un objet doivent être en dépendance
fonctionnelle élémentaire par rapport à l’identifiant de cet objet.
 Troisième Forme Normale (3FN) : Toutes les autres propriétés d’un objet doivent être en dépendance
fonctionnelle directe par rapport à l’identifiant de cet objet.
D’autres types de forme normale plus avancée existent mais en pratique, la satisfaction de la troisième
forme normale suffit à garantir la qualité et la stabilité de la base de données.

15
Note de cours de MERISE Ralaivao

Chapitre VII – MODELE ORGANISATIONNEL DES TRAITEMENTS

1. Objectifs
Le Modèle Organisationnel des Traitements (MOT) spécifie l’organisation qui régira les données et les
traitements en répondant aux questions QUI ? QUAND ? et OU ?

2. Démarche
On prend en compte l’organisation actuelle pour proposer l’organisation future. On précise :

- L’affectation des traitements aux différents postes de travail ;

- L’enchaînement des traitements ;
- Le niveau et le type d’automatisation des traitements : manuel, automatisé en temps réel (mode unitaire
immédiat ou interactif ou conversationnel) ou automatisé en temps différé (mode groupé ou par lots ou
batch).

3. MOT orienté traitement interactif au MLD relationnel

Le niveau de description des traitements dépend de la phase (étude préalable ou étude détaillée). Pour les
traitements automatiques, on ajoute dans l’étude détaillée les informations suivantes dans le MOT :

‐ Le traitement est découpé en unités de traitement (UT)

‐ Les entrées nécessaires à chaque unité de traitement

‐ Les tables concernées par chaque unité de traitement

‐ Pour chacune des tables, le type d’accès (en lecture, écriture, lecture et écriture).

Exemple : Vérification de l’existence et de la solvabilité d’un client

‐ Les résultats produits par unité de traitement

‐ Les droits des utilisateurs (consultation, consultation et modification, aucun droit)

4. Formalisme
Le MOT reprend le même formalisme que le MCT mais plus détaillé. Les unités de traitement peuvent
s’enchaîner : le résultat d’une unité de traitement servira d’entrée à une autre unité.
Le MOT est représenté en plusieurs colonnes :
- La colonne « Temps » pour préciser « QUAND » aura lieu le traitement et sa durée
- Une colonne par poste de travail (« QUI » et « OU »)
- Une colonne pour les acteurs externes
- Une colonne pour le type et le niveau de traitement.

16
Note de cours de MERISE Ralaivao

Chapitre VIII – MODELE PHYSIQUE DES DONNEES

ET MODELE OPERATIONNEL DES TRAITEMENTS
1. Objectifs
Le niveau physique spécifie la réalisation des éléments du projet à travers les deux modèles :
- Le Modèle Physique des Données (MPD) qui précise l’implémentation du MLD relationnel dans un
SGBD (exemple : Microsoft Access, SQL Server, MySQL, Oracle, …) ;
- Le Modèle Opérationnel des Traitements (MOpT) qui est une préparation du développement du logiciel
d’application à mettre en œuvre.

2. Modèle Physique des Données

Ce modèle donnera un aperçu de la base de données en y ajoutant les différentes contraintes d’intégrité (en se
référant au dictionnaire des données).

Le MPD brut ainsi obtenu pourra faire l’objet d’une optimisation de gestion des données. Par exemple :

‐ la mise en place de certains index pour accélérer les recherches d’enregistrement,

‐ la dénormalisation de certaines relations,

‐ l’ajout de données de situation, …

Le MPD précise également la définition et l’utilisation des vues.

3. Modèle Opérationnel des Traitements

Le MOpT structure l’application en regroupant les UTs dans des ensembles cohérents. Dans la réalisation, on
utilisera un type d’interface ou un autre selon les capacités de l’équipe de développement et les habitudes et les
exigences des futurs utilisateurs (exemple : menu déroulant, barre d’outils, …).

Les choix doivent être cohérents aux chaînes de traitement et permettre une navigation facile dans les
applications.

La préparation du développement englobe :

‐ la définition des normes de développement (environnement, plateforme),

‐ la décomposition de l’application en modules.

17