Bonsoir Leauh,
Je suppose que les redondances dont vous parlez concernent l’association PRENDRE. En l’occurrence, il faut déjà montrer que la normalisation est respectée, puisque vous intitulez votre billet : "Problème avec la forme normale". Si elle est respectée, voir alors ce que l’on peut gratter autrement.
Lors de la dérivation du MCD en MLD, en utilisant un outil comme PowerAMC, on obtient une table que l’on peut continuer à appeler PRENDRE. Cette table a la structure suivante (à l’ordre des attributs près, ce qui n’a aucune importance) :
PRENDRE (DisqueId, PisteId, TitreId, DuréeId, PoidsId)
L’outil va générer comme clé primaire le n-uplet {DisqueId, PisteId, TitreId, DuréeId, PoidsId}. En effet, l’identifiant de l’association est par définition la concaténation des identifiants des entités-types participant à cette association.
Avant d’aller plus loin et pour aider à la réflexion, je prends l’exemple des disques enregistrés par Glenn Gould. J’ai devant moi deux disques différents, sur lesquels on trouve les Variations Goldberg (BWV 988) : l’enregistrement historique de 1955 pour le premier et l’enregistrement de 1981 pour le deuxième (lequel contient aussi la fugue en mi majeur (BWV 878) et la fugue en fa# mineur (BWV 883)).
La table PRENDRE a la valeur suivante (je remplace à l’occasion des valeurs d’identifiants par des chaînes de caractères, pour que cela soit plus parlant) :
PRENDRE
Figure 1 - Table PRENDRE
Cette table est à vue d’œil fortement redondante. Mais alors, violerait-elle la forme normale de Boyce-Codd ? Que dis-je, la Cinquième ? (qui n’est pas de Beethoven, malgré le contexte musical...)
Avant de vérifier cela, revenons à la clé primaire. Comme supposé plus haut, est-elle vraiment la suivante ?
{DisqueId, PisteId, TitreId, DuréeId, PoidsId}
La réponse est négative. Un identifiant merisien est toujours une surclé au sens de la théorie relationnelle, mais pas toujours une clé primaire, quoi qu’en disent d’éminents auteurs (cf. [1]). En effet, une clé primaire est un cas particulier du cas plus général de ce que l’on appelle une clé candidate, laquelle est à son tour un cas particulier de ce que l’on appelle une surclé, laquelle répond à la définition à suivre. Pardonnez-moi pour les précisions et définitions, mais j’aime bien que les concepts relationnels soient bien compris.
Concept de surclé
Soit K un sous-ensemble (non strict) des attributs composant l’entête d’une table S ; K est une surclé de S si et seulement si deux tuples (lignes) distincts de S ne peuvent avoir la même valeur.
Cette contrainte porte le nom de Contrainte d’unicité.
Dans votre cas, K = {DisqueId, PisteId, TitreId, DuréeId, PoidsId} est une surclé de la table PRENDRE.
Concept de clé candidate
La surclé K est une clé candidate si elle obéit non seulement à la contrainte d’unicité, mais aussi à une contrainte dite d’irréductibilité, selon laquelle :
Il n’existe pas de sous-ensemble K’ strictement inclus dans K obéissant lui aussi à la contrainte d’unicité.
Intuitivement, K n’est pas ici clé candidate, dans la mesure où débarrassée par exemple de PoidsId, elle garantit la contrainte d’unicité, même chose si on en évacue TitreId et DuréeId.
De fait, si K est réduite à
{DisqueId, PisteId}
alors seulement elle devient clé candidate.
En faisant appel à votre seul bon sens, vous pouvez vérifier que pour le couple {DisqueId, PisteId}, on a un seul titre, une seule durée et un seul poids. Toute autre combinaison est vouée à l’échec : le couple {DisqueId, PisteId} est la seule clé candidate de la table PRENDRE.
Vous pouvez aussi vérifier que cette table respecte la BCNF (cf. la définition donnée dans http://www.developpez.net/forums/sho...d.php?t=281221, #4)
Autrement dit, par les voies "normales", on aura du mal à évacuer des redondances. Maintenant, votre table pose un problème de redondance que l’on rencontre dans les tables à caractère historique, dans lesquelles on retrouve le binôme infernal {DateDébut, DateFin} et qui trouve généralement sa solution par l’utilisation du type Intervalle. Ainsi, vous pouvez éliminer les redondances engendrées par les titres, en projetant la table PRENDRE selon deux tables, PRENDRE_A et PRENDRE_B, et dans le cas des titres utiliser une représentation intervallaire (clé primaire soulignée) :
PRENDRE_A
Figure 2 - Table PRENDRE_A : données du niveau intervalle
Vous observerez que si le couple {DisqueId, PisteDébutId} a été retenu comme clé primaire : à son tour, le couple {DisqueId, PisteFinId} répond à la définition de la clé candidate et devra donc être déclaré comme tel pour le SGBD. En l’occurrence, il s’agit d’une clé candidate non retenue comme clé primaire et qui doit être considérée comme clé alternative. Cela dit, pour la théorie relationnelle, les concepts de clé primaire et clé alternative sont devenus caducs, ne reste que ceux de surclé et de clé candidate.
Concernant les données de niveau piste, on ne peut guère envisager de solution alternative, sauf au cas où, par exemple, à une valeur de durée correspondrait une seule valeur de poids (dépendance fonctionnelle entraînant un viol de 3NF, ou règle de calcul).
PRENDRE_B
Fig_3.jpg)
Figure 3 - Table PRENDRE_B : données du niveau piste
A noter que si vous disposez du type Intervalle, la table PRENDE_A a l’allure suivante :
PRENDRE_A
Figure 4 - Table PRENDRE_A : utilisation du type intervalle
Je ne vous apporte pas de solution miracle, j’en suis désolé. Au moins aurons-nous évoqué les intervalles...
[1] A. Rochfeld et J. Morejon. La Méthode MERISE. Tome 3. Gamme opératoire. (Les Éditions d'organisation. 1989).
[FN] Formes Normales et redondance
.
Répondre avec citation
.
Partager