La normalisation et la troisième forme normale (3FN)
« La clé, toute la clé, rien que la clé » : cette phrase mnémonique résume les trois formes normales d'une base de données. Savoir dire si un schéma respecte la normalisation jusqu'à la 3e forme normale (3FN), et le justifier, est une compétence explicitement attendue à l'UE 8 du DCG. Voici la méthode complète, des dépendances fonctionnelles au schéma normalisé.
Pourquoi normaliser ? Les anomalies de mise à jour
Un schéma mal conçu, où la même information est répétée à plusieurs endroits (redondance), expose à trois types d'anomalies.
L'anomalie d'insertion : impossible d'insérer une information sans en connaître une autre. Si l'adresse du fournisseur est stockée dans la table PRODUIT, on ne peut pas enregistrer un nouveau fournisseur tant qu'il ne fournit aucun produit.
L'anomalie de suppression : la suppression d'un enregistrement entraîne la perte d'informations non liées. Si on supprime le dernier produit d'un fournisseur, on perd aussi ses coordonnées.
L'anomalie de modification : la même information étant stockée à plusieurs endroits, une modification n'est appliquée qu'à certains enregistrements - le fournisseur change d'adresse, mais elle n'est mise à jour que dans trois lignes sur dix. Incohérence garantie.
La normalisation, fondée sur le modèle relationnel d'Edgar F. Codd (1970), élimine ces anomalies en structurant correctement les tables.
Les dépendances fonctionnelles : le concept fondamental
On dit que l'attribut A détermine fonctionnellement l'attribut B (noté A → B) si, à chaque valeur de A, correspond une et une seule valeur de B. A est le déterminant, B le dépendant. Concrètement : si l'on connaît la valeur de A, on peut en déduire avec certitude celle de B.
Dans un énoncé, on repère les dépendances fonctionnelles (DF) dans les règles de gestion du type « un X a un seul Y » : « un client a un seul nom » donne NumClient → NomClient ; « pour une commande et un produit donnés, il y a une seule quantité » donne (NumCommande, NumProduit) → Quantite.
Deux distinctions sont à connaître. Une DF est élémentaire si aucun sous-ensemble strict du déterminant ne détermine le dépendant - on ne peut pas simplifier le déterminant. Une DF est directe s'il n'existe pas d'attribut intermédiaire C tel que A → C → B ; sinon elle est transitive. Exemple type : NumCommande → NumClient → NomClient. On connaît le nom du client via le numéro de commande, mais en passant par NumClient : la DF NumCommande → NomClient n'est pas directe.
Les trois formes normales
Première forme normale (1FN) : une table est en 1FN si tous ses attributs sont atomiques (non décomposables) et s'il n'y a pas d'attributs multivalués. Un champ « Téléphones » contenant « 06xxx, 07xxx » viole la 1FN.
Deuxième forme normale (2FN) : une table est en 2FN si elle est en 1FN et si chaque attribut non-clé dépend de la totalité de la clé primaire, pas d'une partie seulement. Cette règle ne s'applique que si la clé est composée de plusieurs attributs : si la clé primaire est un attribut unique, la table est automatiquement en 2FN. Exemple de violation : dans LIGNECOMMANDE(#NumCommande, #CodeProduit, Quantite, LibelleProduit), LibelleProduit ne dépend que de CodeProduit, pas de la clé complète.
Troisième forme normale (3FN) : une table est en 3FN si elle est en 2FN et si aucun attribut non-clé ne dépend d'un autre attribut non-clé - autrement dit, pas de dépendance transitive. Exemple de violation : dans CLIENT(NumClient, Nom, CodePostal, Ville), Ville dépend de CodePostal et non directement de NumClient.
D'où le moyen mnémonique : 1FN, des attributs atomiques rattachés à la clé ; 2FN, chaque attribut dépend de toute la clé ; 3FN, chaque attribut ne dépend que de la clé. Pour aller plus loin, la forme normale de Boyce-Codd (BCNF) exige que tout déterminant d'une DF soit une clé candidate - elle est rarement demandée, mais bonne à connaître.
Un exemple concret : la table de facturation unique
L'entreprise GestiFact (cas fictif) gère ses factures dans une table unique :
FACTURE(NumFacture, DateFacture, NumClient, NomClient, AdresseClient, CodeProduit, LibelleProduit, PrixUnitaire, Quantite)
La clé primaire est (NumFacture, CodeProduit), car une facture contient plusieurs lignes. Vérifions les formes normales. 1FN : oui, les attributs sont atomiques. 2FN : non - NomClient et AdresseClient dépendent de NumClient via NumFacture seul, et LibelleProduit comme PrixUnitaire dépendent de CodeProduit seul : des attributs dépendent d'une partie de la clé. 3FN : non a fortiori. Les anomalies suivent : impossible d'enregistrer un client sans facture (insertion), perte des coordonnées client en supprimant sa seule facture (suppression), changement d'adresse à répercuter sur toutes les lignes (modification).
Le schéma normalisé en 3FN :
- CLIENT(NumClient, NomClient, AdresseClient)
- PRODUIT(CodeProduit, LibelleProduit, PrixUnitaire)
- FACTURE(NumFacture, DateFacture, #NumClient)
- LIGNEFACTURE(#NumFacture, #CodeProduit, Quantite)
Chaque information n'est plus stockée qu'une seule fois : plus aucune anomalie.
Les erreurs fréquentes
- Confondre 2FN et 3FN : la 2FN traite les dépendances envers une partie de la clé composée ; la 3FN traite les dépendances transitives entre attributs non-clé.
- Oublier que la 2FN ne concerne que les clés composées : avec une clé primaire mono-attribut, la table est automatiquement en 2FN - inutile de chercher une violation.
- Croire que la normalisation est toujours souhaitable : en pratique, on accepte parfois une redondance maîtrisée pour limiter les jointures et améliorer les performances. C'est un compromis à justifier.
- Stocker des données calculées sans précaution : un montant égal à prix × quantité est une redondance à maintenir ; si on le stocke pour la performance, il faut le signaler et le justifier.
FAQ
Comment justifier qu'un schéma est normalisé à l'examen ?
Procédez dans l'ordre : listez les dépendances fonctionnelles à partir des règles de gestion, identifiez la clé (le groupe minimal d'attributs qui détermine tous les autres), puis vérifiez successivement la 1FN (atomicité), la 2FN (dépendance de toute la clé) et la 3FN (aucune dépendance transitive). En cas de violation, décomposez la table pour isoler la DF problématique.
Quel est l'intérêt concret d'un schéma normalisé ?
Obtenir une base cohérente et sans redondance : chaque information est stockée une seule fois, ce qui élimine les anomalies d'insertion, de suppression et de modification, et facilite la compréhension du schéma par tous les acteurs.
Une table en 3FN est-elle forcément en 2FN ?
Oui : les formes normales sont cumulatives. La 2FN suppose la 1FN, la 3FN suppose la 2FN. Inversement, une table qui viole la 2FN viole automatiquement la 3FN « a fortiori » - formulation attendue dans les corrigés.
Entraînez-vous
Soit la table INSCRIPTION(NumEtudiant, NomEtudiant, CodeFormation, LibelleFormation, DateInscription, Note), avec pour clé primaire (NumEtudiant, CodeFormation).
- Listez les dépendances fonctionnelles à partir des règles de gestion implicites (un étudiant a un seul nom ; une formation a un seul libellé ; pour un étudiant et une formation donnés, une seule date et une seule note).
- En quelle forme normale cette table est-elle ? Justifiez pour chaque forme.
- Proposez un schéma normalisé en 3FN.
Afficher le corrigé
1. Dépendances fonctionnelles. NumEtudiant → NomEtudiant (un étudiant a un seul nom) ; CodeFormation → LibelleFormation (une formation a un seul libellé) ; (NumEtudiant, CodeFormation) → DateInscription, Note (pour un couple étudiant-formation, une seule date et une seule note).
2. Vérification des formes normales. 1FN : oui, tous les attributs sont atomiques, pas de groupe répétitif. 2FN : non. La clé est composée, or NomEtudiant ne dépend que de NumEtudiant et LibelleFormation ne dépend que de CodeFormation : des attributs non-clé dépendent d'une partie seulement de la clé. 3FN : non a fortiori, puisque la table n'est pas en 2FN. Anomalies associées : impossible d'enregistrer un étudiant sans inscription, perte du libellé d'une formation si on supprime sa dernière inscription, changement de nom d'étudiant à répercuter sur toutes ses inscriptions.
3. Schéma normalisé en 3FN.
- ETUDIANT(NumEtudiant, NomEtudiant)
- FORMATION(CodeFormation, LibelleFormation)
- INSCRIPTION(#NumEtudiant, #CodeFormation, DateInscription, Note)
Vérification : dans ETUDIANT et FORMATION, chaque attribut dépend directement de la clé ; dans INSCRIPTION, DateInscription et Note dépendent de la clé entière (NumEtudiant, CodeFormation). Plus aucune dépendance partielle ni transitive : le schéma est en 3FN.