Normalisation et Dependance Fonctionnelle

1. Dépendances fonctionnelles

Avant d’aborder les formes normales, il est crucial de comprendre la notion de dépendance fonctionnelle.

• On dit qu’un attribut (ou un groupe d’attributs) B dépend fonctionnellement d’un autre (ou groupe) A si la valeur de A détermine de manière unique la valeur de B.
• Notation : ( A \rightarrow B ).

Exemple simple :

• Dans une table Client(ID_Client, Nom, Adresse), on peut dire :
  ( ID_Client ) → ( Nom )
  ( ID_Client ) → ( Adresse )
  Autrement dit, chaque client a un ID_Client unique qui détermine son nom et son adresse.

2. Première forme normale (1NF)

2.1 Définition

Une table est en 1ère forme normale (1NF) si :

1. Toutes les valeurs des attributs sont atomiques (pas de champs multivalués ou de listes dans une seule colonne).
2. Il n’y a pas de groupes d’attributs répétitifs (ex. Téléphone1, Téléphone2…).

2.2 Exemple de violation

Supposons une table CLIENTS :

Ici, la colonne Téléphone contient parfois plusieurs numéros séparés par une virgule. C’est un champ non atomique.

2.3 Mise en 1NF

Pour satisfaire la 1NF, on crée souvent une table séparée pour les téléphones ou on sépare en plusieurs colonnes si c’est justifié. Par exemple :

Option 1 : une table séparée pour gérer plusieurs téléphones

Table CLIENT

Table CLIENT_TELEPHONE

Chaque enregistrement dans CLIENT_TELEPHONE est atomique et correspond à un seul numéro de téléphone pour un client.

3. Deuxième forme normale (2NF)

3.1 Définition

Une table est en 2ème forme normale (2NF) si :

1. Elle est déjà en 1NF.
2. Tout attribut non clé dépend de la totalité de la clé primaire (pas de dépendance partielle).

Remarque : La 2NF ne concerne que les tables qui ont une clé primaire composite (c’est-à-dire plusieurs colonnes pour la clé).

3.2 Exemple de violation

Prenons une table DETAIL_COMMANDES, avec une clé primaire composite (ID_Commande, ID_Produit), et un attribut Adresse_Client qui dépend seulement de ID_Commande :

• La clé primaire est (ID_Commande, ID_Produit).
• L’attribut Adresse_Client dépend uniquement de ID_Commande (et pas de ID_Produit).
• On a donc une dépendance partielle : ( ID_Commande \rightarrow Adresse_Client ).

3.3 Mise en 2NF

Pour corriger cela, on décompose la table pour que chaque attribut dépende de la clé entière :

1. On déplace Adresse_Client dans une table qui a pour clé uniquement ID_Commande (par exemple, la table COMMANDE).
2. La table DETAIL_COMMANDES ne contiendra alors que des attributs qui dépendent de (ID_Commande, ID_Produit).

Table COMMANDE (exemple simplifié)

Table DETAIL_COMMANDES

Ainsi, DETAIL_COMMANDES est en 2NF car chaque attribut (ici Quantité) dépend de l’ensemble de la clé (ID_Commande, ID_Produit).

4. Troisième forme normale (3NF)

4.1 Définition

Une table est en 3ème forme normale (3NF) si :

1. Elle est déjà en 2NF.
2. Tous les attributs non clés dépendent directement de la clé primaire, c’est-à-dire qu’il n’existe pas de dépendance transitive (un attribut non clé dépendant d’un autre attribut non clé, lui-même dépendant de la clé).

4.2 Exemple de violation (dépendance transitive)

Supposons la table PRODUIT :

• Clé primaire : ID_Produit.
• Attributs non clés : Nom_Produit, Catégorie, Nom_Catégorie.

Ici, on peut voir :

• ( ID_Produit \rightarrow Catégorie ) (direct)
• ( Catégorie \rightarrow Nom_Catégorie ) (un code catégorie détermine le nom de cette catégorie)
• Du coup, ( ID_Produit \rightarrow Nom_Catégorie ) transitivement via Catégorie.

4.3 Mise en 3NF

Pour éliminer la dépendance transitive, on crée une table dédiée pour les catégories :

Table CATEGORIE

Table PRODUIT (révisée)

• Désormais, PRODUIT est en 3NF car il n’y a plus de dépendance transitive : chaque attribut dépend uniquement de ID_Produit.
• Le Nom_Catégorie dépend de Catégorie, mais ce dernier est désormais une clé primaire dans la table CATEGORIE.

5. Forme Normale de Boyce-Codd (BCNF)

La BCNF (Boyce-Codd Normal Form) est une version plus stricte de la 3NF.

• En BCNF, pour toute dépendance fonctionnelle ( X \rightarrow Y ) dans une table, X doit être une clé candidate de la table.

En pratique, la plupart des schémas en 3NF sont déjà proches de la BCNF. Les cas où la BCNF est nécessaire sont plus rares (ils surviennent lorsqu’il existe plusieurs clés candidates et qu’une dépendance n’est pas respectée).

6. Résumé rapide des formes normales

1. 1NF : absence de groupes d’attributs répétitifs, valeurs atomiques.
2. 2NF : 1NF + aucun attribut non clé ne dépend d’une partie seulement de la clé primaire (pas de dépendance partielle).
3. 3NF : 2NF + tous les attributs non clés dépendent directement de la clé (pas de dépendance transitive).
4. BCNF : Toute dépendance fonctionnelle a pour déterminant une clé candidate.

7. Pourquoi normaliser ?

• Éviter les anomalies :
  1. Anomalie d’insertion : difficulté à insérer une donnée car d’autres attributs sont requis inutilement.
  2. Anomalie de mise à jour : risque d’incohérence lorsqu’une information doit être mise à jour dans plusieurs lignes redondantes.
  3. Anomalie de suppression : perte d’informations annexes lorsqu’on supprime un tuple qui contient plusieurs types de données.
• Réduire la redondance et donc gagner en espace de stockage.
• Améliorer la cohérence et la maintenabilité de la base (moins de duplication, plus facile à faire évoluer).

8. Conclusion et conseils de pratique

• Les formes normales (1NF, 2NF, 3NF, BCNF…) forment une suite logique. Lors de la conception, on va progressivement affiner le modèle pour éliminer les redondances et anomalies.
• Dans la pratique, la plupart des BD sont correctement conçues en 3NF, parfois BCNF si nécessaire.
• Attention : une normalisation excessive peut parfois avoir un impact sur les performances (notamment si on multiplie les tables). Il faut donc trouver un compromis entre normalisation et performance (d’où la dénormalisation partielle dans certains contextes).
• Il est important de maîtriser les dépendances fonctionnelles pour identifier les bonnes décompositions de tables.

En résumé, la normalisation est un processus clé pour obtenir une base de données cohérente, sans redondance, et facilitant la maintenance. Les exemples ci-dessus illustrent les corrections typiques pour passer de 1NF à 3NF.