Tipico data warehouse Kim-Star a schema - Viste del modello fattibili? e come codificare Gen

Question

Ho un data warehouse contenente tipici schemi a stella e un sacco di codice che fa cose del genere (ovviamente molto più grandi, ma questo è illustrativo):

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

Sto pensando di sostituirlo con una vista ( MODEL_SYSTEM_1 , diciamo), in modo che diventi:

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

Ma la vista MODEL_SYSTEM_1 dovrebbe contenere nomi di colonna univoci, e sono anche preoccupato per le prestazioni con l'ottimizzatore se vado avanti e lo faccio, perché sono preoccupato che tutti gli articoli nella clausola WHERE attraverso diversi fatti e dimensioni vengono ottimizzati, poiché la vista sarebbe su un'intera stella e le viste non possono essere parametrizzate (ragazzo, non sarebbe fantastico!)

Quindi le mie domande sono -

1. Questo approccio è OK o sarà solo un'astrazione che danneggia le prestazioni e non dà alla mia sintassi nulla di più bello?

2. Qual è il modo migliore per generare codice in queste viste, eliminando i nomi delle colonne duplicate (anche se la vista in seguito deve essere modificata manualmente), dato che sono presenti tutti i PK e gli FK appropriati? Devo solo scrivere un po 'di SQL per estrarlo dal INFORMATION_SCHEMA o esiste già un buon esempio.

Modifica: l'ho testato e le prestazioni sembrano uguali, anche sui processi più grandi, persino unendo più stelle che utilizzano ciascuna queste visualizzazioni.

L'automazione è principalmente dovuta al numero di stelle presenti nel data warehouse e l'FK / PK è stato eseguito correttamente dai progettisti, ma non desidero scegliere tra tutte le tabelle o la documentazione . Ho scritto uno script per generare la vista (genera anche abbreviazioni per le tabelle) e funziona bene per generare lo scheletro automagicamente da INFORMATION_SCHEMA , e quindi può essere modificato prima di eseguire la creazione della vista .

Se qualcuno vuole il codice, probabilmente potrei pubblicarlo qui.

Answer 1

1. Ho usato questa tecnica su diversi data warehouse che mi occupo. Non ho notato alcun peggioramento delle prestazioni durante l'esecuzione di report basati sulle visualizzazioni rispetto a un approccio diretto alla tabella, ma non ho mai eseguito un'analisi dettagliata.

2. Ho creato le viste usando il designer nello studio di gestione di SQL Server e non ho usato alcun approccio automatizzato. Non riesco a immaginare che lo schema cambi abbastanza spesso da rendere comunque utile l'automazione. Potresti impiegare tutto il tempo a modificare i risultati come ci sarebbe voluto per trascinare tutti i tavoli sulla vista in primo luogo!

Per rimuovere l'ambiguità, un buon approccio consiste nel prefigurare i nomi delle colonne con il nome della dimensione a cui appartiene. Ciò è utile per gli autori di report e per chiunque esegua query ad hoc.

Answer 2

Trasforma la vista o le viste in una o più tabelle dei fatti di riepilogo e materializzale. Questi devono essere aggiornati solo quando viene aggiornata la tabella dei fatti principale. Le viste materializzate saranno più veloci da interrogare e questo può essere una vittoria se hai molte domande che possono essere soddisfatte dal riepilogo.

È possibile utilizzare il dizionario dei dati o le viste dello schema di informazioni per generare SQL per creare le tabelle se si dispone di un numero elevato di questi riepiloghi o si desidera modificarli frequentemente.

Tuttavia, immagino che non sia probabile che tu li cambi molto spesso, quindi generare automaticamente le definizioni della vista potrebbe non valere la pena.

Answer 3

Se ti capita di usare MS SQL Server, potresti provare un UDF Inline che è il più vicino a un vista con parametri come si ottiene.