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

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.

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.

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".

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.)

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.

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

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.