Discussion :

[patriceharel]

Bonjour à tous,

Aujourd'hui on vient de me faire douter sur quelque chose que je pensais acquis.
Un client me demande de lui alimenter ses rapports à partir d'un cube... Au début je pensais qu'il faisait l'amalgame entre datawarehouse et cube.. mais non... il fait bien la distinction... Le datawarehouse étant constitué, il me reste la conception du cube.. seulement, je trouve que le cube est inutile dans le sens ou les axes d'analyses sont très peu croisés entre eux, et, les rapports étant déjà prédéfinis, les croisements seront toujours le mêmes. De plus, il y a peu de données à agrégés, les calculs ne seront donc pas complexes, il n'y aura pas de problèmes de performances...bref
Pour moi les cubes sont surtout utiles lorsque les agrégations nécessitent beaucoup de traitement, les croisement d'axes sont nombreux...
Pour vous, à partir de quel moment est ce utile de disposer d'un cube avec son datawarehouse?

Merci

[Sam3oul]

Bonjour patriceharel,

Ce qui est bien avec la solution Microsoft BI (et c'est peut être valable pour les autres solutions) c'est qu'il y a une compatibilité intra et inter-couches.

A partir de là, on peut sans problème omettre d'utiliser tel ou autre maillon de la chaîne sans pour autant aboutir à une solution incomplète ou pire qui ne tourne pas...

Pour ce qui est de la relation cube/rapport, je pense, comme toi, que si le datawarehouse n'est pas volumineux et que les relations entre ses entités sont peu nombreuses, on peut ne pas recourir à la structure multidimensionnelle...

Maintenant, je me mets à la place de ton client et je me dis qu'il vaut mieux avoir un cube pour deux raisons :

- La solution doit être évolutive, donc si les données venaient à s'accumuler ou que le nombre d'entités à augmenter, il vaut mieux prévenir que guérir et donc j'assure mes arrières en ayant une structure qui me permette grâce au mécanisme de l'UDM (à travers la vue de source de données pour être plus précis) d'ajouter sans peine (et à moindre frais) mes nouvelles tables,

- Je paye la solution décisionnelle donc je veux que tout soit optimisé même si je t'accorde que dans ton cas le rendement est pareil à quelques millièmes de secondes près.

Pour conclure, je dirai, que pour mon cas, et avec un schéma en constellation, le cube m'a bien été utile...

Bonne journée

[patriceharel]

- La solution doit être évolutive, donc si les données venaient à s'accumuler ou que le nombre d'entités à augmenter, il vaut mieux prévenir que guérir et donc j'assure mes arrières en ayant une structure qui me permette grâce au mécanisme de l'UDM (à travers la vue de source de données pour être plus précis) d'ajouter sans peine (et à moindre frais) mes nouvelles tables,

Pour cet argument la première partie me plais bien (l'accumulation des données)... par contre pour la seconde, si des dimensions venaient à être ajoutées, il faudrait le faire pour le datawarehouse et le cube... donc cube ou pas c'est pareil.

- Je paye la solution décisionnelle donc je veux que tout soit optimisé même si je t'accorde que dans ton cas le rendement est pareil à quelques millièmes de secondes près.

Ca c'est bien vrai et je n'y avait pas spécialement pensé.

Autre chose complètement différente. Il faut bien faire la distinction entre le datawarehouse qui lui ne possède pas une structure multidimensionnelle de part son mode de stockage (un SGBD ; le datawarehouse sera donc considéré comme relationnel) et le cube véritable structure multidimensionnelle (du moins c'est comme ça qu'on me l'a enseigné). Ma question est la suivante : qu'est ce qui diffère dans le mode de stockage d'un datawarehouse et d'un cube qui justifie le gain de performance entre les deux (hormis le fait que les agrégats soient précalculés)?

[Sam3oul]

Je m'explique :

- Pour la 1ère partie, si le nombre de tables venait à augmenter, il y aura forcément plus de relations entre les tables et donc à ce moment là on aura besoin de ce bon vieux cube pour accélérer le requêtage des données. Certes, il va falloir également rajouter ces tables dans le datawarehouse mais je pense que ton package ETL saura y faire sans problème majeur par contre comment va faire ton système pour faire une requête sur des données dispatchées sur plusieurs dimensions?

- Pour ce qui est de : "Il faut bien faire la distinction entre le datawarehouse qui lui ne possède pas une structure multidimensionnelle de part son mode de stockage (un SGBD ; le datawarehouse sera donc considéré comme relationnel) et le cube véritable structure multidimensionnelle (du moins c'est comme ça qu'on me l'a enseigné)" je suis tout à fait d'accord avec toi et je l'ai même mentionné dans un précédent topic.

- Pour le mode de stockage du cube, il faut savoir que dans OLAP, il y a 4 modes de stockage : MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP), HOLAP (Hybrid OLAP) et DOLAP (Desktop HOLAP).

Le 1er étant adopté par défaut par SSAS car c'est le plus rapide et le plus optimisé en terme de requêtage des données mais les autres modes ont leur avantage en terme de mise à jour du cube.

Bref, tu peux te documenter dessus pour en savoir d'avantage. Moi-même, je ne me suis pas trop approfondi sur ce sujet (pour le moment ).

Disons que, pour l'instant, je me remets à la "projection dans l'espace" pour comprendre le principe de fonctionnement de ce format multidimensionnel.

[Sam3oul]

Je te renvois vers ce lien MSDN qui vient confirmer mes dires et répondre avec plus de détails à ta question.

Bonne lecture

[Reskibil]

Outre les croisements de dimensions, l'un des avantages des cubes est également la notion de hierarchie qui peut apporter un interet pour l'affichage des données.
Par contre faire du OLAP pour le principe n'est pas forcément la bonne solution.

[Sam3oul]

Tout à fait, les hiérarchies sont un autre énorme avantage du recours au cube.

L'affichage des données dans le rapport s'en trouvera nettement amélioré avec des possibilités de drill down (forage vers le bas (général --> détail)) et de roll up (exploration vers le haut (détail --> général)).

[patriceharel]

Ok, merci à vous pour vos réponses, ça me donne des pistes à creuser pour mes spécifications.

Disons que, pour l'instant, je me remets à la "projection dans l'espace" pour comprendre le principe de fonctionnement de ce format multidimensionnel.

Qu'entends tu par "projection dans l'espace"?

[Sam3oul]

C'est une technique de représentation virtuelle de ce cube dans l'espace...

Je laisse faire mon imagination comme au temps de la matière "Dessin Technique" au lycée...

Ca fait un bail

[mochi]

Bonjour
Sam3oul c'est koi le DOLAP ?!!

[Sam3oul]

Le DOLAP est un mode de stockage OLAP, certes peu connu, et qui consiste à stocker les données sur le poste client (d'où la notion de Desktop) en vue de procéder à un traitement multidimensionnel en local.

Il est de moins en moins utilisé vu que la tendance actuelle s'oriente plus vers des architectures à client léger.

Bref, je te renvois vers ce lien pour plus de détail.

[Antoun]

Bonjour
Sam3oul c'est koi le DOLAP ?!!

Le DOLAP, c'est quand le cube est intégré à un outil client. Par exemple, les tableaux croisés dynamiques d'Excel sont une solution DOLAP, parce qu'Excel construit un microcube avec les données sources, et alimente les tableaux croisés à partir de ce microcube. De la même manière, BO DeskI est une solution DOLAP, car les données renvoyées par la requête SQL sont stockées dans un microcube.