Partager via

Relations d’attributs

  • Article

Dans Microsoft SQL Server Analysis Services, les attributs d’une dimension sont toujours liés directement ou indirectement à l’attribut key. Quand vous définissez une dimension basée sur un schéma en étoile, c'est-à-dire quand tous les attributs de la 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. Quand vous définissez une dimension basée sur un schéma en flocon, où les attributs de la dimension sont dérivés de plusieurs tables lié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 de la table secondaire et chaque attribut non-clé lié aux colonnes de la table secondaire.

Cependant, pour plusieurs raisons, vous pouvez souhaiter modifier ces relations d'attributs par défaut. Par exemple, vous voulez 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 de l’attribut de dimension.

Notes

Les relations d'attributs sont appelées propriétés de membre dans les expressions MDX (Multidimensional Expressions).

Relations de hiérarchie naturelle

Une hiérarchie une hiérarchie naturelle quand chaque attribut inclus dans la hiérarchie définie par l'utilisateur possède une relation un-à-plusieurs avec l'attribut se trouvant immédiatement au-dessous de lui. Imaginons par exemple une dimension Customer basée sur une table source relationnelle avec huit colonnes :

  • CustomerKey

  • CustomerName

  • Age

  • Sexe

  • Courrier

  • City

  • Pays ou région

  • Région

La dimension Analysis Services correspondante a sept attributs :

  • Customer (basée sur CustomerKey, avec CustomerName fournissant les noms des 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 d'un niveau et l'attribut du niveau qui se trouve au-dessous. 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} est décrite en ajoutant les relations d'attributs suivantes :

  • l'attribut Country en tant que relation d'attribut de l'attribut Region ;

  • l'attribut Region en tant que relation d'attribut de l'attribut City ;

  • l'attribut City en tant que relation d'attribut de l'attribut Customer.

Pour parcourir les données dans le 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 (qui est 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 basée sur {Age, Gender}. Les utilisateurs ne voient aucune différence dans le comportement des deux hiérarchies, bien que la hiérarchie naturelle tire parti de l’agrégation et de l’indexation des structures - masquées de l’utilisateur - qui comptent les 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 de l'attribut spécifie la colonne de la vue de source de données qui fournit les membres. La propriété NameColumn de 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), l’Designer dimension 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 pour le 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 à propos du contenu des membres. Les membres feuilles n'ont pas de descendants et contiennent des données dérivées des 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 les agrégations des niveaux inférieurs. Par conséquent, quand la propriété IsAggregatable est définie à False sur un attribut source pour un niveau, aucun attribut pouvant faire l'objet d'une agrégation ne peut être ajouté en tant que niveau au dessus de cet attribut.

Définition d'une relation d'attribut

La principale contrainte lorsque vous créez une relation d'attribut consiste à veiller à ce que l'attribut auquel la relation d'attribut fait référence ne dispose que d'une seule valeur pour chaque membre de l'attribut auquel la relation d'attribut appartient. Par exemple, si vous définissez une relation entre un attribut City (Ville) et un attribut State (État), chaque Ville ne peut être liée qu'à un seul État.

Requêtes de relations d'attributs

Vous pouvez utiliser des requêtes MDX pour extraire des données des relations d'attributs, sous forme de propriétés, 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
Référence des propriétés d’attribut de dimension
Hiérarchies utilisateur
Propriétés de la hiérarchie définie par l'utilisateur