Una vez disponemos del módelo lógico completo y revisado, vamos a analizar cada una de las dimensiones, sus atributos e indicadores de negocio para identificar en los sistemas operacionales de la empresa el origen de los datos. Es decir, el lugar en las tablas de las aplicaciones ( aquí también caben otros origenes de información, como aplicaciones web, hojas excel, ficheros planos, etc), desde los cuales vamos a obtener los datos para llenar de manera efectiva nuestro DataWarehouse.
Este proceso de análisis será el punto de partida para la construcción de los procesos ETL ( Extraction, Transform and Load ) que nos permitirán automatizar la carga de nuestro sistema BI. Los procesos ETL seran un conjunto de trabajos o jobs, con diferentes pasos de diferentes tipos ( extracción de datos, filtrado, transformación, mapeo, verificación de errores, logs, etc), que provocaran que nuestro modelo lógico sea llenado con los datos de los sistemas de gestión de la empresa y de esa manera permitir su analisis según los requerimientos establecidos utilizando las herramientas de Business Intelligence.
La metodología para la identificación de cada uno de los componentes de nuestro DW va a consistir en revisar una por una las dimensiones y sus atributos, así como la tabla de hechos, y para cada componente, anotaremos en que lugar del sistema origen se encuentra, cuales son sus características, que tipo de transformaciónes deberemos realizar sobre ellos así como cualquier otra observación a tener en cuenta para la elaboración posterior de los procesos ETL.
Dimensión Tiempo: la dimensión tiempo es una dimensión ficticia, que no existe en nuestro ERP o sistema operacional como tal, y que construiremos a partir de los calendarios (en nuestro caso, generaremos los datos correspondientes a 20 años, desde el año 2000 al año 2020). Para la construcción de la dimensión y de todos sus atributos, construiremos un proceso ETL para la carga inicial de esta dimensión.
Transformaciones para la creación de la Dimensión Tiempo
Dimensión Producto: los datos principales de la dimensión Producto están en nuestro ERP Sap en la tabla MARA Maestro de Materiales. El origen de cada uno de los atributos y las transformaciones a realizar vienen descritas en la siguiente tabla:
Transformaciones para la creación de la Dimension Producto
Dimensión Cliente: los principales datos de los clientes en Sap los tenemos en la tabla KNA1. El origen de cada uno de los atributos y las transformaciones a realizar vienen descritas en la siguiente tabla:
Transformaciones para la creación de la Dimension Cliente
Dimensión Logística: Los datos de los centros logísticos se encuentran en la tabla T001W. El origen de cada uno de los atributos y las transformaciones a realizar vienen descritas en la siguiente tabla:
Transformaciones para la creación de la Dimension Logistica
Dimensión Promoción: Los datos de las promociones se encuentran en la tabla KONA. El origen de cada uno de los atributos y las transformaciones a realizar vienen descritas en la siguiente tabla:
Transformaciones para la creación de la Dimension Promocion
Hechos Transacciones de Ventas: los datos de negocio de las operaciones de venta estan registrados en las tablas de pedido de nuestro ERP y en tablas paralelas (cabecera de ventas VBAK y detalle de ventas VBAP) . El origen de las claves de la tabla de hechos y de los indicadores de negocio, asi como las transformaciones a realizar vienen descritas en la siguiente tabla:
Transformaciones para la creación de la tabla Hechos de Venta (I)
Transformaciones para la creación de la tabla Hechos de Venta (II)
Los campos calculados no siempre es necesario guardarlos en la tabla de Hechos, sobre todo si son campos que no tiene sentido tener calculado cuando estemos navegando por las dimensiones (como los porcentajes). Nos guardaremos para ellos los operadores necesarios para poder realizar los cálculos.
Nota: el origen de los datos aquí descrito es un modelo de ejemplo que puede tener una complejidad mayor o diferencias considerables si estuviesemos trabajando con sistemas reales. Solo trata de ser un ejemplo de como se deben de identificar los origenes de datos para el posterior proceso de extracción (recordar que estamos trabajando con un empresa ficticia para el desarrollo del proyecto). En la documentación también se debería de tener en cuenta cualquier casuistica a aplicar en cada atributo de cara a su conversión en atributos normalizados dentro del DW e incluir esas excepciones en la documentación de cara a los procesos ETL y a posteriores mantenimientos sobre el sistema.
Antes de continuar, veremos en la siguiente entrada del blog que son las herramientas ETL con un poco mas de profundidad, antes de pasar a la construcción del modelo físico definitivo y los procesos de llenado.