Principe de l'analyse ROLAP

[fhy]

Bonjour à tous,
Je cherche a mieux comprendre la démarche ROLAP

Or, dans le dossier du journal du net sur la BI on trouve la définition suivante sur le ROLAP :

ROLAP (Relational OLAP) renvoie à une base relationnelle classique structurée pour réagir à la manière d'une base OLAP. Critiquée pour sa faible performance, elle serait néanmoins mieux adaptée à de grandes quantités de données

Peut on donc dire qu'il s'agit de pseudo OLAP et qu'il n'y a dans ce cas pas de génération de cube en temps que tel mais que tout se passe par du requetage(sql) sur les datamart modelisé de façon dimentionnelle ?

Merci d'avance d'essayer d'éclairer ma lanterne

A+

[Pir-Ax]

je vais essayé d'être clair, mais c'est pas simple. Une base OLAP est une base qui te permet de trouver une valeur à partir de coordonnées (ex : CA pour 1 Client / 1 mois données) où X est le client et Y le mois. C'est donc 1 cube.

Une base ROLAP est une base de données décisionnelles classiques & relationnelles qui te permets d'obtenir ta donnée (ex : CA pour 1 Client / 1 mois données ) soit par agrégation de ton CA de ta table FACTURE pour ce client pour le mois) soit directement la récupération d'un enregistrement (1 ligne) si tu utilises une table d'agrégation mensuelle.

Des outils comme BO, Essbase passe par la notion de Cube ou Univers (olap). Par contre des outils comme Hyperion Intelligence Reporting attaque directement la base de données décisionnelles pour restituer les données. En fait, tout est question de taille / Volumétrie des données pour choisir la meilleure façon de faire.

Il existe maintenant des base HOLAP (H=Hybride) qui te permettent d'avoir dans un premier temps un cube en frontal (rapide à l'exécution) et qui peuvent aussi récupérer les données dans une base classique pour plus de détails.

En espérant avoir pu t'aider.

Pir-Ax

[Paul_S]

Bonjour fhy

Votre définition est juste, permettez-moi de la compléter :

La technologie M-OLAP exige une base de données modélisée en conséquence : des pré-agrégations sont effectuées au préalable pour chaque combinaison possible des valeurs des axes d'analyse.
Exemple, un CA est exprimé par Famille de produits, sous famille, catégorie client, année, trimestre, mois, etc ...
Rappel, Axes d'analyse les + courants et leur division hiérarchique :
- Temps (Année / Trimestre / Mois / Jour)
- Géographique (Pays / Région / Département / Ville)
- Marché (Segment / Catégorie ..)
- Produits (Famille / Sous famille / type)
...
Le nombre d'axes d'analyse et de niveaux par axe n'étant pas limité.

Les caractéristiques de cette technologie sont les suivantes :
- Accès aux informations extrêmement performant, car théoriquement, toutes les pré-agrégations sont effectuées
- Nécessite des ressources conséquentes pour l'administration de la base : plus pointue, langage pas SQL mais MDX
- Licences complémentaires,
- Espace de stockage plus important,
- Temps d'alimentation et procédures d'alimentation conséquents,
- Outil de requêtage en adéquation

A l'inverse la technologie R-OLAP va effectuer à la volée les pré-agrégations.
Entendons nous bien, il ne s'agit pas de cumuler des lignes de factures à partir des bases transactionnelles, mais d'interroger des tables relationnelles intégrées dans un Datawarehouse, comportant des pré-agrégations.
Les caractéristiques sont les suivantes :
- Permet la mise en oeuvre d'applications de BI extrêmement rapidement.
- Ne nécessite pas de ressources complémentaires
- Est ouverte, à l'instar d'une base M-OLAP ou chaque éditeur possède son propre langage d'administration.
- Solution évolutive et interactive: une modification (rajout d'un indicateur, d'une colonne) s'effectue très rapidement sans altération physique du datawarehouse.

Pour conclure, tout est affaire d'adéquation par rapport aux besoins de l'entreprise et à ses resources :

Une grande entreprise possédant un service informatique conséquent avec une expertise soutenue des bases de données, et historisant des données depuis quelques dizaines d'années, peut nécessiter pour des analyses de comportement client par exemple, la mise en place d'une structure multidimensionnelle.

A l'inverse, pour une PME qui souhaite mettre en place quelques applications de BI classiques (reporting commercial, financier et budgétaire, qualité ...)
la technologie R-OLAP est amplement suffisante et accessible.

Les deux technologies cohabitent parfois : M-OLAP permet d'effectuer le reporting de masse et répond à 80% des besoins, alors que le R-OLAP constitue un outil souple pour le reporting Ad-hoc ou opérationnel.

Cldt,


Paul_S

[fhy]

Bonjour à vous deux , merci pour vos réponse, et désolé pour ma réaction tardive.

Vos explication vont dans le sens de ma vision des choses.
Ceci dit, pour les demarches MOLAP on parle systemetiquement de requete MDX,
mais je suppose qu'il existe d'autre language propriétaire.
Je pense que la notion de MOLAP n'est pas lié au language de restitution, mais avec le mode de stockage final en l'occurence un cube
avec toutes les préaggregations possibles.

Quant à la demarche ROLAP on pointe sur des base effectivement relationnelle mais dimentionnelle,
Donc peut on dire qu'un BO pointant sur un datamart entre dans le cadre ROLAP
Si ce n'est pas le cas, pourquoi ?

Encore merci pour vos réations

Bonne Journée

[yphilogene]

Personnellement, je n'ai travaillé qu'avec les technologies Cognos jusqu'à présent.

Il y a 2 ans, chez Cognos, d'un côté on avait les cubes (Powerplay/Transformer) et de l'autre les tables (ReportNet/Framework Manager). Depuis Cognos 8, Framework Manager a été enrichi de possibilités de modélisation DMR (Dimensionnally Modelled Relational). Le principe est de construire un modèle en étoile relationel, puis d'ajouter une couche dimensionnelle par dessus. C'est finalement assez simple à développer et non limité en terme de volumétrie puisque ce sont bien les tables qui sont interrogées. En revanche, certaines fonctionnalités sont manquantes par rapport à ce que permet Transformer (modéliseur de cubes).

A l'utilisation, un modèle DMR s'utilise de la même façon qu'un cube dans Analysis Studio ou Report Studio (outils d'analyse Cognos 8).

Technologiquement, j'avoue que je ne sais pas très bien quel langage de requête est utilisé pour interroger un modèle DMR. Est-ce du MDX comme pour les cubes, est-ce du SQL, est-ce un mix des deux? J'ai du mal à comprendre comment avec du SQL on pourrait obtenir un comportement de type cube au requêtage.

[Paul_S]

Bonjour à tous

Envoyé par fhy

...
Quant à la demarche ROLAP on pointe sur des base effectivement relationnelle mais dimentionnelle,
Donc peut on dire qu'un BO pointant sur un datamart entre dans le cadre ROLAP
Si ce n'est pas le cas, pourquoi ?

Il faut bien faire la distinction ente la structure physique, et la fonction de la base de données interrogée.
En l'occurence, un Datamart (qui rappellons le, est un sous ensemble 'spécialisé' du Datawarehouse') peut indifférement être de type relationnel, ou bien multidimensionnel. Tout est affaire d'adéquation par rapport au besoin.

OLAP définit un mode d'analyse, caractérisé par la possibilité d'offrir à l'utilisateur final des déplacements dynamiques au sein d'un référentiel de dimensions (Drill, permutation et rotation d'axes ...)
Le préfixe R, M, H encore D, définit la nature de la base de données sur laquelle s'appuie le moteur de requêtes pour effectuer son analyse OLAP : multidimensionnelle, relationnelle, hybride ou encore Desktop.

Donc un BO pointant vers un datamart relationnel, pour exécuter des analyses OLAP, peut effectivement être qualifié de démarche R-OLAP.

Envoyé par yphilogene

...
...Technologiquement, j'avoue que je ne sais pas très bien quel langage de requête est utilisé pour interroger un modèle DMR. Est-ce du MDX comme pour les cubes, est-ce du SQL, est-ce un mix des deux? J'ai du mal à comprendre comment avec du SQL on pourrait obtenir un comportement de type cube au requêtage.
...

Un post délivré sur cet excellent forum (discussion Quelle BDD pour utiliser MDX ?) est particulièrement bien formulé (ce qui est rare de la part d'un public plutôt technique...) et mérite d'être souligné :

Envoyé par selecta

...
La requête MDX n'est pas posée directement à la base, cette requête est traduite en 1 ou plusieurs requêtes SQL par la couche middle sollicitée par le requêteur MDX.

Un exemple parmi d'autres est le couple JIVOT - MONDRIAN.
Mondrian serveur OLAP reçoit de JPIVOT les ordres MDX, traduit ces ordres pour interroger la base de données qui peut être SQL SERVER, SYBASE, MYSQL, ORACLE et bien d'autres par des ordres SQL classiques.

En résumé aucune base n'est attaquable par du MDX sauf si tu passes par un produit TIER.
...

Cdlt,

Paul

[yphilogene]

Bon, ça reste flou dans qu'on ne rentre pas dans le détail technique j'ai l'impression.

Je dirais que le R-OLAP est caractérisé par une absence de cube (fichier physique différent d'un ensemble de tables issues d'une base de données).

Pour moi, on peut interroger un cube directement avec du MDX. Ce que Cognos parvient à faire avec le DMR, c'est probablement traduire une requête MDX en de multiples requêtes SQL. Donc, il y a bien un pont (un moteur) entre la base relationnel et l'analyse dimensionnelle (OLAP).

A partir du moment où une technologie propose ce type de moteur, on peut considérer qu'il propose du R-OLAP.

[fhy]

Bonjour a tous,

Je suis d'accord avec les différentes réponses données à mon post (ce qui me rassure).
Pour cognos par compte si il y a un cube de données en tant que tel pour moi il s'agirrait plutot de molap

non ?

[yphilogene]

Depuis la version 8 de Cognos, il y a:

- les cubes M-OLAP modélisés avec Transformer,
- le modèles R-OLAP modélisés avec Framework Manager.

Du point de vue utilisation dans les outils de reporting Cognos, un cube M-OLAP et un modèle R-OLAP ont le même comportement et sont présentés de la même façon.

Avantages R-OLAP: Pas de cubes à générer, pas de contrainte volumétrique, sécurité héritée de la couche inférieure...

Inconvénients R-OLAP: Moins performant qu'un cube (ça reste du SQL derrière), des défauts de présentation (impossibilité de pré trier les éléments dans une dimension)...

[Paul_S]

Envoyé par yphilogene

Inconvénients R-OLAP: Moins performant qu'un cube (ça reste du SQL derrière), des défauts de présentation (impossibilité de pré trier les éléments dans une dimension)...

Bonsoir
J'apporte une précision, mais il me semble que ce débat sera éternel et sans fin...
Que ce soit du M-OLAP ou du R-OLAP, ça restera toujours du SQL derrière. Le M-OLAP présente une couche intermédiaire qui transforme des instructions dites multidimensionnelles (ex : MDX) en SQL de base vers une base de données ou là, il existe une différence : sont présents physiquement dans la base, l'ensemble des n-uplets enviseageables par les multiples combinaisons des dimensions.


Quant au pré-tri, je ne saisis pas (ou quelquechose m'aura échapé) : Il est tout a fait possible de trier des données métriques dans une dimension R-OLAP.



Je suis par ailleurs totalement d'accord sur l'aspect et le comportement des deux technologies.

Cdlt,

Paul

[yphilogene]

Au temps pour moi, je ne saisis pas encore tout à fait comment ça fonctionne derrière le MDX.

Je me suis simplement dit que si on génère un cube, donc un fichier .mdc chez Cognos, cela doit bien avoir un avantage par rapport à un ensemble de tables, notamment dans la lecture du cube. Est-ce qu'un cube est interrogé en SQL? Je ne crois pas. Si?

En tout cas, pour le R-OLAP de Cognos, dit DMR, il me semble évident que c'est du SQL derrière, puisque ce sont bien des tables qui sont requêtés donc le SQL est obligatoire.

Concernant le prétriage, lorsque j'ai développé un modèle DMR il y a un an, avec la version Cognos 8.1, il m'a semblé qu'il n'était pas possible de forcer l'ordre d'affichage des membres dès la construction du modèle. Par exemple, dans une dimension temps, j'interrogeais la colonne YEAR et Framework Manager me construisait un niveau avec 2005, 2008, 2007 dans un ordre aléatoire. Rajouter un ORDER BY dans la requête sous-jacente n'avait aucun impact. Le support Cognos l'a reconnu comme une demande d'amélioration. Je ne sais pas si cela a évolué avec la nouvelle version 8.3.

[Paul_S]

yphilogene,

Cognos n'est pas le seul ...
Sur une autre discussion, j'ai cité deux autres solutions R-OLAP qui sont tout a fait efficaces :
- Latitudes-Bi (http://www.latitudes-bi.com)
- Microstrategy (http://www.microstrategy.com)

Cdlt,
Paul

[yphilogene]

Je n'ai pas cherché à faire de la pub gratuite pour la technologie Cognos. Je ne travaille d'ailleurs pas pour cet éditeur.

N'ayant jusqu'à présent manipulé que cette technologie, je n'ai pu apporter ma contribution à ce topic qu'en expliquant comment Cognos implémente le R-OLAP. Je ne doute pas qu'il ne soit pas le seul sur le marché. J'irais même jusqu'à dire qu'il y a encore beaucoup à faire.

Si tu connais Micro Strategy par exemple, je te laisse le soin d'en parler plus précisemment afin d'illustrer un peu plus ce topic d'exemple concret.

[Paul_S]

Pas de souci, ma remarque n’était pas non plus orientée.
Historiquement, Microstrategy a été un des pionniers de la BI, notamment aux US. Ils ont initié le modèle R-OLAP, puis en on fait leur cheval de bataille.
Leur moteur était extrêmement bien optimisé. Il existe aujourd’hui outre atlantique, de nombreuses entreprises qui utilisent Microstrategy, en complément d’un entrepôt Terradata par exemple, qui ont des temps de réponse extrêmement performants. La solution est moins bien connue en France.

Les technologies avancent. Les éditeurs de bases de données fournissent aujourd’hui des modèles MDX vulgarisés et d'une mise en oeuvre plus accessible. Le discours de Microstrategy a donc évolué : ils ont complété leur offre commerciale par des connecteurs vers ces structures (MDX Microsoft et Oracle, Essbase, SAP BW …)
Pour en revenir au R-OLAP, il présente aujourd’hui une alternative très intéressante dans le reporting dit de ‘libre-service’, c’est à dire en complément par exemple d’un entrepôt très lourd et peu souple.

Dans les mois prochains, peut-être Cognos complètera-t’il sa gamme par l’interrogation directe de structures OLAP IBM db2400, tout en permettant toujours le mode relationnel via le Framework Manager. Qui sait ?
Il me semble que pour les éditeurs, l’avenir est là : offrir d'une part un reporting de masse lourd basé sur un entrepôt multidimensionnel (de type BW), et compléter d'autre part par un module d’interrogation souple (BO, Cognos, etc…)
En tout état de cause, c’est la voie qu’ils suivent…

Cdlt,
Paul