Power BI e le Relazioni Ambigue

Potrebbe interessarti:

Se vuoi imparare a preparare, modellare, visualizzare e analizzare i dati aziendali in modo efficace, dai un’occhiata al corso Introduzione a Power BI, e al Corso Avanzato Power BI DAX.

Dimmi di Più

Cos’è una Relazione Ambigua

In Power BI si parla di relazione ambigua (ambiguous relationship) quando, tra due tabelle del modello, esistono più percorsi possibili attraverso cui un filtro può propagarsi. In questa situazione il motore non riesce a stabilire un unico percorso di propagazione, perché la logica del modello consente più strade alternative. Per evitare tali ambiguità, Power BI è progettato per:

  • lavorare con modelli aciclici (senza cicli tra le relazioni) e
  • con percorsi di filtro chiari e ben definiti.

In altre parole, la piattaforma si aspetta che ogni filtro abbia una direzione di propagazione univoca e prevedibile, così da garantire calcoli coerenti e risultati deterministici.

Un ciclo si verifica quando, partendo da una tabella del modello, è possibile seguire una serie di relazioni e ritornare alla tabella di partenza. In altre parole, si crea un percorso chiuso tra le tabelle. Un esempio semplice potrebbe essere:

A → B → C → A

Un modello aciclico invece (formalmente definito come DAG – Directed Acyclic Graph) è un modello in cui le relazioni tra le tabelle non formano mai un ciclo. Ciò significa che, partendo da una tabella, possiamo attraversare le relazioni verso altre tabelle, ma non potremo mai tornare alla tabella di origine:

A → B → C

Power BI è progettato per funzionare esclusivamente con modelli aciclici. Per questo motivo non consente la creazione di relazioni che chiudono un cerchio: se proviamo ad aggiungere una relazione che genera un ciclo, il sistema segnala un errore e impedisce l’operazione.

Quando un modello aciclico introduce due o più percorsi alternativi di propagazione del filtro (ad esempio, usando relazioni “Molti a Molti” bidirezionali dirette, o tramite “tabelle ponte”), la propagazione diventa ambigua. Power BI deve scegliere quale strada seguire, e lo fa applicando un criterio di priorità e peso. In pratica, privilegia i percorsi più “diretti” e meno ambigui, dando precedenza alle relazioni che collegano Fact Table con Dimension Table, e solo in seconda battuta considera percorsi più complessi o ridondanti.

Un Esempio di Relazione Ambigua

Nel seguente diagramma, la tabella Purchases può essere filtrata per Date esclusivamente tramite il percorso Date → Purchases:

Relazione tra tabella Date e Purchases non ambigua
Figura 1: Relazione ‘Date’ → ‘Purchases’ non ambigua

Che accade se cambiamo l’attributo “Cross filter direction” della relazione tra le tabelle Sales e Product in “Both” (entrambe le direzioni)?

Relazione tra tabella Date e Purchases ambigua
Figura 2: Relazione ‘Date’ → ‘Purchases’ ambigua

Con questa semplice modifica al modello, la Dimension Table Product diventa una tabella ponte per la Fact Table Purchases. Quindi Power BI e riconosce due percorsi di propagazione dei filtri (e non segnala alcun errore):

  1. Date → Purchases;
  2. Date → Sales → Product → Purchases.

In questo caso la scelta apparente è immediata: il percorso diretto (Date → Purchases) è il più breve e intuitivo. Tuttavia, al di là di questo esempio, rimane il fatto che esistono due percorsi alternativi attraverso cui un filtro può propagarsi. In alcuni scenari, una determinata espressione DAX può sfruttare entrambi i percorsi, generando risultati inattesi. Questo accade perché possono verificarsi due fenomeni problematici:

  • il filtro è potenzialmente duplicato:
    quando in un modello ci sono relazioni bidirezionali o percorsi multipli di propagazione, Power BI può applicare il filtro lungo entrambi i percorsi. Questo porta al rischio di duplicazione del filtro, e quindi di risultati inattesi (come ad esempio conteggi più bassi o più alti del previsto). Il risultato finale non è l’unione dei due filtri (OR logico), bensì l’intersezione (AND logico), che restringe eccessivamente il contesto di filtro. Quindi, un valore della tabella filtrata è mantenuto solo se soddisfa tutti i filtri provenienti dai diversi percorsi.

  • i calcoli non sono deterministici:
    in presenza di relazioni bidirezionali e percorsi multipli, l’intersezione dei filtri può cambiare a seconda del contesto del visual. Di conseguenza, una stessa misura può restituire valori differenti pur basandosi sugli stessi dati di origine. In altre parole, la combinazione di colonne, campi e relazioni inserita in un visual determina quali percorsi di propagazione dei filtri vengono attivati e, di riflesso, il risultato prodotto dalle misure.

Per questo motivo Microsoft consiglia di limitare le relazioni bidirezionali, mantenere uno Star Schema chiaro e unidirezionale, e usare DAX per gestire la direzione di filtro. Vediamo che accade usando la funzione Cross Filter per specificare il valore di “Cross Filter Direction” programmaticamente, tramite le seguenti misure:

// Standard Computation, use the model "as is"
Purchases =
    SUMX(
        Purchases,
        Purchases[Quantity] * Purchases[Unit Cost]
    )

// Compute Purchases considering only 'Date' -> 'Purchases' relationship.
Purchase NO Date-Sales =
    CALCULATE(
        [Purchases],
        // turn off the 'Date' -> 'Sales' relationship.
        // CROSSFILTER changes the cross-filter direction of a relationship
        // The arguments are the columns involved in the relationship and
        // the cross-filter direction, which can be BOTH, ONEWAY, NONE
        CROSSFILTER(
            'Date'[Date],
            Sales[Order Date],
            NONE
        )
    )

// Compute Purchases considering only 'Date' -> 'Sales' relationship
Purchase NO Date-Purchases =
    CALCULATE(
        [Purchases],
        // turn off the 'Date' -> 'Purchases' relationship
        CROSSFILTER(
            'Date'[Date],
            Purchases[Order Date],
            NONE
        )
    )

Se confrontiamo i calcoli usando un report con tre diverse tabelle (su ogni tabella applichiamo una misura specifica), possimo vedere tre risultati diversi:

Risultati differenti a seconda del percorso di propagazione dei filtri selezionato
Figura 3: Risultati differenti a seconda del percorso di propagazione dei filtri selezionato

In Conclusione

Se definiamo misure diverse, ciascuna delle quali isola intenzionalmente un ramo del modello tramite funzioni come CALCULATE, CROSSFILTER o USERELATIONSHIP, ognuna di esse applicherà consapevolmente una logica di filtro diversa. Di conseguenza, le misure possono produrre risultati diversi, senza che nessuna di queste sia “sbagliata”, perché ciascuna riflette un percorso di propagazione scelto intenzionalmente dal motore di Power BI. Quando esistono più percorsi possibili tra due tabelle, la domanda da porsi non è:

“Qual è il percorso corretto?”

ma piuttosto:

“Quale percorso voglio usare in questo calcolo?”

In definitiva, per prevenire qualunque forma di ambiguità nella propagazione dei filtri, è consigliabile evitare l’uso di relazioni bidirezionali all’interno del modello dati. Quando è necessario utilizzare un percorso alternativo, è preferibile ricorrere a misure che definiscano in modo esplicito quale percorso di propagazione dei filtri deve essere seguito per quell’elaborazione specifica. In questo modo il comportamento della misura diventa chiaro, controllato e completamente privo di ambiguità.

Riconoscimenti

Questo post ha usato il modello di esempio fornito dalla pagina Bidirectional relationships and ambiguity in DAX di Alberto Ferrari.

Inizio
Prossimo
Precedente