Trasformare OLTP di database relazionali al Data Warehousing Modello

Question

Quali sono gli approcci di progettazione comuni adottate nel caricamento dei dati da un tipico modello di database entità-relazione OLTP in uno schema a stella Data Warehouse Kimball / Marts modello?

• Non si utilizza una zona di sosta per eseguire la trasformazione e quindi caricare nel magazzino?
• Come si fa a collegare i dati tra il magazzino e il database OLTP?
• Dove / Come si fa a gestire il processo di trasformazione -? Nel database come pacchetti sprocs, DTS / SSIS o SQL dal codice dell'applicazione

Answer 1

Personalmente, tendo a lavorare come segue:

1. Progettare il data warehouse prima. In particolare, progettare le tabelle che sono necessari come parte del DW, ignorando tutte le tabelle di gestione temporanea.
2. Progettare l'ETL, utilizzando SSIS, ma a volte con SSIS chiamando le stored procedure nei database coinvolti.
3. Se tutte le tabelle di gestione temporanea sono richiesti nell'ambito del ETL, bene, ma allo stesso tempo assicurarsi che essi vengono puliti. Una tabella di transito utilizzato solo come parte di una singola serie di passaggi ETL devono essere tagliati dopo tali operazioni sono completate, con o senza successo.
4. Ho i pacchetti SSIS si riferiscono al database OLTP, almeno per estrarre i dati nelle tabelle di gestione temporanea. A seconda della situazione, si possono elaborare le tabelle OLTP direttamente nel data warehouse. Tutti tali query vengono eseguiti con (NOLOCK).
5. Documento, Documento, Documento. Chiarire quali input utilizzate da ciascun pacchetto, e dove l'uscita va. Assicurarsi di documentare i criteri con cui l'ingresso selezionati (ultime 24 ore? Dall'ultimo successo? Nuovi valori di identità? Tutte le righe?)

Questo ha funzionato bene per me, anche se devo ammettere che non ho fatto molti di questi progetti, né davvero grandi.

Answer 2

Al momento sto lavorando su una casa dataware piccole / medie dimensioni. Stiamo adottando alcuni dei concetti che Kimball deduce, vale a dire il sistema di stelle con tabelle dei fatti e delle dimensioni. Strutturiamo in modo che i fatti si uniscono solo per le dimensioni (non fatto per fatto o per dimensione dimensione - ma questa è la nostra scelta, non dicendo che è il modo in cui dovrebbe essere fatto), quindi abbiamo appiattire tutte le dimensioni si unisce alla tabella dei fatti.

Usiamo SSIS per spostare i dati dalla produzione DB -> DB sorgente -> DB messa in scena -> segnalazione DB (che probabilmente avrebbe potuto hanno usato meno DB, ma questo è il modo in cui è caduto).

SSIS è veramente bello come è consente di strutturare il vostro flussi di dati molto logico. Noi usiamo una combinazione di componenti SSIS e stored procedure, in cui una caratteristica piacevole di SSIS è la capacità di fornire i comandi SQL come una trasformazione tra un flusso di dati di origine / destinazione. Questo significa che possiamo chiamare stored procedure su ogni riga, se vogliamo, che può essere utile (anche se un po 'più lento).

Stiamo anche utilizzando una nuova funzione di cattura 2008 chiamato il cambiamento dei dati di SQL Server (CDC), che permette di controllare tutte le modifiche su una tabella (è possibile specificare le colonne che si desidera guardare a quei tavoli), quindi abbiamo usare che il DB di produzione per dire cosa è cambiato in modo che possiamo muovere solo i record attraverso al DB sorgente per l'elaborazione.

Answer 3

Sono d'accordo con la risposta molto quotato ma ho pensato aggiungere quanto segue:

* Do you use a staging area to perform the transformation and then

     

Carica nel magazzino?

Dipende dal tipo di trasformazione che richiederà staging. Messa in scena offre vantaggi di rompere l'ETL in pezzi più gestibile, ma fornisce anche una zona di lavoro che consente manipolazioni di prendere posto sui dati senza compromettere il magazzino. Può aiutare ad avere (almeno) alcune ricerche di quota in una zona di sosta che memorizzano le chiavi dal sistema OLTP e la chiave del ultimo disco fioca, da utilizzare come una ricerca durante il caricamento i tuoi record dei fatti. La trasformazione avviene nel processo ETL in sé, ma può o non può richiedere alcuni staging per aiutare lungo la strada.

* How do you link data between the warehouse and the OLTP database?

E 'utile per caricare le chiavi business (o chiavi primarie effettive se disponibili) nel data warehouse come riferimento al sistema OLTP. Inoltre, il controllo in processo DW dovrebbe registrare la discendenza di ciascun bit di dati registrando il processo di caricamento che è stata caricata.

* Where/How do you manage the transformation process - in the

     

database come pacchetti sprocs, DTS / SSIS,   o SQL dal codice dell'applicazione?

Questo viene in genere in pacchetti SSIS, ma spesso è più performante di trasformare nella query di origine. Purtroppo questo rende la query di origine piuttosto complicato da capire e quindi mantenere, quindi, se le prestazioni non è un problema, allora trasformando nel codice SSIS è il migliore. Quando si esegue questa operazione, questo è un altro motivo per avere una zona di sosta, come allora si può fare più join nella query di origine tra le diverse tabelle.

Answer 4

John Saunders' spiegazione processo è una buona.

Se si sta cercando di realizzare un progetto Datawarehouse in SQL Server si trovano tutte le informazioni necessarie per la fornitura di tutto il progetto all'interno del testo eccellente " Il Microsoft Data Warehouse Toolkit ".

abbastanza Funilly, uno degli autori è Ralph Kimball: -)

Answer 5

Si consiglia di dare un'occhiata a Data Vault Modeling . Essa sostiene la risoluzione di alcuni problemi termine solitario come cambiare gli attributi.