Temporalidad DWH Parte 1: El reto

En los últimos años me he enfrentado a la demanda de crear un reporting con dimensiones SCD type 2. Pero como normalmente hay 3 o más líneas de tiempo en el data warehouse, he tenido que aclarar una y otra vez cuál es realmente el requisito de negocio. Aquí intento ordenar mis pensamientos y darle una guía para tales discusiones.

El artículo está dividido en tres partes: - Definición de las distintas timelines - Creación de informes fáciles de usar reduciendo las timelines incluidas en la salida DWH - Qué casos de uso hacen necesario sacar las distintas timelines

En un mundo simple solo está el aquí y ahora: el presente. Si quiero registrar el desarrollo en el tiempo necesito una timeline.

¿Qué es una dimensión temporal (timeline)? ¿Qué es una franja de tiempo? ¿Qué es SCD Type 2? ¿Cuál es la relación con as-is, as-was, as-of?

En un mundo simple solo está el aquí y ahora. Por tanto, el presente. Si quiero registrar el desarrollo en el tiempo necesito una timeline.

Puedo transformar una timeline en un punto en el tiempo si la corto en cualquier lugar.

Pero si ahora voy y corrijo mi timeline, puedo introducir los momentos de cambio nuevamente en una timeline separada.

Si ahora registro estas dos barras de tiempo en un ángulo de 90 grados entre sí, obtengo una superficie temporal.

Puedo reducir esta superficie temporal en cualquier momento a una barra de tiempo si corto mi superficie temporal en cualquier punto paralelamente a una u otra barra.

Así que puedo reducir una superficie temporal a una timeline y esta a su vez a un punto en el tiempo.

Estos cortes se llaman vistas as-of. Hay un corte especial, el del momento actualmente válido (que no siempre es el final de una timeline): as-is. Y otro corte especial que representa la combinación de información en el momento de un evento: as-was.

En este ejemplo simplificado puedo elegir la validez de negocio como timeline y cuándo se registró esta información en un sistema IT como segunda timeline. Así tenemos una superficie temporal.

En el data warehousing, sin embargo, se añade una tercera barra de tiempo en cada caso: cuándo se enteró el data warehouse de información nueva o modificada. Si ahora dibuja esta tercera timeline perpendicular al área temporal existente, obtiene un cubo. Esa es la razón por la que me gusta hablar de dimensiones temporales.

Para evitar los distintos problemas con las distintas terminologías, me gusta el enfoque según el cual las distintas timelines, si pueden entenderse como dimensiones dispuestas en un cubo, se direccionan con números de dimensión.

• 1d: cuándo una entrada era válida desde una perspectiva de negocio. Según Snodgrass citado por Kaul «capturar la historia de una realidad cambiante»: Valid Time.

• 2d: Capture Time / System Time / Logged Time / Inscription Time / Aproximación a Assertion Time en el sistema IT origen.

• 3d: Acquisition Time / System Time / Logged Time / Load Time / Inscription Time / Aproximación a Assertion Time en el sistema DWH.

Franja de tiempo

Una franja de tiempo es una sección en una timeline en la que los atributos para un objeto específico e identificable no cambian. Una franja puede describirse explícitamente con una fecha de inicio y fin, o implícitamente puede considerarse terminada por definición tan pronto como empieza una nueva.

Con las timelines 2d y 3d, por otro lado, se asume que el momento de una nueva entrada significa automáticamente el fin de la anterior.

Mis favoritos personales: 1d: Valid Time 2d: Inscription Time 3d: Load Time

El punto es que no necesitamos ponernos de acuerdo en los nombres, en cuanto todo el mundo sepa qué significa qué timeline.

¿Qué significa SCD Type 2?

SCD type 2 es un procedimiento para documentar una nueva timeline a partir de información recibida en distintos momentos.

Normalmente el término se usa como sinónimo de la creación de la timeline 3d en el data warehouse. El momento de carga en el DWH suele usarse para iniciar una nueva franja. Implícitamente el momento de carga del siguiente conjunto de datos para la misma clave se usa para terminar el periodo de assertion de la entrada anterior.

El problema es que hay implementaciones de data warehouse y también modeladores que no se preguntan: ¿qué timeline representamos realmente aquí? ¿Es esta timeline siquiera adecuada para cumplir los requisitos de nuestro reporting? ¿Necesitamos siquiera esta timeline para nuestras evaluaciones? ¿Los cambios registrados son solo correcciones o estamos realmente registrando cambios en el mundo real?

Desde mi punto de vista personal, esta falta de análisis de los requisitos de negocio lleva a implementaciones poco pensadas en las que todas las dimensiones se sacan en forma SCD Type 2 en todos los informes.

En el resto de esta serie intentaré explicar que en ciertos casos esto no solo es superfluo sino que también puede ser incorrecto en algunos casos. Al mismo tiempo, me gustaría ofrecer soluciones alternativas sobre cómo manejar el tiempo en el Data Vault (y el Data Warehouse) en general.