Chapitre 3
Architecture d'un entrepôt de
données
3.1 Introduction
La mise en place d'un entrepôt de données est un dé de taille. Il existe plusieurs
façons de penser un entrepôt. Le choix de la bonne architecture se base sur la
combinaison de plusieurs critères : les besoins exprimés en termes d'objectifs, des
utilisateurs cibles, du temps alloué pour la mise en place...etc. Nous retrouvons dans
la littérature 5 diérentes architectures. Deux d'entre elles sont les plus utilisées
dans la pratique. Elles correspondent aux visions des deux fondateurs du domaine
décisionnel : Bill Inmon et Ralph Kimball.
Nous présentons dans ce chapitre les diérentes architectures, leurs caractéristiques,
avantages et limites.
3.2 Magasins de données indépendants
Comme dé nit précédemment, un magasin de données peut être vu comme une
sous-partie d'un entrepôt de données répondant à un besoin fonctionnel précis. Dans
une logique de regrouper tous les besoins d'une organisation, ce type d'architecture
propose de regrouper les diérents magasins de données. Ces magasins de données
sont construits de manière indépendante les uns des autres, pouvant utiliser des
sources de données indépendantes. La gure 3.1 illustre l'indépendance de mise en
place de chaque magasin et la possibilité aux diérents utilisateurs d'utiliser les
diérents magasins ensemble.
Datamarts
Sources ETL Restitution Utilisateurs
Indépendants
Source 1 Datamart 1
Source 2 Datamart 2
Silos
de
données
Source 1
Datamart n
Source 3
Figure 3.1: Magasins de données indépendants
13
14 CHAPITRE 3. ARCHITECTURE D'UN ENTREPÔT DE DONNÉES
Avantages et inconvénients
+ Architecture simple et peu coûteuse dans sa mise en place.
+ Fortement orientée sujet.
+ Personnalisation des analyses pour les diérents utilisateurs.
− Certaines données peuvent se retrouver dans diérents magasins, ce qui
implique une répétition de traitements.
− Incohérence et redondances entre les magasins de données.
− Analyse inter-fonctionnelle di cile, voire impossible.
3.3 Architecture en bus de magasins de données
Cette architecture est proposée par R. Kimball. Connue aussi sous le nom
d'approche Bottom-Up, elle propose de construire des magasins de données mais
en utilisant des dimensions conformes. Autrement dit, il s'agit toujours d'une
conception fortement orientée sujet mais pour certaines données, les magasins
utiliseront des dimensions communes. Par exemple, les dimensions temporelle et
géographique. Cela permet de pallier les limites de l'architecture précédente en
éliminant certaines redondances et incohérences au niveau des données.
La gure 3.2 illustre l'architecture. L'ensemble des magasins de données
représentent un entrepôt de données.
Datamarts liés par
Sources ETL dimensions Restitution Utilisateurs
conformes
Source 1
Datamart 1
Source 2
Datamart 2
Datamart n
Source n
Entrepôt de données
Figure 3.2: Architecture en bus de magasins de données
Avantages et inconvénients
+ Architecture incrémentale : Permet de rajouter des magasins au besoin et de
traiter les processus les plus importants en premier.
+ Fortement orientée sujet.
+ Une intégration de données cohérentes grâce aux dimensions conformes.
− Analyse inter-fonctionnelle peu performante impliquant plusieurs magasins.
− Plani cation de nouveaux magasins complexe car il faudra les intégrer à
l'existant.
3.4. ARCHITECTURE HUB-AND-SPOKE 15
3.4 Architecture Hub-and-Spoke
Proposée par B. Inmon, cette architecture est l'opposée de celle en bus d'un point
de vue approche. Appelée aussi approche Top-Down, elle propose de centraliser
toutes les données en construisant en premier lieu tout l'entrepôt de données ( )
et d'alimenter à partir de ce dernier les diérents magasins ( ).
hub
spokes
La gure 3.3 présente l'architecture. L'entrepôt contiendra les données
atomiques, quant aux magasins, ils contiendront des données agrégées. Les analyses
se font directement sur les magasins.
Sources Entrepôt de Datamarts Restitution Utilisateurs
ETL
données dépendants
Source 1 Datamart 1
Source 2 Datamart 2
Entrepôt de données
Source n Datamart n
Hub Spokes
Figure 3.3: Architecture Hub and Spoke
Avantages et inconvénients
+ Intégration et consolidation complète de toutes les données dans un seul
entrepôt.
+ Approche extensible : Il est plus facile de dé nir de nouveaux magasins.
− Analyse inter-fonctionnelle peu performante impliquant plusieurs magasins.
− Temps de mise en place : Construction de tout l'entrepôt avant de créer un
magasin de données.
3.5 Architecture centralisée
Similaire à l'architecture Hub and Spoke, son but est de centraliser toutes les
données dans un seul entrepôt. La diérence réside dans l'inexistence des magasins de
données dans l'architecture centralisée. La gure 3.4 illustre le principe. Les requêtes
analytiques se font directement sur l'entrepôt. Ce dernier contient les données aussi
bien détaillées que résumées.
16 CHAPITRE 3. ARCHITECTURE D'UN ENTREPÔT DE DONNÉES
Sources Entrepôt de Restitution Utilisateurs
ETL
données
Source 1
Source 2
Entrepôt de données
Source n
Figure 3.4: Architecture centralisée
Avantages et inconvénients
+ Les utilisateurs peuvent requêter toutes les données de l'entrepôt.
+ Performance optimale.
− Approche non incrémentale.
− Extensibilité limitée et très coûteuse : Il faudrait repenser toute la conception
de l'entrepôt.
3.6 Architecture fédérée
Cette architecture est utilisée dans le cas où un ou plusieurs entrepôts sont déjà
mis en place, comme dans le cas de fusions de compagnies. Au lieu de reconcevoir un
nouvel entrepôt, l'architecture propose de mettre en place un entrepôt de données
virtuel. Ce dernier représente une vue globale sur les diérents entrepôts existants et
un point d'entrée unique pour les utilisateurs. La gure 3.5 présente l'architecture.
L'intégration de données dans l'entrepôt peut être logique ou physique à l'aide de
métadonnées.
Entrepôts de
Sources ETL Restitution Utilisateurs
données autonomes
Source 1
EDW 1
Source 2
EDW 2
EDW n
Source n
Entrepôt de données virtuel
Figure 3.5: Architecture fédérée
3.7. FACTEURS À CONSIDÉRER POUR LE CHOIX DE L'ARCHITECTURE 17
Avantages et inconvénients
+ Pratique s'il existe au-préalable des entrepôts déjà mis en place.
+ L'intégration virtuelle ne demande que peu de ressources matérielles
additionnelles.
− La gestion de l'intégration est complexe : Il faut prendre en compte la
synchronisation, le parallélisme...
− Performance analytique faible.
3.7 Facteurs à considérer pour le choix de
l'architecture
Comme présenté auparavant, il faut prendre en considération plusieurs critères
pour choisir l'architecture la plus adaptée pour la construction d'un entrepôt de
données. Nous citons dans ce qui suit une liste non exhaustive des paramètres qui
in uencent ce choix :
L'interdépendance informationnelle entre les métiers d'une organisation
(Bonne intégration VS silos de données).
L'urgence d'obtenir une solution fonctionnelle.
Les contraintes sur les ressources ( nancières, mains d'÷uvre...).
Le nombre de sources de données.
La quantité de données (Gigaoctets, Téraoctets, Zettaoctets...).
La fréquence de mise à jour de données (Mise à jour hebdomadaire, temps
réel...).
La nature des tâches des utilisateurs naux (rapports simples, fouille de
données).
Le nombre d'utilisateurs.
Les objectifs du projet (stratégique, opérationnel...).
...
