Un report può avere grafici impeccabili e restituire comunque risposte sbagliate se le formule non rispettano il modello dati. Il rapporto tra DAX e Power BI serve proprio a trasformare tabelle collegate in indicatori dinamici, percentuali, confronti temporali e misure utili alle decisioni. In questa guida mostro come scegliere tra misure e colonne calcolate, come interpretare il contesto di filtro, quali formule usare davvero e quali errori evitare.
Le idee da portare subito nel modello
- Le misure sono la scelta principale per KPI e analisi dinamiche.
- Il contesto di filtro determina il risultato di una formula in ogni visual.
- CALCULATE modifica i filtri ed è il cuore di molte espressioni DAX.
- Un modello a stella rende le formule più leggibili e spesso più efficienti.
- Le colonne calcolate vanno usate per valori riga per riga, non per ogni aggregazione.
Che cosa aggiunge DAX a Power BI
DAX, acronimo di Data Analysis Expressions, è il linguaggio con cui si definiscono calcoli nel modello semantico di Power BI. Non serve soltanto a sommare una colonna. Permette di applicare logiche aziendali, confrontare periodi, ignorare o mantenere filtri, lavorare con tabelle correlate e costruire indicatori che cambiano in base alle selezioni dell'utente.
La differenza rispetto alle formule tradizionali di Excel è soprattutto nel modo in cui DAX gestisce le relazioni tra tabelle e il contesto in cui una formula viene valutata. Se un utente seleziona Lombardia, il 2025 e una determinata categoria, la stessa misura può restituire un valore diverso senza essere modificata.
Per esempio, una misura base può essere scritta così:
Vendite totali = SUM(Vendite[Importo])La formula non produce un unico numero fisso. Il risultato dipende dal visual in cui viene inserita, dai segmenti, dai filtri della pagina e dalle relazioni del modello. È questa dinamicità a rendere DAX così utile per la business intelligence.
Misure, colonne e tabelle calcolate non sono la stessa cosa
Uno degli errori più frequenti consiste nel creare una colonna calcolata quando servirebbe una misura. Le tre opzioni hanno scopi diversi e la scelta incide su memoria, aggiornamento e comportamento nel report.
| Elemento | Quando si calcola | Uso consigliato |
|---|---|---|
| Misura | Quando il visual la richiede | KPI, totali, margini, percentuali e confronti dinamici |
| Colonna calcolata | Durante l'aggiornamento del modello | Classificazioni, etichette, valori necessari riga per riga |
| Tabella calcolata | Durante l'aggiornamento del modello | Tabelle di supporto, calendari o strutture specifiche del modello |
Una misura per il margine, ad esempio, dovrebbe quasi sempre essere dinamica:
Margine % =
DIVIDE(
[Vendite totali] - [Costo totale],
[Vendite totali]
)La funzione DIVIDE è preferibile all'operatore `/` perché gestisce in modo più sicuro il caso in cui il denominatore sia nullo o uguale a zero. In quel caso si può anche specificare un valore alternativo, come `0`.
Quando una colonna calcolata è più adatta
Se devo assegnare a ogni ordine una fascia di valore, una colonna può essere sensata:
Fascia ordine =
IF(
Vendite[Importo] >= 1000,
"Alto",
"Standard"
)Il risultato viene memorizzato riga per riga e può essere usato come filtro o categoria. Non la userei però per calcolare il totale delle vendite, perché in quel caso una misura sfrutta meglio il motore di Power BI e risponde ai filtri del report.
Il ruolo di Power Query
Non tutto ciò che è calcolabile deve essere scritto in DAX. Se devo pulire testi, dividere colonne, unire file o trasformare una data, preferisco intervenire in Power Query, prima che i dati entrino nel modello. DAX dovrebbe occuparsi soprattutto della logica analitica e degli indicatori, non della pulizia di dati strutturalmente disordinati.
Il contesto di filtro è la parte che cambia tutto
Una misura non legge semplicemente una colonna. Legge quella colonna dentro un preciso contesto di filtro, cioè l'insieme dei filtri attivi in quel momento. Un filtro può arrivare da un segmento, da una riga del visual, da un filtro pagina, da una relazione o direttamente dalla formula.
In una matrice con Anno nelle righe, la misura delle vendite viene valutata separatamente per ogni anno. Se aggiungo Regione alle colonne, Power BI crea nuovi contesti e ricalcola lo stesso esatto DAX per ogni combinazione di anno e regione.
Il contesto di riga è diverso. Rappresenta la riga corrente e compare soprattutto nelle colonne calcolate e nelle funzioni iteratrici come `SUMX`, `AVERAGEX` e `FILTER`. Confondere i due contesti è la causa di molti risultati apparentemente inspiegabili.
Perché CALCULATE è così importante
`CALCULATE` valuta un'espressione modificando il contesto di filtro. È la funzione che uso quando voglio dire a Power BI di calcolare un indicatore in condizioni diverse da quelle applicate normalmente dal visual.
Vendite online =
CALCULATE(
[Vendite totali],
Canali[Tipo] = "Online"
)Qui la misura mantiene il resto del contesto, ma aggiunge il filtro sul canale. Se il report è già filtrato per anno e regione, il calcolo rimane limitato a quell'anno e a quella regione, oltre che alle vendite online.
Un altro esempio utile serve a confrontare le vendite con il totale complessivo:
Quota sul totale =
DIVIDE(
[Vendite totali],
CALCULATE(
[Vendite totali],
REMOVEFILTERS(Prodotti[Categoria])
)
)REMOVEFILTERS elimina il filtro sulla categoria, lasciando attivi gli altri. Questo rende la formula più esplicita di molte soluzioni basate soltanto su `ALL`, soprattutto quando l'obiettivo è chiarire la logica a chi dovrà mantenere il modello.
Filtri sostituiti e filtri mantenuti
Quando `CALCULATE` applica un filtro a una colonna già filtrata, il nuovo filtro può sostituire quello esistente. Se invece voglio aggiungere una condizione senza perdere la selezione dell'utente, posso usare KEEPFILTERS.
Vendite prodotti premium =
CALCULATE(
[Vendite totali],
KEEPFILTERS(Prodotti[Segmento] = "Premium")
)La differenza sembra piccola, ma diventa decisiva nei report con molti segmenti e filtri incrociati. Quando una misura restituisce totali troppo alti, controllo prima proprio il comportamento dei filtri dentro `CALCULATE`.
Le formule DAX più utili per iniziare con criterio
Imparare centinaia di funzioni non è il modo più efficace per diventare autonomi. Conviene partire da un gruppo ristretto di funzioni, capire il loro comportamento e combinarle in misure leggibili.
| Obiettivo | Funzioni tipiche | Perché servono |
|---|---|---|
| Aggregare valori | SUM, COUNTROWS, DISTINCTCOUNT | Creano totali, conteggi e conteggi unici |
| Gestire condizioni | IF, SWITCH | Separano scenari e classificano risultati |
| Modificare filtri | CALCULATE, FILTER, REMOVEFILTERS | Controllano il perimetro del calcolo |
| Gestire valori mancanti | COALESCE, DIVIDE | Evitano risultati vuoti o divisioni non valide |
| Analizzare il tempo | DATEADD, TOTALYTD, SAMEPERIODLASTYEAR | Costruiscono confronti tra periodi |
Confrontare l'anno precedente
Per le analisi temporali serve una tabella calendario completa, collegata alla tabella dei fatti e configurata correttamente. Una misura tipica è:
Vendite anno precedente =
CALCULATE(
[Vendite totali],
SAMEPERIODLASTYEAR(Calendario[Data])
)Da qui posso costruire la variazione percentuale:
Variazione annua % =
DIVIDE(
[Vendite totali] - [Vendite anno precedente],
[Vendite anno precedente]
)Se il risultato è vuoto, non significa necessariamente che la formula sia sbagliata. Potrebbero mancare date, la relazione potrebbe usare la colonna errata oppure il calendario potrebbe non coprire tutti i periodi. La qualità della tabella date conta quanto la formula.
Usare variabili per rendere il DAX leggibile
Le variabili riducono ripetizioni e rendono più semplice controllare un calcolo:
Margine assoluto =
VAR Ricavi = [Vendite totali]
VAR Costi = [Costo totale]
RETURN
Ricavi - CostiIn pratica, una misura con nomi chiari è più facile da verificare durante un controllo finanziario o una revisione del report. Secondo la mia esperienza, la leggibilità non è un dettaglio estetico: evita modifiche frettolose che introducono errori nei KPI.
Il modello dati decide quanto sarà semplice il DAX
Molti problemi attribuiti al linguaggio dipendono in realtà da un modello costruito male. La struttura che consiglio nella maggior parte dei progetti è il modello a stella, con una tabella dei fatti al centro e dimensioni separate per date, prodotti, clienti e geografia.
La tabella dei fatti contiene eventi misurabili, come righe d'ordine o movimenti contabili. Le dimensioni descrivono quegli eventi. Questa separazione evita relazioni ambigue, semplifica i filtri e rende formule come `[Vendite totali]` riutilizzabili in molti visual.
Relazioni e direzione del filtro
Una relazione uno-a-molti dalla dimensione alla tabella dei fatti è spesso il punto di partenza più sicuro. Le relazioni bidirezionali possono essere utili in scenari specifici, ma introdurle senza una ragione chiara crea percorsi multipli e risultati difficili da diagnosticare.
Quando esistono più date nella stessa tabella, per esempio data ordine e data consegna, una relazione può essere inattiva e attivata solo dentro una misura:
Vendite per data consegna =
CALCULATE(
[Vendite totali],
USERELATIONSHIP(
Vendite[DataConsegna],
Calendario[Data]
)
)Questo approccio è più pulito che duplicare inutilmente la tabella dei fatti. La relazione inattiva resta disponibile per un'esigenza precisa, mentre la misura documenta quale data sta guidando l'analisi.
Leggi anche: Quanto costa Power BI? Guida a Pro, PPU e Fabric
Performance e manutenzione
Per migliorare le prestazioni, riduco le colonne inutili, preferisco tipi di dati appropriati e mantengo le misure semplici. Evito anche di usare `FILTER` su intere tabelle quando basta un filtro diretto su una colonna, perché il motore può gestire meglio quest'ultimo caso.
Le misure rapide possono essere un buon punto di partenza per calcoli comuni come variazioni annuali o medie mobili. Le uso soprattutto come materiale didattico, perché Power BI mostra il DAX generato e permette di capire la struttura della formula prima di personalizzarla.
Gli errori che fanno perdere tempo nei report
Il primo errore è aspettarsi che una misura restituisca lo stesso valore in ogni punto del report. Una misura è sensibile al contesto, quindi un totale generale può non coincidere con la somma visiva delle righe quando la logica prevede percentuali, medie o condizioni particolari.
Un secondo problema nasce dall'uso di `SUM` quando serve un iteratore. Se devo calcolare il valore riga per riga, posso usare:
Valore vendite calcolato =
SUMX(
Vendite,
Vendite[Quantità] * Vendite[Prezzo unitario]
)SUMX valuta l'espressione per ogni riga e poi somma i risultati. È diverso da sommare una colonna già esistente e diventa indispensabile quando il valore finale dipende dalla moltiplicazione o da una logica riga per riga.
Un terzo errore consiste nel creare relazioni tra colonne con granularità diversa. Collegare una data completa a un semplice anno o un codice prodotto duplicato a una dimensione non univoca può produrre filtri incompleti e duplicazioni.
- Controllo che la dimensione sul lato “uno” abbia valori univoci.
- Verifico che le date abbiano lo stesso tipo e la stessa granularità.
- Testo le misure con una tabella semplice prima di usarle in un grafico complesso.
- Uso nomi coerenti per tabelle, colonne e misure.
- Controllo i valori vuoti prima di correggerli con formule artificiali.
Quando una misura non funziona, non la riscrivo subito da zero. Creo misure intermedie, mostro il risultato in una tabella e aggiungo i filtri uno alla volta. Questo metodo individua rapidamente se il problema è nella formula, nella relazione o nei dati di origine.
Un percorso pratico per costruire il primo modello
Partirei da un caso concreto, come l'analisi delle vendite di un negozio. Prima importo i dati e verifico tipi, chiavi e valori mancanti. Poi creo una tabella calendario, collego le dimensioni alla tabella Vendite e nascondo dal report le colonne tecniche che non servono all'utente.
- Creo le misure fondamentali per vendite, costi, margine e numero di ordini.
- Verifico il contesto con una tabella che mostra anno, categoria e regione.
- Aggiungo i confronti temporali solo dopo aver validato il calendario.
- Costruisco KPI e grafici usando le misure, non somme automatiche di colonne casuali.
- Misuro la leggibilità del report chiedendomi se ogni indicatore risponde a una decisione reale.
Per imparare, trovo utile creare una misura semplice, duplicarla e modificarne un solo elemento alla volta. Le formule diventano comprensibili quando si osserva concretamente come cambiano con un segmento o una riga del visual, non quando si memorizzano definizioni isolate.
In alcuni casi una visual calculation può essere sufficiente per un totale progressivo o una media mobile direttamente sul risultato già visualizzato. Per logiche riutilizzabili in più pagine, regole aziendali e KPI ufficiali, preferisco però una misura del modello, perché centralizza la logica e riduce le versioni discordanti dello stesso indicatore.
La scelta che rende affidabile ogni misura DAX
La parte più importante non è conoscere una funzione in più, ma sapere dove applicare il calcolo. Pulizia e trasformazione appartengono spesso a Power Query, i valori riga per riga possono richiedere colonne calcolate, mentre gli indicatori che devono reagire ai filtri appartengono alle misure.
Quando il modello ha relazioni chiare, una tabella calendario corretta e misure nominate con criterio, DAX smette di sembrare una raccolta di formule misteriose. Diventa un modo preciso per descrivere come l'azienda vuole leggere i propri dati, con risultati verificabili e riutilizzabili in tutto il report.
