Actualités : analyse de données, Business Intelligence, Data Science, Big Data
Forums, dernières contributions

cubes ROLAP / MOLAP / HOLAP

 stani
Mardi 13 Février 2007

Version imprimable
[Ignorer]
bonjour, je reviens sur un de mes derniers posts :

Mes questions portent sur le stockage des donénes, si j'ai tout bien compris :

- un cube MOLAP est un cube multidim dont les données sont stockées dans un fichier dédié de type XML

- un cube ROLAP n'est en fait rien d'autre qu'une table d'agrégats (simple ou en schéma étoile/flocon) stockée dans une base de données relationnelle classique

- pour un cube HOLAP, comment sont stockées exactement les données du cube ?? d'apres ce que j'ai compris les données sont stockées dans le cube multidim mais avec accès possible aux lignes de détail dans la base de donénes ralationnelle, comment se fait la liaison, la 'jointure' entre les 2 pour retrouver ses petits ?

Merci de vos infos !!
 MONCEL Sébastien
Mercredi 14 Février 2007

Version imprimable
[Ignorer]
Bonjour Stani,

On ne parle pas de cube MOLAP, ROLAP ou HOLAP, mais plutôt d'approche MOLAP, ROLAP ou HOLAP.
Un cube sous entend qu'on a une approche MOLAP (ou HOLAP) : on ne parle jamais de cube dans un approche ROLAP.
Pour reprendre tes points :
- au sujet du MOLAP : 'multidim' est un qualificatif superflu lorsqu'on parle de cube. En ce qui concerne le format, il n'est pas forcément de type XML.
- au sujet du ROLAP : non, ce n'est pas forcément qu'une (ou plusieurs) tables d'agrégats, il peut y avoir des tables dans le modèle de données qui soient de granularité transactionnelle (le plus fine possible). C'est le moteur de ton outil décisionnel comme Micorstrategy qui va déterminer dynamiquement quelle va être la table la moins couteuse pour répondre à la restitution (rapport) demandée par l'utilisateur (et c'est là toute la puissance de cette approche qui, à mon avis, est bien plus pertinente que l'approche MOLAP).
- au sujet de l'HOLAP, je n'ai pas eu l'occasion d'avoir affaire à ce contexte technique, mais j'imagine que le moteur de l'outil exploitera, selon la restitution demandée, soit des cubes (pour les restitutions à forte granularité), soit des tables relationnelles (granularité fine). Mais là aussi l'intérêt d'une telle approche me parait assez 'fumeux' étant donné que les performances d'une table agrégée peuvent être équivalentes à celle d'un cube si tenté que le modèle de la base soit bien pensé...
 Stefan
Mercredi 14 Février 2007

Version imprimable
[Ignorer]
Bonjour ,

Faisant suite à nos mails et à la réponse de Sebastien , je ne peux que confirmer ses propos. Par ailleurs , si HOLAP c'était une alternative viable , on le saurait aujourd'hui , mais le nuage qui planne sur les règles utilisées par le requêtage est bien épais selon l'éditeur. Par contre , comme je vous disais , je déconseille fortement XML en stockage , c'est vraiment pas performant du tout ( mon expérience ).

Pour conclure , comme précisé dans mes mails , tout dépend de votre stratégie de stockage et des besoins fonctionnels en face , faut savoir sortir la tête de la technique dans le décisionnel , si vous voulez pas aller droit dans le mur.

Selon les besins donc , les tehnos Sybase IQ + univers BO vs autre base relationnelle + cube OLAP sont adaptés à certains besoins dans certains contextes. Pour moi , plus vous avez besoin de flexibilité et d'adaptabilité , plus vous vous dirigez vers des solutions à base de couche sémantique ( BO , Cognos , etc. ) , et plus vous avez besoin d'encadrer les besoins avec une vitesse supérieure , vous vous dirigez vers une techno MOLAP.

Des éléments comme le stockage , le temps de réponse et le type de besoin sont donc essentiels pour bien cibler votre public , et bien rentrer dans les contraintes de bugdet / ROI / TCO.



Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store