Progettazione di un data warehouse con più tabelle dei fatti

Question

Sono nuovo al data warehousing. In primo luogo, non voglio precisare che la mia copia di Datawarehouse Toolkit è sulla strada verso la mia casella di posta (posta ordinaria: P). Ma sto già studiando tutte queste cose con quello che trovo in rete.

Quello che non trovo in rete, tuttavia, è cosa fare quando sembra che ci sia più di un fatto in un DW. Nel mio caso (assicurazione), ho rimborsi che si verificano su base non regolare. Un cliente non può avere nessuno per 3 mesi e poi dieci negli stessi mesi. D'altra parte, ho una "quota di iscrizione" (non sono sicuro di quale sia il termine inglese corretto, ma ottieni il punto), che si verifica ogni mese o ogni tre mesi. Mi sembra una cosa del genere come due fatti distinti.

Anche questi sono un po 'legati in modo approssimativo da alcune dimensioni, come il cliente o il "prodotto di assicurazione". Ora sono questi due magazzini diversi, su cui devo produrre due report diversi e quindi collegare i report al di fuori del DW? O c'è un modo per progettare questo per adattarsi a una singola discesa DW. O dovrei combinare questi due fatti in uno? Probabilmente perderei granularità sui rimborsi.

Alcuni blog che ho letto dicono che un DW ha sempre una tabella dei fatti. Altri menzionano il passo della progettazione di quelle che sono le tabelle dei fatti con una S, ma non esiste un'istruzione chiara se esiste un collegamento tra di esse o sono solo componenti distinte di uno stesso progetto DW.

Qualcuno conosce alcuni riferimenti su quella parte precisa del design DW?

Answer 1

Riprendendo le domande.

Un data warehouse può avere più di una tabella dei fatti. Tuttavia, si desidera ridurre al minimo i join tra le tabelle dei fatti. È corretto duplicare le informazioni sui fatti in diverse tabelle dei fatti.

degli oggetti che si menzionati:

Il rimborso è un dato di fatto. Il timestamp è la dimensione del fatto di rimborso.

La tassa di abbonamento è un dato di fatto. Il timestamp è la dimensione del fatto di abbonamento.

Un rimborso può avvenire più di una volta. Immagino che ogni cliente abbia una quota di iscrizione. Quindi sembra che abbiamo due tabelle di fatti finora, il cliente e il rimborso del cliente.

Se sapevi che potrebbero esserci solo 3 rimborsi (ad esempio), eliminerai la tabella dei fatti di rimborso cliente e inserirai 3 colonne di rimborso nella tabella dei clienti.

Hai anche menzionato l'assicurazione. Un cliente può avere più di una politica. Quindi abbiamo una terza tabella dei fatti.

Un data warehouse viene solitamente progettato utilizzando star schema. Lo schema a stella è fondamentalmente una tabella dei fatti collegata a una o più tabelle dimensionali. Probabilmente avrai più di una stella in un data warehouse, dal momento che abbiamo già definito 3 tabelle dei fatti.

Answer 2

È possibile disporre di tutte le tabelle dei fatti che si desiderano. Nel tuo esempio si può avere qualcosa di simile:

DimProduct elenca diversi prodotti - sottoscrizione di essere uno di quelli. dimTransactionType sarebbe elencare le operazioni possibili (acquisto, il rimborso, ricorrenti canone di abbonamento ...)

Ora supponiamo che vi interessa nella segnalazione abbonamento semplificato, si potrebbe aggiungere un factSubscription come questo:

Answer 3

Mi rendo conto che sto rispondendo a un vecchio post, ma non sono soddisfatto di nessuna delle risposte fornite. Sento che nessuno dei due ha risposto alla domanda.

Uno schema può avere uno o più fatti, ma questi fatti non sono collegati da alcuna relazione chiave. È consigliabile non associare le tabelle dei fatti in una singola query, come si farebbe per interrogare un database normalizzato/transazionale. A causa della natura di molti a molti join, ecc., I risultati potrebbero essere errati se tentati.

La risposta che si sta cercando è che è necessario "eseguire il drillover" che in pratica significa che si sta interrogando ogni tabella dei fatti (schema) separatamente e unendo i risultati. Questo può accadere usando SQl o preferibilmente tramite uno strumento di reporting/analisi che potresti avere fatto riferimento al data warehouse. Invece di duplicare le risposte su come fare questo, io dirigerò a tutti di due articoli molto buoni:

Three ways to drill across by Chris Adamson

e

Should of the Warehouse - Drilling Across by Ralph Kimball