Différence entre 3NF et BCNF en termes simples (doit pouvoir expliquer à un enfant de 8 ans)

Question

J'ai lu la citation : des données dépend de la touche [1FN], l'ensemble de la touche [2FN] et de rien, mais la touche [3FN].

Cependant, je vais avoir du mal à comprendre 3.5 NF ou FNBC, comme on dit. Voici ce que je comprends :

• FNBC est plus stricte que 3FN
• côté gauche de FD dans le tableau doit être un superkey (ou au moins une clé candidate)

Alors, pourquoi est-il alors, que certains 3FN les tables ne sont pas en FNBC? Je veux dire, la 3FN citer explicitement dit "rien, mais la clé", ce qui signifie que tous les attributs dépendent exclusivement de la clé primaire. La clé primaire est, après tout, un candidat à la clé jusqu'à ce qu'il est choisi pour être notre clé primaire.

Si quelque chose ne va pas au sujet de mon comprendre jusqu'à présent, s'il vous plaît corrigez-moi et merci pour toute aide que vous pouvez fournir.

Answer 1

Votre pizza peut avoir exactement trois types de garniture:

• un type de fromage
• un seul type de viande
• un type de légume

Nous avons donc commander deux pizzas et choisissez les garnitures suivantes:

Pizza    Topping    Topping Type
-------- ---------- -------------
1        mozarella  cheese
1        pepperoni  meat
1        olives     vegetable
2        mozarella  meat
2        sausage    cheese
2        peppers    vegetable

Attendez une seconde, mozzarella ne peut pas être à la fois un fromage et viande! Et la saucisse n'est pas un fromage!

Nous devons éviter que ces sortes de fautes, de faire de mozzarella toujours être de fromage. Nous devrions utiliser un tableau distinct pour cela, nous avons donc écrire que fait dans un seul endroit.

Pizza    Topping
-------- ----------
1        mozarella
1        pepperoni
1        olives
2        mozarella 
2        sausage
2        peppers

Topping    Topping Type
---------- -------------
mozarella  cheese
pepperoni  meat
olives     vegetable
sausage    meat
peppers    vegetable

---

Re votre commentaire:

Votre question nécessite qu'un enfant de 8 ans pourrait comprendre l'explication. :-)

FNBC agit différemment de 3FN seulement lorsqu'il y a plusieurs chevauchement candidat clés.

La raison en est que la dépendance fonctionnelle X -> Y a, certes, si Y est un sous-ensemble de l' X. Donc dans une table qui n'a qu'un seul candidat à la clé et est en 3FN, il est déjà en FNBC, car il n'y a pas de colonne (clé ou non-clé) qui est fonctionnellement dépendant de rien d'ailleurs que les principaux.

Parce que chaque pizza doit avoir exactement un de chaque garniture type, nous savons que (Pizza, Garniture Type) est une clé candidate. Nous savons aussi intuitivement que la garniture ne peut pas appartenir à différents types en même temps. (Pizza, Garniture) doit être unique et, par conséquent, est également une clé candidate. Nous avons donc les deux se chevauchent candidat clés.

J'ai montré une anomalie où nous avons marqué mozzarella comme le mauvais type de garniture. Nous savons que c'est mal, mais la règle qui fait mal, c'est une dépendance Topping -> Topping Type qui n'est pas valide dépendance pour FNBC pour cette table. C'est une dépendance à quelque chose d'autre qu'un ensemble de clé candidate.

Donc, pour résoudre ce problème, nous prenons Type de Garniture de la pizza de table et d'en faire un attribut non-clé dans un des Garnitures de tableau.

Answer 2

La subtile différence est que 3FN fait une distinction entre les clés et les attributs non-clé (aussi appelé non-prime attributs) alors que FNBC ne le fait pas.

Cela est mieux expliqué à l'aide de Zaniolo la définition de 3FN, qui est l'équivalent de Codd:

Une relation R est en 3FN ssi pour tous les non-triviale FD (X->A) satisfait par R au moins UNE des conditions suivantes est remplie:

(a) X est un superkey pour R, ou

(b) A est un attribut clé de la R

FNBC exige (a), mais ne permet pas de traiter (b) comme un cas particulier qui lui est propre. En d'autres termes FNBC exige que tous les non-triviale déterminant est un superkey même ses attributs dépendants arriver à être une partie d'une clé.

Une relation R est en FNBC ssi pour tous les non-triviale FD (X->A) satisfait par R la condition suivante est vraie:

(a) X est un superkey pour R

FNBC est donc plus stricte.

La différence est tellement subtil que ce que beaucoup de gens de façon informelle décrire comme 3FN est en fait FNBC. Par exemple, vous avez déclaré ici que 3FN signifie "données repose sur la touche[s]... et de rien, mais la clé[s]", mais qui est en réalité une description informelle de FNBC et pas en 3FN. 3FN pourrait plus être exactement décrit comme "non-clé de données repose sur les touches... et rien, mais les touches".

Vous avez également déclaré:

la 3FN citer explicitement dit "rien, mais la clé", ce qui signifie que tous les les attributs dépendent exclusivement de la clé primaire.

C'est une explication simpliste. 3FN et FNBC et de toutes les Formes Normales sont concernés par tous les candidats des clés et/ou superkeys, pas juste un "primaire".

Answer 3

Toutes les bonnes réponses. En langage simple [BCNF] Aucune clé partielle ne peut dépendre d'une clé.

C'est-à-dire qu'aucun sous-ensemble partiel (c'est-à-dire tout sous-ensemble non trivial à l'exception de l'ensemble complet) d'une clé candidate ne peut dépendre fonctionnellement d'une clé candidate.