Normalisation SQL : maîtrisez les formes normales

La normalisation SQL est la technique qui transforme une base de données mal conçue en un système fiable, sans redondance et facile à maintenir. En quelques règles formelles, elle garantit que chaque donnée est stockée une seule fois, au bon endroit.

Pourtant, la plupart des développeurs qui débutent en SQL créent des tables fourre-tout qui mélangent plusieurs concepts. Résultat : des mises à jour incohérentes, des doublons incontrôlés et des requêtes de plus en plus complexes. La normalisation résout exactement ces problèmes.

Ce guide vous explique les 3 premières formes normales — celles qui couvrent 95 % des besoins réels — avec des exemples chiffrés et des contre-exemples concrets. Vous apprendrez aussi quand il est acceptable de dénormaliser volontairement une table pour des raisons de performance.

Pourquoi la normalisation SQL est incontournable

Une base de données non normalisée génère 3 types d'anomalies qui coûtent cher en production.

L'anomalie d'insertion survient quand vous ne pouvez pas enregistrer une information sans en avoir une autre. Par exemple, si votre table commandes stocke aussi les coordonnées du client, vous ne pouvez pas créer un client sans lui associer une commande immédiatement.

L'anomalie de mise à jour apparaît quand une même donnée est dupliquée sur plusieurs lignes. Si le téléphone d'un client est répété dans 50 lignes de commandes, une modification nécessite 50 UPDATE — et un oubli crée une incohérence silencieuse.

L'anomalie de suppression est la plus dangereuse : supprimer une commande peut effacer des informations client dont vous avez encore besoin.

Ces 3 problèmes ont une seule cause racine : des dépendances fonctionnelles mal gérées. La normalisation formalise exactement comment les organiser.

La première forme normale (1NF) : atomicité des données

Définition et règles

Une table est en Première Forme Normale (1NF) si et seulement si :

• Chaque colonne contient des valeurs atomiques (indivisibles)
• Chaque colonne contient des valeurs d'un seul type
• Chaque ligne est unique, identifiée par une clé primaire
• Il n'existe pas de groupe répétitif de colonnes

La violation la plus fréquente de la 1NF est la colonne qui contient des listes de valeurs séparées par des virgules.

Exemple de table non conforme à la 1NF

Imaginons une table clients dans un système e-commerce :

| client_id | nom     | produits_achetes           | telephones              |
|-----------|---------|----------------------------|-------------------------|
| 1         | Martin  | "laptop, souris, clavier"  | "06-12, 07-34"          |
| 2         | Dupont  | "écran"                    | "01-56"                 |

Cette table viole la 1NF sur 2 points : produits_achetes contient plusieurs valeurs dans une cellule, et telephones aussi. Impossible d'interroger efficacement ces colonnes avec un simple WHERE.

Transformation vers la 1NF

La solution consiste à extraire les valeurs multiples dans leurs propres tables :

-- Table clients (valeurs atomiques uniquement)
CREATE TABLE clients (
    client_id   INT PRIMARY KEY,
    nom         VARCHAR(100) NOT NULL,
    email       VARCHAR(150) NOT NULL
);

-- Table telephones (1 ligne par numéro)
CREATE TABLE telephones (
    telephone_id INT PRIMARY KEY,
    client_id    INT REFERENCES clients(client_id),
    numero       VARCHAR(20) NOT NULL,
    type         VARCHAR(20) -- 'mobile', 'fixe'
);

-- Table achats (1 ligne par produit acheté)
CREATE TABLE achats (
    achat_id    INT PRIMARY KEY,
    client_id   INT REFERENCES clients(client_id),
    produit_id  INT,
    date_achat  DATE
);

Chaque cellule ne contient désormais qu'une seule valeur. Les requêtes WHERE, JOIN et GROUP BY deviennent naturelles.

La deuxième forme normale (2NF) : éliminer les dépendances partielles

Définition

Une table est en Deuxième Forme Normale (2NF) si :

• Elle est déjà en 1NF
• Chaque attribut non-clé dépend de toute la clé primaire, et non d'une partie seulement

La 2NF ne concerne que les tables avec une clé primaire composite (constituée de plusieurs colonnes). Si votre clé primaire est une seule colonne, votre table est automatiquement en 2NF dès lors qu'elle respecte la 1NF.

Exemple de dépendance partielle

Considérons une table commandes_produits avec une clé composite (commande_id, produit_id) :

| commande_id | produit_id | quantite | nom_produit    | categorie_produit |
|-------------|------------|----------|----------------|-------------------|
| 101         | 5          | 2        | "Laptop Pro"   | "Informatique"    |
| 101         | 8          | 1        | "Souris USB"   | "Périphériques"   |
| 102         | 5          | 3        | "Laptop Pro"   | "Informatique"    |

Le problème : nom_produit et categorie_produit dépendent uniquement de produit_id, pas de (commande_id, produit_id). Ce sont des dépendances partielles. Si le nom du produit 5 change, il faut mettre à jour toutes les lignes qui le référencent.

Transformation vers la 2NF

-- Table produits : les infos produit dépendent uniquement de produit_id
CREATE TABLE produits (
    produit_id  INT PRIMARY KEY,
    nom_produit VARCHAR(200) NOT NULL,
    categorie   VARCHAR(100)
);

-- Table commandes_produits : ne contient que ce qui dépend de la clé composite
CREATE TABLE commandes_produits (
    commande_id INT,
    produit_id  INT,
    quantite    INT NOT NULL,
    PRIMARY KEY (commande_id, produit_id),
    FOREIGN KEY (produit_id) REFERENCES produits(produit_id)
);

nom_produit et categorie sont désormais stockés une seule fois dans produits. Une mise à jour ne nécessite plus qu'une seule ligne modifiée.

Pour bien comprendre comment les contraintes SQL comme PRIMARY KEY et FOREIGN KEY s'articulent avec ces règles de normalisation, consultez notre guide dédié.

La troisième forme normale (3NF) : éliminer les dépendances transitives

Définition

Une table est en Troisième Forme Normale (3NF) si :

• Elle est déjà en 2NF
• Aucun attribut non-clé ne dépend d'un autre attribut non-clé (pas de dépendance transitive)

En d'autres termes : un attribut ne doit dépendre que de la clé, rien que de la clé, et toute la clé.

Exemple de dépendance transitive

| commande_id | client_id | ville_client | code_postal | region    |
|-------------|-----------|--------------|-------------|-----------|
| 101         | 42        | Lyon         | 69001       | Auvergne-RA|
| 102         | 17        | Bordeaux     | 33000       | Nouvelle-A |
| 103         | 42        | Lyon         | 69001       | Auvergne-RA|

Ici, commande_id → client_id → ville_client → code_postal → region. La région dépend du code postal, qui dépend du client, qui dépend de la commande. C'est une dépendance transitive : region ne dépend pas directement de commande_id.

Transformation vers la 3NF

-- Table regions : code_postal → ville, region
CREATE TABLE codes_postaux (
    code_postal VARCHAR(10) PRIMARY KEY,
    ville       VARCHAR(100) NOT NULL,
    region      VARCHAR(100) NOT NULL
);

-- Table clients : client_id → code_postal
CREATE TABLE clients (
    client_id   INT PRIMARY KEY,
    nom         VARCHAR(100) NOT NULL,
    code_postal VARCHAR(10) REFERENCES codes_postaux(code_postal)
);

-- Table commandes : commande_id → client_id
CREATE TABLE commandes (
    commande_id INT PRIMARY KEY,
    client_id   INT REFERENCES clients(client_id),
    date_cmd    DATE NOT NULL,
    montant     DECIMAL(10,2)
);

Chaque table ne contient que des dépendances directes avec sa clé primaire. Si la région associée au code postal 69001 change (fusion administrative), une seule ligne dans codes_postaux suffit.

Tableau comparatif des 3 formes normales