Saltar la navegación

4.1) Carga Inicial

Debemos en este paso realizar la Carga Inicial del DW, poblando el modelo construido en pasos anteriores. Para lo cual debemos llevar adelante una serie de tareas básicas, tales como asegurar la limpieza y calidad de los datos, procesos ETL, etc.

En muchos casos, las tareas antes mencionadas tienen una lógica compleja. Afortunadamente, en la actualidad existen muchas herramientas de software que se pueden emplear y que nos facilitan en gran parte el trabajo.

Se debe evitar que el DW sea cargado con Missing Values (valores faltantes), Outliers (datos anómalos) o faltos de integridad; se deben establecer condiciones y restricciones para asegurar que solo se utilicen los datos de interés.

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. Puede darse el caso que algunas restricciones aplicadas sobre una tabla de Dimensión para analizar una tabla de Hechos, se contrapongan 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. 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. Esto se debe a la existencia de claves foráneas y se realiza para evitar problemas de rechazo de datos por parte del SGBD.

Concretamente, en este paso se deberán registrar en detalle las acciones llevadas a cabo con los diferentes Software de Integración de datos. Por ejemplo, es común que sistemas ETL trabajen con Pasos y Relaciones, en donde cada Paso realiza una tarea en particular del Proceso ETL y cada Relación indica hacia donde debe dirigirse el flujo de datos.

Se debe especificar:

  • qué hace el proceso en general y luego
  • qué hace cada Paso y Relación.

Es decir, se partirá de lo más general y se irá a lo más específico, para obtener de esta manera una visión general y detallada de todo el proceso.

Es importante tener presente, que al cargar los datos en las tablas de Hechos pueden utilizarse preagregaciones con el mismo nivel de granularidad o con niveles menores.

Caso práctico

Para simplificar la aplicación del ejemplo, el caso práctico solo se centrará en los aspectos más importantes del Proceso ETL, obviando entrar en detalle de cómo se realizan algunas funciones y/o pasos.

Proceso ETL Principal

El Proceso ETL principal planteado para la Carga Inicial es el siguiente:

Las tareas que lleva a cabo este proceso son:

  • Inicio: inicia la ejecución de los pasos en el momento en que se le indique.
  • Establecer variables Fecha_Desde y Fecha_Hasta: establece dos variables globales que serán utilizadas posteriormente por algunos Pasos.
    • Para la variable Fecha_Desde se obtiene el valor de la fecha en que se realizó la primera venta.
    • Para la variable Fecha_Hasta se obtiene el valor de la fecha actual.
  • Carga de Dimensión dimClientes: ejecuta el contenedor de Pasos que cargará la tabla de Dimensión dimClientes (más adelante se detallará).
  • Carga de Dimensión dimProductos: ejecuta el contenedor de Pasos que cargará la tabla de Dimensión dimProductos (más adelante se detallará).
  • Carga de Dimensión dimFechas: ejecuta el contenedor de Pasos que cargará la tabla de Dimensión dimFechas (más adelante se detallará).
  • Carga de Tabla de Hechos factVentas: ejecuta el contenedor de Pasos que cargará la tabla de Hechos factVentas (más adelante se detallará).

Carga de Dimensión dimClientes

A continuación, se especificarán las tareas llevadas a cabo por Carga de Dimensión dimClientes. Este Paso es un Contenedor de Pasos, así que incluye las siguientes tareas:

  • Obtener datos de Datasource: obtiene a través de una consulta SQL los datos del Datasource necesarios para cargar la tabla de Dimensión dimClientes.

Se tomará como fuente de entrada la tabla Clientes del Data Source mencionado anteriormente.

Se consultó con l@s usuari@s 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 se encuentren en estas condiciones.

Los clientes eliminados son referenciados mediante el campo Eliminado; el valor 1 indica que éste fue eliminado y el 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 campo se agregó poco después de haberse creado la base de datos inicial, razón por la cual existían Missing Values (valores faltantes). Además, comentó que en el sistema, si un cliente posee en el campo Eliminado el valor 0 o un Missing Value (valor faltante), es considerado como vigente.

Con respecto a la cuenta habilitada, el campo del Data Source que le corresponde es Cta_Habilitada; el valor 0 indica que su cuenta NO está habilitada y el valor 1 que su cuenta sí está habilitada.

A continuación se expondrá la sentencia SQL configurada en este Paso:

  • Cargar dimClientes: almacena en la tabla de Dimensión dimClientes los datos obtenidos en el Paso anterior.

Carga de Dimensión dimProductos

Se especificarán las tareas llevadas a cabo por Carga de Dimensión dimProductos. Este Paso es un Contenedor de Pasos, así que incluye las siguientes tareas:

  • Obtener datos de Datasource: obtiene a través de una consulta SQL los datos del Data Source necesarios para cargar la Dimensión dimProductos.

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

En este caso, aunque existían productos eliminados, l@s usuari@s decidieron que esta condición NO fuese tomada en cuenta, ya que había 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.

La sentencia SQL configurada en este paso es la siguiente:

  • Cargar dimProductos: almacena en la tabla de Dimensión dimProductos los datos obtenidos en el Paso anterior.

Carga de Dimensión dimFechas

A continuación, se especificarán las tareas llevadas a cabo por Carga de Dimensión dimFechas. Este Paso es un Contenedor de Pasos, así que incluye las siguientes tareas:

Para generar la tabla de Dimensión dimFechas (la cual debe estar presente en todo DW) existen herramientas y utilidades de Software que proporcionan diversas opciones para su confección.

Lo que se hizo, fue confeccionar un Procedure (procedimiento) que trabaja de la siguiente manera:

  • 1) Recibe como parámetros los valores de Fecha_Desde y Fecha_Hasta.
  • 2) Recorre una a una las fechas que se encuentran dentro de este intervalo.
  • 3) Analiza cada fecha y realiza una serie de operaciones para crear los valores de los campos de la tabla de la Dimensión dimFechas:

    • idFecha = YEAR(fecha)*10000 + MONTH(fecha)*100 + DAY(fecha)
    • anio = YEAR(fecha)
    • trimestre = CASE WHEN QUARTER(fecha) = 1 then '1er Tri' ... END
    • mes = CASE WHEN MONTH(fecha) = 1 then 'Enero' ... END
  • 4) Inserta los valores obtenidos en la tabla de Dimensión dimFechas.

La clave principal idFecha es un campo numérico representado por el formato yyyymmdd.

Carga de Tabla de Hechos factVentas

A continuación, se especificarán las tareas llevadas a cabo por Carga de Tabla de Hechos factVentas. Este Paso es un Contenedor de Pasos, así que incluye las siguientes tareas:

  • Obtener datos de Datasource: obtiene a través de una consulta SQL los datos del Data Source necesarios para cargar la tabla de Hechos factVentas.

Para la confección de la tabla de Hechos, se tomaron como fuente las tablas Facturas_Ventas y Detalles_Venta. Al igual que en las tablas de Dimensiones, se analizaron las condiciones que deben cumplir los datos para considerarse de interés. 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 brinda dicha información es Anulada de la tabla Facturas_Ventas y si el mismo posee el valor 1 significa que efectivamente fue anulada.

Otro punto 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 configurada en este Paso es la siguiente:

  • Cargar factVentas: almacena en la tabla de Hechos factVentas los datos obtenidos en el Paso anterior.