Différence entre 3NF et BCNF en termes simples (doit pouvoir expliquer à un enfant de 8 ans)
J'ai lu la citation: les données dépendent de la clé [1NF], de la clé entière [2NF] et de rien que de la clé [3NF].
Cependant, j'ai du mal à comprendre 3.5NF ou BCNF comme on l'appelle. Voici ce que j'ai compris:
- BCNF est plus stricte que 3NF
- le côté gauche de toute FD de la table doit être une super-clé (ou au moins une clé candidate)
Alors pourquoi est-il alors que certaines tables 3NF ne sont pas en BCNF? Je veux dire, la citation 3NF dit explicitement "rien que la clé" ce qui signifie que tous les attributs dépendent uniquement de la clé primaire. Après tout, la clé primaire est une clé candidate jusqu'à ce qu'elle soit choisie pour être notre clé primaire.
Si quelque chose ne va pas au sujet de ma compréhension jusqu'à présent, corrigez-moi et merci pour toute aide que vous pourriez fournir.
Votre pizza peut avoir exactement trois types de garniture:
- un type de fromage
- un type de viande
- un type de légume
Nous commandons donc deux pizzas et choisissons les garnitures suivantes:
Pizza Topping Topping Type
-------- ---------- -------------
1 mozzarella cheese
1 pepperoni meat
1 olives vegetable
2 mozzarella meat
2 sausage cheese
2 peppers vegetable
Attendez une seconde, la mozzarella ne peut pas être à la fois un fromage et une viande! Et la saucisse n'est pas un fromage!
Nous devons éviter ce genre d’erreurs, faire de la mozzarella toujours être du fromage. Nous devrions utiliser un tableau séparé pour cela, nous écrivons donc ce fait à un seul endroit.
Pizza Topping
-------- ----------
1 mozzarella
1 pepperoni
1 olives
2 mozzarella
2 sausage
2 peppers
Topping Topping Type
---------- -------------
mozzarella cheese
pepperoni meat
olives vegetable
sausage meat
peppers vegetable
C'était l'explication qu'un enfant de 8 ans pouvait comprendre. Voici la version plus technique.
BCNF agit différemment de 3NF uniquement lorsqu'il existe plusieurs clés candidates se chevauchant.
La raison en est que la dépendance fonctionnelle X -> Y est bien sûr vraie si Y est un sous-ensemble de X. Ainsi, dans toute table ne disposant que d'une seule clé candidate et se trouvant dans 3NF, il l'est déjà dans BCNF car il n'y a pas de colonne (clé ou non-clé) fonctionnellement dépendant de rien d'autre que cette clé.
Parce que chaque pizza doit avoir exactement un type de garniture, nous savons que (Pizza, Type de garniture) est une clé candidate. Nous savons aussi intuitivement qu’un nappage donné ne peut appartenir simultanément à différents types. Donc (Pizza, Topping) doit être unique et constitue donc également une clé candidate. Nous avons donc deux clés de candidats qui se chevauchent.
J'ai montré une anomalie où nous avons marqué mozarella comme étant le mauvais type de garniture. Nous savons que cela est faux, mais la règle qui le rend erroné est une dépendance Topping -> Topping Type qui n'est pas une dépendance valide pour BCNF pour cette table. C'est une dépendance à autre chose qu'une clé entière du candidat.
Pour résoudre ce problème, nous extrayons Topping Type de la table Pizzas et en faisons un attribut non clé dans une table Toppings.
La différence subtile est que 3NF fait une distinction entre les attributs clés et non-clés (également appelés attributs non-premiers ), contrairement à BCNF.
Ceci est mieux expliqué en utilisant définition de Zaniolo sur 3NF, ce qui équivaut à Codd:
Une relation, R, est dans 3NF si et seulement si chaque FD non trivial (X-> A) satisfait par R, au moins UNE des conditions suivantes est vraie:
(a) X est une super clé pour R, ou
(b) A est un attribut clé pour R
BCNF exige (a) mais ne considère pas (b) comme un cas à part. En d'autres termes, BCNF exige que chaque déterminant non trivial soit une super-clé, même ses attributs dépendants arrivent à faire partie d'une clé.
Une relation, R, est dans BCNF si et seulement si, pour tout FD non-trivial (X-> A) satisfait par R, la condition suivante est vraie:
(a) X est une super clé pour R
BCNF est donc plus stricte.
La différence est si subtile que ce que beaucoup de gens décrivent de manière informelle comme 3NF est en réalité BCNF. Par exemple, vous avez indiqué ici que 3NF signifie "les données dépendent de la clé [s] ... et rien que de la clé [s]", mais qu'il s'agit en réalité d'une description informelle de BCNF et non de 3NF. 3NF pourrait plus précisément être décrit comme " des données non-clés dépendent des clés ... et rien que des clés".
Vous avez également déclaré:
la citation 3NF dit explicitement "rien que la clé", ce qui signifie que tous les attributs dépendent uniquement de la clé primaire.
C'est une simplification excessive. 3NF et BCNF et toutes les formes normales concernent toutes clés candidates et/ou super-clés, et non une seule clé "primaire".
La différence entre BCNF et 3NF
Utilisation de la définition BCNF
Si et seulement si pour chacune de ses dépendances X → Y, au moins une des conditions suivantes est vérifiée :
- X → Y est une dépendance fonctionnelle triviale (Y X), ou
- X est une super clé pour le schéma R
et la définition 3NF
Si et seulement si, pour chacune de ses dépendances fonctionnelles X → A, au moins une des conditions suivantes est vérifiée:
- X contient A (c'est-à-dire que X → A est une dépendance fonctionnelle triviale) ou
- X est une super clé, ou
- Chaque élément de A-X, la différence établie entre A et X, est un attribut principal (c’est-à-dire que chaque attribut de A-X est contenu dans une clé candidate).
Nous voyons la différence suivante, en termes simples:
- En BCNF : chaque clé partielle (attribut principal) peut uniquement dépendre d'une super-clé,
tandis que
- En 3NF : une clé partielle (attribut principal) peut également dépendre d'un attribut qui est pas une super-clé (c'est-à-dire une autre clé partielle/un attribut premier ou même un attribut non premier).
Où
- Un attribut premier est un attribut présent dans une clé candidate, et
- Une clé candidate est une super clé minimale pour cette relation, et
- A superkey is a set of attributes of a relation variable for which it holds that in all relations assigned to that variable, there are no two distinct tuples (rows) that have the same values for the attributes in this set.Equivalently a superkey can also be defined as a set of attributes of a relation schema upon which all attributes of the schema are functionally dependent. (A superkey always contains a candidate key/a candidate key is always a subset of a superkey. You can add any attribute in a relation to obtain one of the superkeys.)
C'est-à-dire qu'aucun sous-ensemble partiel (tout sous-ensemble non trivial, à l'exception de l'ensemble complet) d'une clé candidate ne peut être fonctionnellement dépendant de rien d'autre qu'une super-clé.
Une table/relation qui n'est pas dans BCNF est sujette à des anomalies telles que les anomalies de mise à jour mentionnées dans l'exemple de pizza par un autre utilisateur. Malheureusement,
- BNCF ne peut pas toujours être obtenu , tant que
- 3NF peut toujours être obtenu .
Exemple 3NF contre BCNF
Un exemple de différence se trouve actuellement dans " table 3NF ne répondant pas à BCNF (forme normale de Boyce – Codd)) " sur Wikipedia, où la table suivante rencontre 3NF mais pas BCNF car "Court de tennis" (un clé partielle/attribut principal) dépend de "Type de tarif" (attribut clé clé/premier qui est et non une super-clé), qui est une dépendance que nous pourrions déterminer en demandant aux clients de la base de données, le club de tennis:
Réservations du terrain de tennis d'aujourd'hui ( 3NF, pas BCNF )
Court Start Time End Time Rate Type
------- ---------- -------- ---------
1 09:30 10:30 SAVER
1 11:00 12:00 SAVER
1 14:00 15:30 STANDARD
2 10:00 11:30 PREMIUM-B
2 11:30 13:30 PREMIUM-B
2 15:00 16:30 PREMIUM-A
Les super clés de la table sont:
S1 = {Court, Start Time}
S2 = {Court, End Time}
S3 = {Rate Type, Start Time}
S4 = {Rate Type, End Time}
S5 = {Court, Start Time, End Time}
S6 = {Rate Type, Start Time, End Time}
S7 = {Court, Rate Type, Start Time}
S8 = {Court, Rate Type, End Time}
ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey
Le problème 3NF : La clé partielle/attribut principal "Court" dépend de quelque chose d'autre qu'une super-clé. Au lieu de cela, il dépend de la clé partielle/attribut principal "Type de tarif". Cela signifie que l'utilisateur doit modifier manuellement le type de tarif si nous mettons à niveau un tribunal, ou le modifier manuellement si vous souhaitez appliquer un changement de tarif.
- Mais que se passe-t-il si l’utilisateur met à niveau le terrain mais ne se souvient pas d’augmenter le tarif? Ou si le mauvais type de taux est appliqué à un tribunal?
(En termes techniques, nous ne pouvons pas garantir que le "Type de tarif" -> "Dépendance fonctionnelle" ne sera pas violé.)
La solution BCNF : Si nous voulons placer la table ci-dessus dans BCNF, nous pouvons décomposer la relation/table donnée en deux relations/tables suivantes (en supposant que sachez que le type de tarif dépend uniquement du tribunal et du statut de membre, ce que nous avons pu découvrir en demandant aux clients de notre base de données, aux propriétaires du club de tennis):
types de taux (BCNF et le 3NF le plus faible, ce qui est supposé par BCNF)
Rate Type Court Member Flag
--------- ----- -----------
SAVER 1 Yes
STANDARD 1 No
PREMIUM-A 2 Yes
PREMIUM-B 2 No
Réservations du terrain de tennis d'aujourd'hui (BCNF et du 3NF le plus faible, comme l'indique BCNF)
Member Flag Court Start Time End Time
----------- ----- ---------- --------
Yes 1 09:30 10:30
Yes 1 11:00 12:00
No 1 14:00 15:30
No 2 10:00 11:30
No 2 11:30 13:30
Yes 2 15:00 16:30
Problème résolu : Maintenant, si nous améliorons le tribunal, nous pouvons garantir que le type de taux reflétera ce changement et que nous ne pourrons pas facturer le mauvais prix pour un tribunal.
(En termes techniques, nous pouvons garantir que la dépendance fonctionnelle "Type de tarif" -> "Tribunal" ne sera pas violée.)
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 de manière fonctionnelle d'une certaine clé candidate.
Les réponses de "smartnut007", "Bill Karwin" et "sqlvogel" sont excellentes. Permettez-moi cependant de vous donner une perspective intéressante.
Eh bien, nous avons des clés principales et non principales.
Lorsque nous nous concentrons sur la manière dont les non-premiers dépendent des nombres premiers, nous voyons deux cas:
Les non-premiers peuvent être dépendants ou non .
- Si dépendant: nous voyons qu'ils doivent dépendre d'une clé candidate complète. C'est 2NF.
Si non dépendant: il peut y avoir une dépendance sans dépendance ou transitive
- Même pas de dépendance transitive: Pas sûr de ce que la théorie de la normalisation aborde ici.
- Lorsque transitoirement dépendant: Il est jugé indésirable. C'est NF.
Qu'en est-il des dépendances entre les premiers?
Vous voyez maintenant que nous ne traitons pas la relation de dépendance entre les nombres premiers par 2e ou 3e NF. De plus, une telle dépendance, le cas échéant, n’est pas souhaitable et nous avons donc une règle unique pour y remédier. C'est BCNF.
En vous référant à l'exemple de l'article de Bill Karwin ici, vous remarquerez que les deux ' Topping ', et ' Le type de topping 'est une clé principale ayant une dépendance. S'ils avaient été non-premiers avec dépendance, alors 3NF serait entré en jeu.
Remarque:
La définition de BCNF est très générique et ne différencie pas les attributs entre premier et non premier. Cependant, la façon de penser ci-dessus aide à comprendre comment certaines anomalies sont percolées même après les 2e et 3e NF.
sujet avancé: mappage de BCNF générique sur 2NF et 3NF
Maintenant que nous savons que BCNF fournit une définition générique sans référence à aucun attribut premier/non premier, voyons comment sont liées BCNF et 2/3 NF.
Premièrement, BCNF exige (en dehors du cas trivial) que pour chaque dépendance fonctionnelle X -> Y (FD), X soit la super-clé. Si vous considérez seulement une FD, nous avons trois cas - (1) X et Y non-premiers, (2) Les deux premiers et (3) X premiers et Y non-premiers, écartant le cas (insensé) X non -prime et Y prime.
Pour le cas (1), 3NF prend en charge.
Pour le cas (3), 2NF prend en charge.
Pour le cas (2), nous trouvons l'utilisation de BCNF
C'est une vieille question avec des réponses valables, mais j'étais toujours un peu confuse jusqu'à ce que je trouve un exemple concret qui montre le problème avec 3NF. Peut-être ne convient-il pas à un enfant de 8 ans, mais espérons que cela aidera.
Demain, je rencontrerai les enseignants de ma fille aînée lors d’une de ces réunions trimestrielles entre parents et enseignants. Voici à quoi ressemble mon journal (les noms et les salles ont été changés):
Teacher | Date | Room
----------|------------------|-----
Mr Smith | 2018-12-18 18:15 | A12
Mr Jones | 2018-12-18 18:30 | B10
Ms Doe | 2018-12-18 18:45 | C21
Ms Rogers | 2018-12-18 19:00 | A08
Il n'y a qu'un seul enseignant par chambre et ils ne bougent jamais. Si vous regardez, vous verrez que: (1) pour chaque attribut Teacher, Date, Room, nous n’avons qu’une valeur par ligne. (2) Les super-clés sont: (Teacher, Date, Room), (Teacher, Date) et (Date, Room) et les clés candidates sont évidemment (Teacher, Date) et (Date, Room).
(Teacher, Room) n'est pas une super-clé car je compléterai le tableau au prochain trimestre et j'aurai peut-être une rangée comme celle-ci (M. Smith n'a pas bougé!):
Teacher | Date | Room
---------|------------------| ----
Mr Smith | 2019-03-19 18:15 | A12
Que pouvons-nous conclure? (1) est une formulation informelle mais correcte de 1NF. Dans (2), nous voyons qu'il n'y a pas "d'attribut non premier": 2NF et 3NF sont donnés gratuitement.
Mon journal est 3NF. Bien! Non, pas vraiment, car aucun modélisateur de données n'accepterait cela dans un schéma de base de données. L'attribut Room dépend de l'attribut Teacher (encore une fois: les enseignants ne bougent pas!), Mais le schéma ne reflète pas ce fait. Que ferait un modélisateur de données sensé? Diviser la table en deux:
Teacher | Date
----------|-----------------
Mr Smith | 2018-12-18 18:15
Mr Jones | 2018-12-18 18:30
Ms Doe | 2018-12-18 18:45
Ms Rogers | 2018-12-18 19:00
Et
Teacher | Room
----------|-----
Mr Smith | A12
Mr Jones | B10
Ms Doe | C21
Ms Rogers | A08
Mais 3NF ne traite pas les dépendances d'attributs principaux. C'est le problème: la conformité 3NF n'est pas suffisante pour assurer une conception de schéma de table sonore dans certaines circonstances.
Avec BCNF, vous ne vous souciez pas de savoir si l'attribut est un attribut principal ou non dans les règles 2NF et 3NF. Pour chaque dépendance non triviale (les sous-ensembles sont évidemment déterminés par leurs sur-ensembles), le déterminant est une super clé complète. En d'autres termes, rien n'est déterminé par autre chose qu'une super clé complète (à l'exception des FD triviales). (Voir autres réponses pour la définition formelle).
Dès que Room dépend de Teacher, Room doit être un sous-ensemble de Teacher (ce n'est pas le cas) ou Teacher doit être une super clé (c'est pas le cas dans mon journal, mais c'est le cas lorsque vous divisez la table).
Pour résumer: BNCF est plus strict, mais à mon avis plus facile à comprendre que 3NF:
- dans la plupart des cas, BCNF est identique à 3NF;
- dans d'autres cas, BCNF est ce que vous pensez/espérez que 3NF est.