Voici ma requête. Elle affiche le nombre de produits distincts vendus par Pays et Couleur de produits, en filtrant sur les produits de type Vélo et les clients Mâles (dans le slicer) et les Produits de la gamme « Montagne » pour les années de vente 2005 et 2006 dans un subcube.

SELECT
{
     [Measures].[MonCount]
}
 ON 0,
{
    [Customer].[Customer Geography].[Country]
    *
    [Product].[Color].Members

} ON 1
FROM
(
    SELECT
    {
        [Date].[Calendar Year].&[2005],
        [Date].[Calendar Year].&[2006]
    }
    *[Product].[Product Model Lines].[Product Line].&[M]
    ON 0
    FROM [Adventure Works]
)
WHERE
(
    [Product].[Category].&[1]
    ,[Customer].[Gender].&[M]
)

Premier essai : un compte de tous les produits.

Count
(
    [Product].[Product].[Product]
)

Ca ne marche pas terrible: le compte est dé-corrélé de tout contexte car les membres calculés n‘auto-existent pas les sets. Cela affiche la même valeur partout, à savoir le nombre de produits de la dimension Produit. Amélioration : on ajoute donc un Existing. Existing, selon MSDN, force “la prise en compte des coordonnées courantes” de requête pour le jeu de produits. On constate que cela fonctionne pour les slicing par les hiérarchies de la même dimension, ainsi que le slicer ou clause WHERE).

Count
(
    Existing [Product].[Product].[Product]
)

C’est mieux, mais le filtrage par Produit.Modèle du sous-cube n’est pas pris en compte. Nous verrons pourquoi dans quelques lignes.
Une des solutions à ce problème de non prise en compte du sous-SELECT est de le faire en deux passes, en existant d’abord le jeu de produit dans un Dynamic Set – les jeux sont auto-existés en MDX dans le contexte de la requête et donc du subselect – le sous cube est appliqué sur le jeu. C’est Hilmar Buchta qui a le premier abordé cet usage intéressant des jeux nommés dynamiques, introduits en SQL 2008.

SET [QueryContextProducts]
AS
[Product].[Product].[Product]

MEMBER [Measures].[MonDistinctCount]
AS
Count
(
    Existing [QueryContextProducts]
)

Cependant là encore le slicing par pays n’est toujours pas visible: il faut donc cette fois utiliser l’opérateur Exists, qui fait une requête au niveau d’un groupe de mesure, pour évaluer l’indicateur sur le MeasureGroup des ventes qui relie le produit aux autres dimensions de la requête.

Count
(
    Exists
    (
        [Product].[Product].[Product]
        ,,"Internet Sales"
    )
) 

L’Exists n’applique cependant pas les coordonnées courantes sur l’axe Produit – ce que fait EXISTING comme nous l’avons vu – ce qui fait que l’indicateur ne se ventile pas par Couleur, et n’applique pas le filtre sur la gamme du slicer: les 55 produits vendus en Australie correspondent bien à 55 valeurs distinctes de ProductID dans la table de faits, mais le filtrage a posteriori par couleur en lignes, par gamme et par catégorie en filtres n’est pas pris en compte.
C’est logique MSDNement parlant: Exists marche comme ça. A noter qu’Exists sur un groupe est équivalent à un NonEmpty sur une des mesures du même groupe (bon sauf si cette mesure à un NullProcessing à Preserve mais ne chipotons pas).

En rajoutant l’opérateur Existing nous allons maintenant forcer l’application de ces fameuses “coordonnées courantes” du Produit sur le Set sorti par Exists, mais nous retombons dans le même problème que plus haut: celles fixées dans le sous-cube ne sont pas considérées. C’est là aussi by-design: comme le dit Mosha dans un post sur SDN: “EXISTING operator takes into account current coordinate. The whole difference between WHERE clause and subselect, is that WHERE clause sets current coordinate, while subselects merely do top level Exists with Axis and apply visual totals“. Bon OK, dommage que cela ne soit pas dans la doc… Les chiffres ci-dessous ne prennent donc pas en compte le filtrage sur [Product Model Lines], et sont là encore faux.

Count
(
    Existing
    Exists
    (
        [Product].[Product].[Product]
        ,,"Internet Sales"
    )
) 

A noter que du coup ce membre est équivalent à celui ci-dessous, dans lequel l’application du Model Line est précisée mais inutile : le CurrentMember de cette hiérarchie est toujours positionné sur le (All) car si le Subcube applique bien Exists et VisualTotals, il n’altère pas les coordonnées courantes. (Mis en lumière par Mosha dans plusieurs de ses vieux articles, comme Multiselect Friendly MDX Calculations ou Default members, MDX Scripts, Security, KPIs and Perspectives.)

Count
(
    Exists
    (
        [Product].[Product].[Product]
        ,([Product].[Color].CurrentMember,[Product].[Product Model Lines].CurrentMember)
        ,"Internet Sales"
    )
) 

Il en résulte que la seule solution viable et universelle, qui prend en compte tous les filtrages est celle-ci : un Count sur un Existing Exists (ou NonEmpty) appliqué sur un Dynamic Set. Je vous l’accorde, on a vu plus straightforward. A noter aussi que l’ordre d’application importe peu fonctionnellement, on aurait pu faire un Exists d’Existing, mais Chris Webb a montré en 2009 que l’ordre utilisé ci-dessous est le plus rapide. La raison n’est pas connue mais une des hypothèses considérées, à défaut d’avoir le nez dans le moteur, est qu’Exists est Set-Based donc moins impacté par la cardinalité du Set qu’Existing qui semble plus heureux sur une volumétrie réduite.

Count
(
    Existing
    Exists
    (
        [QueryContextProducts]
        ,,"Internet Sales"
    )
) 

Alors simple le MDX non? Des objections?

Bonne lecture!

Son but dans la vie: mettre en avant les bonnes productions françaises de chez nous en terme de BI, projets, articles, séminaires… permettre aux consultants décisionnels d’échanger, de discuter bonnes pratiques en les fédérant, et accessoirement faire des trucs sur SQL Server et affiliés au GUSS où personne de parlera des quorums de clusters de Christophe Laporte, David Barbarin, Cricri Robert ou Seb Pertus^^.

Comme on a rien trouvé de plus fédérateur qu’une bonne bière et un bon sujet polémique, vous êtes donc tous invités au pot de naissance de la FrenchConnection.BI, qui prendra la forme d’un…

1er Afterwork de la communauté BI SQL Server sur le thème
“BI Self-service, mythe ou réalité”

le jeudi 22 mars 2012 à partir de 19h30

au Charlie Birdy, Place Etienne Pernet
(Paris 15, M8 Commerce ou M10 Emile Zola)

Parlez en autour de vous, et viendez! Banzaï!

Bon visionnage!

Plus de détails ici, la version d’évaluation de SQL Server 2012 RTM est dès maintenant disponible, à la veille du Virtual Launch Event dont je vous ai parlé il y a quelques jours.

La sortie définitive est quant à elle prévue le 1er avril 2012.

Bonne évaluation!

Il y a une autre raison à ce post. Pour taper les modèles tabulaires, DAX est beaucoup plus efficace que le Formula Engine MDX qu’Excel utilise pour l’attaquer. Donc dans des frontaux où le développeur écrit sa requête, savoir écrire du DAX est à mon sens indispensable. Donc pour la majorité des gens, qui font du SSRS (par exemple) je pense qu’il vaut mieux présenter DAX comme étant à la base un truc fondamentalement relationnel. Au sens d’Edgar Codd - loué soit son nom. Des tables, des jointures, des agrégats… Mon objectif ici est de vous expliquer DAX de cette manière, en reprenant le chapitre 1 de ma formation de SQL de base, et en transposant les concepts.

Back to school : algèbre relationnelle, projections et sélections

DAX manipule des tables. L’instruction la plus simple qu’on puisse faire sur une table est une projection de toutes ces colonnes :

Evaluate
(
	‘Product’
)

fait un

SELECT *
FROM [Product]

rien de plus. Si je souhaite faire une sélection, au sens de l’algèbre relationnelle, c’est-à-dire un filtrage, je vais simplement utiliser la fonction Filter, qui remplace le WHERE.

Evaluate
(
	Filter
	(
		Product,
		Product[Color] = "Red" && Product[Weight] > 10
	)
) 

Il s’agit donc d’un

SELECT *
FROM Product
WHERE Color= 'Red' AND Size > 10

Faisons maintenant une projection restreinte et n’affichons que les bonnes colonnes. La manière de le faire est d’utiliser la fonction Summarize

Evaluate
(
	Summarize
	(
		Filter
		(
			Product,
			Product[Color]="Red"
		),
		Product[Product ID],
		Product[Model Name]
	)
) 

Attention. Ceci est en réalité équivalent à un SELECT DISTINCT car Summarize applique un DISTINCT. La raison est très simple: DAX n’est pas optimisé pour des projections de certaines colonnes seules sans DISTINCT. Pour faire une vraie projection d’algèbre relationnelle sur le niveau de granularité le plus fin, il faut donc avoir une ou plusieurs colonnes UNIQUE dans les colonnes projetées. En ce qui concerne l’aliasing des colonnes, il n’est pas facile à mettre en œuvre. Il faut utiliser l’astuce de Marco Russo qui consiste à projeter une ou plusieurs colonnes qui donnent l’unicité, et à aller chercher les autres colonnes via des Calculate dans un AddColumns.

Oula je suis allé un peu vite pardon. AddColumns permet d’ajouter des colonnes, par exemple calculées, et Calculate évalue simplement une expression dans le contexte actuel.

Evaluate
(
	AddColumns
	(
		Summarize
		(
			Filter
			(
				Product,
				Product[Color]="Red"
			),
			Product[Product ID]
		),
		"Nom du produit", Calculate(Values(Product[Model Name]))
	)
) 

Pas super intuitif hein. Mais qui se préoccupe d’aliaser les colonnes. Sérieusement.

Que serait un rapport sans agrégations ?

C’est bien la fonction Summarize qui va jouer ce rôle d’agrégateur. En réalité elle permet de définir dans une seule fonction :
- La table
- Les colonnes de groupements
- Les agrégations d’une requête

Par exemple :

Evaluate
(
	Summarize
	(
		Filter
		(
			Product,
			Product[Color]="Red"
		),
		Product[Model Name],
		"Poids Moyen", Average(Product[Weight])
	)
) 

exécute bien la requête équivalente à

SELECT
[Model Name], AVG([Weight]) AS [Poids]
FROM Product
WHERE Color= 'Red' AND Size > 10
GROUP BY [Model Name]

La plupart des agrégations communes existent. Elles sont simplement parfois renommées et DAX n’étant pas super polymorphique vous en verrez des déclinaisons selon le type attendu en argument … La projection exécutée par Summarize quant à elle est simple à comprendre: les colonnes récupérées sont les groupements et les agrégations. Quant au HAVING, c’est un filtre comme les autres. Du point de vue de DAX, tout n’est que table imbriquées. Si je souhaite faire un filtre sur poids, il me suffit de faire :

Evaluate
(
	Filter
	(
		Summarize
		(
			Filter
			(
				Product,
				Product[Color]="Red"
			),
			Product[Model Name],
			"Poids Moyen", Average(Product[Weight])
		),
		[Poids Moyen] > 10
	)
) 

Cette requête est donc équivalent au SQL suivant: le premier qui demande pourquoi le HAVING ne voit pas les alias est prié d’aller relire tout le standard SQL ANSI au coin.

SELECT
[Model Name], AVG([Weight]) AS [Poids]
FROM Product
WHERE Color= 'Red' AND Size > 10
GROUP BY [Model Name]
HAVING AVG([Weight])> 10

Sans oublier les tris !

J’en aurais presque oublié le tri. Comme dans SQL c’est la dernière instruction dans l’ordre d’évaluation « logique ». Et cela s’appelle aussi Order By. Ca c’est sympa.

Evaluate
(
	Summarize
	(
		Filter
		(
			Product,
			Product[Color]="Red"
		),
		Product[Model Name],
		"Poids", AVERAGE(Product[Weight])
	)
)
Order By [Poids] DESC

Sans aucun étonnement, voilà le SQL généré. A noter que nous avons maintenant un statement SQL monotabulaire “complet”.

SELECT
[Model Name], AVG([Weight]) AS [Poids]
FROM Product
WHERE Color= 'Red' AND Size > 10
GROUP BY [Model Name]
HAVING AVG([Weight])> 10
ORDER BY [Poids] DESC

Jointures et relations entre tables : tout – ou presque – est implicite

A la différence de SQL, les jointures sont implicites en DAX. Comme dans un cube, un modèle tabulaire a ses relations définies dans le Dimension Us… pardon dans le designer de relations. Bon en réalité il y a des cas où il faudra les expliciter. Mais on en est pas là. Cette implicitesse… implicité… implicitude signifie que si j’écris la requête suivante :

Evaluate
(
	AddColumns
	(
		Filter
		(
			Product,
			Product[Color] = "Red"
		),
		"Sous catégorie",RELATED('Product Subcategory'[Product Subcategory Name])
	)
)
Order By [Model Name]

La fonction RELATED va juste dire de faire une jointure externe gauche vers la table sous catégorie, en se basant sur la relation définie dans mon modèle – à savoir ‘Product’[Product Subcategory ID] = ‘Product Subcategory‘[Product Subcategory ID] et de ramener cette dernière. On ne peut pas spécifier la condition de jointure, et c’est en cela qu’on se rapproche d’un cube. Mais juste un peu. Bon en SQL ça donne ça:

SELECT p.*, psc.[Product Subcategory Name]
FROM [Product] p
LEFT JOIN [Product Subcategory] psc
ON psc.[Product Subcategory ID]=p.[Product Subcategory ID]
ORDER BY [Model Name]

Cela marche évidemment aussi pour des relations à plus d’une indirection. Je peux bien évidemment aller chercher RELATED(‘Product Category’[Product Category Name]) dans la table catégorie, à laquelle je suis relié par une table intermédiaire (sous catégorie). Qui a parlé de relation Referenced? En revanche cette requête échoue misérablement :

Evaluate
(
	AddColumns
	(
		Filter
		(
			Product,
			Product[Color] = "Red"
		),
		"Année",RELATED('Date'[Calendar Year])
	)
)
Order By [Model Name]

En effet les liens existent certes entre temps et produit (J’ai une many to many entre mes produits et mes dates, qui est la table de faits des ventes) mais ce ne sont pas des liens 1:N comme exigé par la fonction RELATED. Dit autrement Related est un peu comme un Lookup en SSIS : il va chercher une valeur unique basée sur des relations orientées vers la table cible. En utilisant des agrégats c’est encore plus simple : dans la fonction SUMMARIZE les Calculate sont implicites, les agrégats sont donc calculés en suivant les relations.

Evaluate
(
	Summarize
	(
		'Internet Sales',
		Product[Model Name],
		"Somme des ventes Internet", Sum('Internet Sales'[Sales Amount])
	)
)
Order By [Model Name] 

Attention par contre! La table “de base” est importante! C’est elle qui détermine de quel côté se situe la jointure externe. Si je fais comme ci-dessous j’affiche tous les produits, même ceux sans ventes (LEFT OUTER JOIN)

Evaluate
 (
	Summarize
	(
		Product,
		Product[Model Name],
		"Somme des ventes Internet", Sum('Internet Sales'[Sales Amount])
	)
)
Order By [Model Name] 

On comprend donc que dans le cas d’une application analytique, la première table d’un Summarize est très généralement une des tables de faits: c’est depuis elle que les autres arguments du GROUP BY vont venir s’afficher. Pour les filtrages, on peut encore utiliser la fonction Filter vue précédemment. Le problème de Filter, c’est qu’elle est à la base faite pour filtrer les colonnes d’une même table. Donc la solution immédiate c’est d’invoquer Related pour récupérer les valeurs et filtrer.

Evaluate
(
	Filter
	(
		'Internet Sales',
		Related('Product'[Color])="Red"
		&&
		Related('Geography'[Country Region Name])="France"
	)
)

Un peu fastidieux et répétitif. Pour remplacer cela il existe la fonction CalculateTable, qui va appliquer à un ensemble infini de filtres, comme suit. J’ai donc ici les ventes de produits rouges en France.

Evaluate
(
	CalculateTable
	(
		'Internet Sales',
		'Product'[Color]="Red",
		'Geography'[Country Region Name]="France"
	)
)

Customisons ça avec un Summarize et quelques autres colonnes, ainsi que quelques agrégats et voilà déjà un beau rapport non ?

Evaluate
(
	Filter
	(
		CalculateTable
		(
			Summarize
			(
				'Internet Sales',
				'Date'[Calendar Year],
				'Product Category'[Product Category Name],
				'Product Subcategory'[Product Subcategory Name],
				"Nombre de ventes", CountRows('Internet Sales'),
				"Total des ventes", Sum('Internet Sales'[Sales Amount])
			),
			Filter
(
'Product','Product'[Color]="Red"
||
'Product'[Color]="Yellow"
),
			'Geography'[Country Region Name]="France"

		),
		[Total des ventes] > 5000
	)
)
Order By [Calendar Year],[Product Category Name]

Ce qui donne en SQL:

SELECT
	s.*,
	d.[Calendar Year],
	pc.[Product Category Name],
	psc.[Product Subcategory Name],
	COUNT(*) AS [Nombre de ventes],
	SUM(s.[Sales Amount]) AS [Total des ventes]
FROM [Internet Sales] s
LEFT JOIN [Date] d
ON s.[Order Date Key] = d.[Date Key]
LEFT JOIN [Product] p
ON p.[Product ID] = s.[Product ID]
LEFT JOIN [Product Subcategory] psc
ON p.[Product Subcategory ID] = psc.[Product Subcategory ID]
LEFT JOIN [Product Category] pc
ON pc.[Product Category ID] = psc.[Product Category ID]
LEFT JOIN [Customer] c
ON s.[Customer ID]= c.[Customer ID]
LEFT JOIN [Geography] g
ON g.[Geography ID]= c.[Geography ID]
WHERE p.Color IN ('Red','Yellow') AND g.Country='France'
GROUP BY
	s.*,
	d.[Calendar Year],
	pc.[Product Category Name],
	psc.[Product Subcategory Name]
HAVING SUM(s.[Sales Amount])>5000
ORDER BY [Calendar Year],[Product Category Name]

Je pense que ces quelques fonctions constituent une bonne intro au DAX, vous allez déjà pouvoir sortir quelques rapports. La prochaine fois on s’attaque au plus difficile : le DAX pour les fans de MDX, que j’aurais pu appeler où « Comment on fait un à #@%$ de YearToDate ?! » où « Où qu’il est Exists ? ». Bon weekend!

Comment cela marche alors dans SSIS?

SQL Server propose un mode d’exécution appelé FMTONLY ON. Si vous regardez Books Online, vous verrez que cette instruction permet effectivement une inspection des chemins de code et le retour explicite de métadonnées seules dans un objectif de validation. C’est une opération assez empirique, et qui pour être honnête marche parfois assez mal: elle ne gère pas les tables temporaires, pas les curseurs… C’est potentiellement  par exemple ce qui est assez handicapant. Ce post est assez connu sur le sujet des tables temporaires et propose des workarounds qui se valent…

Quelle est la parade aujourd’hui?

En réalité il y en a plusieurs. Une des solutions consiste à désactiver ce FMTONLY pour que SSIS exécute réellement pour extraire les métas. Et effectivement cela fonctionne. C’est la technique bien connue de pas mal de devs, mais elle a ses inconvénients aussi car elle cause de sévères problèmes de performances (SSIS valide constamment les sources, et FMTONLY ON est quand même plus économe qu’une exécution complète).

Il y a aussi la parade qui consiste à faire pas mal de refactoring de code dans le T-SQL pour faire marcher FMTONLY ON. Ce qui n’est pas franchement l’objectif souhaité quand on veut faire du couplage faible entre l’ETL et ses sources… Jamie Thomson en était arrivé à la conclusion dans ce post que les PS ne sont pas faites pour ça… et que dans pareil cas les UDF sont là. Je suis assez d’accord avec lui. Sauf que parfois on ne me laisse pas le choix et je dois quand même utiliser des PS.

Qu’apporte SQL Server 2012?

Il apporte la possibilité d’exécuter une procédure stockée en spécifiant le contrat attendu. Les métadonnées exposées sont celles que vous spécifiez. Si le contrat est enfreint alors l’exécution échoue. Ecrivons une requête bien inutilisable, avec une belle table temporaire pour SSIS

CREATE PROC usp_GetTopCustomersForYear(@Year INT)
AS
 SET NOCOUNT ON
 --Une requête toute bête dans une table temporaire
 SELECT TOP 10 c.CustomerAlternateKey, SUM(s.SalesAmount) SalesAmount
 INTO #TopCustomers
 FROM AdventureWorksDWDenali.dbo.DimCustomer c
 JOIN AdventureWorksDWDenali.dbo.FactInternetSales s
 ON s.CustomerKey = c.CustomerKey
 JOIN AdventureWorksDWDenali.dbo.DimDate d
 ON d.DateKey = s.OrderDateKey
 WHERE d.CalendarYear=@Year
 GROUP BY c.CustomerAlternateKey
 ORDER BY SalesAmount DESC
 --Un SELECT depuis cette table
 SELECT *
 FROM #TopCustomers
GO

Essayons de l’utiliser dans SSIS: échec. Le message d’erreur indique bien que FMTONLY est incapable de parser les métadonnées d’une PS qui fait usage d’une table temporaire.

Là ou je me lancerais maintenant dans un refactoring fastidieux, je vais modifier simplement l’appel à la procédure stockée. Je vais juste spécifier ce que j’attend.

EXEC usp_GetTopCustomersForYear ?
WITH RESULT SETS
(
   (
      CustomerKey NVARCHAR(15),
      Amount FLOAT
   )
)

Le résultat est bien meilleur à tous points de vue!

Il est à noter que ce WITH RESULT SETS peut être utilisé à beaucoup d’autre endroits, pour permettre du couplage très faible entre les applications et les procédures stockées: cela va par exemple permettre de caster les types castables dans un type précis attendu, plutôt que d’être potentiellement embêté par des providers pointilleux sur le typage en cas de modification de la PS par le DBA.

Et pourquoi ne pas avoir directement permis d’exposer les métas des procédures stockées?

Parce que sinon on appellerait ça des UDF. Blague à part ce n’est pas la volonté de Microsoft, la séparation entre procédure et fonction, que les vieux codeurs Pascal connaissent bien aussi, reste dans SQL Server 2012.

D’autres choses?

Oui, on peut noter aussi pour remplacer FMTONLY de nouvelles DMV toutes propres font leur apparition: elles permettent d’exposer des catalogues de métas renvoyés par des procédures stockées si cela est possible. Mais elles partagent avec FMTONLYdes inconvénients. Ma PS n’est pas reconnaissable par ce statement, qui renvoie invariablement:

The metadata could not be determined because statement ‘SELECT * FROM #TopCustomers’ in procedure ‘usp_GetTopCustomersForYear’ uses a temp table.

SELECT *
FROM sys.dm_exec_describe_first_result_set_for_object(OBJECT_ID('dbo.usp_GetTopCustomersForYear'),1)

Voilà pour le sujet, en espérant que cela vous permette d’exécuter des PS en source plus facilement. A bientôt!

Bonne lecture!

Bon et aussi c’est gratuit ce qui ne gâche rien. Pour s’inscrire, c’est ici : http://www.sqlserverlaunch.com/ww/Home

Il y aussi des cadeaux à gagner apparemment

Le message clé: l’UDM disparaît au profit d’un nouveau modèle, le BI Semantic Model ou BISM. Ce BISM désigne techniquement l’intégration (en cours!) d’Analysis Services Multidimensional et de Tabular, que ce soit par le partage de l’API AMO (Analysis Management Objects), c’est à dire de leur modèle objet, du MDX pour les deux plateformes, des providers d’accès…
BISM est en v1.0, cela signifie que l’intégration va se poursuivre, avec, on peut l’imaginer, la fusion des types de projets, des instances, des designers, le support croisé du DAX… Toutes les hypothèses sont ouvertes!

Bon visionnage!