__________________________________________________________________________________________________

La normalizacin y Algunos Ejemplos

La normalizacin es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos ms pequeas, que adems de ser ms simples y ms estables, son ms fciles de mantener. 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. La normalizacin tambin hace las cosas fciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al mximo. Lo hacemos con casi todo, desde los animales hasta con los automviles. Vemos una imagen de gran tamao y la hacemos ms simple agrupando cosas similares juntas. Las guas que la normalizacin provee crean el marco de referencia para simplificar una estructura de datos compleja. 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. Hay menos repeticin de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. El proceso de normalizacin tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, as como las razones para hacerlo de esta manera.
Grados de normalizacin

Existen bsicamente tres niveles de normalizacin: Primera Forma Normal (1NF), Segunda Forma Normal (2NF) Tercera Forma Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada a esa forma de normalizacin. No siempre es una buena idea tener una base de datos conformada en el nivel ms alto de normalizacin, puede llevar a un nivel de complejidad que pudiera ser evitado si estuviera en un nivel ms bajo de normalizacin.

En la tabla siguiente se describe brevemente en que consiste cada una de las reglas, y posteriormente se explican con ms detalle.

__________________________________________________________________________________________________ Regla Primera Forma Normal (1FN) repetidos. Asegura que todas las columnas que no son llave sean completamente dependientes de la llave primaria (PK). Elimina cualquier dependencia transitiva. Una dependencia transitiva es aquella en la cual las columnas que no son llave son dependientes de otras columnas que tampoco son llave. Descripcin Incluye la eliminacin de todos los grupos

Segunda Forma Normal (2FN)

Tercera Forma Normal (3FN)

Primera Forma Normal

La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna mltiples. Muy a menudo, los diseadores de bases de datos inexpertos harn algo similar a la tabla no normalizada. Una y otra vez, crearn columnas que representen los mismos datos. La normalizacin ayuda a clarificar la base de datos y a organizarla en partes ms pequeas y ms fciles de entender. En lugar de tener que entender una tabla gigantesca y monoltica que tiene muchos diferentes aspectos, slo tenemos que entender los objetos pequeos y ms tangibles, as como las relaciones que guardan con otros objetos tambin pequeos.
Segunda Forma Normal

La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un trmino que describe a aquellos datos que no dependen de la llave primaria de la tabla para identificarlos. Una vez alcanzado el nivel de la Segunda Forma Normal, se controlan la mayora de los problemas de lgica. Podemos insertar un registro sin un exceso de datos en la mayora de las tablas.
Tercera Forma Normal

Una tabla est normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Comentamos anteriormente que una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen de otras columnas que tampoco son llave. Cuando las tablas estn en la Tercera Forma Normal se previenen errores de lgica cuando se insertan o borran registros. Cada columna en una tabla est identificada de manera nica por la llave primaria, y no deben haber datos repetidos. Esto provee un esquema limpio y elegante, que es fcil de trabajar y expandir.

__________________________________________________________________________________________________

A travs del siguiente ejercicio se intenta afirmar los conocimientos de normalizacin con un ejemplo simplificado de una base de datos para una pequea biblioteca.
CodLibro Titulo Autor Editorial NombreLector Prez Gmez, Juan Ros Tern, Ana Roca, Ren Garca Roque, Luis Prez Gmez, Juan FechaDevolucion

1001

Variable compleja

Murray Spiegel

McGraw Hill

15/04/2005

1004 1005

Visual Basic 5 Estadstica

E. Petroustsos Murray Spiegel Nancy Greenberg y Priya Nathan

Anaya McGraw Hill

17/04/2005 16/04/2005

1006

Oracle University

Oracle Corp.

20/04/2005

1007

Clipper 5.01

Ramalho

McGraw Hill

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 paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla. 1NF
CodLibro Titulo Autor Editorial Primer Apellido Lector Prez Segundo Apellido Lector Gmez Nombre Lector Fecha Devolucin

1001

Variable compleja Visual Basic 5 Estadstica Oracle University Oracle University Clipper 5.01

Murray Spiegel

McGraw Hill

Juan

15/04/2005

1004

E. Petroustsos

Anaya

Ros

Tern

Ana

17/04/2005

1005

Murray Spiegel Nancy Greenberg

McGraw Hill

Roca

Ren

16/04/2005

1006

Oracle Corp.

Garca

Roque

Luis

20/04/2005

1006

Priya Nathan

Oracle Corp.

Garca

Roque

Luis

20/04/2005

1007

Ramalho

McGraw Hill

Prez

Gmez

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 1001 1004 1005 Titulo Variable compleja Visual Basic 5 Estadstica Autor Murray Spiegel E. Petroustsos Murray Spiegel Nancy Greenberg Priya Nathan Ramalho Editorial McGraw Hill Anaya McGraw Hill

1006

Oracle University

Oracle Corp.

1006 1007

Oracle University Clipper 5.01

Oracle Corp. McGraw Hill

La nueva tabla slo contendr datos del lector.

CodLector Primer Segundo Nombres Apellido Apellido 501 502 503 504 Prez Ros Roca Garca Roque Gmez Tern Juan Ana Ren 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 1001 1004 1005 1006 1007 501 502 503 504 501

FechaDev 15/04/2005 17/04/2005 16/04/2005 20/04/2005 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

CodAutor

Autor

CodEditorial

Editorial

1001 Variable compleja 1004 Visual Basic 5 1005 Estadstica 1006 Oracle University 1007 Clipper 5.01

801 Murray Spiegel 802 E. Petroustsos 803 Nancy Greenberg 804 Priya Nathan 806 Ramalho

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 1001 1004 1005 1006 1006 1007 codAutor 801 802 801 803 804 806 CodLibro 1001 1004 1005 1006 1007 codEditorial 901 902 901 903 901

CodLector Primer Segundo Nombres Apellido Apellido 501 Prez 502 Ros 503 Roca 504 Garca Roque Gmez Tern Juan Ana Ren Luis

CodLibro CodLector FechaDevolucion 1001 1004 1005 1006 1007 501 502 503 504 501 15/04/2005 17/04/2005 16/04/2005 20/04/2005 18/04/2005

Y el resto de las tablas no necesitan modificacin.

__________________________________________________________________________________________________

Bsicamente, las reglas de Normalizacin estn encaminadas a eliminar redundancias e inconsistencias de dependencia en el diseo de las tablas. En este ejemplo vemos los cinco pasos progresivos para normalizar, tienes que tener en cuenta que debes crear una BD funcional y eficiente. Tambin detallar los tipos de relaciones que tu estructura de datos puede tener. Digamos que queremos crear una tabla con la informacin de usuarios, y los datos a guardar son el nombre, la empresa, la direccin de la empresa y algn e-mail, o bien URL si las tienen. En principio comenzaremos definiendo la estructura de una tabla como esta: Formalizacin CERO
usuarios nombre Joe Jill empresa ABC XYZ direccion_empresa 1 Work Lane 1 Job Street url1 www.abc.com www.abc.com url2 www.xyz.com www.xyz.com

Diramos que la anterior tabla esta en nivel de Formalizacin Cero porque ninguna de nuestras reglas de normalizacin ha sido aplicada. Observa los campos url1 y url2 -- Qu haremos cuando en nuestra aplicacin necesitemos una tercera url ? Quieres tener que aadir otro campo/columna a tu tabla y tener que reprogramar toda la entrada de datos de tu cdigo PHP ? Obviamente no, tu quieres crear un sistema funcional que pueda crecer y adaptarse fcilmente a los nuevos requisitos. Echemos un vistazo a las reglas del Primer Nivel de Formalizacin-Normalizacin, y las aplicaremos a nuestra tabla.

1FN - Primer nivel de Formalizacin/Normalizacin. (F/N)

1. 2. 3. Eliminar los grupos repetitivos de la tablas individuales. Crear una tabla separada por cada grupo de datos relacionados. Identificar cada grupo de datos relacionados con una clave primaria.

Ves que estamos rompiendo la primera regla cuando repetimos los campos url1 y url2 ? Y que pasa con la tercera regla, la clave primaria ? La regla tres bsicamente significa que tenemos que poner una campo tipo contador autoincrementable para cada registro. De otra forma, Qu pasara si tuviramos dos usuarios llamados Joe y queremos diferenciarlos. Una vez que apliquemos el primer nivel de F/N nos encontraremos con la siguiente tabla: Usuarios userId 1 1 2 2 nombre Joe Joe Jill Jill Empresa ABC ABC XYZ XYZ direccion_empresa 1 Work Lane 1 Work Lane 1 Job Street 1 Job Street url www.abc.com www.xyz.com www.abc.com www.xyz.com

Ahora diremos que nuestra tabla est en el primer nivel de F/N. Hemos solucionado el problema de la limitacin del campo url. Pero sin embargo vemos otros problemas....Cada vez que introducimos un nuevo registro en la tabla usuarios, tenemos que duplicar el nombre de la empresa y del usuario. No slo nuestra BD crecer muchsimo, sino que ser muy fcil que la BD se corrompa si escribimos mal alguno de los datos redundantes. Aplicaremos pues el segundo nivel de F/N:

__________________________________________________________________________________________________ 1. 2. Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros. Relacionar estas tablas mediante una clave externa. Hemos separado el campo url en otra tabla, de forma que podemos aadir ms en el futuro si tener que duplicar los dems datos. Tambin vamos a usar nuestra clave primaria para relacionar estos campos: usuarios userId 1 2 urls urlId 1 2 3 4 relUserId 1 1 2 2 url www.abc.com www.xyz.com www.abc.com www.xyz.com nombre Joe Jill empresa ABC XYZ direccion_empresa 1 Work Lane 1 Job Street

Como vemos , hemos creado tablas separadas y la clave primaria en la tabla usuarios, userId, esta relacionada ahora con la clave externa en la tabla urls, relUserId. Esto esta mejor. Pero que ocurre cuando queremos aadir otro empleado a la empresa ABC ? o 200 empleados ? Ahora tenemos el nombre de la empresa y su direccin duplicndose, otra situacin que puede inducirnos a introducir errores en nuestros datos. As que tendremos que aplicar el tercer nivel de F/N:

3FN - Tercer nivel de F/N.

1. Eliminar aquellos campos que no dependan de la clave.

Nuestro nombre de empresa y su direccin no tienen nada que ver con el campo userId, asi que tienen que tener su propio empresaId: usuarios userId 1 2 empresas emprId 1 2 urls urlId RelUserId url empresa ABC XYZ direccion_empresa 1 Work Lane 1 Job Street nombre Joe Jill relEmpresaId 1 2

__________________________________________________________________________________________________ 1 2 3 4 1 1 2 2 www.abc.com www.xyz.com www.abc.com www.xyz.com

Ahora tenemos la clave primaria emprId en la tabla empresas relacionada con la clave externa recEmpresaId en la tabla usuarios, y podemos aadir 200 usuarios mientras que slo tenemos que insertar el nombre 'ABC' una vez. Nuestras tablas de usuarios y urls pueden crecer todo lo que quieran sin duplicacin ni corrupcin de datos. La mayoria de los desarrolladores dicen que el tercer nivel de F/N es suficiente, que nuestro esquema de datos puede manejar fcilmente los datos obtenidos de una cualquier empresa en su totalidad, y en la mayora de los casos esto ser cierto. Pero echemos un vistazo a nuestro campo urls - Ves duplicacin de datos ? Esto es perfectamente aceptable si la entrada de datos de este campo es solicitada al usuario en nuestra aplicacin para que teclee libremente su url, y por lo tanto es slo una coincidencia que Joe y Jill teclearon la misma url. Pero que pasa si en lugar de entrada libre de texto usramos un men desplegable con 20 o incluso ms urls predefinidas ? Entonces tendramos que llevar nuestro diseo de BD al siguiente nivel de F/N, el cuarto, muchos desarrolladores lo pasan por alto porque depende mucho de un tipo muy especfico de relacin, la relacin 'varios-con-varios', la cual an no hemos encontrado en nuestra aplicacin.

Antes de definir el cuarto nivel de F/N, veremos tres tipos de relaciones entre los datos: uno-a-uno, uno-con-varios y varioscon-varios. Mira la tabla usuarios en el Primer Nivel de F/N del ejemplo de arriba. Por un momento imaginemos que ponemos el campo url en una tabla separada, y cada vez que introducimos un registro en la tabla usuarios tambin introducimos una sola fila en la tabla urls. Entonces tendramos una relacin uno-a-uno: cada fila en la tabla usuarios tendra exactamente una fila correspondiente en la tabla urls. Para los propsitos de nuestra aplicacin no sera til la normalizacin. Ahora mira las tablas en el ejemplo del Segundo Nivel de F/N. Nuestras tablas permiten a un slo usuario tener asociadas varias urls. Esta es una relacin uno-con-varios, el tipo de relacin ms comn, y hasta que se nos present el dilema del Tercer Nivel de F/N. la nica clase de relacin que necesitamos. La relacin varios-con-varios, sin embargo, es ligeramente ms compleja. Observa en nuestro ejemplo del Tercer Nivel de F/N que tenemos a un usuario relacionado con varias urls. Como dijmos, vamos a cambiar la estructura para permitir que varios usuarios esten relacionados con varias urls y as tendremos una relacin varios-con-varios. Veamos como quedaran nuestras tablas antes de seguir con este planteamiento: usuarios userId 1 2 empresas emprId 1 2 urls empresa ABC XYZ direccion_empresa 1 Work Lane 1 Job Street nombre Joe Jill relEmpresaId 1 2

__________________________________________________________________________________________________ urlId 1 2 url_relations relationId 1 2 3 4 relatedUrlId 1 1 2 2 relatedUserId 1 2 1 2 url abc.com xyz.com

Para disminuir la duplicacin de los datos ( este proceso nos llevar al Cuarto Nivel de F/N), hemos creado una tabla que slo tiene claves externas y primarias url_relations. Hemos sido capaces de remover las entradas duplicadas en la tabla urls creando la tabla url_relations. Ahora podemos expresar fielmente la relacin que ambos Joe and Jill tienen entre cada uno de ellos, y entre ambos, las urls. As que veamos exactamente que es lo que el Cuarto Nivel de F/N. supone:

4FN - Cuarto Nivel de F/N.

1. En las relaciones varios-con-varios, entidades independientes no pueden ser almacenadas en la misma tabla.

Ya que slo se aplica a las relaciones varios-con-varios, la mayora de los desarrolladores pueden ignorar esta regla de forma correcta. Pero es muy til en ciertas situaciones, tal como esta. Hemos optimizado nuestra tabla urls eliminado duplicados y hemos puesto las relaciones en su propia tabla. En la practica, si nos vamos mas all, por ejemplo al modelo fisio, ahora podremos seleccionar todas las urls de Joe realizando la siguiente instruccin SQL: SELECT nombre, url FROM usuarios, urls, url_relations WHERE url_relations.relatedUserId = 1 AND usuarios.userId = 1 AND urls.urlId = url_relations.relatedUrlId Y si queremos recorrer todas las urls de cada uno de los usuarios, hariamos algo as: SELECT nombre, url FROM usuarios, urls, url_relations WHERE usuarios.userId = url_relations.relatedUserId AND urls.urlId = url_relations.relatedUrlId

5FN - Quinto Nivel de F/N.

Existe otro nivel de normalizacin que se aplica a veces, pero es de hecho algo esotrico y en la mayoria de los casos no es necesario para obtener la mejor funcionalidad de nuestra estructura de datos o aplicacin. Su principio sugiere: 1. La tabla original debe ser reconstruida desde las tablas resultantes en las cuales a sido troceada.

Los beneficios de aplicar esta regla aseguran que no has creado ninguna columna extraa en tus tablas y que la estructura de las tablas que has creado sea del tamao justo que tiene que ser. Es una buena prctica aplicar este regla, pero a no ser que ests tratando con una extensa estructura de datos probablemente no la necesitars. Espero que hayas encontrado este artculo til, y que seas capaz de aplicar estas reglas de normalizacin a todos tus proyectos de bases de datos. Y en el caso que te estes preguntando de donde viene todo esto, las tres primeras reglas de normalizacin fueron perfiladas por el Dr. E.F.Codd en su escrito de 1972, "Further Normalization of the Data Base

__________________________________________________________________________________________________ Relational Model" ( Referente a la normalizacin de las Bases de Datos Relacionales). La otras reglas han sido teorizadas por posteriores matemticos/Algebristas.

Qu tan lejos debe llevar la normalizacin?

La siguiente decisin es qu tan lejos debe llevar la normalizacin? La normalizacin es una ciencia subjetiva. Determinar las necesidades de simplificacin depende de nosotros. Si nuestra base de datos va a proveer informacin a un solo usuario para un propsito simple y existen pocas posibilidades de expansin, normalizar los datos hasta la 3FN quiz sea algo exagerado. Las reglas de normalizacin existen como reglas para crear tablas que sean fciles de manejar, as como flexibles y eficientes. A veces puede ocurrir que normalizar los datos hasta el nivel ms alto no tenga sentido. Se estn dividiendo tablas slo para seguir las reglas o estas divisiones son en verdad prcticas?. stas son el tipo de cosas que nosotros como diseadores de la base de datos, necesitamos decidir, y la experiencia y el sentido comn nos pueden auxiliar para tomar la decisin correcta. La normalizacin no es una ciencia exacta, ms bien subjetiva. Existen seis niveles ms de normalizacin que no se han discutido aqu. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyeccin-Unin, Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de Proyeccin-Unin Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalizacin pueden llevar las cosas ms all de lo que necesitamos. stas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias mltiples y claves relacionales.
En resumen

La normalizacin es una tcnica que se utiliza para crear relaciones lgicas apropiadas entre tablas de una base de datos. Ayuda a prevenir errores lgicos en la manipulacin de datos. La normalizacin facilita tambin agregar nuevas columnas sin romper el esquema actual ni las relaciones. Existen varios niveles de normalizacin: Primera Forma Normal, Segunda Forma Normal, Tercera Forma Normal, Forma Normal Boyce-Codd, Cuarta Forma Normal, Quinta Forma Normal o Forma Normal de Proyeccin-Unin, Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de Proyeccin-Unin Extra Fuerte y Forma Normal de Clave de Dominio. Cada nuevo nivel o forma nos acerca ms a hacer una base de datos verdaderamente relacional. Se discutieron las primeras tres formas. stas proveen suficiente nivel de normalizacin para cumplir con las necesidades de la mayora de las bases de datos. Normalizar demasiado puede conducir a tener una base de datos ineficiente y hacer a su esquema demasiado complejo para trabajar. Un balance apropiado de sentido comn y prctico puede ayudarnos a decidir cundo normalizar.