Ce chapitre s’intéresse à la qualité de la conception d’une base de données relationnelle. Elle doit éviter dans la mesure du possible tout forme de redondance dans l’enregistrement des données. En effet, la redondance entraine des anomalies lors de la modification des données, qui conduisent à une incohérence des données stockées. De plus la redondance augmente fortement la taille des données stockées, ce qui peut fortement pénaliser les performances de la base.
L’analyse d’un modèle de données va reposer sur la notion de dépendance fonctionnelle entre les attributs du modèle.
Une analyse de ces dépendances fonctionnelles va conduire à préciser des formes particulières d’une base de données, appelées formes normales.
Dépendances fonctionnelles
Modèle et schéma de base
On regarde un modèle de données, constitué d’un certain nombre d’attributs, qui suivent certaines contraintes provenant de la réalité des données décrites.
On aura à envisager différentes instances envisageables de ce modèle, correspondant à différents moments de l’histoire, passés, futurs ou simplement envisageables.
On va réaliser ce modèle par un schéma de base de données, qui décrit une structure de tables, comme par exemple :
Realisateurs (idR, nom, prenom, sexe, anN, pays)
Films (idF, titre, type, anR, idR)
Pour chaque instance du modèle, on obtiendra ainsi plusieurs tables effectives, comme
idR | nom | prenom | sexe | anN | pays |
---|---|---|---|---|---|
1 |
Eastwood |
clint |
M |
1930 |
US |
2 |
Hitckock |
Alfred |
M |
1899 |
GB |
et
idF | titre | type | anR | idR |
---|---|---|---|---|
1 |
Psychose |
horreur |
1960 |
2 |
2 |
La corde |
policier |
1948 |
2 |
3 |
Impitoyable |
western |
1992 |
1 |
Si on modifie ces données, on obtient une nouvelle instance du même schéma.
Dépendances fonctionnelles
On considère un modèle avec des attributs a1, … , an, et on notera A l’ensemble de tous ces attributs { a1, … an}
Pour un enregistrement t, on note a1(t), … , an(t) les valeurs de ces attributs pour l’enregistrement t.
On peut aussi considérer un sous-ensemble X de A constitué d’un certain nombre d’attributs, et regarder de même l’ensemble X(t) constitué des valeurs en t des attributs contenus dans X.
Si X et Y sont deux ensembles d’attributs de A, on dit qu’il y a une dépendance fonctionnelle de X vers Y, qu’on note X → Y, si pour toute instance du modèle, et tout couple d’enregistrements s,t, tels que X(s) = X(t), on a Y(s) = Y(t).
Clés
Un sous-ensemble C de l’ensemble d’attributs A du modèle est une clé candidate si
-
Pour tout attribut a qui n’est pas dans C, alors C → a.
-
Aucun sous-ensemble strict de C ne vérifie la première propriété.
Il peut y avoir plusieurs clés candidates dans un modèle et on en privilégie une qu’on appelera la clé.
Décomposition d’un schéma
Etant donné un schéma de bases de données S(a1, … , an), on peut le décomposer en plusieurs tables, en écrivant l’ensemble d’attributs A comme réunion de plusieurs sous-ensembles B1, … , Bp, donnant ainsi lieu à p tables. Ainsi le schéma
Films_et_realisateurs(idF, titre, type, anR,idR, nom, prenom, sexe, anN, pays)
peut être décomposé en :
Realisateurs (idR, nom, prenom, sexe, anN, pays)
Films (idF, titre, type, anR, idR)
Une telle décomposition est sans perte d’information si pour toute instance du modèle, on peut reconstituer le schéma initial par jointure à partir du schéma décomposé.
Une décomposition préserve les dépendances fonctionnelles si toute dépendance fonctionnelle X → Y peut être déduite des dépendances fonctionnelles provenant de chacune des tables du schéma décomposé.
Formes normales
Première forme normale
Un schéma est sous première forme normale (1NF en anglais) si tous les attributs sont atomiques, c’est-à-dire si aucune subdivision de la donnée initiale n’apporte d’information complémentaire.
Remarques :
-
une date peut paraître non atomique, mais c’est une mauvaise analyse.
-
le numéro INSEE est effectivement non atomique, mais cela n’apporte pas grand chose de le voir comme réunion de plusieurs morceaux (sexe,année de naissance, mois de naissance, localité de naissance, ordre de naissance sous les conditions précédentes, clé).
-
Une table de la forme
père | mère | enfants |
---|---|---|
Paul |
Marie |
Antoine, Claire, Sylvie |
n’est clairement pas sous première forme normale.
Question : comment représenter ce modèle avec un schéma veérifiant 1NF ?
Deuxième forme normale
Un schéma est sous deuxième forme normale (2NF) si il est sous 1NF et si tout attribut ne faisant pas partie de la clé ne dépend pas fonctionnellement d’un sous-ensemble de la clé.
Remarque : en particulier, cette condition est trivialement réalisée si la clé est constituée d’un seul attribut.
Le schéma
(Produit, Fournisseur, adresse_fournisseur)
n’est pas sous 2NF, puisque l’adresse du fournisseur dépend seulement d’une partie de la clé.
On peut décomposer ce schéma, sans perte d’information, pour le mettre en 2NF :
(Produit, Fournisseur)
(Fournisseur, adresse_fournisseur)
Troisième forme normale
Un schéma est sous troisième forme normale (3NF) si il est sous 2NF et si tout attribut ne faisant pas partie de la clé ne dépend pas fonctionnellement d’un groupe d’attributs en dehors de la clé.
La table
(Fournisseur, adresse_fournisseur, ville, pays)
n’est pas en 3NF, puisque le pays est entièrement déterminé par la ville.
On peut se ramentr à la troisème forme normale en décomposant :
(Fournisseur, adresse_fournisseur, ville)
(ville, pays)
Forme normale de Boyce-Codd
Un schéma est sous forme normale de Boyce-Codd (BCNF) si il est sous 3NF et si tout groupe d’attributs ne faisant pas partie de la clé n’est pas source de dépendance fonctionnelle vers une partie de la clé.
Considérons la relation
R(A,B,C,D,E)
avec les dépendances fonctionnelles
A -> B
A -> C
C,D -> E
B -> D
La décomposition suivante :
R1(A,B,C)
R2(B,D)
R3(B,C,E)
est sous forme normale de Boyce-Codd et préserve les dépendances fonctionnelles.
Exercice
Cet exercice est tiré d’une feuille de TD de la licence informatique du Laboratoire de recherche en informatique de Sorbonne Université.
On imagine une UFR dont les données de scolarité sont organisées suivant le schéma suivant :
UFR (N_TD, SALLE, JOUR, HEURE, N_ENSEIGNANT, NOM_ENSEIGNANT, PRENOM_ENSEIGNANT, COD_MOD, DIPLOME, MATIERE, N_ETUDIANT, NOM_ETUDIANT, PRENOM_ETUDIANT, ADRESSE, DATE_INSCRIPTION )
Les hypothèses sont les suivantes :
-
Un code module précise à la fois un diplôme et une matière.
-
Les TDs sont annuels et il y a un TD par semaine dans chaque module.
-
Un TD est assuré par un seul enseignant.
-
Un N_ de TD est relatif à un module.
-
Un enseignant peut assurer plusieurs TDs
-
Un étudiant peut être inscrit dans plusieurs modules, mais dans un seul TD par module.
-
Date_Inscription est la date d’inscription d’un étudiant à un module.
Une analyse de la situation administrative a extrait les dépendances fonctionnelles suivantes :
N_ETUDIANT -> NOM_ETUDIANT, PRENOM_ETUDIANT, ADRESSE
N_ENSEIGNANT -> NOM_ENSEIGNANT, PRENOM_ENSEIGNANT
COD_MOD -> DIPLOME, MATIERE
DIPLOME, MATIERE -> COD_MOD
SALLE, JOUR, HEURE -> N_TD, COD_MOD
COD_MOD, N_TD -> SALLE, JOUR, HEURE, N_ENSEIGNANT
COD_MOD, N_ETUDIANT -> N_TD, DATE_INSCRIPTION
N_ENSEIGNANT, JOUR, HEURE -> SALLE
N_ETUDIANT, JOUR, HEURE -> SALLE
SALLE, JOUR, HEURE -> N_ENSEIGNANT
N_ETUDIANT, COD_MOD, N_TD -> SALLE, JOUR, HEURE
On considère maintenant la décomposition :
ENSEIGNEMENT (N_TD, COD_MOD, JOUR, HEURE, SALLE, N_ENSEIGNANT,
NOM_ENSEIGNANT, PRENOM_ENSEIGNANT)
INSCRIPTION (N_ETUDIANT, NOM_ETUDIANT, PRENOM_ETUDIANT, ADRESSE, COD_MOD, DIPLOME, MATIERE, DATE_INSCRIPTION, N_TD)
On considère maintenant la décomposition en trois tables :
ENS_PLANNING (N_ENSEIGNANT, NOM_ENSEIGNANT, PRENOM_ENSEIGNANT, JOUR, HEURE,N_TD,CODE_MOD)
ENS_SALLE (N_ENSEIGNANT, JOUR, HEURE, SALLE)
ETU_INSCRIPTION (N_ETUDIANT, NOM_ETUDIANT, PRENOM_ETUDIANT,
ADRESSE, N_TD, CODE_MOD, DATE_INSCRIPTION, DIPLOME, MATIERE)
ETU_PLANNING (N_ETUDIANT, JOUR, HEURE, CODE_MOD)