Temporalidad DWH Parte 3: Sacar las timelines

Aunque en muchos casos no es necesario sacar las timelines en los informes, hay casos en los que sacar las timelines es importante. Ejemplos:

• Mostrar el historial de un cliente (1d)

• Resaltar datos modificados posteriormente para identificar fraudes y correcciones legítimas (2d)

• Comparación flexible de distintos periodos para entender cambios relativos (3d)

Si todavía no ha oído hablar de 1d (Validez de negocio), 2d (Inscription Time) y 3d (Load Time), podría considerar leer la primera parte de esta serie.

Sacar la timeline 1d: Ejemplo de historial de cliente

Puede que quiera profundizar en un caso individual en informes que muestran valores agregados. Para entender el caso individual, podríamos querer entender el historial de un cliente: cuándo vivió en qué región y cuándo cambió qué suscripciones. Un ejemplo: vemos que clientes existentes cancelan su conexión DSL pero más tarde piden conexión por fibra óptica. Para entender qué ocurrió podría ser útil tomar algunas muestras y analizarlas. Esto es un historial 1d: la validez de negocio.

Como aprendimos en la parte 2, puede almacenar esto en un Temporal Instance Hub añadiendo el Valid From Date a la business key. Como el grano del hub y los datos a sacar ahora coinciden, no necesito hacer modificaciones a la salida. Lo único que tengo que tener en cuenta es que un desplazamiento de una franja de tiempo en el eje 1d en la fuente (cambio del valid from time) es reconocido por el DWH como una franja eliminada y una nueva, ya que el valid from time es parte de nuestra clave. Esto significa que tenemos que marcar o filtrar la versión que ya no es válida de una franja de tiempo.

Logramos esto recordando en un tracking satellite si una clave sigue presente en la fuente o no. Importante: esto solo funciona con cargas completas. Esto es independiente de la herramienta Datavault Builder e incluso independiente de Data Vault. Si no recibo un mensaje de borrado explícito de la fuente, solo puedo detectar implícitamente las líneas borradas mediante una carga completa. Sin embargo, esta carga completa solo debe contener todas las partes de la business key y no todos los atributos. Por tanto es posible cargar los atributos en delta y solo cargar la clave y el valid from time completamente para reconocer tales «borrados».

Timeline 2d: Detectar fraude

Hace unos años me pidieron seguir algunas irregularidades en las comisiones de venta de un cliente. Había distintas reglas para cuándo un vendedor tenía derecho a una comisión de venta. El primer día de cada mes miraban cuántos contratos nuevos había firmado un vendedor. Algunos vendedores usaron esto para registrar contratos el último día de un mes y cancelarlos retroactivamente al día siguiente del cálculo de la comisión.

Caso 1: 2d time almacenado en la fuente, pero sin historial

¿Cómo trato estos datos? Si el sistema fuente registra el Inscription Time pero no mantiene un historial de cada cambio, tengo que crear el conocimiento del historial 2d usando el historial 3d en el DWH. Recomendamos almacenar simplemente los tiempos 2d como atributos satélite. Esto significa que en el momento en que almacena los datos, no necesita entender todas las reglas de negocio sobre cómo sacarlos.

La diferencia es que no solo puedo acceder a los últimos datos en el historial 3d (as-now), sino que tengo que evaluar la timeline en la timeline 3d para reconstruir la timeline 2d.

En la siguiente salida ya hemos implementado la primera regla de que el valor se vuelve negativo para el evento «Lost». Pero ya podemos ver aquí que S. Shady fue listo. Cambió el agente de ventas para que el evento de cancelación no se le imputara.

Así que introducimos una nueva regla que toma el Sales Agent del último evento «Completed»:

Y entonces las ventas de S. Shady en febrero se reducirán por el contrato perdido. Pero eso a su vez solo funciona para comisiones lineales. Si no, hay que derivar el periodo para el que se aplica la corrección.

El requisito de sacar simplemente los datos en forma SCD type 2 como están almacenados en el satélite en el eje 3d no ayuda a nadie. Solo interpretando los eventos en los distintos ejes de tiempo se crea conocimiento útil.

Caso 2: 2d time almacenado con historial en la fuente, sin historial 1d

Si ya recibimos historial 2d de la fuente, nuestros datos origen son una tabla pre-historizada. Si la fuente contiene historial 2d pero no historial 1d, entonces se puede asumir que el historial 2d puede equipararse al historial 1d, ya que probablemente sea la mejor aproximación.

Caso 3: 2d time almacenado con historial en la fuente, combinado con historial 1d

Si ya tenemos una fuente de datos bi-temporal con historial 1d y 2d, probablemente estamos con una aseguradora. Para nuestros amigos del sofisticado sector asegurador: hay dos formas de cargar tales datos origen en el Data Vault.

• Combinar la business key con el 1d Valid From timestamp y añadir adicionalmente el 2d timestamp

• Tomar la clave técnica de la fuente y almacenarla como Persistent Staging Load (PSA Load)

Sacar la timeline 3d: Reproducir y comparar niveles de conocimiento

Un caso citado con frecuencia para sacar el eje 3d es la reproducibilidad de los informes. Esto es un requisito muy importante, p. ej. si los informes creados por razones legales deben ser reproducibles en cualquier momento. Sea para Sarbanes-Oxley, Basilea I, II o III u otros reportings. Este requisito es absolutamente real pero a veces puede resolverse en algunas bases de datos con remedios caseros. Oracle ofrece el Flashback Archive para tales consultas en un determinado momento. Snowflake ofrece una funcionalidad similar con Time Travel.

Comparar niveles de conocimiento

Pero ¿quiero darle a un informe la posibilidad de invocar el estado de conocimiento de cada día y comparar 2 o más estados de conocimiento?

Si entiende el requisito del usuario de negocio y comparte su punto de vista, entonces tiene que crear una salida SCD type 2 para la timeline 3d. Describo la implementación técnica en la cuarta parte de esta serie.

Epílogo

Mi opinión personal: En el próximo artículo trataré por fin cómo crear técnicamente una salida SCD Type 2 para la timeline 3d. Lo importante para mí en todo el contexto hasta este punto es mostrar que en la mayoría de las empresas esto debería ser la excepción más que la regla, si es que existe alguna necesidad. Si usa un SCD Type 2 para la timeline 3d como estándar, probablemente lo hace porque puede y porque nadie ha recogido y/o analizado adecuadamente las necesidades de los usuarios de negocio.