[SSAS] Réhabilitation des ParentChild (ou pourquoi elles ne sont pas le mal absolu)

Je discutais l’autre jour avec quelques confrères lorsque j’ai entendu cette phrase au milieu d’un brouhaha technique.

« … les ParentChilds il faut que vous les enleviez: question performance c’est nul, fonctionnellement ça ne sert à rien. Analysis Services n’est pas fait pour ça, il les ont laissées pour s’adapter à certains types d’architectures existantes. Il suffit de lire le Performance Guide. »

Je n’aime pas ce genre d’affirmation pontifiante. D’autant plus quand, comme toute assertion de ce type, elle s’inspire de faits et documents réels en les dénaturant.

Je me propose donc modestement de remettre un petit peu de clarté la dedans.


« Les ParentChild, question performance c’est nul »

Les faits: dans une hiérarchie ParentChild, les aggrégations ne sont créées que pour l’attribut clé et le membre de All de la hiérarchie. Dit autrement des aggrégations ne sont pas calculées sur les niveaux intermédiaires.

Réponse: Le coupable serait donc l’absence de calcul d’aggrégats. Ceux ci sont certes très utiles et jouent un rôle crucial. Mais considérer qu’ils constituent l’unique intérêt de l’OLAP et que leur absence est dans tous les cas catastrophique en terme de performances témoigne d’une certaine méconnaissance de ce genre de systèmes. L’idée de l’OLAP est certes de précalculer mais avant cela de se baser sur un formalisme de stockage spécifique permettant rapidement de récupérer les informations. Un cube même sans aggrégats est bien plus efficace qu’une base relationnelle pour les calculs multidimensionnels habituels.

Une ParentChild n’est donc pas en tous les cas catastrophiques en termes de performances… Tout dépend de la volumétrie!
Plus troublant dans certains cas une utilisation extensive du HideMemberIf dans des hiérarchies naturelles – pour permettre de disposer de hiérarchies irrégulières sur de nombreux niveaux – fait qu’une ParentChild peut être plus performante. (cf ce post d’Ajit Singh pourtant grand pourfendeur des P/C sur SSAS-Info).

« Il suffit de lire un peu la documentation enfin! »

Les faits: le Performance Guide déconseille d’utiliser les ParentChilds et recommande de passer à un design naturel… …mais sur de grosses volumétries et sur beaucoup de dimensions et dans le cas ou fonctionnellement l’alternative est possible, comme visible ci dessous:

Réponse: il s’agit simplement d’un raccourci sur le propos de cet excellent guide. L’extrait est ci-dessous.

If you are in a design scenario with a large parent-child hierarchy (greater than 250,000 members), you may want to consider altering the source schema to re-organize part or all of the hierarchy.

Analysis Services Performance Guide

« Fonctionnellement ça ne sert à rien. »

Les faits: Je crois que c’est l’assertion la plus stupide. Cela ne se base sur rien et vient simplement d’un bouche à oreilles général.

Réponse: Il est facile de trouver quelques cas où la modélisation sans ParentChild est fastidieuse. Même Mosha en convient, au début de ce post.

1) Un bien connu est une hiérarchie opérationnelle récursive: les faits ne se situent pas au niveau le plus bas mais potentiellement partout (au niveau du manager, d’un membre de son équipe…). Les règles de Rollup sont de plus potentiellement compliquées.
En Ragged c’est un enfer à gérer. En ParentChild cela se fait simplement. Et il est rare de disposer de plusieurs centaines de milliers de membres dans ce genre de dimension…

2) Un autre exemple est une hiérarchie de type plan de compte, sur le même modèle ou chaque élément de fait peut référencer un niveau qui n’est pas le plus bas. Dans ce scénario de plus, il est fréquent que les utilisateurs veuillent utiliser les indicateurs de plusieurs niveaux dans la même colonne d’un rapport Excel, et donc disposer de deux représentations: sur un niveau et multi-niveau: le ParentChild est la seule manière d’arriver à cela simplement. De plus là aussi on atteint rarement une volumétrie énorme!

D’ailleurs AdventureWorks contient deux exemples identiques… modélisés en ParentChild -Organization et Account. Pourquoi diable les montrer dans des exemples fonctionnels si comme certains l’affirment « le ParentChild n’est là que pour la compatibilité avec des existants ou des habitudes« .


En conclusion les P/C sont moins performantes que les hiérarchies naturelles sur des grosses volumétries de par leur lacune dans le calcul des aggrégats. Elles sont cependant une nécessité fonctionnelle dans certains cas et il est absurde de s’empêcher de les utiliser sous des prétextes fallacieux.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s