Sono surrogate chiavi primarie bisogno su una tabella dei fatti in un Data Warehouse?

Question

Quando ho chiesto il motivo per cui i nostri progettisti DB nostra tabella dei fatti non si ha una PK, mi è stato detto che non c'è nessun insieme di colonne della tabella che avrebbe identificare in modo univoco un record, anche se sono stati selezionati tutte le colonne. Whenb Ho suggerito che abbiamo una una colonna di identità in questo caso mi è stato detto che "Mi piacerebbe solo essere sprecando spazio e che non era necessario".

La mia sensazione è che ogni tavolo nel sistema di origine dovrebbe avere un PK, anche se si tratta di una colonna di identità. Dato che il data warehouse (DW) è un destinatario di dati provenienti da altri sistemi-come farei altrimenti in grado di garantire che i dati del DW riflette accuratamente ciò che si trova nel sistema di origine, se non v'è alcun modo per legare i singoli record? Se si dispone di un programma carico di instabilità che le viti backup dei dati e ha una durata di una settimana, come è possibile conciliare le differenze con un sistema di origine della transazione dal vivo w / o una sorta di vincolo univoco per confrontare?

Answer 1

tabella del database senza chiave primaria sembra una scelta cattiva progettazione e facendo un sacco di spazio per i diversi tipi di anomalie vale a dire come si dovrebbe eliminare o aggiornare singolo record in tale tabella?

Answer 2

Un data warehouse non è necessariamente un archivio dati relazionale, anche se si può scegliere di farne uno, in modo da definizioni relazionali non si applicano necessariamente.

Una chiave primaria è necessaria solo se si vuole fare qualcosa con i dati che richiede un identificatore univoco (come risalire a una fonte, ma che non è sempre necessario o comunque necessario o addirittura possibile); e dati in un data warehouse spesso possono essere utilizzati in modi che non richiedono chiavi primarie. In particolare, potrebbe non essere necessario per distinguere le righe l'uno dall'altro. Il più delle volte per la costruzione di valori aggregati.

Il tempo non è una dimensione necessaria nella costruzione di tabelle di data warehouse.

Può essere psicologicamente a disagio, e lo spazio sprecato è una questione banale, ma il suo collega è corretta - PK non sono necessari

.

Answer 3

Una colonna di tipo identità è un tasto "surrogato" che sostituisce una delle vostre chiavi "candidati" (in poche parole). L'aggiunta di un surrogato colonne chiave non aggiunge nulla, se non è possibile identificare una riga senza di essa. Che richiede una chiave candidata.

Answer 4

Si dovrebbe almeno avere una chiave naturale sulla tabella dei fatti in modo da poter identificare le righe e riconciliarli contro di origine o di tenere traccia delle modifiche qualora ciò risulti necessario.

In SQL Server una colonna di identità ti dà una chiave surrogata gratuitamente e su altri sistemi che utilizzano sequenze (ad esempio Oracle) può essere aggiunto abbastanza facilmente. Surrogate chiavi di tabella fatto può essere utile per varie ragioni. Alcune applicazioni possibili sono:

• Alcuni strumenti piace avere tasti numerici tabelle dei fatti, preferibilmente quelli monotona crescente. Un esempio di questo è MS SQL Server Analysis Services, che ama veramente avere un, monotona crescente tasto numerico per tabelle dei fatti utilizzati per popolare gruppi di misure. Ciò è particolarmente necessario per i carichi incrementali.

• In caso di relazioni tra le tabelle dei fatti (per esempio una scritta - ripartizione premio guadagnato per chi ha familiarità con assicurazione). Poi una chiave sintetica è utile qui

• Se si dispone di dimensioni che vivono in un M:. Rapporto M con una tabella dei fatti (ad esempio i codici ICD) quindi un tasto numerico sul tavolo infatti semplifica questo

• Se avete qualsiasi self-join requisiti per le operazioni (ad esempio alcune operazioni oggetto di correzioni agli altri) poi una chiave sintetica semplificherà lavorare con questi.

• Se fate operazioni di contropartita ribadire all'interno del vostro data warehouse (vale a dire gestire le modifiche ai dati transazionali generando inversioni e ri-affermando la riga) allora si può avere più righe della tabella dei fatti per la stessa chiave naturale.

In caso contrario, se non si avrà nulla di unirsi al vostro tavolo fatto in un 1:. Rapporto M poi una chiave sintetica probabilmente non verrà utilizzato per qualsiasi cosa

Answer 5

Sono d'accordo con te.

"Mi è stato detto che non c'è nessun insieme di colonne della tabella che avrebbe identificare in modo univoco un record, anche se sono stati selezionati tutte le colonne". - questo sembra rompere qualcosa di fondamentale sui database relazionali, come li capisco.

Un fatto è costituito da valori additivi più chiavi esterne alle dimensioni. Il tempo è una dimensione ovvio che è comune a tutti i modelli dimensionali, che io sappia. Se non altro, una chiave composita che contiene timestamp sarebbe certamente abbastanza unico.

Mi chiedo se i vostri amministratori di database hanno molta conoscenza circa modellazione tridimensionale. E 'un modo diverso di pensare dal normale relazionale, stile transazionale.

Answer 6

Lei ha ragione - sorta di. Senza una chiave primaria, una tabella non soddisfa la definizione minima di essere relazionale. E 'fondamentale essere una relazione che non deve permettere righe duplicate. Le tabelle in un design Data Warehouse dovrebbe essere relazionale, anche se non sono strettamente in forma normale.

Quindi ci deve essere qualche colonna (o insieme di colonne) nella riga che servono per identificare in modo univoco le righe. Ma non deve necessariamente essere un colonna di identità per una chiave surrogata.

Se la tabella dei fatti non ha nessun insieme di colonne che possono servire a questo ruolo di essere una chiave candidata, quindi più tabelle di quota sono necessari in questo DW, e più colonne sono necessari nella tabella dei fatti.

Questa nuova dimensione da solo non può essere la chiave primaria; può essere combinato con le colonne esistenti nella tabella dei fatti per creare una chiave candidata.

Answer 7

Se la tabella dei fatti è al centro di uno schema a stella, allora c'è in realtà una chiave candidata. Se si prende tutte le chiavi esterne nella tabella dei fatti insieme, quelli che puntano alle righe nelle tabelle dimensionali, che è una chiave candidata.

Probabilmente non farebbe molto bene a dichiararla come chiave primaria. L'unica cosa che sarebbe fare è proteggere da un processo di ETL canaglia. Le persone che gestiscono il magazzino potrebbe avere l'elaborazione ETL bene in mano.

Per quanto riguarda l'indicizzazione e la velocità di query è interessato, questa è tutta questione diversa con schemi a stella di quanto lo sia con i database OLTP oriented. Le persone che gestiscono il magazzino possono avere che in mano pure.

Quando si progetta un database da utilizzare OLTP, non è saggio avere un tavolo senza una chiave primaria. Le stesse considerazioni non riporto in depositi.

Answer 8

Ho sempre pensato che una tabella dovrebbe essere ordinato dai suoi query più comuni o battitori di prestazioni, quindi l'indice cluster di una tabella dovrebbe essere in linea con la domanda più difficile o comune.

La chiave primaria non deve essere un indice cluster in modo So che si potrebbe chiedere dove sto andando con questo, ma la mia preoccupazione è di più l'indice cluster che la chiave primaria (e siamo onesti, che normalmente si susseguono altro).

Quindi la domanda iniziale per me non è "dovrei avere una chiave primaria surrogata sulla tabella dei fatti?" ma più come "dovrei avere un indice cluster sulla tabella dei fatti?" Penso che la risposta è sì, si dovrebbe avere uno (e sì, ci sono altri messaggi su questo sito che coprono questa domanda, ma io continuo a pensare che vale la pena menzionare qui solo nel caso in cui questo è il popolo di domanda sono in realtà chiedono nonostante formulazione sbagliato)

Ci sono volte che si desidera una chiave surrogata, ma mi sento di raccomandare il cuore che il surrogato non è indice cluster della tabella. In questo modo sarebbe ordinare la tabella in linea con la chiave surrogata senza senso. (Spesso le persone aggiungere una colonna di identità surrogata ad un tavolo e ne fanno la chiave primaria e anche l'indice cluster per impostazione predefinita)

Quindi, quali colonne per rendere l'indice cluster su? Personalmente mi piace data per la tabelle dei fatti e per questo si potrebbe aggiungere FK di qualche altra dimensione di unicità, ma questo aumenterà dimensioni e forse non fornire alcun beneficio, come in modo che l'indice di essere utile alle dimensioni rilevanti dovrebbero essere riferimento (nel ordine di importanza che la chiave è stata generata con).

Per ovviare a questo (e la ragione di rispondere a questa qui) Penso che si dovrebbe aggiungere una surrogata e quindi creare l'indice cluster sulla chiave data e seguito dal surrogata (in questo ordine). Lo faccio perché la data da solo non sta andando a fare una fila unica, ma aggiungendo la volontà surrogata. Ciò mantiene i dati ordinati per data che aiuta tutti gli altri indici non cluster e mantiene anche la dimensione indice cluster ragionevoli.

Inoltre, come i dati cresce, si consiglia di dividerlo in questo caso avrete bisogno di una chiave di partizione che sarà invariabilmente data. Costruire l'indice cluster con la data come la parte principale del tasto rende questo più facile. Con il partizionamento è ora possibile utilizzare la tecnica finestra scorrevole di archiviare i dati vecchi o nel caricamento.

Answer 9

Non avendo un identificatore univoco per ogni riga è ancora peggio di quello che prima sembra. Certo, è precaria ed è facile da cancellare inavvertitamente alcune righe.

Ma la prestazione è molto peggio troppo. Ogni volta che si finisce per chiedere il database per ottenere le righe per i dipendenti con EmployeeType = 'Manager' si stanno facendo un confronto tra stringhe. Gli identificatori sono solo più veloce e migliore.

Inoltre, lo stoccaggio è a buon mercato e in questo caso immagino l'impatto sullo spazio sarà meno di un quarto di punto percentuale se che - come un data warehouse si sono probabilmente progettando per terabyte di dati.

Answer 10

http://www.ralphkimball.com/html/controversies.html

Fable:

La chiave primaria di una tabella è infatti costituito da tutte le chiavi esterne dimensione riferimento.

Fatto:

Una tabella dei fatti ha spesso 10 o più chiavi esterne che aderiscono alle chiavi primarie delle tabelle delle dimensioni. Tuttavia, solo un sottoinsieme di riferimenti chiave esterna della tabella infatti è in genere necessario per fila unicità. La maggior parte delle tabelle dei fatti hanno una chiave primaria che consiste in un sottoinsieme concatenati / composito delle chiavi esterne.

Answer 11

utilizzando la combinazione di tasti di dimensione surrogate come la chiave primaria della tabella dei fatti non funziona in tutti i casi. Si consideri il caso in cui vi sono tre dimensioni a, bec. Nella maggior parte dei disegni di solito abbiamo una fila dimensione per la "sconosciuta", assumiamo ho sempre assegnare questa riga la chiave surrogata di -1. Potrei facilmente avere due righe nella mia tabella dei fatti che hanno le chiavi a = n1, n2 b = c = -1, cioè duplicare chiavi perché le due righe non hanno ottenuto valori validi per dimensione C e così sia di risolvere alla riga sconosciuta.

Answer 12

Si sta confondendo due questioni qui - l'identificazione di un record unico nella tabella dei fatti, e rintracciare i record dal sistema di origine fino alla tabella dei fatti.

In quest'ultimo caso è del tutto possibile per un singolo record in un sistema di origine per avere più record della tabella dei fatti. Immaginate un record di sistema di origine che rappresenta un trasferimento di fondi da un conto all'altro. Ci potrebbero essere due record della tabella dei fatti per rappresentare questo, uno per il conto addebitato e uno per il conto dove. Inoltre ci potrebbe essere più record fatto per rappresentare diversi stati dei dischi di sistema sorgente in diversi punti è il ciclo di vita.

Per il rilascio della chiave primaria nella tabella dei fatti, non c'è davvero una risposta "corretta". Ci sono caratteristiche desiderabili / essenziali che si potrebbe desiderare (ad esempio, per l'identità di un singolo record da comunicare facilmente tra gli utenti del sistema, o per un singolo record da cancellare o aggiornato facilmente). Tuttavia, per un sistema di Oracle un ROWID potrebbe benissimo fare per che fino a quando non importa se cambia di tanto in tanto.

In realtà, però, c'è così poco overhead nel mantenimento di un singolo tasto sintetico che si potrebbe anche farlo comunque. Si può scegliere di non indicizzarlo, come l'indice sta per essere molto più grande consumatore di risorse rispetto alla colonna stessa.