Formes normales de la base de données

3.1 Normalisation de la base de données

La forme normale est une propriété d'une relation dans un modèle de données relationnel qui la caractérise en termes de redondance, conduisant potentiellement à des résultats logiquement erronés d'échantillonnage ou de modification des données. La forme normale est définie comme l'ensemble des exigences qu'une relation (tables dans une base de données) doit satisfaire.

Le processus de conversion des relations de base de données en une forme conforme aux formes normales est appelé normalisation. La normalisation vise à amener la structure de la base de données sous une forme qui fournit une redondance logique minimale et n'est pas destinée à réduire ou à augmenter les performances, ni à réduire ou à augmenter le volume physique de la base de données .

Le but ultime de la normalisation est de réduire l'incohérence potentielle des informations stockées dans la base de données. L'objectif général du processus de normalisation est le suivant :

• exclusion de certains types de licenciements ;
• corriger certaines anomalies de mise à jour ;
• développement d'un projet de base de données qui soit une représentation suffisamment « qualitative » du monde réel, soit intuitive et puisse servir de bonne base pour une extension ultérieure ;
• simplifier la procédure d'application des contraintes d'intégrité nécessaires.

La redondance est généralement éliminée en décomposant les relations de manière à ce que seuls les faits primaires soient stockés dans chaque relation (c'est-à-dire les faits qui ne sont pas dérivés d'autres faits stockés).

Bien que les idées de normalisation soient très utiles pour la conception de bases de données, elles ne constituent en aucun cas un moyen universel ou exhaustif d'améliorer la qualité d'une conception de base de données. Cela est dû au fait qu'il existe une trop grande variété d'erreurs et de lacunes possibles dans la structure de la base de données qui ne peuvent pas être éliminées par la normalisation.

Malgré ces considérations, la théorie de la normalisation est une réalisation très précieuse de la théorie et de la pratique relationnelles, car elle fournit des critères scientifiquement rigoureux et raisonnables pour la qualité d'un projet de base de données et des méthodes formelles pour améliorer cette qualité. Cela distingue la théorie de la normalisation des approches de conception purement empiriques proposées dans d'autres modèles de données. De plus, on peut affirmer que dans tout le domaine des technologies de l'information, il n'existe pratiquement aucune méthode d'évaluation et d'amélioration des solutions de conception comparable à la théorie de la normalisation des bases de données relationnelles en termes de niveau de rigueur formelle.

La normalisation est parfois critiquée au motif que "c'est juste du bon sens" et que tout professionnel compétent concevra "naturellement" une base de données entièrement normalisée sans avoir à appliquer la théorie de la dépendance.

Cependant, comme l'a noté le professeur Christopher Date, la normalisation est précisément les principes de bon sens qui guident un concepteur mature dans son esprit, c'est-à-dire que les principes de normalisation sont formalisés du bon sens . Pendant ce temps, identifier et formaliser les principes du bon sens est une tâche très difficile, et réussir à la résoudre est une réalisation importante.

3.2 Première forme normale

La première forme normale (1NF) est la forme normale de base d'une relation dans le modèle de données relationnel.

Une variable de relation est en première forme normale si et seulement si, dans toute valeur valide de cette variable, chaque tuple de relation contient exactement une valeur pour chacun des attributs.

Dans un modèle relationnel, une relation est toujours en première forme normale, par définition du concept de relation.

Quant aux différentes tables, elles peuvent ne pas être des représentations correctes des relations et, par conséquent, peuvent ne pas être en 1NF. Selon la définition de Christopher Date pour un tel cas, une table est normalisée (de manière équivalente, est sous sa première forme normale) si et seulement si elle est une représentation directe et vraie d'une relation. Plus précisément, le tableau en question doit satisfaire aux cinq conditions suivantes :

• Il n'y a pas d'ordre des lignes de haut en bas (en d'autres termes, l'ordre des lignes ne transmet aucune information).
• Il n'y a pas d'ordre de gauche à droite des colonnes (en d'autres termes, l'ordre des colonnes ne contient aucune information).
• Pas de lignes en double.
• Chaque intersection d'une ligne et d'une colonne contient exactement une valeur du domaine correspondant (et rien d'autre).
• Toutes les colonnes sont "régulières".

La "régularité" de toutes les colonnes d'une table signifie qu'il n'y a pas de composants "cachés" dans la table auxquels on ne peut accéder que par l'invocation d'un opérateur spécial au lieu de faire référence à des noms de colonnes réguliers, ou qui entraînent des effets secondaires pour les lignes ou des tables lors de l'appel d'opérateurs standard.

La table originale non normalisée (c'est-à-dire pas une représentation correcte d'une relation) :

Une table réduite à 1NF, qui est la représentation correcte d'une relation :

3.3 Deuxième forme normale

Une variable de relation est en seconde forme normale si et seulement si elle est en première forme normale et que chaque attribut non-clé dépend irréductiblement de (chaque) sa clé candidate .

L'irréductibilité signifie que la clé potentielle ne contient pas un plus petit sous-ensemble d'attributs à partir desquels cette dépendance fonctionnelle peut également être dérivée. Pour une dépendance fonctionnelle irréductible, le concept équivalent de « dépendance fonctionnelle complète » est souvent utilisé.

Si la clé candidate est simple, c'est-à-dire qu'elle consiste en un seul attribut, alors toute dépendance fonctionnelle à son égard est irréductible (complète). Si la clé candidate est une clé composite, alors, selon la définition de la deuxième forme normale, il ne doit pas y avoir d'attributs non clés dans la relation qui dépendent d'une partie de la clé candidate composite.

Un exemple de conversion d'une relation en deuxième forme normale

Soit le couple d'attributs {Direction de l'entreprise, Position} forme la clé primaire dans la relation suivante :

Disons que le salaire dépend de la branche et du poste, et que la disponibilité d'un ordinateur ne dépend que du poste.

Il existe une dépendance fonctionnelle Position -> Avoir un ordinateur, dans lequel le côté gauche (déterminant) n'est qu'une partie de la clé primaire, ce qui viole la condition de la deuxième forme normale.

Pour réduire à 2NF, la relation d'origine doit être décomposée en deux relations :

3.4 Troisième forme normale (3NF)

Une variable de relation R est dans 3NF si et seulement si les conditions suivantes sont vraies :

• Rest en seconde forme normale.
• aucun attribut non cléRn'est pas en dépendance fonctionnelle transitive de la clé candidateR.

Explications de la définition :

Un attribut non clé d'une relation R est un attribut qui n'appartient à aucune des clés candidates de R.

La dépendance fonctionnelle de l'ensemble d'attributs Z sur l'ensemble d'attributs X (noté X → Z, prononcé « x détermine z ») est transitive s'il existe un ensemble d'attributs Y tel que X → Y et Y → Z. Dans ce cas, aucun des ensembles X, Y et Z n'est un sous-ensemble de l'autre, c'est-à-dire que les dépendances fonctionnelles X → Z, X → Y et Y → Z ne sont pas triviales, et il n'y a pas non plus de dépendance fonctionnelle Y → X.

Une définition de 3NF, équivalente à celle de Codd mais formulée différemment, a été donnée par Carlo Zaniolo en 1982. Selon elle, une variable de relation est en 3NF si et seulement si chacune de ses dépendances fonctionnelles X → A satisfait au moins une des conditions suivantes :

• X contient A (c'est-à-dire que X → A est une dépendance fonctionnelle triviale)
• X - super clé
• A est un attribut de clé (c'est-à-dire que A fait partie d'une clé candidate).

La définition de Zaniolo définit clairement la différence entre 3NF et la forme normale Boyce-Codd (BCNF) plus stricte : BCNF exclut la troisième condition ("A est un attribut clé").

Un résumé mémorable et traditionnellement descriptif de la définition 3NF de Codd a été donné par Bill Kent : chaque attribut non clé "devrait fournir des informations sur la clé, la clé complète et rien que la clé ".

La condition de dépendre de la "clé complète" des attributs non clés garantit que la relation est sous la deuxième forme normale ; et la condition pour qu'ils ne dépendent de "rien d'autre que la clé" est qu'ils soient en troisième forme normale.

Chris Date parle du résumé de Kent comme d'une « caractéristique intuitivement attrayante » de 3NF, et observe qu'avec une légère modification, il peut également servir de définition de la forme normale plus stricte de Boyce-Codd : « chaque attribut doit fournir des informations sur une clé , une clé complète et rien d'autre que la clé.

La version de Kent de la définition 3NF est moins stricte que la version de forme normale Boyce-Codd de la formulation de Data, car la première indique uniquement que les attributs non clés dépendent des clés.

Les attributs primaires (qui sont des clés ou des parties de celles-ci) n'ont pas du tout besoin d'être fonctionnellement dépendants ; chacun d'eux fournit des informations sur la clé en fournissant la clé elle-même ou une partie de celle-ci. Il convient de noter ici que cette règle n'est valable que pour les attributs non clés, car l'appliquer à tous les attributs désactivera complètement toutes les clés alternatives complexes, puisque chaque élément d'une telle clé violera la condition "clé complète".

Considérons la variable de relation R1 comme exemple :

Chaque employé appartient exclusivement à un département ; chaque département dispose d'un seul téléphone. L'attribut Employé est la clé primaire. Les employés n'ont pas de téléphone personnel et le numéro de téléphone de l'employé dépend uniquement du service.

Dans l'exemple, les dépendances fonctionnelles suivantes existent : Employé → Service, Service → Téléphone, Employé → Téléphone.

La variable de relation R1 est en seconde forme normale car chaque attribut a une dépendance fonctionnelle irréductible à la clé potentielle Employé.

La relation Employé → Téléphone est transitive, donc la relation n'est pas en troisième forme normale.

Le fractionnement de R1 donne deux variables de relation qui sont dans 3NF :

La relation initiale R1, si nécessaire, s'obtient aisément par suite de l'opération de jonction des relations R2 et R3.