Denormalización (base de datos)

La desnormalización es el proceso de procurar optimizar el funcionamiento de una base de datos por medio de agregar datos redundantes.^[1] A veces es necesario porque los actuales sistemas de gestión de bases de datos (SGBD) implementan el modelo relacional de manera limitada. Un SGBD relacional que cumpla las recomendaciones ISO debe permitir una base de datos completamente normalizada a nivel lógico, soportado por un almacenamiento físico de los datos afinado para los requisitos necesarios del sistema.^[2]

Almacenamiento de datos[editar]

Un diseño normalizado a menudo almacenará diferentes, pero relacionadas, piezas de información en tablas lógicas separadas (denominada relaciones). Si estas relaciones están almacenadas físicamente en dos archivos distintos en disco, su recuperación para realizar una consulta a la base de datos que se base en información de varias relaciones (una operación JOIN) puede ser muy lenta, llegando a no satisfacer determinados requisitos no funcionales del sistema. Hay dos estrategias para tratar de solventar esta situación:

El método preferido es mantener normalizado el diseño lógico, pero indicar al SGBD que almacene en el disco información redundante para optimizar la respuesta a la consulta. En este caso, es responsabilidad del software del SGBD proveer soporte para gestionar la confidencialidad de los datos en todos los niveles de la arquitectura. Este método es implementado de diversa manera según el desarrollador: en Microsoft SQL Server se usan vistas indexadas, en lote productos de Oracle vistas materializadas, etc. Una vista representa la información en un formato conveniente para consultar, y el índice asegura que las consultas contra la vista estén optimizadas.
Sin embargo, la aproximación más usual es desnormalizar el diseño de datos lógico. Realizado con cuidado, esto puede alcanzar una mejora similar en respuesta de consulta, pero complica la tarea de los usuarios que modifiquen contenido del sistema: ahora es la responsabilidad del diseñador de la base de datos el asegurarse de que la base de datos desnormalizada no llegue a ser inconsistente. Esto se realiza mediante reglas en la base de datos llamadas restricciones, que especifican cómo las copias redundantes de información se deben mantener sincronizadas. Es el aumento en la complejidad lógica del diseño de la base de datos y la complejidad añadida de las restricciones adicionales lo que hacen de esta una alternativa delicada. Por otra parte, debido a los gastos indirectos de evaluación de restricciones al insertar, actualizar, o eliminar datos, una base de datos desnormalizada puede llegar a ofrecer en la práctica un rendimiento inferior al que proporcionaba su versión equivalente normalizada. En cambio, cuando se está seleccionado o leyendo datos a menudo el funcionamiento es más probable que sí se mejore.

Desnormalización versus no normalización[editar]

Un modelo de datos desnormalizado no es lo mismo que un modelo de datos que no ha sido normalizado, y la desnormalización debe tomar lugar solamente después de que haya ocurrido un nivel satisfactorio de normalización y de que hayan sido creadas las restricciones y/o reglas requeridas para ocuparse de las anomalías inherentes en el diseño. Por ejemplo, que todas las relaciones estén en la tercera forma normal y cualquier relación con dependencias de unión (JOIN) y multi-valor sean manejadas apropiadamente.

Implementación[editar]

Ejemplos de técnicas de desnormalización incluyen:

Vistas materializadas, que pueden implementar lo siguiente:
- Almacenando la cuenta de "muchos" objetos en una relación uno-a-muchos como un atributo de la relación "uno"
- Agregando atributos a una relación de otra relación con la cual será unida (JOIN)
Esquemas en estrella que también son conocidos como modelos hecho-dimensión y se han extendido a los esquemas de copo de nieve
Información de resumen preconstruida (útil para informes, data warehouse o data mining) o cubos OLAP