5.5.5 Paso 4) Procesos ETL

Capítulo 5. Metodología HEFESTO

5.5 Pasos y aplicación metodológica

  5.5.4 PASO 4) PROCESOS ETL

5.5.4. PASO 4) PROCESOS ETL

Una vez construido el modelo lógico, se deberá proceder a probarlo con datos, a través de procesos ETL.

Para realizar la compleja actividad de extraer datos de diferentes fuentes, para luego integrarlos, filtrarlos y depurarlos, existen varios software que facilitan estas tareas, por lo cual este paso se centrará solo en la generación de las sentencias SQL que contendrán los datos que serán de interés.

Antes de realizar la carga de datos, es conveniente efectuar una limpieza de los mismos, para evitar valores faltantes y anómalos.

Al generar los ETL, se debe tener en cuenta cual es la información que se desea almacenar en el depósito de datos, para ello se pueden establecer condiciones adicionales y restricciones. Estas condiciones deben ser analizadas y llevadas a cabo con mucha prudencia para evitar pérdidas de datos importantes.

Cuando se trabaja con un esquema constelación, hay que tener presente que varias tablas de dimensiones serán compartidas con diferentes tablas de hechos, ya que puede darse el caso de que algunas restricciones aplicadas sobre una tabla de dimensión en particular para analizar una tabla de hechos, se puedan contraponer con otras restricciones o condiciones de análisis de otras tablas de hechos.

Primero se cargarán los datos de las dimensiones y luego los de las tablas de hechos, teniendo en cuenta siempre, la correcta correspondencia entre cada elemento. En el caso en que se esté utilizando un esquema copo de nieve, cada vez que existan jerarquías de dimensiones, se comenzarán cargando las tablas de dimensiones del nivel más general al más detallado.

Cuando se haya cargado en su totalidad el DW, se deben establecer sus políticas de actualización o refresco de datos.

Es importante tener presente, que al cargar los datos en las tablas de hechos pueden utilizarse preagregaciones, ya sea al nivel de granularidad de la misma o a otros niveles diferentes.

Caso práctico:

A continuación, se generarán las sentencias SQL para cargar las diferentes tablas de dimensiones y la tabla de hechos.

• Tabla de dimensión “CLIENTE”:

Se tomará como fuente de entrada la tabla “Clientes” del OLTP mencionado anteriormente.

Se consultó con los usuarios y se averiguó que deseaban tener en cuenta solo aquellos clientes que no estén eliminados y que tengan su cuenta habilitada.

Es importante destacar que aunque existían numerosos movimientos de clientes que en la actualidad no poseen su cuenta habilitada o que figuran como eliminados, se decidió no incluirlos debido a que el énfasis está puesto en analizar los datos a través de aquellos clientes que no cuentan con estas condiciones.

Los clientes eliminados son referenciados mediante el campo “Eliminado”, en el cual un valor “1” indica que este fue eliminado, y un valor “0” que aún permanece vigente. Cuando se examinaron los registros de la tabla, para muchos clientes no había ningún valor asignado para este campo, lo cual, según comunicó el encargado del sistema, se debía a que este se agregó poco después de haberse creado la base de datos inicial, razón por la cual existían valores faltantes. Además, comentó que en el sistema, si un cliente posee en el campo “Eliminado” un valor “0” o un valor faltante, es considerado como vigente.

Con respecto a la cuenta habilitada, el campo del OLTP que le hace mención es “Cta_Habilitada”, y un valor “0” indica que no está habilitada y un valor “1” que sí.

Seguidamente, se generará la sentencia SQL, sobre el OLTP “Clientes”, con los datos requeridos para cargar esta tabla de dimensión:

• Tabla de dimensión “PRODUCTO”:

Las fuentes que se utilizarán, son las tablas “Productos” y “Marcas”.

En este caso, aunque existían productos eliminados, el usuario decidió que está condición no fuese tomada en cuenta, ya que habían movimientos que hacían referencia a productos con este estado.

Es necesario realizar una unión entre la tabla “Productos” y “Marcas”, por lo cual se debió asegurar que ningún producto hiciera mención a alguna marca que no existiese, y se tomaron medidas contra su futura aparición.

El SQL es el siguiente:

• Tabla de dimensión “FECHA”:

Para generar esta tabla de dimensión, infaltable en todo DW, existen varias herramientas y utilidades de software que proporcionan diversas opciones para su confección. Pero, si no se cuenta con ninguna, se puede realizar a mano o mediante algún programa, llenando los datos en un archivo, tabla, hoja de cálculo, etc, y luego exportándolos a donde se requiera.

Lo que se hizo, fue realizar un pequeño programa para cargar en un archivo plano las fechas desde el año del primer movimiento de la empresa, en este caso el año 2000, hasta la fecha actual.

A continuación, se puede apreciar una muestra de los datos generados:

Como se puede observar, la primera fila representa los nombres de las columnas, las cuales están separadas entre sí, y para establecer delimitadores, por “;”, y sus nombres figuran entre comillas dobles. De la segunda fila en adelante se encuentran todos los datos de la dimensión. Los campos que son del tipo texto están encerrados entre comillas dobles, los que son numéricos no.

La clave principal es un campo numérico representado por el formato “yyyymmdd”. La misma también puede calcularse mediante la siguiente fórmula:

• Tabla de hechos “VENTAS”:

Para la confección de la tabla de hechos, se tuvieron que tomar como fuente las tablas “Facturas_Ventas” y “Detalles_Venta”. Al igual que en las tablas de dimensiones, se recolectaron las condiciones que deben cumplir los datos para considerarse de interés, y en este caso, se trabajará solamente con aquellas facturas que no hayan sido anuladas.

Se investigó al respecto, y se llegó a la conclusión de que el campo que da dicha información en “Anulada” de la tabla “Facturas_Ventas” y si el mismo posee el valor “1” significa que efectivamente fue anulada.

Otro punto importante a tener en cuenta es que la fecha se debe convertir al formato numérico “yyyymmdd”.

Se decidió aplicar una preagregación a los hechos que formarán parte de la tabla de hechos, es por esta razón que se utilizará la cláusula GROUP BY para agrupar todos los registros a través de las claves primarias de esta tabla.

La sentencia SQL resultante fue la siguiente:

Con respecto a las actualizaciones del depósito de datos, también existen diversas herramientas DW, que proveen muchas facilidades, por lo cual no se entrará en detalle en su utilización, pero sí se establecerá por escrito las políticas que se han convenido con los usuarios:

• La información se refrescará cada semana.

• Los datos de las tablas de dimensiones “PRODUCTO” y “CLIENTE” serán cargados totalmente cada vez.

• Los datos de la tabla de dimensión “FECHA” se cargarán de manera incremental teniendo en cuenta la fecha de la última actualización.

• Los datos de la tabla de hechos que corresponden al último año a partir de la fecha actual, serán reemplazados cada vez.

• Estas acciones se realizarán durante un periodo de prueba, para analizar cuál es la manera más eficiente de generar las actualizaciones, basadas en el estudio de los cambios que se producen en los OLTP y que afectan al contenido del DW.