Partie 1

Université Sidi Mohamed Ben Abdellah Cours Analyse et Conception de S.
I
Faculté des Sciences Dhar Mahraz SMI-S5
Département d’Informatique
ANALYSE ET CONCEPTION DE SYSTEMES D’INFORMATION
LA METHODE DE MERISE
1
SMI / S5 FSDM
Université Sidi Mohamed Ben Abdellah Cours Analyse et Conception de S.I
REFERENCES ET BIBLIOGRAPHIE
LIVRES:
 L'essentiel sur Merise [Broché], Dominique Dionisi (Auteur)
 Merise - Concepts et mise en oeuvre [Broché], Drifa SEBA (Auteur)
 Comprendre Merise : Outils conceptuels et organisationnels [Poche], Jean-Patrick Matheron

(Auteur)
 Exercices et cas pour comprendre MERISE [Broché], Jean-Patrick Matheron (Auteur)
INTERNET :
http://www.scribd.com/doc/7472422/Cours-de-Merise
2
SMI / S5 FSDM
INTRUDCTION A L’ANALYSE ET LA CONCEPTION DE S.I
1 Le système d’information:
1.1 Qu’est ce qu’un système ?
Un système est un tout constitué d’éléments unis par des relations, leurs propriétés (qualités, caractéristique d’une
chose ou d’un individu) et les valeurs que peuvent prendre ces dernières, ainsi que on activité et l’organisation qui en
découle.
L’entreprise peut être vue comme un système, composé d’éléments tels que des « employés », des « services »,
des « produits », etc. Les propriétés décrivant ces éléments peuvent être « le matricule de l’employé », son « nom
», la « référence » du produit, sa « désignation », etc.
Entre ces éléments, on trouve des relations, telles la relation « est rattaché » entre un employé et son service, la
relation « est stocké » entre un produit et son dépôt de stockage… Les propriétés de ces relations seront du type «
date d’entrée dans le service », « quantité stockée » …
1.2 Q’est ce qu’un système d’information de gestion
Le système d’information d’une entreprise est l’ensemble des informations qui y circulent ainsi que l’ensemble des
moyens mis en oeuvre pour les gérer. L’objectif d’un système d’information est de restituer l’information à la personne
concernée, sous la forme appropriée et en temps opportun pour rendre une décision ou effectuer un travail.
Toutes les informations qui circulent dans l’organisation, quelle que soit leur forme, font partie du SI. Mais seules
les informations formalisées (clair, précis, explicite, structuré) nous intéressent, car elles sont les seules à être
vraiment utilisables en informatique. L’ensemble de ces informations formalisées constituent ce qu’on appelle le
système d’information automatisé.
Les systèmes d’information préexistent à l’informatique. Avant d’utiliser les ordinateurs, les informations
concernant les clients, les commandes, les stocks, etc, étaient mémorisées sur papier, sous forme de fiches,
formulaires, regroupés dans des dossiers. Et il existait des procédures manuelles pour traiter ces informations.
Le système informatisé doit être au service du système d’information mis en place par les dirigeants de
l’entreprise (et non l’inverse comme cela existe trop souvent).
1.3 Les fonctions d’un système d’information
Le système d’information de l’entreprise reçoit de son environnement des informations qu’il doit traiter. Ce sont
par exemple des commandes de clients qui doivent être traitées jusqu’à leur aboutissement, ou l’arrivée des
factures des fournisseurs. Le SI reçoit et traite aussi des informations interne à l’organisation, comme par exemple
les documents comptables, ou les chiffres de production.
3
SMI / S5 FSDM
On peut distinguer 4 fonctions principales du système d’information :

1- Recueillir l’information (saisie)
2- Mémoriser l’information (stockage dans des fichiers ou bases de données)
3- Exploiter l’information (traitement)
a. Consulter
b. Organiser
c. Mettre à jour
d. Produire de nouvelles informations par des calculs
4- Diffuser l’information (édition)
Un système d’information pour une organisation est donc un ensemble de ressources, de moyens matériels
(informatiques et autres), de moyens de communication, de logiciels et de procédures permettant à l'entreprise de
fonctionner et de se développer.
Par rapport à ce système d’information existe :
- Un système de pilotage qui dirige l'entreprise en fonction des objectifs poursuivis. Il a comme mission
le contrôle et la régulation
- Un système opérant ou de production qui est un ensemble de moyens matériels, de personnels, de flux
de matières, de flux financiers... nécessaires pour assurer les activités de l'entreprise.
Système de
pilotage
Décisions pour Informations traités

traitement pour pilotage
Instructions
du système de
pilotage Système
Flux externes Flux
d’informations
d’information d’informations
entrant dans le
système
Informations Collecte
traités d’informations
Flux entrant de Système opérant Flux sortant

matières, financiers (produit, services
…)
Figure 1: Système d’information dans le contexte d’une entreprise
4
SMI / S5 FSDM
Les ressources humaines interagissant avec le S.I peuvent être:
- Les utilisateurs
- Les usages
- Les informaticiens
Les ressources matérielles sont les ordinateurs et les réseaux. Alors que les ressources immatérielles sont :
- Les différents logiciels

- Méthodes
- Procédures
- Modèle du représentation du réel
- Les pratiques du travail de l’entreprise
2 Le système informatique
Il représente l’ensemble des moyens matériels et humains mis en œuvre pour le traitement automatisé du système
d’information, comme
- Matériels :
o Ordinateurs (micro, mini, gros systèmes et périphériques associés)
o Réseaux de transmission de données (local, public..)
- Logiciels :
o Système d’exploitation
o Utilitaires
o Logiciels bureautiques
o Applications
o SGBD (système de gestion des bases de données)
o Aide logiciels (AGL)
- Humains
o Informaticiens
o Utilisateurs directement concernés par le système informatique
La qualité d’un logiciel est sa conformité aux besoins ressentis, négociés et acceptés par la maîtrise d’ouvrage
(utilisateurs) et le maître d’œuvre.
3 La modélisation
Les méthodes d’étude des systèmes d’information ont pour objectif de décrire ces systèmes à l’aide de modèles,
puis de réaliser les systèmes informatisés qui en découlent.
Un modèle peut être défini comme étant une image de la réalité. Toute réalité complexe (qui contient de multiples
éléments en relations) a besoin d’être représentée pour être comprise et maîtrisée.
Ex :
Une carte routière représente, à l’aide de symboles, tout ou partie d’un territoire et son infrastructure routière.
Le plan établi par un architecte permet à chaque corps de métier d’intervenir efficacement dans la construction
d’un immeuble.
5
SMI / S5 FSDM
Ainsi, l’informaticien peut être vu comme l’architecte du système informatisé, qui en dresse le plan détaillé.
Un modèle doit permettre de communiquer sans ambiguïté. Donc il faut utiliser un formalisme (langage écrit
formalisé) normalisé (conforme à une norme).
4 Les enjeux du développement informatique

Répondre mieux et plus vite aux besoins des utilisateurs finaux en assurant la maîtrise des coûts, tout en
garantissant la pérennité des investissements, voilà les impératifs majeurs auxquels doivent répondre les décideurs
dans tous les domaines.
L’informatique se caractérise de plus par une forte évolutivité des besoins et des techniques qui conduisent à une
visibilité restreinte sur l’avenir. Il faut donc absolument prendre en compte les points clés suivants :
 Les demandes des utilisateurs se renouvellent et s’accroissent, en quantité comme en qualité.

 Les matériels et les logiciels de base sont en mutation permanente et rapide.
 Les ressources pour satisfaire les demandes diminuent plus qu’elles n’augmentent.
La mise en place d’un système informatisé, c’est à dire l’informatisation du système d’information (SI) de
l’entreprise ne peut être efficace que si celle ci est dirigée du début à la fin par une méthode rationnelle et
compréhensible par les différents acteurs qui interviennent tout au long de la vie du projet.
Par la définition d’un certain nombre de règles strictes, la modélisation du système à l’aide d’une méthodologie
bien étudiée garantie d’une part la cohérence des données et traitements et donc la validité d’une application et
d’autre part la pérennité des développements réalisés grâce une "maintenabilité" accrue.
L’utilisation d’une telle méthode est donc primordiale pour tout développement informatique actuel afin d’assurer
la cohérence entre le cahier des charges initial, issu de la volonté des dirigeants et l’application livrée à
l’utilisateur final.
Il existe différentes méthodes de conception de S.I:
- MERISE, diffusée en 1978, est certainement la plus connue et la plus utilisée en France.
- REMORA, méthode conçue par une équipe d’universitaires en 1982.
- SADT (Structured Analysis and Design Technique), crée en 1976 par Ross de la société Softech.
- AXIAL, développée par IBM en 1984.
- IEM (Information Engineering Méthodology), crée par J. Martin en 1984.
5 Merise
Merise vient de MERISIER dont elle est le fruit et aux dires de ses concepteurs l’exemple même de l’arbre qui
fait l’objet de nombreuses greffes.
Le merisier ne peut porter de beaux fruits que si on lui greffe une branche de cerisier. Il en est de même des
méthodes informatiques bien conçues qui ne produisent de bons résultats que si la greffe sur l’organisation réussit.
6
SMI / S5 FSDM
5.1 Composantes de Merise
Comme toute méthode d’analyse et de conception des SI, Merise regroupe :

Des modèles (concepts, règles de représentation)
Un langage (vocabulaire, règles de syntaxe)
Une démarche
Des outils (des logiciels tels que AMC Designor ou Win Design)
Elle permet de représenter les composantes d’un SIG

Les acteurs
Les données
Les traitements
Les procédures
Les postes de travail, etc.
Ceci afin de concevoir, réaliser et mettre en place un nouveau automatisme qui fixera le cadre des relations
contractuelles (entre le client utilisateur du système et le fournisseur maître d’œuvre informatique), permettra de
disposer d’un référentiel commun, et aidera à la maîtrise des coûts et les délais (a charge de maintenance des
applications est de l’ordre de 70%)
6 Les principes de la méthode merise

Elle consiste à partir d’un “ Réel”, c’est-à-dire de l’ensemble des informations et des règles de gestion de
l’entreprise à définir.
Le futur système d’information s’appuie sur la représentation des structures de l’organisation, de son activité, de
son environnement et de ses finalités. Cette méthode propose la construction du futur système d’information par
approches successives. Elle comprend :
- La démarche par étapes, au cours desquelles est construit progressivement le futur projet (étude
préalable, étude détaillée, réalisation, mise en œuvre).
- La démarche par niveaux, régie par des règles de construction des différents modèles relatifs aux
données et aux traitements.
- La démarche de construction où la construction d’un système d’information s’effectue selon trois

axes appelés cycles :
o Le cycle de vie : Il précise les différentes étapes de la construction et de l’exploitation d’un

système. Il concerne à la fois le cycle de développement et le cycle de maintenance.
o Le cycle de décision : Il représente les différents choix qui doivent être faits tout au long du cycle
de vie (décision de lancement, validation des spécifications, prise en compte des aménagements en
cours de développement).
o Le cycle d’abstraction : Il représente le formalisme utilisé pour modéliser le système
d’information (modèles des données et des traitements).
7
SMI / S5 FSDM
6.1 La démarche par étapes
- Le schéma directeur
o définit les différents domaines d’application
o fixe le plan de développement informatique sur 5 ans
- L’étude préalable
o étude des différentes solutions possible puis choix
o définit la structure globale et générale du futur système
o définit les évaluations pour la suite des travaux
o évalue les enjeux et les risques
o définit le découpage en sous projet
- L’étude détaillée
o complète et précise l’architecture préalablement définie
o affine charges et plannings
- La réalisation (Etude technique et programmation)
o Spécifications techniques complètes
o décrit chaque sous projet dans une forme interprétable par la machine
o écriture des programmes
o production du logiciel
- La mise en œuvre
o Tests, essais
o mise en place de la nouvelle organisation,
o création de la documentation
o formation utilisateur, constitution de fichiers
o mise en place du matériel, lancement et rodage
- Maintenance
o Corrections et adaptations du logiciel
- Contrôle de qualité
o Contrôle de la conformité des résultats par rapport aux demandes
8
SMI / S5 FSDM
6.2 La démarche par niveaux
Les niveaux de représentation de Merise de base consiste à classifier le réel de l’organisation c’est à dire la
description des, données et des traitements pour un projet déterminé, selon trois niveaux :
Gestion :
- données manipulées
- règles de gestion
- enchaînement de traitement
Organisation :
- Partage de taches
- Mode de traitement
- Répartition géographique des
traitements
- organisation des données.
Technique :
- Programmes
- Logiciels
- matériels
Merise (du moins dans sa première version) est une méthode qui préconise de séparer l’étude des données et les
traitements.
Chaque modèle de Merise concerne soit les données, soit les traitements, à un niveau d’abstraction donné.
6.2.1 Le niveau conceptuel
Il a pour objet de décrire le système de gestion pour le domaine concerné.
Quelles données ?
Pour quoi faire ?
Quelles règles de gestion ?
Il est indépendant des choix d’organisation et des choix techniques
- Pour les données : leur signification et les rapports qui existent entre elles selon le modèle individuel (schéma
entité-association).
- Pour les traitements : la succession des actions menées dans le domaine étudié en réponse aux sollicitations
auxquelles il doit faire face (traduction des règles de gestion).
9
SMI / S5 FSDM
6.2.2 Le niveau organisationnel ou logique

Il a pour objet de décrire les choix d’organisation.
- Qui fait quoi ? (les acteurs du système)

- Quand ? (notion de temps)
- Où ? (notion de lieu)
- Quel type de traitement ?
Il est indépendant des choix techniques. On s’attache à décrire :
- Pour les données : les structures logiques (tables relationnelles ou record et set) dans le
Cas d’un SGBD Relationnel.
- Pour les traitements : la répartition entre l’homme et la machine, le mode de traitement (conversationnel ou
différé, centralisé ou réparti).
6.2.3 Le niveau physique ou OPERATIONNEL
Il a pour objet de spécifier les choix techniques
Comment faire ? (Les matériels et les logiciels de base nécessaires, quel type de réseau.)
On s’attache à décrire :
- Pour les données : La description de la base de données à l’aide du langage de description du SGBD retenu (le
SQL pour le relationnel).
- Pour les traitements : le découpage en unités de traitement (les UT) et leur structure d’enchaînement.
10
SMI / S5 FSDM
6.3 Les modèles de représentation
Typologie présentant les différents modèles :
6.3.1 ENCHAINEMENT DES TRAVAUX
Merise est utilisé dans le cas où l’on veut mettre en place ou modifier un système informatisé. Dans les deux cas,
il convient d’analyser et de critiquer le système existant afin de créer un nouveau système adapté à l’organisation.
Pour cela, la démarche consiste à suivre la « courbe du soleil ».
11
SMI / S5 FSDM
L’analyse du système existant conduit à construire :
- Au niveau logico-physique :
o Le modèle conceptuel des communications (MCC) qui représente les échanges de flux
d’informations entre les différents acteurs du SI et les acteurs extérieurs
o Le schéma de circulation des documents (SCD) qui représente les échanges d’informations
entre les acteurs du SI ainsi que les tâches qui produisent les documents.
- Au niveau organisationnel :
o Le modèle organisationnel des traitements qui permet de préciser par rapport à l’étape
précédente si les tâches sont automatisées ou manuelles, les événements déclencheurs et les
conditions d’émission des objets externes.
- Au niveau conceptuel
o Le MCD (modèle conceptuel des données) et le MCT (modèle conceptuel des traitements)
Le passage de la modélisation du système existant à la modélisation du système futur implique une critique du
système existant, une réflexion sur les évolutions possibles en tenant compte des nouveaux objectifs assignés au
système futur.
L’analyse du système futur conduit à construire :

- Au niveau conceptuel :
o Le MCD et le MCT découlant de la critique de l’existant
- Au niveau organisationnel :
o Le MOT du système futur mettant en valeur la nouvelle organisation (y compris en terme
de ressources humaines et de nouveaux postes de travail)
- Au niveau logico-physique
o Le MLD modèle logique des données et le MPD modèle physique des données obtenus à
partir du MCD adapté aux choix effectués dans le MOT et aux besoins d’informations
complémentaires
o Le MPT modèle physique des traitements (algorithmes, structure des programmes…)
12
SMI / S5 FSDM
7 LE MODELE CONCEPTUEL DES DONNEES MCD
Le niveau conceptuel correspond à une formalisation du SI indépendante de toute contrainte

d’organisation
La formalisation des données, au niveau conceptuel, constitue le MODELE CONCEPTUEL DES

DONNEES (M.C.D)
7.1 Définitions et formalisme
Objectifs
•Rassembler les données (regrouper les données ayant des traits communs)
• Structurer les données qui seront utilisées par le S.I
• Décrire les données avec des outils (concepts, schémas)
• Modéliser
• Schématiser
Le M.C.D décrit la sémantique c’est à dire le sens attaché à ces données et à leurs rapports et non
à l’utilisation qui peut en être faite.
Le M.C.D est connu sous différentes dénominations, diagramme:

 entité-association,
 entité-relation (dénomination de l'ISO),
 objet-relation.
 individu-relation
Voici un exemple introductif sur le recueil des données:
Supposons qu’on est intéressé par la personne RAYAN Said. Voilà plusieurs phrases qui décrivent une seule et
même personne, prononcées par des acteurs différents.
« RAYAN Said est une personne convenable. Et je ne dis pas ça parce c’est un client qui m’en prend pour 1000
Dh toutes les semaines ! » Le boulanger
« RAYAN Said, habitant 6 rue petit nid, Fés (fés jdid), née le 13/02/73 à Imouzar (fés boulmane) … » Un
administrateur communcal
« RAYAN Said, voilà une personne correcte qui ne s’est jamais absenté, qui a fait preuve de beaucoup d’initiative
et de créativité. Il réussira dans sa vie professionnelle.» Professeur de la faculté
Différents interlocuteurs, différents points de vue. Lequel est le plus pertinent ?

Ca dépend du domaine étudié.
Mais on ne recense que les informations objectives, formelles
13
SMI / S5 FSDM
Quand on analyse les données sur un objet (abstrait ou concret) du réel, il est nécessaire de faire le tri entre
ce qui est nécessaire pour le système d’information et ce qui ne l’est pas.

 Représentation
Rayan Said sera représenté par au moins ces informations :
- Nom
- Prénom
- Numéro de la voie
- Nature de la voie
- Nom de la voie
- Commune de résidence
- Département de résidence
- Jour de naissance
- Mois de naissance
- Année de naissance
- Commune de naissance
- Département de naissance
A noter qu’il existe par exemple des liens entre les informations 3, 4 et 5 qui représentent l’adresse de Rayan,
entre les informations 8 et 9 qui représentent sa date de naissance…
On va alors regrouper ensemble ces informations liées.
On remarque que toutes les personnes peuvent se décomposer de la manière suivante (en rubriques):
on peut dire qu’on a créé une entité (un ensemble) PERSONNE dont Rayan est une occurrence (ou instance).
7.2 Présentation des concepts et du formalisme MCD

7.2.1 Entité
Une entité représente un objet du SI (acteur, document, concept, …), ou plus exactement un
ensemble d’objets ayant les mêmes caractéristiques. Elle est aussi la représentation dans le SI
d’un objet matériel ou immatériel de l’univers extérieur
Dans une entité, on met les informations nécessaires et suffisantes pour caractériser cette entité. Ces données de
base pour l’entité sont appelées PROPRIETES ou ATTRIBUTS.
Une propriété est dite CONCATENEE s’elle est décomposable en d’autres propriétés.
14
SMI / S5 FSDM
Exemple : Adresse : rue + code postal + ville
Une propriété est dite ELEMENTAIRE si elle ne peut pas se décomposer
Exemple : rue, code postal et ville
Une propriété peut être mémorisée ou calculée (c'est-à-dire déductible des propriétés mémorisées)
Ex: Solde = différence entre CUMUL Débit et CUMUL Crédit
Une propriété peut aussi être portée par un événement.
On distingue 3 sortes de propriétés :

- Les codes :
Informations synthétiques représentatives d’objets matériels ou immatériels de
l’univers extérieur, selon une loi de correspondance rigoureuse (système de
codification). A tout objet existant est associé une valeur et une seule du code. A deux
objets différents correspondent deux valeurs distinctes de ce code (ex : n° bon de
commande)
N° de commande (rubrique de type code)
identifiant de
COMMANDE
(objet de l’UE)
BON-DE-COMMANDE (entité du SI)
- Les libellés
Ce sont des données alphanumériques, qualitatives, de simples chaînes de caractères,
ne pourront participer à aucun calcul mais bien pour faire des tris ou des comparaisons.
Ex : Nom d’un client
- Les montants
Ce sont des données numériques, quantitatives, qui pouront participer à des calculs.
Ex : Prix d’un produit
7.2.1.1 Classification des entités

7.2.1.1.1 Entité permanente
C’est une entité que l’on conserve en permanence dans la base d’information mais qu’on peut mettre à jour à tout
moment. Elle corresponde à la structure. Elle ne représente pas des faits.
Ex: CLIENT : on conserve les propriétés d’un client en permanence

15
SMI / S5 FSDM
Les propriétés d’une entité permanente peuvent changer mais l’entité elle-même est stable (l’adresse d’un client
peut changer dans le temps).
Les propriétés d’une entité permanente peuvent être de deux types :
- propriétés signalétiques : correspondant à sa description, ex : CLIENT : nom, rue, ville …

- propriétés de situation : correspondant à l’état où se trouve l’entité à un instant donné, cumul ou
une position Ex : PRODUIT : stock au début du mois. Il peut s’agir d’une situation actuelle
(propriétés de situation à l’instant présent), et les situations en historique (propriétés de situation de
l’entité à des instants passés).
Ex : Le solde d’un compte au 4 mars peut se calculer a partir du dernier solde mémorisé
(par exemple au 28 février, date de dernière mise a jour des comptes) et des écritures
(mouvements) enregistrées depuis cette dernière MAJ (depuis le 28 février).
SOLDE P = SOLDE P – 1 + cumul des mvts débit - cumul mvts crédit

On a donc deux méthodes pour déterminer Ia situation d’une entité a l’instant t :
- Calculer une fois pour toute cette situation et la mémoriser.
- Recalculer a chaque fois cette situation a partir de la dernière situation
mémorisée et des mouvements enregistrés depuis. Cette méthode n’est
envisageable qu’avec un ordinateur ayant assez de mémoires externes pour
conserver tous les mouvements nécessaires au calcul.
7.2.1.1.2 Entité de type « mouvements »
Une entité de type mouvement est le souvenir d’un événement, dans le SI
Ex: entité COMMANDE : (N° commande, date) mémorisé dans le système est issue de l’événement
PASSATION DE COMMANDE
Il existe un moment où on ne peut plus mettre à jour une entité mouvement (on ne peut plus modifier une
commande une fois qu’elle est passée)
7.2.2 Notion de relation
Une relation est la prise en charge par le SI du fait qu’il existe une association entre des objets de l’univers
extérieur et prendra une association entre les entités correspondantes.
16
SMI / S5 FSDM
Ex:
« Said est marié à Salima » exprime par la relation « est marié à » une association entre les entités Said et
Salima.
Entre l’entité Bon de commandet (N°BC, Date) et l’entité Produit (Réf, Prix) peut exister la relation
CONCERNE exprimant l’association qui existe entre l’objet COMMANDE et certains objets de type PORDUIT.
Par exemple la commande N°123 peut concerner les produits A01 et B125.
A une relation peuvent également être rattachées des propriétés, exactement comme pour les entités.
Ex: la relation CONCERNE peut être porteuse de la propriété QUANTITÉ exprimant pour chaque
produit commandé (concerné par la commande) la quantité commandée.
Bon de Commande (N°BC, Date)

CONCERNE(Qté)
PRODUIT (Réf, Désignation, Prix)
Les 2 entités BON DE COMMANDE et PRODUIT sont reliées par la relation CONCERNE si le
produit est commandé sur le bon de commande par une certaine quantité.
7.2.2.1 Classification des relations

7.2.2.1.1 Relations permanentes
Ce sont des relations entre entités permanentes qu’on conserve en permanence et dont on peut modifier les
propriétés à tout moment. Ce sont des relations structurelles.
Ex: Employé (matricule, nom)

Affecté a (heure début, heure fin) (horaires peuvent être modifiés à tout moment)
Service (code, intitulé)
Said, employé A12 est AFFECTÉ (tous les jours ouvrables de 8h à 17h) au service 18,
Commerciale (les horaires de AFFECTÉ peuvent changer)
7.2.2.1.2 Relations de type mouvements

Ce sont des relations entre entités permanentes ou de mouvements qui représentent le souvenir d’un événement
(RELATION CONJONCTURELLES)
(Conjoncture : situation qui résulte d’un concours de circonstances ; occasion. Une Conjoncture très favorable,
ensemble des éléments qui déterminent la situation économique, sociale, politique ou démographique à un
moment donné.)
17
SMI / S5 FSDM
Ex: COMMANDE (N°BC, date)

SE COMPOSE DE (quantité)
PRODUIT (Réf, désignation, prix)
La commande 125 du 15 novembre 2005 SE COMPOSE de trois produits (X01,

chemise,120dh) et de deux produits (X25, pantalon, 200dh)
SE COMPOSE DE est le souvenir dans le SI (la mémorisations dans le SI) du détail de

l’événement « commande n° 125 », à savoir que celle-ci concernait trois unités du
produit X01 et deux unités du produit X25.
7.2.3 Types et occurrences
Un type est un ensemble d’éléments ou d’objets ayant les mêmes caractéristiques.
Une occurrence d’un type est un élément particulier appartenant à cet ensemble.
ENTITÉ-TYPE : classe d’entités particulières ayant des propriétés analogues
OCCURRENCE D’ENTITE-TYPE : entité particulière appartenant à ce type
ENTITÉ-TYPE
Occurrences (objets)
Ex : CLIENT est une entité-type, client Halim et Client Fatima sont des occurrences de cette
entité-type.
IDENTIFIANT (ou clé d’idntification): Une propriété particulière, appelée identifiant (ou clé
d’identification), permet de distinguer sans ambiguïté cette entité particulière de tout autre entité du
même type.
L’identifiant est une propriété qui caractérise de manière unique chaque occurrence de l’entité-
type. Il ne peut pas changer au cours du temps.
Ex: Entité-type CLIENT (code client, nom client). Code-client est l’identifiant (clé) de
l’entité – type CLIENT
RELATION-TYPE: relation (association) entre plusieurs entités-types. La COLLECTION est la liste des
entités-types qui participent à cette relation
Chaque ensemble d’occurrences des entités composant la relation-type constitue une occurrence de la
relation-type
18
SMI / S5 FSDM
Relation-type Occurrences de la relation
Il est parfois utile de préciser le nombre maxi, mini et moyen d’occurrences.

Cette notion d’occurrence sert à quantifier la base de données.
PROPRIETE-TYPE: classe de propriétés semblables. Une occurrence d’une propriété-type est une valeur prise
par cette propriété. Elle peut être de type code, libellé ou montant. Elle peut être élémentaire ou concaténée,
mémorisé ou calculée.
Ex : NOM-CLIENT est une propriété-type de l’entité-type CLIENT et représente la classe des noms de
tous les clients.
Les occurrences Said et Fatima de cette propriété-type sont des valeurs prises par cette propriété pour
deux clients particuliers (deux occurrences de l’entité-type CLIENT)
Une propriété-type est caractérisé par une certaine structure :

- sa classe (numérique (chiffres), alphabétique (caractères ou espaces), alphanumérique (tous
caractères)
- sa longueur (nombre de caractères)
Exemple général:
Il ne faut pas confondre
- ENTITE-TYPE et OCCURRENCE de l’entité-type,
- ni PROPRIETE-TYPE et VALEUR de propriété
- ni RELATION-TYPE et OCCURRENCE de la relation
Exemple: COMMANDE (N°cde, date)

COMPRTE (Quantité)
PRODUIT (Référence, libellé, Prix de vente)
ENTITE-TYPE OCCURRENCE de l’entité-type

COMMANDE numéro 123, du 08/10/02
PRODUIT Manteau de référence 456 à 100€
PROPRIETE-TYPE VALEUR de la PROPRIETE-TYPE

N° cde: 123
Date: 08/10/02
Référence : 456
Libellé: Manteau
Prix de vente: 100€
RELATION-TYPE OCCURRENCE de la relation-tye
CONCERNER lien entre la commande 123 et le manteau 456 pour une
quantité de 3 unités
19
SMI / S5 FSDM
7.2.4 Formalisme Représentation Schématique
L’identifiant est toujours souligné

La relation AFFECTÉ A est définie sur la collection {SALARIÉ, SERVICE}
Exemple d’occurrences :
Dans cet exemple, on voit que DURAND et DUBOIS sont affectés à la comptabilité et
MARTIN au service commercial.
On représente souvent les occurrences d’une entité-type sous forme d’un tableau. Les lignes correspondent aux
occurrences, et les colonnes correspondent aux valeurs des propriétés-types.
Ex: ETUDIANT (CNE, Nom, Prénom, Adresse)
CNE Nom Prénom Adresse

2341 Aarab Said Rue de fes, 6
4532 Bakali Ahlam Rue du jardin, 19
6542 Badir Kamal Route Imouzar, 8
Différents types de relations:
- binaire,
20
SMI / S5 FSDM
- réflexive,
- ternaire,
- n-aire ou multiple,
DIMENSION : la dimension d’une relation-type est le nombre d’occurrences d’entités concernées par une
occurrence de la relation-type. Elle est supérieur ou égale au nombre d’entités de la collection.
Ex : - Une relation de dimension 2 est une relation binaire
II faut deux occurrences de la relation PERSONNE pour une occurrence de la relation

EST MARIE A (II faut être deux pour se marier).
- Une relation de dimension 3 est une relation ternaire
Par exemple JEAN A VENDU CHEMISE A PAUL: deux occurrences de PERSONNE

et une occurrence de PRODUIT).
- Une relation de dimension n est dite n-aire.
21
SMI / S5 FSDM
FONCTIONALITE : on définit la fonctionnalité d’une relation-type par rapport à deux entités-types X et Y. On

distingue les relations :
1 A 1 (1 – 1) : A toute occurrence de X ne correspond qu’une seule occurrence de Y et

réciproquement
Homme Est marié à Femme
Un homme n’est marié qu’à une femme et une femme n’est mariée qu’à un homme
1 A Plusieurs (1 – n) : A toute occurrence de X correspond une ou plusieurs occurrences de Y et à toute

occurrence de Y une seule de X.
Véhicule Est Possédé Personne
Une Personne possède 1 ou plusieurs Véhicules mais un véhicule est possédé par une
seule Personne
Plusieurs A Plusieurs (n – n) : A toute occurrence de X correspond une ou plusieurs occurrences de Y

et réciproquement.
Client Commande Produit
Un client peut commander plusieurs produits et chaque produit peut être commandé par
plusieurs clients
TOTALITÉ / PARTIALITÉ : Une relation mettant en jeu les entités X et Y est dite :
- Totale : si aucune occurrence de X et aucune occurrence de Y ne peuvent exister sans participer a

une occurrence de la relation.
Ex : Enseignant --- Enseigne --- CLASSE
1,n 1,1
22
SMI / S5 FSDM
- Partielle : si certaines occurrences de X ou certaines de Y peuvent n’être impliquées dans aucune

occurrence de la relation.
Ex : PERSONNE ---- POSSEDE ---- VOITURE
0,n 1,1
7.2.5 Cardinalités
La notion de cardinalité minimum / maximum permet d'exprimer la fonctionnalité et la totalité / partialité d'une
relation.
CARDINALITÉ MINIMUM d'une relation est le nombre minimum de fois où chaque occurrence d'une
entité-type participe à la relation-type.
Cardinalité minimum 0: correspond à une relation partielle

Cardinalité minimum 1: signifie qu'une occurrence d'entité-type ne peut exister sans participer à une
occurrence de la relation
Cardinalité minimum n: implique que toute occurrence d'entité-type participe obligatoirement à n
occurrences de la relation
Les cardinalités minimum non nulles correspondent à des relations totales.
CARDINALITÉ MAXIMUM d'une relation est le nombre maximum de fois où chaque occurrence d'entité-
type peut participer à une occurrence de la relation-type.
Cardinalité maximum 1: signifie que toute occurrence de l'entité-type ne peut participer qu'à une
occurrence de la relation, au plus.
Cardinalité maximum n: signifie qu'une occurrence de l'entité-type peut être impliquée dans un
maximum de n occurrences de la relation
Les cardinalités traduisent aussi des règles de gestion. Ce sont des règles propre au SI étudié, qui expriment des
contraintes d’intégrité du modèle. Ces contraintes d’intégrité représentent les lois de l’univers réel modélisé dans
le SI.
23
SMI / S5 FSDM
Représentation graphique (formalisme) :
Entités-types
Relation-type
Exemple:
1,1 0,n
Homme Est Fils de Femme
Un homme est fils d’au moins et d’au plus une femme, c’est-à-dire d’une femme et d’une seule.
Une femme peut n’avoir pas d’enfants (0 enfant) ou au contraire en avoir plusieurs (n enfants).
1,n 0,n
Enseignant Enseigne Matière
Un Enseignant fait au moins un enseignement. Il peut en faire plusieurs.

Une matière peut ne pas être enseignée. Si elle l’est, elle peut l’être plusieurs fois.
1,n
Enseignant 1,n Enseigne Classe
Une classe a au moins un enseignant et peut en avoir plusieurs.
L’identifiant d'une relation est le produit cartésien (concaténation) des identifiants des objets participant à la
relation. Par exemple, l'identifiant de la relation "HABITER" est:
"NUM CLIENT - CODE GEOGRAPHIQUE"
Chaque occurrence d’entité-type est identifiée de manière unique par un identifiant, qui est une propriété-type
particulière telle que 2 occurrences de l’entité-type ne peuvent pas avoir la même valeur pour cette propriété-type.
24
SMI / S5 FSDM
7.2.6 Règles de gestion (décidées par le Système de pilotage)
Les règles de gestion du MCD précisent les contraintes qui doivent être respectées par le modèle. Elles expriment
les CONTRAINTES D’INTÉGRITÉ du modèle et représentent les lois de l’univers réel modélisé dans le S.I.
Ex : Dans le MCD d’une école les règles de gestion peuvent être les suivants :
RG1 : tout professeur enseigne en principe au moins une matière, mais certains d’entre eux
peuvent être dispensés d’enseignement en raison de leurs travaux de recherche
RG2 : toute matière est enseignée dans au moins une classe
RG3 : toute classe a au moins trois enseignants Matière
1,n
0,n
Professeur Enseigne
3,n Classe
Contraintes statiques :
- sur une propriété :
Forme, liste de valeurs possibles, fourchettes de valeurs admissibles
- sur diverses propriétés d’une même relation ou entité :

Commande (N°cde, date_cde, date_livraison)
On doit toujours avoir date_cde < date_livraison
- sur des propriétés d’occurrences distinctes d’une relation ou entité

Ligne_écriture(N°ecriture, libellé, Montant, Sens)
La somme des montants des lignes de sens « D » (débit) doit être égale à celle des
lignes de sens « C »
- sur des propriétés d’entités/relations différentes

La somme des CA des produits doit être égale à celle des CA clients
- sur les cardinalités
- sur les dépendances fonctionnelles
Contraintes dynamiques :
Les CI dynamiques expriment les règles d’évolution et portent directement sur le passage
du SI d’un état dans un autre
Ex : Le salaire d’un employé ne doit pas diminuer
25
SMI / S5 FSDM
7.3 Dépendances fonctionnelles

7.3.1 Dépendances fonctionnelles entre propriétés
On dit que 2 propriétés a et b sont reliées par une dépendance fonctionnelle (a --- df --- > b) si la
connaissance de la valeur de a détermine une et une seule valeur de b
Ex:
Code-client ------ df ---- nom-client
La connaissance du Code-client détermine une et une seule valeur de nom-client. Autrement dit, si on
connaît le code du client, on doit pouvoir connaître son nom et celui-ci sera unique.
La réciproque est fausse. Le nom du client ne permet pas de déterminer son code, car plusieurs clients
peuvent avoir le même nom. Nom-client ---- df  code-client n’est pas vraie.
Dépendance fonctionnelle élémentaire : on parle de DFE entre les propriétés a et b (a  b) si (a --- df

--- > b) et si aucune partie de a ne détermine b
Ex :
Code-client + Nom-Client --------- df -------- > Adresse-Client n’est pas élémentaire
puisque la connaissance de Code-Client (partie de Code-Client + Nom-Client) suffit à
déterminer l’adresse
Code-client --------- df -------- > Adresse-Client est élémentaire et on peut écrire

Code-Client ----- > Adresse-Client
Dépendance fonctionnelle élémentaire directe : on dit que la propriété b dépend fonctionnellement de a

par une dépendance fonctionnelle élémentaire directe si cette dépendance est élémentaire a ---- > b et s’il
n’existe pas de propriété c telle que a --- df --- > c et c --- df --- > b (càd on élimine toute transitivité)
Ex :
N°Prof ---- > Code-matière
Code-matière ---- > Nom-matière
N°Prof --- > Nom-matière
Les 2 premières dépendances fonctionnelles sont directes, mais la troisième ne l’est pas
en raison de la transitivité (N°Prof --- > Code-matière ----- > Nom-matière).
7.3.2 Dépendances fonctionnelles entre entités
On dit qu’il existe une dépendance fonctionnelle entre deux entités A et B et on note (A B) si
toute occurrence de A détermine une et une seule occurrence de B.
La cardinalité maximum 1 correspond toujours à une DF
26
SMI / S5 FSDM
On peut assimiler les dépendances fonctionnelles entre entités aux dépendances fonctionnelles entre les
identifiants de ces entités.
Ex :
Commande ---- > Client
Est assimilable à :
N°cde --- > Code_Client
7.3.3 Propriétés des DF
Réflexivité : a --- df  a
Projection : a --- df  b +c  a --- df  b et a --- df  c
Augmentation : a --- df  b  V c : a+c --- df  b
Additivité : a --- df  b et a --- df  c  a --- df  b + c
Transitivité : a --- df  b et b --- df - c  a --- df  c
Pseudo-transitivité : a --- df  b et b +c --- df - d  a +c --- df  d
27
SMI / S5 FSDM
LA NORMALISATION
8 Règles relatives au MCD

8.1 La normalisation des entités
L'objectif de la normalisation est de construire, par rapport au MCD, un schéma cohérent. Un mauvais
schéma logique peut conduire à un certain nombre d'anomalies pendant la phase d'exploitation physique. Nous
allons voir ces anomalies dans une première partie. Pour qu’un modèle correspondant à un MCD soit normalisé, il
faut qu’il respecte certaines contraintes appelées les formes normales. Les formes normales s’appuient sur les
dépendances fonctionnelles entre attributs.
8.1.1 L’intérêt de la normalisation
Pour vous montrer l’intérêt de la normalisation, voyons les problèmes que peuvent poser l’utilisation d’une
représentation non normalisée.
Soit le schéma entité: FOURNISSEUR (NomFournisseur, AdresseFournisseur, Produits, Prix)
On peut distinguer les occurrences suivantes des attributs de cette entité :
NomFournisseur AdresseFournisseur Produit Prix

Ali 10 , Rue des Gras - Fès Chaise 20
Table 35
Said 86 , Rue neuve - Rabat Bureau 60
Taher 26 , Rue des Dômes - Méknes Lit 50
Said 39, Rue des Buttes - Fès Lampe 18
Table de chevet 25
1° problème :
Il n’y a pas de clé primaire : on ne sait pas si les deux Dupont sont différents ou pas (si c’est le même Dupont, il y
a une des deux adresses qui est fausse).
2° problème :
L’adresse n’est pas décomposée. Si on veut par exemple rechercher tous les fournisseurs qui habitent la même
ville, ça ne va pas être possible
3° problème :
Une relation (table) correspondant à ce schéma pourra éventuellement contenir plusieurs produits pour un même
fournisseur.
Dans ce cas, il faudra faire face à un certain nombre de problèmes :

 l'adresse du fournisseur sera dupliquée dans chaque occurrence (redondance),
 si on souhaite modifier l'adresse d'un fournisseur, il faudra rechercher et
mettre à jour toutes les occurrences correspondant à ce fournisseur,
28
SMI / S5 FSDM
 si on insère un nouveau produit pour un fournisseur déjà référencé, il

faudra vérifier que l'adresse est identique,
 si on veut supprimer un fournisseur, il faudra retrouver et supprimer tous les
occurrences correspondantes à ce fournisseur (pour différents produits) dans la table.
La normalisation élimine les redondances, ce qui permet:

- une diminution de la taille de la base de donnée sur le disque
- une diminution des risques d’incohérence
- d’éviter une mise à jour multiple des mêmes données
8.1.2 Première forme normale (1FN)
Une entité est normalisée en première forme normale si :

1) elle possède une clé qui identifie formellement chaque occurrence
2) chaque attribut dépend fonctionnellement de la clé
3) chaque attribut ne peut avoir qu’une seule valeur par enregistrement
4) aucun attribut n’est décomposable en plusieurs attributs
Exemple :
CLIENT (nom-client, adresse)
Cette entité n'est pas en 1FN, car il n’y a pas de clé (plusieurs clients peuvent avoir le même nom).
D’autre part adresse-client est sans doute la concaténation de rue et ville et ne constitue alors pas une
propriété élémentaire.
Il doit être :
CLIENT (code_client, nom, rue, ville)
8.1.3 Deuxième forme normale (2FN)
Une entité est en deuxième forme normale si et seulement si :

elle est en 1FN
toute propriété de l’entité doit dépendre de la clé par une dépendance fonctionnelle
élémentaire. Autrement dit toute propriété de l’entité doit dépendre de tout l’identifiant.
conséquence : toutes les entités qui n'ont qu'un seul attribut clé, sont en 2FN si elles sont en
1FN.
Exemple :
LIGNE (num_commande.num article, description_article, quantité_commandée)
L’identifiant de cette entité est la concaténation de num_commande et num_article.

Cette entité n'est pas en 2FN car la dépendance fonctionnelle num_commande.num article --- df --
 descritpion_article n’est pas élémentaire, puisque « description_article » ne dépend que d’une partie de la
clé « num_article »
29
SMI / S5 FSDM
Elle doit être :

LIGNE (num_commande)
Liée par la relation « Concerne (quantité) » à l’entité
ARTICLE (num_article, description_article)
8.1.4 Troisième forme normale (3FN)
Une entité est en 3° forme normale si et seulement si :

 elle est en 2° forme normale
 toute propriété de l’entité doit dépendre de l’identifiant par une dépendance
fonctionnelle élémentaire directe, c'est-à-dire qu’aucun attribut ne doit dépendre de la clé
par transitivité.
Exemple :
CLIENT (code_client, nom_client, code_categ, nom_categ)
Cette relation n’est pas en 3FN car la dépendance fonctionnelle code_client  nom_categ n’est pas
directe du fait de la transitivité code_client  code_categ  nom_categ
Ça doit être : CLIENT (code_client, nom_client)

Lié par la relation « appartient à » à l’entité
CATEGORIE (code_categ, nom_categ)
8.2 Application des règles

Si l’une des 3 règles n’est pas vérifiée, cela indique que le modèle n’est pas normalisé, il faut alors apporter des
modifications pour que les 3 règles soient vérifiées, si on souhaite la normalisation de notre schéma.
On vérifie les règles dans l’ordre. Si la première forme normale n’est pas respectée, pas la peine de vérifier la
2FN. Et si la 2FN n’est pas vérifiée, inutile de vérifier la 3FN.
Il existe d’autres formes normales mais on admet couramment que ces 3 premières formes normales sont
suffisantes pour permettre de construire des modèles fiables et cohérents.
8.2.1 Exemple de vérification :
Soit le MCD suivant :
Client Passer Commande Représentant

Code_client 0,n N°Bon Cde 0,n code_rep
Nom date nom_r
qté
30
SMI / S5 FSDM
La relation Passer Commande n’est pas vérifiée, car il peut y avoir plusieurs valeurs de la quantité dans une
commande passée par un client à un représentant. La quantité ne dépend pas seulement du client et du
représentant mais aussi du produit commandé. Autrement dit :
Dans une relation, les propriétés doivent dépendre fonctionnellement des identifiants des
entités concernées par la relation. La concaténation de ces identifiants constitue l’identifiant de la
relation.
8.2.1.1 Amélioration du MCD
Mais dans la relation COMMANDER PRODUIT, la quantité ne dépend pas seulement du client et du produit
mais aussi du n° de bon de commande (un client peut passer plusieurs commandes du même produit). Le n° de
commande n’est pas connu si on connaît CLIENT, PRODUIT et REPRESENTANT car il peut y avoir plusieurs
bons de commande pour un client donné, un représentant donné et un produit donné. La règle de vérification n’est
pas respectée.
Il faut, en fait, créer l’entité COMMANDE. D’où le MCD:
31
SMI / S5 FSDM
8.2.1.2 Normalisation des relations
Chaque propriété de la relation doit dépendre fonctionnellement de l’ensemble des identifiants des entités
qui participent à la relation, mais d’aucun sous ensemble de cet ensemble.
Il doit y avoir une dépendance pleine des propriétés de la relation par rapport aux entités.
Exemple:
Dans le MCD ci-dessus, on a:
N° bon de Cde  Date
car la date de la commande peut être connue si on connaît le n° de bon de commande.
La propriété date dépend de N° bon de Cde et donc d’un sous-ensemble de la concaténation code-client + Code-r
+ N° bon Cde et il n’y a pas dépendance pleine par rapport à l’ensemble des entités CLIENT REPRESENTANT
et COMMANDE qui participent à la relation PASSER COMMANDE.
La date est une propriété qui doit migrer dans l’entité COMMANDE.
Mais la quantité commandée est connue si on connaît le n° de bon de commande et la référence commandée, On a
donc:
N° bon Cde + Réf — Qté.
et la quantité est vérifiée sur le sous-ensemble COMMANDE x PRODUIT de la collection CLIENT X
COMMANDE x PRODUiT de la relation COMMANDER PRODUIT.
Celle-ci ne respecte donc pas la règle de normalisation.
La propriété Qté doit être affectée à une relation SE COMPOSE DE qui ne met en jeu que les entités
COMMANDE et PRODUIT.
D’où le MCD:
32
SMI / S5 FSDM
CIF
CIF: Contrainte d’Intégrité Fonctionnelle traduisant une dépendance fonctionnelle entre les deux entités
Commande et Client (toute occurrence de Commande détermine une et une seule occurrence de CLIENT)
8.2.1.3 Décomposition des relations
La décomposition consiste à remplacer une relation de dimension n en plusieurs relations de dimensions

plus petites en utilisant les dépendances fonctionnelles (ou Contrainte d’Intégrité Fonctionnelle) que l’on peut
détecter sur la relation.
Exemple:
Dans la relation COMMANDER PRODUIT du MCD précédent, on a la dépendance fonctionnelle :
COMMANDE  CLIENT.
En effet une Commande est passée par un et un seul client.

On peut donc éclater cette relation en deux relations
et
En fait la relation CONCERNE existait déjà dans la relation PASSER COMMANDE (la dépendance
COMMANDE  CLIENT provenait de la relation PASSER COMMANDE).
La décomposition n’est possible qu’à deux conditions:

1. La cardinalité minimum des entités à gauche dans la dépendance fonctionnelle doit être 1 dans la relation à
décomposer (relation totale pour ces entités).
2. Si la dépendance fonctionnelle provient d’une autre relation que la relation à décomposer, il faut qu’elle
concerne les mêmes occurrences d’entités que la relation à décomposer.
33
SMI / S5 FSDM
Dans notre exemple, la dépendance fonctionnelle qui a permis la décomposition est: COMMANDE
 CLIENT.
Cette dépendance s’applique sur la relation COMMANDER PRODUIT et la cardinalité minimum de

COMMANDE dans cette relation est bien 1 ce qui assure le respect de la règle 1.
La dépendance provient de PASSER COMMANDE.
La relation PASSER COMMANDE et la relation à décomposer COMMANDER PRODUIT mettent bien

en jeu les mêmes occurrences de CLIENT et de COMMANDE car ce sont les mêmes clients qui passent des
commandes et qui commandent des produits et car les produits commandés par les clients correspondent aux
mêmes commandes que les commandes passées par les clients. La condition 2 est donc remplie.
Dans le MCD la relation COMMANDER PRODUIT peut donc être décomposée en PASSER
COMMANDE et une nouvelle relation COMMANDER PRODUIT comme ci-dessus.
Celle-ci faisant double emploi avec SE COMPOSE DE peut être supprimée.

De la même manière, les dépendances fonctionnelles (dues aux cardinalités 1,1 de COMMANDE dans
PASSER COMMANDE) :
COMMANDE  CLIENT
et
COMMANDE  REPRÈSENTANT
permettent de décomposer PASSER COMMANDE en deux relations binaires PASSE COMMANDE (entre
CLIENT et COMMANDE) et OBTIENT COMMANDE (entre REPRÈSENTANT et COM MAN DE).
Le MCD suivant résulte de ces décompositions:
34
SMI / S5 FSDM
9 MODELE LOGIQUE DES DONNEES

Dans l'état actuel de la technique, la structure des données représentée sous forme d'un MCD ne peut être portée
sur un système informatique. Il convient donc de traduire le MCD en une structure transportable sur une machine,
cette nouvelle structure est représentée sous forme d'un schéma de données appelé Modèle Logique de Données
ou MLD. Le passage du MCD au MLD est assuré à partir d’un certain nombre de règles.
10 Les fondements du modèle relationnel

Après avoir conçu le Modèle Conceptuel de Donnée (MCD), il est maintenant temps de le transposer en Modèle
Logique de Données Relationnelles (MLDR). Ce MLDR est en fait le dernier pas vers le Modèle Physique de
donnée (MPD), c'est à dire la description de la base qui va être crée. Et là, deux solutions se présentent: soit vous
laissez à un progiciel le soin de transformer votre MCD, soit vous le faîtes vous-même. Dans les deux cas, il est
utile d'avoir un minimum de connaissance théorique sur le sujet. Nous étudierons quelques règles strictes,
nécessaires et suffisantes pour passer d'un MCD à un MLDR.
10.1 Les concepts du modèle relationnel
Les données sont représentées sous forme de TABLES appelées TABLES RELATIONNELLES.
Notation : ETUDIANT (num étudiant, nom, âge)
Une entité devient une Table Relationnelle

Une propriété devient un Attribut
L’identifiant devient Clé primaire
Le vocabulaire du MR et des SGBDR
MLD SGBDR
Relation entre entités Table
Attribut Colonne ou Champ
Occurrence ou Nuplet Ligne
Domaine Type
Clé primaire Index primaire
Attribut : C’est une donnée élémentaire du système d’information. Il n’est pas décomposable
Domaine de définition : L’ensemble des valeurs admissibles pour un attribut. Le plus souvent un type syntaxique
(Numérique, texte, ..).
Clé primaire : Un attribut ou plusieurs qui permettent d’identifier de manière unique chaque nuplet.
Le MLD est lui aussi indépendant du matériel et du logiciel, il ne fait que prendre en compte l'organisation des
données. C'est d'ailleurs le point primordial de la modélisation : si l'organisation des données est relationnelle (si
elles sont "liées" entre elles), alors le MLD est Relationnel et devient le MLDR, ou Modèle Logique de Donnée
Relationnel. Pour la petite histoire, le MLDR a été inventé par Codd en 1970, et repose sur la Théorie
Ensembliste.
35
SMI / S5 FSDM
10.1.1 A PROPOS DES CLES
10.1.1.1 CLE PRIMAIRE
Il s’agit de la clé qui assure l’unicité de l’occurrence (la ligne) pour que la table soit relationnelle. Cette clé
primaire est obligatoire
10.1.1.2 CLE ETRANGERE
Une propriété clé étrangère dans une table est Clé primaire dans une autre table. Elle permet de faire la jointure
entre les deux tables.
10.1.1.3 CLE CANDIDATE
Il s’agit d’un attribut qui n’est pas clé primaire de la table, mais dont on désire l’unicité de ses valeurs comme
pour la clé primaire (Quand on a plusieurs clés on en choisira une comme identifiant).
Exemple:
PERSONNE (matricule , nom, prénom, numéro Insee, adresse...)
Matricule est clé primaire
Numéro Insee est une clé candidate.
10.1.1.4 CLE SECONDAIRE
Il s’agit de l’indexation d’une colonne sur laquelle il y a de nombreux accès (optimisation des temps de
traitement).
10.1.2 Règles de passage du MCD au MLD
10.1.2.1 Cas des entités
Toute entité devient une table, l’identifiant de l’entité correspond à la clé de la table.
<==> CLIENT (id_client, Nom_Client, Tel_client)
10.1.2.2 Cas de relations binaires aux cardinalités (x,1) - (x,n) (où x=0 ou 1)
Les entités concernées deviennent des tables. La table qui correspond aux cardinalités 0,n ou 1,n
devient la table mère et celle qui correspond aux cardinalités 0,1 ou 1,1 la table fille.
La clé de la table mère est ajoutée aux champs de la table fille.
Commande 1,1 0,n Client

R
N0_cde, date Cd cl, Nom
36
SMI / S5 FSDM
Client
Table mère 
Cd cl, Nom
Clé de la table mère

Table fille  Commande
N0_cde, Cd_cl, date
Si la relation est porteuse de propriétés, celles-ci migrent dans la table fille
10.1.2.3 Cas de relations binaires aux cardinalités (x,n) – (x,n) (ou x =0 ou 1)

La relation est transformée en une table supplémentaire. Cette table est fille des tables correspondantes
aux entités pour lesquelles il y a cardinalités 0,n ou 1,n. Les clés de celles- ci migrent dans la table fille et leur
concaténation constitue la clé de celle-ci.
Si la relation n’est pas porteuse de propriétés, la table fille commune (lien) ne

contiendra que les clés de ses tables mères
Exemple :
37
SMI / S5 FSDM
TOURNAGE montre la carrière d’un acteur ou la distribution d’un film
10.1.2.4 Relation n-aire (quelles que soient les cardinalités)
Il y a création d'une table supplémentaire ayant comme Clé Primaire la concaténation des identifiants des
entités participant à la relation.
Si la relation est porteuse de donnée, celles ci deviennent des attributs pour la nouvelle table.
S.I : Un étudiant parle une ou plusieurs langues avec un niveau. Chaque langue est donc parlée par 0 ou n
étudiants avec un niveau. Pour chaque niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.
MCD :
MLDR :
ETUDIANT (id_Etudiant, Nom_Etudiant)

NIVEAU (id_Niveau, Nom_Niveau)
LANGUE (id_Langue, Nom_Langue)
PARLE (id_Etudiant, id_Niveau, id_Langue)
10.1.2.5 Cas de relations binaires aux cardinalités (0,1) – (1,1)
La Clé Primaire de la table à la cardinalité (0,1) devient une Clé Etrangère dans la table à la
cardinalité (1,1) :
S.I : Dans un centre de vacances, Chaque animateur encadre en solo 0 ou 1 groupe, chaque groupe
étant encadré par un et un seul animateur.
38
SMI / S5 FSDM
MCD :
MLDR :
ANIMATEUR (id_Animateur, Nom_Animateur)

GROUPE (id_Groupe, Nom_Groupe, #id_animateur)
10.2 Exemple de Base de données de type Relationnel
Soit le MLD relationnel suivant :
Le langage de description des Données (LDD) est le suivant :
39
SMI / S5 FSDM
Les diagrammes de flux
Les diagrammes de flux répondent à la question : Que fait le système ?
En ce sens, ce sont des modèles FONCTIONNELS (qui décrivent les fonctions)
Il existe2 types principaux de diagrammes de flux :
1) Le modèle de contexte (MC) où le domaine d’étude est vu comme une boite noire. On ne
représente que les flux extérieurs au domaine.
2) Le modèle de flux de données (DFD) ou encore modèle de flux conceptuels (MFC) où l’on
détaille les activités du domaine d’étude. On représente aussi les flux internes au domaine.
11 Vocabulaire associé aux modèles de flux

11.1 Domaine d'étude
Le domaine d'étude est un sous -ensemble cohérent de l'entreprise ou de l'organisme, bien délimité et formant le
contenu du sujet à étudier.
Domaine Dans les modèles de flux, le domaine d'étude est représenté par un rectangle à trait plein.
D’étude Le nom du domaine est placé à l’intérieur du rectangle.
11.2 Acteur externe
Un acteur externe est un élément émetteur ou récepteur de données, situé hors du système d'information
étudié.
Dans les modèles de flux, un acteur externe est représenté par un cercle plein. Le nom de
l’acteur est placé à l’intérieur du cercle.
Acteur
externe
11.3 Domaine connexe
Un domaine connexe est un composant du système d’information interagissant avec le domaine d’étude.
C’est un acteur interne à l’entreprise, mais externe au domaine d’étude
Domaine Dans le modèle de flux, un domaine connexe est représenté par un rectangle (ou un
connexe
rond). Le nom du domaine connexe est placé à l’intérieur du rectangle
40
SMI / S5 FSDM
11.4 Activité
L’activité est un ensemble de traitements homogènes qui transforment ou manipulent des données. Une
activité peut souvent être vue comme un sous -domaine d’étude, un morceau du domaine d’étude.
Chaque activité peut être éclatée. Cet éclatement se traduit alors par l’élaboration d’un nouveau diagramme qui
décompose ce processus éclaté en plusieurs processus plus élémentaires.
Dans les modèles de flux, une activité est représentée graphiquement par un
Activité
rectangle. Le nom de l'activité est placé à l’intérieur du rectangle.
11.5 Flux de données
Un flux est un transfert d’informations entre composants du système. Le composant peut être un domaine,
une activité ou un acteur externe.
Dans les modèles de flux, un flux de données est représenté

graphiquement par une flèche orientée du composant émetteur du flux
vers le composant récepteur. Le libellé du flux est inscrit en regard de la flèche
tracée.
Formalisme graphique illustrant par exemple un échange entre un acteur externe et le domaine d'étude :
12 Modèle de contexte
Le modèle de contexte sert à représenter les interactions entre le domaine d'étude et l’environnement, et entre le
domaine d'étude et les éventuels domaines connexes.
Le domaine d'étude y est représenté comme une boîte noire.
Le modèle de contexte utilise les concepts suivants :

le domaine d'étude
les acteurs externes
les flux de données
les domaines connexes
41
SMI / S5 FSDM
Exemple de modèle de contexte : au sein d’une société commerciale, on étudie le domaine

« gestion des ventes ».
Remarque
on ne fait pas apparaître les flux entre acteurs externes et domaines connexes, ou entre les domaines connexes.
Exemple : le flux correspondant à la livraison de marchandises n’apparaît pas.
13 Modèle de flux conceptuel (MFC) ou diagramme de flux de données

(DFD)
Ce modèle permet de décider quelles activités, inter-reliées de quelle manière, permettront de résoudre au mieux
le problème posé, et cette réflexion est menée sans s'encombrer dans un premier temps du comportement du
système (ordonnancement, règles d'émission, synchronisations…).
Les modèles de flux conceptuels permettent de décomposer le domaine d’étude en activités. Il n’y a pas ici de
notion d’organisation mais d’objectifs à réaliser. On représente les flux entre activités et avec l’environnement.
Pour analyser les communications et les activités, on procède par « zooms » successifs sur le domaine étudié pour
élaborer des modèles de plus en plus détaillés qui permettront d'avoir une cartographie détaillée du système et de
préparer le passage au modèle conceptuel de représentation des traitements.
Le modèle de contexte est également appelé le diagramme de flux de données de niveau 0.

Nous obtenons ensuite des diagrammes de premier, deuxième, troisième, … niveau, par éclatements successifs
des activités à chacun de ces niveaux.
La décomposition d’un domaine ou d’une activité en plusieurs activités peut faire apparaître de nouveaux flux dus
:
- à l’échange d’informations entre activités
- à la décomposition d’un flux présent au niveau n en plusieurs flux au niveau n+1.
Exemple : si on reprend le modèle de contexte précédent, on s’aperçoit que le domaine des ventes peut-être éclaté
en trois activités. Nous obtenons ainsi le diagramme de flux de données de niveau 1 :
42
SMI / S5 FSDM
Remarque
On peut décomposer le modèle de flux de niveau 1 en un modèle de flux de niveau 2 et etc … jusqu’à arriver à
un modèle où l’activité correspond à une opération au sens Merise (règle d’ininterruption).
Exemple : l’activité « gestion des factures » peut être encore décomposée en activités « facturation » et « Suivi
des règlements ».
13.1 Règles de décomposition des activités
Pourquoi décomposer ?
Pour désagréger les groupes de flux, pour arriver à la définition des flux-types du domaine étudié
Pour préparer l'étude dynamique du système d'information, pour arriver à l ’identification des processus et des
opérations conceptuelles
Comment décomposer ?
Identifier les groupes de données entrant et sortant du domaine d’étude pour construire le modèle de contexte
Identifier les activités générant ou traitant les flux de données pour construire le DFD de niveau 1 (approche par
les données) ou identifier une activité de niveau 1 comme un ensemble d’activités participant à une même finalité
(approche par les objectifs)
Jusqu'où décomposer ?
Lorsqu'une activité a atteint le niveau d'interruptabilité (dès lors que le traitement est déclenché, il se déroule sans
attente de ressources complémentaires extérieures). L'activité est alors une opération conceptuelle qui sera
décrite lors de l'étude dynamique du SI dans le MCTA.
43
SMI / S5 FSDM
MODELISATION DES TRAITEMENTS

La modélisation des traitements a pour but de faire la représentation dynamique du système d’information, c’est-
à-dire de représenter l’enchaînement des traitements réalisés. Cette modélisation s’effectue à deux niveaux :
- le niveau conceptuel où l’on s’intéresse aux opérations en dehors de toute mise en oeuvre organisationnelle.
- le niveau organisationnel, où se pose les questions du qui, où, quand
14 Modèle conceptuel de traitements

L’objectif du MCT est de répondre à la question QUOI faire par rapport à un événement. C’est la chronologie qui
importe. Autrement dit, le MCT est une représentation de la succession des règles de gestion dont l’entreprise
veut se doter pour répondre aux événements auxquels elle doit faire face, du fait de son activité et de son
environnement.
14.1 Les concepts du MCT
L’événement
C’est une sollicitation du système d’information qui génère une réaction de la part de celui- ci. Un
événement peut être externe au domaine étudié (ex : commande client) ou interne au SI, souvent le résultat
d’un processus antérieur (ex : ordre de préparation). Un événement peut-être aussi temporel, c'est-à-dire lié
à des dates qui rythment l’exécution de certains traitements (délai de maintenance, relances).
L’opération
C’est un ensemble d’actions accomplies par le système d’information en réaction à un événement ou à
une conjonction d’événements et non interruptibles par un événement externe, c'est-à-dire non soumis à
l’attente de nouveaux événements.
Remarque : Une opération déclenche au moins un résultat. Une opération est représentée par un verbe
ou mieux un substantif (ex : Préparer la commande ou préparation de la commande)
Le résultat
Un résultat peut-être un document, un message externe, un nouvel état du SI (nouvelle situation,
nouvelles données), créé par une opération, qui peut lui-même jouer le rôle d’événement.
Un résultat externe représente une information envoyée à l’extérieur du SI (ex : facture)
Un résultat interne est un nouvel état du système d’information (ex : ordre de préparation)
La synchronisation
Une synchronisation d’une opération marque le rendez-vous des événements contributifs qui doivent
être arrivés avant de déclencher l’opération.
C’est une condition booléenne (ET / OU) traduisant les règles de gestion que doivent respecter les
événements pour déclencher une opération. Dans le cas ET, elle marque qu'un événement déjà là doit en
attendre un ou plusieurs autres.
Remarque : Pour qu'il soit question de synchronisation, il faut la présence de plusieurs événements
déclencheurs; aussi, le symbole de synchronisation est laissé à blanc dans le cas d'un événement unique.
44
SMI / S5 FSDM
Si tous les événements entrants sont liés par le même opérateur, on peut seulement faire figurer
l'opérateur dans le symbole de synchronisation sinon il faut numéroter les événements (a, b ,c …) et constituer
l'expression à l'aide des événements et des opérateurs. (ex : (a ET b) OU c)
 correct
INCORRECT car la production de b

déclencherait l’opération 2 sans attente,
ce qui signifie que a aurait déclenché
OPE1ATION1 + OPEPATION2 sans attente,
soit en réalité une seule opération.

Règle d'émission
Condition, traduisant les règles de gestion, qui permet d'exprimer des conditions de sortie des
résultats. Remarques : L'expression d'une règle d'émission peut être composée de plusieurs conditions
élémentaires reliées par les opérateurs ET, OU. On peut également utiliser l'opérateur NON pour exprimer la
négation d'une condition.

Rôle des règles de gestion
Recensées lors de l'étude de l'existant ou définies pour le futur SI, elles décrivent les enchaînements
d'opérations. Elles rendent possible le regroupement des actions au sein d'une seule opération non
interruptible au niveau conceptuel.

Le processus
C’est un enchaînement synchronisé d'opérations au sein d'un même domaine, généralement
déclenché par un événement externe (externe au domaine ou au SI tout entier).
45
SMI / S5 FSDM
Schéma:
Un MCT est la représentation de l’enchaînement des opérations d’un processus.
Exemple :
Dans une grande administration, les demandes de promotion sont traitées selon les règles de
gestion suivantes:
Règle de gestion 1. Toute demande de promotion doit Subir un examen
préalable permettant de déterminer Si elle est recevable ou non.
Règle de gestion 2. L’examen du dossier d’une demande recevable ne peut se
faire qu’après rapport du supérieur hiérarChique.
Règle de gestion 3. Après examen du dossier par l’autorité compétente, la
promotion sera accordée ou refusée.
46
SMI / S5 FSDM
Modèle Conceptuel de Traitement :
Commentaires :
Des événements externes déclenchent le processus (la première opération du processus).
Toute suite ininterruptible d’actions (c’est-à-dire ne nécessitant pas l’arrivée de nouveaux événements) constitue
une opération.
Selon les règles d’émission, l‘opération « examen préalable » produit le rejet de a demande ou l’ouverture du
dossier.
Dans ce dernier cas une synchronisation est mise en jeu et correspond à l‘attente de l’arrivée de I’événement
externe « Rapport ». Lorsque celui-ci se produit, la synchronisation est activable et l’opération « Examen du
dossier » a peut se déclencher.
La règle d’activation est ici « Dossier ouvert ET Rapport du supérieur ». Elle se traduit par une proposition
logique avec des ET et/ou des OU portant sur des événements contributifs.
47
SMI / S5 FSDM
Selon la règle d’émission « avis favorable ou non », l’opération « examen du dossier » produit l’événement
résultat « Promotion refusée » ou l’événement résultat « Promotion accordée ».
L’attente de l’événement externe « Rapport » est une attente conceptuelle, non liée aux choix d’organisation.
Si on avait ajouté l’attente de l’événement « Service du personnel disponible » (dans la mesure où c’est le service
du personnel qui instruit le dossier, ce qui est un choix d’organisation), on aurait eu une attente organisationnelle
(attente de la disponibilité d’une ressource, ici le service du personnel) qui n’a rien a faire au niveau conceptuel.
Le MCT exprime ce qu’il faut faire, mais n’indique pas qui doit faire ni quand il faut faire ni où il faut
faire (concepts organisationnels) ni comment il faut le faire (concept opérationnel).
Le MCT exprime le quoi mais ni le qui, ni le quand, ni le où, ni encore moins le comment.
14.2 Méthode d’établissement d’un MCT
1) Réaliser le graphe des flux (représentation des acteurs, événements et résultats externes
2) Pour chaque événement, recenser les opérations déclenchées, et/ou les événements internes produits.
3) Regrouper dans une même opération tous les traitements qui ont les mêmes déclencheurs dans une unité de
temps, avec la même synchronisation
Règles de validation
Une opération ne peut pas être interrompue par l’attente d’un événement externe.
Si tel est le cas, il faut décrire une seconde opération déclenchée par cet événement en attente.
Cas particuliers
Cycles : pour une même opération, l'événement déclencheur et l'événement résultat sont identiques.
Une commande de client est servie si les marchandises sont disponibles, sinon cette commande est mise en
attente. Les commandes en attente sont réexaminées lors de chaque réapprovisionnement afin de les livrer.
Il faut s'assurer que le cycle a bien un début et une fin : ici, c'est l’événement "Réapprovisionnement effectué" qui
permet d'éviter que le cycle ne se déroule sans fin sur les commandes en attente.
48
SMI / S5 FSDM
Noter l'importance du concept d'occurrences d'événement :

- une occurrence de Réapprovisionnement est-elle autorisée à consommer toutes les occurrences de Commande en
attente ?
- si le réapprovisionnement est insuffisant, de nouvelles occurrences de Commande en attente doivent-elles être
créées ?
Les événements consommables

Un client non satisfait peut retourner un article. On lui fait un "avoir". Il peut alors le présenter en caisse pour être
remboursé de son achat. Il peut encore remplacer l'article défectueux par un autre, auquel cas on annule l'avoir.
Ce qui pose question :
UNE occurrence de l'événement "avoir établi" ne peut être consommée par 2 opérations (rembourser et imputer).
Autrement dit: "avoir établi" ne sait pas vers quelle opération se diriger. On pourrait se dire qu'il est implicite que
c'est le premier événement qui survient qui gagne : si Echange survient en premier, alors l'avoir est annulé.
Cependant, que se passe-t-il si les 2 événements externes se produisent simultanément ? Si on implémente un tel
schéma dans un automate, il est vraisemblable que le client pourra avoir le beurre et l'argent du beurre : se
présenter en caisse et faire l'échange pour un seul retour. Il est donc préférable d'expliciter (cf ci-après).
Une autre solution consiste à indiquer explicitement que cet événement est consommable, c'est-à-dire que la
première opération qui se déclenche annule l’événement pour l’autre opération.
49
SMI / S5 FSDM
15 Intégration des données dans le MCT (MCTA)

15.1 DEFINITION
Le MCTA est une représentation synthétique des traitements qui met en évidence les réactions du système aux
événements et l'interaction avec les données.
Il vise à
Décrire le fonctionnement du système indépendamment de l'organisation
Donner une vision des traitements et de la coordination des événements déclencheurs
Rapprocher les données et les traitements
15.2 FORMALISME DU MCTA
Pour mettre en évidence l’articulation entre les données et les traitements dans le MCT, on ajoute à droite de
chaque opération les entités ou associations qui sont consultées ou qui subissent un changement d’état (création,
mise à jour, suppression, …)
50
SMI / S5 FSDM
15.3 REPRESENTATION DES ACTIONS SUR LES DONNEES
Un objet correspond à une entité ou une association du MCD correspondant au champ d’étude du SI. Une
action est une manipulation (création, consultation, modification ou suppression) d’un objet du système
d’information. Elle est symbolisée par un trait entre l’opération et l’objet manipulé. Ce trait est non orienté s'il
s'agit d'une suppression et il est orienté pour les autres types de manipulation, le sens de la flèche dépend du type
de manipulation.
Un état d’objet est un stade transitoire par lequel passe un objet (entité ou association) au cours de sa « vie ».
Dans un MCTA, une opération est composée d'un ensemble d'actions sur les données.
Les actions sur les données sont de 4 types :
Création d’une occurrence
51
SMI / S5 FSDM
Suppression d’une occurrence
Consultation d’une occurrence
Modification d’une occurrence
L’action de modification inclut implicitement la ou les consultations préalables

On ne doit pas séparer les consultations qui précèdent les modifications des modifications elles-mêmes
Remarque générale
L’ordre des actions d’une opération sera si possible présenté de haut en bas.
COMPLEMENTS
Condition de déclenchement
L’action élémentaire peut être accompagnée d’une condition de déclenchement (à indiquer au niveau du trait ou à
côté de l’objet). Cette condition peut porter sur l’état de la structure des données à un moment précis et/ou sur le
type d’événement constaté à l’entrée de l’opération.
52
SMI / S5 FSDM
Action collective
Elle permet d’indiquer que l’action intervient sur un ensemble d’occurrences de l’objet concerné (toutes s’il n’y a
pas de condition de déclenchement associée limitant le nombre d’occurrences manipulées).
Exemple : en fin de mois, une compagnie d'assurances résilie les polices qu'elle a proposées dès que le délai de
signature de celles-ci est dépassé.
Cohérence de la base de données
Une BD a cohérent si elle ne comporte pas de contradictions (par rapport aux règles de gestion en particulier)
Une action peut ne pas laisser la structure de données dans un état cohérent.
En revanche, la cohérence doit toujours être assurée au niveau d’une opération.
REGLES DE VALIDATION D’UN MCTA
Une opération conceptuelle ne doit pas être interrompue par l’attente d’un événement externe
Une opération conceptuelle prend la structure de données manipulées dans un état cohérent et la rend dans un
état cohérent
53
SMI / S5 FSDM
Exemple de MCTA
C1 : si le client était précédemment un client prospect (c'est-à-dire client potentiel).

C2 : s'il s'agit d'un nouveau client ou si le client était précédemment un client prospect, le client est mis en
portefeuille (c'est-à-dire qu’il est réellement client)
C3 : si disponibilité de tous les produits (quantité en stock suffisante pour assurer la livraison)
Remarque : on considère ici qu’il n’y a pas de livraison partielle
54
SMI / S5 FSDM

Partie 1

Transféré par

Informations du document

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

Partie 1

Transféré par

Droits d'auteur :

Formats disponibles

Université Sidi Mohamed Ben Abdellah Cours Analyse et Conception de S.

ANALYSE ET CONCEPTION DE SYSTEMES D’INFORMATION

 L'essentiel sur Merise [Broché], Dominique Dionisi (Auteur)

 Merise - Concepts et mise en oeuvre [Broché], Drifa SEBA (Auteur)

 Comprendre Merise : Outils conceptuels et organisationnels [Poche], Jean-Patrick Matheron

 Exercices et cas pour comprendre MERISE [Broché], Jean-Patrick Matheron (Auteur)

INTRUDCTION A L’ANALYSE ET LA CONCEPTION DE S.I

1.2 Q’est ce qu’un système d’information de gestion

1.3 Les fonctions d’un système d’information

On peut distinguer 4 fonctions principales du système d’information :

Par rapport à ce système d’information existe :

Décisions pour Informations traités

Flux entrant de Système opérant Flux sortant

Figure 1: Système d’information dans le contexte d’une entreprise

Les ressources humaines interagissant avec le S.I peuvent être:

- Les différents logiciels

4 Les enjeux du développement informatique

 Les demandes des utilisateurs se renouvellent et s’accroissent, en quantité comme en qualité.

Il existe différentes méthodes de conception de S.I:

5.1 Composantes de Merise

Comme toute méthode d’analyse et de conception des SI, Merise regroupe :

Elle permet de représenter les composantes d’un SIG

6 Les principes de la méthode merise

- La démarche de construction où la construction d’un système d’information s’effectue selon trois

o Le cycle de vie : Il précise les différentes étapes de la construction et de l’exploitation d’un

6.1 La démarche par étapes

6.2 La démarche par niveaux

6.2.1 Le niveau conceptuel

Il a pour objet de décrire le système de gestion pour le domaine concerné.

Il est indépendant des choix d’organisation et des choix techniques

6.2.2 Le niveau organisationnel ou logique

- Qui fait quoi ? (les acteurs du système)

Il est indépendant des choix techniques. On s’attache à décrire :

6.2.3 Le niveau physique ou OPERATIONNEL

Il a pour objet de spécifier les choix techniques

6.3 Les modèles de représentation

Typologie présentant les différents modèles :

6.3.1 ENCHAINEMENT DES TRAVAUX

L’analyse du système existant conduit à construire :

L’analyse du système futur conduit à construire :

7 LE MODELE CONCEPTUEL DES DONNEES MCD

Le niveau conceptuel correspond à une formalisation du SI indépendante de toute contrainte

La formalisation des données, au niveau conceptuel, constitue le MODELE CONCEPTUEL DES

7.1 Définitions et formalisme

Le M.C.D est connu sous différentes dénominations, diagramme:

Voici un exemple introductif sur le recueil des données:

Différents interlocuteurs, différents points de vue. Lequel est le plus pertinent ?

Mais on ne recense que les informations objectives, formelles

7.2 Présentation des concepts et du formalisme MCD

Exemple : Adresse : rue + code postal + ville

Une propriété est dite ELEMENTAIRE si elle ne peut pas se décomposer

Exemple : rue, code postal et ville

Ex: Solde = différence entre CUMUL Débit et CUMUL Crédit

Une propriété peut aussi être portée par un événement.

On distingue 3 sortes de propriétés :

7.2.1.1 Classification des entités

Ex: CLIENT : on conserve les propriétés d’un client en permanence

Les propriétés d’une entité permanente peuvent être de deux types :

- propriétés signalétiques : correspondant à sa description, ex : CLIENT : nom, rue, ville …

SOLDE P = SOLDE P – 1 + cumul des mvts débit - cumul mvts crédit

7.2.1.1.2 Entité de type « mouvements »

Une entité de type mouvement est le souvenir d’un événement, dans le SI

7.2.2 Notion de relation

Bon de Commande (N°BC, Date)