¿Cuándo deberías desnormalizar?

Creo que todos estamos familiarizados con la normalización de la base de datos .

Mi pregunta es: ¿Cuáles son algunas pautas que utiliza cuando desea desnormalizar las tablas?

Desormalizar cuando se trata de operaciones OLAP, normalizar cuando OLTP (del artículo vinculado en la sección Desormalización)

Las bases de datos destinadas al procesamiento de transacciones en línea (OLTP) suelen estar más normalizadas que las bases de datos destinadas al procesamiento analítico en línea (OLAP). Las aplicaciones OLTP se caracterizan por un alto volumen de pequeñas transacciones, como la actualización de un registro de ventas en el mostrador de un supermercado. La expectativa es que cada transacción dejará la base de datos en un estado consistente. Por el contrario, las bases de datos destinadas a operaciones OLAP son principalmente bases de datos de "lectura mayoritaria". Las aplicaciones OLAP tienden a extraer datos históricos que se han acumulado durante un largo período de tiempo. Para tales bases de datos, los datos redundantes o "desnormalizados" pueden facilitar las aplicaciones de inteligencia empresarial. Específicamente, las tablas dimensionales en un esquema en estrella a menudo contienen datos desnormalizados. Los datos desnormalizados o redundantes deben controlarse cuidadosamente durante el procesamiento de extracción, transformación, carga (ETL), y no se debe permitir a los usuarios ver los datos hasta que estén en un estado coherente. La alternativa normalizada al esquema de estrella es el esquema de copo de nieve. En muchos casos, la necesidad de desnormalización ha disminuido a medida que las computadoras y el software RDBMS se han vuelto más poderosos, pero dado que los volúmenes de datos generalmente han aumentado junto con el rendimiento del hardware y software, las bases de datos OLAP a menudo todavía usan esquemas desnormalizados.

La desnormalización también se usa para mejorar el rendimiento en computadoras más pequeñas como en cajas registradoras computarizadas y dispositivos móviles, ya que estos pueden usar los datos solo para búsqueda (por ejemplo, búsquedas de precios). La desnormalización también se puede utilizar cuando no existe un RDBMS para una plataforma (como Palm), o no se deben realizar cambios en los datos y una respuesta rápida es crucial.

Normalizar hasta que duela, desnormalizar hasta que funcione (es decir, el rendimiento se vuelve aceptable) :)

Una razón potencialmente sensata para aplicar la desnormalización controlada es si le permite aplicar alguna restricción de integridad a los datos que de otro modo no sería posible. La mayoría de los DBMS de SQL tienen un soporte extremadamente limitado para las restricciones de varias tablas. En SQL, a veces, la única forma efectiva de implementar ciertas restricciones es asegurarse de que todos los atributos involucrados en la restricción estén presentes en la misma tabla, incluso cuando la normalización dicte que pertenecen a tablas separadas.

La desnormalización controlada significa que se implementan mecanismos para garantizar que no puedan surgir inconsistencias debido a datos redundantes. El costo de estos controles adicionales y el riesgo de datos inconsistentes deben considerarse al decidir si vale la pena la desnormalización.

Otra razón común para la desnormalización es permitir algún cambio en las estructuras de almacenamiento o permitir alguna otra optimización física que el DBMS de otra manera no permitiría. De acuerdo con el principio de Independencia de datos físicos, un DBMS debe tener los medios para configurar estructuras de almacenamiento interno sin alterar innecesariamente la representación lógica de los datos en la base de datos. Desafortunadamente, muchos DBMS son muy restrictivos de las opciones de implementación física disponibles para cualquier esquema de base de datos. Tienden a comprometer la independencia de la base de datos física al admitir solo una implementación subóptima del modelo lógico deseado.

Debería ser obvio, pero aún debe decirse: en todos los casos, solo los cambios en las características de implementación física pueden dictar el rendimiento, características como estructuras de datos internas, archivos, indexación, hardware, etc. La normalización y la desnormalización no tienen nada que ver con el rendimiento o la optimización del almacenamiento.

Desnormalice si está accediendo frecuentemente a datos calculados, como se sugiere en las respuestas a esta pregunta . El costo de almacenar y mantener los datos calculados a menudo será menor que el costo de volver a calcularlos una y otra vez si su perfil de carga es pesado.

Rutinariamente desnormalizo para poder hacer cumplir la integridad de los datos con restricciones. Un ejemplo es una pregunta reciente en este sitio : reproduzco una columna en otra tabla para poder usar una restricción CHECK para compararla con otra columna. Otro ejemplo de esta técnica es mi publicación de blog .

No puede usar las restricciones CHECK para comparar columnas en diferentes filas o en diferentes tablas, a menos que ajuste dicha funcionalidad en UDF escalares invocados a partir de una restricción CHECK. ¿Qué sucede si realmente necesita comparar columnas en diferentes filas o en diferentes tablas para hacer cumplir una regla empresarial? Por ejemplo, suponga que conoce las horas de trabajo de un médico y desea asegurarse de que todas las citas se ajusten dentro de las horas de trabajo. Por supuesto, puede usar un disparador o un procedimiento almacenado para implementar esta regla empresarial, pero ni un disparador ni un procedimiento almacenado pueden brindarle una garantía del 100% de que todos sus datos estén limpios: alguien puede deshabilitar o soltar su disparador, ingrese algunos datos sucios, y vuelva a habilitar o recrear su disparador. Además, alguien puede modificar directamente su tabla sin pasar por los procedimientos almacenados.

Permítanme demostrar cómo implementar esta regla de negocios usando solo restricciones FK y CHECK, eso garantizará que todos los datos satisfagan la regla de negocios siempre y cuando todas las restricciones sean confiables.

Sin embargo, otro ejemplo es una forma de hacer cumplir que los períodos de tiempo no tengan brechas ni superposiciones .