Dimensions - Introduction

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

Toutes les dimensions microsoft SQL Server SQL Server Analysis Services sont des groupes d’attributs basés sur des colonnes de tables ou de vues dans une vue de source de données. Les dimensions existent indépendamment d’un cube, peuvent être utilisées dans plusieurs cubes, peuvent être utilisées plusieurs fois dans un seul cube et peuvent être liées entre SQL Server Analysis Services instances. Une dimension qui existe indépendamment d'un cube est appelée dimension de base de données et une instance de dimension de base de données dans un cube est appelée dimension de cube.

Dimension basée sur un schéma en étoile

La structure d'une dimension repose principalement sur la structure de la table ou des tables de dimension sous-jacentes. La structure la plus simple est appelée schéma en étoile, où chaque dimension est basée sur une seule table de dimension qui est directement liée à la table de faits par une relation clé primaire - clé étrangère.

Le diagramme suivant illustre une sous-section de l’exemple de base de données AdventureWorksDW2012 , dans laquelle la table de faits FactResellerSales est liée à deux tables de dimension, DimReseller et DimPromotion. La colonne ResellerKey de la table de faits FactResellerSales définit une relation de clé étrangère avec la colonne clé primaire ResellerKey dans la table de dimension DimReseller . De même, la colonne PromotionKey de la table de faits FactResellerSales définit une relation de clé étrangère avec la colonne clé primaire PromotionKey dans la table de dimension DimPromotion .

Dimension basée sur un schéma en flocon

Une structure plus complexe est fréquemment requise parce que des informations provenant de plusieurs tables sont nécessaires pour définir la dimension. Dans cette structure, appelée un schéma en flocon, chaque dimension est basée sur les attributs de plusieurs tables liées les unes aux autres ainsi qu'à la table de faits par des relations clé primaire - clé étrangère. Par exemple, le diagramme suivant illustre les tableaux nécessaires pour décrire complètement la dimension Product dans l’exemple de projet AdventureWorksDW :

Pour décrire complètement un produit, la catégorie et la sous-catégorie du produit doivent être incluses dans la dimension Product. Toutefois, ces informations ne résident pas directement dans la table main pour la dimension DimProduct. Une relation de clé étrangère de DimProduct à DimProductSubcategory, qui à son tour a une relation de clé étrangère avec la table DimProductCategory , permet d’inclure les informations relatives aux catégories et sous-catégories de produits dans la dimension Product.

Schéma en flocon et relation de référence

Parfois, vous pouvez être amené à choisir entre l'utilisation d'un schéma en flocons pour définir les attributs d'une dimension à partir de plusieurs tables ou la définition de deux dimensions distinctes avec l'établissement d'une relation de dimensions de référence entre celles-ci. Le diagramme suivant montre ce scénario.

Dans le diagramme précédent, la table de faits FactResellerSales n’a pas de relation de clé étrangère avec la table de dimension DimGeography . Toutefois, la table de faits FactResellerSales a une relation de clé étrangère avec la table de dimension DimReseller , qui à son tour a une relation de clé étrangère avec la table de dimension DimGeography . Pour définir une dimension Reseller qui contient des informations géographiques sur chaque revendeur, vous devez récupérer ces attributs à partir des tables de dimension DimGeography et DimReseller . Toutefois, dans SQL Server Analysis Services, vous pouvez obtenir le même résultat en créant deux dimensions distinctes et en les liant dans un groupe de mesures en définissant une relation de dimension de référence entre les deux dimensions. Pour plus d’informations sur les relations de dimension de référence, consultez Relations de dimension.

Un avantage des relations de dimensions de référence dans ce scénario est que vous pouvez créer une seule dimension Geography, puis créer plusieurs dimensions de cube basés sur cette dimension, sans qu'un espace de stockage supplémentaire soit nécessaire. Par exemple, vous pouvez lier une des dimensions de cube Geography à une dimension Reseller, et une autre dimension de cube Geography à une dimension Customer. Rubriques connexes :Relations de dimension, Définir une relation référencée et propriétés de relation référencées

Traitement d'une dimension

Après avoir créé une dimension, vous devez traiter celle-ci avant de pouvoir afficher les membres des attributs et des hiérarchies dans la dimension. Après avoir modifié la structure d'une dimension ou après la mise à jour des informations de ses tables sous-jacentes, vous devez traiter à nouveau la dimension pour pouvoir afficher les modifications. Lorsque vous traitez une dimension après des changements structuraux, vous devez également traiter les cubes qui comprennent cette dimension, sinon le cube ne sera pas visible.

Sécurité

Tous les objets subordonnés d’une dimension, y compris les hiérarchies, les niveaux et les membres, sont sécurisés à l’aide de rôles dans SQL Server Analysis Services. La sécurité d'une dimension peut être appliquée à tous les cubes de la base de données qui utilisent la dimension, ou à un cube donné seulement. Pour plus d’informations sur la sécurité des dimensions, consultez Accorder des autorisations sur une dimension (Analysis Services).

Voir aussi

Stockage de dimension
Traductions de dimension
Dimensions activées pour l’écriture