9 conseils en services d’analyse

1 – Utiliser des vues comme source pour les cubes et dimensions

Utilisez toujours des vues comme
source de données pour les tables de
dimensions et les tables de faits. En effet,
les vues fournissent une couche
d’abstraction intéressante entre la
table et le cube ; mais elles permettent aussi à  votre personnel d’appliquer sa
compétence en SGBDR (systèmes de
gestion de bases de données relationnelle).
En utilisant une vue comme une
table de faits, vous pouvez gérer les
mises à  jour incrémentielles en modifiant
la clause WHERE dans la vue, au
lieu d’attribuer la clause WHERE à  une
partition OLAP. En utilisant une vue
pour sourcer une dimension, vous
pouvez définir dans la vue une logique
qui, sans cela, devrait être définie dans
Analysis Services (noms de membres
formulés, propriétés de membres
formulés, par exemple).

2 – Laisser les flocons de neige de côté

Analysis Services vous permet de sourcer
les dimensions à  partir d’un
schéma flocon de neige normalisé ou
d’un schéma en étoile aplati. Microsoft
recommande d’aplatir les dimensions
flocons de neige en étoile pour des raisons
de performances, une pratique
suivie par la plupart des développeurs
d’Analysis Services. Cependant, à 
moins que le data mart relationnel soit
consommé par quelque chose d’autre
qu’Analysis Services, cette pratique
présente peu d’avantages et beaucoup
d’inconvénients. Pour ces raisons,
résistez à  la tentation d’aplatir :

• Un schéma flocon de neige procure
  les avantages d’un modèle normalisé.
  Avec un schéma en étoile, gérer
  des attributs pour les membres nonfeuille
  répétitifs est fastidieux et
  difficile.

• Un flocon de neige donne des clés
  uniques à  chaque niveau. Vous pouvez
  ainsi importer des données dans
  un cube à  n’importe quel niveau de
  granularité. C’est très intéressant
  dans des applications de planification
  financière par exemple.

Comme les tables de dimensions
ne sont pas interrogées à  l’exécution
(sauf dans le mode OLAP relationnel –
ROLAP – notoirement lent), les dimensions
flocon de neige n’ont pas
d’impact sur la performance de la
requête. Le seul inconvénient d’une
dimension flocon de neige est qu’elle
(la dimension, pas le cube) est plus
lente à  traiter qu’une étoile en
raison des jointures nécessaires.
Cependant, le temps qu’il faut pour
traiter les dimensions est négligeable
par rapport au temps nécessaire au
traitement des cubes. Il faut donc
adopter la méthode des flocons de
neige, sauf dans le cas suivant : quand
la dimension est énorme et que le créneau
de temps alloué au traitement est
étroit.

3 – Eviter un logiciel client handicapé

Vous viendrait-il à  l’idée d’utiliser un
outil frontal pour un SGBDR qui ne
vous permet pas de spécifier une instruction
SQL ? Certainement pas. C’est
pourtant d’une certaine façon ce qui
attend les développeurs dans l’espace
OLAP. En effet, de nombreux outils de
requête et de reporting standard qui
fonctionnent avec Analysis Services
sont fondamentalement handicapés :
ils ne permettent pas aux développeurs
de fournir une instruction MDX
SELECT. Le problème est le suivant :
aucun des clients commerciaux, même
les plus robustes, n’expose toute la
puissance MDX. Après tout, peut-être
que vos utilisateurs n’ont besoin que
de naviguer dans les cubes. Cependant
pour ne pas perdre votre liberté de manoeuvre,
choisissez un outil frontal qui
permette au développeur de spécifier
des instructions MDX SELECT personnalisées.
Ce conseil mérite toutefois une
mise en garde. Les outils client qui
n’exposent pas MDX sont généralement
étroitement liés à  Analysis
Services – ils fournissent la connectivité
à  d’autres sources de données.
Mais je ne pense pas que ce soit trop
demander à  ces fournisseurs d’exposer
une chaîne de requête MDX SELECT
comme moyen de passage.

4 – Obtenir les noms de niveaux directement à  partir du Get-Go

Lors de la première construction d’une
dimension, les noms de niveaux sont,
par défaut, les mêmes que les noms de
colonnes dans la table de dimensions
(excepté qu’Analysis Services remplace
les caractères spéciaux par des espaces).
On se retrouve donc avec des
noms de niveaux comme Cust Code,
ou pire. Ensuite, une fois le cube traité,
on ne peut pas changer les noms de niveaux
sans retraiter la dimension, ce
qui entraîne à  son tour le retraitement
du cube. Comme il est fastidieux de renommer
les niveaux une fois que le
cube a été traité, de nombreux cubes
vont en production avec des noms de
niveaux affreusement cryptés. Pour
compliquer les choses, les formules
MDX sont souvent écrites avec des dépendances
sur les noms de niveaux inamicaux,
ce qui complique encore davantage
le renommage des niveaux.
Comme les cubes sont supposés être
aisément utilisables d’emblée, il vaut
mieux éviter cet écueil en ayant les
bons noms de niveaux dès le début.
Dès que vous construirez une dimension,
changez les noms de niveaux par
défaut en noms clairs et conviviaux,
avant de placer la dimension dans le
cube.