MOLAP

Nigel Pendse, OLAP Survey y Business Intelligence

carlos — Wed, 02 Jan 2008 22:33:15 +0100

Nigel Pendse es el principal analista y autor de los conocidos OLAP Report y OLAP Survey, que aportan información clave en el mundo del Business Intelligence, sobretodo si se ha de seleccionar una herramienta en la que fundamentar un sistema de BI y se desea obtener un análisis profesional e independiente de los mejores productos que ofrece el mercado.

La consultora BARC, propietaria actual de los informes publica en su web dos artículos muy interesantes y traducidos al castellano de Nigel Pendse.

En Nigel Pendse explica el proceso de proyectos de Business Intelligence el autor proporciona varias directivas para la puesta en marcha y mantenimiento posterior exitosos de un proyecto de Business Intelligence. Los puntos que trata son los siguientes:

- La necesidad
- Selección del producto
- A quién involucrar
- Los datos
- Escalas de tiempo
- Tamaño estimado de la base de datos
- Consideraciones de la red y el hardware
- Costes involucrados
- Dirección del proyecto
- Mantenimiento
- ¿Qué marcha mal?

En Nigel Pendse habla sobre Business Intelligence se reproduce una entrevista en la que el mismo Nigel explica en qué consisten tanto el OLAP Report como la OLAP Survey, y responde a estas interesantes preguntas que relacionan tecnologías, perfiles profesionales y tendencias de mercado del mundo BI:

- Nigel, usted es conocido en todo el mundo como uno de los analistas más importantes de OLAP, Business Intelligence y también Corporate Performance Management (CPM). ¿Podría describirnos brevemente en que consiste su trabajo?

- ¿Cuantos clientes o usuarios normalmente participan en su encuesta?

- El mercado de BI tiene tantos vendedores y productos. ¿Como consigue crear ciertas comparaciones?

- Justo ahora, usted ha terminado su investigación sobre el "OLAP Survey 5". ¿Se ha encontrado con algunas nuevas tendencias que le hayan llamado su atención?

- ¿Pero estos problemas no podrían solucionarse a través de la tecnología?
En su trabajo, ¿Cuántos compañías ha visto que han normalizado sus aplicaciones de BI y CPM con éxito con la ayuda de un único vendedor?

- ¿Usted cree que el OLAP y BI son temas que se pueden relacionar con IT y profesionales de negocios…o los dos?

- Analistas y consultorías pueden ayudar a las compañías en su búsqueda por soluciones de BI. ¿En qué difieren estos enfoques?

- ¿Usted cree que el usuario medio entiende la diferencia?

- ¿Dónde piensa que se posicionará el mercado en los próximos cinco años? ¿considera que el mercado continuará consolidándose o sólo se mantendrá para unos cuantos?

OLAP, MOLAP y ROLAP

carlos — Wed, 08 Aug 2007 00:19:31 +0200

2.2.5.1.- OLAP, ROLAP, MOLAP

2.2.5.1.- Introducción

2.2.5.1.1.- Sistemas MOLAP

2.2.5.1.2.- Sistemas ROLAP

2.2.5.1.3.- ROLAP vs. MOLAP (Comparativa)

Introducción.-

La explotación del Data Warehouse mediante información de gestión, se fundamenta básicamente en los niveles agrupados o calculados de información.

La información de gestión se compone de conceptos de información y coeficientes de gestión, que los cuadros directivos de la empresa pueden consultar según las dimensiones de negocio que se definan.

Dichas dimensiones de negocio se estructuran a su vez en distintos niveles de detalle (por ejemplo, la dimensión geográfica puede constar de los niveles nacional, provincial, ayuntamientos y sección censal).

Este tipo de sistemas ha existido desde hace tiempo, en el mundo de la informática bajo distintas denominaciones: cuadros de mando, MIS, EIS, etc.

Su realización fuera del entorno del Data Warehouse, puede repercutir sobre estos sistemas en una mayor rigidez, dificultad de actualización y mantenimiento, malos tiempos de respuesta, incoherencias de la información, falta del dato agregado, etc.

Los sistemas de soporte a la decisión usando tecnologías de Data Warehouse, se llaman sistemas OLAP (siglas de On Line Analytical Processing (OLAP). En general, estos sistemas OLAP deben:

Soportar requerimientos complejos de análisis
Analizar datos desde diferentes perspectivas
Soportar análisis complejos contra un volumen ingente de datos

La funcionalidad de los sistemas OLAP se caracteriza por ser un análisis multidimensional de datos corporativos, que soportan los análisis del usuario y unas posibilidades de navegación, seleccionando la información a obtener.

Normalmente este tipo de selecciones se ve reflejada en la visualización de la estructura multidimensional, en unos campos de selección que nos permitan elegir el nivel de agregación (jerarquía) de la dimensión, y/o la elección de un dato en concreto, la visualización de los atributos del sujeto, frente a una(s) dimensiones en modo tabla, pudiendo con ello realizar, entre otras las siguientes acciones:

Rotar (Swap): 		alterar las filas por columnas (permutar dos dimensiones de análisis)

Bajar (Down): 		bajar el nivel de visualización en las filas a una jerarquía inferior

Detallar (Drilldown): 	informar para una fila en concreto, de datos a un nivel inferior

Expandir (Expand): 	id. anterior sin perder la información a nivel superior para éste y el resto de los valores

Colapsar (Collapse): 	operación inversa de la anterior.

Para ampliar el glosario sobre exploraciones en análisis OLAP, recomendamos la visita a la página Internet:

http://www.kenan.com/acumate/olaptrms.htm

en donde se describen en torno a 50 términos relacionados con las posibilidades de navegación que permiten este tipo de análisis.

Existen dos arquitecturas diferentes para los sistemas OLAP: OLAP multidimensional (MOLAP) y OLAP relacionales (ROLAP).

2.2.5.1.1.-Sistemas MOLAP

La arquitectura MOLAP usa unas bases de datos multidimensionales para proporcionar el análisis, su principal premisa es que el OLAP está mejor implantado almacenando los datos multidimensionalmente. Por el contrario, la arquitectura ROLAP cree que las capacidades OLAP están perfectamente implantadas sobre bases de datos relacionales

Un sistema MOLAP usa una base de datos propietaria multidimensional, en la que la información se almacena multidimensionalmente, para ser visualizada multidimensionalmente.

El sistema MOLAP utiliza una arquitectura de dos niveles: La bases de datos multidimensionales y el motor analítico.

La base de datos multidimensional es la encargada del manejo, acceso y obtención del dato.
El nivel de aplicación es el responsable de la ejecución de los requerimientos OLAP. El nivel
de presentación se integra con el de aplicación y proporciona un interfaz a través del cual
los usuarios finales visualizan los análisis OLAP. Una arquitectura cliente/servidor permite a varios usuarios
acceder a la misma base de datos multidimensional.

La información procedente de los sistemas operacionales, se carga en el sistema MOLAP, mediante una serie de rutinas batch. Una vez cargado el dato elemental en la Base de Datos multidimensional (MDDB), se realizan una serie de cálculos en batch, para calcular los datos agregados, a través de las dimensiones de negocio, rellenando la estructura MDDB.

Tras rellenar esta estructura, se generan unos índices y algoritmos de tablas hash para mejorar los tiempos de accesos a las consultas.

Una vez que el proceso de compilación se ha acabado, la MDDB está lista para su uso. Los usuarios solicitan informes a través del interface, y la lógica de aplicación de la MDDB obtiene el dato.

La arquitectura MOLAP requiere unos cálculos intensivos de compilación. Lee de datos precompilados, y tiene capacidades limitadas de crear agregaciones dinámicamente o de hallar ratios que no se hayan precalculados y almacenados previamente.

2.2.5.1.2.-Sistemas ROLAP

La arquitectura ROLAP, accede a los datos almacenados en un Data Warehouse para proporcionar los análisis OLAP. La premisa de los sistemas ROLAP es que las capacidades OLAP se soportan mejor contra las bases de datos relacionales.

El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional maneja los requerimientos de almacenamiento de datos, y el motor ROLAP proporciona la funcionalidad analítica.

El nivel de base de datos usa bases de datos relacionales para el manejo, acceso y obtención del dato.
El nivel de aplicación es el motor que ejecuta las consultas multidimensionales de los usuarios.
El motor ROLAP se integra con niveles de presentación, a través de los cuales los usuarios realizan
los análisis OLAP.

Después de que el modelo de datos para el Data Warehouse se ha definido, los datos se cargan desde el sistema operacional. Se ejecutan rutinas de bases de datos para agregar el dato, si así es requerido por el modelos de datos.

Se crean entonces los índices para optimizar los tiempos de acceso a las consultas.

Los usuarios finales ejecutan sus análisis multidimensionales, a través del motor ROLAP, que transforma dinámicamente sus consultas a consultas SQL. Se ejecutan estas consultas SQL en las bases de datos relacionales, y sus resultados se relacionan mediante tablas cruzadas y conjuntos multidimensionales para devolver los resultados a los usuarios.

La arquitectura ROLAP es capaz de usar datos precalculados si estos están disponibles, o de generar dinámicamente los resultados desde los datos elementales si es preciso. Esta arquitectura accede directamente a los datos del Data Warehouse, y soporta técnicas de optimización de accesos para acelerar las consultas. Estas optimizaciones son, entre otras, particionado de los datos a nivel de aplicación, soporte a la desnormalización y joins múltiples.

2.2.5.1.3.-ROLAP vs. MOLAP (Comparativa)

Cuando se comparan las dos arquitecturas, se pueden realizar las siguientes observaciones:

El ROLAP delega la negociación entre tiempo de respuesta y el proceso batch al diseño del sistema.
Mientras, el MOLAP, suele requerir que sus bases de datos se precompilen para conseguir un rendimiento aceptable
en las consultas, incrementando, por tanto los requerimientos batch.
Los sistemas con alta volatilidad de los datos (aquellos en los que cambian las reglas de agregación
y consolidación), requieren una arquitectura que pueda realizar esta consolidación ad-hoc. Los sistemas
ROLAP soportan bien esta consolidación dinámica, mientras que los MOLAP están más orientados
hacia consolidaciones batch.
Los ROLAP pueden crecer hasta un gran número de dimensiones, mientras que los MOLAP generalmente son
adecuados para diez o menos dimensiones.
Los ROLAP soportan análisis OLAP contra grandes volúmenes de datos elementales, mientras que
los MOLAP se comportan razonablemente en volúmenes más reducidos (menos de 5 Gb)

Por ello, y resumiendo, el ROLAP es una arquitectura flexible y general, que crece para dar soporte a amplios requerimientos OLAP. El MOLAP es una solución particular, adecuada para soluciones departamentales con unos volúmenes de información y número de dimensiones más modestos.

Conceptos y funcionalidades básicas de Data Warehouse

carlos — Sun, 05 Aug 2007 02:22:39 +0200

2.2.- CONCEPTOS Y FUNCIONALIDADES BÁSICAS

2.2.1.- Data Warehouse vs. Data Mart

2.2.2.- Componentes a tener en cuenta a la hora de construir un Data Warehouse

2.2.3.- Fases de implantación de un Data Warehouse

2.2.4.- Estrategias de implantación

2.2.5.- Técnicas de Explotación de la Información

2.2.6.- Tipos de aplicaciones en las que utilizar las técnicas disponibles sobre DW

2.2.7.- Seguridad de acceso y manipulación de la información en el Data Warehouse

Manual para la adquisición de un sistema de Data Warehouse

carlos — Sat, 04 Aug 2007 13:55:49 +0200

El Consejo Superior de informática ha publicado una serie de Guías Técnicas Aplicables a la Contratación de Bienes y Servicios de Tecnologías de la Información y las Comunicaciones. Una de estas guías está dedicada a los Sistemas de Data Warehouse. Publicamos aquí su contenido, dada la claridad con la que se explican los conceptos básicos relativos al Data Warehouse y, en definitiva, la utilidad de la misma.

1.- INTRODUCCIÓN

1.1.- Justificación Histórica

1.2.- Sumario

2.- ANÁLISIS DEL ENTORNO DE DATA WAREHOUSE

2.1.- ¿Qué es un Data Warehouse?

2.2.- Conceptos y funcionalidades básicas

2.3.- Tendencias tecnológicas y de mercado

3.- ASPECTOS TÉCNICOS DEL PROCESO DE ADQUISICIÓN DE SISTEMAS DE DATA WAREHOUSE

3.1.- Análisis de las necesidades del comprador

3.2.- Factores relevantes en el proceso de adquisición

3.3.- Diseño del pliego de prescripciones técnicas particulares

4.- PRUEBAS DE VERIFICACIÓN Y CONTROL

5.- REFERENCIAS UTILIZADAS

6.- EQUIPO RESPONSABLE DE LA GUIA TÉCNICA

¿Qué es un Data Warehouse?

carlos — Tue, 31 Jul 2007 18:46:58 +0200

2.1. - ¿QUÉ ES UN DATA WAREHOUSE?

Tras las dificultades de los sistemas tradicionales en satisfacer las necesidades informacionales, surge el concepto de Data Warehouse, como solución a las necesidades informacionales globales de la empresa. Este término acuñado por Bill Inmon, se traduce literalmente como Almacén de Datos. No obstante si el Data Warehouse fuese exclusivamente un almacén de datos, los problemas seguirían siendo los mismos que en los Centros de Información.

La ventaja principal de este tipo de sistemas se basa en su concepto fundamental, la estructura de la información. Este concepto significa el almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y en un entorno diferenciado de los sistemas operacionales. Según definió Bill Inmon, el Data Warehouse se caracteriza por ser:

Integrado: los datos almacenados en el Data Warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.

Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del Data Warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar.

Histórico: el tiempo es parte implícita de la información contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, la información almacenada en el Data Warehouse sirve, entre otras cosas, para realizar análisis de tendencias. Por lo tanto, el Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones.

No volátil: el almacén de información de un Data Warehouse existe para ser leído, y no modificado. La información es por tanto permanente, significando la actualización del Data Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.

E.F. Codd, considerado como el padre de las bases de datos relacionales, ha venido insistiendo desde principio de los noventa, que disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones. Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza. Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio.

Estas dimensiones de negocio se comprenden mejor fijando un ejemplo, para lo que vamos a mostrar, para un sistema de gestión de expedientes, las jerarquías que se podrían manejar para el número de los mismo para las dimensiones: zona geográfica, tipo de expediente y tiempo de resolución. La visión general de la información de ventas para estas dimensiones definidas, la representaremos, gráficamente como el cubo de la derecha:
Un gerente de una zona estaría interesado en visualizar la información para su zona en el tiempo para todos los productos que distribuye, lo podría tener una representación gráfica como el cubo de la derecha:
Un director de producto, sin embargo querría examinar la distribución geográfica de sus productos, para toda la información histórica almacenada en el Data Warehouse. Esto se podría representar como la siguiente figura:
O se podría también examinar los datos en un determinado momento o una visión particularizada.

A su vez estas dimensiones tienen una jerarquía, interpretándose en el cubo como que cada cubo elemental es un dato elemental, del que se puede extraer información agregada. En el ejemplo anterior podría ser:

Y así por ejemplo se podría querer analizar la evolución de las ventas en Galicia de libros de Física por meses desde Febrero del 1996 hasta Marzo del 1997.

Ello es fácil de obtener (incluso a "golpe de ratón") si la información de ventas se ha almacenado en un Data Warehouse, definiendo estas jerarquías y estas dimensiones de negocio.

En este sentido citamos las palabras de D. Wayne Calloway Director Ejecutivo de Operaciones de Pepsico en una asamblea general de accionistas:

"Hace diez años les pude decir cuántos Doritos vendimos al Oeste del Mississipi. Hoy no sólo les puedo decir eso mismo, sino cuántos vendimos en California, en el Condado de Orange, en la ciudad de Irvine, en el Supermercado local Von’s, en una promoción especial, al final del pasillo 4, los jueves".

Otra característica del Data Warehouse es que contiene datos relativos a los datos, concepto que se ha venido asociando al término de metadatos. Los metadatos permiten mantener información de la procedencia de la información, la periodicidad de refresco, su fiabilidad, forma de cálculo, etc., relativa a los datos de nuestro almacén.

Estos metadatos serán los que permitan simplificar y automatizar la obtención de la información desde los sistemas operacionales a los sistemas informacionales.

Los objetivos que deben cumplir los metadatos, según el colectivo al que va dirigido, serían:

Soportar al usuario final, ayudándole a acceder al Data Warehouse con su propio lenguaje de negocio, indicando qué información hay y qué significado tiene. Ayudar a construir consultas, informes y análisis, mediante herramientas de navegación.
Soportar a los responsables técnicos del Data Warehouse en aspectos de auditoría, gestión de la información histórica, administración del Data Warehouse, elaboración de programas de extracción de la información, especificación de las interfaces para la realimentación a los sistemas operacionales de los resultados obtenidos, etc.

Para comprender el concepto de Data Warehouse, es importante considerar los procesos que lo conforman. A continuación se describen dichos procesos clave en la gestión de un Data Warehouse:

Extracció: 	obtención de información de las distintas fuentes tanto internas como externas.

Elaboración: 	filtrado, limpieza, depuración, homogeneización y agrupación de la información.

Carga: 	organización y actualización de los datos y los metadatos en la base de datos.

Explotación: 	extracción y análisis de la información en los distintos niveles de agrupación.

Desde el punto de vista del usuario, el único proceso visible es la explotación del almacén de datos, aunque el éxito del Data Warehouse radica en los tres procesos iniciales que alimentan la información del mismo y suponen el mayor porcentaje de esfuerzo (en torno a un 80%) a la hora de desarrollar el almacén.

Las diferencias de un Data Warehouse con un sistema tradicional las podríamos resumir en el siguiente esquema:

SISTEMA TRADICIONAL	DATA WAREHOUSE
Predomina la actualización	Predomina la consulta
La actividad más importante es de tipo operativo (día a día)	La actividad más importante es el análisis y la decisión estratégica
Predomina el proceso puntual	Predomina el proceso masivo
Mayor importancia a la estabilidad	Mayor importancia al dinamismo
Datos en general desagregados	Datos en distintos niveles de detalle y agregación
Importancia del dato actual	Importancia del dato histórico
Importante del tiempo de respuesta de la transacción instantánea	Importancia de la respuesta masiva
Estructura relacional	Visión multidimensional
Usuarios de perfiles medios o bajos	Usuarios de perfiles altos
Explotación de la información relacionada con la operativa de cada aplicación	Explotación de toda la información interna y externa relacionada con el negocio

Una de las claves del éxito en la construcción de un Data Warehouse es el desarrollo de forma gradual, seleccionando a un departamento usuario como piloto y expandiendo progresivamente el almacén de datos a los demás usuarios. Por ello es importante elegir este usuario inicial o piloto, siendo importante que sea un departamento con pocos usuarios, en el que la necesidad de este tipo de sistemas es muy alta y se puedan obtener y medir resultados a corto plazo.

Terminamos este apartado, resumiendo los beneficios que un Data Warehouse puede aportar:

Proporciona una herramienta para la toma de decisiones en cualquier área funcional, basándose en información integrada y global del negocio.
Facilita la aplicación de técnicas estadísticas de análisis y modelización para encontrar relaciones ocultas entre los datos del almacén; obteniendo un valor añadido para el negocio de dicha información.
Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en diversos escenarios.
Simplifica dentro de la empresa la implantación de sistemas de gestión integral de la relación con el cliente.
Supone una optimización tecnológica y económica en entornos de Centro de Información, estadística o de generación de informes con retornos de la inversión espectaculares.