Star-Schema Design [chiuso]

Question

La progettazione di uno schema a stella è essenziale per un data warehouse? Oppure puoi archiviare i dati con un altro modello di progettazione?

Answer 1

L'uso di schemi a stella per un sistema di data warehouse offre numerosi vantaggi e nella maggior parte dei casi lo è appropriato usarli per il livello superiore. È inoltre possibile disporre di un archivio dati operativo (ODS), una struttura normalizzata che mantiene lo "stato corrente" e facilita operazioni come la conformità dei dati. Tuttavia ci sono situazioni ragionevoli in cui ciò non è desiderabile. Ho avuto occasione di costruire sistemi con e senza livelli ODS e ho avuto ragioni specifiche per la scelta dell'architettura in ogni caso.

Senza entrare nelle sottigliezze dell'architettura del data warehouse o iniziare una guerra di fiamma Kimball vs. Inmon i principali vantaggi di uno schema a stella sono:

• La maggior parte dei sistemi di gestione del database disporre di strutture nel Query Optimizer per fare "Star Transformations" utilizzare le strutture Indice bitmap o Intersezione indice per una rapida risoluzione predicata. Ciò significa che la selezione da uno schema a stella può essere effettuata senza colpire la tabella dei fatti (che di solito è molto più grande degli indici) fino a quando la selezione non viene risolta.

• Partizionare uno schema a stella è relativamente semplice in quanto solo la tabella dei fatti deve essere partizionato (a meno che tu non abbia alcune dimensioni bibliche di grandi dimensioni). Eliminazione delle partizioni significa che Query Optimizer può ignorare le brevetti che non possono partecipare ai risultati della query, risparmiando sull'I / O.

• Dimensioni che cambiano lentamente sono molto più facili da implementare su uno schema a stella che su un fiocco di neve .

• Lo schema è più facile da capire e tende a coinvolgere meno join di un fiocco di neve o schema ER. Il tuo team di segnalazione ti adorerà per questo

• Gli schemi a stella sono molto più facili da usare e (cosa ancora più importante) fanno funzionare bene con strumenti di query ad hoc come Business Objects o Generatore di report . Come sviluppatore hai pochissimo controllo sull'SQL generato da questi strumenti, quindi devi dare a Query Optimizer il maggior aiuto possibile. Gli schemi a stella offrono all'ottimizzatore di query relativamente poche opportunità di sbagliare.

In genere il tuo livello di report utilizza schemi a stella a meno che tu non abbia un motivo specifico per non farlo. Se disponi di più sistemi di origine, potresti voler implementare un Operational Data Store con uno schema normalizzato o a fiocco di neve per accumulare i dati. Questo è più facile perché un ODS in genere non fa la cronologia. Lo stato storico viene tracciato negli schemi a stella, dove è molto più semplice rispetto alle strutture normalizzate. Un archivio dati operativo normalizzato o con fiocchi di neve riflette lo stato "corrente" e non mantiene una visione storica al di là di quella inerente ai dati.

I processi di caricamento ODS riguardano lo scrubbing e la conformità dei dati, che è più facile da fare con una struttura normalizzata. Una volta che hai dati puliti in un ODS, i carichi di dimensioni e fatti possono tenere traccia della storia (cambiamenti nel tempo) con meccanismi generici o relativamente semplici in modo relativamente semplice; questo è molto più facile da fare con uno schema a stella, molti strumenti ETL (ad esempio) forniscono strutture integrate per modificare lentamente le dimensioni e implementare un meccanismo generico è relativamente semplice.

La stratificazione del sistema in questo modo fornisce una separazione delle responsabilità: la logica di pulizia dei dati e degli affari è trattata nell'ODS e i carichi dello schema a stella riguardano lo stato storico.

Answer 2

C'è un dibattito in corso nella letteratura sul dataware che ospita where nell'architettura datawarehouse Il disegno a stella dovrebbe essere applicato.

In breve Kimball è molto favorevole all'utilizzo del solo schema a stella nel datawarehouse, mentre Inmon vuole innanzitutto costruire un Enterprise Datawarehouse utilizzando normalizzato 3NF e successivamente utilizzare il disegno Star-Schema nei datamarts.

Oltre a questo, potresti anche dire che Progettazione dello schema del fiocco di neve è un altro approccio.

Un quarto progetto potrebbe essere l'approccio Data Vault Modeling .

Answer 3

Gli schemi a stella vengono utilizzati per consentire l'accesso ad alta velocità a grandi volumi di dati. Le alte prestazioni sono abilitate riducendo la quantità di join necessari per satsificare qualsiasi query che possa essere effettuata nell'area tematica. Questo viene fatto consentendo la ridondanza dei dati nelle tabelle delle dimensioni.

Devi ricordare che lo schema a stella è un modello per il livello superiore per il magazzino. Tutti i modelli includono anche schemi di gestione temporanea nella parte inferiore dello stack del magazzino e alcuni includono anche un'area di gestione temporanea unita trasformata persistente in cui tutti i sistemi di origine vengono uniti in uno schema modellato 3NF. Le varie aree tematiche siedono al di sopra di questo.

Le alternative agli schemi a stella al livello superiore includono una variazione, che è uno schema a fiocco di neve. Un nuovo metodo che può portare anche a qualche indagine è Data Vault Modeling proposto da Dan Linstedt.

Answer 4

Il vantaggio degli schemi a stella è che sono un modello naturale per i tipi di cose che la maggior parte delle persone desidera fare con un data warehouse. Ad esempio, è facile produrre report con diversi livelli di granularità (ad esempio mese o giorno o anno). È anche efficiente inserire dati aziendali tipici in uno schema a stella, ancora una volta una caratteristica comune e importante di un data warehouse.

Puoi certamente utilizzare qualsiasi tipo di database che desideri, ma a meno che tu non conosca molto bene il tuo dominio aziendale, è probabile che i tuoi rapporti non vengano eseguiti nel modo più efficiente possibile se avessi utilizzato uno schema a stella.

Answer 5

Gli schemi a stella si adattano in modo naturale all'ultimo livello di un data warehouse. Come ci arrivi c'è un'altra domanda. Per quanto ne so, ci sono due grandi campi, quelli di Bill Inmon e Ralph Kimball. Potresti voler esaminare le teorie di questi due ragazzi se / quando decidi di andare con una stella.

Inoltre, alcuni strumenti di reporting apprezzano molto la configurazione dello schema a stella. Se sei bloccato in uno strumento di segnalazione specifico, ciò potrebbe determinare l'aspetto del mart di segnalazione nel tuo magazzino.

Answer 6

Lo schema a stella è un modello logico di dati per database relazionali che si adatta alle normali esigenze di archiviazione dei dati; se viene fornito l'ambiente relazionale, uno schema a stella o fiocco di neve sarà un buon modello di progettazione, cablato in molte metodologie di progettazione DW.

Esistono tuttavia anche motori di database relazionali diversi, che possono essere utilizzati per un efficiente data warehousing. I motori di archiviazione multidimensionale potrebbero essere molto veloci per le attività OLAP (ad es. TM1); in questo caso non possiamo applicare la progettazione dello schema a stella. Altri esempi che richiedono modelli logici speciali includono database XML o database orientati alle colonne (ad es. Il C-store sperimentale ) ).

Answer 7

È possibile farne a meno. Tuttavia, ti renderai la vita difficile - la tua organizzazione vorrà utilizzare strumenti standard che vivono in cima ai DW e quegli strumenti si aspetteranno uno schema a stella - un grande sforzo verrà speso per montare un piolo quadrato in un round foro.

Molte ottimizzazioni a livello di database presuppongono che tu abbia uno schema a stella; passerai molto tempo a ottimizzare e ristrutturare per fare in modo che il DB faccia "la cosa giusta" con il tuo layout non abbastanza stellare.

Assicurati che i professionisti superino i contro.

(Sembra che ci sia già stato?)

-D

Answer 8

Ci sono tre problemi che dobbiamo risolvere.

1) Come estrarre i dati dal sistema operativo sorgente senza esercitare eccessive pressioni su di essi unendo le tabelle all'interno e tra loro, pulendo i dati mentre estraiamo, creando derivazioni ecc.

2) Come unire i dati provenienti da fonti disparate - alcuni legacy, alcuni basati su file, provenienti da dipartimenti diversi in un insieme integrale, accurato, efficiente, che modella il business e non riflette le strutture dei sistemi di origine. Ricorda che i sistemi cambiano / vengono sostituiti relativamente rapidamente, ma il modello di base dell'azienda cambia lentamente.

3) Come strutturare i dati per soddisfare specifici requisiti analitici e di reporting per particolari persone / dipartimenti nel business nel modo più rapido e accurato possibile.

La soluzione a questi tre problemi molto diversi richiede livelli architettonici diversi per risolverli

Livello di gestione temporanea Replichiamo le strutture delle fonti, ma ogni notte vengono caricati solo i dati modificati dalle fonti. una volta che i dati vengono presi dal livello di gestione temporanea al livello successivo, i dati vengono eliminati. Le query sono query a tabella singola con un semplice filtro data_time. Effetto molto scarso sulla fonte.

Livello aziendale Questo è un 3 ° database di moduli normale orientato al business. I dati vengono estratti (e successivamente rilasciati) dal livello di gestione temporanea al livello aziendale, dove vengono ripuliti, integrati e normalizzati.

Livello di presentazione (schema a stella) Qui, modelliamo dimensionalmente per soddisfare requisiti specifici. I dati vengono de-normalizzati deliberatamente per ridurre il numero di join. Le gerarchie che possono occupare più tabelle nel livello Enterprise vengono compresse in tabelle a dimensione singola e più tabelle transazionali possono essere unite in tabelle a fatti singoli.

Devi sempre affrontare questi tre problemi. Se scegli di eliminare il livello aziendale, devi ancora risolvere il secondo problema, ma devi farlo nel livello dello schema a stella e, a mio avviso, questo è il posto sbagliato per farlo.