Diseño de base de datos con desnormalización

Las reglas de normalización no consideran el rendimiento. En algunos casos, es necesario considerar la desnormalización para mejorar el rendimiento.

Durante el diseño físico, los analistas transforman las entidades en tablas y los atributos en columnas. Considere de nuevo el ejemplo del apartado Segunda forma normal. La columna de dirección de almacén aparece primero como parte de una tabla que contiene información sobre componentes y almacenes. Para normalizar adicionalmente el diseño de la tabla, los analistas eliminan la columna de dirección de almacén de la tabla. Los analistas también definen la columna como parte de una tabla que contiene información únicamente sobre almacenes.

La normalización de tablas es la propuesta que se suele recomendar. Pero ¿qué sucede si las aplicaciones necesitan información sobre componentes y almacenes, incluidas las direcciones de los almacenes? La premisa de las reglas de normalización es que las sentencias de SQL pueden recuperar la información uniendo las dos tablas. El problema es que, en algunos casos, se pueden producir problemas de rendimiento como resultado de una normalización. Por ejemplo, algunas consultas de usuario pueden ver datos que están en una o más tablas relacionadas; el resultado es demasiadas uniones. A medida que crece el número de tablas, los costes de acceso pueden aumentar, según el tamaño de las tablas, los índices disponibles, etc. Por ejemplo, si no hay índices disponibles, la unión de numerosas tablas grandes puede tardar demasiado tiempo. Puede que necesite desnormalizar las tablas. La desnormalización es la duplicación intencionada de columnas en varias tablas y esto aumenta la redundancia de datos.

Ejemplo 1: Considere el diseño en que ambas tablas tienen una columna que contiene las direcciones de almacenes. Si este diseño hace que no sean necesarias operaciones de unión, podría ser que la redundancia valga la pena. Las direcciones de almacenes no cambian a menudo y si cambia alguna puede utilizar SQL para actualizar todas las instancias con bastante facilidad.

Consejo: No suponga automáticamente que todas las uniones tardan demasiado tiempo. Si une tablas normalizadas, no es necesario mantener los mismos valores de datos sincronizados en varias tablas. En muchos casos, las uniones son el método de acceso más eficaz, a pesar de la sobrecarga que suponen. Por ejemplo, algunas aplicaciones alcanzan 44 uniones en un tiempo de respuesta de subsegundos.

Cuando crea el diseño físico, el usuario y sus colegas necesitan decidir si deben desnormalizarse los datos. Específicamente, necesita decidir si deben combinarse tablas o partes de tablas a las que accedan con frecuencia uniones que tienen requisitos de alto rendimiento. Se trata de una decisión compleja sobre la cual esta información no puede proporcionar un consejo específico. Para tomar esta decisión necesita evaluar los requisitos de rendimiento, los diferentes métodos de acceder a los datos y los costes de desnormalización de los datos. Debe tener en cuenta el coste y el resultado; ¿es la duplicación, en varias tablas, de columnas solicitadas con frecuencia menos costosa que el tiempo de llevar a cabo las uniones?

Recomendaciones:

No desnormalice tablas a menos que tenga una buena comprensión de los datos y las transacciones empresariales que acceden a los datos. Consulte con los desarrolladores de aplicaciones antes de desnormalizar tablas para mejorar el rendimiento de las consultas de los usuarios.
Cuando decida si va a desnormalizar una tabla, considere todos los programas que accedan de forma regular a la tabla, tanto para lectura como para actualización. Si los programas actualizan con frecuencia una tabla, la desnormalización de la tabla afecta al rendimiento de los programas de actualización puesto que las actualizaciones se aplican más a varias tablas que a una sola tabla.

En la figura siguiente, la información sobre componentes, almacenes y direcciones de almacenes aparecen en dos tablas, ambas en la forma normal.

Inicio de la descripción de la figura. Esta figura muestra dos tablas que cumplen la segunda forma normal. Fin de la descripción de la figura. — Figura 1. Dos tablas que cumplen la segunda forma normal

La siguiente figura ilustra la tabla desnormalizada.

Inicio de la descripción de la figura. Esta figura muestra una tabla desnormalizada. Fin de la descripción de la figura. — Figura 2. Tabla desnormalizada

La resolución de relaciones de varios con varios es una actividad especialmente importante puesto que ayuda a mantener la claridad e integridad en el diseño físico de bases de datos. Para resolver relaciones de varios con varios, se introducen tablas asociativas, que son tablas intermedias que se utilizan para enlazar, o asociar, dos tablas entre sí.

Ejemplo 2: Los empleados trabajan en muchos proyectos. Los proyectos tienen muchos empleados. En el diseño lógico de bases de datos, esta relación se muestra como una relación de varios con varios entre proyecto y empleado. Para resolver esta relación, se crea una nueva tabla asociativa, EMPLOYEE_PROJECT. Para cada combinación de empleado y proyecto, la tabla EMPLOYEE_PROJECT contiene una fila correspondiente. La clave primaria para la tabla estaría formada por el número de empleado (EMPNO) y el número de proyecto (PROJNO).

Otra decisión que debe tomar está relacionada con la utilización de grupos repetitivos.

Ejemplo 3: Suponga que una transacción que se utiliza mucho necesita el número de cables que se venden al mes en un año específico. Los factores de rendimiento podrían justificar cambiar una tabla de modo que viole la regla de la primera forma normal almacenando grupos repetitivos. En este caso, el grupo repetitivo sería: MONTH, WIRE. La tabla contendría una fila para el número de cables vendidos para cada mes (cables de enero, cables de febrero, cables de marzo, etc.).

Recomendación: Si decide desnormalizar los datos, documéntese en profundidad sobre la desnormalización. Describa, de forma detallada, la lógica de la desnormalización y los pasos que ha seguido. A continuación, si en el futuro la organización necesita normalizar los datos, los encargados de realizar este trabajo dispondrán de un registro preciso.