Sommaire

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 Client












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:
Une DF P1 ┘ P2 est dite élémentaire s’il n’existe pas P3  P1
tel que : P3 ┘ P2
Exemple : Considérons les DF suivantes:
# Commande, # Article ┘ Quantité commandée
# Commande, # Article ┘ Nom Article
# Article ┘ Nom Article
La deuxième DF n’est pas élémentaire car # Article  # Commande, # 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.