Droit au but avec ADO .Net

Supposons que vous travailliez
pour la célèbre chaîne de librairies
Pubs et que la Direction veuille
connaître les statistiques de ventes des
livres des différents auteurs, par magasin.
Vous pourriez créer un rapport tabulaire
à  trois colonnes en utilisant une
vue comme celle du listing 1. Cette
vue, wwSales, donne la liste des ventes
de livres groupées par magasin et par
auteur, avec chaque triplette auteurmagasin-
ventes présente dans une
ligne. La figure 1 montre le rapport tabulaire
produit par la vue du listing 1. A
l’évidence, ce rapport serait plus facile
à  lire et plus instructif si on le présentait
sous forme de colonnes comme celui
de la figure 2. Le rapport crosstab
présente les noms de magasins horizontalement
dans les en-têtes de colonnes
plutôt qu’à  côté des noms d’auteurs
dans les lignes. Ainsi, pour
trouver les ventes de l’auteur
MacFeather à  Bookbeat, on regarde
l’intersection de la ligne Stearns
MacFeather et de la colonne Bookbeat.

Les rapports crosstab existent en
deux catégories : largeur fixe et largeur
variable. Pour les rapports de largeur fixe, on connaît au moment de la
conception le nombre des colonnes du
rapport et leurs noms. Il est facile de
produire un rapport crosstab de largeur
fixe à  l’aide d’une requête T-SQL,
parce que l’on peut coder en dur l’expression
CASE imbriquée dans une
fonction agrégée pour évaluer chaque
colonne de sortie. Le listing 2 montre
un exemple d’utilisation d’expression
CASE dans une requête crosstab de largeur
fixe pour notre application de librairies
Pubs. La première expression
CASE du listing 2 dit : si la valeur de la
colonne Store est égale à  celle de
« Barnum », renvoyer la valeur dans la
colonne Sales ; sinon, renvoyer 0. La requête
crosstab utilise les fonctions
SUM() dans ses expressions de colonne,
donc il n’est pas nécessaire de
pré-agréger les données dans la vue
qu’elle utilise pour sa source de données.
Donc, dans sa clause FROM, la requête
crosstab du listing 2 utilise la vue
vwSales2 que le listing 3 crée, au lieu
de vwSales. Si vous utilisez COUNT()
ou AVG() comme fonction agrégée,
laissez « Else 0 » en dehors de l’expression
CASE ; sinon, les réponses feront
la moyenne ou le comptage des transactions
qui ont des valeurs sales de 0,
lesquelles n’existent pas vraiment.
Quand vous enlevez « Else 0 » de l’expression
CASE, vous obtenez des valeurs
NULL au lieu de zéros pour les couples auteur-magasin pour lesquels
il n’existe pas d’enregistrement.

Mais admettons que Pubs a une
centaine de librairies, avec de nouvelles
qui ouvrent et d’autres qui ferment
chaque fois. Dans ce cas, on a besoin
d’un rapport crosstab de largeur
variable qui lit dynamiquement les
noms de magasins à  partir des données
et produit une colonne pour chacun,
indépendamment du nombre qui
existe ce mois-là . Nous allons explorer
deux méthodes très différentes de
création de rapports crosstab de largeur
variable. Le premier exemple utilise
dynamic SQL dans une procédure
stockée pour créer une chaîne de requête
crosstab qui contient des expressions
CASE. La commande EXEC exécute
la chaîne de requête pour fournir
le rapport en retour. Le second
exemple procède différemment. Au
lieu d’expressions CASE ou de dynamic
SQL, il utilise les nouvelles fonctions
relationnelles d’ADO.NET – le composant
d’accès aux données de Visual
Studio .NET – pour tabuler les données.
Au fil de la description, j’indiquerai
les avantages et inconvénients de
chaque méthode.