Datawarehouse
448 Vistas

Implementación Datawarehouse con Metodología Kimball

Por: Moisés Inestroza

La inteligencia de negocios (Business Intelligence) es un conjunto de metodologías, aplicaciones y tecnologías que aporta a empresas y organizaciones información privilegiada y debidamente estructurada, que sirve de soporte a la toma de decisiones.

Permite obtener datos relacionados con las alternativas de ingreso a nuevos mercados, ofertas de productos, eliminación de islas de información, controles financieros, optimización de costos, planificación de la producción , análisis de perfiles de clientes, rentabilidad de un producto, etc., para analizarlos y convertirlos en conocimiento.

En la práctica, la inteligencia de negocios es un factor determinante para el éxito y su implementación  no sería nada fácil, si no contáramos con un instrumento como la Metodología Kimball, para la construcción de un almacén de datos (Datawarehouse)  circunscrito al ámbito de la empresa, de manera integrada y permanente (pero variable) en el tiempo.

Producto de nuestra experiencia en el diseño de Datamart (base de datos departamentales) para un sistema de datawarehouse basado en la Metodología Kimball, hemos rescatado y exponemos en el  siguiente artículo algunos apuntes y sugerencias que consideramos de relevancia para aquellos que deseen implementar o explorar soluciones de esta naturaleza:

  • Una vez seleccionado el proceso al que se va a diseñar una solución OLAP (base de datos orientada al procesamiento analítico) es necesario efectuar un análisis y crear un diagrama OLTP (base de datos orientada al procesamiento de transacciones) de cada modelo implicado. Comprender con suficiente claridad la dinámica de esos datos verificando mediante scripts de consulta, será crucial para tomar decisiones de modelado OLAP. El diagrama debe plasmar todas las estructuras a considerar, es decir, toda la información que se desea extraer hacia el datawarehouse y sus relaciones.
  • Identificar correctamente el “Grano” en el que está la información, es decir el nivel mínimo de detalle para el que se puede obtener una medida determinada o identificar determinado evento que ha ocurrido.
  • Efectuar un análisis y crear un modelo OLAP que especifique las tablas de dimensión y de hechos resultantes, de preferencia, planteada en una “Topología Estrella”. En este modelo de datos debe converger toda la información de las distintas fuentes identificadas.
  • Es conveniente se nombre las tablas con el prefijo adecuado según la naturaleza de cada tipo de tabla OLAP (DIM, FACT). Los nombres para las tablas DIM (dimensiones) deben acabar en singular y los nombres de las tablas FACT (hechos) en plural.

Importancia de las tablas OLAP (DIM, FACT)

Como sabemos, un modelo OLAP se compone de tablas de dimensiones y tablas de hechos. Las dimensiones (DIM) son las tablas que contienen atributos o campos que se utilizan para restringir y agrupar los datos almacenados en una tabla de hechos (FACT).

Para aquellos catálogos pequeños que presentan cambios con muy poca o nula frecuencia en el tiempo (países, género) la lógica de estos ETL es básica. Consiste en limpiar y volver a cargar los datos desde la fuente. En la teoría a este tipo se le conocen como SCD de tipo 1 (Slow Change Dimension).

Las dimensiones en las que deseamos mantener un versionamiento para así poder llevar un tracking de los cambios que han sufrido los valores de determinada entidad la lógica del ETL debe ser comparar el registro actual en el DWH con el registro actual en la fuente OLTP. Es el caso, por ejemplo, de un Cliente que tiene un atributo Estado Civil que en determinado momento es “Soltero” pero luego se actualiza su ficha a “Casado”. Debemos conservar ambas versiones de ese cliente por si queremos luego analizar sus transacciones comparando su comportamiento cuando estaba Soltero a cuando estaba Casado )

Al  encontrar una diferencia en alguno de sus atributos, se crea un nuevo registro en  la dimensión de DWH con una nueva llave subrogada, y alimentando 4 atributos de control adicionales: VERSION, VERSION_ACTUAL (Flag con un 0 para No y un 1 para Sí), FECHA_DESDE (Timestamp de la fecha desde la cual es válida la nueva versión),FECHA_HASTA (Timestamp de la fecha hasta la cual es válida la versión).

  • Es preciso crear llaves subrogadas para todas las dimensiones, es decir una nueva llave, un valor correlativo único diferente a la llave natural que viene del registro en el sistema fuente OLTP, que también se conserva.
  • En la tabla de hechos deben ir todos aquellos eventos o transacciones que ocurren, como ventas, pagos, compras, logs, etc. Se sugiere que se incluya, de cada dimensión asociada, tanto su llave subrogada como su llave natural ya que, en determinado momento, puede que el registro en la dimensión haya cambiado de versión y hayan ocurrido transacciones asociadas a la versión anterior y a la versión actual. Teniendo la llave natural podrán identificarse con más facilidad todos los hechos asociados a determinada entidad sin necesidad de viajar a la dimensión.
  • Toda tabla del DWH debe contar con un timestamp o de registro que permita determinar en qué fecha, hora, minuto y segundo se creó determinado registro en la base de datos. Esto resulta de mucha utilidad en tareas de soporte y monitoreo, así como para propósitos de auditoría.
  • En cada dimensión se deben crear los registros default para los casos en que la información no esté disponible, no aplique o simplemente no exista y así poder distinguir estos escenarios en los hechos. Para ello debe insertarse en cada dimensión y deben usarse como llaves subrogadas y llaves naturales, valores que no vayan a coincidir con los valores de las llaves reales, por ejemplo: el valor cero (0) para el caso de No Definido (N/D, Not defined), el valor menos uno (-1) para el caso de No Aplica (N/A, Not applicable) y el valor menos dos -2 para Por ser Determinado (TBD, To be determinated).
  • Es necesario tener muy en consideración el cómo manejar los casos de Null, sugiriendo evaluar la siguientes alternativas: Dejar valor Null en variables numéricas de tipo Monto, Conteos, Tasas ya que las funciones de agregado ya saben manejar los casos de Null y si se cambia a valor 0 no se podrán determinar cuáles son los casos nulos y cuales son verdaderos casos con cero (0). En los campos alfanuméricos si se encuentra un Null dejar con ‘N/A’. En las llaves id_dim foráneas no puede quedar ningún valor en Null debe quedar apuntando a los registros default de 0,-1,-2.
  • Contar con una dimensión “Tiempo” con los pre-cálculos de fecha ya realizados y así ahorrarle esta tarea de procesamiento a quienes exploten la información del DWH. La dimensión tiempo podría tener la siguiente información:
  • Mes, año, día del mes.

  • La fecha competa incluyendo el nombre del día.

  • El nombre corto del día, el día de la semana en números.

  • El nombre corto correspondiente al día de la semana.

  • Flag fin de semana.

  • Flag si es laborable o no, es decir si son días en los cuales se trabaja.

  • El día del mes en número.

  • El día del año en número.

  • La semana del mes en número.

  • El nombre de la semana del mes.

  • La semana del año.

  • El número de días que tiene el mes.

  • La fecha del fin del mes.

  • El mes del año.

  • El nombre del mes del año.

  • El nombre corto del mes del año.

  • La combinación del año y el mes en números.

  • El trimestre del año al que corresponde una fecha.

  • El nombre del trimestre del año al que corresponde una fecha.

  • La fecha de finalización del trimestre.

  • El semestre del año al que corresponde una fecha.

  • Flag su es cierre de mes.

Con los apuntes esquematizados en el presente artículo esperamos haberle ayudado en la mejor comprensión del funcionamiento y la trascendencia para el éxito empresarial de un datawarehouse y no nos queda más que poner a sus órdenes a GO Consultores, donde cualquiera de nuestro equipo estará gustoso de exponerle nuestro servicio.

SOLICITE MÁS INFORMACIÓN ¡CONTÁCTENOS!

Categorías: