Ora e data dimensione nel data warehouse

Question

Sto costruendo un data warehouse. Ogni realtà ha la sua timestamp. Ho bisogno di creare rapporti di giorno, mese, trimestre, ma per ora troppo. Guardando gli esempi vedo che date tendono ad essere salvati in tabelle dimensionali.
_{(fonte: etl-tools.info )}

Ma credo, che non ha senso per il tempo. La tabella della dimensione avrebbe crescere e crescere. D'altra parte ENTRARE con tavolo data dimensione è più efficiente utilizzando le funzioni di data / ora in SQL.

Quali sono le tue opinioni / soluzioni?

(sto usando Infobright)

Answer 1

La mia ipotesi è che dipende dal vostro obbligo di segnalazione. Se avete bisogno di bisogno di qualcosa come

WHERE "Hour" = 10

significato ogni giorno 10:00:00-10:59:59, quindi vorrei usare la dimensione temporale, perché è più veloce di

WHERE date_part('hour', TimeStamp) = 10  

perché la funzione date_part () verrà valutata per ogni riga. Si dovrebbe comunque mantenere il timestamp nella tabella dei fatti, al fine di aggregare oltre i confini di giorni, come in:

WHERE TimeStamp between '2010-03-22 23:30' and '2010-03-23 11:15' 

che ottiene imbarazzante quando si utilizzano i campi di quota.

Di solito, dimensione temporale ha una risoluzione minuto, quindi 1440 righe.

Answer 2

Kimball consiglia avere tempo-e data dimensioni separate:

Design

-Tip-51-ultima-pensiero-on-tempo-dimensione-tavoli

  

Nelle precedenti libri Toolkit, abbiamo   consigliato costruire tale dimensione   con il componente minuti o secondi   del tempo come un offset dalla mezzanotte di   ogni giorno, ma siamo venuti a realizzare   che l'utente finale risultante   applicazioni è diventato troppo difficile,   soprattutto quando si cerca di calcolare il tempo   si estende. Inoltre, a differenza del giorno di calendario   dimensione, ci sono pochissimi   attributi descrittivi per la   specifica minuti o secondi all'interno di una   giorno. Se l'impresa ha ben   attributi definiti per intervalli di tempo   entro un giorno, come ad esempio nomi di turno, o   fasce orarie di pubblicità, un ulteriore   time-of-day dimensione può essere aggiunto a   il design in cui questa dimensione è   definito come il numero di minuti (o   anche secondi) dopo la mezzanotte. Così questo   dimensione temporale-ofday avrebbero o hanno   1440 record se il grano erano minuti   o 86.400 record se il grano fosse   secondi.

Answer 3

Il tempo dovrebbe essere una dimensione sul data warehouse, dal momento che sarà spesso vuole aggregare a questo proposito. È possibile utilizzare il fiocco di neve-Schema per ridurre il sovraccarico. In generale, come ho sottolineato nel mio commento, ora sembrano un insolitamente alta risoluzione. Se si insiste su di loro, rendendo l'ora del giorno una dimensione separata potrebbe aiutare, ma non si può dire se si tratta di un buon design.

Answer 4

Consiglierei visto dimensione separata per la data e l'ora. Data Dimension avrebbe 1 record per ogni data come parte della identificato intervallo valido di date. Per esempio:. 01/01/1980 al 2025/12/31

E una dimensione separata per tempo avere 86400 record con ogni secondo che ha un record identificato dalla chiave di volta.

Nei record dei fatti, in cui il bisogno di u data e ora entrambi, aggiungere due chiavi che hanno riferimenti a questi conformati dimensioni.