Many-to-Many et agrégations

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.