Lo schema a stella

Oggi, report e analisi sono importanti quasi quanto il core business. I rapporti possono essere costruiti a partire dai tuoi dati in tempo reale; spesso questo approccio farà il trucco per le piccole e medie imprese senza molti dati. Ma quando le cose si fanno più grandi, o la quantità di dati inizia ad aumentare drasticamente, è tempo di pensare a separare i sistemi operativi e di reporting.

Prima di affrontare la modellazione dei dati di base, abbiamo bisogno di alcune informazioni sui sistemi coinvolti. Possiamo dividere approssimativamente i sistemi in due categorie:sistemi operativi e di reporting. I sistemi operativi sono spesso chiamati Online Transaction Processing (OLTP). I sistemi di reporting e di analisi sono indicati come Online Analytical Processing (OLAP). I sistemi OLTP supportano i processi aziendali. Funzionano con dati operativi "in tempo reale", sono altamente normalizzati e reagiscono molto rapidamente alle azioni dell'utente. D'altra parte, lo scopo principale dei sistemi OLAP è l'analisi. Questi sistemi utilizzano dati riepilogati, che di solito vengono inseriti in una struttura di data warehousing denormalizzata come lo schema a stella. (Cos'è la denormalizzazione? In poche parole, significa avere record di dati ridondanti per ottenere prestazioni migliori. Ulteriori informazioni.)

Ora che sappiamo qualcosa sui sistemi, iniziamo a esaminare il data warehouse, i suoi componenti e processi.

Data Warehouse e Data Mart

Un data warehouse (DWH) è un sistema utilizzato per archiviare informazioni da utilizzare nell'analisi e nel reporting dei dati. Data mart sono aree di un data warehouse utilizzate per memorizzare le informazioni necessarie a un singolo reparto o anche a un singolo utente. (Pensa al DWH come a un edificio e ai data mart come a uffici all'interno dell'edificio.)

Perché sono necessari i data mart? Tutti i dati rilevanti sono archiviati all'interno della società DWH. La maggior parte degli utenti, tuttavia, deve accedere solo a determinati sottoinsiemi di dati, come quelli relativi alle vendite, alla produzione, alla logistica o al marketing. I data mart sono importanti sia dal punto di vista della sicurezza (limitando l'accesso non necessario) sia dal punto di vista dell'utente (non vogliamo confonderli o costringerli a guadare dati estranei).

Esistono due diversi approcci alla relazione data warehouse-data mart:

Dalto verso il basso :i data mart vengono creati dal data warehouse. (Questo è qualcosa su cui Bill Inmon, il "padre del data warehouse", sarebbe d'accordo, insieme all'idea che i warehouse dovrebbero essere in 3NF.)
Bottom-up :i data mart vengono prima creati, quindi combinati in un data warehouse. (Questo approccio è più vicino a quello che sostiene Ralph Kimball, esperto di data warehouse e modellazione dimensionale.)

Il processo ETL viene utilizzato per aggiungere regolarmente dati "nuovi" al sistema OLAP. ETL è l'abbreviazione di Estrai, Trasforma e Carica. Come suggerisce il nome, estrarremo i dati da uno o più database operativi, li trasformeremo per adattarli alla nostra struttura di magazzino e caricheremo i dati nel DWH.

Modellazione dimensionale , che fa parte della progettazione del data warehouse, porta alla creazione del modello dimensionale. Sono coinvolti due tipi di tabelle:

Tabelle dimensionali sono usati per descrivere i dati che vogliamo memorizzare. Ad esempio:un rivenditore potrebbe voler memorizzare la data, il negozio e il dipendente coinvolti in un acquisto specifico. Ciascuna tabella delle dimensioni è una categoria a sé stante (data, dipendente, negozio) e può avere uno o più attributi . Per ogni negozio, possiamo salvare la sua posizione a livello di città, regione, stato e paese. Per ogni data, possiamo memorizzare l'anno, il mese, il giorno del mese, il giorno della settimana, ecc. Questo è correlato alla gerarchia di attributi nella tabella delle dimensioni.

Nello schema a stella, di solito troveremo che alcuni attributi sono un sottoinsieme di altri attributi nello stesso record. Questa ridondanza è deliberata e fatta in nome di prestazioni migliori. Potremmo utilizzare le dimensioni di data, posizione e agente di vendita per aggregare (la parte di trasformazione del processo ETL) e archiviare i dati all'interno di DWH. Nella modellazione dimensionale, è molto importante definire le giuste dimensioni e scegliere la corretta granulazione.
Tabelle dei fatti contengono i dati che vogliamo includere nei rapporti, aggregati in base ai valori all'interno delle relative tabelle dimensionali. Una tabella dei fatti ha solo colonne che memorizzano valori e chiavi esterne che fanno riferimento alle tabelle delle dimensioni. La combinazione di tutte le chiavi esterne costituisce la chiave primaria della tabella dei fatti. Ad esempio, una tabella dei fatti potrebbe memorizzare un numero di contatti e il numero di vendite risultanti da questi contatti.

Con queste informazioni in atto, ora possiamo approfondire il modello di dati dello schema a stella.

Lo schema a stella

Lo schema a stella è il modello più semplice utilizzato in DWH. Poiché la tabella dei fatti si trova al centro dello schema con le tabelle delle dimensioni attorno ad essa, ha l'aspetto più o meno di una stella. Ciò è particolarmente evidente quando la tabella dei fatti è circondata da tabelle a cinque dimensioni. Una variante dello schema a stella lo schema millepiedi , dove la tabella dei fatti è circondata da un gran numero di tabelle di piccole dimensioni.

Gli schemi a stella sono molto comunemente usati nei data mart. Possiamo metterli in relazione con l'approccio del modello di dati top-down. Analizzeremo due schemi a stella (data mart) e poi li combineremo per creare un unico modello.

Esempio di schema a stella:vendite

Il rapporto sulle vendite è uno dei rapporti più comuni di oggi. Come accennato in precedenza, nella maggior parte dei casi potremmo generare rapporti di vendita dal sistema live. Ma quando i dati o le dimensioni dell'azienda lo rendono troppo ingombrante, dovremo creare un data warehouse o un data mart per semplificare il processo. Dopo aver progettato il nostro schema a stella, un ETL il processo otterrà i dati dai database operativi, trasformerà i dati nel formato appropriato per il DWH e caricherà i dati nel magazzino.

Il modello presentato sopra contiene una tabella dei fatti (di colore rosso chiaro) e cinque tabelle dimensionali (di colore azzurro). Le tabelle nel modello sono:

fact_sales – Questa tabella contiene riferimenti alle tabelle dimensionali più due fatti (prezzo e quantità venduta). Nota che tutte e cinque le chiavi esterne insieme formano la chiave primaria della tabella.
dim_sales_type – Questa è una tabella delle dimensioni del tipo di vendita con un solo attributo, "type_name ”.
dim_employee – Questa è una tabella delle dimensioni dei dipendenti che memorizza gli attributi di base dei dipendenti:nome completo e anno di nascita.
dim_product – Questa è una tabella delle dimensioni del prodotto con solo due attributi (diversi dalla chiave primaria):nome del prodotto e tipo di prodotto.
dim_time – Questa tabella gestisce la dimensione temporale. Contiene cinque attributi oltre alla chiave primaria. I dati di livello più basso sono le vendite per data (action_date ). La action_week attributo è il numero della settimana in quell'anno (cioè la prima settimana di gennaio verrebbe assegnato il numero 1; l'ultima settimana di dicembre otterrebbe il numero 52, ecc.) Il actual_month e actual_year gli attributi memorizzano il mese di calendario e l'anno in cui si è verificata la vendita. Questi possono essere estratti da action_date attributo. Il action_weekday attributo memorizza il nome del giorno in cui è avvenuta la vendita.
dim_store – Questa è una dimensione del negozio. Per ogni negozio salveremo la città, la regione, lo stato e il paese in cui si trova. Qui possiamo notare chiaramente che lo schema a stella è denormalizzato.

Esempio di schema a stella:ordini di rifornimenti

Ci sono molte somiglianze tra questo modello, mostrato di seguito, e il modello di vendita.

Questo modello ha lo scopo di memorizzare la cronologia degli ordini effettuati. Abbiamo una tabella dei fatti e quattro tabelle dimensionali. Le tabelle dimensionali dim_employee , dim_product e dim_time sono esattamente gli stessi del modello di vendita. Tuttavia, le seguenti tabelle sono diverse:

fact_supply_order – contiene dati aggregati sugli ordini effettuati.
dim_supplier – è una tabella dimensionale che memorizza i dati dei fornitori allo stesso modo di dim_store conservava i dati del negozio nel modello di vendita.

Vantaggi e svantaggi dello schema a stella

Ci sono molti vantaggi nell'usare lo schema a stella. La tabella dei fatti è correlata a ciascuna tabella delle dimensioni esattamente da una relazione e non sono necessari dizionari aggiuntivi per descrivere le tabelle delle dimensioni. Ciò semplifica le query e riduce il tempo di esecuzione delle query. Potremmo produrre lo stesso report direttamente dal nostro sistema OLTP, ma la query sarebbe molto più complessa e potrebbe influire sulle prestazioni complessive del sistema. La seguente query di esempio per il modello di vendita restituirà la quantità di tutti i tipi di prodotti di tipo telefono venduti nei negozi di Berlino nel 2016:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Il più grande svantaggio dello schema a stella è la ridondanza. Ogni dimensione viene archiviata in una tabella delle dimensioni separata e ciò provoca la denormalizzazione. Nel nostro esempio, la città appartiene a una regione o stato, che appartiene a un paese; non memorizziamo quella relazione come regola nel nostro database, ma la ripetiamo continuamente. Ciò significa che spenderemo più spazio su disco e corriamo un rischio per l'integrità dei dati.

Lo schema della galassia

Possiamo considerare i due modelli precedenti come due data mart, uno per il reparto vendite e l'altro per il reparto forniture. Ciascuno di essi è costituito da una sola tabella dei fatti e da alcune tabelle dimensionali. Se volessimo, potremmo combinare questi due data mart in un unico modello. Questo tipo di schema, che contiene diverse tabelle dei fatti e condivide alcune tabelle delle dimensioni, è chiamato schema della galassia . La condivisione delle tabelle delle dimensioni può ridurre le dimensioni del database, soprattutto quando le dimensioni condivise hanno molti valori possibili. Idealmente, in entrambi i data mart le dimensioni sono definite allo stesso modo. In caso contrario, dovremo adattare le dimensioni per soddisfare entrambe le esigenze.

Di seguito è mostrato uno schema di una galassia, costruito con i nostri due data mart di esempio:

Lo schema a stella è un approccio all'organizzazione di un data warehouse. È molto semplice ed è più spesso utilizzato nei data mart. Se non dobbiamo preoccuparci dello spazio su disco e ci prendiamo cura dell'integrità dei dati, lo schema a stella è la prima e migliore scelta praticabile. In caso contrario, dovremmo pensare a un altro approccio. Uno è lo schema del fiocco di neve, di cui parleremo in un prossimo articolo.