Moins de redondance grâce à la normalisation des bases de données
L'équipe éditoriale IONOS
La normalisation est l’un des concepts de base de la modélisation des données relationnelles. Dans le modèle de base de données relationnelle, une bonne conception de base de données se caractérise par une redondance minimale. Cela s’explique par le fait que des données redondantes entraînent des anomalies sémantiques qui, à leur tour, rendent le traitement automatique des données et la maintenance des bases de données difficiles. La normalisation est une stratégie visant à éliminer les redondances dans les bases de données relationnelles. Nous allons vous montrer comment implémenter les formes normales de base de données.
Qu’est-ce que la normalisation des bases de données ? Définition
La normalisation est une approche de conception de base de données utilisée dans les bases de données relationnelles pour éviter la redondance.
Le modèle de base de données relationnelle est le concept le plus largement utilisé dans la gestion informatisée des données. Dans les bases de données relationnelles, les informations sont stockées sous forme d’enregistrements dans des tables liées par des clés. Un enregistrement de données est constitué de plusieurs plages de valeurs qui sont affectées à des attributs spécifiques à l’aide de colonnes de table.
Le tableau suivant présente les données de facturation stockées d’un fournisseur fictif d’équipement de bureau. John Public a commandé 10 moniteurs, 12 tapis de souris et 1 chaise de bureau pour son entreprise. La commande de Jane Doe comprend 2 ordinateurs portables et 2 casques d’écoute.
Dans la base de données de la boutique en ligne, les données de facture sont attribuées au numéro de facture attribué ("Fact. N°."), à la date, au client, au numéro de client ("N°. Client"), à l’adresse, au numéro de poste de facture ("N° inventaire"), au produit, au numéro de produit ("N° produit"), à la quantité ("N°"), au prix. Chaque ligne du tableau représente un enregistrement de données. Ce type d’ensemble de données s’appelle un tuple.
La section de la base de données présentée ci-dessus est un exemple de mauvaise conception de la base de données. A première vue, il est évident que le tableau montre de nombreuses redondances. En outre, les valeurs des colonnes client et adresse contiennent des données multivaleurs. C’est ce qu’on appelle une base de données dénormalisée. En d’autres termes, il ne suit pas les règles de normalisation des bases de données.
Le principal inconvénient des bases de données dénormalisées est l’augmentation des besoins en mémoire en raison des valeurs redondantes. De plus, les attributs qui contiennent des données à valeurs multiples sont difficiles à lire et ne sont pas facilement reliés entre eux.
Exemple : Les deux clients de la section de la base de données susmentionnée sont situés à Springfield, dans le Maine. Cependant, comme ces informations ne sont pas séparées, la base de données ne peut pas être facilement filtrée par les clients du même endroit.
Afin d’éviter les plages de valeurs dupliquées et à valeurs multiples, trois formes normales séquentielles de base de données ont été développés pour les modèles de bases de données relationnelles.
Une forme normale de base de données est un état cible défini. Des exigences particulières ont été définies pour chaque forme normale, qui doivent être remplies pour que cet état cible se réalise. Une base de données correspond exactement à la première, deuxième ou troisième forme normale si toutes les conditions requises pour la forme normale correspondante sont remplies.
La normalisation est la conversion d’une table de base de données à un degré plus élevé de forme normale. La conversion à un moindre degré de forme normale est appelée dénormalisation.
Normalisation de base de données : exemples de reconfiguration
Pour illustrer la conversion d’une base de données relationnelle en la première, la deuxième et la troisième forme normale, nous passerons en revue les différentes étapes de la normalisation des bases de données relationnelles en utilisant les données du tableau ci-dessus comme exemple.
Première forme normale (1NF)
Une table dans une base de données relationnelle répond à la première forme normale (1NF) lorsqu’elle remplit les critères suivants :
- Toutes les données sont atomiques
- Toutes les colonnes du tableau contiennent des valeurs identiques
Un ensemble de données est considéré comme atomique si chaque élément d’information est affecté à un champ de données distinct.
Dans le tableau ci-dessous des données de facturation, toutes les plages de valeurs non atomiques ou ne contenant pas de données équivalentes ont été surlignées en rouge.
Comme le montrent les cellules surlignées, les données du tableau de l’exemple ne satisfont pas à l’une ou l’autre des exigences de conformité de la première forme normale.
La procédure suivante devrait être mise en œuvre pour normaliser ces sections :
- Divisez toutes les données multivaleurs en colonnes séparées.
- Vérifier la similitude des valeurs de chaque colonne.
Pour convertir les enregistrements de données de la table d’exemple en forme atomique, les zones client et adresse doivent être divisées en attributs plus spécifiques de prénom et de nom de famille, et adresse municipale, ville, état et code postal, respectivement.
Une valeur est considérée comme atomique selon le contexte de son utilisation. S’il n’est pas nécessaire de séparer le prénom et le nom de famille, le nom complet d’une personne peut être considéré comme atomique. Mais dans la pratique, il est préférable de diviser les valeurs en plusieurs parties en unités aussi petites que possible.
Les dollars et les cents figurent actuellement dans la colonne des prix. Décidez d’un format pour la devise afin de créer des plages de valeurs similaires.
Le résultat est un tableau conforme à la première forme normale, mais qui ne sera pas traité efficacement en raison des doubles valeurs. Il est alors recommandé de convertir la table à la deuxième forme normale pour éliminer les redondances.
La première forme normale prescrit des plages de valeurs atomiques et permet d’effectuer des requêtes dans la base de données. Les données qui font partie d’une plage de valeurs non atomiques ne peuvent pas être interrogées séparément.
Deuxième forme normale (2NF)
Une table conforme à la deuxième forme normale doit satisfaire à toutes les exigences de la première forme normale en plus de celles qui suivent :
- Chaque attribut non clé doit être entièrement fonctionnel, en fonction de la clé primaire.
Dans l’introduction, une base de données relationnelle est définie comme un système de tables individuelles reliées entre elles par des clés.
Les clés sont utilisées dans les bases de données relationnelles pour identifier de façon unique les enregistrements de données (tuples). Une clé qui vous permet de nommer de façon unique les lignes individuelles d’une table de base de données s’appelle une super clé. Une telle clé peut représenter les valeurs d’une seule colonne ou les valeurs combinées de plusieurs colonnes.
Dans l’exemple donné, une superclé possible résulte des attributs de numéro de facture ("Fact N°."), de numéro de client ("N° Client") et de numéro de poste de facture ("N° inventaire"), comme indiqué dans le tableau ci-dessous.
Une clé composée du numéro de facture, du numéro de client et du numéro d’article de facture avec les valeurs {124, 12, 1} permet, par exemple, de désigner clairement l’enregistrement de données qui représente l’achat de l’ordinateur portable de Jane :
Cependant, toutes les informations de la super-clé sélectionnée ne sont pas nécessaires pour une identification unique. Une combinaison du numéro de facture et du numéro de poste de facture - c’est-à-dire un sous-ensemble de la super-clé - suffirait pour identifier des enregistrements de données individuels. De telles clés avec un nombre minimum d’attributs sont appelées clés candidates ou clés alternatives.
En règle générale, un candidat clé par table est choisi pour représenter la table. La numérotation séquentielle est idéale pour cela. Une telle clé est appelée clé primaire et spécifie la séquence des enregistrements de données.
Comme n’importe quel candidat clé, la clé primaire peut être une clé en une partie ou - comme dans l’exemple donné - une clé composite. Le tableau d’échantillons utilise une clé primaire composite qui comprend le numéro de facture et le numéro de poste de facture.
Pour convertir une table de base de données en la deuxième forme normale, vous devez non seulement déterminer la clé primaire et tous les attributs non clés, mais également leur relation les uns aux autres. Suivez ces étapes :
- Vérifiez si tous les attributs non clés dépendent entièrement de la fonction de la clé primaire. Une telle dépendance n’existe que si tous les attributs clés primaires sont nécessaires pour identifier de façon unique l’attribut non clé. Cela signifie également que les tables avec clés primaires monobloc correspondent automatiquement à la deuxième forme normale si toutes les conditions préalables pour la première forme normale sont remplies.
- Déplacez tous les attributs non clés qui ne dépendent pas entièrement fonctionnellement de la clé primaire complète dans des tables séparées.
En examinant attentivement la table d’exemples, notez que les conditions préalables pour la deuxième forme normale ne sont pas remplies parce que la colonne des dates dépend uniquement du numéro de facture ("Fact. N°."), et non du numéro de poste de facture ("N° inventaire"). Il en va de même pour le prénom, le nom de famille, l’adresse, la ville, l’état et le code postal.
Pour convertir la table de données à la deuxième forme normale, tous les attributs entièrement dépendants du numéro de facture ont été déplacés vers une table séparée appelée "Facture".
Le tableau avec le solde des données a été nommé "Poste de facture".
Après normalisation, le numéro de facture ("Fact. N°") se trouve dans les deux tables et les relie entre elles. Alors que l’attribut fonctionne comme clé primaire dans la table "Facture", il est utilisé comme clé étrangère dans la table "Poste de facture" et fait également partie de la clé primaire composite de la table.
Le lien via la clé étrangère permet d’interroger les deux tables ensemble. C’est ce qu’on appelle une jointure.
Les données de l’exemple sont maintenant conformes à la deuxième forme normale. Cependant, il n’a pas encore été possible d’éliminer complètement les licenciements. Le but de la normalisation est alors habituellement la troisième forme normale.
Troisième forme normale (3NF)
Si une table doit être convertie à la troisième forme normale, toutes les conditions préalables de la première et de la deuxième forme normale doivent être remplies ainsi que les conditions suivantes :
- Aucun attribut non clé ne peut dépendre de façon transitoire d’un candidat clé.
Une dépendance transitive se produit lorsqu’un attribut non clé dépend d’un autre attribut non clé et donc indirectement de son candidat clé.
Le modèle de base de données donné viole les conditions de la troisième forme normale à plusieurs endroits :
Dans le tableau "Facture", le nom et le prénom, l’adresse, la ville, l’état et le code postal dépendent non seulement de la clé primaire (le numéro de facture), mais aussi du numéro du client.
Dans le tableau "Poste de facture", les attributs produits et prix dépendent non seulement de la clé primaire, dérivée du numéro de facture et du numéro de poste de facture, mais aussi du numéro de produit. Cette condition spécifique viole également la troisième forme normale.
Pour supprimer toutes les dépendances entre les attributs non clés, les attributs pertinents ont été déplacés dans des tables séparées, reliées entre elles par des clés étrangères. Il en résulte les quatre tableaux normalisés : "Facture", "Client", "Poste de Facture" et "Produit".
La clé primaire de la table "Facture" est un numéro de facture séquentiel. Une date de facturation et un numéro de client sont attribués à chaque numéro de facture.
Des informations plus détaillées sur chaque client sont stockées dans le tableau "Client". Les tableaux "Facture" et "Client" sont reliés par le numéro de client. Elle est utilisée comme clé primaire dans la table "Client" et comme clé étrangère dans la table "Facture".
Le tableau "Poste de facture" est un tableau central de la base de données d’échantillons, contenant des informations sur les produits qui doivent figurer sur chaque facture, ainsi que sur le nombre d’articles commandés. La clé primaire séquentielle du tableau "Poste de facture" est dérivée du numéro de facture et du numéro de poste de facture. Les produits respectifs ne sont listés que sous forme de numéros de produits qui servent de clés étrangères et relient le tableau "Poste de facture" au tableau "Produits".
Enfin, le tableau "Produits" contient des informations détaillées sur les produits respectifs, telles que la description du produit et son prix. La clé primaire est le numéro de série du produit.
Dans l’exemple, diviser deux tableaux en quatre peut ne pas sembler très efficace. En effet, les redondances dans les données de seulement deux clients sont de peu d’importance. Mais imaginez que vous voulez traiter régulièrement plusieurs centaines de milliers d’enregistrements de clients ou de produits dans une base de données relationnelle sans contradictions. Ceci n’est généralement possible qu’avec une formule de base de données qui correspond à la troisième forme normale.
Les doublons dans les bases de données relationnelles sont souvent inévitables. En examinant l’exemple au fur et à mesure que la conversion se déroule, il est évident que la liaison des tables de base de données par des clés étrangères peut être liée à des redondances. Il s’agit des redondances clés.
Même si la normalisation des bases de données nécessite un effort de programmation plus important, la troisième forme normale 3NF, est généralement considérée comme la norme pour les formules de base de données relationnelles, et n’est déviée que dans des cas exceptionnels. Par exemple, les bases de données conformes à la troisième forme normale sont parfois dénormalisées sous la deuxième forme normale. C’est parce que les jointures entre plusieurs tables prennent beaucoup de temps pour de très grandes bases de données. La dénormalisation réduit le nombre de tables et avec elle le temps de requête.
Autres formes normales
Dans la pratique, la normalisation se termine généralement par la troisième forme normale. Les formulaires normaux suivants se réfèrent à des schémas de base de données avec des conditions spéciales et ne sont ensuite utilisés que dans des cas exceptionnels.
Boyce Codd forme normale (3.5NF)
Boyce Codd forme normale est un resserrement de la troisième forme normale. Pour 3NF :
- Aucun attribut non clé ne peut dépendre de façon transitoire d’un candidat clé.
Dans Boyce Codd forme normale, cependant :
- Aucun attribut ne peut dépendre de façon transitoire d’un candidat clé à moins qu’il ne s’agisse d’une dépendance triviale.
La forme normale de Boyce Codd n’est pertinente que pour les tables de base de données avec plusieurs clés composées dans lesquelles les clés se chevauchent, c’est-à-dire si un seul et même attribut est un sous-ensemble de deux clés candidates.
Les tables de base de données conformes à la troisième forme normale sans candidats clés multiples représentent alors automatiquement la forme normale de Boyce Codd.
Le tableau ci-dessous présente deux candidats clés, chacun composé de deux attributs.
- Numéro fournisseur et numéro de produit
- Fournisseur et numéro de produit
Les deux clés permettent d’identifier chaque enregistrement de données individuel. Le seul attribut sans clé est le numéro. Étant donné que l’attribut de numéro ne dépend pas de façon transitoire de l’un des principaux candidats, le tableau est conforme à la norme 3NF.
D’autre part, il n’est pas conforme à la forme normale de Boyce Codd, car il existe une dépendance entre les attributs de numéro de fournisseur (" N° V ") et de fournisseur (" Vendeur "). L’attribut de numéro de fournisseur dépend de façon transitoire du candidat clé qui combine le numéro de fournisseur et le numéro de produit ; inversement, l’attribut de fournisseur résulte du candidat clé qui combine le numéro de fournisseur (" N° V ") et le numéro de produit ("N° article").
Les dépendances transitoires peuvent être évitées en divisant le tableau de sortie en tableaux "Nombre" et "Fournisseurs", ce qui élimine le chevauchement des candidats clés.
La forme normale de Boyce Codd empêche les redondances en identifiant les attributs clés énumérés plusieurs fois en chevauchant les candidats clés. Dans l’exemple ci-dessus, la conversion en 3.5NF empêche la duplication des valeurs dans la colonne fournisseur.
Une dépendance triviale se produit lorsqu’un attribut est complètement dépendant de lui-même sur le plan fonctionnel. Comme c’est toujours le cas pour chaque attribut dans toutes les conditions de la base de données, les dépendances triviales correspondent à la logique d’une tautologie.
Quatrième forme normale (4NF)
Une table de base de données est conforme à la quatrième forme normale si les exigences de la forme normale de Boyce Codd sont remplies en plus de ce qui suit :
- Il n’y a pas de dépendances à valeurs multiples à moins qu’elles ne soient triviales.
Une dépendance à valeurs multiples existe toujours si deux attributs non liés dépendent du même attribut, comme illustré dans l’exemple ci-dessous :
Le tableau suivant indique quels produits ont été commandés par client et à quel code postal ils doivent être livrés.
Par exemple, le client portant le numéro de client 234 a commandé les articles 1-0023-D et 2-0023-D qui doivent être livrés à son adresse au code postal 12345. Pour le client 567, les articles 1-0023-D, 3-0023-D, 4-0023-D, 4-0023-D et 5-0023-D seront livrés sous le code postal 56789.
Les enregistrements de données ne peuvent être identifiés qu’à l’aide d’une super clé résultant des trois attributs - numéro client, numéro de produit et code postal. Puisqu’il n’y a pas d’attribut non-clé, la base de données est conforme à 3NF. De plus, comme il n’y a pas de dépendances transitives non triviales, il est également conforme à la norme 3.5NF. Toutefois, il existe des dépendances à valeurs multiples : l’attribut numéro de produit et l’attribut code postal dépendent tous deux de l’attribut numéro client, mais ne sont pas liés l’un à l’autre.
L’inconvénient d’une telle conception de base de données est que chaque fois qu’un nouveau produit est ajouté à l’enregistrement du client, le code postal doit également être ajouté, ce qui entraîne des données redondantes.
Ces redondances peuvent être éliminées en convertissant le tableau en 4NF. Pour ce faire, vous devez diviser la table de telle sorte qu’il n’y ait pas ou seulement des dépendances triviales à valeurs multiples. Ceci est possible parce que le numéro de produit et le code postal ne sont en aucun cas liés.
Comme le montre l’exemple, le quatrième formulaire normal élimine la redondance causée par les dépendances à valeurs multiples, dans ce cas spécifiquement dans la colonne Code postal.
Dans cet exemple (certes quelque peu artificiel), on a supposé qu’un seul code postal s’applique pour chaque client. Toutefois, si les clients avait la possibilité de faire livrer leur produit à plusieurs endroits, il y aurait une dépendance entre le numéro de produit et le code postal, auquel cas le tableau de sortie serait déjà conforme à 4NF.
Cinquième forme normale (5NF)
Une table de base de données est conforme à la cinquième forme normale si elle satisfait aux conditions de la quatrième forme normale en plus de ce qui suit :
- Le tableau ne peut pas être divisé davantage sans perdre des informations
Vous trouverez ci-dessous un exemple illustrant un tel cas dans lequel une entreprise exploite un site Web basé sur TYPO3 et une boutique en ligne Magento. Trois employés sont responsables des projets logiciels : Mary Smith, George Miller et Joe Davis, chacun avec des qualifications différentes.
Le tableau indique la qualification du salarié qui s’applique aux exigences de tel ou tel projet logiciel.
Mary Smith utilise ses connaissances de PHP et SQL sur le projet Magento et utilise SQL et JavaScript pour le site TYPO3. George Miller travaille également avec PHP pour Magento et en JavaScript pour TYPO3. Joe Davis n’est impliqué que dans le projet TYPO3, travaillant comme seul programmeur avec PHP. Le tableau montre également que Magento nécessite des connaissances en PHP et SQL, alors que le projet TYPO3 nécessite des connaissances en PHP, SQL et JavaScript.
La table n’a qu’une seule clé composée des trois attributs, ce qui signifie qu’elle est au moins conforme aux formes normales 3NF et Boyce Codd. Puisqu’il n’y a aucune dépendance entre les trois attributs, la table est également conforme à la quatrième forme normale.
Pour vérifier si le tableau est également conforme à la norme 5NF, divisez le tableau de sortie « Qualification des employés pour le déploiement du projet » en trois tableaux : « Déploiement du projet », « Qualification du personnel » et « Exigences du projet ».
Le tableau « Déploiement de projet » indique quel collaborateur est impliqué dans quel projet logiciel.
Le tableau « Qualification de l’employé » indique quel employé maîtrise quel langage de programmation ou de base de données.
Le tableau « Exigences du projet » indique quelle qualification de programmation est requise pour quel projet.
À première vue, la section de la base de données semble beaucoup plus claire après avoir été décloisonnée. Mais les tables créées pendant la normalisation ont-elles le même contenu informationnel que la table initiale ?
Une requête de base de données jointe à travers les trois tables contient la réponse. Le résultat est surprenant.
En restructurant la table de sortie, vous pouvez supposer que chaque salarié impliqué dans le projet utilisera chacune de ses compétences, à condition que celles-ci soient requises par le projet correspondant. Cependant, en faisant cela, l’information que Joe Davis travaillait seul en programmation PHP pour le projet TYPO3 a été perdue. Cela signifie que la table de sortie ne peut pas être décomposée sans perte d’information, ce qui la rend conforme à la cinquième forme normale.
En pratique, vous rencontrerez rarement des formules de base de données qui répondent aux exigences de 4NF mais qui ne sont pas conformes au cinquième formulaire normal. Cependant, 5NF est intéressant pour les applications dans lesquelles de nouvelles informations sont obtenues à partir de données existantes.
Dans l’exemple, Mary Smith et George Miller sont tous deux compétents en PHP, et pourraient également contribuer au projet TYPO3 à l’avenir. L’entreprise pourrait utiliser cette information pour rendre plus efficace le développement de logiciels dans le cadre de ce projet.
Avantages et inconvénients de la normalisation
Le but de la normalisation est de réduire les cas de double valeur. En transférant une base de données à l’un des formulaires normaux répertoriés, le schéma cible bénéficie d’une redondance moindre que le schéma source. La normalisation facilite également la maintenance des bases de données.
D’autre part, la normalisation des bases de données implique toujours le stockage des attributs dans des tables séparées. Cela peut nécessiter l’intégration de clés étrangères, ce qui peut entraîner des redondances de clés. Le principal inconvénient, cependant, est que dans une base de données normalisée, les données logiquement liées ne sont plus stockées ensemble. Une jointure est nécessaire pour fusionner les données qui ont été divisées en différentes tables.
Les informations complexes peuvent être filtrées via des requêtes de base de données à l’aide de jointures. Cependant, les jointures sont plus complexes à mettre en œuvre que les simples requêtes. Cela prend aussi beaucoup plus de temps si les jointures sont faites en utilisant un grand nombre de tables de base de données.
