Hiérarchies utilisateur

Les hiérarchies définies par l’utilisateur sont des hiérarchies définies par l’utilisateur des attributs utilisés dans Microsoft SQL Server Analysis Services pour organiser les membres d’une dimension en structures hiérarchiques et fournir des chemins de navigation dans un cube. Par exemple, le tableau suivant définit une table de dimension pour une dimension de temps. La table de dimension prend en charge trois attributs, nommés Year, Quarter et Month.

Les attributs Year, Quarter et Month sont utilisés pour construire une hiérarchie définie par l’utilisateur, nommée Calendar, dans la dimension de temps. La relation entre les niveaux et les membres de la dimension Calendrier (une dimension régulière) est illustrée dans le diagramme suivant.

Structures membres

À l’exception des hiérarchies parent-enfant, les positions des membres de la hiérarchie sont contrôlées par l’ordre des attributs dans la définition de la hiérarchie. Chaque attribut de la définition de hiérarchie constitue un niveau dans la hiérarchie. La position d’un membre au sein d’un niveau est déterminée par l’ordre de l’attribut utilisé pour créer le niveau. Les structures membres des hiérarchies définies par l’utilisateur peuvent prendre l’une des quatre formes de base, selon la façon dont les membres sont liés les uns aux autres.

Hiérarchies équilibrées

Dans une hiérarchie équilibrée, toutes les branches de la hiérarchie descendent au même niveau, et le parent logique de chaque membre est le niveau juste au-dessus du membre. La hiérarchie Des catégories de produits de la dimension Product dans l’exemple de base de données Adventure Works DW Multidimensional 2012 Analysis Services est un bon exemple de hiérarchie équilibrée. Chaque membre du niveau Nom du produit a un membre parent au niveau Sous-catégorie, qui à son tour a un membre parent dans le niveau Catégorie. En outre, chaque branche de la hiérarchie a un membre feuille dans le niveau Nom du produit.

Hiérarchies déséquilibrées

Dans une hiérarchie déséquilibré, les branches de la hiérarchie descendent à différents niveaux. Les hiérarchies parent-enfant sont des hiérarchies déséquilibrées. Par exemple, la dimension Organisation dans l’exemple de base de données Adventure Works DW Multidimensional 2012 Analysis Services contient un membre pour chaque employé. Le PDG est le premier membre de la hiérarchie, et les gestionnaires de division et secrétaire exécutif sont immédiatement sous le PDG. Les gestionnaires de division ont des membres subordonnés, mais le secrétaire exécutif ne le fait pas.

Il peut être impossible pour les utilisateurs finaux de faire la distinction entre les hiérarchies déséquilibrées et ragrées. Toutefois, vous utilisez différentes techniques et propriétés dans Analysis Services pour prendre en charge ces deux types de hiérarchies. Pour plus d’informations, consultez Hiérarchies ragged et Attributs dans Parent-Child Hiérarchies.

Hiérarchies irrégulières

Dans une hiérarchie ragged, le membre parent logique d’au moins un membre n’est pas dans le niveau immédiatement au-dessus du membre. Cela peut entraîner la descente des branches de la hiérarchie à différents niveaux. Par exemple, dans une dimension Geography définie avec les niveaux Continent, CountryRegion et City, dans cet ordre, l’Europe membre apparaît dans le niveau supérieur de la hiérarchie, le membre France apparaît au niveau intermédiaire et le membre Paris apparaît dans le niveau inférieur. La France est plus spécifique que l’Europe, et Paris est plus spécifique que la France. Pour cette hiérarchie régulière, les modifications suivantes sont apportées :

• Le membre de la Ville du Vatican est ajouté au niveau CountryRegion.

• Les membres sont ajoutés au niveau ville et sont associés au membre de la Ville de Vatican au niveau CountryRegion.

• Un niveau nommé Province est ajouté entre les niveaux CountryRegion et City.

Le niveau province est rempli avec les membres associés à d’autres membres au niveau CountryRegion, et les membres du niveau Ville sont associés à leurs membres correspondants au niveau de la province. Toutefois, étant donné que le membre de la Ville du Vatican au niveau CountryRegion n’a aucun membre associé au niveau de la province, les membres doivent être associés directement au niveau Ville au membre de la Ville du Vatican au niveau CountryRegion. En raison des modifications, la hiérarchie de la dimension est maintenant raré. Le parent de la ville vaticane est le pays/région Vatican City, qui n’est pas dans le niveau immédiatement au-dessus du membre de la Ville du Vatican au niveau de la Ville. Pour plus d’informations sur les hiérarchies, consultez Hiérarchies déséquilibrées.

Parent-Child Hiérarchies

Les hiérarchies parent-enfant pour les dimensions sont définies à l’aide d’un attribut spécial, appelé attribut parent, pour déterminer comment les membres se rapportent les uns aux autres. Un attribut parent décrit une relation auto-référençante, ou auto-jointure, dans une table principale de dimension. Les hiérarchies parent-enfant sont construites à partir d’un attribut parent unique. Un seul niveau est attribué à une hiérarchie parent-enfant, car les niveaux présents dans la hiérarchie sont tirés des relations parent-enfant entre les membres associés à l’attribut parent. Le schéma de dimension d’une hiérarchie parent-enfant dépend d’une relation auto-référençante présente sur la table principale de dimension. Par exemple, le diagramme suivant illustre la table principale de la dimension DimOrganization dans l’exemple de base de données Adventure Works DW Multidimensional 2012Analysis Services.

Dans cette table de dimension, la colonne ParentOrganizationKey a une relation de clé étrangère avec la colonne de clé primaire OrganizationKey . En d’autres termes, chaque enregistrement de cette table peut être lié par le biais d’une relation parent-enfant avec un autre enregistrement de la table. Ce type de jointure automatique est généralement utilisé pour représenter les données d’entité de l’organisation, telles que la structure de gestion des employés d’un service.

Lorsque vous créez une hiérarchie parent-enfant, les colonnes représentées par les deux attributs doivent avoir le même type de données. Les deux attributs doivent également se trouver dans la même table. Par défaut, tout membre dont la clé parente est égale à sa propre clé membre, null, 0 (zéro) ou une valeur absente de la colonne pour les clés de membre est supposée être membre du niveau supérieur (à l’exclusion du niveau (Tout).

La profondeur d’une hiérarchie parent-enfant peut varier entre ses branches hiérarchiques. En d’autres termes, une hiérarchie parent-enfant est considérée comme une hiérarchie déséquilibré.

Contrairement aux hiérarchies définies par l’utilisateur, dans lesquelles le nombre de niveaux de la hiérarchie détermine le nombre de niveaux qui peuvent être visibles par les utilisateurs finaux, une hiérarchie parent-enfant est définie avec le niveau unique d’une hiérarchie d’attributs, et les valeurs de ce niveau unique produisent les différents niveaux observés par les utilisateurs. Le nombre de niveaux affichés dépend du contenu des colonnes de la table de dimension qui stockent les clés membres et les clés parentes. Le nombre de niveaux peut changer lorsque les données des tables de dimension changent. Pour plus d’informations, consultez Parent-Child Hiérarchie et attributs dans Parent-Child hiérarchies.

Voir aussi

Créer des hiérarchies User-Defined
Propriétés de la hiérarchie utilisateur
Informations de référence sur les propriétés d’attribut de dimension