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 :
|
Enabled |
Visible |
OptimizedState |
|
| Attribut d’analyse |
True |
True |
FullyOptimized |
| Attribut intermédiaire |
True |
False |
NotOptimized |
| Propriété |
False |
N/A |
NotOptimized |
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/
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).
