Differenza tra 3NF e BCNF in termini semplici (deve essere in grado di spiegare a un bambino di 8 anni)


157

Ho letto la citazione: i dati dipendono dalla chiave [1NF], l'intera chiave [2NF] e nient'altro che la chiave [3NF] .

Tuttavia, ho difficoltà a comprendere 3.5NF o BCNF come viene chiamato. Ecco cosa ho capito:

  • BCNF è più rigoroso di 3NF
  • il lato sinistro di qualsiasi FD nella tabella deve essere un superkey (o almeno una chiave candidata)

Allora perché è che alcune tabelle 3NF non sono in BCNF? Voglio dire, la citazione di 3NF dice esplicitamente "nient'altro che la chiave", il che significa che tutti gli attributi dipendono esclusivamente dalla chiave primaria. Dopo tutto, la chiave primaria è una chiave candidata fino a quando non viene scelta come chiave primaria.

Se qualcosa non va per quanto riguarda la mia comprensione finora, per favore correggimi e grazie per l'aiuto che puoi fornire.


Questo è un sentimento così strano che solo un libro di testo pubblicato potrebbe fornire una descrizione concisa e accurata di un concetto. Se guardi le risposte a questa (davvero vecchia) domanda, vedrai che nessuna delle più votate è vaga o imprecisa. Avere una definizione algebrica non era il problema, capire il concetto attraverso esempi del mondo reale lo era. Per quanto riguarda la citazione nella mia domanda originale, google "così aiutami Codd" per trovare l'origine delle citazioni. Non c'è nulla di vago al riguardo.
Arnab Datta,

1
Da dove pensi che le fonti non di libri di testo ottengano le loro informazioni? Ci sono anche molti libri di testo poveri, ma i libri di testo vengono esaminati da più persone con apprendistato accademico e hanno molte più probabilità di non avere senso rispetto alle interpretazioni di altri libri di testo. Le valutazioni elevate da parte di persone non informate e male informate non fanno qualcosa di corretto. Ho messo quel commento lì per le persone che sono arrivate alla tua domanda. Quella frase "nient'altro che la chiave" è meno che inutile. Avere una definizione corretta è sicuramente il problema, perché "comprendere il concetto" è impossibile senza uno.
philipxy,

Risposte:


162

La tua pizza può avere esattamente tre tipi di topping:

  • un tipo di formaggio
  • un tipo di carne
  • un tipo di verdura

Quindi ordiniamo due pizze e scegliamo i seguenti condimenti:

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

Aspetta un secondo, la mozzarella non può essere sia un formaggio che una carne! E la salsiccia non è un formaggio!

Dobbiamo prevenire questo tipo di errori, per rendere la mozzarella sempre un formaggio. Dovremmo usare una tabella separata per questo, quindi annotiamo quel fatto in un solo posto.

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

Questa era la spiegazione che un bambino di 8 anni poteva capire. Ecco la versione più tecnica.

BCNF agisce diversamente da 3NF solo quando sono presenti più chiavi candidate sovrapposte.

Il motivo è che la dipendenza funzionale X -> Yè ovviamente vera se Yè un sottoinsieme di X. Quindi in qualsiasi tabella che ha una sola chiave candidata ed è in 3NF, è già presente in BCNF perché non esiste una colonna (chiave o non chiave) che sia funzionalmente dipendente da qualsiasi cosa oltre a quella chiave.

Poiché ogni pizza deve avere esattamente uno di ogni tipo di topping, sappiamo che (Pizza, Topping Type) è una chiave candidata. Sappiamo anche intuitivamente che un determinato topping non può appartenere contemporaneamente a tipi diversi. Quindi (Pizza, Topping) deve essere unico e quindi è anche una chiave candidata. Quindi abbiamo due chiavi candidate sovrapposte.

Ho mostrato un'anomalia in cui abbiamo contrassegnato la mozarella come il tipo di topping sbagliato. Sappiamo che questo è sbagliato, ma la regola che lo rende sbagliato è una dipendenza Topping -> Topping Typeche non è una dipendenza valida per BCNF per questa tabella. È una dipendenza da qualcosa di diverso da un'intera chiave candidata.

Quindi, per risolvere questo problema, prendiamo Topping Type dalla tabella Pizzas e lo rendiamo un attributo non chiave in una tabella Toppings.


3
"È una dipendenza da qualcosa di diverso da un'intera chiave candidata." - Grazie
gnsb il

12
"Quindi in qualsiasi tabella che ha una sola chiave candidata ed è in 3NF" - Non del tutto. L'esempio che fai soddisfa questa condizione. Tuttavia, non è un esempio 3NF perché non è 2NF. La chiave (1NF), l'intera chiave (2NF) e nient'altro che la chiave (3NF). La chiave è (Pizza, Topping) e la colonna ToppingType dipende dalla chiave e nient'altro che la chiave, ma non dipende dall'intera chiave. Quindi non è 2NF, e quindi non 3NF o BCNF. È 1NF. Rendendolo 2NF si aggirerebbe il problema che si sta tentando di illustrare.
Daniel Barbalace,

4
@DanielBarbalace, Il punto di questa tabella è che ha una chiave candidata alternativa per questa tabella: (Pizza, ToppingType). Poiché ToppingType è un sottoinsieme di quella chiave candidata, soddisfa 2NF.
Bill Karwin,

6
Mi dispiace, ho dovuto ridimensionarlo. L'esempio che hai mostrato non è in 3NF. Per capire lo scopo di BCNF, devo vedere un esempio in cui si trova in 3NF ma non in BCNF. In questo momento, non vedo lo scopo di BCNF.
Spero,

5
Perché questo NON è già gestito in 2NF? Dal mio punto di vista, la chiave primaria della tabella originale è Pizza + Topping e Topping Type dipende da Topping, quindi non è una dipendenza parziale che dovrebbe essere curata nella fase 2NF?
GreenPenguin

91

La sottile differenza è che 3NF fa una distinzione tra attributi chiave e non chiave (chiamati anche attributi non primi ) mentre BCNF no.

Questo è meglio spiegato usando la definizione di 3NF di Zaniolo , che è equivalente a quella di Codd:

Una relazione, R, è in 3NF iff per ogni FD non banale (X-> A) soddisfatta da R almeno una delle seguenti condizioni è vera:

(a) X è un superkey per R o

(b) A è un attributo chiave per R

BCNF richiede (a) ma non tratta (b) come un caso speciale a sé stante. In altre parole, BCNF richiede che ogni determinante non banale sia una superkey anche se i suoi attributi dipendenti fanno parte di una chiave.

Una relazione, R, è in BCNF iff per ogni FD non banale (X-> A) soddisfatto da R è vera la seguente condizione:

(a) X è un superkey per R

BCNF è quindi più severo.

La differenza è così sottile che ciò che molte persone descrivono in modo informale come 3NF è in realtà BCNF. Ad esempio, hai affermato qui che 3NF significa "i dati dipendono dalla chiave [s] ... e nient'altro che la chiave [s]", ma questa è in realtà una descrizione informale di BCNF e non 3NF. 3NF potrebbe essere descritto più accuratamente come " i dati non chiave dipendono dalle chiavi ... e nient'altro che le chiavi".

Hai anche dichiarato:

la citazione 3NF dice esplicitamente "nient'altro che la chiave", il che significa che tutti gli attributi dipendono esclusivamente dalla chiave primaria.

Questa è una semplificazione eccessiva. 3NF e BCNF e tutte le forme normali riguardano tutte le chiavi candidate e / o le superkey, non solo una chiave "primaria".


7
Wow. Il Prof. Zaniolo insegna effettivamente la mia classe (CS 143, UCLA) e mi sono imbattuto in questa risposta mentre mi preparavo per l'esame finale. Fantastico vedere il nome del mio prof, e grazie per la risposta dettagliata!
DV.

potresti dare un esempio di una relazione che è in 3NF ma non in BCNF? è difficile per me immaginare ...
Leo

10
R {A, B, C} dove {A, B} è una chiave. Data la dipendenza C-> B, R soddisfa i requisiti di 3NF ma non BCNF.
nvogel

2
Chiave significa chiave candidata. Attributo chiave indica un attributo che fa parte di una chiave candidata, AKA un attributo primo .
nvogel,

3
Un attributo è primo se fa parte di una chiave candidata; non primo se non fa parte di alcuna chiave candidata.
nvogel,

26

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

  1. Un attributo primo è un attributo trovato in una chiave candidata e
  2. Una chiave candidata è una superkey minima per quella relazione e
  3. 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.)


6

Tutte buone risposte. Per dirla in un linguaggio semplice [BCNF] Nessuna chiave parziale può dipendere da una chiave.

cioè Nessun sottoinsieme parziale (cioè qualsiasi sottoinsieme non banale tranne il set completo) di una chiave candidata può essere funzionalmente dipendente da una chiave candidata.


2
Perchè no? Supponiamo che ci sia una relazione R (A, B, C, D, E) e (A, B) e (C, D) sono chiavi candidate. Quindi AB-> D. Poiché AB è un superkey di R, quindi R dovrebbe essere in BCNF, giusto? (Solo una domanda, cercando di capirlo.)
Peteykun,

3

Le risposte di " smartnut007 ", " Bill Karwin " e " sqlvogel " sono eccellenti. Tuttavia, lasciatemi mettere una prospettiva interessante ad esso.

Bene, abbiamo chiavi prime e non prime.

Quando ci concentriamo su come i non primi dipendono dai numeri primi, vediamo due casi:

I non primi possono essere dipendenti o meno .

  • Quando dipendente: vediamo che devono dipendere da una chiave candidata completa. Questo è 2NF .
  • Quando non dipendente: può esserci assenza di dipendenza o dipendenza transitiva

    • Neanche dipendenza transitiva: non sono sicuro di quale teoria della normalizzazione si rivolga a questo.
    • In caso di dipendenza transitoria: è ritenuto indesiderabile. Questo è 3NF .

Che dire delle dipendenze tra numeri primi?

Ora vedete, non stiamo affrontando la relazione di dipendenza tra numeri primi né dal 2o al 3o NF. Ulteriori eventuali dipendenze, se presenti, non sono auspicabili e quindi abbiamo un'unica regola per risolverle. Questo è BCNF .

Facendo riferimento all'esempio del post di Bill Karwin qui, noterai che sia " Topping ", sia " Topping Type " sono chiavi primarie e hanno una dipendenza. Se fossero stati non primi con dipendenza, allora 3NF avrebbe dato il via.

Nota:

La definizione di BCNF è molto generica e senza attributi differenziati tra prime e non prime. Tuttavia, il modo di pensare di cui sopra aiuta a capire come un'anomalia viene percolata anche dopo il 2 ° e il 3 ° NF.

Argomento avanzato: Mappatura di BCNF generico su 2NF e 3NF

Ora che sappiamo che BCNF fornisce una definizione generica senza riferimento ad alcun attributo primo / non primo, vediamo come sono collegati BCNF e 2/3 NF.

In primo luogo, BCNF richiede (oltre al caso banale) quello per ogni dipendenza funzionale X -> Y (FD), X sia una super chiave. Se prendi in considerazione qualsiasi FD, allora abbiamo tre casi: (1) Sia X che Y non primi, (2) Entrambi primi e (3) X primi e Y non primi, scartando il caso (senza senso) X non -prime e Y prime.

Per il caso (1), 3NF si occupa di.

Per il caso (3), 2NF si occupa di.

Per il caso (2), troviamo l'uso di BCNF


3

Questa è una vecchia domanda con risposte preziose, ma ero ancora un po 'confuso fino a quando non ho trovato un esempio di vita reale che mostra il problema con 3NF. Forse non adatto a un bambino di 8 anni, ma spero che sia di aiuto.

Domani incontrerò gli insegnanti della mia figlia maggiore in una di quelle riunioni trimestrali tra genitori / insegnanti. Ecco come appare il mio diario (nomi e stanze sono stati cambiati):

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 

C'è solo un insegnante per stanza e non si muovono mai. Se si dispone di uno sguardo, vedrete che: (1) per ogni attributo Teacher, Date, Room, abbiamo solo un valore per riga. -Keys super (2) sono le seguenti: (Teacher, Date, Room), (Teacher, Date)e (Date, Room)e chiavi candidate sono ovviamente (Teacher, Date)e (Date, Room).

(Teacher, Room) non è un superkey perché completerò il tavolo il prossimo trimestre e potrei avere una fila come questa (il signor Smith non si è mosso!):

Teacher  | Date             | Room
---------|------------------| ----
Mr Smith | 2019-03-19 18:15 | A12

Cosa possiamo concludere? (1) è una formulazione informale ma corretta di 1NF. Da (2) vediamo che non esiste un "attributo non primo": 2NF e 3NF sono dati gratuitamente.

Il mio diario è 3NF. Buona! No. Non proprio perché nessun modellatore di dati lo accetterebbe in uno schema DB. L' Roomattributo dipende Teacherdall'attributo (di nuovo: gli insegnanti non si muovono!) Ma lo schema non riflette questo fatto. Cosa farebbe un modellatore di dati sano? Dividi la tabella in due:

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

E

Teacher   | Room
----------|-----
Mr Smith  | A12
Mr Jones  | B10
Ms Doe    | C21
Ms Rogers | A08

Ma 3NF non si occupa delle dipendenze degli attributi primi. Questo è il problema: la conformità 3NF non è sufficiente per garantire una buona progettazione dello schema di tabelle in alcune circostanze.

Con BCNF, non ti importa se l'attributo è un attributo primo o meno nelle regole 2NF e 3NF. Per ogni dipendenza non banale (i sottoinsiemi sono ovviamente determinati dai loro superset), il determinante è una super chiave completa. In altre parole, nulla è determinato da qualcos'altro che una super chiave completa (esclusi i banali FD). (Vedi altre risposte per la definizione formale).

Non appena Roomdipende Teacher, Roomdeve essere un sottoinsieme di Teacher(non è il caso) o Teacherdeve essere una super chiave (non è il caso nel mio diario, ma è il caso quando dividi il tavolo).

Riassumendo: BNCF è più rigoroso, ma a mio avviso più facile da capire, rispetto a 3NF:

  • nella maggior parte dei casi, BCNF è identico a 3NF;
  • in altri casi, BCNF è ciò che pensi / speri che sia 3NF.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.