Quand on parle d'analyser une base de données pour la conformité aux formes normales, on veut dire qu'on étudie la structure des tables, leurs relations et les dépendances entre les attributs. Le but principal de l'analyse, c'est de trouver les violations de la normalisation et d'évaluer leur impact sur les performances, l'intégrité et la facilité de bosser avec les données.
En gros, c'est comme un audit comptable : tu vérifies que l'argent n'est pas rangé n'importe comment, mais bien réparti dans les bonnes catégories de dépenses.
Approche pratique pour analyser une base de données
Dans n'importe quelle base de données, on commence par se poser trois questions fondamentales, qui correspondent aux trois premières formes normales.
Imaginons qu'on a une base de données d'entrepôt avec une table de cette structure :
| product_id | product_name | supplier_name | supplier_phone | stock_quantity |
|---|---|---|---|---|
| 1 | Clous | StroyKomplekt | +12301112233 | 150 |
| 2 | Vis | KrepezhPro | +12306667788 | 200 |
| 3 | Écrous | StroyKomplekt | +12301112233 | 100 |
Comment vérifier si cette table respecte les formes normales ?
Petit rappel, une table est en 1NF si :
- Chaque cellule contient une seule valeur.
- Il n'y a pas de colonnes répétées pour le même type de données.
Dans notre exemple, il n'y a pas de violation de la 1NF : chaque cellule contient une valeur atomique. Ça veut dire que la table est en 1NF. Yes ! On peut passer à la suite.
Une table est en 2NF si :
- Elle est déjà en 1NF.
- Tous les attributs non-clés dépendent uniquement de la clé primaire entière (et pas d'une partie seulement).
Dans cette table, on voit que supplier_name et supplier_phone dépendent seulement de product_id — la clé primaire. Mais ici, on a une duplication de données : pour un même fournisseur, on stocke son nom et son téléphone dans plusieurs lignes.
Pour passer la table en 2NF, on peut la diviser en deux tables :
Table Products :
| product_id | product_name | supplier_id | stock_quantity |
|---|---|---|---|
| 1 | Clous | 1 | 150 |
| 2 | Vis | 2 | 200 |
| 3 | Écrous | 1 | 100 |
Table Suppliers :
| supplier_id | supplier_name | supplier_phone |
|---|---|---|
| 1 | StroyKomplekt | +78901112233 |
| 2 | KrepezhPro | +78906667788 |
Maintenant, chaque fournisseur est représenté une seule fois, et la relation entre les tables se fait via la clé étrangère supplier_id.
Une table est en 3NF si :
- Elle est déjà en 2NF.
- Tous les attributs non-clés dépendent uniquement de la clé primaire, et pas d'autres attributs non-clés.
Dans le cas des tables normalisées Products et Suppliers, on ne voit pas de dépendances transitives. Ça veut dire que les tables sont en 3NF.
Exercice pratique
Supposons qu'on a la table d'origine "Université"
| student_id | student_name | course_name | professor_name | professor_email |
|---|---|---|---|---|
| 101 | Otto Lin | Mathématiques | Peter Pen | pen@university.com |
| 102 | Anna Song | Physique | Alex Sid | sid@university.com |
| 103 | Otto Lin | Physique | Alex Sid | sid@university.com |
- Vérifie la table pour la conformité aux formes normales.
- Amène-la en 1NF, 2NF et 3NF si besoin.
Solution
ÉTAPE 1 : Vérification de la 1NF
La table est déjà en 1NF : chaque cellule contient une seule valeur.
ÉTAPE 2 : Vérification de la 2NF
La table viole la 2NF : les infos sur les profs (nom et email) sont répétées. On peut les mettre dans une table séparée :
Table Students :
| student_id | student_name |
|---|---|
| 101 | Otto Lin |
| 102 | Anna Song |
Table Courses :
| course_id | course_name | professor_id |
|---|---|---|
| 1 | Mathématiques | 1 |
| 2 | Physique | 2 |
Table Professors :
| professor_id | professor_name | professor_email |
|---|---|---|
| 1 | Peter Pen | pen@university.com |
| 2 | Alex Sid | sid@university.com |
Table Enrollments :
| enrollment_id | student_id | course_id |
|---|---|---|
| 1 | 101 | 1 |
| 2 | 102 | 2 |
| 3 | 103 | 2 |
ÉTAPE 3 : Vérification de la 3NF
Dans la nouvelle structure, il n'y a pas de dépendances transitives. Les tables sont en 3NF.
Conseils pratiques
- Ne cherche pas la perfection si ce n'est pas nécessaire. Parfois, trop normaliser complique les requêtes.
- Analyse comme un détective. Cherche les doublons, les dépendances inutiles et autres "anomalies".
- N'oublie pas les perfs. La normalisation, c'est un équilibre entre la propreté des données et la rapidité de traitement.
Maintenant que tu sais repérer les problèmes dans une base de données et les corriger, tu pourrais honnêtement faire un "audit" d'une base de n'importe quelle taille. Rappelle-toi : une bonne base de données, c'est pas seulement fonctionnel, c'est aussi joli (ou normalisé) comme projet.
GO TO FULL VERSION