Normalizacin paso a paso

Christoper Emanuel Santisteban

Universidad de San Carlos de Guatemala
ces2601@gmail.com
2009

Resumen: Se pretende mostrar el proceso de normalizacin, desde la primera forma

normal 1FN hasta la quinta forma normal 5FN, explicacin y describiendo cada una
paso a paso, debido que es importante si se pretende formar un modelo optimo y
eficaz para la base de datos.
Abstract: We intend to show the normalization process, from the first normal form
1FN to fifth normal form 5FN, explaining and describing each step, because it is
important if we want to make an optimal and effective database model.
Palabras claves: base de datos, diseo, normalizacin, proceso.

1. Introduccin
Normalizacin es un proceso formal para
determinar que campos pertenecen a que
tablas en una base de datos relacional. Sigue
un conjunto de normas que logran eliminar
el
almacenamiento
de
informacin
redundante, hace un modelo de datos mas
cercano a la realidad, mediante entidades y
sus relaciones, estructura la informacin de
manera que el modelo sea flexible. [1]
1.1. Las formas normales
Codd a quien se le considera el padre del
modelo relacional, defini 3 formas
normales, que son 1NF, 2FN y 3FN. Como
la forma 3FN tena ciertos problemas Codd
y Boyce definieron otra nueva forma
llamada Boyce-Codd (abreviada BCNF).
Despus tratando de perfeccionar un poco
ms el modelo Ronald Fagin defini las
formas 4 y 5.

La normalizacin es una tcnica que se basa

en las dependencias entre atributos. Las
primeras 3 formas normales se determinan
en base a la funcionalidad, elementalidad y
dependencias transitivas. La cuarta normal
formal esta basada en dependencias multivaluadas y la quinta forma normal esta
basada en dependencias de unin. [2]

2. Proceso de normalizacin
Uno de los aspectos mas desafiantes de las
bases de datos es el proceso de
normalizacin, para explicar el proceso nos
vamos a basar en 3 conceptos
fundamentales:
a) El razonamiento detrs de
normalizacin
b) Modificacin anmala
c) Dependencias en la informacin

la

2.1. El razonamiento detrs de la

normalizacin
El proceso de normalizacin descompone
tablas grandes e ineficientes en tablas ms
pequeas, estructuradas de una manera ms
eficiente sin perder informacin en el
proceso [3]. Persigue una base de datos
bien definida, que no contiene informacin
duplicada y reduce el mnimo la
redundancia de la informacin.

Una restriccin impuesta a la capacidad de

modificar datos en una tabla que es
impuesta por la estructura de la tabla es
conocida como modificacin anmala.
Existen tres tipos: insercin, borrado y
actualizacin [2].
2.2.1. Insercin anmala
Una insercin anmala existe en una tabla
cuando hay una restriccin innecesaria o no
razonable puesta sobre la tarea de aadir
nuevos registros o cuando aadir nuevos
registros causa redundancia de informacin
innecesaria o no razonable.

Ejemplo # 1
Emp_id
101
102

Figura 1: Proceso de normalizacin

Emp_Nomb
Juan
Pedro

Dep_id
401
302

Dep_nom
Recursos
Libros

Se consigue un modelo bien definido y

eficiente mediante las formas normales.

Figura 2: Insercin anmala

Una forma normal es un algoritmo que se

usa para probar la estructura de una tabla,
ayuda a eliminar campos anmalos y
asegura una tabla eficiente [2].

No se puede aadir un nuevo departamento

sin tener al menos un empleado para dicho
departamento, debido a que empleados y
departamentos se almacenan en la misma
tabla.

2.2. Modificacin anmala

Hasta ahora solo hemos explicado el
proceso de normalizacin, pero no hemos
comentado porque debemos usar este
proceso. La razn principal por la cual
normalizar tablas es para asegurar una
estructura eficiente, integridad de la
informacin, para entender porque se debe
considerar una tabla diseada de una
manera no adecuada, se debe entender los
problemas que conlleva.
A continuacin hablaremos
modificacin anmala:

de

la

Ejemplo # 2
Emp_id
101
102

Emp_Nomb
Juan
Pedro

Cl_id
401
401

Cl_nom
Cliente
Cliente

Figura 3: Insercin anmala

El segundo tipo de insercin anormal es

fcil de distinguir porque existe informacin
redundante en la tabla. En el ejemplo
podemos ver que para un cliente hay dos
vendedores asignados, esto implica que
todos los datos del cliente deben repetirse
para cada vendedor.

2.2.2. Borrado anmalo

Un borrado anmalo es cuando se borra un
registro que borrara informacin que no se
pretenda eliminar
2.2.3. Modificacin anmala
Existe cuando la modificacin de un valor
especfico requiere la misma modificacin
en otros registros o tablas.
2.1. 1FN
Una relacin esta en 1FN si y solo si, en
cada valor de esa relacin, cada tupla
contiene exactamente un valor para cada
atributo [3].
El propsito de esta forma normal es
asegurar que la tabla no contiene ningn
campo de varias partes o varios valores, y
que cada campo tiene slo un valor nico
para cualquier registro dado.
Se puede comenzar a normalizar la tabla de
orden mediante la eliminacin de las
caractersticas de varios valores de los
elementos del campo.
La regla fundamental para que una relacin
este en 1FN es atomicidad, quitando grupos
repetidos [4].
A continuacin veremos un ejemplo en el
cual tendremos una relacin sin normalizar
y empezaremos a normalizarla paso a paso:

ESTUDIANTE (carnet, nombre, direccin,

telfono, celular, fax, cdigo_curso,
nombre_curso, escuela, horario, crditos,
saln, seccion, catedrtico, semestre, ao)
Lo primero que debemos hacer es seguir el
principio de atomicidad, teniendo para cada
atributo un solo valor, separando el nombre
en nombre y apellido:

ESTUDIANTE (carnet, nombre, apellido,

direccin, telfono, celular, fax,
cdigo_curso, nombre_curso, escuela,
horario, crditos, saln, seccin, catedrtico,
semestre, ao)
Seguimos normalizando quitando los
grupos repetitivos, en este caso se asume
que no se necesitan 3 nmeros de contacto,
por lo que se deja solo el nmero de
telfono, eliminando el celular y el fax:
ESTUDIANTE (carnet, nombre, apellido,
direccin, telfono, cdigo_curso,
nombre_curso, escuela, horario, crditos,
saln, seccin, catedrtico, semestre, ao)
Hacer tablas separadas para cada conjunto
de atributos similares, y damos una llave
primaria a cada tabla, hacemos como llave
primaria el carnet y el cdigo del curso
puesto que son nicos, no puede haber dos
estudiantes o cursos con los mismos
cdigos:
ESTUDIANTE (carnet, nombre, apellido,
direccin, telfono, cdigo_curso,
nombre_curso, escuela, horario, crditos,
saln, seccin, catedrtico, semestre, ao)

2.2. 2FN
Una relacin esta en 2FN si y solo si esta en
1FN y cada atributo que no es llave es
irreduciblemente dependiente de la llave
primaria [3].
Una vez que la relacin ya est en 1FN
podemos seguir con 2FN. La segunda forma
normal nos asegura que cada atributo que
no es llave en la tabla es funcionalmente
dependiente sobre la llave primaria, y que la
tabla no contiene campos calculados. [5]
Relacin en 1FN:
ESTUDIANTES (carnet, nombre, apellido,
direccin, telfono, cdigo_curso,

nombre_curso, escuela, horario, crditos,

saln, seccin, catedrtico, semestre, ao)
Para seguir con la forma normal 2FN,
debemos asegurar que cada atributo que no
es llave primaria sea dependiente de sta:

Como la definicin lo dice, una tabla debe

estar ya en la segunda forma normal antes
de aplicar la tercera forma normal. Si ste es
el caso, entonces se sigue con la tercera
forma normal para asegurar que cada tabla
contiene las siguientes caractersticas:

ESTUDIANTE (carnet, nombre, apellido,

direccin, telfono, cdigo_curso,
nombre_curso, escuela, horario, crditos,
saln, seccin, catedrtico, semestre, ao)

Como vemos carnet es la llave primaria

para los datos del estudiante, si solo
tuviramos nombre, apellido, direccin o
telfono no nos servira de nada, puesto que
dentro de la institucin cada estudiante se
identifica mediante su carnet.

Ahora debemos quitar las dependencias

parciales y quitar la informacin
redundante. Si un atributo depende en parte
de una llave multi-valuada debemos quitarla
y pasarla a una tabla separada, separamos
los datos en tres tablas, de acuerdo al
conjunto de datos, hacemos 3 tablas:
estudiante, curso y asignacin:

ESTUDIANTE (carnet, nombre, apellido,

direccin, telfono)
CURSO (cdigo_curso, nombre_curso,
escuela, crditos)
ASIGNACION (carnet-codigo_curso,
horario, saln, seccin, catedrtico,
semestre, ao)

2.3. 3FN
Una relacin es en 3FN si y solo si est en
2FN y cada atributo que no es llave no es
transitivamente dependiente de la llave
primaria [3].

Cada valor de cada atributo es

independientemente
modificable,
cambiar el valor de un campo en un
registro no afecta el valor de ningn
otro campo en ese registro.
Cada
campo
identifica
una
caracterstica especfica del conjunto
de datos que se agrupan en una tabla
Cada campo no clave en la tabla es
funcionalmente dependiente sobre
toda la llave primaria
La tabla describe uno y solo un tipo.

La tercera forma normal elimina

dependencias transitivas. Para ello debemos
borrar columnas que no sean dependientes
de la llave primaria. Si algn atributo no
contribuye a la descripcin de una llave,
debemos moverlo a una tabla separada [6]

ESTUDIANTE (carnet, nombre, apellido,

direccin, telfono)
CURSO (cdigo_curso, nombre_curso,
escuela, crditos)
ASIGNACION (carnet-codigo_curso[fk],
semestre, ao, instructor, seccin)
CATEDRATICO (id_catedratico,
catedrtico)
SECCION (seccin, saln, horario)
Como vemos los atributos que no
contribuyen a la llave primaria los hemos
movido para otras tablas, la seccin, saln y
horario del curso se ha movido a una nueva

tabla que se denota como seccin, para

evitar redundancia de informacin, se si
hubiese dejado en la tabla asignacin al
asignar otro estudiante se hubiera tenido
que volver a ingresar sta informacin aun
cuando sean para el mismo saln, seccin y
horario, de igual manera se movi el
catedrtico a una tabla separada,
catedrtico, evitando redundancia y
moviendo atributos que no contribuyen a la
llave primaria a otra tabla.

2.4. 4FN
Una relacin R es en 4FN si y solo si,
cuando existan subconjuntos A y B de los
atributos de R tales que el MVD AB es
satisfecho, entonces todos los atributos de R
son tambin funcionalmente dependientes
de A [3].
El propsito de la cuarta forma normal es
asegurar que una tabla no contenga ninguna
dependencia multi-valuada y que describe
uno y solo un tipo de informacin, es decir,
no mesclar informacin del curso con el del
estudiante. Una tabla que contiene
dependencias multi-valuadas describe uno o
ms tipos de datos, dependiendo del nmero
de dependencias multi-valuadas que
contiene.
Las dependencias multi-valuadas son una
consecuencia de la primera formal normal,
que prohbe que un atributo de una tupla
contenga un conjunto de valores, si tenesmo
dos o ms atributos multi-valuados
independientes en el mismo esquema de
relacin, podramos tener el problema de
tener que repetir valores de uno de los
atributos con cada valor de otro atributo
para que las tuplas de la relacin sigan
siendo consistentes.
ESTUDIANTE (carnet, nombre, apellido,
direccin, telfono)

CURSO (cdigo_curso, nombre_curso,

escuela, crditos)
ASIGNACION (carnet-codigo_curso[fk],
semestre, ao, instructor[fk], seccin[fk])
CATEDRATICO (id_catedratico,
catedrtico)
SECCION (seccin, saln, horario)

2.5. 5FN
Una relacin R esta en 5FN (a la que
tambin se le llama forma normal
Proyeccin/Unin) si y solo si cada
dependencia de unin no-trivial que se
mantiene en R est implcita en las llaves
candidatas de R.
Una dependencia de unin existe para una
tabla dada si la tabla y todo su contenido
original pueden ser reconstruidos por un
Join de SQL que rene todas las tablas
creadas por su descomposicin.
Teniendo nuestras tablas en 4FN, deberan
estar libres de dependencias multi-valuadas
y transitivas, en la mayora de los casos, no
debera haber necesidad de descomponer
mas tablas, sin embargo, si se cree que se
puede o debe descomponer alguna tabla, se
debe verificar si hay un Join de dependencia
en la tabla
Hay 3 preguntas claves que se deben
contestar antes de descomponer ms una
tabla:
1. Puedo crear ms tablas usando la
llave primaria o candidata como
parte de la estructura de la nueva
tabla?
2. Puedo recrear la tabla original
usando un Join en SQL que rena
todas las tablas creadas por la
descomposicin?

3. Perder algn registro en el proceso

de descomponer la tabla?
Si la respuesta a cada pregunta es si,
entonces la est en su quinta forma normal
y se puede hacer la descomposicin. De
cualquier forma, solo porque se pueda
descomponer ms la tabla no significa
necesariamente que se deba hacer.

4. Ventajas Normalizacin:
Como hemos visto durante el artculo el
normalizar nos representa muchas ventajas
que listaremos a continuacin:

ESTUDIANTE (carnet, nombre, apellido,

direccin, telfono)

CURSO (cdigo_curso, nombre_curso,

escuela, crditos)
ASIGNACION (carnet-codigo_curso[fk],
semestre, ao, instructor[fk], seccin[fk])
CATEDRATICO (id_catedratico,
catedrtico)

5. Inconvenientes:
De la misma manera como tenemos ciertas
ventajas
normalizando
tambin
expondremos algunas desventajas:

SECCION (seccin, saln, horario)

3. Terminologa
Para ayudar a la comprensin de las
definiciones tcnicas expuestas en este
artculo se presenta una seria de
terminologa, donde se explica algunas de
las palabras ms usadas:

Relacin = tabla o archivo

Tupla = registro, fila o rengln
Atributo = columna o campo
Clave = llave o cdigo de
identificacin
Clave Candidata = superclave
mnima
Clave Primaria = clave candidata
elegida
Clave Ajena = clave externa o clave
fornea
Clave Alternativa = clave secundaria
Dependencia Multivaluada =
dependencia multivalor

Evitar la redundancia de los datos.

Evitar problemas de actualizacin de
los datos en las tablas.
Seguridad de los datos
Esquema lgico de estructura
Fcil de entender por otros
programadores en un futuro
Escalabilidad
Tamao BBDD

6.

Muchas ms tablas
Velocidad de ejecucin cdigo
(muchos mas join)
Tiempo diseo de la BBDD
Tiempo para programar
Aprendizaje de la normalizacin.

Conclusiones
Lo principal en la primer forma
normal la atomicidad y eliminar los
grupos repetitivos.

En la segunda forma normal nos

interesa hacer tablas separadas para
cada conjunto de datos relacionados
y tambin debemos asignar una llave
primaria a cada tabla.

Debemos asegurarnos de eliminar

las dependencias transitivas. Para
ello debemos borrar columnas que
no sean dependientes de la llave
primaria. Si algn atributo no
contribuye a la descripcin de una

llave, debemos moverlo a una tabla

separada, esto nos lleva a la tercera
forma normal.

Como vimos en la quinta forma

normal, al hacer la prueba del Join
de dependencia, solo porque se
pueda descomponer ms una tabla
no significa necesariamente que se
deba hacer.

Normalizar una base de datos nos

puede representar tambin una
ventaja puesto que una base de datos
normalizada ocupa menos espacio
en disco que una no normalizada,
hay
muchas
repeticiones
de
informacin por lo que ocupara ms
espacio.

7.

El propsito de la cuarta forma

normal es asegurar que una tabla no
contenga ninguna
dependencia
multi-valuada y que describe uno y
solo un tipo de informacin, esto
evita la redundancia de informacin.

Una de las mayores desventajas de

la normalizacin, es el tiempo que
conlleva hacerlo, es un trabajo largo
y se debe hacer con sumo cuidado,
parecera que no es importante, pero
lo es. Ahora si bien se lleva bastante
tiempo el proceso de normalizacin,
tambin esto contrae la ventaja que
una sistema normalizado nos ahorra
tiempo pues es ms fcil su
comprensin [7].

Recomendaciones
Se recomienda seguir paso a paso el
proceso de normalizacin, y leer la
introduccin para entender el
proceso.

Para mejorar la comprensin de las

definiciones y explicaciones se
recomienda leer detenidamente el
punto nmero 3, donde se explican
algunos trminos tcnicos para
mejor comprensin.

Tambin se puede hacer uso de la

herramienta
llamada
DataBase
Normalizer, la cual es una
aplicacin
que
trabaja
con
dependencias
funcionales
y
normaliza esquemas de bases de
datos
relacionales,
con
la
herramienta se puede hacer la
normalizacin
de
manera
automtica, reduce el tiempo
dedicado para normalizar y se evita
el error humano [8].

8. Bibliografa
[1] David Adams, Normalization is a nice
theory.: Foresight Technology, 1997.
[2] Ileana Stefan, Data base design Normalization, 49th ed., 2008.
[3] Michael Hernandez, Understanding
normalization., 2003.
[4] Marin Fotache, Why normalization
failed to become the ultimate guide for
database designers. Romania:
Alexandru Ioan Cuza University of Iasi,
2006.
[5] Eduardo Mora, Formas normales.
Universidad de Cantabria, 1999.
[6] Dennis Santoro, Data normalization.,
2002.
[7] Miguel Carrasco, To normalize or not to
normalize., 2007.
[8] Nabil Arman, Normalizer. Palentine
Polytechnic University, 2006.