Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se explica la terminología de normalización de bases de datos para principiantes. Una comprensión básica de esta terminología es útil al analizar el diseño de una base de datos relacional.
Descripción de la normalización
La normalización es el proceso de organización de datos en una base de datos. Incluye la creación de tablas y el establecimiento de relaciones entre esas tablas según las reglas diseñadas para proteger los datos y para que la base de datos sea más flexible eliminando la redundancia y la dependencia incoherente.
Los datos redundantes desperdician espacio en disco y crean problemas de mantenimiento. Si se deben cambiar los datos que existen en más de un lugar, los datos deben cambiarse exactamente de la misma manera en todas las ubicaciones. Un cambio de dirección de cliente es más fácil de implementar si esos datos solo se almacenan en la tabla Customers y en ninguna otra parte de la base de datos.
¿Qué es una "dependencia incoherente"? Aunque es intuitivo que un usuario busque en la tabla Clientes la dirección de un cliente determinado, es posible que no tenga sentido buscar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado o depende del empleado y, por lo tanto, debe trasladarse a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso a los datos porque la ruta de acceso para encontrar los datos puede faltar o romperse.
Hay algunas reglas para la normalización de la base de datos. Cada regla se denomina "forma normal". Si se observa la primera regla, se dice que la base de datos está en "primera forma normal". Si se observan las tres primeras reglas, la base de datos se considera que está en "tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el nivel más alto necesario para la mayoría de las aplicaciones.
Al igual que con muchas reglas y especificaciones formales, los escenarios reales no siempre permiten el cumplimiento perfecto. En general, la normalización requiere tablas adicionales y algunos clientes encuentran este engorroso. Si decide infringir una de las tres primeras reglas de normalización, asegúrese de que la aplicación prevé los problemas que podrían producirse, como los datos redundantes y las dependencias incoherentes.
Entre las descripciones siguientes se incluyen ejemplos.
Primer formulario normal
- Elimine los grupos repetidos en 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 un seguimiento de un elemento de inventario que puede provenir de dos orígenes posibles, un registro de inventario puede contener campos para código de proveedor 1 y código de proveedor 2.
¿Qué ocurre cuando agrega un tercer proveedor? Agregar un campo no es la respuesta; requiere modificaciones de programa y tabla y no admite sin problemas un número dinámico de proveedores. En su lugar, coloque toda la información del proveedor en una tabla independiente denominada Proveedores y, a continuación, vincule el inventario a los proveedores con una clave de número de artículo o los proveedores al inventario con una clave de código de proveedor.
Segunda forma normal
- Cree tablas independientes para conjuntos de valores que se aplican a varios registros.
- Relaciona estas tablas con una clave externa.
Los registros no deben depender de ninguna otra clave principal de una tabla (una clave compuesta, si es necesario). Por ejemplo, considere la dirección de un cliente en un sistema de contabilidad. La dirección es necesaria para la tabla de Clientes, pero también para las tablas de Pedidos, Envíos, Facturas, Cuentas por Cobrar y Cobros. En lugar de almacenar la dirección del cliente como una entrada independiente en cada una de estas tablas, almacénela en un solo lugar, ya sea en la tabla Customers o en una tabla Addresses independiente.
Tercera forma normal
- Elimine los campos que no dependen de la clave.
Los valores de un registro que no forman parte de la clave de ese registro no pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos se aplique a más de un único registro de la tabla, considere la posibilidad de colocar esos campos en una tabla independiente.
Por ejemplo, en una tabla de contratación de empleados, se puede incluir el nombre y la dirección de la universidad de un candidato. Pero necesita una lista completa de universidades para correos de grupo. Si la información universitaria se almacena en la tabla Candidatos, no hay ninguna manera de enumerar universidades sin candidatos actuales. Cree una tabla de universidades independiente y vincule a la tabla Candidatos con una clave de código universitario.
EXCEPCIÓN: La adhesión a la tercera forma normal, aunque teóricamente deseable, no siempre es práctica. Si tiene una tabla Customers y desea eliminar todas las posibles dependencias entre campos, debe crear tablas independientes para ciudades, códigos postales, representantes de ventas, clases de cliente y cualquier otro factor que se pueda duplicar en varios registros. En teoría, la normalización vale la pena perseguir. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar las capacidades de archivos y memoria abiertos.
Puede ser más factible aplicar el tercer formulario normal solo a los datos que cambian con frecuencia. Si permanecen algunos campos dependientes, diseñe la aplicación para exigir al usuario que compruebe todos los campos relacionados cuando se cambie alguno.
Otros formularios de normalización
La cuarta forma normal, también denominada Boyce-Codd forma normal (BCNF) y quinta forma normal existen, pero rara vez se consideran en diseño práctico. Omitir estas reglas puede dar lugar a un diseño de base de datos inferior al perfecto, pero no debería afectar a la funcionalidad.
Normalización de una tabla de ejemplo
Estos pasos muestran el proceso de normalización de una tabla ficticia de alumnos.
Tabla no normalizada:
Estudiante# Asesor Adv-Room Clase1 Class2 Clase3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04 Primer formulario normal: sin grupos repetidos
Las tablas solo deben tener dos dimensiones. Dado que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Class1, Class2 y Class3 de los registros anteriores son indicaciones de problemas de diseño.
Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían. Otra manera de examinar este problema es con una relación uno a varios. No coloque un lado y los muchos lados en la misma tabla. En su lugar, cree otra tabla en primer formato normal eliminando el grupo de repetición (Class#), como se muestra en el ejemplo siguiente:
Estudiante# Asesor Adv-Room Clase# 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 101-07 4123 Smith 216 143-01 4123 Smith 216 179-04 Segundo formulario normal: Eliminar datos redundantes
Tenga en cuenta los distintos valores de Class# para cada valor student# de la tabla anterior. Class# no depende funcionalmente de Student# (clave principal), por lo que esta relación no está en segundo formato normal.
En las tablas siguientes se muestra la segunda forma normal:
Estudiantes:
Estudiante# Asesor Adv-Room 1022 Jones 412 4123 Smith 216 Registro:
Estudiante# Clase# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Tercera forma normal: Eliminar datos no dependientes de la clave
En el último ejemplo, Adv-Room (número de oficina del asesor) depende funcionalmente del atributo Advisor. La solución consiste en mover ese atributo de la tabla Students a la tabla Faculty, como se muestra a continuación:
Estudiantes:
Estudiante# Asesor 1022 Jones 4123 Smith Facultad:
Nombre Sala Departamento Jones 412 42 Smith 216 42