Architecture Inmon Contre Architecture Kimball-Revisitée

Architecture Inmon Contre Architecture Kimball-Revisitée

Introduction
Nous vivons à l’ère d’une révolution des données, et de plus en plus d’entreprises se rendent compte que pour diriger—ou dans certains cas, pour survivre—elles doivent exploiter efficacement la richesse de leurs données. L’entrepôt de données, en raison de sa proposition unique en tant que référentiel intégré de données d’entreprise, joue un rôle encore plus important dans cette situation. Il existe deux styles d’architecture importants pratiqués aujourd’hui pour construire un entrepôt de données: l’architecture Inmon et l’architecture Kimball.

Cet article tente de comparer et de contraster les avantages et les inconvénients de chaque style d’architecture et de recommander le style à poursuivre en fonction de certains facteurs.

[Note de l’éditeur: De temps en temps, TDAN.com republie le contenu qui était et reste populaire dans la publication. Cette fonctionnalité de Sakthi Rangarajan est l’un des contenus les plus lus de tous les temps sur TDAN.com.]

Fond
En termes d’architecture de l’entrepôt de données, il existe deux écoles de pensée distinctes: la méthode Inmon et la méthode Kimball. Ils considèrent tous les deux l’entrepôt de données comme le référentiel de données central de l’entreprise, répondent principalement aux besoins de reporting de l’entreprise et utilisent tous les deux ETL pour charger l’entrepôt de données. La principale distinction est la manière dont les structures de données sont modélisées, chargées et stockées dans l’entrepôt de données. Cette différence d’architecture a un impact sur le délai de livraison initial de l’entrepôt de données et sur la capacité à s’adapter aux modifications futures de la conception ETL. Lorsqu’on demande à un architecte de données de concevoir et de mettre en œuvre un entrepôt de données à partir de zéro, quel style d’architecture doit-il choisir pour construire l’entrepôt de données? Quels critères peuvent aider un architecte à choisir entre l’architecture Inmon ou l’architecture Kimball?

L’Approche Inmon
L’approche d’Inmon pour la création d’un entrepôt de données commence par le modèle de données d’entreprise. Ce modèle identifie les domaines clés et, plus important encore, les entités clés avec lesquelles l’entreprise opère et dont elle se soucie, comme le client, le produit, le fournisseur, etc. À partir de ce modèle, un modèle logique détaillé est créé pour chaque entité majeure. Par exemple, un modèle logique sera construit pour le client avec tous les détails liés à cette entité. Il pourrait y avoir dix entités différentes sous Client. Tous les détails, y compris les clés métier, les attributs, les dépendances, la participation et les relations, seront capturés dans le modèle logique détaillé. Le point clé ici est que la structure d’entité est construite sous une forme normalisée. La redondance des données est évitée autant que possible. Cela conduit à une identification claire des concepts commerciaux et évite les anomalies de mise à jour des données. L’étape suivante consiste à construire le modèle physique. L’implémentation physique de l’entrepôt de données est également normalisée. C’est ce qu’Inmon appelle un « entrepôt de données », et c’est là que la version unique de la vérité pour l’entreprise est gérée. Ce modèle normalisé rend le chargement des données moins complexe, mais l’utilisation de cette structure pour l’interrogation est difficile car elle implique de nombreuses tables et jointures. Ainsi, Inmon suggère de créer des magasins de données spécifiques aux départements. Les data marts seront conçus spécifiquement pour la Finance, les ventes, etc., et les data marts peuvent avoir des données dénormalisées pour aider à la création de rapports (Breslin, 2004). Toutes les données qui entrent dans l’entrepôt de données sont intégrées et l’entrepôt de données est la seule source de données pour les différents magasins de données. Cela garantit que l’intégrité et la cohérence des données restent intactes dans toute l’organisation. La figure 1.2 montre l’architecture typique d’un entrepôt de données Inmon.

Les principaux avantages de l’approche Inmon sont les suivants:

L’entrepôt de données sert vraiment de source unique de vérité pour l’entreprise, car c’est la seule source pour les magasins de données et toutes les données de l’entrepôt de données sont intégrées.
Les anomalies de mise à jour des données sont évitées en raison de la très faible redondance. Cela rend le processus ETL plus facile et moins sujet aux pannes.
Les processus métier peuvent être facilement compris, car le modèle logique représente les entités métier détaillées.
Très flexible-À mesure que les exigences de l’entreprise changent ou que les données sources changent, il est facile de mettre à jour l’entrepôt de données car une seule chose se trouve au même endroit.
Peut gérer des besoins de reporting variés dans toute l’entreprise.
Voici quelques-uns des inconvénients de la méthode Inmon:

Le modèle et l’implémentation peuvent devenir complexes avec le temps car ils impliquent plus de tables et de jointures.
Besoin de ressources expertes en modélisation de données et de l’entreprise elle-même. Ce type de ressources peut être difficile à trouver et est souvent coûteux.
La configuration initiale et la livraison prendront plus de temps, et la direction doit en être consciente.
Plus de travail ETL est nécessaire car les data marts sont construits à partir de l’entrepôt de données.
Une équipe assez importante de spécialistes doit être présente pour gérer avec succès l’environnement (Breslin, 2004).
L’Approche Kimball
L’approche de Kimball pour la construction de l’entrepôt de données commence par l’identification des processus métier clés et des questions commerciales clés auxquelles l’entrepôt de données doit répondre. Les sources clés (systèmes opérationnels) de données pour l’entrepôt de données sont analysées et documentées. Le logiciel ETL est utilisé pour importer les données de toutes les différentes sources et les charger dans une zone de transfert. À partir de là, les données sont chargées dans un modèle dimensionnel. Voici la principale différence: le modèle proposé par Kimball pour l’entreposage de données – le modèle dimensionnel-n’est pas normalisé. Le concept fondamental de la modélisation dimensionnelle est le schéma en étoile. Dans le schéma en étoile, il existe généralement une table de faits entourée de nombreuses dimensions. Le tableau des faits contient toutes les mesures pertinentes pour le sujet, ainsi que les clés étrangères des différentes dimensions qui entourent le fait. Les dimensions sont complètement dénormalisées afin que l’utilisateur puisse percer et percer sans se joindre à une autre table. Plusieurs schémas en étoile seront construits pour satisfaire différentes exigences de rapport. Alors, comment l’intégration est-elle réalisée dans le modèle dimensionnel? Kimball propose ici le concept de « dimensions conformes ». Les dimensions clés, comme le client et le produit, qui sont partagées entre les différents faits seront construites une fois et utilisées par tous les faits (Kimball et al. 2013). Cela garantit qu’une chose ou un concept est utilisé de la même manière à travers les faits. Un autre artefact clé du modèle Kimball est la « matrice de bus d’entreprise ». C’est le document où les différents faits sont listés verticalement et les dimensions conformes sont listées horizontalement. Partout où les dimensions jouent un rôle clé étranger dans le fait, il est marqué dans le document. Cela sert de document d’ancrage montrant comment les schémas en étoile sont construits et ce qui reste à construire dans l’entrepôt de données. La figure 1.3 montre une architecture d’entrepôt de données Kimball typique.

Figure 2
Cliquez pour agrandir.
Voici quelques-uns des avantages de la méthode Kimball:

Rapide à mettre en place et à construire, et la première phase du projet d’entreposage de données sera livrée rapidement.
Le schéma en étoile peut être facilement compris par les utilisateurs professionnels et est facile à utiliser pour les rapports. La plupart des outils de BI fonctionnent bien avec le schéma en étoile.
L’empreinte de l’environnement d’entreposage de données est petite;il occupe moins d’espace dans la base de données et facilite la gestion du système.
Les performances du modèle de schéma en étoile sont très bonnes. Le moteur de base de données effectuera une « jointure en étoile » où un produit cartésien sera créé en utilisant toutes les valeurs de dimension et la table de faits sera finalement interrogée pour les lignes sélectives. Ceci est connu pour être une opération de base de données très efficace.
Une petite équipe de développeurs et d’architectes suffit pour que l’entrepôt de données fonctionne efficacement (Breslin, 2004).
Fonctionne très bien pour les métriques par département et le suivi des KPI, car les data marts sont orientés vers les rapports par département ou par processus métier.
Le forage transversal, dans lequel un outil de BI parcourt plusieurs schémas en étoile pour générer un rapport, peut être accompli avec succès à l’aide de dimensions conformes.
Voici quelques-uns des inconvénients de la méthode Kimball:

L’essence de la « source unique de vérité » est perdue, car les données ne sont pas entièrement intégrées avant de répondre aux besoins de reporting.
Les données redondantes peuvent entraîner des anomalies de mise à jour des données au fil du temps.
L’ajout de colonnes à la table de faits peut entraîner des problèmes de performances. C’est parce que les tables de faits sont conçues pour être très profondes. Si de nouvelles colonnes doivent être ajoutées, la taille de la table de faits devient beaucoup plus grande et ne fonctionnera pas bien. Cela rend le modèle dimensionnel difficile à modifier à mesure que les exigences de l’entreprise changent.
Ne peut pas gérer tous les besoins de reporting d’entreprise car le modèle est orienté vers les processus métier plutôt que vers l’entreprise dans son ensemble.
L’intégration des données héritées dans l’entrepôt de données peut être un processus complexe.
Facteurs Déterminants
Maintenant que nous avons vu les avantages et les inconvénients des approches Kimball et Inmon, une question se pose. Quelle approche devrait être utilisée quand? Les architectes d’entrepôts de données sont confrontés à cette question chaque fois qu’ils commencent à construire un entrepôt de données. Voici les facteurs décisifs qui peuvent aider un architecte à choisir entre les deux:

Exigences en matière de rapports – Si les exigences en matière de rapports sont stratégiques et à l’échelle de l’entreprise et qu’un rapport intégré est nécessaire, alors Inmon fonctionne le mieux. Si les exigences en matière de rapports sont tactiques et axées sur les processus métier/l’équipe, alors Kimball fonctionne le mieux.
Urgence du projet-Si l’organisation a suffisamment de temps pour attendre la première livraison de l’entrepôt de données (disons 4 à 9 mois), l’approche Inmon peut être suivie. S’il y a très peu de temps pour que l’entrepôt de données soit opérationnel (disons 2 à 3 mois), l’approche de Kimball est la meilleure (Breslin, 2004).
Plan de dotation futur-Si l’entreprise peut se permettre d’avoir une équipe de spécialistes de grande taille pour maintenir l’entrepôt de données, la méthode Inmon peut être poursuivie. Si le plan futur de l’équipe est d’être mince, alors Kimball est plus adapté.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.