De nombreux utilisateurs demandent souvent à voir des données groupées de différentes façons. Dans le cas le plus simple, un service, comme le marketing, veut voir les clients regroupés selon une hiérarchie donnée et un autre service, comme le commercial, veut les voir dans une hiérarchie différente. Lorsque c'est simple, il est logique d'inclure les deux hiérarchies dans la dimension Client et de les nommer distinctement. Malheureusement, il est possible de construire de nombreuses hiérarchies dans une dimension avant que cela ne devienne inutilisable.
La nécessité d'adapter de manière plus souple les hiérarchies alternatives se produit donc lorsque plusieurs services veulent voir les choses à leur façon, et veulent voir cela de plusieurs manières. Dans ce cas, nous travaillons généralement avec les utilisateurs pour définir le moyen le plus courant de regrouper les données. Cela devient ensuite la norme ou la hiérarchie par défaut dans la dimension de base. Toutes les autres hiérarchies couramment utilisées sont également intégrées dans la dimension afin de simplifier le travail des utilisateurs.
Nous proposons ensuite une table de hiérarchie alternative qui permet aux utilisateurs de manipuler les données en fonction de leur choix et des hiérarchies alternatives disponibles. La figure ci-dessous montre un exemple d'une table intermédiaire de hiérarchie alternative appelée CustomerRegionHierarchy pour aligner les régions géographiques.
Chaque hiérarchie de la table des hiérarchies alternatives doit inclure toute la hiérarchie de son attribut le plus fin, qui sert de jointure avec la dimension associée, à celui le plus haut. Dans le cas illustré ici, la hiérarchie commence au niveau de l'état (State) et remonte à partir de ce point. Il est également possible de commencer à un niveau de détail plus fin, le code postal par exemple, mais cela rendrait la table intermédiaire plus grosse et n'apporterait pas d'avantages supplémentaires. D'un autre coté, s'il y a besoin de créer des groupes de codes postaux dans les états, la table hiérarchique intermédiaire doit évidemment commencer au niveau du code postal.
Pour simplifier les rapports et analyses, la table intermédiaire inclue la définition de la hiérarchie standard. Ce choix devient alors celui par défaut dans tous les rapports structurés, permettant aux utilisateurs de changer ensuite entre la hiérarchie standard et les hiérarchies alternatives. La création d'une table Hiérarchie séparée simplifie la maintenance en ayant une ligne par hiérarchie, mais accroit la complexité visuelle. Cette table peut également être dénormalisée dans la table intermédiaire.
La table CustomerRegionHierarchy peut être utilisée dans les rapports structurés ou par les utilisateurs avancés. La jointure avec la table Client entrainera des cumuls inexacts à moins que le champ HierarchyName soit filtré sur une hiérarchie unique. Tous les rapports structurés qui ont accès à la table des hiérarchies alternatives peuvent être construit en utilisant la hiérarchie par défaut et devraient posséder un filtre choisir une seule hiérarchie.
La table des hiérarchies alternatives est un exemple de valeur ajoutée dans un entrepôt de données. Ce genre de regroupement personnalisé est couramment utilisé par les métiers, mais les définitions sont rarement centralisées et gérées de manière formelle. Habituellement, elles sont stockées dans un fichier Excel sur un ordinateur personnel.
Article original "Kimball Design Tip #62: Alternate hierarchies", publié le 7 décembre 2004.