Forma normal de Boyce-Codd

La Forma Normal de Boyce-Codd (o FNBC) es una forma
normal utilizada en la normalización de bases de datos. Es
una versión ligeramente más fuerte de la Tercera
forma normal (3FN). 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 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á en 3FN y los únicos determinantes son
claves candidatas.

Así mismo dentro de la formal normal
de Boyce Codd, podemos señalar algunos ejemplos
relacionado a dicha forma normal:

Consideremos una empresa donde un trabajador puede
trabajar en varios departamentos. En cada departamento hay varios
responsables, pero cada trabajador sólo tiene asignado
uno. Tendríamos una tabla con las columnas:

IDTrabajador, IDDepartamento, IDResponsable

La única clave candidata es IDTrabajador (que
será por tanto la clave primaria).

Si añadimos la limitación de que el
responsable sólo puede serlo de un departamento, este
detalle produce una dependencia funcional ya que: Responsable ?
Departamento

Por lo tanto, hemos encontrado un determinante
(IDResponsable) que sin embargo no es clave candidata. Por ello,
esta tabla no está en FNBC. En este caso la redundancia
ocurre por mala selección de clave. La repetición
del par [IDDepartamento + IDResponsable] es innecesaria y
evitable.

Solamente en casos raros una tabla en 3NF no satisface
los requerimientos de la FNBC. Un ejemplo de tal tabla es
(teniendo en cuenta que cada estudiante puede tener más de
un tutor):

Otro ejemplo a observar es la tabla tutor- estudiante la
cual tendremos como referencia la siguiente:

El propósito de la tabla es mostrar qué
tutores están asignados a qué estudiantes.
Las claves candidatas de la tabla son:

• {ID Tutor, ID Estudiante}

• {Número de seguro social del tutor, ID
  Estudiante}

Por consiguiente tenemos otra
formulación con respecto a la tabla la cual consta de los
siguientes:

Una forma sencilla de comprobar si una relación
se encuentra en FNBC consiste en comprobar, además de que
esté en 3FN, lo siguiente:

(1) Si no existen claves candidatas compuestas (con
varios atributos), está en FNBC.

(2) Si existen varias claves candidatas compuestas y
éstas tienen un elemento común, no está en
FNBC.

En la tabla de ejemplo anterior existen dos claves
candidatas y ambas comparten el atributo ID Estudiante, por lo
tanto no está en FNBC.

Del mismo modo, Una tabla está en Cuarta Forma
Normal o 4FN si está en FNBC y las únicas
dependencias funcionales multivaluadas que existen son las
dependencias funcionales de la clave con los atributos que no
forman parte de la misma. Estas dependencias multivaluadas de la
clave con los atributos que no forman parte de la misma son
dependencias triviales, por lo que algunos autores dicen que no
existen dependencias multivaluadas en 4FN. En base de datos se
entiende por dependencia Multivaluada el caso en que en una tupla
(X,Y,Z). se dice que Y es multidependiente de X (X —> Y) si
y sólo si el conjunto de valores de Y correspondiente a un
par (X,Z) depende sólo del valor de X y es independiente
del valor de Z.

Forma normal de
proyección-unión

También conocida como "Quinta Forma Normal
(5FN)". La forma normal de proyección unión es un
nivel de normalización de bases de datos, utilizado para
reducir redundancias en las bases de datos relacionales. Una
tabla está en la quinta forma normal solo si está
en la cuarta forma normal y cada dependencia de unión en
ella es implicada por las claves candidatas.

Es la más compleja y polémica de todas.
Polémica, pues no está claro en muchas ocasiones
que sea una solución mejor que él no llegar a este
nivel de normalización.

Una tabla se encuentra en 5FN si:

• La tabla está en 4FN

• No existen relaciones de dependencias triviales
que no siguen los criterios de las claves.

Solamente en algunas ocasiones una tabla 4FN no se
corresponde con una 5FN. Éstas son situaciones en las
cuales una restricción compleja del mundo real, que limita
las combinaciones válidas de los valores de atributos en
la tabla 4NF, no está implícita en la estructura de
esa tabla. Si esa tabla no se normaliza a 5NF, la tarea de
mantener la consistencia lógica de los datos dentro de la
tabla debe ser llevada en parte por la aplicación
responsable de inserciones, borrados, y actualizaciones a ella; y
hay un riesgo elevado de que los datos dentro de la tabla se
vuelvan inconsistentes. Por el contrario, el diseño 5NF
excluye la posibilidad de tales inconsistencias.

La quinta forma normal se refiere a dependencias que son
extrañas. Tiene que ver con afinidades que pueden
dividirse en subafinidades, pero que no pueden reconstruirse. La
condición bajo la cual surge esta situación, no
tiene significado intuitivo preciso. No se sabe cuáles son
las consecuencias de tales dependencias, incluso si tienen
consecuencias prácticas.

Del mismo modo consideramos la siguiente tabla la cual
se observara las relaciones psiquiatra-asegurador de la 5ta forma
normal

Considere el siguiente ejemplo:

El psiquiatra puede ofrecer tratamiento reembolsable a
los pacientes que sufren de la condición dada y que son
asegurados por el asegurador dado. En ausencia de cualquier regla
que restrinja las combinaciones válidas posibles de
psiquiatra, asegurador, y condición, la tabla de tres
atributos Psiquiatra-para-Asegurador-para-Condición es
necesaria para modelar la situación
correctamente.

Sin embargo, suponga que la regla siguiente se
aplica:

Cuando un psiquiatra es autorizado a ofrecer el
tratamiento reembolsable a los pacientes asegurados por el
asegurador P, y el psiquiatra puede tratar la condición C,
entonces – en caso que el asegurador P cubra la condición
C – debe ser cierto que el psiquiatra puede ofrecer el
tratamiento reembolsable a los pacientes que sufren de la
condición C y están asegurados por el asegurador
P.

Con estas restricciones es posible dividir la
relación en tres partes.

Así mismo, podemos notar como esta
disposición ayuda a quitar redundancia. Suponga que el Dr.
James se convierte en un proveedor de tratamientos para
FriendlyCare. En la disposición anterior tendríamos
que agregar dos nuevas entradas puesto que el Dr. James puede
tratar dos condiciones cubiertas por FriendlyCare: ansiedad y
depresión. Con la nueva disposición necesitamos
agregar una sola entrada (en la tabla
Psiquiatra-para-Asegurador).

Forma normal de
Clave de Dominio.

La forma normal de dominio/clave (DKNF) es una forma
normal usada en normalización de bases de datos que
requiere que la base de datos contenga restricciones de dominios
y de claves.

Una restricción del dominio especifica los
valores permitidos para un atributo dado, mientras que una
restricción clave especifica los atributos que identifican
únicamente una fila en una tabla dada.

Esta es el santo grial de la Base de datos y es
alcanzado cuando cada restricción en la relación es
una consecuencia lógica de la definición de claves
y dominios, y, haciendo cumplir las restricciones y condiciones
de la clave y del dominio, causa que sean satisfechas todas las
restricciones. Así, esto evita todas las anomalías
no-temporales.

Es mucho más fácil construir una base de
datos en forma normal de dominio/clave que convertir
pequeñas bases de datos que puedan contener numerosas
anomalías. Sin embargo, construir con éxito una
base de datos en forma normal de dominio/clave sigue siendo una
tarea difícil, incluso para programadores experimentados
de bases de datos. Así, mientras que la forma normal de
dominio/clave elimina los problemas encontrados en la
mayoría de las bases de datos, tiende para ser la forma
normal más costosa de alcanzar. Sin embargo, el no poder
alcanzar la forma normal de dominio/clave puede llevar costos
ocultos a largo plazo, debido a anomalías que aparecen con
el tiempo en las bases de datos que solamente se adhieren a
formas normales más bajas.

Una violación de DKNF ocurre en la siguiente
tabla:

Asuma que el dominio para la 'DNI Persona rica consiste
en los DNI's de toda la gente rica en una muestra predefinida de
gente rica; el dominio para el Tipo de persona rica consiste de
los valores 'Millonario excéntrico', 'Multimillonario
excéntrico', 'Millonario malvado', y 'Multimillonario
malvado'; y el dominio para el Valor neto en dólares
consiste de todos los números enteros mayor que o igual a
1.000.000.

Hay una restricción que liga el Tipo de persona
rica al Valor neto en dólares, incluso aunque no podamos
deducir uno del otro. La restricción dicta que un
Millonario excéntrico o Millonario malvado tendrá
un valor neto de 1.000.000 a 999.999.999 inclusive, mientras que
un Multimillonario excéntrico o un Multimillonario malvado
tendrá un valor neto de 1.000.000.000 o más. Esta
restricción no es ni una restricción de dominio ni
una restricción de clave; por lo tanto no podemos confiar
en las restricciones de dominio y las de clave para garantizar
que una combinación de anómala de Tipo de persona
rica / Valor neto en dólares no tenga cabida en la base de
datos.

La violación de la DKNF podría ser
eliminada alterando dominio Tipo de persona rica para hacer que
sea consistente con solo dos valores, 'Malvado' y
'Excéntrico' (el estatus de persona rica como un
millonario o un multimillonario es implícito en su Valor
neto en dólares, así que no se pierde ninguna
información útil).

Autor:

José A. Rivas

Escuela: 47.

Prof.: Ubaldo Finol.

Republica Bolivariana de
Venezuela.

Ministerio para el poder popular para la
Educación.

Instituto Universitario Politecnico
Santiago Mariño

Valencia. Edo Carabobo.