Projet IDAPA

Accueil > Bases de données relationnelles et indexation du contenu > Rapport - Partie 1

Rapport - Partie 1

Introduction + Etude des entrepôts de données

vendredi 6 février 2009, par Yoann Moreau

La première partie du rapport (1/3) comprend :

- Une introduction présentant globalement le travail effectué durant le semestre

- Le descriptif de l’étude réalisée au début du semestre concernant la définition d’un entrepôt de données (du cube), du principe OLAP, et la correspondance avec les objectifs du projet.

Cela mènera ensuite à l’étude de ce qui est attendu pour cette partie du projet, et des difficultés techniques impliquées.

1. Introduction

L’objectif de cette partie est de mettre en place un serveur d’entrepot de données utilisé pour le scoring réalisé par les autres parties du projet. Cet entrepot de données devra être optimisé spécialement pour son utilisation (le scoring) et offrir une rapidité de réponse maximum.

Cet entrepot sera basé sur le gestionnaire de base de données MySQL et installé sur un serveur Ubuntu Server. Ce projet utilisera uniquement des outils libres (open-source).

Un premier temps a été consacré à l’étude des entrepôts de données. Suite à cela les
besoins du projets se sont révélés en partie différents de l’utilisation propre d’un entrepôt de données, l’étude a donc ensuite consisté à définir les besoins spécifiques au projet. Ces besoins dépendent principalement de la partie scoring dont l’entrepôt de données est finalement un outil utilisé uniquement par la partie et pas directement avec l’environnement du système. L’importance de cette étude s’est révélée primordiale, d’une part car aucun outil libre ne remplit ce rôle à ce jour, et d’autre part car les méthodes employées divergent selon les produits existants (et ne sont pas
toujours rendues publiques). La méthode à employer pour gérer un entrepôt de données dans notre contexte s’approche du domaine de la recherche. Cette méthode a donc été la troisième partie de l’étude de ce premier semestre. Plusieurs solutions ont été envigagées et analysées sur le plan théorique, ce qui a finalement mené au choix d’une de ces solutions.

Etapes de l’étude du premier semestre

  1. Etude des entrepôts de données et comparaison avec l’objectif du projet
  2. Etude des besoins de la partie « OLAP et MySQL » et des difficultés techniques
  3. Etude des solutions envigeables pour répondre aux besoins

2. Etude des entrepôts de données

2.1 L’entrepôt de données

Dans le monde des entreprises, les entrepôts de données sont en parallèle du système
d’information. Si le but du SI est de stocker toutes les informations courantes et à jour de l’entreprise, le but de l’entrepôt est de conserver un historique de ces informations dans le temps.

Un entrepôt n’est donc jamais modifié, on y ajoute seulement des informations datées qui viennent s’ajouter aux précédentes. Son objectif est également différent, l’entrepôt est utilisé pour rassembler ces informations et en faire ressortir des tendances pour aider aux décisions de gestion et politique de l’entreprise. Sa nature même fait qu’un entrepôt fait généralement 100 fois la taille d’une base de données (le SI). Sa taille importante et son utilisation spécifique oblige l’entrepôt a être conçu différemment d’une base de données habituelle. L’ensemble des données d’un entrepôt est appelé cube.

2.2 Le cube

Le cube représente toutes les données qui seront nécessaires à l’analyse, ces données
peuvent être stockées ou calculées à la volée, ce qui impose respectivement de l’espace de stockage et du temps de calcul. Afin de conserver des dimensions raisonnables autant dans l’espace de stockage nécessaire que dans les temps de réponse, il faut choisir quelles données seront calculées d’avance et stockées pour une acquisition immédiate dans le futur, et quelles données seront plutôt calculées à chaque fois qu’elles seront nécessaires.

En effet le cube est produit à partir des données brutes de systèmes d’information, donc
des résultats généralement très précis. Ces résultats peuvent être regroupés par familles de différents niveaux de généralité (les niveaux d’agrégation) selon les besoins de précision de l’analyse. Les valeurs correspondant à ces niveaux sont des totaux, des moyennes et autres de toutes les valeurs précises appartenant au niveau. Les niveaux d’agrégation ont une forme d’arbre où toutes les données brutes sont les feuilles.
Les utilisateurs auront souvent besoin de voir les données à des niveaux d’agrégation
différents, et donc concrétement de regrouper ou détailler les données (respectivement pliage et dépliage du cube). Ces actions impliquent les calculs d’agrégation (total, moyenne etc) et peuvent être lourdes selon la taille des données. Ce sont ces données calculées qui peuvent être stockées pour limiter les calculs lors de l’utilisation (au détriment de l’espace disque).

Il faudra non seulement choisir quels niveaux d’agrégation stocker ou calculer, mais
également regrouper des tables sources pour obtenir des données brutes aussi complètes que possible dans les tables de base du cube. Cette création engendre de très lourdes jointures qui doivent être optimisées.

2.3 OLAP et ROLAP

Même si la définition officielle de OLAP (On-Line Analytical Processing) n’est pas encore
normalisée, ses principes généraux sont d’offrir des possibilités d’agrégation et de dimensions illimitées dans des temps de calculs faibles (en gérant les matrices creuses notament), tout cela sur un serveur gérant un accès concurrent (i.e. plusieurs utilisateurs en même temps) et avec une ergonomie accessible aux non-informaticiens. La partie OLAP (principalement des outils de calculs) est en théorie bien séparée de l’entrepôt de données (l’acquisition, le regroupement et le stockage des données de manière physique).

Le concept OLAP est indépendant de l’implémentation de ses fonctionnalités. Dans notre
cas, l’entrepôt de données sera basé sur un SGBD relationnel : MySQL, on parlera alors de ROLAP (Relationnal OLAP). Le principe de ROLAP est de conserver toutes les données brutes dans une base de données relationnelle et de calculer les agrégats par des requêtes SQL, l’inconvénient est le temps nécessaires à ces calculs. Une solution à ce problème est de stocker des tables d’agrégation calculées au préalables.

On remarque que l’objectif de la partie « OLAP et MySQL » ne correspond pas à la définition complète de OLAP. En effet dans le cadre de notre projet, seules les applications de scoring auront accès à l’entrepôt de données (en accès non concurrent) et cela sans interface graphique.

L’objectif est donc réduit au stockage et à la restitution des données, ce stockage et cette restitution doivent cependant être optimisées car elles devront gérer des quantités de données très importantes.