Las cargas de datos (ETL, de Extract-Tranformation-Load en inglés), permiten mover datos de un sistema informático a otro. Durante este proceso, es habitual realizar modificaciones tanto en los datos (limpieza, estandarización de formatos, etc.) como en el modelo de datos (paso de un modelo transaccional a uno dimensional).
El diseño e implementación de una ETL es una tarea compleja. Existen una gran cantidad de situaciones a tener en cuenta para que ésta sea robusta y eficiente, y proporcione el resultado deseado.
Una de estas situaciones a tener en cuenta es la de la que se produce al cargar datos en un Data Warehouse, cuando una dimensión no está disponible en el momento de procesar un registro de una tabla de hechos. Es lo que se conoce en inglés como Late Arriving Dimension.
Late Arriving Dimension
La ejecución de una ETL, a grandes rasgos, procesa inicialmente las dimensiones para finalizar con las tablas de hechos. De esta manera, al procesar éstos, disponemos de los registros de las dimensiones referenciados en éstos.
Hasta aquí, perfecto. Sin embargo, ¿qué sucede cuando un escenario no es perfecto?
Una ETL simple obtiene todos los datos de un mismo origen. En este caso, es lógico pensar que dimensiones y hechos pueden ser tratados como una única unidad de información atómica. Por tanto, o bien todos los datos se obtendrán en la fase de extracción, o ninguno de ellos. En este último caso, al producirse un error en la extracción de datos, no tendremos ni dimensiones ni hechos. Y ese caso se solucionará restaurando el acceso al sistema origen de los datos.
Sin embargo, en una ETL que obtenga datos de diferentes orígenes, puede darse la situación en que la extracción de uno de ellos no sea posible, mientras que no haya ningún problema con los otros. En este caso, si no hemos podido obtener una dimensión, es posible que los registros de hechos hagan referencia a registros de dimensión que no hayan sido procesados en el sistema. Por tanto, ese registro de hechos no podrá enlazar a la información correcta.
Diseño complejo
Ante una situación así, debemos plantearnos diferentes soluciones en función del escenario.
La primera cuestión a plantearse es: ¿Es necesario disponer de toda la información para poder cargar los datos?
Si éste es el caso, la ETL debería finalizar con error. El siguiente paso sería solucionar el acceso a los datos. Y finalizaríamos ejecutando la ETL nuevamente para así poder cargar todos los datos en el sistema destino.
En caso contrario, procederíamos a cargar el registro de la tabla de hechos, referenciando un registro de dimensión donde únicamente las claves primaria y natural estuviesen informadas con información real (el resto serían valores por defecto). En el futuro, al cargar el registro de dimensión, modificaríamos ese registro inicial.
Pero habría que tener en cuenta también si esa dimensión requiere cambios en el tiempo (Slowly Changing Dimension Type 2, según la metodología Kimball). En ese caso, el proceso de inserción de una nueva versión de la dimensión no debería producirse inicialmente, ya que esta situación dejaría los registros de hechos referenciando a una versión incompleta de la dimensión.
Otra situación especial ocurre cuando no existe un único origen de datos para la confección de una dimensión. Es decir, a pesar de disponer de un maestro para una dimensión, ésta es enriquecida con datos provenientes de otros sistemas origen. La situación es similar a la anteriormente citada con los registros de hechos, pero no es exactamente la misma.
Conclusión
Una ETL debe ser robusta y tiene que proporcionar información correcta y consistente.
En un mundo ideal, todo funcionará siempre a la perfección. Sin embargo, eso es una utopía. La realidad es que a lo largo del tiempo sucederán situaciones de riesgo que una ETL debe tener controladas.
La mitigación de estas situaciones de riesgo es responsabilidad del arquitecto de la ETL. Un buen diseño debe ser capaz de sobreponerse a situaciones no habituales (que no inesperadas), alineando el comportamiento de la ETL a los requerimientos de ésta.
El caso de las Late Arriving Dimensions es uno de estos riesgos a controlar en una ETL. De ello depende que los usuarios puedan disponer o no de información para tomar sus decisiones en el día a día.
