Concepts clés dans MDX (MDX)

Concepts et termes de la modélisation dimensionnelle

Un cube MicrosoftSQL ServerAnalysis Services est organisé selon des mesures, des dimensions et des attributs de dimension. Le tableau ci-dessous décrit les termes et les concepts de la modélisation dimensionnelle que vous devez comprendre pour manipuler le langage des expressions MDX.

• Dimension de base de données
  Une dimension de base de données est une collection d'attributs de dimension liés à un attribut clé lui-même associé à des faits dans la dimension de mesures.

• Attribut de dimension
  Un attribut de dimension est lié à une ou plusieurs colonnes d'une table de dimension et contient des membres. Un attribut de dimension peut contenir des noms de clients, de mois et de produits.

• Membre
  Un membre désigne la valeur d'un attribut de dimension, notamment la dimension de mesures. Au sein d'une hiérarchie, un membre peut être un membre feuille, un membre parent, un membre de données ou un membre (All).

• Mesure
  Une mesure est une valeur extraite d'une table de faits. On parle aussi de fait. Une valeur dans une dimension de mesures est également désignée par le terme générique membre. Les mesures sont généralement des valeurs numériques mais peuvent également être des valeurs de chaîne.

• Dimension de mesures
  Une dimension de mesures est la dimension qui accueille toutes les mesures figurant dans un cube. C'est un type spécial de dimension dans lequel les membres sont généralement agrégés (traditionnellement par somme ou par compte) sur la base du membre actuel de chaque attribut de dimension pour lequel une mesure spécifiée existe.

• Groupe de mesures
  Un groupe de mesures est une collection de mesures associées dans un cube SQL Server Analysis Services (en règle générale, il s'agit de mesures issues de la même table de faits). Dans SQL Server Analysis Services, un cube peut contenir plusieurs groupes de mesures.

• Membre (All)
  Le membre (All) désigne la valeur calculée de tous les membres dans une hiérarchie d'attribut ou une hiérarchie définie par l'utilisateur.

• Membre calculé
  Un membre calculé est un membre de dimension défini et calculé lors de requêtes. Il peut être défini dans une requête de l'utilisateur ou dans le script de calcul MDX et stocké sur le serveur. Un membre calculé correspond aux lignes dans la table de dimension de la dimension dans laquelle elles sont définies.

• Membre de données
  Un membre de données est un membre enfant associé à un membre parent dans une hiérarchie parent-enfant. Un membre de données abrite les valeurs de données de son membre parent, plutôt que la valeur agrégée des enfants du parent.

• Membre parent
  Un membre parent s'inscrit dans une hiérarchie parent-enfant ; il contient la valeur agrégée de ses enfants.

• Membre feuille
  Un membre feuille appartient à une hiérarchie qui n'a pas d'enfants.

• Membre enfant
  Un membre enfant apparaît dans une hiérarchie sous le niveau supérieur.

• Attribut clé
  L'attribut clé d'une dimension de base de données est l'attribut auquel tous les attributs non-clés de la dimension sont liés (directement ou indirectement). L'attribut clé est souvent aussi l'attribut de granularité.

• Attribut de granularité
  Attribut d'une dimension de cube qui relie une dimension aux faits d'un groupe de mesures dans la dimension de mesures. Si l'attribut de granularité et l'attribut clé sont différents, les attributs non-clés doivent alors être liés, directement ou indirectement, à l'attribut de granularité. Dans un cube, l'attribut de granularité définit la granularité d'une dimension.

• Dimension de cube
  Une dimension de cube est une instance d'une dimension de base de données à l'intérieur d'un cube.

• Hiérarchie d'attribut
  Une hiérarchie d'attribut est une hiérarchie de membres d'attribut composée des niveaux suivants :

  • un niveau feuille accueillant chaque membre d'attribut distinct (chaque membre du niveau feuille est également connu sous le terme de membre feuille) ;

  • des niveaux intermédiaires si la hiérarchie d'attribut est une hiérarchie parent-enfant ;

  • un niveau (All) facultatif (IsAggregatable=True) contenant la valeur agrégée des membres feuille de la hiérarchie d'attribut (pour désigner le membre du niveau (All), on parle également de « membre (All) »).

  Par défaut, une hiérarchie d'attribut est définie pour chaque attribut de dimension (AttributeHierarchyEnabled=True). Les hiérarchies d'attribut sont visibles par défaut (AttributeHierarchyVisible=True).

• Hiérarchie équilibrée
  Une hiérarchie équilibrée est une hiérarchie dans laquelle il existe le même nombre de niveaux entre le niveau supérieur et n'importe quel membre feuille.

• Hiérarchie irrégulière
  Voir hiérarchie déséquilibrée.

• Hiérarchie déséquilibrée
  Une hiérarchie déséquilibrée est une hiérarchie dans laquelle de nombreux niveaux différents interviennent entre le niveau supérieur et le niveau feuille. Une hiérarchie parent-enfant est un exemple de hiérarchie déséquilibrée. On utilise également le terme de hiérarchie irrégulière pour désigner une hiérarchie déséquilibrée.

• Hiérarchie parent-enfant
  Une hiérarchie parent-enfant est un type spécial de hiérarchie d'attribut dans laquelle un attribut au sein de la dimension prend le type parent. Une hiérarchie parent-enfant est une hiérarchie déséquilibrée de membres parents et enfants. Elle se compose des niveaux suivants :

  • Niveaux enfants abritant les enfants des membres parents. Les enfants d'un parent incluent les membres d'attribut agrégés dans le membre parent, notamment les membres de données.

  • Niveaux intermédiaires accueillant les membres parents.

  • Niveau (All) facultatif (IsAggregatable=True) contenant la valeur agrégée des membres feuille des hiérarchies parent-enfant (pour désigner le membre du niveau (All), on parle également de « membre (All) »).

  • Une seule hiérarchie parent-enfant peut exister par dimension et doit être associée à l'attribut clé.

• Hiérarchie définie par l'utilisateur
  Une hiérarchie définie par l'utilisateur est une hiérarchie équilibrée de hiérarchies d'attribut utilisée pour faciliter la navigation des utilisateurs dans les données du cube. Les hiérarchies définies par l'utilisateur ne s'ajoutent pas à l'espace du cube. Les niveaux d'une hiérarchie définie par l'utilisateur peuvent être masqués dans certaines circonstances et apparaître déséquilibrés.

• Relation d'attributs
  Une relation d'attributs désigne une relation un-à-plusieurs entre des attributs (par exemple, une relation entre un attribut de dimension d'état et de ville).

• Propriété de membre
  Une propriété de membre désigne la propriété d'un membre d'attribut. Il peut s'agir, par exemple, du sexe d'un client ou de la couleur d'un produit.

• Cellule
  Dans un cube, une cellule désigne l'espace existant à l'intersection d'un membre du membre de dimension de mesures et d'un membre de chaque hiérarchie d'attribut dans un cube.

  • Un membre de la dimension de mesures peut être un membre feuille (fait individuel) ou un membre agrégé (par exemple, les ventes agrégées d'une année donnée).

  • Un membre provenant d'une dimension peut être un membre feuille, un membre de données, un membre parent ou un membre (All).

• Espace du cube
  L'espace du cube est le produit des membres des hiérarchies d'attribut d'un cube associés aux mesures du cube.

• Sous-cube
  Un sous-cube est le sous-ensemble d'un cube qui représente une vue filtrée du cube. Les sous-cubes peuvent être définis dans une instruction Scope à l'intérieur du script de calcul MDX ou dans une clause de sous-sélection au sein d'une requête MDX.

• Sous-cube avec sous-sélection
  Un sous-cube défini à l'aide d'une clause de sous-sélection dans une requête MDX inclut tous les membres existants dans la définition du sous-cube avec les conséquences suivantes :

  • Le fait d'inclure le membre (All) d'une hiérarchie équivaut à inclure chaque membre feuille de la hiérarchie.

  • En incluant un membre quel qu'il soit, vous incluez ses ascendants et ses descendants.

  • En incluant chaque membre provenant d'un niveau d'une hiérarchie définie par l'utilisateur, vous incluez tous les membres de cette hiérarchie mais pouvez exclure les membres d'autres hiérarchies qui n'existent pas avec les membres du niveau concerné (par exemple, une ville qui ne contient aucun client).

  • Tous les membres (All) du cube existent déjà dans des sous-cubes créés à partir du cube.

  • Les valeurs agrégées contenues dans un sous-cube sont visuellement totalisées.

Tuples

Un tuple identifie de manière unique une cellule sur la base d'une combinaison de membres d'attribut composés d'un attribut issu de chaque hiérarchie d'attribut au sein du cube. Lorsque vous définissez un tuple dans une requête ou une expression MDX, vous n'avez pas besoin d'inclure le membre d'attribut de chaque hiérarchie d'attribut de manière explicite. Si un membre d'une hiérarchie d'attribut n'est pas explicitement intégré dans une requête ou une expression, le membre par défaut de la hiérarchie d'attribut en question correspond au membre d'attribut inclus implicitement dans le tuple. À moins d'être explicitement défini dans un cube, le membre par défaut de chaque hiérarchie d'attribut est le membre (All) s'il existe. Si un membre (All) n'existe pas dans une hiérarchie d'attribut, le membre par défaut est un membre au niveau supérieur de la hiérarchie d'attribut. La mesure par défaut correspond à la première mesure précisée dans le cube, sauf si une mesure par défaut est explicitement définie. Pour plus d'informations, consultez Définition d'un membre par défaut et DefaultMember (MDX).

Par exemple, le tuple suivant permet d'identifier une cellule unique dans la base de données Adventure Works en définissant uniquement un membre unique de la dimension de mesures.

(Measures.[Reseller Sales Amount])

L'exemple ci-dessus identifie de manière unique la cellule composée du membre Reseller Sales Amount (volume de vente du revendeur) de la dimension de mesures et du membre par défaut de chaque hiérarchie d'attribut au sein du cube. Le membre par défaut est le membre (All) de chaque hiérarchie d'attribut autre que la hiérarchie d'attribut Destination Currency (devise de destination). Le membre par défaut de la hiérarchie d'attribut Destination Currency est le membre US Dollar (membre par défaut défini dans le script MDX du cube Adventure Works).

La requête suivante retourne la valeur de la cellule référencée par le tuple spécifié dans l'exemple précédent ($80,450.596.98).

SELECT 
Measures.[Reseller Sales Amount] ON COLUMNS 
FROM [Adventure Works]

Vous pouvez utiliser un tuple dans une requête pour retourner la valeur que référence le tuple dans la cellule, comme dans l'exemple précédent. Vous pouvez aussi recourir à un tuple dans une expression pour désigner de manière explicite les membres spécifiés dans ce tuple. La requête ou l'expression peut alors se servir de fonctions qui permettent de retourner ou de consommer des tuples. Vous pouvez faire appel à un tuple pour soit désigner la valeur de la cellule que le tuple spécifie, soit spécifier une combinaison de membres à utiliser dans le cadre d'une fonction.

La dimensionnalité d'un tuple désigne le classement ou l'ordre des membres au sein du tuple. Du fait que les membres implicites surviennent toujours dans le même ordre, la dimensionnalité est plus souvent abordée en termes de membres explicitement définis du tuple. Le classement des membres du tuple est primordial lorsque vous définissez un jeu de tuples. L'exemple ci-dessous présente deux membres dans un tuple sur l'axe des colonnes.

SELECT 
([Measures].[Reseller Sales Amount],[Date].[Calendar Year].[CY 2004]) ON COLUMNS 
FROM [Adventure Works]

Le tuple employé dans la requête de l'exemple ci-avant précise le retour de la cellule du cube à l'intersection de la mesure Reseller Sales Amount de la dimension de mesures et du membre CY 2004 de la hiérarchie d'attribut Calendar Year dans la dimension Date.

Jeux

Un jeu est un ensemble ordonné de tuples doté de la même dimensionnalité. Voici un exemple de jeu :

SELECT 
   {
      ([Measures].[Reseller Sales Amount],
         [Date].[Calendar Year].[CY 2003]),
      ([Measures].[Reseller Sales Amount],
         [Date].[Calendar Year].[CY 2004])
   } ON COLUMNS 
FROM [Adventure Works]

Dans l'exemple ci-dessus, chaque tuple du jeu affiche la même dimensionnalité puisque son premier membre est membre de la dimension de mesures et son deuxième membre est membre de la hiérarchie d'attribut Calendar Year. Si le deuxième membre de l'un des tuples provenait d'une hiérarchie d'attribut différente de la dimension Date (par exemple, Calendar Month), vous recevriez une erreur signalant la différence de dimensionnalité.

Conseil
Vous pouvez créer un jeu à l'aide d'un alias appelé « jeu nommé ». L'utilisation d'un jeu nommé rend votre requête MDX plus facile à maîtriser ou à réutiliser lorsque vous travaillez avec des expressions MDX complexes. Pour utiliser un jeu nommé, appliquez le terme « AS » suivi du nom d'alias désiré à la fin de l'identificateur du jeu.

Espace du cube et auto-existence

Plus haut dans cette rubrique, nous avons défini l'espace du cube comme le produit des membres de ses hiérarchies d'attribut. Le concept d'auto-existence limite l'espace du cube aux cellules réellement existantes. Les membres d'une hiérarchie d'attribut au sein d'une dimension ne peuvent coexister avec les membres d'une autre hiérarchie d'attribut au sein de la même dimension.

Par exemple, si vous travaillez avec un cube muni d'une hiérarchie d'attribut Ville, d'une hiérarchie d'attribut Pays et d'une mesure Volume de vente Internet, l'espace du cube inclut uniquement les membres qui coexistent entre eux. Par exemple, si la hiérarchie d'attribut Ville inclut les villes de New York, Londres, Paris, Tokyo et Melbourne et la hiérarchie d'attribut Pays les pays États-Unis, Royaume-Uni, France, Japon et Australie, l'espace du cube n'inclut pas l'espace (cellule) à l'intersection de Paris et États-Unis.

Lorsque vous interrogez des cellules qui n'existent pas, ces cellules retournent des valeurs NULL, ce qui signifie qu'elles ne peuvent pas contenir des calculs et que vous ne pouvez pas définir un calcul autorisé à écrire dans l'espace concerné. 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 ci-dessus, la cellule à l'intersection de Aaron A. Allen et Female affiche une valeur NULL, tout comme la cellule à l'intersection d'Abigail Clark et Male. Ces cellules n'existent pas et ne peuvent contenir de valeur. En revanche, les cellules non existantes peuvent apparaître dans le résultat que retourne une requête.

Lorsque vous utilisez la fonction Crossjoin (MDX) pour retourner le produit croisé des membres de la hiérarchie d'attribut à partir des hiérarchies d'attribut de la même dimension, l'auto-existence limite les tuples retournés au jeu 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 ci-dessus retourne uniquement les cellules des membres de chaque hiérarchie d'attribut dans la requête qui coexistent entre eux. Vous pouvez également écrire cette requête à 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]

Cette requête peut aussi ê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 retournées des cellules sont identiques, même si les métadonnées dans l'ensemble de résultats apparaissent différemment. Par exemple, dans la requête ci-dessus, la hiérarchie Country a été déplacée vers l'axe de secteur (dans la clause WHERE) et ne peut donc s'afficher de manière explicite dans l'ensemble de résultats.

Chacune des trois requêtes présentées ci-dessus illustre les effets du comportement de l'auto-existence dans SQL ServerAnalysis Services.

Hiérarchies définies par l'utilisateur et espace du cube

Les exemples présentés précédemment dans cette rubrique définissent des positions au sein de l'espace du cube par le biais des hiérarchies d'attribut. Néanmoins, vous pouvez également définir une position dans l'espace du cube en utilisant des hiérarchies définies par l'utilisateur qui ont été conçues à partir des hiérarchies d'attribut d'une dimension. Une hiérarchie définie par l'utilisateur est une hiérarchie de hiérarchies d'attribut conçue pour faciliter la navigation des utilisateurs dans les données du cube.

Par exemple, la requête CROSSJOIN de la section précédente aurait pu aussi être écrite de la manière suivante :

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 ci-dessus, la hiérarchie définie par l'utilisateur Customer Geography incluse dans la dimension Customer est utilisée pour définir la position dans l'espace du cube définie auparavant à l'aide d'une hiérarchie d'attribut. La même position dans l'espace du cube peut être définie soit au moyen de hiérarchies d'attribut, soit à l'aide de hiérarchies définies par l'utilisateur.

Relations d'attributs et espace du cube

La définition de relations d'attributs entre des attributs associés améliore les performances des requêtes (grâce à la création facilitée d'agrégations adaptées) et affecte le membre d'une hiérarchie d'attribut associée qui apparaît avec un membre de hiérarchie d'attribut. Par exemple, lorsque vous définissez un tuple qui inclut un membre de la hiérarchie d'attribut City et que le tuple ne définit pas explicitement le membre de la hiérarchie d'attribut Country, vous pouvez vous attendre à ce que le membre par défaut de la hiérarchie d'attribut Country corresponde au membre associé de la hiérarchie d'attribut Country. Néanmoins, cette situation ne vaut que si une relation d'attributs est définie entre les hiérarchies d'attribut City et Country.

L'exemple ci-après retourne le membre d'une hiérarchie d'attribut associée qui ne figure pas de manière explicite 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'attribut Country associé à chaque membre de la hiérarchie d'attribut State est retourné. Le membre Country attendu apparaît (puisqu'une relation d'attributs est définie entre les attributs City et Country). Par contre, si aucune relation d'attributs n'est définie entre les hiérarchies d'attribut de la même dimension, le membre (All) doit être retourné comme 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 cette requête, le membre (All) (« All Customers ») est retourné parce qu'il n'existe aucune relation entre Education et City. Le membre (All) de la hiérarchie d'attribut Education serait alors le membre par défaut de cette hiérarchie utilisé dans n'importe quel tuple impliquant la hiérarchie d'attribut City où aucun membre Education n'est explicitement fourni.

Contexte de calcul

Chaque jeu, membre, tuple ou fonction numérique s'exécute dans le contexte de l'instruction ou de l'expression MDX à part entière. Lorsqu'un argument (par exemple, un tuple) est transmis à une fonction, seules certaines coordonnées dans l'espace du cube sont fournies de manière explicite. Les autres coordonnées sont obtenues sur la base du contexte de calcul actuel. Le contexte de calcul des coordonnées des cellules et des membres d'attribut non spécifiés est déterminé dans l'ordre suivant :

1. Clause FROM (le cas échéant) : cette clause peut spécifier soit un cube tout entier, soit un sous-cube présenté sous la forme d'une instruction SELECT.

2. Clause WHERE (le cas échéant) : clause également appelée axe de secteur et dans laquelle vous spécifiez un jeu, un tuple ou un membre qui restreint les membres que retourne une requête dans les axes des colonnes et des lignes. D'un point de vue conceptuel, le membre par défaut de chaque hiérarchie d'attribut qui n'est pas explicitement défini dans l'axe des colonnes ou l'axe des lignes appartient à l'axe de secteur.

   [!REMARQUE]

   Lorsque vous spécifiez les coordonnées des cellules d'un attribut en particulier à la fois sur l'axe de secteur et sur un autre axe, les coordonnées spécifiées dans la fonction peuvent être prioritaires dans le choix des membres du jeu sur l'axe. Les fonctions Filter (MDX) et Order (MDX) sont des exemples de ce type de fonction ; vous pouvez filtrer ou classer un résultat par membres d'attribut exclus du contexte de calcul par la clause WHERE ou par une instruction SELECT dans la clause FROM.

3. Jeux nommés et membres calculés définis dans la requête ou l'expression.

4. Tuples et jeux spécifiés sur les axes des lignes et des colonnes à l'aide du membre par défaut des attributs qui n'apparaissent pas sur les axes des lignes ou des colonnes ou sur l'axe de secteur.

5. Cellules du cube ou du sous-cube sur chaque axe avec suppression des tuples vides sur l'axe et application de la clause HAVING.

6. Pour plus d'informations, consultez Définition d'un contexte de cube dans une requête (MDX).

7. Dans la requête qui suit, le contexte de calcul de l'axe des lignes est limité par les membres d'attribut Country et Calendar Year spécifiés dans la clause WHERE.

SELECT Customer.City.City.Members ON 0
FROM [Adventure Works]
WHERE (Customer.Country.France, [Date].[Calendar].[Calendar Year].[CY 2004],
   Measures.[Internet Sales Amount])

1. Cependant, si vous modifiez cette requête en précisant la fonction FILTER sur l'axe des lignes, puis utilisez un membre de la hiérarchie d'attribut Calendar Year dans la fonction FILTER, vous pouvez alors modifier le membre d'attribut de la hiérarchie d'attribut Calendar Year employé pour fournir le contexte de calcul des membres du jeu sur l'axe des colonnes.

SELECT FILTER
   (
      Customer.City.City.Members, 
         ([Date].[Calendar].[Calendar Year].[CY 2003],
            Measures.[Internet Order Quantity]) > 75 
   ) ON 0
FROM [Adventure Works]
WHERE (Customer.Country.France,
   [Date].[Calendar].[Calendar Year].[CY 2004],
   Measures.[Internet Sales Amount])

1. Dans la requête ci-dessus, le contexte de calcul des cellules dans les tuples qui apparaissent sur l'axe des colonnes est filtré par le membre CY 2003 de la hiérarchie d'attribut Calendar Year, même si le contexte de calcul nominal de la hiérarchie d'attribut Calendar Year est CY 2004. De plus, il est filtré par la mesure Internet Order Quantity. Néanmoins, une fois les membres du jeu définis sur l'axe des colonnes, le contexte de calcul des valeurs des membres qui apparaissent sur l'axe est de nouveau déterminé par la clause WHERE.

Voir aussi

Concepts

Autres ressources