Normalizacin

Descripcin de la normalizacin
La normalizacin es el proceso de organizar los datos en una base de datos. Esto incluye crear tablas y establecer relaciones entre las tablas segn reglas diseadas tanto para proteger los datos y para hacer que la base de datos sea ms flexible eliminando redundancia y dependencias incoherentes. Los datos redundantes desperdician espacio en disco y crean problemas de mantenimiento. Si es necesario cambiar datos que aparecen en ms de un sitio, el cambio deber ser exactamente igual en todos estos sitios. Por ejemplo, un cambio de direccin de un cliente es mucho ms fcil de implementar si los datos slo se almacenan en la tabla Clientes y en ningn otro lugar de la base de datos. Qu es una "dependencia incoherente"? Aunque para un usuario puede resultar intuitivo buscar la direccin de un determinado cliente en la tabla Clientes, es posible que no tenga sentido buscar en esa misma tabla el sueldo del empleado que atiende a dicho cliente. El salario del empleado est relacionado con el empleado (es decir, existe una dependencia entre ambos), por lo que debe moverse a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso a los datos, ya que la ruta de acceso a los mismos puede estar rota o no encontrarse. Existen unas cuantas reglas para la normalizacin de bases de datos. Cada regla se denomina "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, se considera que la base de datos est en la "tercera forma normal" Aunque existen otros niveles de normalizacin, se considera que la tercera forma normal es el mximo nivel necesario para la mayora de las aplicaciones. Como sucede con muchas reglas formales y especificaciones, los escenarios del mundo real no siempre permiten cumplir a la perfeccin estas reglas. En general, la normalizacin requiere tablas adicionales y algunos clientes encontrar este complejo. Si decide no cumplir alguna de las tres primeras reglas de normalizacin, asegrese de que su aplicacin anticipe cualquier posible problema, como datos redundantes y dependencias incoherentes. En las siguientes descripciones puede ver algunos ejemplos. Volver al principio

Primera forma normal

Eliminar grupos repetidos en tablas individuales. Crear una tabla diferente para cada conjunto de datos relacionados. Identificar cada conjunto de datos relacionados mediante una clave principal.

No utilizar varios campos en una nica tabla para almacenar datos similares. Por ejemplo, para realizar el seguimiento de un artculo de inventario que puede provenir de

dos orgenes, un registro del inventario puede contener campos para el Cdigo de proveedor 1 y el Cdigo de proveedor 2. Qu sucede al agregar un tercer proveedor? La solucin no es agregar un campo; hace falta modificar el programa y la tabla, y no se adapta fcilmente a cambios dinmicos en el nmero de proveedores. En su lugar, coloque toda informacin de proveedor en una tabla independiente denominada proveedores, inventario de vnculo a los proveedores con una clave de nmero de artculos o proveedores al inventario con una clave de cdigo de proveedor. Volver al principio

Segunda forma normal

Crear tablas independientes para conjuntos de valores que se apliquen a varios registros. Relacionar dichas tablas mediante una clave externa.

Los registros tan slo deben depender de la clave principal de una tabla (si es necesario, puede ser una clave compuesta). Por ejemplo, piense en la direccin de un cliente en un sistema de contabilidad. La direccin es necesaria por la tabla Customers, sino tambin por las tablas pedidos, envos, facturas, clientes y colecciones. En lugar de almacenar la direccin del cliente como una entrada diferente en cada tabla, almacnela en un nico lugar, ya sea en la tabla Clientes o en una tabla de direcciones independiente. Volver al principio

Tercera forma normal

Eliminar los campos que no dependan de la clave.

Los valores de un registro que no forman parte de la clave de dicho registro no pertenecen a esa tabla. En general, siempre que el contenido de un grupo de campos se puede aplicar a ms de un registro de la tabla, debe tener en cuenta la posibilidad de incluir dichos campos en una tabla independiente. Por ejemplo, en una tabla de Seleccin de empleados pueden incluirse el nombre y la direccin de la universidad de un candidato. Sin embargo, necesita una lista completa de todas las universidades para realizar envos de correo. Si la informacin acerca de la universidad se encuentra en la tabla Candidatos, no hay ninguna forma de ver las universidades que no tengan candidatos. Cree una tabla Universidades separada y vinclela a la tabla Candidatos con una clave de cdigo de universidad. EXCEPCIN: Cumplir la tercera forma normal, aunque tericamente es deseable, no siempre es prctico. Si tiene una tabla Clientes y desea eliminar todas las posibles dependencias entre campos, debe crear tablas independientes para ciudades, cdigos postales, representantes de ventas, clases de clientes y cualquier otro factor que pueda aparecer duplicado en varios registros. En teora, la normalizacin merece la pena. Sin embargo, la utilizacin de un gran nmero de tablas pequeas puede perjudicar el rendimiento o superar la capacidad de memoria y de archivos abiertos del sistema. Una posibilidad es aplicar la tercera forma normal nicamente a los datos que cambien

con frecuencia. Si an quedan campos dependientes, disee la aplicacin de forma que solicite al usuario que compruebe todos los campos relacionados cuando se produzca un cambio en cualquiera de ellos. Volver al principio

Otras formas de normalizacin

Existe una cuarta forma normal, llamada tambin Forma normal de Boyce Codd (BCNF), y una quinta forma normal, pero pocas veces se consideran prcticas en un diseo. La omisin de estas reglas puede dar como resultado una tabla que no sea perfecta, pero no debera afectar a su funcionamiento. Volver al principio

Normalizar una tabla de ejemplo

En los pasos siguientes se demuestra el proceso de normalizacin de una tabla de alumnos ficticia. 1. Tabla sin normalizar: Alumno # Asesor Sala anticipado Class1 Class2 Class3 1022 Jones 412 07-101 143-01 159-02 4123 Smith 216 01-201 02-211 01-214 2. Primera forma normal: Sin grupos repetidos Tablas deben tener slo dos dimensiones. Como cada alumno est inscrito en varias clases, stas deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores indican que existe un problema en el diseo. En las hojas de clculo se utiliza con frecuencia la tercera dimensin, pero no debe hacerse en las tablas. Otra forma de ver el problema es considerar una relacin de uno a varios; no se debe poner en la misma tabla el lado en el que hay un elemento y el lado en el que hay varios elementos. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo de repeticin (N clase), como se muestra a continuacin: Alumno # Asesor Sala anticipado N clase 1022 Jones 412 07-101 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 01-201 4123 Smith 216 02-211 4123 Smith 216 01-214 3. Segunda forma normal: Eliminar datos redundantes

Tenga en cuenta los varios valores de N clase para cada valor de N alumno en la tabla anterior. Clase # no es funcionalmente dependiente de N alumno (clave principal), por lo que esta relacin no es normal segundo formulario. Las dos tablas siguientes muestran la segunda forma normal: Alumnos Alumno # Asesor Sala anticipado 1022 Jones 412 4123 Smith 216 Registro Alumno # N clase 1022 07-101 1022 143-01 1022 159-02 4123 01-201 4123 02-211 4123 01-214 4. Tercera forma normal: Eliminar datos no dependientes en la clave En el ltimo ejemplo anticipado-sala (nmero de oficina del Asesor) depende funcionalmente en el atributo de Asesor. La solucin es mover dicho atributo de la tabla Alumnos a la tabla Personal, como se muestra a continuacin: Alumnos Alumno # Asesor 1022 Jones 4123 Smith Profesores Nombre Saln Departamento Jones 412 42 Smith 216 42