J’aime beaucoup les Many-to-Many sur SSAS, surtout que la
littérature pour un sujet aussi anodin en apparence est assez conséquente. J’aime
surtout les Many-to-Many quand il faut les expliquer à un utilisateur qui ne
comprend pas pourquoi la somme de ses lignes n’est pas égale à la cellule du
grand total.
Pour illustrer notre sujet du jour, voici une base de
données se proposant de permettre à mon entreprise préférée l’analyse du
montant de ses ventes (FactSale) en fonction des raisons de la vente
(FactSaleReason) et du revenu de ses clients (FactIncome). Imaginons que nous
retournions à un mode de rétribution à la journée, ça facilite un peu l’interprétation
de notre cas d’étude.
Etant donné qu’un client peut effectuer plusieurs achats
dans les magasins, qu’il peut avoir plusieurs raisons d’achat pour une vente et
qu’il peut percevoir plusieurs rentrées d’argent par jour (salaire, dividende,
redistribution de la part de l’état), on a donc des Many-to-Many croisées entre
ces trois périmètres d’analyse. Au domaine métier près, c’est une modélisation
que je viens de voir chez un de mes clients. Je vous l’accorde, certain
rapprochement sont tendancieux (l’analyse des raisons de la vente en fonction
du revenu notamment, encore que la corrélation de ces deux éléments n’est pas
neutre).
Soit la première analyse permise par mon cube (et connue d’une
bonne partie d’entre vous) : la ventilation du montant de mes ventes en
fonction des raisons d’une vente.
On constate une chose habituelle dans le cas d’une
Many-to-Many, à savoir un excès sur la somme des lignes par rapport au grand
total. C’est visible ici sur le mois de janvier. C’est tout simplement du au
fait que pour une vente sur ce mois, il y a eu plusieurs raisons d’achat –
étant donné la complexité importante de ma base, on pourra supputer que la
vente en question vaut 3 et que les raisons de cette vente sont le prix et la
pub. Une fois expliqué à nos utilisateurs favoris, il se passe des mois sans qu’ils
reviennent vers vous en signalant un problème dans les données. Sauf que, après
ce moment de répit, il se passe L’AUTRE cas, à savoir un défaut par rapport à
la somme globale.
Imaginons maintenant une autre analyse : le montant de
mes ventes en magasin en fonction des revenus de mes clients. Il est important
pour l’analyse de savoir par magasin, quel était le revenu du client. C’est le
rôle de la Many-to-Many qui, dans les trois cas suggérés par la base AS, est
construite sur les dimensions Date et Customer. Comme je l’ai expliqué dans un
billet précédent, lorsqu’une Many-to-Many utilisent plusieurs dimensions, alors
toutes les dimensions sont utilisées dans la résolution de la requête (voir :
).
Mes clients dépensent-ils plus quand ils gagnent plus ?
Outre le fait que les données ont été créées à la main et sans aucune attention
portée à leur cohérence, cette question soulève d’autres points en rapport à l’activité
économique du moment (si ça vous intéresse, les sujets autour de l’inflation/déflation
et du taux d’épargne/dépense des ménages
sont à la mode en ce moment).
Bref, contrairement à la fois dernière, la somme de mes
lignes de revenu est inférieure à la somme globale. L’explication est que tous
les jours, mes clients gagnent de l’argent mais, malheureusement pour mon
entreprise, ils ne vont pas pour autant faire des achats chaque jour. Et ça pour
mes utilisateurs, c’est tout nouveau et même si l’analogie avec mon excès sur
la somme de mes lignes est forte, comprendre un défaut sur cette somme leur est
très compliqué.
Du coup, puisque s’en est trop, puisque pour le défaut sur
la somme est hors du champ de compréhension de mes utilisateurs, comment
puis-je les satisfaire et faire en sorte que la somme globale soit égale à la
somme de mes lignes (il faut bien noter ici que mon utilisateur est catastrophé
car les chiffres qu’il voit ne sont pas bons pour lui et qu’il a à peine
sous-entendu qu’une correction A LA MAIN du total était envisagée). J’avais
commencé à jouer avec du SCOPE dans mon Calculation Script jusqu’à ce que je me
pose la bonne question : que représente ma somme globale, en ligne/colonne
si elle ne reflète pas la somme des lignes/colonnes ? Tout simplement l’agrégation
de mes mesures dans l’espace de cube auxquelles ces cellules appartiennent à
savoir ici, pour la valeur 45 de l’Income du mois de janvier, le ALL de ma
dimension Store et le membre January de mon attribut Month (je passe sous
silence les coordonnées des autres dimensions). Du coup, ce qui me gène c’est d’être
sur le All de la dimension Store. Qu’à cela ne tienne, je vais la filtrer. Je
vais par exemple supprimer de mon analyse les membres Unknown et Store3 pour
lesquels je n’ai pas de valeur :
Et maintenant, TADAAAAAA :
Et à ce moment, dans les yeux de mon utilisateur, une
lumière brille. Non pas qu’il ait compris ce que je viens de coucher sur le
doux papier de ce blog et que je me suis évertué à lui expliquer, mais parce qu’il
n’a plus à justifier que la somme de ses lignes est différente de la somme
totale.
Tout ça pour ça vous dîtes vous, mais la satisfaction de son
client n’a pas de prix. Le goût des choses simples (sur un petit air de Pierre
Bachelet). Mais ça permet surtout de refaire un point sur le fonctionnement des
Many-to-Many.
Bonjour
RépondreSupprimertrès intérissant. Est-ce que vous pouvez juste ajouter le script MDX ajouté au niveau de l'onglet calculation