Cette situation s’explique par le fait que jusqu’à présent le marché OLAP était un marché de niche. Ce marché est désormais en plein boom comme le montre le graphique ci-dessous :

Il est cependant encore difficile de se procurer un ouvrage sur OLAP en France. Mes recherches documentaires ont été très difficiles. Pratiquement l’intégralité des informations a été trouvée sur l’Internet et notamment sur des sites américains.

Ce mémoire constituera une bonne première base écrite sur OLAP pour les personnes intéressées par les technologies de système de base de données et par le décisionnel.

L’objectif de cet écrit est de présenter l’état de l’art de la technologie OLAP. Il s’agit de comprendre la technologie multidimensionnelle, de comprendre les règles OLAP et d’évaluer les bénéfices d’une telle organisation de données.

Nous poserons donc tout d’abord les concepts OLAP et les définitions de base à connaître. Nous présenterons ensuite en détails, les règles d’un système OLAP, ses architectures et leurs bénéfices et inconvénients. Puis nous ferons un panorama des outils et analyserons l’évolution du marché OLAP.

L’information est devenue par conséquent une condition de survie, un point crucial. Pour cela il faut nécessairement une information pertinente, utile, disponible, compréhensible et préparée. Disponible dans le sens de disponibilité au moment où l’utilisateur en a besoin, et compréhensible en pensant au format des données.

L’entreprise dispose très souvent d’une énorme quantité d’information provenant de son système opérant et de l’extérieur. Encore très souvent les entreprises ne se rendent pas comptes qu’elles disposent d’une mine d’informations, il est important cependant qu’elle construise un système décisionnel afin d’améliorer ses performances en s’appuyant sur les informations disponibles.

L’informatique permettant le traitement de l’information, joue dès lors un rôle essentiel dans l’entreprise, elle devient un outil d’aide à la décision. Un certain nombre de solutions ont été apportées afin de répondre à ces besoins parmi celles-ci les info - centres, le data warehouse, et bien sûr les technologies OLAP.

Les concepts

Afin de comprendre le concept OLAP, il est important de définir son domaine d’application, de présenter ses caractéristiques et ce qui le distingue des autres technologies, des autres concepts. Il est notamment important de faire la distinction entre OLAP et OLTP.
Durant les dix dernières années, un pourcentage signifiant de sociétés ont migré leurs données vers des bases de données relationnelles.

Les bases de données relationnelles ont été massivement utilisées dans les domaines opérationnels et de contrôle et particulièrement dans des applications à caractère transactionnel, communément appelées OLTP.

OLAP et OLTP

Le terme On Line Analytical Processing fût introduit en 1993 par E.F. Codd, le père des bases de données relationnelles. OLAP décrit une classe de technologies conçues pour l’accès et l’analyse instantanée de données ad hoc. Tandis que l’OLTP s’appuie essentiellement sur les bases de données relationnelles, OLAP est devenu un synonyme de vues multidimensionnelles de données ‘’business’’. Elles requièrent une technologie multidimensionnelle de base de données. Ces vues constituent la base technique pour le calcul et l’analyse demandée dans les applications de ‘’business intelligence’’.

" Posséder un SGBDR ne constitue pas un nirvana d’aide à la décision. Les SGBDR n’ont jamais eut la prétention de fournir des fonctions puissantes pour la synthèse, l’analyse et la consolidation de données " E.F. Codd, computerworld.

Les systèmes transactionnels se caractérisent synthétiquement par la persistance des données, l’intégrité de la base de données, et par l’importance de l’efficience de l’exécution d’un grand nombre de petites transactions dans un temps acceptable. Des utilisateurs créent, modifient et interrogent des enregistrements, c’est pourquoi les bases de données OLTP sont optimisées pour les transactions (transaction updating). La base de donnée OLAP de son côté, est souvent mise à jour en batch et provient de sources multiples.

Le tableau suivant résume les différences entre OLTP et OLAP :
 

Les applications OLTP on tendance à traiter quelques données atomisées à la fois, tandis que les applications OLAP traitent le plus souvent des données récapitulatives.

Contrairement aux applications OLTP, les applications OLAP ont pour rôle de visualiser des tendances et requièrent donc des données historiques. Les applications OLTP sont orientées processus tel que celui d’une commande, les applications OLAP sont plutôt orientées sujet répondant à des questions telles que ‘’Quels produits se vendent bien ?’’.

L’informatique de décision s’oriente de manière naturelle vers un système OLAP, cependant nous verrons que l’industrie informatique propose différentes approches de OLAP et notamment des systèmes OLAP basés sur des SGBDR (ROLAP).

D’autres concepts s’approchent de OLAP et notamment le data warehouse. " Le data warehouse est une collection de données orientées sujet, non volatiles et historisées, organisées pour le support d’un processus d’aide à la décision. ", Bill Inmon, Using the data warehouse.

Si l’on se réfère uniquement aux ouvrages portant sur le data warehouse, OLAP est présenté comme un composant de modélisation de données. Les puristes OLAP cependant parlent de complémentarité. Alors qu’en est-il réellement ?
 

OLAP et Data Warehouse

Les stratégies actuelles des vendeurs de base de données relationnelles, sont de présenter leurs produits comme étant des outils de construction d’entrepôts de données (data warehouse). Un data warehouse stocke des informations stratégiques qui répondent à des questions telles que ‘’Qui ?’’ et ‘’Quoi ?’’ en s’appuyant sur des événements passés. Une requête typique demandée dans un data warehouse est : " Quel est le chiffre d’affaires total pour la région Est au troisième trimestre ? "

Il est important selon le conseil OLAP* de "distinguer les capacités d’un data warehouse de celles d’un système OLAP. Contrairement à un data warehouse qui se base le plus souvent sur une technologie relationnelle, OLAP utilise des vues multidimensionnelles de données agrégées afin de permettre un accès rapide à des informations stratégiques pour une analyse plus fine. "

OLAP permet à des analystes et gestionnaires d’accéder rapidement, interactivement à des données à travers une large variété de vues possible d’informations. OLAP transforme des données brutes de manière à refléter la réelle dimension d’une entreprise du point de vu de l’utilisateur.

En plus de l’habilité des systèmes OLAP à répondre à des questions de type ‘’Qui ?’’ et ‘’Quoi ?’’, ce qui les distingue des data warehouses, c’est de pouvoir répondre également aux questions ‘’Quoi si ?’’ et ‘’Pourquoi ?’’. OLAP permet la prise de décision sur des actions futures.

OLAP et data warehouse sont donc complémentaires : un data warehouse stocke et gère les données, OLAP transforme ces données en informations stratégiques.

Domaines d’applications

Les applications OLAP fournissent une variété de fonctions organisationnelles. Les services financiers utilisent OLAP pour des applications de budgétisation, analyse de performance financière et modélisation financière.

L’analyse des ventes et la prévision sont deux applications OLAP pour les services des ventes. Parmi les autres applications, les services marketing utilisent OLAP pour les études de marché, compagnes de promotion des ventes, analyse de la clientèle et de la segmentation du marché. Les applications OLAP les plus courantes dans l’industrie, sont la planification de la production, l’analyse des pannes et des anomalies.
 
 

L’aspect important concernant toutes ces applications précitées est la capacité de OLAP à fournir aux décideurs, l’information dont ils ont besoin afin de prendre les bonnes décisions sur les directions stratégiques de leur service. L’indicateur clef d’un bon système OLAP est sa capacité à fournir une information ‘’juste à temps’’ pour la prise de décision, ce qui requière plus qu’un niveau de base de données détaillées.

L’information juste à temps est un ensemble de données informatisées qui représentent des relations complexes et qui sont calculées à la volée. L’analyse et la modélisation de relations complexes ne sont efficientes que si les temps de réponses sont considérablement court. Par conséquent, puisque la nature des relations des données n’est pas forcément connue à l’avance, le modèle de données doit être flexible.

Bien que l’on trouve les applications OLAP dans un large éventail de domaines, elles présentent toutes des caractéristiques communes.

Les caractéristiques clefs
 

Des vues multidimensionnelles de données.

Les vues multidimensionnelles sont représentatives d’un actuel modèle ‘’business’’. Il est rare qu’un tel modèle soit limité à moins de trois dimensions. Les décideurs construisent le plus souvent des scénarios pour des données financières tels que : entreprises, lignes d’unités, et le temps ou encore des données de ventes par produit, lieu géographique, canal et le temps.

C’est pour ces raisons qu’une base de données ne doit pas préjuger des opérations qui peuvent être exécuter sur une dimension, ni du temps qu’elles sont susceptibles de prendre.
Les utilisateurs ont la possibilité d’analyser les données à travers n’importe quelle dimension, à n’importe quel niveau d’agrégation avec les mêmes fonctionnalités et la même facilité. Les applications OLAP supportent ces vues de données de manière naturelle et dispense l’utilisateur d’une syntaxe de requêtes complexe.

Que la demande concerne les ventes hebdomadaires d’un produit en fonction de toute une série de zones géographiques ou qu’elle concerne uniquement les ventes à une date précise pour l’ensemble d’une gamme de produit pour une ville donnée, un système OLAP doit avoir des bons temps de réponse.

Le décideur ne doit pas être pénalisé par la complexité de leurs requêtes que ce soit en terme de ressources requises pour leur exécution ou que ce soit en terme de temps d’attente pour recevoir la réponse.

Des capacités de calculs intensifs.

Le point crucial d’une base de données OLAP est sa capacité à effectuer des calculs complexes. Les bases de données OLAP sont capables de faire davantage que de simples agrégations. Bien qu’une agrégation sur une hiérarchie soit importante, une analyse l’est encore d’avantage que de simples ‘’roll-ups’’ de données.

Les indicateurs de performance d’une activité nécessitent souvent des fonctions algébriques complexes. Les calculs prévisionnels de vente utilisent des algorithmes spécifiques. Analyser les ventes et les promotions d’une entreprise donnée et de ses concurrents, nécessite la modélisation complexe des relations entre les différents acteurs.

En fait, le monde réel lui-même est complexe et la capacité de modéliser des relations complexes est la clef d’un système OLAP.
C’est pour cette raison que les applications OLAP doivent fournir une palette riche de méthodes puissantes.

Afin de rendre les développeurs plus efficaces et les utilisateurs plus autonomes, la manière d’implémenter ces méthodes doit être claire et non procédurale ; ceci dans l’objectif de respecter le concept du ‘’juste à temps’’ de l’information.

Alors que les systèmes transactionnels (OLTP) sont jugés sur la capacité à collecter et à gérer les données, les systèmes analytiques (OLAP) sont jugés sur la capacité à créer de l’information à partir de données.

Dans les calculs complexes, les données historiques sont utilisées pour le prévisionnel, et les données agrégées sont utilisées pour l’estimation.

Une compréhension naturelle du temps.

Le temps est un composant inhérent à la plupart des applications analytiques. Le temps est une dimension particulière par son caractère séquentiel. Les vrais systèmes OLAP comprennent la nature séquentielle du temps. Les performances commerciales sont presque toujours jugées sur le temps, par exemple, ce mois par rapport au mois précédent, ce mois par rapport à l’année dernière à la même période.

Nous avons donc vu les concepts majeurs de la technologie OLAP, ses domaines d’applications et ses caractéristiques, avant de pouvoir présenter l’état de l’Art la technologie OLAP, il est important de définir et d’expliquer auparavant, la terminologie OLAP.
 

Définitions

Dans l’apprentissage de nouvelles notions, une pédagogie consiste à présenter les choses à l’aide d’exemples. Il me semble que pour la terminologie OLAP, cette méthode s’y prête très bien.

Nous verrons donc un exemple de création de base de données OLAP qu’il est possible de trouver sur n’importe quel site Internet traitant de la technologie OLAP.

Imaginons qu’une société désire construire une base de données pour suivre l'évolution de ses ventes par modèle et par mois. On peut imaginer une table vente :
 

Pour analyser ces données, on peut par exemple placer les mois en ligne et le type en colonne, on obtient deux colonnes Nombre et Total HT sur lesquels on peut effectuer toutes les simulations et les graphes que l'on veut.
Puis nous faisons évoluer notre table vente :
 

L'analyse s'avère déjà un peu plus complexe, car une feuille de papier (ou un document d'un tableur) ne possède que deux dimensions. Si l'on veut étudier les performances d'un magasin, il faut faire une sélection sur celui-ci. Mais si on s'intéresse ensuite à ce qui s'est passé en février sur tous les magasins, il faut repartir des données de départ et faire une autre sélection.

On peut imaginer que la société désire aussi étudier la répartition de ses ventes suivant d'autres critères, comme Genre (Homme/Femme/Enfant), Pointure ou encore Couleur.
Dans la terminologie OLAP, les axes d'analyse mois, modèle, magasin sont des dimensions.

Nous pourrons donc parler, par exemple, de la dimension magasin. Celle-ci peut prendre plusieurs valeurs, par exemple 'Paris Bastille'. Ces valeurs sont des positions de la dimension magasin.

Les deux indicateurs suivis par la société sont le nombre de chaussures vendues et les prix de vente hors taxe. Ces indicateurs sont appelés des mesures ou parfois des variables.

Nous pouvons dire que la mesure Nombre est dimensionnée par Mois, Modèle et Magasin.

Une mesure peut avoir de une à plusieurs millions de valeurs. Toutes les valeurs d'une mesure sont du même type, par exemple entier ou décimal.

Notre base de données est devenue multidimensionnelle. Il est possible de la représenter graphiquement.

Chaque case du cube représente une valeur. Les dimensions sont indiquées sur les arêtes du cube. Un plan du cube correspond à toutes les valeurs pour une seule position d'une des trois dimensions. Par exemple, la face avant est celle du magasin Paris Bastille. Enfin, le cube complet représente une mesure, ici le nombre de chaussures vendues.

L'étude des ventes mois par mois est certes utile, mais elle reste restrictive. Nous allons rebaptiser la dimension mois, et l'appeler par exemple Temps. Les positions de la dimension Temps peuvent être des mois, mais aussi des jours, des trimestres ou des années. Ainsi, nous pourrons analyser les résultats des différents magasins sur des niveaux plus ou moins précis.

Pour s'y retrouver entre toutes les positions de la dimension Temps, il suffit de créer une hiérarchie. Cette hiérarchie a, dans notre exemple, quatre niveaux, qui sont respectivement jour, mois, trimestre, année. On pourra alors tout naturellement rattacher le 18/05/98 à mai 1998, puis à 2ème trimestre 1998, puis à 1998.

De la même façon, il est possible de créer une hiérarchie sur la dimension magasin, par exemple en regroupant ceux-ci par département, région et pays. En général, il est même possible de définir plusieurs hiérarchies sur la même dimension. Une deuxième hiérarchie sur la dimension temps peut avoir les trois niveaux jour, semaine et année. Ici, le 18/05/98 est rattaché à semaine 20 1998, puis à 1998.

La seule contrainte pour définir une hiérarchie est que les données doivent être organisées suivant une série de relations (1,n) en cascade, c'est à dire que chaque position ne peut avoir qu'un seul parent. Supposons par exemple que l'on veuille créer une hiérarchie sur les magasins, pour indiquer quelle catégorie de chaussure est vendue (sport, ville, enfant). Il faut alors interdire la diversification aux gérants des magasins ! Mieux vaut donc positionner cette hiérarchie sur la dimension modèle, car un modèle de chaussure n'a qu'une catégorie.

Les mesures Nombre et Total HT sont dimensionnées sur Temps, Modèle et Magasin. Chaque magasin fournit ses données quotidiennement, et la base de données OLAP se charge de consolider ces données sur les différentes hiérarchies. Lorsque cette consolidation consiste à effectuer des sommes, comme c'est le cas ici, des fonctions intégrées permettent de faire cette opération très rapidement et très simplement.

Les résultats de ces agrégats sur les hiérarchies sont mémorisés dans la base, sur les positions correspondant aux niveaux supérieurs de la hiérarchie.

Notre base OLAP dispose pour l'instant de deux cubes de données ou mesures, qui sont le nombre de chaussures vendues et le prix total hors taxe. Ces mesures sont dimensionnées par Temps, Modèle et Magasin.

A partir de ces deux mesures, nous pouvons en créer d'autres, qui cette fois ne seront pas stockées dans la base de données mais calculées dynamiquement lorsqu'un utilisateur désire y accéder. Ces mesures sont parfois appelées des formules, en référence au texte qui les décrit.

Du point de vue de l'utilisateur, il n'y a aucune différence entre une mesure stockée et une formule. Toutes les deux sont dimensionnées et ont un type. La formule Prix moyen, représentant le prix moyen d'une paire de chaussure, est dimensionnée elle aussi, suivant Temps, Modèle et Magasin, de type décimal. Le plus simplement du monde, le texte de la formule est : Prix moyen = Total HT / Nombre

Lorsqu'un utilisateur accède à cette variable, le moteur de la base de données effectue autant de divisions qu'il le faut pour restituer l'information.

Il n'est pas nécessaire que tous les éléments d'une formule soient dimensionnés de la même façon. Par exemple, on peut définir une nouvelle formule : Total TTC = Total HT * 1,206

Ici, toutes les cellules sont individuellement multipliées par 1,206.

Comme ce taux change (trop) souvent, il est possible de créer une nouvelle variable, TVA, dimensionnée seulement sur le temps. Cette variable indiquera le taux de TVA à appliquer pour chaque position de la dimension Temps. On a alors, de façon toujours aussi intuitive :

Ainsi, le taux correct sera automatiquement appliqué pour chaque cellule de la formule.

De même, si le taux de TVA est différent suivant les produits vendus, alors les dimensions de la variable TVA doivent être Temps et Produit. Graphiquement, cette variable ne sera plus représentée par une ligne mais par un plan.

Les concepts OLAP ainsi posés et la terminologie définie, nous pouvons désormais approfondir notre point de vue au niveau technologique même de OLAP.

Dans cet état technologique que nous dresserons, nous verrons les architectures existantes et les règles à respecter.

Les règles OLAP

Les fonctions de base

Les fonctions de bases sont le noyau de la théorie OLAP et de l’analyse multidimensionnelle. Il y a deux concepts clef à garder en mémoire lorsque que l’on apprend OLAP : un système OLAP doit permettre l’accès à beaucoup d’utilisateur à la même donnée. Un système OLAP doit également permettre à un utilisateur d’obtenir le plus d’informations possibles par l’analyse d’une seule donnée. OLAP contient l’idée qu’un individu va pouvoir obtenir le maximum d’information à partir d’une donnée s’il y a accès de n’importe qu’elle manière qu’il le souhaite.

L’utilisateur doit pouvoir suivre ses idées en analysant une donnée et le produit OLAP doit être capable d’y répondre.

Un modèle multidimensionnel : la multidimensionnalité est la clef de la technologie OLAP. OLAP n’est que purement et simplement une base de données multidimensionnelle. Il y a des produits OLAP qui ont la capacité de stocker des données dans une base de données relationnelle tout en fournissant des vues multidimensionnelles de données.

C’est la vue conceptuelle qui est importante.

La multidimensionnalité est essentielle, car un système OLAP reflète de la nature multidimensionnelle des données entreprise. Du plus elle est intuitive pour un utilisateur.

Une manipulation intuitive des données : Alors que les vues multidimensionnelles de données sont un bénéfice pour le stockage de données et pour le temps de réponse des requêtes, la manipulation intuitive des données tend à contribuer à une bonne analyse. Il est naturel pour une personne, de lire un tableau ou un graphique, et de vouloir approfondir la vision d’une donnée ou d’un groupe de données. Avec un outil OLAP, il suffit d’un simple double - click sur la souris afin de ’’dérouler’’ une valeur, un sous-ensemble de données ou de changer tout simplement d’axe d’analyse sur un graphique. Cette règle permet d’éviter les procédures compliquées pour changer de vue.

Accessibilité : en pratique, un analyste aura besoin de sources d’information très différentes, y compris des bases de données OLTP ou même des feuilles de calculs quelconques.

Extraction en batch ou en ligne : cette règle contient l’idée d’une pré-agrégation des données et d’un accès en ligne des données, aussi bien que l’accessibilité en ligne de sources de données. L’extraction en batch fait référence à la capacité d’un produit à collecter les données de sources variées dans une base OLAP.

L’extraction en ligne incombe l’accès à différentes sources de données lorsqu’elle est nécessaire pour une requête. Peu de produits offrent un choix flexible entre les deux.

Idéalement un produit permettrait à un utilisateur de spécifier quelle donnée devrait être extraite en batch ou en ligne. En effet, un utilisateur peut avoir besoin d’obtenir des données historiques disponibles dans une base de données, mais par la suite peut vouloir accéder à des données fraîches dans un système OLTP.

Des modèles d’analyse : OLAP est fait pour l’analyse, mais un système OLAP devrait supporter différents modèles d’analyse. Des exemples de modèles d’analyse sont les rapports statiques, les rapports qui permettent la pagination, la rotation et le déroulé, les projections, les budgétisations.

Une architecture client-serveur : l’architecture client-serveur est importante pour un produit OLAP, dans le sens que c’est le meilleur moyen de déploiement de l’information à un grand nombre d’utilisateur. Dans l’optique de produire des résultats cohérents, les analystes devraient avoir accès à la même information. Il est également plus efficient dans l’optique de la base de données d’avoir une seule consolidation et centralisation de données à un endroit.

Transparence du serveur : cette nécessité de transparence vient de la capacité des produits OLAP à avoir une variété de clients différents. Un client peut être une application, une feuille de données ou encore un explorateur Internet et peut être créé par un utilisateur ou par un autre éditeur. En raison de la grande variété possible de clients, il est important que le produit OLAP assure des fonctionnalités OLAP à l’utilisateur quel que soit l’accès utilisé. Il ne doit pas y avoir de perte de fonctionnalité quel que soit le client utilisé.

Multi-utilisateur : un produit OLAP robuste permettra un accès multiple de manière concurrentielle à une donnée. Cela inclus également la capacité d’un serveur à autoriser des utilisateurs à se servir de différents modèles d’analyse.

Les fonctionnalités de reporting

Les fonctionnalités de reporting sont inhérentes à un bon produit d’analyse. Bien que le style des rapports soit complètement libre, certaines règles devraient être respectées dans l’optique d’une adéquation complète avec les fonctionnalités OLAP.

Une souplesse d’affichage et d’édition : la nature ad hoc de l’analyse requise pour les produits OLAP, nécessite qu’un outil de reporting soit flexible. Un utilisateur devrait être libre de faire apparaître un cube de n’importe quelle façon, c’est-à-dire qu’il devrait n’y avoir aucune contrainte sur l’arrangement des dimensions sur les axes d’une table, et l’utilisateur doit pouvoir faire des rotations et des coupes sur les cubes affichés.

Une performance de reporting uniforme : afin d’éviter des perturbations de flux lors des routines d’analyse, le temps nécessaire à un outil pour présenter un rapport doit être uniforme. Cela signifie qu’une requête doit être exécutée à une allure uniforme, et de même pour le rapport généré.

Gestion des données éparses : chaque base de données à une configuration optimale, déterminée par le nombre de dimensions et par la quantité de données qu’elle contient. Pour le temps de réponses et le stockage de données, une base de données devrait se baser sur ces facteurs. Un système OLAP doit donc ajuster son schéma physique automatiquement pour s’adapter au type de modèle d’analyse, au volume des données et au données dispersées.

Contrôle des dimensions

Une dimensionnalité générique : cette règle tend à stipuler que toutes les dimensions sont équivalentes, et qu’une opération effectuée sur une dimension peut l’être sur n’importe qu’elle autre dimension. Des règles ou opérations spécifiques peuvent être définie pour une dimension, mais ces règles doivent pouvoir être étendues à d’autres dimensions.

Des dimensions à niveaux multiples : idéalement, un produit OLAP devrait permettre à un utilisateur de définir autant de dimensions qu’il est nécessaire pour répondre à la réalité. Dans chaque dimension, l’utilisateur devrait également pouvoir déterminer le nombre de niveau d’agrégation

Opérations sur les dimensions : toutes formes d’opérations doivent êtres possibles à travers toutes les dimensions.

Toutes ces règles constituent une référence et sont présentées par de nombreux fournisseurs de systèmes OLAP dans leurs pages blanches. Naturellement, chaque fournisseur ne respecte pas intégralement l’ensemble de ces règles. Elles constituent cependant avec l’évolution actuelle du marché et la prolifération de produits de tout genre, un moyen de contrôle, un ensemble de critères qui permettent de déceler si un produit est véritablement, un produit OLAP ou non.

Il est nécessaire à présent de se positionner d’un point de vue pratique, et de présenter les composants d’un système OLAP.

Les composants d’un système OLAP

Un système OLAP est composé de différents éléments. Une vision globale du système permet de mettre en évidence une architecture générale : des sources de données, un serveur OLAP et des clients.

Les données à analyser sont transférées ou copiées dans le serveur OLAP, où elles sont organisées et préparées pour optimiser les requêtes. Le client est l’interface du serveur OLAP.

Les sources OLAP

La source d’un système OLAP dépend de l’utilisation du produit OLAP qui en est faite, il peut s’agir d’un data warehouse, d’une base de données quelconque d’une entreprise, d’une collection de feuilles de calculs contenant des données financières ou encore n’importe quelle combinaison des sources précitées. La capacité d’un produit OLAP à exploiter des données provenant d’un grand nombre de sources est importante. L’idée est d’éviter que toutes les sources de données soient stockées dans un format particulier ou dans une base de données particulière, car c’est un inconvénient pour les administrateurs de base de données et cela réduit la puissance et la flexibilité d’un produit OLAP.

Le serveur OLAP

Le noyau d’un système OLAP est son serveur. Tout le ‘’travail’’ est effectué par le serveur, c’est également l’endroit où les données sont stockées. Différentes philosophies régissent l'architecture du serveur OLAP. Un des aspects important est de décider si le serveur emploie une base de données multidimensionnelle (MDDB) pour enregistrer les données ou une base de données relationnelle (RDB).

Les deux solutions architecturales se dénomment respectivement MOLAP et ROLAP.

MOLAP

Le système MOLAP est le plus courant et est synonyme de OLAP. La finalité de cette solution est claire. On peut stocker efficacement des données qui sont de nature multidimensionnelle, et fournir des temps de réponses de requêtes très rapides.

Les données sont transférées d’une source de données dans une base multidimensionnelle, et ensuite seulement, le système procède à l’agrégation des données. Cette préparation des données est la technique qui permet aux requêtes OLAP d’avoir des temps de réponse courts, puisque le calcul des données récapitulatives est déjà effectué.

Le temps de réponse à une requête est alors uniquement fonction du temps requis pour accéder à une donnée élémentaire.

L’approche MOLAP s’appuie également sur l’idée d’effectuer le travail une seule fois et d’utiliser les résultats indéfiniment.

Les bases de données multidimensionnelles sont issues d’une technologie relativement récente. L’utilisation des bases de données multidimensionnelles implique les même inconvénients que l’utilisation de la plupart des autres nouvelles technologies.

Par ailleurs, elles ne sont pas aussi robustes que les SGBDR et ne sont pas optimisées jusqu’au même degré. Un autre inconvénient est que la majorité des bases de données multidimensionnelles sont incapables d’être interrogées pendant qu’elles procèdent à l’agrégation des données, donc un laps de temps est nécessaire avant que de nouvelles informations soient disponibles pour une analyse.
 

Le phénomène d’explosion de base de données est un des problèmes typiques aux bases de données multidimensionnelles. Bien que ce soit un phénomène connu, il est toujours difficile de l’expliquer lorsque cela arrive.

Contrairement à la désinformation perpétrée par les vendeurs de solutions d’architecture différentes de MOLAP, il a été conclue officiellement que le phénomène d’explosion n’est pas dû à la mauvaise gestion des données éparses, ni au stockage multidimensionnel, ni à un manque de compression des données et ni à des erreurs logiciels.

Tout comme les systèmes ROLAP ou les systèmes hybrides, le système MOLAP puise les données de sources extérieures variées. La différence essentielle est que ce système MOLAP, effectue toujours une copie des données puisqu’elles sont traitées et optimisées dans le processus multidimensionnel. Les études montrent que les mêmes informations stockées dans une base multidimensionnelle prennent deux à cinq fois moins de place que dans un SGBDR.

Le problème ne se pose donc pas au niveau du concept même de l’architecture MOLAP.

Nous avons vu que les applications OLAP sont destinées à une utilisation interactive, donc l’utilisateur est en droit d’attendre des temps de réponses très court pour ses requêtes.

Chose qui est assez simple s’il s’agit uniquement d’extraire l’information d’une base, de la reformater et de la présenter à l’utilisateur, mais qui prend largement plus de temps si une bonne partie du calcul est au service de la requête. Cela pourrait en effet, impliquer des consolidations de hiérarchies, des calculs de variance, des analyses de tendances, de dérivation de mesures, etc. Ce n’est pas le calcul arithmétique qui a un coût, mais les extractions des données concernées pour ces calculs.

Ici encore, même si les différences d’implémentation entre un système MOLAP et un système ROLAP sont importantes (la technique de préparation des données pour MOLAP et les tables de sommaires pour ROLAP) le phénomène d’explosion n’en ai pas la conséquence.

Les spécialistes OLAP ont déterminé que le problème est la résultante des relations multidimensionnelles croisées existantes dans toute application OLAP, du fait que les données de référence sont toujours très éparses. Par conséquent, les valeurs de référence distribuées peuvent contenir des centaines de cellules dépendantes du fait qu’elles apparaîtront dans des hiérarchies pour chaque dimension.

Le pré-calcul basé sur des données multidimensionnelles éparses peut donc engendrer un volume de stockage bien plus important que prévu et ceci encore indépendamment de la technologie de stockage utilisé.

Les études démontrent les ratios de multiplication suivants.

Plus les données de références sont éparses, plus le facteur de multiplication du volume d’une base multidimensionnelle est important.

Le graphique ci-dessus à été obtenu par l’exécution de 120 simulations avec des cellules de données générées aléatoirement.

Comme le montre le graphique ci-dessous, le phénomène de données éparses est fonction également des niveaux de hiérarchisation, ce qui amplifie le risque d’explosion.

Deux concepts sont proposés pour éviter ce problème d’explosion.

Eviter d’une part, de pré–calculer tous les objets multidimensionnels qui contiennent plus de 5 dimensions éparses. C’est–à–dire de permettre également des calculs à la volée. Et réduire d’autre part, la dispersion d’objets individuels en utilisant une approche de multicube, c’est–à–dire que chaque objet a un nombre minimum de dimensions nécessaires.

Différentes solutions ont été déjà apportées par les fournisseurs de solutions OLAP, comme un optimiseur d’agrégation par Informix ou l’optimisation automatique des agrégations par partitionnement fourni par les services OLAP de Microsoft.

ROLAP

Si l’architecture MOLAP constitue encore le choix technique le plus utilisé, l’alternative ROLAP acquière ses lettres de noblesses.

Le terme ROLAP, que nous avons précédemment expliqué, signifie que le serveur OLAP s’appuie sur une base de données relationnelle. Les sources de données sont entrées dans une base de données relationnelle, généralement dans le moule d’un schéma en étoile ou en flocon, ce qui permet d’améliorer les temps d’accès.

Le schéma en étoile consiste à grouper les indicateurs de base dans une table centrale appelée table de faits. Ces indicateurs partagent le même ensemble de dimensions et ne peuvent êtres déduits d’autres indicateurs. L’identifiant de cette table de faits est une clé multiple composée de la concaténation des clés de chacune des dimensions d’analyse. Autour de cette table figurent tous les éléments caractérisant les dimensions d’analyse. Ces caractéristiques sont regroupées dans des tables de dimension.

Le modèle en flocon est dérivé du modèle en étoile. Le flocon est simplement une étoile dont les branches sont elles-mêmes décomposées en sous - hiérarchies. Les tables de dimension sont donc éclatées en sous – tables. On introduit la notion de hiérarchie au sein d’une dimension.

Il y a un bon nombre de raisons à choisir une base de données relationnelle pour le stockage par rapport à une base multidimensionnelle. Un SGBDR est une technologie maîtrisée, et optimisée, il supporte de plus grandes capacités de données.

L’argument majeur contre l’utilisation de cette architecture est qu’exécuter des requêtes SQL dans ce genre de base de données afin d’obtenir des données récapitulatives, nécessite des requêtes complexes.
 

Les autres architectures : DOLAP, HOLAP

DOLAP (Destktop OLAP) décrit une catégorie de produits qui ne sont pas nécessairement connectés à un serveur. Ils peuvent essentiellement être exécutés sur un client avec la possibilité de s’appuyer sur une source de données sous la forme d’un ’’Data Cube’’. Le fait que ce cube de données soit construit et stocké localement sur une machine utilisateur, fait de l’architecture DOLAP un bon choix pour ceux qui utilisent fréquemment un ordinateur portable ou qui n’ont pas besoin de faire des calculs complexes pour lesquels la puissance d’un serveur serait nécessaire. HOLAP, pour Hybride OLAP est en fait une architecture hétérogène composée de tout ou partie des architectures précitées.

Nous verrons par la suite de cet exposé, l’état du marché OLAP et les offres de produits issues de ces architectures.

Les clients OLAP

Le client est le composant utilisé pour visualiser et manipuler les données d’une base OLAP. Un client peut être aussi simple qu’une feuille de calculs qui intègre des fonctionnalités OLAP telles le pivotement et le déroulement des données, il peut être un outil de reporting spécialisé ou encore une application OLAP spécifiquement développée pour des manipulations de données plus élaborées.

Le web est la forme la plus récente de client OLAP.

Tandis que le serveur est l’élément qui fournit l’épine dorsale d’une solution OLAP, les éléments en aval sont également importants. Le serveur peut être une bonne base pour une manipulation de données facile, mais si les éléments en aval sont compliqués ou incomplets dans leurs fonctionnalités, alors l’utilisateur ne bénéficiera pas de toute la puissance du serveur. Le client OLAP est si important, que certains fournisseurs OLAP se concentrent exclusivement sur les éléments en avale du serveur.

Ces applications clientes se caractérisent par une interface travaillée et conviviale, par la mise à disposition de fonctions et de structures prédéfinis, ainsi que par la proposition de solutions à des situations plus ou moins standards.

En particulier, les packages financiers sont très populaires. Une application financière préétablie permettra à beaucoup d’utilisateurs de se servir d’outils financiers les plus courants sans avoir à concevoir la structure de la base de données ni les rapports.

Les outils de reporting

Un outil de requête ou un outil de reporting est une forme simple d’accès à des données OLAP. Ce sont des outils conviviaux qui permettent la création de rapports par de simples cliquer - glisser.

Un éditeur de rapports traditionnel permet à un utilisateur de produire uniquement un document statique, tandis que les applications de reporting qui supportent la technologie OLAP produisent des rapports interactifs. Ces applications permettent les techniques du déroulement des données directement sur le rapport, et supportent les hiérarchies, etc.

Des add-ons OLAP sur les feuilles de calculs

Enormément de sociétés utilisent actuellement les feuilles de calculs pour effectuer différentes formes d’analyses sur les données entreprises. D’un certain point de vu, c’est la manière idéale de créer et de visualiser des données. Les analystes peuvent créer des macros pour traiter les données comme ils le souhaitent, des modèles peuvent êtres conçus pour la saisie de données et le traitement des calculs. Mais quoi qu’il en soit, on arrive à des rapports ‘’plats’’, dans le sens qu’une fois que le rapport est généré, il est difficile de le visualiser sous différents aspects.

C’est-à-dire que si un graphique contient des informations mensuelles, une personne qui désirera visualiser les données par jours devra recréer entièrement le graphique.

Lorsque les fonctionnalités OLAP sont rajoutées à ces feuilles de calculs, alors le même graphique peut être générer et n’importe quelle manipulation sur celui-ci peut être opérée pour obtenir l’information désirée.

Le web comme client OLAP

Le dernier arrivé dans la famille des clients OLAP est le web. Il y a un grand nombre d’avantages à déployer OLAP via le web. L’avantage le plus signifiant c’est qu’aucun logiciel particulier n’est nécessaire à une personne pour accéder à l’information. Ce qui permet d’économiser beaucoup de temps et d’argent pour une société.

On trouve actuellement des produits Internet - OLAP très différents. Certains permettent de créer facilement des pages web, mais ne sont pas très flexibles. D’autres permettent de créer des vues de données, puis de les sauvegarder sous le format HTML. Ceux-là permettront de visualiser des données sur le web, mais ne permettront pas de les manipuler de manière interactive. D’autres produits par contre, sont entièrement interactifs et dynamiques ce qui les rendent complètement fonctionnels. L’utilisateur disposera de toutes les fonctionnalités OLAP.

Il est donc nécessaire de définir clairement les besoins avant de choisir un déploiement OLAP sur le web.

Les applications

Les applications sont un type de client qui utilisent des bases de données OLAP. Elles sont similaires à des outils de requêtes ou à des outils de reporting comme précédemment vu, mais elles comportent des fonctionnalités beaucoup plus approfondies. Les applications OLAP sont plus robustes qu’un simple outil de reporting.

Le développement

Les fournisseurs de produits OLAP mettent souvent à la disposition de leurs clients des outils de développement afin qu’ils puissent créer leurs propres applications OLAP.

Il s’agit souvent d’un environnement de développement constitué d’une interface graphique qui supporte le développement orienté objet.

Il existe un guide API OLAP qui en est à sa deuxième version et qui est fournie par le conseil OLAP (MDAPI 2.0). Ce document modélise en UML toutes les méta données, requêtes et éléments d’infrastructure. Son but est de fournir aux clients tous les éléments pour développer eux-mêmes des outils de d’interrogations des bases de données OLAP.

Le MDAPI supporte les plates-formes JAVA et COM et fournie l’implémentation de session et toute la collection d’objet nécessaire. Il comporte également tous les éléments nécessaires à la connexion au serveur, à la synchronisation des opérations.

Sans avoir l’intention de présenter les 229 pages de ce document, il est intéressant à titre d’information de présenter le modèle de données MDAPI 2.0 :

Le MDAPI permet donc le développement de nouveaux clients OLAP, pour des besoins spécifiques aux entreprises. Différents environnements de développement sont proposés par les éditeurs de solutions OLAP.

Au-Delà de ces interfaces, il est intéressant de présenter un panorama des outils existants sur le marché.

Bien que la compréhension de ces différentes approches théoriques soit importante, il a fallu trouver un moyen objectif de les évaluer dans une logique de marché.

Le Conseil OLAP créé en janvier 1995 pour servir de guide industriel et d’interlocuteur avec les clients a développé pour cette raison l’APB-1. L’APB-1 est un banc d’essai qui permet de comparer quantitativement la performance des différents produits OLAP du marché.

L’APB-1

Le banc d’essai spécifie les paramètres d’une base de données ainsi qu’une dizaine de requêtes représentatives d’une activité normale en entreprise. Une simple mesure l’AQT (durée moyenne de requête) est générée en se basant sur le temps écoulé pour charger une base de données, pour procéder à l’agrégation des données et pour exécuter une requête. Des règles sont également définies pour déterminer les opérations autorisées pour les tests, comme le pré-calcul de données ou pour autoriser tel ou tel stockage de données pré-calculées.

Malheureusement l’APB-1 n’est utile que pour les serveurs OLAP, or une bonne partie du marché OLAP est constitué des clients et applications OLAP. De plus ce banc d’essai ne prend pas en compte l’aspect de la configuration matérielle ce qui lui laisse une valeur de référence toute relative.

L’offre du marché

ORACLE

Oracle est la société leader avec son offre Express avec une part de marché de 20.7% en 1997. Oracle a acquis Express de la société IRI Software en 1995.

Serveur

Il y a deux serveurs OLAP dans l’offre d’Oracle. Express Server constitue l’offre principale d’Oracle. Il fournit un système de base de données multidimensionnelle et constitue le noyau OLAP autour duquel tous les autres produits OLAP gravitent.

Oracle propose également Personnal Express qui n’est autre qu’un serveur Express fonctionnant localement sur un poste client.

Le point marquant qui le distingue des autres produits est la grande capacité de Express Server à s’appuyer sur une source de données très variée. Les données pour son système multidimensionnel peuvent être collectées à partir d’une base de données relationnelle par l’outil Express Relational Access Manager. Les données peuvent également être collectées d’autres MDDB, de feuille de calculs ou tout autre fichier ’’plat’’.
 

Administration

L’administration et la maintenance d’une base de données Express et effectuée par l’utilisation de Express SPL ou Stored Procedure Language. Ce langage de procédures stockées sert à définir des dimensions, à définir des routines d’extraction de données, à définir l’organisation de la base et à encore bien d’autres tâches.

Développement

L’utilisateur peut développer des applications OLAP spécifiques grâce à Express Objects. Cet outil fournit une interface graphique pour les développeurs et permet l’approche objet pour le développement d’applications. Une API est également fournie pour permettre aux développeurs d’accéder à une base de données Express de différentes manières.

Applications

Il y a deux applications clé en main proposées par Oracle : un analyseur financier et un analyseur des ventes. Ces applications utilisent Express Server pour accéder aux données et contiennent des fonctionnalités de reporting spécifiques aux milieux financiers. Elles ont également toute une panoplie de fonctions dédiées à l’analyse financière.

Web

Web Agent et Web Publisher sont les deux outils web proposés par Oracle. L’utilisation de l’un de ces deux outils permet à l’utilisateur de créer un site web qui s’appuie sur toutes les possibilités offertes par OLAP de manière dynamique ou interactive.

Web Agent est plutôt dédié aux développeurs et contient une palette de procédures prédéfinies dans Express SPL. Des sites web peuvent êtres créés comme des interfaces à l’accès à une base OLAP.

Web Publisher est dédié à l’utilisateur final. Il inclut Express Analyzer et permet à ceux qui ont une expérience en développement moindre à créer leurs propres sites web interactifs.

ARBOR

Arbor Software Corporation est le principal concurrent d’Oracle. Son produit principal est l’offre serveur : Essbase Server. Arbor est l’épine dorsale de beaucoup de produits OLAP, ce qui signifie qu’un certain nombre de fournisseurs de solutions OLAP s’appuient sur Essbase Server comme support de données en vendant leurs produits clients.

Comme exemples peuvent êtres cités la société Comshare qui propose un composant web au produit Arbor ou CrystalInfo développé par Seagate Software. 

Serveur

Le serveur OLAP d’Arbor est Essbase qui en est à sa version 5. Arbor a implémenté une variété de possibilité de sécurisation, en permettant par exemple à l’administrateur de spécifier des permissions d’une cellule donnée. L’utilisateur peut également être mené à entrer un mot de passe pour pouvoir avoir accès à une donnée particulière que ce soit en lecture seule ou en lecture/écriture. Les mots de passes peuvent expirer après un délai défini ou après une période définie d’inactivité de l’utilisateur. Toutes ces fonctionnalités permettent à l’administrateur d’avoir une politique de sécurité flexible pour sa base de donnée.
 

Les Outils

Arbor propose plusieurs outils connexes à son offre Essbase : Essbase Spreadsheet Add-in qui permet aux feuilles de calculs de bénéficier de toute la puissance de OLAP, Wired for OLAP qui est un outil d’analyse et de reporting, Crystal Info for Essbase qui est un outil de reporting et de planification et SQL Drill-Through qui permet aux utilisateurs de visualiser les données d’un SGBDR avec les fonctionnalités OLAP.

Applications

Arbor propose depuis peu Essbase Adjustment Module qui est une application qui assiste l’utilisateur dans la présentation de rapports.

Développement

Essbase Objects est un outil puissant que les développeurs peuvent utiliser pour créer des applications en utilisant Essbase comme support de données. Cet outil est orienté objet et permet l’utilisation de contrôles ActiveX.

Le code Essbase est compilé de manière optimale pour une utilisation du serveur Essbase. Il comprend également une extension pour les feuilles de calculs. Un API est disponible et permet l’interfaçage d’une base Essbase avec un programme C/C et Visual Basic.

APPLIX

La société Applix offre un produit unique dans le sens que leur serveur OLAP n’utilise pas de pré-agrégation de données ou d’extraction en batch. Elle a introduit le concept de RAP suivant lequel toutes opérations OLAP se fait en temps réel.

Serveur

Dans le serveur OLAP TM-1 d’Applix, seules les données explicites sont sauvegardées dans un cube multidimensionnel ce qui permet de conserver une taille de la base de données petite. Lorsque l’utilisateur exécute une requête, le serveur répond soit en extrayant la valeur ou en la calculant.

Le RAP a ses avantages et ses inconvénients. L’un des avantages est que la menace d’explosion de base de données est inexistante.

Naturellement ce concept semble à première vue contradictoire avec le concept OLAP. Mais finalement l’idée d’une MDDB est que si les données sont optimisées c’est pour obtenir des temps de réponses minimums. Le serveur OLAP TM-1 d’Applix utilise en fait la mémoire vive d’un ordinateur pour optimiser les données ce qui lui permet d’avoir des temps de réponses tout aussi court.

TM-1 permet cependant de stocker les vues qui nécessitent des temps de calculs plus longs et ce qui représente selon la société environ 10% de la taille de la base de données.
 

Client

Le client TM-1 est une interface basée sur une feuille de calcul ayant des fonctionnalités OLAP. Un nombre important de sociétés comme Comshare, Arcplan, Creeth, Richmon and Associates, fournissent des clients interfacé avec le serveur TM-1 dans leurs solutions OLAP.

Développement

L’API TM-1 et TM1- ShowBusiness fournissent des outils de développement pour des applications OLAP spécifiques. TM-1 ShowBusiness est une interface graphique permettant la programmation orientée objet.

Il comprend des outils de présentations graphiques et de reporting. Lotus Notes peut être interfacé avec une base TM-1.

Bien d’autres sociétés ont une offre MOLAP, mais celles présentées précédemment constituent la majorité des parts de marché.

Ainsi concernant l’offre ROLAP du marché, nous présenterons que le leader du marché dans ce segment.

MicroStrategy

MicroStrategy est le leader dans l’industrie ROLAP. L’utilisation d’un système de base de données relationnelle OLAP lui permet de gérer de très grandes bases, ce qui constitue un atout important.

Serveur

Le serveur DSS est le produit majeur de toute la gamme de produit de l’offre MicroStrategy. Il permet à ses clients d’accéder à une base de données relationnelle de manière multidimensionnelle. DSS Server comprend une grand nombre de pilotes qui lui permettent d’accéder à d’autres SGBDR (Oracle, DB2, Sybase, Red Brick, Informix, etc.) DSS Server supporte également les très grandes bases de données de l’ordre du téraoctet.

Client

DSS Agent est l’outil client de DSS Server. Une des fonctionnalités intéressantes de DSS Agent c’est qu’il utilise des agents intelligents pour automatiser des processus. Ainsi les tâches répétitives d’analyse des données seront automatisées.

DSS Executive utilise la puissance de DSS Agent pour fournir des fonctionnalités de reporting très élaborées et des outils d’analyse.

Développement

DSS Objects permet le développement de nouvelles applications OLAP autour de DSS Server. Cet outil de développement permet l’utilisation de langages tels que Visual Basic, Delphi et C/C pour accéder au serveur DSS Server.

Applications

MicroStrategy ne propose guère d’applications ou de suite logiciel. DSS Broadcaster est un simple outil qui permet de transmettre des informations d’une base vers différents canaux tels que le courrier électronique, le fax, le SMS sur les téléphones mobiles, etc.

COGNOS

Son offre est le produit DOLAP par excellence, ce qui signifie que la majorité des opérations sont exécutées localement par opposition à une configuration client / serveur.

Son produit : Impromptu est un outil de requêtes qui est utilisé pour extraire les données d’une base de données multidimensionnelle. Ces données sont ensuite transférées dans PowerPlay qui n’est autres qu’un cube, un support de stockage des informations sur une machine locale.

Les autres offres

La présentation précédente des offres OLAP n’est naturellement pas exhaustive, face à la multitude d’acteurs sur le marché.

Le tableau suivant présente néanmoins un récapitulatif des offres précédentes, ainsi que la présentation 3 autres sociétés.
 

L’arrivée de Microsoft sur le marché OLAP avec sa nouvelle offre Plato qui intègre des services OLAP dans SQL Server 7 produit un grand choc.

Ce n’est pas au niveau technologique que Microsoft a bousculé le marché, car Plato est un système hybride sur basant sur SQL serveur et réorganisant les données dans un mode qui facilite l’analyse. Les postes clients compatibles avec l’API OLE DB for OLAP pourront générer des requêtes et naviguer dans un volume multidimensionnel.

C’est essentiellement au niveau stratégie de marché que Microsoft ébranle le marché OLAP, car son offre représente un coût très modéré et le produit SQL Serveur est très répandu dans les PME. En fait, Microsoft banalise la fonction OLAP, la démocratise, une étape que tous les autres éditeurs du marché n’ont pas encore franchi.

Cependant bien des faits peuvent inquiéter ces mêmes entreprises à l’égard de cette technologie : je pense surtout à l’hétérogénéité des architectures, à l’atomicité des offres du marché et notamment au niveau des solutions applicatives.

Face à cette atomicité des offres, les entreprises devront faire des choix judicieux afin d’éviter les pièges et choisir le bon produit. A ce titre certains points devront êtres considérés :

D’où viennent les données ?

Une étude effectuée en Europe par Sqribe Technologies et Deloitte et Touche a permis de mettre en évidence plusieurs problèmes :

Une utilisation excessive de solutions applicatives

Une interaction d’un nombre toujours croissant de systèmes existants pour obtenir l’information.

Des difficultés inhérentes à l’utilisation d’outils décisionnels client-serveur jugés trop élitistes pour une diffusion généralisée.

Le marché OLAP évolue donc au niveau applicatif. On trouvera désormais deux types d’applications multidimensionnelles : les applications de reporting et celles destinées à l’analyse. Les premières permettent de naviguer dans les données de l’entreprise, notamment dans les données financières, et servent au pilotage de l’entreprise. Les deuxièmes permettent des modélisations complexes, utiles par exemple pour élaborer des budgets.

Dans notre réflexion sur OLAP, il est également facilement concevable, que la technologie OLAP n’en soit encore qu’à ses débuts, son coût est très élevé et les éditeurs ont chacun leur solution propre : l’offre OLAP actuelle s’adresse presque exclusivement aux grands comptes. Mais nous l’avons vu, l’arrivée de Microsoft sur le marché OLAP, va permettre de rendre la technologie OLAP accessible aux PME. Inévitablement cette arrivée va structurer et clarifier le marché. C’est en effet déjà le cas, puisque nous pouvons constater des opérations de rachats comme celle d’Arbor Software (8% du marché) par Hyperion (16.7% du marché), des opérations de fusions ou même d’assainissement du marché.

Quel que soit le destin de la technologie OLAP, cette vision conceptuelle de l’organisation des données en plusieurs dimensions dans une application informatique est néanmoins fascinante. Et on comprend bien dans cette idée, le désire idyllique de trouver une réponse la plus parfaite que possible aux besoins de l’utilisateur. Cette question essentielle qui trop souvent est oubliée par les Hommes du métier de l’informatique : à quoi ça sert ?

Informatiques Magazine : 15 mai 1998.

Informatiques Magazine : 15 septembre1998.

Informatiques Magazine : 6 novembre 1998.

Informatiques Magazine : 15 janvier 1999.

Oracle Express Server Datasheet, Oracle Corporation, 1997.

Adding Value to the Data Warehouse, Dave Menninger, Oracle, 1997.

Enabling Better Business Decisions, Oracle OLAP Technology, 1997.

The Essbase Product Family Datasheet, Arbor Software, 1997.

Increasing Corporate Intelligence with the WWW, Arbor Software.

TM-1 Datasheet, Applix, 1997.

An explanation of multidimensional terminology & technology, Pilot Software.

An Enterprise-Wide Data Delivery Architecture, MicroStrategy White Paper.

The Case for Relational OLAP, MicroStrategy White Paper.

DSS Server Datasheet, MicroStrategy.

HyperionOLAP Technical Data, Hyperion Software.

The OLAP Report: www.olapreport.com.

Database Explosion, Pendse Nigel, 17 janvier 1998.

Market Segment Analysis, Pendse Nigel, 18 janvier 1998.

OLAP Applications, Pendse Nigel, 18 Janvier 1998.

OLAP Architectures, Pendse Nigel, 18 janvier 1998.

Market Share Analysis, Pendse Nigel, 1998.

What's in a name?, Pendse Nigel, 1998.

The OLAP Council: http://www.olapcouncil.org/.

Providing OLAP (On-Line Analytical Processing) to User-Analysts, Codd, E.F., S.B. Codd, and C.T. Salley, E.F. Codd & Associates, 1993.

Oracle OLAP: http://www.oracle.com/st/products/options/olap

Arbor: http://www.arborsoft.com/

MicroStrategy: http://www.strategy.com/

Hyperion: http://www.hyperion.com/

Gentia: http://www.gentia.com/

Applix: http://www.applix.com/

Comshare: http://www.comshare.com/

Cognos: http://www.cognos.com/

The OLAP Report: http://www.olapreport.com/

The OLAP Council: http://www.olapcouncil.org/