Structure d’un système décisionnel

Avant d’aller plus loin, il convient de situer
la place du cube dans un système
décisionnel et par la même faire une
rapide révision de l’architecture type
d’un système décisionnel.
Comme le montre le schéma 1, les
bases de données transactionnelles
(OLTP: Online Transaction Processing)
(par exemple les bases de données utilisées
pour stocker chaque seconde les
opérations des caisses enregistreuses
d’un supermarché) sont modélisées
pour optimiser les opérations d’insertion
et de maintenance.
Les tables sont fortement normalisées
(en général en troisième forme
normale (cf. Codd) : toutes les colonnes d’une table dépendent alors de la clé primaire,
de l’intégralité de la clé primaire et uniquement de la clé primaire).
Cette normalisation conduit à  la création d’un grand nombre de tables jointes entre elles. Pour reprendre l’exemple du supermarché, il y
aura vraisemblablement une table Rayon et une table
Produit, ainsi lorsque l’on devra changer le nom d’un rayon,
il suffira de changer une ligne de la table Rayon et non
chaque ligne des produits appartenant à  un rayon.
Si cette structure permet d’accélérer les insertions et de
faciliter les opérations de maintenance, elle répond mal aux
besoins analytiques des utilisateurs fonctionnels.
En effet, pour reprendre l’exemple du supermarché, le
responsable du magasin sera sans doute intéressé par le
chiffre d’affaire total du Rayon frais pour le premier trimestre
de l’année en cours. Ce type de requête métier sera confrontée
aux deux « ennemis publics numéros un » du SQL en ce
qui concerne la rapidité des requêtes : les jointures (ici pour
passer de la table des ventes à  la table des rayons) et les agrégations
(consolidation des données stockées à  la seconde au
chiffre trimestriel). A cela vient s’ajouter le fait qu’il n’est pas
idéal de faire cohabiter requêtes décisionnelles et requêtes
transactionnelles sur la même base de données. (Le fonctionnement
des caisses pourrait être perturbé par les
requêtes effectuées par les membres de la direction du
magasin.)
Il est donc préférable de construire une base relationnelle
dédiée aux requêtes métiers. La structure de cette base
sera dénormalisée, simplifiée : de la redondance sera ajoutée
pour accélérer les requêtes en sélection.
La structure d’une telle base aura souvent la forme d’un
schéma en étoile : une table centrale (table des faits) qui
contient les données numériques ayant un intérêt pour les
analyses (par exemple Chiffre d’affaire, coût …) et des colonnes
clef étrangères vers les autres tables du modèle. C’est
à  partir de ces autres tables satellites que seront construites
les dimensions. Une dimension est un axe
d’analyse selon lequel il convient d’analyser
les indicateurs numériques de la table
de fait. Dans l’exemple du supermarché, la
période, le produits, le client peuvent être
des axes d’analyse intéressants.
Cette structure relationnelle homogène
et fiable, source des requêtes décisionnelles
est appellée DataWarehouse
(Entrepôt de données) lorsque la base
couvre toutes les questions de l’entreprise
et Data Mart (Magasin de données)
lorsque la base se concentre sur une question
métier particluière (on parle alors de
DataMart Finance ou DataMart Marketing
…)
Un système décisionnel se définit par
la création d’un DataMart ou d’un
DataWarehouse relationnel, zone de stockage homogène et
fiable pour l’ensemble des besoins de reporting.
Le DataMart relationnel peut tout à  fait convenir pour
couvrir à  lui seul les besoins de reporting. Cependant malgré
la dénormalisation effectuée, les requêtes peuvent s’avérer
encore trop lentes. Et dans bien des cas, le langage SQL n’est
pas adapté pour répondre facilement aux questions posées
par les utilisateurs.
Les cubes OLAP (Online Analytical Processing) Microsoft
proposent justement de résoudre ces problématiques :

• le stockage des agrégations les cubes OLAP permettent
  d’obtenir un temps de réponse constant quelle que soit la
  volumétrie des données traitées

• leur structure multi-dimensionnelle colle parfaitement à  la
  logique des questions métiers. Concernant ce dernier
  point, le langage MDX (Multi-Dimensionnal Expression)1
  utilisé pour interroger les cubes MS OLAP est un avantage
  majeur lorsqu’il s’agit d’écrire simplement les requêtes métier
  les plus complexes.