Le magasin avant l’entrepôt

date
ultérieure.

Ce raisonnement s’explique généralement par des contraintes budgétaires. La direction
considère souvent que l’entreposage de données représente un cycle de développement
lent, coûteux, non productif, avec un retour sur investissement (ROI : Return
On Investment) hypothétique. Après tout, comment chiffrer le ROI à  partir du regroupement
des informations de la société et de l’amélioration des analyses ? Comme les magasins
de données présentent immédiatement des bénéfices tangibles, ils séduisent généralement
davantage les financiers. Souvent, le ROI des datamarts sert à  justifier le datawarehouse.
Mais, avant de s’engager dans cette voie, il faut bien réfléchir.

En préférant un magasin à  un entrepôt de données, on peut faire l’économie de
l’acquisition d’outils de nettoyage et de gestion coûteux, nécessaires pour traiter
de gros volumes de données. De plus, les magasins de données reliés au Web permettent
de passer en ligne très rapidement (un projet prioritaire pour de plus en plus
d’entreprises). Toutefois, si la société envisage le passage éventuel à  un entrepôt
de données, le fait de commencer par un magasin peut être assimilé à  la construction
d’une maison suivie, en un deuxième temps, de l’adjonction du sous-sol.

Un entrepôt de données contient des données détaillées dénormalisées : les mêmes
données ou les mêmes faits peuvent se trouver en plusieurs endroits d’un entrepôt.
Une base de données dénormalisée évite des jointures consommatrices de temps lors
de requêtes de données. En revanche, un magasin de données utilise souvent une
structure cube (ou MOLAP) pour stocker des valeurs dérivées calculées pendant
les routines de propagation. Lorsqu’on migre d’un magasin de données à  un entrepôt
de données, on change généralement de schéma de base de données par la même occasion.
Comme le schéma d’un entrepôt diffère de celui d’un magasin de données, il faut
créer de nouveau processus et de nouvelles interfaces de réplication. En clair,
il faudra renoncer aux processus (et à  l’investissement associé) qui transféraient
précédemment les données dans le magasin de données.

Bien sûr, les datamarts n’emploient pas toujours un schéma MOLAP. Beaucoup s’appuient
sur une technologie base de données relationnelle et possèdent alors le même schéma
que les entrepôts de données. Alors que les données stockées dans des magasins
de données relationnels (ou ROLAP) peuvent plus facilement migrer vers un entrepôt
de données, les modèles ROLAP stockent en principe des données récapitulatives
dont le niveau de détail est insuffisant pour un entrepôt de données. A moins
que le contenu du magasin de données ROLAP présente le même format que celui de
l’entrepôt de données, il faudra beaucoup investir pour migrer sur un datawarehouse.

Il existe un moyen d’entamer la création d’un magasin de données en songeant à 
un entrepôt de données potentiel : il faut concevoir l’entrepôt d’abord, puis
n’implémenter que les éléments de celui-ci nécessaires à  l’alimentation du datamart.
Il faudra néanmoins concevoir les processsus de réplication et de transformation
appropriés à  ce magasin de données, et consommer ainsi une grande partie des ressources
que l’on espérait épargner en ne créant pas un datawarehouse entièrement opérationnel.
Cependant, on économise beaucoup de temps et d’argent en n’implémentant (et en
n’écrivant, testant et corrigeant) que les processus nécessaires à  chaque magasin
de données au moment de son installation. Cette méthode est séduisante à  plusieurs
égards : ses cycles de développement sont plus courts et les administrateurs peuvent
utiliser le ROI de la première étape pour financer la seconde, et ainsi de suite.