Bases de données relationnelles et normalisation :
de la première à la sixième forme normale

N.B. R* représente l'en-tête de la relvar R. « Δ  σ » se lit ainsi : Δ implique logiquement σ, ou encore σ est une conséquence logique de Δ. Par ailleurs une dépendance de clé est une dépendance fonctionnelle K ➔ X vérifiée par R, telle que X représente l'ensemble des attributs de R : K est donc une clé de R.


Pour en revenir à la relvar Administrer dans sa version « complétée » (cf. Figure 5.5) :

Comme aucun des sous-ensembles {IngId, SgbdId}, {IngId, CliId} et {SgbdId, CliId} de la DJ ne contient K, la relvar ne respecte pas la 5NF. Normaliser consiste alors à la remplacer par ses projections {IngId, SgbdId}, {IngId, CliId} et {SgbdId, CliId}. Comme on dispose déjà des relvars Maitriser, Affecter et Utiliser qui en sont des sur-ensembles, on se contentera d'éliminer purement et simplement la relvar Administrer, comme dans le cas de la Figure 5.6.

Si malgré tout on devait conserver cette relvar, toujours eu égard à la 9e des 12 règles de Codd, ça devrait être seulement sous forme de vue. Par exemple, en Tutorial D :

         VAR Administrer VIRTUAL (JOIN {Maitriser, Utiliser, Affecter})
                                  KEY {IngId, SgbdId, CliId)} ;

Si le chef n'aime pas les vues (ça arrive) et qu'il faille donc mettre en œuvre Administrer sous forme d'une relvar de base, alors il deviendrait indispensable de mettre en œuvre une contrainte pour s'assurer de la pérennité de la DJ non triviale :

          ★{{IngId, SgbdId}, {SgbdId, CliId}, {CliId, IngId}}

En Tutorial D :

         CONSTRAINT Administrer_Contrainte_01
                  Administrer = JOIN {Maitriser, Utiliser, Affecter} ;

En SQL, il faudrait en passer par une assertion (ou des triggers si le SGBD ne connaît pas les assertions).

On vient de voir que la relvar Administrer « complétée » ne respecte pas la 5NF (alors qu'elle respecte la 4NF), conséquence de la mise en application de la règle de gestion selon laquelle « Si un ingénieur maîtrise un SGBD utilisé par un client chez qui il affecté, alors cet ingénieur administre ce SGBD chez ce client ». En revanche, tant que cette règle n'existait pas (cf. Figure 5.1 et suivantes), la relvar Administrer respectait la 5NF. En effet, la jointure de ses projections avait pour résultat une relation comportant un corps étranger (cf. Figure 5.4), à savoir le tuple <Philou, Adabas, HAL> ne figurant pas dans la relation Administrer de la Figure 5.3 :
la DJ  ★{{IngId, SgbdId}, {SgbdId, CliId}, {CliId, IngId}} n'existait pas.

Pour leur part, les relvars Maitriser, Affecter et Utiliser dont on a des instantanés dans la Figure 5.3 respectent la 5NF. Prenons le cas de la relvar Maitriser :
la seule DJ qu'elle comporte  ★{{IngId, SgbdId}} est triviale puisque l'en-tête de la relvar est la paire {IngId, SgbdId} (qui représente aussi la seule clé de la relvar).
Ce qui vaut pour Maitriser vaut aussi pour Affecter et Utiliser, mutatis mutandis.

Autre exemple : considérons la relvar FPV étudiée notamment aux paragraphes 3.2.2 et 3.3.3. Elle satisfait à la DJ  ★{FV, FPQ} puisqu'elle est égale à la jointure des relvars FV et FPQ (cf. paragraphe 3.3.3). Elle a pour seule clé la paire {Four_No, Piece_No}, paire qui n'appartient pas à FV, en conséquence de quoi FPV ne respecte pas la 5NF (on savait du reste qu'elle ne respecte même pas la 2NF, cf. paragraphe 3.4.2).

En revanche, la relvar FV {Four_No, Ville} ayant pour clé {Four_No} n'est pas décomposable sans perte, et a pour seule DJ  ★{{Four_No, Ville}} laquelle est triviale (tout en notant que la clé {Four_No} est évidemment incluse dans {Four_No, Ville}). La relvar FV respecte la 5NF.

De même (toujours au paragraphe 3.3.3), la relvar FPQ {Four_No, Piece_No, Quantite} ayant pour clé {Four_No, Piece_No} n'est pas décomposable sans perte.
Elle a pour seule DJ  ★{{Four_No, Piece_No, Quantite}} laquelle est triviale : la relvar respecte donc la 5NF.

Prenons un autre exemple, celui d'une relvar en 2NF mais pas en 3NF. Soit la relvar suivante :

        Salarie {SalId, EntId, EntNom}              (clé soulignée)

L'attribut SalId représente l'identifiant (au sens Merise) d'un salarié, EntId représente l'identifiant de l'entreprise de ce salarié et EntNom le nom de cette entreprise.

Les DF sont les suivantes :

         DF1    {SalId} ➔ {EntId, EntNom}

         DF2    {EntId} ➔ {EntNom}

Par application du théorème de Heath et de la règle de Rissanen de préservation des dépendances (cf. paragraphe 3.3.2), la relvar Salarie peut être décomposée sans perte selon les projections :

         {SalId, EntId}              (clé soulignée)

         {EntId, EntNom}          (clé soulignée)

Étant décomposable sans perte, la relvar Salarie satisfait à la DJ non triviale  ★{{SalId, EntId}, {EntId, EntNom}}. Elle a pour unique clé {SalId}, et comme le sous-ensemble {EntId, EntNom} n'est pas clé de la relvar, celle-ci ne respecte pas la 5NF.

Encore un exemple, celui d'une relvar respectant la BCNF mais pas la 4NF. Soit la relvar ISPV de la Figure 4.3 et décortiquée notamment dans les paragraphes 4.3 et 4.7 :

         ISPV {IngId, SgbdId, ProjId, Annee}

ISPV a pour seule clé {IngId, SgbdId, ProjId, Annee}.

Elle comporte les DMV {IngId} ➔➔ {SgbdId} et {IngId} ➔➔ {ProjId, Annee}.

ISPV satisfait donc à la DJ  ★{{IngId, SgbdId}, {IngId, ProjId, Annee}}, Or, ni {IngId, SgbdId} ni {IngId, ProjId, Annee} ne sont clés de ISPV : cette relvar ne respecte pas la 5NF (comme on l'a rappelé, elle ne respectait déjà pas la 4NF).

Fagin fournit un parallèle très intéressant et élégant entre la BCNF, la 4NF et la 5NF. Date l'a résumé ainsi ([Date 2004]) :

 

Ce théorème de Date et Fagin (théorème 4.1) est utile, il permet en effet de restreindre la liste des relvars à vérifier, puisque celles dont les clés sont seulement mono-attributs et qui sont en 3NF sont de facto en 5NF...

Encore un théorème en passant (cf. [Date 2009] page 296) :

5.9. Pour conclure avec la normalisation en 5NF

De la gestion de données intervallaires, disons temporelles et qui intéressent la 6NF (cf. paragraphe 6) ;

De l'optimisation (cf. paragraphe 1.7) : par exemple, certains attributs de cette relvar sont seulement consultés par une population X d'utilisateurs, tandis que d'autres attributs sont mis à jour par une population différente Y d'utilisateurs, et les contentions qui en résultent sont pénalisantes pour les premiers, ce qui amène en l'occurrence à encore décomposer des structures qui sont déjà en 5NF (dans le sens de la 6NF soit dit en passant).

5.10. Un petit exercice

« Les Quatrième et Cinquième Formes Normales ne sont pas incluses dans la Troisième Forme Normale »      « Tous les auteurs affirment que ces deux dernières Formes Normales sont incluses dans la Troisième, prolongeant de façon mécanique la série d'inclusion entre les Troisième, Deuxième et Première Formes Normales. Nous allons montrer que cette affirmation est fausse, car elle gêne énormément la compréhension des Quatrième et Cinquième Formes Normales.      S'il est exact que la Troisième Forme Normale est incluse dans la Deuxième et elle-même dans la Première, le simple bon sens permet de voir que la Quatrième n'est pas incluse dans la Troisième.      En effet, les trois premières Formes Normales sont fondées sur les Dépendances Fonctionnelles alors que la Quatrième (comme la Cinquième) s'appuie sur les Dépendances Multivaluées. Or, la Dépendance Fonctionnelle est un cas particulier de la Dépendances Multivaluée. On peut donc considérer qu'elle est incluse dans dans cette dernière, mais en aucun cas l'inverse. Donc la Quatrième Forme Normale ne peut être incluse dans la Troisième ; tout au plus pourrait-on admettre l'inverse : que la Troisième soit incluse dans la Quatrième. » ... (Au passage une critique à l'endroit des chercheurs (cf. paragraphe 2.8), puis reprise des explications.)      « En fait un Tableau en Quatrième Forme Normale n'est pas en Troisième Forme Normale, ni même en Deuxième, tout simplement parce qu'il n'est pas en Première Forme Normale. En effet, la condition essentielle pour qu'un Tableau soit en Première Forme Normale est l'existence d'une Clef.      Une Clef est une Colonne ou un groupe de Colonnes identifiant toutes les autres de façon unique, c'est-à-dire qu'elle est à l'origine des Dépendances Fonctionnelles. Or, dans un tableau en Quatrième Forme Normale, il n'existe aucune Dépendance Fonctionnelle, seulement une Dépendance Multivaluée.      Il n'y a pas de Clef dans un Tableau en Quatrième Forme Normale, et celui-ci n'est donc pas en Première Forme Normale.      Le processus de Normalisation que nous venons de détailler a donc pour but de se prémunir contre la redondance d'informations et contre les difficultés de mise à jour. Lorsqu'il est conduit à son terme, ne subsistent que deux types de Tableaux :      — Des Tableaux en Forme Normale de Boyce-Codd, c'est-à-dire en Troisième Forme Normale avec, éventuellement, Normalisation de Boyce-Codd ;      — Des Tableaux Binaires exprimant chacun une Dépendance Multivaluée Elémentaire. »