Discussion :

[yphilogene]

Bonjour,

Je travaille actuellement sur un projet B.I. qui consiste à partir de tables de transactions sources pour aboutir à un ensemble de tables modélisées dimensionnellement pour faire du reporting.

Il s'avère que mes tables de transactions sources sont plus ou moins déjà organisées dimensionnellement. C'est pourquoi, aboutir à mon modèle final consistera simplement à regrouper quelques tables, faire quelques pivot et réaliser quelques calculs SQL simples.

Voilà pourquoi j'hésite entre 2 solutions:

1) Solution ETL: Je crée des tables physiques réelles et réalise du transfert/transformation de données des tables transactionnelles sources vers ces nouvelles tables.

2) Solution Vues Matérialisées: Je crée des vues matérialisées à partir de SELECT sur les tables transactionnelles sources.

La solution 1, je connais bien. En revanche, je n'ai jamais utilisé de vues matérialisées et je me pose les questions suivantes:

- Une vue matérialisée peut-elle supporter autant de volumétrie qu'une table réelle? Si j'ai bien compris, la vue matérialisée est conservée en cache. N'est-il pas risqué de construire tout un datamart en vues matérialisées?

- Y a-t-il des instructions du SELECT non acceptées dans la construction d'une vue matérialisée, comme par exemple des sous SELECT à l'intérieur d'un SELECT principal?

En fait, j'ai surtout peur d'utiliser les vues matérialisées parce que je ne sais pas si elles ont été pensées pour être utilisées de cette manière. Quelqu'un qui s'y connait bien pourrait me rassurer ou me prévenir s'il-vous-plaît?

[yphilogene]

En cherchant un peu plus, j'ai trouvé une discussion déjà entamé sur le sujet:

http://www.developpez.net/forums/showthread.php?t=19275

Cela dit, votre avis m'intéresse toujours, notamment en ce qui concerne les contraintes imposées sur le SELECT des vues matérialisées en fonction du mode de rafraichissement. Je voudrais faire du FAST REFRESH. En lisant les docs, j'assimile ce qu'il est possible ou pas de faire, mais je ne comprends pas pourquoi cela est possible ou pas.

[Jester]

Il faut aussi vérifier que toutes les données resterons stockés dans les tables OLTP.

Le problème du fast refresh c'est plu un problème algorithmique à mon avis. Tout est possible, mais c'est compliqué donc pas fait. De toute façon si c'est couteux en complexité ça l'est en temps.

Il faut aussi étudier la question des index sur les vues matérialisées.

Or cas simples, je pense que cette solution n'est pas viable.

[yphilogene]

Effectivement, c'est pas simple le FAST REFRESH... Ca passe par l'utilisation de table de log qui trace les modifs sur la table source. Finalement, je préfère utiliser une table classique avec une requête MERGE pour son rafraichissement.

Cela dit, les MATERIALIZED VIEW JOIN ONLY sont bien utiles et facile à mettre en place.

[Jean_Paul_XX]

Bonjour Yphilogene

Je vous propose mes reflexions.

1°) Je rejoins Jester. J'éviterais personnellement la solution vue matérialisée. Cela ne me semble pas très 'stable'.

2°) Votre application de BI est selon vos dires simple. Si la volumétrie et le nombre d'utilisateurs sont raisonnables, dans ce cas pourquoi ne pas interroger directement vos données source qui sont déjà bien organisées ?
Je pencherais personnellement sur une solution basée sur des données stables et non-volatiles, au détriment peu-être (mais si peu) des critères de performance ? Restons concis ...

Qu'en pensez-vous ?

[yphilogene]

Je suis d'accord, je ne suis pas sûr de gagner en termes de performances en utilisant les vues matérialisées.

Mon projet B.I est simple dans la mesure où je n'ai qu'une petite constellation avec 2 tables de faits à gérer. Mais en termes de volumétrie, c'est très gros et comme on veut avoir du reporting quasi temps-réel, il faut je mette en place un processus d'alimentation très performant.

Il m'est interdit d'interroger directement les tables de faits de l'ERP, tout simplement parce que cela dégraderait les performances sur cet environnement. Le principe est donc de faire une copie de ces tables. Alors j'en profite pour réaliser quelques transformations simples, comme des pivots, etc...

Si je me suis intéressé aux vues matérialisées, c'est avant tout pour rester au plus proche de la base de données afin d'avoir les meilleures performances. En effet, les opérations ETL passent par une couche logiciel qui ralentit fortement le processus. Finalement, j'ai décidé de n'utiliser l'ETL que comme un séquenceur pour lancer des requête MERGE.

[Jester]

A noter que s'il est possible de mettre des triggers sur les tables OLTP, ils peuvent servir à remplir les tables OLAP.

Ca permet d'avoir du temps réel, ça peut aussi être utile pour mettre à jour des agrégats sans les recalculer complètement (un fast refresh à la main sans contraintes mais plus complexe à faire).

Après forcément ça ralenti les modifications des tables OLTP, ce n'est plus "juste" lors de l'étape de transfert qui est placée sur des heures creuses (étape supprimée).