La differenza tra BCNF e 3NF
Usando la definizione BCNF
Se e solo se per ciascuna delle sue dipendenze X → Y, vale almeno una delle seguenti condizioni :
- X → Y è una banale dipendenza funzionale (Y ⊆ X), oppure
- X è una super chiave per lo schema R
e la definizione 3NF
Se e solo se, per ciascuna delle sue dipendenze funzionali X → A, vale almeno una delle seguenti condizioni:
- X contiene A (ovvero X → A è banale dipendenza funzionale), oppure
- X è un superkey o
- Ogni elemento di AX, la differenza impostata tra A e X, è un attributo primo (ovvero, ogni attributo in AX è contenuto in una chiave candidata)
Vediamo la seguente differenza, in termini semplici:
- In BCNF : ogni chiave parziale (attributo primo) può dipendere solo da una superkey,
mentre
- In 3NF : una chiave parziale (attributo primo) può anche dipendere da un attributo che non è una superchiave (cioè un altro attributo chiave / primo parziale o anche un attributo non primo).
Dove
- Un attributo primo è un attributo trovato in una chiave candidata e
- Una chiave candidata è una superkey minima per quella relazione e
- Un superkey è un insieme di attributi di una variabile di relazione per il quale sostiene che in tutte le relazioni assegnate a quella variabile, non ci sono due tuple (righe) distinte che hanno gli stessi valori per gli attributi in questo set. In alternativa un superkey può anche essere definito come un insieme di attributi di uno schema di relazione dal quale tutti gli attributi dello schema sono funzionalmente dipendenti. (Una superkey contiene sempre una chiave candidata / una chiave candidata è sempre un sottoinsieme di una superkey. Puoi aggiungere qualsiasi attributo in una relazione per ottenere una delle superkey.)
In altre parole, nessun sottoinsieme parziale (qualsiasi sottoinsieme non banale eccetto il set completo) di una chiave candidata può essere funzionalmente dipendente da qualcosa di diverso da un superkey.
Una tabella / relazione non in BCNF è soggetta ad anomalie come le anomalie di aggiornamento menzionate nell'esempio della pizza da un altro utente. Sfortunatamente,
- BNCF non può sempre essere ottenuto , mentre
- 3NF può sempre essere ottenuto .
3NF contro BCNF Esempio
Un esempio della differenza è attualmente disponibile nella " tabella 3NF che non soddisfa BCNF (modulo normale di Boyce – Codd) " su Wikipedia, dove la tabella seguente soddisfa 3NF ma non BCNF perché "Campo da tennis" (una chiave parziale / attributo primo) dipende su "Tipo di tariffa" (una chiave parziale / attributo primo che non è una superkey), che è una dipendenza che potremmo determinare chiedendo ai clienti del database, il tennis club:
Prenotazioni del campo da tennis di oggi ( 3NF, non 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
Le superkey del tavolo sono:
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
Il problema 3NF : l'attributo chiave parziale / primo "Corte" dipende da qualcosa di diverso da un superkey. Al contrario, dipende dalla chiave parziale / attributo primo "Tipo di tariffa". Ciò significa che l'utente deve modificare manualmente il tipo di tariffa se si aggiorna un tribunale o modificare manualmente il tribunale se si desidera applicare una variazione di tasso.
- Ma cosa succede se l'utente aggiorna il campo ma non ricorda di aumentare la tariffa? O se si applica un tipo di tariffa errato a un tribunale?
(In termini tecnici, non possiamo garantire che la dipendenza funzionale "Tipo di tariffa" -> "Corte" non venga violata.)
La soluzione BCNF : Se vogliamo posizionare la tabella sopra in BCNF, possiamo scomporre la relazione / tabella data nelle seguenti due relazioni / tabelle (supponendo che sappiamo che il tipo di tariffa dipende solo dallo stato del tribunale e dell'iscrizione, che potremmo scoprire chiedendo ai clienti del nostro database, i proprietari del tennis club):
Tipi di tasso ( BCNF e 3NF più debole, che è implicato da BCNF)
Rate Type Court Member Flag
--------- ----- -----------
SAVER 1 Yes
STANDARD 1 No
PREMIUM-A 2 Yes
PREMIUM-B 2 No
Le attuali prenotazioni dei campi da tennis ( BCNF e il 3NF più debole, implicato dal 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
Problema risolto : ora se eseguiamo l'upgrade del tribunale possiamo garantire che il tipo di tariffa rifletterà questa modifica e non possiamo addebitare il prezzo sbagliato per un tribunale.
(In termini tecnici, possiamo garantire che la dipendenza funzionale "Tipo di tariffa" -> "Corte" non sarà violata.)