La normalisation des bases de données peut se résumer en une phrase : « Un même fait ne doit être stocké qu’à un seul endroit. » La méthode pour y parvenir de façon systématique, c’est 1NF → 2NF → 3NF.
Pourquoi est-ce important ? Parce que si la même information est dispersée sur plusieurs lignes, il suffit d’en modifier une seule sans corriger les autres pour que les données deviennent contradictoires. C’est ce qu’on appelle une anomalie de mise à jour. Essayez-le vous-même ci-dessous.
Le laboratoire de Prof.A a changé, mais dans une table non normalisée, il faut corriger manuellement les 2 lignes. Si vous en oubliez une seule, vous obtenez une contradiction du type « Prof.A est à la fois en Room 301 et en Room 502 ». Dans une table en 3NF, il suffit de modifier 1 seule ligne.
Voilà tout le principe de la normalisation — le reste, ce sont des règles pour décider « dans quelle table placer quelle colonne afin qu’un fait ne soit stocké qu’une seule fois ».
Dépendance fonctionnelle — le critère de la normalisation
La normalisation consiste à se demander « de quoi dépend cette colonne ? ». C’est ce qu’on appelle une dépendance fonctionnelle.
Par exemple, student_id → student_name signifie : « si on connaît l’ID de l’étudiant, alors son nom est déterminé ».
Dans le diagramme ci-dessous, regardez la couleur des flèches :
- vert = dépend de la clé entière (correct)
- jaune = dépend seulement d’une partie de la clé (dépendance partielle → violation de la 2NF)
- rouge en pointillés = dépend en passant par une colonne non-clé (dépendance transitive → violation de la 3NF)
Supprimer les flèches jaunes et rouges = découper la table = normaliser.
Voir 1NF → 2NF → 3NF d’un seul coup
Cliquez ci-dessous pour voir, étape par étape, comment la table se décompose. Les cellules rouges indiquent : « cette colonne ne devrait pas être ici ».
1NF : une seule valeur par cellule
Si une cellule contient plusieurs valeurs comme MATH101, CS102, on ne peut ni faire des recherches correctement, ni faire des JOIN proprement.
Règle : chaque cellule doit être atomique, c’est-à-dire contenir une seule valeur.
Des colonnes comme phone1, phone2, phone3 posent le même problème — on ne fait que cacher les valeurs dans le nom des colonnes.
2NF : supprimer les dépendances partielles
Dans une table dont la clé composite est (student_id, course_id), student_name dépend seulement de student_id. Elle ne dépend donc pas de la clé entière, mais seulement d’une partie — c’est une dépendance fonctionnelle partielle.
Règle : toute colonne non-clé doit dépendre de la clé entière.
S’il existe une dépendance partielle, on retire cette colonne pour en faire une table séparée.
Et si la clé ne contient qu’une seule colonne ? Alors une dépendance partielle est impossible, donc une table en 1NF est automatiquement en 2NF.
3NF : supprimer les dépendances transitives
Dans la table Courses, instructor_office ne dépend pas directement de course_id (la clé). Elle dépend via le chemin course_id → instructor_id → instructor_office — autrement dit, une colonne non-clé dépend d’une autre colonne non-clé. C’est une dépendance transitive.
Règle : une colonne non-clé ne doit dépendre que de la clé. Elle ne doit pas dépendre d’une autre colonne non-clé.
Solution : déplacer instructor_office dans la table Instructors.
Une seule question à retenir plutôt que du par cœur
« Tout attribut non-clé doit dépendre de la clé, de toute la clé, et de rien d’autre que la clé. »
Cette phrase résume tout :
- de la clé = 1NF (le fait doit pouvoir être identifié par une clé)
- de toute la clé = 2NF (dépendance à la clé entière, pas à une partie)
- de rien d’autre que la clé = 3NF (dépendance directe à la clé, sans passer par une colonne non-clé)
Si vous tombez sur un exercice de normalisation à l’examen, posez simplement cette question : « De quoi dépend cette colonne ? De la clé entière, d’une partie de la clé, ou d’une colonne non-clé ? »
Erreurs fréquentes
« Une fois en 3NF, c’est terminé » — la 3NF est un très bon point de départ, pas forcément le point final. Dans certains cas, une BCNF plus stricte est nécessaire ; dans d’autres, on choisit volontairement de dénormaliser pour des raisons de performance.
« Plus on découpe les tables, mieux c’est » — le but de la normalisation n’est pas d’augmenter le nombre de tables, mais de faire en sorte que « chaque table ne soit responsable que d’un seul type de fait ». Si vous découpez sans vraie raison liée aux dépendances, vous ne faites que compliquer les JOIN.
« En NoSQL, la normalisation ne sert à rien » — la normalisation est un terme propre aux bases relationnelles, mais le problème de la cohérence des données dupliquées existe dans n’importe quel type de base. Même quand on dénormalise, il faut savoir clairement « à quoi on renonce ».
Vérifiez-le vous-même
Choisissez une table de votre propre projet, puis :
- Notez quelle est la clé.
- Vérifiez si chaque colonne non-clé dépend de la clé entière ou seulement d’une partie. → Si c’est une partie, il y a violation de la 2NF.
- Vérifiez si une colonne non-clé dépend d’une autre colonne non-clé. → Si oui, il y a violation de la 3NF.
Avec ces 3 étapes seulement, vous pouvez repérer la plupart des problèmes de normalisation.
Besoin d'aide pour un problème ?
Envoyez votre question et obtenez une solution vérifiée, étape par étape, en quelques secondes.
Ouvrir GPAI Solver →