Qu’est-ce que la normalisation des bases de données ?

La normalisation des bases de données est un processus de conception de bases de données qui consiste à organiser les données dans des tables possédant un certain type de structure. Elle permet d’améliorer l’intégrité des données, de prévenir les anomalies, de réduire la redondance des données et de renforcer la performance des requêtes.

La normalisation consiste à optimiser les tables dans les systèmes de gestion de bases de données (SGBD) pour répondre à ce que l’on appelle les formes normales : des ensembles de règles régissant la manière dont les attributs sont organisés dans une table. Ces règles reposent en grande partie sur les relations entre les attributs (colonnes), et notamment les clés utilisées pour identifier les lignes de manière unique.

À la base, la normalisation des bases de données (parfois appelée normalisation des données) aide les entreprises et institutions à organiser, interroger et maintenir plus efficacement de grands volumes de données complexes, interconnectées et dynamiques. Même si les entreprises génèrent et stockent désormais des données à une échelle sans précédent, le besoin de normalisation des bases de données n’est pas nouveau. Il est antérieur au stockage cloud et même à l’invention des entrepôts de données.

Depuis les années 1960, les entreprises peinent à gérer les grands jeux de données. Dans les années 1970, Edgar F. Codd, mathématicien d’IBM connu pour son article fondateur introduisant les bases de données relationnelles, a suggéré que la normalisation des bases de données permettrait d’éviter les dépendances « indésirables » entre attributs (colonnes) et les problèmes qu’elles engendrent.

Autrement dit, lorsque les enregistrements de données sont liés les uns aux autres dans une structure de base de données, la modification d’une seule valeur ou ligne dans une grande table complexe peut avoir des conséquences involontaires, telles que des incohérences ou la perte de données. La normalisation des bases de données est conçue pour minimiser ces risques.

Voici quelques-uns des avantages de la normalisation des bases de données :

La normalisation des structures de données permet d’éviter trois principaux types d’anomalies :

Anomalies d’insertion : on parle d’anomalie d’insertion lorsqu’un enregistrement de données ne peut pas être inséré dans une table car les valeurs requises par une ou plusieurs colonnes de la table sont manquantes.

Anomalies de suppression : on parle d’anomalie de suppression lorsque la suppression d’un enregistrement entraîne la suppression involontaire de données importantes que ce dernier contient.

Anomalies de mise à jour : on parle d’anomalie de mise à jour lorsqu’une instance de données est mise à jour à un endroit de la base de données, mais pas aux autres endroits où cette valeur de données est stockée, ce qui entraîne l’incohérence des données.

Dans le contexte des bases de données relationnelles, une clé est une colonne ou un ensemble ordonné de colonnes qui permettent d’identifier les lignes de données d’une table. Dans les modèles relationnels, les clés établissent également des associations entre les tables liées. C’est ce qui contribue à la réussite et à l’efficacité des requêtes SQL dans les bases de données. Voici les clés qui prédominent dans les règles de normalisation des bases de données :

• Clés primaires
• Clés composites
• Clés candidates
• Clés étrangères
• Super clés

Une clé primaire est une colonne (ou plusieurs colonnes) au sein d’une table de base de données dont les valeurs servent d’identifiants uniques pour chaque ligne ou enregistrement. Par exemple, la colonne ID d’étudiant sera une clé primaire dans une table d’informations sur l’étudiant. Les caractéristiques déterminantes des clés primaires sont les suivantes : elles excluent les valeurs nulles, n’ont pas de valeurs en double et peuvent être composées d’une ou plusieurs colonnes.

Les clés comportant deux ou plusieurs colonnes sont appelées clés composites. Lorsque les clés primaires sont composites, on les appelle « clés primaires composites ».

Une clé candidate est une colonne (ou un groupe de colonnes) qui possède les caractéristiques d’une clé primaire, mais qui ne s’est pas vu attribuer l’état de clé primaire.

Une clé étrangère figurant dans une table renvoie à une clé primaire précise dans une autre table afin de définir une relation entre les tables. Lorsque des tables plus grandes sont divisées en tables plus petites lors de la normalisation, les clés étrangères et les clés primaires associent les nouvelles tables.

Les super clés, bien que similaires aux clés primaires composites, comportent plus de colonnes que nécessaire pour identifier de manière unique les enregistrements.

Plusieurs contraintes de normalisation des bases de données reposent sur les relations (également appelées dépendances) entre les clés primaires et les colonnes qui ne sont ni des clés primaires ni des clés candidates. Ces dernières sont appelées attributs non clés ou attributs non premiers.

Dans les bases de données au sein desquelles un attribut (le déterminant) détermine la valeur d’un autre, les relations entre les attributs sont appelées dépendances fonctionnelles. Les types de dépendances fonctionnelles sont les suivants : dépendance partielle, dépendance transitive, dépendance à valeurs multiples et dépendance de jointure. Ces relations sont mieux comprises lorsqu’elles sont abordées dans le contexte d’ensembles pertinents de règles de normalisation, ou de formes normales.

La normalisation des modèles de données consiste à concevoir des tables conformes à un ou plusieurs niveaux de normalisation, également appelés formes normales. Les formes courantes incluent :

• Première forme normale
• Deuxième forme normale
• Troisième forme normale et forme normale de Boyce-Codd
• Quatrième forme normale
• Cinquième forme normale

La première forme normale, le critère de normalisation des bases de données le plus élémentaire, exige qu’un schéma de table de base de données comprenne une clé primaire tout en excluant les répétitions entre les colonnes. Plus précisément, une table en première forme normale ne doit comporter ni champs avec diverses valeurs (par exemple, une cellule contenant trois noms différents), ni groupes répétitifs (des colonnes différentes qui stockent le même type de données).

Pour mieux comprendre la première forme normale, prenons comme exemple le jeu de colonnes suivant :¹

Les colonnes constituent une table regroupant les parents, ainsi que leur nom, leur date de naissance, leur date de mariage, leur adresse e-mail et le nom de leurs enfants.

Cette table enfreint la première forme normale, car elle contient trois colonnes distinctes stockant le même type d’informations : le nom des enfants. Dans ce cas notamment, la structure de la table peut entraîner des erreurs d’insertion. Par exemple, dans le monde réel, de nombreux parents ont moins de trois enfants.

Dans notre exemple, il n’est pas possible d’ajouter les enregistrements des parents à la table. De plus, interroger cette table pour trouver le nom d’un enfant serait inefficace, car il s’agirait de rechercher des données dans trois colonnes différentes de chaque ligne.

Pour obtenir la première forme normale des données d’une table, il est nécessaire de la diviser en deux. Une table comprendra la plupart des attributs de la table d’origine, tandis que l’autre concernera les enfants.

TABLE 1

TABLE 2

rec_num         child_name

Dans cet exemple, les nouvelles tables restent liées par le biais de la colonne « rec_num », qui est la clé primaire dans la table 1 et référencée par la colonne « rec_num » de la table 2, qui sert de clé étrangère.

Satisfaire à la première forme normale ne réduit pas toujours la redondance des données (les valeurs « rec_num » apparaîtront dans plusieurs lignes du Tableau 2 lorsque des parents ont plus d’un enfant), mais l’élimination des groupes répétitifs peut simplifier les requêtes.

Dans la deuxième forme normale, aucun attribut non clé n’a de dépendance partielle à l’égard de la clé primaire de la table. En d’autres termes, si une clé primaire est une clé composite, l’attribut non clé doit dépendre de toutes les colonnes de cette clé composite.

Prenons l’exemple d’une table d’inventaire qui recense les quantités de pièces stockées dans certains entrepôts. La figure suivante illustre les attributs de l’entité stock.²

Dans cet exemple, les colonnes « part » et « warehouse » forment une clé primaire composite. Cependant, l’attribut « warehouse_address » dépend uniquement de la valeur de « warehouse », en contradiction avec la deuxième forme normale.

Cette table est également sujette à la redondance des données, la valeur de l’adresse d’entrepôt étant répétée chaque fois qu’un enregistrement pour une pièce provenant du même entrepôt figure dans la table. Cela augmente le risque d’erreurs de mise à jour si l’adresse est modifiée dans une ligne et pas dans les autres. Une erreur de suppression peut également se produire si un entrepôt cesse de stocker des pièces : en supprimant les enregistrements de ces pièces, l’adresse de l’entrepôt serait supprimée aussi.

Afin de satisfaire la deuxième forme normale et de réduire le risque d’erreur, les données peuvent être réparties sur deux nouvelles tables :

TABLE 1

TABLE 2

entrepôt                                warehouse_address

Une table en troisième forme normale satisfait aux première et deuxième formes normales, tout en veillant à ce que les attributs non clés dépendent des clés primaires et non d’autres attributs non clés. Lorsque des attributs non clés dépendent d’autres attributs non clés, on parle de dépendance transitive, une violation de la troisième forme normale.

Voici un tableau contenant des informations sur les employés :³

Dans cette table, la clé primaire est la colonne « emp_num ». Cependant, la colonne « dept_name » dépend de la colonne « dept_num », un attribut qui n’est pas une clé. Par conséquent, la table ne respecte pas la troisième forme normale et présente un risque d’anomalies de mise à jour : si un nom de département, comme « manufacturing system », changeait, il faudrait le mettre à jour dans plusieurs lignes dans le schéma de table actuel.

Organiser les données en troisième forme normale dans une base de données normalisée permettrait d’éviter ces erreurs. Dans ce cas, le processus consisterait à structurer les données en trois tables distinctes : EMPLOYEE, DEPARTMENT et EMPLOYEE_DEPARTMENT⁴.

Table EMPLOYEE (EMPLOYÉS)

Table DEPARTMENT (SERVICE)

Table EMPLOYEE_DEPARTMENT

La forme normale de Boyce-Codd (BCNF) est une forme normale qui est considérée comme étant une version plus stricte ou plus forte de la troisième forme normale. La BCNF requiert l’utilisation de super clés.

Les tables respectent la quatrième forme normale si elles ne présentent pas de dépendances à valeurs multiples. On parle de dépendances à valeurs multiples lorsque les valeurs de deux ou plusieurs colonnes sont indépendantes les unes des autres et dépendent uniquement de la clé primaire.

Un exemple courant dans les tutoriels concerne des tables d’employés répertoriant à la fois leurs compétences et les langues parlées. Un employé peut avoir plusieurs compétences et parler plusieurs langues. Il existe donc deux relations : une entre employés et compétences, et une autre entre employés et langues.

Les tables ne respectent pas la quatrième forme normale si elles représentent les deux relations. Pour convertir les données en quatrième forme normale, il faudrait les structurer en deux tables, l’une pour les compétences des employés et l’autre pour les langues.

Généralement considérée comme le niveau de normalisation le plus élevé, la cinquième forme normale est un critère centré sur la dépendance de jointure. Dans la dépendance de jointure, après qu’une table est divisée en tables plus petites, il est possible de reconstituer la table d’origine en rassemblant les nouvelles tables, le tout sans perdre de données ni créer accidentellement de nouvelles lignes de données. C’est un peu comme un puzzle terminé qui, une fois démonté, peut être reconstitué dans sa forme initiale.

En cinquième forme normale, une table ne doit être divisée en tables plus petites que si la dépendance de jointure peut être atteinte. Si, en revanche, la reconstitution de la table d’origine à partir des tables plus petites aboutit à la création d’une table légèrement différente, alors la décomposition de la table d’origine ne devrait pas avoir lieu. Pour reprendre notre analogie du puzzle, ce serait comme reconstituer un puzzle et constater qu’une pièce manque ou qu’une pièce en trop est apparue.

Malgré tous ses avantages, la normalisation des bases de données implique certains compromis. Par exemple, avant la normalisation, un utilisateur recherchant des données spécifiques n’aurait pu avoir qu’à interroger une seule table. Après normalisation, la base de données peut contenir plus de tables, obligeant l’utilisateur à interroger plusieurs d’entre elles : un processus parfois plus lent et plus coûteux.

En outre, si la normalisation simplifie les tables, elle peut augmenter la complexité de la base de données et exige un savoir-faire considérable de la part des concepteurs et des administrateurs pour assurer une mise en œuvre appropriée.