Come e quando le dimensioni vengono riempite in uno schema di data warehouse?

Are both dimension & fact tables are populated during the data warehouse creation/update?

Vago e difficile da rispondere.

How often?

Più difficile da rispondere

What about the DimDate table. Do we populate it with all possible dates or only with date used by facts tables.

Davvero, davvero difficile rispondere.

Continua a leggere. Hai bisogno di leggere su "Dimension Conformance" e l'idea di Kimball del "Dimension Bus".

1. Le dimensioni devono essere compilate per prime. Loro "accrescono" informazioni, a volte da più fonti. Una dimensione comune (come "prodotto") spesso ha più punti di vista in più applicazioni. Questo porta ad attributi che vengono caricati separatamente da fonti separate.

2. Le dimensioni sono "conformi". I dati in arrivo possono concordare con la dimensione esistente. Buono. I dati potrebbero non essere d'accordo. Esistono molti algoritmi standard "a variazione lenta della dimensione" (SCD) per gestire il cambiamento degli attributi dimensionali. Questo è un argomento profondo e complesso. Continua a leggere.

3. I fatti sono abbinati alle dimensioni conformi quando vengono caricati. I piani di carico di fatto dipendono dalle applicazioni di origine e dallo scopo del magazzino. Non c'è una risposta semplice a "quanto spesso?"

4. Alcune dimensioni possono essere pre-compilate (come Time) perché provengono da fonti esterne (come Time) o sono essenzialmente statiche. In alcuni casi, è una pratica finzione aziendale semplicemente dichiarare la dimensione statica e utilizzare speciali utility quasi manuali per modificare la dimensione quando si verifica un cambiamento aziendale. A volte una dimensione è definita dalla legge o da altri standard esterni.

   Il tempo di pre-popolamento è comune perché semplifica leggermente la conformità dimensionale. Inoltre, la dimensione Tempo non è mai una "Dimensione a modifica lenta" perché le istanze temporali non hanno mai attributi modificabili.

   Accumulare il tempo in cui le righe vengono caricate può essere fastidioso perché una riga nella dimensione temporale spesso include informazioni ricche come periodi contabili e altri fatti che non sono banalmente derivati dalla semplice data Y / M / D disponibile nell'input.

Ho intenzione di condividere la mia esperienza con la creazione di un datacube. Ho usato SQL Server Analysis Services 2005. L'azienda è nel commercio al dettaglio e ha negozi in diverse posizioni. Ogni negozio ha il proprio server di database ma utilizza lo stesso schema di database.

Per prima cosa estraggo i dati da ciascun sito in un unico database centrale. Questo è fatto periodicamente, nel mio caso mensile. Questo database centrale utilizza lo stesso schema del database del sito.

Quindi da questo database centrale, i dati vengono massaggiati per formare lo 'schema a stella'. Nel mio caso, ho voluto creare un cubo vendita . Questo cubo di vendita dovrebbe poter essere suddiviso per prodotto, data e posizione. Il cubo di vendita dovrebbe essere in grado di mostrare la somma della quantità di articoli venduti, la somma delle vendite lorde e la somma delle vendite nette.

Per creare questo schema a stella, ho scelto di creare alcune viste per appiattire alcuni riferimenti alle tabelle:

• Una vista per unire l'intestazione vendite e le tabelle dei dettagli di vendita, esponendo data di vendita, codice prodotto, codice posizione, quantità venduta, prezzo unitario, prezzo qtà * e prezzo qty * - sconto. Questo può essere chiamato tabella dei fatti di vendita .
• Una vista per unire la tabella del prodotto con i suoi sottotabella come categoria di prodotto, ecc. Questa è l'origine dati per la dimensione del prodotto .
• Una vista per unire la tabella delle posizioni con i suoi sottotitoli. Questa è l'origine dati per la dimensione della posizione .

Per data, ho creato una tabella calendario contenente tutte le date dal 1 ° gennaio 2001 al 31 dicembre 2030 che assomigliavano a questa:

|date      |year|month|dayofweek|
|2001-01-01|2001|1    |0        |
|...

Questa tabella del calendario è l'origine dati per dimensione della data .

Successivamente ho creato un nuovo progetto di "servizi di analisi" nello studio visivo. Ho impostato le viste e le tabelle sopra come origini dati, collegato il codice prodotto nella visualizzazione vendite alla dimensione prodotto, collegato la data di vendita alla dimensione data, ecc. E build il cubo.

I servizi di analisi imposteranno quindi le definizioni del cubo e popoleranno il cubo e le dimensioni. Al termine di questo processo, il cubo è pronto per l'uso.

Quindi il cubo viene popolato durante l'elaborazione. Rimarrà lo stesso se non lo rielabori.

Gli aggiornamenti giornalieri mi sembrano ragionevoli, ma scelgo il periodo in base ai requisiti aziendali. Ho sviluppato una soluzione per la società commerciale, abbiamo scelto aggiornamenti giornalieri durante la notte. Oggi puoi vedere tutte le transazioni e lo spazio pubblicitario compreso ieri, abbastanza buono per l'analisi. Inoltre, abbiamo evitato problemi di prestazioni con i sistemi di transazioni, leggiamo i dati prima che l'utente aziendale inizi ad aggiornare i dati.

Quando ottieni dati dal sistema delle transazioni, prima aggiorna le tue dimensioni, non puoi inserire dati nelle tabelle dei fatti se non hai dimensioni corrispondenti.

Popolare DimDate con tutte le date nell'intervallo. Ad esempio, se non hai vendite a 19. potresti non vederlo.

Processo standard? Esistono diverse metodologie. Se ti piace l'approccio di Kimball, prova link