Free Press

La modellazione dimensionale (DM) fa parte della metodologia Business Dimensional Lifecycle sviluppata da Ralph Kimball che include un insieme di metodi, tecniche e concetti da usare nella progettazione del data warehouse. L’approccio si concentra sull’identificazione dei processi di business chiave all’interno di un business e sulla modellazione e implementazione di questi prima di aggiungere ulteriori processi di business, un approccio bottom-up.

Quali sono gli obiettivi del Data Warehouse Modeling?

Gli obiettivi, esposti da Ross e Kimball, sono semplici:

• rendere le informazioni facilmente accessibili
• presentare le informazioni in modo coerente
• adattabile e ricettivo al cambiamento
• presentare le informazioni in modo tempestivo
• proteggere il patrimonio informativo

.

• serve come base autorevole e affidabile per migliorare il processo decisionale (singola fonte di verità nel linguaggio del Data Engineering)
• i VIP devono accettare il tuo sistema

Se hai lavorato o usato un sistema ETL, avrete notato che la coerenza delle informazioni si ottiene con misure conformi, la tempestività fornita dai cicli ETL e l’adattabilità dipende anche in gran parte dal design ETL.

Perché la modellazione?

Come ingegnere dei dati, conosci SQL molto bene e probabilmente puoi scrivere query SQL per tutto il giorno. Ma non si può dare per scontato che il tipico utente finale sia un esperto nello scrivere query SQL. Quindi, il nostro obiettivo è quello di costruire un DW così facile per gli analisti da scrivere query di analisi in modo rapido ed efficace.

Cose che non vorresti che i tuoi analisti facessero:

• Query basate su ID
• Cascading outer joins (anche tu non vorresti farlo)
• sottoquery multiple raggruppate o unite
• sottoquery ricorsive (visita Hackerrank SQL e capirai il dolore)
• Correlazione di subquery: recuperare i dati su più colonne in diverse subquery
• Join senza PK/FK: anche per me (1.5 anni di esperienza DE), è difficile da visualizzare.

Cose che potresti e dovresti aspettarti dai tuoi analisti:

• unioni semplici
• colonne con nomi e testo completo
• aggregazione semplice
• funzioni analitiche a finestra
• DISTINTO

Nota, i punti precedenti non sono quelli facili e il tuo sistema dovrebbe essere abbastanza scalabile per tutti questi tipi di query.

I database OLTP vengono trasformati in fatti e dimensioni a causa degli obiettivi di cui sopra.

Transizione dai database transazionali ai fatti

La maggior parte delle aziende misura il proprio successo ed efficienza misurando certi tipi di dati. Questi dati catturano le attività e i progressi reali del business. Questi dati sono chiamati fatti.

I database orientati all’OLTP registrano le transazioni alla volta, un po’ come lo streaming degli eventi ma centralizzato intorno alle transazioni. Il DW è diverso. DW non ha bisogno di registrare i dettagli a livello transazionale. Il DW ha bisogno di avere fatti attraverso diversi criteri del tuo business. Il DW ha bisogno di aggregare (o far aggregare agli analisti) le informazioni necessarie per migliorare il business. E così, la ridondanza è un peccato imperdonabile nel DW.

Cosa sono le misure e perché dovresti riempire le tue tabelle dei fatti con esse?

In un data warehouse, una misura è una proprietà sulla quale possono essere fatti dei calcoli.

I fatti che deriviamo dagli archivi di dati operativi vengono con alcuni dati aggiuntivi che vengono tipicamente sommati nella nostra analisi. Questi sono gli aspetti di un fatto che permettono all’analista, o al dirigente che visualizza l’analisi, di vedere il valore nel fatto.

Perché avete bisogno di mantenere una grana coerente?

Per garantire che il vostro sistema possa legittimamente correlare e aggregare i fatti.

Ma non è sempre possibile avere dati a livelli atomici. Quindi, per colmare questa lacuna, ci sono due metodi:

• Tabelle di fatti istantanee periodiche
• Tabelle di fatti istantanee accumulanti

Tabelle di fatti istantanee periodiche

Come suggerisce il nome, sono raccolte a intervalli di tempo regolari. Consumo di gas, audit e ispezioni sono alcune istanze di raccolta dati che hanno istantanee periodiche abilitate per loro.

Tabelle di fatti istantanee accumulate

Quando un indicatore di performance aziendale è un tasso di completamento di un processo aziendale a più fasi, si potrebbe voler catturare a grana dell’intero processo e registrare l’inizio, il completamento e le fasi in mezzo. Questo può essere a grana di transazione, ma ha molte misure in mezzo. Così, si usano le tabelle di fatti istantanei accumulati per rispondere a domande complesse nella business intelligence dove c’è il passare del tempo tra i fatti. Un buon esempio potrebbe essere la riga della tabella dei fatti del tuo ordine di un panino al pollo e la riga della tabella dei fatti del sacchetto che ti viene consegnato attraverso il finestrino dell’auto al drive-thru di McDonald’s.

Localizzare i fatti attraverso le dimensioni

Tu e i tuoi analisti dovete sapere come interrogare e filtrare i fatti per ricavarne la business intelligence. Questo scopo è servito dalle dimensioni.

Disegnare le dimensioni dai dati di riferimento e dai metadati grezzi

Le dimensioni sono quasi sempre create con una chiave surrogata; la chiave surrogata, naturalmente, è referenziata dalla chiave esterna (o dalle chiavi) nella tabella dei fatti. Noi cerchiamo la tabella cercando le dimensioni a cui siamo interessati. Tutti gli altri dati che descrivono i nostri fatti, come i timestamp, gli agenti dei clienti, la posizione del negozio, il prodotto e il cliente sono ciò che trasformiamo in dimensioni.

La bellezza della modellazione dimensionale è che i fatti non sono definiti dalle chiavi primarie o da qualsiasi tipo di identificatore unico, invece, sono definiti dalla combinazione delle dimensioni. Questo dà origine a Star Schema.

È molto importante avere un’unicità nelle nostre dimensioni. Quando arriviamo alle query attraverso i fatti, i duplicati tra le combinazioni di dimensioni si trasformeranno in un disastro. Se non puoi, allora aggiungi o aggrega le dimensioni per renderle uniche.

Gerarchia nelle dimensioni

Considera le due immagini seguenti.

Un analista avrà vita facile se gli si imposta la seconda tabella delle dimensioni.

Quindi, con la seconda tabella, si ha la seguente gerarchia:

Ci sono tutti i tipi di gerarchie – gerarchie multiple, gerarchia singola, ecc. Non le affronto in questo post del blog.

Una cosa che vorrei sottolineare è che la dimensione temporale è una vera spina nel fianco. Bisogna occuparsi dei giorni magici, del calendario fiscale, dei fusi orari, dei cicli (tipo profitto su trimestre). E non essere pidocchioso o troppo fiducioso in questo, anche i database di serie temporali non ti aiuteranno nelle gerarchie se il tuo ETL è incasinato. Potreste dare un’occhiata alle dimensioni Outrigger. Ci sono anche occasioni in cui una dimensione è naturalmente dipendente da un’altra. In tal caso, i progettisti possono mettere una chiave esterna dall’una all’altra. Questo è ciò che costituisce una “dimensione outrigger”. Nelle dimensioni calendario, questo è molto comune.

Non potete usare una data a una grana diversa in una outrigger dalle date che usate nella tabella fatti. Non puoi permettere l’aggregazione su dimensioni outrigger. Se necessario, maschera i valori numerici nell’outrigger con prefissi o suffissi testuali per impedirlo.

Cambiamento lento delle dimensioni

Per quanto mi piacerebbe scriverne, penso ancora che sia meglio per i miei lettori capire bene questo concetto da qui.

Non sto discutendo le dimensioni Snowflake, ma solo per sottolineare che sono ancora in uso nei database OLAP.

Integra i tuoi Big Data nel tuo sistema ETL

Tratterai i tuoi Big Data tabulari come se fossero stati acquisiti attraverso una delle tue fasi standard di estrazione. Quindi, applicherai ad essi gli stessi passi che hai fatto in transform:

1. Pulizia dei dati
2. Conformazione di unità e formati
3. De-duplicazione
4. Ristrutturazione
5. Staging

Sommario

Ho voluto capire gli aspetti teorici della progettazione di database che mi hanno portato a leggere il libro di Ross e Kimball. Poi sono diventato curioso di tracciare le differenze e le analogie tra i loro metodi e quelli delle aziende leader di oggi basate sui dati come Netflix, Airbnb, Uber, ecc.

In questa ricerca, posso dire che il formato strutturato della modellazione dimensionale è preferito a un ETL hardcore. Perché in questo modo, rimuovi la dipendenza da te, il tuo team di BI non ti chiama su Slack per creare un nuovo DAG per ogni altro insight, invece, con una corretta modellazione, gli permetti di agire ed esplorare liberamente senza il tuo bisogno.

Si prega di lasciare un feedback su come potrei migliorare, sono sicuro che questa non è stata la vostra migliore lettura. Grazie per il vostro tempo.

Note

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross e Kimball, cap 2 e cap 18

Kimball/Ross pp103-109