Une facture unique peut contenir le nom du client, son adresse et plusieurs produits. Quand ces informations sont répétées partout, une modification oubliée suffit à créer des données contradictoires.
La normalisation organise les informations en tables liées pour réduire la redondance et protéger l’intégrité des données. Les formes normales donnent des règles concrètes pour examiner cette organisation.
À retenir :
- Valeurs atomiques et colonnes sans listes répétées
- Dépendance complète à toute la clé composée
- Informations descriptives rattachées à leur propre entité
- Dénormalisation fondée sur des mesures réelles
Normalisation des bases de données : comprendre les trois premières formes
Ces repères prennent leur sens lorsqu’on suit une commande de bout en bout. Selon Codd, les formes normales s’appuient sur les dépendances entre attributs pour structurer les relations.
Première forme normale : une valeur par cellule
La première forme normale exige que chaque cellule contienne une valeur unique, adaptée au sens de la colonne. Une cellule « Sony, Sharp, LG » dans la colonne Fournisseurs mélange plusieurs valeurs distinctes.
On peut créer une ligne par couple produit-fournisseur, ou une table d’association dédiée. Selon Codd, la structure relationnelle doit rendre les valeurs et leurs relations explicites, plutôt que dissimuler des listes dans les champs.
Pour une commande contenant plusieurs articles, la facture et ses lignes sont donc séparées. Cette organisation facilite les recherches, les modifications et le contrôle des quantités.
Les premiers contrôles portent sur la forme des valeurs :
- Une cellule consacrée à une seule valeur métier
- Aucune liste de produits dans une colonne
- Une clé identifiant chaque ligne sans ambiguïté
| Table | Clé possible | Informations conservées |
|---|---|---|
| Commandes | id_commande | Date et identifiant client |
| Clients | id_client | Nom et coordonnées |
| Articles | id_article | Description et prix courant |
| Lignes de commande | id_commande, id_article | Quantité commandée |
Deuxième et troisième forme normale : suivre les dépendances
Une fois les valeurs séparées, la clé indique quelles informations déterminent chaque ligne. Selon Codd, les dépendances fonctionnelles permettent de repérer les attributs qui appartiennent à une autre entité.
Deuxième forme normale : dépendre de toute la clé
La deuxième forme normale concerne surtout les clés composées de plusieurs attributs. Chaque information non identifiante doit dépendre de la clé entière, et non d’une partie seulement.
Supposons que les lignes soient identifiées par le couple commande-article. La quantité dépend de ce couple, tandis que la description de l’article dépend uniquement de l’identifiant de l’article.
Garder la description dans chaque ligne répéterait la même donnée pour toutes les commandes. Il vaut mieux la placer dans Articles, afin qu’une correction ne soit effectuée qu’à un seul endroit.
Troisième forme normale : éviter les dépendances indirectes
La troisième forme normale ajoute une vérification : un attribut non identifiant ne doit pas dépendre d’un autre attribut non identifiant. Selon Codd, chaque caractéristique doit être déterminée directement par la clé de sa table.
Si une table Clients contient l’identifiant, le nom et la ville, puis aussi le pays, la ville peut déterminer le pays. Séparer les villes et les pays évite de répéter cette relation pour chaque client.
Pour auditer un schéma, une équipe peut examiner les liens entre attributs :
- Commande détermine sa date et son client
- Article détermine sa description et son prix courant
- Client détermine ses coordonnées propres
- Commande et article déterminent la quantité de la ligne
| Attribut observé | Dépendance attendue | Emplacement approprié |
|---|---|---|
| Date de commande | Identifiant de commande | Commandes |
| Nom du client | Identifiant client | Clients |
| Description d’article | Identifiant article | Articles |
| Quantité achetée | Commande et article | Lignes de commande |
Appliquer les formes normales sans pénaliser les requêtes
Quand les tables sont bien réparties, la cohérence devient plus facile à maintenir. Cette structure peut toutefois nécessiter plusieurs jointures pour réunir les informations utiles à un écran ou un rapport.
Repérer les anomalies et choisir le bon découpage
Dans une facture regroupant client et articles, modifier l’adresse du client dans plusieurs lignes expose à des oublis. Une table Clients centralise cette adresse, tandis que les lignes relient la facture aux articles commandés.
La normalisation limite aussi les anomalies d’insertion et de suppression. Par exemple, retirer la dernière commande d’un article ne devrait pas effacer sa description du catalogue.
Les formes supérieures, comme la forme normale de Boyce-Codd ou la quatrième forme normale, traitent des dépendances plus particulières. Pour de nombreuses applications transactionnelles, la troisième forme normale constitue un objectif de départ utile.
Dénormaliser seulement après des mesures
Une base normalisée peut demander davantage de jointures, mais cela ne prouve pas qu’elle sera trop lente. Il faut mesurer les requêtes avec des volumes représentatifs avant de modifier le modèle.
Une dénormalisation peut accélérer un accès précis, tout en augmentant le stockage et le risque de divergence. Le choix doit donc tenir compte des écritures, des lectures et des coûts de maintenance.
Avant d’adapter le schéma, les équipes peuvent vérifier les points suivants :
- Les requêtes lentes sont identifiées et mesurées
- Les jointures responsables sont clairement repérées
- Les données dupliquées disposent d’une règle de mise à jour
- Les performances sont comparées après chaque changement
La méthode Merise a contribué à diffuser la modélisation par entités et relations dans les projets francophones. Elle rappelle qu’un découpage pertinent commence par identifier les objets du métier, comme les clients, produits, commandes et factures.
Source : E. F. Codd, « A Relational Model of Data for Large Shared Data Banks », Communications of the ACM, 1970 ; E. F. Codd, « Further Normalization of the Data Base Relational Model », 1971 ; C. J. Date, An Introduction to Database Systems, Addison-Wesley, 1999.
Un mot qui se comprend dossier après dossier
Qu'il s'agisse de philosophie bouddhiste, de méditation, de culture tibétaine, d'industrie durable, de linguistique ou de bien-être, chaque rubrique raconte une facette différente de la même question : comment un même mot peut porter, à la fois, une pensée millénaire et un usage bien actuel. Rien n'est figé : chaque contexte nouveau peut encore faire évoluer ce sens.
Pour aller plus loin
- Comparer plusieurs sources avant de juger la portée d'une traduction ou d'une définition
- Replacer chaque terme dans son contexte culturel réel, pas seulement sa traduction littérale
- S'intéresser aux usages vivants de la langue autant qu'aux définitions figées
- Observer comment un même mot évolue d'un domaine à l'autre au fil du temps
