Le tabelle dei fatti sono il fondamento del data warehouse. Contengono le misure fondamentali dell’azienda e sono l’obiettivo finale della maggior parte delle query di data warehouse. Non ha senso sollevare le tabelle dei fatti sul pennone a meno che non siano state scelte per riflettere le priorità aziendali urgenti, siano state accuratamente assicurate dalla qualità e circondate da dimensioni che forniscono una vasta gamma di punti di ingresso per vincolare e raggruppare. Ora che abbiamo aperto la strada alle tabelle dei fatti, vediamo come costruirle e usarle.
Rimani fedele alla grana
Il primo e più importante passo di progettazione è dichiarare la grana della tabella dei fatti. La grana è la definizione aziendale di ciò che rappresenta un singolo record di tabella dei fatti. La dichiarazione grain non è un elenco di chiavi esterne dimensionali che implementano una chiave primaria per la tabella dei fatti. Piuttosto, il grano è la descrizione dell’evento di misurazione nel mondo fisico che dà origine a una misurazione. Quando lo scanner negozio di alimentari misura la quantità e il prezzo addebitato di un prodotto acquistato, il grano è letteralmente il segnale acustico dello scanner. Questa è una grande definizione di grano!
Subito dopo aver dichiarato la grana, è possibile elencare le chiavi esterne dimensionali che esistono in quella grana. Dichiarando prima il grano, la discussione delle chiavi esterne rimane fondata e precisa.
Il vero scopo della tabella dei fatti è quello di essere il repository dei fatti numerici che vengono osservati durante l’evento di misurazione. È di fondamentale importanza che questi fatti siano fedeli al grano. Il negozio di alimentari” beep ” misura la quantità e il prezzo esteso del prodotto sottoposto a scansione. Non includiamo mai altre misure numeriche che violano la grana, come le vendite complessive di categoria o le vendite di questo prodotto il mese scorso. Anche se queste altre misurazioni potrebbero essere strettamente utili per calcoli selezionati, non possono essere combinate tra i record dei fatti e introducono strane asimmetrie nella progettazione delle applicazioni. Lasciamo che i nostri strumenti di business intelligence (BI) calcolino questi valori off-topic al momento della query piuttosto che codificarli nelle nostre tabelle dei fatti.
Ci sforziamo sempre di rendere i fatti additivi attraverso le dimensioni ed esattamente coerenti con il grano. Si noti che non memorizziamo il prezzo del prodotto sottoposto a scansione perché il prezzo non è aggiuntivo. Piuttosto, memorizziamo il prezzo esteso, che può essere aggiunto liberamente tra prodotti, negozi, orari e tutte le altre dimensioni.
Costruire dalla grana più bassa possibile
Il data warehouse dovrebbe sempre essere costruito su tabelle di fatto espresse alla grana più bassa possibile. Nell’esempio, il segnale acustico del registratore di cassa del negozio di alimentari è il grano più basso possibile perché non può essere diviso ulteriormente. Le tabelle dei fatti con la grana più bassa sono le più espressive perché hanno il set più completo di dimensioni possibili per quel processo aziendale. La tabella beep grain fact potrebbe avere Data, Negozio, Prodotto, cassiere, Manager, Cliente, Promozione, Concorrenza, Cestino e persino Tempo se tutte queste fonti di dati possono essere marshallate quando vengono creati i record dei fatti. Le tabelle aggregate a grana più alta, come le vendite per categoria per distretto, non possono supportare tutte queste dimensioni e quindi sono molto meno espressive. È un errore fondamentale pubblicare solo tabelle aggregate per gli utenti finali senza rendere le tabelle di fatto a grana più bassa facilmente accessibili perforando verso il basso. La maggior parte delle false nozioni che le tabelle dimensionali presuppongono la domanda aziendale provengono dal fare questo errore fondamentale.
Tre tipi di tabelle dei fatti
Se si rimane fedeli alla grana, tutte le tabelle dei fatti possono essere raggruppate in soli tre tipi: grana delle transazioni, grana delle istantanee periodiche e grana delle istantanee accumulate (i tre tipi sono mostrati in Figura 1). Nella Figura 1, le dimensioni sono indicate da FK (chiave esterna) e i fatti numerici sono in corsivo.
La grana della transazione corrisponde a una misurazione effettuata in un singolo istante. Il bip negozio di alimentari è un grano transazione. I fatti misurati sono validi solo per quell’istante e per quell’evento. Il prossimo evento di misurazione potrebbe accadere un millisecondo più tardi o il prossimo mese o mai. Pertanto, le tabelle dei fatti del grano delle transazioni sono imprevedibilmente sparse o dense. Non abbiamo alcuna garanzia che tutte le possibili chiavi esterne saranno rappresentate. Le tabelle dei fatti di grano delle transazioni possono essere enormi, con il più grande che contiene molti miliardi di record.
La grana istantanea periodica corrisponde a un intervallo di tempo predefinito, spesso un periodo di rendicontazione finanziaria. Figura 1 illustra un conto mensile istantanea periodica. I fatti misurati riassumono l’attività durante o alla fine dell’intervallo di tempo. Il grano snapshot periodica porta una potente garanzia che tutte le entità di reporting (come il conto bancario in Figura 1) apparirà in ogni snapshot, anche se non vi è alcuna attività. L’istantanea periodica è prevedibilmente denso, e le applicazioni possono contare su combinazioni di tasti sempre presenti. Le tabelle periodiche dei fatti istantanei possono anche diventare grandi. Una banca con 20 milioni di conti e una storia di 10 anni avrebbe 2.4 miliardi di record nel conto mensile istantanea periodica!
La tabella dei fatti istantanei accumulati corrisponde a un processo prevedibile che ha un inizio e una fine ben definiti. L’elaborazione degli ordini, l’elaborazione dei reclami, la risoluzione delle chiamate di servizio e le ammissioni all’università sono candidati tipici. La grana di un’istantanea accumulata per l’elaborazione degli ordini, ad esempio, è in genere l’elemento pubblicitario dell’ordine. Si noti in Figura 1 che ci sono più date che rappresentano lo scenario standard che subisce un ordine. L’accumulo di record di snapshot viene rivisitato e sovrascritto mentre il processo procede attraverso i suoi passaggi dall’inizio alla fine. L’accumulo di tabelle di snapshot in genere è molto più piccolo degli altri due tipi a causa di questa strategia di sovrascrittura.