Consultas MDX

Expresiones MDX en Analysis Services.

Analysis Services

Jorge Bustos | j.bustos@danysoft.com En este artículo se introducen las bases para entender el lenguaje de consulta MDX, diseñado para realizar consultas sobre cubos OLAP en general, y en Analysis Services en particular. Se explican los conceptos básicos y se ofrecen algunas muestras con la base de datos de ejemplo Foodmaret incluida en Analysis Services.

Para leer este artículo debería estar mínimamente familiarizado con los cubos OLAP, conocer lo que son y haberlos manejado con cualquier tipo de herramienta cliente. Asimismo es recomendable tener Analysis Services instalado, de modo que puedan ejecutarse los ejemplos propuestos.

Consulta de bases de datos multidimensionales con MDX En estos tiempos en que Business Intelligence se está convirtiendo en uno de los temas más en boga dentro de las Tecnologías de la Información, merece la pena hablar de un lenguaje cuya popularidad irá ganando terreno. Del mismo modo que el lenguaje SQL es el estándar para la consulta de bases de datos relacionales, MDX lo es para las bases de datos multidimensionales, conocidas habitualmente como OLAP. MDX es el acrónimo de MultiDimensional eXpressions, lo que da una idea de cual es su finalidad exacta.

¿Qué devuelve una consulta MDX? Del mismo modo que una consulta SQL devuelve un conjunto de datos, una expresión MDX devuelve un conjunto de celdas que es el resultado de tomar un subconjunto de las celdas del cubo original. Por ejemplo, se puede considerar que este cubo completo es el punto de partida para la consulta.

Desde cualquier aplicación cliente OLAP, se pueden hacer varios tipos de manipulaciones a este cubo:

•

Girarlo, que consiste en cambiar el lugar que ocupan las dimensiones.

Es decir, asociar las dimensiones a diferentes ejes.

05/09/2005 | Valor añadido Danysoft | 902 123146 | www.danysoft.com | Página 1.11

• •

Rebanarlo, que consiste en elegir un “corte” del cubo, correspondiente a un miembro concreto de una dimensión.

Cortarlo en dados, que consiste en elegir un trozo particular del cubo limitando los miembros elegidos para visualizar en cada dimensión.

Girar un cubo consiste en cambiar las dimensiones asociadas a cada eje. El siguiente dibujo muestra el resultado de girar el cubo original, mostrado en la figura de arriba.

Como se puede apreciar, el cubo es el mismo, pero los ejes ocupados por las dimensiones de meses, provincias y productos se han cambiado, resultando en una vista diferente de los mismos datos.

Otra operación que se puede realizar en un cubo, según se mencionaba arriba, es su “rebanado”. Rebanar un cubo es, en cierta manera, filtrar los datos que se quieren visualizar del mismo. (El “en cierta manera” es porque en MDX hay una diferencia sustancial entre filtrado y rebanado).

Por ejemplo, tal como está el cubo orientado tras haberlo girado, podría ser interesante examinar los datos de una provincia concreta. De este modo se conseguiría un conjunto de celdas distribuido en dos dimensiones, que es lo que realmente se puede visualizar en cualquier aplicación cliente de cubos OLAP. La siguiente imagen muestra el cubo rebanado:

El rebanado consiste en elegir un miembro concreto de una dimensión para visualizar sólo los datos correspondientes al mismo. En este ejemplo se ha elegido el miembro Zaragoza de la dimensión Provincias, de modo que estamos viendo los datos de Zaragoza para todos los meses y todos los productos existentes en el cubo.

La última operación que se mencionaba arriba era “cortarlo en dados”. Cortar el cubo en dados supone mostrar sólo los datos correspondientes a miembros concretos elegidos en cada dimensión. Esta operación puede parecer lo mismo que el rebanado, pero hay dos diferencias fundamentales:

• •

En el rebanado, la dimensión elegida para rebanar no está en un eje visible. En el ejemplo de arriba se puede ver que en el momento de rebanar, la dimensión provincias ha dejado de estar en un eje.

De la dimensión utilizada para rebanar sólo se puede elegir un único miembro. En cambio, en las dimensiones pertenecientes a los ejes se pueden elegir todos los miembros que se desee.

Un ejemplo de hacer dados a este cubo consistiría en tomar solo parte de los miembros de las dos dimensiones visibles en los ejes, dejando ocultos todos los demás.

En el ejemplo de arriba sólo se están visualizando las bebidas, en la dimensión de productos, y el 2º trimestre, en la dimensión de los meses. Si no estuviera rebanado, esto nos daría un dado completo, resultante de trocear el cubo original, que comprendería las bebidas, el segundo trimestre, y todas las provincias. Pero el dado de la figura además está rebanado, de modo que sólo se toma la provincia de Zaragoza y, más que un dado, es una rebanada de un dado.

Una nota sobre nomenclatura: a las dos últimas operaciones mencionadas se les suele denominar “Slice & Dice” en la jerga inglesa de OLAP. La palabra rebanar y rebanador es la utilizada por Microsoft en la ayuda de Analysis Services. Y “hacer dados”, es la traducción literal de dice. Ambas expresiones, las tomemos en inglés o en su traducción al castellano, son muy visuales, y representan muy bien lo que le sucede al cubo original.

Aunque en rigor no es lo mismo, muchas veces al rebanado se le denomina paginación. En realidad la paginación correspondería al tercer eje de las expresiones MDX, que no se suele utilizar nunca, dado que no es posible visualizar más de dos ejes. Así que la tercera y siguientes dimensiones nunca suelen ir en los ejes de la consulta, sino en los rebanadores.

En el ejemplo utilizado, el cubo sólo dispone de tres dimensiones. Naturalmente, en los cubos que se explotan habitualmente suele haber más de tres dimensiones. La elección de un cubo de tres dimensiones se ha hecho intencionadamente para simplificar el ejemplo, y permitir que siga siendo muy visual, dado que no tenemos la capacidad de visualizar más de tres dimensiones mediante dibujos. Hacer ejemplos de más de tres dimensiones obligaría entrar en terrenos demasiado abstractos. Por tanto, aunque el ejemplo haya sido sobre 3 dimensiones, los conceptos explicados se pueden extender a cualquier número de dimensiones.

¿Qué son las medidas de un cubo?

En los ejemplos de arriba se ha obviado deliberadamente el tema de las medidas. Se ha hablado de los cubos y de sus celdas, y de qué celdas se muestran y de cómo se muestran. Incluso se ha hablado de que, en dichas celdas, hay datos. Sin embargo nada más se ha dicho sobre los datos de las celdas. A continuación se explica que datos hay en ellas.

A los datos existentes en cada celda de los cubos se les denomina medidas. En el cubo empleado para los ejemplos la medida podría ser el número de unidades vendidas, o el costo de fabricación de los productos vendidos, o la cifra neta de ventas, o el beneficio neto de las ventas. Es más, el cubo podría tener todas estas medidas definidas. Sin embargo sólo es posible ver un dato en cada celda en cada momento. Es decir, hay que elegir que medida se quiere ver en cada momento en las celdas del cubo.

En el siguiente apartado se explica como se utilizan las medidas en las expresiones MDX de Analysis Services.

¿Cómo se tratan las medidas en MDX? En MDX, las medidas se tratan como si fueran una dimensión más del cubo, de modo que se puede hacer dos cosas con ellas:

• •

Utilizarlas para rebanar, eligiendo una medida concreta para visualizarla en el cubo.

Mostrar las medidas en un eje, como si se tratara de otra dimensión cualquiera.

Concretando aún más, en las expresiones MDX las medidas se tratan como si pertenecieran a una dimensión que siempre se va a llamar Measures, cuyos miembros son los nombres de las diferentes medidas definidas en el cubo.

¿Para qué se utilizan las consultas MDX? Afortunadamente para los usuarios finales, el conocimiento de las consultas MDX no es necesario para poder realizar la serie de manipulaciones básicas que se han ido mencionando en los apartados anteriores. Cualquier herramienta cliente de OLAP permite visualizar el cubo, girarlo, hacerlo dados, rebanarlo, e incluso realizar otra serie de operaciones más avanzadas, como ordenar, filtrar por valores, añadir cálculos, etc. Sin embargo, detrás de todas estas operaciones, suele existir una consulta MDX. (Algunos sistemas OLAP funcionan de otra manera, siendo específicos de determinados fabricantes).

En definitiva, el usuario final de una aplicación cliente OLAP nunca tiene por que verse involucrado con la creación de consultas MDX ya que dicha aplicación las crea automáticamente para él.

Entonces ¿para qué se necesita MDX? Existen varios motivos que se enuncian a continuación.

Al igual que en SQL, en MDX se pueden utilizar expresiones para manipular los datos, ordenarlos, filtrarlos, agruparlos, realizar cálculos con ellos, etc. Dichas expresiones deben escribirse, como no podía ser de otra manera, con la sintaxis de MDX. A veces hace falta realizar consultas más avanzadas que las permitidas por los clientes OLAP. También puede ser necesario conocer la sintaxis MDX para crear miembros o celdas calculadas, incluso cuando se está utilizando una buena aplicación cliente OLAP. Y, por último, muchas veces, al desarrollar una aplicación, o un informe, no queda más remedio que escribir la expresión MDX a mano. Este es el caso, por ejemplo, de Reporting Services. Cuando se desean mostrar los datos de un cubo en un informe realizado con esta herramienta, es necesario escribir la consulta que se desea visualizar. Cuando se quieren leer datos de un cubo desde una aplicación personalizada sucede lo mismo.

¿Cómo se conectan las aplicaciones a los servidores de cubos?

Aunque en su momento trataron de implantarse otros estándares, y fuera de las conexiones específicas entre los servidores y clientes de determinados fabricantes de productos OLAP, el estándar de facto, sin ningún lugar a dudas, es ADO MD, o ADO con extensiones multidimensionales, si se utiliza el nombre largo.

ADO MD se puede considerar como “el ODBC de las bases de datos multidimensionales” en el sentido de que está tan generalizado entre las bases multidimensionales como ODBC en las relacionales. O, si aún no llega al mismo nivel de generalización, algún día lo hará.

Con este tipo de conexión, y mediante la utilización de expresiones MDX, es posible obtener datos de un cubo desde múltiples lenguajes de programación. Por ejemplo se puede utilizar en Visual Basic o en los lenguajes .NET.

¿Cómo se pueden escribir y probar las expresiones MDX? A falta de una herramienta más avanzada para ello, como la que aparecerá en SQL Server 2005, el único modo de probar las expresiones MDX es utilizando una aplicación de ejemplo a la que se accede desde Analysis Manager.

Dicha aplicación de ejemplo se encuentra dentro del menú SQL Server, en el grupo de Analysis Services. Al abrir el programa hay que introducir los datos para realizar la conexión:

Se debe proporcionar el nombre del servidor, donde puede especificarse su nombre de red, y el proveedor, que será MSOLAP para conectarse a Analysis Services.

La seguridad de Analysis Services va integrada con la de Windows y, por defecto, el Administrador de Windows puede acceder a los cubos sin ningún tipo de limitación.

La aplicación tiene una interfaz básica, pero más que suficiente para realizar pruebas. Consta de un cuadro de texto donde se escribirá la consulta, un explorador de cubos que permite examinar los miembros y niveles de las dimensiones, una lista de los elementos de la sintaxis MDX y una rejilla que se crea al ejecutar las consultas para mostrar sus resultados:

Los nombres de los niveles de las dimensiones y de los miembros se pueden arrastrar directamente desde el explorador al cuadro de texto como ayuda para escribir las consultas.

¿Cómo se escribe una consulta MDX básica?

A través de unos pocos ejemplos se va a dar una visión global del aspecto de las consultas MDX más básicas.

Para ejecutar las consultas puede utilizarse la aplicación de ejemplo mencionada arriba, conectándose a la base de datos de ejemplo Foodmart 2000.

La sintaxis básica es: SELECT <especificación de eje> on columns, <especificación de eje> on rows FROM <especificación de cubo> WHERE <especificación Slicer (rebanador)> En vez de entrar de lleno en ella es mejor partir de ejemplos más sencillos, como el siguiente: SELECT FROM Sales Ya que no se han especificado ejes, esta consulta únicamente devuelve una celda, correspondiente a los datos acumulados del cubo completo. Más precisamente, las dimensiones tienen un miembro por defecto, que es el que toman cuando no se especifican en la consulta MDX. Normalmente este es el miembro “todos”, por lo que esta consulta devuelve el resultado global de todos los datos del cubo. Es decir, para cada dimensión, al no haberse especificado nada, se elige el miembro “todos” que engloba a toda la jerarquía de la dimensión.

La oveja negra, es la dimensión de medidas, Measures, para la que no existe un miembro “todos”, sino que

hay una medida por defecto, especificada al crear el cubo, elegida entre todas las medidas existentes. El valor de la celda se corresponde a la medida Unit Sales.

Para especificar un rebanador, basta con escribir el nombre de un miembro concreto de una dimensión tras el WHERE. La consulta anterior, por tanto, sería totalmente equivalente a: SELECT FROM Sales WHERE [Measures].[Unit Sales] En la consulta puede especificarse el número de ejes que se desee, aunque debe respetarse que el primer eje sea el de columnas, el segundo el de filas, el tercero el de páginas, etc. En este caso, y en la mayoría de los casos, la aplicación sólo soporta un máximo de dos ejes. Eso es natural, si se recuerda lo que se comentaba sobre los ejes y rebanadores al principio de este artículo.

Una consulta que especifica un eje tiene este aspecto: SELECT {[Product].[All Products].[Drink].[Beverages], [Product].[All Products].[Drink].[Dairy], [Product].[All Products].[Food].[Eggs], [Product].[All Products].[Food].[Meat]} on columns FROM Sales Como es aprecia, la especificación de un eje consiste en definir los miembros de la dimensión que se aparecerán en el eje. Este es el resultado:

Naturalmente existen medios para no tener que especificar uno a uno todos los miembros, como la función Members, que devuelve la lista de todos los miembros de un nivel de una dimensión: SELECT {[Product].[Product Department].Members} on columns FROM Sales El resultado es ahora mucho más largo, ya que muestra todos los departamentos de producto existentes en el cubo.

Se puede introducir un segundo eje, como el nivel de ingresos de los compradores: SELECT {[Product].[Product Department].Members} on columns, {[Yearly Income].[Yearly Income].Members} on rows FROM Sales Siendo el resultado de la consulta, aunque no se muestre completo, este:

El girar el cubo es tan sencillo como cambiar las dimensiones mostradas en cada eje: SELECT {[Yearly Income].[Yearly Income].Members} on columns, {[Product].[Product Department].Members} on rows FROM Sales WHERE [Measures].[Unit Sales] En este caso el resultado, (igualmente incompleto) queda así:

Se comentó más arriba que las medidas pueden tratarse como si fueran una dimensión más del cubo. Arriba, en la segunda consulta de ejemplo, ya se vio como se podía utilizar la dimensión Measures como rebanador.

Aquí se muestra una consulta que utiliza la dimensión Measures para definir un eje: SELECT {[Measures].[MeasuresLevel].Members} on columns, {[Product].[Product Department].Members} on rows FROM Sales Siendo este el resultado:

Para terminar, este es un ejemplo de una expresión que contiene varios rebanadores, y que muestra una información muy concreta del cubo original: SELECT {[Product].[All Products].[Drink].[Alcoholic Beverages].[Beer and Wine], [Product].[All Products].[Drink].[Beverages].[Carbonated Beverages], [Product].[All Products].[Drink].[Beverages].[Pure Juice Beverages]} on columns, {[Promotion Media].[All Media].[TV]} on rows FROM Sales WHERE ([Customers].[All Customers].[USA].[CA], [Time].[1997].[Q2], [Marital Status].[All Marital Status].[M], [Measures].[Profit]) Esta consulta devuelve los beneficios (Profit) de las ventas de cerveza y vino, bebidas gaseosas y zumos, en California (CA), en el segundo trimestre del 97 (Q2), para los casados (M), mostrando las cifras para las promociones de TV y Radio.

Se puede apreciar que hay celdas, filas y columnas vacías. Las filas o columnas completamente vacías pueden eliminarse del resultado anteponiendo las palabras claves NON EMPTY a la especificación del eje correspondiente: SELECT NON EMPTY {[Product].[All Products].[Drink].[Alcoholic Beverages].[Beer and Wine], [Product].[All Products].[Drink].[Beverages].[Carbonated Beverages], [Product].[All Products].[Drink].[Beverages].[Pure Juice Beverages]}

on columns, NON EMPTY {[Promotion Media].[All Media].[TV]} on rows FROM Sales WHERE ([Customers].[All Customers].[USA].[CA], [Time].[1997].[Q2], [Marital Status].[All Marital Status].[M], [Measures].[Profit]) Y el resultado de la consulta pasa a ser este orto:

Sólo se ha mostrado la sintaxis más básica de MDX. Este lenguaje de consulta es, como puede imaginarse, mucho más potente. En el siguiente apartado se comentan más posibilidades ofrecidas por MDX.

¿Qué más puede hacerse con MDX? El lenguaje MDX permite hacer consultas muy avanzadas, obteniendo información que no está directamente disponible en las dimensiones del cubo. Por poner algunos ejemplos:

• •

•

• •

Pueden combinarse varias dimensiones en solo eje, haciendo que una dimensión subdivida a otra. Esto también es algo muy habitual en los clientes OLAP. Pueden realizarse consultas con miembros y celdas calculadas: esto permite calcular una nueva medida a partir de otras medidas existentes en un cubo, o crear un nuevo miembro que englobe la dimensión de varios miembros existentes.

Es posible crear consultas que ordenen y filtren el cubo basándose en los valores de las celdas (medidas), en vez de basarlo en los nombres de los miembros de las dimensiones. Entre otras cosas esto permite realizar análisis ABC, o de Pareto, u 80/20, como se prefiera llamarlo, sobre los miembros de una dimensión.

Se pueden realizar agregaciones de datos (sumas, medias, máximos, etc.) del mismo modo que en SQL. Entre las agregaciones, un caso algo especial son los recuentos y, especialmente, los recuentos distintivos, que respondan a preguntas como cuantos clientes han comprado un producto determinado en un rango de fechas dado, o cuantos clientes han comprado dos productos concretos en otro rango de fechas determinado.

Algunas de estas consultas no son tan fáciles de realizar como podría pensarse y requieren un conocimiento y una experiencia grande en MDX, del mismo modo que sucede con las consultas SQL complejas. Aún más, hay determinadas consultas MDX capaces de proporcionar información que aparentemente no existe en el cubo. Solo una gran dosis de experiencia permite conocer las posibilidades reales de este lenguaje.

¿Cómo seguir avanzando?

Quizás usted se encuentre involucrado ahora, o vaya a estarlo en algún momento del futuro próximo, en un proyecto en el que necesite realizar este tipo de consultas… incluso puede que su proyecto consista en la implantación de un Data Warehouse completo o en la creación de los cubos. Si es así, puede contar con los Servicios Profesionales de Danysoft para recibir la formación adecuada, o realizar la consultoría necesaria, para llevar su proyecto a buen puerto.

Para más información.

Si desea hacernos un comentario sobre este artículo, contáctenos en attcliente@danysoft.com o en el 902 123146.