Découverte du langage MDX partie 1 - dominique …...Découverte du langage MDX partie 1 SQL Server...

SQL Server 2008-2016

Dominique Verrière

Dialogue Formation Informatique

SQL Server 2008-2016

Découverte du langage MDX partie 1

SQL Server : Le blog de Dominique Verrière 2

Introduction

Ce petit fascicule fait partie d’une liste de notes que je publie gratuitement sur mon site.

J’essaie de mettre dans ces notes mon expérience de terrain en toute indépendance de Microsoft.

Dominique Verrière

Table des matières Découverte du langage MDX ........................................................................................ 6

Introduction ........................................................................................................................................................... 6

Base de données et cube utilisés dans ce post ..................................................................................................... 7

Concepts de base indispensables ...................................................................................................................... 8

Notion de membre ................................................................................................................................................ 9

Appellation par clé : ........................................................................................................................................... 9

Appellation par nom : ...................................................................................................................................... 10

Notion de tuple .................................................................................................................................................... 10

Notion de set ....................................................................................................................................................... 10

Combinaisons de membres, tuples, sets ............................................................................................................. 10

Cas particulier des mesures ................................................................................................................................. 11

Nos premières requêtes ...................................................................................................................................... 11

Que fait-on avec ces ordres SELECT ? .............................................................................................................. 11

Requête sur un seul axe .................................................................................................................................. 12

Requête sur deux axes ..................................................................................................................................... 12

Et la clause where ? ......................................................................................................................................... 15

Résumé de la syntaxe du select ........................................................................................................................... 16

Les points qui fâchent .......................................................................................................................................... 16

Un tuple comporte des membres de hiérarchies différentes : ....................................................................... 16

Une hiérarchie ne figure que sur un seul axe (Colonne, ligne et slicing) ........................................................ 17

Aller plus loin ............................................................................................................. 18

Contacter l’auteur ...................................................................................................... 19

Sommaire



SQL Server Le blog de Dominique Verrière

Découverte du langage MDX

Introduction Qu’est-ce que le langage MDX ?

Un langage de de requêtes qui permet d’extraire les données d’un système multidimensionnel (Cube).

Si on le compare à Transact SQL, on note que :

Ce langage est fermé dans le sens où il manipule les objets du cube : les hiérarchies et les mesures : tout ce

qu’on lui demande !

Où se sert-on du MDX ?

D’une part en définition de cube car c’est le langage à utiliser pour les membres calculés ou sets embarqués

dans le cube ; de même il est indispensable pour définir des KPI (Key Performance Indicator).

D’autre part dans les outils d’extraction de données : Reporting Services et Excel notamment.

Il n’y a pas de partie DDL (Data Definition Language)

La partie DML est plutôt limitée au SELECT, les mises à jour étant peu développées par nature

Il y a besoin de compléter ce langage par du XMLA et/ou du VBA



Base de données et cube utilisés dans ce post

Je montre la base de données (Data Warehouse) uniquement pour la compréhension, mais un développeur

MDX s’en souciera peu à l’inverse d’un développeur DAX qui pourra faire du direct query.

Quant au cube, voici à quoi il ressemble :



Concepts de base indispensables

Un développeur MDX va se ‘promener’ dans les structures multidimensionnelles :

Par ailleurs la notion de membre est aussi indispensable.

On a deux types de hiérarchies :

La première est plutôt technique, en voici un exemple :

On voit ici les membres (les pays) en dessous du membre particulier All qui permet d’obtenir des agrégats

sur tous les pays.

Par ailleurs on voit également que ce type de hiérarchie a une notion de niveau :

La deuxième occurrence de Pays est le niveau.

On note déjà que l’on verra des données différentes en fonction de l’endroit d’où l’on part : MDX est très lié

au contexte courant.

Une hiérarchie utilisateur, comme son nom l’indique, est plutôt métier :

Les mesures : qui par essence sont agrégables (sum, min, max,…)

Les hiérarchies qui vont permettre de croiser les données sur les mesures

Hiérarchie d’attributs

Hiérarchie utilisateur



Ici les produits vendus par cette entreprise ont été classé en trois étages :

Ceci servira bien sûr à faire des recherches et des comparaisons : part des VTT par rapport aux vélos,

membres fils de la sous catégories des casques, etc.

Notion de membre Un membre est l’élément le plus fin d’une hiérarchie ou d’un niveau : on ne pourra pas le ‘découper’ par la

suite ; on parle dans le jargon de slicing.

On peut les noter par clé ou par nom.

Appellation par clé :

[Produit].[Catalogue].[Categorie].&[2]

On note le chemin complet Dimension.Hiérarchie.Niveau.Clé

Le développeur MDX pourra ‘rebondir’ ailleurs au moyen de cette clé qui est souvent la clé primaire dans le

datawarehouse.

Par ailleurs, dans le cas des clés composites, on aura :

[Date Commande].[Trimestre].&[2016]&[2]

Ici, il s’agit de trimestres dont la clé est composée du couple (Année, Numéro de trimestre).

Ces appellations par clé sont évidemment à privilégier du fait de l’invariance de la clé (dans le temps et par

rapport aux langues par exemple).

1. Catégories

2. Sous catégories

3. Produits



Appellation par nom :

[Produit].[Catalogue].[Categorie].[Composant]

On note le chemin complet Dimension.Hiérarchie.Niveau.Nom

Notion de tuple Quand on cherche des données dans le cube, on fait ce que l’on appelle du slicing = découpe de tranches ou

du dicing = découpe de dés.

La notion de tuple va nous permetter cela :

(Membre1, membre2, … membreN)

Tout se passe comme si, en SQL, vous écriviez AND

Where X=Membre1 AND y=Membre2 …. AND k=MembreN.

A noter les parenthèses ouvrante et fermante pour définir le tuple.

Notion de set

Il est très fréquent d’avoir besoin de travailler sur des ensembles de données les sets.

Ici la notation (en extension) utilise des accolades :

{(Membre1, membre2, … membreN), (Membre1, membre2, … membreN)…}

On voit qu’un set est un ensemble de tuples, c’est comme si, en SQL, vous écriviez des OR :

Where (x=Membre1 and y =membre2…) OR (x=membre1 and y = membre2…)

Combinaisons de membres, tuples, sets Ces notions sont fondamentales, car tout le lange MDX est basé là-dessus.

On va écrire des membres statiques, mais aussi dynamiques, des tuples statiques ou dynamiques, etc.

Le langage va avoir des fonctions qui utilisent des membres, tuples et sets en paramètres, mais aussi des

fonctions qui rendent des membres, tuples et sets.

Je le dis dans mes formations : chaque fois que vous avez un doute, revenez aux fondamentaux :

Membre ? Tuple ? Set ?



Cas particulier des mesures

En conception, on prend bien soin de les définir à part, mais en manipulation c’est le contraire :

Une mesure est en fait un membre de la dimension des mesures :

[Measures].[Montant Ventes]

Est donc une mesure (sans hiérarchie, ni niveaux).

(Ce genre d’écriture peut servir ailleurs mais n’est pas fortement conseillée…)

Nos premières requêtes

C’est là où le débutant va souffrir, et quelque fois abandonner définitivement ce langage qui ne le mérite

pourtant pas !

Au début, on se dit : c’est du SQL !

Effectivement des mots y ressemblent :

SELECT … FROM …. WHERE..

Mais ce sont des faux amis, car MDX ne ressemble pas du tout à SQL !

Que fait-on avec ces ordres SELECT ?

En fait on va projeter sur des axes des croisements de mesures et de membres de dimension ; ces axes étant

habituellement deux :

Le langage prévoit, en théorie, jusqu’à 128 axes mais l’aspect pratique est vite limité : ou afficher tous ces

axes ?

Où faire nos premières requêtes MDX ?

Sous Management Studio, en se connectant sur une base multidimensionnelle et créant une requête MDX

(Attention pas DMX !)

Les colonnes (COLUMNS ou 0)

Les lignes (ROWS ou 1)



Requête sur un seul axe

Voici cette requête :

select [Measures].[Montant Ventes] on columns from [TpLangageMDX];

On a projeté sur les colonnes la valeur de la mesure Montant des ventes.

Pour quelles dimensions ?

Comme rien n’est précisé on a évalué les membres All de toutes les hiérarchies ; en clair : le montant des

ventes de tout le cube.

Ceci a peu d’intérêt pour le métier, mais beaucoup plus pour le développeur : c’est ce que j’appelle un

nombre ‘magique’ ; en général c’est une erreur quand on obtient ce genre de valeurs.

Requête sur deux axes

Il serait plus intéressant d’avoir le chiffre d’affaires par année :

select [Measures].[Montant Ventes] on columns, [Date Commande].[Annee].[Annee] on rows from [TpLangageMDX];



C’est correct mais quelques questions se posent :

Pourquoi [Annee].[Annee] ?

Il s’agit d’une hiérarchie d’attributs, et nous souhaitons avoir toutes les années, et non pas le membre [All]

ce que nous donnerait :

select [Measures].[Montant Ventes] on columns, [Date Commande].[Annee] on rows from [TpLangageMDX];

Il faut par ailleurs noter que je pourrai utiliser la fonction members qui donne tous les membres d’une

hiérarchie ou d’un niveau.

select [Measures].[Montant Ventes] on columns, [Date Commande].[Annee].[Annee].members on rows from [TpLangageMDX];



Donnerait les mêmes résultats…

Mais :

select [Measures].[Montant Ventes] on columns, [Date Commande].[Annee].members on rows from [TpLangageMDX];

Donnerait :

On a parcouru toute la hiérarchie Annee.

Que sont tous ces NULL ?

Ils viennent de la nature du cube qui croise tout par tout (le fameux produit cartésien banni par les DBA en

relationnel !)

On peut facilement les éliminer par le mot clé NON EMPTY :

select [Measures].[Montant Ventes] on columns, non empty [Date Commande].[Annee].[Annee] on rows from [TpLangageMDX];

Ce mot clé s’applique sur chacun des axes, au besoin, et a pour effet de supprimer toute une ligne (ou

colonne donc) qui ne contiendrait que des NULL.



Et la clause where ?

Elle nous permet de slicer sur des dimensions, mais aussi… sur des mesures.

Voyons de cas simples de where sur des membres de dimension :

select [Measures].[Montant Ventes] on columns, non empty [Date Commande].[Annee].[Annee] on rows from [TpLangageMDX] where [Produit].[Catalogue].[Categorie].&[1];

Les ventes de la catégorie Vélos, par années :

Plus subtil est le cas des dimensions :

Si nous voulons faire un tableau croisé des ventes par année ET par catégories, c’est possible de cette

manière :

select [Produit].[Catalogue].[Categorie] on columns, non empty [Date Commande].[Annee].[Annee] on rows from [TpLangageMDX] where [Measures].[Montant Ventes];

Comme dit précédemment, la dernière colonne s’élimine aussi par la clause non empty :

select non empty [Produit].[Catalogue].[Categorie] on columns, non empty [Date Commande].[Annee].[Annee] on rows from [TpLangageMDX] where [Measures].[Montant Ventes];



Résumé de la syntaxe du select

En résumé le SELECT du MDX ressemble à ceci :

SELECT ClauseAxeColonne

[,ClauseAxeLigne]

FROM NomDuCube

[WHERE ClauseAxeSlicing]

Bien sûr, nous sommes dans une introduction, la requête peut être plus complexe que cela !

Les points qui fâchent

Ces points fâchent en général le développeur SQL qui ne connait pas ces contraintes :

Un tuple comporte des membres de hiérarchies différentes :

select [Measures].[Montant Ventes] on columns, ([Produit].[Catalogue].[Categorie].[Vélo]) on rows from [TpLangageMDX];

Est autorisé, mais :

select [Measures].[Montant Ventes] on columns, ( [Produit].[Catalogue].[Categorie].[Vélo], [Produit].[Catalogue].[Categorie].[Composant] ) on rows from [TpLangageMDX];

Est interdit :



Il s’agit en fait d’un set.

Une hiérarchie ne figure que sur un seul axe (Colonne, ligne et slicing)

C’est sans doute le plus dur à accepter :

select [Measures].[Montant Ventes] on columns, non empty [Date Commande].[Calendrier].[Trimestre] on rows from [TpLangageMDX];

Mais un slincig sur l’année ne passera pas :

select [Measures].[Montant Ventes] on columns, non empty [Date Commande].[Calendrier].[Trimestre] on rows from [TpLangageMDX] where [Date Commande].[Calendrier].[Annee].&[2015];

Un contournement immédiat est d’utiliser une autre hiérarchie !

select [Measures].[Montant Ventes] on columns, non empty [Date Commande].[Calendrier].[Trimestre] on rows from [TpLangageMDX] where [Date Commande].[Annee].[Annee].&[2015];



Mais cette solution peut entrainer certains à dupliquer toutes les hiérarchies, ce qui n’est pas une bonne

pratique !

Si vous allez plus loin vous verrez d’autres solutions avec le filtrage et les sous-cubes.

Aller plus loin

Vous pouvez, au choix :

Pratique du langage MDX

Me voir ‘en live’ chez Orsys

Attendre le prochain article

Acheter mon livre sur le sujet :

http://www.youscribe.com/catalogue/livres/ressources-professionnelles/informatique/pratique-du-langage-mdx-1709671

Contacter l’auteur

SQL Server: Le blog de Dominique Verrière

Contacter l’auteur

Dominique Verrière est un consultant spécialisé sur les technologies SQL Server : moteur relationnel, SSIS, SSRS et SSAS. Il intervient dans les entreprises pour des missions d'audit, de suivi de performances, d'administration de bases de données. Les bases de données dont il s'occupe peuvent contenir plusieurs milliards de lignes et atteindre des Téra octets; son expérience du terrain est donc significative. Afin de compléter cet article, un blog www.dominiqueverriere.fr est régulièrement mis à jour avec des articles sur les nouveautés ou expériences nouvelles de l'auteur

http://www.dominiqueverriere.fr/

Découverte du langage MDX partie 1 - dominique …...Découverte du langage MDX partie 1 SQL Server...

Documents

Transcript of Découverte du langage MDX partie 1 - dominique …...Découverte du langage MDX partie 1 SQL Server...