Discussion :

[Antoun]

non. WITH CUBE fait les croisements entre niveaux d'agrégation, et peux donc être considéré comme dimensionnel, donc OLAP, mais MySQL ne l'implémente pas.

WITH ROLLUP hiérarchise les dimensions entre elles, ce qui revient à tout ramener dans une seule dimension, donc je ne vois vraiment pas comment on peut parler d'OLAP.

[Jester]

WITH ROLLUP hiérarchise les dimensions entre elles, ce qui revient à tout ramener dans une seule dimension, donc je ne vois vraiment pas comment on peut parler d'OLAP.

En fait, c'était pour apporter le débat. Si dans la norme ISO SQL c'est dans le package OLAP, peut-on douter de la compétence des gens qui ont fait cette norme?

Pour moi c'est de l'OLAP car c'est pour faire de l'analyse en ligne, après certes pas forcément avec une histoire de cube et autre.

Je discerne bien ce qu'on fait des détails de l'exécutions qui ne regardent que le service informatique. Si vous pouvez avoir la bonne réponse dans un temps correct, tout le monde se fiche de savoir s'il y a un cube R/D/S/RT/H-OLAP derrière.

[Paul_S]

Bien.

Maintenant que tout le monde est d’accord sur la non-présence physique des données dans le cadre d’un cube R-OLAP , je souhaiterais revenir sur quelques précédents posts, au delà des questions de terminologie :

Antoun : … 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...

Tss,tss … Les outils R-OLAP seraient-ils cantonnées à la détection d’erreurs de saisie ? Chez Carrefour, la technologie R-OLAP servirait donc à détecter les erreurs de caisse ?
Non. C’est un peu exagéré. Les matériels et les applications ont évolué. Le concept R-OLAP est en particulier destiné à des PME qui ne disposent pas de ressources (humaines, financières et structurelles) pour monter une plate-forme de BI globale incluant les différentes briques décrites dans vos différents posts (ODS, DW, DM et autres structures multidimensionnelles physiques).
Il est à noter par ailleurs, que certaines organisations ont opté pour cette technique à la suite de temps excessivement longs d'alimentation des bases d'interrrogation M-OLAP.

Ygrim : … 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 …

Et

Antoun : … Ce qui est cocasse, vu que MySQL ne fait évidemment ni MOLAP, ni ROLAP, ni HOLAP, ni DOLAP...

Un point est primordial et caractéristique de la technologie R-OLAP : un cube R-OLAP est INDEPENDANT de la base de données interrogée. Sa description est définie dans l'outil de restitution (et non dans la BDD), et est TRANSPOSABLE. On peut donc décrire une structure multidimensionnelle R-OLAP sur une base MySQL, Oracle, voire Access, et migrer ensuite la BDD sans modification de la description.
Toutes les bases de données sont susceptibles de supporter une description R-OLAP. A l'heure ou l'on parle de souplesse, d'agilité, et de ROI, c'est un avantage important.

[Antoun]

En fait, c'était pour apporter le débat. Si dans la norme ISO SQL c'est dans le package OLAP, peut-on douter de la compétence des gens qui ont fait cette norme?

Bon, disons que ça confirme ce que je disais qq posts plus haut : on peut peut mettre tout et n'importe quoi sous le chapeau "OLAP".

Pour moi c'est de l'OLAP car c'est pour faire de l'analyse en ligne, après certes pas forcément avec une histoire de cube et autre.

Je discerne bien ce qu'on fait des détails de l'exécutions qui ne regardent que le service informatique. Si vous pouvez avoir la bonne réponse dans un temps correct, tout le monde se fiche de savoir s'il y a un cube R/D/S/RT/H-OLAP derrière.

yep !

[Antoun]

Tss,tss … Les outils R-OLAP seraient-ils cantonnées à la détection d’erreurs de saisie ?

Tu me fais dire ce que je n'ai pas dit.

...
Il est à noter par ailleurs, que certaines organisations ont opté pour cette technique à la suite de temps excessivement longs d'alimentation des bases d'interrrogation M-OLAP.

Oui. Le choix MOLAP/ROLAP est essentiellement une question d'arbitrage entre durée d'alimentation, temps de réponse des requêtes et espace disque.

[yphilogene]

Ouais, c'est trop bien le R-OLAP .

[nuke_y]

Oui. Le choix MOLAP/ROLAP est essentiellement une question d'arbitrage entre durée d'alimentation, temps de réponse des requêtes et espace disque.

Les cubes M-OLAP offrent aussi des possibilités d'analyse particulières il me semble, en tous cas certaines technologies. Par exemple soit les faits suivants :

Année | Pays | Volume
2006 | France | 10
2006 | France | 10
2007 | France | 20
2007 | France | 20
2006 | Italie | 10
2006 | Italie | 10
2006 | Italie | 10
2007 | Italie | 30
2008 | Italie | 40
2008 | Italie | 40

Le tableau de bord suivant est possible en M-OLAP mais pas en R-OLAP :

2006
France | 20
Italie | 30

2007
France | 40
Italie | 30

2008
France | 0
Italie | 80

Aucun fait n'est disponible pour France 2008 et pourtant il existe forcément une valeur pour le Volume à l'intersection de 2008 sur l'axe Année et France sur l'axe Pays, valeur qui est 0 (car aucun fait).

2008 |......0............80
2007 |.....40...........30
2006 |.....20............30
.......|____|________|_______
..........France........Italie

[Antoun]

Je ne vois pas trop pourquoi ce ne serait pas possible en ROLAP (mais je n'y connais pas grand-chose). Il suffit d'avoir une table des mois et une table des pays, et de faire les jointures comme il faut.

[nuke_y]

Parce qu'il est impossible de lier une table en jointure externe avec 2 autres tables il me semble, enfin si quelqu'un a une solution je veux bien la noter.

[Jester]

Hum, je ne fait pas de MOLAP, mais pourquoi il y aurait 0 dans une telle case? Comme là c'est l'agrégation somme, encore ça passe. Mais si c'était la moyenne? Mettre un zéro ce serait un peu ambitieux.

En ROLAP avec mondrian vous avez un NULL dans cette case, ce qui est le comportement le plus logique. Après libre à chacun de donner de la sémantique à ce NULL.

Sinon pour ce qui est du SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
mysql> select coalesce(d.year, 'Toute annees') as 'Année', coalesce(d.nom, 'Tous Pays') as 'Pays', sum(coalesce(vol, 0)) as 'Volume' from (select * from Pays p, Annee a) d left outer join Faits f using(year, nom) group by d.year, d.nom with rollup;
+--------------+-----------+--------+
| Année       | Pays      | Volume |
+--------------+-----------+--------+
| 2006         | Espagne   |      0 | 
| 2006         | France    |     20 | 
| 2006         | Italie    |      0 | 
| 2006         | Tous Pays |     20 | 
| 2007         | Espagne   |      0 | 
| 2007         | France    |     40 | 
| 2007         | Italie    |      0 | 
| 2007         | Tous Pays |     40 | 
| 2008         | Espagne   |      0 | 
| 2008         | France    |      0 | 
| 2008         | Italie    |     80 | 
| 2008         | Tous Pays |     80 | 
| Toute annees | Tous Pays |    140 | 
+--------------+-----------+--------+

avec comme table de faits :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
mysql> select * from Faits;
+------+--------+------+
| year | nom    | vol  |
+------+--------+------+
| 2006 | France |   10 | 
| 2006 | France |   10 | 
| 2007 | France |   20 | 
| 2007 | France |   20 | 
| 2008 | Italie |   40 | 
| 2008 | Italie |   40 | 
+------+--------+------+
6 rows in set (0.00 sec)

[Antoun]

Parce qu'il est impossible de lier une table en jointure externe avec 2 autres tables il me semble, enfin si quelqu'un a une solution je veux bien la noter.

Non, l'histoire des deux tables max, c'est une limite artificielle imposée par les ODBC (ou seulement certains ?).
Ce qui est plus problématique, c'est que les jointures sont dans le mauvais sens. ça peut se résoudre en faisant un produit cartésien d'abord :

Code pseudo-SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
FROM (Annees A CROSS JOIN Pays P)
  LEFT JOIN Faits F ON A.Annee = F.Annee AND P.IDpays = F.IDpays

C'est un schéma de requêtage que j'appelle une requête XL (CROSS JOIN puis LEFT JOIN), mais peut-être quelqu'un lui a-t-il donné un autre nom ?

[Antoun]

Hum, je ne fait pas de MOLAP, mais pourquoi il y aurait 0 dans une telle case?

Avec Essbase, ce serait effectivement #MISSING, qui est l'équivalent du NULL.

[Paul_S]

La notion de "Complétude" est effectivement gérée dans le modèle R-OLAP, au choix :

• Au niveau de la base de données, en définissant des jointures externes, comme le cite Antoun.
• Au niveau du moteur R-OLAP, qui génère dynamiquement une valeur dans le dataset pour le tupple considéré.

En tout état de cause, je suis d'accord avec la remarque de Jester. Une valeur 'Null' est attribuée par défaut, quitte à ce qu'elle soit reprise sémantiquement par la suite.

[Antoun]

Jester, au passage, Mondrian fait-il du MOLAP ou seulement du ROLAP ?

[Jester]

Seulement du ROLAP. Le cube n'existe qu'en mémoire. Du coup il ne conserve que certaines agrégations via un système de cache.

HOLAP en partitionnement vertical peut-être?

[Antoun]

Seulement du ROLAP. Le cube n'existe qu'en mémoire. Du coup il ne conserve que certaines agrégations via un système de cache.

OK, merci !

HOLAP en partitionnement vertical peut-être?

Tu veux dire que son cache fonctionne en stockage vertical, à la SyBase IQ ?

[Jester]

En fait je ne connais pas précisément son système de cache ni SyBase IQ, donc je préfère ne pas m'avancer.

[koutangoise]

bonjours je veux juste la définition exacte de "agrégat" en BI et base de données opérationnelles.
ensuite je demande les 2 raisons pour lesquelles les systèmes OLTP ne sont pas adaptés à la gestion d'information pour le décisionnel concernant le temps .
Merci
cordialement