Concevoir le cube OLAP

Par   Partagez : Envoyer le lien de cet article par e-mail   

Quels sont les défauts de conception les plus courants?

cube

Mettre en oeuvre le cube OLAP

Une base OLAP ne se conçoit pas sans une réflexion de fond préalable fondée sur les habitudes et besoins réels des utilisateurs.

En effet, il ne s'agit pas de chercher à sécuriser les "besoins futurs" en stockant un maximum de données et en multipliant le nombre de dimensions en partant du principe.

Actuellement je ne sais pas pourquoi , mais peut-être que quelqu'un, un jour, en aura besoin.

Ce principe, à l'origine de bon nombre d'usines à gaz en informatique, est la meilleure garantie d'une explosion de la base.

3 erreurs de conception

Nigel Pendse, co-fondateur de "l'Olap Report", un site qui fut une référence incontournable de la Business Intelligence au cours de la première décennie de ce siècle et qui a disparu depuis, a bien analysé ces travers de conception particulièrement courants. Dans un texte fondateur de la technologie Olap, une référence pour tous les concepteurs, il décrit et illustre ces erreurs de conception selon 3 axes principaux de dérives.
  1. Stocker un maximum de données
  2. pour autoriser tout type d'analyses
  3. Définir un grand nombre de dimensions
  4. pour faciliter les analyses
  5. Multiplier les agrégats
  6. pour améliorer les temps de réponse
Et pourtant, Pareto's still alive...

A l'usage, on constate que la majorité des requêtes ne portent généralement que sur un ensemble réduit de données. De surcroît, les analyses exotiques, si elles sont lancées lors des premiers jours d'utilisation pour tester la machine, restent plutôt exceptionnelles en usage courant.

C'est par cette identification que doit commencer l'étude de conception d'un cube OLAP.
Ce texte, écrit avant l'essor du Big Data (voir ici le dossier dédié), ne perd pas pour autant sa pertinence. La construction de modèle utilisable dans l'aide à la décision est d'une autre ampleur.

Les dérives du cube OLAP

L’expansion non maîtrisée constitue le principal problème des systèmes OLAP.
La tendance naturelle conduit à 3 erreurs de conception comme : essayer de stocker le maximum de données, de définir de trop nombreuses dimensions et de rechercher le meilleur temps de réponse.

Stocker un maximum de données

Les utilisateurs auront besoin de rapprocher de nombreuses données et de conserver un maximum d’historiques. Actuellement, avec un rythme de renouvellement accéléré des gammes de produits des entreprises, les données évoluent très rapidement et demandent des bases de plus en plus volumineuses.

Définir de nombreuses dimensions

Les dimensions doivent être prévues à l’origine du chargement de la base Olap. Pour éviter des impasses et faciliter les analyses, les utilisateurs ont tendance à définir de nombreuses dimensions pour un même ensemble de données. Souvent ces dimensions restent inexploitées et occupent une place inutile.

À l’analyse des bases existantes, on constate qu’elles contiennent de nombreuses cases vides et les données sont très clairsemées.
(La modélisation Big Data (voir ici le dossier dédié), est un tout autre sujet...)

Rechercher le meilleur temps de réponse

Pour être acceptable, un maximum de requêtes doit être traité en moins de 5 secondes. Quelques unes uniquement seront traitées en un temps maximal de 30 secondes. Au delà, c’est le domaine de l’inacceptable.

Pour un maximum de performance, de nombreux agrégats sont pré-calculés et stockés. Et, paradoxe, quelquefois, le nombre d’agrégats stockés dépasse le nombre de données initiales !
En résultat, les bases sont rapidement saturées et peu utilisables.
En complément pour des requêtes accélérées voir le in-memory, la fiche pratique est ici

À la base, une erreur de raisonnement

L’approche initiale des bases OLAP est dans le même esprit que les premiers data warehouse (voir ici le dossier complet) et part du principe que pour une plus grande efficacité, il suffit de mettre à la disposition des décideurs le maximum de données.
Ces derniers auront ainsi, selon ce principe, toute liberté pour effectuer tous les croisements qui leur sembleraient opportuns.

Ce raisonnement n’est plus possible et les systèmes conçus selon ce principe sont un échec. Les données doivent être structurées « intelligemment » dans les bases, en connaissance et avec compréhension des besoins réels des utilisateurs.

Une conception réfléchie

Nous ne bâtirons pas une architecture technologique extravagante en supposant qu’un décideur potentiel pourrait éprouver le désir de rapprocher des données totalement antinomiques.

Un jour, je posais la question à un prosélyte de ce type d’architecture. Je lui ai demandé quel pouvait être l’intérêt pour un décideur de terrain, de comparer les caractéristiques intrinsèques de la production d’une référence X, avec le résultat des ventes du mois dernier dans la zone Europe du Sud. Il m’avait répondu : « personnellement je ne le sais pas, mais je ne peux pas empêcher un décideur d’effectuer ce rapprochement s’il le souhaite. Il en tirera peut-être un enseignement et prendra LA décision pertinente ».

À première vue, l’argument semble de poids. Pourtant, c’est en cultivant le mythe de l’information « miracle » et cachée que l’on bâtit les « usines à gaz » peu performantes et peu adaptées pour l’usage courant du décideur en situation.
Avant de faire des recoupements tous azimuts, le décideur à besoin de réponses à des problèmes précis. Il est vrai qu’il aura tout intérêt à ne pas rester cantonné dans sa sphère et rien ne l’empêche de souhaiter rapprocher des informations qui, a priori ne sont en rien concomitantes.

Nous remplaçons à escient le terme données par information. Comme nous l’avons vu à l’étape 7 de la méthode Gimsi, l’enseignement sera beaucoup plus profitable en échangeant avec le professionnel concerné, une information construite et structurée, plutôt que de chercher à analyser des données externes à notre périmètre d’activité et donc peu porteuses de sens.
Ce texte a été écrit il y a déjà quelques années. Il est toutefois bon de noter que le Big Data, non pas en théorie mais en pratique, n'a rien changé à ce raisonnement : voir notamment les limites du Big Data

Livre recommandé

Les principes de Olap expliqués. Exemples pratiques avec Oracle Essbase. Comment conduire le projet, bâtir la base multidimensionnelle. Techniques, conseils et recommandations pour configurer et optimiser la base.

Oracle Essbase & Oracle OLAP: The Guide to Oracle's Multidimensional Solution Oracle Essbase & Oracle OLAP
The Guide to Oracle's Multidimensional Solution

Michael Schrader
McGraw-Hill Osborne Media
524 pages
Prix : 55 Euros
Dispo chez : www.amazon.fr & Format Kindle


Partagez cet article...

Envoyer le lien de cet article par e-mail   
(total partages cumulés > 165)

Commentaires lecteurs...

Pour commenter en tant qu'Anonyme, cliquez sur "Commencez la discussion" Puis sur "Nom", tout en bas apparaît alors une case à cocher : "Je préfère publier en tant qu'invité"

La reproduction ou la traduction totale ou partielle de ce texte, images et documents est formellement interdite. Voir ici les conditions pour publier un extrait sur votre site ou blog. Ce texte et les images et documents qu'il contient est déposé auprès de l'IDDN

Suivez aussi les news du portail sur Twitter et rejoignez-nous sur Facebook

Google+    Twitter    Facebook

Excel ® est une marque déposée de Microsoft Corp ®
Gimsi ® est une marque déposée de Alain Fernandez



Copyright : Alain FERNANDEZ ©1998-2017 Tous droits réservés Mentions légales


Management de l'entreprise
  Suivez-nous :   Google+   twitter+  Facebook  Linkedin    e-mail  
»» Toutes les fiches Piloter.org »»