Relations d'attributs
Dans Microsoft SQL Server Analysis Services, les attributs au sein d'une dimension sont toujours liés directement ou indirectement à l'attribut de clé. 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 d'attribut de dimension.
[!REMARQUE]
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
Gender
Email
City
Country
Region
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, ceci 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 naviguer dans les données du cube, vous pouvez aussi 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 rapporteuse). 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 quant à la façon dont les deux hiérarchies se comportent, bien que la hiérarchie naturelle bénéficie de structures d'agrégation et d'indexation, qui sont cachées à l'utilisateur et qui représentent les relations naturelles de la source de données.
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 Outils de données SQL Server (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 liée qui fait partie de la vue de source de données pour le cube. Pour plus d'informations sur la création des hiérarchies définies par l'utilisateur, consultez Créer des hiérarchies définies par l'utilisateur.
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 extraire des propriétés de membre, consultez Utilisation des propriétés de membre (MDX).
Voir aussi
Concepts
Attributs et hiérarchies d'attributs