Fundamentos de la normalizacin de bases de datosLa 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. 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. 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 las descripciones siguientes se incluyen ejemplos.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.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.

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 normalizacinLa 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.Estos pasos demuestran el proceso de normalizacin de una tabla de alumnos ficticia. 1. Tabla sin normalizar: N alumnoTutorDespacho-TutClase1Clase2Clase3

1022Garca412101-07143-01159-02

4123Daz216201-01211-02214-01

2. Primera forma normal: no hay grupos repetidos

Las tablas slo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseo.

Las hojas de clculo suelen usar la tercera dimensin, pero las tablas no deberan hacerlo. Otra forma de considerar ese problema es con una relacin de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (N clase), segn se muestra a continuacin: N alumnoTutorDespacho-TutN clase

1022Garca412101-07

1022Garca412143-01

1022Garca412159-02

4123Daz216201-01

4123Daz216211-02

4123Daz216214-01

3. Segunda forma normal: eliminar los datos redundantes

Observe los diversos valores de N clase para cada valor de N alumno en la tabla anterior. N clase no depende funcionalmente de N alumno (la clave principal), de modo que la relacin no cumple la segunda forma normal.

Las dos tablas siguientes demuestran la segunda forma normal:

Alumnos:N alumnoTutorDespacho-Tut

1022Garca412

4123Daz216

Registro:N alumnoN clase

1022101-07

1022143-01

1022159-02

4123201-01

4123211-02

4123214-01

4. Tercera forma normal: eliminar los datos no dependientes de la clave

En el ltimo ejemplo, Despacho-Tut (el nmero de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solucin es pasar ese atributo de la tabla Alumnos a la tabla Personal, segn se muestra a continuacin:

Alumnos:N alumnoTutor

1022Garca

4123Daz

Personal:NombreHabitacinDept

Garca41242

Daz21642

(Microsoft, 2013)

Ejemplo de NormalizacinA travs del siguiente ejercicio se intenta afirmar los conocimientos de normalizacin con un ejemplo simplificado de una base de datos para una pequea biblioteca.CodLibroTituloAutorEditorialNombreLectorFechaDev

1001Variable complejaMurray SpiegelMcGraw HillPrez Gmez, Juan15/04/2005

1004Visual Basic 5E. PetroustsosAnayaRos Tern, Ana17/04/2005

1005EstadsticaMurray SpiegelMcGraw HillRoca, Ren16/04/2005

1006Oracle UniversityNancy Greenberg y Priya NathanOracle Corp.Garca Roque, Luis20/04/2005

1007Clipper 5.01RamalhoMcGraw HillPrez Gmez, Juan18/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.1NFCodLibroTituloAutorEditorialPaternoMaternoNombresFechaDev

1001Variable complejaMurray SpiegelMcGraw HillPrezGmezJuan15/04/2005

1004Visual Basic 5E. PetroustsosAnayaRosTernAna17/04/2005

1005EstadsticaMurray SpiegelMcGraw HillRoca Ren16/04/2005

1006Oracle UniversityNancy GreenbergOracle Corp.GarcaRoqueLuis20/04/2005

1006Oracle UniversityPriya NathanOracle Corp.GarcaRoqueLuis20/04/2005

1007Clipper 5.01RamalhoMcGraw HillPrezGmezJuan18/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.2NFCodLibroTituloAutorEditorial

1001Variable complejaMurray SpiegelMcGraw Hill

1004Visual Basic 5E. PetroustsosAnaya

1005EstadsticaMurray SpiegelMcGraw Hill

1006Oracle UniversityNancy Greenberg Oracle Corp.

1006Oracle UniversityPriya NathanOracle Corp.

1007Clipper 5.01RamalhoMcGraw Hill

La nueva tabla slo contendr datos del lector.CodLectorPaternoMaternoNombres

501PrezGmezJuan

502Ros TernAna

503Roca Ren

504GarcaRoqueLuis

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:CodLibroCodLectorFechaDev

100150115/04/2005

100450217/04/2005

100550316/04/2005

100650420/04/2005

100750118/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.3NFCodLibroTitulo

1001Variable compleja

1004Visual Basic 5

1005Estadstica

1006Oracle University

1007Clipper 5.01

CodAutorAutor

801Murray Spiegel

802E. Petroustsos

803Nancy Greenberg

804Priya Nathan

806Ramalho

CodEditorialEditorial

901McGraw Hill

902Anaya

903Oracle 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.

CodLibrocodAutor

1001801

1004802

1005801

1006803

1006804

1007806

CodLibrocodEditorial

1001901

1004902

1005901

1006903

1007901

CodLectorPaternoMaternoNombres

501PrezGmezJuan

502Ros TernAna

503Roca Ren

504GarcaRoqueLuis

CodLibroCodLectorFechaDev

100150115/04/2005

100450217/04/2005

100550316/04/2005

100650420/04/2005

100750118/04/2005

Y el resto de las tablas no necesitan modificacin.(Paez)