La nor­ma­li­sa­tion est l’un des concepts de base de la mo­dé­li­sa­tion des données re­la­tion­nelles. Dans le modèle de base de données re­la­tion­nelle, une bonne con­cep­tion de base de données se ca­rac­té­rise par une re­don­dance minimale. Cela s’explique par le fait que des données re­don­dantes en­traî­nent des anomalies sé­man­tiques qui, à leur tour, rendent le trai­te­ment au­to­ma­tique des données et la main­te­nance des bases de données dif­fi­ciles. La nor­ma­li­sa­tion est une stratégie visant à éliminer les re­don­dances dans les bases de données re­la­tion­nelles. Nous allons vous montrer comment im­plé­men­ter les formes normales de base de données.

Qu’est-ce que la nor­ma­li­sa­tion des bases de données ? Dé­fi­ni­tion

La nor­ma­li­sa­tion est une approche de con­cep­tion de base de données utilisée dans les bases de données re­la­tion­nelles pour éviter la re­don­dance.

Le modèle de base de données re­la­tion­nelle est le concept le plus largement utilisé dans la gestion in­for­ma­ti­sée des données. Dans les bases de données re­la­tion­nelles, les in­for­ma­tions sont stockées sous forme d’en­re­gis­tre­ments dans des tables liées par des clés. Un en­re­gis­tre­ment de données est constitué de plusieurs plages de valeurs qui sont affectées à des attributs spé­ci­fiques à l’aide de colonnes de table.

Le tableau suivant présente les données de fac­tu­ra­tion stockées d’un four­nis­seur fictif d’équi­pe­ment de bureau. John Public a commandé 10 moniteurs, 12 tapis de souris et 1 chaise de bureau pour son en­tre­prise. La commande de Jane Doe comprend 2 or­di­na­teurs portables et 2 casques d’écoute.

Image: Exemple d’une table de base de données non normalisée
Extrait d’une table de base de données non nor­ma­li­sée.

Dans la base de données de la boutique en ligne, les données de facture sont at­tri­bué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° in­ven­taire"), au produit, au numéro de produit ("N° produit"), à la quantité ("N°"), au prix. Chaque ligne du tableau re­pré­sente un en­re­gis­tre­ment 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 con­cep­tion de la base de données. A première vue, il est évident que le tableau montre de nom­breuses re­don­dances. En outre, les valeurs des colonnes client et adresse con­tien­nent des données mul­ti­va­leurs. C’est ce qu’on appelle une base de données dé­nor­ma­li­sée. En d’autres termes, il ne suit pas les règles de nor­ma­li­sa­tion des bases de données.

Le principal in­con­vé­nient des bases de données dé­nor­ma­li­sées est l’aug­men­ta­tion des besoins en mémoire en raison des valeurs re­don­dantes. De plus, les attributs qui con­tien­nent des données à valeurs multiples sont dif­fi­ciles à lire et ne sont pas fa­ci­le­ment reliés entre eux.

Exemple : Les deux clients de la section de la base de données sus­men­tion­née sont situés à Spring­field, dans le Maine. Cependant, comme ces in­for­ma­tions ne sont pas séparées, la base de données ne peut pas être fa­ci­le­ment filtrée par les clients du même endroit.

Afin d’éviter les plages de valeurs du­pli­quées et à valeurs multiples, trois formes normales sé­quen­tielles de base de données ont été dé­ve­lop­pés pour les modèles de bases de données re­la­tion­nelles.

Une forme normale de base de données est un état cible défini. Des exigences par­ti­cu­liè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 cor­res­pond exac­te­ment à la première, deuxième ou troisième forme normale si toutes les con­di­tions requises pour la forme normale cor­res­pon­dante sont remplies.

Remarque

La nor­ma­li­sa­tion est la con­ver­sion d’une table de base de données à un degré plus élevé de forme normale. La con­ver­sion à un moindre degré de forme normale est appelée dé­nor­ma­li­sa­tion.

Nor­ma­li­sa­tion de base de données : exemples de re­con­fi­gu­ra­tion

Pour illustrer la con­ver­sion d’une base de données re­la­tion­nelle en la première, la deuxième et la troisième forme normale, nous passerons en revue les dif­fé­rentes étapes de la nor­ma­li­sa­tion des bases de données re­la­tion­nelles en utilisant les données du tableau ci-dessus comme exemple.

Première forme normale (1NF)

Une table dans une base de données re­la­tion­nelle 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 con­tien­nent des valeurs iden­tiques

Un ensemble de données est considéré comme atomique si chaque élément d’in­for­ma­tion est affecté à un champ de données distinct.

Dans le tableau ci-dessous des données de fac­tu­ra­tion, toutes les plages de valeurs non atomiques ou ne contenant pas de données équi­va­lentes ont été sur­lig­nées en rouge.

Comme le montrent les cellules sur­lig­nées, les données du tableau de l’exemple ne satisfont pas à l’une ou l’autre des exigences de con­for­mité de la première forme normale.

La procédure suivante devrait être mise en œuvre pour nor­ma­li­ser ces sections :

  1. Divisez toutes les données mul­ti­va­leurs en colonnes séparées.
  2. Vérifier la si­mi­li­tude des valeurs de chaque colonne.

Pour convertir les en­re­gis­tre­ments de données de la table d’exemple en forme atomique, les zones client et adresse doivent être divisées en attributs plus spé­ci­fiques de prénom et de nom de famille, et adresse mu­ni­ci­pale, ville, état et code postal, res­pec­ti­ve­ment.

Note

Une valeur est con­si­dé­rée comme atomique selon le contexte de son uti­li­sa­tion. S’il n’est pas né­ces­saire 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 ac­tuel­le­ment dans la colonne des prix. Décidez d’un format pour la devise afin de créer des plages de valeurs si­mi­laires.

Le résultat est un tableau conforme à la première forme normale, mais qui ne sera pas traité ef­fi­ca­ce­ment en raison des doubles valeurs. Il est alors re­com­mandé de convertir la table à la deuxième forme normale pour éliminer les re­don­dances.

Conseil

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 in­ter­ro­gées sé­pa­ré­ment.

Deuxième forme normale (2NF)

Une table conforme à la deuxième forme normale doit sa­tis­faire à toutes les exigences de la première forme normale en plus de celles qui suivent :

  • Chaque attribut non clé doit être en­tiè­re­ment fonc­tion­nel, en fonction de la clé primaire.

Dans l’in­tro­duc­tion, une base de données re­la­tion­nelle est définie comme un système de tables in­di­vi­duelles reliées entre elles par des clés.

Les clés sont utilisées dans les bases de données re­la­tion­nelles pour iden­ti­fier de façon unique les en­re­gis­tre­ments de données (tuples). Une clé qui vous permet de nommer de façon unique les lignes in­di­vi­duelles d’une table de base de données s’appelle une super clé. Une telle clé peut re­pré­sen­ter 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° in­ven­taire"), 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 clai­re­ment l’en­re­gis­tre­ment de données qui re­pré­sente l’achat de l’or­di­na­teur portable de Jane :

Cependant, toutes les in­for­ma­tions de la super-clé sé­lec­tion­née ne sont pas né­ces­saires pour une iden­ti­fi­ca­tion unique. Une com­bi­nai­son 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 iden­ti­fier des en­re­gis­tre­ments de données in­di­vi­duels. De telles clés avec un nombre minimum d’attributs sont appelées clés can­di­dates ou clés al­ter­na­tives.

En règle générale, un candidat clé par table est choisi pour re­pré­sen­ter la table. La nu­mé­ro­ta­tion sé­quen­tielle est idéale pour cela. Une telle clé est appelée clé primaire et spécifie la séquence des en­re­gis­tre­ments 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’échan­til­lons 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é­ter­mi­ner la clé primaire et tous les attributs non clés, mais également leur relation les uns aux autres. Suivez ces étapes :

  1. Vérifiez si tous les attributs non clés dépendent en­tiè­re­ment de la fonction de la clé primaire. Une telle dé­pen­dance n’existe que si tous les attributs clés primaires sont né­ces­saires pour iden­ti­fier de façon unique l’attribut non clé. Cela signifie également que les tables avec clés primaires monobloc cor­res­pon­dent au­to­ma­ti­que­ment à la deuxième forme normale si toutes les con­di­tions préa­lables pour la première forme normale sont remplies.
  2. Déplacez tous les attributs non clés qui ne dépendent pas en­tiè­re­ment fonc­tion­nel­le­ment de la clé primaire complète dans des tables séparées.

En examinant at­ten­ti­ve­ment la table d’exemples, notez que les con­di­tions préa­lables pour la deuxième forme normale ne sont pas remplies parce que la colonne des dates dépend uni­que­ment du numéro de facture ("Fact. N°."), et non du numéro de poste de facture ("N° in­ven­taire"). 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 en­tiè­re­ment dé­pen­dants 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 nor­ma­li­sa­tion, le numéro de facture ("Fact. N°") se trouve dans les deux tables et les relie entre elles. Alors que l’attribut fonc­tionne 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.

Note

Le lien via la clé étrangère permet d’in­ter­ro­ger les deux tables ensemble. C’est ce qu’on appelle une jointure.

Les données de l’exemple sont main­te­nant conformes à la deuxième forme normale. Cependant, il n’a pas encore été possible d’éliminer com­plè­te­ment les li­cen­cie­ments. Le but de la nor­ma­li­sa­tion est alors ha­bi­tuel­le­ment la troisième forme normale.

Troisième forme normale (3NF)

Si une table doit être convertie à la troisième forme normale, toutes les con­di­tions préa­lables de la première et de la deuxième forme normale doivent être remplies ainsi que les con­di­tions suivantes :

  • Aucun attribut non clé ne peut dépendre de façon tran­si­toire d’un candidat clé.

Une dé­pen­dance tran­si­tive se produit lorsqu’un attribut non clé dépend d’un autre attribut non clé et donc in­di­rec­te­ment de son candidat clé.

Le modèle de base de données donné viole les con­di­tions 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é­ci­fique viole également la troisième forme normale.

Pour supprimer toutes les dé­pen­dances entre les attributs non clés, les attributs per­ti­nents ont été déplacés dans des tables séparées, reliées entre elles par des clés étran­gères. Il en résulte les quatre tableaux nor­ma­li­sés : "Facture", "Client", "Poste de Facture" et "Produit".

La clé primaire de la table "Facture" est un numéro de facture sé­quen­tiel. Une date de fac­tu­ra­tion et un numéro de client sont attribués à chaque numéro de facture.

Des in­for­ma­tions plus dé­tail­lé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’échan­til­lons, contenant des in­for­ma­tions sur les produits qui doivent figurer sur chaque facture, ainsi que sur le nombre d’articles commandés. La clé primaire sé­quen­tielle du tableau "Poste de facture" est dérivée du numéro de facture et du numéro de poste de facture. Les produits res­pec­tifs ne sont listés que sous forme de numéros de produits qui servent de clés étran­gères et relient le tableau "Poste de facture" au tableau "Produits".

Enfin, le tableau "Produits" contient des in­for­ma­tions dé­tail­lées sur les produits res­pec­tifs, telles que la des­crip­tion 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 re­don­dances dans les données de seulement deux clients sont de peu d’im­por­tance. Mais imaginez que vous voulez traiter ré­gu­liè­re­ment plusieurs centaines de milliers d’en­re­gis­tre­ments de clients ou de produits dans une base de données re­la­tion­nelle sans con­tra­dic­tions. Ceci n’est gé­né­ra­le­ment possible qu’avec une formule de base de données qui cor­res­pond à la troisième forme normale.

Note

Les doublons dans les bases de données re­la­tion­nelles sont souvent iné­vi­tables. En examinant l’exemple au fur et à mesure que la con­ver­sion se déroule, il est évident que la liaison des tables de base de données par des clés étran­gères peut être liée à des re­don­dances. Il s’agit des re­don­dances clés.

Même si la nor­ma­li­sa­tion des bases de données nécessite un effort de pro­gram­ma­tion plus important, la troisième forme normale 3NF, est gé­né­ra­le­ment con­si­dé­rée comme la norme pour les formules de base de données re­la­tion­nelles, et n’est déviée que dans des cas ex­cep­tion­nels. Par exemple, les bases de données conformes à la troisième forme normale sont parfois dé­nor­ma­li­sé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é­nor­ma­li­sa­tion réduit le nombre de tables et avec elle le temps de requête.

Autres formes normales

Dans la pratique, la nor­ma­li­sa­tion se termine gé­né­ra­le­ment par la troisième forme normale. Les for­mu­laires normaux suivants se réfèrent à des schémas de base de données avec des con­di­tions spéciales et ne sont ensuite utilisés que dans des cas ex­cep­tion­nels.

Boyce Codd forme normale (3.5NF)

Boyce Codd forme normale est un res­ser­re­ment de la troisième forme normale. Pour 3NF :

  • Aucun attribut non clé ne peut dépendre de façon tran­si­toire d’un candidat clé.

Dans Boyce Codd forme normale, cependant :

  • Aucun attribut ne peut dépendre de façon tran­si­toire d’un candidat clé à moins qu’il ne s’agisse d’une dé­pen­dance triviale.

La forme normale de Boyce Codd n’est per­ti­nente que pour les tables de base de données avec plusieurs clés composées dans les­quelles les clés se che­vauchent, c’est-à-dire si un seul et même attribut est un sous-ensemble de deux clés can­di­dates.

Les tables de base de données conformes à la troisième forme normale sans candidats clés multiples re­pré­sen­tent alors au­to­ma­ti­que­ment la forme normale de Boyce Codd.

Le tableau ci-dessous présente deux candidats clés, chacun composé de deux attributs.

  • Numéro four­nis­seur et numéro de produit
  • Four­nis­seur et numéro de produit

Les deux clés per­met­tent d’iden­ti­fier chaque en­re­gis­tre­ment de données in­di­vi­duel. Le seul attribut sans clé est le numéro. Étant donné que l’attribut de numéro ne dépend pas de façon tran­si­toire de l’un des prin­ci­paux 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é­pen­dance entre les attributs de numéro de four­nis­seur (" N° V ") et de four­nis­seur (" Vendeur "). L’attribut de numéro de four­nis­seur dépend de façon tran­si­toire du candidat clé qui combine le numéro de four­nis­seur et le numéro de produit ; in­ver­se­ment, l’attribut de four­nis­seur résulte du candidat clé qui combine le numéro de four­nis­seur (" N° V ") et le numéro de produit ("N° article").

Les dé­pen­dances tran­si­toires peuvent être évitées en divisant le tableau de sortie en tableaux "Nombre" et "Four­nis­seurs", ce qui élimine le che­vau­che­ment des candidats clés.

La forme normale de Boyce Codd empêche les re­don­dances en iden­ti­fiant les attributs clés énumérés plusieurs fois en che­vau­chant les candidats clés. Dans l’exemple ci-dessus, la con­ver­sion en 3.5NF empêche la du­pli­ca­tion des valeurs dans la colonne four­nis­seur.

Note

Une dé­pen­dance triviale se produit lorsqu’un attribut est com­plè­te­ment dépendant de lui-même sur le plan fonc­tion­nel. Comme c’est toujours le cas pour chaque attribut dans toutes les con­di­tions de la base de données, les dé­pen­dances triviales cor­res­pon­dent à la logique d’une tau­to­lo­gie.

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é­pen­dances à valeurs multiples à moins qu’elles ne soient triviales.

Une dé­pen­dance à 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 en­re­gis­tre­ments de données ne peuvent être iden­ti­fié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é­pen­dances tran­si­tives non triviales, il est également conforme à la norme 3.5NF. Toutefois, il existe des dé­pen­dances à 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’in­con­vé­nient d’une telle con­cep­tion de base de données est que chaque fois qu’un nouveau produit est ajouté à l’en­re­gis­tre­ment du client, le code postal doit également être ajouté, ce qui entraîne des données re­don­dantes.

Ces re­don­dances peuvent être éliminées en con­ver­tis­sant 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é­pen­dances 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 for­mu­laire normal élimine la re­don­dance causée par les dé­pen­dances à valeurs multiples, dans ce cas spé­ci­fi­que­ment dans la colonne Code postal.

Note

Dans cet exemple (certes quelque peu ar­ti­fi­ciel), on a supposé qu’un seul code postal s’applique pour chaque client. Toutefois, si les clients avait la pos­si­bi­lité de faire livrer leur produit à plusieurs endroits, il y aurait une dé­pen­dance 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 con­di­tions de la quatrième forme normale en plus de ce qui suit :

  • Le tableau ne peut pas être divisé davantage sans perdre des in­for­ma­tions

Vous trouverez ci-dessous un exemple il­lus­trant un tel cas dans lequel une en­tre­prise exploite un site Web basé sur TYPO3 et une boutique en ligne Magento. Trois employés sont res­pon­sables des projets logiciels : Mary Smith, George Miller et Joe Davis, chacun avec des qua­li­fi­ca­tions dif­fé­rentes.

Le tableau indique la qua­li­fi­ca­tion du salarié qui s’applique aux exigences de tel ou tel projet logiciel.

Mary Smith utilise ses con­nais­sances de PHP et SQL sur le projet Magento et utilise SQL et Ja­vaS­cript pour le site TYPO3. George Miller travaille également avec PHP pour Magento et en Ja­vaS­cript pour TYPO3. Joe Davis n’est impliqué que dans le projet TYPO3, tra­vail­lant comme seul pro­gram­meur avec PHP. Le tableau montre également que Magento nécessite des con­nais­sances en PHP et SQL, alors que le projet TYPO3 nécessite des con­nais­sances en PHP, SQL et Ja­vaS­cript.

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é­pen­dance 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 « Qua­li­fi­ca­tion des employés pour le dé­ploie­ment du projet » en trois tableaux : « Dé­ploie­ment du projet », « Qua­li­fi­ca­tion du personnel » et « Exigences du projet ».

Le tableau « Dé­ploie­ment de projet » indique quel col­la­bo­ra­teur est impliqué dans quel projet logiciel.

Le tableau « Qua­li­fi­ca­tion de l’employé » indique quel employé maîtrise quel langage de pro­gram­ma­tion ou de base de données.

Le tableau « Exigences du projet » indique quelle qua­li­fi­ca­tion de pro­gram­ma­tion 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é­cloi­son­née. Mais les tables créées pendant la nor­ma­li­sa­tion ont-elles le même contenu in­for­ma­tion­nel 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 sur­pre­nant.

En res­truc­tu­rant la table de sortie, vous pouvez supposer que chaque salarié impliqué dans le projet utilisera chacune de ses com­pé­tences, à condition que celles-ci soient requises par le projet cor­res­pon­dant. Cependant, en faisant cela, l’in­for­ma­tion que Joe Davis tra­vail­lait seul en pro­gram­ma­tion PHP pour le projet TYPO3 a été perdue. Cela signifie que la table de sortie ne peut pas être dé­com­po­sée sans perte d’in­for­ma­tion, ce qui la rend conforme à la cinquième forme normale.

En pratique, vous ren­con­tre­rez rarement des formules de base de données qui répondent aux exigences de 4NF mais qui ne sont pas conformes au cinquième for­mu­laire normal. Cependant, 5NF est in­té­res­sant pour les ap­pli­ca­tions dans les­quelles de nouvelles in­for­ma­tions sont obtenues à partir de données exis­tantes.

Dans l’exemple, Mary Smith et George Miller sont tous deux com­pé­tents en PHP, et pour­raient également con­tri­buer au projet TYPO3 à l’avenir. L’en­tre­prise pourrait utiliser cette in­for­ma­tion pour rendre plus efficace le dé­ve­lop­pe­ment de logiciels dans le cadre de ce projet.

Avantages et in­con­vé­nients de la nor­ma­li­sa­tion

Le but de la nor­ma­li­sa­tion est de réduire les cas de double valeur. En trans­fé­rant une base de données à l’un des for­mu­laires normaux ré­per­to­riés, le schéma cible bénéficie d’une re­don­dance moindre que le schéma source. La nor­ma­li­sa­tion facilite également la main­te­nance des bases de données.

D’autre part, la nor­ma­li­sa­tion des bases de données implique toujours le stockage des attributs dans des tables séparées. Cela peut né­ces­si­ter l’in­té­gra­tion de clés étran­gères, ce qui peut entraîner des re­don­dances de clés. Le principal in­con­vé­nient, cependant, est que dans une base de données nor­ma­li­sée, les données lo­gi­que­ment liées ne sont plus stockées ensemble. Une jointure est né­ces­saire pour fusionner les données qui ont été divisées en dif­fé­rentes tables.

Les in­for­ma­tions 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.

Aller au menu principal