Présentation des dimensions

Toutes les dimensions SQL Server 2005 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, elles peuvent être utilisées dans plusieurs cubes et plusieurs fois dans un même cube, ainsi que liées entre les instances d'Analysis Services. 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 schéma suivant montre une sous-section de l'exemple de base de données AdventureWorksDW dans lequel la table de faits FactResellerSales est associée à deux tables de dimension, DimReseller et DimPromotion. La colonne ResellerKey dans la table de faits FactResellerSales définit une relation de clé avec la colonne de clé primaire ResellerKey dans la table de dimension DimReseller. De même, la colonne PromotionrKey dans la table de faits FactResellerSales définit une relation de clé étrangère avec la colonne de 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 montre les tables nécessaires pour décrire complètement la dimension de produit 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 principale de 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 des catégories et des sous-catégories de produit dans la dimension de produit.

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 schéma 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 a elle-même une relation de clé étrangère avec la table de dimension DimGeography. Pour définir une dimension Reseller qui contient des informations d'ordre géographique sur chaque revendeur, il est nécessaire d'extraire les attributs des tables de dimension DimGeography et DimReseller. Cependant, dans Analysis Services, vous pouvez obtenir le même résultat en créant deux dimensions distinctes et en les liant avec un groupe de mesures en définissant une relation de dimensions de référence entre les deux dimensions. Pour plus d'informations sur les relations de dimensions 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éfinition d'une relation référencée et des propriétés de relation référencée

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 protégés en utilisant des rôles dans 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 Octroi d'accès à une dimension.

Voir aussi

Concepts

Stockage de dimension
Traductions de dimension
Dimensions activées en écriture
Utilisation de l'Assistant Dimension pour définir une nouvelle dimension
Utilisation de l'Assistant Cube pour définir un cube, des dimensions, des hiérarchies et des attributs

Aide et Informations

Assistance sur SQL Server 2005