La desnormalización es una estrategia utilizada en una base de datos previamente normalizada para aumentar el rendimiento. En informática , la desnormalización es el proceso de intentar mejorar el rendimiento de lectura de una base de datos , a costa de perder algo de rendimiento de escritura, agregando copias redundantes de datos o agrupando datos. [1] [2] A menudo está motivada por el rendimiento o la escalabilidad en el software de base de datos relacional que necesita realizar una gran cantidad de operaciones de lectura. La desnormalización se diferencia de la forma no normalizada en que los beneficios de la desnormalización solo se pueden obtener por completo en un modelo de datos que de otro modo esté normalizado.
Un diseño normalizado a menudo "almacenará" piezas de información diferentes pero relacionadas en tablas lógicas separadas (llamadas relaciones). Si estas relaciones se almacenan físicamente como archivos de disco separados, completar una consulta de base de datos que extrae información de varias relaciones (una operación de unión ) puede ser lento. Si se unen muchas relaciones, puede ser prohibitivamente lento. Existen dos estrategias para lidiar con esto mediante la desnormalización:
Con este enfoque, los administradores de bases de datos pueden mantener el diseño lógico normalizado, pero permitir que el sistema de administración de bases de datos (DBMS) almacene información redundante adicional en el disco para optimizar la respuesta a las consultas. En este caso, es responsabilidad del software DBMS garantizar que las copias redundantes se mantengan consistentes. Este método se implementa a menudo en SQL como vistas indexadas ( Microsoft SQL Server ) o vistas materializadas ( Oracle , PostgreSQL ). Una vista puede, entre otros factores, representar información en un formato conveniente para la consulta, y el índice garantiza que las consultas contra la vista estén optimizadas físicamente.
Con este enfoque, un administrador o diseñador de base de datos tiene que desnormalizar el diseño lógico de los datos. Con cuidado, esto puede lograr una mejora similar en la respuesta a las consultas, pero con un costo: ahora es responsabilidad del diseñador de la base de datos asegurarse de que la base de datos desnormalizada no se vuelva inconsistente. Esto se hace creando reglas en la base de datos llamadas restricciones , que especifican cómo se deben mantener sincronizadas las copias redundantes de información, lo que puede hacer que el procedimiento de desnormalización sea fácilmente inútil. Es el aumento de la complejidad lógica del diseño de la base de datos y la complejidad añadida de las restricciones adicionales lo que hace que este enfoque sea peligroso. Además, las restricciones introducen una disyuntiva , acelerando las lecturas ( SELECT
en SQL) mientras que ralentizan las escrituras ( INSERT
, UPDATE
, y DELETE
). Esto significa que una base de datos desnormalizada bajo una carga de escritura pesada puede ofrecer un peor rendimiento que su contraparte normalizada funcionalmente equivalente.
Un modelo de datos desnormalizado no es lo mismo que un modelo de datos que no ha sido normalizado, y la desnormalización solo debe realizarse después de que se haya alcanzado un nivel satisfactorio de normalización y se hayan creado todas las restricciones y/o reglas necesarias para abordar las anomalías inherentes al diseño. Por ejemplo, todas las relaciones están en la tercera forma normal y todas las relaciones con dependencias de unión y dependencias multivaluadas se manejan adecuadamente.
Ejemplos de técnicas de desnormalización incluyen:
Con el continuo y espectacular aumento de los tres aspectos (el almacenamiento, la potencia de procesamiento y el ancho de banda) en todos los niveles, la desnormalización de las bases de datos ha pasado de ser una técnica inusual o de extensión a algo común o incluso la norma. [¿ Cuándo? ] Por ejemplo, una desventaja específica de la desnormalización era, simplemente, que "utiliza más almacenamiento" (es decir, literalmente más columnas en una base de datos). Con la excepción de sistemas verdaderamente enormes, en la década de 2020 el uso del almacenamiento se ha convertido en un problema relativamente menor.