Diferencia entre 3NF y BCNF en términos simples (debe poder explicar a un niño de 8 años)

He leído la cita: los datos dependen de la clave [1NF], la clave completa [2NF] y nada más que la clave [3NF] .

Sin embargo, tengo problemas para entender 3.5NF o BCNF como se llama. Esto es lo que entiendo:

• BCNF es más estricto que 3NF
• el lado izquierdo de cualquier FD en la tabla debe ser una superclave (o al menos una clave candidata)

Entonces, ¿por qué entonces algunas tablas 3NF no están en BCNF? Quiero decir, la cita de 3NF dice explícitamente "nada más que la clave", lo que significa que todos los atributos dependen únicamente de la clave primaria. La clave principal es, después de todo, una clave candidata hasta que se elija como nuestra clave principal.

Si algo está mal con respecto a mi comprensión hasta ahora, corríjame y gracias por cualquier ayuda que pueda proporcionar.

Su pizza puede tener exactamente tres tipos de cobertura:

• un tipo de queso
• un tipo de carne
• un tipo de verdura

Así que pedimos dos pizzas y elegimos los siguientes ingredientes:

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

¡Espera un segundo, la mozzarella no puede ser tanto un queso como una carne! ¡Y la salchicha no es un queso!

Necesitamos evitar este tipo de errores, para hacer que la mozzarella sea siempre queso. Deberíamos usar una tabla separada para esto, así que anotamos ese hecho en un solo lugar.

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

Esa fue la explicación que un niño de 8 años podría entender. Aquí está la versión más técnica.

BCNF actúa de manera diferente a 3NF solo cuando hay varias claves candidatas superpuestas.

La razón es que la dependencia funcional X -> Yes, por supuesto, verdadera si Yes un subconjunto de X. Entonces, en cualquier tabla que tenga solo una clave candidata y esté en 3NF, ya está en BCNF porque no hay una columna (clave o no clave) que sea funcionalmente dependiente de cualquier cosa además de esa clave.

Debido a que cada pizza debe tener exactamente uno de cada tipo de cobertura, sabemos que (Pizza, Tipo de cobertura) es una clave candidata. También sabemos intuitivamente que un topping dado no puede pertenecer a diferentes tipos simultáneamente. Entonces (Pizza, Topping) debe ser único y, por lo tanto, también es una clave candidata. Entonces tenemos dos claves candidatas superpuestas.

Mostré una anomalía en la que marcamos a mozarella como el tipo de cobertura incorrecto. Sabemos que esto está mal, pero la regla que lo hace mal es una dependencia Topping -> Topping Typeque no es una dependencia válida para BCNF para esta tabla. Es una dependencia de algo más que una clave candidata completa.

Entonces, para resolver esto, sacamos el Tipo de relleno de la tabla Pizzas y lo convertimos en un atributo no clave en una tabla de Toppings.

La sutil diferencia es que 3NF hace una distinción entre atributos clave y no clave (también llamados atributos no primos ) mientras que BCNF no.

Esto se explica mejor utilizando la definición de 3NF de Zaniolo, que es equivalente a la de Codd:

Una relación, R, está en 3NF iff por cada FD no trivial (X-> A) satisfecho por R, al menos UNA de las siguientes condiciones es verdadera:

(a) X es una superclave para R, o

(b) A es un atributo clave para R

BCNF requiere (a) pero no trata (b) como un caso especial propio. En otras palabras, BCNF requiere que cada determinante no trivial sea una superclave, incluso sus atributos dependientes forman parte de una clave.

Una relación, R, está en BCNF si para cada FD no trivial (X-> A) satisfecha por R, la siguiente condición es verdadera:

(a) X es una superclave para R

BCNF es por lo tanto más estricto.

La diferencia es tan sutil que lo que muchas personas describen informalmente como 3NF es en realidad BCNF. Por ejemplo, usted indicó aquí que 3NF significa "los datos dependen de la clave [s] ... y nada más que la clave [s]", pero esa es realmente una descripción informal de BCNF y no de 3NF. 3NF podría describirse con mayor precisión como " los datos no clave dependen de las claves ... y nada más que las claves".

También dijiste:

la cita de 3NF dice explícitamente "nada más que la clave", lo que significa que todos los atributos dependen únicamente de la clave primaria.

Eso es una simplificación excesiva. 3NF y BCNF y todas las formas normales se refieren a todas las claves y / o superclaves candidatas, no solo a una clave "primaria".

La diferencia entre BCNF y 3NF

Usando la definición BCNF

Si y solo si para cada una de sus dependencias X → Y, se cumple al menos una de las siguientes condiciones :

• X → Y es una dependencia funcional trivial (Y ⊆ X), o
• X es una súper clave para el esquema R

y la definición 3NF

Si y solo si, para cada una de sus dependencias funcionales X → A, se cumple al menos una de las siguientes condiciones:

• X contiene A (es decir, X → A es una dependencia funcional trivial), o
• X es una superclave, o
• Cada elemento de AX, la diferencia establecida entre A y X, es un atributo principal (es decir, cada atributo en AX está contenido en alguna clave candidata)

Vemos la siguiente diferencia, en términos simples:

• En BCNF : cada clave parcial (atributo principal) solo puede depender de una superclave,

mientras

• En 3NF : una clave parcial (atributo principal) también puede depender de un atributo que no es una superclave (es decir, otra clave parcial / atributo principal o incluso un atributo no principal).

Dónde

1. Un atributo principal es un atributo que se encuentra en una clave candidata y
2. Una clave candidata es una superclave mínima para esa relación, y
3. Una superclave es un conjunto de atributos de una variable de relación para la cual se sostiene que en todas las relaciones asignadas a esa variable, no hay dos tuplas (filas) distintas que tengan los mismos valores para los atributos en este conjunto. se define como un conjunto de atributos de un esquema de relación del cual todos los atributos del esquema dependen funcionalmente. (Una superclave siempre contiene una clave candidata / una clave candidata es siempre un subconjunto de una superclave. Puede agregar cualquier atributo en una relación para obtener una de las superclaves).

Es decir, ningún subconjunto parcial (cualquier subconjunto no trivial excepto el conjunto completo) de una clave candidata puede depender funcionalmente de otra cosa que no sea una superclave.

Una tabla / relación que no está en BCNF está sujeta a anomalías como las anomalías de actualización mencionadas en el ejemplo de pizza por otro usuario. Desafortunadamente,

• BNCF no siempre se puede obtener , mientras
• 3NF siempre se puede obtener .

Ejemplo 3NF versus BCNF

Un ejemplo de la diferencia se puede encontrar actualmente en la " tabla 3NF que no cumple con BCNF (forma normal de Boyce-Codd) " en Wikipedia, donde la siguiente tabla cumple con 3NF pero no BCNF porque "Cancha de tenis" (una clave parcial / atributo principal) depende en "Tipo de tasa" (una clave parcial / atributo principal que no es una superclave), que es una dependencia que podríamos determinar preguntando a los clientes de la base de datos, el club de tenis:

Reservas de canchas de tenis de hoy ( 3NF, no 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

Las superclaves de la tabla son:

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

El problema 3NF : La clave parcial / atributo principal "Court" depende de algo más que una superclave. En cambio, depende de la clave parcial / atributo principal "Tipo de tasa". Esto significa que el usuario debe cambiar manualmente el tipo de tarifa si mejoramos una cancha, o cambiar la cancha manualmente si desea aplicar un cambio de tarifa.

• Pero, ¿qué sucede si el usuario actualiza la cancha pero no recuerda aumentar la tarifa? ¿O qué sucede si se aplica el tipo de tarifa incorrecto a un tribunal?

(En términos técnicos, no podemos garantizar que no se viole la dependencia funcional "Tipo de tarifa" -> "Corte").

La solución de BCNF : si queremos ubicar la tabla anterior en BCNF, podemos descomponer la relación / tabla dada en las siguientes dos relaciones / tablas (suponiendo que sepamos que el tipo de tasa depende solo del estado de la corte y de la membresía, lo cual podríamos descubra preguntando a los clientes de nuestra base de datos, los propietarios del club de tenis):

Tipos de tasa ( BCNF y el 3NF más débil, que implica BCNF)

Rate Type   Court   Member Flag
---------   -----   -----------
SAVER       1       Yes
STANDARD    1       No
PREMIUM-A   2       Yes
PREMIUM-B   2       No

Reservas de canchas de tenis de hoy ( BCNF y el 3NF más débil, que está implícito en 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 resuelto : ahora, si mejoramos el tribunal, podemos garantizar que el tipo de tarifa reflejará este cambio, y no podemos cobrar el precio incorrecto por un tribunal.

(En términos técnicos, podemos garantizar que no se violará la dependencia funcional "Tipo de tarifa" -> "Tribunal").

Todas buenas respuestas. Para ponerlo en un lenguaje simple [BCNF] Ninguna clave parcial puede depender de una clave.

es decir, ningún subconjunto parcial (es decir, cualquier subconjunto no trivial excepto el conjunto completo) de una clave candidata puede depender funcionalmente de alguna clave candidata.

Las respuestas de ' smartnut007 ', ' Bill Karwin ' y ' sqlvogel ' son excelentes. Sin embargo, déjame ponerle una perspectiva interesante.

Bueno, tenemos claves prime y no prime.

Cuando nos centramos en cómo los no primos dependen de los primos, vemos dos casos:

Los no primos pueden ser dependientes o no .

• Cuando dependen: vemos que deben depender de una clave candidata completa. Esto es 2NF .

• Cuando no es dependiente: puede haber no dependencia o dependencia transitiva

  • Ni siquiera dependencia transitiva: no estoy seguro de qué teoría de normalización aborda esto.
  • Cuando depende transitivamente: se considera indeseable. Esto es 3NF .

¿Qué pasa con las dependencias entre primos?

Ahora puede ver, no estamos abordando la relación de dependencia entre los números primos por segundo o tercer NF. Además, dicha dependencia, si la hay, no es deseable y, por lo tanto, tenemos una sola regla para abordar eso. Esto es BCNF .

Refiriéndose al ejemplo de la publicación de Bill Karwin aquí, notará que tanto ' Topping ' como ' Topping Type ' son claves principales y tienen una dependencia. Si hubieran sido no primos con dependencia, entonces 3NF habría intervenido.

Nota:

La definición de BCNF es muy genérica y sin atributos diferenciadores entre primos y no primos. Sin embargo, la forma de pensar anterior ayuda a comprender cómo se filtra alguna anomalía incluso después del 2º y 3º NF.

Tema avanzado: asignación de BCNF genérico a 2NF y 3NF

Ahora que sabemos que BCNF proporciona una definición genérica sin referencia a ningún atributo principal / no principal, veamos cómo se relacionan BCNF y 2/3 NF.

Primero, BCNF requiere (además del caso trivial) que para cada dependencia funcional X -> Y (FD), X sea una súper clave. Si considera cualquier FD, tenemos tres casos: (1) X e Y no primos, (2) Ambos primos y (3) X primos e Y no primos, descartando el caso (sin sentido) X no -prime y Y prime.

Para el caso (1), 3NF se encarga.

Para el caso (3), 2NF se encarga.

Para el caso (2), encontramos el uso de BCNF

Esta es una vieja pregunta con respuestas valiosas, pero todavía estaba un poco confundido hasta que encontré un ejemplo de la vida real que muestra el problema con 3NF. Quizás no sea adecuado para un niño de 8 años, pero espero que ayude.

Mañana me reuniré con los maestros de mi hija mayor en una de esas reuniones trimestrales de padres / maestros. Así es como se ve mi diario (se han cambiado los nombres y las habitaciones):

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 

Solo hay un maestro por salón y nunca se mueven. Si usted tiene un vistazo, podrás ver que: (1) para cada atributo Teacher, Date, Room, tenemos un solo valor por fila. (2) Grandes teclas son: (Teacher, Date, Room), (Teacher, Date)y (Date, Room)las teclas y candidatos son, evidentemente, (Teacher, Date)y (Date, Room).

_{(Teacher, Room) no es una superclave porque completaré la tabla el próximo trimestre y es posible que tenga una fila como esta (¡el Sr. Smith no se movió!):}

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

¿Qué podemos concluir? (1) es una formulación informal pero correcta de 1NF. De (2) vemos que no hay un "atributo no primo": 2NF y 3NF se dan de forma gratuita.

Mi diario es 3NF. ¡Bueno! No. No realmente porque ningún modelador de datos aceptaría esto en un esquema de base de datos. El Roomatributo depende del Teacheratributo (de nuevo: ¡los maestros no se mueven!), Pero el esquema no refleja este hecho. ¿Qué haría un modelador de datos sensato? Divide la mesa en dos:

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

Y

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

Pero 3NF no trata con dependencias de atributos principales. Este es el problema: el cumplimiento de 3NF no es suficiente para garantizar un diseño de esquema de tabla de sonido en algunas circunstancias.

Con BCNF, no le importa si el atributo es un atributo principal o no en las reglas 2NF y 3NF. Para cada dependencia no trivial (los subconjuntos obviamente están determinados por sus superconjuntos), el determinante es una súper clave completa. En otras palabras, nada está determinado por algo más que una súper clave completa (excluyendo FD triviales). (Ver otras respuestas para la definición formal).

Tan pronto como Roomdependa Teacher, Roomdebe ser un subconjunto de Teacher(ese no es el caso) o Teacherdebe ser una súper clave (ese no es el caso en mi diario, pero ese es el caso cuando divide la tabla).

Para resumir: BNCF es más estricto, pero en mi opinión más fácil de entender, que 3NF:

• en la mayoría de los casos, BCNF es idéntico a 3NF;
• en otros casos, BCNF es lo que piensas / esperas que sea 3NF.