En la gestión y el almacenamiento de datos , una dimensión de cambio lento (SCD) es una dimensión que almacena datos que, si bien generalmente son estables, pueden cambiar con el tiempo, a menudo de manera impredecible. [1] Esto contrasta con una dimensión de cambio rápido , como los parámetros transaccionales como la identificación del cliente, la identificación del producto, la cantidad y el precio, que se actualizan con frecuencia. Algunos ejemplos comunes de SCD incluyen ubicaciones geográficas , detalles del cliente o atributos del producto .
Varias metodologías abordan las complejidades de la gestión de SCD. El kit de herramientas Kimball ha popularizado una categorización de técnicas para manejar atributos de SCD desde el Tipo 1 hasta el Tipo 6. [1] Estas van desde sobrescrituras simples (Tipo 1) hasta la creación de nuevas filas para cada cambio (Tipo 2), la adición de nuevos atributos (Tipo 3), el mantenimiento de tablas de historial separadas (Tipo 4) o el empleo de enfoques híbridos (Tipo 6 y 7). El Tipo 0 está disponible para modelar un atributo como si realmente no cambiara en absoluto. Cada tipo ofrece un equilibrio entre la precisión histórica, la complejidad de los datos y el rendimiento del sistema, atendiendo a diferentes necesidades analíticas y de generación de informes .
El desafío de los SCD radica en preservar la precisión histórica y, al mismo tiempo, mantener la integridad de los datos y la integridad referencial . Por ejemplo, una tabla de hechos que realiza un seguimiento de las ventas puede estar vinculada a una tabla de dimensiones que contiene información sobre los vendedores y sus oficinas regionales asignadas. Si un vendedor es transferido a una nueva oficina, los informes históricos de ventas deben reflejar su asignación anterior sin romper las relaciones entre las tablas de hechos y dimensiones. Los SCD proporcionan mecanismos para gestionar dichos cambios de manera eficaz.
Los atributos de dimensión de tipo 0 nunca cambian y se asignan a atributos que tienen valores duraderos o se describen como "originales". Ejemplos: Fecha de nacimiento , Puntaje crediticio original . El tipo 0 se aplica a la mayoría de los atributos de dimensión de fecha. [2]
Este método sobrescribe los datos antiguos con los nuevos y, por lo tanto, no realiza un seguimiento de los datos históricos.
Ejemplo de una tabla de proveedores:
En el ejemplo anterior, Supplier_Code es la clave natural y Supplier_Key es una clave sustituta . Técnicamente, la clave sustituta no es necesaria, ya que la fila será única por la clave natural (Supplier_Code).
Si el proveedor traslada su sede a Illinois, el registro se sobrescribirá:
La desventaja del método de tipo 1 es que no hay historial en el almacén de datos. Sin embargo, tiene la ventaja de que es fácil de mantener.
Si se ha calculado una tabla agregada que resume los hechos por estado del proveedor, será necesario volver a calcularla cuando se cambie el estado del proveedor. [1]
Este método rastrea datos históricos mediante la creación de múltiples registros para una clave natural determinada en las tablas dimensionales con claves sustitutas independientes o diferentes números de versión. Se conserva un historial ilimitado para cada inserción. La clave natural en estos ejemplos es el "Código de proveedor" de "ABC".
Por ejemplo, si el proveedor se muda a Illinois, los números de versión se incrementarán secuencialmente:
Otro método es agregar columnas de "fecha de vigencia".
La fecha/hora de inicio de la segunda fila es igual a la fecha/hora de finalización de la fila anterior. La fecha de finalización nula en la segunda fila indica la versión actual de la tupla. En su lugar, se puede utilizar una fecha alta sustituta estandarizada (por ejemplo, 9999-12-31) como fecha de finalización, de modo que el campo se pueda incluir en un índice y no se requiera la sustitución de valores nulos al realizar consultas. En algunos programas de bases de datos, el uso de un valor de fecha alta artificial podría causar problemas de rendimiento que se evitarían con el uso de un valor nulo.
Y un tercer método utiliza una fecha efectiva y una bandera actual.
El valor de Current_Flag de 'Y' indica la versión actual de la tupla.
Las transacciones que hacen referencia a una clave sustituta particular (Supplier_Key) quedan entonces vinculadas permanentemente a los intervalos de tiempo definidos por esa fila de la tabla de dimensión que cambia lentamente. Una tabla agregada que resume los hechos por estado del proveedor continúa reflejando el estado histórico, es decir, el estado en el que se encontraba el proveedor en el momento de la transacción; no se necesita ninguna actualización. Para hacer referencia a la entidad a través de la clave natural, es necesario eliminar la restricción única que hace imposible la integridad referencial por parte del DBMS (sistema de gestión de bases de datos).
Si se realizan cambios retroactivos en el contenido de la dimensión, o si se agregan nuevos atributos a la dimensión (por ejemplo, una columna Sales_Rep) que tienen fechas de vigencia diferentes a las ya definidas, esto puede dar como resultado que las transacciones existentes deban actualizarse para reflejar la nueva situación. Esta puede ser una operación de base de datos costosa, por lo que las SCD de tipo 2 no son una buena opción si el modelo dimensional está sujeto a cambios frecuentes. [1]
Este método realiza un seguimiento de los cambios mediante columnas independientes y conserva un historial limitado. El tipo 3 conserva un historial limitado, ya que está limitado a la cantidad de columnas designadas para almacenar datos históricos. La estructura de tabla original en el tipo 1 y el tipo 2 es la misma, pero el tipo 3 agrega columnas adicionales. En el siguiente ejemplo, se agregó una columna adicional a la tabla para registrar el estado original del proveedor; solo se almacena el historial anterior.
Este registro contiene una columna para el estado original y el estado actual; no se pueden rastrear los cambios si el proveedor se reubica una segunda vez.
Una variación de esto es crear el campo Previous_Supplier_State en lugar de Original_Supplier_State que rastrearía solo el cambio histórico más reciente. [1]
El método de tipo 4 suele denominarse "tablas de historial", en las que una tabla conserva los datos actuales y se utiliza una tabla adicional para mantener un registro de algunos o todos los cambios. Ambas claves sustitutas se referencian en la tabla de hechos para mejorar el rendimiento de la consulta.
Para el ejemplo siguiente, el nombre de la tabla original es Proveedor y la tabla de historial es Proveedor_Historial:
Este método se asemeja a cómo funcionan las tablas de auditoría de bases de datos y las técnicas de captura de datos modificados .
La técnica de tipo 5 se basa en la minidimensión de tipo 4 al incorporar una clave de minidimensión de “perfil actual” en la dimensión base que se sobrescribe como un atributo de tipo 1. Este enfoque se denomina tipo 5 porque 4 + 1 es igual a 5. La dimensión de cambio lento de tipo 5 permite acceder a los valores de atributo de minidimensión actualmente asignados junto con los demás de la dimensión base sin vincularlos a través de una tabla de hechos. Lógicamente, normalmente representamos la dimensión base y el perfil de minidimensión actual como una sola tabla en la capa de presentación. Los atributos del perfil deben tener nombres de columna distintos, como “Nivel de ingresos actual”, para diferenciarlos de los atributos en la minidimensión vinculada a la tabla de hechos. El equipo de ETL debe actualizar/sobrescribir la referencia de minidimensión de tipo 1 siempre que la minidimensión actual cambie con el tiempo. Si el enfoque del perfil no ofrece un rendimiento de consulta satisfactorio, los atributos de minidimensión se pueden incorporar físicamente (y actualizar) en la dimensión base. [3]
El método de tipo 6 combina los enfoques de los tipos 1, 2 y 3 (1 + 2 + 3 = 6). Una posible explicación del origen del término es que fue acuñado por Ralph Kimball durante una conversación con Stephen Pace de Kalido [ cita requerida ] . Ralph Kimball llama a este método "Cambios impredecibles con superposición de una sola versión" en The Data Warehouse Toolkit . [1]
La tabla Proveedor comienza con un registro para nuestro proveedor de ejemplo:
Current_State y Historical_State son iguales. El atributo opcional Current_Flag indica que este es el registro actual o más reciente de este proveedor.
Cuando Acme Supply Company se muda a Illinois, agregamos un nuevo registro, como en el procesamiento Tipo 2, sin embargo, se incluye una clave de fila para garantizar que tengamos una clave única para cada fila:
Sobrescribimos la información de Current_State en el primer registro (Row_Key = 1) con la nueva información, como en el procesamiento de Tipo 1. Creamos un nuevo registro para realizar un seguimiento de los cambios, como en el procesamiento de Tipo 2. Y almacenamos el historial en una segunda columna de Estado (Historical_State), que incorpora el procesamiento de Tipo 3.
Por ejemplo, si el proveedor se mudara nuevamente, agregaríamos otro registro a la dimensión Proveedor y sobrescribiríamos el contenido de la columna Current_State:
En muchas implementaciones de SCD de tipo 2 y tipo 6, la clave sustituta de la dimensión se coloca en la tabla de hechos en lugar de la clave natural cuando los datos de hechos se cargan en el repositorio de datos. [1] La clave sustituta se selecciona para un registro de hechos determinado en función de su fecha de vigencia y la fecha de inicio y la fecha de finalización de la tabla de dimensiones. Esto permite unir fácilmente los datos de hechos con los datos de dimensión correctos para la fecha de vigencia correspondiente.
Aquí está la tabla de proveedores tal como la creamos anteriormente utilizando la metodología híbrida tipo 6:
Una vez que la tabla de entrega contiene la clave de proveedor correcta, se puede unir fácilmente a la tabla de proveedores utilizando esa clave. La siguiente consulta SQL recupera, para cada registro de hechos, el estado actual del proveedor y el estado en el que se encontraba el proveedor en el momento de la entrega:
SELECCIONAR entrega . costo_entrega , proveedor . nombre_proveedor , proveedor . estado_histórico , proveedor . estado_actual DE entrega UNIRSE INTERNAMENTAL proveedor EN entrega . clave_proveedor = proveedor . clave_proveedor ; Tener una clave sustituta de tipo 2 para cada intervalo de tiempo puede causar problemas si la dimensión está sujeta a cambios. [1] Una implementación de tipo 6 pura no utiliza esto, sino que utiliza una clave sustituta para cada elemento de datos maestros (por ejemplo, cada proveedor único tiene una clave sustituta única). Esto evita que cualquier cambio en los datos maestros tenga un impacto en los datos de transacciones existentes. También permite más opciones al consultar las transacciones.
A continuación se muestra la tabla de proveedores utilizando la metodología pura Tipo 6:
El siguiente ejemplo muestra cómo se debe ampliar la consulta para garantizar que se recupere un único registro de proveedor para cada transacción.
SELECCIONAR proveedor . código_proveedor , proveedor . estado_proveedor DE proveedor UNIÓN INTERNA entrega EN proveedor . clave_proveedor = entrega . clave_proveedor Y entrega . fecha_entrega >= proveedor . fecha_inicio Y entrega . fecha_entrega < proveedor . fecha_fin ; Un registro de hechos con fecha de vigencia (Fecha_de_entrega) del 9 de agosto de 2001 se vinculará al Código_de_proveedor de ABC, con un Estado_de_proveedor de 'CA'. Un registro de hechos con fecha de vigencia del 11 de octubre de 2007 también se vinculará al mismo Código_de_proveedor de ABC, pero con un Estado_de_proveedor de 'IL'.
Si bien es más complejo, este enfoque tiene varias ventajas, entre ellas:
El siguiente ejemplo muestra cómo se puede utilizar una fecha específica como '2012-01-01T00:00:00' (que podría ser la fecha y hora actual).
SELECCIONAR proveedor . código_proveedor , proveedor . estado_proveedor DE proveedor UNIÓN INTERNA entrega EN proveedor . clave_proveedor = entrega . clave_proveedor Y proveedor . fecha_inicio <= '2012-01-01T00:00:00' Y proveedor . fecha_fin > '2012-01-01T00:00:00' ; Una implementación alternativa es colocar tanto la clave sustituta como la clave natural en la tabla de hechos. [5] Esto permite al usuario seleccionar los registros de dimensión apropiados en función de:
Este método permite vínculos más flexibles a la dimensión, incluso si se ha utilizado el enfoque Tipo 2 en lugar del Tipo 6.
Aquí está la tabla de proveedores tal como la habríamos creado utilizando la metodología Tipo 2:
Para obtener registros actuales:
SELECCIONAR entrega . costo_entrega , proveedor . nombre_proveedor , proveedor . estado_proveedor DE entrega UNIRSE INTERNAmente proveedor EN entrega . código_proveedor = proveedor . código_proveedor DONDE proveedor . indicador_actual = 'Y' ; Para obtener registros históricos:
SELECCIONAR entrega . costo_entrega , proveedor . nombre_proveedor , proveedor . estado_proveedor DE entrega UNIRSE INTERNAMENTAL proveedor EN entrega . código_proveedor = proveedor . código_proveedor ; Para obtener registros históricos basados en una fecha específica (si existe más de una fecha en la tabla de hechos):
SELECCIONAR entrega . costo_entrega , proveedor . nombre_proveedor , proveedor . estado_proveedor DE entrega UNIÓN INTERNA proveedor EN entrega . código_proveedor = proveedor . código_proveedor Y entrega . fecha_entrega ENTRE proveedor . Fecha_inicio Y proveedor . Fecha_final Algunas precauciones:
Se pueden aplicar distintos tipos de SCD a distintas columnas de una tabla. Por ejemplo, podemos aplicar el tipo 1 a la columna Supplier_Name y el tipo 2 a la columna Supplier_State de la misma tabla.