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 AX, la différence d'ensemble entre A et X, est un attribut principal (c'est-à-dire que chaque attribut de AX est contenu dans une clé candidate)
Nous voyons la différence suivante, en termes simples:
- En BCNF : chaque clé partielle (attribut principal) ne peut dépendre que d'une super-clé,
tandis que
- Dans 3NF : Une clé partielle (attribut premier) peut également dépendre d'un attribut qui n'est pas une super-clé (c'est-à-dire une autre clé partielle / attribut principal ou même un attribut non premier).
Où
- Un attribut primordial est un attribut trouvé dans une clé candidate, et
- Une clé candidate est une super- minimale pour cette relation, et
- Une super - clé est un ensemble d'attributs d'une variable de relation pour laquelle il considère que dans toutes les relations affectées à cette variable, il n'y a pas deux tuples (lignes) distincts qui ont les mêmes valeurs pour les attributs de cet ensemble. être défini comme un ensemble d'attributs d'un schéma de relation dont tous les attributs du schéma dépendent fonctionnellement. (Une super-clé contient toujours une clé candidate / une clé candidate est toujours un sous-ensemble d'une super-clé. Vous pouvez ajouter n'importe quel attribut dans une relation pour obtenir l'une des super-clés.)
Autrement dit, 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 quoi que ce soit d'autre qu'une super-clé.
Une table / relation hors 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 , alors que
- 3NF peut toujours être obtenu .
Exemple 3NF contre BCNF
Un exemple de la différence peut actuellement être trouvé à " Table 3NF ne respectant pas BCNF (Boyce – Codd normal form) " sur Wikipedia, où le tableau suivant rencontre 3NF mais pas BCNF car "Tennis Court" (un attribut clé / prime partiel) dépend sur "Rate Type" (un attribut clé / prime partiel qui n'est pas 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 de courts 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-touches 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 : l'attribut clé / prime partielle "Court" dépend de quelque chose d'autre qu'une super-clé. Au lieu de cela, il dépend de l'attribut clé / prime partiel "Type de taux". Cela signifie que l'utilisateur doit modifier manuellement le type de taux si nous améliorons un terrain, ou changer manuellement le terrain s'il souhaite appliquer un changement de taux.
- Mais que se passe-t-il si l'utilisateur met à niveau le court mais ne se souvient pas d'augmenter le taux? Ou que faire si le mauvais type de taux est appliqué à un tribunal?
(En termes techniques, nous ne pouvons pas garantir que la dépendance fonctionnelle "Type de tarif" -> "Cour" ne sera pas violée.)
La solution BCNF : Si nous voulons placer le tableau ci-dessus dans BCNF, nous pouvons décomposer la relation / table donnée en les deux relations / tables suivantes (en supposant que nous savons que le type de taux dépend uniquement du tribunal et du statut de membre, ce que nous pourrions découvrir en demandant aux clients de notre base de données, les propriétaires du club de tennis):
Types de taux ( BCNF et le 3NF plus faible, ce qui est impliqué par BCNF)
Rate Type Court Member Flag
--------- ----- -----------
SAVER 1 Yes
STANDARD 1 No
PREMIUM-A 2 Yes
PREMIUM-B 2 No
Réservations de courts de tennis d'aujourd'hui ( BCNF et le 3NF plus faible, ce qui est impliqué par 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 terrain, nous pouvons garantir que le type de taux reflétera ce changement, et nous ne pouvons pas facturer le mauvais prix pour un terrain.
(En termes techniques, nous pouvons garantir que la dépendance fonctionnelle "Type de tarif" -> "Cour" ne sera pas violée.)