• Aucun résultat trouvé

2 Chapitre 2 : Entrepôts de Données et OLAP

2.5.2 Modélisations logique et physique ROLAP

Dans cette section nous présentons les modélisations logique (Section 2.5.2.1) et physique (Section 2.5.2.2) des systèmes ROLAP.

2.5.2.1 Modélisation logique ROLAP

Dans les implémentations ROLAP, l'ED (i.e. la base de données) est organisé de façon à révéler la dimensionnalité intrinsèque des données décisionnelles suivant des schémas particuliers qui sont des extensions du schéma relationnel. Le schéma relationnel de l'ED inclut un ensemble de tables de fait (les tables relationnelles correspondant aux faits conceptuels) et un ensemble de tables de dimension (les tables représentant les dimensions et leurs niveaux d'agrégation) [Kimball, 1996]. Les tables de fait référencent les tables de dimension en utilisant des clés étrangères. Les tables de dimension peuvent être plus ou moins dénormalisées, ce qui donne lieu à trois types de schéma : en étoile, en flocons de neige ou hybride.

2.5.2.1.1Schéma en étoile

Le schéma en étoile est constitué d'une table de fait qui référence un ensemble de tables de

dimension. Chaque table de dimension correspond à une dimension conceptuelle. Elle

contient une clé primaire et un ensemble de colonnes qui décrivent la dimension; chaque colonne correspond à un attribut de dimension conceptuel. La table de fait correspond à un fait conceptuel et inclut une colonne pour chaque mesure du fait. Cette table référence les tables de dimension en utilisant des clés étrangères; et sa clé primaire est définie par la composition de l'ensemble de ces clés étrangères.

Les tables de dimension sont totalement dénormalisées puisque tous les niveaux d'agrégation d'une dimension sont représentés par une seule table. Ceci permet d'optimiser les performances en temps de réponse aux requêtes (car le nombre de jointures est minimisé); en revanche, cette dénormalisation introduit de la redondance dans les données ce qui nécessite plus d'espace de stockage [Kimball, 1996].

Figure 2.6. Exemple de schéma en étoile. Hypercube des "Ventes". Issue de [Malinowski et Zimányi, 2008].

2.5.2.1.2Schéma en flocons de neige

Le schéma en flocons de neige permet de supprimer la redondance de données introduite par le schéma en étoile. Dans ce schéma, chaque niveau d'agrégation de la dimension est représenté par une table. Ces tables sont reliées par des contraintes d'intégrité référentielle (i.e. clés étrangères) qui traduisent les relations conceptuelles entre les niveaux d'agrégation. Comme pour le schéma en étoile, la table de fait est reliée aux tables de dimension correspondant aux niveaux d'agrégation les plus fins des dimensions, en utilisant des clés étrangères. Cette modélisation permet d'éviter certaines redondances de données, mais affecte négativement les performances en temps de réponse aux requêtes puisqu’elle augmente le nombre de jointures nécessaires entre les tables.

2.5.2.1.3Schéma hybride

Le schéma hybride, appelé aussi starflake, est la combinaison des deux types de schéma décrits précédemment : certaines dimensions sont normalisées (dans le sens où on a une table par niveau d'agrégation), d'autres sont partiellement normalisées (i.e. certains niveaux d'agrégation sont normalisés et d'autres non), et d'autres encore sont dénormalisées.

2.5.2.1.4Schéma en constellation

Lorsque le nombre de tables de fait est supérieur ou égal à 2, ce qui est généralement le cas9, on parle alors souvent de constellation d'étoiles, schéma en constellation. Un schéma en constellation est défini comme un ensemble (constellation) d'étoiles partageant des tables de dimension. Il peut contenir des dimensions plus ou moins normalisées.

Le choix entre la normalisation ou dénormalisation des dimensions est souvent fait en considérant deux critères : le coût de stockage et les performances en temps de réponse aux requêtes attendues [Kimball et Ross, 2002].

9

Un entrepôt de données est sensé représenté tous les sujets d'analyse d'une organisation, ce qui donne lieu généralement à plusieurs tables de fait.

2.5.2.2 Modélisation physique ROLAP

La modélisation physique des ED est une phase très importante notamment dans le contexte des systèmes ROLAP [Adamson, 2006]. Le but est de trouver des techniques pour un stockage efficace et un accès rapide à l'information. Dans cette phase, le modèle MD logique est traduit dans le langage supporté par la plateforme d'implémentation cible. Ensuite un ensemble de techniques d'optimisation sont définies pour améliorer les performances (en temps de réponse et coût de stockage) du système décisionnel. Vues matérialisées, index optimisés et fragmentation sont les techniques les plus couramment utilisées.

La matérialisation de vues consiste à précalculer et stocker physiquement (matérialiser) certaines requêtes (e.g. les requêtes les plus fréquentes ou les plus coûteuses) dans des tables [Adamson, 2006]. Ceci permet d'améliorer les performances en temps de réponse aux requêtes au détriment du coût de stockage (i.e. l'espace et le temps de mise à jour nécessaires). Les problématiques liées à cette technique notamment la sélection (quelles sont les vues à matérialiser ?), la maintenance de ces vues (leurs mises à jour) et la réécriture de requêtes utilisateurs en fonction des vues matérialisées ont été largement étudiées dans la littérature et beaucoup de solutions furent proposées.

Le but de l'indexation est d'accélérer l'exécution des requêtes en permettant l'accès direct aux données. Deux types d'indexes sont couramment utilisés dans les ED : les indexes binaires (ou Bitmap) et les indexes de jointure [Bellatreche et al., 2004]. Les indexes binaires sont adaptés aux attributs à faible cardinalité. Ces indexes nécessitent peu d'espace de stockage et peuvent être manipulés via des opérateurs logiques, ce qui les rend très efficaces. Les indexes de jointure matérialisent les jointures relationnelles entre deux tables en stockant les couples d'identifiants de tuples joints dans une table à deux colonnes.

Finalement, la fragmentation est une technique d’optimisation de performance qui consiste à diviser le contenu d'une table en plusieurs fragments de telle sorte que la combinaison de ces fragments produit l’intégralité des données source, sans perte ou ajout d’information [Bellatreche, 2000]. Cette technique nécessite aussi des méthodes de réécriture et d'exécution parallèle de requêtes.

2.6Conclusion

Dans ce chapitre nous avons décrit les notions essentielles des systèmes d'entrepôts de données et OLAP. Ces systèmes ont été définis comme des SAD particuliers permettant l'intégration, l'historisation et l'analyse multidimensionnelle interactive de plusieurs sources données; et leurs différences par rapport aux systèmes OLTP ont été mentionnées. Il a été ensuite présenté le modèle multidimensionnel sur lequel se base ces systèmes et qui définit (i) des structures de données (dimension, mesure, hiérarchie, etc.) permettant de représenter les informations décisionnelles dans un espace à n dimensions, en accord avec la vision des décideurs; (ii) des fonctions (e.g. Sum) permettant d'agréger les mesures lorsque les utilisateurs naviguent dans les hiérarchies de dimension; et enfin (iii) des opérateurs (e.g. Roll-up) permettant l'exploration rapide des hypercubes de données. Nous avons souligné que l'agrégation des mesures constitue une opération fondamentale dans ces systèmes et que celle-ci dépend de trois conditions d'agrégeabilité : disjonction, complétude et compatibilité

de type. Concernant l'additivité (applicabilité de la fonction d'agrégation Sum), il a été

distingué trois types de mesures : (i) les mesures de type flux qui peuvent être sommées selon tout type de dimension; (ii) les mesures de type stock qui ne peuvent pas être sommées selon la dimension temporelle; et (iii) les mesures de type valeur par unité dont la somme le long de tout type de dimension n'a généralement pas de sens. Toujours par rapport à l'agrégeabilité, il a été rappelé que le type de la hiérarchie de dimension (régulière ou irrégulière), qui sert de support à l'agrégation, est également à considérer. Nous avons ensuite

décrit les couches logicielles composant l'architecture typique de ces systèmes avec une présentation et une comparaison des trois types d'implémentations possibles de cette architecture (ROLAP, MOLAP et HOLAP). Ce chapitre se termine par une section sur la modélisation multidimensionnelle qui présente brièvement les principaux modèles conceptuels en mettant l'accent sur les modèles basés sur UML; également la modélisation logique des systèmes ROLAP où il est souligné que le recours à un schéma en étoile, en flocons de neige ou hybride, dépend du coût de stockage et des performances attendues en termes de temps de réponse aux requêtes; et enfin les principales techniques de modélisation physique des systèmes ROLAP (vues matérialisées, index optimisés et fragmentation) permettant d'optimiser le stockage et l'accès à l'information sont brièvement décrites.

Dans ce chapitre, nous avons défini les concepts qui vont servir de base aux définitions du chapitre suivant, qui lui porte sur les systèmes d'entrepôts de données spatiales et SOLAP; ces systèmes, sur les quels portent nos travaux de thèse, représentent des extensions des systèmes OLAP pour la prise en compte de l'information spatiale dans l'analyse multidimensionnelle.

3 Chapitre 3 : Entrepôts de Données Spatiales