Merise: Sommaire

Merise
Sommaire
INTRODUCTION........................................................................6
MERISE est une méthode de développement des projets informatiques de

gestion....................................................................................6
1 La démarche Merise : 3 découpages sur 4 niveaux.................6
1.1 Trois découpages........................................................................................ 6
1.2 Quatre niveaux : conceptuel, organisationnel, logique et physique...........7
2. L'organisation et les étapes d'un projet informatique..........10
CHAPITRE I LE NIVEAU CONCEPTUEL.......................................11
1 REPRESENTER L'ACTIVITE....................................................11
2 MODELE CONCEPTUEL DE COMMUNICATION.........................11
2.1 Intervenant............................................................................................... 11
2.2 Flux.......................................................................................................... 15
2.3 Information............................................................................................... 17
2.4 Exemple de MCC, messages et informations............................................19
2.5 Résumé du MCC....................................................................................... 20
3 MODELE CONCEPTUEL DE TRAITEMENT................................21
3.1 le modèle conceptuel de traitements reflète le pourquoi indépendant de l'organisation. 22
3.2 Opération conceptuelle............................................................................ 22
3.3 Résumé du MCT........................................................................................ 25
4 MODELE CONCEPTUEL DE DONNEES....................................25
4.1 Le concept : l'individu............................................................................... 26
4.2 L'association de concepts, la relation.......................................................29
4.3 Rappel sur les notions d'occurrences et d'ensemble................................33
4.4 Contraintes............................................................................................... 34
4.5 Quelques pièges à éviter pour construire les modèles.............................45
4.6 Modèles équivalents................................................................................. 57
4.7 Résumé du MCD....................................................................................... 67
4.8 Exercices.................................................................................................. 68
5 VALIDATION DES MODELES ENTRE EUX................................70
5.1 informations des messages / individus et relations..................................70
5.2 Modèles des opérations............................................................................ 72
6 VALIDATION DE L'UTILISATEUR............................................74
7 RESUME GENERAL DU CONCEPTUEL.....................................75
CHAPITRE II : LE NIVEAU ORGANISATIONNEL...........................78
1 POSTE DE TRAVAIL ET ORGANIGRAMME...............................78

1.1 Poste de travail......................................................................................... 78
1.2 Organigramme......................................................................................... 79
2 MODELE ORGANISATIONNEL DE TRAITEMENT (MOT).............82
2.1 La procédure est composée d'opérations organisées (Quoi ?) par des postes de travail (Qui ?)
....................................................................................................................... 83
2.2 Tâche-homme et tâche-machine sont dans l'opération............................84
2.3 Exemple de procédure ou MOT.................................................................85
3 MODELE ORGANISATIONNEL DE DONNEES (MOD).................86
3.1 L'organisation par site de mémorisation..................................................87
3.2 Evaluation des volumes des données.......................................................88
3.3 Le modèle de données s'organise : de nouveaux individus apparaissent. 89
3.4 L'étude des documents existants.............................................................91
4 MODELE ORGANISATIONNEL DE COMMUNICATION (MOC) : les messages
échangés entre sites..............................................................91
RACHDI MOHAMED
INTRODUCTION_________________________________________________________2 sur 214
5 VALIDATION MOD/MOT.........................................................93
5.1 Messages organisés/individus et relations organisés...............................93
5.2 Modèles en création et en consultation des opérations organisées..........96
6 VALIDATION PAR L'UTILISATEUR..........................................98
7 RESUME DU NIVEAU ORGANISATIONNEL...............................98
CHAPITRE III LE NIVEAU LOGIQUE.........................................102
1 LE MODELE LOGIQUE DE DONNEES, un exercice intellectuel.103

1.1 Enregistrement....................................................................................... 103
1.2 Chemin................................................................................................... 105
1.3 Construction du Modèle Logique de Données.........................................105
1.4 Optimisation........................................................................................... 111
2 MODELE LOGIQUE DE TRAITEMENT....................................114
2.1 Opération organisée et outils informatiques..........................................114
2.2 Outils informatiques............................................................................... 115
2.3 Outil interactif........................................................................................ 117
2.4 Outil en traitement différé......................................................................122
3 MODELE LOGIQUE DE COMMUNICATION..............................123
4 VALIDATION DONNEES/TRAITEMENT...................................124
4.1 Validation MOD / outils........................................................................... 124
4.2 Validation MLD / outils............................................................................ 125
4.3 Validation des outils par les actions de mise à jour de données d'enregistrement 125
5 VALIDATION DE L'UTILISATEUR..........................................126
6 RESUME DU NIVEAU LOGIQUE............................................126
CHAPITRE IV LE NIVEAU PHYSIQUE.......................................129
1 MODELE PHYSIQUE DE DONNEES.......................................130

1.1 Information ou lien................................................................................. 130
1.2 SGBD hiérarchique................................................................................. 130
1.3 SGBD navigationnel ou réseau...............................................................132
1.4 SGBD relationnel.................................................................................... 134
1.5 Eclater ou regrouper les enregistrements physiques.............................144
2 MODELE PHYSIQUE DE TRAITEMENT..................................145
3 MODELE PHYSIQUE DE COMMUNICATION............................146
4 VALIDATION MPT/MPD.......................................................146
5 RESUME DU NIVEAU PHYSIQUE..........................................146
CHAPITRE V RESUME DES M+ODELES...................................149
1 RESUME DES COMMUNICATIONS........................................149

2 RESUME DES TRAITEMENTS...............................................149
3 RESUME DES DONNEES......................................................149
CHAPITRE VI L'ORGANISATION D'UN PROJET..........................151
1. LES ACTEURS D'UN PROJET...............................................151

2. SCHEMA DIRECTEUR : le découpage en domaines et la planification. 151
3 ETUDE PREALABLE : le choix de l'organisation et des outils informatiques. 154
3.1 L'existant................................................................................................ 154
3.2 Micro-informatique ou un seul site.........................................................155
3.3 Plusieurs sites........................................................................................ 156
4. ETUDE DETAILLEE : spécifications externe et interne.........157
4.1 Cas d'un seul site................................................................................... 157
4.2 Cas d'informatique multi-sites................................................................157
5 REALISATION : le test de la méthode..................................158
6 LES POINTS FORTS DU PROJET...........................................158
CHAPITRE VII LA META-PHYSIQUE : MAINTENANCE, FORMATION ET

DOCUMENTATION.................................................................160
1 UN DICTIONNAIRE DE DONNEES, SINON RIEN.....................160

2 LA DOCUMENTATION AUTOMATIQUE EXISTE.......................160
3 QUI DIRIGE QUI ? Le conceptuel ou le physique..................160
CHAPITRE VIII EXEMPLES DE MODELES DE DONNEES.............162
1 META-MODELE..................................................................162
1.1 MCC........................................................................................................ 162
1.2 MCT et MOT............................................................................................ 163
1.3 MCD et MOD........................................................................................... 164
1.4 MLT......................................................................................................... 164
1.5 MLD et MPD............................................................................................ 165
1.6 Validations (conceptuel, organisationnel et fin d'étude préalable).........165
2 COMPTABILITE..................................................................166
2.1 Représentation des flux externes et internes.........................................166
2.2 Compte ou pôle d'analyse...................................................................... 167
2.3 Les deux comptabilités........................................................................... 169
CHAPITRE IX SOLUTION DES EXERCICES................................174
1 CONCEPTUEL.....................................................................174
1.1 MCC........................................................................................................ 174
1.2 MCT........................................................................................................ 174
1.3 MCD........................................................................................................ 174
2 ORGANISATIONNEL............................................................176
3 Logique............................................................................177
4 Physique...........................................................................178
5 RESUME............................................................................178
CHAPITRE X : EXERCICES......................................................180
1 MODELE CONCEPTUEL.......................................................180
1.1 Modèle conceptuel de communication...................................................180
1.2 Modèle conceptuel de traitement...........................................................185
1.3 Modèle conceptuel de données..............................................................186
1.4 Validation MCD/MCT................................................................................ 188
2. NIVEAU ORGANISATIONNEL..............................................188
2.1 MODELE ORGANISATIONNEL DE TRAITEMENT.........................................188
2.2 Modèles organisationnels de données....................................................190
2.3 Modèle organisationnel de communication............................................190
3. NIVEAUX LOGIQUE ET PHYSIQUE.......................................191
3.1 Liste des outils informatiques par procédure..........................................191
3.2 Validation liste des outils / MOD et planification....................................191
3.3 Modèle physique de données.................................................................192
3.4 Validation liste des outils / MLD..............................................................193
3.5 Modèle logique de traitement................................................................193
3.6 Modèle logique de communication.........................................................195
CHAPITRE XI 10 CRITÈRES DE CHOIX D'UN OUTIL D'AIDE À LA CONCEPTION 196
1. Pourquoi choisir un outil d'aide à la conception?...............196

2. Quels critères doit-il remplir ?..........................................197
CHAPITRE XII EXERCEZ-VOUS (DOCUMENTS AUTORISÉS).......199
Enoncé................................................................................199
1. Informatique et méthode.......................................................................... 199
2. Les 3 niveaux de MERISE.......................................................................... 200
3. Gestion de projet...................................................................................... 203
4. Le méta modèle........................................................................................ 203

5 La génération d'un Modèle relationnel......................................................204
CORRIGE..............................................................................205
1. Informatique et méthode.......................................................................... 205
2. Les 3 niveaux de MERISE.......................................................................... 205
3. Gestion de projet...................................................................................... 209
4. Le méta-modèle....................................................................................... 210
5. Générer un modèle relationnel.................................................................210
Quel est votre résultat ?.......................................................211
GLOSSAIRE..........................................................................212
Correspondance avec Merise 79 et anglais............................214
BIBLIOGRAPHIE....................................................................215
INTRODUCTION
Il faut ouvrir des cadenas différents avec des

clés différentes.
(Proverbe chinois)
Ce chapitre d'introduction donne une vue globale de la méthode MERISE. Le

lecteur pourra aborder dans les chapitres suivants le vocabulaire et les
détails de la méthode avec plus de facilité.
MERISE est une méthode de développement des projets

informatiques de gestion.
Elle tire son nom du MERISIER qui est un arbre porte-greffe. De façon
analogue, MERISE est le résultat de la greffe de plusieurs méthodes. Une
deuxième explication vient du fait que le mot MERISE se trouvait en haut à
gauche d'un dictionnaire ouvert à la lettre M.
Elle s'adresse à toutes les applications sur micro, mini-ordinateur ou grands
systèmes informatiques. Par commodité, l'organisme à informatiser sur
lequel s'applique la méthode est appelée ici entreprise.
Merise est actuellement la méthode la plus répandue en France.
Historiquement, la première version officielle de Merise date des travaux
coordonnés par le Ministère de l’industrie en 1979 ; le groupe de projet
comprenait, outre une équipe de recherche dirigée par M. H. TARDIEU,
plusieurs sociétés de service. Depuis, plusieurs versions ont été
développées. Voici venu le temps des MERISES. L'ouvrage de référence de
la méthode est celui de MM H. TARDIEU, ROCHFELD et COLETTI (Référence
1).
1 La démarche Merise : 3 découpages sur 4 niveaux.

1.1 Trois découpages
Pour étudier et développer l'informatique d'une entreprise ou de tout type
d'organisme, il est nécessaire de connaître ses échanges internes et avec
l'extérieur, comment elle réagit à une sollicitation externe et quelle est la
structure des informations qu'elle utilise.
La méthode MERISE décrit cette connaissance sous forme de trois
découpages : communication, traitement et données.
Communication
Les échanges ou la communication sont des flux entre systèmes,
notamment des flux d'informations ou messages.
Traitement.
Les traitements des messages, flux d'informations, décrivent les tâches à
effectuer à la réception ou pour l'émission d'un flux d'informations.
Données.
La structure de mémorisation des informations est représentée sous une
forme qui permet un passage aisé vers les "enregistrements informatiques".
1.2 Quatre niveaux : conceptuel, organisationnel, logique et
physique.
L'informatique consiste à mettre à disposition de l'utilisateur des moyens ou
des outils de gestion informatique. Avant de spécifier les moyens
informatiques, il est nécessaire de définir le travail de cet ou de ces
utilisateurs finals, de définir l'organisation du travail au sein de l'entreprise.
Afin de déterminer cette organisation, l'analyse des objectifs et des
fonctions majeures de l'entreprise doit être menée. Ainsi, l'informatisation
est conçue en fonction de l'organisation et l'organisation en fonction des
objectifs à atteindre.
L'enchaînement de l'informatique, de l'organisation et de la fonction
nécessite un découpage en niveaux de la démarche d'informatisation. Ces
niveaux sont nommés conceptuel pour l'étude des fonctions et
organisationnel pour l'étude de l'organisation. Le niveau définissant
l'informatique est séparé en deux : un niveau décrivant l'informatique sans
choix de matériel ou de logiciel précis, le niveau logique, et un niveau
décrivant le résultat de la méthode ou l'informatisation finale, le niveau
physique. Si les choix de matériel ou de logiciel sont effectués, certaines
phases du niveau physique sont abordables directement.
L'adoption de la méthode entraîne la définition des fonctions générales de
l'entreprise avant la définition de l'organisation et avant la définition des
outils informatiques. L'informatique n'est abordée qu'au troisième niveau,
si ce type de solution est retenu.
Il suffit, pour remonter ou descendre d'un niveau, de poser les questions :
 Pourquoi ? Alors, je remonte vers l'invariant.
 Comment ? Alors, je descends vers le plus mobile.
invariant
CONCEPTUEL FONCTION
ORGANISATIONNEL ORGANISATION
LOGIQUE
INFORMATIQUE
PHYSIQUE
variable
Les objectifs de l'entreprise : le niveau conceptuel.

Le plus invariant, le niveau conceptuel, définit les fonctions réalisées dans
l'organisme. Il répond à la question QUE FAIT L'ORGANISME ? Il est
déterminé par son activité. L'étape précédente, l'interrogation du pourquoi
de l'activité, cette remise en question de l'entreprise, n'est pas abordée par

Merise.
Les postes de travail de l'entreprise : le niveau organisationnel
Pourquoi une organisation ? Pour réaliser les fonctions de l'entreprise
décrites dans la première partie. Cela répond à la question QUI FAIT QUOI ?
Dans le cas de développement sur micro-informatique ou dans le cas où
l'application ne concerne qu'une seule personne, le niveau organisationnel
se ramène à sa plus simple expression, un seul poste de travail.
Conceptuel et organisationnel représentent toute l'entreprise. Les deux
niveaux suivants ne prennent en compte que la solution informatique
retenue.
L'informatique universelle : le niveau logique ou externe.

Puis, plus variable, est la forme que doit prendre l'outil informatique pour
être adapté à l'utilisateur, à son poste de travail. C'est le niveau logique, la
maquette des enchaînements d'écran et la réponse à la question AVEC
QUOI ? ou plus exactement AVEC L'AIR DE QUOI ? Le logique est
indépendant de l'informatique spécifique, des langages de programmation
ou de gestion des données.
L'informatique spécifique : le niveau physique ou interne.
Le dernier niveau, le plus variable, est l'outil informatique lui-même, les
fichiers, les programmes. AVEC QUOI ? Ce niveau est appelé niveau
physique.
Ce niveau dépend à 100% du système informatique retenu, du type de la
base de données et des outils de développement. MERISE est d'un secours
précieux dans le cadre des données. La structure "physique" informatique
des données tend à être normalisée. Le passage, à l'aide de règles, à ces
représentations normalisées est facile. C'est à cet instant que la méthode
justifie son utilisation dans le cadre de développement sur micro-
ordinateurs. Le modèle conceptuel de données engendre le modèle
physique de données.
L'existence des quatre niveaux permet un suivi méthodique. Cette étude se
conduit sans retour entre chaque niveau.
Le niveau inférieur peut être modifié sans affecter le niveau supérieur. Par
exemple, le niveau organisationnel peut être modifié sans affecter le niveau
conceptuel.
Le niveau inférieur doit être étudié après le niveau supérieur. Le niveau
logique est abordé après le niveau organisationnel et a fortiori après le
niveau conceptuel. Deux validations sont effectuées à chaque niveau avant
d'aborder le niveau inférieur. La première concerne la cohérence des
modèles entre eux. La deuxième est l'approbation de l'utilisateur.
C O L P
SENS DE L'ETUDE
Les retours sur le niveau précédent sont faibles

Une validation des modèles entre eux est "à cheval" sur plusieurs niveaux.
La fin de l'étude préalable, date importante dans la vie d'un projet, décide
de la réalisation du reste de l'étude. Ce choix s'effectue à partir de la liste
des outils informatiques. La validation entre données et traitement est
effectuée entre chaque outil retenu du niveau logique et les modèles
organisationnels de données. Cette validation vérifie l'exhaustivité de la
liste des outils informatiques à développer.
Etude Etude Liste des outils Etude Etude

conceptuelle organisationnelle et validation MOD logique Physique
ETUDE PREALABLE
L'étude préalable va jusqu'à la définition des outils
MERISE se résume à :
A- 3 découpages sur 4 niveaux.
 trois découpages (communications, données et traitements) fois
 les quatre niveaux conceptuel (quoi ?), organisationnel (qui fait quoi ?),
logique (avec l'air de quoi ?) et physique (avec quoi ? ou comment ?)
donnent douze modèles.
Merise décrit ces modèles sous forme de dessins.
 MCC = Modèle Conceptuel de Communication
 MCD = Modèle Conceptuel de Données
 MCT = Modèle Conceptuel de Traitements...
COMMUNICAT. DONNEES TRAITEMENT

CONCEPTUEL MCC M CD MCT
ORGANISATIONNEL MOC M OD MOT
LOGIQUE MLC M LD MLT
PHYSIQUE MPC M PD MPT
Les "temps forts" de la méthode sont le Modèle Conceptuel de

Communication (MCC), le Modèle Conceptuel de Données (MCD) et le
Modèle Organisationnel de Traitement (MOT). Parmi ces trois modèles, le
plus important concerne la représentation des modèles conceptuels de
données.
B. La représentation des modèles conceptuels de données.
Cette représentation des données est une représentation du système
d'information analysée à partir de la manière de parler, de "croquis de
langage" (référence 2). En effet, la manière de parler reflète la façon dont
une personne a mis en mémoire et a structuré ses pensées et ses données.
Cette syntaxe est aisément représentée sous forme de dessins.
La forme sous laquelle est réalisée cette représentation de données
s'appelle formalisme individu-relation. Elle permettra de déterminer les
individus et les relations entre individus. Le choix de ce qui sera individu ou
relation est le cœur de la méthode MERISE. Les individus sont
indépendants. Les relations ont toujours besoin des individus pour exister et
sont toujours perçues comme relation de... Ce formalisme est considéré
comme la partie essentielle de la méthode.
A partir d'une phrase simple, d'une description en langage naturel telle que
"le client passe une commande", la méthode consiste à découvrir des
concepts et leurs liens mutuels. Ceux-ci représentent la structure de
mémorisation sur laquelle s'appuie la phrase du discours. L'examen du
langage sert à retrouver le "non-dit" de la structure. Cette structure de
mémorisation est exprimée sous forme de rectangle et d'ellipse. Un nom
devient un rectangle, un "individu" et un verbe une ellipse, une "relation".
CLIENT COMMANDE
passer
"Le client passe une commande"
2. L'organisation et les étapes d'un projet informatique

Un planning général de développement ou schéma directeur détermine les
principaux projets à développer et leur enchaînement.
Les études préalables à la réalisation informatique comprennent les niveaux
conceptuels et organisationnels et une partie du logique : la liste des outils
informatiques et la validation de ces outils par les modèles organisationnels
de données. Le résultat de l'étude préalable est impérativement approuvée
par tous les acteurs du projet : utilisateur, informaticien, direction... Cette
phase entraîne le choix des futurs outils informatiques "utilisateur", des
outils de développement informatiques et des futurs investissements.
INTRODUCTION________________________________________________________10 sur 214
CHAPITRE I LE NIVEAU CONCEPTUEL
Sans entrer dans la tanière du tigre,

comment capturer ses petits ?
(Proverbe chinois)
1 REPRESENTER L'ACTIVITE
L'objectif est de représenter l'activité de l'entreprise et de formaliser son

"système d'information" indépendamment de son organisation.
Le compte rendu de cette étude est matérialisé sous la forme de dessins
normalisés, de modèles complétés par un dossier explicatif. Le but de ce
chapitre est d'expliquer comment décrire l'entreprise concernée en
respectant les normes de chaque modèle.
Le modèle de communication formalise les échanges d'informations entre
systèmes fonctionnels et identifie les systèmes "à mémoire".
Le modèle de traitement formalise, comme son nom l'indique, les
traitements effectués par un système fonctionnel, comment l'entreprise
réagit à une réception d'informations, ou quand, spontanément, elle décide
d'émettre des informations.
Le modèle de données est la référence de l'activité de l'entreprise, la
manière dont elle perçoit et mémorise son activité. Il formalise toutes les
informations mémorisées. Ces informations sont structurées, regroupées en
ensembles appelés individus et en ensembles appelés relations entre les
individus : les rectangles et les ellipses de MERISE qui vous seront bientôt
familiers.
2 MODELE CONCEPTUEL DE COMMUNICATION.

Une approche théorique est faite avec l'étude des systèmes, la systémique.
Celle-ci repose sur les principes suivants :
1 - Une approche du général au particulier. Tout système se décompose en
systèmes.
2 - La méthode s'attache à identifier les échanges entre systèmes.
3 - La systémique amène à décomposer l'entreprise en systèmes
homogènes d'information appelés domaines.
2.1 Intervenant
Application de ces principes.
- Du général au particulier et décomposition en systèmes.
L'entreprise est considérée comme un système. L'extérieur, avec qui
l'entreprise effectue ses échanges est aussi perçu comme un ensemble de
systèmes. L'entreprise est découpée en systèmes fonctionnels ou
conceptuels. Systèmes externes et internes sont appelés intervenants.
Entreprise
Systèmes
Flux ou Echanges
Tout est SYSTEME ou FLUX entre systèmes
VENDRE
ACHETER PILOTER
COMPTABILISER
PRODUIRE
PERSONNALISER
L'ENTREPRISE est un système qui peut être découpé

en systèmes FONCTIONNELS, les INTERVENANTS
Soit une entreprise de livraison. Ses intervenants sont livrer, facturer et
encaisser. Ils sont spécifiques de l'entreprise.
ENCAISSER LIVRER
FACTURER
2.1.1 partenaire
Un partenaire est un intervenant extérieur à l'entreprise. Il peut être perçu
de manière FONCTIONNELLE et décrit par un verbe : client (qui paye),
fournisseur (qui...), courtier (qui sert d'intermédiaire), associé (qui partage
les risques ou les profits) ou PHYSIQUE, société, Banque de France,
personne morale, personne physique, Etat. La perception fonctionnelle est
préférable à la perception physique : ne voir que le payeur dans le client, ce
qui n'empêche pas d'avoir tous les égards pour sa personne.
Un partenaire physique est perçu sous plusieurs vues fonctionnelles : si la
société EDF est à la fois fournisseur et cliente d'une même entreprise, elle
sera vue "fonctionnellement" de cette entreprise de deux manières
différentes, fournisseur (d'énergie) et client (payeur).
2.1.2 domaine et sous-domaine

Ils sont l'application du troisième principe de systémique : l'existence de
systèmes d'information homogènes.
Un découpage trop fin de l'entreprise entraînerait une perte de cohérence
de la fonction. Un niveau de ce découpage est identifié, représentant un
"tout homogène".
Un domaine est un système de l'entreprise qui a la caractéristique d'avoir
une mémoire, un système d'information. Le système d'information sera
construit par domaine.
L'entreprise est décomposée en domaines décomposés en sous-domaines,
somme de fonctions élémentaires.
Exemple : l'entreprise est entourée des systèmes tels que Client, Etat... les
partenaires. Elle est découpée en domaines : vendre, produire, assurer la
vie sociale, qui dépendent de son activité. Ces domaines sont décomposés
en systèmes appelés sous-domaines. "Produire" peut être découpé en
"Maintenir", "Assurer l'approvisionnement des chaînes de production"...
Partenaire Sous-Domaine Domaine
ENTREPRISE
Client
Produire Vendre
Maintenir
Etat
Assurer la
vie sociale
Les INTERVENANTS sont EXTERNES (PARTENAIRES) ou INTERNES à

l'entreprise
(DOMAINES et SOUS-DOMAINES)
Un sous-domaine est fonctionnel, joue un rôle. Si la vue est physique et le
nom donné à un sous-domaine un signe d'organisation (back office ou
gestion administrative, front office ou négociateurs, piloter ou chef), il faut
en dégager la vue fonctionnelle. Un verbe peut définir un domaine ou un
sous-domaine. Il représente une fonction, un nom représente plus une
entité physique ou morale (organisation, personne).
Exemples de domaines et de verbes associés : Trésorerie (optimiser les flux
financiers), Ventes (vendre, connaître les souhaits des clients), Comptabilité
générale (se conformer à la législation, assurer la sortie des documents
comptables dans les délais impartis), Pilotage (décider et suivre les
budgets, décider et suivre la planification). Toutes les définitions sont
sujettes à remaniement suivant le contexte.
A chaque domaine ou sous-domaine, des objectifs ou des critères
d'appréciation du résultat peuvent être définis : trésorerie, comparaison
avec un taux standard du marché monétaire ; ventes, nombre de clients
conservés ou nouveaux, chiffre d'affaires ; comptabilité générale,
observations du commissaire aux comptes ou délai de remise des
documents.
Dans le cas de petits services où les mêmes personnes effectuent plusieurs
fonctions, cette étape de définition des sous-domaines doit être limitée
dans le temps. En général, il existe plus de fonctions que de personnes et

l'utilisateur a beaucoup de peine à s'affranchir de l'organisation. La
définition des différentes fonctions est alors effectuée par rapport à la
définition des postes de travail actuels, portant préjudice à une définition
correcte des fonctions.
Pour identifier les domaines, deux approches sont possibles :
 soit ne voir directement que les fonctions majeures qui répondent à la
question pourquoi ?
 soit, si la première démarche n'aboutit pas à un accord général, énumérer
des fonctions élémentaires en réunion de "brain storming" et les
regrouper en sous-domaines, puis en domaines. Pour cela, répondre
toujours à la question pourquoi ? Pourquoi gérer des stocks, pourquoi
tenir une comptabilité, pourquoi enregistrer une commande ? Ainsi sous-
domaines et domaines seront découverts.
Exemple : soit les fonctions analyser la production, produire, gérer les
stocks, maintenir, gérer les pièces détachées, suivre les pannes et gérer les
réparations.
PRODUIRE MAINTENIR
analyser gérer les gérer les

produire
la production pièces réparations
détachées
gérer les stocks suivre les

pannes
Plusieurs découpages...
Nous allons recomposer ces fonctions en les réunissant en ensembles ou
systèmes fonctionnels en posant la question pourquoi ?
L'exercice pourrait s'intituler "Manger pour vivre ou vivre pour manger ?" La
règle à appliquer est : lorsque ceci explique cela, mettre cela dans le cercle
de ceci.
DOMAINE PRODUIRE POUR

VENDRE
P RODUIRE A
SOUS-DOMAINE MOINDRE C OUT
produire
FONCTIONS à tout prix
ELEMENTAIRES analyser la
production
L'entreprise est découpée en domaines, sous-domaines et fonctions

élémentaires.
 Pourquoi analyser la production ? Pour produire à moindre coût.
 Pourquoi produire ? Pour vendre.
 Pourquoi gérer les stocks ? Pour approvisionner la production.
 Pourquoi maintenir ? Pour produire.
 Pourquoi gérer les pièces détachées ? Pour approvisionner la main-
tenance.
 Pourquoi suivre les pannes ? Pour planifier les réparations.

 Pourquoi gérer les réparations ? Pour planifier les réparations.
Si les réponses précédentes sont correctes, nous arrivons à la découpe

suivante :
PRODUIRE POUR
VENDRE
PRODUIRE A MAINTENIR
MOINDRE C OUT
produire analyser la suivre les
à tout prix production pannes VENDRE
gérer les POUR ...
réparations
APP ROVISIONNER
gérer les pièces gérer les

détachées stocks
...sont possibles.
Les fonctions élémentaires, telles que analyser..., gérer..., suivre..., etc.,
sont trop fines et n'ont pas de véritable finalité. Elles ne sont pas traitées
dans l'analyse de l'entreprise.
2.2 Flux
Les intervenants définis, intéressons-nous aux échanges entre ceux-ci.
Suivant la systémique, ces échanges sont plus importants que les
intervenants.
Des flux sont échangés entre des émetteurs et des récepteurs, les
intervenants. Ils peuvent être réels (produit, énergie, argent) ou
d'information, les messages.
Le modèle de communication représente tous les flux et toute l'activité de
l'entreprise. Un dessin ne représentant que les messages est un sous-
ensemble du modèle de communication. Seul, ce sous-ensemble est détaillé
par la suite. En effet, non seulement les flux physiques sont suivis par des
messages porteurs d'informations, mais encore, l'informatique ne traite que
des informations.
2.2.1 Construction du MCC.
Pour s'aider, la construction d'un graphe des flux réels (physiques ou
financiers) est conseillée.
Bien différencier les flux physiques et d'informations : un catalogue
imprimé, vu de l'imprimeur, est un flux physique. Il s'apparente à un
produit. Le même catalogue, envoyé au client, est perçu comme un
message.
Exemple : produit livré, virement bancaire... L'entreprise donne le produit à
livrer à un livreur qui livre le même produit au client. Les flux physiques de
"produits" sont entre entreprise et livreur et livreur et client. Si le client
apporte de l'argent liquide à sa banque, le flux financier "liquidité" existe
entre Client et Banque. Enfin l'entreprise est payée par un virement, flux
financier, de la Banque.
Produit Liquidité
Client
Livreur Banque
Entreprise
Produit Virement
Voici les flux "réels".

2.2.2 message
Un flux est appelé message quand il est ensemble d'informations.
Le modèle conceptuel de communication MCC représente les échanges de
messages entre intervenants. Les messages décrits sont conceptuels et
indépendants de l'organisation. Si un document physique est analysé, les
questions sont "quels sont les messages conceptuels de ce document ?",
"quels sont les messages qui donneront lieu à une réaction ou une action de
l'entreprise ?" Pourquoi ce message et non qui traite le message ?
ENTREPRISE Etat des équipements :

équipements à réparer et à remplacer
Réparer
Optimiser Filiale
flux financiers
Acheter
sous un même "DOCUMENT PHYSIQUE"...

Exemple : le document "état des équipements" est envoyé par une filiale en
plusieurs exemplaires. Il correspond à plusieurs messages conceptuels
différents selon chaque récepteur. Pour l'un, le message est une demande
de réparation, pour un autre, un flux de trésorerie à prévoir pour payer la
réparation et pour un troisième, une demande d'achat des équipements. Le
message organisé ou "physique" comprend trois messages conceptuels :
ENTREPRISE
Demande de réparation d'équipements
Réparer
Optimiser Demande de liquidités

Filiale
flux financiers
Acheter
Demande d'achat d'équipements
...existent plusieurs messages conceptuels.

Une banque de données reçoit des messages avant d'en donner.
Le conceptuel consiste à trouver le pourquoi. Si nous nous intéressons à

l'activité d'une entreprise qui est une Banque de données, la question
"Pourquoi des abonnés consultent-ils une banque de données ?" doit être
posée. Le message conceptuel émis par la personne qui se connecte sur la
banque de données est une demande d'information. Il est nécessaire de
s'interroger sur le besoin d'information de l'abonné pour comprendre
l'activité de l'entreprise. La question se pose pour des motifs de marketing
ou d'étude du client. De manière organisée, seule la banque de données
émet des informations.
Deux types de messages sont distingués, les messages enclencheurs ou
stimulants et les messages informants. Messages enclencheurs et
informants servent à séparer les messages moteurs d'une action et les
messages moteurs d'une mémorisation.
message enclencheur
Dans ce cas, l'émetteur du message enclencheur attend une réponse ou
une réaction du receveur. Il s'agit, la plupart du temps, d'une demande
structurée - demande de remboursement dont les données sont
répertoriables : montant dû, date de la créance - ou non structurée : conseil
ou avis.
message informant
Un message informant renseigne sur une situation donnée sans attendre
une réponse immédiate : cours de la bourse, compte rendu synthétique
(reporting) vers la direction générale, journal des ventes, statistiques. Les
informations contenues dans ces messages serviront à moyen ou à long
terme. Elles constitueront le contexte de la réaction à un futur message
enclencheur. Au lieu de tourner sept fois ma langue dans ma bouche, je
tourne sept fois mes messages informants dans mon système
d'information. Quelquefois, le dernier arrivé est le message enclencheur
quand il est attendu pour réagir.
Les messages informants "n'existent pas" entre sous-domaines d'un même
domaine. Un domaine a un système d'information commun à tous les sous-
domaines. Ce que sait un sous-domaine, un autre le sait aussi en consultant
le système d'information propre aux deux sous-domaines. Cela découle du
troisième principe énoncé de systémique, l'existence de systèmes
d'information homogènes, les domaines. Le message transite par le
système d'information.
2.3 Information
L'information ou la donnée ou la propriété est l'atome du système
d'information et du futur système informatique. L'information est un
"renseignement" ou une "connaissance" élémentaire désignée à l'aide d'un
mot ou d'un groupe de mots prenant des valeurs.
Exemple : nom de personne, nombre de portes, nom de maison.
2.3.1 Occurrence d'information.
Une information est un ensemble d'occurrences, de valeurs possibles
d'information.
Soit l'information nom de personne. M. Martin, M. Doe, M. Smith,
M. Svensson, M. Joe six pack, M. Bolomey ou M. Mueller sont des exemples
de nom de personne. Une information est donc un ensemble d'éléments
dont M. Martin est un exemple. Chaque élément de cet ensemble est appelé
occurrence (avec deux r).
M. Mueller
Occurrences
d'information M. Doe
M. Martin
Information NOM DE PERSONNE
Une INFORMATION possède des OCCURRENCES

Un autre vocabulaire est de déclarer l'ensemble nom de personne comme
information-type par rapport aux informations M. Martin, M. Doe, M. Smith.
Dans l'ouvrage, la vue information et occurrence d'information est celle
retenue. Il en sera de même pour individu et occurrence d'individu et
relation et occurrence de relation que nous verrons plus tard.
 Information : exemples d'occurrences d'information
 Noms : dunepipe, paspossible, àcoucherdehors...
 Conseils : yaqua, fautquon, yavaitcas, fallaitquon, faites mieux la
prochaine fois, votre taux d'endettement est trop élevé...
 Type de voiture : R5, R11, AX,...
2.3.2 Validation et épuration du vocabulaire

Des informations peuvent avoir le même sens, des sens différents ou être
liées entre elles par composition ou une règle de calcul. Il importe
d'identifier le sens de chaque information en supprimant les ambiguïtés de
signification et les liaisons entre informations afin de manipuler un
vocabulaire "épuré" qui sera mémorisé.
Suppression des polysèmes et des synonymes.
Une information dont le nom a plusieurs sens, est un polysème. Montant
peut être le montant de la facture, du contrat, de la commande... Il importe
d'éclater ces informations en informations n'ayant qu'un seul sens pour
éviter toute confusion. Renseigner chaque information identifiée par un
texte évitant tout quiproquo.
1ère Signification
Un nom d'information
2ème Signification
un POLYSEME a au moins deux SIGNIFICATIONS

Les synonymes, ou les noms d'informations de même signification, sont
plus connus.
1er nom d'information

Une Signification
2ème nom d'information
Deux SYNONYMES ont la même SIGNIFICATION.

Néanmoins, un type de synonymie un peu particulier est à expliciter. Soient
les informations "numéro de donneur d'ordre" et "numéro de client". Un
donneur d'ordre est un client ayant passé une commande. Un client n'ayant
pas passé de commande est un prospect. "prospect" ou "client n'ayant pas
commandé" sont synonymes. Par contre, la notion de donneur d'ordre
apporte une restriction à celle de client. Un donneur d'ordre est un client qui
a commandé. Numéro de donneur d'ordre est un sous-ensemble des

numéros de client. Une équivalence "non équilibrée" est donc définie entre
ces deux informations. L'information la plus générale "numéro de client" est
en amont de l'information "numéro de donneur d'ordre". Noter l'équivalence
entre les informations.
Noter les informations composées et les règles de calcul
Information composée.
Une information peut être composée ou décomposée en plusieurs
informations. Noter les informations composées définit le niveau de détail,
l'information élémentaire à gérer dans le MCD.
Une Information composée =
1ère Information 2ème Inf. Nième Information
Une information peut être décomposée.

Soit le numéro de plaque minéralogique d'une voiture. Il est composé d'un
numéro d'ordre et du numéro de département. Le numéro de plaque est la
composition de ces deux informations. Le numéro d'ordre de la plaque est
lui-même composé de deux informations, une numérique, composée de
chiffres et une alphabétique, composée de lettres.
2125 WW 75 = 2125 WW 75 = 2125 WW 75
Le numéro de plaque est composé de 2 ou 3 informations.
Règle de calcul
Une règle de calcul lie plusieurs informations. Dans ce cas, noter les
informations en entrée et résultat de la règle et retenir quelles informations,
entrée ou résultat, seront mémorisées. Si les deux types d'informations
étaient retenues, une possibilité d'incohérence existerait. Ce qu'il faut éviter
à tout prix !
2.4 Exemple de MCC, messages et informations.
Entreprise Ordre de livraison

Livrer Livreur
Demande de Bon de livraison
facturation Demande de livraison
Facture Facture
Facturer Client
émise
Chèque
Avis d'encaissement
Encaisser Banque
MCC simplifié de l'entreprise de livraison

 Avis d'encaissement : numéro compte bancaire, montant à encaisser,

date d'encaissement.
 Bon de livraison : numéro de bon de livraison, date de livraison, adresse
de livraison, nom du client livré, nom du chauffeur.
 Chèque : numéro chèque, numéro facture, montant du chèque, date
chèque.
 Demande de facturation : numéro de bon de livraison, nom du livreur,
référence interne du colis.
 Demande de livraison : Référence du colis à livrer, date de livraison,
adresse de livraison, nom du client.
 Facture : numéro facture, numéro colis, montant facture HT, montant
facture TTC, date de paiement.
 Facture émise : numéro de client, numéro de facture, date de paiement.
 Ordre de livraison : numéro d'ordre de livraison, date de livraison,
adresse de livraison, nom du client, nom du livreur.
2.5 Résumé du MCC.

Le modèle conceptuel de communication représente les échanges de flux
de produits, d'énergie, de personne, de valeur ou d'information entre
systèmes. Ces systèmes fonctionnels appelés intervenants sont,
 soit externes à l'entreprise (partenaires),
 soit internes (domaine, sous-domaine). Un domaine de l'entreprise a un
système d'information propre à tous ses sous-domaines.
Les flux représentés peuvent ne concerner que des flux d'informations,
les messages. Ces messages sont informants ou enclencheurs. Il n'existe
pas de message informant à l'intérieur d'un même domaine.
Message = Domaine
Flux D'informations
Entreprise
Commande
Client
nom client Vendre
Partenaire adresse
date commande
montant commande
Sous-Domaine
Commande est un message entre domaine et partenaire

Un flux est un passage d'objets d'un intervenant à un autre. L'objet est émis
par un intervenant (l'émetteur) et reçu par un autre (le récepteur).
Un message est un objet transmis ne contenant que des informations. Les
intervenants communiquent par message.
Le modèle de communication est un dessin qui représente les flux
d'information (messages) ou non informationnels échangés entre les
intervenants internes de l'entreprise et les intervenants externes.
Les informations des messages peuvent être synonymes, polysèmes, liées
par une équivalence, une règle de calcul ou être composées.
EXERCICES :
1. Un message est-il un flux d'informations ou de matière ?
2. Penser est-il un domaine ?
3. "We demand..." est-il un message informant ?

4. Une demande de paiement est-elle un message informant ?
5. Un tract électoral est-il un message informant ?
6. Une facture est-elle un flux d'informations ou un flux réel ?
3 MODELE CONCEPTUEL DE TRAITEMENT.
Le modèle de traitement est un zoom sur le modèle de communication de

l'entreprise. Dans le modèle de communication, sont représentés les
messages échangés entre intervenants. Dans les modèles de traitement,
nous "voyons" comment un intervenant de l'entreprise réagit quand il reçoit
ce message et quelle opération il effectue.
Un modèle conceptuel de traitement (MCT) comprend les messages et leurs
informations, les opérations conceptuelles et leurs opérateurs, les
intervenants de l'entreprise. Les intervenants de l'entreprise pris en compte
sont les domaines pour un modèle global ou les sous-domaines pour un
modèle de traitement détaillé.
Messages Reçus à traiter
Intervenant : le MCC (intervenant et messages) est

domaine ou sous-domaine détaillé par...
Messages Reçus
Messages Émis traités
Opération
Intervenant
Messages Émis
... le MCT (opérations et messages)
COMMANDE VENDRE
CLIENT
nom client
adresse
date commande
montant commande
MCC : Mais que peut donc bien faire VENDRE

quand il reçoit la commande ?
Vendre traite la commande. L'opération traite ou émet un message. Le
message est événement ou résultat de l'opération.
COMMANDE
CLIENT
nom client VENDRE
adresse
date commande traiter la
montant commande commande
MCT : Vendre traite la commande.
3.1 le modèle conceptuel de traitements reflète le pourquoi

indépendant de l'organisation.
Le Modèle Conceptuel de Traitement reflète le QUOI de l'activité de
l'entreprise et le comment spécifique, les règles de gestion ou les choix de
traitement. A ce niveau, la stratégie de l'entreprise n'est pas abordée, mais
la cohérence de l'ensemble, la réponse aux différents cas de situation est
étudiée en détail.
L'opération peut être différente suivant chaque utilisateur. Une fois le
choix de gestion fait par l'utilisateur, l'opération décrit fidèlement son choix.
Exemples de choix de traitement à faire par l'utilisateur :
1 - La facture est émise dès réception de la commande.
2 - La facture est émise dès la livraison.
3 - La facture est émise dès la connaissance du compte-rendu de
l'inspecteur chargé d'inspecter le chargement de la marchandise.
4 - La facture est émise dès réception d'un document particulier : douane,
plan d'implantation particulier, crédit documentaire...
5 - La facture est émise avant la commande. C'est le cas de fausse facture.
3.2 Opération conceptuelle

L'opération conceptuelle est un traitement, un travail effectué par un
intervenant afin d'émettre un message et/ou d'en traiter un dans un but
précis. L'opération est effectuée par un intervenant interne, un domaine ou
un sous-domaine. L'opération est dite conceptuelle, indépendante de
l'organisation. Seules les opérations effectuées par l'entreprise, les
intervenants internes, sont analysées.
Exemple : la commande est une commande de coke. Le message à traiter
ou événement de l'opération est commande de coke. Les messages
pouvant résulter de l'opération sont les ordres de livraison ou de
réapprovisionnement ou une proposition de produit de substitution au
client.
Commande de coke
Client Vendre
Proposition De Produit
De Substitution
Ordre De
livrer
Ordre De Livraison
Produire
Réapprovisionnement
MCT : "commande" est EVENEMENT et

"ordre de livraison" RESULTAT de l'OPERATION
Le résultat de l'opération dépend de certaines conditions ou, exprimé
différemment, une opération peut comporter plusieurs messages en sortie
ou résultat de l'opération à des conditions définies. Ces conditions
dépendent des informations du message reçu, d'informations mémorisées
ou d'une règle humaine non formalisée.
Opération
Condition
Message
un MESSAGE RESULTAT est émis à une CONDITION.

Exemple de la prise de commande. L'ordre de livraison est émis si le
produit (coke) est en stock. S'il ne l'est pas, une proposition de produit de
substitution est émise ainsi qu'un ordre de réapprovisionnement.
Commande de coke
PRISE DE COMMANDE
Pas de C oke C oke en
en stock stock
Proposition De Produit Ordre De Livraison

De Substitution
Ordre De
"ordre de livraison" n'est émis

que si la CONDITION "coke en stock" est vraie.
3.2.1 opération avec synchronisation
Pour effectuer une opération, l'intervenant a quelquefois besoin de
plusieurs messages qu'il a reçus ou qu'il va recevoir.
DOMAINE OU
SOUS-DOMAINE
accord de la grand-mère
accord du père accord de la mère
(a ou b) e t c
ALLER AU CINEMA
Emploi du temps
1. La SYNCHRONISATION comporte des "ET" et des "OU" de MESSAGES

arrivant tous en même temps.
Exemple : pour aller au cinéma, j'ai besoin de l'accord de mon père et de

ma mère. Sachant que l'accord de ma grand-mère paternelle remplace celui
de mon père, la synchronisation est : pour enclencher l'opération aller au
cinéma, le message Accord du père ou de la grand-mère et le message
Accord de la mère sont nécessaires.
La synchronisation peut être plus complexe. L'accord de ma grand-mère
peut remplacer celui de mon père tandis que celui de mon oncle me suffit à
lui tout seul.
3.2.2 Opération sans synchronisation
Une deuxième manière d'aborder ces problèmes de familles (mère, père,
oncle et grand-mère) est de scinder l'opération précédente avec ses "ou" et
ses "et" par des opérations d'enregistrement de l'accord considéré et de
mettre comme condition de sortie (au cinéma) les accords nécessaires. Pour
toutes les opérations, le message résultat sera l'emploi du temps fourni.
accord de la mère accord du père accord de la grand-mère
Prise En Compte Prise En Compte Prise En Compte

accord Mère accord du Père accord Grand Mère
accord du Père ou accord de la Mère accord de la Mère
de la grand Mère
emploi du temps
= aller au cinéma
2. Les MESSAGES arrivent un par un...
accord de la mère accord du père accord de la grand-mère
Prise En Compte Prise En Compte Prise En Compte

accord Mère accord du Père accord Grand Mère
Planifier emploi
du temps
si ac c ords ...
emploi du temps = aller au cinéma
3. EVENEMENTS et RESULTATS ne font pas partie de la même OPERATION

Une troisième manière est de décrire N opérations d'enregistrement des N
accords et une seule opération "aller au cinéma" si les conditions sont
requises.
La deuxième représentation est la plus proche de la réalité. Les messages
vont et viennent les uns indépendamment des autres, non simultanément.
Les réactions diffèrent suivant chaque cas. Si j'ai l'accord de ma mère, je
peux aller demander celui de ma grand-mère plutôt que celui de mon père.
Une autre différence entre ces représentations est le glissement de la
condition d'émission du message résultat vers l'opération ou le message.
Dans le premier cas, la condition est la synchronisation, la combinaison des
et et des ou, le résultat de la condition est l'opération "aller au cinéma".

Dans les deuxième et troisième cas, les conditions concernent l'émission
des messages résultats et le résultat est le message "je vais au cinéma".
Messages événements :
a b c
Condition
Planifier emploi du temps

(a ou b) et c
Condition
ALLER AU si accords : (a ou b) et c
CINEMA
Message résultat :
Message résultat :
emploi du temps = aller au cinéma
emploi du temps
la CONDITION porte sur l'entrée ou l'émission du message.

La troisième représentation a l'avantage de la simplicité, c'est la raison
pour laquelle elle est conseillée.
3.3 Résumé du MCT.

Un modèle conceptuel de traitement part du modèle conceptuel de
communication en examinant les opérations conceptuelles effectuées par
domaine dans le cas général et par sous-domaine dans le cas détaillé.
Message événement
Intervenant :
Sous-Domaine ou Domaine
Opération
Message résultat Condition
MODELE CONCEPTUEL DE TRAITEMENT

Les opérations analysent les traitements des messages événements pour
les transformer en messages résultats. Elles sont enclenchées par zéro,
dans le cas d'opérations décidées par l'intervenant, un ou plusieurs
messages événements. Elles émettent zéro, un ou plusieurs messages
résultats. Les conditions d'émission sont décrites sur les messages
résultats.
Exercices : vrai ou faux ?
1. Une opération conceptuelle peut n'être effectuée par aucun intervenant.
2. Une opération conceptuelle peut être effectuée par plusieurs
intervenants.
3. Un message peut être événement de plusieurs opérations.
4. Un message peut être résultat de plusieurs opérations.
5. Plusieurs messages conceptuels peuvent apparaître en même temps, de
manière synchronisée.
4 MODELE CONCEPTUEL DE DONNEES

La formalisation des données est le point majeur de la méthode Merise. Il
est important de bien saisir ce chapitre si vous voulez passer pour un
Merisien confirmé.
Pourquoi cette approche données ? Un grand nombre d'ensembles
d'informations manipulées nécessite un travail de cohérence indispensable
et d'optimisation des coûts de stockage et de traitement des informations.
Cette complexité sur les ensembles d'informations, que l'on trouve en
informatique de gestion, a rendu nécessaire la création d'une méthode qui
prenne en compte la structure des informations. Cette méthode s'applique
aussi bien aux développements sur micro-ordinateurs qu'à ceux sur grands
systèmes informatiques.
Les informations sont structurées et classées, sans répétition, en deux
types d'ensembles (d'informations), les individus et les relations.
Un individu est un concept ou un "objet de gestion" conçu par l'esprit de

l'utilisateur lui permettant d'organiser ses connaissances. Une relation est
une association d'individus.
Exemple : Maison est un individu, un concept ayant comme infor mations
hauteur, surface au sol, nombre de portes, nombre de fenêtres, caractère,
couleur... Rivière est un autre individu ayant comme informations largeur de
la rivière, débit de la rivière, vitesse du courant... Une information portée
par la relation ou l'association (maison, rivi-ère) est la "distance la plus
courte entre une maison et une rivière".
La démarche consiste à identifier directement les concepts de maison et de
rivière pour ensuite déterminer les informations d'une maison, d'une rivière
ou de l'association (maison, rivière).
L'approche par les concepts étudie l'activité du domaine, construit les
individus et les relations et range ensuite les informations dans ceux-ci. Le
contrôle de cohérence entre les informations et celles existantes sur les
documents actuels est fait plus tard.
Individus et relations sont étudiés en premier. Les règles à respecter sur les
informations pour obtenir un modèle de données correct sont ensuite
développées. Les compléments à apporter au modèle, les contraintes sont
ensuite abordés. Enfin, la vie d'un modèle et les différents pièges à éviter
entre information, individu et relation seront passés en revue.
4.1 Le concept : l'individu

Un individu est un concept ou une boîte parallélépipèdique. Un individu
est un ensemble d'informations qui a une existence propre. L'individu
PERSONNE comprend les informations, nom, prénom, date de naissance...
PERSONNE Individu
nom
prénom Informations
date de naissance
Un individu porte des informations

4.1.1 Occurrences d'individu

Elément d'un ensemble : Martin, Durand, Dupond sont des occurrences
de l'individu PERSONNE. La boîte "personne" contient des occurrences de
l'individu "personne".
Voici des exemples d'individus : les zones grisées sont les occurrences
d'individu, les zones blanches désignent les ensembles, les individus.
OCCURRENCES D'INDIV IDUS
ma voiture
c elle de mon onc le la poussette Père Noël 87
la mienne mon vélo Père Noël 88
VOITURE VEHIC ULE C OMMANDE
INDIV IDUS
Les OCCURRENCES d'un INDIVIDU peuvent être CITEES

L'occurrence "mon neveu" de l'individu PERSONNE possède, comme
occurrences d'information Ernie, benjamin, 22 Mars 1980.
Ernie
Occurrences
Benjamin
d'information 22 03 1980 Occurrence
PERSONNE d'Individu
nom
Informations prénom
date de naissanc e Individu
un INDIVIDU est un ensemble d'INFORMATIONS

Dans l'approche par les concepts, les informations sont secondaires.
L'important est de pouvoir désigner les occurrences de l'individu facilement.
Quand l'individu "personne" existe, les informations qu'il porte, ses
propriétés peuvent être mentionnées plus tard. A la question "cite moi des
occurrences de tel individu", la réponse doit être aisée. En conséquence, les
occurrences d'individus peuvent être identifiées. Même deux clones sont
identifiables par un code, un numéro, une référence, en un mot, un
identifiant. Celui-ci est une information particulière.
Le modèle de communication est d'un certain secours. Les candidats à
l'individualisation sont : les partenaires (client, fournisseur) et leurs
ressources éventuelles (dépôt, site), les messages conceptuels importants
(commande, facture...) typiques de l'activité et les flux réels (produit,
devise).
A un niveau plus pragmatique ou plus avancé, apparaissent des individus
"forcés" tels que ligne de facture, barreau d'une échelle... , qui n'ont pas
d'existence propre, mais sont représentés par des carrés. Ces cas sont
développés plus en avant.
4.1.2 Règles sur les individus
Les règles définies par le groupe de travail du Ministère de l’industrie à
l'origine de la Méthode Merise en 1979 sont :
un individu est un objet répondant aux conditions suivantes :

1 - être d'intérêt pour l'organisation
2 - être distinguable parmi les autres individus de son type, c'est-à-dire qu'il
existera un identifiant par individu (numéro, code, référence...)
3 - avoir une existence propre, "c'est-à-dire une existence concevable sans
hypothèse sur l'existence d'autres éléments du réel perçu".
4 - être doté d'un ensemble unique de propriétés. Toutes les informations
ont une seule valeur, une seule occurrence pour une occurrence d'individu.
PERE
nom père
Contre-exemple : prénom père
prénom 1er fils
prénom 2ème fils
prénom 3ème fils
Tous les Pères n'ont pas de 2ème fils.

MAUVAIS : un père peut ne pas avoir de puîné (deuxième fils). Ceci n'est un
individu que pour les pères de 3 fils et 3 fils seulement.
VEHICULE
vitesse maximum
niveau de bruit
prix de revient au km
BON : les informations ont un sens pour tous les véhicules.

ATTENTION : la puissance du moteur n'est pas une information de l'individu
VEHICULE car mon vélo n'a pas de moteur. L'information "puissance du
moteur" n'a aucun sens pour l'occurrence "mon vélo" de l'individu
VEHICULE
VEHICULE
Contre-exemple : vitesse maximum
niveau de bruit
puissance du moteur
Certains véhicules n'ont pas de moteur.

4.1.3 Règles sur les informations des individus
1 - Une information est dans un seul individu (ou une seule relation).
2 - Une seule occurrence d'information par individu. La valeur d'une
information est unique pour un individu (nommé aussi ensemble unique de
propriétés d'un individu)
PERE
nom père
Contre-exemple :
prénom père
prénom fils
"prénom fils" existe plusieurs fois.

MAUVAIS : le prénom du fils n'est pas une information unique pour l'individu
Père.
PERE FILS
nom père
prénom fils
prénom père
Deux individus "PERE ET FILS" existent

BON : un père peut avoir autant de fils qu'il le désire.
Il faut pouvoir exprimer le fait que le père est lié au fils. C'est le rôle de la
relation.
4.2 L'association de concepts, la relation

Une relation représente une possibilité de "lien" entre deux ou plusieurs
occurrences d'individus. Pour une relation donnée, les individus sont fixés.
La relation est entre les individus et a besoin d'individus pour exister. Elle
est représentée par une ellipse reliée par des traits aux rectangles
représentant les individus.
PERE FILS
nom père avoir
prénom fils
prénom père
UNE RELATION RELIE DES INDIVIDUS

Un père et un fils "peuvent" être liés par la relation avoir
Une relation n'a pas d'existence propre et doit être définie par les individus
auxquels elle est rattachée.
son godillot Individus glissière

ta botte brin
ma botte de paille
CHAUSSURE TYPE DE
lier FERMETURE
Relation
une RELATION a besoin D'INDIVIDU(S) pour exister

Une relation peut porter des informations. Elle peut aussi (et souvent) ne
pas en porter.
Une relation est un ensemble unique de propriétés. Les informations

portées par une relation ne sont que dans cette relation et ont une seule
valeur par occurrence de relation.
Si elle relie deux occurrences d'individu, de deux individus différents ou
d'un même individu, elle est dite binaire, trois occurrences d'individu,
ternaire, quatre, quaternaire...
Chaque lien de la relation vers un individu est appelé "patte".
2 PATTES
C OMMANDE PRODUIT
passer
Relation binaire
3 PATTES
COMMANDE PRODUIT
passer
CATALOGUE
Relation ternaire
Exemple de relation ternaire (référence 6) : soient les trois individus
Document, Personne et Rôle et la relation "signer" qui concerne la signature
d'un document par une personne et pour un rôle donné.
Si le message secret est signé comme suit la première fois :
Message secret Eudes Emetteur
Message secret Le Bouillon Responsable
Message secret Nicolas Contrôleur
Message secret Agnan Rédacteur
Message secret Le Bouillon Rédacteur
Et qu'un document soit toujours signé ainsi, toute personne ayant signé le
message l'ayant fait avec un rôle donné, le modèle sera :
rédac teur agnan

c ontroleur nic olas
responsable le bouillon
émetteur eudes
ROLE PERSONNE
signer
Le message sec ret
DOCUMENT
Une relation peut relier plus de 2 individus

Il est recommandé de désigner la relation par un verbe. Néanmoins, ce

verbe ne représente la relation que dans un sens ou une patte de la relation
vers un individu. Le père "engendre" le fils et le fils "est engendré" par le
père. Pour bien faire, un verbe par "patte" devrait être donné. Dans le cas
de "nomenclature" c'est-à-dire de relation sur le même individu, il est
conseillé de nommer les pattes.
relation
engendrer
parent de fils de
PERSONNE conduire VOITURE

nom personne no voiture
prénom appartenir
"engendrer" relie un individu "personne". "conduire" et "appartenir" relient

"personne" et "voiture"
4.2.1 Nomenclature
Deux types de nomenclature, de relation sur le même individu, existent. La
première, quand un fils n'a qu'un seul père, est dite hiérarchique. La
deuxième, quand un fils peut avoir plus d'un père, peut être appelée
"matricielle" ou "tensorielle".
La première se présente sous la forme d'une arborescence : une branche
pousse sur une seule branche.
Parent de...
Père
Fils de...
Fils Fils
Parent de...
Petit Fils Petit Fils Fils de...
Nomenclature HIERARCHIQUE
Si un fils a deux pères, un spirituel et un réel, la nomenclature ou la
structure est dite matricielle.
spirituel
réél
2ème père
1er père
Matrice
Si le nombre de pères est supérieur à deux, la représentation est difficile, la
structure est tensorielle et crée des tensions.
4.2.2 Règle importante sur une relation.

Une relation n'a pas d'existence propre et est définie par les individus
auxquels elle est rattachée.
Dans le cas de relation binaire, une occurrence d'1 individu relie UNE FOIS
une occurrence d'1 autre individu.
Exemple : le nombre de produit déterminé dans une commande est fonction
de la commande et du produit uniquement et, si une commande et un
produit sont sélectionnés, un nombre unique est obtenu.
(occurrence de commande, occurrence de produit) => une occurrence de
quantité commandée qui est une information de la relation comprendre.
Occurrence de relation.
Une occurrence de relation existe si le couple ou le n-uplet relation
(occurrence d'individu 1, occurrence d'individu 2,..., occurrence d'individu
n) est vrai pour la relation considérée.
Les occurrences de relation sont les couples, triplés, quadruplets ou n-uplets
d'occurrences d'individu représentés par un noeud de ficelle rattaché à des
brins, les occurrences de pattes, reliant les occurrences d'individu à
l'occurrence de relation. Dans le cas de relation binaire, l'occurrence de
relation a deux brins ou deux occurrences de patte.
Occurrence Occurrence
de relation de patte
brin
ma botte de paille
CHAUSSURE TYPE DE
lier FERMETURE
Les occurrences d'individu d'une relation ne peuvent définir qu'une

occurrence de relation.
3 occurrences de relation
bic yc lette
wagon
Père Noël 88 montre
Père Noël 87 train élec trique
COMMANDE PRODUIT
comprendre
qté c ommandée
Patte "Commande" Patte "Produit"
1 occurrence de relation binaire relie 2 occurrences d'individus

Dans une relation entre individus distincts, il existe autant d'individus que
de pattes. Dans ce cas, la patte peut être désignée par le nom de l'individu
relié : patte "commande" et patte "produit".
2
1
1
wagon
COMMANDE PRODUIT
comprendre
qté c ommandée
Les RELATIONS peuvent contenir des INFORMATIONS

L'information "quantité commandée" est située dans la relation
"comprendre". En 1987, j'ai commandé au Père Noël 1 train électrique et
une montre, en 1988 j'ai commandé 2 wagons.
Dans le cas de relation ternaire, l'occurrence de relation possède trois brins
ou trois occurrences de pattes.
occurrence de la
2 occurrences de
patte "personne"
la relation "signer"
agnan
nic olas
le bouillon
Le message sec ret eudes
DOC UMENT PERSONNE
signer
rédac teur
Patte "Rôle" c ontroleur
responsable
émetteur
ROLE
...ou plus de deux occurrences d'individus

signer (message secret, émetteur, eudes) = vrai
Reprenons l'exemple de relation ternaire du document secret. Pour un triplé
d'occurrences des individus Document, Rôle, Personne, l'occurrence de
relation existe ou n'existe pas.
 signer (message secret, émetteur, eudes) = existe
 signer (message secret, responsable, Le bouillon) = existe
 signer (message secret, émetteur, Agnan) = n'existe pas
4.3 Rappel sur les notions d'occurrences et d'ensemble.

Ensemble et occurrences existent pour les informations, les individus, les
relations et les pattes.
Prenons l'exemple dessiné : l'individu est "Personne", les occurrences
d'individu sont Martin et Pêcheur. Les informations sont "nom personne" (M.
Martin) et "prénom" (Jean-philippe). La relation est "engendrer" et les pattes
"parent de" et "fils de".
fils de
parent de
engendrer Pecheur
parent de fils de Martin
PERSONNE M. Martin
jean-phil
nom personne
prénom
Concept ou Ensemble Occurrence ou élément
Information nom de personne M. Martin
Personne Martin
Individu M. Martin
Engendrer
Relation
Patte Fils de
Pour raccourcir la phrase, au lieu de dire une occurrence de l'individu

PERSONNE, on s'autorise à dire une personne.
4.4 Contraintes.
Si un modèle indique les relations entre les individus personnes, prêts ou
demandes de prêts, est-ce que toutes les personnes peuvent déposer une
demande de prêt ? Celles qui ont un prêt doivent-elles avoir préalablement
déposé une demande ? Peuvent-elles avoir un prêt et déposer une autre
demande ? Combien de prêts leur sont-ils accordés ? Les réponses à ces
questions peuvent être dessinées sur un modéle de données sous la forme
de contraintes.
Les contraintes sont un complément d'explications, des restrictions ou des
graffitis indispensables sur les modèles de données et autant de contrôles
ultérieurs.
Un modèle de données sans contrainte n'est pas complet. Il est nécessaire,
de préciser sur un modèle de données, que le propriétaire d'une voiture est
soit une personne, soit une société, qu'une contrainte existe entre les 3
individus voiture, personne, société et leurs relations.
Les contraintes sont les suivantes, notées de a à g.
a. Les cardinalités minimales et maximales

La cardinalité d'une occurrence d'individu dans une relation donnée est le
nombre d'occurrence(s) de relation que possède cette occurrence d'individu
via la relation.
Dans le cas de relation binaire (reliant deux individus), ce nombre est le
même que le nombre d'occurrence(s) d'individus reliés.
4
3
2
COMMANDE PRODUIT
c onc erner
Quand je compte le nombre de produit(s) d'une commande...
COMMANDE PRODUIT
c onc erner
...je m'intéresse aux cardinalités de la patte "Commande" (de gauche)
COMMANDE PRODUIT
c onc erner
Quand je compte le nombre de commande(s) d'un produit...
COMMANDE PRODUIT
c onc erner
...je m'intéresse aux cardinalités de la patte "Produit" (de droite)

La cardinalité minimale d'une relation vers un individu ou de l'individu vers
la relation (de la patte) est trouvée en comptant le nombre minimum
d'occurrence d'individu dans le cas de la relation binaire (entre deux
individus). Si ce nombre est différent de zéro, la cardinalité minimale est
déclarée égale à 1 par convention.
COMMANDE PRODUIT
c onc erner
La Commande peut-elle ne concerner aucun Produit ?

NON => cardinalité minimale = 1
OUI => cardinalité minimale = 0
La cardinalité maximale d'une relation vers un individu ou de l'individu vers
la relation (de la patte) est trouvée en comptant le nombre maximum
d'occurrence(s) possible d'individu dans le cas de relation binaire (entre
deux individus). Si ce nombre est différent de un, la cardinalité maximale

est notée par la lettre N par convention (N est supérieur à 1).
1 seul maximum ?
COMMANDE PRODUIT
c onc erner
La commande concerne-t-elle un seul produit maximum ?

OUI => cardinalité maximale = 1
NON => cardinalité maximale = N
L'ordre des cardinalités est minimum, maximum.
Cardinalités minimum
CLIENT COMMANDE
0,N 1,1
nom client passer date commande
adresse montant
Cardinalités maximum
Cas des individus "commande" et "produit" : un produit peut n'être

concerné par aucune commande, cardinalité minimale 0. Il peut être
commandé plusieurs fois cardinalité maximale N. Les cardinalités de la
relation du côté "produit" sont 0,N. Chaque commande comprend un produit
au minimum et N (supérieur à un) au maximum. Les cardinalités de la
relation "concerner" du côté commande sont donc un au minimum et N au
maximum.
COMMANDE PRODUIT
1,N 0,N
c onc erner
Voilà le résultat !
Si une des pattes a une cardinalité maximale à 1, il est d'usage de
représenter une flèche partant de cette patte. Une commande concerne un
client au maximum. La flèche part de la commande vers le client.
CLIENT COMMANDE
0,N 1,1
nom client passer date cde
adresse montant
Exemple de la commande au Père Noël.

Voici les cardinalités des occurrences d'individu :
2
1
3 bic yc lette
Père Noël 89 2 wagon
COMMANDE PRODUIT
comprendre
qté c ommandée
OCCURRENCE DE L'INDIVIDUNombre d'occurrences de patte COMMANDE

"commande"
Commande 87 2
Commande 88 2
Commande 89 0
OCCURRENCE DE L'INDIVIDU Nombre d'occurrences de patte PRODUIT

"produit"
Train 1
Montre 2
Wagon 1
Bicyclette 0
En supposant que tous les cas sont représentatifs, les cardinalités sont :
pour la patte "Commande" de gauche 0 minimum et N maximum, pour la
patte "produit" de droite 0 minimum et N maximum. Ce dessin est donc
contradictoire avec les cardinalités minimales de la commande. Il ne devrait
pas comporter de commande (89) sans produit.
Cas de nomenclature
Une nomenclature est une relation sur le même individu. Une personne
engendre une autre personne. une personne est supérieure ou subordonnée
à une autre personne.
composer organiser
c omposant
c omposé subordonné
supérieur
PRODUIT PERSONNE
Si la nomenclature est hiérarchique, une cardinalité maximale est 1 et la

nomenclature peut être représentée par une flèche. Les cardinalités sont
0,N du supérieur au subordonné et 0,1 du subordonné au supérieur. Une
personne peut être le supérieur de zéro à N subordonnés et avoir au
maximum 1 supérieur.
Si la nomenclature est non hiérarchique, les cardinalités maximales sont N.
Les cardinalités sont 0,N du parent au fils et 1,N du fils au parent. Une
personne peut être le parent de zéro à N fils et le fils de un à N (deux)
parents.
composer 0,N organiser

0,1
c omposant
c omposé subordonné
supérieur
PRODUIT PERSONNE
0,N 0,N
Voici les deux cas de nomenclatures.
couronne
hiérarchiser de plumes
2 plumes
- une plume
1 plume
+ une plume
INDIEN
La FLECHE indique une HIERARCHIE.

Dans le cas de relations reliant plus de deux individus (ternaires et...) il faut
compter le nombre de relations.
Exemple : le document est signé deux fois, mais par une seule personne.
agnan
nic olas
le bouillon
DOC UMENT P ERSONNE
signer
rédac teur
c ontroleur
responsable
émetteur
ROLE
Le message secret est signé DEUX FOIS

mais relie TROIS OCCURRENCES D'INDIVIDU (deux rôles et une personne)
Deux petits brins, les occurrences de pattes, partent de l'occurrence
Message secret. Le message secret est signé deux fois. Un document est
signé une à N fois (pas de document sans signature).
DOC UMENT
1,N
signer
.
Toute personne peut signer un document pour un rôle de zéro à n fois. Deux
occurrences de pattes partent de l'occurrence Eudes (zéro à N occurrences
de patte peuvent partir d'une occurrence de personne pour la relation
signer) et
PERSONNE
0,N
signer
un rôle peut être utilisé en signant de zéro à N fois. Une occurrence de patte
part de l'occurrence Emetteur (un rôle peut ne pas participer ou participer N
fois à la relation signer).
ROLE
0,N
signer
Le résultat est :
DOC UMENT PERSONNE

1,N 0,N
signer
ROLE
0,N
Voici les cardinalités de la relation "signer".

DEFINITIONS :
 La cardinalité d'une patte d'une occurrence d'individu lié à la patte est le
nombre d'occurrence(s) de patte liée(s) à l'occurrence d'individu.
 La cardinalité minimale d'une patte est le minimum de 1 et du nombre
minimum de pattes d'une occurrence d'individu lié à la patte. Dans le cas
de relation binaire, la cardinalité de chaque patte est égale au nombre
d'occurrences d'individu liés à l'autre patte.
 La cardinalité maximale d'une patte est la valeur maximale d'occurrences
de patte des occurrences de l'individu lié à la patte. Si elle vaut 0, la
relation n'existe jamais, le modèle doit donc être revu, la relation ne relie
pas cet individu. Si elle est supérieure à un, elle est notée N.
 Le minimum d'une cardinalité peut être différent de un, deux par exemple
(une opération comptable impute deux comptes au minimum, un crédit
et un débit) mais le conceptuel actuel, pour des questions de
simplification et de passage aux fichiers informatiques n'accepte que
zéro, un ou N.
Quatre cas de cardinalités minimale et maximale existent : 0 et 1
minimum, 1 et N maximum.
0 minimum. Ce zéro peut être un zéro dans le temps. Un colis correspond à
zéro ou une commande, mais tout colis est destiné à être commandé et
cette relation entre colis et commande ne pourra pas être modifiée. Il peut
aussi être réel. Un client peut passer de zéro à n commandes car les clients
potentiels sont suivis. Un client pourra toujours exister sans commande. En
supposant que je n'accepte qu'un locataire par appartement, un
appartement aura zéro (quand l'appartement n'est pas loué) à un locataire.
Ce locataire peut changer. Il est "modifiable".
PERSONNE 0, FILS
nom personne avoir
prénom fils
prénom personne
Une personne peut ne pas avoir de fils :

cardinalité minimale = 0
1 minimum : Une commande aura toujours un client payeur.
PERSONNE 1, FILS
nom personne avoir
prénom fils
prénom personne
Un fils a toujours un père : cardinalité minimale = 1

1 maximum. Ce un est il modifiable ou non ? S'il ne peut être modifié, la
patte reste inchangée. Le fils peut-il changer de père ?
PERSONNE ,1 FILS
nom personne avoir
prénom fils
prénom personne
Un fils a toujours un père au plus :

cardinalité maximale = 1 => La flèche est dessinée.
Voici les quatre cas résumés, nous laissons le soin au lecteur de les
découvrir.
non modifiable modifiable
0 minimum colis / commande appartement

/ locataire
locataire/
1 minimum commande / client
appartement
Il existe quatre cas de cardinalité maximale 1

N maximum : Ce nombre peut être connu. Un ordre de paiement sera
toujours visé par deux personnes. Là aussi, peut-on modifier les N ? peut-on
modifier les produits de la commande ?
PERSONNE ,N FILS
nom personne avoir
prénom fils
prénom personne
Une personne peut avoir plus d'un fils :

cardinalité maximale = N
Exemple de modèle de données avec cardinalités : les relations entre
facture et commande.
La commande comprend une à N ligne(s) de commande (cardinalités entre
commande et ligne de commande 1 et N). Une ligne de commande ne
concerne qu'une commande (cardinalités minimale et maximale à 1 de la
ligne de commande vers la commande). Chaque ligne de commande ne
concerne qu'un et un seul produit (cardinalités minimale et maximale à 1 de
la ligne de commande vers le produit).
Le raisonnement est le même entre facture, ligne de facture et produit. Les

cardinalités entre facture et ligne de facture sont 1,N sur la patte "facture"
de la relation "décomposer" et 1,1 sur la patte "ligne de facture" de la
relation "décomposer". Une ligne de facture ne concerne qu'un seul produit.
Lettrer est rapprocher une ligne de facture avec N lignes de commande.
Ainsi, seront mémorisées les lignes de commande n'ayant pas été
facturées. Une ligne de commande peut être lettrée par zéro (quand la
facture n'existe pas) ou plusieurs lignes de facture. Une ligne de facture
peut être lettrée par aucune (quand la commande n'existe pas) ou plusieurs
lignes de commande. Ce rapprochement des lignes de commande et des
lignes de facture dépend de l'utilisateur.
Le client de la commande est le même que celui de la facture. Les
cardinalités ne permettent pas d'exprimer ce fait. Nous le verrons plus tard
sous la notion d'une contrainte exprimée par un texte.
COMMANDE 1,N 1,1 LIGNE DE

CLIENT 0,N 1,1
COMMANDE 1,1
c omprendre
à fac turer quantité
commandée
c onc erner
0,N
0,N
lettrer 0,N
0,N
PRODUIT
annonc er une
bonne nouvelle FACTURE 1,N 1,1 LIGNE DE
FACTURE 1,1 0,N
déc omposer
quantité
1,1 facturée
Un modèle doit avoir toutes ses cardinalités
Si les cardinalités sont 1,1, elles décrivent un individu complètement

"dépendant" d'un autre. La commande dépend du client, la ligne de
commande dépend du produit et de la commande.
Si elles sont 1,N, le rôle de l'individu est compris par ses relations, par les
individus qu'il fréquente. La ligne de facture dépend d'une facture et est
lettrée par des lignes de commande. Le modèle de données fonctionne à
l'envers ! Le modèle reflète la réalité ! ou plus exactement le réel perçu par
l'utilisateur.
1,1
1,1
1,1
1,1
1,1
Repérer les ensembles d'individus

Les cardinalités aident à "lire" un modèle de données, à identifier les
décompositions d'un individu en individus (individus de haut en bas) et à
analyser le pourquoi de chaque niveau d'individu (individus de droite à
gauche).
Rappelons que le but des contraintes est de "coller" au plus près du
discours de l'utilisateur. Les contraintes sont des compléments sur le
modèle de données.
Les quatre contraintes suivantes, de b à e, sont explicitées par la notion

d'ensemble. Elles ont récemment été codifiées par M. TABOURIER
(Référence 3).
Sur un modèle de données, les occurrences d'un individu peuvent être vues
comme élément de sous-ensembles d'occurrences d'individu ayant une
relation particulière :
ensemble des occurrences d'individu

du même individu
sous-ensemble des occurrences

d'individu participant à une même relation
Les trois relations de cet individu caractérisent TROIS SOUS-ENSEMBLES

d'occurrences d'individu.
Exemple : soit le modèle comprenant les individus "personne", "demande
de prêt" et "prêt". Une personne peut déposer de zéro à n demandes de
prêt et rembourser de zéro à n prêts.
P ERSONNE 0,N DEMANDE

0,1
déposer DE P RET
0,N
rembourser 0,1 P RET
Les occurrences d'INDIVIDU ayant ou non des RELATIONS...

Considérons les personnes ayant déposé des demandes de prêts et celles
qui remboursent des prêts. Elles forment deux sous-ensembles des
personnes, celles qui remboursent et celles qui déposent une demande. Ces
deux sous-ensembles ont une intersection, ceux qui empruntent et qui
remboursent dont M. Croisé qui aime bien s'endetter, et une réunion ceux
qui empruntent ou qui remboursent qui ne comprend pas Mme Fourmi qui,
non seulement n'est pas prêteuse, mais en plus n'aime pas s'endetter.
ni rembourse
ni dépose
remboursent M me. Fourmi

NI REMBOURSENT
NI DEPOSENT
REMBOURSENT
PERSONNE
DEPOSENT
déposent une demande
...peuvent être regroupées en ENSEMBLES

Des contraintes peuvent être définies par rapport à ces ensembles.
b - Le ou inclusif (V) où toute occurrence de l'ensemble des individus

appartient à la réunion des ensembles d'occurrences participant aux
relations considérées : toutes les personnes déposent ou remboursent. Mme
Fourmi n'existe pas.

0,1
déposer DE PRET REMBOURSENT
0,N
V
rembourser
PRET DÉPOSENT
0,1
Toutes les personnes ont déposé une demande et/ou remboursent un prêt.
c - l'exclusion (X) où toute occurrence de l'ensemble des individus de
même type appartient à un seul des ensembles d'occurrences participant
aux relations considérées. L'intersection est vide. M. Croisé n'existe pas.
PERSONNE 0,N DEMANDE

0,1
déposer DE PRET
REMBOURSENT DÉPOSENT
0,N X
rembourser
PRET
0,1
Aucune personne ne peut déposer une demande et rembourser un prêt.

d - la partition où toute occurrence appartient à un et un seul ensemble,
est la somme de l'inclusion et de l'exclusion.
Le ou exclusif (+) est la superposition de ou inclusif (V) et de exclusion (X).
Les relations définissent une partition des individus. Pas de Fourmi, ni de
Croisé dans les deux sens. Chaque personne choisit.
PERSONNE 0,N DEMANDE

0,1
déposer DE PRET
REMBOURSENT DÉPOSENT
0,N +
rembourser
PRET
0,1
Toute personne soit dépose une demande, soit rembourse un prêt.

e - l'inclusion (I) où toute occurrence de l'ensemble des individus
participant à une relation (rembourser) participe à une autre relation
(déposer). Les personnes remboursant un emprunt doivent avoir déposé
une demande de prêt.

0,1
déposer DE PRET
DÉPOSENT
0,N REMBOURSENT
I
rembourser
PRET
0,1
Toute personne remboursant un prêt a déposé une demande

Viennent ensuite les deux derniers types de contrainte ou de compléments
du MCD, la "relation pointée" et le texte.
f - La ternaire (relation reliant trois individus) pointant sur un seul individu
Elle montre l'unicité d'occurrence de l'individu pointé.
Exemple : un document est signé par plusieurs personnes qui jouent en
signant un rôle précis. Le message secret est signé par Eudes en tant
qu'émetteur, Le Bouillon comme responsable, Nicolas comme contrôleur et
Agnan comme rédacteur. Le document est signé N fois. Mais le document ne
comporte qu'une signature d'émetteur, de responsable, de contrôleur, de
rédacteur...
Pour un couple (document, rôle), une seule personne est permise.
DOCUMENT ROLE PERSONNE
Message secret Emetteur Eudes
Message secret Responsable Le Bouillon
Message secret Contrôleur Nicolas
Message secret Rédacteur Agnan
Message secret Rédacteur Nicolas
n'est pas possible avec (Message secret, Rédacteur, Agnan) car, pour le
couple (message secret, rédacteur) deux occurrences de personne possibles
(Agnan et Nicolas) existeraient pour la relation signer.
agnan
nic olas
le bouillon
DOCUMENT 0,N
PERSONNE
signer
0,N
0,N rédac teur

c ontroleur
responsable
émetteur
ROLE
La flèche indique l'unicité de la personne pour un couple (document, rôle)

de la relation signer.
g - Le texte
La dernière contrainte permet d'expliciter ce qui ne peut pas être
représenté graphiquement. Sont dans ce cas, les contraintes sur
- les informations. Des inégalités existent sur les informations du modèle

de données suivant.
CONTRAT PRODUIT
1,N c onc erner 0,N
CADRE
quantité
plafond
0,N 0,N
se rapporter livrer produit

quantité livrée
LIVRAIS ON
1,1 1,N
Inégalités entre informations

Soit un contrat cadre fixant des prix par produits et des quantités maximum
ou plafond à respecter par produit. Chaque livraison se rapporte à un
contrat cadre de manière à pouvoir facturer et précise les quantités livrées
par produit. La contrainte est : la somme de toutes les quantités livrées
d'un produit, pour toutes les livraisons se rapportant à un contrat cadre est
inférieure à la quantité plafond de ce produit pour ce contrat cadre.
- les individus et les relations quand une relation peut ne pas être
représentée car déduite ou implicite dans le modèle.
Exemple entre facture et client après la commande : une commande est
émise sur laquelle est mentionné le client à facturer. La commande précise
les lignes de commande, c'est-à-dire les lignes concernant un produit. La
facture est émise après livraison des produits. Chaque ligne de facture,
c'est-à-dire concernant un produit, est rapprochée de chaque ligne de
commande (est lettrée). La facture est envoyée à un client. Quel client ?
Celui qui était à facturer d'après la commande : première contrainte.
Si la relation "annoncer une bonne nouvelle" est rajoutée, une autre
contrainte vient du fait que le client de la facture est le client à facturer
d'après la commande dont les lignes sont lettrées par les lignes de la
facture en question. Une autre contrainte du même style existe sur le
modèle, le produit des lignes de facture est le même que le produit des
lignes de commandes lettrées par la ligne de facture.
C OMMANDE 1,N 1,1 LIGNE DE

C LIENT 0,N 1,1
C OMMANDE 1,1
c omprendre
à fac turer quantité
commandée
c onc erner
0,N
0,N
lettrer 0,N
0,N
P RODUIT
annonc er une
bonne nouvelle FAC TURE 1,N 1,1 LIGNE DE
FAC TURE 1,1 0,N
déc omposer
quantité
1,1 facturée
les commandeurs sont les payeurs !
4.5 Quelques pièges à éviter pour construire les modèles

4.5.1 Plusieurs modèles de données sont à éliminer
Un modèle pur pourrait exister avec tous les concepts, y compris les
individus ou informations "conseils"... Ce conceptuel ne sera pas mémorisé
et la définition fine de ces concepts, dans ce cas de messages, peut être
sautée. Si le conseil a joué un rôle, le modèle en tiendra compte en
"conceptualisant" des individus moins transitoires.
PERSONNE CONSEIL
flatter
écouter
Les conseils ne sont pas mémorisés...

Exemple de demande : veut-on mémoriser les demandes de xxx pour
arriver à un accord ou ne mémorise-t-on que l'accord final ?
DEMANDE 0,N ACCORD

0,N
honorer
... toutes les demandes non plus

Un autre modèle détaillé mais trop complet est la représentation de
négociation de contrat avec n propositions et contre-propositions ou chaque
paramètre peut être en proposition ou agréé.
4.5.2 Que deviennent-ils ?
Petit ruisseau deviendra grand et toute relation peut devenir individu si
l'utilisateur lui prête existence propre. C'est le cas le plus fréquent de
transformation entre information, relation et individu. Individu ou
information peuvent aussi se transformer l'un en l'autre. Ces différents cas
sont explicités.
b
INFORMATION INDIVIDU
d
a
c
RELATION
FORMALISATION NON FORMELLE

a - Relation vers Individu b - Individu vers information
c - Individu vers relation d - Information vers individu
a - Relation vers individu.
"Cardinalités" de la relation. Une occurrence de relation est définie par
des liens reliant les occurrences d'individu pour la relation. Pour une
occurrence de relation, il y a une et une seule occurrence de patte pour
chaque patte de la relation.
Le nombre d'occurrences d'individu(s) que peut avoir chaque occurrence de
relation est toujours un au minimum et un au maximum pour chaque
"patte" de la relation vers les individus, sinon la relation ne pourrait être
définie uniquement par les individus. La quantité commandée concerne un
et un seul produit et une et une seule commande. Les cardinalités de la
relation sont 1,1 pour les n individus qui la composent.

DOCUMENT PERSONNE
signer
émetteur
ROLE
SIGNER = 1 Document, 1 personne et 1 rôle.
DOCUMENT PERSONNE
1,N 0,N
signer
1,1 1,1
1,1
cardinalités de 0,N ROLE
la relation = 1,1
SIGNER = 1 Document, 1 personne et 1 rôle.
Le cas le plus important de transformation d'une relation en individu vient

de la règle "une relation est définie par les individus". Plusieurs occurrences
d'individus ne peuvent définir qu'une occurrence d'une relation donnée. Si
elles peuvent définir plusieurs occurrences de relation, un concept doit être
individualisé.
Exemple de location de voiture : un contrat de location CL entre M.
DONNEUR et M. PRENEUR spécifie le type de voiture et les tarifs de voiture
de type A : 200 F par jour. A1, A2 et A3 sont trois voitures du type A et
louées aux mêmes conditions. M. PRENEUR loue la voiture A1 la première
semaine, la voiture A2 la deuxième semaine, et la voiture A1 (la première
louée) la troisième semaine. M. PRENEUR est tombé en panne deux fois et
la première voiture A1 a été réparée. Le modèle de données est Individus
CONTRAT (Contrat c1), VOITURE (A1,A2), TYPE DE VOITURE (A) et LOCATION.
Un contrat concerne un type de voiture et une à N locations. Une voiture est
d'un type donné et peut être louée de zéro à N fois.
3ème semaine
2ème semaine A2
cl 1ère semaine A1
CONTRAT DE LOCATION VOITURE
LOCATION
date début
date fin
1,1 1,N 1,1 1,1 0,N 1,1
concerner de
A
porter TYPE DE typer
VOITURE 0,N voiture
0,N
L'individu LOCATION vient de...

Une location est liée à un et un seul CONTRAT et une et une seule VOITURE.
Si la LOCATION était définie par la relation LOUER entre contrat et voiture, la
troisième location ne pourrait être représentée car au couple (CONTRAT cl,
VOITURE A1) correspondent, dans le cas qui nous occupe, à deux locations,
celles de la première et de la troisième semaine.
2ème semaine
1ère semaine
3ème semaine ? A2
cl A1
CONTRAT DE louer VOITURE
LOCATION 1,N date début 0,N
date fin
... la relation LOUER

Ce modèle ne doit jamais exister. Une occurrence de relation existe ou
n'existe pas. Rel (ind, ind) existe ou n'existe pas. Elle ne peut exister
plusieurs fois.
une fois !
Individualiser le concept !
Le concept est individualisé

Exemple de la commande : une commande exceptionnelle entre deux

partenaires peut être une relation binaire O,N entre le client et le produit,
1,N entre le produit et le client.
Supposons que l'activité de mon entreprise ne consiste qu'à vendre des
produits exceptionnels : Tour Eiffel, Beaubourg, Arc de triomphe, Arche de
Noë. Il m'arrive, exceptionnellement, de vendre deux fois le même produit,
un arc de triomphe, par exemple, mais jamais au même client.. Dans ce cas,
une occurrence de relation ne reliera jamais une même occurrence de client
et une même occurrence de produit. Ma relation binaire est exacte. "Passer
commande" est une relation. Commande n'est pas un individu (dans ce cas
tordu).
Arche de Noë
Noë
Arc de
Etat Fantoche Triomphe
Etat Français Beaubourg
Ville de Paris Tour Eiffel
C LIENT PRODUIT
passer
commande
0,N 1,N
Le CLIENT "passe commande" (relation) d'un PRODUIT

Ceci montre que "commande" ou "location" n'est pas toujours un individu.
Tout dépend de l'utilisateur et de son activité.
Relation 1,1 - 1,N ou pattes multiples.
Une même occurrence de relation pouvant concerner plusieurs occurrences
du même individu entraîne la création d'un individu. C'est un cas d'un
individu créé à partir de relation ne respectant pas les règles.
Exemple : un document peut être signé par la même personne au titre de
plusieurs rôles. M. LION signe en temps que chef, contrôleur, juge et partie.
La patte (de Lion) allant de la relation "signer" vers l'individu "rôle" est
multiple.
Signer intervient ici une fois pour toutes les signatures d'une personne pour
un document.
La vue utilisateur est :
Document : Décret royal Personne : Lion
Rôles : Juge, Partie.
Déc ret royal lion

DOCUMENT
0,N PERSONNE
signer
0,N
partie
0,N juge
ROLE
Une occurrence de relation multi-occurrences de pattes vers une occurrence

d'individu n'existe pas
La relation signer devient individu SIGNATURE d'un document. La relation

"apposer" entre les individus "signature" et "document" possède 1,1 et 0,N
comme cardinalités.
renard
Déc ret royal
lion
DOC UMENT SIGNATURE imiter
1,1 P ERSONNE
0,N 0,N
apposer
0,N par
1,1 0,N
1,N
partie
juge
valoir
0,N ROLE
Signature est un individu

Si la vue utilisateur est :
Document : Décret royal Personne : Lion Rôle : Juge
Document : Décret royal Personne : Lion Rôle : Partie
Signer intervient ici une fois pour chaque signature d'une personne pour un
document et pour un rôle donné.
Le modèle suivant est correct :
Déc ret royal lion

DOC UMENT P ERSONNE
0,N
signer
0,N
partie
juge
0,N ROLE
Tout est dans la perception de l'utilisateur !
Relation à pattes optionnelles.

C'est le cas où la "cardinalité" de la relation est 0,1 au lieu de 1,1 vers un
individu. Une occurrence de patte est facultative pour une occurrence de
relation, un "brin" de l'occurrence de relation peut ne pas exister. Alors, la
relation devient individu car toutes les pattes d'une relation sont
obligatoires.
Exemple : une commande concerne des produits. "Commande" et "Produit"
sont représentés sous forme d'individus. "Concerner" est représenté par une
relation et contient la quantité commandée. Après livraison, la facture est
émise et "reprend" les produits à facturer. "Reprendre" est représenté par
une relation. Si le lien de cause à effet entre la ligne de commande (relation
"concerner") et la facture (individu "facture") ou la ligne de facture (relation
"reprendre") veut être géré, alors, comme toute ligne de commande ne
donnera pas lieu à facture, cette patte entre la relation "concerner" et
l'individu "facture" est "optionnelle", elle n'existe qu'après émission de la
facture. Pour toutes les commandes n'ayant pas donné lieu à facturation,
l'occurrence de patte n'existe pas, elle est "optionnelle". Le modèle doit être
corrigé.
Il ne doit pas exister d'équivoque, pas d'option possible, la patte existe ou

n'existe pas. Un individu doit être créé pour sortir de cette irrégularité.
COMMANDE PRODUIT
1,N 1,1 concerner 1,1 0,N
qté commandée
0,1 0,N
Patte optionnelle 'lettrer'

reprendre
0,N
qté facturée
FACTURE 1,N prix unitaire
La "patte optionnelle" ne doit pas exister.

Dans l'exemple la relation "concerner" devient l'individu "ligne de
commande"... et la "patte optionnelle" lettrer, la relation 0,1 1,N "lettrer".
COMMANDE 1,N LIGNE DE 1,1 0,N PRODUIT

1,1 COMMANDE
comprendre concerner
quantité
commandée
0,N lettrer 0,1 reprendre 0,N
FACTURE
quantité
facturée
prix unitaire
1,N
L'individu créé Ligne de commande a, pour chaque occurrence, la

possibilité d'avoir un lettrage ou de ne pas en avoir. Un individu peut avoir
une patte optionnelle.
Individus "forcés" :
Plus le modèle avance, plus la différence entre individu et relation
s'estompe. Différents individus apparaissent par nécessité, qui proviennent
de relations, n'ont pas d'existence propre mais doivent exister du fait des
règles.
Exemple de barreaux d'échelle de contrat (remises en fonction de quantités
commandées). Soit un contrat (échelle) dans lequel les conditions sont :
si 10 articles sont commandés, remise de 10%
si 100 articles sont commandés, remise de 20%
si 1 000 articles sont commandés, remise de 30%
1000
30
100
20
Barreau 10
10
Barreau
1000
nombre articles
commandés
100 remise accordée
1,1
10
0,N contrat
Contra t Echelle Echelle
Les barreaux d'échelles sont des individus

Ce contrat peut être représenté par les individus Contrat ou Echelle et
Barreau. Les informations de l'individu Barreau sont nombre d'articles
commandés et remise accordée.
Pour un type de contrat avec remise, le nombre de barreaux est variable.
Nous nous retrouvons dans la position du père et de ses N fils. Les
informations "nombre d'articles commandés" et "remise accordée" ne
peuvent être dans l'individu Echelle ou Contrat. Les barreaux doivent être
des individus bien qu'ils n'aient pas d'existence propre. Qu'est-ce qu'un
barreau sans échelle ?
Une relation devient donc individu dans les deux cas précédents, les cas de
pattes multiples ou de patte optionnelle. Le cas de pattes multiples est un
cas particulier des occurrences de relation reliant plusieurs fois les mêmes
occurrences d'individu (exemple de location de voiture). La relation est dite
"réifiée" car devenue chose, individu.
Plusieurs relations entre deux ou trois individus peuvent cacher un
concept qu'il peut être utile de transformer en individu.
Exemple : autorisation. Un projet est visé par une personne qui a un rôle
de superviseur. Un document (ordre de paiement par exemple) est signé
par une personne en qualité (ou rôle) de fondé de pouvoir. Ces rôles sont
gérés et informatisés à fin de contrôle du visa ou de la signature.
DOC UMENT 0,1 PERSONNE

0,N
signer
0,N
0,N
viser 0,1
ROLE PROJET
0,N
SIGNER ET VISER...
Le concept sous-jacent de ces personnes et de ces rôles est celui
d'autorisation. Une autorisation est donnée à une personne pour un rôle
donné. J'autorise M. Machin à signer des chèques.
0,1 0,N AUTORISATION 1,1 0,N PERSONNE

DOCUMENT
signer donner
1,1 0,N
ROLE 0,N PROJET
jouer viser
0,1
= EXERCER UNE AUTORISATION

Ce cas montre une relation devenue individu par apparition d'un concept.
Je veux gérer l'autorisation comme telle et son identifiant est un identifiant
tout neuf, tel que un mot de passe utilisateur.
Retenir les individus provenant de relations, ces relations "réifiées",
servira au modèle physique.
b - Individu vers information.
Un individu (individu "type de..." sans information dans l'individu) peut

devenir information : import/export, échéance optionnelle/non optionnelle,
obligatoire/facultatif.
Cela n'est possible que si les cardinalités sont 1 minimum et 1 maximum
vers l'individu "Type de" et que l'individu "Type de" n'est relié qu'à l'individu
"occurrence de...".
Un contrat de travail peut être de deux types : à durée indéterminée ou à
durée déterminée. La représentation initiale est faite de 2 individus ;
Contrat et Type de durée. Les occurrences de type de durée sont au nombre
de deux, déterminée et indéterminée. L'information de cet "individu" type
de durée est uniquement type de durée. Cet individu n'est relié à aucun
autre individu par une relation..
déterminée
indéterminée
CONTRAT TYPE DE
1,1 0,N
DUREE
L'individu type de durée...

Il n'existe pas de concept derrière cet individu. Cet individu est une
information "cachée" du contrat type-durée-contrat.
CONTRAT
type durée contrat
... est une information de chaque contrat.
c - Individu vers relation.

Un individu a de fortes chances de devenir relation si toutes ses
cardinalités sont 1,1.
Exemple : le lettrage ne lettre qu'une ligne de commande à une ligne de
facture (la ligne de facture ne sera lettrée qu'une seule fois). Le modèle
initial comprend l'individu LETTRAGE relié aux individus LIGNE DE
COMMANDE et LIGNE DE FACTURE et qui a toutes ses cardinalités égales à
1.
LIGNE DE 0,1 1,1 LETTRAGE 1,1 0,1 LIGNE DE

FACTURE lettrer lettrer
COMMANDE
facture commande
L'individu LETTRAGE...
Dans ce cas, il n'existera jamais deux lettrages reliant deux fois la même
ligne de commande et la même ligne de facture. Comme le lettrage n'existe
que par les lignes de commande et de facture, cet individu peut être
transformé en relation.
LIGNE DE 0,1 0,1 LIGNE DE

FACTURE LETTRER COMMANDE
... est la relation LETTRER.

Il faut se "méfier" des individus aux cardinalités 1,1. La question est
"deux occurrences de cet individu original peuvent-elles concerner plusieurs
fois les mêmes occurrences des autres individus ?" (Vous pouvez relire).
Cela nécessite un individu.

Si la réponse est oui, l'individu existe, il ne peut être identifié par d'autres
individus. Si la réponse est non, une fois, l'individu est une relation.
une fois !
Individualiser le concept !
Premier exemple de règle à respecter, l'individu patte décrit sur le
modèle de la méthode .
Une patte relie un individu et une relation. En représentant ces concepts
de la méthode sur un modèle de données de la méthode, encore appelé
méta-modèle, les cardinalités du méta-individu "patte" vers le méta-
individu "relation" et le méta-individu "individu" sont 1 minimum et 1
maximum.
Soit le modèle de données suivant. Une personne lit ou comprend un
chapitre d'un livre. Une personne est fils de... ou père de. Père de et fils de
sont des pattes de la relation engendrer. La représentation sous forme de
modèle de données est :
engendrer fils de ...

père de ...
PERSONNE 0,n CHAPITRE
0,n
comprendre
0,n 0,n
lire
Si ce modèle de données est représenté sous la forme d'un modèle de

données (de la méthode MERISE) ou méta-modèle : les individus sont
"personne" et "chapitre", les relations sont "comprendre", "lire" et

"engendrer", les pattes sont "fils de" et "père de".
lire
personne père de ... comprendre
chapitre fils de ... engendrer
INDIVIDU PATTE RELATION
0,N 1,1 1,1 0,N
PATTE est un META-INDIVIDU dont

toutes les cardinalités sont à UN.
Les occurrences de patte, "père de" et "fils de" sont reliées à la même
occurrence d'individu, personne et à la même occurrence de relation,
engendrer. Il est nécessaire de traiter patte comme individu et non comme
relation, comme concept et non comme relation entre concept.
Le méta-individu "patte" pourrait aussi être conçu comme "patte de
nomenclature". La méta-relation entre les méta-individus "individu" et
"relation" existe ou n'existe pas en fonction du choix de ces concepts.
Deuxième exemple d'individu aux cardinalités minimale et maximale à 1,
l'individu "location de voiture". Si deux occurrences de l'individu LOCATION
ne concernent jamais le même contrat et la même voiture l'individu
LOCATION est relation.
CONTRAT DE LOCATION VOITURE

LOCATION 0,N 1,1
date début 1,1 0,N
c onc erner date fin de
Troisième exemple : décision de gestion d'un individu, l'individu règle. Le

modèle est correct avec une relation ternaire, mais l'utilisateur décide de
gérer un concept. Alors, l'individu existe.
Je veux gérer les règles de passage d'une situation à une autre en
fonction d'événements. Ces règles me serviront à générer les situations. Si
la situation actuelle est "radieuse" et que l'événement est "Le chat se
gratte l'oreille", la situation suivante est "pluvieuse". Les règles sont gérées.
Celle que je viens d'énoncer est une règle d'expert félin, la règle de "la
patte du chat" (Référence 7). Une autre règle, "pessimiste" est : si la
situation actuelle est "heureuse" et l'événement est une "catastrophe", la
situation suivante est "malheureuse".
A une règle correspondent une et une seule situation précédente, une et
une seule situation suivante, un et un seul événement. Les cardinalités
minimale et maximale de l'individu règle sont égales à 1 pour toutes les
pattes.
Si la situation est appelée "fait" et nous obtenons un modèle de système
expert pour qui tout est "fait" ou "règle" ou les deux.
le chat se
gratte l'oreille
0,n catastrophe
EVENEMENT
tenir
compte
pluvieuse
radieuse
la patte du chat malheureuse
1,1 pessimiste heureuse
REGLE préceder SITUATION
1,1 0,n
suivre
1,1 0,n
Je décide de gérer l'individu règle bien que toutes ses cardinalités soient
égales à 1
Les relations avec des cardinalités 1,1 et 0,1 sur chaque patte prouvent
qu'un intense travail de reflexion a été mené. C'est un exemple de deux
individus qui, quand ils existent, n'en choisissent qu'un autre. Ces deux
individus ne sont différents que par une caractéristique ou une information
particulière.
Exemple du moteur : un modèle tel que véhicule et moteur prouve que
l'on veut gérer des véhicules avec moteur et des véhicules sans moteur.
MOTEUR 1,1 0,1 VEHIC ULE

motoriser
Un moteur existe-t-il sans véhicule ?
d - Information vers individu.

C'est le cas le plus courant qui apparaît au début du modèle. Si une
information n'est portée que par un seul individu, la formalisation est
correcte. Si elle se retrouve dans un deuxième individu, alors un individu
doit être géré. Une information doit appartenir à un seul individu ou une
seule relation. Sinon, il existe un risque de confusion. Quelle est
l'information de référence ? Laquelle doit être mise à jour ? De quel concept
dépend-elle ?
Exemple : nom du pays est information de l'individu ville. Si le nom du pays
apparaît dans un autre individu (devise par exemple), alors l'individu pays
existe. Le cas où un numéro de pays existe prouve que le concept de pays
doit être géré.
VILLE DEVISE
nom ville code devise
nom pays nom pays
L'information "nom pays" est dans deux individus

VILLE PAYS DEVISE

se situer avoir
nom ville dans cours code devise
nom pays
1,1 0,N 1,N 1,1
L'individu pays existe

Nous retrouverons ce point lors de la normalisation des informations au
modèle physique des données.
4.6 Modèles équivalents

Plusieurs modèles expriment plus ou moins les mêmes concepts. Des
modèles équivalents, des vues externes, peuvent être présentés ou servir à
construire le modèle principal.
Parmi ces modèles, qui sont des variantes d'un modèle, un seul doit être
retenu comme référence. Ce choix, qui appartient à l'utilisateur, est délicat
si les modèles sont des expressions "repliées ou dépliées" de concepts. Des
modèles repliés où les individus deviennent des occurrences d'individu
permettent de créer de nouvelles occurrences, mais peuvent engendrer de
nouveaux contrôles. Ne replier que les individus qui se ressemblent.
4.6.1 Vue externe
Le concept de vue externe est important. Une "vue externe" ou un modèle
externe est une vue partisane et partielle d'utilisateur du modèle de
données complet. Cette vue peut être intégrée dans une vue plus large.
Dans la pratique, elle est souvent représentée sous la forme d'un
diagramme d'occurrences, c'est-à-dire d'un dessin d'un modèle de données
avec les occurrences d'individus, de relation et d'information. Un modèle
avec occurrences est plus compréhensible qu'un modèle sans.
Exemple : la vue externe VOITURE et PERSONNE :
voisin dernière sortie

PERSONNE VOITURE
appartenir
0,N 0,1
La voiture d'une personne (vue externe)...

est intégrée dans le modèle VEHICULE, MOTEUR, PROPRIETAIRE, PERSONNE,
SOCIETE.
être personne
propriétaire
0,1
PERSONNE 0,N PROPRIETAIRE
0,1
c apitaliser
soc ialiser
0,N
0,N
appartenir
SOCIETE
Voiture
0,1
MOTEUR 1,1 0,1
VEHICULE
motoriser
...est un VEHICULE à MOTEUR dont le PROPRIETAIRE est une PERSONNE

(vue complète)
4.6.2 MCD avec individus repliés ou dépliés ?

Des individus peuvent être de plusieurs types. Le propriétaire peut être du
type personne ou du type société. Les modèles de données peuvent
représenter les individus "type de" ou non. Un modèle de données avec
beaucoup de "type de" est un modèle avec des individus repliés ou méta.
Un modèle sans "type de", où chaque individu est géré, est déplié.
A1 A2 A3
MODELE DEPLIE
A3
A2
A1
TYPE DE A A
1,N
typer
0,N 1,1
MODELE REPLIE
Les individus deviennent des occurrences.
Dans un modèle "replié", les individus (A1, A2, A3) deviennent des
occurrences d'individu (type de A).
Un modèle replié est plus "souple" au niveau des données. Je pourrais créer
un autre type de A, A4 par exemple. Par contre, les contraintes sont plus
nombreuses. Les contrôles à effectuer sur chaque traitement seront plus
nombreux.
L'exemple suivant montre plusieurs possibilités de représentations. Toutes
ces représentations sont valables. Bien comprendre la signification des
modèles dessinés et s'arrêter là où l'utilisateur ou le concepteur ne suit plus
!
Une société peut avoir plusieurs fonctions, être d'un ou de plusieurs types
de société. Les trois représentations suivantes sont possibles :
- Une SOCIETE est d'un ou plusieurs TYPE(S) DE SOCIETE (fournisseur,
client, banque...) plus connue sous la dénomination tiers, type de tiers ou
acteur et type d'acteur... Lors de la saisie de l'individu société, il faudra
contrôler qu'un compte bancaire ne peut être ouvert que dans une banque.
COMPTE E.D.F fournis s eur
BANCAIRE 1,1 R.A.T.P client

Banque De France banque
ouvrir
SOCIETE TYPE DE
0,N SOCIETE
- nom s ociété
- adres s e du 0,N
s iège s ocial
être d'un
1,N type de
COMMANDE 1,1 0,N 0,N société
CLIENT FACTURE
payer
FOURNISSEUR
à payer 1,1
1 - Modèle replié : SOCIETE et TYPE DE...
- FOURNISSEUR, CLIENT, BANQUE sans lien entre les individus.
Fournisseur 3
R.A.T.P
Fournisseur 2
E.D.F
Banque 1 Client 1 Fournisseur 1
Banque De Franc e Banque De Franc e Banque De Franc e
BANQUE CLIENT FOURNISSEUR
- nom banque
- nom c lient - nom fournisseur
- adresse du
- adresse du - adresse du
siège soc ial
siège soc ial c lient siège soc ial fourn
banque
0,N 0,N
0,N
ouvrir payer à payer
1,1 1,1 1,1
COMPTE COMMANDE FACTURE

BANCAIRE CLIENT FOURNISSEUR
2 - Modèle déplié : pas d'individu SOCIETE, ni TYPE DE....

- SOCIETE, FOURNISSEUR, CLIENT, BANQUE. Une société est fournisseur,
client... Les informations siège social, âge du PDG sont dans l'individu
SOCIETE. Les informations encours fournisseur, encours autorisé, sont dans
l'individu fournisseur. Autour de la société, les cardinalités sont 0,1 pour
toutes les relations avec des individus.
R.A.T.P
E.D.F
Banque De Franc e
SOCIETE
0,1
nom soc iété
adresse du siège soc ial
0,1 0,1
fournisseur 3
1,1
fournisseur 2
banque 1 1,1 c lient 1
1,1 fournisseur
banque 1 e
de franc
BANQUE CLIENT FOURNISSEUR
déc ouvert ac c ordé niveau risque enc ours ac c ordé
0,N 0,N 0,N

ouvrir payer à payer
1,1 1,1 1,1
COMPTE COMMANDE FACTURE

BANCAIRE CLIENT FOURNISSEUR
3 - Modèle mixte.
L'individu TYPE DE société disparaît et est éclaté.
Toutes ces vues sont équivalentes, comme les informations adresse du
siège social fournisseur, adresse du siège social client, adresse du siège
social banque. Ne retenir que celle comprise par l'utilisateur et expliciter le
modèle par un long texte explicatif. Un modèle replié ou méta est plus
souple pour définir les données. Dans la troisième vue, types et "sous-
types" sont représentés.
4.6.3 Le summum du repli, le modèle "Valeur" et "caractéristiques".
Un modèle replié, c'est-à-dire comprenant des individus repliés en un seul
individu classé en "type de", peut, du fait des règles sur les informations,
telle que une information doit avoir un sens pour toutes les occurrences de
l'individu, ne pas exprimer clairement les concepts. Une représentation
particulière permet de contourner cet obstacle, c'est la représentation par
valeur et caractéristique. Il suffit d'introduire un individu "caractéristique" et
une relation portant l'information "valeur". Un contrat a des caractéristiques
variant suivant le type de contrat. Une société a des caractéristiques
variant suivant le type de société. Un véhicule a des caractéristiques qui
varient suivant le type de... véhicule.
Exemple : une trésorerie multi-devises emprunte et prend des options à
terme. Elle gère donc plusieurs types de contrat.
Change
Prêt n° 1 Option
10% Prêt
PRET 0,N TYPE DE CONTRAT
numéro prêt type contrat
taux d'intérêt 1,1
Option n°1 0,N 0,N Change n°1

1000 3,5
type contrat
OPTION type contrat CHANGE
numéro d'option numéro de change
montant du droit d'achat 1,1 1,1 taux de change
Prêts, options et contrats de change sont des types de contrats.

Le montant du droit d'achat de l'option (j'achète l'option d'acheter un

contrat à un montant donné) est une information caractéristique de
l'individu "option". De même, taux d'intérêt et taux de change (j'achète des
Marks contre des Francs à un taux de...) sont des informations
caractéristique des individus "prêt" et "change".
Pour le prêt numéro 1, le taux d'intérêt est de 10 %. Pour l'option numéro
1, le montant du droit d'achat est de 1 000 Francs et pour le contrat de
change numéro 1, le taux de change est de 3,50 Francs/Deutsche Mark.
Représentation par "valeur caractéristique et autorise"
Contrat 3 Change
Contrat 2 Option
Contrat 1 Prêt
C ONTRAT TY PE DE C ONTRAT
0,N
type contrat
1,1
1,N
taux de c hange 1,N

posséder
valeur montant du droit d'ac hat
taux d'intérêt
autoriser
C ARAC TERISTIQUE DU C ONTRAT
0,N
0,N
Modèle Replié au maximum

Un TYPE DE CONTRAT autorise des CARACTERISTIQUES. Un CONTRAT d'un
TYPE DE CONTRAT donné possède (relation entre contrat et caractéristique)
des valeurs (information de la relation) de la CARACTERISTIQUE autorisée
pour le type de contrat.
Le type de contrat "prêt" autorise certaines caractéristiques dont le taux
d'intérêt. Le type de contrat "option" autorise certaines caractéristiques
dont le montant du droit d'achat. Le type de contrat "change" autorise
certaines caractéristiques dont le taux de change.
Contrat 3
Contrat 2
Contrat 1
CONTRAT 3,5
taux de c hange
1000
montant du droit d'ac hat
1,N
10
taux d'intérêt
posséder CARAC TERISTIQUE DU C ONTRAT

valeur
0,N
Occurrences de valeur
Le Prêt numéro 1 devient le contrat numéro 1, l'option numéro 1 devient le
numéro 2, le contrat de change numéro 1 devient le numéro 3. Le contrat
numéro 1 est du type prêt, le numéro deux du type option et le numéro
trois du type change.
L'information "taux d'intérêt" n'est plus une information de l'individu prêt,
mais de la relation "posséder".
10, le taux d'intérêt du contrat numéro 1 est une occurrence d'information

de l'occurrence de la relation posséder entre contrat numéro 1 et la
caractéristique taux d'intérêt.
1000, le montant du droit d'achat du contrat numéro 2 est une occurrence
d'information de l'occurrence de la relation "posséder" entre contrat
numéro 2 et la caractéristique montant du droit d'achat.
3,5 , le taux de change du contrat numéro 3 est une occurrence
d'information de l'occurrence de la relation posséder entre contrat numéro 3
et la caractéristique taux de change.
Application au modèle sur les sociétés banque, client, fournisseur.
Un TYPE DE SOCIETE autorise des CARACTERISTIQUES. Une SOCIETE d'un
TYPE DE SOCIETE donné possède (relation entre société et caractéristique)
des valeurs (information de la relation) de la CARACTERISTIQUE autorisée
pour le type de société.
Fournisseur
COMPTE
Client
BANCAIRE
Banque
SOCIETE 0,N TYPE DE
type société
0,N - nom soc iété
SOCIETE
1,1 1,N 0,N
ouvrir - adresse du
siège soc ial
0,N
0,N 0,N autoriser
posséder encours
payer à payer 0,N niveau de risque
valeur
1,1 découvert
1,1
COMMANDE FACTURE CARACTERISTIQUE

CLIENT FOURNISSEUR 0,N
Cette représentation est séduisante. La relation "autoriser" permet les

contrôles sur les informations possibles d'une société et de rajouter
n'importe quelle caractéristique à une société. Quand la formalisation
conduit à ce type de représentation, veillez à noter tous les paramètres et
les types de possibles. Notez la fréquence d'apparition de ces "types de".
Par exemple, 80 pour cent des contrats sont du type Prêt. Cette fréquence
d'apparition sert à construire le modèle physique de données.
La construction d'un modèle de données n'est pas unique. De nombreux
choix doivent être effectués entre :
- individus et relation. Dans ce cas, le respect des règles est le point
principal.
- modèle replié ou non. Dans ce cas, coller et sentir les concepts. Un
concept "en béton" peut être représenté comme individu. S'il est changeant
et doit le rester, comme des conditions de contrat, préférer une vue "méta".
Le lecteur lira avec intérêt la construction d'un modèle complètement
replié (Référence 2 p 233).
4.6.4. La date.
A un moment ou à un autre d'un projet se pose la question de la date. La
date est-elle une information, une relation ou un individu ? En un mot, la
date est-elle un concept, la date est-elle gérée ? La date d'échéance est-elle
différente de la date de valeur ?
En pratique, représentez la date par des informations situées le plus
souvent dans des individus d'historiques.
Exemple de modèle de date : trésorerie. Les mouvements prévus de longue

date en trésorerie sont les mouvements concernant de grosses sommes à
des dates d'échéances assez éloignées. Quand l'éloigné devient proche, le
mouvement prévu devient un mouvement rapproché et même un ordre de
mouvement (ordre de paiement ou avis d'encaissement) pour une date
d'échéance. Quand la banque a effectué l'ordre, les mouvements
concernant le compte bancaire sont transmis à la société ornés de deux
dates, une date de valeur sur laquelle seront calculés les agios (en cas de
découvert) et les intérêts (dans des cas exceptionnels) et une date du
mouvement qui sert à calculer les soldes comptables.
En première approche, trois concepts de date existent, donc trois individus
"date d'échéance", "date de mouvement" et "date de valeur".
DATE DE
MOUVEMENT 0,N
1,1 MOUVEMENT date mouvement
PREVU DATE DE VALEUR
date éc héanc e
0,N
mvt prévu
0,N
date valeur
0,N 0,N 0,N mouvement
DATE
solde solde
D'ECHEANCE devenir 1,1 1,1
c omptable valeur
0,N 0,N
0,N
0,N 0,1 MOUVEMENT
ORDRE DE 0,1 C OMPTE
0,N c réditer c réditer BANCAIRE
1,1 MOUVEMENT 0,N BANCAIRE
date éc héanc e 0,N
ordre mouvement 0,1 0,N 0,1
débiter débiter
QUE DE DATES !
Ce modèle peut devenir, en ne considérant qu'un seul individu date :
MOUVEMENT 1,1 0,N

date éc héanc e DATE
PREVU 0,N
mvt prévu
date mouvement
0,N
0,N 0,N 0,N date valeur
date éc héanc e solde solde mouvement
devenir ordre mouvement 1,1 1,1
valeur c omptable
0,N 1,1 0,N
0,N
MOUVEMENT
ORDRE DE 0,1 0,N 0,N 0,1
COMPTE BANCAIRE
MOUVEMENT créditer c réditer
BANCAIRE
0,N
0,1 0,N 0,1
débiter débiter
UNE DATE !
Les soldes (solde du compte à une date donnée) contenus dans les
relations entre compte bancaire et date sont des informations résultat de
calcul : la somme de tous les mouvements concernant un même compte
bancaire depuis sa création. Un tel modèle n'est pas très conceptuel, car il y
existe des redondances !
La dernière représentation fait abstraction des individus "dates" en les
transformant en information d'individus : date d'échéance de l'individu
"mouvement prévu", date d'échéance de l'individu "ordre de mouvement",
date de valeur et de mouvement de l'individu "mouvement bancaire"
(relevé). Seuls restent comme individus, la ou les relations dont les
cardinalités vers l'individu date n'étaient pas à 1 maximum. Ces individus
restants sont souvent des Historiques, c'est-à-dire des mémorisations
d'événements à des dates données.
MOUVEMENT
SOLDE BANC AIRE
PREVU
solde c omptable
date éc héanc e
solde valeur
mvt prévu
date du solde
0,N
1,1
devenir
0,N 0,N
MOUVEMENT
ORDRE DE 0,1 0,N 0,N 0,1
C OMPTE BANC AIRE
MOUVEMENT c réditer c réditer
BANC AIRE date mouvement
date éc héanc e 0,1 0,N 0,N 0,1 date valeur
ordre mouvement débiter débiter mouvement
Plus de date, mais des historiques !

Période : catalogues ou tarifs.
Beaucoup d'individus PERIODE sont "cachés" derrière des individus tels que
catalogue ou tarif. Les informations de ces individus sont date de début de
période ou date de fin de période. Les concepts sont bien catalogues, tarifs,
inventaires...
2000
20
printemps 75 aciérie
été 68 imperméable
CATALOGUE PRODUIT
tarifer
prix catalogue 0,N
0,N en Zloties
Les catalogues sont des périodes
4.6.5 Les structures sont des têtes de lien.

Un modèle de données peut assez vite prendre l'allure de "drap de lit" s'il
est construit purement et non simplement à partir des données. Dans ce
cas, deux questions sont importantes : pourquoi gérer ces individus et, si le
modèle est celui d'une structure, quelles sont les occurrences de cette
structure ? Ce paragraphe est assez compliqué et il peut être sauté en
première lecture.
Soit le modèle de données suivant : un client a une adresse. Cette adresse
est dans une commune, dans une ville, un département, un pays... Le client
possède aussi une devise de référence. Cette devise a cours dans des pays.
Le modèle pourrait être :
CLIENT
0,1 0,N COMMUNE 0,1 0,N
VILLE
regrouper regrouper
0,1 0,1
posséder regrouper
0,N 0,N
DEVISE PAYS DEPARTEMENT
0,N 0,N 0,N 0,1
avoir
regrouper
cours
Voici le modèle initial des clients

La première question est :
- pourquoi gérer ces individus ("adresse", "commune", etc.) ?

Si l'objectif est de calculer des résultats par groupe de clients regroupés par
lieu géographique ou par devise, la représentation peut être un modèle de
structure ou de pyramide de client gérant des concepts de "structure" et
"d'éléments de structure". Une structure mémorisera un découpage
géographique, une autre structure un découpage par devise ou financier.
Dans l'exemple ci-dessus, la structure géographique est Client -> Commune
-> Ville-> Département -> Pays et la structure financière est Client ->
Devise
La relation entre devise et pays ne pouvait servir qu'à un contrôle.
Cette représentation est plus proche du discours de l'utilisateur (groupe de
client) et plus souple. La création d'une nouvelle structure (chiffre d'affaire,
publique ou privée...) ne posera aucun problème, car le concept "Groupe de
client" est correctement identifié.
En revanche, le modèle serait différent et ne peut être représenté sous
forme de structure si l'objectif est de minimiser les coûts de routage
(acheminement du courrier). Le modèle doit servir à regrouper des courriers
de clients par zone - de routage-. Le concept de zone de routage devrait
être clairement identifié afin de mentionner les tarifs par zone. Dans ce cas
les concepts sont, par exemple : Client, Zone de routage, Tarif de routage
pour une application de routage et Devise, Taux de change, Place
financière, Instrument financier pour une application financière.
Le modèle de données est au service des traitements.
Représentation de la structure : une structure est composée d'éléments
de structure appelés aussi critères d'analyse ou nœuds et de liens. Soit la
structure suivante :
Tout Client
L4
Grands comptes L3
L1 L2
Client Richard Client Crésus Client Lambda
Les nœuds sont : "tout client" et "grands comptes" et les trois clients de
base ou les feuilles de l'arborescence sont "Richard", "Crésus" et
""Lambda". Les liens sont L1, L2, L3 et L4.
Dans le cas cité plus haut, de structure géographique, les nœuds peuvent
être "La part Dieu" pour une occurrence de commune, "Lyon" pour une
occurrence de ville et "France" pour une occurrence de pays.
La première formalisation d'une structure est la suivante : un nœud
regroupe des clients. Deux relations de nomenclatures géographique et
financière existent. L'information "Type de nœud" ou "niveau de structure"
dont les occurrences sont : tout client, grand compte, commune, ville,
département, pays... est une information de l'individu "nœud".
Lambda
Crésus Tout client
Richard Grand compte
CLIENT NŒUD nomenclature
0,N financière
regrouper type de nœud
avoir comme aval
0,1 avoir comme amont 0,N
0,1 nomenclature
géographique
Les deux relations de nomenclatures...

La deuxième représentation de structures, celle recommandée, prend en
compte N structures et mémorise leurs modifications.
Si le client Lambda absorbe une entreprise, il deviendra "grand compte".
Alors, le lien L3 de "Lambda" à "tout client" sera modifié. Le nœud "Grand
compte" reste le même. Seuls sa nomenclature ou ses liens sont modifiés.
CLIENT NŒUD
type de nœud
0,N 0,N
0,N
regrouper
0,1 avoir comme aval
LIEN
LIEN
0,1
date début lien avoir comme amont
date fin lien 1,1
... deviennent l'individu LIEN

L'individu "structure" existe si plusieurs structures sont mémorisées :
structure géographique et structure financière. Une structure peut aussi
être considérée comme un nœud n'ayant pas de lien par l'amont. Dans ce
cas, l'individu "structure" est superflu.
Par contre, si des contrôles doivent être effectués : vérifier que le type de
nœud "commune" se trouve bien dans une structure géographique, qu'une
ville est en amont d'une commune, alors les concepts de structure et de
niveau doivent être individualisés.
NIVEAU STRUCTURE
LIEN
1,1 0,N
appartenir
0,N 0,N
être
1,1 1,1
ou 1,1 ou 1,N
NŒUD 0,N 1,N LIEN
LIEN
avoir comme aval
date début lien
avoir comme amont date fin lien
1,1
0,N
Voici le modèle final
Cette représentation prend en compte tout changement de structure. Elle

est commune au découpage géographique de la Suisse, de l'Allemagne et à
tout changement de régime territorial. En résumé, cette représentation est
conceptuelle. Une dernière touche est de considérer tous les clients comme
des nœuds de structure. Un client peut être un groupe à lui tout seul.
La deuxième question est :
- quelles seront les occurrences de ces structures ?
Souvent, la difficulté tient à la mise en place de cette structure. Une
structure unique de clientèle est préférable au sein d'une entreprise. La
structure de clientèle servant à attribuer des conditions commerciales
devrait être la même quelle que soit le service de l'entreprise octroyant les
conditions. Cette même structure de clientèle peut servir au calcul des
résultats par client de la société.
La limite du modèle de données vient du fait qu'il ne prend pas en compte
les occurrences des individus et des relations. Il est conseillé de prendre un
exemple, lors de l'étude, en représentant les occurrences par des
diagrammes tels que :
Europe
France Suisse
Lyon Lausanne
La part Dieu Ouchy
Client Soyeux Client Canut Client Bolomey
Ils serviront à obtenir un consensus sur la structure de clientèle et à

initialiser le jeu d'essai à prendre en compte lors des tests de
programmation.
4.7 Résumé du MCD.

Merise est en premier lieu, l'art de dessiner un modèle de données
- en respectant les règles, en créant ou supprimant des individus, des
relations et des informations et
- en choisissant de représenter un concept à son plus juste niveau (modèles

méta).
Un individu est un concept ensemble d'informations. Une occurrence
d'individu est un ensemble d'occurrence d'informations.
Une relation est un lien entre individus pouvant être ensemble
d'informations. Une occurrence de relation lie plusieurs occurrences
d'individus et peut être un ensemble d'occurrence d'information(s).
La règle à retenir sur les individus est :
Les occurrences d'individu doivent pouvoir être citées.
Les règles sur les informations sont :
Une information est dans un seul individu ou une seule relation.
Une information d'individu a une et une seule valeur pour chaque
occurrence de l'individu concerné.
Une information de relation a un et un seul sens pour toutes les occurrences
d'individu reliées (pas de patte optionnelle ou multiple).
La règle à retenir sur les relations est :
L'occurrence d'une relation donnée ne peut exister qu'une fois entre deux
occurrences d'individu.
une fois !
Les contraintes sont un complément d'informations sur le modèle de

données. Les principales sont les cardinalités minimale (0 ou 1) et
maximale (1 ou N) d'une patte, nombres minimum et maximum
d'occurrence(s) de patte que peut avoir une occurrence d'individu pour une
relation donnée.
Au début, on lit carré puis carré et cercle. Puis, on s'aperçoit que les carrés
sont des rectangles et les cercles des ellipses et enfin qu'entre rectangle et
ellipse la différence n'est qu'une question de point de vue mais que toute la
méthode est dans ce point de vue.
4.8 Exercices
1. Le dessin représente une opération (prise de commande) d'un modèle de
traitement, un message événement, trois messages résultats (commande
de coke, demande de produit de substitution, ordre de réapprovisionnement
et ordre de livraison) et deux conditions (pas de coke en stock et coke en
stock). Quelles sont les relations entre les individus MESSAGE, OPERATION
et CONDITION ?
Commande de coke
Prise de commande
Pas de C oke Coke en

en stock stock
Demande De Produit Ordre De Livraison

De Substitution
Ordre De
2. Trouver les cardinalités de chaque patte "fils de" et "parent de" pour
chaque occurrence d'individu.
En supposant que tous les cas possibles sont dessinés, en déduire les
cardinalités minimales et maximales de chaque patte.
Paul
François
engendrer
parent de fils de Marie

Pierre
PERSONNE
nom personne
prénom
3. Quel est le bon modèle ? et quelles sont les cardinalités ?

Un exemplaire est un exemplaire physique de livre. Un ouvrage est un livre.
OUVRAGE EXEMPLAIRE
de
AUTEUR PRET
écrire prêter
Celui-ci ?...
EXEMPLAIRE OUVRAGE
de
AUTEUR PRET
écrire prêter
ou celui-là ?
4. Exercice médical. Quel est le modèle entre le malade, la maladie et les
symptômes ? Quelles sont les cardinalités ? Dites 33.
Le malade consulte le médecin, quel est le modèle ? Le même malade peut-
il consulter plusieurs fois le même médecin ?
5 VALIDATION DES MODELES ENTRE EUX

Modèles de communication (intervenants, messages et informations des
messages), de données (individu, relation, patte, contrainte et informations
des individus ou des relations) et de traitement (messages, opérations et
conditions) doivent être cohérents entre eux.
MCC MCD
MCT
La première cohérence concerne les informations des messages et du

modèle de données.
La deuxième cohérence concerne les opérations et les modèles de données
"lus" ou "actualisés" lors de chaque opération.
Ces deux types de validation des modèles entre eux sont à effectuer pour
obtenir des modèles corrects.
5.1 informations des messages / individus et relations

Les informations du modèle de données sont "pures", il n'existe pas
d'informations polysèmes, synonymes ou pouvant être liées par une règle
de calcul ou une décomposition .
Celles des messages ne sont pas aussi restreintes. Certaines ne seront
jamais dans le modèle de données par choix de l'utilisateur. Les autres se
retrouvent dans le modèle de données (individus et relations) soit via une
équivalence, soit via une règle de calcul.
Informations des messages (MCC et MCT)
non Direct, à
utilisées Règle de calcul Equivalence
l'identique
Informations d'un modèle de données (propriétés)
Les correspondances entre informations MCC/MCT et MCD peuvent passer

par des règles ou des équivalences.
5.1.1 Equivalence
Deux informations sont équivalentes quand les occurrences de l'une sont
soit le même ensemble (synonyme), soit un sous-ensemble de l'autre (la
cause de l'équivalence est alors une relation).
Prenons l'exemple suivant : un contrat est signé par trois sociétés, une
société vendeuse, une société acheteuse et un courtier ou commis-
sionnaire. Le message contrat comprend les trois informations Nom du
vendeur, Nom de l'acheteur et Nom du courtier. Nom de société représente
toutes les sociétés. Nom du vendeur représente les sociétés ayant vendu un
contrat. Nom de l'acheteur représente les sociétés ayant acheté un contrat.
Nom du courtier et Nom du commissionnaire sont synonymes et
représentent les sociétés ayant mis les deux parties d'un contrat en
contact.
1,1 0,N
vendre
CONTRAT 0,N SOCIETE
1,1
acheter
0,1 commissionner 0,N
Les trois relations...

L'information "Nom du vendeur" est équivalente à l'information "nom de
société" par la relation "vendre". Le nom de l'acheteur est équivalent au
nom de société de l'individu Société vu de l'individu Contrat par la relation
acheter.
Amont équivalence Relation Aval équivalence
vendre Nom du vendeur
Nom de société acheter Nom de l'acheteur
commissionner Nom du commissionnaire
... donnent naissance à trois équivalences.

Toutes les informations contenues dans l'individu société peuvent être
traitées de la même manière : adresse du vendeur, banque du vendeur...
5.1.2 Règle de calcul
L'information d'un message peut être liée aux informations du modèle de
données via une règle de calcul.
Soit la règle de calcul d'un montant T.T.C. à partir d'un taux de T.V.A. et d'un
montant hors taxe. L'égalité est :
montant avec tva =

montant hors TVA * (1+ TVA)
La règle permet d'obtenir les informations en sortie ou résultats à partir des

informations en entrée ou hypothèses.
information en entrée taux tva

information en entrée montant hors tva
REGLE DE CALCUL MONTANT

CALCUL TTC
information en sortie montant avec tva

ou résultat
Quelquefois la règle est définie, mais pas son sens ; le montant d'une
transaction en francs français, le montant en devise et le taux sont connus.
La règle permet-elle de connaître le montant en devise ou le taux de la
transaction ? Quelle est l'information mémorisée ?
taux de la transaction montant en devise

montant en franc montant en franc
CALCUL DU MONTANT CALCUL DU TAUX

EN DEVISE DE TRANSACTION
montant en devise taux de la transaction
Quand l'information est dans un message reçu par l'entreprise et que

l'information mémorisée dans le modèle de données est obtenue par un
calcul, nous avons le premier schéma. Quand l'information est dans un
message émis par l'entreprise et l'information mémorisée dans le modèle
de données hypothèse, nous obtenons le deuxième schéma.
Information appartenant à
Information appartenant à
un message
un individu ou une relation
REGLE DE REGLE DE
CALCUL CALCUL
Information appartenant à Information appartenant à

un individu ou une relation un message émis
Cas des informations reçues et à émettre

Dans le modèle conceptuel de données, aucune information ne peut être à
la fois dans le modèle (portée par un individu ou une relation) et déduite
des informations du modèle. Pour chaque règle de calcul, les informations
en entrée et les informations en sortie ne peuvent être ensemble dans le
modèle. La représentation des règles de calcul peut être grossière
(optimisation de tournée) ou fine (calcul du détour d'une livraison à
effectuer en un point par rapport à tous les points d'une tournée). Au
niveau conceptuel, préférer les grossières, la finesse viendra de la
spécification des programmes, au niveau physique.
5.2 Modèles des opérations.

Une vue est un sous-ensemble du modèle de données comprenant des
individus, des relations et des informations. Cette vue externe, "vue" de
l'opération, peut être différente de la représentation du modèle principal.
A chaque opération du modèle de traitement correspond une ou deux vues
du modèle de données. Une vue représente le modèle en lecture ou en
consultation. Quels sont les clients ? Quelle est l'adresse d'Auguste ? Une
autre vue représente le modèle en mise à jour, (en création ou en écriture).
Cette validation entre MCD et MCT consiste à
- construire les vues ou modèles en lecture et/ou en écriture de chaque
opération conceptuelle,
- s'assurer que les informations nécessaires à cette opération existent dans
le modèle de données ou sont dans les messages événements,
- s'assurer que tout individu, relation et information appartient à une vue en
création et une vue en consultation.
Exemple du contrat de location de voiture : l'opération répond à la demande

de location et s'intitule "Etablir un contrat de location".
Demande De Location
De Voiture
Etablir un contrat
de location
Le modèle de données est le suivant : le contrat permet à un ou plusieurs

clients de conduire. Il indique le client payeur, le type de voiture louée et le
tarif. Il enregistre le numéro de la voiture et pour quelle période (location).
1,N CONTRAT DE LOCATION VOITURE

LOCATION
1,1 date début
conduire date fin
1,1 1,N 1,1 1,1 0,N 1,1
payer de
concerner
0,N
0,N
CLIENT porter typer
TYPE DE
VOITURE 0,N voiture
0,N
MCD GENERAL
5.2.1 Modèle de données en consultation.

Lors de l'établissement du contrat de location, l'individu client est consulté
pour connaître l'existence éventuelle d'une occurrence. L'opération
sélectionne une voiture ainsi qu'un type de voiture en fonction de la
demande du client. Les individus consultés sont CLIENT, TYPE DE VOITURE,
VOITURE. La relation consultée est la relation entre voiture et type de
voiture. Elle sert de contrôle au choix de la voiture. De même, les
informations de chaque individu ou relation peuvent être détaillées (adresse
du client pour demander si l'adresse est toujours la bonne etc ...).
Individus et relations consultés sont dessinés en grisé.

LOCATION
1,1 date début
conduire date fin
1,1 1,N 1,1 1,1 0,N 1,1
payer de
concerner
0,N
0,N
CLIENT porter TYPE DE typer
VOITURE 0,N voiture
0,N
VUE en CONSULTATION
5.2.2 Modèle de données en mise à jour

Après avoir pris connaissance du client, l'opération crée ou modifie son
adresse, crée le contrat de location, les relations conduire et payer, note le
numéro de permis de conduire dans la relation conduire, crée une

occurrence de l'individu location et une occurrence de la relation entre
location et voiture.
Individus et relations créés sont dessinés en grisé.

LOCATION
1,1 date début
conduire date fin
1,1 1,N 1,1
1,1 1,1 0,N
payer concerner de
0,N
0,N
CLIENT porter typer
TYPE DE
VOITURE 0,N voiture
0,N
VUE en MISE A JOUR

Les informations créées peuvent être résultat d'une règle de calcul. Dans ce
cas, la règle de calcul est reliée à l'opération. L'opération effectue la règle
de calcul. Il est intéressant d'obtenir des règles de calcul par opération. Ce
sera le travail de l'informatique plus tard. Une conception sans règle de
calcul est soit une conception de contrôle de type autorisation (vérifier les
autorisations de signer les chèques, d'émettre des ordres de paiement...)
d'interrogation ou de recherche, soit un traitement de texte.
Quand toutes les vues en création ou modification et consultation des
opérations sont construites, les deux étapes suivantes à effectuer
consistent à :
- vérifier que toutes les informations d'une opération sont disponibles et
que
- tous les individus, relations et informations sont créés et consultés par une
opération.
De nouvelles informations ou relations du MCD apparaissent ainsi que des
nouvelles opérations.
6 VALIDATION DE L'UTILISATEUR.
La validation des travaux par l'utilisateur final de l'application informatique

est un travail nécessaire. La présentation améliore la communication. Le
travail de fond consistant à lire tous les documents dans le détail pour
approbation ou rectification doit être fait avec l'utilisateur. Le libellé ou
l'explication de texte des informations doit aussi être validé. Il est important
de prendre en compte le temps nécessaire à ce travail. Il importe de faire
l'étude le plus rapidement possible pour éviter que "le soufflé ne
redescende".
Le MCC est aisé à valider par l'utilisateur. Le seul danger est de ne
repérer que les documents actuels sans leur correspondant conceptuel.
Les dessins du MCD peuvent ne pas être compris, mais la traduction
"littéraire" doit correspondre à la vue de l'utilisateur. Ceci est vrai pour les
vues "repliées" qui simplifient la vie et les dessins des modèles mais
compliquent les explications. La seule vue qui soit bonne est celle comprise
par l'utilisateur.
7 RESUME GENERAL DU CONCEPTUEL.
L'intérêt de l'étude du niveau conceptuel réside dans l'analyse des objectifs

de l'entreprise et de son système d'information indépendamment de toute
organisation.
Le modèle de communication (MCC) représente les systèmes fonctionnels
(intervenants) externes (partenaires) et internes à l'entreprise (domaines et
sous-domaines). A chaque fonction correspond un objectif de l'entreprise.
Les échanges d'informations (messages) entre ces fonctions sont
répertoriés et les informations recensées et "épurées". Une étude générale
identifie les domaines. Une étude détaillée (préalable à l'informatisation)
prend en compte uniquement un domaine.
Le modèle conceptuel de traitement (MCT) détaille l'opération conceptuelle
ou le traitement précédant l'émission de message résultat ou suivant la
réception de messages événements. Chaque MCT se construit par domaine
ou sous-domaine.
Le modèle conceptuel de données (MCD) décrit, par domaine de
l'entreprise, la structure des informations manipulées (individus, relations,
pattes et contraintes).
Deux types de validation des modèles entre eux existent.
- Toutes les informations des messages du MCC ou des MCT correspondent à
des informations du MCD soit directement, soit par le biais de règles de
calcul ou d'équivalence.
- Toute information nécessaire pour effectuer une opération du MCT est
disponible dans le message événement et le MCD. Toute information du
MCD est utilisée (créée et lue) par au moins une opération.
Toute l'étude doit être approuvée ou validée par l'utilisateur final.
D m3 C
m1 m2 m4
A m5 B
m6
MODELE DE COMMUNICATION MODELE DE DONNEES
m4
D C A m6
m5
m1 A m3
B
m6
m2
B
m5
MODELE DE TRAITEMENT DE A MODELE DE TRAITEMENT DE B
Le conceptuel, je l'assume
ça marche en
110 ou en 220 ? ou j'interpelle encore
le vécu de l'utilisateur ?
Chef, j'ai les modèles, Pas de problème,

mais où est la notice ? les zéros et les uns
ne sont pas passés.
P.D.G Responsable
M. MERISE Informaticien
Utilisateur
BUREAU DE VALIDATION DU CONCEPTUEL

CHAPITRE II : LE NIVEAU ORGANISATIONNEL
Le moineau, si petit soit-il, possède des

entrailles complètes.
(Proverbe chinois)
Après avoir défini les fonctions principales de l'entreprise et ses
domaines d'information, les concepts et la transformation des messages,
le cadre de l'application est stabilisé. Le propos de ce chapitre est la
définition de l'organisation, des postes de travail, des sites de traitement
et de données. La définition des outils de gestion informatiques viendra à
l'étape suivante, au niveau logique.
Les modèles organisationnels de traitement (MOT) définissent ce que fait
chaque poste de travail, QUI FAIT QUOI ? Préalablement à ces modèles,
l'organisation des postes de travail, QUI, est définie.
Le passage des modèles conceptuels de traitement (opérations
effectuées par des intervenants) aux modèles organisationnels de
traitement (opérations effectuées par une structure organisée) n'est pas
automatique. La construction de la structure des postes de travail
apporte une dimension nouvelle qu'il faut assimiler. Les fonctions de
l'entreprise sont "projetées" sur les postes de travail. Toute opération
conceptuelle devra être exécutée de manière organisée par un poste de
travail.
Les modèles organisationnels de données (MOD) ajoutent la géographie
des données aux concepts. Chaque modèle organisationnel est un sous-
ensemble du modèle conceptuel adapté à un site de données. Le lien
entre MCD et MOD est donc fort. Un MCD correspond à un domaine.
L'étude des MOD se conduit par domaine afin de faire ressortir les
cohérences et les consolidations entre site.
Les MOD s'enrichissent, par rapport au MCD, de nouveaux individus liés à
l'organisation tels que "autorisation", "document", "historique".
Les modèles organisationnels de communication (MOC) représentent les
communications entre sites de traitement, attachés à un poste de travail,
et un site de données.
L'ordre des trois modèles du niveau organisationnel (traitements,
données et communications) est différent de celui du niveau conceptuel.
1 POSTE DE TRAVAIL ET ORGANIGRAMME.
1.1 Poste de travail.

Le découpage organisationnel de l'entreprise définit les postes de travail
ou les unités d'organisation. "QUI", poste de travail est défini avant de
déterminer "QUI FAIT QUOI ?"
Un poste de travail est une responsabilité au sein de l'entreprise : P. D.
G., directeur commercial, secrétaire... Il est aussi "casquette" : acheteur,
vendeur... Une même personne peut avoir plusieurs casquettes. Tout
dépend de ses capacités et de sa charge de travail. Certaines personnes
auront toujours la même casquette : Andy Capp, le héros de bande
dessinée, par exemple. D'autre part, plusieurs personnes peuvent porter
la même "casquette" comme une caissière dans un supermarché. A

l'étape suivante, il sera nécessaire d'affecter des personnes à chaque
poste. Les écrans informatiques seront validés par les personnes
affectées à un poste, les utilisateurs finals.
Une organisation est une adaptation des fonctions de l'entreprise à
l'environnement en les projetant sur les postes de travail. Un poste de
travail est défini par les moyens mis à disposition (personnes, ressources
matérielles et logicielles) et le travail à effectuer (les opérations
organisées).
La définition des postes de travail reflète les intervenants définis au
niveau conceptuel.
ORGANISATION
Poste 1 Poste 2 Poste 3
FONCT ION
Intervenant 1
Interne
Intervenant 2
Interne
Intervenant 3
Interne
L'organisation est SPECIALISEE...

Si chaque poste de travail traite une fonction, l'entreprise est organisée
de manière spécialisée.
A la Poste, en France, à un guichet (poste de travail 1, 2, ou 3) cor-
respond une fonction : distribuer les timbres-poste, affranchir les lettres
et les paquets, payer les mandats... les intervenants internes.
ORGANISATION
FO N C T IO N
Poste 1 Poste 2 Poste 3
Intervenant 1
Interne
Intervenant 2
Interne
Intervenant 3
Interne
...ou POLYVALENTE
Par contre, aux Etats-Unis, chaque poste de travail exerce les différentes
fonctions. Les clients attendent sur une file commune et vont au premier
guichet libéré. Cette organisation est non spécialisée ou polyvalente. On
peut aussi dire qu’il n’existe qu’un seul poste de travail.
Les raisons de s'organiser de telle ou telle manière sont des raisons de
bon sens telles qu'un partenaire (le client par exemple) doit toujours
avoir un même poste de travail (interlocuteur client) comme
correspondant pour le fidéliser ou des raisons de pouvoir ou d'historique
non formalisable. L'utilisateur exerce son choix.
1.2 Organigramme.
L'organigramme est un dessin représentant la structure d'organisation
des postes de travail de l'entreprise.
Pour être défini sans ambiguïté, un poste de travail ne doit dépendre que
d'un seul poste de travail amont (qui est responsable ?) et doit avoir ses
responsabilités clairement énoncées (que fait-il ou que doit-il faire ?).
Cela évitera d'embaucher un salarié pour faire A, lui faire faire B, le juger
sur C et lui octroyer la médaille du travail pour D.
Poste de
P. D. G.
Travail
D. G. Service de livraison
L'architecture des postes de travail est représentée par un

organigramme...
Le niveau de détail de la définition des postes de travail dépend de
l'objectif poursuivi par sa construction. S'il s'agit de définir l'organisation
générale d'une grande entreprise, l'organigramme est général. S'il s'agit
de définir ou valider des écrans informatiques, l'organigramme doit être
détaillé. Le travail de la secrétaire est différent de celui du livreur.
P. D. G.
Livreur Secrétariat de livraison
...plus ou moins détaillé.

Un organigramme de "postes de travail" a plusieurs formes :
- rateau ou peigne où un chef a plusieurs subordonnés :
- matrice, où une personne a deux supérieurs 1 et 2 (fonctionnel et

opérationnel) :
Fonction
Operat.
- "armée mexicaine" où plusieurs généraux se partagent un seul caporal :

Reprenons la société décrite conceptuellement par les domaines livrer,

facturer et encaisser :
ENCAISSER LIVRER
FACTURER
.
L'entreprise découpée en systèmes fonctionnels...
Son organisation est le Président Directeur Général, qui encaisse, livre et
facture, son "bras droit" qui livre et facture et le livreur qui ne fait que
livrer. Livrer, encaisser et facturer sont des intervenants, P. D. G., "bras
droit" et livreur sont des postes de travail.
P. D. G. Poste de
Travail
Bras Droit Livreur
... possède un ORGANIGRAMME...
P. D. G.
L
I
V
R
E
U
BRAS DROIT R
..et se découpe en systèmes organisés, les postes de travail
ENCAISSER LIVRER
P. D. G.
FACTURER
BRAS DROIT
LIVREUR
Le P. D. G. livre, facture et encaisse. Son "bras droit" livre et facture. Le

livreur livre.
L'organisation est plus souvent modifiée que les fonctions. Si le "bras

droit" du P. D. G. fonde sa société de livraison, si le livreur suit des cours
de comptabilité et que le nombre de factures à écrire augmente
considérablement, l'organisation deviendra P. D. G., comptable et
facturier. Encaisser, livrer et facturer seront toujours effectués.
P. D. G.
Com ptable Facturier
2 MODELE ORGANISATIONNEL DE TRAITEMENT (MOT)

S'organiser consiste aussi à prévoir les réactions ou les réflexes à
acquérir face à des événements extérieurs. Ces réflexes normalisés au
sein de l'entreprise sont décrits sous formes de procédures, les MOT.
Après avoir défini qui est qui, comment il se situe dans un organi-
gramme, nous allons représenter qui fait quoi, quel poste de travail
effectue quelle opération au moyen de procédures, les MOTS ou Modèles
Organisationnels de Traitement.
Une procédure est un choix d'organisation face à un événement
(message) externe (venant d'un partenaire).
Une procédure prévoit tous les cas possibles à l'intérieur de cette
procédure. De manière plus abrupte : "savoir qui engueuler quand ça va
mal". Le Plan ORSEC est une procédure d'urgence. La présence ou
l'absence de procédure, prévoyant la conduite à tenir dans ces cas ex-
trêmes, permet de juger l'organisation.
ENTREPRISE ORGANISEE
Partenaire Poste 1 Poste 2 Poste 3 Partenaire
Message "externe"
enclenchant
Un MOT analyse les réactions des postes de travail à un message

externe.
Une procédure peut commencer par une opération sans message
événement comme la décision de passer des contrats financiers.
L'éclatement d'une opération conceptuelle en N opérations organisées
permet un partage des responsabilités et doit définir le contrôle en
découlant. Le regroupement d'opérations conceptuelles en une opération
organisée ou sur un poste de travail permet une synchronisation, donc
une accélération des traitements organisés et la création de postes de
travail "correspondant" de partenaires - le client a un interlocuteur
unique pour la commande, la livraison, le service après-vente, le
contentieux...
2.1 La procédure est composée d'opérations organisées (Quoi ?)

par des postes de travail (Qui ?)
Chaque opération est enclenchée par zéro, un (ou plusieurs mais ceci
n'est pas conforme à la réalité) message événement et, après traitement,
engendre zéro, un ou plusieurs messages résultats.
L'opération peut être enclenchée de manière périodique, à 10 heures,
tous les jours, toutes les décades, toutes les mille factures... par un
temporisateur. Les clients réguliers pour lesquels de nombreuses factures
sont à émettre peuvent recevoir leurs factures toutes les décades par
exemple.
Temporisateur
tous les
dix jours
émettre factures
des clients réguliers
Factures client
Elle peut être enclenchée par un temporisateur

Sans message événement, ni temporisateur, l'opération est une décision.
Sans message résultat, l'opération est une prise en compte d'un
message informant venant d'un partenaire. Il n'existe pas d'opération
sans message événement et sans message résultat. Si un message
informant est émis par un autre poste de travail, ses informations sont à
l'intérieur du système d'information et sa représentation est inutile. Les
messages de poste de travail à poste de travail sont toujours
enclencheurs.
prendre
note
j'ai décidé que ...
Opérations sans résultat ou sans événement.

Le choix d'une procédure plutôt qu'une autre est un choix personnel de
l'utilisateur ou de celui qui conçoit les procédures (l'organisateur). Ce
choix est subjectif. L'important est de s'assurer qu'une personne suive
toutes les procédures liées à un domaine afin de vérifier leur cohérence
et souligner les détours inutiles.
Chaque opération correspond à une valeur ajoutée. Si l'opération
consiste à transmettre le message à un autre poste de travail, elle peut
être supprimée (l'opération, pas le poste de travail, sauf s'il ne fait que
ça). Cette valeur ajoutée provient souvent d'une opération conceptuelle.
Toute opération conceptuelle doit donner lieu à au moins une opération
organisée.
Les messages organisés, décrits par une procédure comme événement
ou résultat d'opération organisée, correspondent à certains documents
circulant dans l'entreprise. A ce stade de l'étude, il est intéressant de
comparer ces documents avec le modèle (MOT ou procédure).
L'existence des informations des documents existants est alors vérifiée.
Ce point est développé dans le paragraphe concernant les MODs.
Un poste de travail effectue plusieurs opérations de plusieurs procédures.

La lecture de toutes les opérations organisées d'un poste de travail
détermine la définition du poste. Une chronologie des événements et des
opérations peut être tenue : 8H réception des commandes, 14H
Livraison. Ainsi, la charge de travail dans le temps est analysée par poste
de travail et définit les ressources à mettre en place y compris aux
heures de pointe.
2.2 Tâche-homme et tâche-machine sont dans l'opération

Le découpage de l'opération en sous-opérations manuelles ou au-
tomatisées n'est pas nécessaire. L'opération peut être décomposée en
sous-opérations ou tâches pouvant être de deux types : les tâches
"nobles", humaines et les "machinables". Pour aller au cinéma, la tâche
humaine est de regarder le film, la tâche machine est le déplacement à
la salle de cinéma. Un choix supplémentaire s'effectue. La décomposition
dépend de l'utilisateur. La périodicité des tâches à effectuer et le gain
attendu en temps ou en argent ou en pénibilité sont les principaux
critères de choix. La décomposition est ardue quand les deux tâches sont
exécutées en même temps. Je conduis et je passe les vitesses. Tâche-
homme ou tâche-machine ? C'est pourquoi cette notion de tâche
exécutée par un homme ou une machine peut être oubliée en première
approche. Il importe surtout de comprendre que l'opération comprend
tout et même et surtout les décisions (opérations sans message événe -
ment).
Les messages internes à un même poste de travail doivent être sup-
primés.
Exemple : soit l'opération de "Prise en compte de la commande". A
réception de la commande, la première tâche est de vérifier la confiance
que j'ai dans le client, d'examiner son encours, ce qu'il me doit et s'il n'a
pas atteint le plafond fixé par client, son encours maximum. Si son
plafond est atteint, je décide ou non d'honorer sa commande. Si sa
commande est honorable, je vérifie si les produits commandés sont en
stock. S'ils ne sont pas en stock, j'envoie un avis de réapprovisionnement
à un autre intervenant ou un autre poste de travail. S'ils sont en stock, un
avis de déstockage ou un bon de sortie magasin est émis pour livraison
et la facture est envoyée au client.
Commande du client
2
Commande
Commande au
client refus ée
Fournis s eur
Facture au Client
MOT 1 : l'opération, décomposée en tâches...

L'opération "Prise en compte de la commande" est découpée en 2 sous-
opérations ou tâches :
- Tâche 1 : Vérifier encours client.
- Tâche 2 : Vérifier si les produits commandés sont en stock.
Cette opération se ramène à :
Commande du client
1 2 3
Commande
Commande au client refusée
Fournisseur Facture au Client
...se ramène à l'opération ci-dessus. MOT 2

Les conditions de sortie et les messages résultats associés sont :
1 - Produit manquant et message résultat Commande fournisseur (ou
commande interne).
2 - Produit en stock et message résultat facture client (et bon de sortie
magasin).
3 - Commande non honorable et message résultat commande refusée.
Il est donc inutile de la décomposer.
2.3 Exemple de procédure ou MOT

Après avoir étudié organigramme et procédure, voici un exemple
représentatif de l'intérêt d'une procédure. Une opération conceptuelle,
"décider de réparer" est éclatée en 3 opérations organisées.
L'organigramme va du responsable de chantier, en bas, au responsable
national (en haut) :
Res ponsable National
Res ponsable Régional
Res ponsable Départemental
Res ponsable De Chantier
ORGANIGRAMME NATIONAL
Le niveau de décision de réparation d'équipements, local, régional ou
national, est décidé en fonction du montant de la réparation.
RESPONSABLE RESPONSABLE RESPONSABLE RESPONSABLE REPARA-

TEUR
CHANTIER DEPARTEMENTAL REGIONAL NATIONAL
Matériel
endommagé
ANALYSE DEMANDE
REPARATION
OK et Montant
Refus
< 10 > 10
Refus De
Réparation Demande De Réparation Régionale
Locale
ANALYSE DEMANDE
REPARATION
REGIONALE
OK et Montant
Refus
< 100 > 100
Refus De
Réparation
Demande De Réparation Nationale
Régionale
ANALYSE DEMANDE
REPARATION
NATIONALE
Refus OK
Refus De
Réparation
Nationale Ordre de
Réparation
MOT. Une même opération conceptuelle (réparer) se projette sur

plusieurs opérations organisées
Le responsable de chantier constate qu'un matériel qu'il utilise est
endommagé. Il en réfère au responsable départemental qui a le droit de
donner des ordres de réparations quand le devis estimé ne dépasse pas
10. Si le responsable départemental estime que la réparation n'est pas
nécessaire, il avise le responsable de chantier de son refus de réparer le
matériel. S'il pense que la réparation est nécessaire, mais que son
montant dépasse 10, il fait une demande de réparation régionale au
responsable régional qui a le pouvoir de décider la réparation si son
montant ne dépasse pas 100. En cas de devis de réparation supérieur à
100, le responsable régional demande au responsable national qui donne
accord de réparation ou refus au responsable régional. Le cas des
multinationales n'est pas envisagé ici.
Tous les messages ne sont pas représentés. Quand un avis positif sur la
réparation est donné, mais que le montant ne correspond pas à la
compétence, il faut indiquer au niveau inférieur que le dossier est en
bonne voie : "On s'occupe de votre cas", "Nous suivons votre dossier
avec la plus haute attention", "je m'en occupe personnellement".
N'apparaissent pas non plus les demandes de remplacement du matériel
endommagé dans les autres départements et régions que pourrait faire
le responsable régional ou national. Enfin, le responsable de chantier ne
sait jamais quand sa demande finale va aboutir. Vous pouvez compléter
la procédure en conséquence.
3 MODELE ORGANISATIONNEL DE DONNEES (MOD)

Les MOT, les procédures, déterminent qui fait quoi ? De la même
manière, les modèles organisationnels de données déterminent qui - quel
site de données - stocke quoi - quelles informations dans quel modèle
organisationnel de données. Cette découpe par site, construite à partir
du MCD permet de conserver la cohérence, de maîtriser la "redondance"
d'information entre site et détermine les consolidations de données

éventuelles.
Ce découpage permet de calculer les volumes de données nécessaires
par site de données final. Ce calcul de volume des données est de moins
en moins nécessaire suite à l'augmentation rapide des capacités de
stockage.
De plus, de nouveaux individus, reflets de l'organisation, tels que
documents, ou reflet de la réflexion, tels que Règle, apparaissent dans le
modèle de données à ce stade de l'étude.
3.1 L'organisation par site de mémorisation.

La notion de site est géographique. Un site peut être le site d'un poste
de travail ou le site de données pour un même poste de travail.
Néanmoins, si l'informatique est définie, des sites plus précis et cor-
respondant aux bases de données sont retenus : un site tableur, un site
micro-ordinateur, un site central à l'entreprise, un site pour interrogation
des données ou infocentre... Dans ce cas, le choix du niveau de détail
dépend du système informatique.
Le modèle conceptuel de données est rapproché des différents sites
géographiques de données, ou de mémorisation, ou de traitement.. Pour
chaque site, une "vue externe" ou partielle du modèle général de don-
nées est définie. Cette vue concerne les individus, les relations et les
informations.
Pour chaque base de données, un modèle organisationnel de données
(MOD) est construit. Ces modèles organisationnels de données sont des
vues externes du modèle principal (MCD) sur chaque site.
Exemple : soit une entreprise de livraison constituée d'un siège social,
d'un entrepôt et d'agences. Le siège qui s'occupe de tous les clients et de
toutes les factures aura le modèle général comme vue externe :
CLIENT C ONTRAT 1,1 COMMANDE

0,N 1,1 0,N
0,N
1,N
0,N
1,1 0,N
FACTURE 1,N 0,N LIVRAISON PRODUIT
1,N 0,N
MCD et MOD SIEGE

L'entrepôt ne s'occupe que de la livraison à partir des ventes et a un
modèle sans contrat ni facture.
C LIENT 1,1 C OMMANDE

0,N
0,N
1,N
0,N
LIVRAISON P RODUIT
1,N 0,N
MOD SITE 1 : ENTREPOT

Une agence n'effectue que les livraisons et les factures et a un modèle

sans contrat.
C LIENT 1,1 C OMMANDE

0,N
0,N
1,N
0,N
1,1 0,N
FAC TURE 1,N 0,N LIVRAISON P RODUIT
1,N 0,N
MOD SITE 2 : AGENCE

Un site comprendra le modèle commande et facture et l'autre le modèle
commande et livraison. L'organisation des données n'est pas par sous-
ensembles cohérents du modèle principal tels que modèle contrat,
modèle facture ou modèle livraison. Le découpage organisationnel est
réalisé à partir des individus "vus de la lorgnette utilisateur" basés sur un
site précis.
Analyse des modèles organisationnels : chaque individu d'un modèle
organisé est analysé. Quel type d'occurrences gère-t-il ? Les produits
gérés par l'entrepôt AUFEU situé à Lyon sont-ils les mêmes que ceux du
siège de Paris ? Quelles informations sont prises en compte ? Le prix du
produit est-il communiqué ?
3.2 Evaluation des volumes des données

L'évaluation du volume des données est nécessaire quand une solution
est envisagée sur micro-ordinateur ou quand l'application finale risque de
faire "sauter" les disques de stockage. Elle permet de calculer le volume
d'espace disque nécessaire ou d'en déduire des sauvegardes sur
disquette ou bande magnétique. Nous sommes à la limite de
l'organisationnel et de l'informatique. Ce calcul est néces-saire dans le
cas d'applications du type "statistiques de ventes" où les informations
résultats de calcul sont mémorisées.
Les volumes concernent le nombre d'occurrences d'individus par site et
les informations de chaque individu ou chaque relation par site de
données. Combien d'occurrences contient l'individu PRODUIT sur le site
de LYON en moyenne ?
Quand tous ces renseignements seront connus, il sera possible de
calculer les volumes de mémoire nécessaires à l'informatisation par site
en multipliant le nombre d'occurrences de chaque individu "organisé" par
le nombre de caractères des informations d'un individu.
Exemple : le client porte comme informations son code sur 3 carac-
tères, son adresse sur 30 caractères, son nom sur 20 caractères, son
prénom sur 10 caractères et le nom de la personne à contacter sur 20
caractères. 20 000 clients seront gérés sur la base de l'agence YVES,
donc l'individu client comportera 20 000 (3+30+20+10+20) = 1 660 000
caractères. Ensuite, la conversion en kilo-octets, unité de base d'espace
mémoire informatique se fait en fonction du type de la base de données.
Le nombre final d'octets est supérieur au nombre de caractères du fait
des relations entre individus. Le fait qu'un chiffre prenne moins de place
qu'une lettre est négligeable. 1,7 Mega Octets sont nécessaires, dans cet
exemple, pour stocker les occurrences de client.
3.3 Le modèle de données s'organise : de nouveaux individus

apparaissent.
Les individus tels que DOCUMENT, HISTORIQUE, AUTORISATION
apparaissent pendant l'étude du niveau organisationnel et sont des re-
flets de l'organisation.
Les documents sont souvent des occurrences d'un même individu. Ne pas
créer autant d'individus que de documents !
Un document est émis par une personne et destiné à être reçu par
d'autres personnes. Un document est d'un type donné et concerne un
objet de gestion important de l'entreprise.
TYPE DE 0,N 1,1 DOCUMENT 1,1 0,N PERSONNE

typer émettre
DOCUMENT
document 1,N 0,N
recevoir
1,1
OBJET GERE 0,N
concerner
MCD du document
Exemples :
1 - L'objet géré est un contrat. Le type de document est lettre d'intention
de commande, telex contractuel, confirmation du contrat, lettre de crédit,
certificat de non-gage...
2 - L'objet géré est un mouvement de produit, les types de document
sont rapport d'inspection, rapport d'analyse de produit...
3 - L'objet géré est un mariage. Les types de document sont compte-
rendu de visite prénuptiale, dépôt de la liste de mariage, faire-part de
mariage, livret de famille...
4 - L'objet géré est un procès. Les types de documents sont... in-
nombrables.
Créer un seul individu pour plusieurs documents.
Historique provient des archivages à effectuer en ne retenant pas toutes
les informations. Les informations des individus "archives" sont à définir.
Elles peuvent être différentes des individus "vivants".
Premier exemple : les soldes des comptes généraux seront conservés
pendant une période plus longue que les écritures comptables se rap-
portant à ces soldes.
0,N 0,N C OMP TE EC RITURE

P ERIODE 0,N 1,1
GENERAL C OMP TABLE
solder
2 Ans 1 An
Deuxième exemple : chaque contrat comporte des informations telles

que date, taux contractuel si le contrat est un contrat de change ou
d'intérêt. Il sont reliés à un client, un type de contrat, un chargé d'affaire,
une division...
Prenons comme hypothèse que ces contrats sont conservés deux ans
quand ils sont échus. Après ces deux ans, ils sont archivés. Les
informations d'un contrat que l'on archive sont restreintes par rapport à
celles d'un contrat en activité. Seul le résultat, le gain ou la perte, est
mémorisé (information résultat de calcul). Seul le type de client est

mémorisé et non le client particulier. Toutes les informations ne sont pas
mémorisées.
5 Ans 2 Ans
C ONTRAT TYP E DE CONTRAT

C LIENT
ARCHIVE C LIENT
date c ontrat
résultat taux c ontrac tuel
date d'éc héanc e1,1 0,N 0,N 1,1 0,N 1,1 date d'éc héanc e
Les individus Règle, Scénario... sont des indications de

l'approfondissement de l'application. Ces individus apportent une forte
valeur ajoutée et sont représentatifs de traitements formalisés dans les
données. Ils apparaissent souvent au niveau organisationnel car ils sont
identifiés et créés lors d'une deuxième "passe" sur les modèles.
Exemple : soit des contrats financiers (prêts ou emprunts) à options ou à
échéance optionnelle. Dans le cas de contrat à option, le choix de
respecter le contrat ou de livrer (d'emprunter un emprunt ou de prêter
un prêt) est à l'initiative de l'acheteur du contrat. Dans le cas de contrat
à échéance optionnelle, la date d'échéance réelle du contrat est à
l'initiative de l'acheteur (date de remboursement du prêt).
Pour un scénario, c'est-à-dire un ensemble d'hypothèses, certains
contrats sont retenus, d'autres non (cas des options). Un paramètre du
contrat tel que date d'échéance peut être choisi. Après traitement, un
résultat de scénario donne certaines valeurs de paramètre telles que
montant à emprunter ou disponible pour certaines dates (position de
trésorerie). Un scénario peut être de solder tous les contrats de prêts
pour connaître "l'argent frais" disponible.
soldes date échéance

RESULTAT SC ENARIO prendre PARAMETRE
SCENARIO 1,1 0,N C ONTRAT
en compte
0,N valeur
0,N
0,N
0,N 0,N
retenir retenir
option 0,N
0,N
TY PE CONTRAT posséder
CONTRAT
1,1 1,N
0,N
L'individu AUTORISATION exprime la sécurité, les contrôles sur mots de

passe. Telle personne ou tel utilisateur a besoin d'une autori sation pour
émettre tel document ou un ordre de paiement.
Il peut se retrouver dans le modèle de sécurité informatique, de la
sécurité d'accès à des ressources informatiques (fichier, informations,
base de données, systèmes informatiques, outils informatiques...).
Une autorisation d'accès d'un type donné (création, modification,
suppression, lecture) est accordée à un utilisateur ou un groupe
d'utilisateur.
outil UTILISATEUR GROUPE

1,N 0,N D'UTILISATEUR
système
base de données 1,N
information 0,N
0,1 0,1 lecture
fichier
TYPE DE AUTORISATION suppression
RESSOURC E
modification
0,1
création
RESSOURC E 1,N
0,N 1,1 0,N accéder TYPE D'ACCES
1,N
0,N
L'individu AUTORISATION d'accès.
3.4 L'étude des documents existants

L'étude des documents existants se fait lors de l'étude organisationnelle
pour valider les messages organisés. Un modèle de données organisé est
facile à effectuer sur un document, car l'ordre de présentation des
informations est clarifié. Attention, ces documents peuvent être des
bordereaux de saisie ou des résultats de calcul. Dans le deuxième cas, ils
ne correspondent pas à un modèle conceptuel de données car ils
contiennent des données calculées.
Exemple : la prévision des ventes est effectuée par vendeur, pour un
produit donné et dans un service. Les imprimés sont remplis ainsi.
S ervice TERIQU E Produit OUNON
Vendeur : A 100
Vendeur : B 1000
Vendeur : C 1
Vendeur : D 288
Vendeur : E 1580
Le modèle de données découlant de ce document est :
Térique Mai 88
SERVICE PREVISION
0,N 1,1 100
VENTES
vendre
1,1 1,N montant
Ounon A
PRODUIT 0,N 0,N PERSONNE
L'étude des documents existants permet de vérifier que toutes les

informations actuelles sont prises en compte pour l'analyse.
4 MODELE ORGANISATIONNEL DE COMMUNICATION (MOC) : les

messages échangés entre sites.
Les échanges ont lieu entre sites de traitement et de données.
Le MOC ne concerne que les communications entre sites. Il n'existe pas
s'il n'existe qu'un site.
Le modèle organisationnel de communication découle des opérations

organisées et des sites de données. Un échange a lieu quand un poste de
travail situé sur un site donné effectue une opération et que la vue en
consultation ou en mise à jour de cette opération se trouve sur un autre
site (voir ci-dessous la validation). Il en résulte des communications entre
les deux sites (de traitement et de données) qu'il importe de
dimensionner dans certains cas.
Lec ture
Opération
organisée
Ec riture
Site de Traitement
Site de Données
MOC
Exemple : cas de réparation locale, régionale et nationale.
1er Cas : centralisation totale, un seul site de données, au niveau
national.
Toutes les opérations, effectuées par les postes de travail des différents
sites, locaux, régionaux et national, font référence aux mêmes
informations sur un même site.
Il y a donc lieu de dimensionner les lignes de communications entre les
sites central, régionaux et départementaux. Il y aura mise à jour de la
base de données en "direct" à partir de tous les sites de traitement, des
postes de travail.
Lecture
Site de Données Site de Traitement
Centralisée (Poste de travail)
Ecriture
MOC 1
2ème Cas : centralisation nationale et régionale/locale. Un site de
données au niveau national et des sites de données régionaux et dé-
partementaux.
En supposant chaque MOD connu, un pour le site national et un par site
régional ou local (individu "réparateur" sur site national, "réparation" sur
chaque site), les messages échangés entre site de données et site de
traitements sont :
Consultation des
Site de Données réparateurs agréés Site de Traitement
National Local
Ec riture
Consultation des Ecriture
réparations
Site de Données
Régional et local
MOC 2
3ème Cas : décentralisation totale. Il n'existe aucun échange, sauf

éventuellement entre sites locaux et base de données locale, sites dé-
partementaux et base de données départementale.
MEME SITE
Lecture
Traitement Données
Local Locales
Ecriture
MOC 3
Dans cette phase, la "propriété" des données, l'autorisation de créer,
de modifier, de lire et de supprimer des occurrences doit être explicitée
par poste de travail.
Qui est responsable de la mise à jour des clients de l'agence ? Quelle
opération crée quel individu sur quel site de données ?
5 VALIDATION MOD/MOT.
De la même manière qu'au niveau conceptuel, une vérification de la
cohérence des modèles entre eux est faite. Cette vérification comporte
deux étapes.
- Cohérence entre les informations des messages des modèles or-
ganisationnels de traitement, les procédures et les informations des
modèles organisationnels de données portées par les individus et les
relations de chaque site de données.
- Cohérence entre la création et la consultation des informations des
modèles de données lors d'opérations organisées effectuées par un poste
de travail. Les informations nécessairement disponibles et donc
consultées pour effectuer les opérations organisées doivent se trouver
dans les modèles organisationnels de données et créés par d'autres
opérations.
Toute donnée d'un MOD est créée et consultée par une opération.
5.1 Messages organisés/individus et relations organisés
Informations des messages organisés (MOT)
non Direct, à
Règle de calcul Equivalence
utilisées l'identique
Informations d'un modèle organisé de données (MOD)
Les correspondances entre données et traitement passent par des règles

de calcul ou des équivalences.
Les informations "utiles" de chaque message organisé (entre opérations
organisées ou émis par un partenaire) doivent se retrouver à l'identique
ou via une règle de calcul ou une équivalence dans un modèle de don-

nées organisé, dans un individu ou une relation d'un site.
5.1.1 règles de calcul
Une règle de calcul transforme des informations en entrée (de règle) en
informations en sortie (de règle). Les règles peuvent s'appliquer sur des
ensembles et font alors intervenir un compteur d'occurrences. Les règles
ont toujours un sens.
Un exemple de règle sans compteur a été étudié au chapitre précédent
concernant le conceptuel. Il explicite le calcul d'un montant toutes taxes
comprises.
information en entrée taux tva

information en entrée montant hors tva
REGLE DE CALCUL MONTANT

CALCUL TTC
information en sortie montant avec tva

ou résultat
Règle de calcul simple.

Deuxième exemple de règle avec compteur d'occurrences dans le modèle
organisationnel de données : soit un contrat spécial avec remise en
fonction du nombre de commandes. Si le nombre de commandes est
petit, les frais occasionnés sont plus faibles et le client bénéficie d'une
réduction. Le raisonnement pourrait être le même en fonction du nombre
de livraisons.
Le modèle de données est : un contrat peut avoir de zéro à N remises.
Une remise est valable pour un seul contrat. Si le nombre de commandes
est inférieur à 20, la remise accordée est de 5%, Si le nom bre est
inférieur à 10, la remise est de 20%. Dans le cas cité, une remise de
100% est accordée s'il n'existe aucune commande. Ces remises ne sont
valables que pour un chiffre d'affaires à réaliser indiqué dans le contrat.
20
5
10
20
REMISE CONTRAT 0,N 1,1 COMMANDE

nombre de c ommandes
0,N c ommande /
remise ac c ordée c ontrat
1,1
MOD ou MCD
La règle de calcul concerne la remise à accorder. Les informations en
entrées sont le nombre de commandes d'un contrat donné et les remises
du contrat. Le nombre de commandes du contrat est calculé à l'aide
d'une première règle comptant le nombre d'occurrences de commandes
pour un contrat donné.
numéro de contrat nombre de commandes du contrat

numéro de commande remises du contrat
COMPTAGE DU NOMBRE CALCUL DE

DE COMMANDES LA REMISE
D'UN CONTRAT
nombre de commandes remise à accorder

du contrat
Règle de calcul avec compteur.

Troisième exemple de règle : sens de la règle de calcul
Une règle de calcul existe entre les coordonnées d'un éclair, d'un
observateur, la direction de l'éclair et le temps écoulé entre l'éclair et le
tonnerre. Cette règle existe. Il n'est pas nécessaire de l'expliciter
maintenant.
Coordonnées De L'éclair
Direction De L'éclair
Temps Après Éclair
Coordonnées Observateur
Ces informations sont liées.

Par contre, dans quel sens lire cette règle ? Veut-on obtenir les co-
ordonnées de l'éclair ? ou veut-on obtenir les coordonnées de
l'observateur ?
Coordonnées Observateur Coordonnées De L'éclair

Temps Après Éclair Temps Après Éclair
Direction De L'éclair Direction De L'éclair
calcul des calcul des

coordonnées coordonnées
de l'éclair de l'observateur
Coordonnées De L'éclair Coordonnées Observateur
Choisir une règle.
5.1.2 Equivalences
La notion d'équivalence a été développée lors de la validation des
modèles du niveau conceptuel. Un deuxième exemple est développé ici
dans le cadre de l'éclair.
Supposons que le modèle de données soit composé des individus BRUIT,
CLOCHE, ECLAIR et AVION. L'individu "bruit" est géré et contient des
informations telles que durée du bruit, fréquence du bruit... Le bruit
provient soit d'une cloche, soit d'un éclair, soit d'un avion (contrainte +).
0,N AVION
+ sonner
le mur
0,1
0,1
CLOCHE 0,N sonner les BRUIT ECLAIR
tonner
matines 0,1 0,1
LE BRUIT est tonnerre, son de cloche ou mur du son.

Les messages portent les informations "durée du tonnerre", "durée du
son de cloche" ou "durée du son du mur du son". Ces informations sont
équivalentes à l'information amont (qui se situe dans le modèle de
données) "durée du bruit".
L'information "durée du tonnerre" est (aval) équivalente à l'information
"durée du bruit" via la relation tonner. L'information "durée du son de
cloche" est (aval) équivalente à l'information "durée du bruit" motif (via
la relation) sonner les matines. L'information "durée du mur du son" est
(aval) équivalente à l'information "durée du bruit" motif via la relation...
amont-équivalent aval-équivalent par RELATION
=
BRUIT
durée du tonnerre tonner
durée du bruit
sonner les
durée du son de c loc he
matines
durée du mur du son

sonner
le mur
Le bruit du modèle de données est équivalent au bruit du tonnerre s'il

tonne...
Le tonnerre, le mur du son et le son de cloche sont des types de bruit. Le
modèle était donc replié !
5.2 Modèles en création et en consultation des opérations

organisées.
A chaque opération correspond une vue organisée, un sous-ensemble
d'un modèle organisé de données en mise à jour et en consultation. Une
opération conceptuelle mémorise ou lit des informations dans les
modèles conceptuels de données. De la même manière, une opération
organisée mémorise ou lit des informations dans les modèles organisa -
tionnels de données, attachés à un site.
Un contrôle a lieu en fin d'étude organisationnelle en vérifiant que tout
individu, relation ou information est créé par une opération et consulté
par une autre. Ce point peut être validé par un utilisateur averti.
Réciproquement, toute donnée d'un MOD appartient à un modèle en
mise à jour et un modèle en consultation d'une opération. Si une telle
opération n'existe pas, soit la donnée est inutile, soit une opération
manque.
Exemple : le tonnerre est entendu s'il y a orage et éclair. L'opéra-tion
organisée "Tonnerre" est effectuée par un poste de travail "observateur".
Elle consiste à scruter le ciel, déjà répertorié, par ses orages et ses
éclairs et d'enregistrer le cri du tonnerre le soir au fond des bois. Les

éclairs sont aussi connus.
Le modèle conceptuel de données comprend les individus "orage",
"éclair" et "tonnerre". L'orage comprend des éclairs. Chaque éclair ap-
partient à un orage. Un tonnerre vient en plus d'un éclair. Mais si l'éclair
n'est pas connu, le tonnerre n'est lié à aucun éclair et l'éclair peut n'être
lié à aucun tonnerre. L'exemple aurait pu être pris avec la fumée et le
feu.
TONNERRE 0,1 0,1 EC LAIR ORAGE

1,1 0,N
MOD général.
Dès réception du message Tonnerre, le modèle consulté concerne les
individus ORAGE et ECLAIR.
ECLAIR 1,1 0,N ORAGE
MOD consulté.
Le modèle mis à jour comprend l'individu TONNERRE et la relation entre
l'éclair et le tonnerre. Les modèles comprennent aussi les informations.
ECLAIR 0,1 0,1 TONNERRE
MOD Mis à jour.

Pour une opération donnée, seule une vue en consultation ou en création
peut exister.
Vue En
Consultation
ECLAIR 0,N ORAGE

1,1
Lecture
OPÉRATION
TONNERRE Ecriture
Vue En
Création
ECLAIR 0,1 0,1 TONNERRE
L'opération consulte ou lit une vue, crée ou modifie une deuxième vue
Les modèles de données doivent être organisés.
Supposons qu'il existe deux sites de données, un site céleste et un site
terrestre. Les deux modèles célestes et terrestres doivent être considérés
car le modèle en mise à jour de la base terrestre ne sera plus le même,
mais comprendra non seulement l'individu tonnerre mais aussi les

individus orage et éclair.
Partenaire
MOD MOD
Poste 1
C éleste Terrestre
MISE A
Orage Orage
Tonnerre JOUR
LECTURE
Ec lair Ec lair
Tonnerre
Les MOD sont organisés.

Si le modèle terrestre ne connaît que les tonnerres éclairés et les éclairs
tonnants, son modèle de données sera une "vue externe" de la vue
céleste :
Orage Ec lair
tonnant
Un MOD peut être une vue externe.
6 VALIDATION PAR L'UTILISATEUR.

La validation consiste, pour le responsable utilisateur, à donner son
accord aux modèles décrivant l'organigramme des postes de travail et le
travail effectué par chacun.
Un organigramme sans pointillé entre un poste de travail aval et un
deuxième amont (opérationnel ou fonctionnel) est difficile à faire valider
par un utilisateur final. Dans ce cas, un poste de travail a plusieurs
responsables (postes de travail) en amont. Des messages incohérents
(faites ceci et faites cela) peuvent venir des deux sources.
Une procédure est facile à comprendre. Découper les opérations en
tâches n'est utile que pour expliquer la manière de travailler à un nouvel
utilisateur.
7 RESUME DU NIVEAU ORGANISATIONNEL

Une étude organisationnelle commence par :
1 la définition des postes de travail.
Ces postes de travail (QUI EST QUI ?) sont placés dans la structure
d'organisation, un organigramme. Cet organigramme peut être construit
en deux temps : général, puis détaillé.
Poste de
P. D. G.
Travail
Organigramme
2 La liste des procédures à représenter.
Chaque procédure (MOT) décrit QUI (poste de travail) FAIT QUOI
(opération organisée) face à un événement extérieur.
ENTREPRISE ORGANISEE
Partenaire Poste 1 Poste 2 Poste 3 Partenaire
Message "externe"
enclenchant
MOT ou procédure
Une opération organisée est enclenchée par un message événement,
une décision ou un temporisateur.
- Les Modèles organisationnels de données (MOD) adaptent individus,
relations et informations du MCD par site de données. Les ensembles
d'occurrences sont explicités. Les volumes de données sont calculés pour
estimer les capacités de mémoire nécessaires.
- Les Modèles organisationnels de communications (MOC) entre sites de
données (MOD) et de traitement (Site de poste de travail) dimensionnent
les communications entre site et les accès possibles (création, lecture...)
Lecture
Opération
organisée
Ecriture
Site de Traitement
Site de Données
- La validation de la cohérence des informations entre modèles de

traitement et de données passe par les notions de règles de calcul et
d'équivalence.
Exercices :
1. Dessiner un organigramme allemand avec directoire.
2. Une réunion est-elle un poste de travail ?
3. Dessiner une procédure de vote. Les postes de travail sont Secrétariat,
qui donne les bulletins de vote, Président qui tient l'urne, et deux
assesseurs dont l'un tient le registre et l'autre le tampon final.
Poste 2
C Poste 1
D
PD G
M1
OO1
Poste 1 Poste 2
ORGANIGRAMME MODELE DE TRAITEMENT(MOT)
S3
S2
S1
MODELE DE COMMUNICATION MODELES DE DONNEES (MOD)

INTRODUCTION______________________________________________________100 sur 214
C'est bon, le P.D.G et le

ça marche :
Responsable utilisateur
je suis le Chef !
sont contents.
C'est bon, je n'ai Pas de problème,

rien à faire. les zéros et les uns
ne sont pas passés.
Responsable
P.D.G M. MERISE Informaticien
Utilisateur
BUREAU DE VALIDATION DE L'ORGANISATIONNEL

CHAPITRE III LE NIVEAU LOGIQUE
Changez de chanson quand vous changez de

montagne.
(Proverbe chinois)
Les fonctions et les concepts principaux sont définis (niveau conceptuel).

L'entreprise est organisée sous forme de postes de travail et de sites.
L'objectif du niveau logique est la définition des moyens informatiques à
disposition des postes de travail (utilisateurs) afin d'effectuer les opérations
organisées. Cette définition passe par la description de :
 l'aspect externe de ces moyens informatiques sous forme de masques
d'écran et de leur succession.
 les actions de ces moyens informatiques sur la structure logique des
données et, pour cela,
 la structure logique des données (MLD) indépendamment de tout choix
de matériel ou de logiciel de développement informatique.
Le niveau logique représente le dernier niveau validé par l'utilisateur final
(sauf si celui-ci réalise la programmation). Il comprend une vue de
utilisateur de l'informatique (vue externe de l'informatique) et une vue plus
spécifique (vue interne).
Le modèle logique de données (MLD) décrit les structures de données
indépendamment de la gestion physique des bases de données. Il est une
étape intermédiaire, intellectuellement très satisfaisante, vers le modèle
physique de données. Si celui-ci peut être construit, le MLD peut être sauté.
Un premier MLD se déduit d'un MOD (Modèle Organisationnel de Données).
Il est ensuite optimisé ou modifié suivant le choix de l'utilisateur pour
accélérer certains traitements effectués par les outils informatiques.
Le modèle logique de traitement décrit les moyens informatiques, les outils
de consultation et d'écriture informatique. Un outil logiciel "utilisateur"
permet soit la lecture, soit l'écriture d'informations dans la mémoire (les
enregistrements du modèle logique de données) de l'ordinateur ou les deux
(écriture et lecture). On distingue outil transactionnel ou en traitement
immédiat et outil de traitement différé.
Définir un outil informatique, c'est :
 dans le cas d'outils transactionnels, définir la liste des enchaînements
"question réponse", ce qui est affiché à l'écran et ce que l'utilisateur peut
frapper au clavier (Modèle logique de traitement).
 dans le cas d'outil de traitement différé, déterminer les fonctions de tri,
de calcul, de recherche et leurs conditions d'enclenchement nécessaires
au déroulement de l'outil.
C'est aussi, dans les deux cas, indiquer quelles sont les données ou
informations lues et écrites dans le modèle logique de données à chaque
étape (spécification interne).
Exemple d'outil informatique transactionnel : outil d'interrogation des
abonnés téléphoniques. Cet outil est décrit par une succession d'étapes (le
Modèle Logique de Traitement). La première étape concerne la saisie du
Nom, du prénom de l'abonné et la deuxième affiche son numéro de

téléphone, s'il existe.
Pour chaque outil transactionnel un MLT sera construit et les informations
de chaque étape analysées.
Exemple d'outil de traitement différé : les factures sont émises toutes les
décades. Un programme s'enclenchera donc le 10, le 20 et le 30 de chaque
mois pour imprimer toutes les factures.
Les applications des outils de traitement différé ou par lot sont les
traitements enclenchés par un temporisateur ou les traitements nécessaires
dus aux "performances" des machines. Les factures sont émises toutes les
décades. Mais, comme le calcul des factures avec TVA dure par exemple
plus de 4 heures, le calcul des lignes de factures TTC se fera tous les jours
et l'impression toutes les décades. Cela donnera lieu à deux outils de
traitement différé, le calcul des lignes de facture et le calcul et l'impression
des factures.
Le modèle logique de communication concerne surtout les outils de
traitement différé. Certaines données d'un MLD correspondent à des
données d'un autre MLD. Quand ces données peuvent être dupliquées
automatiquement, en différé, sans l'aide de l'utilisateur, des outils peuvent
effectuer ce transfert de données d'une base à une autre. Dans certains cas
spécifiques, comme la réservation de vols aériens, cela concerne les outils
fonctionnant "en temps réel" demandant une lecture ou une écriture
instantanée sur un site de données différent du poste de travail. Ce MLC est
un sous-ensemble du MOC.
1 LE MODELE LOGIQUE DE DONNEES, un exercice intellectuel.

Le modèle logique de données est un passage du MOD vers un système
informatique de stockage des informations dans une base de données
(Modèle physique de données).
Il comprend des enregistrements d'informations et des chemins d'accès aux
informations.
Tous les individus et toutes les relations d'un MOD contenant des
informations se transforment en enregistrement. Toutes les relations se
transforment en deux, trois ou N chemins. Une relation contenant des
informations se transforme donc en un enregistrement et des chemins.
La construction des enregistrements et des chemins d'accès aux in-
formations est indépendante du futur logiciel de gestion des données.
Cependant, la connaissance de ce logiciel, appelé SGBD pour Système de
Gestion de Base de Données, accélère la construction des fichiers finals. Si
le SGBD est connu, passez directement au niveau physique des données.
1.1 Enregistrement.
Un enregistrement est l'unité de données du niveau logique.
Les occurrences d'enregistrement mémorisent toutes les occurrences
d'information d'individu ou de relation et des occurrences de pattes, de
cardinalité maximale égale à un, désirées par l'utilisateur.
no 2
Occurrences dupond
no 3
toto d'information 1, place de
no 2 no 1 la mosquée
pince mi durand
no 1 1, place de
pince moi l'église
FILS PERE
numéro fils Information numéro père
prénom fils
nom père Occurrences
Enregistrement adresse d'enregistrement
Une occurrence d'enregistrement porte des occurrences d'information

Les informations contenues dans les individus et les relations sont
mémorisées dans les enregistrements. Une occurrence d'enregistrement, un
enregistrement élémentaire, est identifié par une occurrence d'information
particulière déclarée comme clé de l'enregistrement. Une occurrence de clé
d'enregistrement identifie une occurrence d'enregistrement. Un
enregistrement est "identifié" par une clé. Celle-ci peut être l'identifiant de
l'individu d'origine dans le cas d'enregistrement issu d'individu. Elle peut
être aussi la composition de clés d'enregistrement ou la composition de
clé(s) et d'un numéro d'ordre.
Un enregistrement est représenté sous la forme d'un rectangle, la clé de
l'enregistrement est soulignée pour indiquer sa spécificité.
Les numéros de fils ou de père sont des informations clés d'enregistrement.
Tout ce qui contient une ou des informations est transformé en
enregistrement. Donc, tout individu se transforme en enregistrement,
Individu FILS Enregistrement FILS

Identifiant Clé
numéro fils numéro fils
d'individu d'enregistrement prénom fils
prénom fils
L'individu se transforme en enregistrement

et toute relation porteuse d'information(s) se transforme en enregistrement.
COMMANDE PRODUIT
concerner
quantité
c ommandée
La relation "concerner" porteuse d'information...
CONCERNER Enregistrement
c lé c onc erner Clé d'enregistrement
quantité c ommandée
... se transforme en enregistrement "concerner".

1.2 Chemin
Un chemin permet la lecture d'informations à partir d'autres informations
situées dans les enregistrements.
Un chemin est orienté. A partir d'une occurrence d'information, le chemin
conduit à une ou N occurrence(s) d'information. Par extension, le chemin
d'un enregistrement vers un autre est le chemin de sa clé vers la clé du
second.
Un chemin peut ne pas exister pour toutes les occurrences d'information de

départ. Nous retrouvons les cardinalités minimum et maximum. Une patte
de relation est mémorisée par un chemin. Un chemin permet donc de
mémoriser les liaisons telles que Individu1-Relation1-Individu2... lisibles sur
un modèle conceptuel ou organisationnel de données.
Deux chemins sont implicites et ne seront plus pris en compte par la suite :
le chemin de la clé de l'enregistrement vers les informations de
l'enregistrement et les chemins des informations d'un enregistrement vers
sa clé.
1 - Le chemin de la clé d'un enregistrement vers une information de ce
même enregistrement est implicite.
Exemple : le chemin du numéro de client vers son adresse de livraison est
implicite. Si le "numéro de client", clé de l'enregistrement client est connu,
l'adresse de livraison de ce client est connue. La clé de l'enregistrement
donne accès à toutes les occurrences d'information de l'enregistrement.
2 - D'autres chemins, qui permettent de remonter des occurrences
d'information vers l'occurrence de l'enregistrement, peuvent être explicités
par enregistrement.
Exemple : à partir du nom du client, de son prénom et de son adresse de
livraison, je veux être capable de retrouver le bon client et son numéro, sa
clé.
CLIENT CLIENT
numéro de client numéro de client
nom du client nom du client
prénom du client prénom du client
date de naissance date de naissance
encours autorisé encours autorisé
adresse livraison adresse livraison
ville livraison ville livraison
2 Chemins implicites d'enregistrement
1.3 Construction du Modèle Logique de Données.

Le passage du MOD au MLD se fait en fonction de règles. Celles-ci
examinent les cardinalités des pattes, le nombre de pattes d'une relation et
l'existence éventuelle d'informations dans la relation.
1.3.1 Cas de la relation à patte 1,1

La relation se transforme en deux chemins dont un peut être supprimé en
cas de redondance d'information. C'est le cas du fils et de son père. Le fils
n'a qu'un père et le père peut avoir de 0 à N fils :
FILS PERE
numéro fils lier numéro père
1,1 0,N
Les individus père et fils et la relation lier...

Les deux individus se transforment en deux enregistrements dont les clés
sont les identifiants des individus père et fils, soit le numéro de père et le
numéro de fils.
La relation donne naissance à deux chemins : le premier permet l'accès du
fils à un père et le deuxième d'un père à tous ses fils.
1
FILS PERE
numéro fils
2 numéro père
... se transforment en 2 enregistrements et 2 chemins...

La migration du numéro de père dans l'enregistrement fils supprime le
premier chemin. Seul reste le chemin du père vers le ou les fils.
FILS PERE
numéro fils 2
numéro père
numéro père
Migrer le numéro du père dans le fils supprime 1 chemin.

Le chemin restant est représenté par une flèche pour différencier le départ
(numéro du père) de l'arrivée (numéro du fils).
FILS PERE
numéro fils numéro père
numéro père
Le chemin restant pointe du père vers les fils...

Cette flèche est dans le sens inverse de celle représentée sur le modèle de
données.
FILS PERE
numéro fils lier numéro père
1,1 0,N
MCD ou MOD : La flèche va du fils vers son père

Attention : la flèche a changé de sens !!
1.3.2 Relation binaire à pattes X,N - X,N non porteuse d'information

Une relation binaire X,N X,N (X est égal à 0 ou 1) ne comprenant pas
d'information se transforme en 2 chemins à N informations arrivées. Nous
retrouvons le même cas que le précédent. Comme les chemins ont N
arrivées, la migration d'une information dans un enregistrement n'est pas
possible.
1.3.3 Relation binaire à pattes X,N X,N porteuse d'informations
Une relation binaire X,N X,N comprenant des informations se transforme en
3 chemins et un enregistrement.
Deux individus et une relation porteuse d'informations se transforment en 3
enregistrements et 3 chemins :
 identifiant de l'individu 1 vers identifiant de l'individu 2,
 la réciproque, identifiant 2 vers identifiant 1 et
 le chemin des deux identifiants vers les informations de la relation.
Chemin 1 Chemin 2
COMPTE lier FILIALE

numéro c ompte 0,N
0,N
liaison
Chemin 3
Trois chemins.
Prenons l'exemple suivant : un compte d'une société a d'autres comptes de
liaison ou de consolidation correspondant à plusieurs filiales. Le compte
client no 411-412 correspond chez ma filiale Capone au compte fournisseur
401-512. La filiale Capone est pour moi le client 412 et je suis chez elle le
fournisseur 512.
401-512
411-412 Capone
COMPTE lier FILIALE
numéro c ompte
0,N liaison 0,N
Les 2 individus "compte", "filiale" et la relation "lier"...

Pour passer au niveau logique, les deux individus "compte" et "filiale" dont
les identifiants sont "numéro de compte" et "numéro de filiale" deviennent
deux enregistrements "compte" et "filiale" de clés "numéro de compte" et
"numéro de filiale". La relation "lier", porteuse d'informations, se transforme
en un enregistrement dont la clé peut être appelée "clé enregistrement
lier".
COMPTE FILIALE LIER

numéro c ompte numéro filiale Clé enregistrement lier
numéro c ompte liaison
...se transforment en 2 enregistrements issus d'individus, 1 enregistrement

issu de la relation...
La relation "lier" 0,N 0,N porteuse d'informations se transforme en trois
chemins.
 Le premier chemin permet d'obtenir toutes les filiales concernées par un
compte donné.
 Le deuxième obtient tous les comptes liés à une filiale donnée.
 Le troisième chemin permet d'obtenir le numéro de compte de la filiale à
partir d'un numéro de compte et d'un numéro de filiale. Un chemin
permet d'accéder à une ou N informations (arrivée) à partir de une ou N
informations (de départ).
1er
numéro c ompte N numéro filiale
2ème
N numéro c ompte numéro filiale
numéro c ompte 3ème

1 numéro c ompte
numéro filiale liaison
... et trois chemins.
1.3.4 Relations non binaires

Le cas des relations non binaires complique horriblement le sujet. Ainsi,
une relation ternaire - à trois pattes - entraîne la création de :
 3 chemins partant de chaque individu vers les deux autres individus via
la relation, plus
 les 6 chemins de chaque individu vers un seul des deux autres et,
 du chemin des trois individus vers l'information de la relation, quand elle
existe.
Soit, au total, 10 chemins possibles à partir d'une relation ternaire ! Tous
ces cas entraîneront la création d'un enregistrement provenant de la
relation. L'identification des chemins sert à l'optimisation : quels seront les
chemins empruntés ?
1.3.5 Construction de la clé
Les clés d'enregistrement, provenant d'individu ou de relation, peuvent
être la composition de clés d'enregistrement des individus originels ou la
composition de clés et d'un numéro d'ordre.
Clé composée de clés

La relation "concerner", devenue individu du fait de la "patte optionnelle"
avec la facture, est identifiable par la commande et le produit.
C OMMANDE PRODUIT
1,N concerner 0,N
qté c ommandée
L'individu "ligne de commande" se transforme en enregistrement dont la clé

peut être la composition du numéro de commande et du numéro de produit.
COMMANDE 0,N LIGNE DE 0,N PRODUIT

1,1 1,1
numéro de c omprendre COMMANDE c onc erner
commande numéro de
numéro de ligne
produit
de commande
L'individu "ligne de commande" se transforme en...
LIGNE DE COMMANDE
numéro de c ommande * numéro de produit
... enregistrement "ligne de commande" de clé composée

La clé de l'enregistrement ligne de commande est la composition ou la
série du numéro de commande et du numéro de produit. Si le numéro de
commande est égal à 38767 et le numéro de produit à 045, le numéro de
ligne de commande est égal à 38767 045.
Noter les "trous éventuels" sert au modèle logique.
Exemple : document et signature, mais avec la variante que les
"signatures anonymes", les croix apposées existent. Sur un document, tel
rôle (le jugé) est reconnu, mais le nom de la personne n'est pas connu, la
personne n'a pas été identifiée. Le modèle de départ est le suivant :
DOCUMENT 0,N
PERSONNE
0,N
signer
0,N 0,N
ROLE
anonyme
0,N
DEUX RELATIONS (signer et anonyme)...

Supposons que l'individu RESPONSABILITE provenant des relations Signer
et Anonyme devienne un enregistrement. La clé de l'enregistrement
"responsabilité" peut être composée de clés (numéro document-numéro de
personne-numéro rôle). Cette clé peut avoir un numéro de personne
inexistant ou vide. Le numéro de personne est un "trou" dans la clé (numéro
document, numéro de personne, numéro rôle). Pourtant la composition des
deux ou des trois clés fonctionne comme clé de la responsabilité. Ce
concept est important quand on passera au modèle physique de données.
Certains systèmes de gestion des données n'acceptent pas de valeur vide
dans la clé.
1,1 RESPONSABILITE 0,1 0,N PERSONNE

par
engager
0,N
1,1
DOCUMENT ROLE
valoir
0,N
...se transforment en un individu (RESPONSABILITE)
RESPONSABILITE
code document, code personne, code rôle
La clé de l'enregistrement dérivé est composée de clé d'autres

enregistrements (document, rôle et personne)
Clé d'enregistrement provenant de relation porteuse d'information.
Une deuxième manière de représenter la migration est de transformer en 3
enregistrements les deux individus et la relation. La clé de l'enregistrement
provenant de la relation est la composition des identifiants des deux
individus. La construction de cette clé mémorise le chemin des deux
individus vers la relation.
Exemple précédent : si la clé de l'enregistrement "lier" est la composition de
"numéro de compte" et "numéro de filiale", le troisième chemin disparaît.
Clé composée de clé et d'un numéro d'ordre
Dans certains cas, la création d'un numéro d'ordre (premier, deuxième,
troisième...) permet de créer une clé composée et supprime un chemin.
Exemple : l'échelle est composée de N barreaux. Les individus sont
"barreaux" et "échelle".
Barreau
Barreau
 1,1
 0,n
Echelle
Echelle
Le barreau de l'échelle est un individu ...

Dans le passage au modèle logique, les deux individus "barreau" et
"échelle" deviennent des enregistrements "barreau" et "échelle" et la
relation génère deux chemins provenant des deux pattes.
BARREAU 1 EC HELLE
référenc e barreau référenc e éc helle
% réduc tion barreau hauteur éc helle
N
qui se transforme en enregistrement barreau...

La clé de l'enregistrement barreau, "référence barreau" est choisie comme

composition de l'information "référence de l'échelle" et du "numéro du
barreau dans l'échelle". Choisir cette composition dispense du chemin
barreau vers échelle. Il suffira de lire une partie de la clé du barreau pour
connaître l'échelle. Un seul chemin est déclaré, le chemin de la référence de
l'échelle vers les N barreaux de l'échelle.
BARREAU ECHELLE
N
référenc e barreau = (référenc e éc helle, numéro d'ordre)
référenc e éc helle
hauteur éc helle
% réduc tion barreau
...dont la clé est composée de la clé de l'échelle.

Deuxième exemple de numéro d'ordre : l'individu location provenant de
la relation identifié par "numéro de contrat" et "numéro d'ordre de la voiture
louée". La voiture A1 aura la location 1 la première semaine, la voiture A2
aura la location 2 la deuxième semaine et la voiture A1 aura la location 3 la
troisième semaine.
1.4 Optimisation
Le passage des MOD au MLD peut être généré suivant les règles
précédentes, puis modifié "manuellement" afin d'optimiser traitements et
données. Les moyens d'optimiser un modèle logique de données sont la
suppression ou la redondance de chemin ou la duplication d'informations
(migration d'identifiants ou la redondance d'informations).
1.4.1 Suppression de chemin.
Des chemins provenant de pattes "conceptuelles" sont supprimés si
l'utilisateur ne désire pas les emprunter.
Exemple : la commande ne concerne qu'une seule devise. La liste des
commandes par devise ou le chemin du "code devise" vers le "numéro de
commande" n'intéresse pas l'utilisateur, il est supprimé.
COMMANDE DEVISE
devise /
numéro c ommande commande c ode devise
1,1 0,N
La relation donne naissance à 2 chemins non dessinés...
COMMANDE 1 Chemin DEVISE

numéro c ommande c ode devise
... car un seul est d’intérêt.
1.4.2 Redondance de chemin

Plusieurs chemins se suivant donnent naissance à un nouveau chemin qui,
par expérience de l'utilisateur, sera souvent utilisé.
Exemple : le véhicule a un propriétaire qui peut être une personne.
PERSONNE PROPRIETAIRE
0,1 0,1 0,1 VEHICULE
0,N
référence personne capitaliser
référence propriétaire appartenir
nom personne référence véhicule
prénom personne montant patrimoine nombre de roues
Le véhicule appartient au propriétaire personne...

Le passage au modèle logique génère 3 enregistrements et 4 chemins
issus des 2 relations.
PERSONNE 1
PROPRIETAIRE 1
VEHICULE
référence personne
nom personne référence propriétaire référenc e véhicule
1 N
se transforme en 4 chemins.
Si le véhicule et ses caractéristiques sont consultés, le nom et le prénom du
propriétaire seront consultés. Un chemin est créé partant de l'information
"référence du véhicule" pour aller vers l'information "référence de la
personne". Si l'information est unique, celle-ci peut migrer, être écrite
plusieurs fois pour faciliter et accélérer certains traitements.
Une redondance d'informations est créée en mémoire pour limiter les
chemins successifs à parcourir.
P ERSONNE 1
PROPRIETAIRE 1
VEHIC ULE
référenc e personne
nom personne référenc e propriétaire référenc e véhic ule
1 N
La personne propriétaire du véhicule est un chemin supplémentaire, un

raccourci ou shunt.
1.4.3 Migration ou redondance d'informations.

Migration et redondance sont deux manières de dupliquer les informations.
Une clé migre, un résultat de calcul et une information différente d'une clé
sont redondés.
Migration de clé.
Nous l'avons déjà rencontrée : c'est le cas de la migration du numéro de
père dans l'enregistrement fils pour supprimer le chemin du numéro de fils
vers le numéro de père.
Redondance des résultats de calcul.
Deux cas se présentent, un calcul issu d'une équation telle que montant
TTC = montant HT (1+TVA) ou un calcul avec comptage, ristourne accordée
en fonction du nombre de commandes. Dans ce deuxième cas, faut-il gérer
un compteur et, si oui, quand doit-il être utilisé ? Ce compteur peut être
géré dans le modèle de données et mis à jour pour chaque incrément. Le
choix de gérer ou non ce compteur revient en premier lieu à l'utilisateur.
Calcul issu d'une équation : le calcul du montant d'une facture avec TVA fait
appel au modèle suivant. La facture concerne un à N produits (lignes de
facture). Chaque produit est assujetti à un régime de TVA.
FACTURE
1,1 1,N numéro fac ture
LIGNE DE
FACTURE
PRODUIT TVA
numéro ligne
1,1 0,N 1,1 0,N
de fac ture c ode produit c ode TVA
quantité facturée conc erner prix produit HT taux TVA
Le MOD de la ligne de facture...
N FACTURE
LIGNE DE
FACTURE numéro fac ture
1
numéro ligne
de fac ture N PRODUIT 1 TVA
quantité fac turée c ode produit c ode TVA
1 prix produit HT taux TVA
...se transforme en MLD comprenant 4 enregistrements et 5 chemins.

Les trois informations résultats de règles de calcul peuvent être "placés"
dans le modèle logique de données.
taux TVA du produit
prix produit HT
c ode produit montant hors taxe ligne de fac ture montant avec tva
quantité facturée ligne de fac ture
CALCUL MONTANT CALCUL MONTANT CALCUL MONTANT

HORS TAXE AVEC TVA FACTURE AVEC TVA
montant avec tva montant avec tva

ligne de fac ture fac ture
montant hors taxe ligne de fac ture
Les informations en sortie de 3 règles de calcul...

Trois règles correspondent à ce calcul. La première calcule le "montant hors
taxe de la ligne de facture" en multipliant le prix unitaire hors taxe par la
quantité facturée. La deuxième calcule le "montant TVA incluse" en utilisant
le taux de TVA applicable au produit. La troisième calcule le "montant avec
TVA" de la facture.
LIGNE DE N FACTURE
FACTURE numéro fac ture
numéro ligne montant avec tva
de fac ture 1 facture
quantité fac turée
N
montant avec tva PRODUIT
ligne de facture 1 TVA
c ode produit
prix produit HT c ode TVA
montant hors taxe
taux TVA
ligne de facture 1
...sont redondées dans le MLD.

Une autre redondance ou une autre règle de calcul aurait pu être choisie ; le
prix unitaire par produit avec TVA par exemple.
Questions : vrai ou faux ?

1. Un enregistrement logique contient toujours des informations.
2. L'information identifiant un individu peut être une clé de l'enregistrement
issu de l'individu.
3. Une patte peut se transformer en chemin.
4. Un chemin provient obligatoirement d'une patte.
5. La clé d'un enregistrement peut se décomposer en plusieurs informations
élémentaires.
6. Les informations hypothèses et les informations résultats d'un même
calcul peuvent être mémorisées dans un MLD.
7. Les informations hypothèses et les informations résultats d'un même
calcul peuvent être mémorisées dans un MCD ou un MOD.
8. Le MLD dépend du matériel informatique de l'entreprise.
9. Un MLD non optimisé peut être construit à partir d'un MOD et de règles.
EXERCICE SUR LE MLD :
Dessiner le MLD à partir du MOD suivant,
OUVRAGE 0,N 1,1 EXEMPLAIRE

de
0,N 0,N
AUTEUR prêter 1,N PRET
éc rire
date de retour
1,N
2 MODELE LOGIQUE DE TRAITEMENT

Le modèle logique de traitement suit le modèle organisationnel de
traitement. Celui-ci comprend les opérations effectuées par des postes de
travail. A chaque opération organisée sont associés un ou plusieurs outils
informatiques. Le modèle logique de traitement comprend la partie visible,
la spécification externe des transactions informatiques, le cheminement
possible d'écran à écran après un menu principal
saisie facture
toujours
saisie ligne de facture

toujours
MLT saisie des factures

et la partie non visible, interne, lectures et actions d'écritures
d'informations dans le modèle logique de données.
2.1 Opération organisée et outils informatiques

L'outil est le moyen, AVEC QUOI ?, mis à disposition de l'utilisateur pour
effectuer une ou des opérations organisées.
Je peux aller au cinéma à vélomoteur, en voiture ou prendre l'avion pour

aller à Hollywood. C'est l'arrivée de l'homo habilis, l'homme sachant se
servir d'outils. De même, l'outil utilisateur sera un traitement de texte ou un
programme spécifique sur tableur. Les outils les plus simples sont la gomme
et le crayon.
Chaque opération organisée s'automatise plus ou moins. Le plus correspond
à une automatisation liée à l'informatique, le moins correspond à une phase
non automatisable, peu rentable ou de pure décision. Les choix
d'automatisation sont liés au gain de temps (traitement d'un plus grand
nombre de dossiers par une même personne ou temps de séjour du dossier
plus court dans l'entreprise) ou à une amélioration des conditions de travail
(recopie inutile d'un dossier). Divers outils (informatiques) sont conçus par
procédure et répondent à une ou plusieurs opérations organisées de cette
procédure.
Exemple d'outils pour réaliser l'opération organisée "prise en compte de la
commande" : interrogation du client, interrogation du stock de produit,
enregistrement de la commande.
Les outils sont des aides et non un découpage de l'opération en sous-
opérations ou tâches.
Si l'opération concerne un voyage de Paris à Marseille, les différentes
étapes de Paris à Lyon, de Lyon à Marseille s'effectuent à l'aide d'un même
outil, une voiture. La voiture n'est pas une partie de voyage.
Chaque opération peut être effectuée à l'aide d'un ou plusieurs outils.
Réciproquement, un outil peut servir à plusieurs opérations. La voiture
sert à aller au cinéma et les lunettes stéréoscopiques à regarder le film en
relief. Ces deux outils peuvent me servir pour aller travailler ou pour lire.
1 opération Regarder la télévision
2 outils
 
une OPERATION peut être exécutée avec DEUX OUTILS
L'outil est une notion utilisateur. Un couteau suisse est un exemple
d'outil. Il en existe en plusieurs tailles et avec un nombre de lames différent.
Le choix dépend de la taille de la main, de celle de la poche ou du prix que
l'on veut y consacrer.
La définition des outils peut se faire par procédure. Porter une attention
particulière à la première opération à réception d'un message. Un outil de
consultation ou de mise à jour peut être utilisé par le partenaire émetteur
du message !
2.2 Outils informatiques

Dans la pratique, l'outil est informatique et peut être de deux types :
transactionnel ou interactif , traitement immédiat ou "en temps réel" ou en
traitement différé ou par lot , calcul sans intervention directe de l'utilisateur.
Dans le deuxième cas, le programme s'enclenche et effectue ses calculs et
ses mises à jour éventuelles sur les données à un moment prédéterminé.
CLIENT VENDEUR MAGASINIER
Commande de coke
PRISE DE COMMANDE
Pas de C oke en stock C oke en stock
Proposition De Produit Ordre De Livraison

De Substitution
Ordre De
Une opération organisée d'un poste de travail...

Exemple d'outils d'une opération organisée de prise de commande: le
choix répond au besoin d'interrogation du stock et de création de l'ordre de
livraison. La prise de la commande peut être exécutée par (presque) une
infinité d'outils.
Solution A - Un seul outil pour tout faire.
Interrogation du stock, création de l'ordre de livraison, consultation des
délais de réapprovisionnement, consultation des goûts du client pour
connaître sa catégorie (pressés ou non), recherche des produits de
substitution pour livraison immédiate ou annonce du délai de livraison
acceptable. Comme vous pouvez le constater, cet outil fait tout, papa et
maman.
A - PAPA
B - MAMAN
peut être effectuée à l'aide d'UN SEUL OUTIL...

Solution B - Deux outils
1. Interrogation du stock
2. Création de l'ordre de livraison (outil d'édition)
INTERROGATION IMPRESSION
DES STOCKS DES ORDRES
DE LIVRAISON
... ou DE PLUSIEURS OUTILS...

C - A vous de l'inventer :
2ème exemple d'outils

Un tire-bouchon à droite, à gauche ou à air comprimé sont 3 outils.
3ème exemple, l'infocentre est un outil d'interrogation des données de
l'entreprise par un langage simple d'emploi. Il est considéré comme un outil
pouvant s'appliquer à des opérations de prise de décision.
2.3 Outil interactif

Un outil interactif permet un dialogue entre l'utilisateur et l'ordinateur via
un écran et un clavier. Il comprend des écrans se succédant où l'utilisateur
tape des informations ou des commandes au clavier et obtient
immédiatement la réponse. Il enchaîne les traitements sans arrêt.
2.3.1 La vue utilisateur : la spécification externe des outils.
Un état est une étape d'un outil informatique, un ensemble d'informations
affichées et prêt à recevoir des informations (à saisir). Un "masque" d'écran
peut servir à plusieurs états.
Le dessin des états, des écrans de saisie (et d'affichage) des infor-
mations, et de leur enchaînement est proposé par ou à l'utilisateur final. Le
"masque" des états, le dessin ou le support des écrans, peut servir pour
plusieurs états, mais, en règle générale, états de saisie et d'interrogation
des enregistrements sont différents.
Il est important de valider la liste des outils avec l'utilisateur final et le
responsable informatique qui suivra la réalisation pour ne pas voir
apparaître de nouveaux outils en cours de validation.
Exemple d'état et de support : soit un outil d'interrogation des fils en
fonction du nom du père. Sur le premier état est saisi le nom du père. Le
deuxième état affiche le nom du père saisi dans l'état précédent (grenouille
dans l'exemple) et les noms des fils (corbeau, écureuil ou taureau).
Père : -------- Père : grenouille
Fils : -------- Fils : corbeau

-------- écureuil
-------- taureau
L'information "nom du père" est saisie sur un 1er état

Les informations sont affichées dans un 2ème état.
Ces deux états (saisie du père et affichage des fils) possèdent le même
support (les références viennent du bébête show).
Père : nom du père
Fils : nom du fils

nom du fils
nom du fils
Les deux états ont le même support

L'enchaînement des états de l'outil est le suivant :
1er Etat Saisie du père
2ème Etat Affichage des Fils
MLT de l'outil : interrogation des fils

Le passage du premier état au deuxième se fait à condition que le père
existe et qu'il ait des fils.
Un MLT peut être plus compliqué et débuter par un menu des états :
menu
Enchaînement
Des États delar soeur
addition
MLT d'outil
Les états et leur enchaînement doivent être approuvés par l'utilisateur final
avant de commencer la programmation. Ainsi, l'utilisateur final peut
changer d'avis sur la "tête" des états et de leur enchaînement sans
remettre en question la programmation.
2.3.2 Que devient la représentation repliée en "caractéristique"
"type de" et "valeur" ?
La représentation d'une partie du modèle conceptuel de données replié -
où des individus deviennent des occurrences d'un individu "type de..." -
implique la création d'écrans banalisés, non spécifique des occurrences.
Le modèle comprend les individus "type de..." "contrat" et
"caractéristique" et les relations "posséder" porteuses de l’information
"valeur", "type de contrat" et "autoriser".
C ONTRAT TY PE DE C ONTRAT
1,1 0,N
type contrat
1,N 1,N
autoriser
posséder
C ARAC TERISTIQUE DU C ONTRAT
valeur
0,N 0,N
Les états de saisie et de restitution de ces valeurs ne peuvent donner lieu

à des zones de saisie spécifiques de chaque caractéristique. Toutes les
caractéristiques devront être saisies suivant un même masque, en colonnes
"caractéristique" et "valeur".
Si l'état de saisie est différent d'une présentation en colonnes
"caractéristique" et "valeur", le modèle conceptuel doit être déplié
L'informatique ne peut pas gérer des présentations d'informations spé-

cifiques de chaque occurrence.
CONTRAT AAAA TYPE DE CONTRAT AA SAISIE DES CARACTERISTIQUES
aaa : sssss aaa : sssss

Caractéristiques Valeur
---------------- ------
---------------- ------ aaaa : sssss aa : sssss
---------------- ------
---------------- ------
aaa : sssss aa : sssss aa : sssss
---------------- ------
---------------- ------
VALIDER : O/N
Ecran en colonnes ou spécifique de chaque occurrence.

Exemple : un cas où se pose le bien-fondé de la décomposition fine est le
cas de saisie de paramètres d'un équipement (par exemple hauteur,
largeur, épaisseur du chapeau, nombre de pieds...). Ces renseignements
sont purement indicatifs et ne serviront qu'en consultation. Une
représentation concentrée en EQUIPEMENT, TYPE D'EQUIPEMENT et
PARAMETRE ne permet pas de concevoir un écran de saisie avec passage du
curseur sur chaque paramètre après son libellé explicatif. Les
caractéristiques doivent être identifiées. Chaque aaa représente des
caractères affichés : nombre de pieds, épaisseur etc et chaque sss
représente l'information saisie : 4, 3 mm etc..
2.3.3 Standards de développement
Des "standards" de développement des outils sont fixés en début de
spécification. Voici les principaux :
- un macro-outil, appelé moniteur de transaction, permet de passer d'un
outil à un autre, d'un outil de saisie à un outil d'interrogation. Son existence
conditionne la conception des outils transactionnels.
Voici l'exemple d'un outil de création des fils de père s'adressant à un outil
de consultation des pères. Le premier état de l'outil de saisie des fils saisit
le numéro de père. A partir de cet état, pour aider l'utilisateur ne
connaissant pas les numéros de père, l'état de consultation des numéros de
père et de leur nom peut être appelé directement. Ainsi, le numéro de père
pourra être connu et quelquefois rapporté directement au premier état.
NO PERE : PERE :
no père nom du père
FILS : nom du fils no père nom du père
no père nom du père
nom du fils
nom du fils no père nom du père
1ER ETAT : saisie des numéros de Père

CONSULTATION DES PERES
de l'OUTIL : SAISIE DES FILS
- action des touches fonctions nommées souvent F1, F2... sur les claviers.
Exemples : F1 menu précédent, F2 interrogation des occurrences de la zone,
F3 touche d'aide de l'écran ou de l'information, F4 retour au menu principal,
F5 pagination avant, F6 pagination arrière...
- dessin de grille standard avec réservation de zones pour l'affichage de la
date, du numéro de transaction actuelle, des messages d'erreur, des aides
sur chaque information ou sur l'écran ou saisie du numéro de transaction où

l'on veut accéder directement...
Date Nom de l'outil Transac tion

S ouhaitée
Messages
Zones réservées.
- conception générale d'un outil - création, modification, suppression dans
un menu ou code à saisir dans les lignes d'un état.
- créer Ligne de commande

C ________________
- supprimer
S ________________
M ________________
- modifier
I ________________
________________
- interroger
Comment créer, supprimer...

- Comment passe-t-on d'un état à l'autre en cas d'enregistrement de MLD
"dépendant" ? Quand le nombre de fils dépasse un certain nombre, passe-t-
on à un état suivant ou sont-ils sur le même état ?
Exemple : saisie des familles. L'outil à développer doit permettre la saisie
de familles, du père, de la mère (nom, prénom) et des enfants, (leur sexe,
prénom et date de naissance).
Solution 1 : 1er état, saisie des informations des parents et deuxième état,
saisie des informations des enfants.
Solution 2 : 1er état, saisie des informations des parents et saisie des
informations de 5 enfants. Si la famille a plus de 5 enfants, valider, repasser
sur le même état et rajouter des enfants.
Solution 3 : 1er état, menu principal, plus ou moins de 5 enfants. Deuxième
état, saisie des informations des parents et des enfants des familles de
moins de 5 enfants et troisième état, saisie des informations des familles de
plus de 5 enfants.
- type de libellé des messages d'erreur issus de contraintes sur les
informations de l'état, abréviations ou libellé des informations. Les
messages d'erreur sont-ils gérés dans le modèle de données ? en anglais ?
- type de validation. Se sert-on d'une touche fonction pour valider ou doit-
on répondre au message Validation Oui/Non ?
2.3.4 De nouvelles informations apparaissent.
Les informations telles que code action (suppression, création...),
enregistrement suivant, numéro de transaction suivante apparaissent dans
des proportions importantes (facteur 1,5). Ces informations ne
correspondent à rien dans le modèle de données. Elles sont des aides pour
l'utilisateur.
Les informations aval équivalentes (donneur d'ordre, c'est-à-dire "numéro

de client ayant commandé" est en aval de "numéro client") réapparaissent
dans les spécifications. Il faut les utiliser afin de lever les éventuelles
ambiguïtés.
2.3.5 Le traitement des données : la spécification interne des outils
De chaque état, une ou plusieurs action(s) de mise à jour, de modification
ou de suppression d'occurrence d'information ou d’enregistrement peut
exister. La spécification interne consiste à déclarer les actions et l'obtention
des informations :
 affichées dans chacun des états suivants
 concernées par une action sur les informations d'un enregistrement
 faisant partie d'une condition de passage de cet état vers un des
suivants.
Elles sont obtenues à partir des informations connues dans le premier état -
les informations affichées et saisies - et au moyen de :
 une règle de calcul
 la clé d'un enregistrement (qui donne accès à toutes les informations de
l'enregistrement)
 un chemin d'accès
Exemple : l'outil concerne l'interrogation des fils d'un père. Le premier état
saisit un numéro de père. Si celui-ci n'existe pas, l'état suivant est la
création d'un père. A partir de cet état, une occurrence de l'enregistrement
père est créée. Si celui-ci existe, l'état suivant affiche les fils, leur prénom et
leur date de naissance.
Saisie du numéro de père

1er Etat
le numéro n'existe pas le numéro existe
Création du Père Affichage des Fils
Les informations dont l'obtention doit être déclarée sont :

 prénom du fils, date de naissance du fils qui sont des informations
affichées dans l'état "affichage des fils" et non saisies dans l'état "saisie
du numéro de père". Elles sont obtenues via le chemin allant du numéro
de père vers les numéros de fils.
 numéro de père est une information non saisie sur l'état création du père
et à créer dans le MLD à partir de l'action création du père. Cette action
s'effectue à partir de cet état. Cette information "numéro de père" est le
numéro saisi dans l'état "saisie du numéro de père" ou un numéro
résultat de la règle de calcul "nouvel abonné" qui consiste à ajouter 1 au
dernier inscrit.
L'utilisateur valide une partie des spécifications internes, les modifications
possibles des informations d'enregistrement.
Le concepteur, qui n'a alors de concepteur que le nom, doit effectuer un
travail astreignant dont il importe de comprendre l'utilité avant de se lancer
dans l'aventure. Si un générateur d'application, c'est-à-dire un outil de
génération de programme à partir de "macro-commandes" est ou doit être
utilisé, veillez aux réutilisations possibles.
Il existe deux conceptions d'outils :
- une conception "mono-enregistrement" ou données où un outil sert à la

modification, la création et la suppression d'une occurrence d'un même
enregistrement et des chemins alentour. Cette première conception est
simple à programmer et demande une adaptation de l'utilisateur. Celui-ci
pourra comprendre toutes les applications.
Dans ce cas, il existe 5 outils par individu (création, modification,
suppression, consultation et recherche à partir des informations de
l'individu) et un certain nombre d'outil de recherche d'occurrence d'individu
dont le maximum est le nombre de chemins, donc le nombre de pattes de
relation. Les outils sont alors créés à partir des MOD. Certains pourraient
parler de conception orientée "objet" ou individu.
Si l'outil précédemment décrit sert à la création des fils, de l'état création
du père, un enchaînement est possible vers l'outil création du fils. Cette
conception est mono-enregistrement : un seul enregistrement "Père" ou
"fils" est mis à jour.
Création du Père
Création des Fils
Un enregistrement par état.

- une conception "multi-enregistrements" ou traitements où un état sert à
plusieurs enregistrements et évite à l'utilisateur de paginer plusieurs états
avant de consulter ou de saisir l'information souhaitée. Cette deuxième
conception est plus courante pour les utilisateurs (approche traitements).
Les outils sont créés à partir des MOT.
NO PERE : SSSS Nom SSSSSSS

Date de naissance SS SS SS
FILS : prénom du fils date de naissance

sssssssssss ss ss ss
Création du père et des fils.

Exemple de l'état saisie du père et des fils : les occurrences des fils peuvent
être créées à partir de l'état création du père.
2.4 Outil en traitement différé.

Rappelons que les applications de ce type d'outil sont les enclenchements
automatiques tels que les éditions ou les longs calculs à effectuer la nuit
quand l'ordinateur "n'est pas chargé". Ces outils sont très difficiles à
identifier par une approche des outils du type MOD.
Dans ce type d'outil, l'utilisateur final n'attend pas de réponse im-
médiate de l'informatique. L'outil est lancé automatiquement et exé-cute
les calculs, les mises à jour des données ou les impressions demandées.
Un traitement en temps différé peut être décrit en un ensemble de

programmes ou de sous-programmes exécutant des règles de calcul et des
actions de mise à jour des bases de données. Notre objet n'étant pas de
décrire les aides de programmation, ce sujet est volontairement laissé de
côté.
Exercice MINITEL : Recherche (simplifiée) d'un numéro de téléphone.
Dessiner le MLT et les informations du premier état.
3 MODELE LOGIQUE DE COMMUNICATION
Les messages échangés entre site et base de données sont répertoriés et

fixés. Il serviront de référence aux échanges d'informations entre outils lors
de l'étude détaillée. Il s'agit des messages passant dans les "pipe-lines"
informatiques.
Le modèle logique de communication provient du MLD et de l'utilisation
des outils en temps différé.
Exemple : cas de réparation locale, régionale et nationale exposé au
niveau organisationnel.
1er Cas Centralisation totale : pas de message échangé.
Base De Données
Centralisée
MLC 1
2ème Cas Centralisation nationale : les messages échangés entre bases
sont :
Demande de réparation nationale

Base De Données Bases De Données
Refus de réparation nationale
Nationale Régionale et Locale
MLC 2
3ème Cas Décentralisation totale : tous les messages recensés sur la
procédure seront à transmettre d'une base à l'autre.
Base De Données Base De Données

Nationale Régionale
Base De Données
Locale
MLC 3
4 VALIDATION DONNEES/TRAITEMENT.
4.1 Validation MOD / outils.

Tout individu, relation ou information d'un MOD est créé et consulté par un
outil. Sinon, soit un outil existant ou à créer doit le faire, soit l'individu, la
relation ou l'information est inutilement géré.
Ensuite, cette liste d'outils est comparée avec les outils existants.
L'informatique future doit au moins couvrir les traitements existants à
conserver.
Apparaissent des outils "techniques" tels que les outils de création de
références comme la création des individus LIEU, PAYS, DEVISE. Pour ces
outils, un outil standard de création des individus ne comprenant comme
information que l'identifiant et un libellé peut être défini.
Trois ensembles d'outils sont alors à examiner car ils peuvent faire l'objet
d'une approche standard ou être réalisés par un progiciel. Ces outils sont les
outils d'édition (voir les documents du MOD), les outils de sécurité d'accès
(voir les autorisations d'accès du MOD) et les outils d'interface (voir les
types d'anomalie suivant).
Les outils de reprise des données existant dans des fichiers existants sont à
recenser. Un outil en temps différé gérant les transferts entre base de
données peut s'appuyer sur une partie du modèle de données comprenant
un individu intitulé "type d'anomalie".
L'individu TYPE D'ANOMALIE apparaît.
Type d'anomalie provient du chargement de données provenant de base de
données différentes.
Supposons le cas d'une société d'assurance multi-sites. Un site de données
(MOD A) gère des véhicules avec ou sans moteur. Un deuxième site, une
agence, gère uniquement des assurances de voitures (MOD B). De manière
périodique, les voitures de l'agence seront envoyées sur le modèle A. Les
deux modèles A et B peuvent être identiques ou différents, comme sur le
modèle. L'individu en blanc est un autre individu (Propriétaire ou Location).
MOD A MOD B
MOTEUR VEHICULE Transfert VOITURE
Automatique
Un transfert de données entraîne des anomalies...

Les informations transférées entre deux systèmes ne sont pas toujours

cohérentes et des contrôles ont lieu pour assurer la cohérence du système
"receveur". A chaque contrôle peut correspondre un type d'anomalie.
Exemple : les stocks d'équipement sont gérés à travers le monde à fin de
location. Les situations d'équipement telles que "disponible", "en
réparation", "loué"... sont suivies et reçues automatiquement d'un site à un
autre. La cohérence entre les situations successives d'un même équipement
doit être vérifiée pour une base donnée. Un équipement doit être "inspecté"
après avoir été "en réparation". Si une situation équipement "loué" est
reçue pour cet équipement, un type d'anomalie "loué et non inspecté" est
généré.
Cet exemple montre l'intérêt qu'il y a à développer une procédure dans ce
cas. Qui est responsable de la cohérence des situations des équipements ?
Définir l'organisationnel avant le logique.
loué et non inspec té
Loué
10-1-88
TYPE no 2512
D'ANOMALIE
0,N SITUATION SITUATION
RECUE ACTUELLE
provenir 0,1
0,N type situation date début situation
0,N équipement date fin situation
0,1
1,1
existenc e enc ht situation 1,1
existenc e type situation
0,N 0,N
1,1 séquencer réparation 1,N no 2512
existenc e équpt
TYPE EQUIPEMENT
CONTROLE
SITUATION
INTERNE 0,N
... à corriger.
Après cette validation MOD/Outils, la liste des outils est complète.
4.2 Validation MLD / outils

Tout enregistrement, information ou chemin d'un MLD est créé et consulté
par un outil. Cette validation définit quels outils créent ou consultent quelle
information ou quel chemin redondés du MLD optimisé.
La lecture s'effectue grâce à un chemin ou une information
d'enregistrement. La mise à jour s'effectue grâce à un enregistrement.
4.3 Validation des outils par les actions de mise à jour de données
d'enregistrement
Dans le cas où les spécifications comprennent les actions de mise à jour des
informations d'enregistrement, toutes les informations doivent être créées
par une action. Cette action est enclenchée lors d'un état d'outil
transactionnel ou lors d'un outil par lot.
Si une information n'est pas créée, il y a eu erreur sur la validation
précédente. Les vues des MLD définissent le cadre des actions. Dans la
pratique, lorsqu'aucune méthode n'est employée, cette validation est
effectuée après la réalisation.
5 VALIDATION DE L'UTILISATEUR
L'utilisateur valide évidemment les enchaînements d'état par outil. Il peut

également valider les redondances de chemin et d'information et les
suppressions de chemin. Il connaît les informations le plus souvent utilisées.
6 RESUME DU NIVEAU LOGIQUE
Un MLD se déduit de chaque MOD en fonction de règles transformant

individus et relations en enregistrements et chemins. Ensuite chaque MLD
est optimisé en supprimant ou en dupliquant des informations ou des
chemins. Les clés d'enregistrement peuvent être décomposées en clés ou
clé(s) et numéro d'ordre au niveau logique.
Chaque outil informatique "transactionnel" se décrit sous la forme
d'enchaînement d'états (MLT) affichant des informations et prêt à en saisir
d'autres. La spécification externe comprend la description des états et des
informations affichées et saisies approuvée par l'utilisateur final. La
spécification interne comprend la description des actions de création des
informations du MLD (enregistrements, informations et chemins d'accès)
Le MLC recense les messages échangés entre sites de mémorisation. Il
concerne principalement les outils en temps différé.
Plusieurs validations sont possibles au niveau logique MOD/liste des outils,
MLD/liste des outils, actions de mise à jour/liste des outils. La première
validation entre MOD et outils évite de construire le MLD. Elle est impérative
pour l'étape de fin de l'étude préalable.
Enchaînement
Des États État Soeur :
menu
nom soeur
Affiché
delar soeur
nom frère
Saisie
MLT (enchaînement des états) MLT (Etats)
l'état soeur met à jour

l'enregistrement E2.
E1
E2
soeur
E2 E3
E3 les informations affichées dans

l'état delar sont obtenues par
le chemin de E3 vers E2.
E2
delar
E3
MODELE LOGIQUE DE DONNEES SPECIFICATION INTERNE

C'est fini. C'est dommage,

Vous pouvez
la secrétaire du responsable
répéter le menu ?
utilisateur était sympa
Attention,
Ca y est, c'est fini.
les zéros et les uns
vont bientôt passer.
Responsable
P.D.G M. MERISE Informaticien
Utilisateur
COMITE DE VALIDATION DU NIVEAU LOGIQUE

CHAPITRE IV LE NIVEAU PHYSIQUE
Sans peau, où pousseraient les poils ?

(Proverbe chinois)
Le dernier niveau de la méthode, le niveau physique, représente le résultat

informatique. Il dépend des logiciels de développement nécessaires à la
programmation et à la manipulation des données. La méthode laisse place
aux normes du réel. En l'état de l'art, on arrive assez facilement à déduire
du MCD, MOD des structures de SGBD ou, à partir d'un dessin d'écran, des
programmes transactionnels. Remarquons la faiblesse des investissements
en matière de modèles de communication. L'hétérogénéité des systèmes,
en l'attente de normes internationales, pèse sur les automatismes de
production du MPC.
Le modèle logique de données représente la future base de données, le
contenant des informations. Trois types de logiciel - de Système de Gestion
de Base de Données (SGBD) - permettant de créer, modifier ou consulter
des informations, existent actuellement : hiérarchique, navigationnel ou
réseau et relationnel. Les passages des modèles organisationnels aux
modèles navigationnel ou relationnel sont explicités dans ce chapitre. Le
passage d'un MOD ou MLD à un modèle de SGBD hiérar chique n'est pas
automatisable. Les SGBD relationnels doivent respecter certaines conditions
(Règles de Codd) ainsi que leurs enregistrements (Normalisations).
Le modèle physique de traitement comprend les programmes informatiques
et leur environnement d'exploitation, moniteurs temps réel, traitement par
lot, temps partagé... Aucune représentation n'est spécifique de MERISE et
ne sera développée.
Le modèle physique de communication comprend la télématique entre site
informatique, les techniques de transmission de données entre applications.
Aucune représentation n'est spécifique de MERISE et ne sera aussi
développée.
1 MODELE PHYSIQUE DE DONNEES.
Le modèle physique de données est un modèle de la base de données.

L'implantation physique, la topographie des enregistrements informatiques
ne sont pas définies. Trois systèmes de gestion de base de données, les
modèles hiérarchiques, navigationnels et relationnels servent de modèles.
Le choix du type de SGBD effectué, deux questions se posent : comment
retrouver physiquement un chemin logique, par une information ou par un
lien physique ? Faut-il éclater ou regrouper certains enregistrements afin
d'accélérer les traitements ?
1.1 Information ou lien.

Un chemin indique le moyen d'arriver à une information à partir d'une
information de départ. Deux moyens existent, en informatique, pour
retrouver cette information, soit connaître son adresse ou sa position
"physique" dans un fichier informatique, soit connaître sa valeur. Connaître
son adresse consiste à conserver un chemin "physique", un lien. Connaître
sa valeur consiste à dupliquer l'information. Un lien physique n'existe
qu'entre enregistrements physiques.
Lien
CLIENT COMMANDE
adresse mémoire
du c lient
Un lien permet de connaître l'adresse de la clé.
CLIENT COMMANDE
Numéro Client No Commande
Numéro Client
Dupliquer la clé permet de connaître sa valeur

Si l'adresse du numéro de client existe dans l'enregistrement commande, le
numéro de client peut être modifié dans l'enregistrement client sans
affecter le donneur d'ordre de la commande. Son adresse reste la même. Si
son numéro est dans l'enregistrement commande, en modifiant la valeur de
ce numéro dans l'enregistrement client, la commande ne sera plus reliée au
bon numéro, donc au bon client.
Les modèles hiérarchiques gèrent des informations et des adresses
d'information, les pointeurs, le modèle relationnel gère des informations.
1.2 SGBD hiérarchique

Ce SGBD est le premier apparu. Il stocke les données sous l'aspect d'un
arbre généalogique où un fils n'a qu'un père et tout le monde est père
et/ou fils. Ce modèle est un ensemble de "noyaux" de famille où l'un peut
être père dans l'une et fils dans l'autre. Chaque fils possède l'adresse de son
père.
Père 1
Fils 1 Fils 2
Petit-Fils 2 Petit-Neveu 2
Petit-Fils 1 Petit-Neveu 1
occurrences d'un SGBD HIERARCHIQUE

Le modèle des fichiers hiérarchiques se présente sous la forme
d'enregistrements reliés par des liens dont la flèche va de l'amont vers
l'aval : du père aux N fils, du fils aux N petits-fils, du fils aux N petits-
neveux.
Lien
Enregistrement
PERE FILS
PETIT PETIT
FILS NEVEU
Nomenclature HIERARCHIQUE : enregistrements et liens

Pour accéder aux petits-neveux, il faut accéder à la bonne occurrence de
père, puis à la bonne occurrence de fils. La clé de l'enregistrement Fils est la
composition des clés du Père et du Fils. La clé de l'enregistrement Petit-
Neveu est la composition des clés du Père, du Fils et du Petit-Neveu.
Clé
Père Fils Petit-Neveu
Petit-Neveu
Clé
Père Fils
Fils
Les clés sont composées.

Le passage du modèle organisationnel ou logique de données à un modèle
hiérarchique n'est pas automatique. Dans le cas de relation 0,N 0,N ,telle
que la relation "écrire" entre auteur et livre, entre deux individus ou de
deux chemins d'arrivée à N informations, les deux liens doivent exister. Un
lien relie le premier enregistrement au deuxième et un autre du deuxième
vers le premier.
LIVRE AUTEUR
Père ou Propriétaire Père ou Propriétaire
AUTEUR LIVRE
Fils ou Membre Fils ou Membre
Gestion des liens "auteur de livre" et "livre d'auteur"

Ce modèle, de par sa contrainte pour un enregistrement de n'avoir qu'un
seul lien de "filiation", n'est pas recommandé.
1.3 SGBD navigationnel ou réseau

Ce type de SGBD est actuellement le plus répandu et a fait l'objet de
normalisation dans le cadre d'un groupe de travail nommé CODASYL. La
différence essentielle avec le SGBD de type hiérarchique est qu'un en-
registrement Fils ou Membre peut avoir plusieurs enregistrements Pères ou
Propriétaires.
PERE
Père Propriétaire
Lien
FILS
Membre
Aîné Frère Frère Benjamicrobe
SGBD RESEAU : occurrences, enregistrements et liens

Dans ce modèle, le père a l'adresse du premier fils. Chaque fils a l'adresse
du frère qui le suit et de celle de son père dans une famille. Le dernier frère,
en queue du peloton, a l'adresse de son père.
Le chemin (d'adresse) d'un père vers ses N fils est appelé lien, comme en
hiérarchique.
FAMILLE FAMILLE
FILS
1 2
Un fils peut appartenir à plusieurs familles.

Des règles de transformations du modèle logique ou du formalisme
individu/relation en enregistrement et lien ont été édictées. Les règles
diffèrent suivant le cas des individus, des relations binaires (à deux pattes)
non porteuses d'informations de cardinalité maximale à un, des autres
relations binaires et des relations non binaires sont explicitées. Le cas
MLD/MPD est vu en premier et le second cas est le passage direct du MCD
ou du MOD vers le MPD.
Règles de transformation du modèle logique vers le modèle réseau :
1) Tout enregistrement logique devient un enregistrement physique.
2) 2 chemins à N arrivées entre 2 enregistrements logiques deviennent un
enregistrement physique et 2 liens.
Enregistrement N Enregistrement
logique logique
N
MLD
Enregistrement Enregistrement
Enregistrement
physique physique
physique
MPD Réseau
3) Les autres chemins à N arrivées entre 2 enregistrements logiques
deviennent un lien.
Règles de transformation du modèle individu/relation vers le modèle réseau
1) Tout individu devient un enregistrement
INDIVIDU ENREGISTREMENT
2) Toute relation non porteuse d'informations ayant une cardinalité

maximale à 1 : 0,1-0,N, 1,1-0,N, 0,1-1,N, 1,1-1,N se transforme en lien. Le
lien mémorise les deux chemins à 1 arrivée et N arrivées du niveau logique.
,1
Une relation X,N donne un lien. La flèche change de sens.

3) Les autres relations binaires se transforment en un enregistrement et
deux liens. L'enregistrement dérivé de la relation contient les adresses des
clés des enregistrements issus des individus et les informations
éventuellement portées par la relation.
,N ,N
Une relation NN donne 1 enregistrement et 2 liens.

Remarque : une relation non porteuse d'informations dont les cardinalités
maximales sont N se transforme en un enregistrement alors qu'au niveau
logique, cette relation ne donnait pas lieu à un enregistrement, mais à deux
chemins. Les deux chemins menant à N informations du niveau logique se
transforment en 1 enregistrement et 2 liens. Cet enregistrement ne contient
que des adresses d'informations.
4) Les relations non binaires, N-aires (N = nombre de pattes) se
transforment en 1 enregistrement et N liens. L'enregistrement final contient
les adresses des autres enregistrements et les informations éventuelles de
la relation.
Exemple de 3 pattes :
Une relation à 3 pattes se transforme en

1 enregistrement et 3 liens
La mise en place de telles structures de données influe notablement sur les
performances. Il vaut mieux ne mettre en place qu'un ou deux liens et
traiter le troisième chemin en lecture séquentielle.
1.4 SGBD relationnel

Ce type de SGBD se développe de plus en plus. C'est pourquoi il est plus
approfondi. Comme il ne gère pas d'adresse ou de lien, son for malisme est
plus facile à comprendre.
Dans un modèle relationnel, tous les enregistrements sont composés
d'informations et il n'existe pas d'adresse d'informations, de pointeurs ou
de liens connus de l'utilisateur. Toutes les informations peuvent être
accédées indépendamment de leur adresse. Il n'est pas nécessaire de
déclarer des fichiers ouverts, de passer à l'occurrence d'enregistrement
suivant pour mettre à jour une information.
Fils
Père
Pas de lien en relationnel.

Un langage normalisé de création et d'interrogation des enregistrements et
des informations existe pour tout SGBD relationnel. Il est appelé SQL pour
Structured Query Language. Ce langage permet à un utilisateur final
d'interroger, après une formation préalable, toutes les informations de la
base de données. Cette recherche d'information peut être menée de toutes
les manières possibles, même celles non prévues par des programmes
informatiques. Il est possible de rechercher toutes les personnes dont le
grand-père est né un jeudi ou dont la fortune est égale à leur poids en
grammes. Ce langage permet aussi de mettre à jour, lire ou modifier
facilement toutes les informations. (Référence 4).
1.4.1 Au Tableau !
Un enregistrement d'un SGBD relationnel est appelé relation ou table. Ces
relations n'ont rien à voir de près avec les relations du modèle de données.
Le modèle est appelé relationnel car l'établissement d'une navigation entre
deux enregistrements nécessite la mise en relation, à valeurs égales,
d'informations d'enregistrements. Table ou tableau sont les termes les plus
simples spécifiques des SGBD relationnels. Les colonnes d'une table sont les
informations et les lignes les occurrences d'enregistrement, les ensembles
d'occurrences d'information.
Exemple : Père et fils sont des tables à deux dimensions ou des matrices. La
table PERE comprend comme colonnes : numéro du père, nom de famille,
prénom, date de naissance, etc.. Une ligne de cette table est constituée des
occurrences d'information d'une occurrence de Père : 44, Charles, Jacques, 6
Septembre 1950.
PERE
Lignes = numéro nom prénom date
Occurrence père famille père naissance
d'enregistrement C harles Jacques
44 6-9-50
Colonnes =
Informations
Certaines colonnes peuvent ne pas avoir de sens pour toutes les lignes
(occurrences) de la table. Par exemple, une colonne de la table père peut
être "prénom de l'épouse". Dans ce cas, les valeurs de ce prénom pour les
pères célibataires n'existent pas, sont vides de sens.
Le tableau FILS comprendra comme colonnes : prénom du fils, ordre
d'apparition dans la famille, numéro du père... Une ligne de ce tableau sera
composée des occurrences d'information d'une occurrence de Fils : 252,
Romain, 2ème, 44.
FILS
numéro prénom ordre numéro
fils fils famille père
252 Romain 2 44
Tableau "FILS"
Définition de la contrainte d'intégrité référentielle. En déclarant
l'information "numéro de père" dans la table fils comme dépendante de
l'information "numéro de père" dans la table père, la valeur du numéro de
père dans la table père doit exister avant la valeur numéro de père dans la
table fils. La référence du père (du fils) se trouve dans la table père. 44 ne
peut être enregistré dans le tableau FILS que si le Père 44 existe dans le
tableau PERE.
1.4.2 A l'Index !
Toute colonne d'un tableau relationnel peut faire l'objet d'accès pour
rechercher une ou des lignes (à l'aide du langage SQL en particulier). Les
colonnes d'un tableau, les informations, peuvent être déclarées comme
critère d'accès accéléré ou colonne indexée. La plupart du temps, ces
colonnes indexées proviennent des chemins retenus au niveau logique.
La colonne numéro de père peut être indexée dans la table du fils et
conserve ainsi le chemin du Père vers ses fils.
Chaque table peut posséder une clé permettant d'accéder à la bonne ligne.
Cette clé est déclarée comme "index unique". Deux pères ne peuvent
posséder le même numéro, la même clé. Un index unique peut être la

composition de plusieurs colonnes.
Exemple : le tableau "père" comprendra la colonne index unique "numéro
du père", la colonne index "nom", la colonne index "prénom père" si je veux
souhaiter les fêtes et retrouver tous les pères ayant le même prénom d'une
manière accélérée.
Index Index
Unique
numéro nom prénom date
père famille père naissance
L'index unique du tableau PERE peut être la composition des infor mations
sexe, année de naissance, mois de naissance, numéro de département de
naissance, numéro d'ordre de naissance dans la commune et le
département. Aucune information "composante" ne peut être vide pour une
ligne de table. Vous venez d'apprendre la deuxième contrainte en
relationnel, la "Contrainte d'intégrité sur la clé".
Index Unique
nom prénom
sexe, année de naissance, mois, numéro de département, ...
famille père
Il faut déclarer si une colonne de l'index unique doit être indexée. Veut-on
souvent trier les pères d'après l'année de naissance ?
1.4.3 Passage du MLD vers le MPD relationnel.
1) Tout enregistrement logique devient une table.
2) 2 chemins à N arrivées entre 2 enregistrements logiques deviennent trois
tables. Deux chemins logiques provenant d'une relation binaire X,N, X,N
non porteuse d'informations se transforment donc en une table.
Enregistrement N Enregistrement
logique 1 logique 2
clé1 N clé2
MLD
Table 1 Table 3 Table 2
clé1 clé1, clé2 clé2
MPD relationnel
3) 1 chemin à 1 arrivée entre 2 enregistrements logiques redonde une clé, à
indexer le plus souvent, dans la table de départ.
Enregistrement 1 Enregistrement
logique 1 logique 2
clé1 N clé2
MLD
Table 1 Table 2
clé1 clé2 clé2
MPD relationnel
1.4.4 Passage du MOD vers le MPD relationnel.
Le passage du modèle individu/relation au modèle relationnel consiste à
créer des tables provenant d'individus, des tables provenant de relations et
de répéter ou migrer les identifiants ou les clés de table dans d'autres
tables. Les redondances d'information ou de chemin du MLD sont reprises
plus tard.
Création de table :
Chaque individu se transforme en table,
INDIVIDU TABLE
Un individu se transforme en table.
,N ,N
identifiant 1 identifiant 2
identifiant 1 identifiant 1, identifiant 2 identifiant 2
Une relation NN se transforme en table.

ainsi que chaque relation (X,N),(X,N). La clé, index unique, de la table
provenant de la relation, est la composition des clés ou des identifiants des
individus. Une table est aussi créée si la relation relie plus de deux
individus. Elle contiendra les informations éventuelles de la relation.
Si deux chemins ont été conservés au niveau logique, les deux informations
de la table "relation" sont candidates à l'indexation.
Migration d'informations
Une cardinalité maximale à 1 d'une patte de relation binaire entraîne la
duplication de l'identifiant d'un individu dans la table issue de l'autre
individu.
,1
identifiant 1 identifiant 2
identifiant 1 identifiant 2 identifiant 2
Une relation X,1 entraîne la migration de l'identifiant

Le deuxième chemin, de l'identifiant 2 vers l'identifiant 1, est conservé en
indexant l'identifiant 2 dans la table 1.
Dans le cas où cette patte est 0,1, l'identifiant 2 est une valeur qui peut
être vide, la cardinalité minimum est 0. Cela entraîne l'obligation de traiter
les valeurs vides.
Exercice de passage MOD/MPD relationnel.
Dessiner le modèle relationnel de ce MOD :

de
réf. ouvrage réf. exemplaire
0,N 0,N
AUTEUR prêter PRET
écrire
date de retour
réf. auteur 1,N réf. prêt
1,N
1.4.5 Au résultat !
Le résultat du choix des colonnes de table doit respecter certaines règles.
Les premières s'appuient sur les informations (formes normales), les
secondes (règles de Codd) sont plus larges et définissent l'environnement
des tables. Normalisation et règles de Codd sont décrites dans ce
paragraphe.
Les rapports entre tables, s'appuyant sur les informations, sont classés en
cinq formes dites normales. Ces classes de normalisation des tables
permettent de respecter la cohérence des informations entre tables : par
exemple, ne pas mettre le prénom du fils dans la table du père. Ces classes
de normalisation recoupent les règles de construction du MCD. Un MCD
correctement construit entraîne la génération de tables normalisées.
Les règles (de Codd) permettent de vérifier si un SGBD est relationnel ou
non. Les SGBD relationnels actuels ne sont pas actuellement aussi
performants en rapidité que les autres du fait de la gestion des informations
et non des adresses. Cette performance va en s'améliorant. Tout n'est
qu'état de l'art de la technique.
Normalisation des tables
La normalisation des tables consiste à répartir les informations dans les
tables en fonction de règles. Seules les clés peuvent être redondées. Cinq
étapes de normalisation sont distinguées. A chaque étape, les tables sont
déclarées comme étant en première, deuxième... cinquième forme normale.
Le but est d'arriver à la dernière étape pour obtenir des tables normalisées.
Cette normalisation est obligatoire uniquement si les tables ont été
directement construites sans méthode.
Ces règles peuvent être rapprochées des règles sur les informations
d'individus ou de relation (une seule valeur d'information par individu ou
relation par exemple). Quand le passage s'effectue du MCD MOD (MLD) au
MPD, les tables sont obligatoirement normalisées. Merise évite d'avoir à
normaliser les tables.
Dépendance multi-valuée et fonctionnelle sont des termes typiques du
modèle relationnel. Une dépendance multi-valuée est un chemin d'une
information de départ à N informations d'arrivée. A partir d'un "nom de
pays", N "nom de villes" sont trouvés.
Une dépendance fonctionnelle est un chemin d'une information de départ à
1 information d'arrivée. A partir d'un "nom de ville", 1 "nom de pays" est
trouvé, ainsi qu'1 "nombre de citadins".
N 1
Dépendance multi-valuée et fonctionnelle

Le défaut de cette représentation est de ne prendre en compte ni la
cardinalité minimale (0 ou 1) ni le "chemin inverse" de l'autre patte.
1ère forme normale : élimination des dépendances multi-valuées entre
informations d'une même table. Elles éliminent d'une table les informations
prenant plus d'une valeur dans cette table (chemin à N arrivées à partir de
la clé de table ou chemin de "clé1" vers xxx et "yyy"). Ces informations
"arrivées" se trouvent dans une autre table, à créer et non normalisée,
provenant d'un autre individu.
N clé1 xxx yyy

1 N
=>
clé1 aaa bbb xxx yyy clé1 aaa bbb
L'élimination des dépendances multivaluées conduit à une table normalisée

et une à normaliser
0,N
clé1 ou
aaa 1,N
Les cardinalités maximales N sont identifiées.

Dans une table en première forme normale, les informations ne prennent
qu'une valeur. Les cardinalités 0,N et 1,N sont identifiées. Le traitement des
dépendances multi-valuées (cas de plusieurs dépendances multi-valuées
dépendant de la clé) fait l'objet des quatrième et cinquième normalisations.
La table de départ peut provenir d'une relation.
2ème forme normale : élimination des dépendances sur une partie de clé
(non élémentaires), les relations exprimées sont identifiées.
Une dépendance non élémentaire existe quand une information de départ
dépend d'une partie de la clé d'une table. Dans l'exemple, ccc et bbb
dépendent de deux parties de la clé : clé1 et clé2. aaa dépend de clé1,clé2.
Exemple : si la table de départ est "produit commandé", l'index unique est

"numéro de commande, numéro de produit". Si la "date de la commande"
se trouve dans cette table, elle doit être sortie car elle ne dépend que du
"numéro de commande".
clé1, clé2 aaa

1 1
clé1, clé2 aaa bbb ccc =>clé1 ccc
1 clé1 bbb
Identification des tables issues de relations

Création des tables issues des individus
L'information ccc est une propriété de l'individu d'identifiant clé1,
l'information bbb est une propriété de l'individu d'identifiant clé2,
l'information aaa est une propriété de la relation entre les deux individus.
0,N 0,N
clé1 aaa clé2
ccc bbb
Identification des relations

3ème forme normale : élimination des dépendances transitives.
Une information est "dépendante de manière transitive" quand elle dépend
d'une information non clé d'une table : bbb dépend de aaa. aaa n'est la clé
d'aucune table. Comme les dépendances multi-valuées ont été éliminées, la
relation a une cardinalité maximale égale à 1, 0,1 ou 1,1. aaa est une clé
qui n'a pas été identifiée. Cette information n'a pas été déclarée comme
partie d'index unique d'une table.
1 1 clé1 aaa ccc

clé1 aaa bbb ccc => aaa bbb
1
bbb passe dans une nouvelle table

Les individus non identifiés contenant plusieurs informations sont identifiés.
0,1
ou aaa
1,1 bbb
Identification des cardinalités X,1 d'individus identifiés avec des individus

non identifiés
4ème forme normale : traiter les dépendances multi-valuées reconnues
dans la première forme normale. C'est le cas d'une clé à plusieurs
dépendances multi-valuées. La "table" n'était pas normalisée en 1. Les
tables xxx et yyy sont séparées.
N N clé1 xxx xxx
clé1 xxx yyy => clé1 yyy yyy
Identification de tables issues de relations X,N

Le chemin à N arrivées de clé1 vers xxx et yyy entraîne la création de la
deuxième table contenant les informations yyy et la table croisée, "relation"
contenant les informations clé1 et yyy si le chemin de yyy vers clé1 a N
arrivées (relation NN se transformant en table). Si le chemin de yyy vers
clé1 a 1 arrivée, le chemin est conservé en redondant clé1 dans la table yyy
(relation X,1 entraînant la redondance de la clé du "père"). L'index unique
est alors yyy et non clé1, yyy. Les deux tables en pointillés n'existent alors
pas.
1,N ?
ou
yyy
0,N
0,N ou 1,N
?
xxx
Identification des cardinalités X,N

avec les individus non identifiés
5ème forme normale : une dépendance multi-valuée existe entre arrivée
de dépendances multi-valuées. C'est une quatrième forme normale où une
relation supplémentaire est "identifiée". Elle concerne le chemin à N
arrivées entre xxx et yyy. Si cette dépendance existe, la relation grisée
existe, donc la table qui a pour clé (xxx yyy).
clé1 xxx xxx

clé1 xxx yyy =>xxx yyy
N clé1 yyy yyy
Identification de la dernière table possible

Les individus sans identifiant sont reliés. Les relations non exprimées sont
identifiées. La relation entre les individus xxx et yyy peut être du type 0,1
0,N. Dans ce cas, xxx peut être dans la table yyy (chemin à une arrivée de
yyy vers xxx).
yyy
?
1,N
ou
xxx
0,N
Relations entre individus non identifiés

Résumé. Les tables de départ correspondent à l'individu et la relation en
trait gras. La 1ère normalisation identifie les relations X,N. La deuxième
traite la table relation déjà exprimée. La troisième identifie les cardinalités 1
maximum avec des individus contenant plus d'une information. La
quatrième sépare les relations N. La cinquième identifie les relations entre
individus non identifiés à une information.
?
aaa 3 4 xxx
X,N
bbb
X,N 1 ?
2 5
4 X,N
? yyy
Résumé : les tables de départ sont en trait gras
1.4.6 Les douze Règles de Codd (plus la zéro).

Ces règles ont été exprimées par M. CODD * (référence 10) et servent de
modèle pour les SGBD actuels. Elles sont souvent mentionnées et rarement
citées. C'est pourquoi elles le sont ici.
Une vue est une vue externe telle que définie au niveau conceptuel. Dans le
cas de SGBD relationnel, une vue est un ensemble de tables que
l'utilisateur manipule. Ces tables manipulées peuvent être différentes des
tables définies dans le SGBD. La table manipulée Véhicule à Moteur est une
vue des tables Véhicule et Moteur.
Règle 0 - SGBD relationnel. Un SGBD relationnel doit pouvoir gérer toutes
les bases de données par ses possibilités relationnelles (recherche d'une
occurrence par combinaison d'ensembles d'occurrences).
Règle 1 - Règle sur les informations. Toutes les informations, dans une base
de données relationnelle, sont dans des tables (même le méta-modèle : le
descripteur de tables est une table).
Règle 2 - Garantie d'accès. Toute information élémentaire dans une base de
données relationnelle est logiquement accessible par combinaison de nom
de tables, de clé primaire (index unique), et de nom de colonne.
Règle 3 - Traitement des valeurs vides. Les valeurs vides sont supportées
par les SGBD relationnels pour représenter des informations inconnues ou
inapplicables de manière systématique.
* E.F. Codd. An evaluation scheme for database management systems that are claimed to be relational. Computerworld 1985
Règle 4 - Catalogue "relationnel" de la base. La description des bases de

données est représentée comme des données ordinaires. Le langage
d'interrogation est le même.
Règle 5 - Syntaxe d'un langage concernant les données. Un SGBD re-
lationnel possède au moins un langage
- possédant une syntaxe définie,
- comprenant les fonctionnalités suivantes : définition des données, des
vues, manipulation des données (de manière interactive et par pro-
gramme), contraintes d'intégrité, autorisation (d'accès), commandes de
transaction (commencer, valider ou mise à jour logique, revenir à la
validation précédente).
Règle 6 - Règles de modification des vues. Toutes les vues théoriquement
modifiables (création et suppression) sont modifiables par le SGBD.
Règle 7 - Création, modification et suppression de tables. La possibilité de
manipuler une table comme opérande est valable pour la sélection, la mise
à jour et la suppression.
Règle 8 - Indépendance vis-à-vis des données physiques. Programmes
d'application et transactions ne sont pas modifiés par des changements de
stockage ou de méthodes d'accès aux informations.
Règle 9 - Indépendance vis-à-vis des données logiques. Programmes
d'application et transactions ne sont pas modifiés par des changements sur
les tables sans perte théorique d'information.
Règle 10 - Indépendance des contraintes d'intégrité. Les contraintes
d'intégrité sont définies et stockées dans un catalogue (et non dans un
programme).
Règle 11 - Indépendance vis-à-vis de la répartition. Un SGBD relationnel est
indépendant de la répartition des données.
Règle 12 - Règle de respect des contraintes. Si un SGBD possède un
langage "détaillé" (une ligne de table à la fois par opposition à la ma -
nipulation des lignes de tables par intersection sur des ensembles de
lignes), celui-ci doit tenir compte des contraintes d'intégrité (référentielles
et d'intégrité sur la clé) déclarées dans le langage "général". *
1.4.7 L'information du modèle relationnel.
Pour conserver la "pureté" des informations définies au niveau conceptuel,
les différentes informations "adresse du client", "adresse du fournisseur"
doivent être conservées et définies dans le système d'information. En
relationnel, cette contrainte ne fait pas partie du système.
Qu'est-ce que l'information en relationnel ? Une information est-elle dans
une table ou dans plusieurs tables ? Le numéro du père dans la table fils
est différent du numéro du père dans la table père. Pour manipuler des
informations en relationnel, il est nécessaire de spécifier la table de
l'information. Chercher le numéro du père dans la table père est différent de
chercher le numéro du père dans la table fils. Il peut fort bien n'y avoir
aucun rapport entre deux colonnes de tables différentes portant le même
nom. Des colonnes telles que adresse, date, numéro, code, montant sont
possibles en relationnel sans préciser adresse du client, adresse du
fournisseur...
* E.F. Codd. An evaluation scheme for database management systems that are claimed to be relational. Computerworld 1985
1.5 Eclater ou regrouper les enregistrements physiques.

Un ou des enregistrements du MLD peuvent donner naissance à plusieurs
(éclatement d'enregistrement) ou un enregistrement(s) (regroupement
d'enregistrements) physiques du MPD. Si les informations des
enregistrements sont très différentes, l'éclatement prend en compte moins
d'occurrences lors de la manipulation des enregistrements. Le
regroupement prend en compte moins d'enregis-trements, mais plus
d'occurrences. Le choix s'effectue en fonction de la fréquence des
programmes manipulant les enregistrements et de la comparaison en gain
de temps des solutions .
Eclatement d'enregistrement logique.
Reprenons les exemples du contrat. 80% des contrats sont du type 1, 10%
du type 2 et le reste (10%) d'au moins cinq types différents.
L'enregistrement logique dérivé de l'individu contrat est unique. Les
enregistrements physiques peuvent être optimisés et l'enregistrement
"contrat" éclaté en Contrat1, Contrat2 et Contrat autre. Les informations de
l'enregistrement Contrat1 sont définies et non communes aux autres.
Deuxième exemple. Le méta-individu "pattes" donne naissance à deux
enregistrements physiques, "pattes de nomenclature" et "pattes d'individus
différents". Le premier doit avoir une clé propre. Le deuxième est un
enregistrement croisé des enregistrements "individu" et "relation".
Regroupement d'enregistrements logiques.
Exemple des véhicules et des moteurs. Au niveau conceptuel, le modèle de
données est :
MOTEUR 1,1 0,1 VEHICULE

motoriser
Un véhicule peut ne pas avoir de moteur

Au niveau logique, les individus moteur et véhicule se transforment en
enregistrements moteur et véhicule. Le modèle de données est :
MOTEUR
c lé Moteur c lé Véhic ule Puissanc e du moteur nombre de c ylindres
VEHICULE
c lé véhic ule c lé moteur
Le véhicule peut toujours ne pas avoir de moteur

Au niveau physique, si 90% des véhicules traités sont des véhicules à
moteur, un seul enregistrement "Véhicule" peut être retenu dans lequel
seront stockées les informations des moteurs :
VEHICULE
c lé véhic ule Puissanc e du moteur nombre de c ylindres
Les vélos ont un moteur "à blanc" au niveau physique.

Que devient la représentation "type de...", "caractéristique" et
"posséder" du modèle de données ?
Prenons exemple sur le modèle relationnel. Les individus deviennent des ta -
bles. Les relations "posséder" et "autoriser" deviennent des tables.
XXX TYPE DE XXX

1,1 0,N
typer
1,N 1,N
posséder autoriser
valeur CARACTERISTIQUE DE XXX
0,N 0,N
MCD replié
La table "type de..." indique quelles sont les informations à lire dans
l'enregistrement "posséder".
Xxx Référenc e xxx Référenc e type xxx Libellé xxx
Référenc e type xxx Libellé type xxx

Type De Xxx
Caractéristique De Xxx Référenc e c arac téristique Libellé c arac téristique
Référenc e xxx Référenc e c arac téristique valeur

Posséder
Autoriser Référenc e type xxx Référenc e c arac téristique
Supposons que les tables "XXX" et "caractéristiques de XXX" soient

regroupées et que la table "autoriser" indique le numéro d'ordre de la
"référence caractéristique" dans la "référence type XXX". Alors, "autoriser"
indique la structure de données de la table regroupée "XXX", comme un
"code carte" indiquait la structure de données d'une carte perforée.
Carte Référenc e xxx Référenc e type c arte Libellé xxx
valeur 1 valeur 2 valeur N
Type De Carte Référenc e type xxx Libellé type xxx
Caractéristique De Carte Référenc e c arac téristique Libellé c arac téristique
Autoriser Référenc e type xxx Référenc e c arac téristique Numéro d'ordre
2 MODELE PHYSIQUE DE TRAITEMENT
Il consiste en l'écriture du programme. Celui-ci peut être généré dans le

cadre d'un "atelier de génie logiciel". La finalité de méthodes telles que
MERISE est la production de "code" automatique à partir de la conception.
La maquette est l'enchaînement des états sans réels calculs. Un prototype

exécute des calculs, met à jour des données et l'utilisateur final peut
presque dire que la programmation est terminée.
Programme
L'outil informatique retenu par l'utilisateur va être réalisé par un
programmeur. Celui-ci est libre de découper ses programmes de manière à
les réutiliser dans les différents outils informatiques.
Les programmes d'édition sont un exemple de programme spécial
permettant de créer tout état de sortie en fonction des informations de la
base de données. C'est le cas des progiciels sophistiqués.
3 MODELE PHYSIQUE DE COMMUNICATION

Il s'agit de télématique entre sites informatiques. Il n'existe pas de modèle
propre à MERISE.
4 VALIDATION MPT/MPD
Tout programme met à jour ou lit des informations dans des enre-
gistrements physiques et des liens d'enregistrements.
Toute information d'un MPD doit être créée et consultée par un programme.
Ceci a déjà été en partie vérifié lors du niveau logique. L'éclatement ou le
regroupement d'enregistrements entraîne une nouvelle validation.
5 RESUME DU NIVEAU PHYSIQUE.

Les modèles du niveau physique représentent les normes actuelles.
En matière de données (MPD), trois types de SGBD, hiérarchique,
navigationnel et relationnel sont normalisés. Les deux derniers permettent
de conserver facilement les relations NN identifiées au niveau conceptuel.
Le modèle relationnel est promu à un bel avenir grâce à son langage
normalisé de manipulation des enregistrements (tables) et des informations
nommé SQL. Il ne remplace pas la méthode et 5 types de normalisation des
tables doivent être menés par les "non-merisiens".
Les deux autres modèles (traitement et communication) ne sont pas
propres à MERISE. Les normes de programme et de transfert physique
d'information n'existent pas actuellement.
PERE
FILS NEVEU
PETIT
NEVEU
S G B D HIERARCHIQUE
PERE
FILS NEVEU
ONCLE PETIT
NEVEU
S G B D NAVIGATIONNEL
PERE
FILS NEVEU
ONCLE PETIT
NEVEU
S G B D RELATIONNEL
BUREAU DE VALIDATION DU NIVEAU PHYSIQUE

CHAPITRE V RESUME DES MODELES
Le bois est désormais devenu bateau.

(Expression chinoise)
1 RESUME DES COMMUNICATIONS.

Les communications représentent les échanges entre systèmes. Au niveau
conceptuel, les échanges sont les messages et les systèmes fonctionnels
les intervenants. Au niveau organisationnel, les échanges sont les
informations échangées et les systèmes organisés les sites de traitements
et de données. Les échanges existent par les vues en lecture ou en mise à
jour des opérations organisées effectuées sur un site. Au niveau logique, les
échanges sont les actions de mise à jour des outils de traitements différés.
Les systèmes sont les sites de données. Au niveau physique, les échanges
sont les mêmes actions de mise à jour des outils.
2 RESUME DES TRAITEMENTS.

Les traitements représentent le travail effectué par un système. Au niveau
conceptuel, les traitements sont les opérations conceptuelles et les
systèmes fonctionnels les intervenants. Au niveau organisationnel, les
traitements sont les opérations organisationnelles et les systèmes
organisés les postes de travail. Au niveau logique, les traitements sont les
outils. Les systèmes sont informatiques, sans pouvoir les nommer. Au
niveau logique, les traitements sont les programmes. Les systèmes sont
informatiques. Au niveau physique, ils peuvent être nommés (SGBD,
Système de traitement ou d'exploitation).
Les modèles de traitements se décomposent en opérations conceptuelles/
opérations organisées/ outils/ programmes. Entre chaque niveau, une
décomposition et une recomposition existent. Il existe N solutions de choix
d'opérations organisées, d'outils et de programmes.
Exercices : vrai ou faux ?

1. Un outil est indépendant de l'organisation.
2. Un système se décompose en systèmes.
3. Le P-D-G n'effectue que des opérations conceptuelles.
4. Un employé n'effectue que des opérations organisées.
5. Mon oncle va enfin pouvoir aller au cinéma.
6. Une opération dite conceptuelle est effectuée par un domaine.
3 RESUME DES DONNEES.

Les données représentent la mémoire d'un système. Au niveau conceptuel,
la structure de cette mémoire est composée d'individu, de relation, de
patte, d'information, de contrainte et le système est un domaine. Au niveau
organisationnel, la structure de cette mémoire est composée d'individu, de
relation, de patte, d'information, de contrainte et le système est un site

géographique de données d'un domaine. Au niveau logique, la structure de
cette mémoire est composée d'enregistrement, de chemin, d'information et
le système est un site de données informatique. Au niveau physique, la
structure de cette mémoire est composée d'enregistrements physiques, de
lien et d'information et le système est un site de données informatique dont
le type de SGBD est connu.
OPERATION INDIVIDU SYSTEME

C INTERVENANT D D'INFORMATION :
P CONCEPTUELLE RELATION
O G PATTE DOMAINE
O E
M E T
U OPERATION POSTE DE INDIVIDU
SITE DE
M ORGANISEE N A RELATION
R TRAVAIL DONNEES
E PATTE
Q E I
N OUTIL R L ENREGISTREMENT SITE DE
U
T A CHEMIN DONNEES
O INFORMATIQUE L
? L E
I PROGRAMME ENREGISTREMENT
LIEN TYPE SGBD
?
Traitement et données
CHAPITRE VI L'ORGANISATION D'UN PROJET
L'application d'un plan annuel dépend des

efforts qu'on fait au printemps.
(Proverbe chinois)
1. LES ACTEURS D'UN PROJET.

Le choix des personnes à affecter à un projet en fonction de leur
compétence et de leur expérience est primordial.
Ce point est essentiel pour la réussite d'un projet. Mieux vaut un bon chef
de projet avec une méthode quelconque, si cela existe, qu'un chef de projet
médiocre avec une bonne méthode. De plus, un "bon" chef de projet saura
changer de méthode pour en suivre une plus adaptée. Rassurez-vous,
Merise est une très bonne méthode.
Les acteurs principaux sont :
- le futur utilisateur de l'informatique qui détient le savoir-faire de sa
technique, expert dans son métier,
- le "concepteur" ou formalisateur du système qui acquiert le savoir, pour le
spécifier au
- réalisateur ou programmeur qui détient le savoir-réaliser.
Les autres acteurs sont l'organisateur, qui sait organiser, et un res-ponsable
de l'application qui sait choisir. Ces acteurs sont fonctionnels, une seule et
même personne peut tenir tous ces rôles et peut utiliser, concevoir, réaliser,
organiser et choisir.
Il est important de se doter de moyens de décision à un niveau élevé,
appelé comité de pilotage, pour servir de cellule de décision sur les choix à
effectuer et de moteur à la méthode.
2. SCHEMA DIRECTEUR : le découpage en domaines et la

planification.
La présentation d'un schéma directeur est volontairement simplifiée de
manière à souligner les apports spécifiques de la méthode.
Un schéma ou plan directeur d'informatisation retient les principales
options informatiques (Matériel) et la planification des projets. Pour cela, il
identifie les domaines de l'entreprise, les flux et concepts (individus)
principaux.
VENDRE
ACHETER PILOTER
COMPTABILISER
PRODUIRE
PERSONNALISER
Découpage en domaines
VENDRE PILOTER
BUDGET
Recoupement des concepts entre domaines

Le schéma directeur définit le cadre organisationnel et informatique des
futurs projets. Après étude de l'informatique existante et consultation de
fournisseurs de matériels informatiques, il préconise un choix informatique.
Les critères de choix sont des délais de mise en place et de réalisation des
programmes, de fiabilité de matériel, de facilité de mise en oeuvre et de
coût, de capacité de traitement ou de mémorisation, du nombre de postes
de travail... Quel système ? Micro-ordinateur (avec ou sans réseau), mini ou
gros système ?
Ce choix est souvent soit une centralisation pour cause de "synergie",
soit une décentralisation pour cause de "responsabilisation", centre de coût
ou de profit. Il est donné pour un coût et pour un gain attendus sous forme
de pourcentages "saupoudrés" par domaine. Il ne faut pas négliger les coûts
internes en personnel dus à la formation et à la disponibilité "perdue".
Les gains attendus en confort d'utilisation, motivation du personnel et
augmentation potentielle de chiffre d'affaires ne sont pas mesu-rables
facilement.
Année 1 Année N
gain Personnel
Matériel
dépense - Matériel
Logiciel
Personnel - interne
externe
Différence - ++
Enfin et surtout, un schéma directeur établit une planification des projets

par domaine et un plan d'investissement. Cette planification est
représentée sous la forme d'enchaînement de projets.
Projet 1 Projet N
Projet 2
Départ Arrivée
Projet i Projet i+1
et de réalisation dans le temps. Il est fortement recommandé de

commencer par la comptabilité analytique. Elle définit les critères
analytiques principaux de l'entreprise. L'organisation peut en être déduite.
L'estimation des délais est un exercice difficile qui dépend fortement de
l'environnement. Une comptabilité analytique ou une gestion du personnel
peut être opérationnelle en 6 mois ou 2 ans.
Année 1 Année N
Projet 1
Projet 2
Projet i
Projet i+1
Projet N
Chaque projet sera ensuite l'objet d'une étude préalable.

Introduction à la gestion de projet :
La gestion de projet concerne l'enchaînement détaillé des travaux à
effectuer, leur répartition en fonction des équipes et le suivi de la
réalisation.
Cet enchaînement d'opérations permet la planification et la détermination
du "chemin critique" du projet, le parcours le plus "serré", nécessairement le
plus long pour arriver au résultat final. Celui-là représente la suite des
opérations à surveiller de près afin d'éviter un glissement dans le temps.
Tout retard pris sur ce chemin critique se répercute automatiquement sur la
date finale de réalisation.
Le but d'une gestion de projet est de respecter les coûts prévus et la date
finale de réalisation pour un résultat donné. Le découpage du projet en
tâches élémentaires d'une durée prévue est effectué. Chaque tâche peut
débuter ou se terminer à une date déterminée. A chaque tâche est affectée
une ou des ressources acquises à un coût donné. La gestion des ressources
(personnel, matériel) consiste à déterminer les tâches dans le temps en
tenant compte des disponibilités des ressources. Le modèle de données
d'une gestion de projet est :
0,N
0,1 0,N
enc haîner TACHE débuter EVENEMENT
0,N durée tâc he 0,N date événement

0,1
libellé évt
utiliser terminer
1,N
nombre DIS PONIB ILITE
RES S OURCE 0,N 1,N
être date début
0,N nombre date fin
c oût
Deux types de graphes existent pour représenter cet enchaînement des

tâches. Le premier représente la tâche par un trait et l'événement par un
rond. Le deuxième représente la tâche par un rond ou un rectangle et
l'événement par une flèche. La flèche représente l'enchaînement obligatoire
entre tâches. La deuxième, se dessine plus facilement et est utilisée ici.
3 ETUDE PREALABLE : le choix de l'organisation et des outils

informatiques.
Une étude préalable concerne un domaine. Elle retient un choix
d'organisation détaillé et d'outils informatiques à disposition des postes de
travail. Le choix final peut être de ne pas informatiser. Une étude préalable
peut aller d'une étude d'opportunité (dans le cas où le schéma directeur est
inexistant) à la préparation de l'étude détaillée.
Etude Etude Liste des outils Etude Etude

conceptuelle organisationnelle et validation MOD logique Physique
ETUDE PREALABLE
L'étude préalable comprend une partie du niveau logique

Le résultat d'une étude préalable est généralement, dans le cas
d'informatisation, une liste d'outils informatiques validés par des modèles
organisationnels de données et les outils informatiques existants. L'étude
préalable recouvre donc une étude conceptuelle, une étude
organisationnelle et une partie de logique.
3.1 L'existant.
Lors d'une étude préalable se pose le problème de l'existant. Doit-on
étudier l'existant pour en connaître les avantages et les inconvénients,
reprendre les transactions informatiques appréciées des utilisateurs ou tout
reprendre sous prétexte d'œil neuf et ne pas passer plus de temps à étudier
le vieux que de faire du neuf ?
La réponse est d'étudier le conceptuel avant l'existant et de ne pas essayer
de faire de conceptuel de l'existant.
Conceptuel
Organisationnel Organisationnel
existant prévu
Informatique Informatique
existante prévue
COURBE DE LA PLUIE : tout descend du conceptuel

Le conceptuel avant l'existant.
D'étudier les fonctions majeures de l'entreprise, les domaines, permet
d'exercer un œil critique sur l'existant. Si, après analyse du conceptuel, il
est décidé de ne plus avoir de service de livraison interne, l'analyse des
documents internes de demande de livraison est inutile. Les informations
examinées à la lumière du conceptuel permettent une compréhension plus
facile.
Ne pas essayer de faire de conceptuel de l'existant.
Comment est-ce possible de conceptualiser l'existant ? En remontant du
physique ou en interrogeant l'utilisateur en lui demandant de parler de
l'existant et non de ce qu'il désire. Dans le deuxième cas, comment
descendre vers le physique ? Si des informations sont redondantes, existent
plusieurs fois, dans quel concept existent-elles ? Le seul cas possible de
"conceptualiser" l'existant est quand le physique est modifié aussitôt pour
coller à un conceptuel existant et futur.
3.2 Micro-informatique ou un seul site.

Dans le cas de développement sur micro-informatique, il n'est souvent
question que d'un seul domaine et d'un seul site de données. La règle est
de faire un modèle de données complet avec les règles de calcul et, dans le
cas de recherche de progiciel, de les comparer avec ceux du progiciel.
L'étude préalable recouvre un conceptuel détaillé (plus détaillé que le
schéma directeur) et une liste d'outils informatiques. Les validations
possibles sont : fin du conceptuel, fin de l'étude préalable avec une liste des
outils. Cette dernière étape est indispensable.
Les outils utilisateurs sont explicités suivant leur type (interface, édition,
autorisation d'accès, traitement immédiat ou différé, progiciel...) et leur
complexité de réalisation (simple, moyen, difficile, très difficile). Ils sont
ensuite planifiés pour leur spécification et la réalisation : outil de saisie du
client avant celui de la commande (toujours les mêmes exemples, avez-
vous remarqué ?).
Le choix de l'outil de développement est effectué et les temps définis
pour chaque complexité. Les temps de spécification sont en moyenne de
deux jours pour un outil simple, une semaine pour un moyen et quinze jours
pour un difficile. Voir une application dans le cas "Bibliothèque". Les temps
de réalisation dépendent fortement de l'outil de développement et sont à
peu près équivalents aux temps de spécification. Une moyenne de 7 jours
par outil - spécification + réalisation - est une très bonne moyenne.
Les dessins suivants sont des exemples de planning. Les rectangles
représentent les tâches à effectuer et les flèches les enchaînements
obligatoires. Par exemple, sur le dessin suivant représentant l'enchaînement

des tâches du niveau conceptuel, le MCD doit être exécuté après le MCC.
liste des Modèle conceptuel de données : Validation niveau

partenaires C ONCEP TUEL
individus, relations, contraintes
et sous-domaines et informations, vues externes
Concordance des
Modèle Conceptuel informations des messages
Epuration du
De Communications / infos du MCD
vocabulaire
règles, équivalences
La conception est indispensable

Puis, à l'aide du MCD, listez les outils et calculez les volumes de stockage
nécessaires pour dimensionner le disque dur. Rappelons que ce cas
s'applique uniquement dans le cas d'un site de données, sinon, les MOD
sont indispensables pour consolider les données.
Validation Modèles en Mise à jour et consultation

liste des
C ONCEPTUEL outils par outil + validation de la liste des
outils = fin de l'étude préalable
3.3 Plusieurs sites.

L'étude préalable recouvre alors un conceptuel détaillé, un organi-
sationnel et une liste d'outils informatiques. Les validations possibles sont :
fin du conceptuel, fin de l'organisationnel et organisationnel plus liste des
outils. Cette dernière étape est indispensable (Bis repetita placent).
Les outils utilisateurs et de développement sont explicités de la même
manière que dans le cas de micro-informatique. Bien sûr, le résultat de
l'étude préalable peut être le choix d'un progiciel. Dans ce cas, le chemin
critique est souvent la réalisation des interfaces informatiques et la
construction d'un jeu d'essai est primordiale.
Dans certains cas toujours mentionnés, valides dans le cas de choix de
progiciel, une étude de scénario est prévue. Trois types d'hypothèses sont à
expliciter par scénario : organisation (organigramme), ressources
informatiques (matériels informatiques et liste des outils de développement
et utilisateur) et développement (planification du projet et charge de
travail).
MCT VALIDATION
DONNEES/TRAITEMENT
modèles des opérations
EPURATION
MCC VOCABULAIRE
VALIDATION
INFORMATIONS VALIDATION
MCD PAR L'UTILISATEUR
MESSAGES / MCD
Du conceptuel à la fin de l'étude préalable.

Vérification des Vérification de

liste des la liste des outils à l'aide
informations à l'aide
postes de travail des outils existants
des documents existants
Etablissement des procédures

Validation (MOT) avec l'utilisateur. Validation des procédures,
Conceptuel Détermination des outils associés des outils associés
et de leur complexité. et des informations liées
Déterminations des données associées (liste des outils / MOD)
aux opérations (Modèles des opérations)
liste des
procédures
Planning de réalisation des
spécifications détaillées et de Fin de l'étude préalable
la réalisation du projet : lancement du projet
4. ETUDE DETAILLEE : spécifications externe et interne.

La spécification externe (enchaînement des états et définition des
informations de chaque état) est effectuée et validée par l'utilisateur avant
la spécification interne ou la programmation, que ce soit dans le cas d'un
site ou de plusieurs sites (de micro-informatique ou non).
4.1 Cas d'un seul site.

Le passage du modèle conceptuel de données au modèle physique est
possible (MCD -> MPD).
Modèles en Mise-à-jour
et consultation par outil
+ validation de la liste
des outils = fin de Description des
Etats (MLT)
l'étude préalable
Construction
MLD ou MPD Programmation
4.2 Cas d'informatique multi-sites.

Les modèles logiques de données (livre des enregistrements et des
chemins) sont construits pour chaque base de données.
C hoix des équipes de spécification, P lanning et Répartition

de développement et de validation des outils à spécifier
Lancement
Du Projet
C onstruction Validation Modèles Lancement des
MLD ou MPD LD ou PD / outils études détaillées
Un Modèle Logique de Communication ou un schéma d'architecture de

l'informatique existante et cible décrivant les messages échangés entre
N fois
base de données et engendrés par tel outil est bienvenu. La liste des outils
etLancement
un Modèle Logique de Données validé par les traitements (Modèles des
outils) sont nécessaires pour
des études Tests la distribution des outils et attaquer la
spécification.
détaillées
Les tâches comprises entre le lancement des études détaillées et les

tests sont à multiplier par le nombre d'équipes de spécification. Le Modèle
Logique de Données n'est pas obligatoire pour la spécification externe. La
difficulté des études détaillées tient à la charge de travail et à l'éclatement
nécessaire du travail. La construction préalable du MLD évite toute dérive
"personnalisée" par un analyste ou un programmeur audacieux.
Enchaînement des Actions de mise à jour par état

Lancement
états et validation sur le Modèle Logique de Données.
des études
utilisateur Obtention des informations
détaillées
(spécification externe) (Spécification interne)
Analyse des
Programmation des Programmation des
programmes
outils traitement programmes
par lot (dont
différé transactionnels
interfaces)
Définition des Mise en

jeux d'essais Tests
production
Spécification et réalisation
5 REALISATION : le test de la méthode

Si la réalisation est bonne et l'utilisateur final enchanté du résultat, c'est
sûrement grâce à la méthode. Sinon, c'est la faute de l'informatique.
D'ailleurs, c'est souvent à ce moment qu'on se demande à quoi peut bien
servir l'informatique.
6 LES POINTS FORTS DU PROJET.

Les équipes de conception, organisation et réalisation doivent être le plus
"constantes" possible. Cela implique que les données et les traitements
doivent être suivis par les mêmes personnes et que les responsables de
l'organisation et de l'informatique soient les mêmes ou "chapeautés" par un
même responsable des... systèmes d'information. Les gardiens de la
méthode doivent participer aux études et ne pas se cantonner dans un
service "méthodes".
Passer souvent sur les mêmes données et les mêmes opérations ap-
profondit les problèmes et les solutions. Les individus tels que REGLE,
SCENARIO, SIMULATION... apportent la valeur ajoutée et la durée de vie au
résultat final. Ce point dépend fortement du premier.
Un utilisateur fortement sollicité par plusieurs personnes se réclamant
d'une méthode n'apporte pas toute la concentration nécessaire. Il convient
de choyer l'utilisateur final.
Il faut donc choisir des utilisateurs pouvant s'abstraire de l'existant en le
simplifiant et en l'améliorant.
Attention à l'utilisateur seul et décidant pour ses "postes de tra vail" : les
"postes de travail" se feront connaître un jour ou l'autre et auront sûrement
un point de vue différent.
Et, bien sûr, ne jamais faire de projet sans avoir de contact suivi avec
l'utilisateur : "Pas de conception en chambre".
CHAPITRE VII LA META-PHYSIQUE : maintenance, formation et

documentation
Les oiseaux gazouillent, les fleurs

embaument.
Maintenance, documentation et formation permettent de faire face au
départ classique du créateur du programme en temps différé datant des
débuts de l'informatique et à remplacer par le nouvel embauché. Cette
documentation doit porter au minimum sur les données. Certains logiciels
de développement permettent une modification mémorisant
automatiquement des renseignements sur les programmes et les bases de
données.
1 UN DICTIONNAIRE DE DONNEES, SINON RIEN

La documentation est un domaine important et rarement traité.
L'application d'une méthode telle que Merise facilite grandement cette
tâche. Cette documentation obligatoire implique un certain travail.
Un dictionnaire de données d'entreprise, c'est-à-dire la liste des
informations avec leur signification et dans quel enregistrement elles se
trouvent est un atout considérable dans tout "système d'information" qui se
respecte.
2 LA DOCUMENTATION AUTOMATIQUE EXISTE.

Certains logiciels comprennent une partie de documentation liée au
physique ou au logique : quelles sont les données touchées par tel pro-
gramme, pour connaître les programmes à modifier en cas de changement
de données.
D'autres utilitaires de base de données facilitent la maintenance. Certains
logiciels de SGBD proposent des dictionnaires d'enregistrements et des
informations comprenant des explications : méta-dictionnaire de données
incorporé (tables de tables en relationnel). L'adresse des programmes en
bibliothèque peut être disponible automatiquement.
3 QUI DIRIGE QUI ? Le conceptuel ou le physique.

L'utilisation d'un progiciel de support de la méthode, d'aide à la
conception et à la réalisation, fortement conseillée, peut entraîner un "pont"
entre base de données de conception et base de données opérationnelle.
L'individu "client" est conçu dans une "base de conception". Dans cette
base, l'enregistrement physique est "individu" et l'une de ses occurrences
est "client". L'enregistrement physique "client" existe, ainsi que toutes ses
occurrences dans une base de données "opérationnelle".
La structure et la nature des informations dans les enregistrements est la
partie principale du dictionnaire de données et de ce "pont".
Trois démarches sont possibles.

Première démarche : le conceptuel de la base de données (MCD, MOD ou
MLD) définissant les concepts est bon et génère le physique. C'est le cas
général lors du démarrage de l'application. Les fichiers opérationnels sont
créés par une base conceptuelle. Toute information dans un enregistrement
est préalablement déclarée dans une base de données conceptuelle, définie
dans un individu ou une relation. L'avantage "conceptuel" est de n'avoir
que des informations qui se respectent, sans redondance non méritée.
Deuxième démarche : la base opérationnelle alimente la base de
données de conception. Les informations "opérationnelles" servent de base
de documentation "automatique" facilitant la compréhension et la
maintenance. Le risque est l'absence de documentation des informations
d'enregistrements physiques créées lors de l'écriture de programmes. Les
programmes seront plus vite réalisés mais avec le risque de ne pas avoir de
documentation.
Troisième démarche : trois bases de données existent, une base
"méthode", une base "opérationnelle" et une base "tampon" où se trouvent
les concepts désirés non opérationnels et les informations opérationnelles
non "conceptualisées". Cette démarche permet une désynchronisation de la
conception et de l'opérationnel.
La troisième démarche est celle recommandée. Elle permet d'organiser
la fonction d'administration de données.
CHAPITRE VIII EXEMPLES DE MODELES DE DONNEES
C'est pendant qu'il pleut qu'il faut remplir

les jarres.
(Proverbe chinois)
Vous pouvez maintenant raisonner en utilisant les principes et les dessins
de la méthode à presque toutes vos pensées. Prenons deux exemples, la
méthode appliquée à la méthode et à la comptabilité.
1 META-MODELE
Un méta-modèle est un modèle de données de la méthode. Deux exemples
ont été pris au chapitre 1. Le premier concernait les pattes et le deuxième
les opérations, les conditions et les messages. Quiconque comprend le
(méta-)modèle de la méthode comprend la méthode et réciproquement.
C'est donc un exercice de style amusant pour clarifier les idées de ceux qui
sont à l'aise en abstraction et confondre les autres.
1.1 MCC
Entreprise
Colis livré
Client Vendre
Avis de livraison
Fournisseur Electricité Livrer
MCC des flux réels

L'activité est définie par des flux émis ou reçus par des systèmes. Ces flux
sont de plusieurs types, physique ou matériel, d'énergie, valeur (argent) ou
d'information (message). Ces systèmes sont d'un type donné, domaine,
sous-domaine ou partenaire. La relation entre "type de système" indique
qu'ils sont tous intervenants. L'entreprise est aussi un "type de système".
Exemple de méta-modèle :
électricité
fournisseur
virement
livrer
client colis livré
sous/
systeme vendre O,N avis livraison
SYSTEME émettre FLUX
O,N
1,1 O,N O,N

recevoir
processeur 1,1 énergie

partenaire financier
intervenant physique
O,N domaine message
O,N TYPE DE TYPE DE FLUX
sous/type SYSTEME
systeme O,N
O,N
Exemple d'une partie de modèle de communication : le client émet une

commande vers l'intervenant vendre :
Client Commande Vendre

nom c lient
adresse
date c ommande
montant c ommande
MCC du projet
Le concept est représenté par deux occurrences de l'individu intervenant
"vendre" et "client", une occurrence de l'individu message "commande" et
quatre occurrences de l'individu information "nom client", "adresse", "date
commande" et "montant commande".
nom client
adresse émettre
date commande recevoir C LIENT
montant commande C OMMANDE VENDRE
0,N 0,N
INFORMATION MESSAGE émettre
INTERVENANT
0,N 1,N 0,N 0,N
recevoir
MCD DU MCC
Le modèle conceptuel comprend les intervenants qui émettent et reçoivent
des messages qui sont des flux d'informations.
1.2 MCT et MOT

MCT et MOT comprennent les opérations effectuées par un intervenant
(opération conceptuelle) ou un poste de travail (opération organisée). Ces
opérations sont enclenchées par des messages événements et donnent
naissance à des messages résultats via une condition. Une opération
organisée peut être enclenchée par un temporisateur. Une procédure est un
ensemble d'opérations organisées dont, si possible, les messages résultats
de l'une sont événements de l'autre.
Une opération conceptuelle se décompose en opérations organisées. Une
opération organisée s'effectue au moyen d'outils informatiques.
Une contrainte importante sur le modèle porte sur les individus MESSAGE,
INTERVENANT ET OPERATION ainsi que les relations entre ces individus : un
message émis ou reçu par un intervenant est résultat événement d'une
opération effectuée par cet intervenant.
organigramme 0,N
SITE
POSTE DE 0,1 0,N
INTERVENANT 0,1
TRAVAIL
0,N
0,N
0,N 0,N effec tuer 0,N PROCEDURE
effec tuer
rec evoir V 0,N s'insc rire
0,1
dans
émettre 0,1 OP ERATION
0,N 0,N 0,N 0,N
événement c onc eptuel /
organisationnel
MESSAGE 0,N 0,1 0,N
0,N
démarrer
0,N résultat 0,N
0,N
REGLE TEMPORISATEUR
C ONDITION 0,N
MCT et MOT
1.3 MCD et MOD

Au niveau conceptuel, le modèle de données comprend les informations, les
individus, les relations, les pattes et les contraintes. Une patte relie un
individu à une relation. Une information se trouve dans un individu ou une
relation. Une information est amont ou aval d'une composition, entrée ou
sortie de règle de calcul, amont ou aval d'une équivalence, le "motif"
pouvant être une relation.
Les pattes relient une relation à un individu. Bel exemple d'individu dont
toutes les cardinalités sont à 1. Les contraintes sur le modèle de données
portent sur les individus, les relations et les informations.
Au niveau organisationnel, individus, relations et informations sont reliés à
site (représenté par un S sur le dessin).
c omposition
0,N 0,N aval amont

REGLE entrée
INFORMATION 0,N
0,N
0,N aval
sortie S
0,N
0,1 0,1 amont
identifiant 1,1 1,N
C ONTRAINTE RELATION EQUIVALENCE

0,N 0,N
0,N
0,1 0,N
S
0,N 0,N 0,N 0,1
INDIVIDU PATTE
0,N 1,1
S motif
S 1,1
Vocabulaire, MCD et MOD
1.4 MLT
Spécification externe.
Le Modèle Logique des Traitements concerne les outils informatiques. Ces

outils sont composés d'états où sont affichées des informations et prêts à la
saisie d'autres informations.
Spécification interne.
Les actions de création, suppression ou mise à jour d'informations dans un
enregistrement pour un site de données sont spécifiées pour chaque état.
1,1 ETAT
0,N 1,N
0,N AC TION 1,1 0,N SITE
1,N
0,N 0,N 0,N
OUTIL
saisir 1,1
1,N
ENCHAINER
affic her
0,N 0,N 0,N 0,N
0,N ENREGISTREMENT
C ONDITION 0,N INFORMATION
0,N
MLT Spécification externe et interne

Les informations utilisées dans une action, un enchaînement d'état ou
affichées dans un état sont obtenues via un enregistrement, une règle, une
équivalence ou un chemin.
1.5 MLD et MPD.

Au niveau logique, un enregistrement contient des informations, est défini
par sa clé et appartient à un site de données. Il provient soit d'un individu,
soit d'une relation.
Un chemin, départ et arrivée d'informations peut provenir d'une patte et
donner lieu à un lien entre enregistrements physiques.
INDIVIDU INFORMATION arrivée

CHEMIN
0,N 1,N
S S
1,N départ S
0,1 0,N 0,N 1,N
0,N
clé 0,N 0,1
0,1 0,N
ENREGISTREMENT
0,1 0,N
RELATION
S
0,1
S 0,N
0,1 propriétaire
1,N membre
1,1
1,1
LIEN
PATTE 0,N
1,1 S
0,1
1,1 S
1.6 Validations (conceptuel, organisationnel et fin d'étude

préalable)
La première validation concerne la correspondance entre les informations
des messages et les informations du modèle des données via les règles de
calculs, les équivalences et la composition. Toute information "à retrouver"
existe dans le modèle de données directement ou par l'intermédiaire d'une
règle, une équivalence ou une composition.
0,N
0,1 1,N
c omposer
INFORMATION identifiant INDIVIDU
0,1 0,1
S S
0,N 1,N
MESSAGE 0,N 0,1
0,N
0,N
amont-eq sortie 0,N
RELATION
1,1 aval-eq 1,N S

entrée
EQUIVALENCE 1,N REGLE
1,N
La deuxième concerne la correspondance entre opérations, outils et

modèles des données. Individus, relations et informations du MCD
appartiennent à un modèle en lecture et un modèle en écriture des
opérations conceptuelles. Individus, relations et informations rattachés à un
site, d'un MOD, appartiennent à un modèle en lecture et un modèle en
écriture des opérations organisées et des outils.
INTERVENANT
P OSTE DE 0,N SITE 0,N
TRAVAIL
1,N
1,N
0,1 0,1 0,N 0,N
0,1 0,1
OP ERATION lec ture MODELE INDIVIDU
0,N 1,N
0,1
éc riture 0,N
0,1 0,1
0,N 0,N 0,1 0,N
lec ture 0,N
éc riture 0,N RELATION
1,N 1,N 0,1
REGLE INFORMATION
OUTIL
0,1
2 COMPTABILITE*
2.1 Représentation des flux externes et internes

La comptabilité représente l'activité de l'entreprise, les valeurs des flux
externes et internes réels : financiers, biens, services et prestations.
Associé
Client Prêteur
Marchandise
Entreprise
Liquidité Employé
Fournisseur
* Toutes
les représentations et les schémas du présent paragraphe, excepté les modèles de données, proviennent
ou ont été inspirés de l'ouvrage "COMPTABILITE GENERALE" de M. PEROCHON paru aux éditions
FOUCHER.
Partenaires et flux de l'entreprise

Les opérations effectuées par l'entreprise donnent naissance à des flux
externes et à des flux internes à l'entreprise (flux de produits intermédiaires
Marchandise M
d'un atelier
Entreprise de fabrication à unFournisseur
autre, dont la valeur doit être définie).
Liquidité
Exemple de flux externe : l'achat de marchandise. Un flux reçu est un
emploi
Emploi : (valeur obtenue)
Marchandise M et un flux
Emploi émis est une ressource (valeur fournie).
: Liquidité
Ressource : Liquidité Ressource : Marchandise M
Cet échange, vu de l'entreprise E, se présente ainsi :
Marchandise M
Entreprise Liquidité
et se ramène au suivant :
Entreprise
Valeur échangée
Marchandise
Liquidité
Liquidité
Dans la comptabilité d'une entreprise donnée, l'échange de deux flux

externes (un réel et un financier) prend l'apparence d'un flux unique.
Les opérations internes ne sont pas des échanges et se traduisent par un
seul flux interne.
Exemple : un lot de marchandise d'une valeur de 500 F est détérioré.
Marchandise Flux de perte : 500 Perte

Liquidité
EMPLOI : Perte 500 RESSOURCE: Marchandises 500
2.2 Compte ou pôle d'analyse

Toute opération externe et interne est traduite en emploi et ressource
entre comptes.
Flux F
C ompte 1 C ompte 2
crédit ou ressource débit ou emploi
Un compte ou un pôle d'analyse est départ ou arrivée de flux. Un compte

représente un pôle sous la forme d'un tableau à 2 colonnes dont la partie
gauche est réservée aux emplois et désignée débit et la partie droite
réservée aux ressources et désignée crédit, la fameuse partie double.
Toutes les représentations et les schémas du présent paragraphe, excepté les modèles de données, proviennent
ou ont été inspirés de l'ouvrage "COMPTABILITE GENERALE" de M. PEROCHON paru aux éditions
FOUCHER.
Toutes les représentations et les schémas du présent paragraphe, excepté les modèles de données, proviennent ou ont été
inspirés de l'ouvrage "COMPTABILITE GENERALE" de M. PEROCHON paru aux éditions FOUCHER.
a : 600 b : 2 000
c : 2 000 Compte X d : 1 700

e : 800
DEBIT (emplois) CREDIT (ressources)
Opération a .........600 Opération b ......2 000

Opération c ......2 000 Opération d .....1 700
Opération e ........800
FLUX du compte X
Présentons le cas de perte de marchandise vue du pôle stock de
marchandise et vue du pôle perte :
Compte Stock Flux de perte Compte

de marchandise 1 000 Perte
DEBIT C REDIT DEBIT C REDIT
Opération .....1 000 Opération .....1 000
Les comptes sont inscrits dans deux classes en fonction de leurs soldes :
débiteur à l'actif et créditeur au passif. Une caisse est débitrice, le capital
est créditeur. Le bilan différencie ces deux classes.
A CTIF BILA N PA SSIF
(Emplois nets) (Ressources nettes)

C omptes à solde usuellement débiteur : C omptes à solde usuellement créditeur :
Biens, créances, (résultat) C apital, réserves, dettes
(résultat)
2.3 Les deux comptabilités

La "comptabilité intégrale" telle que décrite ci-dessus (échange fournisseur
et marchandise) est décomposée en :
COMPTABILITE GENERALE axée sur l'étude des flux externes
COMPTABILITE ANALYTIQUE axée sur l'étude des flux internes
investissement capitaux
propres
dettes
pôle de financieres
résultat
fournisseurs
client
stocks personnel
état
liquidités
MCC de la comptabilité générale

La comptabilité générale ne détaille pas les flux internes. L'opération ou
l'échange Marchandise / Liquidité devient un échange Ventes ou Produit /
Liquidité. Toutes les marchandises sont confondues.
Le compte de résultat est unique :
CHA RGES RESULTAT PRODUITS
Débité en cours d'exercice : Crédité en cours d'exercice :

flux externes (achats, salaires, intérêts flux externes (ventes de marchandises
impôts ..) ou produits)
Débité en fin d'exercice :
flux interne d'amortissement
Débité ou crédité en fin d'exercice des variations de stocks
La représentation merisienne est élémentaire :

Un échange ou une opération débite et crédite des pôles d'analyse ou
des comptes. Si la facture client est la suivante,
FACTURE
total brut : ........9 000

remise 10% : ....... 900
8 100 Ventes 8 100
Produits 200
Port ......................... 200
accessoires
8 300
Net à payer ........8 300 Client
Liquidité
elle représente les flux entre les comptes crédités "Ventes" et "produits
accessoires" (port) et le compte débité "Client" (Net à payer).
La représentation des occurrences est :
débiter
8300
c réditer
8100 c lient
c réditer ventes
200
fac ture du sièc le produits ac cessoires
1,N 0,N
OPERATION créditer COMPTE
1,N 0,N
débiter
MCD presque correct

L'échange est décrit comme opération créditant ou débitant des comptes.
Comme les deux relations "créditer" et "débiter" ont des pattes op-
tionnelles (un crédit ou un débit peut être lettré, rapproché avec un autre
débit ou un autre crédit), elles deviennent un individu unique (qui comprend
l'information débit ou crédit) appelé "écriture comptable".
Dans ce modèle, une écriture égale un débit ou un crédit.
L'opération est aussi assimilée à la pièce comptable. (numéro de facture
pour l'opération de facturation). Les écritures d'une opération sont saisies
dans des journaux (de caisse, de vente...) qui sont des comptes rendus
chronologiques d'un type d'écriture.
8 100
c rédit
8 300
c lient
débit
200 ventes
fac ture du sièc le c rédit produits ac c essoires
OPERATION ECRITURE COMPTE
1,N 1,1 1,1 0,N
MCD simplifié de la comptabilité générale

Le Grand Livre est la liste des comptes et de toutes leurs écritures sur
une période donnée. La Balance est la liste des comptes et de leurs soldes.
La COMPTABILITE ANALYTIQUE est axée sur l'étude des flux internes et

détermine
- les coûts et résultats analytiques par critère (article, centre de profit,
type de client, région...)
- les éléments de gestion prévisionnelle (coûts, revenus et résultats
prévisionnels)
L'écriture concerne des critères d'analyse ou analytiques. Ces critères
peuvent être du type article, service, région, type de client... Une écriture
concerne toujours une charge ou un produit. Charges ou produits sont un
type de critère, le compte général.
Projet
Région
Service
Type de client Schéma directeur
Article Grands comptes
Charge/produit Frais personnel
Type de critère Critère analytique
1,1
MCD "Comptabilité analytique"

Avant d'étudier le domaine, il faut décider si le but de l'étude est une
comptabilité d'analyse très fine (critères d'analyse très fins), donc de
"gestion" ou de "production" ou une comptabilité de "synthèse", celle qui
est appelée analytique.
Facture Client Région
Produit Service Type de Client
MCD "Production"
L'essentiel de la comptabilité analytique est la détermination des critères
(analytiques) et des répartitions à effectuer.
0,N 1,1
devise
DEVISE ECRITURE 1,N 0,N CRITERE
écriture
concerne ANALYTIQUE
0,N
référence
0,N 0,N 0,N 0,N
effectue
0,N arrivée
1,N départ
UNITE 0,1 REPARTITION
0,N
D' OEUVRE base 1,N
Modèle conceptuel sans cumul

Pour calculer un résultat sur un critère déterminé, une répartition des
coûts non imputables au critère choisi est nécessaire.
Par exemple, le salaire d'un commercial ou du P.D.G est réparti par
produit si un résultat est calculé par produit. Sinon, le résultat total, qui
prend en compte ses frais généraux, ne correspondrait pas à la somme des
résultats élémentaires par produit.
Cette répartition est effectuée au moyen d'un facteur de proportionnalité
(règle de trois) vis-à-vis d'une unité d'œuvre (heures, nombre de factures,
francs, nombre de personnes, tonnes...).
Le salaire du Directeur Général est réparti en fonction du chiffre d'affaires

de chaque produit, les coûts du service facturation sont répartis au prorata
du nombre de factures émises par produit etc...
L'écriture comptable (débit ou crédit) a une devise "originale" et
éventuellement une ou des devises de références (facture en dollars et
convertie en francs à un taux déterminé).
Afin de permettre un accès direct à des comparaisons de dépenses
prévues (budget), engagées (commandées), réalisées (facturées ou
comptabilisées) entre une période comptable ou une autre, des cumuls des
écritures comptables sont mémorisées. Les montants sont d'un type donné
(budget prévu, réactualisé, ré-réactualisé, commandé, facturé, encaissé).
Les cumuls sont mémorisés pour un type de montant et une période (année
N, N-1, etc.).
Un compte analytique est la composition des critères sur laquelle un
cumul de montant d'écriture sera mémorisé.
Le modèle de données final est le suivant :
ECRITURE 1,1 0,N COMPTE 1,N 0,N CRITERE

concerne ANALYTIQUE ANALYTIQUE
combiner
1,1
1,1
1,N
concerne TYPE DE
MONTANT 0,N
cumuler
0,N
0,N
concerne PERIODE
0,N ANALYTIQUE
Une structure de compte analytique peut être définie à l'aide de liens de

compte. Elle permet la mémorisation des cumuls de comptes analytiques.
CHAPITRE IX SOLUTION DES EXERCICES
Viser à l'ensemble et se mettre à l'œuvre

par les détails.
1 CONCEPTUEL
1.1 MCC
1 : un message est un flux d'information.
2 : penser n'est pas un domaine. Pourquoi penser ?
3 : "We demand" signifie "nous exigeons". C'est donc un message
enclencheur ou stimulant.
4 : non, message enclencheur. L'émetteur espère une réponse immédiate à
sa demande de paiement.
5 : oui, le message est informant. La réponse au tract électoral viendra le
jour du vote.
6 : La facture est un flux d'informations pour le client ou le fournisseur et un
flux réel pour l'imprimeur des factures.
1.2 MCT
1 : non. Toute opération conceptuelle est effectuée par un intervenant.
2 : non. Une opération conceptuelle est effectuée par un seul intervenant,
sinon plusieurs intervenants rempliraient une fonction commune.
3 : non. Un message est événement d'une opération conceptuelle au
maximum. Eclater le message en plusieurs messages conceptuels.
4 : oui et le message résultat est envoyé à un même intervenant.
5 : non. La synchronisation provient de l'organisation (même support
physique de deux messages conceptuels). Elle est à proscrire au niveau
conceptuel.
1.3 MCD
1. "événement" est une relation binaire. "résultat" est une relation
ternaire reliant les 3 individus "opération", "message" et "condition".
demande de produit de s ubs titution pas de coke en s tock

ordre de réapprovis ionnement coke en stock
ordre de livraison CONDITION
MESSAGE
0,N
0,N 0,N résultat
0,N OPERATION
événement
0,1
2 : un auteur écrit un ouvrage, le contenu d'un livre. Le prêt concerne un

exemplaire physique de livre ou d'ouvrage.

de
0,N 0,N
AUTEUR prêter PRET
éc rire
date de retour 1,N
1,N
3 : une personne présente un à N symptômes. Les symptômes sont

typiques de zéro à N maladies (pathologies). Une maladie est typée par un
à N symptômes.
La consultation est faite par un médecin. "Consultation" est un individu
car les historiques des consultations sont gérés.
Imaginaire Knoc k
Malade Consultation Médec in

1,1 1,1 0,N
0,N
Consultation est un individu

Un diagnostic suit une ou plusieurs consultations. Il identifie toujours une
maladie au minimum.
Une contrainte existe sur ce modèle. Les diagnostics de plusieurs
consultations concernent tous la même personne.
1,N 0,N
PERSONNE SYMPTOMES
présenter
0,N 0,N
DIAGNOSTIC
1,N
1,N typer
avoir
1,1 0,1 1,N
CONSULTATION
0,N MALADIE
MEDECIN
faire
1,1 0,N
4:
OCCURRENCE D'INDIVIDUNombre de pattes parent Fils de...
Pierre 3 0
Marie 1 1
François 0 2
Paul 0 1
François est fils de Pierre et de Marie qui sont père et fille.
2 ORGANISATIONNEL.
Question 1 : La réunion des personnes peut être considérée comme poste
de travail quand une opération est effectuée.
Question 2 : Organigramme allemand avec directoire. Un poste de travail
peut être constitué de plusieurs postes de travail et être relié à plusieurs
personnes.
Question 3 : procédure de vote. Le secrétariat vérifie l'identité à partir d'une

pièce d'identité et donne les bulletins de vote. La carte d'électeur n'est pas
obligatoire. Le président est chargé de surveiller l'isoloir et examine les
deux pièces, la carte d'électeur (C. E.) et la pièce d'identité (P. I). Il les
donne ensuite au "1er assesseur". Si la carte d'électeur est absente, il
déclare nom et prénom à l'assesseur qui tient le registre (le 2ème). Sinon, il
déclare le numéro de la carte d'électeur. Le 2ème assesseur recherche
l'électeur sur le registre et indique son nom, son prénom et son adresse au
1er assesseur. Celui-ci déclare "peut voter" à l'aide des pièces si tout est
OK. Alors, l'électeur remet son bulletin sous enveloppe dans l'urne et le
président déclare "a voté". Le 2ème assesseur signe le registre, le 1er
tamponne la carte d'électeur et remet les pièces à l'électeur.
Citoyen Secrétariat 1er assesseur Président 2ème assesseur
demande de vote
Examen
identité
refus de vote
Surveiller isoloir
bulletin de vote
incident
demande de revoter
Pièce Identité (+ Carte Electeur)
demande de dépôt
bulletin dans l'urne
Examiner identité
refus de vote no carte ou nom...
P.I (+ C. E)
Examiner registre
Nom, prénom...
Examiner identité
refus de vote
KO peut voter
demande de dépôt
bulletin dans l'urne
Examen du vote
a voté
Tamponner
carte électeur
carte électeur Signer registre
tamponnée
Vous venez
dépouiller ?
3 Logique
MLD : dessin d'une partie de MLD bibliothèque. Les individus se
transforment en enregistrement. Les relations "écrire" et "de", non
porteuses d'information, se transforment chacune en 2 chemins. La relation
"prêter exemplaire", porteuse d'information, se transforme en 3 chemins et
un enregistrement.
N
OUVRAGE EXEMPLAIRE
1 1 PRETER
EXEMPLAIRE
N N
N
N
AUTEUR PRET
MLT Minitel : Recherche d'un numéro de téléphone. Nous laissons le soin au

lecteur de se servir d'un MINITEL pour vérifier le résultat.
Saisie des caractéristiques

Envoi avec abonné Envoi sans abonné
Affichage des numéros Pas d'abonné
suite c orrec tion Guide + Elargir c orrec tion

MLT simplifié de l'outil : interrogation des abonnés.
Nom Saisie obligatoire

Rubrique Saisie obligatoire
Localité Saisie obligatoire
Département Saisie facultative

Adresse Saisie facultative
Prénom Saisie facultative
Etat "saisie des caractéristiques"
4 Physique
MPD : dessin d'une partie de MLD bibliothèque en relationnel.
Les individus se transforment en enregistrement. Les relations "écrire" et
"prêter exemplaire", porteuses d'information, de pattes de cardinalités
maximales N et N se transforment en table. La relation "de" de patte de
cardinalités maximales 1 et N entraîne la redondance de l'information "réf.
ouvrage" dans l'enregistrement "exemplaire".
OUVRAGE EXEMPLAIRE AUTEUR PRET
réf ouvrage réf exemplaire réf ouvrage réf auteur réf prêt
ECRIRE PRETER EXEMPLAIRE

réf ouvrage réf auteur réf exemplaire réf prêt date retour
MPD : dessin d'une partie de MLD bibliothèque en navigationnel.

Les individus se transforment en enregistrement. Les relations "écrire" et
"prêter exemplaire", porteuses d'information, de pattes de cardinalités
maximales N et N se transforment en enregistrement et 2 liens physiques
"pointant" vers les enregistrements créés.
La relation "de" de patte de cardinalités maximales 1 et N se transforme en
1 lien physique d'"ouvrage" vers "exemplaire".
EXEMPLAIRE PRETER
ECRIRE OUVRAGE
EXEMPLAIRE
AUTEUR PRET
5 RESUME
Traitement :
1 : Non, un outil informatique dépend de l'organisation. Il sera à la
disposition d'un ou de plusieurs postes de travail.
2 : Oui. Un système se décompose en sous-systèmes. Quelle est la

différence entre un système et un sous-système ?
3 : Non, il effectue aussi des opérations organisées. Tout poste de travail
effectue des opérations organisées.
4 : Non, tout poste de travail effectue aussi tout ou partie d'opérations
conceptuelles. Il remplit certaines fonctions de l'entreprise.
5 : La réponse est oui, mais quelle est la question ?
6 : Oui, toute opération conceptuelle est effectuée par une fonction majeure
de l'entreprise, un domaine ou un sous-domaine.
CHAPITRE X : Exercices
Deux touches pour les yeux et voilà le dragon

dessiné qui s'anime.
Ce cas concerne l'étude d'une bibliothèque dont l'activité principale
consiste à prêter des livres à des abonnés. Elle gère d'autres activités
comme l'achat de livres à des éditeurs ou la reliure chez des relieurs. La
bibliothèque est subventionnée et les abonnés ne payent pas de cotisation.
Les règles de fonctionnement sont les suivantes :
 Tous les abonnés sont acceptés et tous les livres empruntables.
 Les employés de la bibliothèque déterminent les numéros des livres que
les abonnés souhaitent emprunter.
 Les livres disponibles sont remis aux abonnés dans la limite d'un nombre
maximal de livres empruntables fixé à 5.
 La durée maximale du prêt dépend du titre emprunté. Lorsque cette
durée est dépassée, une relance est faite auprès des abonnés.
 Les livres neufs, issus des propositions des abonnés (éventuellement
enrichis d'autres titres), sont commandés aux éditeurs.
 Les livres les plus usagés sont détruits, les réparables sont envoyés chez
un relieur.
 Les commandes (aux éditeurs et aux relieurs) sont suivies et une relance
est effectuée dès que la date de livraison prévue est dépassée d'une
semaine.
1 MODELE CONCEPTUEL
1.1 Modèle conceptuel de communication

1.1.1 Intervenants : partenaires et domaines
Les intervenants externes, les partenaires de la bibliothèque sont :
Abonné, Relieur, Editeur, Mécène (bibliothèque est subventionnée). Des
partenaires non représentés tels que banque ou Etat existent également.
Les intervenants internes à la bibliothèque sont :
Prêter les livres, domaine qui se décompose en trois sous-domaines :
 prêter les livres assure une bonne rotation des livres prêtés, récupère les
livres prêtés...
 enrichir la bibliothèque conseille le choix de lecture aux abonnés,
commande les nouveautés.
 entretenir les livres s'assure de leur bon état, les fait relier, les met au
pilon, les recommande aux éditeurs s'ils sont irrécupérables.
Un deuxième domaine est d'Assurer l'équilibre financier de la Bibliothèque
qui trouve les dons pour la bibliothèque, fixe des budgets pour les
commandes aux éditeurs et aux relieurs...
Lecteur BIBLIOTHEQUE
Prêter les livres
Prêter les livres

Editeur
Entretenir
les livres
Enrichir la
Bibliothèque
Relieur
A ssurer l'équilibre
financier
Mécène
INTERVENANTS de la bibliothèque
Le domaine prêter les livres et les partenaires associés Abonné, Editeur et
Relieur sont développés pour la suite de l'étude.
1.1.2 Flux
Flux réels. Les flux réels sont les flux de livres. Pour clarifier le propos, les
autres flux réels (flux d'argent tels que le don du mécène ou le paiement
des livres) ne sont pas représentés.
Le modèle indique qu'entretenir est responsable de la commande des livres
neufs et remplace les livres usagés. Un autre choix possible est de ne pas
considérer le flux de livres neufs entre Entretenir et l'éditeur, Enrichir la
bibliothèque se chargeant d'effectuer toutes les commandes.
Prêter les
Livre Prêté livres
Abonné Livre Rendu
Prêter les livres
Enrichir la
Livre Neuf
Bibliothèque
Editeur Livre Neuf
Entretenir
Livre Usagé
les livres
Relieur Livre Relié
FLUX REELS
Messages ou Flux d'informations.
Demande d'abonnement
Demande de prêt
Retour de prêt
Abonné
Demande de restitution
de livre
Prêter les
Prêt accordé livres
Abonnement
Commande relieur
Entretenir Tarif reliure Relieur
Conseil de lecture
les livres Facture relieur
Demande de Enrichir la Commande éditeur

Bibliothèque Commande éditeur
Conseil de lecture Catalogue Editeur
Facture éditeur
MCC de la bibliothèque : les messages

Sous-domaine "Prêter les livres"
Messages de l'Abonné vers Prêter les livres (informations entre
parenthèses) :
Demande d'abonnement (Nom Personne, Prénom, Adresse)
Demande de prêt (Titre de l'ouvrage, Auteur, Thème)
Retour de prêt (Numéro de livre, Date de retour réelle du livre)
Messages de Prêter les livres vers l'Abonné :
Abonnement accepté (Numéro d'abonné)
Prêt accordé (numéro de livre, date de retour maximum du livre, date du
prêt, numéro de prêt)
Demande de restitution de livre (numéro de livre, date de retour
maximum du livre, date de la relance, numéro de prêt)
Sous-domaine "Enrichir la Bibliothèque"
Message de l'Abonné vers Enrichir :
Demande de conseil de lecture (Auteur, Thème)
Message de Enrichir vers l'Abonné :
Conseil de lecture (Titre de livre, Auteur, date de disponibilité de livre)
Messages de l'Editeur vers Enrichir :
Catalogue (Titre de l'ouvrage, Auteur, Thème, Prix unitaire)
Facture Editeur (Référence éditeur, Prix unitaire, quantité commandée,
Taux TVA, Total facture TTC)
Message de Enrichir vers l'Editeur :
Commande à l'éditeur (Référence éditeur, Prix unitaire, quantité
commandée, date de la commande)
Sous-domaine "Entretenir"
Messages du Relieur vers Entretenir :
Tarif reliure (Type de Prestation, Prix unitaire)
Facture Relieur (Prestation, Référence livre, Prix unitaire, quantité reliée,
Taux TVA, Total facture TTC)
Message de Entretenir vers Relieur :
Commande au Relieur (Prestation, Référence livre, Date de la

commande, date de disponibilité de livre)
Message de Entretenir vers l'Editeur :
Commande à l'éditeur (Référence éditeur, Prix unitaire, quantité
commandée, date de la commande)
1.1.3 Epuration du vocabulaire.
L'épuration du vocabulaire consiste à reprendre les informations des
messages, éliminer les synonymes, les équivalences et les polysèmes,
déterminer les informations composées et les règles de calcul.
INFORMATIONS en vrac, vocabulaire à épurer :
Nom Personne, Prénom, Adresse
Titre de l'ouvrage, Auteur, Thème
Numéro d'abonné
Numéro de livre, date de retour maximum du livre, date du prêt du message
Prêt accordé
Date de retour réelle du livre du message Retour de prêt de l'abonné vers
prêter les livres
Numéro de livre, date de retour maximum du livre, date de la relance du
message Demande de restitution de livre
Titre de livre, date de disponibilité de livre du message Conseil de lecture de
l'Abonné vers Enrichir.
Titre de l'ouvrage, Auteur, Thème, Prix unitaire, du message Catalogue
entre l'Editeur et Enrichir conceptuellement la Bibliothèque.
Référence éditeur, Prix unitaire, quantité commandée, Taux TVA, Total
facture TTC du message Facture éditeur entre Editeur et Enrichir
Type de Prestation, Prix unitaire du message Tarif reliure de Relieur vers
Entretenir.
Prestation, Référence livre, Prix unitaire, quantité reliée, Taux TVA, Total
facture TTC du message Facture Relieur vers Entretenir.
Référence éditeur, Prix unitaire, quantité commandée, date de la
commande du message Commande à l'éditeur d'Enrichir.
Prestation, Référence livre, Date de la commande, date de disponibilité de
livre du message Commande au relieur d'Entretenir.
Référence éditeur, Prix unitaire, quantité commandée, date de la
commande du message Commande à l'éditeur d'Enrichir ou Entretenir.
Informations épurées.
Informations sans-souci :
Ces informations n'apparaissent qu'une seule fois ou possèdent la même
signification dans différents messages.
Nom Personne, Prénom, Adresse, Titre de l'ouvrage, Auteur, Thème,
Numéro d'abonné, numéro de livre, date du prêt, Date de retour réelle du
livre, date de la relance, Prestation, Référence livre (de la bibliothèque),
Référence éditeur, quantité reliée.
Informations à équivaloir (synonymes de) :
Date de disponibilité de livre et date de retour maximum du livre. Ces
informations ont strictement la même signification. "Date de disponibilité
du livre" est à remplacer par "date de retour maximum du livre".
Titre de livre et titre de l'ouvrage : ces informations n'ont pas exactement la

même définition. Un titre de livre est un titre d'ouvrage d'un exemplaire
physique de livre déterminé. Un ouvrage écrit mais non publié ou non
acheté par la bibliothèque a un titre d'ouvrage mais pas de titre de livre.
La notion de titre d'ouvrage est plus grande que la notion de titre de livre.
Titre de livre est un sous-ensemble
Information en d'un titre d'ouvrage.
AMONT : Titre d'ouvrage
entrée de règle
EQUIVALENCE
Titre D'ouvrage REGLE DE
TITRE DEAmont
LIVRE / TITRE D'OUVRAGE Titre De Livre
CALCUL
aval
Information calculée
AVAL : Titre de livre en sortie de règle
Equivalence et règle de calcul

Informations obtenues à partir de règles de calcul.
Les informations en sortie résultent de traitement des informations en
entrée par la règle. L'information "date de retour maximum du livre" est
calculée à partir de la "date du prêt" et d'une autre information, la "durée
autorisée d'un prêt".
Le Total facture TTC est calculé à partir des quantités unitaires, des prix
unitaires et du taux de TVA : ce calcul peut être décrit de façon grossière :
Prix Unitaire
durée autorisée date du Taux TVA
Quantité
d'un prêt prêt
calcul de la date de calcul du montant
retour maximum du livre total de la facture TTC
date de retour Total facture TTC

maximum du livre
ou de façon détaillée :
Prix quantité Total ligne Total Taux TVA

unitaire de facture facture HT
calcul du montant calcul du montant calcul du montant
ligne de facture HT total de la facture HT total de la facture TTC
Total ligne de facture Total facture HT Total facture TTC
Règles de calcul détaillées

Informations à séparer (polysèmes).
Prix unitaire, des messages Catalogue, tarif reliure, Facture Relieur.
Cette information est à éclater en prix unitaire facture relieur, facture
éditeur, catalogue éditeur, tarif relieur.
Date de la commande des messages Commande au relieur et Commande à
l'éditeur.
Date de disponibilité de livre des messages Conseil de lecture et
Commande au relieur. Cette information, qui se trouve dans deux mes-
sages, a deux significations : date de livraison souhaitée pour l'éditeur et
date de retour maximum. Nous avions le cas d'une information polysème et
synonyme d'une autre information.
1.2 Modèle conceptuel de traitement
Le modèle de communication à développer pour expliciter le sous-domaine

"prêter les livres" est le suivant :
Demande d'abonnement
Demande de prêt
Retour de prêt
Abonné
Demande de restitution de livre

Prêt accordé Prêter les livres
Abonnement
MCC partiel (d'un sous-domaine)

Opérations et messages associés (événement et résultat).
Quatre opérations concernent ce sous-domaine :
Demande
de prêt
TRAITER DEMANDE DE PRET RECUPERER

abonné LIVRE
non
pas de livre livre à
abonné à restituer
si livre à rendre
restituer
livre disponible
Demande de
Abonnement restitution de livre
Retour de prêt
Prêt accordé
Demande de restitution de livre

PRISE EN COMPTE
Demande
RETOUR DE PRET
d'abonnement
toujours
ABONNER
Demande inspection
PERSONNE
du livre
toujours
Abonnement
MCT du sous-domaine PRETER LES LIVRES

- Traiter les demandes de prêt.
Cette opération est enclenchée à réception du message de l'abonné, la
demande de prêt. Si la personne n'est pas abonnée, elle est systéma -
tiquement abonnée. La bibliothèque est large et généreuse. Pas de coti -
sation, ni de parrainage. Si la personne est abonnée, elle peut avoir un ou
plusieurs livres à rendre, dont la date de restitution est dépassée. Dans ce
cas, une demande de restitution de livres est effectuée. Si elle n'a pas de
livre à restituer et si un livre demandé est disponible, un message de prêt
accordé est émis vers l'abonné.
- Récupérer livre.
Cette opération est décidée. Elle consiste à inspecter les livres non rendus
et dont le prêt est arrivé à échéance. Le message résultat est la demande
de restitution du livre.
- Abonner personne.
Cette opération est enclenchée à réception du message de l'abonné, la
demande d'abonnement. Si la personne n'est pas abonnée, elle est
systématiquement abonnée. La bibliothèque est large et généreuse. Pas de
cotisation, ni de parrainage.
- Prise en compte du retour de prêt.
Cette opération est enclenchée à réception du message de l'abonné, Retour
de prêt. Elle consiste à "enregistrer" le retour du ou des livres et à émettre
une demande d'inspection de l'état du livre au sous-domaine entretenir. Ce
message est nouveau. Il sera répertorié sur le modèle conceptuel de
communication.
1.3 Modèle conceptuel de données

1.3.1 Individus et relations
Différence entre "ouvrage" et "exemplaire". Un exemplaire est un livre
physique, un ouvrage est un livre écrit par un auteur, le contenu.
"Prêt" est un individu. Un même exemplaire peut être prêté 2 fois au même
abonné. Les prêts échus font partie de la gestion d'une bibliothèque. Par
contre, les demandes de prêts ne sont pas gérées.
PERSONNE PRET EXEMPLAIRE

nom abonné
prénom abonné date du prêt date destruc tion
adresse abonné
Prêt est un concept à individualiser

Que gère la bibliothèque, des ouvrages édités ou des ouvrages d'auteur ?
Un "ouvrage édité" est un ouvrage valable dans une collection. "Les trois
Mousquetaires" en collection de poche est un ouvrage différent des "Trois
Mousquetaires" en collection de luxe. Les commandes aux éditeurs
concernent les "ouvrages édités". Les exemplaires sont des exemplaires
physiques identiques d'un même ouvrage.
Les individus et leurs informations sont :
OUVRAGE 1,1
EXEMPLAIRE
0,N 1,N 0,N
GENRE
titre ouvrage
nom genre durée autorisée date destruc tion
1,N c ollec tion
1,N 0,1
0,N 0,N
AUTEUR 0,N
livrer prêter livre
nom auteur
prénom auteur exemplaire date retour
1,N 1,N 1,N

COMMANDE COMMANDE PRET
EDITEUR 0,N RELIEUR
date du prêt
date c ommande date c ommande
éditeur relieur
1,1
1,1 1,1
0,N
0,N 0,N
EDITEUR RELIEUR PERSONNE

nom relieur nom abonné
nom éditeur
adresse relieur prénom abonné
adresse éditeur
adresse abonné
MCD 1 les individus sont dépliés...

Comment obtient-on un modèle replié ?
Editeur, relieur et fournisseur. Pourquoi la bibliothèque gère-t-elle les
individus "Editeur" et "Relieur" ? En temps que "fournisseur". Les individus
"éditeur" et "relieur" deviennent l'individu "fournisseur" qui peut être de
plusieurs types. Un éditeur peut être relieur. Si un fournisseur est soit
éditeur, soit relieur, "type de fournisseur (relieur/éditeur)" est une
information de l'individu "fournisseur".
Critère de choix, type de critère et paramètre. Pourquoi la bibliothèque
gère-t-elle les individus "Auteur" et "Genre" ? Pour répondre aux abonnés
quand ils demandent un ouvrage ou pour établir des moyennes de lecture.
Les livres de tel auteur ou de tel genre (roman policier) sont les plus
demandés. Ces deux individus sont des occurrences de l'individu "Critère de
choix". Genre et Auteur sont des occurrences de l'individu "Type de critère".
Ainsi, la couleur du livre, l'éditeur, et tout autre idée peuvent devenir des
critères de choix.
L'information "durée autorisée" de l'individu "ouvrage" peut être gérée
par un individu "paramètre". Ainsi, il sera possible de déterminer cette
durée en fonction du genre ou de l'auteur.
eyrolles éditeur
couleur
jaune
thème
jeux
nom auteur
aventure
0,N
Victor Hugo TYPE DE
CRITERE
CRITERE 0,N réf. type c ritère
DE CHOIX libellé type c ritère
réf. c ritère
libellé c ritère autoriser
durée autorisée
valoriser
0,1 valeur 0,N PARAMETRE
avoir
réf. paramètre
1,N OUVRAGE 0,N libellé param.
0,N
0,N titre ouvrage
c ollec tion ouvrage
éditer 1,1
0,N 0,N
livrer EXEMPLAIRE
0,N
COMMANDE exemplaire livre prêté
réf. exemplaire
date retour
date destruc tion
date c ommande 0,N relier livre
1,N
date livraison exemplaire
PRET
1,1
date prêt
0,1 0,N
FOURNISSEUR 1,1
TYPE PERSONNE
nom fournisseur 1,N typer 0,N FOURNISSEUR nom abonné
adresse fournisseur fournisseur libellé type prénom abonné
délai de relanc e
fournisseur adresse abonné
0,N
MCD 2 les individus sont repliés...
1.3.2 Informations de relation

Les informations des relations sont : type de prestation de "Relier
exemplaire", date de retour de "livre prêté" et valeur de "valoriser".
Il convient de reprendre les informations des messages afin de séparer les
concepts "référence exemplaire" et "référence ouvrage".
1.4 Validation MCD/MCT.

Toutes les informations nécessaires aux opérations sont-elles disponibles ?
Toutes les informations de l'opération décidée (sans message événement)
relance fournisseur sont-elles disponibles ? Le délai de relance du
fournisseur manque. Les bons fournisseurs sont relancés plus tard que les
inconnus. Une nouvelle information apparaît sur l'individu "fournisseur".
Tous les individus, relations et informations du MCD sont-ils créés et
consultés ? Validation à effectuer.
2. NIVEAU ORGANISATIONNEL
2.1 MODELE ORGANISATIONNEL DE TRAITEMENT

2.1.1 Liste des postes de travail et des procédures.
Les postes de travail sont multi-domaines, ils concernent Gérer les livres et
Assurer l'équilibre financier. Ils ont été choisis dans une organisation
spécialisée pour les besoins de l'exemple. Ils sont :
Accueil de la clientèle : administratif, responsable des abonnements et de
l'orientation des abonnés.
Bibliothécaire : aide au choix de l'ouvrage, remplit les commandes,

réceptionne les livres des éditeurs.
Chef encaisse les dons du mécène, règle les factures fournisseurs, signe les
bons de commande et vérifie les dépenses engagées vis-à-vis du budget,
réceptionne et règle les factures éditeurs et relieurs.
Magasinier responsable du stock, déballe et range les livres, met à
disposition les livres demandés, réceptionne les livres reliés.
L'organigramme est :
C hef
Bibliothécaire Accueil
Magasinier
Postes de travail de la bibliothèque.
Liste des procédures ou MOT

Six procédures sont retenues. La procédure Budget ne fait pas partie du
domaine Prêter les livres. De manière organisée, le budget sera décidé pour
fixer les limites des commandes.
Les procédures sont : Prêt - Demande Abonnement - Rendu des livres -
Achat éditeur - Commande relieur - Budget
Les procédures précédentes sont détaillées. Les trois procédures Prêt,
Demande d'abonnement et Rendu des livres pourraient être regroupées en
une seule. Le choix de la "longueur" d'une procédure appartient à
l'utilisateur final.
2.1.2 Exemple de procédure ou de MOT.
Que fait la Bibliothèque et qui fait quoi quand un abonné demande un prêt ?
La réponse est décrite à l'aide du MOT ou de la procédure suivante.
ABONNE AC C U E IL MAGASINIER CHEF
demande
de prêt
Examen demande de prêt
+5 non livre non tout
livres abonné disponible O K demande de sortie
refus des livres
de prêt
autre Rechercher
guic het les livres
KO OK
disponibilité
du livre
livre introuvable
Annoncer indisponibilité
toujours
désolé,
pas de livre
livre à disposition
Prise en charge Prêt

M
toujours
Inventaire
ac c ord
de prêt
livres
manquants
PROCEDURE OU MOT "DEMANDE DE PRET"

Sur cette procédure apparaissent des messages typiquement organisés tel
que "autre guichet" et une opération temporisée - ici mensuellement - ,
l'inventaire. La procédure devrait continuer : quelle est la réaction du chef si
des livres manquent ?
La vérification de l'opération organisée "Examen de la demande de prêt"
avec son équivalent conceptuel "traiter demande de prêt" entraîne la
création d'un message résultat supplémentaire oublié, la "demande de
restitution de livres".
2.2 Modèles organisationnels de données.

- Sites.
2 sites de données pourraient être envisagés. Un site de données servant
de base d'interrogation des livres pour les abonnés et un site propre à la
gestion de la bibliothèque. Un seul est retenu pour le cas.
- Individus et relations.
Les individus et les relations sont les mêmes qu'au niveau conceptuel.
- Informations
Les informations sont les mêmes qu'au niveau conceptuel.
2.3 Modèle organisationnel de communication

- Sites : un seul site, donc pas de communication.
3. NIVEAUX LOGIQUE ET PHYSIQUE
3.1 Liste des outils informatiques par procédure

PROCEDURE PRET. Les opérations organisées sur le MOT précédent ont à
disposition les outils suivants :
Opération "examen de la demande de prêt" : outils consultation abonné,
modification abonné, consultation des titres et de leur disponibilité,
consultation des abonnés, calcul du nombre de livres empruntés.
Opération "rechercher les livres" : outils échelle, tenue du stock en
rayonnage affecté, les livres dans l'ordre de leur numéros.
Opération "annoncer indisponibilité" : pas d'outil, sinon la diplomatie !
Opération "prise en charge du prêt" : outil Enregistrement d'un prêt.
Les outils informatiques sont donc, pour cette procédure : Consultation
abonné, Modification abonné, Consultation des titres, des livres et de leur
disponibilité, Enregistrement d'un prêt, Consultation des abonnés,
Consultation des prêts non soldés.
Autres procédures. Les opérations organisées des autres procédures sont
aussi dotées de moyens informatiques à disposition des postes de travail,
bibliothécaire, accueil... Les outils de chaque procédure sont explicités ci-
après afin d'en dresser une liste exhaustive et d'en déduire une
planification.
PROCEDURE DEMANDE D'ABONNEMENT : création abonné, édition de la
fiche abonné
PROCEDURE RENDU LIVRES : relancer les abonnés pour prêts non rendus
(TD)
PROCEDURE ACHAT EDITEUR, enregistrer les commandes éditeurs, relancer
les éditeurs pour livraison (TD), consultation des commandes éditeurs,
consultation de base de données éditeur. commande par Minitel aux
éditeurs, enregistrer les exemplaires livrés., consultation des types de livres
lus par les abonnés.
PROCEDURE ACHAT RELIEUR : création de commande au relieur, relance des
relieurs pour livraison (TD), consultation des commandes relieurs,
consultation de la durée moyenne de vie des livres en fonction des éditeurs.
PROCEDURE BUDGET : consultation des commandes éditeurs, consultation
des commandes relieurs.
3.2 Validation liste des outils / MOD et planification.

Tous les individus, relations et informations sont-ils créés et lus par un
outil ? Les individus critère de choix, type de critère et les relations autour
de critère seront créés par l'outil nouveau création des ouvrages. Les
individus "fournisseur", "type de fournisseur" seront créés par un nouvel
outil "création des fournisseurs". L'individu "paramètre" et la relation
"paramètre/type de critère" seront créés par un nouvel outil "création des
paramètres".
Planification. 22 outils sont identifiés. 17 peuvent être qualifiés de simples à
spécifier et 5, ceux qui tournent autour d'ouvrage et critères, sont de
complexité moyenne. Le temps nécessaire à la spécification externe
(enchaînement des états, description des informations et validation par
l'utilisateur) et interne (actions sur le MLD et description de l'obtention des
informations) est estimé à :
17x2 + 5x5 = 59 jours, soit 3 mois environ. La réalisation sur micro-
ordinateur est estimée à 3 mois aussi.
3.3 Modèle physique de données

Le modèle physique retenu pour cet exemple est le modèle relationnel,
celui-ci étant appelé à se développer de plus en plus. Les enregistrements
ou tables sont composés d'informations et d'une clé. La clé est cernée de
trait gras. Si deux informations sont dans un même rectangle, la clé est la
composition de ces deux informations.
Tous les individus se transforment en enregistrements.
Les relations autoriser et valoriser entre les individus "type de critère",
"critère de choix" et "paramètre" sont des relations NN et se transforment
en enregistrements.
type de critère réf. type c ritère libellé type c ritère
critère de choix réf. c ritère libellé c ritère réf. type c ritère réf.fournisseur
paramètre réf. paramètre libellé paramètre
autoriser réf. paramètre, réf. type de c ritère
valoriser réf. paramètre, réf. c ritère valeur paramètre
Les relations "ouvrage commandé", "relier exemplaire" et "typer

fournisseur" entre les individus "commande", "ouvrage", "exemplaire",
"fournisseur" et "type de fournisseur" sont des relations NN et se
transforment en enregistrements.
commande no c ommandedate c ommanderéf. fournisseur
ouvrage réf. ouvrage titre ouvrage c ollec tion ouvrage
ouvrage commandé relier exemplaire

numéro c ommande, réf. ouvrage numéro c ommande, réf. exemplaire type prestation
fournisseur
réf. fournisseur nom fournisseur adresse fournisseur délai de relance
type de fournisseur typer fournisseur

réf. type fournisseur libellé type fournisseur réf fournisseur, réf. type fournisseur
Les relations "choisir" et "prêter livre" entre les individus "ouvrage",

"critère de choix", "exemplaire" et "prêt" sont des relations NN et se
transforment en enregistrements.
personne
no abonné nom abonné prénom abonné adresse abonné nb livres empruntés
prêter livre numéro de prêt, réf. exemplaire date retour livre
prêt numéro prêt date prêt no abonné choisir réf. ouvrage, réf. c ritère
exemplaire réf. exemplaire date destruc tion réf. ouvrage réf. c de éditeur
Chemins. Tous les chemins provenant de pattes sont conservés sauf le

chemin de fournisseur à critère de choix qui n'est pas retenu. Il n'est pas
intéressant de connaître le numéro de critère de choix d'un fournisseur.
L'information référence du critère n'est pas dans l'enregistrement

Fournisseur.
Informations. Les informations des individus et des relations se retrouvent
dans les enregistrements dérivés.
L'information calculée "nombre de livres prêtés à un abonné" est redondée
dans l'enregistrement "personne". L'information "collection de l'ouvrage"
est redondée dans l'enregistrement "ouvrage". On aurait pu redonder le no
d'abonné emprunteur et la date de retour prévisionnelle dans l'exemplaire.
L'information "numéro de prêt", clé de l'enregistrement Prêt est, en général,
choisie comme composition du numéro d'abonné et de la date. Dans une
approche des individus par les informations, ce numéro de prêt n'existe pas
et l'individu prêt n'est pas identifié tout de suite.
L'information "numéro de livre", clé de l'enregistrement Exemplaire est, en
général, choisie comme composition du numéro d'ouvrage et d'un numéro
d'ordre. Dans ce cas, si un exemplaire est détruit, que devient son numéro
d'ordre ?
réf. exemplaire = réf.ouvrage numéro d'ordre
Composition de la référence exemplaire
3.4 Validation liste des outils / MLD.

L'information supplémentaire "nombre de livres empruntés" de
l'enregistrement personne doit être créée ou modifiée par l'outil
"enregistrement prêt".
3.5 Modèle logique de traitement

L'outil traité est "l'enregistrement des prêts".
3.5.1 Spécification externe de l'outil
Saisie des abonnés et des livres

toujours
Affichage et validation
si validation
MLT de l'outil "Enregistrement des prêts"
Date Affi chée

Numéro abonné saisie obligatoire Nom abonné
Nombre de livres empruntés
Numéro de livres Titre ouvrage date de retour
saisie facultative
saisie facultative
saisie facultative
saisie facultative
saisie facultative
1er état de l'outil
Date affi chée

Numéro abonné affi ché Nom abonné affi ché
Nombre de livres empruntés affi ché
Numéro de livres Titre ouvrage date de retour
affi ché affi ché affi chée
Validation O/N saisie
2ème état de l'outil

3.5.2 Spécification interne de l'outil
Action des états de l'outil "Enregistrement des prêts".
A partir du deuxième état, si l'information saisie "validation" est oui, 3
actions de création ou de mise à jour du MLD sont enclenchées.
La première "MAJ du nombre de livres empruntés" met à jour l'information
"nombre de livres empruntés" de l'enregistrement "Personne". La deuxième
"Création d'un prêt" crée toutes les informations "numéro de prêt", "date de
prêt", "numéro abonné" de l'enregistrement "Prêt". La troisième "Création
de livre prêté" crée les informations "référence exemplaire", "numéro de
prêt", de l'enregistrement "Prêter livre".
Utilisons le formalisme individu/relation ou représentons le Méta-Modèle ou
le modèle de données de la spécification interne.
création d'un
livre prété numéro de prêt
Préter livre
création d'un prêt date de prêt
Prêt
maj nombre de nombre de
Personne livres empruntés
livres empruntés
ENREGISTREMENT ACTION INFORMATION
0,N 1,1 1,N 0,N
Méta-modèle des actions du deuxième état sur le MPD

Obtention des informations mises à jour.
Les informations "numéro de prêt", "date du prêt" et "nombre de livres
empruntés" sont des informations mises à jour et non saisies ou affichées
dans l'état. Comment sont-elles obtenues ?
L'information "numéro de prêt" est obtenue par une règle de calcul "dernier
prêt plus un".
L'information "nombre de livres empruntés" est obtenue par une règle de
calcul avec compteur "compter les livres empruntés" d'un abonné.
L'information "date du prêt" est obtenue par une équivalence "date du jour
du prêt". La date du prêt est la date du jour (système) du prêt.
Obtention des informations affichées.
Les informations "titre de l'ouvrage", "date du retour prêt" sont des
informations affichées et non saisies ou affichées dans l'état précédent.
Comment sont-elles obtenues ?
L'information "titre de l'ouvrage" est obtenue par un chemin "titre de

l'exemplaire" qui va de l'information "référence de l'exemplaire" à
l'information "titre ouvrage" via l'information "référence de l'ouvrage".
L'information "date de retour du prêt" est obtenue par une règle de calcul
"calcul de la date de retour du prêt". Cette règle de calcul a été identifiée
lors de l'épuration du vocabulaire.
3.6 Modèle logique de communication

Dans cet exemple, un seul site de mémorisation existe. Aucun message
n'est échangé entre sites ; il n'existe pas de MLC.
CHAPITRE XI 10 critères de choix d'un outil d'aide à la conception
1. Pourquoi choisir un outil d'aide à la conception?

Le choix d'un outil d'aide à la conception s'effectue en étudiant les modèles
de la méthode. Construire le modèle conceptuel de communication permet
de dégager les critères de choix. Rassurons les ingénieurs conseils, ces
outils sont plus des outils du type dessins Assistés par Ordinateur plutôt que
de Conception Assistée par Ordinateur.
L'objectif de la méthode est de "formaliser" les choix de l'utilisateur final en
vu de les faire réaliser informatiquement. Le modèle de communication de
la méthode est le suivant :
demande d'informatisation
FORM ALISER
demande de validation de texte
demande de validation de dessins
maquette à valider
demande de programmation
UTILISER produit informatique PROGRAM M ER
Le MCC de la méthode...
Les partenaires ou les intervenants externes de la méthode sont : UTILISER
l'informatique et PROGRAMMER ou réaliser. MERISE est le langage de
référence entre UTILISER et PROGRAMMER.
Cette découpe entre FORMALISER et PROGRAMMER dépend de l'ampleur de
l'outil et du champ de la méthode. Dans certains cas, la réalisation de
l'informatique peut être comprise dans la méthode. Alors, informatiser
recouvre formaliser et réaliser. C'est la différence entre les ateliers de génie
logiciel appelés "upper case" (jeu de mot de typographe américain), qui
débouchent sur le cahier des charges de réalisation informatique, ou "lower
case", qui comprennent la réalisation informatique. Si vous voulez être
branchés vous pouvez parler de I-Case ou Integrated Case ou monstre sacré
ou C-Case ou Component Case ou case à visage humain. Conserver aussi à
l'esprit qu'aucun outil n'a encore totalement supprimé PROGRAMMER. Des
concepts tels que "règles de calcul", "chemin", "contraintes" doivent être
programmés ainsi qu'une bonne partie des programmes non interactifs ou
par lot.
Les messages échangés entre les différentes fonctions ou domaines suivent
la logique suivante. L'utilisateur exprime son besoin, sa demande
d'informatisation dans les meilleurs cas ou sa solution informatique dans les
pires. Après longue réflexion et moultes changements de demande de
l'utilisateur final, "FORMALISER" formalise et présente la demande de
l'utilisateur sous forme de dessins (les modèles) ou de texte, ses demandes
de validation. L'utilisateur approuve, n'approuve pas ou bien dit qu'il n'y

comprend rien, que cela prend vraiment beaucoup de temps pour pas grand
chose, qu'il ne peut plus vivre comme ça, que cela fait beaucoup de temps
de dépensé pour... un outil que l'on désire seulement simple, convivial,
évolutif et puissant.
Enfin, comme nous discutons d'informatique, après la liste indispensable
des outils informatiques à PROGRAMMER, les maquettes d'outil ou les
enchaînements d'écrans sont présentés. Rappelons que la maquette ne fait
que simuler le comportement de l'informatique. La maquette est une "vue
externe de l'outil". Elle a pour objectif de permettre à l'utilisateur de
prendre encore son temps pour changer d'avis, s'il ne l'a pas encore fait.
La maquette est approuvée. FORMALISER, fort de tout ce qu'il a appris, et
non de ce qu'il a appris à faire (en aucun cas, il ne peut se substituer à
l'utilisateur, même après 20 ans de maison), exprime sa demande de
réalisation à PROGRAMMER. Le produit final, le produit informatique, va de
PROGRAMMER à UTILISER ou peut passer par FORMALISER qui vérifie si la
réalisation est conforme.
2. Quels critères doit-il remplir ?

Le choix d'un outil d'aide à la conception doit remplir les fonctions de
FORMALISER et permettre l'émission des messages précédents. Il
comprendra :
 Un composeur de documents types : MCC, MCD ... maquette, dossier de
réalisation.
 Un "lanceur" de documents à partir de documents types : MCC de la
méthode, MCD "bibliothèque" ou "comptable", dossier de réalisation de
l'outil "création de la commande" etc.
 Une application dessinant les modèles de MERISE sous forme de dessins :
les modèles de données et leurs informations sur le même dessin par
exemple. Les types de dessins représentent les concepts de la méthodes.
 Un maquettage des outils informatiques : enchaînement des écrans,
description des champs des écrans pouvant être modifiés
indépendamment de la structure logique ou physique des donnée.
Il doit aussi respecter certaines règles propres à MERISE ou à d'autres
méthodes :
 Un dictionnaire de données du méta-modèle permettant la composition
de textes ou de documents. Si possible, ce dictionnaire de données doit
respecter les règles de construction des modèles de données : une
occurrence de relation ne peut exister qu'une fois entre les deux mêmes
occurrences d'individus. Si ce dictionnaire peut être partagé entre
plusieurs utilisateurs en même temps (réseau local ou site central), il
vaut de l'or.
 Permettre une validation entre les modèles de données, de traitements et
de communication : il doit pouvoir, en particulier, créer des informations
indépendamment des modèles de données.
Enfin, il doit apporter certaines fonctionnalités:
 Des facilités, telles que la réalisation automatique d'un Modèle Logique
de Données à partir d'un modèle organisationnel ou conceptuel, peuvent
être proposées. Cette facilité n'est pas à surestimer. Rien ne vaut un MLD
créé (et compris) "à la main".
 Une certaine ergonomie (tel que fenêtrage), présenter des temps de
réponse corrects sans exiger un ordinateur du type 786 à 150 Mhz et un
logiciel gourmand peu répandu.
 Générer des applications en langage standard (C ou cobol) et simples à

utiliser sur micro ordinateur.
Si vous voulez tester un atelier, mettez donc des croix, faites le total et
jugez le résultat ! A partir de 5 croix, le résultat est correct.
CRITERES DE CHOIX OK
Messages
Construit des documents types
Edite des documents type : demande de
programmation...
Réalise des dessins MCD, MCC ...
Réalise une maquette
Méthode
Contient un dictionnaire de données (partageable)
Respecte les règles entités relation
Valide les modèles
communication/données/traitements
Fonctionnalités
Génère un MLD
Ergonomie, temps de réponse, simplicité
Génère un code standard sur micro
... détermine les 10 critères de choix.
CHAPITRE XII Exercez-vous (Documents autorisés)
Ce chapitre a pour objectif de vous tester à l'aide d'un questionnaire. En
remplissant rapidement ces quelques grilles, vous pouvez enfin tester vos
connaissances sans acheter Le Nouvel Observateur ou Aujourd'hui Madame.
Vous êtes sensés le remplir le soir dans votre lit pendant que votre fils dort
et que votre femme lit le dernier Cosmopolitan. Le choix de la boisson est
libre mais le crayon à papier est obligatoire.
Enoncé
Ce questionnaire comporte 5 parties : informatique et méthode, les 3
niveaux de MERISE, la gestion de projet, le méta-modèle et un exercice de
construction de modèle de données relationnel. 20 questions sont posées.
La note maximale pour chaque question est indiquée en fin de chapitre. Le
choix de votre note peut être fait suivant votre critère mais vous n'êtes pas
autorisés à dépasser la note maximale.
1. Informatique et méthode
1 A quoi peut bien servir l'informatique ?
2 Quel est le plus difficile en informatique ? Classer par ordre d'importance.
Programmer
connaître le ou la petit(e) ami(e) de l'utilisatrice
(teur)
connaître ce qu'il veut informatiser
documenter ce qui a été programmé
maintenir
structurer les données
dessiner des maquettes d'écrans
3 A quoi sert une méthode comme MERISE ?

2. Les 3 niveaux de MERISE

Le niveau conceptuel
4 Quels sont les objectifs principaux du conceptuel ?
Oui No
n
Connaître le ou la petit(e) ami(e) de
l'utilisatrice (teur)
Connaître l'activité de l'utilisateur
Connaître la perception de l'utilisateur de
son activité à informatiser
Délimiter le champ de l'étude
Définir ce qu'il n'y aura pas à faire
5 Le niveau conceptuel est indépendant de :

Oui No
n
L'informatique
L'organisation
Du PDG
Des utilisateurs finals
L'activité de l'entreprise
Différencier données et traitements

6 Quels sont les verbes à proscrire des activités conceptuelles. Les verbes
du type créer, supprimer, modifier, sélectionner, consulter sont des verbes
de type accès aux données (D) et non des verbes de type traitement (T).
Classer les verbes ci-dessous en fonction de leur penchant Données ou
Traitement
VERBE D T VERBE D T
Gérer Affecter
Assurer Répertorier
Analyser Identifier
Calculer Lister
Prévoir Inscrire
Enregistrer Connaître
Numéroter Attribuer un
numéro
Codifier Suivre
Administrer Diriger
Classer Maîtriser
7 Qu'est-ce qu'un domaine ?

un terrain produisant un grand cru
un ensemble de valeurs possibles d'une

information
une vente aux enchères de l'état
le rêve de tout états-unien (habitant des Etats
Unis)
un ensemble de données et de traitement
un ensemble de fonctions de l'entreprise
un ensemble de propriétés en Argentine
(Hacienda)
8 Les phrases suivantes représentent une activité conceptuelle de
l'entreprise (même philosophie que la question 6) :
D T
analyser les écarts
suivre le déficit
tracer la courbe des excédents
définir des priorités
planifier un projet
gérer des stocks
produire des articles
connaître le client
promouvoir la vente des produits
maîtriser les dépenses
établir des règles
établir des statistiques
9 Une opération conceptuelle peut-elle exister sans message événement ?

Répondre par Oui ou Non.
Le modèle de données
10 Un "individu" au sens MERISE est :

L'histoire d'un mec
Un objet conceptuel
Un ensemble infini d'élément
Un ensemble définit par un identifiant
Une date
11 Quelles sont les caractéristiques spécifiques des relations ?

Elle a besoin des individus pour exister
Elle ne peut contenir des informations
Elle ne peut être reliée à un seul
individu.
12 Comment se construit un MCD ?

A partir des concepts
Des informations
des informations demandées par
l'utilisateur
des fichiers existants
Différencier conceptuel et organisationnel

13 Classer les messages suivants en Conceptuels (C) et Organisationnels
(O) :
C O
demande de XXX
refus de XXX
dossier
exemplaire
ordre interne
reporting
remarque
fiche
feuille rose
formulaire jaune
accord de XXX
14 Quelle est la différence entre une information, une donnée, un attribut et

une propriété ?
Le niveau organisationnel
15 Que définit le niveau organisationnel ? Répondre par Oui (et classer par
ordre de priorité 1, 2, 3...) ou Non.
Oui No
n
Ce qu'il y a à faire
Qui fait quoi
Les volumes des données à
mémoriser
Qui est le chef
La marque du tableur à
acheter
Les domaines de l'entreprise
L'informatique
Les postes de travail
Le salaire du PDG
L'organigramme de l'entreprise
L'activité de l'entreprise
Tous les niveaux

16 Les modèles suivants sont constitués de :
MC MC MCT MO MO MLT MLD
C D T D
Opération
outil
informatique
message
condition
information
poste de
travail
événement
résultat
domaine
sous-domaine
Individu
Relation
Patte
Contrainte
Site
Record
Clé
Etat
Support
Action mise à
jour
Lien
3. Gestion de projet
17 Quand doit être analysé l'existant ?
Oui No
n
juste avant le conceptuel
juste après l'organisationnel
juste avant l'informatique
si on est pressé
lors de la documentation
Quand le chef de projet le demande
18 Quand doit-on programmer ?
Oui No
n
juste après la réunion de
démarrage du projet
juste après la liste des outils
juste après la maquette
après validation de la maquette
après la spécification interne
juste avant le MLD
4. Le méta modèle
19 Mettre des cardinalités sur le modèle de données suivant représentant le
modèle de données de la méthode (le méta-modèle).
Où place-t-on les cardinalités maximales et minimales du modèle de
données (non méta) ?
PATTE RELATION M ESSAGE

Patter relation
patter
événement
épatter info/ relation porter sur
individu INDIVIDU résulter
CONDITION OPERATION
identifier INFORMATION
porter
propriété
5 La génération d'un Modèle relationnel.

20 Passage d'un MCD à un Modèle de données relationnel
Le modèle suivant représente le "suivi" des réclamations des
consommateurs finals. Un réclameur envoie sa réclamation (qualité du
produit, de l'emballage, pas de languette sur le pot, ouvre-boîte n'ouvrant
pas les boîtes de petits pois...) à l'entreprise concernée qui détermine de
quelle usine provient le produit défectueux. Ensuite, une réponse ou une
visite sera accordée au consommateur final. Les réclamations ne touchent
qu'un produit. Ce produit peut appartenir à plusieurs groupes se regroupant
entre eux.
CONSOM M ATEUR 1,N 1,1 RECLAM ATION 1,1 0,N PRODUIT

envoy er date réclamation concerner code produit
nom consom.
prénom consom.
adresse consom. 0,1
0,N 0,N
grouper
être à l'origine de app eler 1,N
1,N GROUPE DE PRODUIT
0,N
USINE REPONSE code groupe produit
code usine date réponse
libellé réponse
composer groupe
0,N être composé de
0,N
regrouper groupe
Construisez le modèle physique de données en relationnel (table, clés et

index).
CORRIGE
1. Informatique et méthode
Question 1 : A quoi sert l'informatique ?
Réponses "sérieuses"
 A automatiser les traitements de l'information
 A économiser de l'argent
 A produire et diffuser des documents
 A éviter des erreurs des utilisateurs
 A donner des autorisations d'accès aux informations
Réponses moins sérieuses :

 A faire passer des examens
 A vendre des livres d'informatique sur MERISE
 A dépenser de l'argent
 A compliquer ce qui ne l'est pas
 A simplifier ce qui est compliqué
 A aider les utilisateurs à réfléchir
 A aider à la promotion des femmes.
 A enrichir les informaticiens
Notez-vous correctement de 0 à 5.
Question 2 (7 points)
Programmer 5
connaître le ou la petit(e) ami(e) de l'utilisatrice 7
(teur)
connaître ce qu'il veut informatiser 1
documenter ce qui a été programmé 4
maintenir 2
structurer les données 3
dessiner des maquettes d'écrans 6
Question 3 : A quoi sert une méthode comme MERISE ? (2 points)

 A connaître ce que veut informatiser l'utilisateur
 Vérifier que sa demande est informatisable.
2. Les 3 niveaux de MERISE

Oui No
n
Connaître le ou la petit(e) ami(e) de X
l'utilisatrice (teur)
Connaître l'activité de l'utilisateur X X
Connaître la perception de l'utilisateur de X
son activité à informatiser
Délimiter le champ de l'étude X
Définir ce qu'il n'y aura pas à faire X
L'objectif est surtout de connaître la perception de l'utilisateur, son réel
perçu, et non son activité
Oui No
n
L'informatique X
L'organisation X
Du PDG X
Des utilisateurs finals X
L'activité de l'entreprise X
Le niveau conceptuel est dépendant du PDG, car il définit la politique de
l'entreprise.
Question 6 : (20 points).

VERBE D T VERBE D T
Gérer X Affecter X
Assurer X Répertorier X
Analyser X Identifier X
Calculer X Lister X
Prévoir X Inscrire X
Enregistre X Connaître X
r
Numérote X Attribuer un X
r numéro
Codifier X Suivre X
Administr X Diriger
er
Classer X Maîtriser X
Pourquoi diriger ?
Question 7 : Qu'est-ce qu'un domaine ? (7 points)
un terrain produisant un grand cru X

un ensemble de valeurs possibles d'une X
information
une vente aux enchères de l'état X
le rêve de tout états-unien (habitant des X
Etats Unis)
un ensemble de données et de traitement X

un ensemble de fonctions de l'entreprise X
un ensemble de propriétés en Argentine X
(Hacienda)
L'important est de répondre un ensemble de données et de traitement. Le
MCD est construit par domaine.
Question 8 : (12 points)

D T
analyser les écarts X
suivre le déficit X
tracer la courbe des X
excédents
définir des priorités X
planifier un projet X
gérer des stocks X
produire des articles X
connaître le client X
promouvoir la vente des X
produits
maîtriser les dépenses X
établir des règles X
établir des statistiques X
Question 9 : une opération conceptuelle peut exister sans message

événement. 5 points.
Question 10. 5 points.

L'histoire d'un mec
Un objet conceptuel X
Un ensemble infini d'élément
Un ensemble définit par un identifiant
Une date
"Date" n'est pas un individu.
Question 11 : 3 points.
Elle a besoin des individus pour exister X
Elle ne peut contenir des informations
Elle ne peut être reliée à un seul
individu.
A partir des concepts X
Des informations
des informations demandées par
l'utilisateur
des fichiers existants
Certaines chapelles font partir le MCD des informations. Surtout, il ne faut

jamais prendre celles demandées par les utilisateurs sans savoir pourquoi.
C O
demande de XXX X
refus de XXX X
dossier X
exemplaire X
ordre interne X X
reporting X
remarque X
fiche X
feuille rose X
formulaire jaune X
accord de XXX X
Question 14 : Aucune différence (1 point)
Question 15 : 14 points. Un pour chaque croix et un de plus pour les

premiers par ordre de priorité.
Oui No
n
Ce qu'il y a à faire X
Qui fait quoi 1
Les volumes des données à 2
mémoriser
Qui est le chef 3
La marque du tableur à X
acheter
Les domaines de l'entreprise X
L'informatique X
Les postes de travail 1
Le salaire du PDG X
L'organigramme de l'entreprise 1
L'activité de l'entreprise X
L'organisationnel ne définit pas le salaire du PDG, mais le type de
rémunération du PDG (qui n'est pas assimilable à un salaire).
Question 16 : 22 points
MC MC MCT MO MO MLT MLD
C D T D
Opération X X
outil X X
informatique
message X X X
condition X X X
information X X X X X X X
poste de travail X
événement X X
résultat X X
domaine X X X
Partenaire X X X
sous-domaine X X
Individu X X
Relation X X
Patte X X
Contrainte X X
Site X X X
Record X X
Clé X
Etat X
Support X
Action mise à X
jour
Lien X
3. Gestion de projet
Question 17 : 12 points, 2 par croix.

Oui No
n
juste avant le conceptuel X
juste après l'organisationnel X
juste avant l'informatique X
si on est pressé X
lors de la documentation X
Quand le chef de projet le demande X
Si vous êtes pressés, n'utilisez pas une méthode, vous n'en aurez pas le
temps, sinon avant l'organisationnel. Ne soyez donc pas si pressés.
Oui No
n
juste après la réunion de X
démarrage du projet
juste après la liste des outils X
juste après la maquette X
après validation de la maquette X
après la spécification interne X
juste avant le MLD X
4. Le méta-modèle
Question 19 Les cardinalités maximales et minimales du modèle de
données
Elles sont dans la relation entre individu et relation pour les relations qui ne
sont pas de nomenclature (sur un même individu) et dans l'individu patte
pour les relations de nomenclature.
24 points : 1 point par cardinalité et par card-min et card-max.
PATTE 1,1 RELATION M ESSAGE

P atter relation
0,N
card nom mini 0,1
card nom maxi 1,N
patter 0,N
1,1 card mini 0,N 0,N
0,N card maxi
événement
épatter info/ relation porter sur
individu INDIVIDU résulter
0,N
0,1 0,N 1,N 0,N 0,1
1,N 0,1
OPERATION
identifier INFORM ATION 0,N 0,N CONDITION
0,1 porter
propriété
1,1
5. Générer un modèle relationnel

Question 20 : 1 point par record et 1 point par information = 30
points
CONS OMMATEUR RECLAMATION PRODUIT GROUPER

code consom code réclamation code produit
nom consom. code produit
date réclamation code groupe produit
prénom consom.
adresse consom. code consom
code usine
GROUPE DE PRODUIT
code produit
code groupe produit
APPELER
code réclamation
code réponse
REPONS E REGROUPER
GROUPE
US INE code réponse code groupe produit aval
code usine date réponse code groupe produit amont
libellé réponse
1) toutes les relations de cardinalité maximale égale à 1 redondent

l'information : code usine, code consommateur, code produit dans le record
ou la table reclamation.
2) Les relations dont les deux pattes sont de cardinalité maximale à N
créent une table dont la clé est composée des clés des tables des individus :
table "appeler" entre "réclamation" et "réponse réclamation", table "grouper
produit" entre "produit" et "groupe produit". La relation "regrouper groupe"
se transforme en table dont la clé est composée des informations
équivalentes à code groupe produit.
3) Il n'existe pas de relation ternaire
Quel est votre résultat ?
QUESTIO NOTE MAXI

N
Informatique et méthode 1 5
2 7
3 2
Les 3 niveaux de la méthode
Le niveau conceptuel 4 5
5 5
Données ou traitements ? 6 20
7 7
8 12
9 5
Le modèle de données 10 5
11 3
12 4
Conceptuel ou 13 11
organisationnel ?
14 1
Organisationnel 15 14
Revue générale 16 22
Gestion de projet 17 12
18 6
Le méta modèle 19 24
Construire un MLD 20 30
TOTAL 200
 Entre 0 et 50 : vous devriez lire ce livre, vous l'avez surement ouvert du
mauvais côté. Vous êtes plutôt du type distrait ou papillon.
 Entre 51 et 100 : vous avez entendu parler de la méthode. Peut-être
même apprise dans une autre école. Vous êtes du type touche à tout ou
belette.
 Entre 101 et 150 : bravo, vous vous débrouillez bien. Vous pouvez
aborder toutes les méthodes. Vous devez être normal.
 Entre 151 et 200 : excellent vous pouvez me téléphoner au 3615 Code
MISERE et m'indiquer mes erreurs. Vous être du type "tête d'œuf". Ne
vous prenez pas trop au sérieux.
 Au delà de 200 points ? Vous vous singularisez.
GLOSSAIRE
Abstraction : mode de fonctionnement intellectuel requis pour

comprendre la suite.
Action : action de mise à jour ou de modification d'informations du
modèle logique de données.
Activité : occupation de l'entreprise. L'activité est analysée en fonction
des flux échangés avec les partenaires de l'entreprise.
Base de données : ensemble d'enregistrements ou de tables physiques.
Cardinalité : nombre de fois qu'une occurrence d'individu participe au
minimum ou au maximum à une relation. Nombre minimum et maximum
d'occurrences de patte.
Chemin : possibilité du niveau logique d'atteindre une ou des
informations à partir d'autres informations. Dans le cas de chemin de clé
d'enregistrement à clé d'enregistrement, le chemin est dit d'enregistrement
à enregistrement.
Clé : information identifiant une occurrence d'enregistrement.
Concaténation : décomposition d'une information en plusieurs
informations élémentaires.
Conceptuel : premier niveau de la méthode. Niveau fonctionnel
indépendant de l'organisation.
Condition : circonstance ou proposition vraie ou fausse. Toujours est
toujours vrai. Jamais ne l'est jamais. Peut-être ..
Contrainte : complément d'explication ou violence exercée sur les
individus, les relations et les pattes du modèle de données.
Contrainte d'intégrité fonctionnelle : patte de cardinalités minimale
et maximale égales à un.
Conversationnel : utilisation d'un ordinateur à l'aide d'un dialogue
interactif.
Déclaration : description des modalités d'obtention d'une information
dans le déroulement d'un outil ou d'un état.
Domaine : sous-système conceptuel de l'entreprise ayant un système
d'information. Le MCD est construit par domaine.
Donnée : information.
Enclencheur : message appelant à une réaction du récepteur.
Enregistrement : ensemble d'informations manipulées d'un bloc.
Equivalence : synonymie particulière d'informations. L'information
amont se trouve dans le modèle de données. Les informations avals
forment un sous-ensemble (défini par les occurrences d'individu participant
à une relation) de l'ensemble des informations amonts.
Etat : étape d'un outil informatique caractérisée par des informations
affichées ou à saisir dans une grille d'écran (support).
Etude préalable : étude d'opportunité ou étude préalable au lancement
des études détaillées (dessins, enchaînements des écrans et
programmation) d'un projet informatique.
Fichier : ensemble d'enregistrements ou programme.
Flux : translation ou passage d'information, de matière, d'énergie, de

valeur entre systèmes.
Formalisme : remplace modélisation qui n'existe pas dans le dictionnaire
(Robert).
Individu : idée, objet conçu par l'esprit d'un utilisateur et lui permettant
de mémoriser et structurer ses connaissances (concept)
Information : plus petit élément d'un système d'information.
Informatique : science du traitement de l'information, notamment par
machine automatique.
Intervenant : système fonctionnel interne ou externe à l'entreprise.
Lien : association d'enregistrements physiques. Un père est propriétaire
et N fils sont membres. Un lien est géré au moyen de pointeurs.
Logiciel : ensemble de programmes.
Logique : niveau logique de l'informatique. Représentation de
l'informatique indépendante du SGBD ou des systèmes informatiques.
Lourdeur : objection soulevée à propos de Merise. On peut aussi parler
de rouleau compresseur.
Merise : ne cherchez plus, les initiales ne signifient rien.
Message : flux d’information.
Meta-Modèle : modèle conceptuel de données représentant les
concepts de la méthode.
Modèle : représentation graphique de concepts d'un niveau (Conceptuel,
organisationnel, ..) et d'un découpage (communications, données ou
traitements) dans la Méthode MERISE.
Navigationnel : SGBD où un enregistrement peut être lié à plusieurs
pères ou propriétaires par des liens.
Occurrence : mot barbare désignant un élément d'un ensemble.
Opération : travail ou action exécutée par un intervenant (opération
conceptuelle), un poste de travail (organisationnel).
Organisationnel : 2ème niveau de la méthode. Celui-ci représente la
structure de l'entreprise en postes de travail et les sites de traitement (des
postes de travail) et de données.
Outil : moyen (informatique) mis à disposition d'un utilisateur pour
effectuer une ou plusieurs opérations.
Partenaire : système fonctionnel externe à l'entreprise.
Patte : rôle d'un individu dans une relation.
Pointeur : zone mémoire où sont stockées des adresses d'informations.
Poste de travail : unité d'organisation ou centre d'activité de
l'entreprise. Il peut lui être associé une ou plusieurs personnes, une ou
plusieurs machines, un ou plusieurs outils informatiques.
Procédure : ensemble d'opérations organisées enclenchées par un
message externe ou une opération sans message événement.
Progiciel : logiciel standard prêt-à-porter par opposition au sur mesure.
Programme : suite d'instructions écrites dans un langage exécutable par
un ordinateur.
Propriété : information d'individu ou de relation.
Règle de calcul : règle permettant d'obtenir des informations à partir
d'autres.
Relation : association d'individus.

Schéma directeur : Plan de développement informatique à moyen
terme (5 ans).
SGBD : Système de Gestion de Base de Données. Logiciel permettant de
créer, modifier ou consulter des informations dans une base (de données).
3 types de SGBD sont normalisés, hiérarchique, navigationnel ou réseau et
relationnel.
Site : lieu de traitement ou de stockage de données. Il peut exister
plusieurs sites de données sur un micro-ordinateur (tableur et gestion de
fichiers).
Spécification externe : partie du niveau logique à valider par
l'utilisateur final. Elle comprend les enchaînements d'états par outil (MLT) et
la description des informations affichées et à saisir par état.
Spécification interne : partie du niveau logique pouvant être ignorée
par l'utilisateur final. Elle comprend les actions de création d'information ou
d'enregistrement à partir des états et la description de l'obtention des
informations affichées ou créées par état.
Support : dessin ou masque d'écran.
Système : découpe de l'entreprise et de son environnement. Un
domaine est un système possédant une "mémoire".
Temporisateur : mode d'enclenchement d'une opération organisée
(tous les jours, à chaque passage d'étoiles filantes, toutes les vingt, cent,
mille factures...)
Temps réel : mode de traitement qui permet l'admission des données et
l'obtention immédiate des résultats (traitement immédiat ou mode
conversationnel).
Traitement par lot : mode de traitement suivant lequel les programmes
à exécuter sont groupés par lot (traitement différé).
Utilisateur : futur usager de l'informatique.
Validation : approbation des études par l'utilisateur final ou vérification
de la cohérence des modèles entre eux. Celles-ci s'effectuent aux dates
suivantes : fin du conceptuel, fin de l'organisationnel, fin de l'étude
préalable, fin du logique et fin du physique.
Correspondance avec Merise 79 et anglais.

Merise original Anglais
INDIVIDU OBJET ENTITY
RELATION RELATION RELATIONSHIP
INFORMATION PROPRIETE
ENREGISTREMENT SEGMENT RECORD
CHEMIN LIEN SET
OPERATION ORGANISEE PROCEDURE FONCTIONNELLE
BIBLIOGRAPHIE
1 - H. TARDIEU, A. ROCHFELD, R. COLLETTI : La méthode Merise. Tome 1

principes et Outils. Les Editions d'organisation. 1983.
2 - Y. TABOURIER : De l'autre côté de Merise. Les Editions d'organisation.

1986.
3 - Y. TABOURIER : Du modèle entité/relation vers un véritable réseau

sémantique. MBD n°9 1988.
4 - C. JAULT : Les bases de données relationnelles ou le libre accès aux

informations. Les Editions d'organisation. 1986
5 - D. DURAND : La systémique. Collection Que sais-je ? PUF. 1979.
6 - J. J. SEMPE, R. GOSCINNY : Le petit Nicolas. Denoël. 1960.
7 - M. AYME : Les contes rouges du chat perché. Gallimard. 1963.
8 - H. LABORIT : La colombe assassinée. Grasset. 1983.
9 - C. PEROCHON : Comptabilité générale. Editions Foucher. 1981.
10 - E.F. CODD : An evaluation scheme for database management systems

that are claimed to be relational. Computerworld. 1985.
11 - H. TARDIEU, A. ROCHFELD, R. COLLETTI : La méthode Merise. Tome 2

démarche et pratiques. Les Editions d'organisation. 1985.
12 - Dictionnaire chinois-français des locutions et proverbes. Joint Publishing

Co. 1980.

Merise: Sommaire

Transféré par

Droits d'auteur :

Formats disponibles

Merise: Sommaire

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Merise: Sommaire

Transféré par

Droits d'auteur :

Formats disponibles

Merise

MERISE est une méthode de développement des projets informatiques de

CHAPITRE I LE NIVEAU CONCEPTUEL.......................................11

CHAPITRE II : LE NIVEAU ORGANISATIONNEL...........................78

1 POSTE DE TRAVAIL ET ORGANIGRAMME...............................78

CHAPITRE III LE NIVEAU LOGIQUE.........................................102

1 LE MODELE LOGIQUE DE DONNEES, un exercice intellectuel.103

CHAPITRE IV LE NIVEAU PHYSIQUE.......................................129

1 MODELE PHYSIQUE DE DONNEES.......................................130

CHAPITRE V RESUME DES M+ODELES...................................149

1 RESUME DES COMMUNICATIONS........................................149

CHAPITRE VI L'ORGANISATION D'UN PROJET..........................151

1. LES ACTEURS D'UN PROJET...............................................151

CHAPITRE VII LA META-PHYSIQUE : MAINTENANCE, FORMATION ET

1 UN DICTIONNAIRE DE DONNEES, SINON RIEN.....................160

CHAPITRE VIII EXEMPLES DE MODELES DE DONNEES.............162

CHAPITRE IX SOLUTION DES EXERCICES................................174

CHAPITRE XI 10 CRITÈRES DE CHOIX D'UN OUTIL D'AIDE À LA CONCEPTION 196

1. Pourquoi choisir un outil d'aide à la conception?...............196

CHAPITRE XII EXERCEZ-VOUS (DOCUMENTS AUTORISÉS).......199

4. Le méta modèle........................................................................................ 203

Correspondance avec Merise 79 et anglais............................214

Il faut ouvrir des cadenas différents avec des

Ce chapitre d'introduction donne une vue globale de la méthode MERISE. Le

MERISE est une méthode de développement des projets

1 La démarche Merise : 3 découpages sur 4 niveaux.

Les objectifs de l'entreprise : le niveau conceptuel.

de l'activité, cette remise en question de l'entreprise, n'est pas abordée par

L'informatique universelle : le niveau logique ou externe.

Les retours sur le niveau précédent sont faibles

Etude Etude Liste des outils Etude Etude

L'étude préalable va jusqu'à la définition des outils

COMMUNICAT. DONNEES TRAITEMENT

Les "temps forts" de la méthode sont le Modèle Conceptuel de

"Le client passe une commande"

2. L'organisation et les étapes d'un projet informatique

CHAPITRE I LE NIVEAU CONCEPTUEL

Sans entrer dans la tanière du tigre,

L'objectif est de représenter l'activité de l'entreprise et de formaliser son

2 MODELE CONCEPTUEL DE COMMUNICATION.

Tout est SYSTEME ou FLUX entre systèmes

L'ENTREPRISE est un système qui peut être découpé

2.1.2 domaine et sous-domaine

Partenaire Sous-Domaine Domaine

Les INTERVENANTS sont EXTERNES (PARTENAIRES) ou INTERNES à

dans le temps. En général, il existe plus de fonctions que de personnes et

analyser gérer les gérer les

gérer les stocks suivre les

DOMAINE PRODUIRE POUR

L'entreprise est découpée en domaines, sous-domaines et fonctions

 Pourquoi suivre les pannes ? Pour planifier les réparations.

Si les réponses précédentes sont correctes, nous arrivons à la découpe

gérer les pièces gérer les

Voici les flux "réels".

ENTREPRISE Etat des équipements :

sous un même "DOCUMENT PHYSIQUE"...

Optimiser Demande de liquidités

...existent plusieurs messages conceptuels.

Le conceptuel consiste à trouver le pourquoi. Si nous nous intéressons à