Qu'est-ce que la normalisation de base de données ? Quelles sont les formes normales ?

La normalisation de base de données est un ensemble structuré d'étapes permettant de concevoir de manière optimale un modèle de base de données. Grâce à la normalisation de la base de données, les administrateurs de base de données, les ingénieurs de données et les architectes de données peuvent modéliser et concevoir un cadre pour stocker les données d'une application de manière à ce que la couche de base de données de l'application fonctionne avec une efficacité maximale.

Dans ce contexte, le modèle de données fait référence à l'ensemble de relations et d'entités conceptuelles spécifiques au cas d'utilisation métier que les données représentent. Par exemple, dans le cas des données bancaires de détail, cela peut inclure des transactions financières et des informations sur les comptes d'épargne des clients.

Étant donné que la plupart des sites Web et des applications logicielles reposent sur le stockage des données pour fonctionner efficacement, la normalisation des bases de données reste une étape cruciale dans la gestion des données.

Il convient de noter qu'il existe également une sixième forme normale (6NF). Cela dit, 6NF n'est pas encore normalisé, je ne l'ai donc pas inclus dans cette définition.

Lecture connexe du dictionnaire technique de Built InQu'est-ce que l'architecture de données

Le processus de normalisation de la base de données est une étape critique dans la gestion de notre base de données pour de nombreuses raisons. La normalisation de la base de données nous aide :

Les anomalies de base de données sont des erreurs qui se produisent lors de la modification de données, telles que l'insertion, la mise à jour ou la suppression de valeurs ou d'attributs de données spécifiques. Ces modifications peuvent entraîner des données incorrectes ou manquantes. La normalisation des données peut empêcher la base de données de souffrir de ces problèmes lors des opérations quotidiennes.

Les dépendances fonctionnelles sont des relations entre les attributs de la base de données, qui sont les entités conceptuelles et physiques représentées par les données. L'attribut d'un client peut être son numéro de téléphone ou son adresse personnelle.

Voici comment cela fonctionne : un attribut (A) est fonctionnellement dépendant d'un autre attribut (B) lorsque, en connaissant la valeur de B, vous pouvez déterminer de manière unique la valeur de A. Ce processus ne fonctionne pas en sens inverse. En d'autres termes, les dépendances fonctionnelles représentent les relations entre les données. Ceux-ci sont mieux organisés ou gérés par la normalisation, un processus que je vais démontrer ci-dessous.

Dans la conception de bases de données, nous voulons éviter que de nombreuses parties de la base de données (et ses données) dépendent de plusieurs autres parties de la base de données. En d'autres termes, nous voulons éviter un système fortement couplé.

Dans un système étroitement couplé, une partie du système peut se casser ou cesser de fonctionner, entraînant ainsi la rupture de nombreuses autres parties, ce qui affecte finalement négativement les performances de la base de données.

La normalisation aide les administrateurs de base de données à obtenir un système faiblement couplé, plus modulaire et moins interdépendant. Ce couplage lâche facilite les diagnostics opérationnels et l'analyse des causes profondes des problèmes lorsqu'ils surviennent inévitablement.

Plus de base de données 101 de nos expertsQu'est-ce qu'une base de données relationnelle ?

Dans la gestion de base de données, les redondances se réfèrent principalement à la présence de données en double dans le système, ce que nous pouvons éviter grâce à la normalisation. Il est important d'éviter les données en double car cela peut nous faire économiser de l'argent et des ressources de stockage supplémentaires nécessaires pour les maintenir, en plus du risque de devoir mettre à jour/maintenir la cohérence des données à plusieurs endroits au lieu de simplifier le modèle de données.

Un effet secondaire positif de tout ce qui précède est l'évitement des bogues, des problèmes système et, finalement, même des temps d'arrêt potentiels de l'application logicielle. Un temps d'arrêt du système peut survenir en raison de défaillances au niveau de la couche de base de données si les données ne sont pas correctement normalisées. Cet aspect relie directement la gestion et le stockage appropriés des données d'application dans les systèmes back-end à l'expérience client sur le front-end et, en fin de compte, au succès commercial de l'entreprise propriétaire de l'application.

Une base de données normalisée permet également de réaliser des gains d'efficacité. Par exemple, votre système peut avoir besoin d'exécuter un plus petit ensemble d'opérations pour modéliser, servir et traiter les données des clients. Un ensemble d'opérations plus petit en raison de données bien normalisées nécessite également moins de puissance de calcul, ce qui entraîne des économies de coûts sur l'infrastructure logicielle (ou pile) sur laquelle l'application de base de données s'exécute. Pour cette raison, la normalisation des bases de données est également directement liée aux économies de coûts opérationnels.

Maintenant que nous comprenons les avantages de la normalisation, passons en revue les étapes de normalisation de nos bases de données. Nous les appelons les formes normales.

A cette étape, nos données ne sont pas encore normalisées, elles sont donc pleines de redondances et encore sous leur forme brute sans aucune structure ou logique de modélisation qui leur est appliquée.

Passer de 0NF à 1NF implique :

Examinons un exemple de ce qu'il faut pour déplacer des données de 0NF à 1NF en utilisant des livres comme ensemble de données d'échantillon.

Ci-dessous, vous pouvez voir que le tableau représente les données sous une forme normale zéro, car chaque livre stocke plusieurs informations sur l'auteur dans différents attributs (Auteur 1 et Auteur 2), qui répètent des colonnes des mêmes données. De plus, il existe des colonnes telles que Nom de l'auteur qui stockent plusieurs valeurs, et cela doit être corrigé.

Nous éliminons les redondances en divisant les données en une table Books (et en créant un identifiant d'ID de livre) et une table Book-Author. La table des livres a maintenant un identifiant d'ID de livre, tandis que la table d'auteur de livre stocke toutes les informations d'identification de l'auteur dans une seule colonne (l'ID de l'auteur), ainsi que des attributs d'auteur supplémentaires (nom de l'auteur, sexe et emplacement géographique).

Nous n'avons qu'un seul livre dans cet exemple, mais la structure tient lorsque nous augmentons le nombre de livres que nous stockons.

Apprenez des experts de Built InQu'est-ce qu'une base de données non relationnelle ?

Passer de 1NF à 2NF implique :

Ces données ne sont pas entièrement dépendantes sur le plan fonctionnel puisque, selon la définition de dépendance fonctionnelle dont nous avons discuté ci-dessus, nous ne pouvons pas déterminer de manière unique le nom de l'auteur en fonction de certains autres attributs, tels que l'ID du livre.

En effet, BookID a deux auteurs distincts, ce qui signifie que nous devons prendre correctement les données dans leur deuxième forme normale.

Pour déterminer de manière unique la valeur d'un attribut à partir de la valeur de sa clé, nous divisons davantage les données et créons la table Authors. Avec les données de ce formulaire, nous sommes désormais en mesure de :

Passer de 2NF à 3NF implique :

Une fois que nous avons réévalué les données selon les troisièmes règles de forme normale, nous remarquons qu'il existe un champ non ID (Province) qui détermine de manière unique la valeur de l'attribut Pays. Par conséquent, le pays dépend fonctionnellement de la province, une colonne non ID.

En éliminant cette dépendance, nous pouvons obtenir les données sous la troisième forme normale. Pour ce faire, nous créons une table Province avec les valeurs Province définies comme ID de province et gardons l'ID de province dans la table Auteurs. Enfin, nous lions les données et évitons la dépendance transitive que nous avons vue dans la deuxième forme normale.

Passer de la forme normale 3NF à la forme normale Boyce-Codd implique :

La différence entre cette forme et la troisième forme normale est subtile. Comme dans la troisième forme normale, nous sommes principalement concernés par la suppression des dépendances fonctionnelles sur les attributs non clés, alors qu'ici, nous sommes concernés par la suppression des dépendances fonctionnelles sur les attributs clés potentiels.

À ce stade, nos données sont déjà extrêmement normalisées, donc aller au-delà de ce point nous amène dans le domaine de la sur-normalisation, ce qui signifie une normalisation au point d'introduire des problèmes de performances sur la base de données puisque les données sont trop séparées et cloisonnées.

En pratique, ces deux dernières formes ne sont pas utilisées. En théorie, ils sont destinés à réduire encore plus le nombre d'anomalies de base de données. Si vous souhaitez approfondir les détails théoriques, voici quelques ressources utiles :

Dans la pratique courante, la première forme normale jusqu'à la forme normale de Boyce-Codd définit l'ensemble des étapes les plus couramment utilisées pour obtenir les avantages de la normalisation. Les quatrième et cinquième formes sont plus rares dans la pratique.