Hiérarchies définies par l'utilisateur

Les hiérarchies définies par l'utilisateur sont des hiérarchies d'attribut définies par l'utilisateur utilisées dans Microsoft SQL Server 2005 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. Le diagramme suivant montre la relation entre les niveaux et les membres de la dimension Calendar (dimension régulière).

Remarque :
Toute hiérarchie autre qu'une hiérarchie d'attribut à deux niveaux par défaut se nomme hiérarchie définie par l'utilisateur. Pour plus d'informations sur les hiérarchies d'attribut, consultez Attributs et hiérarchies d'attributs.

Structures de membres

À l'exception des hiérarchies parent-enfant, la position des membres d'une hiérarchie est déterminée par l'ordre des attributs dans la définition de la hiérarchie. Chaque attribut inclus dans la définition de la hiérarchie génère un niveau dans la hiérarchie. La position d'un membre à l'intérieur d'un niveau est déterminée par le classement de l'attribut utilisé pour créer le niveau. Les structures de 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 aboutissent au même niveau, et le parent logique de chaque membre figure dans le niveau immédiatement supérieur au membre. La hiérarchie Product Categories de la dimension Product dans l'exemple de base de données d'Analysis Services Adventure Works DW, est un bon exemple de hiérarchie équilibrée. Chaque membre du niveau Product Name a un membre parent dans le niveau Subcategory, qui a à son tour un membre parent dans le niveau Category. De plus, chaque branche de la hiérarchie possède un membre feuille dans le niveau Product Name.

Hiérarchies déséquilibrées

Dans une hiérarchie non équilibrée, les branches aboutissent à des niveaux différents. Les hiérarchies parent-enfant sont des hiérarchies déséquilibrées. Par exemple, la dimension Organization dans l'exemple de base de données d'Analysis Services Adventure Works DW, contient un membre pour chaque employé. Le directeur général est le membre supérieur de la hiérarchie et les directeurs des différents services ainsi que la secrétaire de direction se trouvent immédiatement après lui. Des membres sont subordonnés aux directeurs des différents services, mais pas à la secrétaire de direction.

Il est parfois impossible pour les utilisateurs finaux de faire la différence entre les hiérarchies non équilibrées et les hiérarchies irrégulières. Toutefois, différentes techniques et propriétés dans Analysis Services vous permettent de prendre en charge ces deux types de hiérarchies. Pour plus d'informations, consultez Utilisation de hiérarchies irrégulières et Utilisation d'attrbuts dans des hiérarchies parent-enfant.

Hiérarchies irrégulières

Dans une hiérarchie irrégulière, le membre parent logique d'au moins un membre ne figure pas dans le niveau immédiatement supérieur à ce membre. Cela peut amener les branches de la hiérarchie à aboutir à des niveaux différents. Par exemple, dans une dimension Geography définie avec les niveaux Continent, CountryRegion et City, dans cet ordre, le membre Europe apparaît au niveau supérieur de la hiérarchie, le membre France apparaît au niveau intermédiaire et le membre Paris apparaît au niveau inférieur. France est plus précis que Europe et Paris l'est davantage que France. Les modifications suivantes sont apportées à cette hiérarchie régulière :

• Le membre Vatican City est ajouté au niveau CountryRegion.
• Des membres sont ajoutés au niveau City et sont associés au membre Vatican City dans le niveau CountryRegion.
• Un niveau, nommé Province, est ajouté entre le niveau CountryRegion et le niveau City.

Le niveau Province est rempli avec des membres associés à d'autres membres du niveau CountryRegion, et des membres du niveau City sont associés à leurs membres correspondants du niveau Province. Toutefois, le membre Vatican City du niveau CountryRegion n'étant associé à aucun membre du niveau Province, les membres doivent être associés directement du niveau City au membre Vatican City du niveau CountryRegion. En raison de ces modifications, la hiérarchie de la dimension est désormais irrégulière. Le parent de la ville Vatican City est Vatican City du niveau CountryRegion, qui n'est pas inclus dans le niveau immédiatement supérieur au membre Vatican City du niveau City. Pour plus d'informations, consultez Utilisation de hiérarchies irrégulières.

Hiérarchies parent-enfant

Les hiérarchies parent-enfant de dimensions sont définies à l'aide d'un attribut spécial, nommé « attribut parent », pour déterminer la façon dont les membres sont liés les uns aux autres. Un attribut parent décrit une relation d'auto-référencement, ou jointure réflexive, dans une table de dimension principale. Les hiérarchies parent-enfant sont construites à partir d'un seul attribut parent. Un seul niveau est affecté à une hiérarchie parent-enfant parce que les niveaux présents dans la hiérarchie sont constitués à partir 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 de la présence d'une relation d'auto-référencement dans la table principale de la dimension. Par exemple, le schéma suivant montre la table de dimension principale DimOrganization de l'exemple de base de données AdventureWorksDW Analysis 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 dans cette table peut être associé à un autre enregistrement de la table par une relation parent-enfant. Ce type de jointure réflexive est généralement utilisé pour représenter les données d'une entité d'une organisation, telles que la structure de gestion des employés dans 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 figurer dans la même table. Par défaut, tout membre dont la clé de parent est égale à sa clé de membre, à une valeur null, à 0 (zéro) ou à une valeur ne figurant pas dans la colonne des clés de membre, est considéré comme appartenant au niveau supérieur (niveau (Tous) exclu).

La profondeur d'une hiérarchie parent-enfant peut varier d'une branche à l'autre de sa hiérarchie. En d'autres termes, une hiérarchie parent-enfant est considérée comme étant une hiérarchie déséquilibrée.

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 visibles pour les utilisateurs finaux, une hiérarchie parent-enfant est définie avec le niveau unique d'une hiérarchie d'attribut, et les valeurs de ce niveau unique produisent les multiples niveaux visibles pour les utilisateurs. Le nombre de niveaux affichés dépend du contenu des colonnes de table de dimension qui stockent les clés de membre et les clés parentes. Le nombre de niveaux peut changer à mesure que les données des tables de dimension changent. Pour plus d'informations, consultez Définition d'une hiérarchie parent-enfant et Utilisation d'attrbuts dans des hiérarchies parent-enfant.

Voir aussi

Concepts

Définition et configuration d'une hiérarchie définie par l'utilisateur
Configuration des propriétés des hiérarchies définies par l'utilisateur
Définition et configuration des attributs de dimension

Aide et Informations

Assistance sur SQL Server 2005