Power BI e la Modellazione Dimensionale

Nel post sui database relazionali abbiamo dato delle informazioni di massima sulla natura di questo strumento, sulle sue funzionalità, e sulle caratteristiche che lo contraddistinguono da altri strumenti “più semplici”, come i fogli di calcolo (Excel, Libreoffice Calc, ecc.). In particolare, nel capitolo sui dati denormalizzati abbiamo discusso brevemente l’utilizzo di un database data warehouse, e della distinzione tra schema transazionale, ottimizzato per la scrittura, e schema a stella, affinato per la lettura e l’esecuzione di query analitiche. Vediamo ora di approfondire l’argomento della modellazione dimensionale e della comprensione dello Star Schema.

Lo Star Schema

lo Star Schema (o schema a stella) è un modello logico di dati progettato per semplificare l’analisi e migliorare le prestazioni dei report e dei dashboard. Immaginiamo una stella:

• al centro c’è la Fact Table (tabella dei fatti)
• attorno, come “le punte di una stella”, ci sono le Dimension Table (tabelle dimensionali)

Questa forma “a stella” dà il nome allo schema.

La Fact Table è la tabella centrale dello schema, e contiene i dati numerici e misurabili, cioè le metriche o misure di nostro interesse, che vogliamo analizzare. Ad esempio: importi di vendita, quantità, costi, ore lavorate, ecc. Include anche le chiavi esterne (foreign key) che collegano la tabella ai suoi contesti descrittivi, definiti dalle Dimension Table.

Le Dimension Table (tabelle dimensionali) forniscono i dettagli descrittivi che aiutano a spiegare le metriche di business presenti nella Fact Table associata. Esempi: prodotti, clienti, date, sedi, categorie, ecc. Ogni tabella dimensionale è collegata alla Fact Table tramite una relazione uno-a-molti, dove una riga della Dimension Table può essere collegata a molte righe nella Fact Table. A livello concettuale, uno schema a stella può essere rappresentato nel modo seguente:

Mentre in Power BI, un datamodel che implementa tale schema è simile a questo diagramma:

Nei database di tipo data warehouse, e in Power BI, l’uso dello Star Schema presenta diversi vantaggi:

• Semplicità di Navigazione:
  Lo schema a stella rende il modello dati più intuitivo da esplorare. Chi costruisce report in Power BI può combinare con facilità misure numeriche, presenti nella Fact Table, con attributi descrittivi, presenti nelle Dimension Table. Ad esempio, è possibile creare rapidamente un grafico che mostra le vendite per categoria di prodotto o il numero di clienti per area geografica, semplicemente trascinando i campi di aggregazione della Fact Table e i campi descrittivi delle Dimension Table nei campi di configurazione degli oggetti Visual.

• Miglior Interpretabilità:
  Lo Star Schema separa i “fatti” (dati quantitativi, misurabili) dalle “dimensioni” (contesti descrittivi, come cliente, prodotto, tempo, area geografica). Questa distinzione facilita la comprensione del modello, sia per chi lo sviluppa sia per chi lo consulta. Inoltre, le modifiche future — come l’aggiunta di un nuovo attributo nella Dimension Table, o una nuova misura nella Fact Table — risultano più semplici da attuare, poiché le tabelle sono indipendenti e ben organizzate.

• Performance Migliori:
  Il motore di calcolo VertiPaq, alla base di Power BI, è ottimizzato per lavorare con modelli a stella. Quando il modello è ben strutturato, VertiPaq riesce a comprimere i dati in modo più efficiente, poichè lo Star Schema evita la duplicazioni di attributi descrittivi (nomi di prodotti, città, categorie), riducendo la memoria usata e migliorando le query. Inoltre, le colonne chiave numeriche usate per filtrare e aggregare i dati possono essere indicizzare rapidamente, riducendo il tempo di calcolo nelle query DAX, e migliorando quindi la reattività dei report.

• Uso di DAX Semplificato:
  Le formule DAX (Data Analysis Expression), usate per creare misure e calcoli in Power BI, funzionano in modo più prevedibile ed efficiente in un modello a stella. Ogni Dimension Table filtra naturalmente i dati della Fact Table associata tramite la relazione “Uno a Molti”. Queste relazioni lineari, prive di ambiguità, permettono al motore di calcolo di interpretare correttamente il Filter Context e le aggregazioni dei dati. In pratica, i calcoli di somma, media, conteggio o percentuale si comportano esattamente come previsto, senza problemi legati a relazioni “Molti a Molti”, o a percorsi di filtro complessi.

Le Fact Table

Le Fact Table raccolgono i dati di osservazione o la misurazione di eventi. Si tratta, ad esempio, di informazioni relative a ordini di acquisto, quantità vendute, prezzi, date e orari delle transazioni.

In genere, una Fact Table contiene numerosi valori ripetuti, associati a entità differenti. Ad esempio, la referenza allo stesso prodotto può comparire più volte nella tabella — magari per clienti diversi o in giorni diversi. Questi dati possono essere aggregati per ottenere informazioni di sintesi e visualizzazioni utili. Un caso tipico è il grafico che mostra il totale degli ordini per cliente, calcolato come somma di tutte le righe della Fact Table corrispondenti a quel cliente.

Le colonne di una Fact Table contengono spesso valori numerici e date. I numeri possono rappresentare misure (come importi di vendita, quantità, costi) oppure chiavi esterne che collegano la Fact Table alle tabelle dimensionali, come l’ID cliente o l’ID prodotto.

In genere, una Fact Table contiene molti più record di una Dimension Table, perché essa contiene i record di numerosi eventi, come ad esempio le singole vendite effettuate nel periodo di diversi anni di attività dell’azienda.

Le Dimension Table

Le Dimension Table sono delle tabelle periferica nello Star Schema, e ognuna di esse è collegata alla Fact Table tramite una relazione “Uno a Molti”, in cui il lato “Uno” della relazione si trova a lato della tabella dimensionale. Esse hanno il compito di descrivere e contestualizzare i dati numerici contenuti nella Fact Table. In altre parole, le Dimension Table forniscono i “punti di vista” da cui possiamo osservare e analizzare i fatti (i record presenti nella tabella dei fatti). Esempi comuni sono:

• Product (Prodotti)
• Customer (Clienti)
• Date (tabella temporale)
• Employee, Region, OrderType, ecc.

Ognuna di queste tabelle contiene informazioni descrittive che danno significato ai numeri della Fact Table. Ad esempio, se osserviamo i dati numerici presenti in tale tabella, invece di vedere solo un codice prodotto o un ID cliente, grazie alle tabelle dimensionali associate, possiamo leggere nomi, categorie, aree geografiche, periodi temporali e altri attributi. Per esempio, nel contesto di business di un semplice sistema e-commerce:

• la dimensione¹ Product descrive i dati relativi ai prodotti venduti (es.: nome, categoria, marca, colore).
• la dimensione Customer descrive i clienti (es.: nome, città, fascia d’età, settore).
• la dimensione Date fornisce la struttura temporale (giorno, mese, trimestre, anno).

Immaginiamo di avere una Fact Table di nome Sales. Quando creiamo una visualizzazione in Power BI, e trasciniamo un campo descrittivo da una Dimension Table, ad esempio il campo [Salesperson] dell’omonima tabella Salesperson, Power BI effettua le seguenti operazioni:

1. utilizza la relazione tra la tabella dimensionale Salesperson e la la tabella dei fatti Sales;
2. raggruppa automaticamente i record di Sales per la dimensione Salesperson[Salesperson];
3. per ogni gruppo risultante, calcola le misure numeriche (es. Totale Vendite, Quantità, Margine) solo sui dati filtrati.

In altre parole, i campi delle Dimension Table “guidano” il processo di raggruppamento e filtro operato sulla Fact Table, come mostrato dall’immagine seguente, che indica il totale delle vendite raggruppate per venditore e paese:

Ogni Dimension Table contiene valori univoci nelle sue chiavi:

• una riga per ogni prodotto nella tabella Product;
• una riga per ogni cliente nella tabella Customer;
• una riga per ogni giorno nella tabella Date.

Poiché queste tabelle si limitano a elencare i possibili valori descrittivi (e non tutti i record di transazioni), sono generalmente più piccole delle Fact Table.

Lo Snow Flake Schema

Lo Snowflake Schema (schema “a fiocco di neve”) è una variante dello Star Schema. Nello Star Schema classico, ogni Dimension Table è collegata direttamente alla Fact Table. Nello Snowflake Schema, invece, alcune dimensioni vengono normalizzate in più tabelle, e organizzate in strutture gerarchiche. In altre parole, le tabelle dimensionali vengono suddivise in sotto-dimensioni, collegate tra loro tramite chiavi esterne. Questa suddivisione consente di rappresentare ogni concetto una sola volta all’interno di una tabella dedicata, riducendo la ridondanza dei dati. Il risultato è un diagramma più ramificato, che visivamente ricorda un fiocco di neve — da cui deriva il nome dello schema. Ad esempio, nell’immagine seguente, la Dimension Table DimProduct viene normalizzata in più livelli tramite le tabelle DimProductSubcategory e DimProductCategory:

Concettualmente, lo Snow Flake Schema - rispetto allo Star Schema - è un “passo indietro” verso gli schemi normalizzati dei database transazionali. Tale struttura presenta i seguenti vantaggi:

• Minore Ridondanza:
  lo Snowflake Schema riduce la duplicazione dei dati nelle Dimension Table, poiché ogni informazione viene memorizzata una sola volta nella tabella a cui appartiene. Nell’immagine precedente, ad esempio, il nome della categoria di un prodotto è archiviato in modo univoco nella tabella DimProductCategory. Allo stesso modo, la relativa sotto-categoria è conservata nella tabella DimProductSubcategory, evitando di ripetere questi valori all’interno di DimProduct.

• Maggiore Coerenza dei Dati:
  lo Schema a Fiocco di Neve mantiene una struttura più pulita e coerente dal punto di vista del modello logico. Questo accade perché ogni concetto viene separato in una tabella dedicata, evitando duplicazioni e garantendo che ogni informazione esista in un solo punto del modello.

• Migliore Manutenzione del Data Model:
  questo tipo di data model è più vicino alla struttura di un modello relazionale classico, spesso utilizzato nella fase di importazione dei dati. Per questo motivo, l’aggiornamento di informazioni condivise o comuni può risultare più semplice, poiché esse sono centralizzate in tabelle specifiche anziché distribuite in più punti del modello.

Tuttavia, usando lo Snow Flake Schema, le query diventano più complesse (e lente), a causa del maggior numero di join necessarie per recuperare i dati normalizzati. Questo può peggiorare le prestazioni di Power BI, soprattutto su grandi dataset, e rendere “visivamente” più difficile la comprensione del modello.

Linee Guida della Modellazione Dimensionale

Il libro The Data Warehouse Toolkit di Ralph Kimball (il testo di riferimento per la modellazione dimensionale) indica una serie di principi fondamentali che guidano la corretta progettazione di uno schema a stella. Ecco una sintesi delle regole più importanti:

1. Parti sempre da un processo reale e dalle domande analitiche che deve supportare:
   Ogni Fact Table deve rappresentare un processo misurabile dell’azienda. Esempi: vendite, spedizioni, ordini, prenotazioni, pagamenti. L’obiettivo è modellare come il business “funziona”, non come i dati sono archiviati nel sistema sorgente.

2. Separa i dati “misurabili” da quelli “descrittivi”:
   Ogni fatto deve avere un contesto fornito dalle sue dimensioni. Come abbiamo visto, i fatti (Fact Table) sono le misure quantitative (importi, quantità, costi, tempi, ecc.), mentre le dimensioni (Dimension Table) sono gli attributi descrittivi (cliente, prodotto, data, luogo, ecc.)

3. Le relazioni devono essere chiare e basate su chiavi surrogate² stabili:
   La chiave primaria della Fact Table è formata dalle chiavi esterne delle sue Dimension Table (es. DateKey, ProductKey, CustomerKey). Queste relazioni creano il legame tra i i dati quantitativi presenti nella tabella dei fatti e i contesti di analisi delle tabelle dimensionali.

4. Ogni dimensione ha una chiave surrogata stabile nel tempo:
   Le chiavi delle Dimension Table non devono dipendere dai sistemi sorgente (es. codici ERP o CRM) o da concetti di business (es.: codice SKU per un sistema di e-commerce), ma da un identificativo interno al data warehouse. Questo permette di gestire meglio la storia dei dati (es. clienti che cambiano indirizzo) e l’indipendenza dal sistema sorgente.

5. Scegli consapevolmente la strategia “Slowly Changing Dimension” per ogni dimensione:
   I dati dimensionali cambiano nel tempo (es. un cliente cambia città o un prodotto cambia categoria). A seconda delle esigenze analitiche, Kimball propone diverse tecniche per gestire questi cambiamenti, ad esempio:

   • Tipo 1: sovrascrivi il valore (non mantenere lo storico dei dati).
   • Tipo 2: aggiungi una nuova riga con una nuova chiave (conserva lo storico dei dati).
   • Tipo 3: per un dato campo, conserva una versione “precedente” e una “attuale” nella stessa riga, senza aggiungere nuovi record. Ad esempio, usa il campo Indirizzo e Indirizzo_Precedente.

6. Mantieni le Fact Table additive:
   Le misure devono poter essere additive, sommate in modo coerente lungo le dimensioni. Kimball distingue tra:

   • Fatti completamente additivi: (es. vendite, quantità) — sommabili su tutte le dimensioni.
   • Fatti semi-additivi: (es. giacenze di magazzino) — sommabili solo su alcune dimensioni, non sul tempo.
   • Fatti non additivi: (es. percentuali, rapporti) — da calcolare tramite formule.

7. Privilegia la semplicità e la leggibilità rispetto alla ridondanza:
   Lo Star Schema deve essere semplice da capire: le Dimension Table non devono essere normalizzate (niente sotto-tabelle o join annidati), e ogni dimensione deve contenere tutti gli attributi descrittivi necessari per l’analisi.

8. Crea dimensioni conformi³ (Conformed Dimension):
   Le Dimension Table comuni (es. Date, Customer, Product) devono essere condivise tra più Fact Table. Questo permette di avere coerenza tra più modelli e analisi trasversali tra processi diversi (es. confrontare vendite e spedizioni per cliente).

9. Documenta la granularità della Fact Table:
   La granularità definisce il livello di dettaglio di ogni riga nella Fact Table. Ad esempio: una riga per transazione singola (granularità fine), oppure una riga per giorno e prodotto (granularità grossolana, quando ogni riga rappresenta un’aggregazione o un riassunto di più eventi). Tutti gli attributi e le misure devono essere coerenti con il livello di dettaglio scelto.

10. Includi sempre una dimensione temporale (Date Table):
    Quasi ogni analisi richiede una prospettiva temporale (calcoli definiti per mese, trimestre, anno, ecc.). Una Dimension Table di tipo Date fornisce flessibilità nei confronti temporali e semplifica i calcoli DAX. Quindi, nel data model, è buona regola creare sempre una tabella calendario dedicata, anche se il database sorgente ha campi data all’interno delle singole tabelle.

11. Evita relazioni complesse o circolari:
    Kimball raccomanda di mantenere uno schema chiaro, a stella o fiocco di neve semplice, evitando relazioni “Molti a Molti” non necessarie, join tra Dimension Table e cicli di relazioni⁴. Con questa struttura di relazioni, un sistema relazionale non sa quale percorso usare per propagare i filtri o calcolare le misure. Come risultato, potremmo avere ambiguità nei risultati delle query, errori di modellazione oppure prestazioni scadenti.

    Nota: in Power BI, i cicli di relazioni sono vietati per impostazione predefinita.

Misure Additive, Semi-Additive e Non-Additive

Una misura addittiva è un valore numerico che può essere aggregato tramite la funzione SUM lungo tutte le dimensioni del modello (per qualsiasi attributo). L’importo delle vendite è un esempio perfetto di misura additiva. Infatti, l’importo delle vendite per tutti i clienti è la somma delle vendite individuali di ciascun cliente (aggregazione per cliente); allo stesso tempo, l’importo su base annua è la somma degli importi di ciascun mese (aggregazione lungo una dimensione temporale).

In altre parole, una misura addittiva è una misura che mantiene il suo significato anche quando viene sommata per prodotto, per cliente, per area geografica, per periodo di tempo o per qualsiasi altra dimensione. In Power BI, le misure additive vengono aggregate automaticamente. Immaginiamo una Fact Table Vendite di questo tipo:

Le misure Quantità e Importo sono additive, perché puoi sommarle:

• per cliente (totale vendite per cliente),
• per prodotto (totale vendite per prodotto),
• per mese, o per qualsiasi altra dimensione

e il risultato ha sempre senso. Ad esempio:

• Totale Importo: 800 + 1.600 + 600 = 3.000
• Totale vendite per prodotto:
  • Laptop = 2.400
  • Smartphone = 600

Una misura semi-additiva è una misura numerica che descrive uno stato o una condizione in un punto nel tempo. Essa può essere sommata correttamente solo lungo alcune dimensioni (campi), ma su altre dimensioni la sommatoria deve usare regole particolari. Alcuni esempi di misure semi-additive sono: saldi, scorte, giacenze. Consideriamo la seguente tabella, che contiene il saldo del conto corrente di un determminato cliente:

Per il campo Cliente, la misura deve essere additiva: il saldo totale per tutti i clienti è la somma del saldo di ciascun cliente. Tuttavia, quando si aggrega nel tempo, usando il campo Data, non è possibile utilizzare la funzione SUM in modo normale. In questo caso, la misura deve considerare solo l’ultimo valore dell’intervallo temporale scelto. Ad esempio:

• per Gennaio 2025, SUM deve considerare esclusivamente il saldo del giorno 31/01/2025 (€1.500,00);
• per il primo trimestre del 2025, SUM deve considerare il saldo del 31/03/2025;
• per l’anno 2025, SUM deve considerare il saldo del 31/12/2025.

Una misura non-additiva è un valore calcolato o derivato, che non può essere aggregato con una somma, ma deve essere ricalcolato ogni volta che cambia il contesto di analisi. Alcuni esempi di tali misure sono: percentuali, indici, prezzi medi.