Pourquoi avoir besoin d'un entrepôt de données : définition, architecture et avantages
- Science des données, entreposage des données
- Entreposage de données, datasphere, DWC, DWH
- 8 min de lecture
Marco Ferrari
Qu'est-ce qu'un entrepôt de données (chapitre 1), comment est-il structuré (chapitre 2) et pourquoi ai-je besoin d'un entrepôt de données en tant qu'organisation (chapitre 3) ? L'article de connaissances suivant répond à ces questions.
Table des matières
1. qu'est-ce qu'un entrepôt de données ?
1.1 Définition de l'entrepôt de données
"Un entrepôt de données est un ensemble de données subjectif, intégré, temporel et non volatile, destiné à soutenir les processus de décision, de planification et de contrôle de la direction" (Müller & Lenz, 2013, p. 14).
Le data warehousing peut être considéré comme l'un des éléments les plus importants de la business intelligence. On entend par là l'ensemble du processus qui se déroule dans un entrepôt de données. Les différentes étapes de ce processus sont présentées ci-dessous :
- Le processus commence par la collecte de données, qui se base sur des sources externes et internes à l'entreprise.
- Viennent ensuite la préparation des données et la transformation des données qui s'ensuit.
- Finalement, les données préparées et transformées sont stockées dans l'entrepôt de données – Stockage des données. (Müller et Lenz, 2013, p. 11)
Ces étapes de processus laissent supposer que ce processus ne décrit fondamentalement que la maintenance de la base de données des données collectées. Cette hypothèse est cependant loin d'être vraie : la réalité montre que ce processus vaste est constitué de nombreux processus individuels, qui représentent une charge de travail énorme. Un exemple en est le processus ETL (Extraction, Transformation et Chargement), qui décrit comment les données attribuées aux différents services sont transférées dans l'entrepôt de données et liées entre elles. (Müller et Lenz, 2013, p. 11-12)
Vous trouverez une description précise des caractéristiques d'un entrepôt de données ainsi que du terme "cloud computing" dans cet article wiki.
1.2 D'où vient l'idée de l'entrepôt de données ?
Historiquement, le terme d'entrepôt de données est apparu pour la première fois en 1988. Barry A. Delvin et Paul T. Murphy y décrivent pour la première fois l'utilisation d'un lieu central pour la collecte de données.(Köppen, 2014)
Ils ont décrit dans le "Systems Journal" d'IBM qu'en raison de l'utilisation croissante des systèmes informatiques dans les entreprises, le besoin d'accéder aux données d'entreprise stockées dans les différents systèmes s'est fait sentir. Ce besoin a mis en évidence la nécessité d'une architecture ou d'un système qui rassemble les données d'entreprise collectées à partir des différentes applications informatiques et qui permette d'y accéder de manière uniforme. Delvin et Murphy (1988) ont présenté sur près de 20 pages leur propre système EBIS. Le E correspond aux abréviations des régions Europe (E), Moyen-Orient (ME) et Afrique (A) et les lettres BIS signifient Business Information System. Ce système développé en interne par IBM devait permettre de rassembler pour la première fois les données informatiques des différentes régions et est donc considéré comme le premier exemple de système d'entrepôt de données.(Devlin & Murphy, 1988, p. 60)
2. comment un entrepôt de données est-il structuré ?
Il existe différentes exigences pour un entrepôt de données, qui peuvent varier considérablement en fonction du secteur et de l'entreprise. C'est pourquoi il n'existe pas d'architecture fixe à respecter pour un entrepôt de données. Au fil du temps, les structures des entrepôts de données n'ont donc cessé d'évoluer et différentes variantes de modélisation décrivant l'architecture d'un entrepôt de données ont vu le jour.(Hahne, 2014)
Dans de nombreuses entreprises, les concepts de Data Warehouse ne sont pas nés historiquement sur la base d'un plan proactif visant à la mise en œuvre de la Business Intelligence. Au lieu de cela, ils ont émergé au cours du développement continu des paysages de systèmes informatiques dans les entreprises respectives. Lors de la mise en place d'un Data Warehouse, il y a différents aspects techniques et économiques à prendre en compte. Il est donc avantageux que l'architecture d'un Data Warehouse ait été planifiée et réfléchie dès le départ. Cette approche structurée offre par la suite des avantages, tant lors de l'utilisation que lors du développement du Data Warehouse. (Gluchowski, 2021)
En raison des avantages que présente une architecture structurée pour un entrepôt de données, nous allons d'abord présenter une structure de base d'un entrepôt de données. Ensuite, quelques exemples de différentes variantes d'architecture sont présentés.
La figure 1 représente la structure de base ainsi que les composants nécessaires d'un entrepôt de données. Un entrepôt de données comprend à la fois les données provenant des différentes sources (figure 1, zone 1) et les processus ETL, qui chargent les différentes données dans la 3e zone et l'entrepôt de données central représenté ici (Core Data Warehouse), dans la conception globale d'un entrepôt de données. De même, la conception de base d'un entrepôt de données comprend la mise à disposition des données du Core Data Warehouse pour la création d'analyses de données et de rapports. (Müller et Lenz, 2013)
Les cinq variantes de modélisation les plus connues sont décrites plus en détail ci-dessous :
Marchés de données indépendants - Stove Pipe
Des data marts aux dimensions communes
Marchés de données dépendants - Hub and Spoke
Architectures fédérées
Architecture des couches de l'entrepôt de données
2.1 Marchés de données indépendants - Stove Pipe
Dans la première variante de modélisation de l'architecture d'un entrepôt de données, on parle de marchés de données indépendants. Cela décrit le cas où certains départements d'une entreprise commencent à mettre en place eux-mêmes des solutions de business intelligence. Une telle démarche a pour conséquence que chaque département met en place son propre data mart. Ainsi, du point de vue de l'entreprise, l'entrepôt de données de base se compose de plusieurs data marts départementaux qui sont indépendants les uns des autres. Cette variante de modélisation doit être considérée comme un exemple négatif, car dans ce cas, il n'existe pas de "Single point of truth" dans l'entreprise, qui représenterait la vérité commune des données. Cela est dû au fait que les données sont classées dans des dimensions différentes dans les différents marchés de données et qu'elles sont également marquées différemment. Il en résulte que les données des différents départements ne sont pas comparables entre elles et qu'il faut en outre créer un processus ETL spécifique pour chaque département ou data mart. (Müller et Lenz, 2013, p. 21)
2.2 Marchés de données avec des dimensions communes
Dans une autre variante de modélisation, les data marts sont reliés entre eux par des dimensions communes. Ainsi, les différents data marts ne sont plus indépendants les uns des autres. Cela permet de passer d'un data mart à l'autre et de les relier entre eux par une dimension donnée. Müller et Lenz citent ici l'exemple du lien entre le data mart des ventes et le data mart des ressources humaines. Ces deux cubes sont par exemple reliés entre eux par la structure de la filiale, identique pour les deux cas, et donc par la dimension du lieu. (Müller et Lenz, 2013, p. 21)
2.3 Marchés de données dépendants - Hub and Spoke
La variante de modélisation avec des Data Marts dépendants est souvent appelée architecture Hub and Spoke et, outre l'architecture avec des Data Marts avec des dimensions communes, elle est l'architecture la plus fréquemment utilisée dans la pratique. Dans ce cas, les Data Marts sont alimentés en données par l'ODS selon un schéma prédéfini, valable pour l'ensemble de l'entreprise. Cette approche est à l'opposé des Data Marts indépendants et suit le principe dit Top Down. (Müller et Lenz, 2013, p. 22)
2.4 Architectures fédérées
L'architecture fédérée d'un entrepôt de données est utilisée lorsque les données des systèmes sources sont accessibles directement et ne doivent pas être extraites par un processus ETL. Dans ce cas, on accède virtuellement aux données lors des requêtes afin de les intégrer dans les analyses. Cette approche est utilisée lorsque les données évoluent rapidement ou sont gérées par des tiers. Les principaux composants de l'architecture fédérée sont le wrapper et le médiateur. Le wrapper fournit l'accès aux données dans les systèmes sources et aligne les données entre elles. Le médiateur coordonne les requêtes et relie les résultats.
2.5. architecture des couches de l'entrepôt de données
Outre les structures classiques d'un entrepôt de données, une autre architecture fondamentale pour un entrepôt de données s'est établie. Il s'agit de l'architecture en couches, dans laquelle les différents composants et processus de l'entrepôt de données sont divisés en différentes couches. (Gluchowski, 2021)
Gluchowski indique en outre que, dans la pratique, il n'existe pas de modèle uniforme pour la structure et la désignation des couches. C'est pourquoi nous présentons ci-dessous un exemple d'architecture en couches idéal-typique de Gluchowski.
Comme l'illus tre la figure 2, le point de départ et le point d'arrivée de l'architecture en couches correspondent au point de départ et au point d'arrivée de l'architecture de base d'un entrepôt de données présentée dans la figure 1. Dans les deux architectures, les sources externes sont l'origine et les analyses ainsi que les rapports sont la finalité du processus d'entreposage des données.
3. pourquoi a-t-on besoin d'un entrepôt de données ?
Le data warehousing est une composante essentielle de la business intelligence. Souvent, le terme data warehousing est également utilisé pour désigner le processus qui se cache derrière la business intelligence. La littérature montre que les frontières entre les processus qui se cachent derrière les deux termes ne sont pas clairement définies et se confondent.
Müller et Lenz (2013) définissent le terme d'entrepôt de données comme suit :
"L'entreposage de données désigne le processus commercial qui comprend l'acquisition de données à partir de sources internes et externes accessibles, la transformation et la préparation des données conformément aux schémas de base de données source et cible, l'assurance de la qualité des données et le stockage dans l'entrepôt de données (central) ou dans les data marts (décentralisés) (vues utilisateur) et l'analyse des données basée sur OLAP." (Müller et Lenz, 2013, p. 11)
Müller et Lenz (2013) présentent dans leur livre sur la Business Intelligence que la part de l'entreposage de données représente 25 % du concept global décrit par le terme Business Intelligence. Cette contribution est complétée à 25 % par l'exploration de données et les statistiques, et à 50 % par l'économie d'entreprise et la recherche opérationnelle. (Müller & Lenz, 2013, p. 15)
Par conséquent, la réponse à la question "Pourquoi a-t-on besoin d'un entrepôt de données ?" est qu'un entrepôt de données et le processus d'entreposage de données sont nécessaires à l'exécution de la veille stratégique dans une entreprise. Pour répondre clairement à la question du "pourquoi" dans le sens d'un entrepôt de données, il faut donc d'abord répondre à la question de la motivation pour la Business Intelligence dans une entreprise.
Digression : Business Intelligence
Depuis plus de 60 ans déjà, les entreprises ont constamment recours aux technologies de l'information pour soutenir leur gestion. La plupart du temps, il s'agissait d'aider les cadres à prendre de futures décisions de gestion ou à définir une approche stratégique en utilisant les connaissances et les expériences accumulées sous la forme de chiffres, de données et de faits basés sur l'informatique. Il a toutefois fallu quelques années avant que les premiers systèmes fonctionnels et utilisés avec succès ne soient développés. Au début, ils étaient encore axés sur les tâches. (Kemper, Baars, & Mehanna, 2010, p. 1)
Le terme "Management Support Systems" s'est imposé dans les années 80 pour résumer la diversité des systèmes d'information et de communication existants. Il est encore utilisé aujourd'hui dans le monde scientifique. Cela s'explique par le fait qu'il décrit comment le soutien à la gestion basé sur les TI ne se réfère pas seulement à l'utilisation d'ordinateurs, mais vise également à soutenir la gestion à l'aide des technologies de l'information et de la communication. (Kemper, Baars, & Mehanna, 2010, p. 1)
Le terme " Business Intelligence " décrit en fait le soutien de gestion basé sur l'informatique et est utilisé depuis les années 90 pour décrire les processus et les applications liés à l'informatique. Ce terme est principalement issu des réflexions du Gardner Group, qui s'occupe d'études de marché et d'analyse des évolutions dans le domaine des technologies de l'information. Il convient également de noter que le terme "Business Intelligence" ne peut pas être défini ou décrit de manière univoque. La diversité des définitions de ce terme générique est grande et a notamment pour conséquence que ce terme a permis de discuter en permanence du principe de l'aide à la gestion basée sur les technologies de l'information et de le repenser en permanence. (Kemper, Baars, & Mehanna, 2010, p. 2)
Avec les connaissances acquises sur le fonctionnement d'un entrepôt de données et les raisons pour lesquelles les entreprises décident de mettre en œuvre la Business Intelligence, il est possible de répondre comme suità la question de savoir pourquoi un entrepôt de données est nécessaire :
Il faut d'abord mentionner la motivation fondamentale qui se cache derrière le mot Business Intelligence. L'objectif est de permettre un soutien stratégique de la gestion basé sur l'informatique. Il s'agit d'offrir à la direction une base solide grâce à la mise en relation et à l'analyse des données de l'entreprise, afin de pouvoir prendre des décisions stratégiques sur cette base.
C'est là qu'intervient l'entrepôt de données, car les fonctionnalités d'un entrepôt de données permettent aux entreprises de regrouper toutes les données et de les modéliser de manière à permettre des requêtes complexes ainsi que des analyses à partir des stocks de données.
Bibliographie
Devlin, B. A. & Murphy, P. T. (1988). An architecture for a business and information system. IBM Systems Journal, 60-80. https://www.semanticscholar.org/paper/An-Architecture-for-a-Business-and-Information-Devlin-Murphy/c22ce1eeafb01f0682e194a2a22349aa141b78f6
Gluchowski, P. (2021, 26. Février). Data Warehouse. Enzyklopaedie der Wirtschaftsinformatik.
Hahne, M. (2014). Modélisation de systèmes de business intelligence : Guide pour des projets réussis basés sur des architectures flexibles d'entrepôts de données. Édition TDWI. TDWI Europe. http://site.ebrary.com/lib/alltitles/Doc?id=10904187
Kemper, H.-G., Baars, H., & Mehanna, W. (2010). Business Intelligence - Bases et applications pratiques : Une introduction à l'aide à la gestion basée sur les technologies de l'information (3e édition, revue et augmentée). Étude Informatique de gestion. Vieweg + Teubner.
Köppen, V. (2014). Technologies d'entrepôt de données (2e éd.). mitp Professional. mitp. https://ebookcentral.proquest.com/lib/kxp/detail.action?docID=6166362
Müller, R. M. & Lenz, H.-J. (2013). L'intelligence économique. Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-35560-8
Vous souhaitez approfondir ce sujet ? Dans ce cas, nous nous réjouissons d'un échange personnel sur le Data Warehousing. N'hésitez pas à prendre contact avec nous !
