Discussion :

[taoufiqENSIAS]

bonjour et merci pour la clarite de discussion
je me demande si vous avez koi dire sur PENTAHO
merci

[nuke_y]

@taoufiqENSIAS : je te conseille d'ouvrir un sujet dédié à une discussion sur pentaho (sauf s'il existe déjà). Non seulement ça sera plus clair mais tu auras plus de chance d'avoir des participants que dans cette conversation de 4 pages.

Sinon pour l'opposition datamart / DW, je dirais qu'il y a 2 méthodes et que chacun fait un peu comme il veut / peut. Cependant pour un projet qui démarre je crois beaucoup plus à la méthode Datamarts -> DW qu'à la méthode DW -> Datamarts.

Je m'explique : pour moi un projet décisionnel commence souvent par un datamart parce que peu d'entreprises se sentent de lancer un projet "DW global". Puis on rajoute un autre datamart pour un autre service. Et ainsi on commence à avoir une constellation (comme le dit yphilogene) qui équivaut à un DW.

Puis 2 points transformeront l'archi en top-down :
- à partir de ce DW (de cet ensemble de datamarts) on pourra alimenter d'autres Datamarts, par exemple pour croiser des données.
- on essaiera aussi de mutualiser les alimentations de données ce qui fait qu'on commencera la refonte du DW en faisant une alimentation du DW puis une alimentation des datamarts à partir du DW.

Alors oui on aurait pu commencer tout de suite par créer un DW au lieu de démarrer par des datamarts, mais combien d'entreprises ont une vision et un budgets suffisants pour agir ainsi ? Et surtout, est-ce mieux, plus rapide et plus rentable finalement ?

[Antoun]

Bon j'ai cogité un peu pour savoir ce que tu veux dire. Corriges moi si je fais erreur :
On construit un entrepôt de données "enterprise wide" et on donne accès aux données à différents départements de l'entreprise via des cubes (M-OLAP d'après ce que tu dis). C'est ça que tu essaye d'expliquer ?

A peu près. Je dirais plutôt : on construit un DW "enterprise wide", avec le même niveau de détail que les bases de prod. A partir de ça, on alimente une série de DM thématiques, agrégés selon les différents besoin métier (donc par exemple un DM marketing où on détaillerait les dimensions produit et client, un DM logistique où on travaillerait plutôt sur les types de packaging, les poids, les volumes, etc.). Chaque DM peut être une étoile/flocon ou un cube (MOLAP).

Dans ce schéma, je ne parle pas des cubes ROLAP, car ce n'est pas un type de base de données, mais plutôt une technique d'interrogation de bases relationnelles. Concrètement, un cube ROLAP c'est une étoile ou un flocon avec une couche de présentation multidimensionnelle.

Sinon, je pense qu'une bonne partie de nos malentendus vient des deux questions suivantes :

1. les datamarts font-ils partie du datawarehouse ?
2. Le datawarehouse est-il une collection de datamarts ?

1/ Cette question peut paraître complètement oiseuse. A l'évidence, DM et DW auront pas mal de tables en commun, et il serait complètement stupide de les dupliquer sur plusieurs instances ou serveurs. On gagnera en volume, en rapidité d'alimentation et en cohérence à tout mettre dans une seule base. Donc, physiquement, DM et DW forment une seule base (sauf évidemment pour les DM sous forme de cubes MOLAP).

La question se justifie néanmoins au niveau logique. En effet, le DW a un rôle de stockage des données détaillées et sur tout l'historique. A l'inverse, les DM répondent à une logique de restitution, avec un objectif de performance, des données agrégées, et une profondeur historique limitée aux nécessités de l'analyse. Comme la nature des données, l'objectif de la base et l'utilisation qui en est faite sont inverses, il me semble donc largement préférable de considérer qu'il s'agit, au niveau logique, de bases différentes. Cela permet de mieux savoir de quoi on parle.

Maintenant, vous pouvez parfaitement me dire que tout ceci n'est que chipotage de vocabulaire et vous aurez entièrement raison : au final, on collera tout dans la même BDD.

2/ Partons maintenant de la définition du DW telle que je viens de la donner. Dire "le DW est une collection de DM" peut se traduire par "il n'y a pas de DW, j'alimente directement chaque DM à partir de la base de prod". En terme de stratégie décisionnelle, ça veut dire faire du développement jetable. C'est probablement rentable sur le premier projet (construction du premier DM), mais ça veut dire qu'on repartira de zéro pour le deuxième.

Il ne s'agit évidemment pas de dire qu'il faut construire intégralement le DW avant de faire les DM. En général, on recommande plutôt une démarche incrémentale. On va commencer par analyser le besoin de reporting du premier groupe d'utilisateurs. On va ensuite modéliser et concevoir le DM qui permet de répondre au besoin.

Une fois qu'on a conçu le DM, il est relativement facile de dire quelles sont les données qu'il faudrait rapatrier dans le DW pour alimenter le DM. Cela nous donne un premier modèle, partiel, du DW.

Quand le DW partiel et le DM sont conçus, il n'y a plus qu'à mettre en place les flux d'alimentation. Ces flux sont évidemment prod -> DW -> DM. On a ainsi fait la conception dans le sens inverse de l'alimentation.

On passe maintenant à la conception du deuxième DM, selon la même méthode. Quand on passe à la phase "conception du DW partiel", on doit s'apercevoir qu'on réutilise une partie des données destinées au premier DM ; on économise ainsi une partie de la conception du DW et des flux d'alimentation.

Le DW se construit ainsi de manière incrémentale, au fur et à mesure des projets. Au final, on a un DW "monobloc", mais on l'a construit par petits morceaux.

[nuke_y]

@Antoun : on est d'accord (cf ce que je disais juste plus haut).

Plutôt d'accord aussi avec ça :

je ne parle pas des cubes ROLAP, car ce n'est pas un type de base de données, mais plutôt une technique d'interrogation de bases relationnelles.

Bien que le terme "technique d'interrogation" me gêne un peu... J'aurai plutôt exprimé quelque chose comme "technique de stockage intermédiaire à but d'interrogation".

[Paul_S]

Bonjour,


@Antoun : j'approuve totalement le discours sur la cinématique d'alimentation des différentes instances de stockage (Prod->DW->DM) ainsi que sur la présence physique et considération logique des données.

Précision cependant :

Dans ce schéma, je ne parle pas des cubes ROLAP, car ce n'est pas un type de base de données, mais plutôt une technique d'interrogation de bases relationnelles

Ok pour ça.

En revanche,

Concrètement, un cube ROLAP c'est une étoile ou un flocon avec une couche de présentation multidimensionnelle.

La modélisation n'est pas une obligation, même si c'est effectivement plus performant (parce qu'il y aura eu agrégation préalable) et plus 'logique' conceptuellement parlant. Il est en effet envisageable d'interroger le DW, voire, à l'extrême limite, une base de prod avec cette couche de présentation ROLAP (c'est le cas notamment pour du reporting de contrôle, ou bien pour répondre à des besoins précis temps-réel ...).
D'ou mes posts précédents citant souplesse et rapidité mise en oeuvre.

@nuke_y
Compte tenu du paragraphe ci-dessus,

J'aurai plutôt exprimé quelque chose comme "technique de stockage intermédiaire à but d'interrogation".

ne me semble pas correct. Il ne s'agit pas de stockage mais bien de couche de présentation d'un stockage relationnel.

[nuke_y]

Ce qui me gêne c'est qu'il peut y avoir de l'intelligence dans la création du cube qui n'existe pas dans le modèle relationnel, notamment dans la gestion des données par défaut. Et c'est pour ça que ça me gêne de ne parler que de présentation pour le cube...

[Antoun]

Il y a également de l'intelligence dans la création d'un univers BO (enfin, pas toujours, mais bon )... mais effectivement, il serait préférable de parler de "couche sémantique", qu'il s'agisse d'un cube ROLAP ou d'un univers.

[Antoun]

La modélisation [en étoile/flocon ?] n'est pas une obligation, même si c'est effectivement plus performant (parce qu'il y aura eu agrégation préalable) et plus 'logique' conceptuellement parlant. Il est en effet envisageable d'interroger le DW, voire, à l'extrême limite, une base de prod avec cette couche de présentation ROLAP (c'est le cas notamment pour du reporting de contrôle, ou bien pour répondre à des besoins précis temps-réel ...).
D'ou mes posts précédents citant souplesse et rapidité mise en oeuvre.

100% d'accord avec toi, mais il ne faut pas oublier les limites de cette solution : faibles performances et risques d'erreurs. Mais pour de la détection d'erreurs de saisie, c'est effectivement idéal.

@nuke_y
Compte tenu du paragraphe ci-dessus, ne me semble pas correct. Il ne s'agit pas de stockage mais bien de couche de présentation d'un stockage relationnel.

Effectivement, la caractéristique d'un cube ROLAP est de ne pas contenir de données. S'il y a des données stockées dans une structure multidim, c'est du MOLAP ou du HOLAP.

[yphilogene]

Oui, moi quand on me dit cube, je pense tout de suite au fichier physique et donc à quelque chose qui contient de la donnée. C'est pourquoi le terme "cube R-OLAP" ne me plait pas trop.

[nuke_y]

Effectivement, la caractéristique d'un cube ROLAP est de ne pas contenir de données

Je ne vois pas trop en quoi il s'agit d'un cube alors... Quand vous parliez de "cube ROLAP" je pensais qu'il s'agissait de cubes alimentés par une base relationnelle. Mais s'il s'agit effectivement juste d'une couche sémantique d'interrogation basée sur une base relationnelle, je suis de l'avis de yphilogene et je n'aime pas le terme "Cube ROLAP" car je ne vois pas en quoi c'est un cube.

[ygrim]

le R-OLAP, reste du OLAP, qui respecte toutes les spécifités d'un cube. Le point que certains trouveront négatif c'est qu'il utilise effectivement du SQL et des tables relationnelles pour permettre une analyse multi-dimensionnelle. Une sorte d'émulation M-OLAP.

[nuke_y]

le R-OLAP, reste du OLAP, qui respecte toutes les spécifités d'un cube.

Spécificités qui sont ? Parce que pour moi un cube c'était
1) une valeur d'indicateur pour chaque valeur des dimensions (en gros 3 axes, 3 valeurs par axe, ça nous donne 27 valeurs pour chaque indicateur).
2) tous les indicateurs à chaque intersection des axes sont pré-calculés
mais j'ai l'impression d'avoir loupé un truc (faut dire que je n'ai jamais eu de formation dessus).

[ygrim]

Monsieur CODD à définit des régles pour dire que tel ou tel outil ou technologie est du OLAP, pour éviter les "moi je le définit comme ..." :
http://fr.wikipedia.org/wiki/OLAP

Et comme les cube R-OLAP de microsoft (pour citer ce que je connais) associés aux technologies d'interrogation de cube répondent à ces spécs, les cubes R-OLAP sont des outils OLAP

[yphilogene]

Mouais.... Ces définitions de Wikipédia me donnent un peu la nausée à vrai dire... Il y a plusieurs phrases qui sont sujettes à polémiques.

Reste que OLAP est un concept, effectivement énoncé par Ted Codd et qu'il y a plusieurs façons de l'implémenter. Personnellement, je n'en vois que 2:

- Les cubes, qui sont des fichiers au format propriétaire contenant de la donnée et interrogeable directement via le langage MDX. Une fois généré, un cube vit indépendamment des sources de données qui ont permis de l'alimenter.

- Les modèles R-OLAP, couches logicielles permettant de former à la volée via SQL des cubes mis en cache mémoire et interrogeable via MDX.

Certaines déclinaisons du concept OLAP sont assez limites je trouve. Le H-OLAP par exemple, tel qu'il est défini sur Wikipédia, donne une vision assez limité du drill through.

[ygrim]

Je pense qu'on en a déjà parlé plus haut :
- Le terme cube est une vulgarisation du modèle multi dimensionnel, un modèle qui, à l'inverse du modèle relationnel, est optimisé pour l'analyse et la stratégie.
- OLAP désigne, à l'inverse de OLTP, les méthodes et outils pour faire de l'analyse multi dimensionnelle, c'Est à dire à base de dimensions et de faits.
- ROLAP, DOLAP, MOLAP, HOLAP, etc sont des implémentations du modèle multi dimensionnel. En gros, ça fait la même chose, mais avec des technologies différentes. Certaines se débrouilleront mieux que d'autres pour faire du OLAP.

[nuke_y]

C'est pas sur OLAP que je suis pas d'accord hein ? Ni sur R-OLAP. C'est sur "Cube R-OLAP".

Je pense qu'on en a déjà parlé plus haut :
- Le terme cube est une vulgarisation du modèle multi dimensionnel, un modèle qui, à l'inverse du modèle relationnel, est optimisé pour l'analyse et la stratégie.

J'ai lu la définition de wikipédia mais y a pas moyen, j'arrive pas à me faire à cette phrase :

Online Analytical Processing (OLAP), désigne les bases de données multidimensionnelles (aussi appelées cubes ou hypercubes) destinées à des analyses complexes sur ses données.

C'est sûr que si dès qu'on parle d'OLAP on peut dire "Cube" alors oui évidemment les "Cubes R-OLAP" pourquoi pas...

[Antoun]

En fait c'est le gag, un cube R-OLAP est un cube, il est tout ce qu'il y a de plus OLAP, mais ce n'est pas une base de données.
Ceci dit, je ne suis pas sûr qu'il y ait vraiment lieu de s'empailler sur la terminologie.

[nuke_y]

On pourrait penser que c'est sans importance mais moi quand on me vend une technologie en me disant "Alors ça fait R-OLAP, M-OLAP et des cubes" ben j'aime bien tout comprendre, surtout les nuances.

[Antoun]

T'as pas tort, en particulier avec le terme OLAP, qui a une signification fonctionnelle mais pas vraiment de signification technique... ou plus exactement, qui est employé dans un sens technique pour désigner tout et n'importe quoi.

A titre d'exemple, l'assistance de config de MySQL (sous Windows) pose une question qui est à peu près "faites-vous de l'OLTP ou de l'OLAP ?". Ce qui est cocasse, vu que MySQL ne fait évidemment ni MOLAP, ni ROLAP, ni HOLAP, ni DOLAP... En gros, il faut comprendre cette questions comme "faites-vous plein de petites requêtes (OLTP), ou bien quelques grosses requêtes (OLAP) ?".

[Jester]

Et la fonction ROLLUP de SQL c'est pas du OLAP peut-être?