Impostazione di tabelle Dim e Fact per un data warehouse

Question

Ho il compito di creare un datawarehouse per un cliente. Le tabelle coinvolte non seguono realmente gli esempi tradizionali (prodotto / ordini), quindi ho bisogno di aiuto per iniziare. Il cliente è essenzialmente un centro di elaborazione per i casi (simile a un caso legale). Ogni giorno, i nuovi casi vengono inseriti nel DB nella sezione "casi" tavolo. Ogni colonna contiene alcune informazioni relative al caso. Durante l'elaborazione del caso, vengono popolate tabelle uno-a-molti aggiuntive con eventi correlati al caso. Esistono alcune di queste tabelle di eventi, le tabelle di esempio potrebbero essere: (case-open, case-dept1, case-dept2, case-dept3, ecc.). Ognuna di queste tabelle ha un caseid che si ricollega ai "casi" tavolo. Ci sono anche alcune tabelle di ricerca coinvolte.

Attualmente, le esigenze di reporting si riferiscono all'esposizione di strozzature nelle varie fasi e la granularità è al livello orario per alcune aree del processo.

Potrei chiedere troppo qui, ma sto cercando una direzione su come dovrei impostare le mie tabelle Dim e Fact o qualsiasi altro suggerimento che potresti avere.

Answer 1

Ti suggerisco di leggere i libri di Kimball, in particolare questo , che dovrebbe avere alcuni esempi per farti pensare alle applicazioni del tuo dominio problematico.

In ogni caso, devi decidere se un modello dimensionale è persino appropriato. È del tutto possibile trattare un "data warehouse aziendale" di un database 3NF con indici o riepiloghi diversi o altro.

Senza vedere il tuo schema attuale, è DAVVERO difficile da dire. Sembra che finirai con diversi modelli stellari con alcune dimensioni conformi che li legano insieme. Quindi potresti avere una dimensione del caso come una delle dimensioni conformate. I fatti di ogni altra tabella sarebbero in realtà tabelle che collegano sia la dimensione conformata sia qualsiasi altra dimensione appropriata ai fatti, quindi, ad esempio, se esiste un ID dipendente aperto, che si collegherebbe a una dimensione conforme dipendente , dalla tabella case-open-fact. Questa dimensione conforme potrebbe essere collegata più volte da diverse tabelle dei fatti sussidiarie.

Il metodo di modellazione di Kimball è abbastanza semplice e può essere seguito come una ricetta. È necessario iniziare identificando tutti i fatti, raggruppandoli in tabelle dei fatti, identificando le singole dimensioni su ciascuna tabella dei fatti e quindi raggruppandoli come appropriato in tabelle delle dimensioni e identificando il tipo di ogni dimensione.

Answer 2

La tabella dei fatti è l'evento case ed è "senza fatti" in quanto non ha valore numerico. Le dimensioni sarebbero il tempo, il tipo di evento, il caso e forse alcuni altri a seconda di quali altri dati sono nel sistema.

È necessario consolidare le tabelle degli eventi in una singola tabella dei fatti, etichettata con una dimensione "tipo di evento". I rapporti sul throughput / collo di bottiglia calcolano le differenze tra i tempi degli eventi per combinazioni specifiche di tipi di eventi in un determinato caso.

I rapporti dovrebbero calcolare i tempi evento-evento e possibilmente inserirli in un istogramma. È inoltre possibile etichettare determinati tipi di combinazioni di eventi e applicare l'etichetta agli eventi di interesse. A questi eventi potrebbe quindi essere registrato il tempo a loro sfavore, il che consentirebbe operazioni di slice-and-dice sui tempi con uno strumento OLAP.

Se si desidera confrontare determinate fasi della progressione del ciclo di vita, si dovrebbe avere una tabella che indica il tipo di caso, il tipo di evento 1, il tipo di evento 2, il tempo di riferimento.

Con un po 'di massaggio, potresti essere in grado di utilizzare un toolkit di data mining o anche una semplice analisi di regressione per individuare le correlazioni tra attributi del caso e tempi evento-evento (YMMV).

Answer 3

Come ogni altro aspetto dello sviluppo, è necessario affrontare il problema dai requisiti finali ("storie degli utenti", se lo si desidera) al contrario. L'approccio più conservativo per un magazzino è quello di rappresentare semplicemente una copia del database delle transazioni. Da lì, guidato dai requisiti, è possibile apportare alcune ottimizzazioni per migliorare le prestazioni di determinati modelli di accesso ai dati. Ritengo sia importante, tuttavia, vederli come ottimizzazioni e non dare per scontato che un data warehouse automaticamente debba essere un'esplosione complessa di ogni possibile dimensione su ogni fatto. La mia esperienza è che per la maggior parte degli scopi, una rappresentazione diretta è adeguata o addirittura ideale per il 90 +% delle query analitiche. Per il resto, considera innanzitutto gli indici, le viste indicizzate, le statistiche aggiuntive o altre ottimizzazioni che possono essere apportate senza influire sulle strutture. Quindi, se sono necessarie aggregazione o altre strutture ridondanti per migliorare le prestazioni, prendere in considerazione la possibilità di separarle in un "data mart" (almeno concettualmente) che prevede una separazione tra fatti primitivi e licenziamenti. Infine, se i requisiti sono troppo fluidi e l'aggregazione richiede troppo per funzionare in modo efficiente in questo modo, è possibile prendere in considerazione esplosioni all'ingrosso di dati, ad esempio lo schema a stella. Ancora una volta, però, limitalo alla sezione trasversale più piccola possibile dei dati.

Answer 4

Ecco cosa ho pensato essenzialmente. Grazie NXC

Eventi di fatto

EventID TimeKey CaseID

Eventi fiochi

EventID EventDesc

Dim Time

TimeKey

Regioni deboli

regionId RegionDesc

Casi

CaseID RegionId

Answer 5

Questo potrebbe essere il caso di scegliere una soluzione prima di aver considerato il problema. Non tutti i datawarehouse rientrano nel modello dello schema a stella. Non vedo che stai aggregando alcun dato qui. Finora abbiamo una tabella dei fatti senza fatti e almeno una dimensione (casi) in rapida evoluzione.

Osservando ciò che vedo finora, penso che l'entità centrale in questo database dovrebbe essere il caso. Cercare di attaccare l'evento nel mezzo non sembra giusto. Prova a guardarlo in un modo diverso. Forse, caso, eventi ed eventi caso da iniziare.