Principes de la troisième forme normale (3NF)

La troisième forme normale (3NF), c'est un pas de plus vers un vrai rangement dans nos données. En gros, une table est en 3NF si :

1. Elle est déjà en deuxième forme normale (2NF).
2. Tous les attributs non-clés dépendent uniquement de la clé primaire et de rien d'autre (pas de dépendances transitives !).

En d'autres termes, la 3NF exige que toutes les données d'une table soient directement liées à sa clé primaire et ne dépendent pas d'autres attributs non-clés.

Une dépendance transitive, c'est quand l'attribut A dépend de l'attribut B, et que B dépend de l'attribut C, ce qui crée une chaîne de dépendances A → B → C. Par exemple, « Employé » dépend du « Département », et le « Département » dépend de « Emplacement ». Du coup, « Employé » dépend transitivement de « Emplacement ».

Exemple de violation de la 3NF

Imaginons qu'on a une table employees qui stocke les infos sur les employés :

Ici :

• employee_id — c'est la clé primaire.
• department et department_manager — ce sont des attributs non-clés.

À première vue, tout a l'air ok, mais si on regarde de plus près, on voit un souci : department_manager dépend pas de employee_id, mais de department. Donc, on a une dépendance transitive : employee_id → department → department_manager.

Les problèmes qui peuvent arriver

Si on change le nom du manager du département (« Finance »), il faudra mettre à jour toutes les lignes où ce département apparaît. Si on oublie une ligne, les données deviennent incohérentes. C'est la galère qu'on peut éviter.

Mettre la table en 3NF

Pour virer les dépendances transitives, on va séparer la table en deux : une pour les employés, l'autre pour les départements.

Table employees

Table departments

Maintenant, tout est bien rangé, et chaque table fait son taf :

1. La table employees garde les infos sur les employés.
2. La table departments stocke les infos sur les départements et leurs managers.

Si le manager d'un département change, on n'a qu'à mettre à jour une seule ligne dans la table departments, pas toutes les lignes des employés.

Comment savoir si une table viole la 3NF ?

Pour voir si une table viole la 3NF, vérifie :

1. Est-ce qu'il y a des dépendances transitives ? Par exemple, l'attribut A dépend de B, qui dépend de C.
2. Est-ce que tous les attributs non-clés dépendent directement de la clé primaire ? Si un truc dépend d'un autre attribut non-clé, la table n'est pas en 3NF.

Exemple pratique : magasin

Regarde la table sales qui contient les infos sur les ventes :

Ici, on voit clairement de la redondance : le prix du produit se répète à chaque vente. Si le prix change, les données deviennent vite incohérentes.

Pour corriger la violation de la 3NF, on va séparer la table en deux :

1. La table sales va garder les infos sur les ventes.
2. La table products — les infos sur les produits et leurs prix.

Table sales

Table products

Maintenant, si le prix d'un produit change, on met à jour une seule ligne dans la table products, et les données restent cohérentes.

Exercice pratique

Voilà un petit défi : tu as une table students_courses comme ça :

Sépare la table pour qu'elle respecte la 3NF. Astuce : il faut créer trois tables (students, courses, teachers) et bien les relier.

Pourquoi c'est important de respecter la 3NF ?

Pourquoi se prendre la tête avec la troisième forme normale (3NF) ? Parce que ça te simplifie vraiment la vie. Quand tes tables sont en 3NF, les données sont bien rangées — pas de doublons inutiles, donc moins de risques de tout casser par accident. Les mises à jour sont plus rapides et plus simples, vu que tout est stocké à un seul endroit, pas copié-collé partout.

En plus, la structure de la base devient plus flexible. Tu veux ajouter un nouveau champ ou modifier un ancien ? Pas besoin de tout refaire.

Mais, comme dans toute bonne histoire, y'a un mais : si tu normalises trop, tu te retrouves avec plein de petites tables et des requêtes compliquées avec plein de JOIN. Parfois, ça peut ralentir un peu. Donc le plus important, c'est de doser. Là où il faut — normalise, et là où c'est plus simple de garder un peu de redondance — n'aie pas peur.

On va continuer à creuser : on va apprendre à bien faire les relations entre les tables et à créer des bases qui sont à la fois pratiques et fiables. Allez, on fonce vers un super design de base de données !