Etapas para la construcción del DataWareHouse (Cont.)

Modelo lógico del DataWareHouse 

Los modelos conceptuales son representaciones generales de la información y no determinan la forma en que serán representados; en esta siguiente etapa se diseñará el modelo lógico para contener la estructura del depósito de datos. Primeramente se seleccionará el tipo de modelo a utilizar, posteriormente se definirán las dimensiones, los hechos y las uniones correspondientes.

Tipo de modelo lógico del DataWareHouse

En este paso se debe elegir el tipo de esquema que se utilizará, se debe elegir el esquema más adecuado a los requerimientos y necesidades de los usuarios. Los modelos que se pueden emplear son esquemas en estrella, constelación o copo de nieve.

Tablas de dimensiones 

En este paso se definen las tablas de dimensiones que contendrá el DataWareHouse, cada perspectiva del modelo conceptual constituirá una tabla dimensión; para ello se deben realizar las siguientes actividades:

• Se debe elegir un nombre que identifique a la tabla dimensión y que represente de manera adecuada la perspectiva que representa.
• Seleccionar el campo que represente su clave principal
• Se redefinirán los nombres de los campos en caso que sus nombres no sean lo suficientemente específicos de la información que representan.

Tablas de Hechos

La tabla de hechos contiene la representación de los indicadores que se pretende analizar o estudiar; para su construcción se deben realizar las siguientes actividades:

• Se debe seleccionar un nombre para la tabla de hechos
• Se definirá su clave primaria, que se compone de la combinación de las claves primarias de cada tabla de dimensión relacionada.

Uniones 

Las uniones representan las relaciones entre las tablas de dimensión y de hechos.

Integración de Datos

Una vez construido el modelo lógico se debe realizar el poblado de las estructuras físicas en apego a las políticas y reglas definidas para tal propósito.

Carga inicial

La carga de datos en el Data WareHouse requiere llevar a cabo algunas tareas que tienen relación con la calidad de los datos, limpieza de los mismos y procesos de ETL (Extract, Transform and Load, del inglés Extracción, Transformación y Carga).

En este paso se realizan las estrategias comentadas en "Procesamiento de Datos", con el propósito de que la información que se utilice cumpla con las condiciones y restricciones de calidad establecidas.

Las herramientas de ETL representan el soporte principal para las tareas de integración de datos, la mayor cantidad de esfuerzo para la construcción y actualización recaen en éstas.
 

El motor ETL de Pentaho ejecuta los trabajos (Job) y transformaciones (Transform) creados con las herramientas de Pentaho Data Integration (PDI, también conocido como Spoon).

El motor ETL es parte de la estructura del BI, pero puede correr en diferentes servidores o aún en múltiples servidores en modo de Cluster.
Para la carga de datos se requiere que primeramente se carguen las tablas de dimensiones y al final las tablas de hechos, teniendo en cuenta siempre la correcta correspondencia entre las claves de las tablas dimensiones y de hecho.
 

Cuando se utilicen esquemas copo de nieve, si existen jerarquías se deben comenzar cargando las tablas de dimensiones del nivel más general al más detallado.

Actualización

La información de los Data WareHouse son dinámicos y los análisis deben realizarse sobre información nueva que se debe actualizar periódicamente, independientemente que el Data WareHouse contenga información histórica.

Ralph Kimball, inventor del modelo multidimensional, propuso tres diferentes estrategias para llevar a cabo las actualizaciones, también conocidas como Slowly Changing Dimensions (SCD, del inglés Dimensiones Lentamente Cambiantes), los cuales se describen a continuación:

SCD Tipo 1.- Sobrescribir 
Las columnas son pobladas con la información nueva, desechando y sin conservar los valores anteriores.
 
SCD Tipo 2.- Añadir renglón

Esta estrategia permite conservar información y preservar información histórica, extrayendo datos actualizados cuando se realizan las consultas a las tablas de dimensión. 

Para seguir la pista de los cambios realizados es necesario agregar campos adicionales, lo más común es agregar campos de tipo TimeStamp al registro de la dimensión; normalmente el campo de Valid_From (válido desde...) y Valid_To (válido hasta...). Además se pueden utilizar campos que definen el registro válido actualmente (Current_Record), llenándose con valores incrementales cada vez que existe un registro nuevo.

SCD Tipo 3.- Añadir columna 

Esta estrategia necesita, al menos una columna extra en la tabla dimensión. Cuando el valor de una columna cambia se añade una columna extra que contiene el valor anterior. Para este caso sólo es posible almacenar una versión extra.

La estrategia a utilizar dependerá del tipo de datos y la periodicidad de las actualizaciones, por lo que se recomienda analizar cuidadosamente la opción seleccionada.

Etapas para la construcción del DW

Hefesto propone una metodología para la construcción del DataWareHouse en cuatro etapas sencillas que permite en un periodo corto de tiempo entregar resultados.

La siguiente figura  muestra las etapas del proceso de construcción y al igual que las fases del proceso de BI, para un mayor entendimiento posteriormente se describirá un caso práctico de la implementación de indicadores.

Etapas para la construcción del Data WareHouse. (Dario, 2013)

Análisis de los Requerimientos

Identificar Preguntas

Dentro del ciclo de vida para el análisis y desarrollo de sistemas, una de las primeras actividades que deben desarrollarse es recopilar información acerca de las necesidades de los usuarios finales y de los directivos de la Institución.

Este conocimiento se lleva a cabo a través de métodos interactivos como son: Las entrevistas, las reuniones, encuestas mediante cuestionarios.
 

Otra forma de recopilar información es a través de métodos no intrusivos, como son: muestreo, la investigación y la observación del comportamiento, y el entorno físico. Este método debe respaldarse del método anterior, de lo contrario el resultado puede llegar a ser deficiente.
 

El conocimiento de los procesos del negocio y de los objetivos organizacionales es requerido por parte de quien realiza las preguntas, ya que éstas deben realizarse con objetividad y enfocados a obtener información vista desde diferentes perspectivas que ayude en la toma de decisiones.

Identificar Indicadores y Perspectivas

Una vez establecidas las preguntas de negocio, se deben analizar para poder obtener los indicadores claves que serán utilizados; estos indicadores deberán ser representados con valores numéricos y basados en la forma propuesta para la Matriz de Indicadores de Resultados.
 

Las organizaciones cuentan con áreas de interés para el análisis; dentro de cada una de ellas existen objetos específicos a los que se deben examinar para extraer el conocimiento requerido.

Modelo Conceptual

Un modelo conceptual es un esquema obtenido a partir de una lista descriptiva de objetos y asociaciones identificadas.
Para el caso del Data WareHouse el modelo se conforma de indicadores y perspectivas, lo que permitirá observar con claridad los alcances de las interrogantes planteadas por los usuarios.
 

El modelo debe ser claro para el implementador ya que a través de él se debe realizar la implementación física en el Data WareHouse, y debe permitir con facilidad ser explicado al usuario quién deberá aprobar si corresponde a las preguntas planteadas en la etapa de recolección de necesidades.
 

El modelo, tal como se ilustra en la figura requiere que las perspectivas se coloquen del lado izquierdo unido a través de un óvalo central que representa la relación que existe entre ellas. La relación constituye el proceso o área de estudio elegida. A la derecha se colocan los indicadores los cuales son entrelazados a la relación central.

Elementos del Modelo Conceptual, Fuente: elaboración propia

Análisis de los OLTP

Conformar Indicadores

En este paso debemos mostrar cómo se realizarán los indicadores; para nuestro proyecto debemos apegarnos a las especificaciones definidas en "Características de los Indicadores"  e indicar las operaciones que se realizarán.

Establecer correspondencias

Este paso tiene como propósito mostrar la información y las características que contienen los Sistemas OLTP para poder identificar las correspondencias entre el modelo conceptual requerido y las fuentes de datos.

Nivel de Granuralidad

Una vez establecidas las relaciones entre el modelo conceptual y las OLTP, se deben seleccionar los atributos que mostrarán las perspectivas por las que se analizarán y filtrarán los indicadores.

El análisis de la información por medio de los atributos seleccionados requiere un conocimiento de los procesos de negocio, por lo que es necesario conocer a detalle el significado de cada campo de información, esto se obtiene investigando los diccionarios de datos, entrevistando a los usuarios y a los administradores de los Sistemas.

El nivel de detalle del análisis de información se define en este paso y uno de los atributos más importantes a definir será la dimensión Tiempo.

Modelo Conceptual Ampliado

Los resultados obtenidos en los pasos anteriores son graficados, colocando las diferentes perspectivas y desglosando los atributos seleccionados por un lado; y los indicadores con sus respectivas fórmulas de cálculo por el otro; ambos lados unidos por medio de la acción de relación.

Operadores OLAP

Los modelos de datos se caracterizan en cómo se organiza la información, dicha organización se denomina estructura, y la forma en que se explota y explora la información se denominan operadores.

Los operadores OLAP son operadores de análisis, realizan las mismas consultas que se hacen mediante SQL, además cuenta con características especializadas para análisis de la información desde la perspectiva de almacenes de datos.

Las consultas realizadas en los modelos multidimensionales tienen la ventaja de realizarse de manera fácil y rápida; dichas consultas suelen ser dinámicas arrastrando simplemente con el ratón las dimensiones y las medidas. Por esa razón se dice que más que operadores son navegadores de informes.

Clasificación de los Operadores OLAP

• Drill.- La información se presenta desglosada a mayor nivel de detalle, mientras que las sumarizaciones son menores.
• Roll.- Al contrario de Drill, las sumarizaciones se presentan consolidadas, mientras que las dimensiones se presentan a un menor nivel de detalle.
• Slice & Dice.- Se seleccionan y se proyectan los datos
• Pivot.- se reorientan las dimensiones

Operadores OLAP: Roll, Drill y Pivot respectivamente, Fuente: elaboración propia

Expresiones Multidimensionales (MDX) 

MDX es un lenguaje de consulta para bases de datos multidimensionales sobre cubos OLAP, se utiliza en Sistema de Inteligencia de Negocios para generar reportes para la toma de decisiones basados en datos históricos. Tal como el lenguaje SQL representa un estándar para las bases de datos relacionales, MDX lo es para las bases de datos multidimensionales.

Sintaxis básica de MDX

SELECT {[Measures].[Inversion 1], [Measures].[Inversion 2] } ON COLUMNS,
{[Entidades].members} ON ROWS
WHERE [Ejercicio Fiscal].[2010]

Propuesta de la Implementación del DataWareHouse

El Data WareHouse es una infraestructura tecnológica que reúne una colección de datos de bases de datos transaccionales y otras fuentes externas, para hacerlas accesibles para el análisis y la toma de decisiones.
La construcción de un Data WareHouse está basada en una serie de etapas que proporcionan un marco de trabajo y que pertenece a una fase de la Metodología de BI.

Características de la Metodología

• El enfoque aplicado es principalmente basado en los requerimientos de los usuarios; sin embargo, también podemos dar relevancia al modelo de datos con que contamos en el Sistema Transaccional - OLTP.
• Utiliza modelos conceptuales y lógicos, sencillos de interpretar y analizar.
• No depende de alguna herramienta en particular para su implementación
• Es fácil de entender y llevar a la práctica
• El Data WareHouse es el encargado de extraer, transformar, consolidar, integrar y centralizar los datos que la Institución genera en todos los ámbitos de la actividad diaria (Programas Sociales, Nómina, Inventario, Viáticos, etc.), permitiendo a través de análisis multivariantes el acceso y exploración de la información requerida (Dario, 2013).

OLTP

La entrada, la recuperación y el procesamiento de datos se realiza normalmente mediante Sistemas Transaccionales en Línea (OLTP) y corresponde a las cargas de trabajo operacionales diarias de la institución.
 
El término On-Line implica disponibilidad en tiempo real y su uso puede llegar a ser de cientos o miles de usuarios, por lo que es necesario que el Sistema cuente con tiempos de respuestas eficientes.

 

Sistemas transaccionales como fuentes de información, Fuente: elaboración propia

Las operaciones que se realizan habitualmente son las altas, bajas, modificaciones de los registros de información, por lo que se requiere que dicha información se encuentre estructurado en repositorios normalizados que permitan tiempos de respuestas ágiles.
Dentro de la arquitectura, los OLTP representan el punto de entrada y los insumos con que se alimentará el Data WareHouse.

DATAMART

Las áreas funcionales que conforman el modelo de negocio de cualquier organización son múltiples y cada una de ellas tiene su grado de importancia dentro de la operación de la misma. Para que el análisis de la información sea más eficiente, normalmente las implementaciones de estos datos se realizan sobre un departamento o un área específica del negocio.
 

El almacenamiento especializado de los datos recibe el nombre de DataMart y permite analizar la información desde varias perspectivas, al mismo tiempo que otorga acceso confidencial y reduce la latencia del depósito de datos.

La implementación de los DataMart se realiza normalmente sobre cubos OLAP.

Esquema en Estrella

El modelo para el esquema en Estrella se construye con una tabla de hechos al centro y distribuido en torno a esta tabla, se encuentran las tablas de dimensiones.

Uno de los beneficios de usar un esquema de este tipo es la simplicidad y la compresión para los usuarios finales.
 

La diferencia entre las tablas de dimensiones y de hechos, es que las primeras contienen información acerca de las entidades de negocios (Ejecutores, Programas Sociales, Entidades Federativas) y las tablas de hechos contienen información acerca de eventos de negocios (Inversiones Aprobadas, Inversiones Ejercidas).

Las tablas de hechos contienen columnas sobre las cuales se pueden realizar operaciones de sumas, promedios, porcentajes; además se caracteriza por contener llaves foráneas que apuntan a las tablas de dimensión.

En las tablas de hechos los atributos de medidas responden generalmente a las preguntas de “cuánto”, mientras que las dimensiones responderán al “cuándo”, “qué” y “dónde”.

Modelo Estrella Simple, Fuente: elaboración propia

Modelo Copo de Nieve, Fuente: elaboración propia

Existen dos tipos de esquemas en estrella:

• Estrella Simple.- Cuando no hay caminos alternativos en las dimensiones
• Copo de Nieve.- Cuando si hay caminos alternativos