Navegando por dimensiones que cambian lentamente (SCD) y reformulación de datos: una guía completa |  de Kirsten Jiayi Pan |  febrero de 2024

Estrategias para gestionar eficientemente los cambios de dimensiones y la reformulación de datos en el almacenamiento de datos empresariales

Imagínese esto: usted es un ingeniero de datos que trabaja para una gran empresa minorista que utiliza la técnica de carga incremental en el almacenamiento de datos. Esta técnica implica actualizar o cargar selectivamente solo los datos nuevos o modificados desde la última actualización. ¿Qué podría ocurrir cuando el departamento de I+D de un producto decide cambiar el nombre o la descripción de un producto actual? ¿Cómo afectarían dichas actualizaciones a su canal de datos y almacén de datos existentes? ¿Cómo planea abordar desafíos como estos? Este artículo proporciona una guía completa con soluciones que utilizan dimensiones que cambian lentamente (SCD) para abordar posibles problemas durante la reformulación de datos.

Imagen recuperada de: https://unsplash.com/photos/macbook-pro-with-images-of-computer-language-codes-fPkvU7RDmCo

¿Qué son las dimensiones que cambian lentamente (SCD)?

Las dimensiones que cambian lentamente se refieren a cambios poco frecuentes en los valores de las dimensiones, que ocurren esporádicamente y no están vinculados a un cronograma diario o regular, ya que las dimensiones generalmente cambian con menos frecuencia que las entradas de transacciones en un sistema. Por ejemplo, una empresa de joyería cuyos clientes realizan un nuevo pedido en su sitio web se convertirá en una nueva fila en la tabla de datos de pedidos. Por otro lado, la empresa de joyería rara vez cambia el nombre y la descripción de su producto, pero eso no significa que nunca sucederá en el futuro.

La gestión de cambios en estas dimensiones requiere el empleo de técnicas de gestión de Dimensiones de Cambio Lento (SCD), que se clasifican en tipos de SCD definidos, que van desde el Tipo 0 hasta el Tipo 6, incluidos algunos tipos combinados o híbridos. Podemos emplear uno de los siguientes métodos:

SCD tipo 0: ignorar

Los cambios en los valores de las dimensiones se ignoran por completo y los valores de las dimensiones permanecen sin cambios desde el momento en que se crearon inicialmente en el almacén de datos.

SCD Tipo 1: Sobrescribir/Reemplazar

Este enfoque es aplicable cuando el valor anterior del atributo de dimensión ya no es relevante o importante. Sin embargo, no es necesario el seguimiento histórico de los cambios.

SCD tipo 2: crear una nueva fila de dimensión

Este enfoque se recomienda como técnica principal para abordar los cambios en los valores de las dimensiones, lo que implica la creación de una segunda fila para la dimensión con una fecha de inicio, una fecha de finalización y potencialmente un indicador “actual/vencido”. Es adecuado para nuestros escenarios, como descripción de producto o cambios de dirección, asegurando una partición clara del historial. La nueva fila de dimensión está vinculada a las filas de hechos recién insertadas, con cada registro de dimensión vinculado a un subconjunto de filas de hechos según los tiempos de inserción: los anteriores al cambio vinculados a la fila de dimensiones anterior y los posteriores vinculados a la nueva fila de dimensiones.

Figura 1 (Imagen del autor): PRODUCT_KEY = “cd3004” es la reformulación de PRODUCT_KEY = “cd3002”

SCD tipo 3: crear una columna “PREV”

Este método es adecuado cuando tanto los valores antiguos como los nuevos son relevantes y los usuarios pueden querer realizar un análisis histórico utilizando cualquiera de los valores. Sin embargo, no es práctico aplicar esta técnica a todos los atributos de dimensión, ya que implicaría proporcionar dos columnas para cada atributo en las tablas de dimensiones o más si es necesario conservar varios valores “PREV”. Debe utilizarse selectivamente cuando corresponda.

Figura 2 (Imagen del autor): PRODUCT_KEY = “cd3002” se actualiza con el nuevo PRODUCT_NAME, el antiguo PRODUCT_NAME se almacena en la columna NAME_PREV

SCD tipo 4: grandes dimensiones que cambian rápidamente

¿Qué sucede si en un escenario necesita capturar cada cambio en cada atributo de dimensión para una dimensión muy grande del comercio minorista, digamos más de un millón de clientes de su gran empresa de joyería? El uso del tipo 2 anterior aumentará muy rápidamente el número de filas en la tabla de dimensiones del cliente a decenas o incluso cientos de millones de filas y el uso del tipo 3 no es viable.

Una solución más eficaz para tablas de dimensiones de gran volumen y que cambian rápidamente es categorizar atributos (p.ej, categoría de edad del cliente, sexo, poder adquisitivo, fecha de nacimiento, etc.) y separarlos en una dimensión secundaria, como una dimensión de perfil de cliente. Esta tabla, que actúa como una tabla de dimensiones de “cobertura total”, todos los valores potenciales para cada categoría de atributos de dimensión están precargados en la tabla, lo que puede gestionar mejor la granularidad de los cambios y al mismo tiempo evitar una expansión excesiva de filas en la dimensión principal del cliente.

Por ejemplo, si tenemos 8 categorías de edad, 3 géneros diferentes, 6 categorías de poder adquisitivo y 366 cumpleaños posibles. Nuestra tabla de dimensiones de “cobertura total” para perfiles de clientes que contiene todas las combinaciones anteriores será 8 x 3 x 6 x 366 combinaciones o 52704 filas.

Necesitaremos generar surrogate_key para esta tabla de dimensiones y establezca una conexión con una nueva clave externa en la tabla de hechos. Cuando se produce una modificación en una de estas categorías de dimensiones, no es necesario agregar otra fila a la dimensión del cliente. En su lugar, generamos una nueva fila de hechos y la asociamos tanto con la dimensión del cliente como con la dimensión del nuevo perfil del cliente.

Figura 3 (Imagen del autor): Diagrama de entidad-relación para una tabla de “Dimensión de cobertura total”

SCD tipo 5: una extensión del tipo 4

Para mejorar el enfoque Tipo 4 mencionado anteriormente, podemos establecer una conexión entre la dimensión del cliente y la dimensión del perfil del cliente. Este vínculo permite el seguimiento del perfil de cliente “actual” de un cliente específico. La clave facilita la conexión del cliente con el perfil de cliente más reciente, lo que permite un recorrido fluido desde la dimensión del cliente hasta la dimensión del perfil del cliente más reciente sin la necesidad de vincularse a través de la tabla de hechos.

Figura 4 (Imagen del autor): El diagrama de relación de entidad muestra el vínculo entre customer_dim y cust_profile_dimension

SCD tipo 6: una técnica híbrida

Con este enfoque, integra tanto el Tipo 2 (nueva fila) como el Tipo 3 (columna “PREV”). Este enfoque combinado ofrece las ventajas de ambas metodologías. Puede recuperar datos utilizando la columna “ANTERIOR”, que proporciona valores históricos y presenta hechos asociados con la categoría de producto en ese momento específico. Al mismo tiempo, la consulta mediante la columna “nuevo” proporciona todos los datos tanto para el valor actual como para todos los valores anteriores de la categoría de producto.

Figura 5 (Imagen del autor): PRODUCT_ID = “cd3004” es la reformulación de PRODUCT_ID = “cd3002”, que PRODUCT_ID = “cd3001” está marcado como “EXPIRED” en la columna LAST_ACTION

Bonificación y conclusión

Normalmente, la extracción de datos se realiza en el esquema STAR, que incluye una tabla de hechos y varias tablas de dimensiones en una empresa. Mientras que las tablas de dimensiones almacenan todos los datos descriptivos y las claves primarias, la tabla de hechos contiene datos numéricos y aditivos que hacen referencia a las claves primarias de cada dimensión a su alrededor.

Figura 6 (Imagen del autor): Ilustración del esquema de estrella

Sin embargo, si su extracto de datos de ventas de marketing se proporciona como una única tabla desnormalizada sin tablas de dimensiones distintas y carece de la clave principal para sus datos descriptivos, las futuras actualizaciones de los nombres de los productos pueden plantear desafíos. Manejar estos escenarios en su canal existente puede ser más complicado.

La ausencia de claves primarias en los datos descriptivos puede generar problemas durante la reformulación de los datos, especialmente cuando se trata de conjuntos de datos grandes. Por ejemplo, si el nombre de un producto se actualiza en el extracto de reformulación sin un nombre único product_key, la canalización de carga incremental puede tratarlo como un producto nuevo, lo que afecta los datos históricos en su capa de consumo. Para abordar esto, creando surrogate_key para la dimensión del producto y una tabla de mapeo para vincular los nombres de productos originales y reformulados es necesaria para mantener la integridad de los datos.

En conclusión, todos los aspectos del diseño del almacén de datos deben considerarse cuidadosamente, teniendo en cuenta los posibles casos extremos.