Rappel sur la notion d’objectifs
Quand on crée des KPI, on a besoin de travailler les objectifs des indicateurs.
On peut écrire les objectifs en dur dans les KPI (dans Analysis Services via Visual Studio ou dans un outil plus adapté comme le Dashboard Designer de Performance Point). Mais bien évidemment, ce n’est pas la “bonne pratique” recommandée.
La première étape est de créer une table d’objectifs. Vu du cube, c’est une simple table de faits, ventilée sur les dimensions adéquates. Cependant, il est rare que les objectifs soient connus (et encore moins saisis) à une granularité très fine.
Problématique
Prenons l’exemple d’une mesure chiffre d’affaire. En phase de planning budgétaire, on va déterminer les objectifs de CA par mois par exemple. Il y a rarement de linéarité sur cette mesure mais il est rare qu’on descende à la journée. 
Admettons qu’on veuille avoir un indicateur au jour le jour car on intègre des factures quotidennement. On va avoir un problème sur notre KPI car en début de mois, nous serons loin de l’objectif et nous ne pourrons savoir si on est “dans les clous” qu’une fois le mois quasiment terminé car le seul chiffre que l’on ait est celui du mois. Difficile de piloter de cette façon.
Solution(s)
L’idée est donc de proratiser notre objectif sur la dimension temps pour obtenir l’objectif sur la granularité voulue (dans notre exemple la jour). Je vous propose donc 3 solutions dans cet article :
Remplir la table de faits à la bonne granularité
La première solution est la plus simple car il suffit de remplir directement notre table d’objectifs à la bonne granularité et donc avoir un objectif quotidien.
Le problème de cette solution est qu’il faut modifier beaucoup de lignes si je devais revoir l’objectif d’un mois par exemple. Nous avons donc un problème de praticité même si évidemment, on ne remplit la table qu’une fois et on la modifie rarement.
Ventiler les objectifs dans le DSV
Le modèle d’Analysis Services permet d’avoir une abstraction sur le DatawareHouse via le DSV (Data Source View). Cette abstraction permet d’interférer sur le modèle de données via du code T-SQL.
La seconde solution utilise cette possibilité pour changer la granularité de la table d’origine. En T-SQL, on démultiplie les lignes afin d’en obtenir une par jour et on divise l’objectif selon le nombre de jours. Je vous passe le script car je ne souhaite pas focaliser sur cette méthode.
Ventiler les objectifs dans le cube
La troisième solution est d’opérer la ventilation non pas en T-SQL mais dans le cube, en MDX.
Pour cela, il suffit tout simplement de surcharger le calcul des cellules du cube et le langage MDX nous permet de le faire simplement. On utilise l’instruction SCOPE et on redéfinit le contenu de la cellule. Cela se fait dans l’onglet Calculations d’un cube dans Visual Studio.
Scope
( { [Temps].[Calendrier].[Date] }, { [Measures].[Budget] } );
This =
([Temps].[Calendrier].Parent)
/
[Temps].[Calendrier].CurrentMember.Siblings.Count;
End Scope;
La première partie du script définit la portée du calcul. Jusqu’à l’instruction End Scope, on est donc borné à la mesure Budget au niveau Date, plus rien d’autre n’existe.
This= redéfinit les cellules de la portée avec un nouveau calcul. Ici, je prends le tuple parent (donc le budget du niveau mois, qui, lui, est défini) et je le divise par le nombre de dates en dessous (ie. le nombre de jours dans le mois).
J’obtiens donc une proratisation du budget mensuel par jour.
A noter qu’avec le scope, je ne perturbe pas le niveau mois car ce script passe après le calcul initial des cellules (CALCULATIONPASS, mais ça c’est une autre histoire 
).
Conclusion
Je n’ai pas de préférence pour l’une ou l’autre de ses méthodes. La plus technique est sans aucun celle en MDX. Toutefois, utiliser un script T-SQL dans le DSV est pragmatique car on s’appuie ensuite sur la simplicité de l’aggrégation du cube.
D’un point de vue performances, je n’ai jamais fait de tests. Je le mets dans ma TODO-List et ce sera l’occasion d’un nouvel article.
Je reviens sur un post qui date de plus de 2 ans : 
).
Cas pratique : obtenir la liste des attributs des dimensions leurs caractéristiques et leurs croisements avec les groupes de mesures (sous format exploitable type Excel évidemment).
.
