Sin entrar en las características que debe cumplir un DW, pues creo que ya está todo escrito, mencionar que el DW tiene como única finalidad la capacidad de analizar la información de interés desde diversos puntos de vista, a lo largo del tiempo, entre otras muchas cosas. Ello obliga a que esté diseñado y construido de una forma específica, siendo pues necesario cumplir con el término OLAP (OnLine Analytical Process), en contra de los diseños tradicionales, los cuales ahora los denominamos OLTP (OnLine Transaction Processing).
Años antes del DW ya se intentaron montar este tipo de sistemas, a base de duplicar el mundo operacional. El tiempo demostró que dicho camino no era el más efectivo y que tenía serias limitaciones, tomando fuerza la necesidad de que el DW esté diseñado con características OLAP.
Recordemos que los sistemas OLAP cumplen con más de 50 posibilidades de "navegación" por la información, como rotar, bajar, profundizar, expandir, colapsar, etc. Todo esto y mucho más es simplemente imposible en los sistemas tradicionales (OLTP), motivo extra para olvidarse de replicar sistemas, solución ya probada (años 70) y que no dio los resultados esperados.
Existen diversas alternativas para la arquitectura de un DW. En cuanto a tipos de almacenamiento, mencionaremos las más habituales:
- Solución MOLAP (Multidimensional OLAP)
Montar el almacenamiento bajo una base de datos multidimensional propietaria (MDDB de SAS, ESSABE, etc.). - Solución ROLAP (Relacional OLAP)
Montar el almacenamiento bajo una base de datos relacional (SQLServer, Oracle, DB2, etc.). - Soluciones Hibridas, denominadas HOLAP
Combinan ambas alternativas en una única solución, interesante y sabia alternativa según las necesidades.
Debemos considerar que detrás de unas siglas se esconden unas claras diferencias tecnológicas y unas ventajas e inconvenientes que deben conocerse a priori. Las diferencias más llamativas o significativas las podemos clasificar en cuatro puntos:
Necesidades de procesamiento y tiempo de respuesta
Como no existen soluciones ideales cada una ofrece diversas capacidades: Mientras los modelos ROLAP deben calcular y buscar los datos al vuelo, lo cual consume tiempo y retarda la respuesta, los modelos MOLAP tienen todo precocinado y sus tiempos son mejores. Lógicamente las necesidades batch para crear los MOLAP son claramente superiores a los ROLAP. También mencionar que los volúmenes de datos gestionados en ROLAP son muy, pero que muy superiores a los MOLAP, a más datos más tiempo. En algún cliente he intentado crear MOLAP con importantes volúmenes y simplemente fue imposible. Cada tecnología vale para una cosa.
Gestión e incremento en las visiones de negocio
Las visiones de negocio o dimensiones, utilizando términos de BI, son casi infinitos en el mundo ROLAP, pero no por el contrario en el mundo MOLAP. Los modelos MOLAP empiezan a flaquear en la frontera de las 10 dimensiones, pues al crear el MOLAP se deben de calcular todos los cruces o combinaciones posibles, por lo tanto ojo al número de combinaciones usadas.
Necesidades cambiantes de agrupaciones o consolidaciones
En este caso los modelos ROLAP tienen una capacidad más camaleónica, pues todo se calcula al vuelo, siendo más flexibles y potentes. Por contra, los modelos MOLAP requieren de una precocina en batch. En general, incluir cualquier concepto olvidado en un DW es algo laborioso, especialmente en función de donde se deba incluir. Incluir una nueva métrica en una tabla de hechos (tabla fact) (2) es lo más costoso, pues no vale solo con ponerla, será necesario recargar esa métrica y todo su historial asociado. Es casi mejor pecar por exceso, un olvido en una tabla de hechos se paga muy caro.
Volúmenes y capacidades
Posiblemente el éxito de los modelos ROLAP viene especialmente por esta capacidad. Son los únicos que pueden enfrentarse a volúmenes de Gb e incluso Teras de información, algo simplemente imposible en el mundo MOLAP. Lo cual lógicamente hace que sus respuestas no ofrezcan unos tiempos óptimos, pero en otras soluciones simplemente no se pueden hacer. La arquitectura ROLAP es la clara vencedora por capacidad y flexibilidad. Dejando el mundo MOLAP a soluciones o necesidades muy controladas, pequeñas, departamentales o, hablando en cristiano, de "andar por casa". Es normal encontrarse con evoluciones en base a Data Marts (3) , decisión muy extendida e incluso razonable años atrás. Especialmente usadas en las primeras iniciativas de BI, pues resultan rápidas de desarrollar y nos permiten que en nuestras compañías, "los mayores", entiendan las capacidades y bondades de dichos sistemas. Les gustarán mucho y obtendremos financiación para continuar. Pero debemos ser conscientes de las limitaciones que tendremos a medio o largo plazo, pues tendremos silos de información y limitadas capacidades de cruces, lo cual terminará obligando a desarrollar más y más Data Marts.
Posiblemente habremos salido de una pesadilla operacional para entrar en una pesadilla informacional, gracias a la proliferación de Data Marts en nuestra organización.
La otra, o mejor dicho, la única alternativa eficaz, flexible y que siempre nos permitirá un crecimiento y mantenimiento acorde a nuestras necesidades, si hablamos de DW, enten- diéndolo como una solución integrada, consolidada y de amplia cobertura empresarial (no me atrevo a decir corporativo, pero lo pienso), es montar el DW bajo arquitectura ROLAP, como se ilustra la figura 1.
Figura 1. Arquitectura ROLAP para Data Warehouse
Bajo esta figura podemos ofrecer lo mejor de ambos mundos. Dado la limitación física de los MOLAP, dejemos los cimientos del BI bajo ROLAP, y diseñemos estructuras MOLAP para accesos controlados, rápidos y eficaces a los departamentos o necesidades especificas. Como ya hemos comentado, una solución Hibrida (HOLAP) es una sabia salida que ofrece lo mejor de cada arquitectura.
Una vez tratado ligeramente el tema de los almacenamientos posibles y considerando que nos decantamos por su gestión bajo un motor relacional, debemos considerar que los modelos tradicionales no están pensados para las necesidades que debe de soportar un DW. Lo cual requiere un diseño específico, como ya hemos comentado, el cual permita su explotación OLAP. Tradicionalmente nos encontramos con dos tendencias: los modelos en estrellas y los modelos copo de nieve.
