Vous êtes sur la page 1sur 22

Analyse Dimensionnelle Datawarehouse et moteur OLAP.

Rapport de l’étude pour le module d’Architecture Logicielle

Joris VASSOU Jordan DECOT Alexandre LEBLUN Bastien BARBE

Logicielle Joris VASSOU Jordan DECOT Alexandre LEBLUN Bastien BARBE Architecture logicielle 8 Novembre 2012

Architecture logicielle

8 Novembre 2012

Sommaire :

Table of Contents

1.

Introduction

3

1.1. Les outils usuels des bases de données

3

1.2. D es données toujours plus volumineuses

3

2. L’architecture décisionnelle

5

2.1.1.

Datamart

10

2.2.

Analyse des données

10

2.2.1. Datamining

10

2.2.2. OLAP

10

3.

Avantages/Inconvenients du moteur OLAP

13

3.

Structures et Agrégations

15

4.1.

. Datawarehouse

15

3.2.1

MOLAP

19

3.2.2.

ROLAP

20

3.2.3.

HOLAP

21

Conclusion

22

Bibliographie

22

1. Introduction

1.1. Les outils usuels des bases de données

Avant de commencer à décrire le datamining et aux outils qui gravitent autour, il faut comprendre pourquoi les autres outils de bases de données ne suffisent parfois plus.

Les intérêts des SGDB usuels Le datamining qui sera présenté plus loin ne révolutionne pas le monde de la persistance. Il n’apporte pas certaines qualités qu’offre un outil que nous qualifierons de plus classique.

Pour comprendre cela il faut comprendre dans quel but les outils de SGBD, tel que le très répandu SGBD relationnel, ont été conçus.

Le cadre des années 70 Le datamining qui sera présenté plus loin ne révolutionne pas le monde de la persistance. Il n’apporte pas certaines qualités qu’offre un outil que nous qualifierons de plus classique.

Pour comprendre cela il faut comprendre dans quel but les outils de SGBD, tel que le très répandu SGBD relationnel, ont été conçus.

Besoin de rapidité

C’est dans la période 65- 75 que grandit le besoin de pouvoir organiser de grandes quantités de données, de manière à pouvoir s’affranchir d’une partie de l’intelligence liée à leurs gestions. On à besoin de systèmes “bêtes et méchants” qui font ce qu’on leurs demandent, des systèmes où l’on a pas besoins de spécifier comment chercher, mais où on garde un maximum de contrôle sur l’organisation. Nous sommes dans une période où l’informatique est jeune, la mémoire est limitée, et aucun cycle n’est négligé. Pour un exemple plus concret, si aujourd’hui une énorme base de données se mesure en Terabyte, dans les années 80 elle se mesure en Megabyte !

1.2. D es données toujours plus volumineuses

Bien sûr chaque concept à des limites, et les SGBD classiques ne sont pas une exception.Au fur et à mesure que l’informatique s’est complexifié, répandu, ces outils on continués être utilisés, mais dans certains cas ils ne sont plus suffisant.

1.1.1. La gestion

Les ordinateurs, tous les 18 mois, doublent sa puissanc e de calcul. Cela s’est aussi vérifier pour les unités de stockages. Cela veut dire que la taille des données présentes sur les unités de stockage à travers le monde a littéralement explosé au cours des dernières années. Le problème ne vient certainement pas de la vitesse de réponse des SGBD classiques, ils sont faits pour ça, mais plutôt de la gestion de ces données par l’homme. Imaginez - vous devoir analyser des revenus annuels en détail, armé de votre tableur Excel et de votre petit programme de gestion de base de données, font à des milliers voir des millions de réponses à vos requêtes. De plus de tels systèmes sont gérés par plusieurs personnes simultanément, ce qui conduit à une multiplication du risque d’une erreur humaine dans la base. Face à un million de lignes en réponse, comment trouver l’erreur si elle existe ? L’homme ne doit pas être l’instrument de la machine, c’est l’inverse qui devrait se produire

1.1.2. La conception

Si le problème précédent sur la gestion et l’utilisation existe, il ne faut pas non plus négliger

celui de la conception d’un programme qui doit puiser dans la base de données.Format de données différents, mise à jour perpétuelle due à un changement dans les bases, architecture trop compliquée, trop coûteuse : les bases de données énormes semblent plus causer de problèmes qu’elles n’en résolvent

1.2. Quel marché, q uelles possibilités ?

1.2.1. L’informatique décisionnelle

L’informatique décisionnelle est un terme qui désigne une branche de l’informatique qui à pour but de fournir à ses utilisateurs des aides à la prise de décision. Cette informatique est souvent mis e en œuvre dans des domaines tels que l’analyse fi nancière, pour permettre de corriger le cap pris par une entreprise si celui - ci n’apporte pas les résultats escomptés par exemple.

Pourquoi pas les SGDB classiques ? Lorsque l’on travaille dans le cadre d’une entreprise, il faut comprendre que la base d e données de celle- ci est en fait un agrégat de plusieurs bases de données, dont le format a pu changer au fur et à mesure du développement de l’entreprise, où les données, d’une base à une autre peut être radicalement différente. Les outils usuels deviennent de plus en plus difficile à gérer. Prendre des décisions rapides, ou même faire de la prévision à long terme

en se basant sur le plus de données possible est quasiment impossible. Il faut d’autres outils, pour aller chercher les données qu’il faut, là où elles sont, sans que cela soit un casse- tête pour l’utilisateur.

1.3.1. Réintroduire de l’intelligence dans la recherche

Le problème vient du fait que les SGBD ne sont simplement pas faits pour passer une certaine échelle sur un certain type d’utilisation. Le problème à l’air très spéci fi que, mais denos jour il est de plus en plus récurent. Il repenser ces systèmes, offrir une couche par dessus, pour introduire de l’intelligence en plus par le biais d’une architecture efficace, notamment.

Réunir les données virtuellement Une solution envisageable est d’offrir un système de “super” base de données, charger de jouer le rôle d’interface. Grâce à ce genre de système, on pourrait réunir les données virtuellement en faisant office de pont entre l’utilisateur et la base de données, offrant même peut- être le service de passerelle pour traduire les formats de données si nécessaire. Plus besoin de mettre à jour les logiciels, il faut mettre à jour l’interface si la base de données change. Si certaines données ne sont utilisées que localement, nul besoin de les mettre dans l’interface global : ça permet de désépaissir les bases de données virtuellement pour simpli fi er la tâche des utilisateurs.

Réunir les données spécifiquement Puisque l’on à parler de filtrage de données, autant filtrer complètement. Au lieu de donner une interface unique, on multiplie les interfaces pour pouvoir les spécialiser à un métier particuli er. Du point de vue de l’utilisateur la base de données est toute simple, facile d’accès, facile à gérer, facile à utiliser.

2. L’architecture décisionnelle

Comme nous avons pu le voir précédemment, les SGDB ne sont pas assez efficaces pour traiter et analyser des flots de données de plus en plus importants. L’informatique décisionnelle a besoin de nouveaux outils et support adapté pour avoir des données pertinentes.

Les systèmes décisionnels sont complexes et utilisent de nombreux nouveaux concepts que no us allons définir.

2.1. Vue globale

Ce schéma représente une architecture décisionnelle classique. On peut distinguer que l’illustration est séparée en cinq parties, représentant le cheminement et les transformations

des informations.

Les données sont rep résentées de nombreuse manière différente (fichier csv, xml, base de

),

données, etc elles vont être modifié, transformé et stocker pour enfin être analysé.

modifié, transformé et stocker pour enfin être analysé. 2.1. Dataware House 2.1.1. Principe des dataware house

2.1. Dataware House

2.1.1. Principe des dataware house

Une entreprise possédant un système d’information très développé peut posséder de nombreuse base de données permettant de stocker toutes les informations nécessaires à son activité. Ces diverses données sont souvent stockées de différente façon et ont pour unique but de répondre à un besoin fonctionnel de l’entreprise. Elles ne sont donc pas adaptées à la prise de décision. On a donc besoin d’une base de données adaptée :

les datawarehouse ou entrepôts de données.

2.1.2. Définition

Selon Bill Inmon, le créateur de ce concept, une dataware house est :

« une collection de données orientées sujets, intégrées, non volatiles et historisées, organisées pour le support d'un processus d'aide à la décision. »

- Orientées sujet Les données provenant des bases de données sont regroupées sous forme de

-Orientées sujet

Les données provenant des bases de données sont regroupées sous forme de thème (ou sujet) propre à l’entreprise. L’intérêt de cette organisation

est de pouvoir L’intérêt de cette organisation est de disposer de l’ensemble des informations utiles sur un sujet le plus souvent transversal aux structures fonctionnelles et organisationnelles de l’entreprise.

-Intègrées Les données provenant de différentes bases doivent être unifiées afin d’être intégrées au dataware house. C’est le processus le plus difficile à mettre en place lors de la mise en place d’un entrepôt de donnée, car les données provenant des bases de données sont hétérogènes.

-Non volatiles Une fois que les données sont stockées dans le dataware house, aucune modification ou suppression ne peut être faite. Une requête adresser à l’entrepôt de données à un mois d’intervalle aura donc le même résultat.

-Historisées Les informations stockées ne sont jamais mises à jour comme nous l’avons vu précédemment. Les données ont donc besoin d’être référencé dans le temps afin de retrouver les retrouver pour une date donnée.

Une datawarehouse est donc le regroupement de toutes les informations de l’entreprise stockée d’une nouvelle manière avec l’ajout de plus value permettant l’exploitation grâce aux nouveaux outils d’analyse.

2.1.1. Alimentation de l’entrepôt de données

Les informations contenues dans l’entrepôt de données provenienent des différentes sources de l’entreprise. Ce transfert d’information est assuré par les middlewares de type ETL (Extraction / Transformation / Loading) ou datapumping. Comme est l’indice, ces outils permettent d’extraire les données à partir de différentes sources, les modifier et les charger dans l’entrepôt de données.

2.1.2. Datawarehouse VS opérationnel

Comme nous l’avons vu, les datawarehouse ne sont pas structurés de la même manière qu’un système transactionnel classique. Voici un résumé des différences que l’on peut trouver ente un datawarehouse et un un système opérationnel classique

2.1.3 . Structure d’une dataware house Un entrepôt de données peut se structurer en quatre

2.1.3. Structure d’une dataware house

Un entrepôt de données peut se structurer en quatre classes de données organisées

selon un axe historique et un axe de synthèse.

Les données agrégées

Les données agrégées correspondent à des éléments spécifiques d’analyse dont un utilisateur pourrait avoir besoin. On peut donc voir qu’une première analyse est effectuée

au niveau du datawarehouse Elles constituent déjà un résultat d’analyse et une synthèse

de l’information contenue dans le système décisionnel, et doivent être facilement

accessibles et compréhensibles.

Les données détaillées

Les données détaillées reflètent les événements les plus récents. Les intégrations

régulières des données issues des systèmes de production vont habituellement être

réalisées à ce niveau.

Les métadonnées

Les métadonnées constituent l'ensemble des données qui décrivent des règles ou

processus attachés à d'autres données. Ces dernières constituent la finalité du système

d'information.

Les données historisées

Chaque nouvelle insertion de données provenant du système de production ne détruit

pas les anciennes valeurs, mais créer une nouvelle occurrence de la donnée.

2.1.4. Modélisation des données

Les données stockées dans le dataware house peuvent être modélisées de trois

manières différentes

-Le modèle en étoile

Ce modèle est constitué d’une table centrale appelée table des faits a laquelle vont se greffer les autres tables appeler tables de dimension. La table des faits contient toutes les clés étrangères des tables des dimensions ainsi que des attributs appelés mesure

des dimensions ainsi que des attributs appelés mesure Figure 1 Modèle en étoile Le modèle en

Figure 1 Modèle en étoile

Le modèle en flocon se distingue par rapport à celui de l’étoile uniquement par les tables de dimension. En effet, ces tables vont être plus détaillées et donner naissance à de nouvelles tables. On va donc avoir une hiérarchie des tables de dimension.

2.1.1. Datamart Un datamart (ou magasin de données) est un sous-ensemble d’un datawarehouse. Il permet

2.1.1. Datamart

Un datamart (ou magasin de données) est un sous-ensemble d’un datawarehouse. Il permet de focaliser les informations sur un secteur d’activités particulier de l’entreprise. Cela va notamment permettre de données aux utilisateurs un outil adapté à leur besoin et avoir un accès plus rapide aux données.

2.2. Analyse des données

2.2.1. Datamining

Le datamining ou fouille de données est un outil très performant pour l’analyse d’un très grand nombre de données afin d’extraire des connaissances permettant de faire apparaître des corrélations jusqu’alors cachées entre les données. L’objectif du datamining est de pouvoir extraire des informations riches et découvrir des modèles (ou pattern) à partir des données contenues dans le dataware house.

2.2.2. OLAP

Définition

Les bases de données relationnelles ne sont pas adaptées à l’analyse de données décisionnelle, car elles demandent beaucoup de ressource machine. Les transactions effectuées à travers un datawarehouse sont donc différentes d’un système classique. On parle ici de système OLAP (On Line Analytical Processing) qui s’oppose au système OLTP ( On Line Transaction Processing).

Les technologies basées sur OLTP sont le système de transaction utilisée par les SGDB. Elles permettent d’insérer, modifier et d’interroger les bases. Ces transactions sont adaptées pour de faibles quantités de données.

La technologie OLAP quant à elle repose la plupart du temps sur des datawarehouse. Il va récupérerles informations du datawarehouse en informations stratégiques.

Fonctionnement de OLAP

OLAP propose une approche multidimensionnelle. Les données vont être représentées sous la forme d’hypercube à n dimensions, on parle de manière générale de cube OLAP.

n dimensions, on parle de manière générale de cube OLAP. particulier Ces cubes sont une nouvelle

particulier

Ces cubes sont une nouvelle couche intermédiaire entre les bases de données et l’utilisateur.

Un cube de données est composé de dimensions et de mesures. Une dimension représente un axe d’analyse par exemple Magasins, Catégories et Mois dans l’image ci-dessous.

Une dimension contient des membres organisés en hiérarchie,chacun des membres appartenant à un niveau hiérarchique (ou niveau de granularité)

Dans l’exemple précédent, pour la dimension Mois les membres hiérarchiques peuvent être les semaines, les jours, etc

Les analyses OLAP vont se porter sur des éléments de données que l’on appelle mesure. Ex. : Vente de chaussure au mois de janvie

Les différents aspects de OLAP

MOLAP Multidimensionnal Online Analytical Processing.

Il s’agit comme son nom l’indique d’une structure de donnée multidimensionnelle. Ce type de base est rapide et très performant. Avec MOLAP on crée un cube qui précalcule l’ensemble des données, ce qui prend de la place et du temps. La limite des données

dépend sur le serveur sur lequel il est déployé.

ROLAP Relationnal Online Analytical Processing

ROLAP est le plus souvent utilisé, car il se greffe à une donnée relationnelle classique,

mais qui est organisée pour fonctionner comme une base OLAP avec un cube classique.

Les analyses sont transformées en requête SQL pour être exécutées sur les

tables. Cette méthode à l’avantage d’avoir un faible cout de mise en place de mise en place étant donné que les ressources sont déjà présentes dans l’entreprise. Par contre, l’utilisation d’un SGDB classique va ralentir le temps de réponse, car la génération des requêtes SQL n’est pas encore optimisée.

HOLAP Hybrid Online Analytical Processing

HOLAP est en quelque sorte un mélange des deux technologies. Les données

agrégées sont stockées sous formes multidimensionnelles, alors que les autres sont stockées dans des structures relationnelles.

3.

Avantages/Inconvenients du moteur OLAP

3.1. Avantages

OLAP

traitement d’une masse très importante de données, qui aurait été autrefois réservé à

des statisticiens. L’accès à cette immense base d’information permet donc aux

experts du métier de réaliser des requêtes afin de résoudre des problèmes

complexes et ainsi leur facilite la prise de décision sans pour autant être expert en

informatique ou statistique. Ceci permet notamment à une entreprise de pouvoir

maximiser ses profits en analysant toutes les données de son historique.

à des personnes non expérimentées le

permet

de

rendre

accessible

Les données, souvent agrégées, peuvent provenir d’une multitude de sources

différentes. Le fait de combiner toutes ces informations différentes dans une même

base homogène permet alors de pouvoir réaliser des requêtes dont il aurait été

impossible de faire sur des bases de données séparées. En effet, des données

séparées peuvent prendre un tout nouveau sens une fois réuni.

Le fait d’homogénéiser les données permet aussi d’avoir une structure plus

cohérente, et ainsi améliorer les performances de stockage et de calcul de ces

données. Le travail initial de nettoyage des données permet aussi de relever les

incohérences dans les bases de données actuelles et de les corriger.

L’utilisation d’une structure OLAP sous forme de cube permet d’analyser les données

dans de multiples dimensions et permet par exemple de favoriser la rapidité d’accès

aux données en précalculant différents faits sur les données sous toutes les

dimensions.

Une structure OLAP est basée sur des dimensions que l’on crée au préalable. Elles

sont indépendantes les unes des autres. Ce qui en fait donc un outil très flexible : on

peut faire plusieurs cubes avec des dimensions en commun, ou même en supprimer

une ou deux sans que les autres données ne soient affectées. Un cube de données

n’est donc composé que des mesures qui sont agrégées, ce qui offre une grande

flexibilité et évolutivité.

3.2. Inconvénients Une structure comme OLAP nécessite une mise en place couteuse. En effet, comme

les sources de données sont très souvent hétérogènes, il y a un très grand travail

d'homogénéisation à réaliser au préalable. Les données doivent être nettoyées afin

de pouvoir être cohérente une fois toutes réunies. Cela a naturellement un coût élevé

et n’est donc pas une étape à négliger pour une entreprise souhaitant mettre en

place une technologie comme celle-.

Après la mise en place, il faut également prendre en compte les coûts de

maintenance. En effet, il est nécessaire de continuellement mettre à jour les données

au sein de la base afin de pouvoir toujours offrir des résultats pertinents. Il est donc

nécessaire à l’entreprise de déterminer si les avantages apportés par la mise en

place d’un datawarehouse sont supérieurs aux coûts de mise en place initiale et de

maintenance.

Si l’on souhaite réaliser un cube OLAP, il faut savoir que la structure des données

diffère d’une base de données classique. Le travail nécessaire afin d’intégrer les

données est assez important, et donc si le volume de données est très élevé, il ne

sera pas possible d’actualiser les données de façon très régulière, ce qui peut avoir

un impact non négligeable si l’entreprise a besoin de données très récentes.

3.

Structures et Agrégations

Un système de bases de données classique atteint vite ses limites lorsqu’il s’agit d’informatique décisionnelle. Par exemple un tupl e va être parcouru un grand nombre de fois, alors que l’on aurait besoin de l’information que sur un plus haut niveau. Si on veut le chiffre d’affaires d’une grande enseigne par pays, avec une requête SQL classique on reprendra chaque vente de chaque magasin. Quelles que soient les optimisations qui seront faites, le temps d’exécution de la requête sera donc très long. Certaines requêtes en SQL seul peuvent même être impossibles à formuler. Pour de l’informatique décisionnelle il est donc impératif de reprendre ces technologies et de les adaptes a l’utilisation qu’on veut en faire.

C’est donc pour cela qu’il existe un certain nombre de structures : le datawarehouse, la base de toute architecture décisionnelle, puis viennent les technologies OLAP avec MOLAP (OLAP Multidimensionnel), ROLAP (OLAP Relationnel) et HOLAP (OLAP Hybride, un mélange des deux dernières approches). Ma liste n’est pas exhaustive, mais elle représente bien les technologies majeures des analyses décisionnelles. Ce sera l’une d’entre elles qui sera utilisée dans 90% des projets impliquant de la prise de décision.

4

Datawarehouse

Un datawarehouse (ou entrepôt de données) est une base de données où les données sont triées, nettoyé, donc fiable. Le plus souvent il s’agit d’une base de données complexe et optimisée pour la performance.

Les données seront donc conservées sous forme élémentaire et détaillée (exemple : pour une banque, chaque opération sur chaque compte de chaque client) si la volumétrie le permet. Elles présentent des avantages évidents, mais représentent un plus grand volume et nécessitent donc des matériels plus évolués.

Il est aussi possible qu’elles sous forme agrégée selon les axes ou dimensions d'analyse. Les données agrégées présentent d'autres avantages (facilité d'analyse, rapidité d'accès, moindre volume). Il est cependant impossible de retrouver le détail des données une fois ceux- ci agrégés : on prend le risque de figer les données et de ne plus pouvoir revenir aux données initiales.

4.2. OLAP

Le terme OLAP d ésigne un ensemble de moyens et de techniques pour réaliser des systèmes d’aide à la décision. De nombreux traitements se mi - automatiques sont mis en œuvre pour interroger, visualiser et synthétiser les données. Une base OLAP doit être très rapide et elle a pour but de donner à l’utilisateur une réponse fiable de faconde quasi instantanée.

Gestion de la granularité La granularité est le niveau de détail des données dans une base de données. La hiérarchisation de l!information en différents niveaux de détai ls appelés niveaux de granularité, le niveau le plus bas est celui de l’entrepôt.

Les données au sein d’une structure OLAP sont être groupées à différents niveaux de granularité : les regroupements sont précalculés, par exemple, le total des ventes pour l’année calculée à partir de la somme de toutes les ventes des mois (et non des jours, le calcul du total des mois étant fait auparavant).

Des opérateurs OLAP permettent de gérer cette granularité:

• ¥ - Forer (drill- down ) : Descent dans la hiérarchie de la dimension. C’est par exemple quand le chiffre d’affaires de l’année est affiché et on veut l’obtenir moins par mois. On descend donc d’un niveau dans la dimension Temps . (niveau de granularité inférieur, plus détaillé).

. (niveau de granularité inférieur, plus détaillé). • - Remonter ( drill - up ) :

• - Remonter (drill- up) : Contrai rement au drill - down on remonte dans la dimension. (niveau de granularité supérieur)

Voici les autres opérateurs important au sein de OLAP pour la restructuration :

• - Pivoter (Rotate) : c’est une rotation des axes du cube pour avoir une vue alternative sur les données.

Figure 2 : exemple de rotaite sur un petit cube de données Si on considère

Figure 2 : exemple de rotaite sur un petit cube de données

Si on considère que la face étudiée est celle qui est en gras, on pivote le cube pour avoir l’affichage des départements (dimension géographique) au lieu de celle qui contient les catégories de produits (dimension catégorie).

- Le scapin : qui consiste à ne se focaliser que sur un sous ensemble du cube, avec une ou plusieurs lignes et colonnes. En ne gardant qu’un sous - ensemble de catégories produit et un sous- ensemble d’années par exemple.

produit et un sous- ensemb le d’années par exemple. Figure 3 : exemple de l'operateur scoping

Figure 3 : exemple de l'operateur scoping

-

tranche du cube , une des dimensions est alors réduite à une seule

c‘est le même principe que le scapin, mais sur une

Le

slicing :

valeur.

à une seule c‘est le même principe que le scapin, mais sur une Le slicing :

Figure 4 exemple de slicing

3.2.1 MOLAP

Le modèle MOLAP est un système multidimensionnel pur, c’est- à - dire qu’il gère des structures multidimensionnelles de manière native , comme des tableaux à n dimensionnent (hypercube), des axes et des mesures qui seront l’intérieur de notre cube.

Les données s ont stockées sous forme de tableaux, d’où une grande rapidité, il n’y a aucune jointure à faire.En général, dans un cube de données il peut y avoir jusqu’à 90% de cases vides. L’idée est donc de stocker ces cases sous forme de gros blocs pour gagner en temps lors du parcours du cube.

Agréger est le fait de parcourir et d’appliquer une fonction d’agrégat sur des lignes du tableau, ils peuvent être calculés à la demande ou précalculés et stockés comme des lignes du tableau. En MOLAP les agrégats sont calcules en divisant le cube en sous cubes (chunks) qui tiendront en mémoire principale et qui seront compresses et optimises. Puis les agrégats sont calculés en parcourant chaque cellule de chaque sous- cube en y calculait les prédicats partiels.

La principale fo rce d’un cube OLAP est ses très bonnes performances. Elles sont dues à la réalisation de nombreuses préagrégations et de précalculs de données sur tous les niveaux de hiérarchies des dimensions. Cependant ces précalculs de données réalisés génèrent de très importants volumes de données, en particulier quand la taille de la base dépasse quelques Go, les performances se dégradent vite. La technologie MOLAP doit donc être utilisée si l’entreprise souhaite des résultats très rapides au détriment de l’espace de stockage.

Le précalcul général de toutes les données nécessite de reconstruire périodiquement. À chaque fois que l’on souhaite rafraichir le contenu du cube, il faut le régénérer. Il y a des modèles de données dont cette reconstruction ne posera aucun pro blème. Par exemple une enseigne qui veut connaître le chiffre d’affaires de ces magasins pendant l’année, on ne souhaite pas intégrer les ventes du jour. Au contraire, pour du temps reel ou une base très réactive aux nouvelles données il faudra choisir un modèle relationnel ou hybride.

3.2.2. ROLAP

Tout comme MOLAP cet outil a été créé pour analyser des données via un modèle multidimensionnel, mais il diffère dans la mesure ou il ne nécessite aucune étape de génération comme c’est le cas avec MOLAP. Les outils ROLAP accèdent à la base relationnelle et génèrent des requêtes SQL pour calculer les informations au niveau de granularité demande par l’utilisateur. Avec ROLAP, il est possible de créer de nouvelles tables qui résumeront les données avec n’importe quelle combinaison de dimensions.

Le système ROLAP utilise une technologie de stockage relationnelle, il traduit dynamiquement le modèle logique de données multidimensionnelles modèles de stockage relationnel. Il a l’avantage de s’appuyer sur une technologie mature qu’est la gestion des données relationnelle.

Dans une structure du type ROLAP, le recalcul des agrégats prend une place très importante dans l’optimisation du temps d’exécution et de l’espace disque. Il est nécessaire de stocker certains de ces résu ltats d’agrégation, mais ils prennent de l’espace disque et les stockers prennent du temps. Pour va définir les résultats qui seront stockes en fonction du niveau d’agrégation nécessaire (définit à la conception de la solution), mais aussi des requêtes uti lisateurs fréquents. Pour de bonnes performances, une bonne conception est primordiale, le niveau de détails ne doit pas être trop bas, mais il doit pouvoir répondre à toutes les requêtes. Ces résultats sont stockés dans des vues matérialisées.

Une vue matérialisée (snapshot) est une table contenant les résultats d’une requête, elle sert à améliorer l’exécution des futures requêtes qui s’appuieront sur ces données. Cette vue matérialisée peut servir a en construire d’autres par la suite.

En conclusion les trois moteurs d’une architecture ROLAP sont l’indexation spécifique des données, qui doit être étudie au cas par cas, la sélection et la matérialisation des vues, pour en stocke le plus possible pour gagner du temps de calcul, et la fragmentation des tables de l’entrepôt de données qui doit être sous forme de schéma en étoile adapte aux requêtes que l’on souhaite faire.

3.2.3. HOLAP

Cette approche consiste à utiliser les tables comme structure permanente de stockage des données et les tableaux comme structure p our les requêtes. En clair cette version de OLAP combine les bons cotés de ROLAP et MOLAP en stockant les données détailles de la base de données dans un système de gestion de base de données relationnelle, les données agrégées sont stockées dans un système multidimensionnel. La proportion de ROLAP et MOLAP dépend de notre base de données et de l’utilisation qu’on va en faire.

En combinant ces deux architectures, on peut gérer des entrepôts de données très importants en gardant des temps de réponse satisfai sants.

très importants en gardant des temps de réponse satisfai sants. Figure 5 : Representation d'une structure

Figure 5 : Representation d'une structure HOLAP

Conclusion

En conclusion, les outils comme les datawarehouse ou OLAP ont trouvé leurs places dans l'informatique moderne. Ils répondent vraiment à un besoin grandissant: la gestion de très gros volume de données. C'est st un secteur en pleine croissance, aussi bien du côté de la demande que de l'offre.

De nombreuses variantes (parfois exotiques) du moteur OLAP existent à ce jour, ils permettent de répondre aux besoins d'aide à la décision, mais également de choisir une solution « sur mesure » aux besoins des utilisateurs.

Bibliographie

Cours :

http://www.lsis.org/espinasseb/Supports/DWDM - 2009/3 - OLAP - 2010- 4p.pdf

http://www.info.univ- tours.fr/~marcel/BD/dw_notes2.pdf

http://cs.ulb.ac.be/public/_media/teaching/cubesolap.pdf

http://www.lirmm.fr/~laurent/CNAM/cycleC.pdf

Forums et sites persos

http://www.developpez.net/forums/d942143/logiciels/solutions - dentreprise/business-

intelligence/approche- theorique- decisionnel/alimentation/difference- entre- datawarehouse-

olap/

http://blerubrus.free.fr/cnam/ueeng111/solap_html/sectOlap.html

http://www- poleia.lip6.fr/~doucet/CoursBDWA/BDWA2 - Cube2010.pdf

http://xpose.avenir.asso.fr/viewxpose.php?site=39&subpage=/multidim.html