Progettazione del data warehouse Oracle: tabella dei fatti che funge da dimensione?

Question

GRAZIE: entrambe le risposte sono molto utili, ma potrei sceglierne solo una. Apprezzo molto il consiglio!

il nostro datawarehouse verrà utilizzato più per i report sul flusso di lavoro rispetto ai report analitici tradizionali. Ai nostri utenti interessa "quotazione attuale" molto più della storia. (anche se la storia conta anche.) Siamo un'entità governativa che non ha costi o calcoli correlati. Principalmente conta solo le persone all'interno di determinate località e con storia correlata.

Stiamo usando Oracle, e ho trovato evidente vantaggio nell'usare il join a stella ogni volta che è possibile e vorrei ricercare di nuovo tutto per assomigliare allo schema a stella quanto è ragionevole per i nostri usi aziendali. La velocità in questo DW è di vitale importanza e numerosi test hanno già dimostrato il mio approccio allo schema a stella.

La nostra "persona" la tabella è la chiave: contiene oltre 4 milioni di record e sarà la fonte più utilizzata nelle query. Può essere vista al centro di una stella con più dimensioni (come età, sesso, affiliazione, posizione , eccetera.). È una tabella molto LUNGA, in particolare quando mi unisco all'indirizzo e alle informazioni di contatto.

Tuttavia, è più simile a una tabella dimensionale quando iniziamo a guardare la cronologia. Ad esempio, ci sono due diverse tabelle cronologiche che hanno una chiave persona che punta alla tabella persona. Uno ha oltre 20 milioni di record e l'altro ne ha quasi 50 milioni e cresce ogni giorno.

Questa tabella è una tabella dei fatti o una tabella delle dimensioni? Si può lavorare come entrambi? In tal caso, sarà un grosso problema di prestazioni? È comune interrogare più di una dimensione che di un fatto? Cosa succede se una tabella dei fatti DIVERSA che utilizza la tabella delle persone come dimensione è in realtà solo 60.000 record (molto più piccoli.)

Penso che il mio problema sia che i nostri dati e il loro utilizzo non si adattano agli esempi comunemente utilizzati di schemi a stella.

CHIARIMENTI: Alcuni pensieri positivi sono stati aggiunti di seguito, ma forse ho lasciato troppo fuori per spiegare davvero bene. Ecco alcune altre informazioni:

Gestiamo un database degli elettori. Non abbiamo alcuna misura se non il conteggio degli elettori per vari gruppi: il conteggio degli elettori per partito, per età, per posizione; gli elettori contano per tipo di votazione ed elezione, per stato di votazione ed elezione, ecc. Abbiamo una "cronologia dei voti" registro e registro di controllo attività (cambio di indirizzo, parte, ecc.). Abbiamo informazioni su quali elettori sono elettori e tutte quelle informazioni correlate. Immagino che arriverò alle cose periferiche più tardi.

Per ora mi sto concentrando sui nostri due principali "processi aziendali": la registrazione degli elettori (che è un elettore) e l'affluenza alle elezioni. Nel primo, l'elettore è un dato di fatto. Nel secondo, l'elettore è una dimensione, insieme a partito, elezione e tipo di votazione. (e nel caso qualcuno sia preoccupato - no non sappiamo come votano le persone. Solo che lo fanno. LOL)

Spero che chiarisca un po 'le cose.

Answer 1

ok - questa non è una risposta completa " answer " ;, ma è vicina.

Nota questo post di blog che descrive una lezione di Kimball: http: // database-geek .com / 2005/03/28 / a-day-with-ralph-Kimball-parte-2 /

Il motivo per cui sto lottando è che questo è un "degenerato" dimensione. Il mio registro degli elettori e le informazioni associate sono uno a uno con la mia "registrazione". tabella dei fatti. Quindi sembra che sia persino ok con Kimball buttarlo nella tabella dei fatti.

Quindi ora sto solo esaminando cosa succede quando una tabella dei fatti viene utilizzata da un'altra tabella dei fatti.

MODIFICA: Inoltre, ho trovato su Google il termine "dimensione mostro". essere molto utile. È molto simile a una dimensione del cliente che cambia lentamente. Finché sono disposto a fare il fiocco di neve, posso ottenere ciò di cui ho bisogno: le stelle si uniscono quando si interrogano gli elettori e non causano problemi a usare l'elettore come dimensione per varie tabelle dei fatti.

EDIT: Ecco la mia conclusione finale: come consigliato sopra, il punto è facilitare il processo aziendale, non adattarlo al diagramma del libro di testo.

La nostra attività è tale che non vi è assolutamente alcun motivo per dividere la tabella degli elettori (con una tabella dei fatti per "registrazioni" e una dimensione per gli "elettori") - quando si esegue una query con quella tabella desideriamo tutti gli attributi così come tutte le bandiere e le informazioni di testo. Non vorrei suddividere gli attributi separatamente in "fact" (come il libro di Kimball mostra per i clienti e gli ordini) perché tali attributi significano qualcosa di diverso se associati ai fatti rispetto a quando sono collegati alle dimensioni. Inoltre, gli elettori vengono utilizzati come attributo in più luoghi, alcuni dei quali si adattano a una stella tradizionale.

Il mio scopo principale è SPEED. Quindi ho scelto un formato modificato - un po 'come il fiocco di neve - in cui l'elettore è il centro di più tabelle e l'oracolo può usare il collegamento a stella quando indicizzo tutto nel modo giusto. Quindi, uso l'elettore come una dimensione in tutte le altre mie "stelle". In ogni caso, l'ho impostato in modo che la maggior parte, se non tutte, le tabelle possano essere unite usando il join a stella, anche se non è " libro di testo. & Quot;

Grazie ancora per l'aiuto!

Answer 2

Se possibile, il mio suggerimento sarebbe di riformattare queste tabelle in modo che siano più in linea con uno schema a stella reale. Anche se 50 milioni di record sembrano molto (quando si pensa a un sistema transazionale), abbiamo più tabelle dei fatti con un massimo di 500 milioni di righe. Supponendo che il tuo hardware sia stato progettato per questo tipo di lavoro, non dovresti avere problemi a combinare le tue tabelle in una grande tabella dei fatti (supponendo che siano tutti all'interno della stessa area tematica).

Detto questo, assicurati di tenere conto degli altri fattori che dovrebbero essere considerati quando scegli una struttura altamente denormalizzata. Lo schema a stella è un ottimo design per il reporting dei dati a causa della riduzione dei join necessari, tuttavia, spesso si paga un prezzo elevato per questo durante l'aggiornamento delle tabelle e nello spazio su disco. Quando dici che stai pensando di utilizzare questo schema per più di un'applicazione di flusso di lavoro, piuttosto che principalmente di analisi, mi assicurerei di tenere conto degli aggiornamenti. Sono necessari aggiornamenti in tempo reale o quasi in tempo reale? In tal caso, potresti non voler considerare una stella.

Infine, sì, in alcuni casi interroghiamo solo le nostre tabelle dimensionali, spesso quando un'applicazione necessita di un elenco specifico di articoli (ad es. prodotti, clienti, ecc.), questo è un uso valido, tuttavia, una soluzione migliore potrebbe probabilmente sfruttare un ODS piuttosto che il nostro schema a stella.

Quello che ho trovato è tanto quanto provo a far sembrare il mio schema come qualcosa uscito da un libro di testo di Inmon o Kimball, non funziona quasi mai senza un po 'di personalizzazione nel mondo reale.

Modifica Sono stato sicuramente più specifico con riferimento all'ODS.

Un archivio di dati operativi (o "ODS") è un database progettato per integrare i dati provenienti da più fonti per semplificare l'analisi e il reporting. Poiché i dati provengono da più origini, l'integrazione spesso comporta la pulizia, la risoluzione della ridondanza e il controllo delle regole aziendali per l'integrità. Un ODS è di solito progettato per contenere dati di basso livello o atomici (indivisibili) (come transazioni e prezzi) con cronologia limitata che viene catturata "in tempo reale"; o "quasi in tempo reale" al contrario dei volumi molto più grandi di dati archiviati nel Data warehouse in genere su base meno frequente.

Secondo Bill Inmon, il creatore del concetto, un ODS è una raccolta di dati dettagliata, orientata al soggetto, integrata, volatile, valutata in base alla sola corrente, a supporto della necessità di un'organizzazione di -secondo, informazioni operative, integrate, collettive. "

ODS differisce dalla definizione di Inmon di data warehouse aziendale per avere una cronologia limitata e un aggiornamento più frequente di un EDW. In pratica, ODS tende a riflettere maggiormente le strutture di origine al fine di accelerare le implementazioni e fornire una rappresentazione più vera dei dati di produzione.

http://en.wikipedia.org/wiki/Operational_data_store

Answer 3

Grandi " persone " Le dimensioni (cliente) sono frequenti nelle telecomunicazioni, nel settore bancario, assicurativo, ecc. Kimball ha una sezione denominata "Grandi dimensioni cliente modificabili". nel capitolo CRM (6). Mostra come creare "minidimensioni". Gli attributi (colonne) che cambiano frequentemente o che vengono analizzati frequentemente sono suddivisi in mini tabelle dimensionali separate. Queste mini dimensioni sono collegate tramite la tabella dei fatti, quindi la tabella dei fatti ha un FK per ciascuna di queste tabelle separatamente.

Mi sembra che il tuo esempio sia vicino a questo.

Come regola generale, la tabella delle dimensioni è una tabella di ricerca per oggetti che cambiano raramente (persone, account, tempo, prodotti, negozi) e la tabella dei fatti acquisisce l'attività (cronologia) delle interazioni tra questi oggetti. La tabella dei fatti contiene misure da aggregare (vendite totali, numero di ore lavorate, numero di parti prodotte, ecc.).

DOPO LA CHIARIFICAZIONE :
Direi che Voter è in realtà una dimensione conforme, comune a tutti i data mart (processi aziendali). Altre dimensioni conformi sarebbero: data, partito, elezioni, stazioni di voto. Le mini dimensioni sarebbero Demographic e GeoArea. Le tabelle dei fatti sarebbero: RegistrationEvent (chi quando e dove registrato) ed ElectionEvent (chi quando e dove ha votato in quale elezione, usando cosa).
Dimension Voter e fact RegistrationEvent sono caricati da sistemi operativi che acquisiscono la registrazione degli elettori e altre modifiche.
Questo è semplificato, ma spero che catturi l'idea di base.