Conception logique

La conception logique d’un entrepôt de données vise à organiser et classer les informations des sources de données par sujet fonctionnel. Elle est préliminaire à la modélisation dimension-nelle où chaque sujet correspond à une table gérée au sein de l’entrepôt. Ce dernier permet d’isoler les données stratégiques et de conserver les métadonnées.

L’interrogation des entrepôts de données se fait par des requêtes OLAP. Ces requêtes cor-respondent à une structuration des données selon plusieurs axes d’analyse pouvant représenter des notions variées telles que le temps de la localisation géographique ou le code identifiant des produits. Les modèles de conception des systèmes transactionnels ne sont pas adaptés à ce type de requêtes complexes qui utilisent beaucoup de jointures, demandent beaucoup de temps de calcul et sont de nature ad hoc. Pour ce type d’environnement, une nouvelle approche de modélisation a été suggérée: les modèles multidimensionnels.

1.1.2.1 Les modèles multidimensionnels

La modélisation multidimensionnelle permet d’observer un sujet analysé comme un point dans un espace à plusieurs dimensions. Les données sont organisées d’une manière qui met en évidence le sujet en cours d’analyse et ses différentes perspectives d’analyse. Ainsi, ce modèle a donné naissance aux concepts de fait et de dimension.

1. Une dimension est une liste d’éléments organisés de façon hiérarchique. Par exemple, pour le client, nous pouvons avoir la hiérarchie: adresse, ville et pays. Ainsi, les tables de dimensions contiennent les niveaux hiérarchiques des dimensions ainsi que les formules à appliquer sur les données numériques pour passer d’un niveau à un autre. La figure 1.3 illustre un exemple d’hiérarchie.

Figure 1.3 – Vue multidimensionnelle des données

2. Un fait représente le sujet analysé. Il est formé de mesures qui correspondent aux infor-mations liées au thème analysé. Les mesures sont stockées dans des tables de faits qui contiennent les valeurs des mesures et les clés vers les tables de dimensions.

L’objectif majeur de cette modélisation est la vision multidimensionnelle des données, ce qui est assuré via le concept de cube de données. Ce dernier organise les données en une ou plusieurs dimensions qui déterminent une mesure d’intérêt.

Deux approches fondamentales sont utilisées pour construire des systèmes basés sur un modèle multidimensionnel.

1.1.2.2 Les systèmes MOLAP

Les systèmes de type MOLAP (”Multidimensional On-Line Analytical Processing”) stockent les données dans un SGBD multidimensionnel sous la forme d’un tableau multidimensionnel où chaque dimension est associée à une dimension du cube. L’intérêt de cette approche est l’optimisation du temps d’accès, mais elle présente certaines limites telles que

– le besoin de redéfinir des opérations pour manipuler les structures multidimensionnelles, – la difficulté de la mise à jour et de la gestion du modèle,

– la consommation de l’espace lorsque les données sont éparses, ce qui nécessite l’utilisation des techniques de compression. [6]

1.1. Cycle de vie de conception d’un entrepôt de données 1.1.2.3 Les systèmes ROLAP

Les systèmes de type ROLAP ("Rolational On-Line Analytical Processing") utilisent un SGBD relationnel pour stocker les données de l’entrepôt. Le moteur OLAP est un élément supplémentaire qui fournit une vision multidimensionnelle de l’entrepôt, des calculs de don-nées dérivées et des agrégations à différents niveaux. Il est aussi responsable de la génération des requêtes SQL mieux adaptées au schéma relationnel, qui bénéficient des structures d’op-timisation existantes pour exécuter efficacement ces requêtes. Ces systèmes peuvent stocker de grands volumes de données, mais ils peuvent présenter un temps de réponse élevé. Leurs principaux avantages sont la facilité d’intégration dans les SGBDs relationnels existants et une bonne efficacité pour stocker les données multidimensionnelles.

Il existe deux schémas principaux pour modéliser les systèmes ROLAP [6].

Schéma en étoile est largement utilisé par les industriels. Il contient une table des faits

normalisée et des tables de dimension qui sont généralement dé-normalisées afin de minimiser le nombre de jointures nécessaires pour évaluer une requête. La figure 1.4 illustre un schéma en étoile où la table des faits V EN T ES stocke la quantité et le montant de vente d’un client pour un magasin donné. Les tables correspondant à CLIEN T , à T EM P S, P RODU IT et

M AGASIN comportent les informations pertinentes sur ces dimensions. Il est à noter que la

fusion de plusieurs schémas en étoile, qui ont des tables de dimension, donne lieu à un schéma

en constellation. Ainsi, le schéma contient plusieurs tables de faits.

Figure 1.4 – Exemple d’un schéma en étoile.

Les requêtes typiques de ce schéma, nommées requêtes de jointure en étoile (star-join

que-ries), ont les caractéristiques suivantes :

– il y a des jointures multiples entre la table des faits et les tables de dimension, – il n’y a pas de jointure entre les tables de dimensions.

Chaque table de dimensions impliquée dans une opération de jointure a plusieurs prédicats de sélection sur ses attributs descriptifs. La syntaxe générale de ces requêtes est la suivante:

SELECT <Liste de projection> <Liste d’agrégation>

FROM <Nom de la table des faits> <Liste de noms de tables de dimension> WHERE <Liste de prédicats de sélection et de jointure>

GROUP BY <Liste des attributs de tables de dimension> Order by <Liste des attributs de tables de dimension>

Schéma en flocon de neige (snowflake schema) est un raffinement du schéma en étoile.

Certaines tables de dimensions sont normalisées selon leur hiérarchie en donnant lieu à de nouvelles tables. La figure 1.5 illustre le schéma en flocon de neige correspond au schéma en étoile de la figure 1.4.

Figure 1.5 – Exemple d’un schéma en flocon en neige.