una descripcion de alfo

1. 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

2. • 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.

3. 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.

4. 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á.

5. 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:

6. 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

7. 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:

8. 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:

9. 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]}

10. 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.

11. 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.