Buone pratiche di modellazione dei dati sono molto importanti per creare report Power BI ottimizzati per le prestazioni e in grado di scalare secondo le necessità.
Questo tutorial utilizza un dataset di esempio fornito da Microsoft, adattato per riflettere le migliori pratiche di data modeling di cui parleremo in questo articolo. Puoi scaricare il dataset qui.
Che cos’è la modellazione dei dati?
La modellazione dei dati è il processo di creazione di rappresentazioni visive delle connessioni tra strutture di dati, con informazioni sugli attributi individuali contenuti in tali strutture.
Quando si parla di modellazione dei dati in generale, il termine che sentirai più spesso è schema a stella. Si tratta di un approccio ampiamente adottato per progettare data warehouse e database relazionali ed è l’approccio consigliato anche in Power BI.
Ci sono due principali vantaggi nell’utilizzare uno schema a stella:
- Usabilità: Uno schema a stella rende il tuo modello dati più pulito e organizzato, e il report risulterà più facile da usare.
- Prestazioni: Gli schemi a stella ti permettono di scalare facilmente il report su volumi di dati molto grandi. Anche le misure DAX vengono calcolate più velocemente e l’aggiornamento del report Power BI è complessivamente più rapido.
Come funziona uno schema a stella?
Uno schema a stella è composto da una tabella dei fatti centrale con più tabelle di dimensione che si diramano da essa, proprio come l’aspetto di una stella. Idealmente, è buona pratica avere una sola tabella dei fatti in un modello dati. Tuttavia, in Power BI è possibile includere più tabelle dei fatti.
Schema a stella in Power BI. Immagine dell’autore
Una tabella dei fatti è composta da valori che possono essere riassunti e aggregati, oltre a una o più chiavi che collegano alle tabelle di dimensione. Lo scopo della chiave è creare connessioni tra le tabelle. Se hai modelli dati complessi o grandi volumi di dati, è una buona idea che le chiavi siano valori numerici piuttosto che stringhe di testo, perché questo può migliorare le prestazioni del modello.
Le tabelle dei fatti dovrebbero essere molto strette e includere il minor numero possibile di colonne. Eventuali colonne che descrivono le caratteristiche di un dataset, come Nome prodotto o Categoria prodotto, dovrebbero essere separate dalla tabella dei fatti (se non sono già separate nel data warehouse) nelle rispettive tabelle di dimensione. Questo processo si chiama normalizzazione dei dati e l’obiettivo è evitare la ripetitività.
Le tabelle di dimensione descrivono le caratteristiche del dataset, raggruppando logicamente le caratteristiche in tabelle separate per evitare di appesantire un’unica tabella o rendere difficoltosa la creazione delle relazioni. Le tabelle di dimensione dovrebbero contenere valori univoci per le caratteristiche che descrivono e le loro colonne saranno responsabili del filtraggio o del raggruppamento dei dati nel report Power BI.
Un’estensione dello schema a stella è lo schema a fiocco di neve. In questo approccio, le tabelle di dimensione vengono ulteriormente suddivise se una caratteristica ha ulteriori categorie o sottocategorie. Nel nostro caso, abbiamo una tabella Prodotti che contiene ID prodotto, Nome prodotto e Categoria prodotto. In uno schema a fiocco di neve, questa tabella Prodotti conterrà solo ID prodotto e Nome prodotto, mentre la Categoria prodotto verrà ulteriormente suddivisa in una propria tabella con ID categoria prodotto e Categoria prodotto.
Schema a fiocco di neve in Power BI. Immagine dell’autore
Tuttavia, l’uso di uno schema a fiocco di neve può aggiungere inutilmente complessità al tuo modello dati; includere queste tabelle extra potrebbe ridurre le prestazioni e rendere difficile e confusa la creazione delle relazioni.
Come creare relazioni in Power BI
Ci sono due modi per creare una relazione in Power BI:
- Seleziona un campo da una tabella e trascinalo sul campo della seconda tabella con cui vuoi creare la relazione.
- Seleziona Gestisci relazioni nella barra multifunzione e scegli “Nuovo” per aggiungere una relazione usando la stessa finestra di cui parleremo tra poco (solo che partirà vuota).
Per impostazione predefinita, Power BI proverà a dedurre una relazione tra le tabelle; non sempre ci riesce, quindi potresti voler disattivare questa funzione nelle impostazioni o eliminare eventuali relazioni create automaticamente. Per modificare la relazione, fai clic con il tasto destro sulla linea di collegamento tra le tabelle e seleziona “Proprietà”.
Questa finestra offre 2 opzioni interessanti quando si definisce una relazione: cardinalità e direzione del filtro incrociato. Le scelte per ciascuna di queste opzioni possono avere un forte impatto sul report risultante, quindi valuta con attenzione. Vediamo nel dettaglio ciascuna opzione.
Creare relazioni in Power BI. Immagine dell’autore
Cardinalità
Ci sono 4 scelte di cardinalità: molti-a-uno, uno-a-uno, uno-a-molti o molti-a-molti.
Quando crei relazioni, si consiglia che il campo di collegamento contenga valori univoci in almeno una delle tabelle. Questo ti permette di usare le opzioni uno-a-molti o molti-a-uno nel tuo modello dati.
Nei nostri dati, abbiamo una relazione tra la tabella Financials e la tabella Products usando il campo ID prodotto. La tabella Products ha valori univoci per il campo Prodotto (ogni prodotto compare una sola volta nella tabella). Tuttavia, la tabella Financials può contenere ciascun prodotto più volte per data, paese, segmento, ecc.
L’opzione molti-a-molti è la più problematica e, sebbene possa essere molto utile in modelli complessi, andrebbe selezionata solo se comprendi appieno le conseguenze di questa relazione.
Per illustrare dove le relazioni molti-a-molti possono creare problemi, creiamo nel modello dati una tabella degli obiettivi di vendita annuali per Categoria prodotto. Dobbiamo poter riportare i valori di vendita e questi obiettivi affiancati nello stesso visual. Questo si può ottenere creando una relazione molti-a-molti tra la tabella Sales Target e la tabella Product.
Relazioni molti-a-molti in Power BI. Immagine dell’autore
Nella seguente tabella visual, possiamo vedere i valori di vendita e gli obiettivi affiancati per ciascuna categoria di prodotto.
Categoria prodotto, vendite e importo. Immagine dell’autore
Tuttavia, se provassimo a visualizzare questa tabella a livello di Prodotto, i valori per l’obiettivo sarebbero completamente errati. Questo a causa dei diversi livelli di granularità nei dati; poiché esistono solo obiettivi di vendita a livello di categoria di prodotto, Power BI non può visualizzare ragionevolmente questi obiettivi a livello di prodotto e quindi gli obiettivi vengono semplicemente duplicati per ogni prodotto nella categoria. Se non sapessi che questa può essere una conseguenza dell’uso di una relazione molti-a-molti, ciò potrebbe essere altamente problematico per il reporting aziendale.
Categoria prodotto, vendite e importo. Immagine dell’autore
Direzionalità
L’opzione di direzione del filtro incrociato offre la scelta tra singola o entrambe le direzioni. Le relazioni fluiscono dalla tabella con valori unici alla tabella con molti valori. Nel nostro caso, la relazione fluisce dalla tabella Products alla tabella Financials. Ciò significa che, se la direzione del filtro incrociato è impostata su singola, la tabella Financials può essere filtrata dai campi prodotto e categoria prodotto nella tabella Products. Tuttavia, la tabella Products non può essere filtrata utilizzando il campo ID prodotto nella tabella Financials o utilizzando qualsiasi altra caratteristica contenuta in altre tabelle di dimensione.
La direzione singola è consigliata nella maggior parte dei casi. Questo perché le relazioni bidirezionali (opzione “entrambe”) non solo riducono le prestazioni del modello, ma possono anche introdurre ambiguità quando si filtra i dati.
Nel nostro caso, considera le relazioni tra le tabelle Product, Countries e Financials. Sono entrambe relazioni uno-a-molti a direzione singola. Questo significa che filtrare il report per paese non filtrerà a sua volta la tabella Product. Per illustrarlo, considera gli slicer qui sotto. Selezionare un paese (come gli USA) non farà sì che lo slicer dei prodotti si adatti mostrando solo i prodotti rilevanti per quel paese.
Slicer in Power BI. Immagine dell’autore
Tuttavia, modificando la relazione tra la tabella Products e la tabella Financials in bidirezionale, possiamo consentire al filtraggio di fluire nella tabella Products. In questo caso, vediamo che il prodotto Carretera non appare nello slicer dei prodotti perché non ci sono vendite per quel prodotto negli Stati Uniti d’America.
Slicer in Power BI. Immagine dell’autore
In alternativa, per evitare l’uso di relazioni bidirezionali, puoi aggiungere un filtro al visual dello slicer per escludere gli elementi vuoti. Vale la pena notare che dovresti farlo per ogni visual che utilizza campi tra tabelle di dimensione.
Filtri e slicer in Power BI. Immagine dell’autore
Come ottimizzare il tuo modello Power BI
Il fattore più importante per ottimizzare il tuo modello Power BI è utilizzare buone pratiche di modellazione dei dati come quelle illustrate in questo tutorial. Molto spesso, un buon modello dati può, da solo, consentire a un report Power BI di scalare a milioni e miliardi di righe mantenendo comunque un livello di prestazioni adeguato.
Tuttavia, oltre a seguire buone pratiche di data modeling, ci sono alcune altre cose che puoi fare per ottimizzare il tuo modello Power BI, come ad esempio:
- Disattivare la time intelligence – Questa funzione in Power BI crea automaticamente gerarchie data/ora ogni volta che un campo data viene aggiunto a un visual. Ogni volta che viene creata una di queste gerarchie, in pratica si aggiunge una tabella aggiuntiva al modello dati. Come puoi immaginare, questo può far gonfiare significativamente il report Power BI, rallentando il rendering dei visual e aumentando i tempi di aggiornamento. È una buona idea disattivare questa funzione e utilizzare invece una tabella date dedicata per tutte le gerarchie data/ora.
- Caricare solo le colonne di cui hai davvero bisogno – Usando l’editor di Power Query, è una buona idea rimuovere le colonne di cui non hai bisogno o che non stai usando nel report. Uno dei campi più comuni che di solito si mantiene “nel caso servisse” è un campo Row ID. Questo campo sarebbe univoco per il tuo dataset, ma un esempio è l’Order ID per ogni transazione in una tabella Ordini. Molto spesso, questo campo ID è anche archiviato come testo, il che gonfia ulteriormente il modello. Se il campo ID non è esplicitamente utilizzato in una relazione, di solito non è necessario caricarlo nel modello.
- Caricare solo le righe necessarie – Non cadere nella trappola di pensare di dover importare tutti i dati aziendali nel tuo report Power BI. Soprattutto se la tua azienda opera da molto tempo, questo può significare che il report conterrà una grande quantità di dati a cui nessuno presta davvero attenzione. La chiave qui è parlare con gli utenti business del report e capire esattamente di quanta storicità hanno bisogno. Se devono vedere dati più vecchi, potresti considerare di importare solo una versione riepilogata di quella tabella anziché ogni singola transazione.
