Relazioni in Power BI - cardinalità, filtri e DAX

Un report Power BI può mostrare numeri plausibili e tuttavia raccontare una storia sbagliata, semplicemente perché le tabelle non comunicano nel modo corretto. In questo articolo chiarisco come funzionano le relazioni tra tabelle, come scegliere cardinalità e direzione dei filtri, quando usare RELATED, RELATEDTABLE e USERELATIONSHIP in DAX e come diagnosticare i risultati inattesi.

Perché le relazioni sono il cuore del modello Power BI

Immaginiamo una tabella FactVendite con importi, quantità e date, collegata a DimProdotto, DimCliente e DimData. Quando seleziono “Lombardia” in un filtro clienti, Power BI deve sapere quali righe della tabella vendite mantenere. La relazione è il percorso che consente a quel filtro di arrivare fino ai valori visualizzati.

Questo meccanismo non serve soltanto a rendere leggibile il diagramma del modello. Determina il contesto di filtro, cioè l’insieme di condizioni che DAX considera quando calcola una misura. Se il collegamento è assente o configurato male, una misura come Totale vendite = SUM(FactVendite[Importo]) può restituire lo stesso totale per ogni cliente o prodotto.

Il modello che preferisco nella maggior parte dei progetti è lo schema a stella. Le dimensioni contengono descrizioni e attributi, mentre la tabella dei fatti contiene gli eventi misurabili. In questo modo i filtri seguono percorsi chiari e il report resta più semplice da usare e da mantenere.

Dimensioni e fatti hanno ruoli diversi

Una tabella dimensionale contiene normalmente una riga per ogni elemento, ad esempio un prodotto o un cliente. La tabella dei fatti, invece, può contenere migliaia di vendite per lo stesso prodotto. Per questo il collegamento tipico è uno-a-molti, indicato in Power BI come 1 a *.

La regola pratica è semplice: il lato “uno” deve contenere una chiave univoca. Se DimProdotto[CodiceProdotto] contiene duplicati, Power BI non può sapere quale descrizione associare a una vendita e la relazione uno-a-molti non è affidabile.

Cardinalità e direzione dei filtri senza confusione

Quando creo una relazione, Power BI chiede soprattutto di definire la cardinalità e la direzione del filtro incrociato. La cardinalità descrive quante righe di una tabella possono corrispondere a una riga dell’altra, mentre la direzione stabilisce in quale verso si propagano i filtri.

Filtro a senso unico

Nel modello classico il filtro viaggia dalla dimensione verso la tabella dei fatti. Un filtro su DimCliente[Regione] riduce le righe di FactVendite, ma la tabella dei fatti non modifica automaticamente l’elenco dei clienti disponibili. Questa direzione rende il comportamento più prevedibile e riduce il rischio di percorsi circolari.

Filtro bidirezionale

L’opzione “Entrambe” può essere utile quando il filtro deve viaggiare in due sensi, ma non è una correzione universale. In modelli complessi può generare ambiguità, rallentamenti e risultati difficili da spiegare, soprattutto quando esistono più percorsi tra le stesse tabelle.

La mia regola è lasciare il filtro a senso unico nello schema a stella e attivare la direzione bidirezionale solo quando esiste un’esigenza concreta. Se una visualizzazione funziona soltanto dopo aver impostato “Entrambe”, controllo prima la struttura del modello e la qualità delle chiavi.

Relazioni attive e inattive

Una relazione attiva viene usata automaticamente per propagare i filtri. Una relazione inattiva, rappresentata con una linea tratteggiata nel modello, resta disponibile ma deve essere richiamata esplicitamente in una misura DAX.

Il caso più comune riguarda la tabella calendario collegata sia a FactVendite[DataOrdine] sia a FactVendite[DataSpedizione]. Per evitare due percorsi attivi ambigui, una relazione può restare inattiva e venire utilizzata solo nelle misure che analizzano le spedizioni.

Come creare una relazione robusta in Power BI Desktop

Power BI può riconoscere automaticamente alcuni collegamenti osservando nomi e valori delle colonne, ma non considero l’automatismo una verifica del modello. Prima di accettare una relazione controllo sempre chiavi, tipi di dati e unicità.

1. Apri la vista Modello e identifica la dimensione e la tabella dei fatti.
2. Verifica che le colonne abbiano lo stesso tipo, ad esempio testo con testo o numero intero con numero intero.
3. Controlla che la chiave sul lato “uno” non contenga duplicati.
4. Crea o modifica la relazione da Gestisci relazioni.
5. Imposta la cardinalità corretta e preferisci il filtro a senso unico salvo necessità documentate.
6. Lascia la relazione attiva quando deve guidare normalmente i filtri del report.
7. Testa il risultato con una tabella che mostri dimensione, conteggio delle righe e misura principale.

Un problema frequente nasce dalle date. Una colonna con data e ora può non corrispondere correttamente a una colonna che contiene soltanto la data. In questi casi creo una colonna data coerente in Power Query o nella sorgente, invece di affidarmi a trasformazioni improvvisate dentro le misure.

Controllo anche le righe senza corrispondenza. Un codice prodotto presente in FactVendite ma assente da DimProdotto può produrre una voce vuota nei filtri e valori classificati come BLANK. Non è sempre un errore di Power BI: spesso segnala un problema reale di qualità o sincronizzazione dei dati.

La documentazione di Microsoft Learn ricorda che almeno un lato della relazione deve offrire un elenco distinto di chiavi nei casi in cui si vuole una relazione uno-a-molti. Se la sorgente non lo garantisce, una tabella ponte con valori distinti è spesso più sicura della semplice rimozione delle righe duplicate.

RELATED e le funzioni DAX che usano le relazioni

La funzione RELATED recupera un valore dalla tabella collegata sul lato “uno”. È particolarmente utile in una colonna calcolata della tabella dei fatti, dove esiste un contesto di riga preciso.

Categoria prodotto =
RELATED(DimProdotto[Categoria])

Con questa formula ogni riga di FactVendite riceve la categoria del prodotto associato. La relazione deve esistere e il codice usato nel collegamento deve permettere di individuare un solo valore. Se la relazione manca, è inattiva o è ambigua, RELATED non può risolvere il problema da sola.

RELATED non sostituisce una misura

Uno degli errori che incontro più spesso è usare RELATED come se fosse una misura aggregata. La funzione lavora bene quando DAX sa qual è la riga corrente, mentre una misura viene valutata in un contesto di filtro che può contenere molte righe. Per una misura è spesso più corretto usare una funzione come CALCULATE, oppure progettare il modello in modo che la dimensione filtri direttamente la tabella dei fatti.

Per leggere dati dal lato “molti” esiste RELATEDTABLE. Per esempio, in una colonna calcolata della tabella clienti si può contare il numero di vendite collegate:

Numero vendite =
COUNTROWS(RELATEDTABLE(FactVendite))

Questa soluzione è leggibile, ma non sempre è la più efficiente per grandi volumi. Per analisi dinamiche preferisco quasi sempre una misura, perché il calcolo viene eseguito in base ai filtri applicati nel report e non memorizzato riga per riga nel modello.

USERELATIONSHIP per date diverse

Supponiamo che la relazione attiva usi la data dell’ordine e quella inattiva la data della spedizione. La misura può richiamare il secondo percorso così:

Ordini spediti =
CALCULATE(
    COUNTROWS(FactVendite),
    USERELATIONSHIP(
        DimData[Data],
        FactVendite[DataSpedizione]
    )
)

USERELATIONSHIP modifica il comportamento soltanto durante il calcolo della misura. È una scelta elegante quando il report non deve filtrare contemporaneamente gli stessi dati usando due ruoli della data. Se invece gli utenti devono confrontare ordine e spedizione nello stesso momento, due copie della dimensione calendario, come DimDataOrdine e DimDataSpedizione, rendono l’esperienza più chiara.

Leggi anche: Power BI API e DAX per integrare dati, report e automazioni

CROSSFILTER e TREATAS nei casi avanzati

CROSSFILTER permette di modificare la direzione o disattivare una relazione dentro una specifica espressione. Lo uso con prudenza, perché può nascondere un difetto strutturale se diventa necessario in molte misure.

TREATAS, invece, applica i valori di una tabella espressione a colonne di una tabella non collegata. È utile per costruire una relazione virtuale, ma non dovrebbe diventare il modo normale per collegare dimensioni e fatti. Quando il collegamento è stabile e frequente, una relazione fisica è quasi sempre più trasparente.

Quando i numeri non tornano e come trovare la causa

Un totale ripetuto su ogni riga, un filtro che non produce effetto o una categoria vuota indicano spesso un problema di relazione. Inizio la diagnosi con una visualizzazione tabella, non con formule DAX sempre più complesse. Mi serve vedere la chiave, il valore descrittivo, il conteggio delle righe e l’importo nello stesso punto.

• Duplicati sul lato uno indicano che la tabella dimensionale non è davvero una dimensione.
• Chiavi mancanti producono righe senza categoria, cliente o prodotto associato.
• Tipi di dati diversi, come testo contro numero, impediscono corrispondenze affidabili.
• Spazi e formati incoerenti fanno sembrare uguali valori che per Power BI sono diversi.
• Relazioni inattive non propagano filtri finché una misura non le attiva.
• Molti-a-molti non controllati possono duplicare o alterare le aggregazioni.

La relazione molti-a-molti merita particolare cautela. Se clienti e account condividono più codici o se un prodotto appartiene a più categorie, collegare direttamente le due tabelle può produrre risultati ambigui. Una tabella ponte con chiavi distinte e relazioni uno-a-molti rende il percorso dei filtri più leggibile.

Controllo anche i percorsi multipli. Se un filtro può arrivare alla stessa tabella passando da due strade diverse, Power BI può bloccare la configurazione bidirezionale oppure restituire un comportamento non intuitivo. In questi casi disattivo una relazione, separo una dimensione con una copia dedicata o gestisco il caso con USERELATIONSHIP e misure esplicite.

Per modelli pubblicati, la funzione DAX INFO.RELATIONSHIPS può aiutare a ispezionare metadati come stato attivo, cardinalità e direzione del filtro. La considero uno strumento di controllo e documentazione, non una scorciatoia per evitare di comprendere il diagramma.

Un criterio pratico per progettare modelli che durano

Prima di aggiungere una nuova relazione, mi chiedo quale domanda analitica deve rendere possibile. Se la risposta è soltanto “perché così il filtro funziona”, probabilmente manca una dimensione ben definita o la tabella dei fatti non è stata preparata correttamente.

Per un modello vendite partirei da una struttura essenziale con DimData, DimProdotto, DimCliente e FactVendite. Le dimensioni filtrano la tabella dei fatti, le misure aggregano importi e quantità, mentre le colonne calcolate vengono usate soltanto quando aggiungono davvero valore al modello.

In pratica, preferisco un modello con poche relazioni ben motivate a uno schema pieno di collegamenti “di sicurezza”. La semplicità non è solo una qualità estetica: riduce il tempo necessario per spiegare una misura, facilita la gestione della sicurezza a livello di riga e rende più affidabili le evoluzioni future del report.

La verifica finale che evita la maggior parte degli errori

Prima di consegnare un report controllo quattro cose. Ogni dimensione deve avere una chiave coerente, i filtri devono seguire percorsi comprensibili, le misure devono usare la relazione corretta e le righe senza corrispondenza devono essere spiegate.

Se una relazione appare necessaria per far funzionare una singola visualizzazione, la testo in un modello ridotto con pochi record e confronto il risultato con un calcolo indipendente. Questo piccolo controllo spesso rivela duplicazioni invisibili, date non allineate o filtri bidirezionali inseriti troppo presto.

La qualità del modello viene prima della formula. Quando la struttura è chiara, DAX diventa più breve, le relazioni risultano prevedibili e anche chi userà il report dopo di me potrà modificarlo senza dover ricostruire ogni passaggio da zero.