Relations d’attributs

Dans Microsoft 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.

Remarque

Les relations d’attribut sont connues dans les expressions multidimensionnelles (MDX) en tant que propriétés de membre.

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)

• Age, Gender, Email, City, Region, Country

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 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} laquelle est décrite l’ajout des relations d’attribut suivantes :

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

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

• 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 des structures ( masquées de l’utilisateur) qui comptent pour les relations naturelles dans les données sources.

La SourceAttribute propriété d’un niveau détermine l’attribut utilisé pour décrire le niveau. La KeyColumns propriété sur l’attribut spécifie la colonne dans la vue de source de données qui fournit les membres. La NameColumn propriété 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 (SSDT), le Concepteur de dimensions vous permet de sélectionner un attribut de dimension, une colonne dans 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 membres feuille n’ont pas de décroissants et contiennent des données dérivées de sources de données sous-jacentes. Les membres non-sourds 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 IsAggregatable propriété est définie 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 PROPERTIES mot clé 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