Chapitre I - INTRODUCTION

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

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

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

Etude préalable

Etude détaillée

Réalisation et mise en œuvres

Il convient donc de l'adapter afin de retenir uniquement les concepts et/ou les étapes appropriées aux besoins
4. Démarche
La méthode MERISE présente sa démarche en trois axes présentant trois cycles de préoccupation différente mais complémentaire : le cycle d'abstraction,
le cycle de décision et le cycle de vie.

Ce cours sera axé sur les formalismes et concepts de Merise utiles aux descriptions statique et dynamique du système d'information à automatiser.
Relativement à ces descriptions (encore appelées modèles) la méthode Merise préconise 3 niveaux d'abstraction dans son cycle d'abstraction :
- le niveau conceptuel qui décrit la statique et la dynamique du système d'information en se préoccupant uniquement du point de vue du gestionnaire.
- les niveaux logique et organisationnel décrivent la nature des ressources qui sont utilisées pour supporter la description statique et dynamique du
système d'information. Ces ressources peuvent être humaines et/ou matérielles et logicielles.
- les niveaux physique et opérationnel dans lequel on choisit les techniques d'implantation du système d'information (données et traitements)
Du fait de ce découpage (qui a été introduit pour faciliter l'analyse d'un problème) seul le premier niveau est réellement indépendant de toute considération
technologique : logicielle ou matérielle. Par exemple, si les données du futur système d'information doivent être gérées par un SGBD, c'est au niveau
organisationnel que le choix du type du SGBD (relationnel, réseau ou objets) devra être effectué. La description statique du système d'information à ce
niveau sera donc basée sur l'organisation des bases relationnelles, ou réseau, ou objets. Le troisième niveau est encore plus dépendant de l'aspect
technologique puisqu'il cherchera à optimiser l'implantation. Il suppose donc une connaissance très pointue de l'architecture et des fonctions du SGBD qui
gérera le système d'information.
5. Le cycle d'abstraction et les modèles de MERISE
La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc
de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements,
il faut vérifier la concordance entre données et traitement afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas
de données superflues.
Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information:
Niveau Statique (données) Dynamique (traitements)
C onceptuel MCD MCT Indépendant du système:
QUOI ?
Organisationnel MLD MOT Choix du SGBD:
ou logique (OU?) (OUI ? QUAND ?) QUI ? QUAND ? OU ?
Opérationnel ou MPD MOPT Haute connaissance du
physique SGBD: COMMENT °
L'expression des besoins aboutit au MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre compte.
L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le
MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte.
Le modèle organisationnel consiste à définir le MLD (Modèle logique des données) qui représente un choix logiciel pour le système d'information et le
MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel).
Enfin, le modèle physique reflète un choix matériel pour le système d'information.

6. Conclusion et objectif du cours

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

Chapitre II - ANALYSE PREALABLE

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

2. Démarche
L'analyse préalable comporte trois étapes :
- l'analyse de l'existant où l'on étudie le fonctionnement du système actuel avant de le critiquer ;
- la conception de l'avant-projet où l'on définit les orientations générales (gestion, organisation, technique) des solutions possibles ;
- le choix de la solution à retenir.
3. Analyse de l'existant
a. Etude de l'existant
L'étude de l'existant a pour objectifs de prendre connaissance dans le détail le domaine à étudier en recensant l'ensemble exhaustif des objectifs poursuivis
par l'entreprise dans ce domaine.
Ces détails seront obtenus à partir des interviews auprès des entités auprès desquelles se fait l'étude de l'existant : la direction (présentation d'une vue
globale et de l'ensemble des objectifs dans le domaine) et les postes de travail (connaissances détaillées sur le poste en question).
Le système d'information actuel est étudié à l'aide :
- de la description des postes de travail en faisant ressortir les tâches effectuées, leur durée, leur fréquence, etc.
- de la description des documents
- de la description des données (fiches, fichiers, base de données, etc.)
- d'interviews des utilisateurs.
Une synthèse de ces éléments est présentée sous forme d'un diagramme tâches-documents (ou diagramme
T1 : Création du bon de commande (BC)
T2 : Enregistrement commande et visa du bon de commande
T3 : Préparation et envoi commande et création de l'avis d'expédition (AE)
T4 : Envoi du bon de commande pour établir la facture
T5 : Création de la facture (F) et de sa copie (CF)
 b. Critique de l'existant
Cette étape fournit un état de la situation actuelle et tente de faire apparaître (objectivement) les défauts et les qualités de ce qui existe déjà. Cette critique
peut déboucher sur la remise en cause des structures, des postes, des hommes, des documents, ... Elle permet ainsi :
- l'identification des atouts (points forts) du système existant ;
- la recherche des aspects à améliorer ;
- la mise en évidence des insuffisances actuelles (points faibles) et de leurs causes.
4. Conception de l'avant-projet
Cette étape est également appelée « Ebauche de solutions ». Il s'agit d'établir une ou plusieurs propositions de solution globale, permettant de pallier aux
carences repérées lors de la critique de l'existant. Il faut faire apparaître les axes fondamentaux des solutions proposées et les moyens à mettre en œuvre
pour arriver à atteindre les objectifs fixés tout en respectant les contraintes relatives aux orientations de gestion, d'organisation et techniques. Ces solutions
devront en plus résoudre les points faibles identifiés précédemment tout en sauvegardant ses points forts.

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

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

Chapitre III - MODELE CONCEPTUEL DES DONNEES

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

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

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

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

Règles à vérifier sur les associations

1. Une association est une relation que les règles de gestion établissent entre deux entités (ou plus).
2. Une occurrence d'une association est une instance del'association dans le monde réel.
3. Une association peut posséder des propriétés.
4. L'identifiant d'une association est la concaténation des identifiantsdes entités qu'elle relie.
Règles à vérifier sur les cardinalités
La cardinalité d'une entité par rapport à une associations'exprime sous forme d'un couple :(cardinalité minimale : cardinalité maximale). La cardinalité
minimale est le nombre minimal de fois où uneoccurrence d'un objet participe aux occurrences del'association ; elle vaut très souvent 0 ou 1. La cardinalité
maximale est le nombre maximal de fois où uneoccurrence d'un objet participe aux occurrences del'association ; elle vaut 1, un entier fixé ou n.

5. Vérification d'un MCD

Vérifier :
• les règles sur les entités ;
• les règles sur les associations ;
• les règles globales suivantes :
1. Une propriété ne figure qu'une fois dans le MCD ;
2. Les propriétés calculées ne figurent pas dans le MCD (maisil faut s'assurer qu'avec le MCD on puisse les calculer) ;
3. On ne fait pas figurer les associations qui se déduisent partransitivité.
Chapitre IV-MODELE CONCEPTUEL DES TRAITEMENTS
1. Objectifs
Le MCT est une représentation schématique de l'activité d'une entreprise indépendamment des choix d'organisation et des moyens d'exécution.

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

2. Définition des concepts

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

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

• Un événement est une sollicitation (externe ou interne) du Système d'Information auquel celui-ci doit réagir ;
• Une synchronisation d'événements est une condition logique nécessaire au déclenchement d'une opération ;
• Un résultat est le produit d'une opération, événement interne qui peut être événement déclencheur d'autres opérations.

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

Au préalable, il faut :
• avoir explicité les règles de gestion ;
• avoir établi un diagramme des flux, c'est-à-dire une représentation graphique de la circulation des informations entre les différents acteurs de
l'entreprise ;
Comme une opération est une suite ininterrompue d'actions, aucun événement externe ne peut l'interrompre et aucunrésultat interne à une opération ne peut
conditionner la suitede ses actions.
Remarque : Une application réelle est souvent constituée d'unejuxtaposition de petits MCT.

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

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

3. demande rapport
1. demande promotion
. du pers^
serv
4. rapport
2. lettre de rejet

5. notification avis favorable

4. Formalisme
15
Exemple :
Chapitre V - VALIDATION

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

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

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

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

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

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

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

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

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

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

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

f------------- 1
 “3 ___________
- Nom client - Date commande

o Cas des autres associations

(Cardinalité des entités associées 0,n ou 1,n)
- Chaque entité devient une table, l'identifiant de l'entité devient la clé de la table.
- L'association devient une table, l'identifiant de l'association (formé par la composition des identifiants des entités, cf Règle de validation
n°4) devient la clé primaire de cette table.
- Les propriétés éventuelles de l'association deviennent des attributs de la table « fils ».
 Exemple
FOURNISSEUR ARTICLE
[ offre \
- N°Fournisseur 1]
- Prix Achat - Réf. Article

k QtéD p- J
- Nom fournisseur - Désignation

♦ Concernant les IDENTIFICATIONS RELATIVES

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

HOTEL comprend CHAMBRE

- N°Hotel ------ -------1 - N°Chambre
—
- Nom hotel
\ ___ J Prix

♦ Concernant les ASSOCIATIONS REFLEXIVES

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

EMPLOYE f Chef de \

- Matricule

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

Chapitre VII - MODELE ORGANISATIONNEL DES TRAITEMENTS

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

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

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

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

3. MOT orienté traitement interactif au MLD relationnel

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

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

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

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

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

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

- Les résultats produits par unité de traitement

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

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

Chapitre VIII - MODELE PHYSIQUE DES DONNEES

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

2. Modèle Physique des Données

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

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

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

- la dénormalisation de certaines relations,

- l'ajout de données de situation, ...

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

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

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

La préparation du développement englobe :

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

- la décomposition de l'application en modules.