Forma normal de Boyce-Codd

La forma normal de Boyce-Codd ( BCNF o 3.5NF ) es una forma normal utilizada en la normalización de bases de datos . Es una versión ligeramente más estricta de la tercera forma normal (3NF). Al utilizar BCNF, una base de datos elimina todas las redundancias basadas en dependencias funcionales .

Edgar F. Codd publicó su artículo original «Un modelo relacional de datos para grandes bases de datos compartidas» en junio de 1970. Esta fue la primera vez que se publicó el concepto de base de datos relacional. Todos los trabajos posteriores, incluido el método de forma normal de Boyce-Codd, se basaron en este modelo relacional.

La forma normal de Boyce-Codd fue descrita por primera vez por Ian Heath en 1971, y también ha sido llamada forma normal de Heath por Chris Date . ^{[ 1 ]}

La BCNF fue desarrollada formalmente en 1974 por Raymond F. Boyce y Edgar F. Codd para abordar ciertos tipos de anomalías que no eran tratadas por la 3NF tal como se definió originalmente. ^{[ 2 ]}

Como se mencionó, Chris Date ha señalado que una definición de lo que ahora conocemos como BCNF apareció en un artículo de Ian Heath en 1971. ^{[ 3 ]} Date escribe: ^{[ 1 ]}

Dado que esa definición precedió a la definición de Boyce y Codd por unos tres años, me parece que la BCNF debería, por derecho, llamarse forma normal de Heath . Pero no lo es .

Si un esquema relacional está en BCNF, entonces se ha eliminado toda redundancia basada en dependencia funcional , ^{[ 4 ]} aunque aún pueden existir otros tipos de redundancia. Un esquema relacional R está en forma normal de Boyce-Codd si y solo si para cada una de sus dependencias funcionales X → Y , se cumple al menos una de las siguientes condiciones: ^{[ 5 ]}

• X → Y es una dependencia funcional trivial (Y ⊆ X),
• X es una superclave para el ^esquema R. ^{[ 5} ]

Si un esquema relacional está en BCNF, automáticamente también está en 3NF, ya que BCNF es una forma más estricta de 3NF. Si bien todas las relaciones en BCNF cumplen las condiciones de 3NF, no todas las relaciones en 3NF cumplen los requisitos más estrictos de BCNF, lo que elimina toda redundancia causada por dependencias funcionales.

Solo en casos excepcionales una tabla en 3NF no cumple con los requisitos de BCNF. Una tabla en 3NF que no tiene múltiples claves candidatas superpuestas está garantizada en BCNF. ^{[ 6 ]} Dependiendo de sus dependencias funcionales, una tabla en 3NF con dos o más claves candidatas superpuestas puede o no estar en BCNF.

Un ejemplo de una tabla en 3NF que no cumple con BCNF es:

• Cada fila de la tabla representa la reserva de una pista en un club de tenis. Ese club tiene una pista dura (Pista 1) y una pista de hierba (Pista 2).
• Una reserva se define por su cancha y el período para el cual la cancha está reservada.
• Además, cada reserva tiene asociado un tipo de tarifa. Existen cuatro tipos de tarifa distintos:
  • AHORRO, para reservas de la Pista 1 realizadas por socios
  • ESTÁNDAR, para reservas de la Pista 1 realizadas por no socios
  • PREMIUM-A, para reservas de la Pista 2 realizadas por socios.
  • PREMIUM-B, para reservas de la Pista 2 realizadas por no socios.

Las superclaves de la tabla son:

• S ₁ = {Tribunal, Hora de inicio}
• S ₂ = {Tribunal, Hora de finalización}
• S ₃ = {Tipo de tarifa, Hora de inicio}
• S ₄ = {Tipo de tarifa, Hora de finalización}
• S ₅ = {Tribunal, Hora de inicio, Hora de finalización}
• S ₆ = {Tipo de tarifa, Hora de inicio, Hora de finalización}
• S ₇ = {Tribunal, Tipo de tarifa, Hora de inicio}
• S ₈ = {Tribunal, Tipo de tasa, Hora de finalización}
• S _T = {Tribunal, Tipo de tarifa, Hora de inicio, Hora de finalización}, la superclave trivial

Cabe señalar que, si bien en la tabla anterior los atributos Hora de inicio y Hora de finalización no presentan valores duplicados, debemos admitir que en otros días dos reservas diferentes en las pistas 1 y 2 podrían comenzar o terminar simultáneamente . Por este motivo, {Hora de inicio} y {Hora de finalización} no pueden considerarse superclaves de la tabla.

Las claves candidatas de la tabla son:

• S ₁ = {Tribunal, Hora de inicio}
• S ₂ = {Tribunal, Hora de finalización}
• S ₃ = {Tipo de tarifa, Hora de inicio}
• S ₄ = {Tipo de tarifa, Hora de finalización}

Solo S ₁ , S ₂ , S ₃ y S ₄ son claves candidatas (es decir, superclaves mínimas para esa relación) porque, por ejemplo, S ₁ ⊂ S ₅ , por lo que S ₅ no puede ser una clave candidata.

Dado que la 2NF prohíbe las dependencias funcionales parciales de atributos no primos (es decir, un atributo que no aparece en ninguna clave candidata ) y que la 3NF prohíbe las dependencias funcionales transitivas de atributos no primos en claves candidatas.

En la tabla de reservas judiciales de hoy , no hay atributos no clave; es decir, todos los atributos pertenecen a alguna clave candidata. Por lo tanto, la tabla cumple con la segunda y tercera forma normal (2NF y 3NF).

La tabla no cumple con la forma normal de Boyce-Columbia (BCNF). Esto se debe a la dependencia Tipo de tarifa → Tribunal, donde el atributo determinante es Tipo de tarifa, del cual depende Tribunal. Cabe señalar que (1) {Tipo de tarifa} no es una superclave y (2) {Tribunal} no es un subconjunto de {Tipo de tarifa}.

Tipo de tasa de dependencia → Se respeta el tribunal, ya que un tipo de tasa solo debe aplicarse a un único tribunal.

El diseño puede modificarse para que cumpla con la norma BCNF:

Las claves candidatas para la tabla Tipos de tarifa son {Tipo de tarifa} y {Tribunal, Indicador de miembro}; las claves candidatas para la tabla Reservas de hoy son {Tribunal, Hora de inicio} y {Tribunal, Hora de finalización}. Ambas tablas están en BCNF. Cuando {Tipo de tarifa} es una clave en la tabla Tipos de tarifa, es imposible que un mismo tipo de tarifa esté asociado a dos tribunales diferentes; por lo tanto, al usar {Tipo de tarifa} como clave en la tabla Tipos de tarifa, se ha eliminado la anomalía que afectaba a la tabla original.

En algunos casos, una tabla que no cumple con la notación BCNF no puede descomponerse en tablas que sí la cumplan y que conserven las dependencias presentes en la tabla original. Beeri y Bernstein demostraron en 1979 que, por ejemplo, un conjunto de dependencias funcionales {AB → C, C → B} no puede representarse mediante un esquema BCNF. ^{[ 7 ]}

Consideremos la siguiente tabla no BCNF cuyas dependencias funcionales siguen el patrón {AB → C, C → B}:

Para cada combinación de persona y tipo de tienda, la tabla nos indica cuál de estas tiendas se encuentra geográficamente más cerca del domicilio de la persona. Para simplificar, asumimos que una misma tienda no puede ser de más de un tipo.

Las claves candidatas de la tabla son:

• {Persona, Tipo de tienda},
• {Persona, Tienda más cercana}.

Dado que los tres atributos son atributos primos (es decir, pertenecen a claves candidatas), la tabla está en 3NF. Sin embargo, la tabla no está en BCNF, ya que el atributo Tipo de tienda depende funcionalmente de una clave que no es superclave: Tienda más cercana.

La violación de la forma normal de Boyce-Cook (BCNF) implica que la tabla está sujeta a anomalías. Por ejemplo, Eagle Eye podría cambiar su tipo de tienda a "Optometrista" en su registro "Fuller", mientras que conserva el tipo de tienda "Óptico" en su registro "Davidson". Esto implicaría respuestas contradictorias a la pregunta: "¿Cuál es el tipo de tienda de Eagle Eye?". Parece preferible mantener el tipo de tienda de cada establecimiento solo una vez, ya que esto evitaría que se produzcan tales anomalías.

En este diseño revisado, la tabla "Tiendas más cercanas por persona" tiene una clave candidata de {Persona, Tienda}, y la tabla "Tiendas" tiene una clave candidata de {Tienda}. Desafortunadamente, aunque este diseño cumple con la notación BCNF, es inaceptable por otros motivos: permite registrar varias tiendas del mismo tipo asociadas a la misma persona. En otras palabras, sus claves candidatas no garantizan que se respete la dependencia funcional {Persona, Tipo de tienda} → {Tienda}.

Es posible un diseño que elimine todas estas anomalías (pero que no se ajuste a BCNF). Este diseño introduce una nueva forma normal, conocida como Forma Normal de Clave Elemental . ^{[ 8 ]} Este diseño consiste en la tabla original "Tiendas más cercanas" complementada con la tabla "Tienda" descrita anteriormente. La estructura de tabla generada por el algoritmo de generación de esquemas de Bernstein ^{[ 9 ]} es en realidad EKNF, aunque esta mejora a 3NF no se había reconocido en el momento en que se diseñó el algoritmo:

Si se define una restricción de integridad referencial que establece que {Tipo de tienda, Tienda más cercana} de la primera tabla debe hacer referencia a un {Tipo de tienda, Tienda} de la segunda tabla, entonces se evitan las anomalías de datos descritas anteriormente.

Es NP-completo , dado un esquema de base de datos en tercera forma normal , determinar si viola la forma normal de Boyce-Codd. ^{[ 10 ]}

Si una relación R no está en BCNF debido a una dependencia funcional X→Y, entonces R puede descomponerse en BCNF reemplazando esa relación con dos subrelaciones:

1. Uno con los atributos X ⁺ ,
2. y otra con los atributos RX ⁺ +X. Nótese que R representa todos los atributos de la relación original.

Comprueba si ambas subrelaciones están en BCNF y repite el proceso recursivamente con cualquier subrelación que no esté en BCNF. ^{[ 11 ]}

• Reglas de normalización de datos
• Normalización avanzada por ITS, Universidad de Texas.