Discussion :

[new_wave]

Bonjour et bonne année 2008,

Suite à l'étude de la normalisation des associations, il me manque les éléments suivants .
Si vous pouviez m'aider à y répondre, je vous en serais très reconnaissante
car j'ai absolument besoin de ce complément d'information.

Pour une assocation à deux pattes qui n'est pas en 3 Fn , c'est à dire pour laquelle il existe une dépendance fonctionnelle entre deux propriétés de cette association,doit on créer une nouvelle association de dimension 2 qui contiendra la propriété source de dépendance fonctionnelle et éliminer cette propriété de la première association

Dans le cas d'une assocation à 3 pattes qui n'est pas en 3 FN, doit on, comme pour association à deux pattes, créer une nouvelle association de dimension 2 qui contiendra la propriété source de la DF et retirer cette propriété de la première association.

Et dans le cas dune asociation qui n'est pas en FNBC, que doit on faire dans le cas
-d'une assocation à deux pattes
-d'une association à trois pattes

Petite précision, dans le cas d'une association qui n'est pas en 2 Fn, le fait de faire migrer la propriété qui dépend d'une partie de l'identifiant vers l'entité concernée, peut on dire que l'on a remplacé une association de dimension 2 en une association de dimension 1 ?
( car le principe de la décomposition d'une association est de remplacer une association de dimension n par une association de dimension n-1.


Merci beaucoup encore de votre aide.

Bien cordialement.
Nathalie

[fsmrel]

Bonsoir Harbonne,

Merci pour vos vœux et je vous souhaite à mon tour une bonne année 2008.

Concernant la normalisation, j’ai pour habitude de raisonner au niveau du Modèle Relationnel de Données dont le père, Ted Codd a défini les règles en 1971 (2NF et 3NF) et Ian Heath aussi en 1971 (BCNF). Revoyez à ce sujet votre discussion d’il y a une semaine (http://www.developpez.net/forums/sho...ighlight=heath).

Si donc je dérive un MCD sous forme de relvars (tables, de façon informelle), je ne spécialise pas les solutions selon que la normalisation concerne les entités-types ou les associations-types, puisqu’au niveau relationnel il n’y a qu’un concept en face, celui de relvar. En outre, la notion de dimension telle que vous l’entendez n’y joue aucun rôle : la définition des formes normales met en jeu seulement des dépendances fonctionnelles (DF) et des clés candidates, le nombre d’attributs composant ces dernières (et reflétant la dimension) n’ayant aucune incidence.

Au niveau relationnel, on applique le théorème de Heath, dont je rappelle l’énoncé :

Soit R une relvar {X, Y, Z}, X, Y et Z représentant des sous-ensembles d’attributs de R.
Si on a la DF : X → Y, alors la relvar peut être décomposée sans perte en {X, Y} et {X, Z}.

Si R représente la relvar issue d’une association-type, et si A et B sont deux propriétés de cette association-type, telles que la DF {A} → {B} entraîne un viol de 3NF, R sera donc à décomposer en R1 (hébergeant A) et R2 (hébergeant B). Par rétroconception, vous obtiendrez deux associations-types R1 et R2, hébergeant respectivement A et B. Ceci est indépendant du nombre initial de pattes. La réponse à vos deux premières questions est donc, en principe, affirmative. Mais je dis : en principe ! car le remède peut être pire que le mal. En effet, vous devrez maintenant mettre en oeuvre une contrainte d’égalité, pour vous assurer que les occurrences d’une entité participant à R1 participent également à R2. Au niveau conceptuel, on se contente de dessiner un rond supplémentaire, mais au niveau opérationnel (SQL), cela fera l’objet d’un trigger plus coûteux (du fait du nombre de tables impliquées, auatnt que de pattes) qu’un trigger chargé de vérifier que la DF {A} → {B} est toujours respectée (une seule table en jeu). Ainsi, on peut légitimement préférer ne pas respecter la 3NF, mais à la condition expresse de garantir la validité de la base de données à l’aide d’une contrainte ad-hoc, mise en œuvre au moyen d’un trigger (tant que les SGBDR délaisseront l’instruction CREATE ASSERTION).

Concernant la BCNF :

Toujours au niveau relationnel, l’application du théorème de Heath permet une fois de plus de décomposer une relvar délinquante en deux relvars normalisées.

Supposons qu’au niveau MCD vous ayez deux entités-types A et B mises en relation par l’association-type R, laquelle porte une propriété X source d’un viol de BCNF. Soient A# et B# les propriétés identifiant respectivement A et B. Le couple {A#, B#} est clé de la relvar R dérivée de l’association-type R. On a par définition la DF {A#, B#} → {X}. S’il y a viol de BCNF, c’est que l’on a par exemple la DF {X} → {A#}. Par application du théorème de Heath, vous devrez une fois de plus décomposer la relvar R en deux relvars R1 {X, A#} et R2 {X, B#}. Par le jeu de la rétroconception, X fera l’objet d’une nouvelle entité-type, disons C (porteuse de la propriété X) et R1 et R2 feront l’objet de deux associations-types mettant en relation A et C d’une part, B et C d’autre part. Mais les couples {A, B} ne peuvent pas être quelconques, c'est-à-dire qu’il faut conserver l’association-type R initiale, tout en l’ayant débarrassée de la propriété X. Mais le fait d’avoir expulsé X de R fait que désormais on ne peut plus garantir que X dépend de couples {A, B} précis, sinon par la mise en œuvre de nouvelles contraintes qui nous font tourner en rond. Comme dans le cas de la 3NF (et cette fois-ci cela devient nécessaire), il est préférable de violer la BCNF et de s’assurer que la DF {X} → {A#} est garantie au niveau SQL, grâce à l’utilisation d’un trigger ad-hoc.