Deploiement DWH

Dans cet article, je présente les deux scénarii de déploiement d'une solution décisionnelle. Bien entendu ces scénarii n'engagent que moi.

Axiomes :

- « On n’achète pas un DataWareHouse, on le construit » : Bill Inmon. 

- Un DataWareHouse, un vrai, se justifie par la satisfaction d’un besoin horizontal.

I- Scénario 1 : DataWareHouse « Global »

Ici le DataWareHouse (rigoureusement la zone de données principales) contiendra potentiellement tous les lots (« verticaux » et « horizontaux ») 

I-1       Avantages

-          Centralisation des données

-          Possibilité de brancher un programme de DataMining (le volume et la centralisation des données peuvent justifier ce branchement) afin de détecter des corrélations cachées entre les données 

I-2       Limites et contraintes 

- Le DataWareHouse peut rapidement devenir inconsistant. En effet, il ne suffit pas d’aligner des lots « verticaux » les uns à côtés des autres pour obtenir un lot « horizontal » cohérent;

- Risque de collision entre les objets « horizontaux » et « verticaux » si la frontière n’est pas clairement définie;

- Difficultés liée à la maintenance et à l’administration. En effet étant donné que plusieurs domaines fonctionnels et que les deux visions « verticale » et « horizontale » cohabitent, une maintenance et une administration efficaces nécessiterons une bonne compréhension de plusieurs domaines fonctionnels et de plusieurs visions. Ce qui énorme en terme de charge; 

- Besoin important en ressources machines (disques, RAM , CPU, …). En effet dans un DataWareHouse « global », le volume de données est de l’ordre du téra octet ----à Nécessité de mettre en place de véritables architectures de bases de données dédiées décisionnelle (Teradata , Netezza, …)

I-3       Remarques :

Ce déploiement peut convenir :

-          Aux organisations qui n’ont pas beaucoup d’applications verticales  

-          Aux organisations qui ont un ERP qui couvre l’essentiel des domaines fonctionnels

-        Aux organisations dont les besoins en indicateurs et métriques ne font pas intervenir plusieurs domaines fonctionnels

II- Scénario 2 : DataWareHouse « Horizontal » et DataMarts « verticaux »   

Ici le DataWareHouse (rigoureusement la zone de données principales) contiendra uniquement des lots susceptibles d’intervenir dans la satisfaction d’une problématique ou d’un besoin « horizontal ». Les besoins « verticaux » étant alors comblés par des DataMarts dédiées 

II-1     Avantages

-          Architecture distribuée

-          Possibilités de brancher un programme de DataMining (le volume et la centralisation des données peuvent justifier ce branchement) afin de détecter des corrélations cachées entre les données

II-2     Limites et contraintes  

- Suivi de la cohérence

- Possibilité d’organiser les données décisionnelles par groupe fonctionnel (peut aussi être vu comme un avantage).

- Nécessité de mettre en place une véritable architecture de bases de données dédiées décisionnelle (Teradata , Netezza, …) en cas de grosse volumétrie

II-3     Remarques :

Ce déploiement peut convenir :

-          Aux organisations qui ont beaucoup d’applications verticales

-          Aux organisations qui n’ont pas un ERP qui couvre l’essentiel des domaines fonctionnels

Tout ou Partie de cet article ne peut reproduit sans autorisation écrite de M. Benjamin EPEE