OLAP pour développeurs

Après la release de SQL Server 7.0
OLAP Services par Microsoft, l’une des
fonctions les plus fréquemment sollicitées
était la possibilité d’extraire les
données sous-jacentes utilisées pour
calculer la valeur d’une cellule particulière.
Cette possibilité est intéressante si l’on veut savoir, par exemple, quels
clients ou quels produits sont inclus
dans une cellule donnée. OLAP a la
possibilité d’agréger les lignes d’une
table de faits – sa principale force –
mais sa nature propre fait aussi abstraction
des lignes de détails et complique
donc leur recherche. Avant la release
d’Analysis Services, un
développeur confronté à  ce défi devait
instaurer une couche de mapping de
métadonnées entre les membres du
cube et la base de données relationnelle
(qui contenait le schéma étoile
ou flocon de neige). Lorsqu’il accédait
à  une cellule, le code devait lire à  la fois l’information du membre du cube et
l’éventuel filtre appliqué à  la requête.
Ensuite, le code devait générer une requête
SQL pour joindre des tables multiples
provenant de la base de données
relationnelle, exécuter la requête, et
renvoyer un jeu de résultats. Il n’est
pas si simple d’écrire du code pour accéder
correctement à  une cellule de
cette manière. Avec Analysis Services, il
n’est plus du tout nécessaire d’écrire
ou de maintenir ce code.

Analysis Services contient le code
pour mettre en oeuvre drillthrough ; la
figure 1 montre une vue supérieure de
la manière dont Analysis Services accomplit
le drillthrough. L’application
client exécute une instruction MDX
qui est transmise du Pivot Table Service
local au serveur OLAP. Rappelons que
le Pivot Table Service est le fournisseur
OLE DB qui offre le caching, le traitement
du cube local, et les connexions à 
un serveur Analysis (OLAP). Le serveur
OLAP utilise ensuite les options de
configuration et les paramètres de sécurité
du cube pour créer une instruction
SQL et l’envoyer à  la base de données
relationnelle qui contient les données
de détail. L’instruction SQL renvoie
le jeu de lignes OLE DB retourné
par l’intermédiaire du serveur OLAP et
de Pivot Table Services, à  l’application
client. En principe, le client accède aux
données par l’intermédiaire d’un objet
ADO Recordset.

Pour mettre en oeuvre la fonction
drillthrough, il faut effectuer des
tâches à  la fois administratives et
propres à  l’application. Du point de
vue d’un administrateur, la première
tâche consiste à  valider le cube pour le
drillthrough. Il est indispensable que
l’administrateur puisse contrôler la validation
du cube pour drillthrough,
parce que les cellules contiennent souvent
les données de milliers, voire de
millions, de lignes. Et donc, si on laisse
tous les utilisateurs interroger ces données
sans restriction aucune, on va
tout droit à  l’engorgement du réseau.
Pour valider le cube pour drillthrough,
démarrez le Cube Editor et sélectionnez
Tools, Drillthrough Options. Dans la boîte de dialogue Cube Drillthrough
Options résultante, cochez simplement
la case Enable drillthrough,
comme le montre la figure 2. Analysis
Services supporte le drillthrough pour
des cubes normaux, virtuels, ou liés,
mais Analysis Services ne vous permettra
pas d’utiliser drillthrough sur une
cellule ayant des valeurs fondées sur
des cellules membres calculées ou des
formules membres personnalisées.

Notez dans la figure 2 que vous devez
valider le drillthrough et que la liste
de colonnes contient toutes les colonnes
des tables de faits et de dimensions
dans le schéma. Ici, le nom du
cube est Enrollment et le cube permet
le reporting sur les inscriptions des
étudiants dans les cours d’éducation
technique de Quilogy. Selon les colonnes
que vous sélectionnez dans
cette boîte de dialogue, Analysis
Services joindra les tables appropriées
quand il interrogera les données sousjacentes.
La boîte de dialogue de la figure
2 contient aussi un onglet Filter
qui peut contenir une clause WHERE
destinée à  limiter le nombre de lignes
présentes dans le jeu de résultats.
Cette clasuse WHERE s’ajoute à  la
clause WHERE que drillthrough génère
dynamiquement.

Outre la validation du drillthrough
au niveau du cube, vous pouvez également
modifier les options sur chaque
partition individuelle dans les cubes
qui en contiennent plus d’une. Vous
pouvez accéder à  une boîte de dialogue
analogue à  celle de la figure 2 par
l’intermédiaire du Partition Wizard –
pour accéder au Partition Wizard, faites
un clic droit sur la partition et sélectionnez
Edit dans le menu contextuel –
en cliquant sur le bouton Advanced
Settings et Drillthrough Options. La
boîte de dialogue Partition
Drillthrough Options résultante permet
de changer les colonnes et le filtre
à  utiliser lors de la création des données
drillthrough depuis cette partition.
La possibilité de définir des options
drillthrough sur des partitions
individuelles, signifie que si l’on exécute une opération drillthrough sur
une cellule qui agrège des données
provenant de plus d’une partition,
chaque partition renvoie son propre
jeu de résultats et les colonnes qu’il
contient peuvent différer entre elles.
Les développeurs d’applications doivent
connaître ce comportement afin
de pouvoir afficher les résultats en
conséquence. La tâche suivante de
l’administrateur, configurer la sécurité
du drillthrough, demande d’utiliser la
boîte de dialogue Cube Role Manager
et de cliquer sur le paramètre
Drillthrough pour le rôle auquel vous
voulez donner accès. Chaque rôle a un
paramètre de sécurité, appelé Allow
Drillthrough, que vous pouvez sélectionner
pour permettre à  ce rôle d’exécuter
les requêtes qui effectuent une
opération drillthrough.