La forma normal de Boyce-Codd ( BCNF o 3.5NF ) es una forma normal que se utiliza 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 eliminará todas las redundancias basadas en dependencias funcionales .
Edgar F. Codd publicó su artículo original "Un modelo relacional de datos para grandes bancos de datos compartidos" 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 la 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 Chris Date también la llamó forma normal de Heath . [1]
La BCNF fue desarrollada en 1974 por Raymond F. Boyce y Edgar F. Codd para abordar ciertos tipos de anomalías que no eran abordadas por la 3NF tal como se definió originalmente. [2]
Como se mencionó, Chris Date señaló 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 es anterior a la de Boyce y Codd en unos tres años, me parece que la BCNF debería llamarse por derecho propio la forma normal de Heath , pero no es así .
Si un esquema relacional está en BCNF, se ha eliminado toda redundancia basada en dependencia funcional , [4] aunque todavía 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 X → Y , se cumple al menos una de las siguientes condiciones: [5]
Tenga en cuenta que si un esquema relacional está en BCNF, entonces está en 3NF.
Solo en casos excepcionales una tabla 3NF no cumple con los requisitos de BCNF. Se garantiza que una tabla 3NF que no tenga múltiples claves candidatas superpuestas estará en BCNF. [6] Dependiendo de cuáles sean sus dependencias funcionales, una tabla 3NF con dos o más claves candidatas superpuestas puede o no estar en BCNF.
Un ejemplo de una tabla 3NF que no cumple con BCNF es:
Las superclaves de la tabla son:
Tenga en cuenta que, aunque en la tabla anterior los atributos Hora de inicio y Hora de finalización no tienen valores duplicados para cada uno de ellos, aún tenemos que admitir que en algunos otros días dos reservas diferentes en la cancha 1 y la cancha 2 podrían comenzar a la misma hora o finalizar a la misma hora . Esta es la razón por la que {Hora de inicio} y {Hora de finalización} no pueden considerarse como las superclaves de la tabla.
Sin embargo, sólo S 1 , S 2 , S 3 y S 4 son claves candidatas (es decir, superclaves mínimas para esa relación) porque, por ejemplo, S 1 ⊂ S 5 , entonces S 5 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 de cancha de hoy no hay atributos no principales: es decir, todos los atributos pertenecen a alguna clave candidata. Por lo tanto, la tabla se adhiere tanto a la 2NF como a la 3NF.
La tabla no se ajusta a la BCNF debido a la dependencia Tipo de tasa → Tribunal, en la que el atributo determinante Tipo de tasa (del que depende Tribunal) (1) no es una clave candidata ni un superconjunto de una clave candidata y (2) Tribunal no es un subconjunto del tipo de tasa.
Se respeta el tipo de tasa de dependencia → Tribunal, ya que un tipo de tasa solo debe aplicarse a un único Tribunal.
El diseño se puede modificar para que cumpla con BCNF:
Las claves candidatas para la tabla de tipos de tarifas son {Rate type} y {Court, Member flag}; las claves candidatas para la tabla de reservas de hoy son {Court, Start time} y {Court, End time}. Ambas tablas están en BCNF. Cuando {Rate type} es una clave en la tabla de tipos de tarifas, es imposible tener un tipo de tarifa asociado con dos canchas diferentes, por lo que al usar {Rate type} como clave en la tabla de tipos de tarifas, se ha eliminado la anomalía que afectaba a la tabla original.
En algunos casos, una tabla que no sea BCNF no se puede descomponer en tablas que satisfagan la BCNF y conserven las dependencias que existían en la tabla original. Beeri y Bernstein demostraron en 1979 que, por ejemplo, un conjunto de dependencias funcionales {AB → C, C → B} no se puede representar mediante un esquema BCNF. [7]
Considere la siguiente tabla no BCNF cuyas dependencias funcionales siguen el patrón {AB → C, C → B}:
Para cada combinación de tipo Persona/Tienda, la tabla nos indica qué tienda de este tipo se encuentra geográficamente más cerca del domicilio de la persona. Para simplificar, suponemos que una misma tienda no puede ser de más de un tipo.
Las claves candidatas de la tabla son:
Dado que los tres atributos son atributos principales (es decir, pertenecen a claves candidatas), la tabla está en 3NF. Sin embargo, la tabla no está en BCNF, ya que el atributo de tipo de tienda depende funcionalmente de una clave que no es superclave: la tienda más cercana.
La violación de la BCNF significa que la tabla está sujeta a anomalías. Por ejemplo, Eagle Eye podría tener su tipo de tienda cambiado 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?". Mantener el tipo de tienda de cada tienda solo una vez parecería preferible, ya que al hacerlo se evitarían tales anomalías:
En este diseño revisado, la tabla "Tienda cercana a persona" tiene una clave candidata de {Persona, Tienda}, y la tabla "Tienda" tiene una clave candidata de {Tienda}. Desafortunadamente, aunque este diseño se adhiere a BCNF, es inaceptable por diferentes motivos: nos permite registrar múltiples tiendas del mismo tipo para 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 la BCNF). Este diseño introduce una nueva forma normal, conocida como Forma Normal de Clave Elemental . [8] Este diseño consta de 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 esa 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 según la cual {Tipo de tienda, Tienda más cercana} de la primera tabla debe hacer referencia a un {Tipo de tienda, Tienda} de la segunda tabla, 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 se puede descomponer en BCNF reemplazando esa relación con dos subrelaciones:
Verifique si ambas subrelaciones están en BCNF y repita el proceso recursivamente con cualquier subrelación que no esté en BCNF. [11]
Corolario 3.