Mais quelles sont donc ces fameuses fonctionnalités d'SSAS qui créent cette dépendance? On trouve pas mal d'informations contradictoires sur le sujet que ce soit sur les blogs ou les forums. D'où l'idée de ce petit post afin de clarifier tout ça.
Les fausses raisons
- Le Writeback: Pendant longtemps j'ai cru que la dépendance venait de cette fonctionnalité qui permet de modifier directement les cellules d'un cube sans modification de la table de faits sous jacente. Il n'en est rien. Quand un utilisateur saisie des données dans un formulaire sous Excel et qu'il les soumet, il y a alors une étape intermédiaire qui consiste à mettre ces données à jours dans la base relationnelle (datawarehouse) avant de reprocesser le cube (model). La fonction native de writeback d'SSAS n'est donc pas utilisée dans cette version de PPS.
- Le Pro-active Caching: J'ai pu lire sur plusieurs blogs que les cubes générés par Planning (lorsqu'on crée un model dans le Business Modeler) utiliseraient la fonctionnalité de proactive caching d'SSAS. Celle-ci permet un accès en "temps réel" aux dernières valeurs de la table de faits sous jacente au cube lorsque celui ci n'est pas encore reprocessé. Il s'avère qu'en ouvrant ces cubes dans management studio, on s'aperçoit vite que cette propriété n'est pas activée...donc fausse piste là aussi!
Si toutes ces raisons qui sont très largement reprises sur le net sont fausses, d'où vient donc cette dépendance du module Planning de PPS à la version Enterprise d'SQL Server? Il y en a t il réellement une au delà de l'aspect purement "licensing"? Je vous rassure, la réponse est oui :-)
Les vraies raisons
- L'intelligence financière: Dans PPS-P, une des dimensions préexistantes "Account" utilise une fonctionnalité "SSAS Enterprise only", celle des dimensions d'intelligence financière (Account Intelligence). Derrière ce nom un peu sophistiqué se cache en fait la possibilité de créer une dimension contenant différents comptes et de paramétrer correctement les agrégations en fonction du type de compte choisi. Typiquement, un compte de type "Asset" sera considéré comme un compte "debit" et aura une agrégation semi-additive.
- Les mesures semi-additives: C'est une conséquence directe de l'utilisation de l'intelligence financière. Certains types de comptes ont des mesures semi-additives. En opposition aux mesures additives classiques (sum par exemple), les mesures semi-additives ne s'agrègent pas sur la dimension temps. C'est logique, si sur un compte vous avez 1000€ en janvier, 1000€ en février et 1000€ en mars, afficher 3000€ comme valeur pour ce trimestre n'a aucun sens. C'est donc là qu'interviennent ces mesures semi-additives, comme "last non empty" par exemple qui afficherait ici 1000€ pour le trimestre.
- Les opérateurs unaires: Autre conséquence de de l'utilisation de l'intelligence financière. Certains types de comptes sont de type "debit", d'autres de type "credit". C'est ce qui définit la façon dont un compte doit être agrègé dans la hiérarchie "account". Ainsi les valeurs seront ajoutées ou soustraites lors des agrégation sur cette dimension en fonction de l'opérateur unaire défini.
Conclusion
Il y a donc bien une dépendance physique entre PerformancePoint Planning et SQL Server Enterprise; ce n'est pas seulement du "licensing".
Si vous ne possédez que la version standard de SQL Server, rassurez vous, vous pourrez tout de même utiliser PerformancePoint Server....mais uniquement les modules Monitoring & Analytics.
Ps: Il est possible qu'il y ait d'autres dépendances qui m'aient échappées. N'hésitez pas à réagir dans les commentaires si c'est le cas!
.png)
.png)
Aucun commentaire:
Enregistrer un commentaire