Explorer les Livres électroniques
Catégories
Explorer les Livres audio
Catégories
Explorer les Magazines
Catégories
Explorer les Documents
Catégories
Habiba Chaoui
Filière Génie Informatique
1
Les formes normales
o Les formes normales sont différents stades de qualité qui permettent d’éviter
des anomalies dans les bases de données relationnelles
o Représentent l’état des tables relationnelles en fonction de leurs dépendances
fonctionnelles
o Il existe 5 formes normales principales et deux extensions
1. Première forme normale (1FN)
2. Deuxième forme normale (2FN)
3. Troisième forme normale (3FN)
4. Forme normale de Boyce-Codd
5. Quatrième forme normale (4FN)
6. Cinquième forme normale (5FN)
7. Forme Normale Domaine-Clé
o Plus le niveau de normalisation est élevé, plus la table sera exempte
d’anomalies
o Une table en forme normale de niveau x est automatiquement en forme
normale de niveau x-1
o À la suite d’une modélisation, la plupart des modèles seront déjà en forme
normale de Boyce-Codd (ou presque) 2
Première Forme Normale (1FN)
o Une table est en forme normale si tous ses attributs sont simples et non décomposables
o Si une table n’est pas en 1FN, alors elle en FNN (Forme Non Normalisée)
o Si les tables relationnelles résultant de la modélisation ne sont pas déjà en 1FN, il serait approprié de
retourner à l’étape de modélisation. Une modélisation de qualité minimale devrait toujours être en
1FN.
VOL VOL
NoVol* JOURNÉES-VOL NoVol*
Code AéroportDép#
CodeAéroportArr#
NoVol* Code AéroportDép#
HeureDécollage Jour* CodeAéroportArr#
HeureAtterrissage
Jours HeureDécollage
HeureAtterrissage
o Ici, "Jours" est non simple, alors on crée une nouvelle entité pour
représenter la multiplicité des jours de vol, ce qui donne des tables
résultantes en 1FN
3
Deuxième Forme Normale (2FN)
o Une table est en deuxième forme normale si elle est en 1FN et que l’une de ces trois conditions est
respectée
o Pour passer de la première forme normale à la deuxième, il faut diviser chaque table ne
satisfaisant pas les critères en deux tables distinctes
4
Exemple : Supposons la table suivante représentant des modèles
génériques de télévisions construites par différents fabricants. La marque et
le modèle permettent d’identifier de façon unique chaque sorte de
télévision. Le mode sonore ainsi que la résolution sont spécifiques au
modèle et non à la marque.
5
Troisième Forme Normale (3FN)
o Une table est en 3FN si elle est déjà en 2FN et qu’aucun attribut ne faisant pas partie de la clé ne dépend
d’un autre attribut ne faisant pas partie lui non plus de la clé
o En 3FN, les dépendances fonctionnelles entre deux attributs ordinaires (ne faisant par partie de la clé)
ne sont pas autorisées.
o Pour passer de 2FN à 3FN, il faut
o Diviser chaque table ne satisfaisant pas ce critère en deux tables. La nouvelle table aura comme
clé l’attribut dont provient la dépendance et comme attributs, ceux qui en dépendent.
o Éliminer les attributs dépendants de la table originale. La clé de la nouvelle table demeure dans
l’ancienne en tant que clé étrangère
Exemple du livre : Dans le cas des voitures usagées, toutes les voitures de la même année sont vendues
au même prix.
VOITURE (NoStock, Marque, Modèle, Année, Couleur, Prix, TélFabricant)
Il y a donc une DF entre "Année" et "Prix", ce qui signifie que cette table n’est pas en 3FN. Il faut donc
décomposer cette table en deux.
6
Forme Normale de Boyce-Codd (FNBC)
o Extension de la 3FN, plus rigide que celle-ci, faite par R.F. Boyce et E.F. Codd, qui ont constaté que la
3FN pouvait comporter certaines anomalies
o Un modèle relationnel en FNBC est considéré comme étant de qualité suffisante pour une l’implantation
o Une table est en FNBC si elle est déjà en 3FN et qu’aucun attribut faisant partie de la clé ne dépend d’un
attribut ne faisant pas partie de la clé primaire
o Les cas de tables modélisées et transformées en 3FN qui ne sont pas déjà en FNBC sont très rares
o Pour passer de la 3FN à la FNBC, il faut
o Diviser chaque table ne satisfaisant pas au critère ci-haut en deux tables. La nouvelle table aura
comme clé l’attribut ordinaire dont provient la dépendance et comme attributs la partie de la clé qui
en dépend.
o Remplacer la partie de la clé concernée par l’attribut ordinaire (qui est devenu la clé de l’autre
table)
8
Normalisation du cas de l’aéroport du dernier cours
Modèle relationnel résultant de la modélisation
AÉROPORT (CodeAéroport, Nom, Ville, Prov-État, Pays, Altitude, LongueurPiste)
VOL (NoVol, Code AéroportDép, CodeAéroportArr, HeureDécollage, HeureAtterrissage)
JOURNÉES-VOL (NoVol, Jour)
RÉSERVATION (NoRéservation, NoClient, NoEnvolée, Prix, Classe)
ENVOLÉE (NoEnvolée, NoVol, CodeAvion, Date)
PASSAGER (NoClient, Nom, NoTél)
PILOTE (NoPilote, Nom, AnnéesExp)
AVION (CodeAvion, Modèle, TypeMoteur, LongueurPisteReq, NbSiègesPrem, NbSiègesDeux,
NbSiègesAff)
HABILITATION (NoPilote, CodeAvion)
9
Tous les attributs sont simples et non décomposables, donc ce modèle est en 1FN.
Pour respecter les contraintes du modèle relationnel, il faut décomposer VOL (exception "2 à plusieurs"
du dernier
cours) en deux tables :
VOL (NoVol, Code Aéroport, HeureDécollage, HeureAtterrissage)
AEROPORT-DE-VOL (NoVol, CodeAéroport, Direction)
Les tables AÉROPORT, VOL, RÉSERVATION, ENVOLÉE, PASSAGER, PILOTE et AVION ont des
clés formées d’un seul attribut (condition 1 de la 2FN) et les tables JOURNÉES-VOL et HABILITATION
ont des clés constituées de tous les attributs de la table (condition 2 de la 2FN), donc le modèle est en
2FN.
Dans la table AÉROPORT, il existe une DF qui a pour origine les attributs "Ville" et "Prov-État" et dont
dépend "Pays" (Avec une ville et une province (ou état) donnés, il ne correspond qu’un seul pays). On
divise donc cettetable en deux de la façon suivante :
Il n’existe pas d’autres DF entre attributs ne faisant pas partie de la clé, donc ce modèle est en 3FN.
Il n’existe pas de DF entre des attributs ordinaires et des parties de clé, donc le modèle est en FNBC.
10
Le modèle final en FNBC est donc le suivant :
11