Trasformare il database relazionale OLTP nel modello di data warehouse

Question

Quali sono gli approcci di progettazione comuni adottati nel caricamento dei dati da un modello di database OLTP tipico di Entity-Relationship in uno schema di Kimball modello di data warehouse/Marts?

• Si utilizza un'area di gestione temporanea per eseguire la trasformazione e quindi caricarla nel magazzino?
• Come si collegano i dati tra il magazzino e il database OLTP?
• Dove/Come si gestisce il processo di trasformazione: nel database come sprocs, pacchetti dts/ssis o SQL dal codice dell'applicazione?

Answer 1

Personalmente, tendo a lavorare come segue:

1. design warehouse i dati prima. In particolare, progettare le tabelle necessarie come parte del DW, ignorando eventuali tabelle di staging.
2. Progettare l'ETL, utilizzando SSIS, ma a volte con SSIS che chiama stored procedure nei database coinvolti.
3. Se alcune tabelle di staging sono richieste come parte dell'ETL, bene, ma allo stesso tempo assicurarsi che vengano ripulite. Una tabella di staging utilizzata solo come parte di una singola serie di passaggi ETL deve essere troncata al termine di tali passaggi, con o senza esito positivo.
4. I pacchetti SSIS fanno riferimento al database OLTP almeno per inserire dati nelle tabelle di staging. A seconda della situazione, possono elaborare le tabelle OLTP direttamente nel data warehouse. Tutte queste query vengono eseguite con (NOLOCK).
5. Documento, documento, documento. Metti in chiaro quali input sono usati da ciascun pacchetto e dove va l'output. Assicurati di documentare i criteri con cui l'input è selezionato (ultime 24 ore? Dall'ultimo successo? Nuovi valori di identità? Tutte le righe?)

Questo ha funzionato bene per me, anche se ammetto di non averlo fatto molti di questi progetti, né di quelli veramente grandi.

Answer 2

La spiegazione del processo di John Saunders è buona.

Se stai cercando di implementare un progetto Datawarehouse in SQL Server, troverai tutte le informazioni necessarie per la consegna dell'intero progetto all'interno dell'eccellente testo "The Microsoft Data Warehouse Toolkit".

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

Answer 3

Attualmente sto lavorando su una casa dataware piccole/medie dimensioni. Stiamo adottando alcuni dei concetti proposti da Kimball, vale a dire lo schema a stelle con tabelle dei fatti e delle dimensioni. Lo strutturiamo in modo che i fatti si uniscano solo alle dimensioni (non di fatto in fatto o dimensione in dimensione - ma questa è la nostra scelta, non dicendo che è il modo in cui dovrebbe essere eseguita), quindi appiattiamo tutti i join di dimensione alla tabella dei fatti.

Utilizziamo SSIS per spostare i dati dal DB di produzione -> DB di origine -> DB di staging -> DB di report (probabilmente avremmo potuto utilizzare meno DB, ma è così che è caduto).

SSIS è davvero bello in quanto consente di strutturare i flussi di dati in modo molto logico. Utilizziamo una combinazione di componenti SSIS e stored proc, in cui una delle funzionalità di SSIS è la possibilità di fornire comandi SQL come una trasformazione tra un flusso di dati di origine/destinazione. Ciò significa che possiamo chiamare proc memorizzati su ogni riga, se vogliamo, che può essere utile (anche se un po 'più lento).

Stiamo anche utilizzando un Server 2008 cattura funzionalità chiamata Change Data nuovo SQL (CDC), che permette di controllare tutte le modifiche su una tabella (è possibile specificare le colonne che si desidera guardare a quei tavoli), quindi abbiamo utilizzalo sul DB di produzione per dire cosa è cambiato in modo da poter spostare solo quei record nel DB di origine per l'elaborazione.

Answer 4

Si consiglia di dare un'occhiata a Data Vault Modeling. Afferma di risolvere alcuni problemi solitari come la modifica degli attributi.

Answer 5

Sono d'accordo con la risposta molto quotato, ma ho pensato di aggiungere il seguente:

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

carico nel magazzino?

Essa dipende dal tipo di trasformazione che richiederà staging. La stadiazione offre i vantaggi di rompere l'ETL in blocchi più gestibili, ma fornisce anche un'area di lavoro che consente di effettuare manipolazioni sui dati senza intaccare il magazzino. Può aiutare ad avere (almeno) alcune ricerche dimensionali in un'area di staging che memorizza le chiavi dal sistema OLTP e la chiave dell'ultimo record di oscuramento, da utilizzare come ricerca quando si caricano i record dei fatti. La trasformazione avviene nel processo ETL stesso, ma può o non può richiedere alcuni staging per aiutarlo lungo la strada.

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

È utile per caricare le chiavi business (o chiavi primarie reali se disponibile) nel data warehouse come riferimento al sistema OLTP. Inoltre, il controllo nel processo DW dovrebbe registrare la discendenza di ciascun bit di dati registrando il processo di caricamento che l'ha caricato.

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

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

Questo di solito è nei pacchetti SSIS, ma spesso è più performante da trasformare nella query di origine. Sfortunatamente ciò rende la query di origine piuttosto complicata da comprendere e quindi mantenere, quindi se le prestazioni non sono un problema, la trasformazione nel codice SSIS è la migliore. Quando si esegue questa operazione, questo è un altro motivo per avere un'area di gestione temporanea in quanto è possibile creare più join nella query di origine tra tabelle diverse.