Diseño de un “data warehouse”: explicación de los errores de Kimball mediante ejemplos. (Parte III)

Para cerrar esta serie de artículos, continuaremos con los “últimos” errores de Kimball.

Espero que los contenidos tratados hayan despertado el interés sobre el apasionante mundo de la BI.

“Error 6: Crear un modelo dimensional para resolver un informe en particular.”

La fase de contacto con el cliente en una implantación de un data warehouse debe servir para definir los indicadores que se deberán registrar en el mismo, no para definir el modo en que estos serán explotados. Si el modelo se orienta a un informe en concreto, lo más probable es que ese informe sea correcto pero cualquier otro vera aumentado su grado de complejidad (llegando a hacer imposible su generación). Además, al orientar hacia un informe podría suponer una gran pérdida de tiempo si el cliente modificase esos requerimientos.

“Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.”

Esto supondría una pérdida de datos o una información incompleta que no permitiría profundizar en el análisis de los datos.

Por ejemplo dada la tabla de hechos de ventas:

Estaríamos mezclando los niveles de granularidad ya que, aunque el campo TotalAmount fuese un agregado del costo de los productos de cada línea de producto de un pedido, nos resultaría imposible saber a qué precio se vendió cada producto.

“Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.“

Si disponemos del máximo nivel de detalle en el data warehouse cualquier pregunta podrá ser respondida. En el momento en que descartamos información estamos perdiendo consistencia de los datos y complicando la resolución de futuros requerimientos.

Por ejemplo, supongamos que queremos analizar las ganancias por pedido. Para ello tendremos la siguiente tabla de hechos.

En este momento conocemos la cantidad neta, total y el impuesto (además de las ganancias calculadas). Pero qué pasa si todos los productos de un pedido no tienen el mismo IVA o si queremos saber cuáles son nuestros productos más rentables y más vendidos. Al no guardar el máximo detalle habremos perdido la capacidad de responder a esas preguntas.

“Error 3: Omitir las tablas agregadas y comprimir las tablas de dimensión para afrontar los problemas de rendimiento.“

Todos los data warehouse tienen problemas de rendimiento ya que la información es ingente. Para la mejora del mismo se deben analizar las consultas que se realizan. En el caso de que se realicen muchas consultas que calculen datos sobre granularidades de tiempo mayores que las que definimos en el diseño, se debe sopesar el uso de tablas agregadas. Es cierto que estas tablas deberán ser mantenidas pero, en comparación con los tiempos de espera, la memoria física resulta muy barata. Además, como ya he dicho con anterioridad, las tablas de dimensión no suponen normalmente un coste excesivo por lo que su compresión no mejoraría el rendimiento de forma sustancial.

“Error 2: No unificar los hechos entre distintas tablas de hechos.”

En una tabla de hechos deben de almacenarse todos los registros donde tenga valor nuestra semilla.

Por ejemplo, dada la tabla de hechos de ventas por producto:

Deberemos registrar también las devoluciones para poder conocer exactamente la cantidad de productos devueltos y los productos que realmente han salido de nuestro almacén. No se deberá crear otra tabla de hechos que registre las devoluciones.

“Error 1: No compartir dimensiones entre diferentes tablas de hechos.”

La duplicidad de dimensiones, además de aumentar el tamaño del data warehouse innecesariamente, genera informes imprecisos. Toda la información debe ser filtrada y “estandarizada” para permitir análisis más precisos en la explotación de los datos.
Por ejemplo, si tenemos distintos orígenes de datos a volcar en el data warehouse, deberemos consolidarlos para que, ya sean distintas descripciones o identificadores de objeto del operacional sean agrupados cuando, en realidad, hagan referencia al mismo objeto.

Post publicado por: Juan José Hernández