II.

4 L’informatique décisionnelle
L’informatique décisionnelle (ou business intelligence) est l'informatique
dédiée aux décideurs et aux dirigeants d'entreprises. Elle désigne les moyens, les
outils et les méthodes qui permettent de collecter, historier, consolider, modéliser,
extraire, traiter et restituer les données, matérielles ou immatérielles, d'une
entreprise en vue d'offrir une aide à la décision et de permettre à un décideur
d’avoir une vue d’ensemble de l’activité analysée.

II.5 Le système DataWarehouse

II.5.1 Définition
Bill Inmon définit le Data Warehouse, dans son livre considéré comme étant
la référence dans le domaine “Building the Data Warehouse” [Inmon, 2002] comme
suit: « Le Data Warehouse est une collection de données orientées sujet, intégrées,
non volatiles et évolutives dans le temps, organisées pour le support d’un processus
d’aide à la décision. » Les paragraphes suivants illustrent les caractéristiques
citées dans la définition d’Inmon.
Orienté sujet : le Data Warehouse est organisé autour des sujets majeurs de
l’entreprise, contrairement à l’approche transactionnelle utilisée dans les systèmes
opérationnels, qui sont conçus autour d’applications et de fonctions telles que :
cartes bancaires, solvabilité client…, les Data Warehouse sont organisés autour de
sujets majeurs de l’entreprise tels que : clientèle, ventes, production…. Cette
organisation affecte forcément la conception et l’implémentation des données
contenues dans le Data Warehouse.
Intégrée : le Data Warehouse va intégrer des données en provenance de
différentes sources. La transversalité recherchée sera d’autant plus efficiente que
le système d’information sera réellement intégré. Cette intégration nécessitera une
forte normalisation, une bonne gestion des référentiels et de la cohérence, une
parfaite maîtrise de la sémantique et des règles de gestion s’appliquant aux
données manipulées.
Evolutives dans le temps : Dans un système décisionnel il est important de
conserver les différentes valeurs d’une donnée, cela permet les comparaisons et le
suivi de l’évolution des valeurs dans le temps, alors que dans un système
opérationnel la valeur d’une donnée est simplement mise à jour. Dans un
DataWarehouse chaque valeur est associée à un moment « Every key structure in
the data warehouse contains - implicitly or explicitly -an element of time » [Inmon,
2000].
Non volatiles : c’est ce qui est, en quelque sorte la conséquence de l’historisation
décrite précédemment. Une donnée dans un environnement opérationnel peut être
mise à jour ou supprimée, de telles opérations n’existent pas dans un
environnement Data Warehouse. Afin de conserver la traçabilité des
informations et des décisions prises, les informations stockées au sein du Data
Warehouse ne peuvent pas être supprimées.
Organisées pour le support d’un processus d’aide à la décision : Les
données du Data Warehouse sont organisées de manière à permettre l’exécution
des processus d’aide à la décision (Reporting, Data Mining…).
II.5.2 Structure des données d’un Data Warehouse
Le Data Warehouse a une structure bien définie, selon différents niveaux d’agrégation et de
détail des données. Cette structure est définie par Inmon [Inmon, 2000] comme suit

Figure 1:Structure des données d’un entrepôt de données

Données détaillées : ce sont les données qui reflètent les événements les plus
récents, fréquemment consultées, généralement volumineuses car elles sont d’un
niveau détaillé. Les intégrations régulières des données issues des systèmes de
production sont réalisées à ce niveau.
Données détaillées archivées : anciennes données rarement sollicitées,
généralement stockées dans un disque de stockage de masse, peu coûteux, à un
même niveau de détail que les données détaillées.
Données agrégées : constituent un résultat d’analyse et une synthèse de
l’information contenue dans le système décisionnel, et doivent être facilement
accessibles et compréhensibles.
Données fortement agrégées : données agrégées à partir des données détaillées,
à un niveau d’agrégation plus élevé que les données agrégées.
Meta données : ce sont les informations relatives à la structure des données, les
méthodes d’agrégation et le lien entre les données opérationnelles et celles du Data
Warehouse. Les métadonnées doivent renseigner sur : Le modèle de données, la
structure des données telle qu’elle est vue par les développeurs, la structure des
données telle qu’elle est vue par les utilisateurs, les sources des données, les
transformations nécessaires et le suivi des alimentations.
II.5.3 Les éléments d’un Data Warehouse
 L’environnement du Data Warehouse est constitué essentiellement de
quatre éléments : les applications opérationnelles, la zone de préparation des
données, la présentation des données et les outils d’accès aux données.
Les applications opérationnelles : ce sont les applications du système
opérationnel de l’entreprise et dont la priorité est d’assurer le fonctionnement de
ce dernier et sa performance. Ces applications sont extérieures au Data
Warehouse.
Préparation des données : la préparation englobe tout ce qu’il y a entre les
applications opérationnelles et la présentation des données. « Un point très
important, dans l’aménagement d’un entrepôt de données, est d’interdire aux
utilisateurs l’accès à la zone de préparation des données, qui ne fournit aucun
service de requête ou de présentation ». [Kimball, 2002]
Présentation des données : c’est l’entrepôt où les données sont organisées et
stockées. Si les données de la zone de préparation sont interdites aux utilisateurs,
la zone de présentation est tout ce que l’utilisateur voit et touche par le biais des
outils d’accès.
Les outils d’accès aux données : L’exploitation du Data Warehouse se fait par
le biais d’un ensemble d’outils analytiques développés autour du Data Warehouse.
Donc cette étape nécessite l’achèvement du développement, ou de la mise en
place de ces outils qui peuvent accomplir les fonctions suivantes: Le requêtage ad-
hoc, Reporting, tableau de bord, data mining.
II.5.4 Architecture d’entrepôts de données
II.5.4.1 Data Mart interconnectés
Les Datamarts sont développés par sujet/processus d’affaire, en se basant
sur des dimensions conformes. L’entrepôt de données est formé de magasin de
données inter-reliées à l’aide d’une couche d’intergicielle (middlware) ou bus
(Appellation proposée par Ralph Kimball dans son ouvrage [Kimball, 2002].).

Figure 2: Architecture bus de données [Kimball, 2002]

II.5.4.2 Architecture Hub and Spoke

Cette approche est celle proposée par Bill Inmon ici l’entrepôt (hub) contient
des données atomiques c’est-à-dire le niveau de détail le plus fin et normalisé 3FN ;
les Datamart spoke reçoivent les données de l’entrepôt. Les données des Datamarts
suivent le modèle dimensionnel et sont principalement résumées (pas atomique).
La plus part des requêtes analytiques sont faites sur les Datamarts.

Figure 3:Architecture fédéré

II.5.5 Modélisation des données de l’entrepôt

Les Data Warehouse sont destinés à la mise en place de systèmes
décisionnels. Ces systèmes, devant répondre à des objectifs différents des systèmes
transactionnels, ont fait ressortir très vite la nécessité de recourir à un modèle de
données simplifié et aisément compréhensible. La modélisation dimensionnelle
permet cela. Elle consiste à considérer un sujet d’analyse comme un cube à
plusieurs dimensions, offrant des vues en tranches ou des analyses selon différents
axes.

Figure 4:Considération d’un sujet d’analyse comme un cube à plusieurs dimensions

II.5.5.1 Concept de fait

Une table de faits est la table centrale d’un modèle dimensionnel, où les
mesures de performances sont stockées. Une ligne d’une table de fait correspond
à une mesure. Ces mesures sont généralement des valeurs numériques, additives;
cependant des mesures textuelles peuvent exister mais sont rares. Le concepteur
doit faire son possible pour faire des mesures textuelles des dimensions, car elles
peuvent êtres corrélées efficacement avec les autres attributs textuels de
dimensions.
II.5.5.2 Concept de dimension
Les tables de dimension sont les tables qui accompagnent une table de faits,
elles contiennent les descriptions textuelles de l’activité. Une table de dimension
est constituée de nombreuses colonnes qui décrivent une ligne. C’est grâce à cette
table que l’entrepôt de données est compréhensible et utilisable; elles permettent
des analyses en tranches et en dés.
 II.5.6 Différents modèles de la modélisation dimensionnelle
Modèle en étoile : ce modèle se présente comme une étoile dont le centre n’est
autre que la table des faits et les branches sont les tables de dimension. La force
de ce type de modélisation est sa lisibilité et sa performance.

Figure 5:Modèle en étoile

Modèle en flocon : identique au modèle en étoile, sauf que ses branches sont
éclatées en hiérarchie. Cette modélisation est généralement justifiée par
l’économie d’espace de stockage, cependant elle peut s’avérer très couteuse en
termes de performances et moins compréhensible pour l’utilisateur final.

Figure 6:Modèle en flacon

II.5.6.1 Le concept OLAP

Le terme OLAP (On-Line Analytical Processing) désigne une classe de
technologies conçue pour l’accès aux données et pour une analyse instantanée de
ces dernières, dans le but de répondre aux besoins de Reporting et d’analyse. R.
Kimball définit le concept « OLAP » comme «Activité globale de requêtage et de
présentation de données textuelles et numériques contenues dans l’entrepôt de
données; Style d’interrogation spécifiquement dimensionnel » [Kimball, 2005].
II.5.6.2 Architecture des serveurs OLAP
Ce concept a été appliqué à un modèle virtuel de représentation de données
appelé cube ou hyper cube OLAP qui peut être mis en œuvre de différentes façons :

 Les systèmes à architecture MOLAP : les systèmes de type

MOLAP stockent les données dans un SGBD multidimensionnel sous
la forme d’un tableau multidimensionnel. Ces systèmes demandent
un pré-calcul de toutes les agrégations possibles. En conséquence, ils
 sont plus performants que les systèmes traditionnels, mais difficiles
à mettre à jour et à gérer.

Figure 7:Architecture de base MOLAP

 Les systèmes à architecture ROLAP : R. Kimball définit ces

systèmes comme étant un « Ensemble d’interfaces utilisateurs et
d’applications qui donnent une vision dimensionnelle à des bases de
données relationnelles » [Kimball, 2005]. Les systèmes ROLAP «
Relationnel On-line Analytical Processing » sont en mesure de
simuler le comportement d’une SGBD multidimensionnel en
exploitant un SGBD relationnel.

Figure 8:Principe de l’architecture ROLAP

 Les systèmes à architecture HOLAP : Les systèmes HOLAP sont

une sorte de compromis entre les différents systèmes précités. Cette
combinaison donne à ce type de système les avantages du ROLAP et
du MOLAP en utilisant tour à tour l’un ou l’autre selon le type de
données.
II.5.7 La navigation dans les données
Une fois que le serveur OLAP a construit le cube multidimensionnel « ou
simulé ce cube selon l’architecture du serveur », plusieurs opérations sont possibles
sur ce dernier offrant ainsi la possibilité de naviguer dans les données qui le
constituent. Ces opérations de navigation « Data Surfing » doivent être, d’une
part, assez complexes pour adresser l’ensemble des données et, d’autre part, assez
simples afin de permettre à l’utilisateur de circuler de manière libre et intuitive
dans le modèle dimensionnel. Afin de répondre à ces attentes, un ensemble de
mécanismes est exploité, permettant une navigation par rapport à la dimension et
par rapport à la granularité d’une dimension.
 II.5.7.1 Slice & Dice
Le « Slicing » et le « Dicing » sont des techniques qui offrent la possibilité de
faire des tranches dans les données par rapport à des filtres de dimension bien
précis, se classant de fait comme des opérations liées à la structure . La différence
entre eux se manifeste dans le fait que le Slicing consiste à faire une sélection de
tranches du cube selon des prédicats et selon une dimension « filtrer une dimension
selon une valeur »
II.5.7.2 Drill down et Roll-up
Ces méthodes, appelées aussi « forage vers le bas/vers le haut », sont les
méthodes les plus répandues pour une navigation dans un entrepôt de données.
Elles consistent à représenter les données du cube à un niveau de granularité
inférieur, dans le cas du « Drill down», ou un niveau supérieur, c’est le « Roll-up ».
En somme, ces deux opérations permettent de contrôler le niveau de détail des
données du cube.

Figure 9:Représentation d'un cube OLAP et des opérations possibles

II.5.8 Systèmes d’Extraction-Transformation-Chargement ETC

Il s’agit d’une technologie informatique intergicielle (middleware)
permettant d’effectuer des synchronisations massives d’information d’une banque
de données vers une autre.

Figure 10:représentation de l’ETL

Nous allons étudier plus en détail chacune des étapes de l’extraction,

transformation et chargement.
 Le processus d’extraction : L’extraction des données sources est la
première étape d’un outil d’alimentation. Son rôle, comme son nom
l’indique, est de lire et d’extraire les données des systèmes sources qui
se trouvent le plus souvent dans des bases de données de production
ou dans des fichiers. L’E.T.L utilise des connecteurs pour interagir
avec les bases de données ou les fichiers. Il faut, dans la mesure du
possible, extraire seulement les données utiles.
 Le processus de transformation : La transformation est une tâche
complexe qui nécessite beaucoup de réflexion et de ressource. Après
avoir extrait les données, il faut effectuer plusieurs traitements en
vue de les : dénormaliser, nettoyer, réconcilier et préparer.

 Le processus de chargement : Le chargement consiste à insérer ou

mettre à jour les données cibles tout en conservant les données
modifiées devant l’être, afin de conserver une traçabilité des
informations (desquelles découlent les décisions prises). On peut en
déduire l’existence de deux types de chargement de données: le
chargement complet ou initial et le chargement incrémental
correspondant aux mises à jour périodiques.