Entrepôt de données

Troisième partie
Entrepôt de données
23

Chapitre 8
Architecture d’un entrepôt de données
8.1 Systèmes décisionnels
8.1.1 Comparaison avec un système transactionnel
Un système transactionnel est une base de données tournée vers la saisie, le stockage, la mise à jours et
l’intégrité des données. Ces systèmes permettent de gérer les transactions quotidiennes d’une ou de plusieurs
applications particulières (réservation, commande, gestion de stock, ...). Les données sont détaillée, et la
notion d’archivage est quasiment absente. L’activité est caractérisée par un nombre important de requêtes
simples d’interrogation et de modification. On parle de base OLTP (On-Line Transaction Processing).
Un système décisionnel permet d’agréger des données internes ou externes et de les transformer en
information apportant une aide à la décision. Un système décisionnel n’est mis à jour qu’à un moment choisi
lors de l’import de donnée. Son activité principal est de répondre à des interrogations complexes et ouvertes.
C’est l’utilisateur qui doit pouvoir formuler simplement ses questions en fonction de ses besoin. La prévision
des interrogations est imprévisible car elle dépend de l’utilisateur et des réponses aux autres interrogations.
Par exemple, si un produit s’est peu vendu une année par rapport à la précédente, le responsable
marketing va vouloir comprendre pourquoi en effectuant des analyses suivants plusieurs axes : Ventes par
région, par magasin, par mois, par profil de client, ... Il faut donc que le système décisionnel lui permette
d’explorer toutes mes données suivant les recherches qu’il a à mener, afin d’apporter une aide à la décision
(par exemple faire une promotion ciblée pour les clients d’un certain age, d’une certaine région, ...).
On parle dans ce car de base OLAP (On-Line Analytical Processing). Le support d’une activité OLAP
nécessite la construction d’un Datawarehouse.
8.1.2 Datawarehouse
Définition
Un datawarehouse est une collection de données orientées sujets, intégrées, non volatiles et historisées,
organisées pour le support du processus d’aide à la décision. ( Bill Inmon, 1994).
Il s’agit donc d’une base de données alimentée par les systèmes de production (souvent des bases OLTP),
après nettoyage et uniformisation de leur données. La figure 8.1 montre les différents aspect du dataware-
house.
Caractéristiques des données décisionnelles
Orientées sujet Les données sont organisées autours des sujets majeurs de l’entreprise, elles présentent
une vue synthétique des informations pertinentes pour les décideurs, dans la perspective d’une aide à la
décision et non de la gestion quotidienne de opérations.
Intégrées Elles sont construites en intégrant plusieurs sources de données hétérogènes (fichiers, base de
données relationnelles, ...) issues de l’entreprise ou de sources externes. L’uniformisation de ces données est
une part importante dans la construction du datawarehouse.
Historisées Un référentiel temps est systématiquement mis en place pour les données. La mise à jours
des données n’existe pas, mais il y aura un stockage de l’historique des valeurs des données.
24

CHAPITRE 8. ARCHITECTURE D’UN ENTREPÔT DE DONNÉES
Figure 8.1 – Architecture d’un datawarehouse
Non Volatiles En conséquence de l’historisation des données, une requête effectuée à deux instants dif-
férents mais portant sur la même période devra toujours donner le même résultat.
8.2 Datamart
8.2.1 Définition
Le DataMart est issu d’un flux de données provenant du DataWarehouse. Contrairement à ce dernier
qui présente le détail des données pour toute l’entreprise, il a vocation à présenter la donnée de manière
spécialisée, agrégée et regroupée fonctionnellement. (Bill Inmon)
Le DataMart est un sous-ensemble du DataWarehouse, constitué de tables au niveau détail et à des
niveaux plus agrégés, permettant de restituer tout le spectre d’une activité métier. L’ensemble des DataMarts
de l’entreprise constitue le DataWarehouse. (Ralph Kimball)
8.2.2 Caractéristiques
Un datamart est orienté vers un sujet unique, et contient des données fortement agrégées pour lesquelles le
datawarehouse joue le rôle d’historique. Il est organisé de façon multidimensionnel dont une est généralement
le temps.
25

Chapitre 9
Conception d’un entrepôt de données
Un entrepôt de données ne s’achète pas, il se construit. (Bill Inmon)
9.1 Modélisation
9.1.1 Représentation multidimensionnelle
Un datawarehouse est basé sur une modélisation multidimensionnelle qui représente les données dans un
cube à plusieurs dimensions.
Dimension Une dimension est un attribut ou un ensemble d’attribut (temps, localisation, produit, client,
...).
Granularité Une dimension possède une granularité qui correspond au niveau de détail de la dimension.
Par exemple :
Dimension Temps Années/Trimestre/Mois/Jours
Dimension Géographique Pays/Région/Province/Ville
Fait Les cellules du cube contiennent des valeurs agrégées appelées faits (chiffre d’affaire, Coût, nombre
d’unité, ...)
Figure 9.1 – Représentation Multidimensionnelle des données
9.1.2 Phases de réalisations
La construction d’un Datawarehouse doit suivre trois étapes dépendantes les une des autres.
L’étude préalable
doit permettre
— de définir les objectifs et le contenu du datawarehouse en fonction des besoins des décideurs
26

CHAPITRE 9. CONCEPTION D’UN ENTREPÔT DE DONNÉES
— d’établir la liste des données nécessaire pour alimenter le datawarehouse :
Dans les bases de production
Dans des sources externes à identifier
Cette étude préalable permettra d’établir la liste des dimensions (et de leur granularité) ainsi que les faits
qui devront être exposé dans le datawarehouse.
Modélisation conceptuelle
La modélisation d’un datawarehouse est basé sur une modélisation conceptuelle permettant de représen-
ter les cubes. On distinguera dans le modèle obtenu deux types de tables :
Tables de dimensions Chaque dimension répertoriée lors de l’étude préalable produit une table appelée
table de dimension dans le modèle conceptuel
Table de Fait A chaque cube est associé une table de faits qui contient les mesures, et les clés de
chacune des dimensions associée au cube. Il existe deux modélisation courante permettant d’effectuer une
telle modélisation.
Modèle en Étoiles Chaque cube est associé à une table de faits dont la clé est composée de toutes les
clés des tables de dimensions qui lui sont associées. Les autres champs de la table de fait sont les mesures
du cube.
Dans les tables de dimensions, on retrouve la clé de la dimension, des informations complémentaire et
un champ par niveau de la dimension (notion de granularité).
Figure 9.2 – Modèle en étoiles
Modèle en Flocons Le modèle flocon est un dérivé du modèle étoile qui normalise les tables de dimensions
suivant leur granularité. Dans un modèle flocon, les différents niveaux de la dimension seront normalisé dans
des tables.
Figure 9.3 – Modèle en flocons
27