En continuación a nuestro post
anterior:
Errores comunes
en modelado dimensional para BI/DWH: dimension de encabezado o maestro en
estructura maestro/detalle(header/line) PT 1
En este post trataremos otro patrón a evitar al modelar una relación
maestro/detalle (encabezado/detalle o header/line) en un modelo ROLAP. Como bien se mencionó en el post anterior,
muchas veces los diseñadores de un modelo analítico (OLAP) están mucho más
familiarizado con el diseño de un modelo transaccional (OLTP) por lo cual
instintivamente buscan aplicar las mismas técnicas y patrones de diseño
olvidando que ambos enfoques tienen objetivos completamente distintos. En el post anterior mencionamos el error de
manejar el encabezado como una dimensión (por ejemplo una factura en la que el encabezado de la
factura es tratado como una dimensión). En este caso
trataremos el error de manejar tanto el encabezado, como el detalle como
fact tables como podemos ver en el siguiente diagrama:
(Los nombres de tablas y campos en este ejemplo no son importantes, lo importante es notar el diseño de 2 fact tables unidas por una tabla foránea)
En este caso, el encabezado ya no es una dimensión, sino una
fact table a la cual están asociadas diversas dimensiones (por ejemplo: producto,cliente,
sucursal ,fecha). El detalle es a su vez otra fact table relacionada con el
encabezado a través de una llave foránea (por ejemplo el número de factura) y adicionalmente otras dimensiones.
Aunque este diseño representa de manera precisa la relación jerárquica padre/hijo entre el encabezado y el detalle, tiene fallas importantes. Si bien hemos mencionado antes, en un modelo analítico se busca facilidad de consumo y tiempo ágil de respuesta , buscando almacenar la información de manera que se tenga la menor cantidad de joins y cálculos posibles en tiempo de consulta, a costo de un mayor espacio en disco(esto varía en función del motor de base de datos y la tecnología de este, ya que hay motores columnares especializados para OLAP que manejan índices y bitmaps) y procesamiento en tiempo de ETL, asi como tiempo de desarrollo a los procesos de ETL, en este modelo esto no ha sido aplicado , y el poder analizar las métricas a nivel de detalle implica realizar joins con el encabezado la cual es una tabla casi tan voluminosa (y con ritmo de crecimiento alto) como la tabla de detalle, y luego realizar un segundo join a las dimensiones. De esta manera el plan de ejecución de la consulta involucra: tabla voluminosa -> tabla voluminosa -> tablas pequeñas(dimensionales).
Aunque este diseño representa de manera precisa la relación jerárquica padre/hijo entre el encabezado y el detalle, tiene fallas importantes. Si bien hemos mencionado antes, en un modelo analítico se busca facilidad de consumo y tiempo ágil de respuesta , buscando almacenar la información de manera que se tenga la menor cantidad de joins y cálculos posibles en tiempo de consulta, a costo de un mayor espacio en disco(esto varía en función del motor de base de datos y la tecnología de este, ya que hay motores columnares especializados para OLAP que manejan índices y bitmaps) y procesamiento en tiempo de ETL, asi como tiempo de desarrollo a los procesos de ETL, en este modelo esto no ha sido aplicado , y el poder analizar las métricas a nivel de detalle implica realizar joins con el encabezado la cual es una tabla casi tan voluminosa (y con ritmo de crecimiento alto) como la tabla de detalle, y luego realizar un segundo join a las dimensiones. De esta manera el plan de ejecución de la consulta involucra: tabla voluminosa -> tabla voluminosa -> tablas pequeñas(dimensionales).
Luego de ver el problema , y lo que este conlleva, podemos tocar la solución al mismo,
nuevamente esta solución conlleva un patrón de diseño que puede causar
incomodidad al diseñador(arquitectos de datos, ingenieros de datos, etc) que está
acostumbrado al modelado relacional de sistemas transaccionales pero que luego
de absorberlo se verán los beneficios en la agilidad y performance en un sistema
de distinto enfoque(analítico) .
La solución consiste en crear una única fact
table, cuya granularidad es 1 registro
en el modelo dimensional, por cada registro del detalle en el modelo
transaccional, las dimensiones asociadas al encabezado(o maestro) son asociadas
a cada registro de la fact table a través
de llaves foráneas a las tablas dimensionales.
De esta forma se evita el
realizar joins enter 2 tablas voluminosas , y el tener que recorrer estas
tablas para encontrar los valores distintos de cada dimensión, y así también se
genera un modelo más intuitivo y entendible para usuarios de negocio , lo cual
cumple con 2 de los objetivos fundamentales: facilidad y agilizad de consumo de
información
Autor: Luis Leal
