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
Datawarehouse : table des faits
Bjr,
Nous avons une bdd deja toute faite relative à une application web.
Nous souhaitons créer un reporting sur les données provenant de cette appli. Mais lors de la création du Datawarehouse, pouvons nous reprendre le schéma identique de la bdd (cad tables et relations) ou sommes nous obligé de créer un datawarehouse avec dimensions et table(s) des faits ???
Merci pour vos infos.
beaucoup d'entreprises font une copie de leur base à j-1 + des index pour faire du reporting. Faire un "bon" Datawarehouse, dénormalisé coûte cher alors qu'une copie brute de la base c'est facile à mettre en place.
Si c'est pour faire des rapports (Ireport, Birt, BO...) ca marche. Les requêtes risquent d'être complexes. Si tu veux faire des analyse olap par contre ca ne marchera pas.
Oui mais quand on part d'une BDD deja toute faite, et que l'on souhaite créer un bon DW dénormalisé, en modele etoile ou flocon, avec une ou plusieurs tables des faits et dimensions, devrait on recréer un datawarehouse alors ?Si c'est pour faire des rapports (Ireport, Birt, BO...) ca marche. Les requêtes risquent d'être complexes. Si tu veux faire des analyse olap par contre ca ne marchera pas.
Quels outils devrais je utiliser ? OWB ou un ETL? ou bien simple pl/sql suffira ?
Merci pour vos réponses.
> simple pl/sql suffira
oui, ça peut. Après c'est juste possiblement plus dur à maintenir.
Un data warehouse peut être dan la même BD que la BD opérationnelle. Tout est une question de logique, de coût, de volume et d'utilisation.
pour compléter la réponse de Jester :
Apparemment tu as de l'oracle en source et en cible donc OWB peut être un bon compromis entre du pl/sql maison et un etl payant.
Il est gratuit avec une licence oracle enterprise c'est ça ?
Je l'avais utilisé pour alimenter un petit DW, je ne sais pas ce qu'il vaut s'il y a de gros volumes.
Salut,beaucoup d'entreprises font une copie de leur base à j-1 + des index pour faire du reporting
Je voulais savoir ce que tu voulais dire par faire "une copie de leur base à j-1 des index", et pourquoi cela couterait cher de dénormaliser.
Et pour ce cas-ci, cela dépend des besoins des utilisateurs non ?Les requêtes risquent d'être complexes. Si tu veux faire des analyse olap par contre ca ne marchera pas.
pour faire des analyses de type OLAP, il faut obligatoirement respecté les modeles (étoiles, flocons), je me trompe ?
Merci pour vos réponses.
Pas forcément, mais dans ce cas tu as juste le plain SQL, ce qui est limité. A moins de refaire un moteur OLAP.Envoyé par Go_Ahead
Tous (?) les outils d'analyse OLAP demandent des tables en étoile pour fonctionner.
oui limité à moins d'aimer se casser vraiment la tete...Pas forcément, mais dans ce cas tu as juste le plain SQL, ce qui est limité
La nuit tu fais une copie de ta base de prod vers une base rep_prod. Donc dans la nouvelle base tu as les données de la veille. C'est facile à mettre en place (selon la taille de ta base).
Faire un DW dénormalisé est généralement un projet qui peut s'étaler sur plusieurs mois (étude du besoin des utilisateurs, conception du modèles, des processus d'alimentation, dév, recette...) d'où le coûteux. C'est surtout de la main d'oeuvre.
Oui si les utilisateurs ne voient pas l'utilité de mettre du OLAP en place, cela fait une raison en moins de se casser la tête.
Pour la complexité des requêtes généralement les analyses se font sur des compartifs sur plusieurs années, mois ... avec des tables qui setrouvent d'un bout à l'autre du modèle de données...
Bonjour,
Avec mon peu d'expérience, je peux quand même te dire que si tu as des données difficiles à traiter ou extraire ou bien un grand nombre de données. Je te conseille de réfléchir au schéma ?
Pourquoi ? Le but est d'optimiser à des fins de reporting même si tu ne trouves pas ça à première vue très optimisé au niveau base de données.
Ca permet notamment de sortir des états ou de faire des tableaux de bord quasi instantanément et la rapidité, c'est très important chez l'utilisateur.
Après, tout est question de choix.
Bon courage !
Bonjour,
La création d'un datawarehouse ne constitue pas un pré-requis.
Pour interroger les données d'une application, on peut commencer comme le cite Hebus, par travailler sur une simple réplication nocturne de la base de production. Voire directement sur les données d'exploitation si les ressources le permettent.
L'objectif consiste surtout à valider les prototypes elaborés auprès des utilisateurs, et dans ce cas il y a souvent des modifications, évolutions, retour en arrière, etc... et cette configuration offre cette flexibilité.
Il est à noter au passage, qu'il existe des produits OLAP qui travaillent directement sur des bases relationnelles normalisées.
Cette simple copie peut par la suite être améliorée : en général on commence par des procédures de nettoyage, de validation, etc...
Puis on peut élaborer ensuite des Datamarts modélisés en étoile, comprenant des agrégats permettant de répondre à des problématiques de performance, d'historisation, etc...
On peut alors connecter l'outil de BI sur la base Datamart qui est dénormalisée et faire évoluer l'application pour plus de performance comme le cite Bim.
Outil Olap sur base normalisé ?
Paul_S, peux-tu nous donner un exemple d'outil OLAP sur base applicative directe ???
Tu penses à des outils MOLAP je présume ?
Thanks
Pouvez-vous préciser votre conception du terme "MOLAP" ?Tu penses à des outils MOLAP je présume ?
Merci
Bonjour,
Pourquoi ne pas essayer de faire un univers BO sur ta BDD?
C'est rapide, pas cher (si tu as déjà BO) en plus tu connais déjà la structure.
Tu peux tester quelques requêtes et puis si ça va pas là tu peux te lancer sur une analyse Datawarehouse.
C'est ce qu'on appelle du reporting opérationnel et d'ailleurs c'est peut-être ça que tu souhaites.
dslé pour la réponse... tardive.
C'est ce que j'ai fais, mais le problème que je trouve avec cette "méthode" c'est qu'elle est en contradiction avec la création d'un datawarehouse (au niveau de la théorie) par exemple, tables des faits, dimensions, modele étoile/flocon... c'est ça qui me gène beaucoup. Si je le fais de cette façon, je ne fais que du simple reporting (avec peut etre du sql avancé) mais pas vraiment de la BI.Pourquoi ne pas essayer de faire un univers BO sur ta BDD?
C'est rapide, pas cher (si tu as déjà BO) en plus tu connais déjà la structure.
Tu peux tester quelques requêtes et puis si ça va pas là tu peux te lancer sur une analyse Datawarehouse.
C'est ce qu'on appelle du reporting opérationnel et d'ailleurs c'est peut-être ça que tu souhaites.
Qu'en pensez-vous ?
Pour ceux qui ont déjà "construit" un DW à partir d'une BDD existante en prod, comment vous etes vous pris ?
Je pense que le PL/Sql peut représenter une contrainte dans la mesure où nous avons des données compliquées à extraire.
Dans ce cas, un ETL comme OWB ou BODI ou encore open source sont ils plus facil à gérer ??
Merci pour vos réponses et vos informations.
Bonjour,
Le problème est de savoir si tu as besoin d'un datawarehouse ou pas. Je ne suis pas partisan de l'idée "reporting donc datawarehouse" qui à mon avis constitue une erreur. Les entrepôts de données sont utiles pour :
- conserver une information "propore" et sur la durée (historique) et donc gérer un gros volume de données
- que le client est une meilleure compréhension de son nouveau SI (de manière générale, l'entrepôt de données est plus lisible que le schéma UML : les axes d'analyses y sont plus facilement identifiables) en disposant de données orientées métiers.
- permettre une agrégation des données plus intuitive et performante
En ce qui concerne l'extraction des données, bien évidemment les ETL sont plus souples d'utilisation que des requêtes ou du SQL procédurale. Ils constituent un gain de temps en développement et sont plus faciles à maintenir que des pages de code (enfin c'est mon avis).
Le besoin existe, dans la mesure où il faut extraire des données de la BDD pour generer des fichiers xls ou pdf. Les outils je les ai également donc pas de probleme de cout.Le problème est de savoir si tu as besoin d'un datawarehouse ou pas.
j'ai déjà créer le datawarehouse mais en reprenant tel quel le schéma BDD, sans le modifier. Je cherche aussi un bouquin où je pourrai m'inspirer des méthodes à respecter lors de la création/entretien d'un DWH.
Le problème n'est pas pris dans le bon sens... on pourrait très bien générer des rapports Excel, Word, PDF ou ce que tu veux sans avoir d'entrepôt de données... Ce n'est pas le besoin de rapport qui encourage la mise en place d'un datawarehouse mais les analyses dont on a besoin derrière.Le besoin existe, dans la mesure où il faut extraire des données de la BDD pour generer des fichiers xls ou pdf. Les outils je les ai également donc pas de probleme de cout
Si tu as repris le schéma de la base opérationnelle tel quel, tu n'as donc pas constitué un entrepôt de données au sens où on l'entend généralement.j'ai déjà créer le datawarehouse mais en reprenant tel quel le schéma BDD, sans le modifier.
Il en existe des pas mal comme ceux là :Je cherche aussi un bouquin où je pourrai m'inspirer des méthodes à respecter lors de la création/entretien d'un DWH
- The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling de Kimball
- Le data warehouse : Guide de conduite de projet toujours de Kimball (plus dans la gestion d'un projet et un peu moins dans la modélisation)
- Data Warehousing Fundamentals: A Comprehensive Guide for IT Professionals de Paulraj Ponniah (assez avancé mais très complet : écrit dans un anglais très technique je trouve)
Tout à fait d'accord avec ton propos. Mais quelle alternive a t on pour generer du reporting journalier, tableau de bords assez complexe (en xls, pdf pour la présentation) sans utiliser un outil de reporting qui est spécialisé sur ce theme la. La suite BO ne s'arrete pas uniquement qu'au Designer mais aussi au Reporter....Le problème n'est pas pris dans le bon sens... on pourrait très bien générer des rapports Excel, Word, PDF ou ce que tu veux sans avoir d'entrepôt de données... Ce n'est pas le besoin de rapport qui encourage la mise en place d'un datawarehouse mais les analyses dont on a besoin derrière.
Bref si tu as d'autres alternatives, je suis preneur.
Oui tout à fait, pour créer un entrepot de données, il faudrait examiner les differentes dimensions qui seraient utiles, la ou les tables des faits, utiliser un ETL ou coder en pl/sql pour charger ses données etc...Si tu as repris le schéma de la base opérationnelle tel quel, tu n'as donc pas constitué un entrepôt de données au sens où on l'entend généralement.
Bonjour,
@ Go_Ahead, je vous suggère de prendre un peu de recul par rapport à la théorie. Patrice Harel a raison, vous n'abordez pas le projet par le bon bout : le Datawarehouse n'est pas une finalité, mais un moyen. Sa mise en oeuvre répond à un besoin d'amélioration des performances de votre plateforme décisionnelle.
De plus, il n'est pas obligatoirement modélisé multidimensionnel (faits + dimensions) si un outil de restitution OLAP n'y est pas associé.
Donc,
commencez par faire une copie améliorée de vos données de prod pour créer un "infocentre", faites vos requêtes et vos rapports sur cet infocentre et automatisez son alimentation.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager