Temporalidad DWH Parte 2: Reducir complejidad

Sobre la «Temporalidad» en el Data Vault

Eliminando la complejidad temporal

Como fabricante del software de automatización Datavault Builder, nos preguntan a menudo cómo mapear los cambios a lo largo del tiempo en nuestra herramienta y/o en el Data Vault en general. A menudo en la forma: ¿cómo puedo reportar SCD Type 2? Sin embargo, no siempre está claro de qué eje temporal estamos hablando. Por eso aquí un intento de aclararlo. Este es el segundo artículo de una serie de tres.

• El primer artículo definió el reto al que nos enfrentamos con la temporalidad en el DWH

• Este artículo define posibilidades para simplificar la complejidad temporal si es posible

• El tercer artículo discute requisitos de negocio para sacar las timelines

Hay distintos enfoques para la temporalidad en el data vault. Por eso recomiendo leer los textos de Dirk Lerner, Christian Kaul y Lars Rönnbäck. Aquí presento una variante de cómo representar o simplificar las distintas líneas de tiempo de forma que puedan controlarse. Como se definió en el primer artículo, solo discuto 3 líneas de tiempo y uso los siguientes atajos:

• 1d para Valid Time

• 2d para Inscription Time

• 3d para Load Time

La primera dimensión (1d) es la validez de negocio. Esta timeline es especial en el sentido de que una nueva franja de tiempo en la timeline no significa que la entrada antigua sea inválida: si vivo en Basilea en lugar de Zúrich, la información de que viví en Zúrich no es incorrecta.

Eje 1d: toda la información es válida pero solo una entrada es actual.

La segunda dimensión (2d) es el inscription time en el sistema fuente. Esto es relevante porque en el eje 1d también puede introducir nuevas entradas para el futuro y correcciones para la franja actual y/o pasada. En ciertas industrias y departamentos esto puede usarse para cometer fraude. Esta es también la razón de la primera simplificación: sugiero almacenar la timeline 2d en un satélite simplemente como atributo en un primer paso para que no se pierda información.

1.ª simplificación / estrategia: almacenar los tiempos 2d como atributo satélite normal

Esto significa que del espacio tridimensional solo consideramos un plano bidimensional.

La tercera dimensión (3d) es el momento en que la información se ha cargado en el data warehouse. El eje 3d es especial en que está bajo el control del equipo DWH. Y muchos de los que llevamos tiempo trabajando en este área sabemos que no nos fiamos de ningún sistema fuente :)

Eje 3d: una información reemplaza la otra implícitamente (sí, Petr es la ortografía correcta de mi nombre)

¿De qué hablamos / correcciones vs. historia real?

Si ahora asumimos que la carga al DWH está muy cerca de la captura en la fuente, simplemente almacenamos el tiempo 2d como atributo en el satélite y lo ignoramos en un primer paso. Así que cuando hablamos de SCD type 2: ¿es 1d o 3d? No siempre está claro y depende en parte de la industria. En el negocio asegurador, por ejemplo, es obligatorio mantener un historial 1d para muchos objetos en la fuente.

En algunas empresas esto es tan común que no se distingue entre 1d y 3d.

Historia real vs historia relevante

Pero incluso si hay un historial real: si es irrelevante para mi modelo de negocio cuál era el nombre pasado de una persona (a menos que venda tazas con su nombre): ¿por qué pondría esta información en un informe?

De hecho, en muchos casos tiene más sentido proporcionar una vista point-in-time (según las necesidades de negocio) en los informes, porque facilita el uso de los informes y reduce la probabilidad de evaluar algo erróneamente.

Cómo modelar el historial 1d en el DWH

Hay algunas diferencias básicas: ¿interpreto el tiempo antes de cargarlo en el Data Vault, o cargo primero todo lo que viene de la fuente en el Raw Vault, incluso si recibimos franjas de tiempo solapadas? Hemos elegido el segundo enfoque.

2.ª «simplificación» / estrategia: crear un temporal instance hub concatenando la business key con el business valid from time

Esto significa que recibimos varias entradas válidas para una business key, como un número de contrato, incluso si no son actuales. La solución es o bien usar un Multi-Active Satellite o cambiar la granularidad del hub. A esto lo llamo temporal instance hub.

Ejemplo: En seguros tengo una póliza con una cobertura definida. Sin embargo, esta cobertura puede ajustarse a lo largo del tiempo. Importante: esto normalmente no es una corrección, sino que establece una nueva instancia de la póliza.

Si ahora hay una corrección porque en enero 2019 alguien descubre que la cobertura se introdujo incorrectamente, el temporal instance hub tiene una clara ventaja aquí: si solo se cambia una franja de tiempo, se actualizará correctamente en la timeline 3d con un patrón de carga estándar.

Por estas razones soportamos el enfoque del temporal instance hub en nuestra herramienta.

¿Y qué pasa con atributos dimensionales relevantes: instanciación?

Aunque he descrito arriba que ciertos cambios de atributos no son relevantes para muchas evaluaciones, hay sin duda cambios que son centrales.

Un ejemplo es uno de nuestros clientes que tiene la posibilidad de producir o comprar determinados productos antes de venderlos a sus clientes. Para fines de aseguramiento de calidad es significativo si el producto fue vendido y entregado por el cliente o por una empresa externa.

Así que tenemos el caso en el que un eje temporal 3d se usa como aproximación para la vista 1d. En el modelado Data Vault hay una manera muy sencilla de hacerlo: podemos transferir este atributo desde el hub producto al hub línea de pedido de venta. Esto se hace montando un Business Vault Load en el momento en que la transacción se carga en el Raw Vault, que hace un lookup as-of-now sobre el atributo del producto y luego lo almacena en un satélite Business Vault sobre la transacción. A este procedimiento lo llamo instanciación de un atributo en otro grano.

3.ª simplificación / estrategia: instanciar atributos en un determinado momento en las transacciones

Si ahora sacamos la orden de venta, podemos también sacar el atributo Business Vault en este grano de la transacción. Cada usuario entiende que ese atributo es algo en el momento de la transacción.

Resumen breve

Con estas tres simplificaciones / estrategias,

• almacenar 2d solo como atributo en el satélite

• inclusión del tiempo 1d en la clave del hub

• instanciación de atributos en la transacción

afirmo que podemos cubrir la mayoría de los requisitos para una salida historizada en la mayoría de las industrias. En un tercer artículo discutiré los casos en los que esto no es suficiente y cuáles son las soluciones técnicas para tales requisitos.