Construction d'un Datawarehouse [Résolu]

[Sniper69003]

Bonjour à tous,

Je suis actuellement sur un projet de construction de système décisionnel pour une société. Ayant quelques lacunes dans le domaine, je me tourne vers vous pour avoir quelques infos.

Pour résumer, je dois réaliser un entrepot de données permettant de faire du reporting via B.O XI R2. A ce jour, j'ai réalisé "sur papier" un schéma en étoile que je voudrais tester.

Je ne dispose que d'une seule source de données qui sont toutes uniforment donc pas besoin d'ETL. Le logiciel sur lequel je dois récuperer les données tourne sur un serveur Oracle 9.2.

Mes questions sont les suivantes :

1) Avec quel outil, je dois contruire mon entrepot de donnée (plus précisément mes datamarts) ? Est-ce que des requêtes PL/SQL suffisent ? Est-ce que la solution OWB d'oracle est intéressante ?

2) Est-il possible de stocker mes schéma en étoile directement sur le serveur du logiciel afin de simplifier l'architecture ?

N'ayant jamais construit d'entrepôt de donnée, je voudrais simplement avoir une méthodologie (étape par étape) pour en réaliser un.

Merci d'avance

[Paul_S]

Bonjour,
La construction d'un datawarehouse pour une source de données... Si vous n'avez pas de problématiques particulières de performance (débit réseau, charge CPU...) , est-ce pertinent ?
Ne serait-il pas préférable de modéliser vos données au sein de l'univers ?

[Sniper69003]

Tout d'abord merci pour ta réponse.

En fait, je travaille avec une source de données importante (environ 2000 tables avec beaucoup de lignes).

Maintenant, j'ai fais le choix d'utiliser un autre serveur dans lequel je vais modéliser mon schéma en étoile. Ma question se résume à la conception de ce schéma en terme de langage SQL.

Pouvez vous me donner à titre d'exemple (en SQL) comment modéliser mon schéma qui est composé de 5 dimensions :
Organisation(ID_DIM_ORGA, Société, Site...),
Temps(ID_DIM_TEMPS, Année, Trimestre...),
Géographie(ID_DIM_GEO, Pays, Région...),
Clients(ID_DIM_CLI, Nom, Prenom...),
Patrimoine(ID_DIM_PATR, Immeuble,...)
et d'une table de fait : Faits analyse Référentiel(Les ID, NbClient,...)

Est ce que je dois faire :
1) CREATE TABLE table () AS SELECT les champs des tables qui m'intéresse
2) CREATE VIEW view () AS SELECT les champs des tables qui m'intéresse
3) ou autre chose ?

Merci d'avance pour vos réponses

[Jester]

Il vaut mieux une table, parce qu'une vue ne va rien changer à faire les requêtes en direct sur les tables originelles (sauf les vues matérialisées, mais je ne suis pas sur que ce soit très pratique non plus).

[Paul_S]

Bonjour,
Je suis d'accord avec Jester. ll est préférable de travailler sur des tables.
Concernant la procédure d'alimentation, un choix avec si peu d'informations est délicat. D'après ce que je crois comprendre, il faut alimenter le datawarehouse à fréquence trimestrielle, donc générer les données métriques pour chaque n-uplet considéré, sans oublier de tenir à jour les nouvelles valeurs pour chaque dimension, gérer les erreurs et les procédures de relance, etc...
On peut démarrer avec du script Oracle, puis opter pour OWB si l'ensemble se complexifie.

[doc malkovich]

Par contre, les vues matérialisées peuvent être intéressantes si on peut alimenter les tables en une seule requête. D'ailleurs, y'a un bloc sur l'utilisation de ces vues dans la doc oracle sur le datawarehousing.
Sinon, il faut voir le cout d'investissement dans un ETL comme OWB, qui n'est pas que financier !!!
En effet, utiliser un ETL implique des formations, une appropriation et généralement une découverte des limites ( et bugs ) du logiciel
Si tu dois faire un petit datamart rapidement qui n'est pas très complexe il vaut mieux partir sur des procs pl/sql quand on connait bien ce langage.

[Jester]

Envoyé par john malkovich

Par contre, les vues matérialisées peuvent être intéressantes si on peut alimenter les tables en une seule requête. D'ailleurs, y'a un bloc sur l'utilisation de ces vues dans la doc oracle sur le datawarehousing.

Ça pose quand même des problèmes. Il faut que toutes les données soient dans la source, vu qu'on repart de zéro à chaque refresh. De plus, l'aspet read-only des données n'est pas assuré. Du coup, c'est plus un cache de données qu'un DWH.

C'est que que pour l'alimentation, un simple insert dans une procédure PL/SQL est le plus simple, vu qu'il ne semble pas y avoir beaucoup de complexité.

[fleure]

bonsoir, je veux implémenté un entrepot de données , mais comme je suis débutante est ce que vous pouvez me donner les étapes à suivre.
merci et bonne nuit.

[doc malkovich]

Salut Jester,
Je n'avais pas vu ta réponse, donc je te réponds avec un peu de retard

Envoyé par Jester

Ça pose quand même des problèmes. Il faut que toutes les données soient dans la source, vu qu'on repart de zéro à chaque refresh. De plus, l'aspet read-only des données n'est pas assuré. Du coup, c'est plus un cache de données qu'un DWH.

Non, justement les VM ont un mode d'alim en FAST REFRESH pour les reconstruire uniquement avec les enregistrements ayant été changés, créés ou supprimés depuis le dernier rafraichissement. Tu as des cas particuliers qui empêchent ce mode de fonctionnement, maintenant il faut voir la requete source ...
Je n'ai pas compris l'aspect readonly des VM ?

@fleure : tu devrais commencer une nouvelle discussion, ce serait mieux ...

[Jester]

Envoyé par john malkovich

Non, justement les VM ont un mode d'alim en FAST REFRESH pour les reconstruire uniquement avec les enregistrements ayant été changés, créés ou supprimés depuis le dernier rafraichissement. Tu as des cas particuliers qui empêchent ce mode de fonctionnement, maintenant il faut voir la requete source ...

J'y avais pensé, mais je ne sais plus dans quel cas ce n'est pas applicable, je dirais un certain nombre. Mais avoir ce système quand ça marche et un autre quand ça ne marche pas me semble assez hybride et peu clair. Mais on peut y voir des cas d'usages.

Pour le read only, je ne sais plus. (oups).

[doc malkovich]

Envoyé par Jester

J'y avais pensé, mais je ne sais plus dans quel cas ce n'est pas applicable, je dirais un certain nombre. Mais avoir ce système quand ça marche et un autre quand ça ne marche pas me semble assez hybride et peu clair. Mais on peut y voir des cas d'usages.

De mémoire il s'agit de requêtes complexes et des agrégats ( normal il faut tout recalculer ... )
Je suis d'accord avec toi, je ne recommande pas les VM mais dans le cas d' alimentations simples je pense que cela peut être une alternative simple et performante.