Connexion

Connexion à votre compte

Identifiant
Mot de passe
Maintenir la connexion active sur ce site

INTEGRATEUR DE SOLUTIONS OPEN SOURCE,

BUSINESS INTELLIGENCE, GESTION DE DONNÉES, OUTILS COLLABORATIFS.

Découvrez Tableau Server 8

Altic vous propose des Dataviz construites sur des données publiques. Profitez de notre démonstration pour tester Tableau Server 8

Exploitez vos gros volumes de données

Avec les technologies Big Data, transformez les masses de données inutilisées en nouvelles opportunités.

Formez-vous aux outils de datavisualisation

Suivez nos formations Tableau Software.

Ne parlez plus en chiffres !

Dynamiser vos reporting avec SpagoBI et ses moteurs analytiques.

Cartographiez vos Données

Accédez à une nouvelle dimension.

Travaillez collaborativement sur vos projets

Arrêtez de perdre du temps, centralisez et partagez les informations de vos projets.

Actualités

L'OLAP, histoire, caractéristiques et état du marché : de Codd à Hyde !!

  1. Historique de l'OLAP
  2. Les grands principes de l'OLAP
  3. État du marché

 

La gestion de l'information réclame forcément, d'une façon ou d'une autre que celle-ci soit stockée sur un support. Au début de l'informatique moderne, les entreprises ont dû s'organiser et choisirent d'enregistrer l'information sous forme de fichiers dit « indexés » ! C'est ainsi que au sein de grandes organisations par exemple, on a vu naître des applications pour les différents domaines traités. Évidemment toutes ces applications fonctionnaient de manière très déconnectée ! Dans ce contexte, chacun des sous-systèmes gère quelque part une partie de l'information qui est, elle aussi, manipulée par un autre service, une autre division de l'entité.


Toute cette redondance d'information a poussé la recherche en informatique à modifier la donne ! Le Docteur Edgar F. Cood, alors employé chez IBM, publie un papier,« A Relational Model of Data for Large Shared Data Banks », en 1970 qui régente les fondations des bases de données relationnelles modernes.

Par un mécanisme de relations entre entités, la répétition de l'information connue jusqu'alors est enfin écartée

 

Le modèle proposé en profite pour simplifier l'accès à la donnée. Toutefois, ce n'est qu'à partir des années 1980 que sa théorie se traduit dans les logiciels de bases de données. C'est entre autre grâce à son invention que toutes les informations associées à un achat de billet sur Internet ou aux courses réalisées dans les supermarchés peuvent être si facilement et si rapidement sauvegardées.

 

 

 

 

 



Depuis le débuts des années 1980 et avec une explosion au milieu des années 1990, les entreprises s'équipent de solutions de gestion et stockent un volume d'information qui s'agrandit un peu plus chaque jour. Rapidement apparait l'idée d'exploiter toutes ces données afin d'optimiser la décision. Naît ainsi l'informatique décisionnelle dont le but est de collecter, consolider, synthétiser l'information pour aider à la prise de décision.

Ce secteur de l'informatique repose en grande partie sur un stockage en base de données. Il s'agit entre autre de procéder à des calculs de type statistique, d'en restituer le résultat sous forme de graphique ou rapport. La mise à disposition de ces derniers sont d'autant plus rapide que les accès aux données le sont. Or le modèle relationnel a vite perdu les bénéfices initiaux qu'il avait gagnés vis à vis des fichiers indexés. En effet, les développeurs d'applications ont complexifié la modélisation « entités – relations » ! En conséquence elle n'est pas du tout accessible (compréhensible) aux utilisateurs finaux d'applications ! De plus, cette approche du développement va à l'encontre d'une interrogation intuitive et efficiente de l'information enregistrée dans le système relationnel.

Partant de ce constat, le Docteur Edgar F. Cood, lui-même, publie un papier intitulé « Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate » ! Il y dresse cette fois les lois qui gouvernent les technologies d'analyses croisées. Sa publication n'est toutefois pas la première tentative de créer un environnement pour ce domaine. Des systèmes tels que APL, Express, System W, Metaphor, EIS, parfois encore utilisés de nos jours, mettaient déjà en œuvre certains principes de l'OLAP. En 1993 quand parait son article, l'accueil est très controversé parce qu'il répond à une étude commandée par une firme logicielle connue aujourd'hui sous le nom  d'Hypérion. Quoi qu'il en soit, aujourd'hui ces règles, dont 12 sont très connues et 6 autres ajoutées plus tard en 1995 toujours par le Docteur Edgar F. Cood, coordonnent la conception de système OLAP :


Caractéristiques Basiques

  • Modèle Conceptuel Multidimensionnel : le modèle OLAP est par nature multidimensionnel ! Il se doit de faciliter le forage de données.
  • Manipulation Intuitive des données : la lecture et la modification des données doivent rester simples. Ici, cette règle n'évoque pas directement les feuilles de calculs mais le rappelle fortement.
  • Accessibilité : OLAP comme un médiateur : Codd imagine l'OLAP comme un tout capable de se connecter à des sources hétérogènes de données avec un accès utilisateur unique,
  • Extraction vs Interprétive
  • Modèle analytique OLAP : pouvoir entre autre paramétrer un rapport, classifier, hiérarchiser la donnée. Codd pensait certainement déjà au datamining.
  • Architecture client-serveur : avoir la possibilité que plusieurs types de clients puissent se connecter à un serveur de données OLAP.
  • Transparence : les données stockées sur un serveur OLAP doivent être simples d'accès jusqu'à offrir une interface vers les feuilles de calcul.
  • Multi-Utilisateurs : le système doit être capable de répondre à des demandes concurrentes.


Caractéristiques Spéciales

 

  • Traitement de données non-normalisées : référence aux sources hétérogènes de données, par exemple les environnements dénormalisés, auxquels peut se connecter un serveur OLAP. Codd imagine l'impossibilité de mettre à jour les données. Cette règle semble de moins en moins respecter. Les éditeurs offrent cette possibilité dans le cadre de la simulation : changer la valeur d'une cellule de son analyse croisée pour en déduire l'impact sur les totaux et la répartition des chiffres.
  • Stocker les résultats des analyses OLAP : les séparer des données sources : ici Codd se penche plus sur la méthode que sur le serveur OLAP lui même. Il ne conçoit pas la possibilité d'ériger son système OLAP directement au sein de son système opérationnel (transactionnel). De nombreux auteurs ont longtemps défendu ce point de vue. Aujourd'hui les performances machine pourraient transformer cette vision. Sans compter que la nouvelle version Oracle 11 arrive avec « Active Data Guard » qui maintient à jour au sein d'une même instance de base données une réplication qui peut être accédée uniquement en lecture.
  • Extraire les valeurs manquantes : toutes les valeurs absentes sont remplacées de façon uniforme. Il s'agit de distinguer les valeurs manquantes de celle qui valent 0.
  • Traiter les valeurs manquantes : à rapprocher de la règle précédente. Les valeurs manquantes ne sont généralement pas pris en compte par les analyseurs OLAP : pas d'intersections entre l'ensemble des dimensions !


Caractéristiques de Reporting

 

  • Reporting flexible : l'utilisateur peut disposer comme il le souhaite des dimensions. La plupart des produits du marché offrent une manipulation conviviale des dimensions aux utilisateurs.
  • Performance uniforme des rapports : le nombre de dimensions, le volume de données manipulées ne doivent pas affecter la constance des performances de restitution des résultats. Pour maintenir cette uniformité de la performance, il faut préférer travailler directement avec un niveau agrégé de l'information dans certains cas.
  • Ajustement Physique Automatique : le serveur OLAP doit être capable d'auto-ajuster l'espace disque qui lui est nécessaire. Peu d'éditeurs ont mis en place cette règle. A défaut d'être automatique de nombreuses bases de données possède le « partitionnement » ; il facilite la gestion d'ajout ou de suppression d'unités de stockage.


Contrôle des dimensions

 

  • Dimension générique : une dimension doit avoir la même signification selon les différents contextes auxquels il peut être associé. Ralph Kimball l'un des pères du data warehousing parle lui de « dimension conforme ».
  • Nombre de dimensions et de niveaux hiérarchiques illimités : techniquement aucun produit ne peut répondre à cette règle. Ralph Kimball pense quant à lui que le nombre maximum de dimensions qui décrivent un fait ne doit pas excéder 15. Si le nombre de dimensions et de hiérarchies sont trop important le modèle risque d'être incompréhensible à l'utilisateur.
  • Opérations sur les analyses croisées non-restreintes : en OLAP les opérations coïncident d'abord avec des fonctionnalités d'agrégation (somme, comptage, ...). Cependant tous types d'opérations doivent être possibles, même des calculs complexes.


Le marché de l'OLAP se divise en trois grands courants qui se différencient quant à la façon dont sont sauvées physiquement les dimensions :

  • ROLAP  - Relational OLAP : les dimensions sont stockées au sein d'une base de données relationnelle. Par contre le schéma logique reste multidimensionnel.
  • MOLAP – Multidimensional OLAP : les données sont physiquement stockées sous forme de dimensions.
  • HOLAP – Hybride OLAP : le moteur d'analyse embarque les deux approches.


En 2007 le marché a radicalement changé. D'abord parce qu'il s'est concentré ! Oracle a acheté Hypérion un des leaders du marché, ensuite ce fut au tour de Business Objects par SAP et pour finir IBM qui n'a pas résisté et a récupéré Cognos. Si bien que désormais les cinq principaux acteurs du marché réalisent plus de 90% du chiffre d'affaires du secteur.

olapmarket1
Microsoft n'est pas resté en dehors de ce secteur puisqu'il truste la première place.

olapmarket2

Le marché continue à progresser toutefois bien plus doucement qu'au début. En 2008, les perspectives pour ce marché avoisinaient les 8 milliards de dollars. Microsoft bénéficie de son large parc d'outils bureautiques installés avec lequel sa plate-forme d'informatique décisionnelle se trouve très intégrée. Qui plus est, son serveur de données SQL Server a longtemps embarqué un moteur OLAP pour lequel l'éditeur ne réclamait pas de coût de licence supplémentaire.

2007 est aussi l'année où le marché a commencé à considérer les acteurs open source. A ce titre, il faut saluer le travail accompli par Julian Hyde qui est le leader du projet Mondrian. Julian Hyde a implémenté un moteur ROLAP en suivant les principes de l'open source. Il a ouvrert le projet très tôt et assez rapidement de nombreux autres projets ont embarqué son moteur, ce qui contribue au succès de cette brique OLAP.
Mondrian est écrit en Java et interprète des requêtes MDX pour les transformer en SQL, le langage d'interrogation des bases de données relationnelles.
Lors de l'initialisation de son projet le langage MDX, inventé par Microsoft, n'était pas un standard. Peu de grands acteurs l'avaient intégré à leur moteur tel Hypérion ! L'histoire est en passe de donner raison à Julian Hyde quant au choix du MDX. Oracle, longtemps réfractaire, montre finalement un intérêt pour ce langage. MDX deviendrait un standard de fait ce qui peut encourager son apprentissage et sa vulgarisation.
Il faut par ailleurs noter que le langage MDX fait aujourd'hui partie d'un ensemble plus large nommé XMLA, qui spécifie comment interroger une base de données OLAP au dessus du protocole Internet HTTP. XMLA, pour « XML For Analysis », est une spécification que Microsoft a rendu public.

Désormais l'ensemble des conditions est réuni pour qu'émerge l'interopérabilité dans le requêtage des serveurs de données OLAP. Tout comme l'est SQL pour les systèmes de base de données relationnelles.


Depuis la création de Mondrian, Jedox, un éditeur allemand, a libéré un serveur MOLAP, Palo, qui lui aussi sait dialoguer selon le protocole XMLA avec le langage MDX. Ce projet paraît là encore présenter des perspectives très intéressantes. En effet, l'éditeur de la solution est partenaire de SAP, le leader mondial des ERP, qui semble lui porter un certain soutien.

La communauté open source cherche à tirer son épingle du jeu. Julian Hyde pense qu'il a à apprendre du projet Palo et s'est déjà rapproché de l'équipe allemande pour une collaboration concernant par exemple la possibilité de mettre à jour les cellules d'une analyse croisée. Cette fonctionnalité permet que l'analyse croisée soit davantage interactive notamment pour ce qui est des simulations.

Les éditeurs traditionnels n'ont pour l'instant pas pris la mesure des projets open source. Toutefois, cet éco-système très vivant offre au marché de vraies alternatives dans le choix de leur serveur OLAP.

 

Article par Charly Clairmont, directeur technique d'ALTIC

Avril 2009

Les prochaines formations

Sessions de formations inter-entreprises prévues pour la fin du premier semestre, renseignez-vous via notre formulaire de contact.

Les événements à ne pas manquer

  • /component/allevents/display/event/default/72-solution-linux-2014Solution Linux 2014 - Les conférences ALTIC (21-05-2014)
  • /component/allevents/display/event/default/71-big-data-paris-2014Big Data Paris 2014 : Cas client: Avencall et la solution XIVO (02-04-2014)