Le processus de normalisation permet de construire des bases de données relationnelles en évitant les redondances et en préservant l’intégrité des données. Il est préférable de normaliser les relations au moins jusqu’à la troisième forme normale.
La normalisation est basée sur les dépendances fonctionnelles (DF). E.F. Codd fut le premier à publier des écrits sur les DF [COD 72].
Définition
Un attribut b dépend fonctionnellement d’un attribut a si à une valeur de a correspond au plus une valeur de b. La dépendance fonctionnelle est notée a Æ b.
Le membre droit de l’écriture s’appelle le dépendant, le membre gauche s’appelle le déterminant.
Plusieurs attributs peuvent apparaître dans la partie gauche d’une DF. Dans ce cas, il convient de considérer le couple (si deux attributs figurent dans la partie gauche), le triplet (s’il y a trois attributs), etc. Plusieurs attributs peuvent apparaître dans la partie droite d’une DF. Dans ce
cas, il convient de considérer chaque DF en gardant la partie gauche et en faisant intervenir un seul attribut dans la partie droite.
Supposons les exemples suivants, qui concernent des pilotes ayant un numéro, un nom, une fonction (copilote , commandant, instructeur…) :
● l’écriture numPilote,jour Æ nbHeuresVol est une DF, car à un couple ( numPi-lote, jour) correspond au plus un nombre d’heures de vol ;
● l’écriture numPilote ÆnomPilote, fonction est équivalente aux écritures numPi-lote Æ nomPilote et numPilote Æ fonction qui sont deux DF. En consé-quence numPiloteÆnomPilote, fonction est une DF ;
● l’écriture nomPilote Æ fonction est une DF s’il n’y a pas d’homonymes dans la population des pilotes enregistrés dans la base de données. Dans le cas contraire, ce n’est pas une DF, car à un nom de pilote peuvent correspondre plusieurs fonctions ;
● l’écriture fonctionÆnomPilote n’est pas une DF, car à une fonction donnée corres-pondent éventuellement plusieurs pilotes.
DF élémentaire
Une DF a,b→c est élémentaire si ni a→c, ni b→c ne sont des DF.
Considérons les exemples suivants :
● la dépendance fonctionnelle numPilote,jourÆ nbHeuresVol est élémentaire, car numPiloteÆnbHeuresVol n’est pas une DF (un pilote vole différents jours, donc pour un pilote donné, il existe plusieurs nombres d’heures de vol), pas plus que jourÆ nbHeuresVol (à un jour donné, plusieurs vols sont programmés) ;
● la dépendance fonctionnelle numPilote,nomPiloteÆfonction n’est pas élémen-taire, car le numéro du pilote suffit pour retrouver sa fonction (numPiloteÆfonction est une DF).
DF directe
Une DF a Æ c est directe si elle n’est pas déduite par transitivité, c’est-à-dire s’il n’existe pas de DF a Æ b et b Æ c.
L’expérience montre qu’il est difficile de savoir si une DF est directe, mais il est aisé de voir si elle est indirecte. En conséquence si une DF n’est pas indirecte, elle est directe (ouf !).
Illustrons cette définition par la figure suivante. Soit les trois dépendances fonctionnelles (1), (2) et (3). La dépendance fonctionnelle (3) est non directe et les dépendances (1) et (2) sont directes.
Considérons l’exemple qui fait intervenir les attributs suivants : (immat : numéro d’immatri-culation d’un avion ; typeAvion : type de l’aéronef ; nomConst : nom du constructeur de l’aéronef).
● La dépendance immatÆnomConst n’est pas une DF directe.
● La dépendance immatÆtypeAvion est une DF directe.
● La dépendance typeAvionÆnomConst est une DF directe.
Propriétés
Les propriétés suivantes sont appelées « axiomes d’Armstrong » ou « règles d’inférence ».
L’article [ARM 74] est à l’origine de ces axiomes.
Réflexivité : si b est un sous-ensemble de a alors a Æ b est une DF. Une autre écriture de la réflexivité (appelée « autodétermination ») a Æ a est une DF, cette écriture peut aider à rendre minimal un ensemble de DF.
Augmentation : si a Æ b est une DF, alors a,c Æ b,c est une DF.
Transitivité : si a Æ b et b Æ c sont des DF, alors a Æ c est une DF.
Union : si a Æ b et a Æ c sont des DF, alors a Æ b,c est une DF.
Pseudo-transitivité : si a Æ b et b,c Æ d sont des DF, alors a,b Æ d est une DF.
Décomposition : si a Æ b,c est une DF, alors a Æ b et a Æ c sont des DF.
Fermeture d’un ensemble de DF
Nous avons vu précédemment qu’on pouvait déduire des DF à partir de DF par règles d’inférence.
La fermeture F+ d’un ensemble de DF F est l’ensemble des DF qu’on peut obtenir par applications successives des axiomes d’Armstrong.
La couverture minimale est l’ensemble des DF élémentaires issues de F+ tel que :
• le membre droit (dépendant) de chaque DF ne contient qu’un seul attribut ;
• le membre gauche (déterminant) de chaque DF est irréductible ;
• aucune DF ne peut être supprimée.
Figure 2-4 Dépendances fonctionnelles directes et non directes
(2) directe c
(3) indirecte
a b
(1) directe
Cˆ
En considérant seulement aÆb et bÆc, la fermeture obtenue contient 21 DF ! (aÆa, bÆb, aÆc, a,cÆb…).
L’exemple suivant décrit la résolution de la fermeture et de la couverture minimale de l’ensemble de DF F = {immatÆ compagnie, immat ÆtypeAvion, typeAvionÆ capacite, typeAvionÆnomConst}.
On applique la transitivité entre :
● la DF immatÆtypeAvion et type AvionÆnomConst et on obtient la DF immat ÆnomConst ;
● la DF immatÆtypeAvion et typeAvionÆcapacite et on obtient la DF immat Æcapacite.
On pourrait appliquer l’union entre immatÆ compagnie et immat Æ typeAvion de manière à obtenir la DF immatÆtypeAvion,compagnie.
De même, l’union entre typeAvionÆ capacite et typeAvionÆ nomConst donne typeAvionÆcapacite,nomConst.
On pourrait appliquer l’augmentation entre chaque DF. Ainsi la DF immatÆcompagnie donnerait lieu à l’écriture des DF suivantes :
● immat,typeAvionÆcompagnie,typeAvion
● immat,capaciteÆcompagnie,capacite
● immat,nomConstÆcompagnie,nomConst
On pourrait également appliquer les autres propriétés des DF aux DF initiales de manière à obtenir un nombre important de DF pas nécessairement intéressantes. La fermeture de cet ensemble s’écrirait de la sorte :
F+ = {immat Æ compagnie ; immat Æ typeAvion ; typeAvion Æ capacite ; typeAvionÆ nomConst ; immat Æ capacite ; immat Æ nomConst ; immat Æ typeAvion,compagnie ; immat,typeAvion Æ compagnie,typeAvion ; immat,capacite Æ compagnie,capacite ; immat,nomConst Æ compagnie, nomConst ; … }
Ce qui intéresse le concepteur est l’ensemble des DF composant la couverture minimale de F+ noté : = {immat Æ compagnie ;immat Æ typeAvion ; typeAvion Æ capacite ; typeAvion ÆnomConst}.
Nous étudierons en fin de chapitre deux méthodes de conception de schémas relationnels normalisés basées sur les DF.
Alors que les DF vont servir à classifier un schéma relationnel en première, deuxième, troisième ou BCFN (Boyce-Codd forme normale), d’autres formes de dépendances vont permettre de définir les quatrième et cinquième formes normales. Ces familles de dépendances sont les dépendances multivaluées et les dépendances de jointure. Néanmoins, la majorité des schémas relationnels en entreprise sont en deuxième (on dénormalise des relations volontairement pour des contraintes d’optimisation) ou en troisième forme normale.
Cˆ
Dépendances multivaluées
Les dépendances multivaluées (DM) permettent d’appréhender certaines dépendances existant entre attributs d’une même relation.
La DM entre les attributs a et b et c d’une relation R est notée a ÆÆ b | c (a multidétermine b pour c). Pour toute valeur de a, il existe un ensemble de valeurs de b indépendant des valeurs de c.
Si (a1,b1,c1) Œ R et (a1,b2,c2) ŒR fi (a1,b2,c1) Œ R et (a1,b1,c2) Œ R
La relation suivante décrit une DM typeAvionÆÆqualif | nomPilote. En effet, les triplets (A320,PP-IFR,Bidal) et (A320,QT-JAR25,Soutou) de la relation QualifsAvions1 entraînent (A320,PP-IFR,Soutou) et (A320,QT-JAR25,Bidal) dans la même relation.
Le lecteur aura compris que pour qu’un pilote soit lâché (terme aéronautique indiquant qu’un pilote est apte à voler sur une machine) sur A320, il faut qu’il ait à la fois les qualifications PP-IFR et QT-JAR25. Le type de machine A340 requiert quant à lui trois qualifications (PP-IFR, PL et QT-JAR25).
Les dépendances multivaluées existent toujours par paires [DAT 00]. En effet, a ÆÆ b | c peut être aussi noté avec les deux écritures a ÆÆ b et a ÆÆ c.
Dans notre exemple, nous aurions donc les notations des DM typeAvionÆÆqualif et typeAvionÆÆnomPilote. Il semble cependant préférable d’utiliser la première notation (a ÆÆ b | c).
Les axiomes d’Armstrong [ARM 74] ont été étendus par [BEE 77] pour les DM. On découvre notamment que les propriétés de réflexivité, d’augmentation, de transitivité, de pseudo-transitivité, d’union et de décomposition peuvent s’appliquer aux DM.
Figure 2-5 Dépendances multivaluées
QualifsAvions1
nomPilote typeAvion qualif Bidal A320 PP-IFR
Bidal A320 QT-JAR25
SanFilippo A340 PL
SanFilippo A340 QT-JAR25
SanFilippo A340 FH
Soutou A320 PP-IFR Soutou A320 QT-JAR25
typeAvion qualif | nomPilote
Par ailleurs, une DM a ÆÆ b est triviale si b est un sous-ensemble de a ou si l’union des deux colonnes donne relation entière [TEO 94].
Dépendances de jointure
Les dépendances de jointure (DJ) permettent de résoudre certaines redondances assez rares, qu’on ne peut pas traiter avec les DF et DM, pour mener ainsi à la cinquième forme normale.
Le principe est de pouvoir recomposer une relation contenant des redondances à partir de jointures sur n relations (n>2).
Dans l’exemple suivant, la relation Employer comporte des redondances au niveau de la qualification du pilote (certaines qualifications sont répétées pour différentes compagnies).
On ne peut pas décomposer cette relation en deux relations. Il est nécessaire d’utiliser une troisième relation pour éviter des redondances (voir la figure 2-7). En contrepartie, il faudra mettre en œuvre de nombreuses jointures au niveau du langage SQL pour interroger et manipuler ces relations.
Figure 2-6 Relation Employer Employer
Figure 2-7 Relations définies en extension permettant de reconstituer Employer QualifsAvions2
Une dépendance de jointure est vérifiée dans une relation R entre les attributs si la jointure1 de ses projections2 sur chaque attribut reconstitue R.
• Soit R[a,b,c], une dépendance de jointure existe si R = (a) (b) (c).
Bilan des dépendances
Il est utile au concepteur de connaître ces notions de base. En effet, même s’il construit le schéma avec un formalisme entité-association ou UML, il peut toujours en extraire des relations entre attributs et déduire s’il s’agit de DF ou non. Ainsi, il peut concevoir des schémas normalisés.
Les clés primaires et étrangères des relations peuvent être également définies à l’aide des DF.
Reprenons l’exemple des ordinateurs et des étudiants décrit en début de chapitre. On aurait pu déduire les DF élémentaires et directes suivantes :
● cpu→ prixMoyen, cpu→ delaiMoyen ;
● codetu→ nomEtu, codetu→ cpu, cette dernière DF permet de statuer sur l’existence d’une clé étrangère dans la relation Etudiant.
La figure 2-8 indique la notation de ce schéma relationnel en intention :