Io e un altro DBA della nostra azienda abbiamo il compito di rivedere un progetto di database che un fornitore ha sviluppato per noi. Il venditore ha dichiarato di utilizzare Kimball come base per il loro design. (NOTA: non sto cercando argomenti su Kimball vs Inmon, ecc.) Hanno progettato un mart con più fatti e dimensioni.
Ora in tutta onestà, la nostra azienda non ha mai progettato un singolo mart. Abbiamo sempre avuto i consulenti a farlo. E non siamo mai stati inviati a lezioni o altro. Quindi la nostra conoscenza del magazzinaggio / marts / modellazione dimensionale, ecc. Si basa su quella poca esperienza che abbiamo, ciò che possiamo trovare su Internet e l'auto-lettura (abbiamo i libri di Inmon e Kimball e stiamo cercando di farcela) .
Ora che il palcoscenico è pronto per il mio livello di conoscenza, arriviamo alla sfida del design.
Esiste una tabella dei fatti chiamata "Statistica delle perdite sinistri" (questo è per le assicurazioni). E stanno provando a catturare sia i pagamenti per i sinistri (arrotolati a un livello mensile), sia i soldi nelle riserve (un po 'come un conto bancario per i sinistri). Vogliono vedere gli importi mensili per i pagamenti (no biggie). Ma desiderano vedere il saldo corrente del conto delle riserve.
Farò un esempio pittorico.
Supponiamo di aver impostato $ 1000 USD in riserve per un reclamo. Questo viene messo da parte (quindi per alcuni aspetti funziona come un conto bancario).
Nell'ottobre 2014 non paghiamo ancora nulla. Quindi l'azienda vuole vedere i pagamenti e il saldo di riserva alla fine di ottobre.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------Quindi arriva novembre. Effettuiamo pagamenti di $ 100, $ 150 e $ 75 dollari. Vogliono vedere tali importi aggregati e la riserva al saldo come segue:
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------E poi diciamo che abbiamo zero pagamenti a dicembre e poi $ 200 in più a gennaio del prossimo anno.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------
- 122014 - 0.00 - 675.00 -
-----------------------------------------------
- 12015 - 200.00 - 475.00 -
-----------------------------------------------Qui è dove faccio fatica. La mia comprensione è che la parte dei pagamenti è corretta. Sono tutti raggruppati a livello mensile all'interno di ciascun record. Quindi puoi eseguire il rollup ulteriormente se lo desideri per l'anno, il trimestre, ecc.
Ma l'importo delle riserve è diverso. È un equilibrio. E l'azienda vuole vedere quanto c'è in saldo ogni mese. Ma non puoi aggregare in questo campo. Se lo facessi, otterrai alcuni risultati traballanti.
In qualche modo questo mi sembra sbagliato. Ma non posso sinceramente dire che ho modellato abbastanza o ne so abbastanza. Tutto quello che posso dire è quello che so. E da quello che so, tutti i valori di un Fatto dovrebbero essere alla stessa granularità.
Entrambi i numeri sono alla stessa granularità di un "mese", ma non sono dal punto di vista di ciò che rappresentano. Uno è dollari aggregati entro un mese. L'altro è solo l'equilibrio.
È corretto? Ho respinto questo progetto. Sbaglio a farlo? Va bene farlo in un dato di fatto? O il mio senso di "odore di codice" di un cattivo design è accurato?
Qualsiasi aiuto sarebbe apprezzato. NOTA: per favore non solo dire "Dovrebbe essere il modo X", per favore spiega perché dovrebbe essere così in modo che io possa imparare da questo.
EDIT : Beh, ho imparato che la mia comprensione iniziale del Fatto è sbagliata. La granularità NON è mensile. La granularità è a livello di transazione. Ciò significa che entro il MONTH_YEAR (ovvero in realtà è il periodo di rendicontazione finanziaria) ci saranno più operazioni di pagamento e recupero. Questi saranno registrati per data o data della transazione. Ma a causa di un precedente rapporto che l'azienda vede, e anche a causa di come i dati sono archiviati nel sistema legacy da cui provengono, volevano mettere sia i dati transazionali (una riga per) sia il saldo mensile di riserva (una riga al mese ).
Una volta appreso ciò, mi rendo conto che il problema non era tanto additivo contro non additivo, né semi-additivo quanto lo era il grano, che era ciò che sospettavo dall'inizio. Il nostro team DBA ha discusso di questo con il team del progetto e ha riferito che stanno tentando di mettere due grani diversi nello stesso fatto, e questo non era corretto. Il fatto che dovrebbero o aumentare le transazioni a un livello mensile, consentendo loro di avere i pagamenti, i recuperi e il saldo delle riserve mensili (cioè un fatto semi-additivo) perché tutto sarebbe a grano mensile. Oppure devono trovare un modo per scomporre il saldo di riserva in transazioni per preservare il livello di transazione. Oppure devono dividere il fatto in due fatti. Uno può essere il livello mensile per il saldo di riserva. L'altro può essere a livello di transazione per pagamenti e recuperi. (Non vi è alcun motivo per cui anche loro non possano mettere i pagamenti e i recuperi a livello mensile nella realtà a livello mensile. Dipende solo dalle esigenze aziendali.)
Dato quello che ho imparato, segnerò la risposta di Thomas come quella corretta. Tuttavia, ritengo che la discussione che ho iniziato con la domanda originale sia ancora valida per gli altri, quindi lascerò intatta la parte originale della mia domanda. Intendo anche assegnare una generosità alla risposta di Nikadam, poiché ciò mi ha insegnato molto sui fatti additivi, non additivi e semi-additivi e ha corretto molti fraintendimenti che ho avuto sulla modellazione dimensionale.
