3.
1 Normalisation
3.1.1 Introduction
Les formes normales sont différents stades de qualité qui permettent d’éviter la redondance dans les
bases de données relationnelles afin d’éviter ou de limiter : les pertes de données, les incohérences au
sein des données, l’effondrement des performances des traitements.
Le processus de normalisation consiste à remplacer une relation donnée par certaines projections afin
que la jointure de ces projections permette de retrouver la relation initiale. En d’autres termes, le
processus est réversible (i.e. sans perte d’information). Les notions de projection et de jointure seront
respectivement définies dans les sections 3.4.3 et 3.4.8.
Il existe une hiérarchie dans les règles de normalisation : une relation en 5 e forme normale est
forcément en 4e forme normale, une relation en 4e forme normale est forcément en forme normale de
Boyce-Codd, etc. Il existe des méthodes systématiques pour normaliser une relation dans chacune des
formes normales. Ces algorithmes de décomposition, associés à chacune des formes normales, sortent
du cadre de ce cours et ne seront pas abordés.
La normalisation peut être effectuée, et c’est préférable, pendant la phase de conception sur le modèle
entités-associations (cf. section 2.5.4). Ce qui a été dit et les exemples qui ont été donnés dans cette section
restent transposables au modèle relationnel. Dans le cas où la normalisation est faite en amont, lors de la
conception, il n’est pas nécessaire de la recommencer sur le modèle relationnel. On peut tout de même
vérifier que les relations obtenues par le passage du modèle entités-associations au modèle relationnel
sont toujours en forme normale, mais, sauf erreur, il ne devrait pas y avoir de problème. Il en va tout
autrement lorsque l’on ne connaît pas bien, ou maîtrise pas bien, l’origine d’un modèle relationnel. Dans
ce cas, vérifier la normalisation des relations, et, le cas échéant, les normaliser, est une phase primordiale.
C’est également le cas lorsque le modèle relationnel est le modèle de conception (i.e. on ne passe pas par
un modèle entités-associations).
Contrairement à ce que nous avions fait dans la section 2.5.4 dans le cadre du modèle entités-
associations, nous abordons ici la normalisation en nous appuyant sur les notions de dépendance fonc-
tionnelle, dépendance multivaluée et dépendance de jointure. Il est important de prendre conscience que la
dépendance fonctionnelle, la dépendance multivaluée et la dépendance de jointure sont des notions
sémantiques. Elles tirent leurs origines dans les contraintes du monde réel. Comme ces contraintes par-
ticipent à la sémantique de la situation, elles doivent avoir une manifestation dans la base de données.
Les dépendances doivent donc être spécifiées dans la définition de la base de données afin que le SGBD
puisse les appliquer. Les concepts de normalisation fournissent en fait un moyen indirect de déclarer
ces dépendances. Autrement dit, la normalisation d’une base de données est une manifestation obser-
vable des dépendances observées dans le monde réel. La dépendance fonctionnelle permet de définir
les premières formes normales jusqu’à la forme normale de Boyce-Codd (1FN, 2FN, 3FN et BCNF).
La dépendance multivaluée permet de définir la quatrième forme normale (4FN) et la dépendance de
jointure la cinquième forme normale (5FN).
3.1.2 Dépendance fonctionnelle (DF)
Définition 3.14 -dépendance fonctionnelle (DF)- Soit R(A1, A2, . . . An) un schéma de relation, et X et Y
des sous-ensembles de A1, A2, . . . An. On dit que X détermine Y ou que Y dépend fonctionnellement de X si, et
seulement si, des valeurs identiques de X impliquent des valeurs identiques de Y. On le note : X → Y.
Autrement dit, il existe une dépendance fonctionnelle entre un ensemble d’attributs X et un ensemble
d’attributs Y, que l’on note X → Y, si connaissant une occurrence de X on ne peut lui associer qu’une
seule occurrence de Y.
Il est essentiel de noter qu’une dépendance fonctionnelle est une assertion sur toutes les valeurs
possibles et non sur les valeurs actuelles : elle caractérise une intention et non une extension de la
relation.
Définition 3.15 -dépendance fonctionnelle élémentaire- Une dépendance fonctionnelle élémentaire est
une dépendance fonctionnelle de la forme X → A, où A est un attribut unique n’appartenant pas à X et où il
n’existe pas XJ inclus au sens strict dans X (i.e. XJ c X) tel que XJ → A.
Autrement dit, une dépendance fonctionnelle est élémentaire si la cible est un attribut unique et
si la source ne comporte pas d’attributs superflus. La question sur l’élémentarité d’une dépendance
fonctionnelle ne doit donc se poser que lorsque la partie gauche de la dépendance fonctionnelle comporte
plusieurs attributs.
Définition 3.16 -dépendance fonctionnelle directe- Une dépendance fonctionnelle X → A est une dé-
pendance fonctionnelle directe s’il n’existe aucun attribut B tel que l’on puisse avoir X → B et B → A.
En d’autres termes, cela signifie que la dépendance entre X et A ne peut pas être obtenue par transitivité.
3.1.3 Première et deuxième forme normale
Première forme normale
Définition 3.17 -première forme normale (1FN)- Une relation est en première forme normale si, et seule-
ment si, tout attribut contient une valeur atomique (non multiples, non composées).
Par exemple, le pseudo schéma de relation Personne(num-personne, nom, prénom, rue-et-ville, prénoms-
enfants) n’est pas en première forme normale. Il faut le décomposer en :
– Personne(num-personne, nom, prénom, rue, ville)
– Prénoms-enfants(num-personne, num-prénom)
– Prénoms(num-prénom, prénom)
Remarques sur la première forme normale
La première forme normale impose que chaque ligne d’une relation ait une seule valeur pour chaque
colonne (i.e. attribut), ce qui est justement la définition d’une table. Donc, une table est nécessairement
en première forme normale au sens du modèle relationnel.
Cependant, il faut noter que le modèle relationnel peut être étendu de manière à permettre des
colonnes à valeur complexe. On parle alors de modèle relationnel étendu (NF2 pour Non First Normal Form
en anglais).
Deuxième forme normale
Définition 3.18 -deuxième forme normale (2FN)- Une relation est en deuxième forme normale si, et
seulement si, elle est en première forme normale et si toutes les dépendances fonctionnelles entre la clé et les autres
attributs sont élémentaires.
Autrement dit, une relation est en deuxième forme normale si, et seulement si, elle est en première
forme normale et si tout attribut n’appartenant pas à la clé ne dépend pas que d’une partie de la clé.
Une relation peut être en deuxième forme normale par rapport à une de ses clés candidates et ne pas
l’être par rapport à une autre. Une relation avec une clé primaire réduite à un seul attribut est, par
définition, forcément en deuxième forme normale.
Soit, par exemple, le schéma de relation suivant : CommandeLivre(Num-Commande, Num-Client,
Titre, Auteur, Quantité, Prix). Cette relation indique qu’un client (identifié par Num-Client) a passé une
commande (identifiée par Num-Commande) de livre. Elle est bien en première forme normale. Par contre,
les attributs Titre, Auteur, Quantité et Prix ne dépendent que de Num-Commande, et pas de Num-Client.
Cette relation n’est donc pas en deuxième forme normale. Une solution simple pour la normaliser est de
la remplacer par : CommandeLivre(Num-Commande, Num-Client, Titre, Auteur, Quantité, Prix).
3.1.4 Troisième forme normale
Définition 3.19 -troisième forme normale (3FN)- Une relation est en troisième forme normale si, et
seulement si, elle est en deuxième forme normale et si toutes les dépendances fonctionnelles entre la clé et les autres
attributs sont élémentaires et directes.
Autrement dit, une relation est en troisième forme normale si, et seulement si, elle est en
deuxième forme normale et si tout attribut n’appartenant pas à la clef ne dépend pas d’un
attribut non-clé.
Une relation peut être en troisième forme normale par rapport à une de ses clés candidates
et ne pas l’être par rapport à une autre. Une relation en deuxième forme normale avec au plus
un attribut qui n’appartient pas à la clé primaire est, par définition, forcément en troisième
forme normale.
Soit, par exemple, le schéma de relation suivant : CommandeLivre(Num-Commande,
Num-Client, Titre, Auteur, Quantité, Prix). Comme nous l’avons vu plus haut, cette relation
est bien en deuxième forme normale. Par contre, les attributs Auteur et Prix dépendent de
l’attribut Titre. La relation n’est donc pas en troisième forme normale. Pour la normaliser, il
faut la décomposer de la manière suivante :
– CommandeLivre(Num-Commande, Num-Client, Num-Livre, Quantité)
– Livre(Num-Livre, Titre, Auteur, Prix)
Remarques importantes
Soit les schémas de relation suivant :
– Ville(Code-Postal, Nom, Population)
– Personne(Nom, Prénom, Téléphone)
Dans ces relations, on suppose les dépendances fonctionnelles directes suivante :
– Code-Postal → Nom
– Code-Postal → Population
– Nom, Prénom → Téléphone
Dans la section 2.6.2, nous avons dit qu’il est souvent préférable de choisir un identifiant
arbitraire de type entier. Cette pratique semble aller à l’encontre de la troisième forme
normale. Par exemple, la relation Ville(num-ville, Nom, Code-Postal, Population) n’est pas en
troisième forme normale si l’on suppose que les attributs Nom et Population dépendent
toujours de l’attribut Code-Postal. Cependant, comme nous l’avons dit dans l’introduction, une
dépendance fonctionnelle est la manifestation d’une notion sémantique, pas d’une notion
formelle ou absolue. Dans le cas du code postal, nous avons déjà expliqué (cf. note page 33)
qu’il n’existe pas de relation systématique entre le code postal et le code du département
ou la commune. Ainsi, il n’y a pas de dépendance fonctionnelle entre les attributs Nom et
Population et l’attribut Code-Postal. La relation Ville(num-ville, Nom, Code-Postal, Population)
est donc bien en troisième forme normale (en France, plusieurs villes portent le même nom).
La notion de dépendance fonctionnelle est donc une question d’interprétation faisant appel à
la connaissance du système modélisé et au bon sens.
Il en va de même avec le schéma de relation Livre(Num-Livre, Titre, Auteur, Prix). Nous
avons ici introduit un identifiant numérique arbitraire Num-Livre car l’identifiant naturel Titre,
qui est une chaîne de caractères complexe, de taille non bornée et au format libre, ne constitue
pas un bon identifiant dans la pratique. Pour justifier la troisième forme normale de cette
relation, on peut imaginer que plusieurs livres peuvent porter le même titre.
Il faut enfin noter que la normalisation n’est pas une fin en soit et qu’elle ne doit pas
nécessairement être systématiquement appliquée (nous y reviendrons section 3.2.7).