Relations d’attributs

S’applique à : SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Dans Microsoft SQL Server SQL Server Analysis Services, les attributs d’une dimension sont toujours liés directement ou indirectement à l’attribut clé. Lorsque vous définissez une dimension basée sur un schéma en étoile, c’est-à-dire que tous les attributs de dimension sont dérivés de la même table relationnelle, une relation d’attribut est automatiquement définie entre l’attribut clé et chaque attribut non clé de la dimension. Lorsque vous définissez une dimension basée sur un schéma flocon de neige, c’est-à-savoir où les attributs de dimension sont dérivés de plusieurs tables associées, une relation d’attribut est automatiquement définie comme suit :

• Entre l’attribut clé et chaque attribut non clé lié aux colonnes de la table de dimension principale.

• Entre l’attribut clé et l’attribut lié à la clé étrangère dans la table secondaire qui lie les tables de dimension sous-jacentes.

• Entre l’attribut lié à la clé étrangère dans la table secondaire et chaque attribut non clé lié aux colonnes de la table secondaire.

Toutefois, il existe plusieurs raisons pour lesquelles vous souhaiterez peut-être modifier ces relations d’attribut par défaut. Par exemple, vous pouvez définir une hiérarchie naturelle, un ordre de tri personnalisé ou une granularité de dimension basée sur un attribut non clé. Pour plus d’informations, consultez Référence des propriétés d’attribut de dimension.

Relations de hiérarchie naturelle

Une hiérarchie est une hiérarchie naturelle lorsque chaque attribut inclus dans la hiérarchie définie par l’utilisateur a une relation à plusieurs avec l’attribut immédiatement en dessous. Par exemple, considérez une dimension Client basée sur une table source relationnelle avec huit colonnes :

• CustomerKey

• Nom du client

• Âge

• Sexe

• Messagerie électronique

• Ville

• Pays

• Région

La dimension Analysis Services correspondante a sept attributs :

• Client (basé sur CustomerKey, avec CustomerName fournissant des noms de membres)

• Âge, Sexe, Courriel, Ville, Région, Pays

Les relations représentant des hiérarchies naturelles sont appliquées en créant une relation d’attribut entre l’attribut pour un niveau et l’attribut pour le niveau inférieur à celui-ci. Pour SQL Server Analysis Services, cela spécifie une relation naturelle et une agrégation potentielle. Dans la dimension Customer, une hiérarchie naturelle existe pour les attributs Country, Region, City et Customer. La hiérarchie naturelle pour {Country, Region, City, Customer} est décrite par l'ajout des relations d'attribut suivantes :

• Attribut Country en tant que relation d’attribut avec l’attribut Region.

• L'attribut Région est défini comme une relation d'attribut avec l'attribut Ville.

• Attribut City en tant que relation d’attribut avec l’attribut Customer.

Pour naviguer dans les données du cube, vous pouvez également créer une hiérarchie définie par l’utilisateur qui ne représente pas une hiérarchie naturelle dans les données (appelée hiérarchie ad hoc ou de création de rapports ). Par exemple, vous pouvez créer une hiérarchie définie par l’utilisateur en fonction {Age, Gender}de . Les utilisateurs ne voient aucune différence dans le comportement des deux hiérarchies, bien que la hiérarchie naturelle bénéficie de l'agrégation et de l'indexation de structures cachées à l'utilisateur, qui tiennent compte des relations naturelles dans les données sources.

La propriété SourceAttribute d’un niveau détermine l’attribut utilisé pour décrire le niveau. La propriété KeyColumns sur l’attribut spécifie la colonne dans la vue de source de données qui fournit les membres. La propriété NameColumn sur l’attribut peut spécifier une colonne de nom différente pour les membres.

Pour définir un niveau dans une hiérarchie définie par l’utilisateur à l’aide de SQL Server Data Tools, le Concepteur de dimensions vous permet de sélectionner un attribut de dimension, une colonne d’une table de dimension ou une colonne d’une table associée incluse dans la vue de source de données du cube. Pour plus d’informations sur la création de hiérarchies définies par l’utilisateur, consultez Créer des hiérarchies User-Defined.

Dans Analysis Services, une hypothèse est généralement faite sur le contenu des membres. Les nœuds feuille n'ont pas de descendants et contiennent des données dérivées de sources de données sous-jacentes. Les membres non-feuilles ont des descendants et contiennent des données dérivées des agrégations effectuées sur les membres enfants. Dans les niveaux agrégés, les membres sont basés sur des agrégations de niveaux subordonnés. Par conséquent, lorsque la propriété IsAggregatable a la valeur False sur un attribut source pour un niveau, aucun attribut aggregatable ne doit être ajouté comme niveaux au-dessus de celui-ci.

Définition d’une relation d’attribut

La contrainte principale lorsque vous créez une relation d’attribut consiste à vérifier que l’attribut référencé par la relation d’attribut n’a pas plus d’une valeur pour un membre de l’attribut auquel appartient la relation d’attribut. Par exemple, si vous définissez une relation entre un attribut City et un attribut State, chaque ville ne peut se rapporter qu’à un seul état.

Requêtes de relation d’attribut

Vous pouvez utiliser des requêtes MDX pour récupérer des données à partir de relations d’attributs, sous la forme de propriétés de membre, avec le mot clé PROPERTIES de l’instruction MDX SELECT . Pour plus d’informations sur l’utilisation de MDX pour récupérer des propriétés de membre, consultez Utilisation des propriétés de membre (MDX).

Voir aussi

Attributs et hiérarchies d’attributs
Informations de référence sur les propriétés d’attribut de dimension
Hiérarchies utilisateur
Propriétés de la hiérarchie utilisateur