Un "entrepôt de données d'entreprise" (EDW pour Enterprise Data Warehouse) est le nom d'une approche de conception. L'architecture EDW diffère sensiblement de celle du bus décisionnel. L'EDW incarne un certain nombre de thèmes connexes qui doivent être mis en comparaison avec l'approche du bus décisionnel. Il peut être utile de séparer les questions logiques des questions physiques pour le moment.
Logiquement, les deux approches préconisent un ensemble cohérent de définitions qui rationalisent les différentes sources de données dispersées dans l'organisation. Dans le cas du bus, les définitions importantes concernent principalement les dimensions conformes et les faits conformes. Avec l'approche EDW, la cohérence semble beaucoup plus amorphe. Cela repose sur le fait que si vous avez un modèle Entité/Relation hautement normalisé unique de toutes les informations de l'entreprise, vous savez alors comment administrer des centaines ou des milliers de tables de manière cohérente. Mais, dépassant ce manque de précision, on pourrait soutenir que les deux approches sont du même avis jusqu'ici. Les deux approches visent à appliquer des règles cohérences pour unifier toutes les sources de données distribuées.
Un problème du modèle de données EDW est que, souvent, ces modèles sont des modèles d'information idéalisés plutôt que de vrais modèles de sources de données. Bien que l'exercice de la création du modèle d'information idéalisé soit utile, j'ai vu un certain nombre de ces grands schémas jamais utilisé. J'ai également écrit un certain nombre d'articles tentant de mettre en lumière la demande liée à ces grands modèles normalisés: encapsuler les "règles métier" de l'organisation. Au mieux, les modèles normalisés appliquent certaines règles de données (principalement des relations 1-à-plusieurs), mais presque rien de ce qu'un expert fonctionnel appellerait des règles métiers. Les explications du chemin qui mène au schéma Entité/Relation est rarement, voire jamais, donnée dans le code des processus ETL ou dans la requête et les outils de reporting.
Même si nous sommes à peu près d'accord pour dire que les deux approches ont le même objectif, qui est de créer une représentation cohérente des données d'une entreprise, dès que vous vous déplacez dans la conception physique et les problèmes de déploiement, les différences entre l'EDW et le bus décisionnel deviennent vraiment flagrantes.
Comme la plupart d'entre vous le savent, les dimensions conformes et les faits conformes prennent des formes spécifiques dans l'architecture du bus décisionnel. Les dimensions conformes sont des dimensions qui ont des champs communs et dont les domaines de valeurs dans ces champs sont les mêmes. Cela permet d'effectuer des requêtes sur les tables de faits connectées à ces dimensions et de fusionner les colonnes dans un résultat final. J'ai beaucoup écrit sur les étapes requises pour gérer des dimensions conformes et des faits conformes dans un environnement d'entrepôt de données distribué. Je n'ai jamais vu une littérature comparable pour décrire les lignes directrices de l'approche EDW. Je trouve cela intéressant parce que même dans un EDW physiquement centralisé, vous devez stocker les données dans des espaces de tables physiquement distincts, et qui nécessite de suivre la même logique de réplication que celle des dimensions conformes. Mais je n'ai jamais vu de de procédures descriptives, rédigées par les défenseurs de l'EDW, pour le faire. Quelles tables répliquez-vous entre les espaces de table et quand? Les procédures du bus décisionnel décrivent cela dans les moindres détails.
La deuxième forme normale naturelle des dimensions dans la conception du bus décisionnel nous permet de gérer l'évolution naturelle d'une dimension de manière prévisible (dimension à évolution lente de type 1, 2 et 3).
Encore une fois, dans le monde hautement normalisé de l'EDW, je n'ai jamais vu une description équivalente aux dimensions à évolution lente. Mais il semblerait qu'elle utilise de manière abondante l'horodatage sur l'ensemble des entités, ainsi qu'un travail d'administration plus important que dans l'approche dimensionnelle. Par ailleurs, l'approche des clés de substitution que j'ai décrit pour l'administration des dimensions à évolution lente n'a en fait rien à voir avec la modélisation dimensionnelle. Dans un EDW, la table de base d'une "dimension" en flocon aurait à subir exactement le même gestion des clés (en utilisant une clé de substitution ou une clé naturelle et une date) avec le même nombre d'enregistrements, si elle suit la même évolution au cours du temps que la version de bus décisionnel.
La deuxième forme normale naturelle des dimensions dans la conception de bus décisionnel nous permet une approche systématique pour définir des agrégats, le moyen le plus puissant et efficace d'augmenter les performances d'un entrepôt de données volumineux. Les techniques d'agrégations dimensionnelles sont intimement liées à l'utilisation de dimensions conformes. Les dimensions "réduites" d'une table de fait agrégée sont parfaitement conformes aux sous-ensembles des dimensions de base de l'architecture de bus décisionnel. L'approche EDW, encore une fois, n'a pas d'approche systématique et documentée pour maintenir des agrégats dans l'environnement normalisé, ou ne donne aucun conseil aux utilisateurs d'outils de requêtage et de reporting sur la façon d'utiliser des agrégats.
L'architecture EDW est à la fois physiquement et logiquement centralisée. Peut-être que c'est injuste, mais je pense que cette approche a le même problème que l'économie planifiée. Cela sonne bien, et les arguments idéalistes sont difficiles à réfuter avant le début du projet. Mais le problème est qu'une approche entièrement centralisée suppose une information parfaite "a priori" et ensuite une meilleure prise de décision. L'architecture de bus décisionnel encourage une conception en constante évolution avec des critères spécifiques pour "modifier élégamment" des schémas de données pour que les applications existantes continuent à fonctionner. La symétrie de la démarche de conception dimensionnelle du bus décisionnel nous permet de déterminer exactement où les données, nouvelles ou modifiées, peuvent être ajoutés dans une modélisation pour préserver ce caractère élégant.
Plus important encore, une hypothèse importante présent dans la plupart des architectures EDW est que l'EDW centralisé "fourni" des data marts. Ces magasins de données sont souvent décrits comme "construit pour répondre à une question métier spécifique". Presque toujours cela vient d'agrégations prématurées et inopportunes. Si le data mart ne contient que des données agrégées, alors bien sûr il y aura une série de questions qui ne pourront pas être résolues. Généralement, ces questions ne se basent pas sur un enregistrement atomique unique, mais plutôt sur de grandes quantités de données. Une dernière hypothèse irréaliste de l'EDW est que si l'utilisateur veut poser l'une de ces questions précises, il doit quitter le data mart agrégé et descendre dans les données atomiques de troisième forme normale situées dans l'entrepôt. Tout est faux avec ce point de vue, à mon avis. L'effet de levier que nous avons développé dans le bus décisionnel bat cette architecture hybride: le forage à travers des dimensions conformes jusqu'aux données atomiques; le codage uniforme des dimensions à évolution lente, l'utilisation d'agrégats pour améliorer la performance, et le caractère sacré de la conservation des données de l'entrepôt.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #34: You don't need an EDW", publié le 28 février 2002.
Aucun commentaire:
Enregistrer un commentaire