[MDX] ParallelPeriod sur hiérarchies multiples


mdx_parallelperiod

L’intelligence temporelle est une des fonctionnalités phares du décisionnelle. Le MDX est conçu pour répondre simplement à ce besoin. Cependant la mise en œuvre n’est pas si trivial qu’il n’y parait et il est bon de prendre en compte un certain nombre de point avant de se lancer.

Beaucoup de littérature a déjà été écrite sur le sujet, il y a des années de cela. En commençant par le whitepaper de David Shroyer, A Different Approach to Implementing Time Calculations in SSAS. Cet article, sous forme de tutoriel, montre comment créer une dimension technique (shell dimension) pour projeter toute ou partie des mesures d’un cube afin d’y appliquer des calculs temporels. Ceci est un moyen puissant de factorisation et offre une boite à outil très utile pour les utilisateurs.

Cet article a été repris par Mosha Pasumansky, un des créateurs du MDX, avec son article Time calculations in UDM: Parallel Period. où il propose une méthode alternative à celle de David Shroyer, plus performante.

Le recours à des fonctions temporelles en MDX est courant, l’utilisation des plusieurs hiérarchies sur la dimension temps l’est tout autant. La fonction ParallelPeriod est quasi incontournable quand il s’agit de mettre en oeuvre de la Time Intelligence, même si Mosha montre que l’on peut remplacer son utilisation par les fonctions Lag et Prevmember, modulo quelques imperfections à mon sens. En outre parce que le nombre d’enfant d’une semaine au sein d’une année n’est pas fixe. Il peut être égale à 52 ou 53.

Je préfère donc l’approche qui consiste à utiliser la fonction ParallelPeriod. Cependant, il faut savoir que la fonction ParallelPeriod ne fonctionne correctement que si le design de votre dimension est adapté.

Présentation du problème :

Présentons d’abord les hiérarchies en jeu :

Pour des raisons de performances, on essaiera de rendre ces hiérarchies naturelles, c’est à dire que l’on créera les relations entre les attributs.

Note : La non définition des relations d’attributs ne nous donnerait pas des résultats différents. La différence ne se situerait qu’au niveau du stockage.

Intuitivement, la modélisation d’attribut qui vient est sous forme de diamant :

Attribute_relationships_diamant

Cette modélisation semble juste et pourtant cela nous causera un problème dans notre script  pour la simple et bonne raison qu’un attribut est partagé entre les 2 hiérachies et que cela créera une confusion pour la fonction ParallelPeriod qui ne sera capable de sélectionner la bonne hiérarchie.

Créons le script suivant :

  1. Nous créons une mesure vide
  2. Nous faisons un premier scope sur la mesure
  3. Nous scopons d’abord sur le niveau le plus élevé de la hiérarchie et sur la clé de la dimension date afin de sélectionner tous les membres de la hiérarchie et de lui appliquer notre calcul.
  4. Nous scopons sur la seconde hiérarchie de la même manière afin d’affecter les valeurs sur l’autre hiérachie.

La conséquence sur le résultat est :

Resultat_Excel_diamant*

Nous pouvons constater qu’une seule des 2 hiérarchie est peuplée et que c’est le dernier scope qui a pris le dessus.

Solution :

Nous pouvons corriger cette anomalie en rompant ce partage d’attribut entre ces 2 dimensions et de manière transparente pour l’utilisateur. Il suffit juste de :”

  1. Créer un attribut distinct pour les années

distinct_attributes

  1. Créer 2 chemins distinct afin de dissocier totalement les 2 hiérarchies

Attribute_relationships_separe

Si on déploie les changements et actualise la feuille Excel, nous constatons que le problème est résolu et le niveau intermédiaire de chacune des 2 dimensions est correctement peuplé.

Resultat_Excel_separe

J’espère que ces explications pourront vous êtes utiles sur vos projets.

Commentez cet article