Un report può avere grafici impeccabili e restituire comunque numeri sbagliati se le tabelle non comunicano tra loro nel modo corretto. Un data model Power BI ben progettato chiarisce la struttura dei dati, rende le misure DAX più affidabili e migliora anche la velocità dei report. In questa guida mostro come organizzare fatti e dimensioni, creare relazioni solide, scegliere tra Import e DirectQuery e gestire gli errori che più spesso complicano i progetti reali.
Un modello Power BI efficace nasce da relazioni semplici e da una granularità chiara
- Schema a stella con tabelle dei fatti e dimensioni separate.
- Relazioni uno-a-molti con filtri, quando possibile, in una sola direzione.
- Misure DAX preferibili alle colonne calcolate per i risultati aggregati.
- Tabella calendario dedicata per analisi temporali coerenti.
- Controlli su prestazioni e sicurezza prima della pubblicazione.
Il modello giusto parte da fatti e dimensioni
Quando progetto un modello in Power BI, parto sempre da una domanda semplice: che cosa rappresenta una riga? Questa informazione definisce la granularità, cioè il livello di dettaglio del dato, e condiziona ogni relazione, misura e filtro del report.
Lo schema a stella è spesso il punto di partenza più efficace. Al centro si trova una tabella dei fatti, che registra eventi come vendite, ordini o movimenti di magazzino. Intorno ci sono le dimensioni, che descrivono prodotti, clienti, date, punti vendita o venditori.
| Elemento | Contenuto | Esempio |
|---|---|---|
| Tabella dei fatti | Eventi, chiavi e valori numerici | Vendite con quantità, prezzo e costo |
| Dimensione | Attributi usati per filtrare e raggruppare | Prodotto, cliente, data, regione |
| Misura | Calcolo eseguito al momento della query | Fatturato, margine, numero di ordini |
Immaginiamo una tabella FactSales con una riga per ogni riga d’ordine. Le dimensioni DimDate, DimProduct e DimCustomer filtrano quella tabella attraverso chiavi univoche. Il vantaggio non è solo estetico: i filtri diventano prevedibili e le formule DAX hanno meno possibilità di produrre risultati ambigui.
Un errore frequente consiste nel mescolare descrizioni e transazioni nella stessa tabella senza una ragione precisa. Un altro è sommare dati con granularità diverse, per esempio vendite giornaliere insieme a obiettivi mensili, senza definire come devono essere confrontati. Prima di creare una misura, scrivo sempre una frase come “una riga rappresenta una vendita per prodotto e giorno”. Se non riesco a formularla, il modello non è ancora pronto.
Come costruire il modello senza creare confusione
La modellazione non comincia dalla vista Relazioni. Comincia dalla preparazione dei dati. Power Query serve per importare, pulire e trasformare le sorgenti; il modello semantico serve poi a stabilire come quelle tabelle devono interagire nei report.
- Definisci il processo aziendale. Parti da vendite, acquisti, ticket o budget e stabilisci quali eventi vuoi analizzare.
- Controlla la granularità. Verifica che ogni riga della tabella dei fatti abbia lo stesso significato.
- Prepara le chiavi. La colonna sul lato “uno” deve contenere valori univoci e non vuoti.
- Crea le relazioni. Preferisci relazioni uno-a-molti tra dimensioni e fatti, con propagazione del filtro dalla dimensione al fatto.
- Nascondi i dettagli tecnici. Le chiavi e le colonne utilizzate solo per le relazioni non dovrebbero confondere chi costruisce il report.
Le relazioni determinano il comportamento dei filtri
Una relazione non è solo un collegamento grafico. È il percorso attraverso cui un filtro passa da una tabella all’altra. Se seleziono “Lombardia” nella dimensione dei clienti, Power BI deve sapere come arrivare alle vendite da aggregare.
La configurazione più leggibile è generalmente uno-a-molti e a direzione singola. Le relazioni bidirezionali possono essere utili in casi specifici, ma introducono percorsi di filtro più difficili da controllare e possono creare ambiguità.
Le relazioni molti-a-molti meritano particolare cautela. Quando due dimensioni devono essere collegate, spesso inserisco una tabella ponte con le chiavi delle due entità. Per esempio, una tabella ponte può associare più venditori a più aree commerciali senza forzare Power BI a interpretare direttamente una relazione ambigua.
La tabella calendario non è un dettaglio
Per analizzare mesi, trimestri, anni e periodi precedenti, uso una dimensione data autonoma collegata alla tabella dei fatti. Deve contenere almeno una riga per ogni giorno del periodo analizzato e colonne come anno, mese, numero del mese e trimestre.
Una data scritta come testo o una gerarchia automatica lasciata al caso può funzionare in un prototipo, ma diventa fragile appena servono confronti come anno su anno o progressivi annuali. Una sola dimensione data condivisa mantiene coerenti calendario, filtri e misure.
DAX funziona bene quando il modello gli lascia spazio
DAX non corregge una struttura confusa. Può modificare il contesto di filtro e applicare logiche molto potenti, ma se le relazioni sono errate una formula complessa spesso nasconde il problema invece di risolverlo.
Per i valori aggregati preferisco creare misure esplicite. Una misura viene calcolata quando il visual ne ha bisogno e risponde ai filtri applicati dall’utente. Un esempio essenziale è:
Fatturato =
SUMX(
FactSales,
FactSales[Quantity] * FactSales[UnitPrice]
)Se il prezzo è già memorizzato come valore di riga, SUM può essere sufficiente. SUMX, invece, valuta un’espressione riga per riga e poi somma i risultati. La scelta dipende dalla struttura della tabella dei fatti, non da una regola assoluta.
Misure e colonne calcolate hanno scopi diversi
Una colonna calcolata viene valutata per ogni riga durante l’aggiornamento del modello e occupa spazio in memoria. Una misura viene calcolata durante l’interazione con il report. Per questo, per percentuali, totali, margini e KPI, scelgo quasi sempre una misura.
Margine % =
DIVIDE(
[Margine],
[Fatturato],
0
)DIVIDE gestisce in modo più sicuro il caso in cui il denominatore sia zero o vuoto. È una piccola scelta, ma evita messaggi di errore e risultati poco presentabili nei visual.
Il contesto di filtro è il vero centro di DAX
La funzione CALCULATE modifica il contesto in cui viene valutata una misura. Per esempio, posso calcolare il fatturato dell’anno precedente usando una dimensione data ben collegata:
Fatturato anno precedente =
CALCULATE(
[Fatturato],
DATEADD(DimDate[Date], -1, YEAR)
)Questa formula funziona correttamente solo se la colonna data è completa, collegata alla tabella dei fatti e utilizzata nel modo previsto. Nella pratica, molti problemi attribuiti a DAX dipendono invece da date duplicate, relazioni inattive o granularità incompatibili.
Quando una tabella dei fatti contiene più date, per esempio ordine, spedizione e consegna, una sola relazione tra le stesse tabelle può essere attiva. Per usare una relazione alternativa si può ricorrere a USERELATIONSHIP, ma se le date hanno un ruolo importante nel report può essere più chiaro usare dimensioni data separate per ogni ruolo.
Import, DirectQuery e modello composito richiedono scelte diverse
La modalità di connessione influenza prestazioni, aggiornamento e complessità del progetto. Non esiste una scelta migliore in assoluto: dipende dal volume dei dati, dalla frequenza richiesta e dalle capacità della sorgente.
| Modalità | Punto di forza | Limite principale | Quando la sceglierei |
|---|---|---|---|
| Import | Risposte rapide grazie ai dati caricati nel modello | Richiede aggiornamenti programmati e memoria sufficiente | Report direzionali e analisi interattive quotidiane |
| DirectQuery | Interroga la sorgente senza importare tutto il contenuto | Le prestazioni dipendono dal database e dalle query generate | Dati molto grandi o requisiti di freschezza elevati |
| Composito | Combina tabelle importate e tabelle interrogate direttamente | Aumenta la complessità delle relazioni e dei test | Scenari ibridi con dati storici e dati operativi recenti |
Per la maggior parte dei report gestionali partirei da Import, se il volume e la frequenza di aggiornamento lo consentono. Offre spesso l’esperienza più fluida e rende più semplice ottimizzare le misure. DirectQuery ha senso quando la latenza dell’aggiornamento è davvero importante o quando importare i dati non è praticabile.
Un compromesso comune consiste nel mantenere in Import lo storico e interrogare direttamente solo i dati più recenti. Questa soluzione può essere valida, ma va verificata con dati realistici. Un modello composito progettato senza test può risultare più lento e più difficile da amministrare di un modello Import completo.
Prestazioni, sicurezza e manutenzione si progettano insieme
La velocità non dipende soltanto dal numero di righe. Contano anche il numero di colonne, i tipi di dati, la cardinalità e la qualità delle relazioni. Una colonna testuale ad alta cardinalità, come un identificativo univoco ripetuto raramente, può pesare più di quanto immaginiamo.
Nel lavoro quotidiano applico alcune regole semplici:
- elimino in Power Query le colonne che non servono al report;
- preferisco tipi numerici e date corretti a testi usati impropriamente;
- evito di caricare tabelle intermedie che non hanno un ruolo analitico;
- mantengo una granularità coerente nelle tabelle dei fatti;
- controllo le query lente con Performance Analyzer e con test su visual rappresentativi;
- valuto l’aggiornamento incrementale quando lo storico cresce continuamente.
La sicurezza a livello di riga, o RLS, filtra i dati in base all’utente o al ruolo. Per esempio, un responsabile regionale può vedere solo le vendite della propria area. La sicurezza dipende però dalla propagazione dei filtri: una relazione configurata male può mostrare dati incompleti oppure non applicare il filtro dove serve.
Per questo testo sempre RLS con almeno due profili diversi e verifico i risultati direttamente nel servizio Power BI. Non mi affiderei a un controllo visivo del report: un modello apparentemente corretto può ancora esporre dati oltre il perimetro previsto.
Leggi anche: TOPN in DAX per classifiche dinamiche in Power BI
La documentazione riduce gli errori futuri
Un modello condiviso dovrebbe avere nomi coerenti, descrizioni per le misure più importanti e una breve nota sulla granularità di ogni tabella dei fatti. Anche una pagina interna con le definizioni di “fatturato”, “cliente attivo” e “ordine completato” evita discussioni ripetute tra analisti e responsabili aziendali.
La documentazione ufficiale Microsoft Learn tratta separatamente schema a stella, relazioni, DAX e progettazione dei modelli semantici. Io la uso come riferimento tecnico, ma la completo sempre con regole specifiche del progetto, perché nessuna guida generale conosce le definizioni adottate dalla singola azienda.
Gli errori che rendono fragile un modello Power BI
Il primo errore è importare una grande tabella piatta e collegarla direttamente a tutto. Può sembrare il modo più veloce per iniziare, ma appena aumentano i visual compaiono duplicazioni, filtri incoerenti e misure difficili da mantenere.
Il secondo è lasciare a Power BI la creazione automatica di tutte le relazioni. L’individuazione automatica può essere utile come suggerimento, ma non conosce sempre la logica aziendale. Una relazione basata su una colonna dal nome simile non è necessariamente una relazione corretta.
Altri segnali da controllare sono:
- totali duplicati dopo un merge o una relazione molti-a-molti;
- filtri che non arrivano alla tabella dei fatti;
- misure diverse che usano definizioni differenti dello stesso KPI;
- date incoerenti tra calendario, transazioni e obiettivi;
- formule DAX enormi usate per compensare una struttura dati sbagliata.
Quando una misura richiede molti FILTER, LOOKUPVALUE e condizioni eccezionali per restituire un numero apparentemente semplice, mi fermo e controllo il modello. Spesso la soluzione più solida non è aggiungere altra DAX, ma correggere una chiave, separare una dimensione o rendere esplicita la granularità.
La verifica finale che trasforma le tabelle in un modello affidabile
Prima di pubblicare un report, controllo il modello con una sequenza breve ma concreta. Verifico la granularità dei fatti, l’unicità delle chiavi, la direzione delle relazioni, il comportamento della tabella calendario e la riconciliazione di almeno un totale con la fonte originale.
- Una riga della tabella dei fatti ha un significato preciso?
- Le dimensioni filtrano i fatti senza percorsi ambigui?
- Le misure principali restituiscono lo stesso totale della fonte?
- Import o DirectQuery rispondono ai tempi richiesti dagli utenti?
- RLS, aggiornamento e responsabilità di manutenzione sono stati testati?
La mia regola pratica è questa: prima si rende chiaro il modello, poi si rende sofisticata la DAX. Un modello Power BI semplice da leggere sarà anche più facile da spiegare, correggere e far crescere quando arriveranno nuovi dati, nuovi utenti e nuove domande aziendali.
