INTRODUCTION:_____________________________________ 2

I. LES DIFFERENTES ETAPES D’UNE ANALYSE. 2

1) Etude de l’existant: 2
2) La rédaction du cahier des charges 2
3) L’évaluation de la demande 2
4) La conception des maquettes d’écrans et d’états 2
5) l’élaboration du dictionnaire des données 2
6) La constitution des entités et des relations 2
a) Propriété 2
b) Individu 2
c) Relation 2
7) Dépendances Fonctionnelles 2
a) Dépendance Fonctionnelles intra-individu et intra-relation 2
b) Dépendances Fonctionnelles inter-individus (DF) et Contraintes d’Intégrité
Fonctionnelle (CIF) inter-individus 2
8) Règles de normalisation 2
a) Première forme normale (1ere FN) 2
b) Deuxième Forme Normale (2ème FN) 2
c) Troisième forme normale (3ème FN) 2
d) Forme normale de Boyce-Codd (BCNF) 2
9) CIF inter-relation 2
a) CIF « inclusive » 2

Introduction

La méthode MERISE est devenue le « standard » des méthodes de conception.

Ce suc-cès est dû en grande partie au fait que la méthode couvre les différents
aspects du cycle d’analyse, de conception et de développement du système
d’information. Elle offre un lan-gage commun aux différents acteurs impliqués
dans un projet.

Présentation de MERISE.
Merise est une méthode de conception et de développement de systèmes
d’information, elle vise à recenser la totalité des informations dont l’entreprise
a besoin pour assurer tout ou partie des ses activités fondamentale, que ces
informations soient utilisées ma-nuellement ou qu’elles le soient de manière
automatique.

La conception d’un système d’information fiable et traduisant le plus

fidèlement pos-sible l’organisation de l’entreprise est l’objectif principal de
merise.
Informations
SYSTEME OPERANT D’UNE ESE
SYSTEME DE PILOTAGE
- régulation et contrôle
constituent - pour connaître l’état du
le système système opérant
d’information

Nécessité d’une analyse.

Pourquoi une analyse?
Programmer sans analyser au préalable son problème méthodiquement, c’est
comme bâtir une maison sans plan.

Donc tout débutant qui a l’ambition de devenir un vrai professionnel du

développe-ment d’applications doit passer par l’apprentissage d’une méthode
d’analyse.

I. Les différentes étapes d’une analyse.

Le but d’une analyse est double:
• Etablir la description de la base de données
• Etablir la descriptif des traitements à programmer c’est tout ce que l’on
demande à l’analyse.

Mais ce n’est pas peu. Comment en partant d’une demande d’informatisation

formulée de façon plus ou moins précise, arriver à une base de données et des
programmes?

Il va donc falloir être très méthodique et bien décomposer le travail en étapes

succes-sives pour ne pas se perdre dans les détails.

Notre méthode d’analyse regroupe trois grandes phases:

Phase A: Analyse générale

Phase B: Analyse des données

Phase C: Analyse des traitements

1) Etude de l’existant:
Ici commence vraiment le travail de l’analyste.
Lorsque celui ci reçoit une demande d’informatisation ou de ré-informatisation
, écrite ou orale, la première étape consiste à interviewer le responsable du
domaine, puis les utilisa-teurs directs. Le but sera de savoir où l’on met les
pieds, de comprendre le fonctionnement actuel du système actuel
d’information.

Voici quelques démarches à effectuer obligatoirement:

délimiter très précisément le domaine d’étude par rapport aux autres⊗
domaines, et lister au passage les autres domaines qui auront des interfaces
avec le domaine à étudier.
⊗ Récupérer des exemplaires de documents utilisés actuellement, porteurs de
données si pos-sible et non des imprimés vierges,
⊗ Si le système est déjà informatisé, récupérer les descriptions des fichiers
informatiques actuels,
⊗ d’autres techniques d’investigation sont facultatives. Elles deviendront
nécessaires si le sujet est complexe:
⊗ Etablir la liste des opérations qui se font actuellement en prenant note de :
Quand est faite l’opération ? c’est à direΦ à quel événement ?
Combien de fois par jour ou par mois ?Φ
Qui le fait (un Ordinateur , une personne ,avec quelle compétence?Φ
Où cela se fait (dans quel bureau , sur quel ordinateur)?Φ

Etablir le schéma de circulation des documents si les documents circulent

beaucoup.⊗

On aboutira au dossier de « Descriptif de l’existant ».

2) La rédaction du cahier des charges

Travailler en équipe, c’est mieux !

Le cahier des charges de l’application peut vous être fourni par le demandeur
.Soyons réaliste. C’est assez rare et ce n’est pas d’ailleurs forcément l’idéal.
L’idéal c’est d’élaborer ce cahier des charges en équipe constituée des
personnes suivantes:
Le demandeur (en général le responsable du domaine à informatiser ),⊗ il
apporte une vue d’ensemble du problème qui est en phase avec le reste de
l’entreprise,
⊗ L’utilisateur de base, indispensable, car c’est le seul qui puisse apporter son
vécu du ter-rain,
L’analyste qui est là pour écouter, mais aussi pour expliquer ce qui⊗ est
possible et ce qui est impossible à réaliser avec un ordinateur.

Trois avantages à travailler ainsi en équipe :

Φ Selon le vieil adage « il y en a plus dans plusieurs têtes que dans une »;
Φ l’absence d’une seule de ces trois compétences produirait un cahier des
charges déséquili-bré, non réalisé.
Le cahier des charges devient le bébé de ses trois concepteurs, etΦ par la suite
aucun des trois n’aura envie d’assassiner son bébé!

Que doit contenir le cahier des charges?

D’une façon générale, le cahier des charges sera le contrat qui lie le demandeur
du projet avec l’informaticien .

L’informatisation doit donc veiller à ce qu’il ne contienne rien d’irréalisable!

Le cahier des charges doit toujours être sous forme écrite, même pour un petit
projet, même si l’analyste doit le réaliser seul, sans la contribution de
l’utilisateur. Il devra être visé, sinon signé par le demandeur afin de prendre sa
vraie valeur de contrat.

Pour élaborer le cahier des charges, les questions que l’équipe de conception
doit se poser sont les suivantes :
Quel est le but réelΦ de nouvelle demande?
Quelles sont les nouvelles règles de gestion si elles ont changé?Φ
Quels changements sont peut-être déjà décidés dans l’organisation ?Φ
Quel est le nouveau schéma de circulation des documents souhaité ?Φ
Quelles vont être les nouvelles opérations de gestion ?Φ
Quand seront faites ces opérations ?
Combien de fois par jour ou par mois ?
Qui les fera (Ordinateur, une personne, avec quelle compétence)?
Où cela se fera (dans quel bureau, sur quel Ordinateur) ?
Finalement le cahier des charges doit contenir la liste exhaustive de toutes les
fonctionnalités à réaliser.

3) L’évaluation de la demande

Une fois le cahier des charges réalisé, il faut en évaluer le coût de réalisation.
Il faut répondre à ces questions :
Quels nouveaux besoins en matériel informatique ? que choisir et àΦ quel coût
? (sans ou-blier les coûts de maintenance du matériel, les coûts des
consommables, ni les coûts des té-lécommunications),
Quels besoinsΦ en progiciel ou logiciel ? dans le cas d’un progiciel, que
choisir et à quel coût ? dans le cas d’un logiciel à développer, qui développe ?
quel langage ? quelle durée de développement ? quel coût ?
Quels besoins nouveaux en personnel utilisateur ? quelles compétencesΦ ?
faudra-t-il pré-voir de la formation ? quelle durée ? quel coût ?
Φ En contrepartie de ces coûts, quels sont les gains prévisibles de l’opération :
Φ Quels avantages en qualité du service ?
Φ Quel gain de personnel ?
Φ Quels autres gains ?

Il faut aussi évaluer le délai de réalisation et de mise en place en place

définitive.
Enfin, il faut oser se poser la question : est-ce faisable ? et surtout oser répondre
par la négative, le cas échéant.

4) La conception des maquettes d’écrans et d’états

Sur la base du cahier des charges, notre équipe regroupant le demandeur,

l’utilisateur final de base et l’analyste continue son travail en élaborant des
maquettes d’écrans et d’états.
Parfois, c’est l’analyste seul qui effectue ce travail. Dans ce cas, il devra
toujours faire valider ses résultats par les deux autres membres de l’équipe de
départ.

Sinon, la validation se fera inévitablement le jour de la remise finale de

l’application et les dégâts seront plus lourds .....

Pour les maquettes d’écrans, il faudra dessiner :

les maquettes de menus,
les maquettes d’écrans de saisie de données,
les maquettes d’écrans de consultation de données.

Chaque maquette sera identifiée par un nom, par exemple : état ET01 et ET02,
écrans EC01, EC02 et EC03.

Les écrans intermédiaires et les écrans d’états les plus importantes d’une
application de gestion des commandes des clients.

Ecran de saisie d’un nouveau Clien

Ecran de saisie d’un nouvel article
Ecran de saisie d’une commande d’un client
Catalogues des Articles
Facture
5) l’élaboration du dictionnaire des données

En utilisant les maquettes d’écrans et d’états, il faut recenser maintenant toutes

les données qui s’y trouvent afin de constituer ce qu’on appelle le Dictionnaire
des Données .On ne prendra pas en compte les constantes que sont les titres
d’états ou les en-têtes de colonnes ou les étiquettes d’écrans. En revanche les
totaux et les sous totaux de fin d’états seront à prendre en compte.
Nom de la donnée
Adresse1 du Client
Adresse2 du Client
Code Article
Code Client
Code Postal du Client
Commune du Client
Date de la Commande
Libellé de la commande Total HT de la Commande pour Article
Libellé de l’article Quantité Commandée
Montant total de la TVA Prix Unitaire
Montant HT de la Commande Numéro de la Commande
Montant total TTC Nom du client

6) La constitution des entités et des relations

Dégager les entités

D’après la définition théorique, une entité est la représentation d’un Objet

matériel ou Immatériel de l’univers.

En pratique, dans une entreprise, une entité est un des multiples Objets porteurs
d’information que l’on manipule quotidiennement. On trouvera par exemple
l’entité « Four-nisseur » , l’entité « employé », l’entité « bulletin de paie » ou
encore l’entité « compte analy-tique ».

Une entité peut être permanente ou temporaire. Un compte de comptabilité est

une entité permanente alors qu’une commande d’un client est une entité
temporaire.

On appelle Occurrence d’une entité, un exemplaire. Par exemple le client

nommé DUPONT est une occurrence de l’entité «client ». L’entité «client »
aura donc autant d’occurrence que l’entreprise aura de clients.

Comment établir la liste des entités d’une application informatique? Il faut

analyser le dictionnaire des données. Dans un premier temps, il faudra
s’attacher à ne conserver que les données dites élémentaires, c’est à dire
éliminer les données calculées telle que les totaux de notre exemple. C’est alors
qu’apparaissent intuitivement les entités.

a) Propriété
Une propriété représente le plus petit lot de données qu’il est possible d’utiliser
d’une ma-nière autonome et qui a un sens indépendamment des autres lots.

La propriété servira donc à caractériser les entités que l’on sera amené à définir
dans le cadre de la modélisation pour représenter les objets et les associations
entre ces objet. Comme propriété nous aurons ainsi par exemple : Nom client
qui caractérisera le client, Adresse four-nisseur qui décrira en partie le
fournisseur.
Il est possible d’attribuer une valeur à toute propriété, on parlera alors
d’occurrence de la propriété. Dans l’exemple précédent le Nom du client sera «
Dupont » et l’adresse du four-nisseur « PARIS ».
b) Individu
La définition de l’individu fait intervenir l’intérêt que celui-ci présente pou
l’organisation.
Un individu est ne entité concrète ou abstraite, ayant une existence propre et
présentant un intérêt pour le système ou l’application envisagée.

L’individu constitue l’image d’un objet du monde réel dans le système

d’information. Il est décrit par un ensemble de propriétés qui le caractérisent.
Un ensemble de valeurs prises par ces propriétés définit une occurrence de
l’individu. L’une de ces propriétés joue un rôle particulier dans la mesure où
elle permet de repérer d’une manière univoque chacune des oc-currences de
l’individu. Il s’agit de l’identifiant. Chaque individu possède donc une propriété
identifiant qui lui est propre.

L’identifiant doit être tel qu’à deux occurrences distinctes de l’individu

correspondent nécessairement deux valeurs différentes de la propriété. Cette
valeur de l’identifiant ne peut être indéterminée (ou « nulle »), elle doit
obligatoirement être stable dans le temps. Cette rè-gle est connue sous le nom
d’intégrité d’entité.

Tout individu doit obligatoirement posséder une propriété identifiant, même si

cette dernière n’apparaît pas systématiquement dans toutes les vues externe.
Dans le cas où celle-ci n’existe pas « naturellement » le concepteur sera amené
à en définir une qui sera la plus logi-que possible.
Il existe une Dépendance Fonctionnelle (DF) implicite entre l’identifiant et les
autres propriétés de l’individu, ce qui signifie qu’à tout instant une valeur de
l’identifiant détermine une et une seule valeur de chacune des propriétés de
l’individu. Cette notion est développée d’une façon plus formelle dans la suite
de ce chapitre.

Le modèle individuel propose des représentations graphiques pour la plupart

des no-tions qu’il utilise. Un individu est donc représenté dans un rectangle
dans lequel apparaissent d’une part le nom de l’individu et d’autre part les
propriétés caractérisant l’individu.
Par exemple l’individu CLIENT caractérisé par les propriétés « Numéro client
», « Nom client » et « Adresse client » apparaîtra sous la forme:
Afin de faciliter la lecture des individus, nous faisons précéder l’identifiant du
sym-bole #. Cette convention est largement utilisée dans le modèle relationnel.

Un individu possède des réalisations que nous appellerons des occurrence de

l’individu. Ces occurrences sont telles que l’on attribue une valeur à chacune
des propriétés caractérisant l’individu. Pour l’individu CLIENT l’une de ses
occurrence sera par exemple:

C52 Dupont PARIS

c) Relation
Les relations quant à elle permettent de traduire les associations qui existent
entre dif-férents individus. Elles ne possèdent pas d’identifiants propres, mais
sont identifiées par la concaténation des identifiants des individus participant à
leur réalisation.
Exemple: soit la relation « titulaire » entre CLIENT et ABONNEMENT.
La cardinalité 1.n de CLIENT signifie qu’un CLIENT (MARTIN,
DUPONT,...) peut être TITULAIRE de 1 à n ABONNEMENTs. La cardinalité
1.1 de ABONNEMENT est né-cessairement attaché à un seul CLIENT.

Il est important de démarrer le processus de mise en évidence des relations en

prenant en compte la dimension maximale possible pour chaque relation, c’est-
à-dire celle qui met en jeu le plus grand nombre d’individus et qui confère donc
la dimension maximale à la collec-tion de la relation.

Dans l’exemple, on peut dégager les entités suivantes:

¬ l’entité « client »;
¬ l’entité « article »;
¬ l’entité « commande »;
¬ l’entité « ligne de commande ».
Les propriétés
Les informations relatives à une entité sont appelées des propriétés, ou encore
des at-tributs. Par exemple, les propriétés des l’entité « client » sont: le code du
client, son nom et son adresse qui décompose en quatre propriété.

Une propriété peut être un code, un libellé, une valeur « vrai ou faut », et
pourquoi pas une image (la photo d’un article produit), voire un son ou même
une séquence vidéo.

Les propriétés qui se présentent sous la forme d’un code peuvent être codées de
plu-sieurs manières:
¬ un simple numéro d’ordre croissant, de 1 à N;
¬ un code mnémonique, qui est un abrégé de sa signification, par exemple «
FRN » pour le mot « Fournisseur »;
un code articulé, qui est constitué de plusieurs parties accolées les¬ unes aux
autres, par exemple le matricule INSS de chaque personne ou bien le numé-ro
d’immatriculation des véhicules français.
Il est très important de choisir la bonne méthode de codification au moment de
l’analyse, car il sera extrêmement difficile de changer les habitudes par la suite.
L’identification
L’identification est une entité, encore appelé critère d’identification, est une
propriété ou un ensemble de propriétés de l’entité que l’analyste aura choisi de
façon à ce que deux occurrences de cette entité ne puissent pas avoir le même
identifiant.

Par exemple, le numéro de client sera l’identifiant de l’entité « client ».

Dans certains cas, l’identifiant devra être constitué de plusieurs parties. Prenons
un exemple: une commande d’un client est constituée de plusieurs lignes de
commandes. Pour pouvoir identifier de manière unique toute ligne de
commande, il faudra prévoir un identifiant constitué du numéro de la command
associé au numéro de l’article commandé.

Lorsque toutes les entités auront été dégagées, avec leurs propriétés et leur
identifiant, on devra les représenter comme ci-dessous. Notez que le nom de
l’entité apparaît en haut du cadre et que l’identifiant est souligné.
Les relations
Nous allons maintenant établir des relations entre les entités.

Lorsque deux entités ont une propriété commune, on peut établir une relation
entre elles. Ce qui donne graphiquement le schéma suivant trois relations:
A ce moment de l’analyse, il faut distinguer plusieurs types de relations:
⇒ Les relations de type 1-(0-1);
⇒ Les relations de type 1-(0-N);
⇒ Les relations de type (0-N)- (0-M);
⇒ Les relations de type 1-1.

Qu’est-ce que tout cela signifie?

Ù Relation de type 1-(0-1)

Une relation de type 1-(0-1) entre deux entités A et B est une relation dans
laquelle 1 occurrence de l’entité A ne peut correspondre qu’à 0 ou 1 occurrence
de l’entité B.

Un exemple: dans une banque, prenons les deux entités « client » et « plan
d’épargne logement ». Chaque client peut éventuellement avoir contracté un
plan d’épargne logement. Mais selon la loi, une personne ne peut bénéficier au
maximum que d’un seul plan d’épargne logement, on peut donc dire qu’à toute
occurrence de l’entité « client » ne peut correspondre que 0 ou 1 occurrence de
l’entité plan « plan d’épargne logement ».
C’est la relation « père-fils unique », sachant qu’ici le fils unique est...
optionnel.
Ù Relation de type 1-(0-N)

Cette relation est de loin la plus fréquente.

Une relation de type 1-(0-N) entre deux entités A et B est une relation dans
laquelle 1 occurrence de l’entité A ne peut correspondre qu’à 0 ou N
occurrence de l’entité B.

A titre d’exemple, nous prendrons les entités « client » et « commande ». on

peut dire qu’à chaque client correspond de 0 à N.

C’est la relation générale « père-fils ». il ne peut pas y avoir de fils sans père,
mais il peut y avoir un père sans fils. Et généralement, un père aura plusieurs
fils.
Notons au passage qu’une relation de type 1-(0-1) est réalité un cas particulier
de relation de type 1-(0-N).

Ù Relation de type (0-N)-(0-M)

Une relation de type (0-N)-(0-M) entre deux entités A et B est une relation dans
la-quelle:
◊ à 1 occurrence de l’entité A correspondent de 0 à M occurrences de l’entité B;
◊ à 1 occurrence de l’entité B correspondent de 0 à N occurrences de l’entité A;

Par exemple, considérons les deux entités « classe » et « professeur » d’un

lycée. On peut dire que chaque classe a plusieurs professeurs, mais aussi que
chaque professeur a plu-sieurs classes. On se trouve bien devant d’une relation
de type (0-N)-(0-M).

En principe, à ce stade de l’analyse, vous ne devriez plus trouver ce type de

relation car vous devriez déjà l’avoir transformée - intuitivement peut-être - en
une entité supplémen-taire.
Mais, si vous trouvez un jour une relation de type (0-N)-(0-M) sur votre
chemin. Sa-chez qu’il n’est pas possible de l’intégrer telle quelle dans une base
de données relationnelle. Il faut obligatoirement la transformer en une entité
supplémentaire reliée aux deux entités par des relations de type 1-(0-N).

Nous allons donc ajouter l’entité « enseigne » dans notre lycée et mentionner
les oc-currence sur le schéma:
Notation graphique des occurrences des relations
Nous pouvons maintenant ajouter les nombres occurrences sur le schéma de
l’application de gestion des commandes pour le terminer:
7) Dépendances Fonctionnelles
a) Dépendance Fonctionnelles intra-individu et intra-relation
La notion de Dépendance Fonctionnelle (DF) est le concept fondamental
permettant de passer d’un ensemble de propriétés à des individus à des relations
entre ces individus.
Il existe une DF entre deux propriétés P1 et P2 d’un individu ou d’une relation
donnés si à toute valeur de P1 on peut associer à tout instant qu’une et une seul
valeur de P2.

P1 est alors la source de la DF et P2 le but P1 ┘ P2

Exemple: Considérons les deux propriétés # INSEE et Nom Personne. Il existe
une DF
# INSEE ┘ Nom Personne
car connaissant un # INSEE on connaît le Nom Personne, l’inverse n’étant pas
forcément vrai. En effet, si le nom est MARTIN on obtiendra généralement un
ensemble de # INSEE pour les personnes ayant ce patronyme.

Dans le modèle individuel les propriétés sources de DF constitueront les

identifiants des individus et relations. Il arrive toutefois dans les modèles de
données qu’une propriété ne puisse être fonctionnellement rattachée à aucun
individu ni à aucune relation car il est alors impossible d’établir une DF pour
cette propriété. Dans un tel cas, nous parlerons de paramè-tre de donnée.
Cette propriété spécifique est généralement nécessaire pour effectuer un calcul
permet-tant d’obtenir la valeur d’une autre propriété qui elle est calculée.
Comme propriétés paramè-tre nous pouvons ainsi rencontrer Taux TVA,
plafond de cotisation à la Sécurité Sociale, Dé-lai de péremption, Date du jour,
etc.

Exemple: Dans une entreprise tous les produits on le même Taux de TVA. Le
montant de la facture est obtenu par la règle de calcul suivante:
TTC = MHT 4.(1 + TTVA/100)

Le TTVA ne peut donc être rattaché à aucun des produits vendus par
l’entreprise car il n’en dépend pas d’une manière fonctionnelle, c’est donc un
paramètre de calcul. Le modèle de données sera
Pour ce qui concerne la représentation graphique, les paramètres seront
représentés dans des rectangles sans aucun lien avec les autres entités du
modèle.

Un paramètre peut donc être défini comme une propriété qui n’appartient à
aucun individu ni à aucune relation. A un instant donné, un paramètre ne
possède qu’une seule valeur pouvant évoluer dans le temps. Un paramètre est
donc une propriété non stable. Dans le cas d’une donnée stable, le paramètre
n’a pas à figurer dans la structure de données car il s’agit alors d’une constante
(Exemple: l’accélération de la pesanteur).

Deux notions sont très importantes pour pouvoir définir dans de bonnes
conditions les FN, il s’agit des notions de DF élémentaire et de DF directe.
¬ DF élémentaire:
P1⊂Une DF P1 ┘ P2 est dite élémentaire s’il n’existe pas P3
tel que : P3 ┘ P2
Exemple : Considérons les DF suivantes:
# Commande, # Article ┘ Quantité commandée
# Commande, # Article ┘ Nom Article
# Article ┘ Nom Article
# Commande, #⊂La deuxième DF n’est pas élémentaire car # Article Article
et que ces deux propriétés ont le même but qui est Nom Article.
Une DF dont la source est réduite à une propriété est toujours élémentaire.
Cette notion ne sera par conséquent utilisée que pour les propriétés composées
c’est-à-dire pour les rela-tions.
¬ DF directe:
Une DF P1 ┘ P2 est dite directe s’il n’existe pas P3 tel que:
P1 ┘ P3
P3 ┘ P2
Exemple : Considérons les DF suivantes:
# Commande ┘ # Client
# Commande ┘ # Nom Client
# Client ┘ # Nom Client
La deuxième DF n’est pas directe car il existe # Client tel que:
# Commande ┘ # Client ┘ Nom Client
Les formes normales seront abordées dans le détail ci-après, auparavant
examinons les DF inter-individus et DF entre individu et relation.

b) Dépendances Fonctionnelles inter-individus (DF) et Contraintes d’Intégrité

Fonctionnelle (CIF) inter-individus
Une DF inter-individus est un cas particulier de relation binaire. Elle traduit le
fait que connaissant une occurrence de l’un des deux individus composant la
collection de la relation, on connaît directement une et une seule occurrence de
l’autre individu.

Le premier individu est appelé source de la DF, le second cible ou but. Les
cardinalités sont 1.1 ou 0.1 pour les individus-source et sont quelconques (1.1
ou 0.1 ou 0.n ou 1.n) pour les individus-cible. Ceci traduit le fait qu’à une
occurrence de l’individu source est associée une et une seule occurrence de
l’individu cible.

La DF est dite forte lorsque la cardinalité minimale de l’individu source est de

1. Le lien existe alors à tout moment pour l’ensemble des individus.

Elle est faible lorsque cette cardinalité est de 0. Le lien n’existe alors pas pour
l’ensemble des individus à tout moment.

Exemple:
Partant du fait que tout CLIENT a au plus un REPRESENTANT, connaissant
le CLIENT on connaît son REPRESENTANT éventuel.

Lorsque deux objets sont reliés par une DF, il est nécessaire de simplifier une
éven-tuelle relation n-aire (n >= 2) à laquelle ils participaient.

Cette simplification est mise en évidence par le schéma ci-après.

Dans ce cas, la DF introduite est faible.
Si la cardinalité minimale de client avait été de 1, alors nous aurions introduit
une DF forte et la représentation aurait été la suivante:
Il est important de noter à ce niveau que lorsqu’une cardinalité maximale est
égale à 1, la relation sur laquelle elle porte, ne peut avoir de propriété.

Une CIF est un cas particulier de la DF inter-individus. En effet pour qu’il y ait
CIF il faut que la dépendance soit stable, c’est-à-dire qu’une fois le lien établi
entre deux occurren-ces il ne peut pas être modifié dans le temps.
Considérons l’exemple suivant:
Une règle de gestion indique qu’une POLICE ne peut être souscrite que par un
AS-SURE et un seul, et de plus une fois établie pour cet assuré elle ne peut être
affectée à quel-qu’un d’autre. C’est-à-dire qu’à tout moment lorsque l’on
connaît la POLICE, on connaît l’ASSURE.

IL y aura donc CIF entre POLICE et ASSURE .

De plus, la POLICE quant à elle est gérée par un AGENT et un seul, mais il est
possi-ble, pour une raison de gestion quelconque, cette POLICE change
d’AGENT. Dans ce cas il existe une DF forte, et non pas une CIF, entre
POLICE et AGENT.
La différence entre les deux contraintes est donc bien une notion de stabilité
dans le temps, concernant le lien en cause qui existe dans un cas et pas dans
l’autre.

D’autre part, en ce qui concerne la date de souscription, elle ne dépend pas en

réalité de la relation Souscrire mais en fait de la POLICE elle-même. Le modèle
simplifié est le sui-vant:
Cet exemple illustre de plus la façon dont une propriété (Date de souscription)
peut migrer d’une relation vers un individu.

De même que pour les DF, les CIF peuvent être fortes (cardinalité source 1.1)
ou fai-ble (cardinalité source 0.1). la représentation graphique est similaire à
celle des DF. Si une CIF est forte le lien et alors dit total.

Dans les exemple présentés jusqu’à présent la cardinalité maximale de

l’individu but de la DF ou de le CIF était toujours égale à n. Dans certaines
modélisations, il en va tout au-trement et les cardinalités maximales des deux
individu concernés sont égalent à 1.

Exemple : une facture donne lieu à un règlement et un seul. Tout règlement

porte sur une seul facture. Toutefois, au moment de son émission, la facture ne
possède pas encore de règlement, mais tout règlement est tributaire de
l’existence de la facture corres-pondante. D’où le modèle suivant :
On est amené à se demander quel est l’individu source et quel est l’individu
but? La réponse fait intervenir le temps, ainsi une facture est émise sans
règlement correspondant, mais le règlement ne s’effectue que postérieurement
et porte sur une facture précise (et non pas l’inverse). La règle pour déterminer
le sens de la DF ou CIF est :

• Source : individu apparaissant postérieurement désignant ou référençant).

• But : individu existant antérieurement (désigné ou référencé).
Dans un cas comme ci-dessus, où il existe un couple de cardinalité 0.1 et 1.1
l’individu source de la DF est l’individu possédant la cardinalité 1.1. En effet,
toutes ses occurrences ont besoin de la présence des occurrences de l’individu
but pour pouvoir nécessairement être re-liées.
Le modèle devient :
Autre exemple : Soit la vue externe tirée d’un document règlement dans lequel
tout règlement ne voit qu’une seule facture et qu’un seul client. Une facture
quant à elle ne voit qu’un seul règlement et qu’un seul règlement et qu’un seul
client. Le client voit n factures ainsi que n règlements. Le modèle en première
approxi-mation est donc :
Il existe en effet une CIF entre les individus :
REGLEMENT ┘ CLIENT
FACTURE ┘ CLIENT
Un lien de ce type existe également entre REGLEMENT et FACTURE. Dans
l’exemple précédent nous avons vue quelle était son orientation, une CIF sera
donc introduite :
REGLEMENT ┘ FACTURE
Le modèle devient :
Nous pouvons formuler la règle suivante :
Une relation ne peut avoir de « pattes directes » vers un individu qu’avec une
cardialité maximale n.

Si des pattes portent une cardinalité maximale de 1, alors il est nécessaire de

modifier le modèle en introduisant des DF ou des CIF.
8) Règles de normalisation
Des règles de détermination formelle des individus et relations vont s’ajouter
aux pré-cédentes. Elles sont constituées des formes normales (FN) empruntées
au modèle relation-nelle, mais appliquer et exprimer dans le vocabulaire et le
formalisme du modèle individuel. Précisant que dans la méthode MERISE de
base il existait déjà une expression de ces FN, toutefois les définitions données
ici sont le fruit de réflexions menées récemment sur la mé-thode afin de la
rendre encore plus abordable à ses utilisateurs.

a) Première forme normale (1ere FN)

Deux contraintes doivent être remplies pour répondre à la 1ere FN. La première
ne concerne que les individus puiqu’elle portent sur l’existence obligatoire
d’une propriété identifiant. Elle ne concerne pas les relations dans la mesure où
leurs identifiants sont obtenus automatique-ment par concaténation. La seconde
porte sur les réalisations.

Tout individu doit obligatoirement posséder une propriété identifiant.

Toute propriété d’un individu ou d’une relation doit être atomique, c’est-à-dire
qu’elle ne doit pas regrouper plusieurs valeurs.
Exemple : Considérons les deux individus suivants avec un ensemble de leurs
occurrences et examinons s’ils sont en 1ere FN.
n’est pas en 1ere FN car la propriété « caractéristiques Article » regroupe
plusieurs valeurs.
La propriété « caractéristiques Article » indique le prix unitaire ainsi que le
poids de l’article.

ARTICLE # Article Non Article Caractéristiques

Article
A5
A7
A8 Cuillère
Couteau
Fourchette 25 ; 20
37 ; 100
35 ; 50

b) Deuxième Forme Normale (2ème FN)

La 2ème FN se base sur la notion de DF élémentaire, elle ne s’applique donc
que sur les propriétés composées et par conséquent uniquement sur les
relations.

Nous commencerons par donner une définition utilisant explicitement la notion

de DF puis une définition plus proche des concepts du modèle individuel.

Une relation est en 2ème FN si toutes les DF entre sa propriété identifiant et ses
autres pro-priétés sont élémentaires.

La deuxième définition est :

Il ne peut y avoir une dépendance partielle d’une propriété par rapport à une
sous-collection de la relation.
Si un tel cas se produit, cela traduit l’existence de deux relations séparées dont
l’une regroupe une sous-collection issue de la relation initiale, ou que la
propriété appartient en fait à l’un des individus de la collection plutôt qu’à la
relation dans son ensemble.

Si toutes les dépendances sont élémentaires alors la relation est en 2ème FN.
Considérons l’exemple suivant portant sur une Facturation :

Il semble évident dans cet exemple que le PU article dépend uniquement de

l’article indépendamment de la facture dans laquelle il intervient. La bonne
modélisation sera donc :
Autre exemple : soit le modèle ci-dessous :
Date de stationnement et N° Place s’appliquent effectivement au triplet
(PERSONNE, VOITURE, PARKING), c’est-à-dire que ces propriété
dépendent bien de ces trois individus.

En revanche, il n’en va pas de même pour la propriété N° Place autorisée. Cette

der-nière est rattachée à une voiture et un parking indépendamment de la
personne qui la conduit. Pour satisfaire la 2ème FN il est donc nécessaire de
créer une relation Stationnement qui indi-quera pour une voiture la place
autorisée en fonction du parking.
La bonne modélisation est donc la suivante :
Nota : Nous virons ci-dessous qu’il existe un lien entre les occurrences des
deux relations car en effet une personne ne peut se garer avec une certaines
voitures dans un parking que si la place de stationnement est autorisée, ce lien
prendra la forme d’une CIF in-ter-relation.
c) Troisième forme normale (3ème FN)
Nous donnerons également deux expressions de la définition.
Un individu ou une relation est en 3ème FN si toutes les DF entre ces propriétés
sont élé-mentaires et directes.
Il ne peut pas exister de situation telle qu’en connaissant une propriété autre
que l’identifiant, on connaisse une ou plusieurs autres propriétés du même
individu.

Lorsque cette condition est vérifiée on dit que l’individu ou la relation est en
3ème FN.
Important : Les FN sont commutatives c’est-à-dire que pour être en 2ème FN il
faut au pré-alable être en 1ere FN, pour être en 3ème FN il faut être en 2ème
FN, etc.
Considérons la description suivante de l’individu VEHICULE
Couleur dépend directement de # Immatriculation. Par contre il existe une
corrélation entre Type, Cylindrée, Nb de places et Consommation. Cette
corrélation traduit dans l’effet l’existence d’une autre entité, distincte de
VEHICULE qui est le TYPE de ce véhicule.

Toutes les R9 d’un même type ont théoriquement une cylindrée, un Nb de place
et une Consommation (norme UFACE) identiques
La modélisation correcte est la suivante :
d) Forme normale de Boyce-Codd (BCNF)

Bien qu’étant en 3ème FN le modèle de données peut encore présenter quelques

anoma-lies. Ainsi dans un modèle :

Un individu déterminé de manière unique par une relation, ne peut déterminer à

son tour d’une manière unique l’un des individus appartenant à la collection de
la relation.

Lorsque cette règle est vérifiée, le modèle est alors en BCNF.

Exemple : Dans une entreprise, un employé s’occupe d’un certain nombre de

projets. Pour un projet donné un employé ne travaille sur ce projet que dans un
seul labora-toire. D’autre part, dans un laboratoire ne travaillent que des
employés affectés au projet considéré. Le modèle correspondant est le suivant :

Nota : Nous remarquerons ici l’utilisation d’une DF entre une relation et un

individu.

Ce modèle n’est pas en BCNF car il traduit le fait qu’une occurrence de

LABORA-TOIRE déterminée de façon unique par une occurrence de la relation
« Travaille sur », déter-mine à son tour de façon unique, une occurrence de l’un
des individus composant cette rela-tion (PROJET).
La normalisation nous conduira au modèle ci-dessous :

La BCNF peut également être appliquée dans une relation. Si le laboratoire

n’avait pas été vu comme un individu, mais comme une propriété de la relation
« Travaille sur » nous aurions eu alors le modèle suivant en 3ème FN :
Dans ce modèle il existe le DF inter-relation suivantes :

# Employé, # Projet ┘ Laboratoire

Laboratoire ┘ # Projet

Le modèle contrevient donc à la BCNF, il doit être normalisé par la création

d’un in-dividu LABORATOIRE. Le nouveau modèle est donc identique au
modèle normalisé précé-dent.
9) CIF inter-relation
Ce type de contrainte consiste à exprimer le fait que les associations entre
occurrences d’individus dans une relation sont tributaires de la présence ou de
l’absence d’association en-tre ces mêmes occurrences, dans une autre relation
du modèle de données. Les deux relations doivent faire intervenir des individus
communs, tels que la collection de l’une soit incluse dans la collection de
l’autre (par exemple R1 formée des individus A, B, C et R2 formée de A, B).
a) CIF « inclusive »

Considérons deux relations R1 et R2 reliant respectivement les individus A, B,

C et A, B.

Il existe une CIF inclusive entre R1 et R2 si pour toute association entre deux
occurrence de A et B dans R1, il existe une association entre ces mêmes
occurrence dans R2.
Pour illustrer ce type de CIF, nous considérons un exemple dans lequel un
employé est Affecté à un certain nombre de projets dans différents laboratoires.
D’autre part, pour connaî-tre la charge de chaque laboratoire, il existe une
relation, est traité dans, donnant le nombre totale d’heures par projet.
Il paraît évident qu’un employé ne puisse être affecté à un projet dans un
laboratoire que dans la mesure où ce projet a été préalablement associé au
laboratoire dont il est question. En autre terme, avant de pouvoir créer une
occurrence dans la relation Affecté il sera impéra-tif de s ’assurer que la
relation Est traité dans, comporte déjà l’association entre les occurrence de
projet et laboratoire considérées.

Cette contrainte est exprimée dans le modèle par une CIF inclusive entre les
deux rela-tions.

vBulletin® v3.8.4, Copyright ©2000-2010, Jelsoft Enterprises Ltd