IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Autres outils décisionnels Discussion :

Utilisation des vues matérialisées Oracle


Sujet :

Autres outils décisionnels

  1. #1
    Membre actif
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 205
    Points : 222
    Points
    222
    Par défaut Utilisation des vues matérialisées Oracle
    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?

  2. #2
    Membre actif
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 205
    Points : 222
    Points
    222
    Par défaut
    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.

  3. #3
    Membre éprouvé Avatar de Jester
    Inscrit en
    septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 813
    Points : 1 014
    Points
    1 014
    Par défaut
    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.

  4. #4
    Membre actif
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 205
    Points : 222
    Points
    222
    Par défaut
    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.

  5. #5
    Nouveau membre du Club
    Profil pro
    Inscrit en
    octobre 2007
    Messages
    29
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 29
    Points : 35
    Points
    35
    Par défaut
    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 ?

  6. #6
    Membre actif
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 205
    Points : 222
    Points
    222
    Par défaut
    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.

  7. #7
    Membre éprouvé Avatar de Jester
    Inscrit en
    septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 813
    Points : 1 014
    Points
    1 014
    Par défaut
    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).

Discussions similaires

  1. Utilisation des Vues Matérialisées
    Par bar_79 dans le forum PL/SQL
    Réponses: 1
    Dernier message: 13/08/2010, 13h33
  2. Récupérer les noms des vues sous Oracle
    Par Remedy dans le forum SQL
    Réponses: 10
    Dernier message: 07/12/2007, 18h22
  3. Fonctionnement et utilisation des vues matérialisées
    Par gOgHi dans le forum Administration
    Réponses: 7
    Dernier message: 19/10/2004, 14h29
  4. Utilisation des vues
    Par Andry dans le forum Débuter
    Réponses: 2
    Dernier message: 19/07/2004, 08h00
  5. [Crystal Report] Utilisation des vues de sql serveur
    Par Olivierakadev dans le forum SAP Crystal Reports
    Réponses: 2
    Dernier message: 15/11/2002, 17h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo