Discussion :

[Wazzouille]

Bonjour à tous !

Alors voilà, un cube, au final, c'est quoi ?
J'ai regardé sur internet, ça à compléter ce que j'ai pu apprendre pendant les quelques petites heures de cours que nous avons reçu à ce sujet, j'ai donc compris le concept (plusieurs dimensions, des valeurs, on prend telle, telle et telle dimension et on a un valeur qui correspond au croisement), j'ai compris que ça permet d'augmenter la rapidité des requêtes (langage MDX)
mais je me demande concrètement ce que c'est ?

J'ai lu beaucoup d'articles sur le sujet, mais je n'ai trouvé personne qui aborde réellement à cette question qui peut vous sembler idiote :

Est-ce qu'un cube est une manière de modéliser une base de donnée (DW, DM) afin qu'il soit utilisable par des outils OLAP, ou est-ce qu'il s'agit d'une étape postérieur au DW ?

Et la question qui vient s'y ajouter est de savoir : est-ce qu'un cube est obligatoirement nécessaire ? Peut-on s'en passer ?
Sur cette question, de mon point de vue tout dépend de ce que l'on cherche à obtenir. Il n'est pas nécessaire dans le cadre d'un reporting, mais il l'est bel et bien dans un objectif d'analyse. Pouvez-vous me confirmer mon point de vue sur la question ?

En espérant en apprendre d'avantage de votre part,
Wazzouille

[nuke_y]

Un cube c'est une réponse technique à un problème technique : comment faire des requêtes OLAP rapides sur de gros volumes de données en laissant la possibilité à l'utilisateur de:

• appliquer des filtres
• agréger à sa convenance
• ajouter / enlever des dimensions ou attributs ou mesures

Une des réponses, surtout il y a 20 ans, a été le cube : il pré-calcule TOUT pour que les données soient prêtes pour les choix de l'utilisateur. Il doit donc calculer toutes les possibilités de filtre, agrégation, sélection de dimensions et de mesures.

Au passage de petites fonctionnalités exotiques se sont rajoutées:

• calcul différent selon le niveau d'agrégation
• cube hybride qui déclenche des requêtes de détail à la demande

Mais pendant ce temps les générateurs de requêtes faisaient leur bonhomme de chemin (à partir de 1990 environ): Business Objects, Cognos. Ils donnaient de la flexibilité aux utilisateurs et sur un modèle en étoile bien indexé restaient assez rapide + possibilité de faire du drill-down (accès au détail) facilement. Bref, pas de temps de pré-calcul, language SQL, performances assurées par le tuning de la BDD et/ou la modélisation, formats de sortie divers, ces outils ont pris énormément de parts de marché, sans forcément tuer le Cube qui gardait ses adeptes et avait globalement l'avantage des performances, la faute aux générateurs de requêtes qui n'ont pas su gérer simplement les pré-calculs (tables pré-agrégées) et aux BDD de ne pas savoir se mettre à l'écoute des requêtes OLAP.

Mais avec les générateurs de requêtes il manquait toujours cette navigation fluide qu'on pouvait trouver dans les Cubes.

Puis sont apparus les outils in memory : Qlikview, Spotfire, Tableau : toutes les données, dans un modèle, de l'interactivité, plus de prompts, du temps de réponse, des gros volumes et de l'affichage sexy. Là les cubes ont pris un grand coup dans les genoux, mais les générateurs de requête ont bien résisté, grâce au SQL sous-jacent et aux BDD musclée pour l'OLAP (exadata, PDW et autres).

Donc non aujourd'hui un cube n'est pas nécessaire, il est bien plus simple d'utiliser du Qlikview qui de toutes façons peut aussi faire du Cube si on le souhaite (même s'il faut bricoler un peu) et surtout les enjeux ne sont plus là: les vitesses de calcul, la RAM, sont tels que les enjeux se sont déplacés ailleurs.

Enfin la logique de Cube reste valable, certains produits continuent de l'utiliser de manière sous-jacente, surtout avec du Cube hybride (il me semble que c'est le cas de Microstrategy). Si on devait absolument tuer les Cubes aujourd'hui on pourrait utiliser:

• les outils in memory travaillant sur le détail tels que Qlikview
• Les générateurs de SQL (BO, Cognos) + BDD optimisée pour l'OLAP (Exadata, PDW)
• Les générateurs de SQL (BO, Cognos) sur des BDD classiques mais avec des tables pré-calculées (materialized views en Oracle, Query Rewrite en Oracle)
• du Big data: et oui ça commence à arriver

C'est ce que font beaucoup d'entreprises.

A noter quand même que le Cube a un avantage : il force à travailler de manière plutôt respectueuse de(s) la théorie(s) décisionnelle(s), c'est une des raisons pour lesquelles il était plébiscité par les informaticiens. Alors qu'un modèle de données BO, Cognos ou Qlikview, c'est souvent un carnage mais "ça marche".

[Antoun]

Un autre point, qui est souvent crucial dans les choix d'archi, c'est celui de la simulation (what-if analysis). Dans toute une séries de cas, on a besoin soit de comparer le réalisé par rapport à des données plus ou moins fictives (par exemple des objectifs), soit de faire des calculs mélangeant le réalisé avec des données fictives (par exemple des prévisions budgétaires). Ces données fictives doivent être saisies, or les outils BI relationnels ne prévoient pas de possibilité de saisie (par principe : les BDD relationnelles sont dénormalisées, il serait hasardeux d'y faire des saisies). A l'inverse, les cubes prévoient nativement cette possibilité de saisie... cf mon billet http://blog.developpez.com/bi/p7422/...dimensionnelle

[Wazzouille]

Bonjour,

Merci pour vos réponses, j'y vois un peu plus clair à présent.
Je vais lire votre billet avec attention même s'il ne rentre pas dans le cadre de mon analyse présente.

Merci !

[nuke_y]

A part EssBase et des outils très orientés élaboration budgétaire je ne connais pas de technologie de cube orientée saisie:
- SSAS le permet soit-disant mais je ne connais personne qui l'a fait
- Powerplay ne le permet pas que je sache (mais c'est peut-être possible, c'est toujours un enfer d'obtenir une vision complète des fonctionnalités Cognos)

L'écriture nécessite un retour du cube vers les sources de données, ce qui s'avère souvent compliqué dans le cas de multi-sources ou risqué (perte de données) si stocké dans le cube.

Mais je suis ouvert aux retours d'expérience, est-ce qu'il y a des technologies de cube le permettant auxquelles je n'ai pas pensé ?

Merci

[YobsDebutant]

Bonjour,

Pour les cubes en saisie, on est en train d'étudier ça...
- Côté COGNOS, l'outil s'appelle TM1. J'ai ça aussi!
La mise en oeuvre faite chez nous par un presta me semble extrèmement laborieuse (échange avec la base datawarehouse à grand coup de fichiers CSV, aller comme retour).
Mais je n'ai pas encore eu le temps d'éclaircir si c'était le presta qui a fait n'imp ou si c'est structurel...

- On a un outil nommé Board qui fait ça, et plutôt pas mal avec gestion de règles de répartition et ce genre de joyeuseté. Par contre, ça embarque son propre système de programmation que je trouve assez laborieux...

Yohann

[YobsDebutant]

Petite correction après avoir cliqué trop vite...
Ces outils sont souvent vendus plutôt avec une étiquette "Elaboration budgétaire" que vraiment package décisionnel (ça doit parler plus aux directions financières)...

Yohann

[Buzzak]

Comme tu as dis, le mot cube provient du fait qu'il faut au minimum 3 dimension.

Tu pourrais avoir un rapport qui illustre les Ventes PAR Catégorie Par Région Par Client etc etc..

Avec un rapport comme ça on pourrait analyser et tenir des conclusions face au vente.

L'entreprise ou je travaillais avant utilisais cognos, mais cette application a c'est limite et la génération de cube peux être très longue si il y a beaucoup de donnée.

SQL Server Analysis Services SSAS permet de contré se problème.
Bien sur il faut avoir un entrepôt de donnée et aussi configurer en plus de comprendre toute le pattern SSIS (SQL Server Integration Services).

Je trouve avantageux, car ETL permet d'aller chercher les informations de source différentes que se soit des données d'un fichier, d'un serveur Oracle, ainsi que Sql et plus

Bien sur je ne suis pas un expert j'ai reçu une formation SSAS et SSIS mais rien de plus.


Le cube te permet simplement de donnée une certain flexibilité à ce qui attrait de la modulation des données un coup extrait de la bd.

[nuke_y]

@YobsDebutant: ah oui mais TM1... sérieusement... non, pas TM1... non

Les outils d'élaboration budgétaire sont souvent des "cubes-avec-saisie" oui, c'est LA raison d'être d'un tel outil de pouvoir saisir des données.

[YobsDebutant]

Tiens, TM1 ne semble pas avoir la cote?
J'avoue ne pas encore avoir eu le temps de me pencher dessus, si ce n'est très sommairement, et j'ai trouvé cela extrêmement lourd.
@Nuke_y: Vous avez déjà manipulé et pas été convaincu? C'est le sens du non, pas TM1... non ?

Cordialement,

[nuke_y]

TM1 c'est pas un mauvais concept en soit mais franchement c'est complexe à utiliser pour des fonctionnalités qui peuvent être adressées autrement. Après comme toujours, si un expert TM1 est disponible, il peut faire des merveilles. Mais un débutant rencontrera des difficultés terribles, ne serait-ce que pour trouver de la doc, des retours d'expérience, une communauté.