Sin entrar en discusiones filosóficas acerca de por qué el mundo OLAP no tiene interfaces estandarizadas, lo cierto es que quien da sus primeros pasos en este mundillo se encuentra con que los cimientos sobre los que se construyen las aplicaciones que atacan bases de datos relacionales, son unos débiles ladrillos de adobe en el mundo multidimensional.
¿Qué interfaz debe usar mi aplicación? ¿Cuales existen? ¿Para qué sirven?. Existen sobre todo dos grandes familias de tipos de acceso a bases de datos multidimensionales: aquellos que son interfaces relacionales con alguna extensión que los hace multidimensionales, y los que son puramente multidimensionales. El abanico de posibles mecanismos de conexión depende mucho de la base de datos que se utilice.
Practicamente todas las bases de datos multidimensionales permiten la conexión a través de interfaces relacionales. Las hay muy orientadas al mundo JAVA, que usan jdbc como estándar de conexión y SQL como lenguaje de query (por ejemplo Oracle), y las hay que ofrecen conexiones OLEDB u ODBC.
Acceder a un almacén multidimensional por medio de un API relacional siempre es un problema, porque sólo podremos acceder de esta forma a proyecciones bidimensionales de nuestra base de datos. Esto no significa que no podamos consultar datos estructurados en más de dos dimensiones… sólo significa que cuando los consultemos, al igual que al dibujar un cubo en una pizarra obtenemos una proyección plana, al consultar más de dos dimensiones también obtendremos una proyección aplanada (el resultado de realizar una multiplicación cartesiana de las distintas dimensiones que queremos representar).
Al final, en la interfaz de usuario sólo podemos mostrar dos dimensiones, así que uno podría pensar… qué rayos, me da lo mismo trabajar sobre un conjunto de datos aplanado. ¡No, no, y no! ¡Al aplanar un conjunto de datos multidimensional, hemos perdido gran parte de los metadatos que lo acompañan! Un volumen multidimensional que haya perdido su estructura, no nos permitirá realizar con comodidad operaciones de rotación o pivotado, así que precisamente estamos limitando en gran medida la capacidad de análisis que debería tener el usuario sobre esos datos. Vamos, que cualquier API que sólo permita acceder por medio de una interfaz relacional a un volumen multidimensional, no es más que una chapucilla para salir del paso.
Entonces, ¿qué alternativas nos quedan?
Muchos fabricantes tienen sus propias APIs no estándar que permiten acceder a conjuntos de datos multidimensionales… pero por suerte, también nos encontramos estándares.
- Algunos estándares se utilizan para acceder a volúmenes multidimensionales utilizando un modelo de objetos. Seguro que podéis haceros una idea, ¿verdad? Instancio un cubo, me voy a la colección de dimensiones, ejecuto ciertas operaciones y me traigo un subconjunto del cubo con los datos que quiero. Oracle apuesta por este tipo de acceso, y como Oracle, todos aquellos que apuestan por JOLAP (http://jcp.org/en/jsr/detail?id=069). Yo veo un problema a este tipo de interfaces, y es que generalmente están ligados a que se desarrolle un determinado modelo de objetos (generalmente complejo) implantado en el lenguaje desde el que se lanzan las queries. Generalmente se desarrollan para un único lenguaje (en el caso de JOLAP es Java), aunque lo cierto es que desde que existen los servicios web, no tendría por qué ser así… ¿no creeis?.
Microsoft también tiene una API de este tipo: la AMO (Analysis Management Objects), con la particularidad de que AMO sólo sirve para consultar los metadatos de una base de datos OLAP, y nunca para acceder a los datos en sí.
- Microsoft lanzó en su día ODBO: OLE DB for OLAP. ODBO era una interfaz diseñada casi a medida de Excel, cuyo objetivo era permitir la conexión entre las «Pivot table» de excel y SQL Server Analysis Services. De hecho, a este proveedor OLE DB, se le llamaba también «Microsoft Pivot Table Services». Sin embargo, ODBO empezó a utilizarse para otros fines (por ejemplo, SAP incorpora una interfaz ODBO). Junto con ODBO, Microsoft lanzó un lenguaje de query para bases de datos multidimensionales: el MDX. ODBO transmite los datos en formato binario, a través de sockets TCP o encapsulado dentro de HTTP, pero siempre en formato binario. La pega que se le achacaba en su día a ODBO es el no ser lo suficientemente abierto.
- En medio de esta guerra, surgió el XMLA como iniciativa de Microsoft. XMLA es un estándar abierto, basado en SOAP. XMLA ha sido rápidamente adoptado por un gran número de fabricantes de bases de datos multidimensionales (Hyperion, SAS, Mondrian…) salvo por Oracle, que lo tacha de estándar propietario de Microsoft. Podéis encontrar información sobre XMLA en www.xmla.org
¿Y por qué es XMLA nuestro amigo? Realmente el XMLA es el único estándar universal del que disponemos. XMLA no excluye a nadie, y puede ser implementado en cualquier lenguaje del mundo que permita programar y consumir web services. Microsoft, Hyperion y SAS ya tienen soporte XMLA, e incluso el mundo open source se está acercando a este estándar. En el mundo .NET, el cliente ADOMD.NET o incluso OLEDB for OLAP 9.0 son clientes XMLA, lo que les permite ir más allá de ser simples interfaces para acceder a Analysis Services y permitirles acceder en teoría a cualquier servidor XMLA (esto no siempre es así, pero no porque ADOMD.NET sea un cliente cerrado, sino porque muchas veces el soporte XMLA de las bases de datos no es lo suficientemente completo).
¿Qué razones hay para no apostar por el XMLA? La única razón es Oracle. Nos dicen que únicamente soportarán JOLAP, y que XMLA es un estándar cerrado de Microsoft. Es curioso que digan esto, ¡porque JOLAP y XMLA no son comparables! JOLAP y AMO sí que serían comparables, pero XMLA es un estándar que define la comunicación con la base de datos multidimensional a un nivel mucho más bajo que JOLAP. De hecho, JOLAP es un API, y XMLA es la definición de una interfaz orientada a servicios. JOLAP podría funcionar perfectamente sobre XMLA, utilizando un api en JAVA para lanzar consultas que se convirtiesen en llamadas «execute» de XMLA con sentencias MDX encapsuladas… bueno, esto no hace falta que lo diga yo, ¡es como actualmente funciona Hyperion!
Así que en esta película, si no nos queda más remedio que programar para Oracle, no nos quedará más remedio que rechazar el XMLA… pero hasta en este último caso, piensa que no hay ninguna razón para enemistarse con el XMLA. Es sólo que a veces las presiones y el politiqueo nos impiden elegir a nuestros amigos ;-).