Posso avere codici non di misura mescolati con misure nella mia tabella dei fatti?

Question

Stiamo facendo un po 'complesso di accumulo di dati. Il nostro cliente ci invia alcune cose che includono due dimensioni (tempo e unità di business). Il tempo è per lo più anno-mese. La dimensione dell'unità di business ha solo alcuni attributi: un nome e alcune categorie a cui le BU possono appartenere a fini di reportistica e analisi.

Le cose che ci inviano includono alcune informazioni sullo stato corrente (date e codici). Questi sembrano fatti. Inoltre, inviano alcune informazioni che caratterizzano il rapporto con la business unit (principalmente codici aggiuntivi). Ancora una volta, questi sono unici per la business unit e il periodo di tempo.

Infine, ci inviano cose che sono chiaramente fatti additivi. Include valuta e conteggi con unità appropriate.

Dovrei mescolare queste informazioni qualitative in una singola tabella dei fatti con i fatti additivi? O dovrei separare le cose qualitative (che possono essere usate solo con i conteggi) da quelle quantitative (che possono essere usate con la somma)?

Answer 1

Metti le cose nella tabella dei fatti solo se sono degenerate (causando problemi di alta cardinalità / unicità nella tua dimensione dove porta la dimensione in una relazione 1-1 con la tabella dei fatti). Kimball raccomanda di evitare la tentazione di inserire qualsiasi cosa tranne dimensioni degenerate nei fatti (numero di ordine unico, ad esempio).

Puoi sempre inserirli in ciò che Kimball chiama "junk" dimensione. Tutti quei codici possono essere semplicemente raggruppati in una dimensione spazzatura. La maggior parte delle date andrebbero nella tabella dei fatti come chiavi della dimensione della data in un ruolo particolare (di solito con una chiave int naturale del modulo AAAAMMGG - una delle uniche volte in cui non utilizziamo una chiave surrogata senza significato senza identità)

Mi piace ingenuamente vedere la stella come tutti i fatti e quindi quali colonne vanno in quali dimensioni è semplicemente determinata dalla convenienza. Non si dovrebbe necessariamente vederli come corrispondenti a una particolare entità aziendale - ricorda, la stella non è un database OLTP normalizzato in stile ERD.

Answer 2

Se i dati sono entrambi direttamente correlati al fatto additivo e non sono qualcosa su cui vuoi raggruppare / ordinare / cercare, metterli nella tabella dei fatti va bene.

Tuttavia, tieni presente che i dati non additivi nella tabella dei fatti impediranno il roll-up o diventeranno un'operazione con perdita di dati.

Answer 3

Brad Wilson descrive accuratamente il rischio di aggiungerli alla tabella dei fatti. In passato, ho aggiunto gli attributi spazzatura alla mia tabella dei fatti solo per richiedere il refactoring in seguito.

  

Le cose che ci inviano includono alcune   informazioni sullo stato corrente (date e   codici). Questi sembrano fatti. Essi   anche inviare alcune informazioni che   caratterizza la relazione con   l'unità di business (principalmente aggiuntiva   codici). Ancora una volta, questi sono unici per   unità aziendale e periodo di tempo.

A quale scopo commerciale servono le date? Direttamente, consiglierei di creare queste dimensioni e descriverle accuratamente.

Quanto sono volatili i codici extra che arrivano? Se il grano della tabella dei fatti è data e BU, perché non possono essere inclusi nella dimensione BU e trattati come attributi che cambiano lentamente?

Senza ulteriori dettagli non posso formulare una raccomandazione ferma, ma queste sarebbero le prime domande che mi porrei.