NORMALIZACION

Procedimiento que busca eliminar la redundancia de las bases de datos, obteniendo las
denominadas formas normales correspondientes.
Es un proceso que sigue normas bien definidas y reversibles. Estas normas son aplicables
durante el proceso de diseo de una base de datos.
Despus de disear el diagrama Entidad-Relacin el siguiente paso para el diseo de la
base de datos es la ormali!acin que consiste en e"aminar los datos que se encuentran
agrupados en una tabla #asta reempla!arlos por varias tablas que resultan ser simples y
predecibles #acindolas mas f$ciles de mane%ar. Este proceso se reali!a por las siguientes
ra!ones&
Estructurar los datos de tal manera que se pueda establecer f$cilmente la relacin
entre los datos.
'acilitar la recuperacin de los datos para satisfacer las necesidades de informacin.
'acilitar el mantenimiento de los datos (altas, ba%as y cambios).
Reducir la posibilidad de reorgani!ar o reestructurar la base de datos ante nuevas
necesidades de almacenamiento de informacin.
Reducir la posibilidad de redundancia e inconsistencias en los datos.
Para reali!ar este proceso se tienen cuatro pasos&
Estado inicial
Primera forma normal
*egunda forma normal
+ercera forma normal
Estado ,nicial
En este paso se listan todos los datos del sistema, describiendo las tablas, llaves primarias y
llaves for$neas que ser$n -tiles para #acer los enlaces entre las tablas. *e e"aminan
aquellos datos que tienen el resultado de un c$lculo porque regularmente stos no se
almacenan en la base de datos, como seria el total de sueldos devengados por
departamento.
. continuacin se detalla el estado inicial de las tablas&
Empleados
Cdigo Empleado
o .pellido
o ombre
o /digo de Depto.
o ombre del Depto.
o /digo del Puesto
o /digo Especiali!acin 0..1
o Descripcin Especiali!acin 0..1
o Establecimiento 0..1
o .o obtenido 0..1
/ategor2a de Puesto
o Cdigo de Puesto
o ombre
o Requisito 0..1
( Las llaves primarias estn subraadas sobreimpresas!
Las llaves "orneas estn subraadas #
PRIMERA $ORMA NORMAL
Es en la primera forma normal donde se eliminan las columnas que son redundantes en la
misma fila y se crea una o m$s tablas y relaciones con los datos eliminados de la tabla
original. *e alcan!a la primera forma normal cuando ya no e"isten grupos de datos que se
repiten.
En el caso de las tablas antes mencionadas la informacin redundante estaba en las
siguientes tablas&
Empleados& cdigo de especiali!acin, establecimiento y ao en el que se obtuvo ya
que para cada empleado puede tener #asta tres diplomas o t2tulos.
/ategor2a de Puestos& *e ten2a de 3 a 1 requisitos que debe cumplir el candidato al
puesto
Despus de detectados los datos que est$n redundantes se procede a eliminarlos de la
tabla original y se crea una nueva con sus relaciones a otras tablas.
(0) 0..1 porque se puede tener #asta 1 especialidades por empleado, registrando el cdigo,
descripcin, establecimiento y ao en el que se obtuvo cada uno de ellos.
(4) 0..1 porque se puede tener #asta 1 requisitos para que una persona desempee el
puesto.
/on estas nuevas tablas ya no se tendr$ limitado a 1 el n-mero de diplomas, t2tulos o
especialidades por empleado de igual manera para cada puesto puede tenerse m$s de 1
requisitos que debe cumplir el candidato al puesto.
Empleado
Cdigo Empleado
.pellido
ombre
/digo de Depto.
ombre del Depto.
/digo del Puesto
Espe%iali&a%in
Cdigo Empleado
Cdigo Espe%iali&a%in
Descripcin Especiali!acin
Establecimiento
.o obtenido
Categor'a de Puesto
Cdigo de Puesto
ombre
/digo de Requisito
Re(uisitos
/digo de Requisito
Descripcin
( 5as llaves primarias est$n subrayadas y sobreimpresas.
5as llaves for$neas est$n subrayadas )
)E*+N,A $ORMA NORMAL
*e aplica para tablas cuya llave primaria es compuesta y se eliminan las columnas que
depende slo de una parte de la llave creando una o varias tablas con los datos que se
removieron de%ando -nicamente los datos dependientes.
*i se e"aminan cada una de las tablas que se encuentran en primera forma normal se
puede observar que slo la tabla de especiali!acin cuenta con una llave primaria
compuesta y que las columnas establecimiento y ao obtenido dependen completamente de
la llave primaria y no de una parte de ella 6Por que7, porque el establecimiento y ao en el
que un empleado obtuvo una especiali!acin tiene relacin directa con el empleado y con el
identificador de la especiali!acin y no puede ser relacionado slo con uno de ellos. *in
embargo, la descripcin de la especiali!acin depende slo del cdigo de especiali!acin,
por lo que deber$ sacarse de esta tabla y crear una nueva, /at$logo .cadmico, quedando
la segunda forma normal as2&
Empleados
Cdigo Empleado
.pellido
ombre
/digo de Depto.
ombre de Depto.
/digo del puesto
Categor'a de Puesto
Cdigo de Puesto
ombre
/digo Requisito
Catlogo A%ad-mi%o
Cdigo de Espe%ialidad
Descripcin
Espe%iali&a%in
Cdigo Empleado
Cdigo Espe%iali&a%in
Establecimiento
.o 8btenido
Re(uisitos
Cdigo Re(uisito
Descripcin
( 5as llaves primarias est$n subrayadas y sobreimpresas.
5as llaves for$neas est$n subrayadas )
.ERCERA $ORMA NORMAL
Para que los datos se encuentran en tercera forma normal, las columnas no llave, no deben
ser dependientes transitivos de la llave primaria.
En una tabla se dice que tiene dependencia transitivas si&
5a columna . es dependiente de la columna 9 y
la columna 9 depende de la columna /, entonces
la columna . depende de la columna /, siendo / la llave primaria.
Este tipo de dependencia puede provocar problemas si no se elimina, ya que de desconocer
tal caracter2stica de los datos se pueden eliminar datos inapropiadamente, como seria el
caso si se elimina / siendo . y 9 dependientes de /, tambin se borrar$n.
Para las tablas del sistema de informacin de empleados los datos ya se encuentran en
segunda forma normal y s2 tienen dependencia transitiva en la tabla de Empleados. 5a llave
primaria de la tabla de Empleados es cdigo empleado. 5os atributos apellido, nombre,
cdigo de Depto. y cdigo del puesto dependen directamente del cdigo empleado. *in
embargo, el nombre de Depto. depende directamente del cdigo de Depto. y no de cdigo
empleado, por lo que se deber$ crear otra tabla llamada Departamento, quedando el diseo
en tercera forman normal, as2&
Empleados
Cdigo Empleado
.pellido
ombre
/digo de Depto.
/digo del Puesto
,epartamento
/digo de Depto.
ombre
Categor'a de Puesto
Cdigo de Puesto
ombre
/digo Requisito
Catlogo A%ad-mi%o
Cdigo Espe%ialidad
Descripcin
Espe%iali&a%in
Cdigo Empleado
Cdigo Espe%iali&a%in
Re(uisitos
Cdigo Re(uisito
Descripcin
( 5as llaves primarias est$n subrayadas y sobreimpresas.
5as llaves for$neas est$n subrayadas )
E/emplo0
*e tienen los datos en segunda forma normal, encontrando que los datos de producto
terminado son dependientes de los datos de materia prima y los datos de materia prima son
dependientes de proveedor, entonces productos terminados son dependientes de proveedor
como se puede visuali!ar en la figura de aba%o. Debido a la transitividad si se borra un
proveedor se borran los datos de productos terminados y los datos de materia prima,
situacin que no seria conveniente.
Produ%to
.erminado
Materia
Prima
Proveedor
Produ%tos
Cdigo de Produ%to
/digo de Proveedor
/digo de :ateria Prima
ombre del Proveedor
Direccin del Proveedor
Descripcin del Producto
Descripcin de :ateria Prima
;alor Producto
( 5as llaves primarias est$n subrayadas y sobreimpresas )
Para eliminar este problema se procede a eliminar de la tabla los datos de materia prima y
de proveedores< con esos datos se crean dos tablas nuevas llamadas Proveedores y
:ateria Prima.
Produ%tos
Cdigo Produ%to
Descripcin Producto
;alor Producto
Proveedores
Cdigo Proveedor
ombre Proveedor
Direccin del Proveedor
Materia Prima
Cdigo Materia Prima
Descripcin :ateria Prima
( 5as llaves primarias est$n subrayadas y sobreimpresas )
Para poder reali!ar este traba%o el diseador debe tener conocimiento de la relacin entre
los datos y de las actividades de la empresa donde stos son utili!ados.
Articulo Original
Uno de los factores mas importantes en la creacin de pginas web dinmicas es el diseo de las Bases
de Datos (BD). Si tus tablas no estan correctamente diseadas, te pueden causar un montn de dolores
de cabeza cuando tengas de realizar complicadsimas llamadas S!" en el cdigo #$# para e%traer los
datos &ue necesitas. Si conoces como establecer las relaciones entre los datos ' la normalizacin de
estos, estars preparado para comenzar a desarrollar tu aplicacin en #$#.
Si traba(as con )'S!" o con *racle, debes conocer los m+todos de normalizacin del diseo de las
tablas en tu sistema de BD relacional. ,stos m+todos pueden a'udarte a -acer tu cdigo #$# mas fcil
de comprender, ampliar, ' en determinados casos, incluso -acer tu aplicacin mas rpida.
Bsicamente, las reglas de .ormalizacin estn encaminadas a eliminar redundancias e
inconsistencias de dependencia en el diseo de las tablas. )s tarde e%plicar+ lo &ue esto significa
mientras /emos los cinco pasos progresi/os para normalizar, tienes &ue tener en cuenta &ue debes
crear una BD funcional ' eficiente. 0ambien detallar+ los tipos de relaciones &ue tu estructura de datos
puede tener.
Digamos &ue &ueremos crear una tabla con la informacin de usuarios, ' los datos a guardar son el
nombre, la empresa, la direccin de la empresa ' algun e1mail, o bien U2" si las tienen. ,n principio
comenzarias definiendo la estructura de una tabla como esta3
4ormalizacin 5,2*
usuarios
nombre empresa direccion=empresa url0 url4
>oe .9/ 0 ?or@ 5ane abc.com "y!.com
>ill ABC 0 >ob *treet abc.com "y!.com
Diramos &ue la anterior tabla esta en ni/el de 4ormalizacion 5ero por&ue ninguna de nuestras reglas de normalizacin -a
sido aplicada. *bser/a los campos url6 ' url7 11 8!u+ -aremos cuando en nuestra aplicacin necesitemos una tercera url 9
8 !uieres tener &ue aadir otro campo:columna a tu tabla ' tener &ue reprogramar toda la entrada de datos de tu cdigo
#$# 9 *b/iamente no, tu &uieres crear un sistema funcional &ue pueda crecer ' adaptarse fcilmente a los nue/os
re&uisitos. $ec-emos un /istazo a las reglas del #rimer .i/el de 4ormalizacin1.ormalizacin, ' las aplicaremos a nuestra
tabla.
#rimer ni/el de 4ormalizacin:.ormalizacin. (4:.)
6. ,liminar los grupos repetiti/os de la tablas indi/iduales.
7. 5rear una tabla separada por cada grupo de datos relacionados.
;. <dentificar cada grupo de datos relacionados con una cla/e primaria.
8 =es &ue estamos rompiendo la primera regla cuando repetimos los campos url6 ' url7 9 8 > &ue pasa con la
tercera regla, la cla/e primaria 9 "a regla tres bsicamente significa &ue tenemos &ue poner una campo tipo
contador autoincrementable para cada registro. De otra forma, 8 !u+ pasaria si tu/ieramos dos usuarios llamados
?oe ' &ueremos diferenciarlos. Una /ez &ue aplicaramos el primer ni/el de 4:. nos encontrariamos con la
siguiente tabla3

usuarios
userId nombre empresa direccion=empresa url
0 >oe .9/ 0 ?or@ 5ane abc.com
0 >oe .9/ 0 ?or@ 5ane "y!.com
4 >ill ABC 0 >ob *treet abc.com
4 >ill ABC 0 >ob *treet "y!.com
@-ora diremos &ue nuestra tabla est en el primer ni/el de 4:.. $emos solucionado el problema de la limitacin
del campo url. #ero sin embargo /emos otros problemas....5ada /ez &ue introducimos un nue/o registro en la
tabla usuarios, tenemos &ue duplicar el nombre de la empresa ' del usuario. .o slo nuestra BD crecer
muc-simo, sino &ue ser mu' facil &ue la BD se corrompa si escribimos mal alguno de los datos redundantes.
@plicaremos pues el segundo ni/el de 4:.3
Segundo nivel de F/N
6. 5rear tablas separadas para a&uellos grupos de datos &ue se aplican a /arios registros.
7. 2elacionar estas tablas mediante una cla/e e%terna.

$emos separado el campo url en otra tabla, de forma &ue podemos aadir ms en el futuro si tener &ue duplicar
los dems datos. 0ambien /amos a usar nuestra cla/e primaria para relacionar estos campos3
usuarios
userId nombre empresa direccion=empresa
0 >oe .9/ 0 ?or@ 5ane
4 >ill ABC 0 >ob *treet
urls
urlId relDser,d url
0 0 abc.com
4 0 "y!.com
1 4 abc.com
E 4 "y!.com
=ale, -emos creado tablas separadas ' la cla/e primaria en la tabla usuarios, user<d, esta relacionada a-ora con la
cla/e e%terna en la tabla urls, relUser<d. ,sto esta me(or. 8 #ero &ue ocurre cuando &ueremos aadir otro
empleado a la empresa @B5 9 8 o 7AA empleados 9 @-ora tenemos el nombre de la empresa ' su direccin
duplicandose, otra situacin &ue puede inducirnos a introducir errores en nuestros datos. @s &ue tendr+mos &ue
aplicar el tercer ni/el de 4:.3
0ercer ni/el de 4:..
6. ,liminar a&uellos campos &ue no dependan de la cla/e.
.uestro nombre de empresa ' su direccin no tienen nada &ue /er con el campo user<d, asi &ue tienen &ue tener su
propio empresa<d3

usuarios
userId nombre relEmpresa,d
0 >oe 0
4 >ill 4
empresas
emprId empresa direccion=empresa
0 .9/ 0 ?or@ 5ane
4 ABC 0 >ob *treet
urls
urlId RelDser,d url
0 0 abc.com
4 0 "y!.com
1 4 abc.com
E 4 "y!.com
@-ora tenemos la cla/e primaria empr<d en la tabla empresas relacionada con la cla/e e%terna rec,mpresa<d en
la tabla usuarios, ' podemos aadir 7AA usuarios mientras &ue slo tenemos &ue insertar el nombre B@B5B una
/ez. .uestras tablas de usuarios ' urls pueden crecer todo lo &ue &uieran sin duplicacin ni corrupcin de datos.
"a ma'oria de los desarrolladores dicen &ue el tercer ni/el de 4:. es suficiente, &ue nuestro es&uema de datos
puede mane(ar facilmente los datos obtenidos de una cual&uier empresa en su totalidad, ' en la ma'oria de los
casos esto ser cierto.
#ero -ec-emos un /istazo a nuestro campo urls 1 8 =es duplicacin de datos 9 ,sto es perfectamente aceptable si
la entrada de datos de este campo es solicitada al usuario en nuestra apliacin para &ue teclee libremente su url, '
por lo tanto es slo una coincidencia &ue ?oe ' ?ill teclearon la misma url. 8 #ero &ue pasa si en lugar de entrada
libre de te%to usramos un menC desplegable con 7A o incluso ms urls predefinidas 9 ,ntonces tendramos &ue
lle/ar nuestro diseo de BD al siguiente ni/el de 4:., el cuarto, muc-os desarrolladores lo pasan por alto por&ue
depende muc-o de un tipo mu' especfico de relacin, la relacin B/arios1con1/ariosB, la cual aCn no -emos
encontrado en nuestra aplicacin.
Relaciones entre los Datos
@ntes de definir el cuarto ni/el de 4:., /eremos tres tipos de relaciones entre los datos3 uno1a1uno, uno1con1
/arios ' /arios1con1/arios. )ira la tabla usuarios en el #rimer .i/el de 4:. del e(emplo de arriba. #or un
momento imaginmos &ue ponemos el campo url en una tabla separada, ' cada /ez &ue introducimos un registro
en la tabla usuarios tambien introducimos una sola fila en la tabla urls. ,ntonces tendramos una relacion uno1a1
uno3 cada fila en la tabla usuarios tendra e%actamente una fila correspondiente en la tabla urls. #ara los
propsitos de nuestra aplicacin no sera Ctil la normalizacin.
@-ora mira las tablas en el e(emplo del Segundo .i/el de 4:.. .uestras tablas permiten a un slo usuario tener
asociadas /arias urls. ,sta es una relacin uno1con1/arios, el tipo de relacin ms comCn, ' -asta &ue se nos
present el dilema del 0ercer .i/el de 4:.. la Cnica clase de relacin &ue necesitamos.
"a relacin /arios1con1/arios, sin embargo, es ligeramente ms comple(a. *bser/a en nuestro e(emplo del 0ercer
.i/el de 4:. &ue tenemos a un usuario relacionado con /arias urls. 5omo di(mos, /amos a cambiar la estructura
para permitir &ue /arios usuarios esten relacionados con /arias urls ' as tendremos una relacin /arios1con1
/arios. =eamos como &uedaran nuestras tablas antes de seguir con este planteamiento3
usuarios
userId nombre relEmpresa,d
0 >oe 0
4 >ill 4
empresas
emprId empresa direccion=empresa
0 .9/ 0 ?or@ 5ane
4 ABC 0 >ob *treet
urls
urlId url
0 abc.com
4 "y!.com
url1relations
relationId relatedDrl,d relatedDser,d
0 0 0
4 0 4
1 4 0
E 4 4
#ara disminuir la duplicacin de los datos ( este proceso nos lle/ar al 5uarto .i/el de 4:.), -emos creado una
tabla &ue slo tiene cla/es e%ternas ' primarias urlDrelations. $emos sido capaces de remo/er la entradas
duplicadas en la tabla urls creando la tabla urlDrelations. @-ora podemos e%presar fielmente la relacin &ue ambos
?oe and ?ill tienen entre cada uno de ellos, ' entre ambos, las urls. @s &ue /eamos e%ctamente &ue es lo &ue el
5uarto .i/el de 4:.. supone3
5uarto .i/el de 4:..
6. ,n las relaciones /arios1con1/arios, entidades independientes no pueden ser almacenadas en la misma tabla.
>a &ue slo se aplica a las relaciones /arios1con1/arios, la ma'oria de los desarrolladores pueden ignorar esta regla de
forma correcta. #ero es mu' Ctil en ciertas situaciones, tal como esta. $emos optimizado nuestra tabla urls eliminado
duplicados ' -emos puesto las relaciones en su propia tabla.
*s /o' a poner un e(emplo prtico, a-ora podemos seleccionar todas las urls de ?oe realizando la siguiente instruccin
S!"3
SELECT nombre, url FRO usuarios, urls, url!relations "#ERE url!relations$related%ser&d ' ( AND
usuarios$user&d ' ( AND urls$url&d ' url!relations$related%rl&d
> si &ueremos recorrer todas las urls de cada uno de los usuarios, -ariamos algo as3
SELECT nombre, url FRO usuarios, urls, url!relations "#ERE usuarios$user&d ' url!relations$related%ser&d
AND urls$url&d ' url!relations$related%rl&d
)uinto Nivel de F/N$
,%iste otro ni/el de normalizacin &ue se aplica a /eces, pero es de -ec-o algo esot+rico ' en la ma'oria de los casos no es
necesario para obtener la me(or funcionalidad de nuestra estructura de datos o aplicacin. Su principio sugiere3
6. "a tabla original debe ser reconstruida desde las tablas resultantes en las cuales a sido troceada.
"os beneficios de aplicar esta regla aseguran &ue no -as creado ninguna columna e%traa en tus tablas ' &ue la estructura
de las tablas &ue -as creado sea del tamao (usto &ue tiene &ue ser. ,s una buena prctica aplicar este regla, pero a no ser
&ue estes tratando con una e%tensa estructura de datos probablemente no la necesitars.
,spero &ue -a'as encontrado este artculo Ctil, ' &ue seas capaz de aplicar estas reglas de normalizacin a todos tus
pro'ectos de bases de datos. > en el caso &ue te estes preguntando de donde /iene todo esto, las tres primeras reglas de
normalizacin fueron perfiladas por el Dr. ,.4.5odd en su escrito de 6EF7, G4urt-er .ormalization of t-e Data Base
2elational )odelG ( 2eferente a la normalizacin de las Bases de Datos 2elacionales). "a otras regla -an sido teorizadas
por posteriores matemticos:@lgebristas.
11Barr'
0raducido por. ?.).4ont ((mfg76Hwanadoo.es)