database - learning - Diferencia entre 3NF y BCNF en términos simples(debe ser capaz de explicar a un niño de 8 años)

normalization ingles (5)

La diferencia entre BCNF y 3NF

Usando la definición de 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), y
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 tecla 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 sea una superclave (es decir, otra clave parcial / atributo principal o incluso un atributo no principal).

Dónde

Un atributo principal es un atributo encontrado en una clave candidata, y
Una clave candidata es una superclave mínima para esa relación, y
Una superkey es un conjunto de atributos de una variable de relación para la cual 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. Igualmente, una superclave también puede se define como un conjunto de atributos de un esquema de relación sobre el cual todos los atributos del esquema son funcionalmente dependientes. (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 superkeys).

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

Una tabla / relación que no está en BCNF está sujeta a anomalías tales 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 de 3NF frente a BCNF

Un ejemplo de la diferencia puede encontrarse actualmente en " tabla 3NF que no cumple con BCNF (forma normal Boyce-Codd) " en Wikipedia, donde la siguiente tabla cumple 3NF pero no BCNF porque "Pista de tenis" (un atributo clave / principal parcial) depende en "Tipo de tasa" (un atributo clave / principal parcial que no es una superclave), que es una dependencia que podríamos determinar al preguntar 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 superkeys de la mesa 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 : el atributo clave / principal parcial "Corte" depende de algo que no sea una superclave. En cambio, depende del atributo clave / principal parcial "Tipo de velocidad". Esto significa que el usuario debe cambiar manualmente el tipo de tarifa si actualizamos un tribunal, o cambiar manualmente el tribunal si desea aplicar un cambio de tarifa.

Pero, ¿qué sucede si el usuario mejora la cancha pero no recuerda aumentarla? ¿O qué pasa si se aplica un tipo de tarifa erróneo a un tribunal?

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

La solución de BCNF : si queremos colocar 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 únicamente del tribunal y del estado de membresía, lo cual podríamos descubre preguntando a los clientes de nuestra base de datos, los propietarios del club de tenis):

Tipos de tasas ( BCNF y el 3NF más débil, que está implícito en 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 actualizamos el tribunal, podemos garantizar que el tipo de tarifa reflejará este cambio, y no podemos cobrarle el precio incorrecto a un tribunal.

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

He leído la cita: los datos dependen de la tecla [1NF], la clave completa [2NF] y nada más que la tecla [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é es que algunas tablas de 3NF no están en BCNF? Quiero decir, la cita de 3NF explícitamente dice "nada más que la clave", lo que significa que todos los atributos dependen únicamente de la clave principal. 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, por favor corrígeme y gracias por cualquier ayuda que pueda brindar.

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

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

Una relación, R, está en 3NF iff por cada FD no trivial (X-> A) satisfecha 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 si sus atributos dependientes son parte de una clave.

Una relación, R, está en BCNF iff 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 ya que " los datos no clave dependen de las teclas ... y nada más que las teclas".

Usted también declaró:

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

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

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

Bueno, tenemos claves primarias y no primordiales.

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

Los no primos pueden ser dependientes o no .

Cuando dependemos: vemos que deben depender de una clave candidata completa. Esto es 2NF .
Cuando no es dependiente: no puede haber dependencia transitiva ni dependencia
- Ni siquiera dependencia transitiva: no estoy seguro de qué teoría de normalización aborda esto.
- Cuando es transitivo dependiente: se considera indeseable. Esto es 3NF .

¿Qué hay de las dependencias entre los primos?

Ya ves, no estamos abordando la relación de dependencia entre primos por segunda o tercera NF. Además, tal dependencia, si existe, no es deseable y, por lo tanto, tenemos una sola regla para abordar eso. Esto es BCNF .

En referencia al ejemplo de la publicación de Bill Karwin aquí, verás que tanto '' Topping '' como '' Topping Type '' son claves principales y tienen una dependencia. Si no hubieran sido primos con dependencia, entonces 3NF habría dado un puntapié.

Nota:

La definición de BCNF es muy genérica y sin atributos de diferenciación entre primos y no primos. Sin embargo, la forma de pensar anterior ayuda a comprender cómo se percola una anomalía incluso después de la 2ª y 3ª FN.

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 attribus principal / no principal, veamos cómo se relacionan BCNF y 2/3 NF.

Primero, BCNF requiere (aparte del caso trivial) que para cada dependencia funcional X -> Y (FD), X debe ser superclave. Si solo considera cualquier FD, entonces tenemos tres casos: (1) X e Y no primo, (2) Primario y (3) X primo e Y no primo, descartando el (sin sentido) caso X no -prime y Y prime.

Para el caso (1), 3NF se ocupa de.

Para el caso (3), 2NF se ocupa de.

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

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

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

Tu pizza puede tener exactamente tres tipos de topping:

un tipo de queso
un tipo de carne
un tipo de vegetal

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 queso como carne! ¡Y la salchicha no es un queso!

Necesitamos evitar este tipo de errores para hacer que la mozzarella siempre sea queso. Deberíamos usar una tabla separada para esto, así que escribimos 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 forma diferente a 3NF solo cuando hay varias claves candidatas superpuestas.

La razón es que la dependencia funcional X -> Y es, por supuesto, verdadera si Y es un subconjunto de X Por lo tanto, en cualquier tabla que tenga solo una clave candidata y esté en 3NF, ya está en BCNF porque no hay ninguna columna (clave o no clave) que dependa funcionalmente de nada más que esa clave.

Debido a que cada pizza debe tener exactamente uno de cada tipo de cobertura, sabemos que (Pizza, Topping Type) 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 donde marcamos mozarella como el tipo de encabezado incorrecto. Sabemos que esto está mal, pero la regla que lo hace incorrecto es una dependencia Topping -> Topping Type que no es una dependencia válida para BCNF para esta tabla. Es una dependencia de algo más que una clave candidata completa.

Para resolver esto, sacamos Topping Type de la tabla Pizzas y lo convertimos en un atributo no clave en una tabla de Toppings.