Unire fatti da fonti diverse? O caricare separatamente?

Question

Abbiamo dati con due origini diverse: alcuni provengono da un cliente, altri provengono da fornitori diversi. Attualmente, "uniamo" fisicamente " questi dati in una tabella enorme con quasi un centinaio di colonne, decine di migliaia di righe e nessuna separazione formale delle due dimensioni. Di conseguenza, non possiamo effettivamente utilizzare questa tabella per molto.

Ridisegnerò questo casino in uno schema a stella adeguato, ma piccolo.

Le due dimensioni sono ovvie. Uno di questi, ad esempio, è il tempo.

I dati forniti dal cliente forniscono numerosi valori di fatto. Ogni fornitore può (o meno) fornire valori fattuali aggiuntivi che si adattano alle stesse dimensioni.

Questi dati di fatto hanno tutti la stessa granularità. Può essere chiamato " sparse " perché spesso non riceviamo informazioni da tutti i fornitori.

Ecco il mio dilemma.

Questa è una tabella dei fatti - con alcuni valori null - popolata da fonti diverse?

Oppure si tratta di n +1 tabelle dei fatti - una popolata dal cliente, l'altra popolata da ciascun fornitore?

Ci sono pro e contro in ogni disegno. Ho bisogno di alcune seconde opinioni sulla scelta tra "unire" oppure " caricare separatamente " ;.

---

Il cliente fornisce entrate, costi, conteggi, pesi e altre cose che sanno sulla fine di una transazione.

Il fornitore fornisce alcuni dettagli aggiuntivi su alcune delle transazioni: pesi, costi, durate. Le altre transazioni non avranno alcun valore dal fornitore uno.

Il fornitore due fornisce alcuni dettagli aggiuntivi su alcune delle transazioni: volumi, durate, lunghezze, tassi di cambio. Le altre transazioni non avranno alcun valore per il fornitore due.

Alcune transazioni avranno entrambi i fornitori. Alcune transazioni non avranno né il fornitore.

Una tabella con valori null? Tre tavoli?

Answer 1

Vorrei scegliere la tabella dei fatti singoli. Il punto forte di questo approccio è che lascia tutto il duro lavoro al momento del caricamento piuttosto che al momento della query.

Answer 2

Da quello che descrivi, sembra che una sola tabella dei fatti sia la strada da percorrere.

Sembra che la tabella dei fatti avrebbe una gran quantità di tempo x transazione x cliente (?).

La mia domanda precedente stava davvero cercando di scoprire se alcuni dei dati del fornitore erano candidati per la propria dimensione. Lascio a te determinare questo. ma non sembra proprio così.

I fatti nulli possono generare avvisi durante le aggregazioni (a seconda della piattaforma), ma l'alternativa di popolarli con zeri probabilmente fuorvianti è peggiore.

Answer 3

Credo che poiché entrambe le fonti condividono lo stesso grano, la risposta è che dovresti avere una tabella dei fatti. Pensa a come desideri che gli utenti finali interagiscano con le informazioni. Se ha senso e i rapporti commerciali trarranno vantaggio dalla collocazione congiunta di tali dati, questa è la tua risposta. Cerca però di evitare valori nulli nelle tabelle dei fatti. Se puoi inserire uno zero (e lo zero ha senso per i dati, cioè pensa alla temperatura), fallo. Ciò consentirà di risparmiare confusione ai tuoi utenti e, come sottolineato da TrickyNixon, causerà problemi di aggregazione.

In realtà sei a un buon punto qui sull'applicazione 'brownfield'. Puoi guardare ciò che esiste oggi e sfruttare l'esperienza per creare un design migliore. Questo è il momento più importante per selezionare il miglior grano che si spera non cambi per la vita del DW.