En este punto y teniendo en cuenta que ya se han detallado claramente las características generales del Data Warehousing, se definirán y describirán todos los componentes que intervienen en su arquitectura o ambiente.

A través del siguiente gráfico se explicitará la estructura del Data Warehousing:

---

Figura 3.1:   Data Warehousing, arquitectura.

---

Tal y como se puede apreciar, el ambiente esta formado por diversos elementos que interactúan entre sí y que cumplen una función específica dentro del sistema. Por ello es que al abordar la exposición de cada elemento se lo hará en forma ordenada y teniendo en cuenta su relación con las demás partes.

Básicamente, la forma de operar del esquema superior se resume de la siguiente manera:

• Los datos son extraídos desde aplicaciones, bases de datos, archivos, etc. Esta información generalmente reside en diferentes tipos de sistemas, orígenes y arquitecturas y tienen formatos muy variados.
• Los datos son integrados, transformados y limpiados, para luego ser cargados en el DW. 
• Principalmente, la información del DW se estructura en cubos multidimensionales, ya que estos preparan esta información para responder a consultas dinámicas con una buena performance. Pero también pueden utilizarse otros tipos de estructuras de datos para representar la información del DW, como por ejemplo Business Models.
• L@s usuari@s acceden a los cubos multidimensionales, Business Models (u otro tipo de estructura de datos) del DW utilizando diversas herramientas de consulta, exploración, análisis, reportes, etc.

A continuación se detallará cada uno de los componentes de la arquitectura del Data Warehousing, teniendo como referencia siempre el gráfico antes expuesto, pero resaltando el tema que se tratará.

Figura 3.2:  OLTP

---

OLTP (On Line Transaction Processing), representa toda aquella información transaccional que genera la empresa en su accionar diario, además, de las fuentes externas con las que puede llegar a disponer.

Como ya se ha mencionado, estas fuentes de información, son de características muy disímiles entre sí, en formato, procedencia, función, etc.

Entre los OLTP más habituales que pueden existir en cualquier organización se encuentran:

• Archivos de textos.
• Hipertextos.
• Hojas de cálculos.
• Informes semanales, mensuales, anuales, etc.
• Bases de datos transaccionales.

 3.3 Load Manager
  3.3.1 Extracción
  3.3.2 Transformación
   3.3.2.1 Codificación
   3.3.2.2 Medida de atributos
   3.3.2.3 Convenciones de nombramiento
   3.3.2.4 Fuentes múltiples
   3.3.2.5 Limpieza de datos
  3.3.3 Carga
  3.3.4 Proceso ETL
 

3.3. Load Manager 

Figura 3.3:  Load Manager.

---

Para poder extraer los datos desde los OLTP, para luego manipularlos, integrarlos y transformarlos, para posteriormente cargar los resultados obtenidos en el DW, es necesario contar con algún sistema que se encargue de ello. Precisamente, la Integración de Datos en quien cumplirá con tal fin.

La Integración de Datos agrupa una serie de técnicas y subprocesos que se encargan de llevar a cabo todas las tareas relacionadas con la extracción, manipulación, control, integración, depuración de datos, carga y actualización del DW, etc. Es decir, todas las tareas que se realizarán desde que se toman los datos de los diferentes OLTP hasta que se cargan en el DW.

Como se mencionó anteriormente cuando se trataron las características del DW, si bien los procesos ETL (Extracción, Transformación y Carga) son solo una de las muchas técnicas de la Integración de Datos, el resto de estas técnicas puede agruparse muy bien en sus diferentes etapas. Es decir, en el proceso de Extracción tendremos un grupo de técnicas enfocadas por ejemplo en tomar solo los datos indicados y mantenerlos en un almacenamiento intermedio; en el proceso de Transformación por ejemplo estarán aquellas técnicas que analizarán los datos para verificar que sean correctos y válidos; en el proceso de Carga de Datos se agruparán por ejemplo técnicas propias de la carga y actualización del DW.

A continuación, se detallará cada una de estas etapas, se expondrá cuál es el proceso que llevan a cabo los ETL y se enumerarán cuáles son sus principales tareas.

3.3.1. Extracción

Es aquí, en donde, basándose en las necesidades y requisitos de l@s usuari@s, se exploran las diversas fuentes OLTP que se tengan a disposición, y se extrae la información que se considere relevante al caso.

Si los datos operacionales residen en un SGBD Relacional, el proceso de extracción se puede reducir a, por ejemplo, consultas en SQL o rutinas programadas. En cambio, si se encuentran en un sistema no convencional o fuentes externas, ya sean textuales, hipertextuales, hojas de cálculos, etc, la obtención de los mismos puede ser un tanto más dificultoso, debido a que, por ejemplo, se tendrán que realizar cambios de formato y/o volcado de información a partir de alguna herramienta específica.

Una vez que los datos son seleccionados y extraídos, se guardan en un almacenamiento intermedio, lo cual permite, entre otras ventajas:

• Manipular los datos sin interrumpir ni paralizar los OLTP, ni tampoco el DW.
• No depender de la disponibilidad de los OLTP.
• Almacenar y gestionar los metadatos que se generarán en los procesos ETL.
• Facilitar la integración de las diversas fuentes, internas y externas.

El almacenamiento intermedio constituye en la mayoría de los casos una base de datos en donde la información puede ser almacenada por ejemplo en tablas auxiliares, tablas temporales, etc. Los datos de estas tablas serán los que finalmente (luego de su correspondiente transformación) poblarán el DW.

3.3.2. Transformación

Esta función es la encargada de convertir aquellos datos inconsistentes en un conjunto de datos compatibles y congruentes, para que puedan ser cargados en el DW. Estas acciones se llevan a cabo, debido a que pueden existir diferentes fuentes de información, y es vital conciliar un formato y forma única, definiendo estándares, para que todos los datos que ingresarán al DW estén integrados.

Los casos más comunes en los que se deberá realizar integración, son los siguientes:

• Codificación.
• Medida de atributos.
• Convenciones de nombramiento.
• Fuentes múltiples.

Además de lo antes mencionado, esta función se encarga de realizar, entre otros, los procesos de Limpieza de Datos (Data Cleansing) y Calidad de Datos.

3.3.2.1. Codificación

Una inconsistencia muy típica que se encuentra al intentar integrar varias fuentes de datos, es la de contar con más de una forma de codificar un atributo en común. Por ejemplo, en el campo “estado”, algun@s diseñador@s completan su valor con “0” y “1”, otros con “Apagado” y “Encendido”, otros con “off” y “on”, etc. Lo que se debe realizar en estos casos, es seleccionar o recodificar estos atributos, para que cuando la información llegue al DW, esté integrada de manera uniforme.

En la siguiente figura, se puede apreciar que de varias formas de codificar se escoge una, entonces cuando surge una codificación diferente a la seleccionada, se procede a su transformación.

---

Figura 3.4:  Transformación: codificación.

---

3.3.2.2. Medida de atributos

Los tipos de unidades de medidas utilizados para representar los atributos de una entidad, varían considerablemente entre sí, a través de los diferentes OLTP. Por ejemplo, al registrar la longitud de un producto determinado, de acuerdo a la aplicación que se emplee para tal fin, las unidades de medidas pueden ser explicitadas en centímetros, metros, pulgadas, etc.

En esta ocasión, se deberán estandarizar las unidades de medidas de los atributos, para que todas las fuentes de datos expresen sus valores de igual manera. Los algoritmos que resuelven estas inconsistencias son generalmente los más complejos.

---

Figura 3.5:   Transformación: medida de atributos.

---

3.3.2.3. Convenciones de nombramiento

Usualmente, un mismo atributo es nombrado de diversas maneras en los diferentes OLTP. Por ejemplo, al referirse al nombre del proveedor, puede hacerse como “nombre”, “razón_social”, “proveedor”, etc. Aquí, se debe utilizar la convención de nombramiento que para l@s usuari@s sea más comprensible.

---

Figura 3.6:   Transformación: convenciones de nombramiento.

---

3.3.2.4. Fuentes múltiples

Un mismo elemento puede derivarse desde varias fuentes. En este caso, se debe elegir aquella fuente que se considere más fiable y apropiada.

---

Figura 3.7:   Transformación: fuentes múltiples.

---

3.3.2.5. Limpieza de datos

Su objetivo principal es el de realizar distintos tipos de acciones contra el mayor número de datos erróneos, inconsistentes e irrelevantes.

• Las acciones más típicas que se pueden llevar a cabo al encontrarse con Datos Anómalos (Outliers) son:
  • Ignorarlos.
  • Eliminar la columna.
  • Filtrar la columna.
  • Filtrar la fila errónea, ya que a veces su origen, se debe a casos especiales.
  • Reemplazar el valor.
  • Discretizar los valores de las columnas. Por ejemplo de 1 a 2, poner “bajo”; de 3 a 7, “óptimo”; de 8 a 10, “alto”. Para que los outliers caigan en “bajo” o en “alto” sin mayores problemas.
• Las acciones que suelen efectuarse contra Datos Faltantes (Missing Values) son:
  • Ignorarlos.
  • Eliminar la columna.
  • Filtrar la columna.
  • Filtrar la fila errónea, ya que a veces su origen, se debe a casos especiales.
  • Reemplazar el valor.
  • Esperar hasta que los datos faltantes estén disponibles.

Un punto muy importante que se debe tener en cuenta al elegir alguna acción, es el de identificar el por qué de la anomalía, para luego actuar en consecuencia, con el fin de evitar que se repitan, agregándole de esta manera más valor a los datos de la organización. Se puede dar que en algunos casos, los valores faltantes sean inexistentes, ya que por ejemplo, l@s nuev@s asociad@s o client@s, no poseerán consumo medio del último año.

3.3.3. Carga

1) Esta función se encarga, por un lado de realizar las tareas relacionadas con:

• Carga Inicial (Initial Load).
• Actualización o mantenimiento periódico (siempre teniendo en cuenta un intervalo de tiempo predefinido para tal operación).

La carga inicial, se refiere precisamente a la primera carga de datos que se le realizará al DW. Por lo general, esta tarea consume un tiempo bastante considerable, ya que se deben insertar registros que han sido generados aproximadamente, y en casos ideales, durante más de cinco años.

Los mantenimientos periódicos mueven pequeños volúmenes de datos, y su frecuencia está dada en función del gránulo del DW y los requerimientos de l@s usuari@s. El objetivo de esta tarea es añadir al depósito aquellos datos nuevos que se fueron generando desde el último refresco.

Antes de realizar una nueva actualización, es necesario identificar si se han producido cambios en las fuentes originales de los datos recogidos, desde la fecha del último mantenimiento, a fin de no atentar contra la consistencia del DW. Para efectuar esta operación, se pueden realizar las siguientes acciones:

• Cotejar las instancias de los OLTP involucrados.
• Utilizar disparadores en los OLTP.
• Recurrir a Marcas de Tiempo (Time Stamp), en los registros de los OLTP.
• Comparar los datos existentes en los dos ambientes (OLTP y DW).
• Hacer uso de técnicas mixtas.

Si este control consume demasiado tiempo y esfuerzo, o simplemente no puede llevarse a cabo por algún motivo en particular, existe la posibilidad de cargar el DW desde cero, este proceso se denomina Carga Total (Full Load).

Ingresarán al DW, para su carga y/o actualización:

• Aquellos datos que han sido transformados y que residen en el almacenamiento intermedio.
• Aquellos datos de los OLTP que tienen correspondencia directa con el depósito de datos.

Se debe tener en cuenta, que los datos antes de moverse al almacén de datos, deben ser analizados con el propósito de asegurar su calidad, ya que este es un factor clave, que no debe dejarse de lado.

 

2) Por otra parte, el proceso de Carga tiene la tarea de mantener la estructura del DW, y trata temas relacionados con:

• Relaciones muchos a muchos.
• Claves Subrogadas.
• Dimensiones Lentamente Cambiantes.
• Dimensiones Degeneradas.

3.3.4. Proceso ETL

A continuación, se explicará en síntesis el accionar del proceso ETL, y cuál es la relación existente entre sus diversas funciones. En la siguiente figura se puede apreciar mejor lo antes descrito:

---

Figura 3.8:  Proceso ETL.

---

Los pasos que se siguen son:

• Se extraen los datos relevantes desde los OLTP y se depositan en un almacenamiento intermedio.
• Se integran y transforman los datos, para evitar inconsistencias.
• Se cargan los datos desde el almacenamiento intermedio hasta el DW.

3.4 Data Warehouse Manager
  3.4.1 Base de datos multidimensional
  3.4.2 Tablas de Dimensiones
   3.4.2.1 Tabla de Dimensión Tiempo
  3.4.3 Tablas de Hechos
   3.4.3.1 Tablas de hechos agregadas y preagregadas
  3.4.4 Cubo Multidimensional: introducción
   3.4.4.1 Indicadores
   3.4.4.2 Atributos
   3.4.4.3 Jerarquías
   3.4.4.4 a) Relación
   3.4.4.5 b) Granularidad
  3.4.5 Tipos de modelamiento de un DW
   3.4.5.1 Esquema en Estrella
   3.4.5.2 Esquema Copo de Nieve
   3.4.5.3 Esquema Constelación
  3.4.6 OLTP vs DW
  3.4.7 Tipos de implementación de un DW
   3.4.7.1 ROLAP
   3.4.7.2 MOLAP
   3.4.7.3 HOLAP
   3.4.7.4 ROLAP vs MOLAP
  3.4.8 Cubo Multidimensional: produndización 
  3.4.9 Metadatos
   3.4.9.1 Mapping
 

3.4. Data Warehouse Manager

 

Figura 3.9:   Data Warehouse Manager.

---

El DW Manager presenta las siguientes características y funciones principales:

• Se constituye típicamente al combinar un SGBD con software y aplicaciones dedicadas.
• Almacena los datos de forma multidimensional, es decir, a través de tablas de hechos y tablas de dimensiones.
• Gestiona las diferentes estructuras de datos que se construyan o describan sobre el DW, como Cubos Multidimensionales, Business Models, etc.
• Gestiona y mantiene metadatos.

Además, el DW Manager se encarga de:

• Transformar e integrar los datos fuentes y del almacenamiento intermedio en un modelo adecuado para la toma de decisiones.
• Realizar todas las funciones de definición y manipulación del depósito de datos, para poder soportar todos los procesos de gestión del mismo.
• Ejecutar y definir las políticas de particionamiento. El objetivo de realizar esto, es conseguir una mayor eficiencia y performance en las consultas al no tener que manejar todo el grueso de los datos. Esta política debe aplicarse sobre la tabla de hechos que, como se explicará más adelante, es en la que se almacena toda la información que será analizada.
• Realizar copias de resguardo incrementales o totales de los datos del DW.

3.4.1. Base de datos multidimensional

Una base de datos multidimensional es una base de datos en donde su información se almacena en forma multidimensional, es decir, a través de tablas de hechos y tablas de dimensiones.

Proveen una estructura que permite, a través de la creación y consulta a una estructura de datos determinada (cubo multidimensional, Business Model, etc), tener acceso flexible a los datos, para explorar y analizar sus relaciones, y consiguientes resultados.

Las bases de datos multidimensionales implican tres variantes posibles de modelamiento, que permiten realizar consultas de soporte de decisión:

• Esquema en Estrella (Star Scheme).

• Esquema Copo de Nieve (Snowflake Scheme).

• Esquema Constelación o copo de estrellas (Starflake Scheme).

Los mencionados esquemas pueden ser implementados de diversas maneras, que, independientemente al tipo de arquitectura, requieren que toda la estructura de datos este desnormalizada o semi desnormalizada, para evitar desarrollar uniones (Join) complejas para acceder a la información, con el fin de agilizar la ejecución de consultas. Los diferentes tipos de implementación son los siguientes:

•  Relacional — ROLAP.

•  Multidimensional — MOLAP.

• Híbrido — HOLAP.

3.4.2. Tablas de Dimensiones

Las tablas de dimensiones definen como están los datos organizados lógicamente y proveen el medio para analizar el contexto del negocio. Contienen datos cualitativos.

Representan los aspectos de interés, mediante los cuales l@s usuari@s podrán filtrar y manipular la información almacenada en la tabla de hechos.

En la siguiente figura se pueden apreciar algunos ejemplos:

---

Figura 3.10:   Tablas de Dimensiones.

---

Como se puede observar, cada tabla posee un identificador único y al menos un campo o dato de referencia que describe los criterios de análisis relevantes para la organización, estos son por lo general de tipo texto.

Los datos dentro de estas tablas, que proveen información del negocio o que describen alguna de sus características, son llamados datos de referencia.

Más detalladamente, cada tabla de dimensión podrá contener los siguientes campos:

• Clave principal o identificador único.
• Clave foráneas.
• Datos de referencia primarios: datos que identifican la dimensión. Por ejemplo: nombre del cliente.
• Datos de referencia secundarios: datos que complementan la descripción de la dimensión. Por ejemplo: e-mail del cliente, fax del cliente, etc.

Usualmente la cantidad de tablas de dimensiones, aplicadas a un tema de interés en particular, varían entre tres y quince.

Debe tenerse en cuenta, que no siempre la clave primaria del OLTP, se corresponde con la clave primaria de la tabla de dimensión relacionada. Es recomendable manejar un sistema de claves en el DW (Claves Subrogadas) totalmente diferente al de los OLTP, ya que si estos últimos son recodificados, el almacén quedaría inconsistente y debería ser poblado nuevamente en su totalidad.

3.4.2.1. Tabla de Dimensión Tiempo

En un DW, la creación y el mantenimiento de una tabla de dimensión Tiempo es obligatoria, y la definición de granularidad y estructuración de la misma depende de la dinámica del negocio que se este analizando. Toda la información dentro del depósito, como ya se ha explicado, posee su propio sello de tiempo que determina la ocurrencia de un hecho específico, representando de esta manera diferentes versiones de una misma situación.

Es importante tener en cuenta que la dimensión tiempo no es sola una secuencia cronológica representada de forma numérica, sino que mantiene niveles jerárquicos especiales que inciden notablemente en las actividades de la organización. Esto se debe a que l@s usuari@s podrán por ejemplo analizar las ventas realizadas teniendo en cuenta el día de la semana en que se produjeron, quincena, mes, trimestre, semestre, año, estación, etc.

Existen muchas maneras de diseñar esta tabla, y en adición a ello no es una tarea sencilla de llevar a cabo. Por estas razones se considera una buena práctica evaluar con cuidado la temporalidad de los datos, la forma en que trabaja la organización, los resultados que se esperan obtener del almacén de datos relacionados con una unidad de tiempo y la flexibilidad que se desea obtener de dicha tabla.

Así mismo, si se requiere analizar los datos por Fecha (año, mes, día, etc) y por Hora (hora, minuto, segundo, etc), lo más recomendable es confeccionar dos tablas de dimensión Tiempo; una contendrá los datos referidos a la Fecha y la otra los referidos a la Hora.

Si bien, el lenguaje SQL ofrece funciones del tipo DATE, en la tabla de dimensión Tiempo, se modelan y presentan datos temporales que no pueden calcularse a través de consultas SQL, lo cual le añade una ventaja más.

Es conveniente mantener en la tabla de dimensión Tiempo un campo que se refiera al día Juliano. El día juliano se representa a través de un número secuencial e identifica unívocamente cada día. Mantener este campo permitirá la posibilidad de realizar consultas que involucren condiciones de filtrado de fechas desde-hasta, mayor que, menor que, etc, de manera sencilla e intuitiva; ya que si por ejemplo a partir de tal fecha se desea analizar los datos de los 81 días siguientes, el valor "desde" sería el día Juliano de la fecha en cuestión y el valor "hasta" sería igual a "desde" más 81.

 

3.4.3. Tablas de Hechos

Las tablas de hechos contienen, precisamente, los hechos que serán utilizados por l@s analistas de negocio para apoyar el proceso de toma de decisiones. Contienen datos cuantitativos.

Los hechos son datos instantáneos en el tiempo, que son filtrados, agrupados y explorados a través de condiciones definidas en las tablas de dimensiones.

Los datos presentes en las tablas de hechos constituyen el volumen de la bodega, y pueden estar compuestos por millones de registros dependiendo de su granularidad y antigüedad de la organización. Los más importantes son los de tipo numérico.

El registro del hecho posee una clave primaria que está compuesta por las claves primarias de las tablas de dimensiones relacionadas a este.

En la siguiente imagen se puede apreciar un ejemplo de lo antes mencionado:

---

Figura 3.11:   Tablas de Hechos.

---

Como se muestra en la figura anterior, la tabla de hechos “VENTAS” se ubica en el centro, e irradiando de ella se encuentran las tablas de dimensiones “CLIENTES”, “PRODUCTOS” y “FECHAS”, que están conectadas mediante sus claves primarias. Es por ello que la clave primaria de la tabla de hechos es la combinación de las claves primarias de sus dimensiones. Los hechos en este caso son “ImporteTotal” y “Utilidad”.

A continuación, se entrará más en detalle sobre la definición de un hecho, también llamado dato agregado:

• Los hechos son aquellos datos que residen en una tabla de hechos y que son utilizados para crear indicadores, a través de sumarizaciones preestablecidas al momento de crear un cubo multidimensional, Business Model, etc. Debido a que una tabla de hechos se encuentra interrelacionada con sus respectivas tablas de dimensiones, permite que los hechos puedan ser accedidos, filtrados y explorados por los valores de los campos de estas tablas de dimensiones, obteniendo de este modo una gran capacidad analítica.

Las sumarizaciones no están referidas solo a sumas, sino también a promedios, mínimos, máximos, totales por sector, porcentajes, fórmulas predefinidas, etc, dependiendo de los requerimientos de información del negocio.

Para ejemplificar este nuevo concepto de hechos, se enumerarán algunos que son muy típicos y fáciles de comprender:

• ImporteTotal = precioProducto * cantidadVendida
• Rentabilidad = utilidad / PN
• CantidadVentas = cantidad
• PromedioGeneral = AVG(notasFinales)

A la izquierda de la igualdad se encuentran los hechos; a la derecha los campos de los OLTP que son utilizados para representarlos. En el último ejemplo se realiza un precálculo para establecer el hecho.

Existen dos tipos de hechos, los básicos y los derivados, a continuación se detallará cada uno de ellos, teniendo en cuenta para su ejemplificación la siguiente tabla de hechos:

 

Figura 3.12:   Hechos básicos y derivados.

---

• Hechos básicos: son los que se encuentran representados por un campo de una tabla de hechos. Los campos ”precio” y ”cantidad” de la tabla anterior son hechos básicos.
• Hechos derivados: son los que se forman al combinar uno o más hechos con alguna operación matemática o lógica y que también residen en una tabla de hechos. Estos poseen la ventaja de almacenarse previamente calculados, por lo cual pueden ser accedidos a través de consultas SQL sencillas y devolver resultados rápidamente, pero requieren más espacio físico en el DW, además de necesitar más tiempo de proceso en los ETL que los calculan. El campo ”total” de la tabla anterior en un hecho derivado, ya que se conforma de la siguiente manera:
  • total = precio * cantidad

Los campos ”precio” y ”cantidad”, también pertenecen a la tabla ”HECHOS”. Cabe resaltar, que no es necesario que los hechos derivados se compongan únicamente con hechos pertenecientes a una misma tabla.

Los hechos son gestionados con el principal objetivo de que se construyan indicadores basados en ellos, a través de la creación de un cubo multidimensional, Business Model, u otra estructura de datos.

 

3.4.3.1. Tablas de hechos agregadas y preagregadas

Las tablas de hechos agregadas y preagregadas se utilizan para almacenar un resumen de los datos, es decir, se guardan los datos en niveles de granularidad superior a los que inicialmente fueron obtenidos y/o gestionados.

Para obtener tablas agregadas o preagregadas, es necesario establecer un criterio por el cual realizar el resumen. Por ejemplo, esto ocurre cuando se desea obtener información de ventas sumarizadas por mes.

Cada vez que se requiere que los datos en una consulta se presenten en un nivel de granularidad superior al que se encuentran alojados en el Data Warehouse, se debe llevar a cabo un proceso de agregación.

El objetivo general de las tablas de hechos agregadas y preagregadas es similar, pero cada una de ellas tiene una manera de operar diferente:

• Tablas de hechos agregadas: se generan luego de que se procesa la consulta correspondiente a la tabla de hechos que se resumirá. En general, la agregación se produce dinámicamente a través de una instrucción SQL que incluya sumarizaciones.
• Tablas de hechos preagregadas: se generan antes de que se procese la consulta correspondiente a la tabla de hechos que se resumirá. De esta manera, la consulta se realiza contra una tabla que ya fue previamente sumarizada. Habitualmente, estas sumarizaciones se calculan a través de procesos ETL.

Las tablas de hechos preagregadas cuentan con los siguientes beneficios:

• Reduce la utilización de recursos de hardware que normalmente son incurridos en el cálculo de las sumarizaciones.
• Reduce el número de registros que serán analizados por l@s usuari@s.
• Reduce el tiempo utilizado en la generación de consultas por parte de l@s usuari@s.

Las tablas de hechos preagregadas son muy útiles en los siguientes casos generales:

• Cuando los datos a nivel detalle (menor nivel granular) son innecesarios y/o no son requeridos.
• Cuando una consulta sumarizada a determinado nivel de granularidad es solicitado con mucha frecuencia.
• Cuando los datos son muy abundantes, y las consultas demoran en ser procesadas demasiado tiempo.

Como contrapartida, las tablas de hechos preagregadas presentan una serie de desventajas:

• Requieren que se mantengan y gestionen nuevos procesos ETL.
• Demandan espacio de almacenamiento extra en el depósito de datos.

 

3.4.4. Cubo Multidimensional: introducción

Si bien existen diversas estructuras de datos, a través de las cuales se puede representar los datos del DW, solamente se entrará en detalle acerca de los cubos multidimensionales, por considerarse que esta estructura de datos es una de las más utilizadas y cuyo funcionamiento es el más complejo de entender.

Un cubo multidimensional o hipercubo, representa o convierte los datos planos que se encuentran en filas y columnas, en una matriz de N dimensiones.

Los objetos más importantes que se pueden incluir en un cubo multidimensional, son los siguientes:

• Indicadores: sumarizaciones que se efectúan sobre algún hecho o expresiones basadas en sumarizaciones, pertenecientes a una tabla de hechos.
• Atributos: campos o criterios de análisis, pertenecientes a tablas de dimensiones.
• Jerarquías: representa una relación lógica entre dos o más atributos.

De esta manera en un cubo multidimensional, los atributos existen a lo largo de varios ejes o dimensiones, y la intersección de las mismas representa el valor que tomará el indicador que se está evaluando.

En la siguiente representación matricial se puede ver más claramente lo que se acaba de decir:

 

---

Figura 3.13:   Cubo multidimensional.

---

Para la creación del cubo de la figura anterior, se definieron tres Atributos (“Atributo 1”, “Atributo 2” y “Atributo 3”) y se definió un Indicador (“Indicador 1”). Entonces el cubo quedo compuesto por 3 dimensiones o ejes (una por cada Atributo), cada una con sus respectivos valores asociados. También, se ha seleccionado una intersección al azar para demostrar la correspondencia con los valores de las Atributos. En este caso, el indicador “Indicador 1”, representa el cruce del Valor “5” de “Atributo 1”, con el Valor “4” de “Atributo 2” y con el Valor “3” de “Atributo 3”.

Se puede observar, que el resultado del análisis está dado por los cruces matriciales de acuerdo a los valores de las dimensiones seleccionadas.

Más específicamente, para acceder a los datos del DW, se pueden ejecutar consultas sobre algún cubo multidimensional previamente definido. Dicho cubo debe incluir entre otros objetos: indicadores, atributos, jerarquías, etc, basados en los campos de las tablas de dimensiones y de hechos, que se deseen analizar. De esta manera, las consultas son respondidas con gran performance, minimizando al máximo el tiempo que se hubiese incurrido en realizar dicha consulta sobre una base de datos transaccional.

3.4.4.1. Indicadores

Los indicadores son sumarizaciones efectuadas sobre algún hecho o expresiones basadas en sumarizaciones, que serán incluidos en algún cubo multidimensional, con el fin de analizar los datos almacenados en el DW. El valor que estos adopten estará condicionado por los atributos/jerarquías que se utilicen para analizarlos.

Los indicadores, además de hechos, pueden estar compuestos por otros indicadores, pero no ambos simultáneamente. Pueden utilizarse para su creación funciones de sumarización (suma, conteo, promedio, etc), funciones matemáticas, estadísticas, operadores matemáticos y lógicos.

3.4.4.2. Atributos

Los atributos constituyen los criterios de análisis que se utilizarán para analizar los indicadores dentro de un cubo multidimensional. Los mismos se basan, en su gran mayoría, en los campos de las tablas de dimensiones y/o expresiones.

Dentro de un cubo multidimensional, los atributos son los ejes del mismo.

3.4.4.3. Jerarquías

Una jerarquía representa una relación lógica entre dos o más atributos pertenecientes a un cubo multidimensional; siempre y cuando posean su correspondiente relación “padre-hijo”.

Las jerarquías poseen las siguientes características:

• Pueden existir varias en un mismo cubo.

• Están compuestas por dos o más niveles.

• Se tiene una relación “1-n” o “padre-hijo” entre atributos consecutivos de un nivel superior y uno inferior.

Por lo general, las jerarquías pueden identificarse fácilmente, debido a que existen relaciones “1-n” o “padre-hijo” entre los propios atributos de un cubo.

La principal ventaja de manejar jerarquías, reside en poder analizar los datos desde su nivel más general al más detallado y viceversa, al desplazarse por los diferentes niveles.

La siguiente figura muestra un pequeño ejemplo de lo recién expuesto:

---

Figura 3.14:   Jerarquía Fechas.

---

Aquí, se puede apreciar claramente como se construye una jerarquía:

1. Se crearon dos atributos, ”FECHA - Año” y ”FECHA - Mes”, los cuales están constituidos de la siguiente manera:

   • ”FECHA - Año” = FECHA.Año

   • ”FECHA - Mes” = FECHA.Mes

   A la izquierda de la igualdad se encuentra el nombre del atributo; a la derecha el nombre del campo de la tabla de dimensión “FECHA”.

2. Se creó la jerarquía llamada ”Jerarquía Fechas”, en la cual se colocó el atributo más general en la cabecera y se comenzó a disgregar los niveles hacia abajo. En este caso, la figura se explica como sigue:

   • Un mes del año pertenece solo a un año. Un año puede poseer uno o más meses del año.

3.4.4.4. a) Relación

Una relación representa la forma en que dos atributos interactúan dentro de una jerarquía. Existen básicamente dos tipos de relaciones:

• Explícitas: son las más comunes y se pueden modelar a partir de atributos directos y están en línea continua de una jerarquía, por ejemplo, un país posee una o más provincias y una provincia pertenece solo a un país.

• Implícitas: son las que ocurren en la vida real, pero su relación no es de vista directa, por ejemplo, una provincia tiene uno o más ríos, pero un río pertenece a una o más provincias. Como se puede observar, este caso se trata de una relación muchos a muchos.

3.4.4.5. b) Granularidad

La granularidad representa el nivel de detalle al que se desea almacenar la información sobre el negocio que se esté analizando. Por ejemplo, los datos referentes a ventas o compras realizadas por una empresa, pueden registrarse día a día, en cambio, los datos pertinentes a pagos de sueldos o cuotas de socios, podrán almacenarse a nivel de mes.

Mientras mayor sea el nivel de detalle de los datos, se tendrán mayores posibilidades analíticas, ya que los mismos podrán ser resumidos o sumarizados. Es decir, los datos que posean granularidad fina (nivel de detalle) podrán ser resumidos hasta obtener una granularidad media o gruesa. No sucede lo mismo en sentido contrario, ya que por ejemplo, los datos almacenados con granularidad media podrán resumirse, pero no tendrán la facultad de ser analizados a nivel de detalle. O sea, si la granularidad con que se guardan los registros es a nivel de día, estos datos podrán sumarizarse por semana, mes, semestre y año, en cambio, si estos registros se almacenan a nivel de mes, podrán sumarizarse por semestre y año, pero no lo podrán hacer por día y semana.

 

3.4.5. Tipos de modelamiento de un DW

3.4.5.1. Esquema en Estrella

El esquema en estrella, consta de una tabla de hechos central y de varias tablas de dimensiones relacionadas a esta, a través de sus respectivas claves. En la siguiente figura se puede apreciar un esquema en estrella estándar:

---

Figura 3.15:   Esquema en Estrella.

---

 

El modelo ejemplificado cuando se abordo el tema de las tablas de hechos, es un esquema en estrella, por lo cual se lo volverá a mencionar para explicar sus cualidades.

---

Figura 3.16:  Esquema en Estrella, ejemplo.

---

 

Este modelo debe estar totalmente desnormalizado, es decir que no puede presentarse en tercera forma normal (3ra FN), es por ello que por ejemplo, la tabla de dimensión “PRODUCTOS” contiene los campos “Rubro”, “Tipo” y “NombreProducto”. Si se normaliza esta tabla, se obtendrá el siguiente resultado:

---

Figura 3.17:   Desnormalización.

---

Cuando se normaliza, se pretende eliminar la redundancia, la repetición de datos y que las claves sean independientes de las columnas, pero en este tipo de modelos se requiere no evitar precisamente esto.

Las ventajas que trae aparejada la desnormalización, son las de obviar uniones (Join) entre las tablas cuando se realizan consultas, procurando así un mejor tiempo de respuesta y una mayor sencillez con respecto a su utilización. El punto en contra, es que se genera un cierto grado de redundancia, pero el ahorro de espacio no es significativo.

El esquema en estrella es el más simple de interpretar y optimiza los tiempos de respuesta ante las consultas de l@s usuari@s. Este modelo es soportado por casi todas las herramientas de consulta y análisis, y los metadatos son fáciles de documentar y mantener, sin embargo es el menos robusto para la carga y es el más lento de construir.

A continuación se destacarán algunas características de este modelo, que ayudarán a comprender mejor el por qué de sus ventajas:

• Posee los mejores tiempos de respuesta.
• Su diseño es fácilmente modificable.
• Existe paralelismo entre su diseño y la forma en que l@s usuari@s visualizan y manipulan los datos.
• Simplifica el análisis.
• Facilita la interacción con herramientas de consulta y análisis.

3.4.5.2. Esquema Copo de Nieve

Este esquema representa una extensión del modelo en estrella cuando las tablas de dimensiones se organizan en jerarquías de dimensiones.

---

Figura 3.18:   Esquema Copo de Nieve.

---

Como se puede apreciar en la figura anterior, existe una tabla de hechos central que está relacionada con una o más tablas de dimensiones, quienes a su vez pueden estar relacionadas o no con una o más tablas de dimensiones.

Este modelo es más cercano a un modelo de entidad relación, que al modelo en estrella, debido a que sus tablas de dimensiones están normalizadas.

Una de los motivos principales de utilizar este tipo de modelo, es la posibilidad de segregar los datos de las tablas de dimensiones y proveer un esquema que sustente los requerimientos de diseño. Otra razón es que es muy flexible y puede implementarse después de que se haya desarrollado un esquema en estrella.

Se pueden definir las siguientes características de este tipo de modelo:

• Posee mayor complejidad en su estructura.

• Hace una mejor utilización del espacio.

• Es muy útil en tablas de dimensiones de muchas tuplas.

• Las tablas de dimensiones están normalizadas, por lo que requiere menos esfuerzo de diseño.

• Puede desarrollar clases de jerarquías fuera de las tablas de dimensiones, que permiten realizar análisis de lo general a lo detallado y viceversa.

A pesar de todas las características y ventajas que trae aparejada la implementación del esquema copo de nieve, existen dos grandes inconvenientes de ello:

• Si se poseen múltiples tablas de dimensiones, cada una de ellas con varias jerarquías, se creará un número de tablas bastante considerable, que pueden llegar al punto de ser inmanejables.

• Al existir muchas uniones y relaciones entre tablas, el desempeño puede verse reducido.

Las existencia de las diferentes jerarquías de dimensiones debe estar bien fundamentada, ya que de otro modo las consultas demorarán más tiempo en devolver los resultados, debido a que se deben realizar las uniones entre las tablas.

3.4.5.3. Esquema Constelación

Este modelo está compuesto por una serie de esquemas en estrella, y tal como se puede apreciar en la siguiente figura, está formado por una tabla de hechos principal (“HECHOS_A”) y por una o más tablas de hechos auxiliares (“HECHOS_B”), las cuales pueden ser sumarizaciones de la principal. Dichas tablas yacen en el centro del modelo y están relacionadas con sus respectivas tablas de dimensiones.

No es necesario que las diferentes tablas de hechos compartan las mismas tablas de dimensiones, ya que, las tablas de hechos auxiliares pueden vincularse con solo algunas de las tablas de dimensiones asignadas a la tabla de hechos principal, y también pueden hacerlo con nuevas tablas de dimensiones.

---

Figura 3.19:   Esquema Constelación.

---

Su diseño y cualidades son muy similares a las del esquema en estrella, pero posee una serie de diferencias con el mismo, que son precisamente las que lo destacan y caracterizan. Entre ellas se pueden mencionar:

• Permite tener más de una tabla de hechos, por lo cual se podrán analizar más aspectos claves del negocio con un mínimo esfuerzo adicional de diseño.

• Contribuye a la reutilización de las tablas de dimensiones, ya que una misma tabla de dimensión puede utilizarse para varias tablas de hechos.

• No es soportado por todas las herramientas de consulta y análisis.
   

3.4.6. OLTP vs DW

Debido a que, ya se han explicado y caracterizado los distintos tipos de esquemas del DW, se procederá a exponer las razones de su utilización, como así también las causas de por qué no se emplean simplemente las estructuras de las bases de datos tradicionales:

• Los OLTP son diseñados para soportar el procesamiento de información diaria de las empresas, y el énfasis recae en maximizar la capacidad transaccional de sus datos. Su estructura es altamente normalizada, para brindar mayor eficiencia a sistemas con muchas transacciones que acceden a un pequeño número de registros y están fuertemente condicionadas por los procesos operacionales que deben soportar, para la óptima actualización de sus datos. Esta estructura es ideal para llevar a cabo el proceso transaccional diario, brindar consultas sobre los datos cargados y tomar decisiones diarias, en cambio los esquemas de DW están diseñados para poder llevar a cabo procesos de consulta y análisis para luego tomar decisiones estratégicas y tácticas de alto nivel.

A continuación se presentará una tabla comparativa entre los dos ambientes, que resume sus principales diferencias:

---

Figura 3.20:   OLTP vs Data Warehouse.

---

3.4.7. Tipos de implementación de un DW

3.4.7.1. ROLAP

Este tipo de organización física se implementa sobre tecnología relacional, pero disponen de algunas facilidades para mejorar el rendimiento.

Es decir, ROLAP (Relational On Line Analytic Processing) cuenta con todos los beneficios de una SGBD Relacional a los cuales se les provee extensiones y herramientas para poder utilizarlo como un Sistema Gestor de DW.

En los sistemas ROLAP, los cubos multidimensionales se generan dinámicamente al instante de realizar las diferentes consultas, haciendo de esta manera el manejo de cubos transparente l@s usuari@s. Este proceso se puede resumir a través de los siguientes pasos:

1. Se seleccionan los indicadores, atributos, jerarquías, etc, que compondrán el cubo multidimensional.
2. Se ejecutan las consultas sobre los atributos, indicadores, etc, seleccionados en el paso anterior. Entonces, de manera transparente a l@s usuari@s se crea y calcula dinámicamente el cubo correspondiente, el cual dará respuesta a las consultas que se ejecuten.

Al no tener que intervenir l@s usuari@s en la creación y el mantenimiento explícito de los cubos, ROLAP brinda mucha flexibilidad, ya que dichos cubos son generados dinámicamente al momento de ejecutar las consultas. Posibilitando de esta manera la obtención de consultas ad hoc.

La principal desventaja de los sistemas ROLAP, es que los datos de los cubos se deben calcular cada vez que se ejecuta una consulta sobre ellos. Esto provoca que ROLAP no sea muy eficiente en cuanto a la rapidez de respuesta ante las consultas de l@s usuari@s.

Para incrementar la velocidad de respuesta, en algunos casos se puede optar por almacenar los resultados obtenidos de ciertas consultas en la memoria caché (ya sea en el servidor o en una terminal), para que en un futuro, cuando se desee volver a ejecutar dicha consulta, los valores sean obtenidos más velozmente.

Cabe aclarar que si los datos del DW son almacenados y gestionados a través de un SGBD Relacional, no se requiere de otro software que administre y gestione los datos de manera Multidimensional.

Entre las características más importantes de ROLAP, se encuentran las siguientes:

• Almacena la información en una base de datos relacional.

• Utiliza índices de mapas de bits.

• Utiliza índices de Join.

• Posee optimizadores de consultas.

• Cuenta con extensiones de SQL (drill-up, drill-down, etc).

Como se aclaró anteriormente, el almacén de datos se organiza a través de una base de datos multidimensional, sin embargo, puede ser soportado por un SGBD Relacional. Para lograr esto se utilizan los diferentes esquemas, en estrella, copo de nieve y constelación, los cuales transformarán el modelo multidimensional y permitirán que pueda ser gestionado por un SGDB Relacional, ya que solo se almacenarán tablas.

3.4.7.2. MOLAP

El objetivo de los sistemas MOLAP (Multidimentional On Line Analytic Processing) es almacenar físicamente los datos en estructuras multidimensionales de manera que la representación externa y la interna coincidan.

Para ello, se dispone de estructuras de almacenamiento específicas (Arrays) y técnicas de compactación de datos que favorecen el rendimiento del DW.

MOLAP requiere que en una instancia previa se generen y calculen los cubos multidimensionales, para que luego puedan ser consultados. Este proceso se puede resumir a través de los siguientes pasos:

1. Se seleccionan los indicadores, atributos, jerarquías, etc., que compondrán el cubo multidimensional.

2. Se precalculan los datos del cubo.

3. Se ejecutan las consultas sobre los datos precalculados del cubo.

El principal motivo de precalcular los datos de los cubos, es que posibilita que las consultas sean respondidas con mucha rapidez, ya que los mismos no deben ser calculados en tiempo de ejecución, obteniendo de esta manera una muy buena performance.

Existen una serie de desventajas que están directamente relacionadas con la ventaja de precalcular los datos de los cubos multidimensionales, ellas son:

• Cada vez que se requiere o es necesario realizar cambios sobre algún cubo, se debe tener que recalcularlo totalmente, para que se reflejen las modificaciones llevadas a cabo. Provocando de esta manera una disminución importante en cuanto a flexibilidad.

• Se precisa más espacio físico para almacenar dichos datos (esta desventaja no es tan significativa).

Habitualmente, los datos del DW son almacenados y gestionados a través de SGBD Relacionales, ya que estos tienen la ventaja de poder realizar consultas directamente a través del lenguaje SQL. En estos casos, para la generación de los cubos multidimensionales se requiere de otro software que administre y gestione los datos de manera Multidimensional.

3.4.7.3. HOLAP

HOLAP (Hybrid On Line Analytic Processing) constituye un sistema híbrido entre MOLAP y ROLAP, que combina estas dos implementaciones para almacenar algunos datos en un motor relacional y otros en una base de datos multidimensional.

Los datos agregados y precalculados se almacenan en estructuras multidimensionales y los de menor nivel de detalle en estructuras relacionales. Es decir, se utilizará ROLAP para navegar y explorar los datos, y se empleará MOLAP para la realización de tableros.

Como contrapartida, hay que realizar un buen análisis para identificar los diferentes tipos de datos.

3.4.7.4. ROLAP vs MOLAP

En la siguiente tabla comparativa se pueden apreciar las principales diferencias entre estos dos tipos de implementación:

---

Figura 3.21:   ROLAP vs MOLAP.

---

3.4.8. Cubo Multidimensional: profundización

Ahora que ya se tiene una visión general de los tipos de modelamiento e implementación de un DW, se volverá a abordar el tema de los cubos multidimensionales, pero esta vez se hará énfasis en su construcción y se ejemplificará cada paso, a fin de que se puedan visualizar mejor los resultados de cada acción. 

La forma que se utilizará para graficar el cubo que se creará, será la siguiente:

---

Figura 3.22:   Cubo estándar.

---

Tal y como podemos observar, el gráfico toma una estructura de árbol, en la cuál en la raíz figura el cubo en cuestión y dependiendo de este sus diferentes objetos relacionados. En el caso de las jerarquías, los atributos que la componen, también deben estructurarse en forma de árbol, teniendo en cuenta su respectiva relación padre-hijo.

Se tomará como base para la realización de los ejemplos, el siguiente esquema en estrella:

---

Figura 3.23:   Esquema en Estrella.

---

Como primer paso se creará un cubo multidimensional llamado ”Cubo de Ventas”, gráficamente:

---

Figura 3.24:   Cubo multidimensional, paso 1.

---

Luego se crearán dos atributos:

• De la tabla de dimensión “PRODUCTOS”, se tomará el campo “Producto” para la creación del atributo denominado:

  • “PRODUCTOS - Producto”.

• De la tabla dimensión “MARCAS”, se tomará el campo “Marca” para la creación del atributo denominado:

  • “MARCAS - Marca”.

Gráficamente:

---

Figura 3.25:   Cubo multidimensional, paso 2.

---

También se creará un indicador:

• De la tabla de hechos “VENTAS”, se sumarizará el hecho “Venta” para crear el indicador denominado:

  • “VENTAS - Venta”.

  La fórmula utilizada para crear este indicador es la siguiente:

  • “VENTAS - Venta” = SUM(VENTAS.Venta).

Gráficamente:

---

Figura 3.26:   Cubo multidimensional, paso 3.

---

En este momento, tenemos un cubo multidimensional de dos dimensiones, cuya representación matricial sería la siguiente:

---

Figura 3.27:   Cubo multidimensional de dos dimensiones.

---

Este cubo posee dos ejes o dimensiones, “PRODUCTOS - Producto” y “MARCAS - Marca”. La intersección de los ejes representa las ventas de cada producto con su respectiva marca (indicador “VENTAS - Venta”).

Por ejemplo:

• Las ventas asociadas al producto “P1” y a la marca “M1” son 40.

• Las ventas asociadas al producto “P1” y a la marca “M2” son 25.

• Las ventas asociadas al producto “P1” y a la marca “M3” son 60.

Ahora, al cubo planteado se le agregará un nuevo atributo:

• De la tabla de dimensión “CLIENTES”, se tomará el campo “Cliente” para la creación del atributo denominado:

  • “CLIENTES - Cliente”.

Gráficamente:

---

Figura 3.28:   Cubo multidimensional, paso 4.

---

De esta manera, ahora tenemos un cubo multidimensional de tres dimensiones, cuya representación matricial sería la siguiente:

---

Figura 3.29:   Cubo multidimensional de tres dimensiones.

---

En este caso los valores del indicador “VENTAS - Venta” están dados de acuerdo a las ventas de cada producto, de cada marca, a cada cliente.

Para finalizar, se añadirá un cuarto atributo al cubo:

• De la tabla de dimensión “TIEMPO”, se tomará el campo “Año” para la creación del atributo denominado:

  • “TIEMPO - Año”.

Gráficamente:

---

Figura 3.30:   Cubo multidimensional, paso 5.

---

 

Entonces, la representación matricial del cubo multidimensional resultante sería la siguiente:

---

Figura 3.31:   Cubo multidimensional de cuatro dimensiones.

---

Los valores del indicador “VENTAS - Venta” en este momento, estarán condicionados por las ventas de cada producto, de cada marca, a cada cliente, en cada año.

Esta última imagen, demuestra claramente los conceptos expuestos de la tabla de dimensión tiempo, donde se decía que pueden existir diferentes versiones de la situación del negocio.

Cabe aclarar que pueden crearse tantos cubos se deseen y que los mismos pueden coexistir sin ningún inconveniente.

 

3.4.9. Metadatos

Los metadatos son datos que describen o dan información de otros datos, que en este caso, existen en la arquitectura del Data Warehousing. Brindan información de localización, estructura y significado de los datos, básicamente mapean los mismos.

El concepto de metadatos es análogo al uso de índices para localizar objetos en lugar de datos.

Es importante aclarar que existen metadatos también en las bases de datos transaccionales, pero los mismos son transparentes a l@s usuari@s. La gran ventaja que trae aparejada el Data Warehousing en relación con los metadatos es que l@s usuari@s pueden gestionarlos, exportarlos, importarlos, realizarles mantenimiento e interactuar con ellos, ya sea manual o automáticamente.

Las funciones que cumplen los metadatos en el ambiente Data Warehousing son muy importantes y significativas, algunas de ellas son:

• Facilitan el flujo de trabajo, convirtiendo datos automáticamente de un formato a otro.

• Contienen un directorio para facilitar la búsqueda y descripción de los contenidos del DW, tales como: bases de datos, tablas, nombres de atributos, sumarizaciones, acumulaciones, reglas de negocios, estructuras y modelos de datos, relaciones de integridad, jerarquías, etc.

• Poseen un guía para el mapping, de cómo se transforman e integran los datos de las fuentes operacionales y externos al ambiente del depósito de datos.

• Almacenan las referencias de los algoritmos utilizados para la esquematización entre el detalle de datos actuales, con los datos ligeramente resumidos y éstos con los datos altamente resumidos, etc.

• Contienen las definiciones del sistema de registro desde el cual se construye el DW.

Se pueden distinguir tres diferentes tipos de Metadatos:

• Los metadatos de los procesos ETL, referidos a las diversas fuentes utilizadas, reglas de extracción, transformación, limpieza, depuración y carga de los datos al depósito.

• Los metadatos operacionales, que son los que básicamente almacenan todos los contenidos del DW, para que este pueda desempeñar sus tareas.

• Los metadatos de consulta, que contienen las reglas para analizar y explotar la información del almacén, tales como drill-up y drill-down. Son estos metadatos los que las herramientas de análisis y consulta emplearán para realizar documentaciones y para navegar por los datos.

3.4.9.1. Mapping

El término mapping, se refiere a relacionar un conjunto de objetos, tal como actualmente están almacenados en memoria o en disco, con otros objetos. Por ejemplo: una estructura de base de datos lógica, se proyecta sobre la base de datos física.

 

3.5 Query Manager
  3.5.1 Drill-down
  3.5.2 Drill-up
  3.5.3 Drill-across
  3.5.4 Roll-across
  3.5.5 Pivot
  3.5.6 Page
  3.5.7 Drill-through

 

3.5. Query Manager

---

Figura 3.32:   Query Manager.

---

Este componente realiza las operaciones necesarias para soportar los procesos de gestión y ejecución de consultas relacionales, tales como Join y agregaciones, y de consultas propias del análisis de datos, como drill-up y drill-down.

Query Manager recibe las consultas de l@s usuari@s, las aplica a la estructura de datos correspondiente (cubo multidimensional, Business Models, etc.) y devuelve los resultados obtenidos.

Cabe aclarar que una consulta a un DW, generalmente consiste en la obtención de indicadores a partir de los datos (hechos) de una tabla de hechos, restringidas por las propiedades o condiciones de los atributos que hayan sido creados.

Las operaciones que se pueden realizar sobre modelos multidimensionales y que son las que verdaderamente les permitirán a l@s usuari@s explorar e investigar los datos en busca de respuestas, son:

• Drill-down.
• Drill-up.
• Drill-across.
• Roll-across.
• Pivot.
• Page.
• Drill-through.

A continuación, se explicará cada una de ellas y se ejemplificará su utilización, para lo cual se utilizará como guía el siguiente esquema en estrella.

---

Figura 3.33:    Esquema en Estrella.

---

El mismo posee cuatro tablas de dimensiones y una tabla de hechos central, en la cual el hecho “Venta” representa las ventas a un cliente, de un producto en particular, de una marca específica en un año dado.

Sobre este modelo, entonces, se creará un cubo llamado “Cubo - Query Manager” que será utilizado para explicar las operaciones del Query Manager. El mismo contiene los siguientes objetos:

• De la tabla de hechos “VENTAS”, se sumarizará el hecho “Venta” para crear el indicador denominado:

  • “VENTAS - Venta”.

  La fórmula utilizada para crear este indicador es la siguiente:

  • “VENTAS - Venta” = SUM(VENTAS.Venta).

• De la tabla de dimensión “MARCAS”, se tomará el campo “Marca” para la creación del atributo denominado:

  • “MARCAS - Marca”.

• De la tabla dimensión “TIEMPO”, se tomará el campo “Año” para la creación del atributo denominado:

  • “TIEMPO - Año”.

• De la tabla dimensión “PRODUCTOS”, se tomará el campo “Producto” para la creación del atributo denominado:

  • “PRODUCTOS - Producto”.

• De la tabla dimensión “PRODUCTOS”, se tomará el campo “Clase” para la creación del atributo denominado:

  • “PRODUCTOS - Clase”.

• Se definió la jerarquía “Jerarquía PRODUCTOS”, que se aplicará sobre los atributos recientemente creados, “PRODUCTOS - Producto” y “PRODUCTOS - Clase”, en donde:

  • Una clase de producto pertenece solo a un producto. Un producto puede ser de una o más clases.

  Gráficamente:

  ---

  Figura 3.34:   ”PRODUCTOS”, relación padre-hijo.

  ---

  Entonces, el cubo quedará conformado de la siguiente manera:

---

Figura 3.35:    ”Cubo - Query Manager”.

---

Para simplificar los ejemplos que se presentarán, se utilizará solo una pequeña muestra de datos correspondientes al año 2007.

 

3.5.1. Drill-down

Permite apreciar los datos en un mayor detalle, bajando por una jerarquía definida en un cubo. Esto brinda la posibilidad de introducir un nuevo nivel o criterio de agregación en el análisis, disgregando los grupos actuales.

Drill-down es ir de lo general a lo específico. Gráficamente:

---

Figura 3.36:   Drill-down.

---

Para explicar esta operación se utilizará la siguiente representación tabular:

---

Figura 3.37:   Resultados antes de aplicar Drill-down.

---

Como puede apreciarse, en la cabecera de la tabla se encuentran los atributos y el indicador (destacado con color de fondo diferente) definidos anteriormente en el cubo multidimensional; y en el cuerpo de la misma se encuentran los valores correspondientes. Se ha resaltado la primera fila, ya que es la que se analizará más en detalle.

En este caso, se realizará drill-down sobre la jerarquía “Jerarquía PRODUCTOS”, entonces:

---

Figura 3.38:   Resultados después de aplicar Drill-down.

---

Tal y como puede apreciarse en los ítems resaltados de la tabla, se agregó un nuevo nivel de detalle (“PRODUCTOS — Clase”) a la lista inicial, y el valor “40” que pertenecía a las ventas del “Producto1”, de la marca “M1”, en el año “2007”, se dividió en dos filas. Esto se debe a que ahora se tendrá en cuenta el atributo “PRODUCTOS - Clase” para realizar las sumarizaciones del indicador “VENTAS - Venta”.

La siguiente imagen muestra este mismo proceso pero, representado matricialmente:

---

Figura 3.39:   Drill-down, representación matricial.

---

De aquí en más se utilizará esta forma para explicar cada operación.

 

3.5.2. Drill-up

Permite apreciar los datos en menor nivel de detalle, subiendo por una jerarquía definida en un cubo. Esto brinda la posibilidad de quitar un nivel o criterio de agregación en el análisis, agregando los grupos actuales.

Drill-up es ir de lo específico a lo general. Gráficamente:

---

Figura 3.40:   Drill-up.

---

Se tomará como referencia los resultados anteriores:

---

Figura 3.41:   Resultados antes de aplicar Drill-up.

---

Se aplicará drill-up sobre la jerarquía “Jerarquía PRODUCTOS”, entonces:

---

Figura 3.42:   Resultados después de aplicar Drill-up.

---

Como se puede observar en la lista resultante, en la fila resaltada se sumarizaron los valores “22” y “18” de la tabla inicial, debido a que al eliminar el atributo “PRODUCTOS - Clase”, las ventas se agruparon o sumarizaron de acuerdo a “PRODUCTOS - Producto”, “MARCAS - Marca” y “TIEMPO - Año”.

La siguiente imagen muestra este mismo proceso pero, representado matricialmente:

---

Figura 3.43:   Drill-up, representación matricial.

---

3.5.3. Drill-across

Funciona de forma similar a drill-down, con la diferencia de que drill-across no se realiza sobre una jerarquía, sino que su forma de ir de lo general a lo específico es agregar un atributo a la consulta como nuevo criterio de análisis.

Se partirá de los siguientes resultados:

---

Figura 3.44:   Resultados antes de aplicar Drill-across.

---

Ahora, se aplicará drill-across, al agregar el atributo “MARCAS - Marca”, entonces:

---

Figura 3.45:   Resultados después de aplicar Drill-across.

---

La siguiente imagen muestra este mismo proceso pero, representado matricialmente:

---

Figura 3.46:   Drill-across, representación matricial.

---

3.5.4. Roll-across

Funciona de forma similar a drill-up, con la diferencia de que roll-across no se hace sobre una jerarquía, sino que su forma de ir de lo específico a lo general es quitar un atributo de la consulta, eliminando de esta manera un criterio de análisis.

Se tomará como base la representación tabular anterior:

---

Figura 3.47:   Resultados antes de aplicar Roll-across.

---

Se aplicará la operación roll-across, quitando de la consulta el atributo “MARCAS - Marca”, entonces:

---

Figura 3.48:   Resultados después de aplicar Roll-across.

---

La siguiente imagen muestra este mismo proceso pero, representado matricialmente:

---

Figura 3.49:   Roll-across, representación matricial.

---

3.5.5. Pivot

Permite seleccionar el orden de visualización de los atributos e indicadores, con el objetivo de analizar la información desde diferentes perspectivas.

Se tomará como referencia, para explicar esta operación, la siguiente tabla:

---

Figura 3.50:   Resultados antes de aplicar Pivot.

---

Como puede apreciarse, el orden de los atributos es: “TIEMPO - Año”, “PRODUCTOS - Producto” y “MARCAS - Marca”. Ahora, se hará pivot, reorientando la vista multidimensional:

---

Figura 3.51:   Resultados después de aplicar Pivot.

---

El nuevo orden de los atributos es: “MARCAS - Marca”, “TIEMPO - Año” y “PRODUCTOS - Producto”.

La siguiente imagen muestra este mismo proceso pero, representado matricialmente:

---

Figura 3.52:   Pivot, representación matricial.

---

Pivot permite realizar las siguientes acciones:

• Mover un atributo o indicador desde el encabezado de fila al encabezado de columna.

• Mover un atributo o indicador desde el encabezado de columna al encabezado de fila.

• Cambiar el orden de los atributos o indicadores del encabezado de columna.

• Cambiar el orden de los atributos o indicadores del encabezado de fila.

3.5.6. Page

Presenta el cubo dividido en secciones, a través de los valores de un atributo, como si se tratase de páginas de un libro. Gráficamente:

---

Figura 3.53:   Page.

---

Page es muy útil cuando las consultas devuelven muchos registros y es necesario desplazarse por los datos para poder verlos en su totalidad.

Se tomará como referencia, para explicar esta operación, la siguiente tabla:

---

Figura 3.54:   Resultados antes de aplicar Page.

---

Se realizará Page sobre el atributo “PRODUCTOS - Producto”, entonces se obtendrán las siguientes páginas:

 

• Página Nro 1:

 

Figura 3.55:    Página Nro 1, representación tabular.

---

Matricialmente:

---

Figura 3.56:   Página Nro 1, representación matricial.

---

• Página Nro 2:

 

Figura 3.57:   Página Nro 2, representación tabular.

---

Matricialmente:

---

Figura 3.58:   Página Nro 2, representación matricial.

---

Cuando existe más de un criterio por el cual realizar Page, debe tenerse en cuenta el orden en que estos serán procesados, ya que dependiendo de esto, de podrán obtener diferentes resultados sobre una misma consulta. Para ejemplificar este concepto se utilizará como base la tabla expuesta al inicio.

Entonces, si se desea realizar Page por “PRODUCTOS - Producto” y “MARCAS - Marca”, se dispondrá de dos opciones de ordenación:

1. Primero por “PRODUCTOS - Producto” y luego por “MARCAS - Marca”: en este caso, si se selecciona la página correspondiente al producto “Producto1”, se obtendrán las siguientes sub-páginas, que se corresponden con los valores de las marcas: “M1”, “M2” y “M3”. Expresado en esquema de árbol jerárquico, quedaría como sigue:

   • Página Nro 1: “Producto1”

   • Sub-página Nro 1.1: “M1”.

     • Sub-página Nro 1.2: “M2”.

     • Sub-página Nro 1.3: “M3”.

   • Página Nro 2: “Producto2”

     • Sub-página Nro 2.1: “M1”.

     • Sub-página Nro 2.2: “M2”.

     • Sub-página Nro 2.3: “M3”.

   Como puede observarse, se obtendrán dos páginas, con tres sub-páginas cada una de ellas.

2. Primero por “MARCAS - Marca” y luego por “PRODUCTOS - Producto”: en este caso, si se selecciona la página correspondiente a la marca “M1”, se obtendrán las siguientes sub-páginas, que se corresponden con los valores de los productos: “Producto1” y “Producto2”. Expresado en esquema de árbol jerárquico, quedaría como sigue:

   • Página Nro 1: “M1”

     • Sub-página Nro 1.1: “Producto1”.

     • Sub-página Nro 1.2: “Producto2”.

   • Página Nro 2: “M2”

     • Sub-página Nro 2.1: “Producto1”.

     • Sub-página Nro 2.2: “Producto2”.

   • Página Nro 3: “M3”

     • Sub-página Nro 3.1: “Producto1”.

     • Sub-página Nro 3.2: “Producto2”.

   Como puede observarse, se obtendrán tres páginas, con dos sub-páginas cada una de ellas.

Es decir, el primer criterio utilizado para realizar Page condiciona los valores disponibles en el segundo, y así sucesivamente.

 

3.5.7. Drill-through

Permite apreciar los datos en su máximo nivel de detalle. Esto brinda la posibilidad de analizar cuáles son los datos relacionados al valor de un Indicador, que se ha sumarizado dentro del cubo multidimensional.

Se tomará como referencia, para explicar esta operación, la siguiente tabla:

---

Figura 3.59:   Resultados antes de aplicar Drill-through.

---

Se aplicará la operación drill-through sobre el Indicador de la fila seleccionada, para obtener el detalle de este valor:

 

---

Figura 3.60:   Resultados después de aplicar Drill-through.

---

 

La siguiente imagen muestra este mismo proceso pero, representado matricialmente:

---

Figura 3.61:   Drill-through, representación matricial.

---

 

3.6 Herramientas de Consulta y Análisis
  3.6.1 Reportes y Consultas
  3.6.2 OLAP
  3.6.3 Dashboards
  3.6.4 Data Mining
   3.6.4.1 Redes Neuronales
   3.6.4.2 Sistemas Expertos
   3.6.4.3 Programación Genética
   3.6.4.4 Árboles de Decisión
   3.6.4.5 Detección de Desviación
  3.6.5 EIS

 

3.6. Herramientas de Consulta y Análisis

 

Figura 3.59:   Herramientas de Consulta y Análisis.

---

Las herramientas de consulta y análisis son sistemas que permiten a l@s usuari@s realizar la exploración de datos del DW. Básicamente constituyen el nexo entre el depósito de datos y l@s usuari@s.

Utilizan la metadata de las estructuras de datos que han sido creadas previamente (cubos multidimensionales, Business Models, etc.) para trasladar a través de consultas SQL los requerimientos de l@s usuari@s, para luego, devolver el resultado obtenido.

Estas herramientas también pueden emplear simples conexiones a bases de datos (JNDI, JDBC, ODBC), para obtener la información deseada.

A través de una interfaz gráfica y una serie de pasos, l@s usuari@s generan consultas que son enviadas desde la herramienta de consulta y análisis al Query Manager, este a su vez realiza la extracción de información al DW Manager y devuelve los resultados obtenidos a la herramienta que se los solicitó. Luego, estos resultados son expuestos ante l@s usuari@s en formatos que le son familiares.

Este proceso se puede comprender mejor al observar la siguiente figura:

---

Figura 3.60:   Proceso de Consulta y Análisis.

---

El mismo, se lleva a cabo a través de seis pasos sucesivos:

1. L@s usuari@s seleccionan o establecen que datos desean obtener del DW, mediante las interfaces de la herramienta que utilice.
2. La herramienta recibe el pedido de l@s usuari@s, construye la consulta (utilizando la metadata) y la envía al Query Manager.
3. El Query Manager ejecuta la consulta sobre la estructura de datos con la que se esté trabajando (cubo multidimensional, Business Model, etc.).
4. El Query Manager obtiene los resultados de la consulta.
5. El Query Manager envía los datos a la herramienta de consulta y análisis.
6. La herramienta presentan a l@s usuari@s la información requerida.

Una de las principales ventajas de utilizar estas herramientas, es que l@s usuari@s no se tienen que preocupar por conocer cuáles son las características y funcionalidades de las estructuras de datos utilizadas, ni por saber emplear el lenguaje SQL, solo se deben enfocar en el análisis.

Las herramientas de consulta y análisis, en general, comparten las siguientes características:

• Accesibilidad a la información: permiten el acceso a la información a través de las diferentes estructuras de datos de forma transparente a l@s usuari@s finales, para que est@s solo se enfoquen en el análisis y no en el origen y procedencia de los datos.
• Apoyo en la toma de decisiones: permiten la exploración de los datos, a fin de seleccionar, filtrar y personalizar los mismos, para la obtención de información oportuna, relevante y útil, para apoyar el proceso de toma de decisiones.
• Orientación l@s usuari@s finales: permiten a través de entornos amigables e intuitivos, que l@s usuari@s puedan realizar análisis y consultas, sin poseer conocimientos técnicos. Si bien lo realmente importante son los datos mismos, que estos puedan ser interpretados y analizados por l@s usuari@s dependerá en gran medida de cómo se presenten y dispongan.

Existen diferentes tipos de herramientas de consulta y análisis, y de acuerdo a la necesidad, tipos de usuari@s y requerimientos de información, se deberán seleccionar las más propicias al caso. Entre ellas se destacan las siguientes:

• Reportes y Consultas.
• OLAP.
• Dashboards.
• Data Mining.
• EIS.

 

3.6.1. Reportes y Consultas

Se han desarrollado muchas herramientas para la producción de consultas y reportes, que ofrecen a l@s usuari@s, a través de pantallas gráficas intuitivas, la posibilidad de generar informes avanzados y detallados del tema de interés de interés que se este analizando. L@s usuari@s solo deben seguir una serie de simples pasos, como por ejemplo seleccionar opciones de un menú, presionar tal o cual botón para especificar los elementos de datos, sus condiciones, criterios de agrupación y demás atributos que se consideren significativos.

Actualmente las herramientas de generación de reportes y consultas cuentan con muchas prestaciones, las cuales permiten dar variadas formas y formatos a la presentación de la información. Entre las opciones más comunes se encuentran las siguientes:

• Parametrización de los datos devueltos.
• Selección de formatos de salida (planilla de cálculo, HTML, PDF, etc.).
• Inclusión de gráficos de tortas, barras, etc.
• Utilización de plantillas de formatos de fondos.
• Inclusión de imágenes.
• Formatos tipográficos.
• Links a otros reportes.

 

3.6.2. OLAP

El procesamiento analítico en línea OLAP (On Line Analytic Processing), es la componente más poderosa del Data Warehousing, ya que es el motor de consultas especializado del depósito de datos.

Las herramientas OLAP, son una tecnología de software para análisis en línea, administración y ejecución de consultas, que permiten inferir información del comportamiento del negocio.

Su principal objetivo es el de brindar rápidas respuestas a complejas preguntas, para interpretar la situación del negocio y tomar decisiones. Cabe destacar que lo que es realmente interesante en OLAP, no es la ejecución de simples consultas tradicionales, sino la posibilidad de utilizar operadores tales como drill-up, drill-down, etc, para explotar profundamente la información.

Además, a través de este tipo de herramientas, se puede analizar el negocio desde diferentes escenarios históricos, y proyectar como se ha venido comportando y evolucionando en un ambiente multidimensional, o sea, mediante la combinación de diferentes perspectivas, temas de interés o dimensiones. Esto permite deducir tendencias, por medio del descubrimiento de relaciones entre las perspectivas que a simple vista no se podrían encontrar sencillamente.

Las herramientas OLAP requieren que los datos estén organizados dentro del depósito en forma multidimensional, por lo cual se utilizan cubos multidimensionales.

Además de las características ya descritas, se pueden enumerar las siguientes:

• Permite recolectar y organizar la información analítica necesaria para l@s usuari@s y disponer de ella en diversos formatos, tales como tablas, gráficos, reportes, tableros de control, etc.
• Soporta análisis complejos de grandes volúmenes de datos.
• Complementa las actividades de otras herramientas que requieran procesamiento analítico en línea.
• Presenta a l@s usuari@s una visión multidimensional de los datos (matricial) para cada tema de interés del negocio.
• Es transparente al tipo de tecnología que soporta el DW, ya sea ROLAP, MOLAP u HOLAP.
• No tiene limitaciones con respecto al número máximo de dimensiones permitidas.
• Permite a l@s usuari@s, analizar la información basándose en más criterios que un análisis de forma tradicional.
• Al contar con muestras grandes, se pueden explorar mejor los datos en busca de respuestas.
• Permiten realizar agregaciones y combinaciones de los datos de maneras complejas y específicas, con el fin de realizar análisis más estratégicos.

 

3.6.3. Dashboards

Los Dashboards se pueden entender como una colección de reportes, consultas y análisis interactivos que hacen referencia a un tema en particular y que están relacionados entre sí.

Existen diversas maneras de diseñar un Dashboard, cada una de las cuales tiene sus objetivos particulares, pero a modo de síntesis se expondrán algunas características generales que suelen poseer:

• Presentan la información altamente resumida.
• Se componen de consultas, reportes, análisis interactivos, gráficos (de torta, barras, etc), semáforos, indicadores causa-efecto, etc.
• Permiten evaluar la situación de la empresa con un solo golpe de vista.
• Poseen un formato de diseño visual muy llamativo.

 

3.6.4. Data Mining

Esta herramienta constituye una poderosa tecnología con un gran potencial que ayuda y brinda soporte a l@s usuari@s, con el fin de permitirles analizar y extraer conocimientos ocultos y predecibles a partir de los datos almacenados en un DW o en un OLTP. Claro que es deseable que la fuente de información sea un DW, por todas las ventajas que aporta.

La integración con el depósito de datos facilita que las decisiones operacionales sean implementadas directamente y monitorizadas.

Implementar Data Mining permitirá analizar factores de influencia en determinados procesos, predecir o estimar variables o comportamientos futuros, segmentar o agrupar ítems similares, además de obtener secuencias de eventos que provocan comportamientos específicos.

Una de las principales ventajas del Data Mining es que, como recién se ha hecho mención, permite inferir comportamientos, modelos, relaciones y estimaciones de los datos, para poder desarrollar predicciones sobre los mismos, sin la necesidad de contar con patrones o reglas preestablecidas, permitiendo tomar decisiones proactivas y basadas en un conocimiento acabado de la información.

Además brinda la posibilidad de dar respuesta a preguntas complicadas sobre los temas de interés, como por ejemplo Qué está pasando?, Por qué? y Qué pasaría sí?, estos cuestionamientos aplicados a una empresa podrían ser: Cuál de los productos de tal marca y clase serán más vendidos en la zona norte en el próximo semestre? y por qué? Además se podrán ver los resultados en forma de reportes tabulares, matriciales, gráficos, tableros, etc.

Entonces, se puede definir Data Mining como una técnica para descubrir patrones y relaciones entre abundantes cantidades de datos, que a simple vista o que mediante otros tipos de análisis no se pueden deducir, ya que tradicionalmente consumiría demasiado tiempo o estaría fuera de las expectativas.

Los sistemas Data Mining se desarrollan bajo lenguajes de última generación basados en Inteligencia Artificial y utilizan métodos matemáticos tales como:

• Redes Neuronales.
• Sistemas Expertos.
• Programación Genética.
• Árboles de Decisión.

Soporta además, sofisticadas operaciones de análisis como los sistemas Scoring, aplicaciones de Detección de Desviación y Detección de Fraude.

Es muy importante tener en cuenta que en las herramientas OLAP y en los reportes y consultas, el análisis parte de una pregunta o hipótesis generada por l@s usuari@s, en cambio Data Mining permite generar estas hipótesis.

Generalmente las herramientas de Data Mining se integran con plataformas de hardware y software existentes (como DW) para incrementar el valor de las fuentes de datos establecidas y para que puedan ser integradas con nuevos productos y sistemas en línea (como OLAP). En adición a esto, hacer minería de datos sobre un depósito de datos permite entre otras ventajas contar con los beneficios de los procesos ETL y de las técnicas de limpieza de datos, tan necesarios en este tipo de análisis.

3.6.4.1. Redes Neuronales

Se utilizan para construir modelos predictivos no lineales que aprenden a través de entrenamiento y que semejan la estructura de una red neuronal biológica.

Una red neuronal es un modelo computacional con un conjunto de propiedades específicas, como la habilidad de adaptarse o aprender, generalizar u organizar la información, todo ello basado en un procesamiento eminentemente paralelo.

Por ejemplo, las redes neuronales pueden emplearse para:

• Resolver problemas en dominios complejos con variables continuas y categóricas.
• Modelizar relaciones no lineales.
• Clasificar y predecir resultados.

3.6.4.2. Sistemas Expertos

Un sistema experto, puede definirse como un sistema informático (hardware y software) que simula a l@s expert@s human@s en un área de especialización dada.

La principal ventaja de estos sistemas es que l@s usuari@s con poca experiencia pueden resolver problemas que requieren el conocimiento de una persona experta en el tema.

Por ejemplo, los sistemas expertos pueden utilizarse para:

• Realizar transacciones bancarias a través de cajeros automáticos.
• Controlar y regular el flujo de tráfico en las calles y en los ferrocarriles, mediante la operación automática de semáforos.
• Resolver complicados problemas de planificación en los cuales intervienen muchas variables.
• Descubrir relaciones entre diversos conjuntos de variables.

3.6.4.3. Programación Genética

El principal objetivo de la programación genética es lograr que las computadoras aprendan a resolver problemas sin ser explícitamente programadas para solucionarlos, generando de esta manera soluciones a partir de la inducción de los programas. El verdadero valor de esta inducción está fundamentado en que todos los problemas se pueden expresar como un programa de computadora.

Por ejemplo, la programación genética se utiliza para:

• Resolver problemas, para los cuales es difícil y no natural tratar de especificar o restringir con anticipación el tamaño y forma de una solución eventual.

• Analizar sistemas que actúan sobre condiciones inestables en ambientes cambiantes.

• Generar de manera automática programas que solucionen problemas planteados.

3.6.4.4. Árboles de Decisión

Son estructuras de forma de árbol que representan conjuntos de decisiones. Estas decisiones generan reglas para la clasificación de un conjunto de datos, las cuales explican el comportamiento de una variable con relación a otras, y pueden traducirse fácilmente en reglas de negocio.

Son utilizados con finalidad predictiva y de clasificación.

Por ejemplo, los árboles de decisión pueden emplearse para:

• Optimizar respuestas de campañas.

• Identificar clientes potenciales.

• Realizar evaluación de riesgos.

3.6.4.5. Detección de Desviación

Analiza una serie de datos similares, y cuando encuentra un elemento que no coincide con el resto lo considera una desviación.

Usualmente para la detección de la desviación en base de datos grandes se utiliza la información explícita externa a los datos, así como las limitaciones de integridad o modelos predefinidos. En un método lineal, al contrario, se enfoca el problema desde el interior de los datos, empleando la redundancia implícita de los mismos.

Por ejemplo, la detección de desviación puede utilizarse para:

• Descubrir excepciones a modelos establecidos.

• Delimitar grupos que cumplan con condiciones preestablecidas.

3.6.5. EIS

EIS (Executive Information System) proporciona medios sencillos para consultar, analizar y acceder a la información de estado del negocio. Además, pone a disposición facilidades para que l@s usuari@s puedan conseguir los datos buscados rápidamente, empleando el menor tiempo posible para comprender el uso de la herramienta.

Usualmente, EIS se utiliza para analizar los indicadores de performance y desempeño del negocio o área de interés, a través de la presentación de vistas con datos simplificados, altamente consolidados, mayormente estáticos y preferentemente gráficos.

El concepto principal de esta herramienta, se basa en el simple hecho de que l@s ejecutiv@s no poseen tiempo, ni las habilidades necesarias para analizar grandes cantidades de datos.

Al igual que OLAP y Data Mining, los EIS, se pueden aplicar independientemente de la plataforma DW. Pero tener como base un depósito de datos para implementar esta herramienta, conlleva todas las ventajas implícitas del mismo.

---

Figura 3.61:   Usuari@s.

---

L@s usuari@s que posee el DW son aquell@s que se encargan de tomar decisiones y de planificar las actividades del negocio, es por ello que se hace tanto énfasis en la integración, limpieza de datos, etc, para poder conseguir que la información posea toda la calidad posible.

Es a través de las herramientas de consulta y análisis, que l@s usuari@s exploran los datos en busca de respuestas para poder tomar decisiones proactivas.

Para comprender mejor a l@s usuari@s del almacén de datos, se hará referencia a las diferencias que estos tienen con respecto a los del OLTP:

• L@s usuari@s que acceden al DW concurrentemente son poc@s, en cambio los que acceden a los OLTP en un tiempo determinado son much@s más, pueden ser cientos o incluso miles. Esto se debe principalmente al tipo de información que contiene cada fuente.
• L@s usuari@s del DW generan por lo general consultas complejas, no predecibles y no anticipadas. Usualmente, cuando se encuentra una respuesta a una consulta se formulan nuevas preguntas más detalladas y así sucesivamente. Es decir, primero se analiza la información a nivel de datos actual para averiguar el “qué”, luego, para obtener mayor detalle y examinar el “cómo”, se trabajan con los datos ligeramente resumidos, derivados de la consulta anterior, y desde allí se puede explorar los datos altamente resumidos. Teniendo en cuenta siempre la posibilidad de utilizar el detalle de datos histórico. Al contrario, l@s usuari@s de los OLTP solo manejan consultas predefinidas.
• L@s usuari@s del DW, generan consultas sobre una gran cantidad de registros, en cambio los del OLTP lo hacen sobre un pequeño grupo. Esto se debe a que como ya se ha mencionado, el depósito contiene información histórica e integra varias fuentes de datos.
• Las consultas de l@s usuari@s del DW no tienen tiempos de respuesta críticos, aunque sí se espera que se produzcan en el mismo día en que fueron realizadas. Mientras mayor sea el tamaño del depósito y mientras más compleja sea la consulta, mayores serán los tiempos de respuestas. En cambio, las respuestas de las consultas en un OLTP son y deben ser inmediatas.
• En los OLTP, l@s usuari@s típicamente realizan actualizaciones, tales como agregar, modificar, eliminar y consultar algún registro. En cambio en un DW, la única operación que pueden realizar es la de consulta.

Las mencionadas diferencias entre estos dos tipos de usuari@s se pueden apreciar mejor en la siguiente tabla comparativa:

---

Usuari@s de OLTP Usuari@s de Data Warehouse Acceso concurrente Much@s. Poc@s. Tipo de consultas Predefinidas. Complejas, no predecibles y no anticipadas. Registros consultados Pocos. Muchos Tiempo de respuesta Crítico. No crítico. Acciones permitidas Agregar, modificar, eliminar y consultar. Consultar.  Figura 3.62:   Usuari@s de OLTP vs Usuari@s de DW.

---