Dépendances fonctionnelles restantes après la décomposition de Boyce Codd?

Question

Cet exemple de décomposition a été donné en classe, mais la solution prête à confusion car elle semble laisser certains FD non adressés. Veuillez confirmer 3) ci-dessous est dans BCNF, ou ne peut pas être mis dans BCNF?

Let R be a relation schema, with schema(R) = {C,T,H,R,S,G} 

set of FDs F over R : 
C->T 
HR->C 
HT->R 
CS->G 
HS->R 

décomposition:

1) C T H R S G 
2) C T  C H R S G 
3) C T  H R C  H R S G 
end. (Not further decomposed.) 

Dans 3) HRSG contient des attributs R et G sans paraître satisfaire HT-> r ou CS-> g.

ht-> r est réduit parce que nous n'avons t HRSG CS-> g est réduit parce que nous n'avons pas c dans HRSG

est-il une règle que si le LHS d'une fonctionnelle la dépendance contient des attributs qui ne sont pas dans la relation, le FD ne s'applique pas? Merci

Answer 1

Le FD s'applique toujours à la conception db globale. Chaque FD est toujours l'expression d'une règle métier. Toutes les règles métier indiquées s'appliquent toujours, qu'elles soient appliquées sur une version à une table du schéma de base de données ou sur une version décomposée de celle-ci. Cependant, les exprimant comme FD exige que tous les attributs impliqués dans la FD apparaissent dans le même relvar (parce que c'est la façon dont ils ont été inventés: comme un moyen d'exprimer une règle qui applique à un relation schéma (notez qu'il ne pas dire « schéma de base de données » ici). La conséquence logique est que FD de sont tout simplement incapables d'exprimer des règles « span » plus que juste un schéma de relation. La conséquence logique de que est que ce n'est rien de plus que normal "décomposer un schéma de relation" va/pourrait conduire certains FD à devenir inexprimables (pas "inapplicable") dans la nouvelle version.

(1) Les FD qui sont encore exprimables après décomposition/normalisation en BCNF, peuvent être «implémentées» en déclarant le LHS du FD comme une clé du schéma de relation. (2) Les FD devenus inexprimables dans un schéma décomposé devront être réintégrés dans la conception globale de la base de données sous la forme d'une contrainte de base de données. Cette "contrainte de base de données" est très similaire aux contraintes clés correspondant aux FD de (1), dans la mesure où ces contraintes de base de données sont aussi une "clé" d'un tri, elles ne sont simplement pas une clé pour une relation dans le schéma de base de données. à la place, ils sont la clé d'une relation «virtuelle» («vue») définissable dans le schéma de la base de données. Cette vue est une projection (sur exactement les attributs mentionnés de chaque côté de la FD) des JOINs (donc, la "recomposition des parties décomposées") des schémas de relation impliqués. C'est beaucoup de mots et peut-être difficile à suivre, mais la procédure est (pour cs-> g): réintégrer les schémas de relation décomposés (sur HR, nous renvoyant une relation HRCSG), projeter jusqu'à les attributs impliqués dans le FD (donc, projet jusqu'à CSG), et dans cette relation, CS doit être une clé. Notez que je dis «clé» ici en ce sens qu'il ne peut pas être permis à la même combinaison de valeurs CS d'apparaître avec des valeurs G différentes. Pas dans le sens où il s'agit d'une déclaration que vous pourriez faire à n'importe quel SGBD pour appliquer une telle règle.Si les SGBD pouvaient effectivement le faire, la conception de la base de données serait beaucoup plus facile :-) Signifiant que l'application de la règle, et veiller à ce qu'aucune donnée ne viole jamais cette règle, est maintenant à vous.

Heureusement, dans la pratique ces cas ne sont pas trop nombreux, et la plupart du temps, vous remarquerez que la grande majorité des FD dans votre version originale, finissent simplement comme des clés déclarées sur les tables BCNF.