Espace Cube

L’espace de cube est le produit des membres des hiérarchies d’attributs d’un cube avec les mesures du cube. Par conséquent, l’espace de cube est déterminé par le produit combinatorial de tous les membres de la hiérarchie d’attributs dans le cube et les mesures du cube et définit la taille maximale du cube. Il est important de noter que cet espace inclut toutes les combinaisons possibles de membres de la hiérarchie d’attributs ; même les combinaisons qui pourraient être considérées comme impossibles dans le monde réel, c’est-à-dire les combinaisons où la ville est Paris et les pays/régions sont l’Angleterre ou l’Espagne ou le Japon ou l’Inde ou ailleurs.

Autoexists et espace cubique

Le concept de l’existence automatique limite cet espace de cube à ces cellules qui existent réellement. Les membres d’une hiérarchie d’attributs dans une dimension peuvent ne pas exister avec les membres d’une autre hiérarchie d’attributs dans la même dimension.

Par exemple, si vous avez un cube qui a une hiérarchie d’attributs City, une hiérarchie d’attributs Country et une mesure Internet Sales Amount, l’espace de ce cube inclut uniquement les membres qui existent entre eux. Par exemple, si la hiérarchie d’attributs City inclut les villes de New York, Londres, Paris, Tokyo et Melbourne ; et la hiérarchie des attributs Country comprend les pays États-Unis, Royaume-Uni, France, Japon et Australie ; puis l’espace du cube n’inclut pas l’espace (cellule) à l’intersection de Paris et des États-Unis.

Lors de l’interrogation de cellules qui n’existent pas, les cellules non existantes retournent des valeurs Null ; autrement dit, ils ne peuvent pas contenir de calculs et vous ne pouvez pas définir un calcul qui écrit dans cet espace. Par exemple, l’instruction suivante inclut des cellules qui n’existent pas.

SELECT [Customer].[Gender].[Gender].Members ON COLUMNS,  
{[Customer].[Customer].[Aaron A. Allen]  
   ,[Customer].[Customer].[Abigail Clark]} ON ROWS   
FROM [Adventure Works]  
WHERE Measures.[Internet Sales Amount]  

Lorsque vous exécutez la requête précédente, la cellule située à l’intersection d’Aaron A. Allen et de Femelle affiche une valeur Null. De même, la cellule à l’intersection d’Abigail Clark et Male affiche une valeur Null. Ces cellules n’existent pas et ne peuvent pas contenir de valeur, mais les cellules qui n’existent pas peuvent apparaître dans le résultat retourné par une requête.

Lorsque vous utilisez la fonction Crossjoin (MDX) pour renvoyer le produit croisé des membres des hiérarchies d'attributs dans la même dimension, la fonction d'existence automatique limite ces tuples à l'ensemble des tuples qui existent réellement, plutôt que de retourner un produit cartésien complet. Par exemple, exécutez et examinez les résultats de l’exécution de la requête suivante.

SELECT CROSSJOIN  
   (  
      {[Customer].[Country].[United States]},  
         [Customer].[State-Province].Members  
  ) ON 0   
FROM [Adventure Works]  
WHERE Measures.[Internet Sales Amount]  

La requête précédente retourne uniquement les cellules des membres de chaque hiérarchie d’attributs dans la requête qui existent entre eux. La requête précédente peut également être écrite à l’aide de la nouvelle variante * de la fonction * (Crossjoin) (MDX).

SELECT   
   [Customer].[Country].[United States] *   
      [Customer].[State-Province].Members  
ON 0   
FROM [Adventure Works]  
WHERE Measures.[Internet Sales Amount]  

La requête précédente peut également être écrite de la manière suivante :

SELECT [Customer].[State-Province].Members  
ON 0   
FROM [Adventure Works]  
WHERE (Measures.[Internet Sales Amount],  
   [Customer].[Country].[United States])  

Les valeurs de cellules retournées sont identiques, bien que les métadonnées du jeu de résultats soient différentes. Par exemple, avec la requête précédente, la hiérarchie Country a été déplacée vers l’axe du segment (dans la clause WHERE) et n’apparaît donc pas explicitement dans le jeu de résultats.

Chacune de ces trois requêtes précédentes illustre l’effet du comportement d’existence automatique dans SQL Server Analysis Services.

User-Defined hiérarchies et espace de cube

Les exemples précédents de cette rubrique définissent des positions dans l’espace cube à l’aide de hiérarchies d’attributs. Toutefois, vous pouvez également définir une position dans l’espace de cube à l’aide de hiérarchies définies par l’utilisateur qui ont été définies en fonction des hiérarchies d’attributs dans une dimension. Une hiérarchie définie par l’utilisateur est une hiérarchie d’hiérarchies d’attributs conçue pour faciliter la navigation des données de cube par les utilisateurs.

Par exemple, la CROSSJOIN requête de la section précédente peut également avoir été écrite comme suit :

SELECT CROSSJOIN  
   (  
      {[Customer].[Country].[United States]},  
         [Customer].[Customer Geography].[State-Province].Members  
   )   
ON 0   
FROM [Adventure Works]  
WHERE Measures.[Internet Sales Amount]  

Dans la requête précédente, la hiérarchie définie par l’utilisateur Customer Geography dans la dimension Customer est utilisée pour définir la position dans l’espace de cube précédemment défini à l’aide d’une hiérarchie d’attributs. La position identique dans l’espace de cube peut être définie à l’aide de hiérarchies d’attributs ou de hiérarchies définies par l’utilisateur.

Relations d’attributs et espace de cube

La définition des relations d’attributs entre les attributs associés améliore les performances des requêtes (en facilitant la création d’agrégations appropriées) et affecte le membre d’une hiérarchie d’attributs associée qui apparaît avec un membre de hiérarchie d’attributs. Par exemple, lorsque vous définissez un tuple qui inclut un membre de la hiérarchie d’attributs City et que le tuple ne définit pas explicitement le membre de hiérarchie d’attribut Country, vous pouvez vous attendre à ce que le membre de hiérarchie d’attribut Country par défaut soit le membre associé de la hiérarchie d’attributs Country. Toutefois, cela est vrai uniquement si une relation d’attribut est définie entre la hiérarchie d’attributs City et la hiérarchie d’attributs Country.

L’exemple suivant retourne le membre d’une hiérarchie d’attributs associée qui n’est pas incluse explicitement dans la requête.

WITH MEMBER Measures.x AS   
   Customer.Country.CurrentMember.Name  
SELECT Measures.x ON 0,  
Customer.City.Members ON 1  
FROM [Adventure Works]  

Dans la requête précédente, le nom du membre de la hiérarchie d'attributs pays associé à chaque membre de la hiérarchie d'attributs état est renvoyé. Le membre Country attendu apparaît (car une relation d’attribut est définie entre les attributs Ville et Pays). Toutefois, si aucune relation d’attribut n’a été définie entre les hiérarchies d’attributs dans la même dimension, le membre (All) est retourné, comme illustré dans la requête suivante.

WITH MEMBER Measures.x AS   
   Customer.Education.Currentmember.Name  
SELECT Measures.x  ON 0,   
Customer.City.Members ON 1  
FROM [Adventure Works]  

Dans la requête précédente, le membre (All) (« All Customers ») est retourné, car il n’existe aucune relation entre Education et City. Par conséquent, le membre (All) de la hiérarchie d’attributs Éducation serait le membre par défaut de la hiérarchie d’attributs Éducation utilisé dans n’importe quel tuple impliquant la hiérarchie d’attributs City où un membre Éducation n’est pas explicitement fourni.

Contexte de calcul

Voir aussi

Concepts clés dans MDX (Analysis Services)
Tuples
Existe automatiquement
Travail avec les membres, les tuples et les ensembles (MDX)
Totaux visuels et totaux non visuels
Référence du langage MDX (MDX)
Informations de référence sur les expressions multidimensionnelles (MDX)