CHAPITRE 0: Normalisation

Pourquoi?
La normalisation d'un schéma relationnel a pour objectif d'éviter que la base de données ne
contienne des données redondantes. Il est évident qu'une même donnée stockée plusieurs fois
dans la base peut provoquer des anomalies lors des mises à jour.
Par exemple, si le nom d'un fournisseur est stocké à la fois dans la table
PRODUITS et dans la table FOURNISSEURS, le gestionnaire commercial
pourrait mettre à jour la table FOURNISSEURS et omettre de répercuter la
modification dans la table PRODUITS ; d'où une incohérence de la base de
données.

Mais avant de normaliser nous allons d’abord nous rassurer d’établir les dépendances
cohérentes entre les relations.
I. Les Dépendances Fonctionnelles
Il s’agit de Quoi?
Les dépendances sont des propriétés inhérentes du système de données. Elles expriment les différentes
façons dont les données sont associées les unes aux autres.
définition
Etant donnée une relation R(X, Y, Z) (où X, Y, Z sont des ensembles de constituants, Z pouvant être vide), on
dit qu’il existe une dépendance fonctionnelle entre X et Y notée, X Y, si et seulement si, quelles que soient
les X, Y, Z-valeurs (x, y, z) et (x, y’, z’) ||R(x, y, z)|| et ||R(x, y’, z’)|| ⇒ y = y’

Un schéma d’une relation noté R =<U,{XY}> définit l’ensemble des relations R construites sur
l’ensemble de constituants U qui vérifient toutes la dépendance fonctionnelle X ->Y

Exemple
 P (professeur), H (heure), N (salle), Y (classe), T (matière)
’’le professeur p qui enseigne la matière t fait cours à l’heure h en salle n à la classe y ’’
P -> T
H, Y -> N
P, H -> Y
H, N -> P

but
Le but des dépendances fonctionnelles est de définir les relations entre les attributs d'une table dans une base de
données relationnelle. Les dépendances fonctionnelles permettent de garantir l'intégrité des données en imposant des
contraintes sur les valeurs pouvant être stockées dans les attributs, en assurant que les données sont cohérentes et que
les opérations de mise à jour ou de suppression ne conduisent pas à des incohérences. Elles permettent également
d'optimiser les requêtes en aidant le système de gestion de base de données à trouver les données plus rapidement.
Les dépendances fonctionnelles sont des propriétés qui s'appliquent aux attributs d'une relation dans une base de
données.

Voici quelques propriétés des dépendances fonctionnelles:

1. Unicité: Chaque dépendance fonctionnelle est unique et identifiée par une clé primaire.

2. Transitivité: Si A dépend de B et B dépend de C, alors A dépend également de C.

A-->B et B-->C alors A-->C

3. Réflexivité: Tout attribut dépend de lui-même.

Si X €Y€U alors Y-->X

4. Augmentation: Si X dépend de Y et Z€W€U alors X,W-->Y,E

5. Réduction: Si A dépend de B et A dépend de C, alors il existe une dépendance fonctionnelle entre B et C.

A-->B et A-->C alors on a aussi B-->C

6. Croissance: Si un attribut est ajouté à une relation dépendante, alors la dépendance fonctionnelle est
conservée.

7. Division: Si A dépend de B et C, alors on peut diviser la dépendance en deux dépendances: A dépend de B et A

dépend de C.
A-->B ,C alors A-->B et A-->C

€ ( inclu ou égal)
Application:
L'axiome de pseudo transitivité nous dit que si XY et YWZ, alors XWZ.

Démontrer cet axiome à l'aide des autres axiomes d'Armstrong.

XY alors XWYW (accroissement)

XWYW et YWZ

alors XWZ (transitivité)

Une DF doit être

Elémentaire : C'est l'intégralité de la source (partie gauche) qui doit déterminer le but (partie droite) d'une DF. Exemple
: Si P1 → P3 alors P1, P2 → P3 n'est pas élémentaire.
Directe : La DF ne doit pas être obtenue par transi vité. Par exemple, si P1 → P2 et P2 → P3 alors P1 → P3 a été
obtenue par transitivité et n'est donc pas directe.

Graphe de Dépendances Fonctionnelles (GDF)

Onpeut
On peutégalement
égalementreprésenter
représenterune
unedépendance
dépendancefonctionnelle
fonctionnelleà àl'aide
l'aided'un
d'unGraphe
GraphededeDépendances
DépendancesFonctionnelles
Fonctionnelles
(GDF). (GDF).
Fermeture Transitive:
Soit un ensemble de dépendances fonctionnelles F. La fermeture transitive de F, noté F+, est obtenue en ajoutant à F toutes
les dépendances fonctionnelles transitives.
Exemple:

Couverture minimale
Une couverture minimale, notée F*, est un ensemble de dépendances fonctionnelles élémentaires et directes. Soit F un
ensemble de DFs, on dira que F* est une couverture minimale de F si et seulement si le fermeture transitive obtenue à partir
de F, est égale à la fermeture obtenue à partir F*, et qu'il n'existe aucun autre sous-ensemble F'*de F* tel que la fermeture
transitive obtenue à partir de F'* soit égale à la fermeture transitive obtenue à partir de F.
 Les formes normales
Introduction

De nos jours, la conception des bases de données rencontre plusieurs problèmes notamment les redondances
et les incohérences au niveau des données .pour palier à ces différents problèmes on fait appel aux formes
normales qui sont un ensemble de règles visant à éliminer les redondances Et améliorer l’intégrité de données.
On distingue 06 types de formes normales mais nous étudierons juste les 04 premiers
-1FN
-2FN
-3FN
-4FN ou encore de boyce_CODD

Les forme normales sont des règles utiliser pour concevoir des bases de données relationnelles efficaces
et robustes elles visent à éliminer les redondances et l’incohérence dans les données.
 1FN
CONDITION:
• chaque ligne d’une table doit avoir une clé unique et que chaque colonne doit contenir une valeur atomique
c’est-à-dire non répétitive

Exemple
considérons la table concurrents suivante :

Lorsqu’une table comporte une colonne qui est elle-même une relationnel faut transforme la colonne en autant
de colonne qu’il Ya d’éléments distinct dans las relation
En divisant la colonne AgeEtCat en colonnes Age et Cat, on mets ainsi la table concurrent en 1ere forme
normale.

Lorsqu’une table comporte une colonne qui est elle-même une relationnel faut transforme la colonne en
autant de colonne qu’il Ya d’éléments distinct dans las relation

2FN
La deuxième forme normale permet d'éliminer les dépendances entre des parties de clé et des
attributs n'appartenant pas à une clé.
 CONDITION:

• La relation devrait tout d’abord être en 1FN

• Tout attribut qui n'est pas dans une clé ne dépend pas d'une partie seulement d'une clé

Illustration:
On a les données suivantes sur des élèves avec le DFs:
MatriculeNom, Age
Matricule Club
club Salle

Une dépendance fonctionnelle DF établit d'abord une relation entre donnée , en plus d'être fonctionnelle.
Maintenant considérons la relation:
ELEVE (Matricule, Nom , Age, Club, Salle)
on peut dire que l'attribut Matricule est clé, car il détermine tous les autres attributs, y compris la Salle
(la DF Matricule Salle est transitive).
Cette relation est en 2FN, car aucun attribut non clé ne dépend d'une partie de la clé(la clé n'est
pas composée d'ailleurs)
 Attention !!!
La définition de la 2NF doit être vérifiée pour toutes les clés candidates et non seulement la clé primaire (dans
le cas où il y a plusieurs clés).

Remarque

Si toutes les clés d'une relation ne contiennent qu'un unique attribut, et que la relation est en 1NF, alors la
relation est en 2NF.
 3FN
CONDITION:

• Etre en 2FN
il n’y
•il n’y a pas
a pas d’attribut
d’attribut n’appartenant
n’appartenant paspas
`a laà cl´e
la cléqui
quid´epende
dépendede
delalacl´e
clé par
par transitivit´e
transitivité (pas de d´ependance
par(pas de d´ependance par transitivité)
transitivit´e)
 Théorème

Toute relation R a une (ou plusieurs) décomposition(s)

(R1,R2,...,Rp) en troisième forme normale telle(s) que la décomposition
préserve les DF la décomposition est sans perte d’information
 4FN(Boyce Codd)
Condition
• Etre en 3FN
• Toute source de DF est clé primaire minimale.
Rappels: UML et Merise
Il s’agit de quoi?

UML et merises sont deux méthodes modélisation et de conception des systèmes

d'information merise(méthode d'études et de réalisation informatique pour les systèmes
d'entreprise)

Historiques:

merise(méthode d'études et de réalisation informatique pour les systèmes d'entreprise) est né à la fin des
années 1970 en France avec pour objectif de définir une démarche de conception de système d'information
son principe de base repose sur la séparation des données et des [Link]( unified modeling
language ou langue de modélisation unifiée en français) est né à la fin des années 1990 en Amérique est l'un
des langages de modélisation graphique à la base de pictogrammes conçu comme une méthode normalisée
de visualisation.
Ses deux langages ont plusieurs point en commun en entreprises mais diffères aussi quant t’il s’agit de
spécialité.
Principales différences entre MERISE et UML

Merise est souvent utilisé dans le

cadre des projets de développement
des bases de données et des
systèmes d'information tandis que
UML est plus adapté au projet de
développement des logiciels et des
systèmes complexes

Conclusion
En conclusion Merise et uml sont techniquement complémentaires si l'on considère que le système d'information est
modélisable comme deux sous-systèmes inclus l'un dans l'autre
Chapitre 1: Les DFD
Qu'est-ce qu'un diagramme de flux de données ?

Un diagramme de flux de données représente la manière

dont les informations circulent dans un processus ou un
système. Ces éléments comprennent les entrées et les sorties
de données, les dépôts de données et les différents sous-
processus par lesquels transitent les données. Les DFD sont
élaborés à l’aide de symboles et de notations standardisés
pour décrire les différentes entités et leurs associations.

Les diagrammes de flux de données illustrent

visuellement des systèmes et des processus qu’il serait
difficile de décrire avec seulement des mots. Vous
pouvez utiliser ces diagrammes pour cartographier un
processus existant et l’améliorer ou pour planifier la mise
en œuvre d’un nouveau système. Visualiser chaque
élément vous permettra d’identifier facilement les
sources d’inefficacité et de produire le meilleur système
possible.
 Vocabulaire(Éléments d'un diagramme de flux de données)

Pour commencer, il vous faudra (également appelé Niveau 0), qui représente l'ensemble du système. Voyez cela
comme une vue aérienne que les ingénieurs, clients et cadres peuvent consulter pour comprendre le
fonctionnement d'un processus. Une fois le diagramme créé, vous pouvez ajouter des niveaux qui détaillent les
informations relatives à un processus. Vous pouvez continuer à ajouter des couches supplémentaires au
diagramme, mais essayez de vous cantonner au minimum.

Il existe des symboles de diagramme de flux de données

standard qui servent à représenter les différentes parties
du système. Vous utiliserez par exemple une forme pour
représenter une entité externe et un autre symbole pour
représenter un processus.
 Les processus

sont représentés par un cercle ou un carré traversé en sa partie supérieure Ou

par une ligne horizontale. Un processus est une activité métier impliquant
la manipulation et la transformation de données. Les données sont
modifiées pendant le processus

Les flux
représentent la façon dont les données transitent. Nommez la flèche
selon le type de données qui se déplace dans le système.
L'entité externe

est symbolisée par un carré. Une entité externe peut être une personne, un
système ou une application. C'est le point de départ ou de fin des données.

Les banques de données

sont des rectangles (avec parfois une ligne verticale dans le symbole) qui
montrent où les données produites ou requises, en lien avec le processus, sont
stockées.
Diagrammes de flux de données logiques et physiques

Avant de créer votre diagramme de flux de données, vous devez déterminer quel type de DFD, physique ou
logique, correspond le mieux à vos besoins. Si vous êtes novice en la matière, rassurez-vous, la distinction
est assez simple.

• DFD Logique
Les diagrammes de flux de données logiques se concentrent sur ce qui se passe dans un flux d’informations
particulière : quelles informations sont transmises, quelles entités reçoivent ces informations, quels processus généraux
entrent en jeu, etc. Les processus décrits dans un DFD logique sont des activités commerciales - un DFD logique ne se
penche pas sur les aspects techniques d'un processus ou d'un système, tels que la manière dont le processus est
construit et est mis en œuvre. Vous n'avez donc pas besoin d'inclure des détails tels que la configuration ou la manière
dont vous de stocker vos données. Les employés non techniques doivent être capables de comprendre ces diagrammes,
faisant des DFD logiques un excellent outil de communication avec les différentes parties prenantes du projet.

Un Exemple
Diagramme de flux de données logique
 • DFD Physique

Les diagrammes de flux de données physiques se concentrent sur la façon dont les choses se passent dans un flux
d’informations. Ces diagrammes précisent les logiciels, le matériel, les fichiers et les personnes impliqués dans un flux
d’informations. Dans sa forme détaillée, un diagramme de flux de données physique permet de faciliter le développement
du code nécessaire à la mise en œuvre d’un système de données.

Un Exemple
Les diagrammes de flux de données physiques et logiques peuvent tous deux décrire le même flux d’informations.
Utilisés de manière coordonnée, ils fournissent plus de détails que lorsqu’ils sont employés séparément. Lorsque vous
choisissez le type de diagramme le plus approprié, gardez à l’esprit que vous pourriez avoir besoin des deux.

Niveaux des diagrammes de flux de données

Les diagrammes de flux de données sont également classés par niveau. En
commençant par le plus basique, le niveau 0, les DFD deviennent de plus en plus
complexes à mesure que le niveau augmente. Lorsque vous construisez votre
propre diagramme de flux de données, vous devez décider du niveau auquel il se
situe.

DFD-0(diagramme de flux de donnée niveau 0)

Les diagrammes de flux de données sont
également classés par niveau. En commençant
par le plus basique, le niveau 0, les DFD
deviennent de plus en plus complexes à
mesure que le niveau augmente. Lorsque vous
construisez votre propre diagramme de flux de
données, vous devez décider du niveau auquel
il se situe. Les DFD de niveau 0, également appelés
diagrammes de contexte, sont les diagrammes
de flux de données les plus basiques. Ils
fournissent une vue d’ensemble facile à
comprendre, mais contiennent peu de détails.
Les diagrammes de flux de données de niveau 0
représentent un seul nœud de processus et ses
connexions à des entités externes. Par exemple,
dans

l'exemple ci-dessous, illustre le processus de réservation d'hôtel avec le

flux d'informations entre l'administrateur et les clients.
 DFD-1(diagramme de flux de donnée niveau 1)

Les DFD de niveau 1 offrent également une vue d’ensemble, mais ils sont plus détaillés qu’un diagramme de
contexte. Dans un DFD de niveau 1, le nœud de processus unique du diagramme de contexte est décomposé en
sous-processus. Au fur et à mesure que ces processus sont ajoutés, le diagramme devra comporter des flux de
données et des dépôts de données supplémentaires pour les relier entre eux. Dans l'exemple de réservation
d'hôtel, cela peut inclure l'ajout des processus de sélection et de demande de chambre au système de réservation,
ainsi que des magasins de données.

Reprenons le même Exemple:

Modèle de diagramme de flux de données niveau 1
 DFD-2(diagramme de flux de donnée niveau 2)

Les DFD de niveau 2 et plus décomposent simplement les processus en sous-processus plus détaillés. En théorie,
les DFD peuvent dépasser le niveau 3, mais ils le font rarement. Les diagrammes de flux de données de niveau 3
sont suffisamment détaillés pour qu’il ne soit généralement pas utile de les affiner davantage. .

Le diagramme de niveau 2 ci-dessous développe le processus de

réservation d'hôtel pour inclure des processus plus granulaires,
tels que les processus d'annulation et de confirmation et les flux
de données connectés qui en découlent..
 Symboles et notations des diagrammes de flux de données
Selon la méthodologie utilisée (Gane et Sarson ou Yourdon et Coad), les symboles de DFD diffèrent
légèrement. Cependant, les concepts de base restent les mêmes. Un diagramme de flux de données
comporte quatre éléments fondamentaux : les processus, les dépôts de données, les entités externes et les
flux de données. L’image ci-dessous présente les formes standard des deux méthodologies.
 Comment créer un diagramme de flux de données
Maintenant que vous avez quelques notions de base sur les diagrammes de flux de données et leur catégorisation, vous
pouvez élaborer votre propre DFD. Le processus peut être décomposé en 5 étapes :

1. Identifier les principales entrées et sorties de

votre système
Presque tous les processus ou systèmes
commencent par une entrée provenant d’une 2. Construire un diagramme de contexte
entité externe et se terminent par la sortie de Une fois que vous avez identifié les principales entrées et
données vers une autre entité ou base de sorties, vous pouvez facilement créer un diagramme de
données. L’identification de ces entrées et sorties contexte. Dessinez un nœud de processus unique et reliez-le à
donne une vue globale de votre système : elle des entités externes apparentées. Ce nœud représente le
indique les tâches les plus générales que le celui- processus le plus général auquel les informations sont
ci doit accomplir. Le reste de votre DFD sera soumises pour passer de l’entrée à la sortie.
construit à partir de ces éléments, il est donc L’exemple de diagramme de flux de données ci-dessous
indispensable de les connaître dès le début. montre comment les informations circulent entre diverses
entités via une communauté en ligne. Les données circulent
vers et depuis les entités externes, représentant à la fois les
entrées et les sorties. Le nœud central, « communauté en
ligne », représente le processus général.
3. Développer le diagramme de contexte en un DFD de
niveau 1
L’unique nœud de processus de votre diagramme de contexte
ne fournit pas beaucoup d’informations : vous devez le
décomposer en sous-processus. Dans votre diagramme de flux
de données de niveau 1, vous devez inclure différents nœuds
de processus, les principales bases de données et toutes les
entités externes. Observez le flux d’informations : d’où
viennent les informations et comment sont-elles traitées avant
chaque dépôt de données ?

4. Développer le diagramme en un DFD de niveau 2 ou plus

Pour détailler davantage votre diagramme de flux de données,
suivez la même méthode qu’à l’étape 3. Les processus de votre
DFD de niveau 1 peuvent être décomposés en sous-processus
plus spécifiques. Encore une fois, assurez-vous d’ajouter tous
les dépôts et flux de données nécessaires : à ce stade, vous
devriez avoir une description assez détaillée de votre système.
Pour aller au-delà du niveau 2, il vous suffit de répéter cette
étape. Arrêtez-vous lorsque vous avez atteint un niveau de
détail satisfaisant.
5. Confirmer la justesse de votre diagramme final
Une fois votre diagramme terminé, examinez-le. Portez une
attention particulière au flux d’informations : est-il logique ?
Tous les dépôts de données nécessaires sont-ils inclus ? En
consultant votre diagramme final, les autres parties doivent
pouvoir comprendre le fonctionnement de votre système.
Avant de le présenter, vérifiez auprès de vos collègues que
votre diagramme final est compréhensible.