Business Geek

Je rencontre fréquemment en consulting des problématiques relatives aux budgets et/ou aux prévisionnels à intégrer dans un cube.

Comme souvent en décisionnel, il y a de nombreuses façons de traiter (concevoir) ce type de fonctionnalité et le but de ce post n’est en aucun cas de rédiger un état de l’art sur le sujet.

Je propose en règle générale 2 approches :

• utilisation d’une table de budgets
• utilisation d’une dimension scénario

Je vais passer vite sur la première approche puisqu’elle consiste à ajouter des mesures représentant les budgets. Bien souvent, on a un table de faits dédiée (et donc un groupe de mesure). On peut donc jouer avec les mesures Ventes et Ventes prévues par exemple.

J’aime cette approche car elle permet d’avoir une granularité différente de la table de faits principale (qu’on résout par des Cube Calculation mais c’est une autre histoire ).

La dimension Scenario

L’idée de cette approche consiste à créer une nouvelle dimension qui contient les scénarios de travail comme par exemple Courant (Actual), Budget 1, Budget 2, Prévisionnel (Forecast), etc.

On ajoute donc une clé dans la table de fait pour le scénario pour gérer la nouvelle dimension. Cela permet d’avoir une infinité de scénarii, utile en période de planification budgétaire (d’ailleurs les utilisateur de feu Planning Server connaissent très bien cette approche).

C’est cette technique qui est utilisée dans la réalisation de cubes comptable.

Evidemment, on utilisera un Default Member sur cette dimension afin de ne pas perturber l’usage en affichant naturellement le scénario courant.

Pour générer et alimenter automatiquement une table de dimension temps, il  existe une option dans l’assistant de création des dimensions de BIDS.

Créez une nouvelle dimension en suivant les étapes suivantes :

Choix de la bonne option

Choix de la plage de dates

Démarrage de l’assistant de génération de la table dans le DataWarehouse

Ne pas oublier de choisir l’option Populate pour générer les enregistrements

A ce stade, la table est générée et alimentée.

Pour anticiper le passage en production, je mets un profiler sur ma base de développement pour récupérer le script de remplissage (populate).

Je refais la même manipulation pour mettre à jour la dimension temps. En effet, on ne mets pas toujours toutes les dates possibles dans la dimension et je prends l’habitude de mettre un reminder fin novembre pour alimenter l’année qui arrive. (voire faire un script qui la génère automatiquement).

PS : merci Philippe de l’équipe DGD de Bewise pour les screenshots.

Les attributs d’une dimension dans un cube servent à la base à analyser les données selon les valeurs qu’ils contiennent. Par exemple, dans une dimension produit, on peut avoir des attributs comme la couleur, le poids, la gamme, le nom du designer qui l’a créé, etc.

Dans la vraie vie, une dimension peut contenir un grand nombre d’attributs. Le problème est que souvent, certains attributs n’ont rien à voir avec de l’analyse. Par exemple, un attribut Adresse dans une dimension client n’est pas un bon candidat pour l’analyse (et je parle bien de l’adresse du genre “3 rue des macarons cuits”, pas de la ville ou du code postal).

Néanmoins, on trouve souvent ce genre d’attributs à des fins de présentation dans un rapport (pour du publipostage ou de l’export par exemple).

Mon premier avis serait d’orienter ce genre de restitution de données vers une base de production (ou tout du moins dans une base relationnelle) comme source de données et non un cube mais ce n’est pas toujours possible.

L’approche que j’utilise est la suivante. Je catégorise avec mon client les attributs :

• Attribut d’analyse : utilisé pour ventiler les mesures
• Attribut intermédiaire : attribut technique utilisé dans une Referenced Dimension Usage par exemple
• Propriété simple : utilisé pour afficher des méta-données sur le client

En fonction de ma classification, je configure les attributs différemment pour optimiser mon cube :

Il y a toutefois encore un problème à résoudre. En effet, le fait de mettre AttributeHierarchyEnabled à false, empêche de voir la propriété dans les assistants d’un outil comme Report Builder.

En effet, en requêtage MDX, on récupère un CellSet qui peut contenir, si on les demande dans la requête, les méta-données mais il faut que le client OLAP sache les exploiter correctement.

Par exemple, Excel (2007+) sait les demander et les afficher nativement.

Dans Report Builder, on devra passer par un membre calculé pour remonter la propriété comme une mesure avec une expression comme celle-ci.

[Tiers].CurrentMember.Properties(“Adresse”)

La méthode est décrite dans ce post :
 http://blog.djeepy1.net/2009/01/27/report-builder-2-0-creer-un-membre-calcule-sans-passer-par-ssas/