ETL ou Copie de base

[BIMAN]

Bonjour,

Afin de réaliser un Datamart, je me pose la question du choix de l'alimentation des données. Pourquoi prendre un ETL plutôt que des copies de bases régulières.

L'ETL peut faire des opérations - Ok - mais la gestion, la maintenance, l'administration ou l'acquisition peuvent s'avérer compliquées.

La copie de base par un SGBD (Oracle, SQL Server etc.) tout les soirs permet de faire un annule et remplace des bases sans avoir de maintenance avec une image parfaite du système source.

Qu'en pensez vous ?

[Prjprj]

En faisant la copie d'une base tous les soirs, tu fais un infocentre (et encore), tu copies une base d'une application ailleurs et tu fais pointer sur celle-ci un outil de Reporting pour ne pas pourrir les perfs de la base d'origine.

Un Entrepôt de données ou un Datamart va bien plus loin que cela, et c'est pour ce "plus loin" qu'on a besoin d'un ETL.
Dans un DWH ou un DM, tu historises tes données, tu mets à plat tes hierarchies, tu consolides, tu calcules de nouveaux indicateurs, tu agrèges, tout cela te permettre d'enrichir tes données et de créer du sens à partir de tes données. Cela ne se fait pas par copie de base, cela se fait via un ETL (facilement) ou via des proc stock/vues (plus difficilement).

Après, la maintenance, ca dépend des ressources dispos dans ton entreprise.

[didafd]

Bonjour,mes amis
je veux construire un data warehouse par l'outil Oracle 9i
warehouse builder.
je cherche un Tutorial en français qui facilite la construction de cette entrepôt de données et faire l'ETL.

Est ce que Oracle 9i warehouse builder extraire les données de n'importe quelle base de données ou bien base de données oracle se tout? comment paramétrer Oracle 9i warehous builder :code utilisteur et mot de passe
de même le nom d’hôte, numero de port et sid oracle
SVP, mes amis aidez moi par des exemples et merci

[BIMAN]

Merci de ta réponse Prjprj.

Mon problème est que les ETL sembleent faciles d'utilisation à premièrees vues mais après quelques années : ils deviennent des gouffres en maintennace, temps de traitement. Au final une personne ne fait plus que ça.

C'ets pour cette raison que je cherche une solution rapide avec copie de bases car je suis sur de tout récupérer.

Par contre ta remarque est pertinente au ujet de l'historique. Peut être que les SGBD gère les différence entre base (au lieu de tout copier / recréer)

Qu'en pensez vous ?

[Prjprj]

@didafd : Un topic = un sujet, tu as une question, tu crées un nouveau topic

@BIMAN : Je ne connais pas ton expérience des ETLs, mais je ne pense pas que ta vision des ETL soit une généralité.
Il est vrai que plus les bases grossissent, plus les traitements ont tendance à être longs, mais cela vient souvent du fait qu'on optimise les traitements quand on est le nez collé au mur, le monde de l'informatique est ainsi fait...
Une bonne modélisation et une bonne conception permettent d'éviter les problèmes d'explosion de temps de traitement.

Concernant la maintenance, c'est une question de ressources, les personnes qui connaissent s'en vont et sont souvent remplacées par des personnes moins qualifiées qui prennent plus de temps à faire la même chose.

Si tu veux être sûr de ne rien oublier, tu peux construire tes traitements en deux phases : une copie de base pour avoir toutes les données à dispo sans risque d'en perdre en route et ensuite des traitements ETL pour enrichir et/ou historiser les données.

C'est moins "best practices" mais c'est une solution à moindre coût.

[BIMAN]

"Si tu veux être sûr de ne rien oublier, tu peux construire tes traitements en deux phases : une copie de base pour avoir toutes les données à dispo sans risque d'en perdre en route et ensuite des traitements ETL pour enrichir et/ou historiser les données."

Cest tout à fait ça Prjprj.

Je pense tester une solution de ce type :

- Faire un back up complet (SQL SERVER) : réplication de base, toutes les champs, données etc.

- Et ensuite faire tous les soirs un back up différentiel pour prendre en compte les ajouts/différences pour garder l'historique.

Par contre je ne sais pas (mais je ne pense pas que ce soit l'objet de cette rubrique) si SQL SERVER STANDARD permet de faire ces sauvegardes différentielles et si oui quelles sont les conséquences si des nouveaux champs ou tables sont créer dans la base source ? et ce que celle ci sont répliquée même en différentiel.

Voilà.

[Prjprj]

Envoyé par BIMAN

- Faire un back up complet (SQL SERVER) : réplication de base, toutes les champs, données etc.

- Et ensuite faire tous les soirs un back up différentiel pour prendre en compte les ajouts/différences pour garder l'historique.

Je crois qu'on s'est mal compris, moi ce que je te propose, c'est de faire une copie full de base tous les soirs et d'enrichir tes données via traitements ETL sur des tables hors du périmètre de ta sauvegarde.

De cette façon, tu gardes tes données courantes cohérentes et ton historique est séparé et ne risque pas d'entrer en conflit avec tes données courantes (pratique pour les corrections de bugs).
De plus, une copie full de base est généralement plus rapide qu'un traitement ETL copiant toutes les tables d'une base.

Envoyé par BIMAN

Par contre je ne sais pas (mais je ne pense pas que ce soit l'objet de cette rubrique) si SQL SERVER STANDARD permet de faire ces sauvegardes différentielles et si oui quelles sont les conséquences si des nouveaux champs ou tables sont créer dans la base source ? et ce que celle ci sont répliquée même en différentiel.

Je pense que tu devrais ouvrir un topic dédié dans la section administration sur SQL-Server où des DBA confirmés pourront te répondre (ils rodent par là d'après ce qu'on me souffle dans l'oreillette )

[BIMAN]

Merci PrjPrj.

J'ai ouvert un topic chez les experts SQL Server.