Unidad 4: Normalizacin:

4.1. Fundamentos de la Normalizacin

4.2 Niveles de Normalizacin
4.2.1. Primera Forma Normal
4.2.2. Segunda Forma Normal
4.2.3. Tercera Forma Normal
4.3 Normalizar una Tabla de Ejemplo

4.1 Fundamentos de la normalizacin

La normalizacin es el proceso de organizar los datos de una base de datos. Se

incluye la creacin de tablas y el establecimiento de relaciones entre ellas segn
reglas diseadas tanto para proteger los datos como para hacer que la base de datos
sea ms flexible al eliminar la redundancia y las dependencias incoherentes. Tambin
se puede entender la normalizacin como una serie de reglas que sirven para ayudar
a los diseadores de bases de datos a desarrollar un esquema que minimice los
problemas de lgica. Cada regla est basada en la que le antecede. La normalizacin
se adopt porque el viejo estilo de poner todos los datos en un solo lugar, como un
archivo o una tabla de la base de datos, era ineficiente y conduca a errores de lgica
cuando se trataban de manipular los datos.

Otra ventaja de la normalizacin de base de datos es el consumo de espacio. Una

base de datos normalizada ocupa menos espacio en disco que una no normalizada.
Los datos redundantes desperdician el espacio de disco y crean problemas de
mantenimiento. Si hay que cambiar datos que existen en ms de un lugar, se deben
cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la
direccin de un cliente es mucho ms fcil de implementar si los datos slo se
almacenan en la tabla Clientes y no en algn otro lugar de la base de datos.

Qu es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar

en la tabla Clientes para buscar la direccin de un cliente en particular, puede no tener
sentido mirar all el salario del empleado que llama a ese cliente. El salario del
empleado est relacionado con el empleado, o depende de l, y por lo tanto se
debera pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar
el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.

4.2 Niveles de Normalizacin

Hay algunas reglas en la normalizacin de una base de datos. Cada regla se

denomina una "forma normal". Si se cumple la primera regla, se dice que la base de
datos est en la "primera forma normal". Si se cumplen las tres primeras reglas, la
base de datos se considera que est en la "tercera forma normal". Aunque son
posibles otros niveles de normalizacin, la tercera forma normal se considera el
mximo nivel necesario para la mayor parte de las aplicaciones.

Al igual que con otras muchas reglas y especificaciones formales, en los escenarios
reales no siempre se cumplen los estndares de forma perfecta. En general, la
normalizacin requiere tablas adicionales y algunos clientes consideran ste un trabajo
considerable. Si decide infringir una de las tres primeras reglas de la normalizacin,
asegrese de que su aplicacin se anticipa a los problemas que puedan aparecer,
como la existencia de datos redundantes y de dependencias incoherentes.

En la tabla siguiente se describe brevemente en qu consiste cada una de las reglas, y

posteriormente se explican con ms detalle.

4.2.1 Primera forma normal

Elimine los grupos repetidos de las tablas individuales.

Cree una tabla independiente para cada conjunto de datos relacionados.

Identifique cada conjunto de datos relacionados con una clave principal.

No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo,
para realizar el seguimiento de un elemento del inventario que proviene de dos
orgenes posibles, un registro del inventario puede contener campos para el Cdigo de
proveedor 1 y para el Cdigo de proveedor 2.

Qu ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la

respuesta, requiere modificaciones en las tablas y el programa, y no admite fcilmente
un nmero variable de proveedores. En su lugar, coloque toda la informacin de los
proveedores en una tabla independiente denominada Proveedores y despus vincule
el inventario a los proveedores con el nmero de elemento como clave, o los
proveedores al inventario con el cdigo de proveedor como clave.

4.2.2. Segunda forma normal

Cree tablas independientes para conjuntos de valores que se apliquen a varios

registros.

Relacione estas tablas con una clave externa.

Los registros no deben depender de nada que no sea una clave principal de una tabla,
una clave compuesta si es necesario. Por ejemplo, considere la direccin de un cliente
en un sistema de contabilidad. La direccin se necesita en la tabla Clientes, pero
tambin en las tablas Pedidos, Envos, Facturas, Cuentas por cobrar y Colecciones.
En lugar de almacenar la direccin de un cliente como una entrada independiente en
cada una de estas tablas, almacnela en un lugar, ya sea en la tabla Clientes o en una
tabla Direcciones independiente.

4.2.3. Tercera forma normal

Elimine los campos que no dependan de la clave.

Los valores de un registro que no sean parte de la clave de ese registro no pertenecen
a la tabla. En general, siempre que el contenido de un grupo de campos pueda
aplicarse a ms de un nico registro de la tabla, considere colocar estos campos en
una tabla independiente. Por ejemplo, en una tabla Contratacin de empleados, puede
incluirse el nombre de la universidad y la direccin de un candidato. Pero necesita una
lista completa de universidades para enviar mensajes de correo electrnico en grupo.
Si la informacin de las universidades se almacena en la tabla Candidatos, no hay
forma de enumerar las universidades que no tengan candidatos en ese momento.
Cree una tabla Universidades independiente y vinclela a la tabla Candidatos con el
cdigo de universidad como clave.

EXCEPCIN: cumplir la tercera forma normal, aunque en teora es deseable, no

siempre es prctico. Si tiene una tabla Clientes y desea eliminar todas las
dependencias posibles entre los campos, debe crear tablas independientes para las
ciudades, cdigos postales, representantes de venta, clases de clientes y cualquier
otro factor que pueda estar duplicado en varios registros. En teora, la normalizacin
merece el trabajo que supone. Sin embargo, muchas tablas pequeas pueden
degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.

Puede ser ms factible aplicar la tercera forma normal slo a los datos que cambian
con frecuencia. Si quedan algunos campos dependientes, disee la aplicacin para
que pida al usuario que compruebe todos los campos relacionados cuando cambie
alguno.

Otras formas de normalizacin

La cuarta forma normal, tambin llamada Forma normal de Boyce Codd (BCNF, Boyce
Codd Normal Form), y la quinta forma normal existen, pero rara vez se consideran en
un diseo real. Si no se aplican estas reglas, el diseo de la base de datos puede ser
menos perfecto, pero no debera afectar a la funcionalidad.

4.3 Normalizar una tabla de ejemplo

Estos pasos demuestran el proceso de normalizacin de una tabla de alumnos ficticia.

1. Tabla sin normalizar:

CodLibro Titulo Autor Editorial NombreLector FechaDev

1001 Variable compleja Murray Spiegel McGraw Hill Prez Gmez, Juan 15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ros Tern, Ana 17/04/2005
1005 Estadstica Murray Spiegel McGraw Hill Roca, Ren 16/04/2005
1006 Oracle University Nancy Greenberg Oracle Corp. Garca Roque, 20/04/2005
CodLibro Titulo Autor Editorial NombreLector FechaDev
y Priya Nathan Luis
1007 Clipper 5.01 Ramalho McGraw Hill Prez Gmez, Juan 18/04/2005

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo tener campos
atmicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en
apellido y nombres. Tal como se muestra en la siguiente tabla.
1NF
CodLibro Titulo Autor Editorial Apellido Nombres FechaDev
Variable
1001 Murray Spiegel McGraw Hill Prez Juan 15/04/2005
compleja
1004 Visual Basic 5 E. Petroustsos Anaya Ros Ana 17/04/2005
1005 Estadstica Murray Spiegel McGraw Hill Roca Ren 16/04/2005
1006 OracleUniversity NancyGreenberg Oracle Corp. Garca Luis 20/04/2005
1006 OracleUniversity Priya Nathan Oracle Corp. Garca Luis 20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Prez Juan 18/04/2005

Como se puede ver, hay cierta redundancia caracterstica de 1NF.

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra
manera, todos los atributos no clave deben depender por completo de la clave primaria.
Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como
atributo clave el cdigo del libro.

Por ejemplo, el ttulo es completamente identificado por el cdigo del libro, pero el nombre del
lector en realidad no tiene dependencia de este cdigo, por tanto estos datos deben ser
trasladados a otra tabla.

2NF
CodLibro Titulo Autor Editorial

1001 Variable compleja Murray Spiegel McGraw Hill

1004 Visual Basic 5 E. Petroustsos Anaya

1005 Estadstica Murray Spiegel McGraw Hill

1006 Oracle University NancyGreenberg Oracle Corp.

1006 Oracle University Priya Nathan Oracle Corp.

1007 Clipper 5.01 Ramalho McGraw Hill

La nueva tabla slo contendr datos del lector.

CodLector Apellido Nombres

501 Prez Juan

502 Ros Ana

503 Roca Ren

504 Garca Luis

Hemos creado una tabla para contener los datos del lector y tambin tuvimos que crear la
columna CodLector para identificar unvocamente a cada uno. Sin embargo, esta nueva
disposicin de la base de datos necesita que exista otra tabla para mantener la informacin de
qu libros estn prestados a qu lectores. Esta tabla se muestra a continuacin:

CodLibro CodLector FechaDev

1001 501 15/04/2005

1004 502 17/04/2005

1005 503 16/04/2005

1006 504 20/04/2005

1007 501 18/04/2005

Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems los atributos no
clave deben ser mutuamente independientes y dependientes por completo de la clave primaria.
Tambin recordemos que dijimos que esto significa que las columnas en la tabla deben
contener solamente informacin sobre la entidad definida por la clave primaria y, por tanto, las
columnas en la tabla deben contener datos acerca de una sola cosa.

En nuestro ejemplo en 2NF, la primera tabla conserva informacin acerca del libro, los autores
y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF.

3NF
CodLibro Titulo

1001 Variable compleja

1004 Visual Basic 5

1005 Estadstica

1006 Oracle University

1007 Clipper 5.01

CodAutor Autor

801 Murray Spiegel

802 E. Petroustsos

803 Nancy Greenberg

804 Priya Nathan

806 Ramalho

CodEditorial Editorial

901 McGraw Hill

902 Anaya

903 Oracle Corp.

Aunque hemos creado nuevas tablas para que cada una tenga slo informacin acerca de una
entidad, tambin hemos perdido la informacin acerca de qu autor ha escrito qu libro y las
editoriales correspondientes, por lo que debemos crear otras tablas que relacionen cada libro
con sus autores y editoriales.

CodLibro codAutor

1001 801

1004 802

1005 801

1006 803

1006 804

1007 806

CodLibro codEditorial
1001 901

1004 902

1005 901

1006 903

1007 901

Y el resto de las tablas no necesitan modificacin.

CodLector Apellido Nombres

501 Prez Juan

502 Ros Ana

503 Roca Ren

504 Garca Luis

CodLibro CodLector FechaDev

1001 501 15/04/2005

1004 502 17/04/2005

1005 503 16/04/2005

1006 504 20/04/2005

1007 501 18/04/2005