Reflexiones sobre la dimensión Tiempo

Hoy he estado trabajando corrigiendo la dimensión “tiempo” de uno de mis cubos para Analysis Services 2005. Resulta que ayer, escribiendo unas queries MDX, me di cuenta de que para analizar si determinado patrón se produce siempre en una determinada época del año (por ejemplo, queremos comparar las ventas realizadas durante toda la época de rebajas) lo tenemos complicado si sólo disponemos de la dimensión “tiempo”. Me explico

Supongamos que queremos estudiar la evolución de las ventas durante los meses de rebajas. Si partiésemos de un cubo en el que una de las dimensiones fuese “promociones” y la otra fuese el “tiempo”, el tema estaría chupado… ¿no? Bastaría con seleccionar las ventas por meses y filtrar para “[promociones].[rebajas]”. Lo que pasa es que no siempre tenemos esa segunda dimensión por la que filtrar, y muchas veces nos vemos obligados a filtrar en función del nombre del mes. Eso es exactamente lo que quería hacer ayer… filtrar la ocurrencia de un determinado evento todos los meses de verano. Lo curioso es que la expresión MDX que me surgió, resultó ser mucho más complicada de lo que esperaba: ¡me obligó a escribir un set en el que se agrupaban los meses de verano! Eso es básicamente porque las dimensiones son jerárquicas, y uno siempre se encuentra problemas si quiere obtener todos los hechos referentes a un valor que se repite a lo largo del mismo nivel de la dimensión. Por ejemplo:

  • 2001
    • Trimestre 1
    • Trimestre 2
    • Trimestre 3
    • Trimestre 4
  • 2002
    • Trimestre 1
    • Trimestre 2
    • Trimestre 3
    • Trimestre 4

Si queremos obtener las ventas del conjunto de “Trimestres 3” a lo largo de todos los tiempos, tenemos que andar escribiendo sets, o realizando filtrados chapuceros en función del nombre del mes. Sin embargo, si el conjunto estuviese ordenado de la siguiente forma:

  • Trimestre 1
    • 2001
    • 2002
  • Trimestre 2
    • 2001
    • 2002
  • Trimestre 3
    • 2001
    • 2002
  • Trimestre 4
    • 2001
    • 2002

El problema tendría una solución muchísimo más sencilla.

No se si equivocadamente o no, he adoptado la solución de añadir los dos niveles de jerarquías en mi dimensión tiempo… uno con agregación MOLAP y el otro (menos común) con agregación ROLAP. Más que nada, de esta forma la estructura es mucho más rica en metadatos, y le puede ayudar al analista a adoptar uno u otro tipo de análisis. Sin embargo, me marcho a la cama sin poder olvidar este problema… y es que sin duda, la solución ideal hubiese sido tener una segunda dimensión por la que filtrar. Vamos, sin ninguna duda.

Que importante es estudiar muy bien las dimensiones sobre las que vamos a querer realizar futuros estudios…

En fin, si alguien piensa que lo que he hecho es una animalada, que no dude en contestarme. Yo seguiré reflexionando sobre el problema… no puedo dejar de pensar que tiene que haber soluciones más sencillas al problema.

Un comentario sobre “Reflexiones sobre la dimensión Tiempo”

  1. Cuando este post fue publicado en «MSN Spaces», recibió una serie de comentarios que voy a adjuntaros porque considero interesantísimos:

    ————-

    Sigo reflexionando sobre el tema, y he llegado a la conclusión de que a pesar de dar dimensiones con niveles jerárquicos, nunca está de más que expongamos la esa misma dimensión “aplandada”, es decir:

    Fecha:
    – Año
    – Mes
    – Día
    – Mes
    – Día

    De esta forma siempre se podrá filtrar por cualquiera de los niveles:

    Select [measures].[ventas] on rows
    [Fecha].[Mes] on columns
    Where [Fecha].[Mes].&[8]

    Una expresión similar a esta nos podría dar las ventas a lo largo de los distintos meses de agosto, mientras que si sólo hubiésemos dejado la jerarquía “Año-Mes-Día” la consulta sería muchísimo más complicada.

    Publicado por: Gorka

    ————-

    Es mas sencillo si creas una jerarquia usando solo esos 2 atributos de la dimension. Si no tenes un atributo trimestre en la tabla de origen es muy facil crear una named column que contenga ese valor.

    Publicado por: Pablo Mugica

    ————-

    Estoy añadiendo funcionalidad a una aplicación «cerrada» que se vende a terceros, así que en principio, no es sencillo modificar las dimensiones a posteriori (ojo, que al final a lo mejornos decantamos por un diseño guiado por metadatos y damos al usuario final una herramienta con la que sea capaz de modificar los cubos… ¿os había dicho que tiene que funcionar sobre SQL Server y Oracle?). A lo que voy es a que lo ideal sería que el diseño original de las dimensiones fuese lo suficientemente genérico. Por eso, mi conclusión final ha sido modelar la dimensión de la siguiente forma:

    /Tiempo
    +—Año
    | +—- Trimestre
    | +—– Mes
    +—Trimestre
    +—Mes

    De todas formas, estoy de acuerdo en que la solución más sencilla es organizarte la jerarquía de forma que se facilite la consulta, o bien tener una segunda dimensión con la que coger un «slice» de los datos adecuado. El problema es que ambas soluciones requieren que tengas previamente el esquema adecuado (o que tengas la posibilidad de modificar el esquema en el momento de realizar la consulta).

    Publicado por: Gorka
    ————-

    Exacto, y esto es mucho + facil en AS2005 porque lo sque compone una dimensión no son los niveles y las jerarquías sino los atributos. Podemos tener las jerarquías que queramos combinando los atributos de la misma.

    Publicado por: Pablo Mugica
    ————-

    Quiero decir que coincido con tu último comentario, pero que al usar solo 3 atributos podés incluir todas las combinaciones que consideres necesarias como jerarquías 🙂

    Publicado por: Pablo Mugica

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *