Normalización: (Formas Normales)

La teoría de la normalización es una guía que ayuda a prevenir problemas de diseño de bases de datos como las redundancias y otras anomalías en la inserción, modificación y borrado en las tablas de una base de datos; aunque como contrapartida puede haber problemas en su recuperación.

La normalización es un proceso de diseño que consiste en descomponer los registros en otros de menor tamaño (con menos campos), de forma que cumplan una serie de restricciones que se definen como forma normal.

Noción de las Formas Normales

Primera Forma Normal 1FN

No se permite que un registro tenga grupos repetitivos, el concepto de "grupo repetitivo", puede ser definido de diferentes maneras según el criterio utilizado. Por tanto, no hay un acuerdo universal sobre los requisitos para que una tabla se pueda considerar en 1FN.

Aquí vamos a considerar que todos los campos deben ser únicos. En la Figura 1 se muestran distintas opciones de cómo pasar un registro a primera forma normal. Cada una tiene ventajas e inconvenientes y su implantación dependerá de las características del grupo que se repite. (Por ejemplo, si es fijo y con muy pocas ocurrencias podría ser conveniente contemplar la opción C, si fuera variable y numeroso, podría ser más acertada la opción B).

Segunda Forma Normal

Un registro está en segunda forma normal 2FN. Si además de estar en primera forma normal, todos los campos que no pertenezcan a la clave primaria dependen de toda la clave primaria.

Es decir, los campos que no son clave suministran información acerca de la clave.

Por ejemplo, en el registro.

Suministros(Cod_Objeto, Cod_Almacen, Cantidad, Ubicación_Almacen)

Donde la clave primaria está formada por los campos Cod_Objeto y Cod_Almacen, la ubicación en el almacén (Ubicacion_Almacen) es un hecho sólo acerca de Cod_Almacen no del conjunto de la clave, por lo que este registro viola la segunda forma normal. Para evitar este problema, el registro se puede descomponer del siguiente modo:

Suministros (Cod_Objeto, Cod_Almacen, Cantidad)

Almacenes (Cod_Almacen, Ubicacion_Almacen)

Que ya se encuentran en 2FN.

                                

Tercera Forma Normal 

La tercera forma normal 3FN además de englobar las otras dos anteriores, añade la siguiente restricción: Los campos que no forman parte de la clave primaria deben facilitar información sólo acerca de la(s) claves(s) primarias, y no acerca de otros campos. Es decir, un registro está en tercera forma normal, si sus campos deben ser independientes mutuamente y dependientes completamente de las claves primarias.

El siguiente registro, cuya clave es el código de médico, viola la 3FN, ya que el nombre del departamento es un hecho acerca del código del departamento además de serlo transitivamente de Cod_Medico

Medicos (Cod_Medico, Cod_Especialidad, Nombre_Especialidad)

Para conseguir la 3FN sería conveniente descomponerlo de la siguiente manera:

Medicos (Cod_Medico, Cod_Especialidad)

Especialidad (Cod_Especialidad, Nombre_Especialidad)

Definición de dependencia funcional

Decimos que un descriptor Y (Conjunto de campos) depende funcionalmente del descriptor X, si, y sólo si, cada valor de X tiene asociado en todo momento un único valor de Y, lo que se representa como: X -> Y

Así por ejemplo, podemos decir que:

Cod_Almacen -> Direccion_Almacen

Ya que cada código (suponiendo que no se repiten) existe en una sola dirección, en esta dependencia, se dice que el Cod_Almacen es el implicante y Direccion_Almacen el implicado.

Dependencia funcional completa y 2FN

Si el descriptor X es compuesto X(X1, X2) se dice que Y tiene dependencia funcional completa o plena respecto de X, pero no depende de ningún subconjunto del mismo, esto es: 

X ->Y

X1 -/-> Y

X2 -/-> Y

Así por ejemplo, si suponemos que en un hospital un médico puede trabajar en varias espacialidades, realizando una sola función en cada una de ellas (Traumatología, aparato digestivo, pediatría, etc.), aunque pueda ser distinta según la especialidad que:

(DNI_Medico, Cod_Especialidad) -> Funcion

Es una dependencia completa, ya que ninguno de los elementos del descriptor por separado determina el implicado, al poder tener un médico muchas funciones, lo mismo que una especialidad.

Sin embargo la dependencia:

(Cod_Objeto, Cod_almacen) -> Direccion_Almacen

No es completa, ya que Cod_Almacen -> Direccion _Almacen

Podemos ahora definir la 2FN de manera más rigurosa diciendo que un registro está en 2FN si:

-Está en 1FN

-Todo campo no clave tiene una dependencia funcional completa respecto de la clave primaria.

Por esta razón la relación:

Suministros (Cod_Objeto, Cod_Almacen, Cantidad, Ubicacion_Almacen)

No se encuentra en 2FN, mientras que las relaciones:

Suministros (Cod_Objeto, Cod_Almacen, Cantidad)

Almacenes (Cod_Almacen, Ubicacion_Almacen)

Si, ya que el primer registro, (Cod_Objeto, Cod_Almacen) -> Cantidad es una dependencia completa, (Se puede repetir el código de pieza, si el Cod_Almacen cambia, por eso tiene que ir el Cod_Almacen y decimos que es dependencia completa)

Por ejemplo

Cod_Objeto Cod_Almacen Cantidad

001 001 12

002 001 46

002 002 34

y en el segundo caso Cod_Almacen -> Ubicacion_Almacen también lo es, ya que si la clave es simple (está formada por un solo campo) siempre que se encuentre en 1FN lo estará también en 2FN.

Dependencia funcional transitiva y Tercera Forma Normal

Dado un registro con tres descriptores en el que existen las siguientes dependencias funcionales, como se indica en la Figura 2:

X -> Y

Y -> Z

Y -/-> X

Se dice que Z depende transitivamente respecto de X a través de Y, lo que se representa como X- - > Z

Por ejemplo, si suponemos que se dan las siguientes dependencias:

Cod_Medico -> Cod_Especialidad

Cod_Especialidad -> Nombre_Especialidad

Cod_Especialidad -/-> Cod_Medico

Podemos afirmar que Cod_Medico -> Nombre_Especialidad transitivamente a través de Cod_Especialidad.

Se dice que un registro se encuentra en 3FN si:

- Está en 2FN

- Ningún campo no clave depende transitivamente de ninguna clave.

Es por esto que el registro:

Medicos (Cod_Medico, Cod_Especialidad, Nombre_Especialidad) 

No se encuentra en 3FN, ya que la clave es el Cod_Medico, mientras que Nombre_Especialidad, que no forma parte de la clave, depende transitivamente de ella.

Forma normal de Boyce-Codd (FNBC) 

Si nos encontramos con casos en los que hay varias claves compuestas solapadas (que comparten algún campo), tendremos problemas.

Forma Normal Boyce-Codd

Se dice que un registro se encuentra en FNBC si y solo si, todo determinante es clave, donde por determinante entendemos cualquier conjunto de campos en el que otro campo depende funcionalmente de forma completa.

Dado el siguiente registro:

Suministros(Cod_Objeto, Cod_Almacen, Nombre_Almacen, Cantidad)

Donde los almacenes se identifican unívocamente tanto por el código como por el nombre; pero hay dos claves, la formada por el conjunto (Cod_Objeto Cod_Almacen) y la que componen (Cod_Objeto, Nombre_Almacen). Sin embargo, hay cuatro determinantes; además de las claves anteriores, el campo Cod_Almacen y el campo Nombre_Almacen son determinantes, ya que uno implica al otro y viceversa, por tanto este registro no se encuentra en FNBC, por que no todo determinante es clave (Cod_Almacen y Nombre_Almacen forman parte de la clave, pero no “son” la clave.)

Para cumplir la FNBC hay que descomponer el registro, de la siguiente manera:

Almacenes (Cod_Almacen, Nombre_Almacen)

Suministros (Cod_Objeto, Cod_Almacen, Cantidad)

De tal forma que en el primer registro existen dos claves: Cod_Almacen y Nombre_Almacen, y ambos campos son también determinantes, así que está en forma normal FNBC, mientras que en el segundo registro existe una clave compuesta por (Cod_Objeto, Cod_Almacen) y hay un único determinante formado por los dos campos (Cod_Pieza, Cod_Almacen) que determinan a Cantidad, por lo que también se encuentra en FNBC.

Cuarta Forma Normal

Una tabla está en 4NF si y solo si esta en 3FN o en BNCB (Cualquiera de ambas) y no posee dependencias multivaluadas triviales. (requiere que ciertas tuplas estén presentes en la misma). Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.

Por ejemplo

Dada una tabla de diferentes hospitales con los médicos que tiene y las especialidades que tratan:

Hospitales (Cod_Hospital, Cod_médico, Cod_especialidad)

Cada fila indica que un hospital dado puede tratar una enfermedad con un médico. Como la tabla tiene una clave única y ningún atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que los médicos de cada hospital son independientes de las especialidades tratadas, hay redundancia en la tabla. Esto se ve mejor en una tabla con los campos rellenos:

                     

Por ejemplo, nos dicen tres veces que el hospital del Sur tiene al Dr. Bermúdez, si el hospital del Sur contrata al Dr. Martín necesitaremos agregar múltiples registros, uno para cada especialidad tratada. En términos formales, esto se describe como que cada médico está teniendo una dependencia multivalor en Hospital.

Para satisfacer la 4NF, debemos poner los hospitales con los distintos médicos mostrados en una tabla diferente de los hospitales con sus especialidades.