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, añadiendo copias redundantes de datos o agrupando datos. [1] [2] A menudo está motivado por el rendimiento o la escalabilidad del software de bases de datos relacionales que necesitan realizar un gran número de operaciones de lectura. La desnormalización se diferencia de la forma no normalizada en que los beneficios de la desnormalización solo pueden lograrse plenamente 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 resultar lento. Si se unen muchas relaciones, puede ser prohibitivamente lento. Hay dos estrategias para lidiar con esto.
Un método es 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 coherentes. Este método a menudo se implementa 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 realizar consultas, y el índice garantiza que las consultas en la vista se optimicen físicamente.
Otro enfoque consiste en desnormalizar el diseño de datos lógicos. Con cuidado, esto puede lograr una mejora similar en la respuesta a las consultas, pero a un costo: ahora es responsabilidad del diseñador de la base de datos garantizar 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 fácilmente puede hacer que el procedimiento de desnormalización sea 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 compensación : aceleran las lecturas ( SELECTen SQL) y ralentizan las escrituras ( INSERT, UPDATEy DELETE). Esto significa que una base de datos desnormalizada con una gran carga de escritura 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 sólo debe tener lugar después de que se haya alcanzado un nivel satisfactorio de normalización y de que se hayan creado las restricciones y/o reglas necesarias para abordar las necesidades inherentes. anomalías en el diseño. Por ejemplo, todas las relaciones están en tercera forma normal y cualquier relación con dependencias de unión y de valores múltiples se maneja adecuadamente.
Ejemplos de técnicas de desnormalización incluyen:
Con el continuo y dramático aumento en los tres: almacenamiento, potencia de procesamiento y ancho de banda, en todos los niveles, la desnormalización en las bases de datos ha pasado de ser una técnica inusual o de extensión a algo común, o incluso la norma. Por ejemplo, una desventaja específica de la desnormalización fue, simplemente, que "utiliza más almacenamiento" (es decir, literalmente más columnas en una base de datos). Con la excepción de sistemas realmente enormes, este aspecto particular se ha vuelto irrelevante y usar más almacenamiento no es un problema.