Présentation de l’Analyse et

Conception des Systèmes

d’Information
ACSI

Définitions
• L’A.C.S.I. a pour objet l’analyse et la conception des
systèmes d'information (SI) des organisations.

• Le SI regroupe l’ensemble des ressources (humaines,

organisationnelles, matérielles, logicielles) permettant de
gérer (saisir, stocker, traiter, restituer, transmettre) toutes
les informations utiles aux décideurs et aux
opérationnels.

Système
de pilotage Flux de décisions
Système
d’information SI Flux d’informations
Flux
Système
opérant physiques

1
 Caractérisation « informatique » d’un SI

S.I.

infrastructure
(distribuée)
base(s) de applications
données (interactives ou non)
{règles} d’usage, de validation, de sécurité, de suivi et
d’évolution…

Algorithmique Programmation

Bases de données Interfaces utilisateurs

Réseaux et systèmes Systèmes distribués

Analyse et conception
• on s'intéresse en général à un domaine
d'activité de l'entreprise :
– ventes,
– production,
– logistique,
– finances,
– RH …
• on prend en compte les besoins des
utilisateurs,
• on définit le problème à résoudre :
fonctionnalités et qualités attendues.

2
 on définit une solution informatique :
- structuration des données,
- organisation des traitements,
- définition des postes de travail,
- choix techniques : matériels, langages de
programmation, logiciels de gestion de
données (SGBD)…

Démarche « très théorique »

analyse du problème conception de la solution

réalisation du système

Pas une démarche linéaire:

« analyse  conception  réalisation »

Analyser Concevoir Réaliser

ACSI

Un recueil des besoins exhaustif dès le départ n’est pas

réaliste dans les cas complexes.

3
 mais une démarche « itérative » :
processus de développement itératif et travail d’analyse
itératif sur le terrain :

4- Soumettre son
1- Poser des questions
Travail
Quoi? Pourquoi?
Comprendre le métier
Comment? Qui? …
Accepter les changements

2 - Analyser les réponses 3 – Modéliser

Cohérentes? Complètes? But? Lecteurs?
Suffisantes? … Notation?

La notion de modèle
• Au centre de la démarche d’ACSI.
• Modèle = représentation simplifiée d’une réalité sur
laquelle on veut être renseigné.
• S’exprime avec un ensemble de concepts dotés de
règles d’utilisation et de notations (souvent graphiques).
• En ACSI les modèles servent à :
communiquer : vérifier que l’analyste a bien compris
les utilisateurs grâce à des modèles du problème
(modèles d’analyse),
préparer la réalisation : grâce à des modèles de la
solution (modèles de conception).

4
 Un modèle…

La réalité ?

But ?
Lecteurs ?
Notation ?

Autant de modèles que de buts, de lecteurs, de

notations … de modélisateurs.

Modèle pour touriste

même
réalité

Modèle pour technicien

10

5
 Un modèle d’ACSI

11

Présentation de la méthode
Merise

12

6
 • En 1977 le Ministère de l’Industrie Français finance le
développement de Merise avec des SSII, le ministère
de l’équipement et des universitaires. Elle est libre de
droits (open source avant l’heure).
• Elle vise les SI construits autour des bases de
données relationnelles.
• Elle est encore aujourd’hui très utilisée en France,
même si elle est fortement concurrencée par les
approches à objets (UML). Il en existe plusieurs
versions (Merise, Merise 2, Merise Objet, …). Dans
la pratique beaucoup d’entreprises se limitent à un
Merise de base assez restreint.
• Elle n’a jamais été exportée en dehors des pays
francophones. Beaucoup de pays ont défini des
méthodes nationales (ex: Structured System Analysis
and Design Method – SSADM en Angleterre).

13

Les fondements
Merise adopte plusieurs points de vue.
1. Le cycle d'abstraction
Une démarche intellectuelle à 3 niveaux :
– le niveau conceptuel : répond aux questions
Quoi ? Avec quelles données ?
– le niveau organisationnel : répond aux
questions Qui ?, Ou ?, Quand ?
– le niveau physique : répond à la question
Comment ?

14

7
 Objectifs de cette décomposition :
– procéder de manière progressive,
– distinguer le quoi (plutôt stable) du comment
organisationnel et technique (plutôt instable),
– ne prendre en compte qu'une classe de
problèmes à chaque niveau.

Les trois niveaux d'abstraction s’appliquent

aux données et aux traitements
=> 6 modèles !

15

NIVEAUX DONNEES TRAITEMENTS

CONCEPTUEL MCD : sémantique des MCT quoi ?
données (modèle (fonctions du SI)
entité/association)
ORGANISATIONNEL MLD : organisation des MOT qui fait quoi,
(ou LOGIQUE) données (ex: modèle ou, quand ?
relationnel)
PHYSIQUE MPD implantation des MPT comment on
données (ex: SGBD fait ?
Oracle)
MCD : Modèle conceptuel des données
MLD : Modèle logique (organisationnel) des données
MPD : Modèle physique des données
MCT : Modèle conceptuel des traitements
MOT : Modèle organisationnel des traitements
MPT : Modèle physique des traitements

16

8
 Les questions abordées à chaque niveau

NIVEAU CHOIX CONTENU

CONCEPTUEL GESTION, données traitées, règles de

‘METIER’ gestion, enchaînements des
traitements, …

ORGANISATIONNEL ORGANISATION partage homme/machine,

LOGIQUE interactif/différé, organisation
des données et traitements,
distribution,…
PHYSIQUE TECHNIQUE programmes, écrans, états,
organisation physique des
données, matériel, réseau,
…

17

« courbe
du soleil »
concevoir

faire abstraction des

détails

détailler la réalisation

observer

18

9
 2. Le cycle de vie
Démarche d’informatisation : succession de
phases contrôlables par l’organisation (planning,
échéances, moyens humains, …). Pour gros projets.
1. L’analyse et conception.
1.1. Construction du schéma directeur global
Politique globale d’informatisation à 3/5 ans.
Grandes orientations (développement interne, progiciels,
externalisation, …).
Moyens (personnel, matériel, logiciels, ...).
Pas détaillé dans ce cours d’ACSI (pour décideurs).
1.2. Étude préalable par domaine (ex: gestion
commerciale, gestion du personnel, …)
Analyse de l’existant (problème à résoudre – implique
les 3 niveaux d’abstraction).
Objectifs de l’informatisation.

19

Proposition et évaluation de différentes solutions.

Dossier de choix et choix par la direction.
Première partie du cours d’ACSI
1.3. Étude détaillée par projet (ex. dans domaine
commercial : devis, facturation, règlements, …)
Spécifications de la solution : données, traitements,
interfaces utilisateurs.
Cahier des charges de l'application (contrat vis à vis
des utilisateurs).
Dossier d'étude détaillée pour les analystes-
programmeurs.
Cahier des charges pour appel d'offres.
Deuxième partie du cours d’ACSI.

20

10
 2. La réalisation qui consiste à produire le logiciel
pour chaque projet/application et à le mettre en
place.
2.1. Étude technique
Spécifications techniques complètes (base de donnée,
programmes, écrans, états).
Documentations techniques et documentations
utilisateur.
2.2. Production logicielle
Ecriture des programmes et tests.
2.3. Mise en service
Installation de l'application informatique, formation des
utilisateurs.
3. La maintenance du SI qui consiste à l'adapter
aux évolutions de l'environnement : correction
des anomalies, améliorations, évolutions.

21

3. Le cycle de décision
Durant le cycle de vie, des décisions sont à prendre
aux différentes étapes (possibilités de conflits) :
Etapes Décisions
Schéma directeur approbation et mise en application
du plan de développement (3 à 5 ans)
Etude préalable choix d'une solution
Etude détaillée accord des utilisateurs sur
spécifications fonctionnelles
Etude technique accord du chef de projet sur
spécifications techniques
Production recette provisoire, conformité solution
Mise en service recette définitive, système en service
Maintenance recette maintenance

22

11
 L’étude de l’existant
Le modèle des
communications
(ou modèle ‘acteurs/flux’)

23

Le recueil des informations

But faire un inventaire exhaustif des
échanges d'information entre les différents
intervenants (acteurs) du domaine étudié.
Documents types pour la collecte
- descriptif de poste de travail
- descriptif de document
- descriptif de fichier
- inventaire des flux d'informations

24

12
 Le modèle des communications
(modèle acteurs/flux)
Définitions
• Flux : lot d'informations transmis entre deux
acteurs du SI étudié.
• Acteur : tout ce qui peut émettre ou recevoir
des flux.
Par ex. : un domaine d'activité, un service, une
personne, une fonction ou sous-fonction d'une
organisation
Acteur externe : entité externe à l'organisation ou au
domaine étudié. Ex : client, fournisseur, banque, …
Acteur interne : appartient à l'organisation ou au domaine
étudié. Ex : service production, service commercial, …

25

Flux interne : émis par un acteur interne au SI

étudié.
Flux externe : émis par un acteur externe au SI
étudié.

Le choix interne/externe est fondamental : il

décrit la frontière du domaine étudié. C’est à
faire tout au début d’une analyse.
Ce choix doit être négocié avec les
demandeurs de l’informatisation.

26

13
 Matrice et graphe des flux
Représentation graphique des flux d'informations.
• matrice des flux :
Tableau qui décrit les flux d'information entre
acteurs :
- les acteurs figurent en tête des lignes et des
colonnes;
- un flux apparaît à l'intersection d'une ligne et
d'une colonne.
• graphe des flux : représentation graphique de la
matrice des flux.

27

Émetteur / Acteur1 Acteur2 Acteur3

Récepteur

Acteur 1 Flux 1 Flux 3

Acteur 2 Flux 2
Acteur 3 Flux 4

Remarque : cette forme incite à regarder toutes les combinaisons

Possibles.
Flux 2

Acteur 1 Flux 1 Acteur 2

Flux 3 Acteur 3 Flux 4

28

14
 Exemple : Gestion des sinistres dans une société
d’assurance
A l'arrivée d'une déclaration de sinistre, on
l'examine. Si la déclaration est recevable, on
demande l'avis d'un expert, sinon on notifie le
refus à l'assuré. Au retour de l'expertise et après
réception de la facture du garage, on calcule le
montant du remboursement et on envoie le
chèque au client.
Liste des acteurs SOCIETE D’ASSURANCE (int),
CLIENT (ext), EXPERT (ext), GARAGE (ext)
Liste des flux DECLARATION, DEMANDE AVIS,
FACTURE, REFUS, AVIS EXPERT, CHEQUE

29

Déclaration
Refus Client
interne Assureur
externe
Chèque

Avis Facture
Demande
d’avis
Expert Garage

externe externe

30

15
 Lorsque le graphe comporte plusieurs
acteurs internes on regroupes parfois tous
ces acteurs en une même entité
(correspondant au SI à étudier) et on ne
garde que les flux en entrée et en sortie.
C’est le ‘graphe des flux contextuel’.

SI complet

Acteurs Acteurs
externes externes

31

A partir de ce schéma on peut dresser la liste

de tous les événements en entrée du
système (arrivée d’un flux sur un acteur
interne) et tous les événements en sortie
(départ d’un flux sur un acteur interne vers un
acteur externe). C’est important pour la suite
de l’analyse.
Sur l’exemple :
- événements en entrée : arrivée d’une
déclaration, d’un avis d’expert, d’une facture
garage,
- événements en sortie : production d’un
refus, d’un chèque, d’une demande d’avis

32

16
 L’étude de l’existant
Le schéma de circulation
des documents

33

• Représentation du fonctionnement du SI existant avec

tous les détails de l’organisation actuelle (niveau
organisationnel).
• Très utilisé. Ne fait pas partie de Merise qui propose à la
place le MOT (nous verrons le MOT plus tard car il
dérive du MCT que nous présenterons d’abord).
• Prise en compte :
– des événements en entrée et en sortie,
– des postes de travail,
– des traitements et moyens (ex: fichiers),
– du temps.
• Démarche
– Recueil
– Modélisation

34

17
 MCT MCT

MOT MOT
Acteurs/flux et Circulation documents

35

Concepts
Evénement : fait nouveau qui :
– déclenche une réaction de la part du SI (traitement),
– est porteur d'informations utiles au SI.
Événement externe : issu de l'univers extérieur.
Événement interne : construit par le SI
– soit destiné à l'univers extérieur,
– soit réutilisé au sein du SI.
Ex :
• Arrivée d’un flux (document) externe ou interne au SI, mais
aussi :
• Date ou périodicité (ex: tous les matins).
• Changement d’état du SI (ex: seuil de réapprovisionnement d’un
produit est atteint).
• Décision ou ordre de faire une action.

36

18
 Poste de travail
Ressources affectées à la réalisation d'une activité
= acteur.
Phase de traitement
– suite d'actions (tâches) exécutées
• par un acteur sur un poste de travail,
• de manière continue (sans interruption),
• à la même date ou même périodicité.
– déclenchée par un (ou plusieurs) événement(s),
– qui construit un (des) flux (résultat) destiné :
• à l'univers extérieur au domaine d’étude,
• à une autre phase de traitement.

37

Phase de traitement est caractérisée par :

- les acteurs concernés (QUI),
- les actions/tâches effectuées (QUOI),
– saisir des données,
– contrôler, vérifier, valider des informations,
– consulter des données mémorisées (fichiers),
– mettre à jour des données mémorisées : création,
suppression, modification,
– faire des calculs (ex: établir des factures...) ,
– afficher, imprimer, éditer des résultats,
– prendre des décisions (annuler une commande,
réapprovisionner le stock).
- la date ou la périodicité et la durée (QUAND),
- les résultats (POURQUOI),
- les moyens utilisés : fichiers manuels, informatisés…
(COMMENT)

38

19
 Symboles utilisés dans les schémas de circulation des
documents (pas normalisé)
Principaux Secondaires

Fichier
informatique
Document archivé

Fichier
manuel Document détruit
Rattachement
Rupture temps
Document entre phases

Phase de etc.
N° traitement

39

date/période Assureur QUI Client Expert Garage

as ds
Liste des flux et fichiers
ds : DECLARATION
jour j, 9h
1 av : RAPPORT EXPERT
QUAND fa : FACTURE
re : REFUS
re da
da : AVIS EXPERT
ch : CHEQUE
av ra : fichier des rapports
d'experts
jour j1 2 as : fichier des assurés

ra COMMENT
fa
Liste des phases
jour j2 3
1. Recevabilité de la déclaration
2. Enregistrement de l’expertise
ch
3. Règlement du sinistre
POURQUOI QUOI

40

20
 Beaucoup plus détaillé que :
Déclaration

interne Assureur Refus Client

externe
Chèque
Avis Facture
Demande
d’avis
Expert Garage

externe externe
Mais les 2 schémas doivent être cohérents :
mêmes acteurs et mêmes flux entrants/sortants.

41

Le modèle conceptuel des

traitements

42

21
 MCT

Acteurs/flux Circulation Documents

43

Le Modèle Conceptuel des Traitements

Il décrit le fonctionnement du SI d’une organisation au
niveau conceptuel : on fait abstraction des contraintes
d’organisation et techniques; on ne décrit que les
règles fondamentales de gestion (les invariants, ‘le
métier’ de l’organisation). Description la plus stable.

Exemple introductif
Les demandes d'ouverture de compte bancaire doivent
suivre les règles de gestion suivantes :

Règle 1 : Toute demande d'ouverture de compte doit faire

l'objet d'un examen préalable.

Règle 2 : L'accord définitif d'ouverture ne peut être donné

qu'après avis de la Banque de France.

44

22
 demande d’ouverture

Instruction de la demande
Recevable Non recevable

demande
avis BdF demande demande
instruite rejetée
a b
Avis de
la BdF a et b
On suppose que ce
Décision d’ouverture découpage est bien
une règle de gestion
OK non OK
et pas un simple
choix d’organisation
compte ouverture du travail.
ouvert refusée

45

Le fonctionnement du SI est décrit :

• par l’enchaînement d’opérations,
• déclenchées selon certaines conditions de
synchronisation (et, ou, …),
• par des événements contributifs (internes
ou externes),
• et produisant d’autres événements résultats
(internes ou externes).

46

23
 Opération
Événement précédente
Événement
contributif
externe contributif
interne

a b c
Schéma d’une
[ Proposition logique (a,b,c) ] opération
acteur conceptuelle

Nom de l' opération

Règle Règle
Émission … Émission

Événement Événement
résultat résultat
externe interne
Opération
suivante
Remarque : les acteurs sont facultatifs

47

Événement contributif externe

• C’est un stimulus pour le SI qui provoque une
réaction. Il doit être détectable par le SI.
• C’est un message c’est à dire un ensemble de
données qui sont associés au fait nouveau.
Opération
• Séquence continue d’actions non interruptible.
• Déclenchée par un ou plusieurs événements
contributifs internes ou externes.
• Produit des événements résultats internes ou
externes, conditionnés par des règles
d’émission.

48

24
 Les actions sont constituées :
• des traitements appliqués aux données en
entrée selon certaines règles,
• des tâches de consultation et de mise à jour
d’une base d’informations (base de données)
implicitement accessible.
Synchronisation
• Condition exprimée sur les événements
contributifs, qui détermine le déclenchement
d’une opération.
• S’exprime sous la forme d’une proposition
logique utilisant des et et des ou (on évitera au
maximum le non, les non-événements n’étant
pas toujours détectables par le SI)
Exemple : a ou (b et c)

49

Règles d’émission
Elles caractérisent les résultats possibles de
l’opération.
Ex: Prise en compte
d'une commande

OK Produit conditions d'émission

non disponible des messages

cde absence
à livrer produit

• les conditions d’émission des résultats d’une opération ne

sont pas nécessairement exclusives (un résultat peut être
émis par deux règles d’émission distinctes)
• les conditions d’émission portent souvent sur des cas
d’anomalies (ex : une rupture de stock).

50

25
 Les Types d’événement
• Evénements contributifs externes : proviennent
de l’univers extérieur, sont traités par une
opération conceptuelle (ex: arrivée d’un flux
d’entrée, date de déclenchement),
• Evénements contributifs internes : générés par
une opération conceptuelle, contribuent au
déclenchement d’une autre opération (état
intermédiaire du SI ou état d’attente),
• Evénements résultats : générés par une
opération conceptuelle et destinés à l’univers
extérieur (résultats externes) ou à d’autres
opérations (résultats internes).

51

Construction du MCT
LISTE DES ACTEURS ET DES FLUX

GRAPHE DES FLUX

LISTE DES EVENEMENTS REGLES DE GESTION

EN ENTREE ET EN SORTIE

MODELE CONCEPTUEL
DES TRAITEMENTS

52

26
 Étape 1A partir du graphe des flux (complet ou contextuel),
on construit la liste de tous les événements en entrée et
en sortie du SI.
Étape 2 Passage au MCT
• tout événement en entrée se retrouve en entrée d'une
opération,
• il existe d’autres événements en entrée (ex: des dates
conceptuelles),
• tout événement en sortie est produit par une
opération,
• une opération peut avoir plusieurs événements
contributifs vérifiant une règle de synchronisation,
• une opération peut avoir plusieurs événements résultats
émis selon certaines règles d'émission,
• une opération peut ne construire aucun événement
résultat mais uniquement des événements internes,
• tout événement résultat est destiné soit à un acteur
externe, soit à une autre opération,
• le découpage en opérations est guidé par les règles de
gestion.
53

Exemple : facturation
Bon de cde

Événement externe
client en entrée (arrivée flux)
Traiter bon cde
sur place à expédier

fin mois Bon expédition

Cde livrée client

a et b
Événement interne Établir facture Date
(état attente toujours conceptuelle
intermédiaire)
Événement résultat
client facture externe (émission flux)

54

27
 Gestion des sinistres
Déclaration accident
client

Ouverture dossier
Demande Décl. OK Non OK client
d’avis
Dossier Dossier Lettre refus
ouvert classé
expert
Avis
expert a et b et c
Facture garage
Paiement
garagiste
toujours

Dossier États finaux

client
Chèque clôt (conseillés)

55

Quelques schémas de base (1)

OP État
(OU) d’attente
X (OU) D

OP1 OP2

Alternative entre Alternative entre quelque

opérations chose ou rien
(choix entre OP1 et OP2 (arrivée d’un flux X
selon le résultat de OP) OU pas de flux X et
délai D dépassé)

56

28
 Quelques schémas de base (2)

b a OP1 OP2
a ET b
OP (ET)

a b
a ET b
OP1 OP2
OP

Itération Parallèle divergente Parallèle convergente

(répéter OP) (‘fork’) (‘join’)
(OP1 et OP2 en //) (OP après OP1 et
OP2 en //)

57

Le modèle conceptuel des

données

58

29
 Objectif du MCD
Décrire les données du SI, indépendamment
de tout choix d'implantation physique.

1. Le dictionnaire des données

• Inventaire exhaustif des données du domaine
étudié.
• On utilise habituellement :
– une fiche "descriptif de document" (une par
document),
– une fiche récapitulative "descriptif des données".

59

Les données sont décrites par :

• un identificateur mnémonique unique,
• un type (numérique, alphanumérique, ...) et une taille,
• un mode d'obtention :
– donnée mémorisée,
– donnée calculée,
– donnée "paramètre" : donnée utile à un traitement
et non mémorisée (ex: date d'édition d'un
document),
• une règle de calcul (pour les données calculées),
• des contraintes d'intégrité: intervalle de valeurs, liste
de valeurs, ...

60

30
 DESCRIPTIF DES DONNEES
Domaine : Rédacteur : Date :
Processus :

Rubriques Libellé Type Mode D1 D2 D3 D4

identificateur libellé entier mémorisée x x

réel calculée x
date paramètre x x x x
chaîne
booléen

61

2. Le modèle conceptuel des données : le

modèle entité/association (cf. cours BD
1°A)
a) les concepts de base du modèle E/A,
b) vérification et normalisation du modèle E/A,
c) les contraintes d'intégrité dans le modèle
E/A.

62

31
 a) Les concepts de base
Entité : tout objet concret ou abstrait ayant une
existence propre et conforme aux besoins de
gestion de l’organisation.
Ex: le client «Dupond», le produit de référence «a456», …
Classe d’entités (ou entité-type) : ensemble des
entités décrites par les mêmes caractéristiques.
Ex: la classe CLIENT dont «Dupond» est une occurrence
(ou instance).
Association : n-uplet d’entités « sémantiquement
liées ».
Ex: («Dupond», «1367 VS 54») indiquant que la
personne Dupond est propriétaire de la voiture
immatriculée 1367 VS 54.

63

Classe d’associations (ou association-type) :

regroupe toutes les associations constituées des
mêmes types d’entités jouant le même rôle dans
l’association.
Ex: PROPRIETAIRE(PERSONNE, VOITURE)
Les occurrences de cette classe d’association sont un
sous ensemble du produit cartésien PERSONNE x
VOITURE (c.à.d. une partie de l’ensemble des couples
possibles de personnes et de voitures).

PERSONNE VOITURE

PROPRIETAIRE

64

32
 Remarques
• On peut avoir plusieurs classes d’associations
sur les mêmes classes d’entités.
Ex : PROPRIETAIRE(PERSONNE, VOITURE)
et CONDUIRE(PERSONNE, VOITURE)
• On peut avoir une classe d’association sur une
seule classe d’entités (on parle d’association
‘réflexive’). On ajoute souvent dans ce cas des noms
de rôles pour distinguer les deux occurrences.
Ex : CONJOINT(PERSONNE, PERSONNE)

PERSONNE
époux
CONJOINT
épouse

65

• On peut avoir une classe d’association

définie sur n classes d’entités (association n-
aire ou d’arité n ou de dimension n ou à « n
pattes »).
Ex: COURS(MATIERE, CLASSE, PROF)

Attention : les arités élevées sont rares. Elle

dénotent souvent des faiblesses dans
l’analyse. arité 2 : 80%
arité 3 : <20%
arité > 3 : 

66

33
 Propriété : donnée élémentaire permettant de
caractériser les entités et associations
Ex : nom, prénom, adresse propriétés de
PERSONNES

PROFESSEUR MATIERE
COURS
Nom, Jour, Refmat,
Prénom, Heuredeb, Intitulé
Adresse, Heurefin
Age

CLASSE
Refclasse,
Numsalle

67

Identifiant : propriété ou groupe de propriétés

permettant d’identifier de manière unique
chaque occurrence de la classe d’entités.
Ex : N° immatriculation pour VOITURE. Nom ne suffit
pas pour PERSONNE. N° Client pour CLIENT (propriété
ajoutée)
Les identifiants sont en général soulignés.
Cardinalités : indiquent pour chaque classe
d’entités de la classe d’association, les nombres
mini et maxi d’occurrences de l’association
pouvant exister pour une occurrence de l’entité.
La cardinalité minimum est 0 ou 1.
La cardinalité maximum est 1 ou n.

68

34
 Une cardinalité minimum à 0 signifie qu’il est possible
d’observer (un jour) une occurrence d’entité sans
occurrence d’association.
Donc 4 combinaisons possibles :
0,1 au plus 1
1,1 1 et 1 seul
1,n au moins 1
0,n un nombre quelconque

Ex: PROPRIETAIRE(PERSONNE [0,n],

VOITURE [1,1])
Une personne a 0 à n voitures; une voiture a 1 et 1
seul propriétaire.

69

CONDUIT(PERSONNE [0,n], VOITURE [1,n])

Une personne conduit 0 à n voitures; une voiture est
conduite par 1 à n personnes.

Représentation graphique :
Sens de lecture destination
source
PERSONNE VOITURE
0,n PROPRIETAIRE 1,1

70

35
 COURS(MATIERE [1,n], CLASSE [1,n], PROF[1,n])
Un prof. a 1 à n cours dans la semaine, une matière a 1 à
n cours dans la semaine, une classe a 1 à n cours dans la
semaine.

PROF MATIERE
COURS
Nom, 1,n Jour, Refmat,
1,n Intitulé
Prénom, Heuredeb,
Adresse, Heurefin
Age
1,n
CLASSE
Refclasse,
Numsalle

71

b) Vérification et Normalisation
Contrôler la qualité du modèle vis-à-vis :
 des fondements du modèle d’une part (règles
de vérification),
 de la redondance de données d’autre part
(règles de normalisation) .
Permet de détecter certaines incohérences dans
la construction des modèles.
1. Règles Générales
• Toute propriété doit apparaître une seule fois
dans un modèle.
Il faut éliminer la redondance des propriétés dans la
même entité (avec des noms différents) ou dans des
entités distinctes :

72

36
 PRODUIT PRODUIT TARIF
1,n
prix1 coûte
code-tarif
prix2 prix libellé-tarif

CLIENT PROSPECT CONTACT

code-client code-prospect code-contact

nom-client nom-prospect nom-contact
type (C, P)

Pas d’héritage dans le modèle E/A de base !

• Toutes les propriétés identifiées doivent

apparaître dans le modèle.

73

2. Règles sur les entités

2.a Règle de l’identifiant
Toutes les entités ont un identifiant.
2.b Règle de vérification des entités
Pour une occurrence d’une entité, chaque
propriété ne prend qu’une seule valeur (cf. la
1FN du modèle relationnel); MONO-VALUEE
Employé Employé Enfant
Matricule Matricule Matricule
Nom Nom Prénom-
Prénom- enfant
enfant

On décompose l'entité Employé en deux entités : Employé, et

Enfant

74

37
 2.c Règles de normalisation des entités
a) Les dépendances fonctionnelles (DF) entre
les propriétés d’une entité doivent vérifier la
règle suivante : toutes les propriétés de l’entité
dépendent fonctionnellement de l’identifiant et
uniquement de l’identifiant.
Rappel :  une DF XY si à une valeur de X correspond
une et une seule valeur de Y (réciproque pas vraie).
Voiture Voiture Propriétaire
N°immatric. N°immatric. N° insee
Type Nom
N° insee Type
Adresse
Nom
Adresse

La DF: N°insee Nom, Adresse contredit la règle.

75

b) Une partie de l’identifiant ne peut pas

déterminer certaines propriétés.
Commande

N°comm Commande LigneCom

N°prod
N°comm N° comm
Qté
DateCom
DateComm
N°Client 0,n 1,1 N°prod
N°client Qté

La DF n°-comm  date-comm, n°-client contredit la

règle. On décompose l’entité Commande en deux
entités.
Ces règles correspondent aux 2FN et 3FN du modèle
Relationnel (dépendance pleine et directe des clés).

76

38
 3. Règles sur les associations
3.a Règle de vérification des associations
Pour une occurrence d’association, chaque propriété
ne prend qu’une seule valeur.
3.b Règle de normalisation sur les propriétés
des associations
Toutes les propriétés de l’association doivent
dépendre fonctionnellement de tous les identifiants
des entités portant l’association, et uniquement d’eux.
Voiture autorisé Personne
Date-aut N°insee
N°immatr
Date-permis

N°-insee  Date-permis pose problème (donc déplacer

Date-permis vers Personne)

77

3.c La décomposition des associations n-aires

Il faut garder un minimum d’associations d’arité > 2.
Si on observe une DF entre un sous-ensemble des
entités d’une association, on peut la décomposer en
deux associations (on parle aussi de ‘contrainte
d’intégrité fonctionnelle’ ou CIF).
Prof Matière
N°prof N°mat
0,n 0,n
Nom
cours
salle, heure
Classe
0,n
N°classe

Une éventuelle DF N°prof  N°mat donne la décomposition :

78

39
 Prof 1,1 1,n Matière
assure N°mat
N°prof
Nom
cours
0,n
salle, heure Classe
0,n N°classe

C’est le cas, quand une patte a une cardinalité 1,1.

Par exemple à 1 contrat est associé un client et un local :
Client Local

Client 0,n 0,n Local 0,n 0,n

location
concerne porte-sur
1,1
Contrat 1,1 1,1
Contrat

79

3.d La suppression des associations transitives

Toute association pouvant être obtenue par transitivité de n
autres associations peut être supprimée.

Facture 1,1 1,n Commande

concerne

1,1
1,1 obtenue_par
associée_a
1,n
Représentant
1,n

On supprime l'association associée_a, car elle peut être

obtenue par transitivité sur les associations concerne et
obtenue_par

80

40
 Une démarche de construction ?
Certains auteurs suggèrent la démarche suivante :
1 Analyser l'existant et constituer le dictionnaire des données
2 Épurer les données (éliminer synonymes et polysèmes)
3 Dégager les ‘entités naturelles’ grâce aux identifiants
existants déjà dans l’organisation
4 Rattacher les propriétés aux entités
5 Recenser les associations entre entités et leur rattacher
leurs éventuelles propriétés
6 Déterminer les cardinalités
7 Décomposer si possible les associations n-aires (cf. règles)
8 S'assurer de la conformité du modèle aux règles de
construction (cf. règles)
9 Normaliser le modèle : s'assurer qu'il est en 3FN

81

Le modèle logique des

données relationnel

82

41
 Le Modèle Logique des Données (MLD) est
une étape intermédiaire pour passer du modèle
E/A, qui est un modèle sémantique, vers une
représentation physique des données : fichiers,
SGBD hiérarchique, SGBD réseau, SGBD
relationnel.
Nous nous limitons au seul MLD relationnel, qui
prépare le passage aux SGBD relationnels.

83

Modèle logique relationnel (rappel)

La table relationnelle correspond à un objet du SI
(commande, client …).
Elle est composée d’attributs/colonnes : les
données élémentaires qui décrivent l’objet
( n° commande, date commande, …).
Elle possède une clé primaire (sous-ensemble
d’attributs) dont la valeur est unique pour chaque
n-uplet/ligne de la table.
Exemple :
Commande (nucommande, datcommande, adr_livr)

84

42
 Les associations/liens entre objets sont réalisées
par les clés étrangères (foreign key).
La clé étrangère est un ensemble d'attributs d'une
table T2 qui est clé primaire dans une table T1.
Exemple :
Lien vers client
Client (nocli, nomcli, adrcli)
Commande(nucommande, datcommande, adrliv, nocli)

La clé étrangère doit correspondre à une clé

primaire existante (contrainte d’intégrité
référentielle normalement vérifiée par SGBD).
Les tables relationnelles vérifient encore d'autres
contraintes d'intégrité (voir cours SGBD).

85

Passage du Modèle E/A au MLR

Entité
Toute Entité devient une table dont la clé primaire
est l'identifiant de l'Entité.

Client
Codcli
Nomcli se traduit par :
Adrcli

Client (codcli, nomcli, adrcli)

86

43
 Passage du Modèle E/A au MLR
Toute association binaire (1/1) - (0/N) ou (1/N)
se traduit en ajoutant une clé étrangère (identifiant
de l'entité de cardinalité (0,N) ou (1,N) ) à la table
provenant de l'entité dont la cardinalité est (1,1).
toujours un seul client
Client Commande
codcli 0,N passe 1,1 nucom
nomcli datcom
adrcli adrlivr
se traduit par :
toujours un seul
Client (codcli, nomcli, adrcli) client (attribut
Commande (nucom, datcom, adrliv, codcli) monovalué)

87

Passage du Modèle E/A au MLR

Toute association binaire (1/1) - (0/1)
se traduit en ajoutant une clé étrangère
(identifiant de l'entité de cardinalité (0,1) ) à la
table provenant de l'entité dont la cardinalité est
(1,1).
toujours un seul employé
Employé Département
nuemp 0,1 1,1 nudep
dirige
nomemp nomdep
se traduit par :
toujours un seul
Employé (nuemp, nomemp) employé
Département (nudep, nomdep, nuemp)

88

44
 Passage du Modèle E/A au MLR
Association binaire (0/1) - (0/N) ou (1/N)
Solution 1: idem à association (1/1) – (0/N) ou (1/N).
Problème de clé étrangère pas toujours définie
(certains SGBD supportent, d’autres non).
Solution 2: on crée une table ayant pour clé primaire
l'identifiant de l'entité (0/1) et pour clé étrangère
l'identifiant de l'autre entité. On ajoute les éventuelles
propriétés de l'association à la table. Plus lourd.

Employé 0,1 Classer 0,n Projet

nuemp dateaffect refproj
nomemp budget
se traduit par :
Employé (nuemp,refproj,nomenp, dateaffect) (solution 1)
Classer(nuemp, refproj, dateaffect) (solution 2)

89

Passage du Modèle E/A au MLR

Association binaire (0/N) ou (1/N) - (0/N) ou (1/N)
se traduit par une nouvelle table dont la clé primaire
est composée des identifiants des deux entités. Les
éventuelles propriétés de l'association deviennent
les attributs de cette table.
0,n Classer 0,n
Skieur CompétitionR
rang efcomp
Nomski
spécialité datcomp
se traduit par :
Classer (nomski, refcomp, rang)

90

45
 Passage du Modèle E/A au MLR
Association n-aire (n>2)
On crée une table ayant pour clé primaire les
identifiants des différentes entités de
l'association. Les propriétés de l'association
deviennent les attributs de la table.
Classe
No_classe
0,n
0,n Assure 0,n Professeur
Matière
codsalle
No_matiere No_prof

se traduit par :
Assure (no_classe, no_matiere, no_prof, codsalle)

91

Ce passage du modèle E/A au modèle

relationnel répondant à des règles précises
peut être automatisé (génération du modèle
logique relationnel à partir du MCD).

92

46