NORMALIZACION: (FORMAS NORMALES)

La teora de la normalizacin es una gua que ayuda a prevenir problemas de diseo de

bases de datos como las redundancias y otras anomalas en la insercin, modificacin y
borrado en las tablas de una base de datos; aunque como contrapartida puede haber
problemas
en
su
recuperacin.
La normalizacin es un proceso de diseo que consiste en descomponer los registros en otros
de menor tamao (con menos campos), de forma que cumplan una serie de restricciones que
se definen como forma normal.

NOCIN 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 segn 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 cmo pasar un registro a primera forma normal. Cada una tiene ventajas
e inconvenientes y su implantacin depender de las caractersticas del grupo que se repite.
(Por ejemplo, si es fijo y con muy pocas ocurrencias podra ser conveniente contemplar la
opcin C, si fuera variable y numeroso, podra ser ms acertada la opcin B).
Segunda Forma Normal.
Un registro est en segunda forma normal 2FN. Si adems 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 informacin acerca de la clave.
Por ejemplo, en el registro.
Suministros(Cod_Objeto, Cod_Almacen, Cantidad, Ubicacin_Almacen)
Donde la clave primaria est formada por los campos Cod_Objeto y Cod_Almacen, la ubicacin
en el almacn (Ubicacion_Almacen) es un hecho slo 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 adems de englobar las otras dos anteriores, aade la siguiente
restriccin: Los campos que no forman parte de la clave primaria deben facilitar informacin
slo 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 cdigo de mdico, viola la 3FN, ya que el nombre del
departamento es un hecho acerca del cdigo del departamento adems de serlo
transitivamente de Cod_Medico
Medicos (Cod_Medico, Cod_Especialidad, Nombre_Especialidad)
Para conseguir la 3FN sera conveniente descomponerlo de la siguiente manera:
Medicos (Cod_Medico, Cod_Especialidad)
Especialidad (Cod_Especialidad, Nombre_Especialidad)

DEFINICIN DE DEPENDENCIA FUNCIONAL.

Decimos que un descriptor Y (Conjunto de campos) depende funcionalmente del descriptor X,
si, y slo 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 cdigo (suponiendo que no se repiten) existe en una sola direccin, 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 ningn subconjunto del mismo, esto es:
XY
X1 -/-> Y
X2 -/-> Y
As por ejemplo, si suponemos que en un hospital un mdico puede trabajar en varias
espacialidades, realizando una sola funcin en cada una de ellas (Traumatologa, aparato
digestivo, pediatra, etc.), aunque pueda ser distinta segn 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 mdico 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 ms 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 razn la relacin:
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 cdigo de pieza, si el Cod_Almacen cambia, por eso tiene que ir
el Cod_Almacen y decimos que es dependencia completa)
P.Ej.
Cod_Objeto Cod_Almacen Cantidad
001
002
002

001
001
002

12
46
34

y en el segundo caso Cod_Almacen Ubicacion_Almacen tambin lo es, ya que si la clave es

simple (est formada por un solo campo) siempre que se encuentre en 1FN lo estar tambin
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:

XY
YZ
Y -/-> X
Se dice que Z depende transitivamente respecto de X a travs 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 travs de
Cod_Especialidad.
Se dice que un registro se encuentra en 3FN si:
-

Est en 2FN
Ningn 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
Nombre_Especialidad, que no forma parte de la clave, depende transitivamente de ella.

que

FORMA NOMAL DE BOYCE-CODD (FNBC)

Si nos encontramos con casos en los que hay varias claves compuestas solapadas (que
comparten algn 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 unvocamente tanto por el cdigo 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; adems 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 tambin 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 tambin 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 estn presentes en la

misma). Una tabla con una dependencia multivaluada es una donde la existencia de dos
o ms 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 mdicos que tiene y las especialidades que
tratan:
Hospitales (Cod_Hospital, Cod_mdico, Cod_especialidad)

Cada fila indica que un hospital dado puede tratar una enfermedad con un mdico. Como la
tabla tiene una clave nica y ningn atributo no-clave, no viola ninguna forma normal hasta el
BCNF. Pero debido a que los mdicos 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. Bermdez, si el hospital
del Sur contrata al Dr. Martn necesitaremos agregar mltiples registros, uno para cada
especialidad tratada. En trminos formales, esto se describe como que cada mdico est
teniendo una dependencia multivalor en Hospital.
Para satisfacer la 4NF, debemos poner los hospitales con los distintos mdicos mostrados en
una tabla diferente de los hospitales con sus especialidades.