4.6 FORMA NORMAL BOYCE-CODD

Edgar Frank Codd a finales definió las bases del modelo relacional a finales de los 60. Trabajaba para IBM empresa que tardó un poco en implementar sus bases. Pocos años después el modelo se empezó a implementar cada vez más, hasta ser el modelo de bases de datos más popular. En las bases de Codd se definían los objetivos de este modelo:

Independencia física. La forma de almacenar los datos, no debe influir en su manipulación lógica

Independencia lógica. Las aplicaciones que utilizan la base de datos no deben ser modificadas por que se modifiquen elementos de la base de datos.

Flexibilidad. La base de datos ofrece fácilmente distintas vistas en función de los usuarios y aplicaciones.

Uniformidad. Las estructuras lógicas siempre tienen una única forma conceptual (las tablas)

Sencillez.

La Forma Normal Boyce-Codd (Denominada por sus siglas en ingles como BCNF or FNBC) es una forma normal utilizada en la normalización de bases de datos. Es una adaptación vagamente más segura de lo establecido en la Tercera Forma Normal (3FN).

Es una etapa en que se deben agrupar los datos por afinidad, formando tablas las cuales se relacionan entre si mediante campos comunes; una tabla se considera en esta forma si y sólo sí cada determinante o atributo es una llave candidata.

La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En base de datos un atributo determinante es un atributo del que depende funcionalmente de manera completa algún otro atributo. Todo determinante es una clave candidata.

Como una tabla está en Forma Normal de Boyce-Codd si solo existen dependencias funcionales elementales que dependan de la clave primaria o de cualquier clave alternativa. Si la clave primaria está formada por un solo atributo y está en 3FN, ésta a su vez está en FNBC. Cómo en una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como ). Se dice que una tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En términos menos formales, una tabla está en FNBC si está 3FN y los únicos determinantes son claves candidata

La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si éstas existen. La BCFN es más fuerte que la 3FN, por lo tanto, toda relación en BCFN está en 3FN.

La violación de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente se presentan. Se debe comprobar si una relación viola la BCFN si tiene dos o más claves candidatas compuestas que tienen al menos un atributo en común.

   Gráficamente podemos representar  la forma normal de Boyce Codd de la siguiente forma:

Un ejemplo típico para mostrar una tabla que, estando en 3FN, mantiene dependencias funcionales, puede ser una tabla que posee los atributos Dirección, Código Postal y Ciudad, deduciendo que a Ciudades diferentes le corresponden códigos postales distintos.

Tabla en tercera forma normal
CPost	Dir	Ciud
3000	C/ Las Flores N°17	Merida
4858	Av. Bolívar este Nº72	Maracay

En este caso hay dependencia entre el Código Postal y la Ciudad, ya que, conocido el Código Postal se puede conocer la Ciudad, y conocida la Dirección y la Ciudad, se conoce el Código Postal.

Para transformar la tabla en una tabla en FNBC se crea una tabla de Códigos Postales y Ciudades, eliminando de la tabla original la Ciudad, obteniéndose dos tablas, una con los atributos Dirección y Código Postal y otra con el Código Postal y la Ciudad

Tabla en forma normal de Boyce-Codd
CPost	Dir
3000	C/ Las Flores N°17
4858	Av. Bolívar este Nº72

Tabla en forma normal de Boyce-Codd
CPost	Ciud
3000	Merida
4858	Maracay

En la mayoría de los casos, las relaciones en 3FN estarán en FNBC. Para Validar esto se deben ubicar todos los determinantes existentes en la relación así como todas las claves candidatas, se comparan ambos conjuntos y si encuentra que hay algún determinante que no resulta ser clave candidata se demuestra que no esta en FNBC. Se comprueba que la relación está en 1FN, todos los atributos son atómicos. También está en 2FN ya que no hay dependencias funcionalmente completas entre atributos que no sean clave (formen parte de la clave). Y finalmente se verifica que no hay ningún atributo que dependa de forma transitiva de la clave Primaria, luego está en 3FN. Usualmente se considera aceptable tener relaciones que lleguen sólo hasta la FNBC.

La definición de la 3FN no produce diseños satisfactorios cuando se dan las siguientes condiciones, o lo que es lo mismo, cuando una relación NO ESTE EN FNBC concurrirán las siguientes circunstancias:

• Existen varias claves candidatas.

• Las claves candidatas son compuestas.

• Las claves candidatas se encubren, tienen al menos un atributo en común.

No hay un teorema sobre la división de la relación, el motivo es que no se puede asegurar que al descomponer una relación en dos para conseguir la FNBC el significado de las relaciones obtenidas se corresponda semánticamente a lo que representa la relación inicial. En otras palabras, se puede tomar una decisión equivocada al descomponer ya que puede que perdamos parte de la semántica de la relación anterior.