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
145 Casita y colocamos varios
registros para los
154 Granja proveedores (tabla de en
medio). Sustituimos la
Artículo Cod.Prov tabla superior de la
izquierda por la tabla
Maíz 154 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.
