Bonsoir,
Affirmer qu’un schéma T* d’une table T est ou n’est pas en 3NF ne se décide pas au hasard, mais sur preuves.
Dans un premier temps, on doit disposer de la liste des règles de gestion de données concernées par T*.
Dans un deuxième temps, on traduit sous forme de dépendances fonctionnelles les règles qui manifestement sont concernées.
Dans un troisième temps, on détermine de façon algorithmique les clés candidates de T*.
Dans un quatrième temps on vérifie le niveau de normalité de T*, sachant que la cible est la BCNF (forme normale de Boyce-Codd).
(On se limitera ici à la 3NF).
Or, vous dites :
Où sont les règles de gestion des données ?
Je suppose qu’en ayant souligné l’attribut NoStock, vous voulez signifier que celui-ci est clé ? Tout cela s’appelle mettre la charrue avant les bœufs.
Si l’on parcourt le film en arrière, en ayant procédé ainsi, vous signifiez qu’il existe (entre autres) les dépendances fonctionnelles suivantes :
DF1 : {NoStock} → {marque}
DF2 : {NoStock} → {modèle}
DF3 : {NoStock} → {année}
DF4 : {NoStock} → {couleur}
DF5 : {NoStock} → {prix}
Je rappelle au passage la définition de la dépendance fonctionnelle (DF) :
Soit A et B deux sous-ensembles d’attributs de l’en-tête (ou schéma) d’une table T. Cette table satisfait à la DF A → B si et seulement si à chaque fois que deux lignes de la table ont la même valeur pour A, elles ont nécessairement la même valeur pour B (A est appelé le déterminant et B le dépendant). On dit encore que A détermine fonctionnellement B.
Vous noterez que je n’écris pas NoStock → marque, mais {NoStock} → {marque}. En effet, les DF ne mettent pas en jeu des éléments (les attributs) mais des sous-ensembles composés d’attributs.
En remontant à la première phase, on doit obligatoirement trouver les règles de gestion des données du genre des suivantes (parmi une foultitude d’autres) :
(RG1) Une voiture est synonyme d’un stock.
(RG2) Une voiture est d’une seule marque.
(RG3) Une voiture est d’un seul modèle.
(RG4) Une voiture est d’une seule année.
(RG5) Une voiture est d’une seule couleur.
(RG6) Une voiture a un seul prix.
Le coup du stock mérite des explications (j’aurais plutôt vu un numéro de série), mais bon. De même, qu’est-ce qu’une marque, un modèle ? De quelle année s’agit-il ? Production ? Vente ? Destruction ? Etc. Bref, il faut mettre un peu de sémantique dans tout cela, c’est la base. Règle d'or :
on doit savoir parfaitement de quoi on parle. Partant de là, on peut produire un modèle conceptuel qui servira à la production des tables.
Par ailleurs, il ne faut pas hésiter à utiliser des exemples. Je ne connais pas grand-chose au monde automobile, mais je ne pense pas dire de bêtises en prenant un exemple au hasard :
La voiture Stock007, de marque Renault, modèle Clio III, produite en 2008, de couleur rose bonbon est à vendre pour 12000 euros.
Je subodore alors qu’un modèle n’appartient qu’à une seule marque, je me renseigne auprès du chef de projet, et après confirmation de sa part, si la règle de gestion correspondante a été omise, je la fais rajouter :
(RG7) un modèle est d’une seule marque.
D’où une règle de gestion supplémentaire :
DF6 : {modèle} → {marque}
Le prix de la Clio III est peut être le même pour toutes les voitures de ce modèle (prix de vente conseillé en fonction de l’année par exemple), et plus généralement pour tous les modèles d’une marque. On va supposer que le chef de projet a dit que ce prix pouvait connaître des variations, en fonction de négociations avec l’acheteur et donc qu’il n’y a pas de règle unique en l’occurrence.
Supposons donc que les règles de gestion soient complètes du point de vue de celles qui nous intéressent, c'est-à-dire les règles d’
unicité entre attributs ou ensembles d’attributs.
Les règles de gestions étant complètes, Les dépendances fonctionnelles qui en sont la traduction le sont aussi, il s’agit en la circonstance de DF1 à DF6.
Je rappelle maintenant la définition de la clé candidate :
Une clé candidate est un sous-ensemble d’attributs K de l’en-tête d’une relation R, respectant les deux contraintes suivantes :
— Unicité. Deux tuples distincts de R ne peuvent avoir même valeur de K.
— Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.
(vous pouvez remplacer "relation" par "table" et "tuple" par "ligne".)
En vertu de quoi, une clé candidate détermine fonctionnellement chaque {attribut} de la table. Du fait de DF1 à DF5, {NoStock} est clé candidate.
Il vous faudra ensuite vérifier s’il existe d’autres clés candidates.
Partant, vous pourrez attaquer la normalisation, en commençant par la 2NF (ça n’est pas ma stratégie, mais on va faire comme si).
Pour que le schéma de la table Voiture vérifie la 2NF, il faut
1) Qu’il vérifie la 1NF
2) Que tout {attribut} n’appartenant pas à une clé candidate n’en dépende pas que d’une partie.
C’est notre cas, dans la mesure où l’on n’a trouvé qu’une seule clé, laquelle est un singleton.
Pour que le schéma de table vérifie la 3NF, il faut :
1) Qu’il vérifie la 2NF
2) Que tout {attribut} n’appartenant pas à une clé candidate ne dépende pas d’un sous-ensemble d’attributs non-clés.
Et cette fois-ci, on constate que la 3NF n’est pas respectée, à cause de DF6 :
{modèle} → {marque}, en effet {marque} dépend de {modèle} qui n’est pas clé candidate.
Normaliser consiste en l’occurrence à appliquer le théorème de Heath qui s’énonce ainsi :
Soit la table R {X, Y, Z} dans laquelle X, Y et Z sont des ensembles d’attributs de R. Si R satisfait à la dépendance fonctionnelle X → Y, alors R est égale à la jointure de ses projections sur {X, Y} et {X, Z}.
Si vous remplacez X par {modèle}, Y par {marque} et Z par ce qui reste, à savoir {NoStock, année, couleur, prix}, l’application du théorème conduit à décomposer la table en :
T1 {modèle, marque}
T2 {NoStock, année, couleur, prix}
T1 a pour seule clé candidate {modèle} (facile à vérifier)
T2 a pour clé candidate NoStock, héritée de Voiture.
Je vous engage à lire la discussion avec
Boubou382002, laquelle concerne votre sujet.
Pour votre part, vous obtenez :
modele (marque, prix, année)
voiture (n°stock, marque, couleur)
Si l’on traduit ceci sous forme de DF, puis de règles de gestion, on obtient :
DF11 : {NoStock} → {marque}
DF12 : {NoStock} → {couleur}
DF13 : {marque} → {prix}
DF14 : {marque} → {année}
(RG11) Une voiture est d’une seule marque
(RG12) Une voiture est d’une seule couleur
(RG13) Une marque vend toutes ses voitures à un prix unique
(RG14) Une marque vend toutes ses voitures la même année
Admettez que les deux dernières règles n’ont pas d’équivalent dans la réalité...
En plus on a perdu la relation entre une marque et ses modèles. Fâcheux.
ma décomposition en 3FN est-elle correcte?
Répondre avec citation
Envoyé par johnny3
Partager