Le projet Data Warehouse, un processus continu. Les 4 étapes

Une démarche singulière

Un processus continu

La toute première génération de Data warehouse a été marquée par une succession d'échecs. Les concepteurs appliquaient le "postulat du technicien" :
" Si je mets le maximum de données, les utilisateurs trouveront leur bonheur." Bien entendu, avec une hypothèse erronée dès l'énoncé du principe fondateur, on ne peut que bâtir des usines à gaz. En fait, le projet Data Warehouse est un processus. Il sera toujours en perpétuelle évolution, que ce soit sur le plan du nombre d'utilisateurs que celui des thématiques traitées.

Une succession de projet plus "légers"

Il est important de considérer le projet Data Warehouse, non pas comme unique, mais plutôt comme une succession de projets plus légers, focalisés sur les besoins métiers, répondant chacun à une nécessité clairement identifiée et définie. Chacun des projets s'intégrant avec le précédent et ouvrant des pistes pour les suivants. Un peu comme un puzzle sans fin.
C'est la solution pour suivre de près les attentes des utilisateurs et maîtriser le ROI du projet.

Le projet DW

Les 4 temps du projet

1) Identifier le besoin auprès des utilisateurs
Le data warehouse est le pivot du système décisionnel. Les données stockées seront transformées en informations et exploitées par les utilisateurs-décideurs. Il semble donc primordial de placer les besoins des utilisateurs au centre de la problématique.
C'est vrai quel que soit le projet d'informatisation. Mais dans le cas du projet Data warehouse, cette omission ne pardonne pas.
Ainsi, chacune des phases du projet sera définie sous l'éclairage des nécessités utilisateurs, des besoins métiers. On accordera un soin particulier à la délicate phase de collecte et notamment aux opérations de nettoyage, de formatage et de consolidation. Ne perdons pas de vue qu'une donnée n'a pas de valeur en soi. C'est bien l'utilisateur-décideur qui transformera les données en informations.
Voir aussi les données de référence.
2) Modéliser les données
Adoptez un modèle spécifique orienté utilisateur et métier dans une logique décisionnelle et non un modèle qui privilégie le confort technique de l'analyste Base de données dans une logique de production. C'est une différence majeure de conception. Les modèles de structure des données normalisés ne sont pas adaptés aux besoins décisionnelles qui sollicitent de nombreux rapprochement de données. Ls modèles étoiles et flocons, les plus courants sont plus adéquats, et ce n'est pas peu dire, pour des analyses complexes. La modélisation est une tâche particulièrement complexe qui ne s'improvise pas, c'est un métier à part entière.
Pour aller plus avant : Modéliser les données
3) Choisir l'architecture technique
Les requêtes décisionnelles un peu complexes sollicitent énormément l'architecture de traitement. Autant prendre le temps de bien la choisir en tenant compte des besoins actuels et de leurs évolutions dans un horizon de temps raisonnable. Les architectures technologiques représentent un investissement conséquent qu'il s'agit de rentabiliser dans la durée.
Pour aller plus avant :Choisir l'architecture technique
4) Implanter et déployer
Élaboration des schémas d'accès aux données et des règles de nettoyage et de consolidation. Voir aussi Data Warehouse et DataMart.

Partagez cet article...

Envoyer le lien de cet article par e-mail

(total partages cumulés > 165)

Commentaires lecteurs...

Pour commenter en tant qu'Anonyme, cliquez sur "Commencez la discussion" Puis sur "Nom", tout en bas apparaît alors une case à cocher : "Je préfère publier en tant qu'invité"

La reproduction ou la traduction totale ou partielle de ce texte, images et documents est formellement interdite. Voir ici les conditions pour publier un extrait sur votre site ou blog. Ce texte et les images et documents qu'il contient est déposé auprès de l'IDDN

Suivez aussi les news du portail sur Twitter et rejoignez-nous sur Facebook