Modellazione dimensionale: una tabella dei fatti dovrebbe avere una chiave esterna?

Question

Una tabella dei fatti non può contenere alcuna chiave? o se può, è un buon design? Se una tabella dei fatti non ha alcuna dimensione, su quale base viene analizzata?

Che cosa succede se una tabella dei fatti ha solo chiavi primarie e nessuna chiave esterna?

Answer 1

Parlando in modo inesatto, le chiavi esterne ti collegano alle tabelle che suddividono la tabella dei fatti in categorie e sottocategorie.

Quindi se la tabella dei fatti era

create table stores (id, kindOfStore, sales)

Quindi kindOfStore sarebbe la tua dimensione - se fosse così, allora potresti sostenere che una tabella separata per kindOfStore è eccessiva (tranne per lo spazio sprecato dicendo tipo di negozio = " Food " anziché " Kind_id = 8 " ;. Se hai sottocategorie, ha senso collegarti a una tabella diminsion come

create table kindOfStore (id, Variety, Specialization, Subspecialization) 

Sarebbe saggio spazio inefficiente per memorizzare la varietà, la specializzazione e la sottospecializzazione nella tabella dei fatti.

Lo schema risultante è uno schema a stella e i data warehouse sono ottimizzati per gestire tali schemi, anche se i motori di data warehouse più recenti e più veloci sembrano essere così veloci che anche uno schema non a stella è piuttosto veloce.

I datawarehouse denormalizzano (usano meno tabelle) le tabelle dei fatti rispetto a un database OLTP, ma ciò non significa che dovresti cercare una soluzione con una sola tabella.

Answer 2

La modellazione dimensionale è progettata per consentire al fatto di avere dettagli aggiuntivi sospesi, descrivendo gli attributi che possono essere " arrotolati " e aggregato in informazioni di sintesi significative. È una caratteristica del datawarehousing (un ambiente principalmente READ), ma può anche avere il suo posto nell'OLTP, modellando dati realmente transazionali su fatti primari (pensa a transazioni su un conto bancario, che potrebbero essere transazioni finanziarie, note e revisioni della lapide del cliente - tutti con un collegamento comune all'entità del conto bancario).

Prime tra la serie di dettagli solitamente sospesi dal fatto sono le dimensioni TIME e PLACE.

Se il tuo fatto non esiste nel tempo o nello spazio, potrebbe presumibilmente esistere senza una voce in quelle dimensioni (anche se non posso per la vita di me capire quando un fatto sarebbe così).

Se ulteriormente, le altre dimensioni sono piccole e contenute (il che significa che nessun altro fatto le condivide), potresti cavartele rotolando nella tabella dei fatti originale come un ENUM.

Il risultato finale sarebbe una singola tabella dei fatti, con più dimensioni ridotte rappresentate come ENUMS.

Ma sarebbe un caso estremamente strano per alcuni dati davvero strani ...

Answer 3

in un buon design, ogni tabella avrà una chiave primaria.

l'uso di chiavi esterne dipenderà da cosa / come si sta tentando di vincolare i valori delle tabelle. fornire informazioni più specifiche sulla propria situazione se si desidera una risposta più specifica

Answer 4

Il caso che posso ricordare è quando si utilizza una tabella che contiene attributi ai fini dell'elenco delle dimensioni e lo strumento richiede di impostare / contrassegnare / identificare una tabella o un alias come tabella dei fatti.

Immagina un DB di vendita, la tabella delle opportunità contiene un lungo elenco di attributi, giusto? Il tuo cliente dice & Quot; Voglio ottenere un elenco di tutti i nomi opportunità, ID e persone assegnate come proprietari oppty & Quot; ... Quindi puoi creare un alias o un sinonimo o mappare la stessa tabella nella tua logica design.

Le dimensioni degenerate possono essere un altro caso ... quindi ... sebbene la tabella sia una tabella dei fatti reali, la funzionalità fornita è praticamente la stessa, non è vero?