2. Normalización
• La normalización es el proceso de organizar los datos
en una base de datos. Esto incluye la creación de tablas
y que establece relaciones entre aquellas tablas según
reglas diseñadas para proteger los datos y hacer la base
de datos que es más flexible al eliminar redundancia y
dependencia incoherente.
Los datos redundantes desperdician espacio en disco y
crean problemas de mantenimiento. Si es necesario
cambiar datos que aparecen en más de un sitio, el
cambio deberá ser exactamente igual en todos estos
sitios. Por ejemplo, un cambio de dirección de un cliente
es mucho más fácil de implementar si los datos sólo se
almacenan en la tabla Clientes y en ningún otro lugar de
la base de datos.
3. Normalización
• ¿Qué es una "dependencia incoherente"? Aunque para un usuario
puede resultar intuitivo buscar la dirección 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 normalización 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 normalización, se considera que la tercera
forma normal es el máximo nivel necesario para la mayoría de las
aplicaciones.
4. 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.
5. Por Ejemplo
Para realizar el seguimiento de un artículo de inventario
que puede provenir de dos orígenes, un registro del
inventario puede contener campos para el Código de
proveedor 1 y el Código de proveedor 2.
¿Qué pasa si agregamos un tercer campo?
La solución no es agregar un campo; hace falta modificar
el programa y la tabla. En su lugar, almacene todas las
informaciones de proveedor en una tabla independiente
denominada Proveedores entonces en lugar de utilizar
los campos proveedor 1, proveedor 2, etc. Utilizamos un
solo campo CódigoProveedor relacionado a la tabla
proveedores.
6. Ejemplo
Artículo Prov1 Prov2 Prov3
Maíz - Granja - En lugar de hacer varios
Arroz Casita - - campos para los
proveedores en una sola
Código Proveedor tabla, hacemos otra tabla
con el campo proveedor y
145 Casita colocamos varios
154 Granja registros para los
proveedores (tabla de en
medio). Sustituimos la
Artículo Cod.Prov tabla superior de la
Maíz 154 izquierda por la tabla
inferior.
Arroz 145
7. 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 sólo deben depender de la
clave principal de una tabla (si es
necesario, puede ser una clave
compuesta).
8. Ejemplo
piense en la dirección de un cliente en un
sistema de contabilidad. La dirección es
necesitada por la tabla Clientes pero por
las tablas Pedidos, Facturas y Cuentas a
cobrar también. En lugar de almacenar la
dirección del cliente como una entrada
diferente en cada tabla, almacénela en un
único lugar, ya sea en la tabla Clientes o
en una tabla de direcciones
independiente.
9. 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 más de un registro de la tabla,
debe tener en cuenta la posibilidad de incluir dichos campos en una
tabla independiente.
• EXCEPCIÓN: No es práctico siempre cumplir la forma tercera
normal teóricamente conveniente. Si tiene una tabla Clientes y
desea eliminar todas las posibles dependencias entre campos,
debe crear tablas independientes para ciudades, códigos postales,
representantes de ventas, clases de clientes y cualquier otro factor
que pueda aparecer duplicado en varios registros. En teoría, la
normalización merece la pena. Sin embargo, la utilización de un
gran número de tablas pequeñas puede perjudicar el rendimiento o
superar la capacidad de memoria y de archivos abiertos del
sistema.
10. Otras formas normales
• Otras formas de normalización
• Existe una cuarta forma normal, llamada
también Forma normal de Boyce Codd
(BCNF), y una quinta forma normal, pero
pocas veces se consideran prácticas en
un diseño. La omisión de estas reglas
puede dar como resultado una tabla que
no sea perfecta, pero no debería afectar a
su funcionamiento
11. Haga esta tabla en Access para normalizarla. La tabla se llama alumnos
12. Primera forma normal: Ningún
grupo repetido
• Como cada alumno se encuentra inscrito
en varios cursos, estos deben aparecer
en una tabla independiente. Los campos
curso1, curso2, curso3 de los registros
anteriores indican que existe un problema
en el diseño.
13.
14. Segunda forma Normal: Elimine
datos redundantes
• Curso no depende del carné (que será
nuestra clave principal) por lo que la tabla
no esta en la segunda forma normal.
Debemos separar la información de los
cursos-alumnos a otra tabla. Haremos la
tabla asignaciones.
16. Tercera forma Normal: Eliminar
datos que no dependen de la clave
• De el último ejemplo la oficina del asesor
depende funcionalmente del atributo
asesor. La solución es mover dicho
atributo de la tabla alumnos a la tabla
personal, como se muestra a
continuación.
19. • Hemos llegado finalmente a una base de
datos bien organizada en la cual podemos
actualizar o cambiar los datos
almacenados fácilmente y de una manera
ordenada sin alterar los demás registros.