Curso Pentaho DI. Componentes de un sistema BI – PARTE 2

2.2 Data Warehouse y Data Marts. Conceptos genéricos.

El significado de los términos Data Warehouse o Data Marts, entre otros, son cuanto menos familiares en cualquier contexto de las TIC que tenga una relación más o menos directa con la gestión de bases de datos.

La finalidad de este curso no es entrar en el detalle de estos conceptos, pero si que requieren ser conocidos para saber de que recursos disponemos y como ubicarlos en nuestra arquitectura definida para la implantación de Business Intelligence.

Estos términos, los vamos a utilizar a lo largo de todo el curso por lo que es necesario hacer un inciso para recordar que significa cada concepto y como ubicarlo en la practica.

Data Warehouse: Es un almacén de datos (traducción literal del inglés), orientada a un determinado ámbito. Este almacén es no volátil y variable en el tiempo. Dicha información almacenada se utiliza para la toma de decisiones basadas en el histórico almacenado. Estos contenedores de información no se usan para almacenar información actual, además de que al contener grandes cantidades de información, normalmente se subdividen en unidades lógicas más pequeñas. Está diseñado sobre todo para optimizar el análisis y divulgación de la información almacenada (Procesamiento analítico en Línea. OLAP). Dos de los autores más conocidos sobre la materia, definen Data Warehouse como:

• Bill Inmon (Metodología de desarrollo top-down): El Data Warehouse tiene las siguientes características:

• Orientado a temas

• Variante en el tiempo

• No volátil

• Integrado

• Ralph Kimball (Metodología de desarrollo bottom-up): El Data Warehouse es una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis.

Data Marts: Son subconjuntos de datos del Data Warehouse, utilizando diferentes segmentaciones. Sus características más destacadas:

• Usuarios limitados

• Área especifica

• Finalidad especifica

• Tiene una función de apoyo

Según lo indicado sobre las características del Data Mart, se puede caer en el error de creer que:

• Son más simples de implementar. Tienen la misma complejidad que un Data Warehouse

• Al ser menor el conjunto de datos, necesita menos recursos. Ya que el número de registros puede ser mucho menor, pero la estructura de datos, no tiene que variar respecto al DWH, lo cual hace que el uso de recursos, no varíe prácticamente.

• El tiempo de consulta, es menor debido al volumen de datos. Esto no es real, ya que al tener topologías en estrella, las consultas se segmentan de manera que el tiempo de ejecución no varía entre un DWH y un DM.

• Los tiempos de actualización entre un DWH a un DM, son muy similares a los de un DWH a los datos primarios.

Las últimas líneas de este punto las vamos a dedicar para definir las topologías de bases de datos más utilizadas en la construcción de estos ‘almacenes’.

Tablas de Hechos: Es la tabla central de un esquema dimensional donde se almacenan los indicadores de negocio, que vinculan esta tabla a las tablas de dimensiones.

Tablas de dimensiones: Contienen los atributos de los datos almacenados en la tabla de Hechos

Esquema en estrella: Está formada por una tabla central (tabla de hechos), que recoge la información de los identificadores que relaciona los datos de las tablas de dimensiones. Y las tablas de dimensiones, que contienen la información completa de los datos referenciados desde la tabla de hechos.

Esquema de copo de nieve: Similar al esquema en estrella, pero algunas de las tablas de dimensiones, tienen vinculadas otras tablas en un nivel inferior. Estos esquemas debido a su topología tienen un peor rendimiento que los esquemas en estrella.

 

Cubos: Son bases de datos multidimensionales, en la cual el almacenamiento de datos, se realiza mediante un vector multidimensional.

 

2.3 Composición de cada parte en un entorno BI

Explicados los elementos anteriores, solo nos queda saber ubicarlos en el contexto de la tecnología Business Intelligence, para comprender el funcionamiento genérico en este ámbito.

Como se muestra en la figura anterior, podemos dividir cada parte como un paso dentro de la ejecución de carga.

Por una parte, obtenemos los datos de los diferentes orígenes, tras el análisis previo, con el fin de poder modelar posteriormente dicha información para la obtención de los indicadores requeridos.

Tras esta extracción de información, alimentamos nuestros desarrollos ETL (sobre nuestra herramienta ETL), para realizar el modelado de la información pertinente. En este paso, se suelen utilizar tablas intermedias, para conseguir el objetivo de carga del DWH, del DM o de ambos, como ya se ha comentado anteriormente.

Carga de los datos en la Base de Datos que albergará toda la información que vamos a interpretar posteriormente.

Y por último, la representación de los datos mediante los cuadros de mando.

Estos serían los pasos y elementos que formarán parte de la carga de los KPIs definidos por el cliente. Por lo que con todo esto ya estaríamos en un contexto Business Intelligence.

Dentro de las buenas prácticas, debemos recordar que no trabajaremos sobre la capa de producción, sino que se definirán varias capas para garantizar la subida de los desarrollos estables y realizando las cargas correctas. Para ello, podemos definir, por ejemplo, una capa de desarrollo con una copia de algunos de los registros por cada tabla implicada, desde donde desarrollaremos las ETLs. Una vez desarrollada, se realizará un despliegue a otra capa, por ejemplo Integración, donde se realizan pruebas con datos y volúmenes de información, cercana a la realidad, con el fin de confirmar el correcto funcionamiento y validar los datos de carga. Como último paso, se realizaría un despliegue a Producción, donde ya se explotarán los datos reales, planificando la ETL en la ventana de ejecución definida.

Un ejemplo de esquema de despliegue entre entornos, sería: