Concevoir et déployer un data warehouse

Concevoir et déployer un data warehouse Ralph Kimball Éditions Eyrolles ISBN : 2-212-09165-6 2000

2 Le cycle de vie dimensionnel Avant d étudier de plus près les spécificités de la conception, du développement et du déploiement d un data warehouse, nous allons exposer une méthodologie globale tout en présentant le cycle de vie dimensionnel. Celui-ci constitue la trame de cet ouvrage et définit la marche à suivre. Vous y trouverez des matrices contenant les informations qui seront détaillées dans les chapitres suivants. Nous allons débuter par un historique de l évolution du cycle de vie dimensionnel. Nous allons en formaliser les étapes et les schémas. Chaque tâche de haut niveau ou composant du cycle de vie dimensionnel seront décrits. Enfin, nous apporterons les recommandations générales nécessaires à une mise en oeuvre efficace du cycle de vie tout au long d un projet. Nous conseillons au lecteur de prendre le temps de passer en revue ce chapitre d introduction, même s il ne se sent concerné que par un seul aspect du projet de data warehouse. Nous croyons qu il est bénéfique à toute l équipe d appréhender la méthodologie dans son ensemble. Nous avons écrit ce chapitre pour vous aider à prendre du recul. Pour le moment, nous allons nous intéresser à la forêt : les chapitres à venir nous mèneront à l arbre, à la feuille, à l écorce, puis aux racines. Évolution du cycle de vie Le cycle de vie dimensionnel présenté dans cet ouvrage a vu le jour chez Metaphor Computer Systems au milieu des années 80. Cette société appartient maintenant au «folklore» du data warehouse. Fondée en 1982, elle était une entreprise pionnière dans la commercialisation de systèmes décisionnels. À cette époque, les produits de Metaphor étaient basés sur la technologie LAN (Local Area Network, réseau local) avec une plate-forme de serveur de base de données relationnelle et une interface utilisateur client graphique conviviale. Cela vous dit quelque chose, n est-ce pas? Quand Metaphor s est penché sur ce secteur d activités, il portait encore le nom de «systèmes décisionnels» ; la notion de «data warehouse» a fait son apparition bien plus tard.

2 Gestion de projet et évaluation des besoins PREMIÈRE PARTIE Les auteurs de ce livre travaillaient ensemble chez Metaphor au tout début de l implémentation des solutions décisionnelles. À cette époque, il n existait ni pratique industrielle optimale, ni méthodologie officielle. Les auteurs, ainsi que d autres collaborateurs de Metaphor, ont commencé à développer des techniques et des approches destinées à traiter les particularités du décisionnel. Nous avions été formés aux méthodologies de développement traditionnelles ; nous avons cependant modifié et amélioré ces pratiques afin d aborder les défis particuliers que représentaient le fait de mettre à la disposition des utilisateurs un accès direct aux données tout en prenant en compte la croissance et l extensibilité. Au fil des ans, les auteurs se sont trouvés impliqués dans des centaines de projets de data warehouse. Beaucoup ont été couronnés de succès, d autres n ont répondu qu à certaines exigences, et quelques-uns se sont soldés par des échecs retentissants. Chaque projet a été riche d enseignements. De plus, nous avons tous eu la chance, au cours de ces années, de nous instruire au contact d organisations et de personnes talentueuses. Nos approches et nos techniques, formées et affinées au fil du temps, sont aujourd'hui présentées dans cet ouvrage. La réussite de l implémentation d un entrepôt de données dépend de l intégration adéquate de nombreux composants et tâches. Il ne suffit pas de posséder le modèle de données parfait ou la meilleure technologie ; il s agit de coordonner les multiples facettes du projet de data warehouse, tout comme un chef d orchestre doit accorder les nombreux instruments qui composent son orchestre. Un soliste ne peut mener tout un orchestre à lui seul. De la même manière, les efforts fournis pour l implémentation d un entrepôt de données doivent révéler leur efficacité à travers tous les aspects du projet. Le cycle de vie dimensionnel s apparente à la partition d un chef d orchestre ; il fait en sorte que les éléments du projet soient placés dans le bon ordre au bon moment. En dépit des avancées technologiques spectaculaires survenues depuis les débuts de Metaphor dans les années 80, les concepts de base du cycle de vie dimensionnel sont restés remarquablement stables. Notre approche de la conception, du développement et du déploiement des entrepôts de données est éprouvée et fiable. Elle a quasiment été testée dans tous les secteurs d activités et sur toutes les plates-formes technologiques. Le cycle de vie a fait ses preuves. Approche par le cycle de vie L approche globale de l implémentation d entrepôts de données par le cycle de vie est illustrée par la figure 2.1. Ce schéma représente la succession des tâches de haut niveau (macro tâches) nécessaires à la conception, au développement et au déploiement d entrepôts de données efficaces. Il décrit le cheminement du projet dans son ensemble ; chaque rectangle sert de poteau indicateur ou de borne. Planification du projet Comme on peut s y attendre, le cycle de vie commence par la planification du projet. Celle-ci aborde la définition et l étendue du projet de data warehouse, y compris l appréciation du niveau de maturité de l organisation face à cet type d approche et sa justification fonctionnelle. Certaines tâches initiales sont décisives en raison du fort besoin de visibilité et des coûts associés à la plupart des projets de data warehouse. À partir de là, la planification du projet se concentre sur les besoins en terme de ressources et de niveau de qualification, couplés aux affectations des tâches, à leur durée et à leur séquencement. Le planning qui en découle identifie toutes les tâches associées au cycle de vie dimensionnel et mentionne les ressources

Le cycle de vie dimensionnel CHAPITRE 2 3 impliquées. Il représente la pierre angulaire de la gestion de votre projet de data warehouse au quotidien. La planification du projet dépend des besoins, comme l indique la flèche à double sens reliant ces deux activités. Définition de l'architecture technique Installation et sélection des produits Planification du projet Définition des besoins de l'entreprise Modélisation dimensionnelle Conception du modèle physique Conception et développement des éléments de la zone de préparation des données Déploiement Maintenance et croissance Spécification de l'application utilisateur Développement de l'application utilisateur Gestion du projet Figure 2.1 Schéma du cycle de vie dimensionnel. Définition des besoins Les chances de succès d un entrepôt de données se trouvent considérablement accrues par la bonne compréhension des utilisateurs et de leurs besoins. Sans elle, le data warehouse deviendrait rapidement un exercice vain pour l équipe des concepteurs. L approche utilisée pour identifier les besoins analytiques des employés diffère de manière significative de la traditionnelle analyse des besoins pilotée par les données. Les constructeurs d entrepôts de données doivent appréhender les facteurs clés qui conduisent l entreprise à vouloir définir de manière efficace ses besoins et les traduire pour les intégrer lors de la conception. Ces besoins constituent le point de départ des trois trajectoires parallèles que sont la technologie, les données et les interfaces utilisateur. La collecte des besoins est traitée en détail dans le chapitre 4. Modélisation dimensionnelle des données La définition des besoins détermine les données requises pour répondre aux besoins d analyse des utilisateurs. La conception de modèles de données destinés à corroborer ces analyses nécessite une approche différente de celle utilisée lors de la conception de systèmes opérationnels. Nous commencerons par construire une matrice qui représentera les processus métier clés et leur dimensionnalité. La matrice fera office de schéma directeur pour garantir que l entrepôt de données sera extensible dans le temps au sein de l organisation. À partir de là, nous effectuerons une analyse plus détaillée des données des systèmes source opérationnels. En couplant cette analyse à la compréhension des besoins précédemment établie, nous développerons ensuite un modèle dimensionnel. Ce modèle identifie la granularité de la table des faits, les dimensions associées, les attributs ainsi que leur hiérarchisation. La conception logique d une base de données est complétée par les relations appropriées entre

4 Gestion de projet et évaluation des besoins PREMIÈRE PARTIE les structures des tables et les clés principales et extérieures. Le plan d agrégation préliminaire sera également développé. Cet ensemble d activités s achèvera sur le développement d une mise en correspondance des données source et cible. Les concepts relatifs à la modélisation dimensionnelle sont traités dans les chapitres 5 à 7. Le chapitre 5 propose une introduction à la modélisation dimensionnelle et sa justification, tandis que le chapitre 6 couvre les sujets plus avancés relatifs à la modélisation dimensionnelle. Le chapitre 7 décrit l approche recommandée du processus de développement d un modèle dimensionnel. Conception du modèle physique de données La conception physique d une base de données définit les structures physiques nécessaires pour l implémentation de la bases de données logique. Les éléments fondamentaux du processus sont la détermination des «règles de nommage» et la mise en place de l environnement des bases de données. L indexation préliminaire ainsi que les stratégies de partitionnement sont également définies. La conception du modèle physique de données est abordée dans le chapitre 15. Conception et développement de la zone de préparation des données Le processus de conception et de développement des éléments de la zone de préparation des données (data staging) constituent souvent la tâche la plus sous-estimée du projet de data warehouse. Le processus de préparation se déroule en trois étapes majeures : l extraction, la transformation et le chargement des données. Le processus d extraction révèle toujours des problèmes de qualité des données, «enfouies» au sein des systèmes source opérationnels. Or, la qualité des données influence de manière significative la crédibilité de l entrepôt de données ; il convient donc de régler ces problèmes. Pour compliquer encore la chose, il faut concevoir et construire deux processus d extraction : le premier pour le peuplement initial de l entrepôt de données, le second pour les chargements réguliers et incrémentiels. Le développement du processus de préparation des données est décrit en détail au chapitre 16. Définition de l architecture technique Les environnements de data warehouse nécessitent l intégration de nombreuses technologies. Cette étape de définition donne une vision globale de la structure de l architecture technique à mettre en œuvre. Vous devrez prendre simultanément en considération trois facteurs : vos besoins, l environnement technique existant et les orientations techniques stratégiques qui ont été planifiées. Le chapitre 8 propose une introduction à l architecture technique des entrepôts de données. Des réflexions portant sur l architecture des outils de la zone de construction et des outils de restitution sont respectivement exposées dans les chapitres 9 et 10. Le chapitre 11 met en évidence les infrastructures de l architecture et les métadonnées. Enfin, un cours avancé sur la sécurité des entrepôts de données et l impact d Internet vous est proposé au chapitre 12. Choix technologiques et mise en œuvre À partir de votre étude d architecture technique, vous évaluerez et sélectionnerez les composants spécifiques, tels que la plate-forme matérielle, le système de gestion de base de données et les outils de préparation et d accès aux données. Un processus d évaluation standard sera

Le cycle de vie dimensionnel CHAPITRE 2 5 défini, en même temps que les facteurs d évaluation spécifiques à chaque composant de l architecture. Une fois les produits évalués et sélectionnés, ceux-ci devront être installés et testés méticuleusement afin de garantir une intégration adéquate de bout en bout dans l environnement du data warehouse. Le chapitre 13 traite principalement de l architecture, de l évaluation technologique, ainsi que des processus de sélection et d installation qui en découlent. Développement de l application utilisateur Nous vous recommandons de définir une série d applications standard destinée à l utilisateur final, car tous les utilisateurs n ont pas besoin d un accès ad hoc à l entrepôt de données. Les spécifications de l application décrivent les maquettes d états, les critères laissés à l initiative de l utilisateur et les calculs nécessaires. Elles garantissent que l équipe de développement et les utilisateurs ont intégré une compréhension commune des applications qui vont être livrées. Les détails concernant les spécifications utilisateur final sont fournis dans le chapitre 17. Déploiement Le déploiement est le point de convergence de la technologie, des données et des applications utilisateur accessibles à partir du poste de travail. Une planification de grande envergure est indispensable afin que toutes les pièces du puzzle se placent correctement. Il est également nécessaire de prévoir une formation des utilisateurs qui intègre tous les aspects de cette convergence. En outre, avant de permettre à l utilisateur d accéder à l entrepôt de données, il faut mettre en place les processus de communication, de support utilisateur, et de prise en compte des demandes d évolution ou de correction. Le chapitre 18 met l accent sur l importance de bien orchestrer le déploiement (celui-ci devra être reporté si tous les éléments ne sont pas prêts). Maintenance et croissance Après le déploiement initial de l entrepôt de données, il reste encore beaucoup de travail. Il faut continuer à vous occuper de vos utilisateurs en leur procurant un service de support et une formation continue. Vous devez également vous assurer que les processus et les procédures mis en place pour la gestion de la zone de construction vont faire fonctionner l entrepôt en continu et efficacement. Pour bien «vendre» votre entrepôt de données à ses utilisateurs, vous devez songer à mesurer périodiquement son acceptation et ses performances. Enfin, votre plan de maintenance devra inclure une stratégie de communication de grande envergure. Si, jusqu à présent, vous avez utilisé le cycle de vie dimensionnel, votre entrepôt de données va évoluer et croître. À la différence de certaines initiatives traditionnelles de développement, le changement devra être perçu comme un facteur de succès et non d échec. Des processus de hiérarchisation des priorités doivent être mis en place afin de gérer la demande de l utilisateur en termes d évolution et de croissance. Après avoir identifié les priorités du projet, nous revenons au début du cycle de vie, en prenant appui sur ce qui a déjà été mis en place dans l environnement du data warehouse et en nous penchant sur les nouveaux besoins. Le chapitre 19 expose nos recommandations concernant la santé et la croissance à long terme de votre entrepôt de données.

6 Gestion de projet et évaluation des besoins PREMIÈRE PARTIE Gestion du projet La gestion de projet garantit que les activités du cycle de vie dimensionnel restent sur la bonne voie et sont bien synchronisées. Comme le montre la figure 2.1, les activités de gestion de projet sont étalées tout au long du cycle de vie. Elles concernent le contrôle de l état d avancement du projet, la détection et la résolution des problèmes et le contrôle des changements, afin de rester dans la limite des objectifs et du périmètre. Enfin, la gestion de projet inclut le développement d un plan de communication détaillé, qui aborde à la fois les services informatiques et utilisateurs. Une communication suivie est absolument décisive pour gérer les attentes, et une bonne gestion des attentes est elle-même absolument décisive pour que votre entrepôt atteigne ses objectifs. Le chapitre 3 détaille les activités de gestion de projet. Guide d exploitation du cycle de vie dimensionnel Le schéma du cycle de vie dimensionnel matérialise l enchaînement des grandes étapes de l implémentation d un entrepôt de données. Il identifie le séquencement des tâches de haut niveau (macro tâches) et souligne les contraintes entre ces différentes actions tant au niveau technologique ainsi qu au niveau des données et des applications. Par exemple, n essayez pas d achever la conception physique des données et de commencer à construire la zone de préparation des données si vous ne possédez pas à la fois une bonne compréhension des besoins, de l architecture technique globale et des choix techniques spécifiques, et enfin des outils d accès aux données. Par ailleurs, le cycle de vie dimensionnel ne reflète pas un axe chronologique absolu. Comme vous l avez probablement remarqué sur la figure 2.1, tous les rectangles ont la même largeur, sauf celui de la gestion de projet. Même avec une expérience réduite du data warehouse, vous devez savoir que les ressources et le temps nécessaires à chaque rectangle du schéma ne sont pas égaux. Le lecteur ne doit surtout pas poser une règle au bas du schéma et diviser les tâches selon un axe chronologique imaginaire gradué en mois. Il doit savoir combiner le séquencement et la simultanéité plutôt que fixer des échéances en valeur absolue. Comme pour la plupart des outils de méthodologie et de gestion de projet, vous devrez peutêtre personnaliser le cycle de vie dimensionnel en fonction des besoins particuliers de votre organisation. Si c est le cas, nous saluons votre adoption de la méthode et votre créativité. Cette tâche est le plus souvent confiée à des consultants, tels que nous-mêmes. À travers cet ouvrage, nous tentons de recenser ce à quoi vous devez réfléchir lors de la conception, du développement et du déploiement d un entrepôt de données. Ne vous laissez pas déborder par le volume des informations. Certains détails ne sont pas applicables au cycle de vie de votre projet. Nous sommes conscients que chaque développement d un système impose des compromis. Néanmoins, nous savons par expérience que les projets réussis devront aborder toutes les tâches : il s agit juste de déterminer quand et comment. Enfin, comme nous le décrirons dans le chapitre 3, le cycle de vie dimensionnel est plus fructueux lorsqu il est utilisé pour implémenter des projets dont les objectifs sont maîtrisés et clairement définis. Il est quasiment impossible de tout régler en une seule fois ; ne laissez donc pas les utilisateurs, vos collaborateurs ou vos supérieurs tenter d infléchir cette approche. Par ailleurs, il est tout à fait envisageable de construire, de développer et de déployer un environnement de data warehouse par des phases successives en exploitant le cycle de vie dimensionnel.

Le cycle de vie dimensionnel CHAPITRE 2 7 Points de repère du cycle de vie dimensionnel : comment utiliser cet ouvrage En résumé Vous trouverez des références au cycle de vie dimensionnel tout au long de cet ouvrage. Pour commencer, chaque page portant un titre de chapitre reprend le schéma du cycle de vie (voir figure 2.1). Il vous fournit un point de repère vous permettant de vous situer dans le cycle de vie. Sachez qu il n existe pas de relation directe entre ces points de repère et les chapitres du livre. Dans certains cas, un seul chapitre abordera de nombreux points de repère, comme le chapitre 3, qui couvre à la fois la planification et la gestion de projet. D autres chapitres ne couvrent qu un seul point de repère, comme les chapitres 5 à 7, qui traitent de la modélisation dimensionnelle. En plus de ces points de repère, les chapitres orientés sur les processus comprendront, le cas échéant, les éléments communs suivants : La liste détaillée des tâches du projet et des responsabilités associées au point de repère. Ces listes sont regroupées dans l annexe pour former un plan complet et intégré. Les rôles clés de l équipe du projet. Des estimations. Chaque projet est tellement spécifique qu il est pratiquement impossible de proposer une estimation de délai pour chaque point de repère. Nous avons donc préféré vous livrer une liste de variables et de relations dont vous pourrez tenir compte pour attribuer une échéance à chaque point de repère de votre projet. Le cycle de vie dimensionnel propose un cadre permettant d organiser les nombreuses tâches nécessaires à l implémentation réussie d un data warehouse. Grâce à des années d expériences pratiques, nous l avons fait évoluer. Il est fortement ancré dans la réalité d aujourd hui. Maintenant que vous avez fait la connaissance du cycle de vie dimensionnel, nous pouvons commencer!