Du DataWarehouse au WebHouse : le croisement des réseaux et

des bases de données

Samira Silhadi-HacidMalika Tarafi

1. Introduction

Un entrepôt de données (data warehouse) [Kim96, Inmo96] est un ensemble de technologies destinées à permettre à une personne qui manipule des connaissances (gestionnaire, analyste, cadre) de prendre de bonnes et rapides décisions. Pour une bonne aide à la décision, la personne est supposée avoir la bonne information, à la bonne place, au bon moment et avec un faible coût. La pratique a montré que les systèmes transactionnels ne sont pas appropriés pour l’aide à la décision et que les avancées réalisées dans le domaine des réseaux ne peuvent, à elles seules, résoudre le problème de l’accessibilité à l’information.

L’entrepôt de données est devenu une stratégie importante pour intégrer des sources d’informations hétérogènes dans les organisations, et permettre un traitement analytique en-ligne. Le développement des entrepôts de données est une conséquence de l’observation, par W. Inmon et E. F. Codd, au début des années 90, sur le fait que le niveau opérationnel du traitement transactionnel en-ligne (OLTP) et les applications d’aide à la décision (OLAP) ne peuvent pas coexister efficacement dans le même environnement de bases de données, essentiellement à cause de leurs caractéristiques transactionnelles très différentes.

Un entrepôt de données centralise des données d’intérêt sélectionnées pour un groupe de clients, de telle sorte que l’accès devienne rapide, moins coûteux et plus efficace. Considéré comme un tampon long-terme entre l’OLTP et l’OLAP (figure 1), l’entrepôt de données pose deux problèmes importants : (1) comment réconcilier les données émanant de multiples sources d’informations hétérogènes ; (2) comment personnaliser les données dérivées pour des applications OLAP spécifiques.

1

Figure 1 : Du traitement transactionnel au traitement analytique

Nous considérons un entrepôt de données comme une collection de données orientées sujet, intégrées, variables dans le temps, et non volatiles, utilisées essentiellement pour l’aide à la décision. Le but d’un entrepôt de données est de supporter le traitement analytique en-ligne (OLAP). Les exigences en terme de fonctionnalités et de performances de ces traitements sont différents de ceux des applications de traitement transactionnel en-ligne (OLTP), habituellement supportés par les bases de données opérationnelles. Pour permettre des analyses et visualisation complexes, les données dans l’entrepôt sont organisées selon le modèle de données multidimensionnel. La modélisation de données multidimensionnelle signifie l’agrégation partielle des données de l’entrepôt selon différents critères.

1.1 Agrégation multidimensionnelle

Le marché traditionnel des bases de données traite des applications de traitement transactionnel en-ligne (OLTP). Les applications OLTP se caractérisent par un grand nombre de transactions relativement simples. Habituellement, les transactions retrouvent et mettent à jour un petit nombre d’enregistrements qui sont contenus dans plusieurs tables distinctes. Les relations entre ces tables sont généralement simples. Une transaction OLTP typique pour une entrée commande client pourrait retrouver toutes les données relatives à un client spécifique et ensuite insérer une nouvelle commande pour le client. Les relations entre les enregistrements sont simples et seul un petit nombre d’enregistrements est retrouvé ou mis à jour pour une transaction donnée.

Cependant, ce qui est attendu de la technologie de l’information d’aujourd’hui c’est la possibilité d’aider les utilisateurs de connaissances (gestionnaire, analyste, etc.) dans la prise de décision. Des requêtes typiques qu’un utilisateur voudrait formuler à son entrepôt de données de l’entreprise sont :

. Quelles étaient les quantités vendues par région et catégorie de produit pour l’année précédante ?. Comment le prix des actions des constructeurs d’ordinateurs est-il corrélé avec les profits trimestriels au cours des 10 dernières années ?. Quelles commandes doivent être satisfaites pour maximiser les profits ?

2

Il est clair que de telles exigences en matière d’interrogation ne peuvent être satisfaites par les systèmes traditionnels.

1.2 OLAP et aide à la décision

Les applications OLAP sont assez différentes des applications OLTP. L’OLAP fait partie de systèmes d’aide à la décision et des systèmes d’information exécutifs. La fonctionnalité des OLAP est caractérisée par l’analyse multidimensionnelle et dynamique de données consolidées qui supportent les activités analytique et navigationnelle d’un utilisateur final. Au niveau pratique, l’OLAP entraîne toujours l’interrogation interactive des données, en réalisant des analyses à travers de multiples passes, comme drill-down, successivement dans des niveaux de détail inférieurs.

L’information est multidimensionnelle, signifiant pour l’utilisateur qu’elle peut être visualisée sous forme de grilles. Elle est typiquement visualisée sous forme de cubes, et des outils proposent la possibilité de pivoter les axes du cube. Une caractéristique des outils OLAP pour l’analyse de données est de permettre la consolidation de données à des niveaux supérieurs, tout en supportant des requêtes sur les niveaux de détail. Considérons l’exemple suivant de session d’analyse OLAP : une base de données OLAP peut consister en des données ventes qui ont été agrégées par région, type de produit, et type de distribution. Une requête OLAP typique pourrait accéder une base de données ventes de plusieurs gigabytes contenant des informations sur plusieurs années afin de retrouver toutes les ventes de produits dans chaque région pour chaque type de produit. Après avoir exploré les résultats, un analyste pourrait alors affiner la requête pour retrouver les quantités vendues pour chaque type de distribution dans des classifications région/produit. Comme dernière étape, l’analyste pourrait vouloir réaliser des comparaisons années-années ou trimestre-trimestre pour chaque type de distribution.

2. Une architecture pour les entrepôts de donnéesL’architecture d’un entrepôt de données influence plusieurs facteurs comme la disponibilité des données et l’efficacité des traitements. L’architecture la plus simple consiste seulement en des bases de données sources, un entrepôt de données central et plusieurs clients. Parce que les applications des entrepôts de données sont devenues plus complexes, les entrepôts sont construits en utilisant des architectures multi-niveaux afin d’accroître la performance, i.e., il n’y a pas seulement un entrepôt de données cantral, mais aussi des « data marts » qui permettent de placer les données le plus proche de l’utilisateur final.

3

La figure 2 donne un aperçu des composants d’un entrepôt de données et les relations entre ces composants. Les données sont chargées par des « wrappers » à partir de plusieurs sources dans l’entrepôt de données. Dans l’entrepôt, les données sont intégrées pour respecter un schéma commun. Un administrateur contrôle les composants pour le chargement et la distribution des données. La métabase est un entrepôt qui contient des informations relatives aux différents composants.

Figure 2 : Architecture générale d’un entrepôt de données

2.1 Les composants d’un entrepôt de données

2.1.1 Sources et « wrappers »

Concernant les sources, les compagnies spécialisées dans les entrepôts de données tentent de prendre en compte autant de sources de données que possible. Les catégories de sources d’information suivantes sont mentionnées dans le contexte de l’intégration de sources de données :

. Systèmes de bases de données (relationnel, orienté-objet, réseau, hiérarchique)

. Sources d’information externes (informations obtenues auprès d’autres compagnies, résultats d’études, …)

4

. Fichiers d’applications standards (e.g., Excel)

. D’autres documents (e.g., word, WWW)

Les wrappers et les chargeurs sont des programmes qui chargent les données des sources d’information dans l’entrepôt de données. Ces programmes sont responsables du chargement, de la transformation, du nettoyage et de la mise à jour des données des sources dans l’entrepôt. Une liste détaillée d’outils pour ces tâches peut être trouvée dans [Gree97]. Ces outils essayent d’automatiser ou fournissent une aide pour les tâches qui sont :

. L’extraction (accédant différentes bases de données sources)

. Le nettoyage (trouver et résoudre les inconsistances dans les données sources)

. La transformation (transformation entre différents formats de données, langages, etc.). Le chargement (chargement des données dans l’entrepôt). L’analyse (détection des valeurs non valides/inattendues). Le transfert de données à haut débit (important pour les gros entrepôts de données). Le test pour la qualité de données, correction et complétude. Analyse des méta données (pour supporter la conception d’un entrepôt de données)

2.1.2 Entrepôt de données et data marts

Le système de gestion de bases de données qui est utilisé pour l’entrepôt de données lui-même et les data marts doit être un système très performant, qui répond aux exigences en terme d’interrogations complexes exprimées par les clients. Les architectures suivantes sont utilisées pour l’entrepôt de données [Weld97] :

. Les systèmes de gestion de bases de données relationnels

. Les systèmes de gestion de bases de données super-relationnels

. Les systèmes de gestion de bases de données multidimensionnels

. Les systèmes de gestion de bases de données orienté-objets

Les systèmes de gestion de bases de données relationnelles sont plus flexibles quand ils sont utilisés avec une structure de données normalisée. Parce que les structures de données normalisées sont non redondantes, les relations normalisées sont utiles pour un travail opérationnel journalier. Dans un contexte OLAP, les requêtes concernent plusieurs structures et donc nécessitent plusieurs opérations de jointures sur une structure de données normalisée.

2.1.3 Les applications clients

5

L’OLAP est l’une des applications importantes pour les entrepôts de données. Des requêtes OLAP typiques scrutent de nombreuses relations, réalisent de nombreuses jointures et agrégations. Au contraire, les systèmes de gestion de bases de données, qui sont utilisés pour un travail opérationnel quotidien, appelés systèmes de traitement transactionnels en-ligne (OLTP), sont optimisés pour assurer un petit nombre de transactions et les requêtes utilisent des clés primaires et des indexes spécialisés. Alors que les systèmes OLTP stockent uniquement l’information courante, les entrepôts de données contiennent des données historiques et consolidées. Ces données sont utilisées par les gestionnaires pour trouver des tendances dans les marchés, et aident les gestionnaires dans la prise de décision. Les opérations typiques exécutées par les clients OLAP sont [CD97] :

. Roll-up (relever le niveau d’agrégation)

. Drill-down (diminuer le niveau d’agrégation)

. Slice et Dice (sélection et projection)

. Pivot (ré-orienter la vue multidimensionnelle)

Pour rendre les SGBDs plus utiles pour les applications OLAP, les vendeurs leur ont ajouté de nouvelles fonctions. Ces caractéristiques, dites super-relationnelles, comportent un support pour l’extension aux formats de stockage, et des schémas d’indexation spécialisés. Pour fournir des temps d’accès rapides aux applications OLAP, les données sont organisées selon un schéma en étoile (star) ou en flocon (snowflake).

Un schéma en étoile consiste en une table de faits centrale et plusieurs tables dimensions. Les mesures d’intérêt pour l’OLAP sont stockées dans la table des faits (e.g., ventes, stock). Pour chaque dimension du modèle multidimensionnel il existe une table (e.g., région, produit, temps). Cette table stocke les informations relatives aux dimensions.

6

Figure 3 : Schéma en étoile

La figure 3 est un exemple de schéma en étoile. La table ventes au centre de l’étoile est la table de faits avec les clés étrangères code géographie, code temps, code compte, et code produit vers les tables dimensions correspondantes. Les dimensions sont souvent organisées de façon hiérarchique. Chaque table dimension consiste en plusieurs attributs décrivant un niveau de dimension. Par exemple, la dimension produit est organisée dans une hiérarchie comportant les niveaux produit, catégorie de produit, et marque. La structure hiérarchique d’une dimension est particulièrement importante pour les opérations drill-down et roll-up. Chaque hiérarchie est représentée par un ou plusieurs attributs dans la table dimension. Les tables dimensions ont une structure dénormalisée. A cause des problèmes relatifs aux structures de données dénormalisées, comme la redondance, il peut être utile de créer un schéma en flocon. Ceci est fait en normalisant les tables dimensions du schéma en étoile. Un schéma en flocon correspondant au schéma en étoile de la figure 3 est donné figure 4. Par exemple, la table temps est maintenant divisée en trois nouvelles tables : temps, trimestre et mois.

Figure 4 : Schéma en flocon

Le modèle de données résultant peut être très complexe et difficile à comprendre pour un utilisateur final. Les vendeurs de SGBDs, comme Informix et Sybase,

7

tentent de cacher cette complexité derrière un moteur spécial pour OLAP. L’architecture résultant est appelée OLAP relationnel (ROLAP).

Les systèmes de gestion de bases de données multidimensionnelles sont plus appropriés pour les applications OLAP car le modèle de données multidimensionnel correspond mieux à la façon dont les utilisateurs OLAP appréhendent, visualisent et travaillent avec les données. L’OLAP nécessite l’analyse de gros volumes de données complexes et reliées entre elles, et la visualisation de ces données selon plusieurs perspectives [Kena95]. Les systèmes de gestion de bases de données multidimensionnelles (SGBDM) stockent les données dans des cubes n-dimensionnels. Chaque dimension représente une perspective. Par exemple, les données ventes d’une compagnie peuvent avoir les dimensions produit, région, et temps. Grâce à la façon dont les données sont stockées, il n’y a pas d’opérations de jointure nécessaires pour répondre aux requêtes qui retrouvent les données ventes par l’une de ces dimensions. Par conséquent, pour les applications OLAP, les SGBDM sont souvent plus performants que les SGBDR classiques [Coll96]. Un problème avec les SGBDM est que la restructuration est beaucoup plus coûteuse que dans les bases de données relationnelles. De plus, il n’y a pas actuellement de langages de définition et de requêtes standards pour le modèle de données multidimensionnel.

En pratique, le SGBDM est utilisé pour compléter une architecture d’entrepôts de données [Sahi96]. Il obtient ses données d’un entrepôt de données relationnel et les fournit aux applications OLAP.

Figure 5 : Un SGBDMD dans un environnement entrepôt de données

8

Comme le montre la figure 5, les requêtes ad-hoc sont envoyées directement à l’entrepôt de données, alors que les applications OLAP travaillent sur le modèle de données plus approprié du SGBDM.

Cette stratégie est aussi proposée par les vendeurs de bases de données multidimensionnelles comme Arbor Software [Arbo96] et Oracle [Orac97].

Comme il a été dit précédemment, OLAP est une application importante des entrepôts de données. Les autres applications clientes possibles sont :

. Rapports et outils d’interrogation

. Systèmes d’information géographiques (SIG)

. Fouille de données (Data-Mining)

. Systèmes d’aide à la décision (SAD)

. Systèmes d’information exécutifs (SIE)

. Statistiques

Les applications OLAP nécessitent un support pour les opérations spéciales rotate, slice, dice, roll-up, et drill-down d’un cube multidimensionnel. Ce support est fourni par les systèmes de bases de données multidimensionnelles et les serveurs OLAP relationnels.

3. Construction des entrepôts de données

Nous distinguons deux niveaux dans la construction des entrepôts de données. Le premier niveau correspond à la construction des sources de données opérationnelles, et l’entrepôt de données global. Le second niveau englobe tous les entrepôts de données locaux. La raison de cette distinction est qu’à chaque niveau, sont associées fondamentalement différentes étapes de traitement et difficultés techniques.

Au premier niveau, le processus de construction est décomposé en quatre étapes principales, qui sont : (1) extraction des données des sources de données opérationnelles, (2) transformation des données aux niveaux structurel et sémantique, (3) intégration des données, et (4) stockage des données intégrées dans le système cible. La figure 8 résume l’enchaînement de ces étapes de traitement.

Figure 8 : Etapes de traitement du premier niveau de construction d’un entrepôt de données.

9

Notez cependant que cette décomposition est seulement logique. L’ étape d’extraction et une partie de l’étape de transformation peuvent être groupées dans le même composant logiciel, tel qu’un « wrapper » ou un outil de migration de données. L’étape d’intégration est souvent couplée avec des possibilités de transformation de données riches dans un même composant logiciel, qui, habituellement réalise le chargement dans l’entrepôt de données. Toutes les étapes de traitement peuvent aussi être groupées dans un même logiciel, comme par exemple un système multibase. Quand les étapes d’extraction et d’intégration sont séparées, les données nécessitent d’être stockées entre les deux. Ceci peut être fait en utilisant un média par source ou un média pour toutes les sources. Une vue opérationnelle typique de ces composants est donnée par la figure 9. Les composants logiciels sont représentés par des rectangles. Les ellipses désignent des stockages intermédiaires des résultats de l’étape d’extraction/transformation. Toutes les données qui sont en entrée du composant intégration utilisent le même modèle de représentation de données. Finalement, un « wrapper » est associé à chaque source, fournissant ainsi une interface API à la source.

Figure 9 : Vue Opérationnelle des composants utilisés pour la construction d’entrepôts de données

Au second niveau, le processus de construction comporte trois étapes distinctes, qui sont : (1) l’extraction de données à partir d’une base de données (entrepôt de données local ou global), (2) calcul des données dérivées pour l’entrepôt de données local cible, et (3) stockage des résultats dans l’entrepôt de données local. L’étape d’extraction est un cas particulier de celle du premier niveau parce que les données de l’entrepôt sont stockées dans une base de données. A l’opposé, dans le premier niveau, l’extraction peut concerner des sources de données arbitraires, comme des fichiers par exemple. Le calcul des données dérivées est assez spécifique car il peut impliquer des requêtes complexes avec agrégats.

4. Vue conceptuelle multidimensionnelle des données

Les tables dans les bases de données relationnelles contiennent des enregistrements. Chaque enregistrement consiste en des champs (colonnes). Un

10

certain nombre de champs (clés) dans chaque enregistrement peut identifier de façon unique chaque enregistrement. A l’opposé, le modèle de données multidimensionnel est un tableau n-dimensionnel (parfois appelé hypercube). A chaque dimension est associée une hiérarchie de niveaux comme pays, région, ville, bureau. Sur l’exemple de la figure 6, les dimensions choisies sont Produit, Région et Mois.

Figure 6 : Les ventes comme une fonction de produit, temps, et géographie

Les mesures, qui sont aussi appelées variables ou métriques – comme ventes dans l’exemple, ou revenu, inventaire, etc. – dans un tableau multidimensionnel correspondent à des colonnes dans une table de base de données relationnelle. Les valeurs dans une colonne d’une table correspondent à des valeurs pour cette mesure dans un tableau multidimensionnel : une mesure est un point dans l’espace multidimensionnel. Dans notre exemple, une mesure des ventes du produit Cola, dans la région du nord, en janvier, est 13. Ainsi, une dimension agit comme un index pour identifier des valeurs dans un tableau multidimensionnel.

Si un membre d’une dimension est sélectionné, alors les dimensions restantes avec les membres sélectionnés, définissent un sous-cube. Si toutes les dimensions, sauf deux, ont un membre unique sélectionné, les deux dimensions restantes définissent une page (ou slice ou spreadsheet). Si toutes les dimensions ont un membre unique sélectionné, alors une cellule est définie. Les dimensions offrent une façon concise et intuitive pour organiser et sélectionner les données pour l’interrogation, l’exploration et l’analyse.

11

Des exemples de niveaux de dimensions pour l’agrégation de données dans un entrepôt de données sont : temporelle (années vs. mois), géographique/spatiale (e.g., Lyon vs. France), organisationnelle (Institut vs. Département), et physiques (voiture vs. moteur). La figure 7 donne quelques hiérarchies typiques.

Figure 7 : Exemples de hiérarchies de dimensions

Une valeur dans une cellule peut représenter une mesure agrégée calculée à partir de données spécifiques à un niveau donné inférieur de la même dimension. Par exemple, la valeur 13 pour les ventes de janvier, peut avoir été obtenue en faisant la somme des valeurs des ventes hebdomadaires (ou quotidiennes).

4.1 Opérations impliquant les dimensions

La navigation est un terme utilisé pour décrire le processus employé par les utilisateurs pour explorer un cube de façon interactive, habituellement en utilisant un client OLAP graphique connecté à un serveur OLAP. Le processus utilisateur interactif pour une requête multidimensionnelle est appelé « slicing » et « dicing ». Le résultat d’une requête multidimensionnelle est soit une cellule, un « slice » bi-dimensionnel, ou un sous-cube multidimensionnel. Les opérations sur les données multidimensionnelles les plus fréquentes dans les systèmes commercialisés sont :

Agrégation (ou consolidation, ou Roll-up) : l’agrégation concerne le calcul des relations pour une ou plusieurs dimensions. Par exemple, les centres de ventes peuvent être agrégés en zones et les zones en régions; l’utilisateur peut être intéressé par le total des ventes, par des pourcentages du total, etc.

12

Roll down (ou Drill down, ou Drill through) : l’utilisateur navigue à travers les niveaux de données allant du plus haut niveau de consolidation au plus bas niveau de consolidation (ou données détaillées).

Screening (ou sélection, ou filtrage) : un critère est évalué sur les données ou les membres d’une dimension dans le but de restreindre l’ensemble des données retrouvées. Comme exemples de sélection, on peut s’intéresser aux dix meilleurs vendeurs par chiffre d’affaire, aux données de la région Est uniquement et à tous les produits avec une marge supérieure à 20 pourcent.

Slicing : sélectionner toutes les données satisfaisant une condition au regard d’une dimension particulière. Un slice est un sous ensemble d’un tableau multidimensionnel correspondant à une valeur individuelle pour un ou plusieurs membres des dimensions qui ne sont pas dans le sous ensemble.

Scoping : restriction de la vue des objets d’une base de données à un sous ensemble spécifique. D’autres opérations, comme la mise à jour ou la recherche, affecteront seulement les cellules du sous ensemble spécifié. Par exemple, cette opération permet aux utilisateurs de retrouver ou de mettre à jour uniquement les valeurs des ventes pour le premier trimestre dans la région Est (si ce sont les seules données qu’ils souhaitent recevoir).

Pivot (ou Rotate) : pour changer l’orientation (par rapport aux dimensions) d’un cube, pour analyser les données en utilisant un niveau de dimension particulier comme variable indépendante. Par exemple, la rotation peut consister à interchanger les lignes et les colonnes.

4.2 Modèles de données

Etant donnée la popularité des systèmes de gestion de bases de données relationnelles, on est tenté de construire un outil OLAP comme un niveau sémantique au dessus d’un SGBD relationnel [Coll96]. Ceci s’appelle le OLAP Relationnel (ROLAP ). C’est juste une extension du modèle relationnel dans lequel les opérations sur les données multidimensionnelles sont traduites en opérations relationnelles standards. Ce niveau fournit une vue multidimensionnelle, le calcul de données consolidées, les opérations de drill down, et la génération d’ordres SQL appropriés pour accéder aux données.

Une autre approche est l’OLAP Multidimensionnel (MOLAP). C’est un modèle de données dédié dans lequel les données multidimensionnelles et les opérations sont mises en correspondance directement.

4.2.1 Le Modèle de données ROLAP

13

Un outil basé sur ROLAP possède un générateur SQL puissant, capable de créer des select multi-passes et/ou des sous-requêtes corrélées; il est suffisamment puissant pour créer des classements non triviaux et des comparaisons; il génère des ordres SQL optimisés pour la base de données cible, comprenant des extensions SQL, en utilisant, par exemple, les ordres Group By, sous-requêtes corrélées, Having, Create View et Union. Il fournit un mécanisme pour décrire le modèle à travers les méta-données, et utilise les méta-données en temps réel pour construire des requêtes.

Au centre de la technologie ROLAP se trouve la modélisation des dimensions. Il s’agit d’organiser l’information en deux types de structures de données : mesures, ou données numériques (par exemple les ventes), qui sont stockées dans des tables dites tables des faits; et des dimensions, qui sont stockées dans des tables satellites et sont reliées à la table des faits. Les systèmes ROLAP doivent fournir des techniques capables de supporter et d’optimiser les trois fonctions suivantes :

Dénormalisation : une conception de base de données qui consiste à stocker les données dans des tables, minimisant le nombre de jointures (consommatrices de temps quand une requête est exécutée), et réduisant le nombre d’enregistrements qui doivent être analysés;

Consolidation : une technique pour agréger les informations par avance, évitant ainsi de le faire à l’exécution;

Partitionnement : la possibilité de décomposer une table de faits volumineuse en plusieurs petites tables, améliorant ainsi le temps de réponse aux requêtes et aussi aux restorations et rechargement de l’entrepôt de données.

Les ’’Data marts’’ sont des collections, probablement sous forme de vues matérialisées dérivées d’un entrepôt de données, où les agrégations et les partitions sont implantées selon les besoins des utilisateurs cibles, de telle sorte que les requêtes puissent être mieux optimisées.

Un argument à l’encontre du modèle ROLAP porte sur les faibles performances résultant d’un grand nombre de jointures [Fink96]. C’est la raison pour laquelle les ’’Data Marts’’ sont introduits dans ROLAP comme des bases de données spéciales dénormalisées. Les tables dénormalisées sont des tables qui sont pré-jointes (i.e., toutes les tables sont combinées en une seule table), pour éviter les jointures consommatrices de temps. Malheureusement, cette solution présente plusieurs inconvénients liés à la performance et aux ressources système. La dénormalisation produit des tables volumineuses car les données sont redondantes. Les requêtes d’analyse en-ligne s’adressent ainsi à des bases de données volumineuses conduisant à des calculs aussi coûteux, sinon plus, que les jointures. De plus, la dénormalisation génère des valeurs manquantes dans la base de données.

14

Une approche intéressante qui permet de remédier à ces problèmes d’utilisabilité dans le modèle relationnel consiste à stocker les données dans une structure en étoile (’’star’’), qui tente d’offrir une structure multidimensionnelle au dessus du modèle relationnel bi-dimensionnel. Le modèle en étoile simplifie le modèle logique en organisant les données plus efficacement pour le traitement analytique.

4.2.2 Le modèle de données MOLAP

Plutôt que de stocker les informations comme des enregistrements, et les enregistrements dans des tables, les bases de données multidimensionnelles (BDM) basées sur MOLAP stockent les données dans des tableaux. Les BDMs sont capables de fournir des performances remarquables quant au traitement des requêtes, qui sont obtenues en anticipant la manière avec laquelle les données seront accédées. Parce que l’information, dans une BDM, est stockée avec une granularité plus coersive que les bases de données relationnelles classiques, l’index est plus petit et très souvent réside en mémoire. Une fois l’index parcouru, peu de pages sont considérées. Certains outils sont conçus pour placer ces pages dans des mémoires partagées, améliorant ainsi la performance. Un autre aspect intéressant des BDMs est que l’information est physiquement stockée dans des tableaux : Ceci veut dire que les valeurs dans le tableau peuvent être mises à jour sans modifier l’index. Un inconvénient de cette architecture est que même des changements mineurs affectant la structure des dimensions nécessitent une réorganisation complète de la base de données.

Un avantage du MOLAP par rapport au ROLAP est qu’il permet des opérations OLAP dédiées. Avec un serveur BDM, il est facile de pivoter l’information (puisque toute l'information est stockée dans un hypercube multidimensionnel), de réaliser des drill down sur les données, et d’effectuer des calculs complexes impliquant des cellules de structure multidimensionnelle. Il n’est pas nécessaire d’avoir recours à des jointure complexes, à des sous-requêtes, et à des unions. Ces aspects n’existent pas car les données sont stockées comme des blocs multidimensionnels au lieu d’une structure de table disséquée.

5. Interrogation des entrepôts de données

Un entrepôt de données peut être vu comme une collection de vues matérialisées résultant de l’interrogation de sources de données. En général, les entrepôts de données sont structurés de façon hiérarchique : il y a différents niveaux de vues, où les vues d’un niveau donné sont dérivées de celles des niveaux au-dessous. Les vues dans un entrepôt de données partagent des caractéristiques avec les requêtes utilisateur, et donc les calculer pose des problèmes similaires. Pour cette raison,

15

nous discuterons les traitements de requêtes dans une perspective la plus générale possible, couvrant toutes les parties d’une architecture d’entrepôt de données.

Un entrepôt de données ne contient pas uniquement des données décrivant une entreprise ou autre organisation, mais aussi des données auxiliaires, appelées méta-données décrivant la structure interne et les opérations de l’entrepôt de données. Explorer et interroger les méta-données est une activité importante pour chaque utilisateur final, qui doit connaître quels sont les niveaux d’information disponibles avant d’interroger les données. De plus, les méta-données sont importantes pour les administrateurs pour gérer l’entrepôt. Finalement, les opérations du système lui-même sont spécifiées et contrôlées à travers les méta-données.

Cependant, contrairement aux données de bases, il n’y a pas de standards quant à la représentation des méta-informations. En particulier, il n’y a pas de consensus sur le format et le contenu des requêtes portant sur les méta-données. De ce fait, nous nous restreignons ici à des requêtes portant sur le niveau données.

Dans la suite, nous supposons une architecture simplifiée d’entrepôt de données, qui consiste en un noyau, un front end et un back end.

Requêtes au niveau Back End : le back end connecte l’entrepôt de données aux sources de données opérationnelles. Le back end accède aux sources, habituellement à des intervalles de temps réguliers, pour charger les données dans l’entrepôt. Le chargement implique le ’’nettoyage des données’’. Dans le cas le plus simple, le nettoyage n’est rien d’autre que l’association de codes cryptés apparaissant dans les sources à des chaînes plus lisibles. Cependant, des techniques plus élaborées peuvent entraîner des accès à des bases de données qui contiennent des informations supplémentaires nécessaires à la résolution des ambiguïtés dans les sources. Le chargement peut également entraîner le calcul d’agrégats des données sources, comme la somme (sums), ou des agrégats plus ou moins complexes.

Requêtes au niveau Front End : le front end contient les outils avec lesquels les utilisateurs finaux accèdent aux données de l’entrepôt. Il existe une multitude de moyens mis à la disposition des utilisateurs pour retrouver l’information : les gestionnaires qui généralement se contentent d’un bref coup d’œil sur une interface graphique, les assistants qui inspectent la dernière version d’un rapport complexe, les analystes qui interroge un cube de données avec un outil de spécification de requêtes ad-hoc, les personnels systèmes qui construisent de telles interfaces et définissent la perspective sous laquelle l’entrepôt de données peut être perçu à travers les outils d’interrogation.

Requêtes au niveau noyau : le noyau consiste en un gestionnaire d’objets et de méta-données. Dans les systèmes OLTP, les schémas sont conçus de telle sorte

16

qu’il y ait un minimum de redondance. A l’opposé, les entrepôts de données, sont conçus de façon à présenter une certaine redondance : certaines données sont des vues sur d’autres données, et donc redondantes d’un point de vue logique. La redondance peut être inhérente à l’architecture globale. Elle peut être aussi locale à un composant où des résultats pré-calculés sont stockés pour améliorer le temps de réponse de certaines requêtes supposées fréquentes.

5.1 Transactionnel vs. requêtes sur un entrepôt de données

Les requêtes sur un entrepôt de données se distinguent des requêtes dans les systèmes OLTP par leur fréquence et les volumes de données sur lesquels elles portent. Les requêtes OLTP sont des parties de transactions. Elles concernent uniquement un petit nombre de tuples, mais apparaissent fréquemment : e.g., 50 transactions par seconde sont possibles dans une base de données d’une compagnie aérienne. Au contraire, les requêtes dans un entrepôt de données à tous les niveaux peuvent concerner des gigabytes de données, mais avec une moindre fréquence.

C’est une caractéristique, de presque toutes les requêtes dans les entrepôts de données, de porter sur des ensembles volumineux de données. Cependant, ceci ne veut pas dire qu’elles produisent également des sorties volumineuses. Les résultats volumineux sont typiques des requêtes qui correspondent au processus de chargement. Dans une telle optique, de telles requêtes sont exécutées en batch sur une base de données transactionnelle.

Les utilisateurs, au contraire, ne sont pas intéressés par des sorties gigantesques. Ils veulent réduire de gros volumes à un petit nombre de paramètres caractéristiques, pour lesquels ils ont besoin d’agrégation.

Requêtes pré-formulées et requêtes ad-hoc : dans un entrepôt de données, nous distinguons deux modes d’interrogation : (1) les requêtes pré-formulées ont été spécifiées par l’administrateur et exécutées par un utilisateur final. Elles peuvent être sujettes à une certaine paramètrisation, mais elles sont principalement fixes. Typiquement, toutes les requêtes exécutées au niveau back end et au niveau du noyau entrent dans cette catégorie. Les interfaces graphiques fournissant une vue gérable d’une organisation et les rapports sont basées sur les requêtes pré-formulées ; (2) l’analyste interroge un entrepôt de données dans un mode ad-hoc. Dans une session d’analyse, il formule une série de requêtes corrélées. Par exemple, afin de connaître comment un événement particulier influence la performance de la compagnie entière, il formulera des requêtes avec des niveaux de généralisation qui concerneront de plus en plus de données.

5.2 Requêtes multidimensionnelles

17

Parmi les requêtes multidimensionnelles, on peut distinguer celles qui retrouvent des données à partir des dimensions, et celles qui retrouvent des faits [Kim96].

Interroger les dimensions : avant d’interroger les informations factuelles d’un data cube, un analyste explorera en premier les dimensions du cube. Il utilisera un outil d’interrogation pour prendre connaissance d’une ou de plusieurs valeurs des attributs d’une dimension, probablement en restreignant les autres attributs. Par exemple, il peut interroger la dimension produit pour connaître les valeurs de l’attribut marque quand l’attribut catégorie est restreint à produit_laitier. Si le data cube est implanté sur une base de données relationnelle selon le modèle en étoile, alors une telle requête entraînera juste des projections et des sélections. S’il est implanté comme un flocon, alors la requête entraînera la jointure des tables de la dimension en question.

Bien que les tables des dimensions sont plus petites que les tables des faits, elles peuvent s’avérer volumineuses dans certains cas. La dimension client dans un entrepôt de données d’une compagnie téléphonique peut contenir plusieurs millions de tuples. De ce fait, les requêtes d’exploration, bien que simples d’un point de vue structurel, requièrent des optimisations pour pouvoir les exécuter efficacement.

Le but de l’exploration est d’identifier des sous-ensembles intéressants d’une dimension, appelés des groupes contraints car ils satisfont certaines contraintes sur la dimension, et les décrire par des requêtes. Avec un outil d’interrogation on peut nommer de telles requêtes et les stocker. Dans un environnement coopératif, les groupes contraints peuvent être rendus accessibles par les utilisateurs. Dans ce cas, il y a nécessité d’organiser de nombreuses requêtes et de spécifier leur sens. Des outils offrent cette possibilité en permettant, par exemple, d’attacher des commentaires aux requêtes, mais n’offrent aucune possibilité de raisonnement.

D’autres sous ensembles d’une dimensions, appelés groupes comportementaux ne se définissent pas uniquement en termes des attributs d’une dimension, mais impliquent également des faits et des restrictions sur d’autres dimensions. Un exemple serait le groupe des produits qui se vendent très bien durant les quatre semaines précédant Noël. Ce groupe est défini non seulement en terme de la dimension produit mais aussi en termes des ventes et du temps. Comme pour les groupes contraints, il y a aussi nécessité de gérer des requêtes définissant des groupes comportementaux.

Interroger les informations factuelles : l’objectif principal dans l’interrogation des cubes de données est de produire des rapports. Un rapport est une table dont les dimensions sont étiquetées avec des valeurs d’attributs et dont les faits sont calculés en agrégeant des faits du cube impliqué. Souvent les faits ne sont pas de

18

simples agrégats comme count et sum, mais sont des comparaisons entre différents agrégats. De plus, un rapport peut contenir d’autres agrégats comme des sous-totaux et des totaux, et des valeurs exceptionnelles peuvent être mises en évidence.

Pour calculer un rapport, il existe deux possibilités : La première est de traduire la spécification du rapport dans SQL. Ceci pose des problèmes quand des comparaisons sont à considérer. Comparer les ventes du mois courant avec celles du mois précédent nécessite d’accéder à la table des faits au moins deux fois. Dans SQL, ceci peut être accompli soit avec un self-join, ou avec des sous requêtes corrélées comme dans SQL-2. Cependant, les deux options conduisent à un code difficile à lire et pour lequel les optimiseurs de requêtes tendent à produire des plans d’exécution inefficaces. La deuxième possibilité est de décomposer la spécification du rapport en un nombre de requêtes SQL relativement simples, une pour chaque comparaison, et laisser l’outil d’interrogation assembler les résultats dans le rapport. Cette stratégie véhicule plusieurs avantages. Comme les requêtes ne sont pas trop complexes, essentiellement des requêtes select-project-join avec l’agrégation, elles peuvent être exécutées efficacement par des SGBDs. De plus, une édition incrémentale du rapport est possible, puisque après une modification, seules les requêtes qui sont affectées par la modification sont recalculées.

Les rapports peuvent également être spécifiés et calculés par des serveurs OLAP dédiés. Les serveurs OLAP sont spécialisés dans le stockage de cubes de données et supportent les requêtes multidimensionnelles sur ces cubes. Ils contiennent non seulement les cubes de bases, mais aussi des agrégats pré-calculés pour les attributs des dimensions. Ainsi, ils garantissent des temps de réponse raisonnables pour des requêtes qui nécessitent l’agrégation. Cependant, et souvent, ils manquent de flexibilité pour la formulation de requêtes plus élaborées.

Extensions de SQL : Kimball souligne les limites de SQL quand les requêtes d’aide à la décision sont à spécifier [Kim96]. De telles requêtes requièrent des agrégations plus sophistiquées que ceux disponibles dans SQL, e.g., rank, n-tile, moving-avg, ou moving-sum. De plus, pour les requêtes d’analyse, les comparaisons sont essentielles. Si elles sont exprimées en SQL ou si un code SQL est produit par un outil d’interrogation, elles sont exécutées par des passes séquentielles multiples. Ceci peut être évité si SQL est étendu par une syntaxe spéciale pour les comparaisons, qui peuvent être évaluées plus efficacement [CR96].

Pour la spécification des groupes de requêtes agrégats, les opérateurs rollup et cube ont été introduits comme des extensions à SQL dans [GBLP97]. Chaque opérateur a comme argument une relation et une liste d’attributs. Il spécifie un ensemble de requêtes reliées entre elles et qui calculent des agrégats à travers des groupements.

19

L’opérateur rollup agrège à travers des groupements où chaque groupement est plus compact que ses prédécesseurs. Par exemple, rollup pour la liste des attributs année, magasin, et prix produit d’abord une agrégation à travers le groupement par tous les attributs, ensuite par année et magasin, et finalement par année uniquement. Une requête rollup peut être calculée efficacement en dérivant le résultat pour un groupement à partir du résultat pour son prédécesseur.

L’opérateur cube réalise des groupements par chaque sous ensemble d’attributs de la liste. Ainsi, s’il y a n attributs, cube spécifie des groupements. Les groupements forment un treillis booléen qui décrit ce qui peut être calculé et à partir de quoi. Contrairement à rollup, il n’est pas facile de déterminer la stratégie la plus efficace pour calculer les agrégats. Agarwal et al. rapportent des analyses empiriques sur les différentes stratégies de calcul de requêtes avec l’opérateur cube [AAD+96].

6. OLAP et bases de données statistiques

Les deux domaines traitement analytique en-ligne (OLAP) et bases de données statistiques (BDS) traitent d’ensembles de données multidimensionnelles, et ces deux domaines s’intéressent à la production de résumés statistiques moyennant les dimensions des ensembles de données.

6.1 Exemples de bases de données statistiques et de bases de données OLAP

6.1.1 Représentation de données dans les BDS

Considérons les données représentées sur la figure 10 comme une table 2-D. Cette figure montre la répartition, selon les types de baccalauréats, des succès à cet examen dans la région lyonnaise (les nombres sont fictifs). La répartition est faite par sexe, par année et par spécialité. Cette forme de représentation de tables multidimensionnelles est très populaire dans le domaine des statistiques. Plusieurs remarques s’imposent :

1. Par nécessité, plus d’une dimension doit être représentée par les lignes et les colonnes si plus de deux dimensions existent dans l’ensemble de données. Ceci est réalisé en sélectionnant un ordre arbitraire pour les dimensions dans les lignes et les colonnes. Sur la figure 10, les lignes représentent les deux dimensions « sexe » et « année », qui sont ordonnées (sexe puis année) de façon arbitraire.

2. Les colonnes dans cet exemple ne représentent pas deux dimensions, bien que leur forme ressemble aux lignes. « Type Bac » et « Spécialité » représentent une relation hiérarchique entre les instances de « Type Bac » (e.g., Général) et les

20

instances de « Spécialité » (e.g., « Sciences »). On se réfère à cette structure par « hiérarchie de classification ».

3. Le label « Baccalauréat à Lyon » représente la mesure résumée pour cet ensemble de données, mais il dit aussi que cet ensemble de données admet une dimension supplémentaire « ville » où l’instance sélectionnée est le singleton « Lyon ».

4. Il y a une fonction d’agrégation impliquée par cet ensemble de données pour d’eventuels résumés (à travers « Sexe » ou « Spécialité »). Dans ce cas la fonction d’agrégat est « sum ». Notons qu’alors que « sexe » et « année » est un seul niveau d’agrégation, l’agrégation à travers « Spécialité » peut être réalisée au niveau « Type Bac » ou au niveau de toutes les spécialités et tous les types de baccalauréats. Ceci grâce à la structure hiérarchique de classification.

Pour résumer, cet ensemble de données admet la structure conceptuelle suivante :

Mesure de résumé : BaccalauréatFonction de résumé : SumDimensions : Sexe, Année, Spécialité, ville=LyonHiérarchie de classification : Type Bac Spécialité

Figure 10 : Représentation de données statistiques en 2-D

6.1.2 Un exemple OLAP utilisant le modèle data cube

Sur la figure 11 nous montrons un exemple typique d’une base de données, représentée comme un cube multidimensionnel. Evidemment, cette représentation graphique peut être utilisée seulement pour un nombre de dimensions inférieur ou égal à 3. Mais elle est utile pour des besoins d’illustration. Cet exemple de data cube contient la quantité vendue pour une chaîne de magasins particulière, par produit, par magasin et par jour. Nous notons :

21

1. La dimension « emplacement magasin » admet une hiérarchie naturelle. « emplacement magasin » a deux composantes : « ville » et « numéro magasin ». Puisque les magasins sont organisés selon la ville où ils sont implantés, la hiérarchie ville magasin existe. Si les numéros de magasins ne sont pas globalement uniques, alors on a besoin de concatener ville et numéro de magasin pour la rendre unique. Au regard de la terminologie des modèles ER, on peut dire qu’il existe une « ID dépendance » entre magasins et la ville.

2. La dimension « jour » est un autre exemple de hiérarchie de classification. Etant donné que jour est identifié par son mois et son année (e.g., 17 novembre 1999), alors il est ID dépendant de mois (novembre, 1999) qui à son tour est dépendant de l’année (1999). Ainsi, il peut être traité comme une hiérarchie de classification à 3 niveaux pour les besoins de consolidation aux niveaux mois et année.

3. La mesure « quantité vendue ».

Pour résumer, pour cette base de données OLAP, nous avons la structure conceptuelle suivante : Mesure de résumé : quantité vendueFonction de mesure : SumDimensions : produit, emplacement magasin, jourHiérarchie de classification : ville magasinHiérarchie de classification : année mois jour

Comme on peut le constater, d’un point de vue structure conceptuelle, les exemples de BDS et OLAP ont exactement les mêmes composants : une mesure, une fonction, une ou plusieurs dimensions, zéro ou plusieurs hiérarchies de classification. Il est évident que l’exemple OLAP peut être représenté moyennant la représentation 2-D des BDS, et l’exemple de BDS sous forme d’un cube de données.

Il est facile d’étendre ce modèle pour avoir plusieurs mesures associées au même ensemble de données à travers les mêmes dimensions (comme par exemple « population et revenu moyen par département, par année, par sexe, et par race »). Dans la littérature BDS, on appelle ceci « objet statistique complexe ».

6.2 Domaines d’applications

Le domaine des BDS est essentiellement motivé par des bases de données socio-économiques, qui sont essentiellement le domaine des statisticiens. Comme

22

exemples de domaines d’applications, nous pouvons citer les données de recensement, les données économiques (ventes et revenus des entreprises), ressources naturelles (niveaux d’eau dans les barrages, exploitation du bois dans les forets, etc.). Le domaine des OLAP est, quant à lui, dirigé par des applications de commerce, et leur analyse pour un besoin d’aide à la décision. Des exemples d’applications sont l’analyse des ventes au détail dans les magasins, gestion de stock, etc. C’est la raison pour laquelle OLAP est considéré comme un composant des possibilités des entrepôts de données. L’objectif principal d’un entrepôt de données est de collecter et d’analyser l’information pour prendre des décisions. Les décideurs ne sont pas nécessairement des statisticiens, mais plutôt des gestionnaires commerciaux.

Figure 11 : Une représentation data cube de données OLAP

De ces exemples, il apparaît que les BDS et les bases de données OLAP traitent de problèmes similaires. Cependant, chaque domaine a mis l’accent sur des aspects différents. La littérature BDS s’est focalisée sur le traitement des structures de classification multi-niveaux complexes, alors que la littérature OLAP suppose des structures simples et élégantes. Certaines BDS se sont fortement focalisées sur les dimensions région, spatiale et géographique, alors que dans certaines bases de données OLAP, l’accent est mis sur les dimensions temporelles. Une autre différence est que la littérature OLAP traite de l’efficacité des accès à des gygabytes de données (pour satisfaire le caractère « en-ligne » des OLAP), alors que la littérature BDS s’est concentrée sur d’autres aspects, comme la modélisation conceptuelle.

6.3 Modélisation conceptuelle – représentation des structures de données

23

Nous décrivons dans ce qui suit 3 modèles utilisés pour les BDS et les OLAP, à savoir : (1) les modèles à base de graphes, (2) les modèles tabulaires, et (3) le modèle data cube.

6.3.1 Modèles à base de graphes

Le modèle graphique, exhibé par la figure 12 pour la table 2-D de la figure 10 montre les éléments du modèle graphique. Il y a 3 types de noeuds : les S-noeuds pour les attributs résumés, les X-noeuds pour le produit croisé représentant la multidimensionnalité, et le C-noeud pour représenter l’attribut catégorie (qui correspond à la classification). Notons qu’un C-noeud au dessus d’une collection d’autres C-noeuds représente un niveau de la structure de classification hiérarchique, et ainsi appelé hiérarchie catégorie.

Figure 12 : Un modèle graphique pour les données statistiques

Cette représentation comporte plusieurs avantages comparée à la représentation tabulaire 2-D : (1) les dimensions n’ont pas à être partitionnées en celles qui vont dans les colonnes et celles qui vont dans les lignes, (2) cette représentation est insensible à la permutation des noeuds, (3) la hiérarchie de classification est explicite, et donc un attribut catégorie de niveau supérieur (comme «Type Bac») ne peut pas être confondu avec une dimension de l’ensemble de données statistiques, et (4) il est possible de représenter convenablement un nombre raisonnable de dimensions sur un seul écran.

Néanmoins, Cette représentation possède certains problèmes dans les applications réelles quand il est question de représenter des ensembles de données complexes. Un des problèmes est que dans le cas où le nombre de valeurs d’un attribut catégorie est important (e.g., 50 villes), il devient difficile de les représenter convenablement à l’écran. Un autre problème, plus important, est que les noeuds

24

intermédiaires d’une hiérarchie de catégories ont deux rôles : (1) représenter la valeur de la catégorie du noeud au dessus, (2) représenter le nom de l’attribut catégorie pour les noeuds au dessous.

6.3.2 Modèle tabulaire

La figure 13 montre la même table 2-D que celle de la figure 10 mais nous insérons deux colonnes qui donnent un récapitulatif sur les lignes. Comme on peut le voir, une colonne « total » est associée au type de baccalauréat « professionnel ». Des colonnes similaires pour les autres types de baccalauréats existent. Les inconvénients de cette représentation tabulaire rejoignent ceux des modèles à base de graphes.

Une autre représentation tabulaire découle de la popularité du modèle relationnel. L’avantage de cette représentation est sa familiarité et le fait qu’elle peut être raisonnablement implantée sur un schéma relationnel, et également la flexibilité de l’intégrer avec d’autres données dans le même modèle. Cependant, il y a plusieurs problèmes avec cette représentation, comme : (1) il n’y a pas de sémantique associée à une table relationnelle pour distinguer entre catégorie et attribut résumé, (2) il n’y a pas de distinction entre les attributs associés à la hiérarchie de classification et les dimensions.

Une représentation relationnelle qui résoud partiellement ces problèmes et d’autres est utilisée par une compagnie OLAP [MicroStrategy], en utilisant le modèle en étoile (« star model »).

Figure 13 : Table statistique avec des marges

6.3.3 Modèle data cube

Un exemple de modèle data cube était donné figure 10. Cette représentation graphique est utilisée dans les papiers OLAP (e.g., [GB+96]) et les produits OLAP multidimensionnels (e.g., [Arborsoft]).

25

Alors que l’espace multidimensionnel est clairement représenté dans ce modèle data cube, la structure des dimensions n’est pas bien présentée. Ce n’est qu’à travers des labels comme lycée, ville, département, etc. associés aux dimensions que l’on peut supposer que la dimension a une structure et des données.

Mis à part ces insuffisances, ce concept de data cube est utile dans la visualisation de certaines opérations, comme le slice et le dice. La table de la figure 14 donne la correspondance entre les termes utilisés dans les domaine de BDS et OLAP.

BD Statistiques OLAP

Attribut de catégorie DimensionHiérarchie de catégorie Hiérarchie de dimensionValeur de catégorie Valeur de dimensionAttribut synthèse MesureObjet statistique Data cubeProduit croisé MultidimensionnalitéTable résumé Table/data cube

Figure 14 : correspondance entre les termes dans les BDS et OLAP

6.4 Opérations

6.4.1 Opérateurs statistiques

Dans la littérature BDS, il existe plusieurs approches pour définir les opérateurs qui reflètent le modèle structurel de l’objet statistique. Une approche consiste à utiliser le cadre relationnel, mais à enrichir le modèle structurel avec une sémantique relative aux propriétés de l’objet statistique, particulièrement : la multidimensionnalité et la hiérarchie de classification. Dans [MRS92] des opérateurs qui correspondent aux opérateurs de l’algèbre relationnelle « select », « project », « union », et « aggregate » étaient définis. Ils étaient nommés « S-select », « S-project », etc.

6.4.2 Opérateurs OLAP

Les opérateurs définis dans le domaine OLAP utilisent l’image graphique du data cube. Ainsi, un slice est une coupe à travers l’espace multidimensionnel, un dice est la sélection sur certaines valeurs des dimensions, roll-up (appelé aussi consolidation) est le résumé au dessus d’un niveau de la hiérarchie de classification, et « drill-down » est l’opération opposée.

26

La table de la figure 15 résume la correspondance entre les opérateurs des BDS et ceux des OLAP.

BD Statistiques OLAP

S-projection SliceS-selection DiceS-aggregation Rool-upS-desagregation Drill-downS-union ---

Figure 15 : Correspondance entre les opérateurs des BDS et ceux des OLAP

Bibliographie

[AAD+96] S. Agrawal, R. Agrawal, P. Deshpande, A. Gupta, J. Naughton, R. Ramakrishnan et S. Sarawagi. On the computation of multidimensional aggregates. In Proceedings of the 22nd Interational Conference on Very Large Data Bases, Bombay (India), September 1996.

[Arbo96] Arbor Software Corporation. Arbor Essbase. http://www.arborsoft.com/essbase.html, 1996.

[Arborsoft] Relational OLAP : Expectations & Reality. An Arbor Software White Paper, http://www.arborsoft.com/papers/rolapTOC.html.

[CD97] S. Chaudhuri and U. Dayal. An Overview of Data Warehousing and OLAP Technology. SIGMOD Record, Vol. 26, No. 1, March 1997.

[Coll96] G. Colliat. OLAP, Relational, and Multidimensional Database Systems. SIGMOD Record, Vol. 25, No. 3, Septembre 1996.

[CR96] D. Chatziantoniou and K. Ross. Querying multiple features in relational databases. In Proceedings of the 22nd Interational Conference on Very Large Data Bases, Bombay (India), September 1996.

[Fink96] Richard Finkelstein. Understanding the need for On-line analytical servers. White paper from Arbor Software, Inc.

[GBLP97] J. gray, A. Bosworth, A. Leyman et H. Pirahesh. Data cube : A relational operator generalizing group-by, cross-tabs, and sub-totals. Data Mining and Knowledge Discovery Journal, 1(1), 1997.

27

[GB+96] Jim Gray, Adam Bosworth, Andrew Layman and Hamid Pirahesh. Data Cube : A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Total. In Proceedings of the International Conference on Data Engineering (ICDE’96), 1996.

[Gree97] L. Greenfield. Data Warehousing Information Center. http://pwp.starnetinc.com/larryg/index.html.

[Inmo96] W. H. Inmon. Building the Data Warehouse. John Wiley and Sons, 1996.

[Kena95] Kenan Technologies. An Introduction to Multidimensional Database Technology. http://www.kenan.com/acumate/mddb_toc.htm, 1995.

[Kim96] Ralph Kimball. The data warehouse toolkit. John Wiley and Sons, 1996.

[MicroStrategy] The Case For Relational OLAP, A White Paper Prepared by MicroStrategy, Incorporated. http://www.strategy.com/dwf/wp_b_a1.htm.

[MRS92] Leonardo Meo-Evoli, Fabrizio L. Ricci and Arie Shoshani. On the Semantic Completeness of Macro Data Operators for Statistical Aggregation. In Proceedings of the 6th International Conference on Statistical and Scientific Database Management (SSDBM) 1992, pp. 239-258.

[Orac97] Oracle Corporation. Oracle Express Server. http://www.oracle.com :81/products/olap/html/oes.html, 1997.

[Sahi96] Kenan Sahin. Multidimensional Database Technology and Data Warehousing. http://www.kenan.com/acumate/byln_mdw.htm, 1996.

[Weld97] Jay-Louise Weldon. Warehouse Cornerstones. Byte, pp. 85-88.

Autres références :

Le site http://www.cs.toronto.edu/~mendel/dwbib.htmlhttp://www.cs.toronto.edu/~mendel/dwbib.html recense et donne accès à tous les travaux réalisés par des chercheurs universitaires et d’autres centres de recherche (IBM, Microsoft, AT&T, etc.) académiques sur les entrepôts de données et OLAP. On y trouve 132 articles.

Le site http://www.cio.com/research/data/http://www.cio.com/research/data/ Est consacré à des travaux portant sur la vulgarisation de ces nouvelles technologies d’aide à la décision et à leur croisement avec d’autres technologies comme le datamining, le commerce éléctronique, Internet, etc.

28

Les sites http://www.intelligententerprise.com/http://www.intelligententerprise.com/, http://www.datawarehousingonline.com/http://www.datawarehousingonline.com/, et http://www.dwinfocenter.org/http://www.dwinfocenter.org/ sont, quant à eux, consacrés à l’utilisationsont, quant à eux, consacrés à l’utilisation effective de ces technologies au sein des entreprises. On y trouve des dizaines eteffective de ces technologies au sein des entreprises. On y trouve des dizaines et des dizaines d’articles.des dizaines d’articles.

29