Condividi tramite

Linee guida sulle relazioni attive e inattive

  • Articolo

Questo articolo è destinato a un modellatore di dati che lavora con Power BI Desktop. Fornisce indicazioni su quando creare relazioni tra modelli attivi o inattivi. Per impostazione predefinita, le relazioni attive propagano i filtri ad altre tabelle. La relazione inattiva, tuttavia, propaga i filtri solo quando un'espressione DAX attiva (usa) la relazione.

Nota

Un'introduzione alle relazioni tra modelli non è descritta in questo articolo. Se non si ha familiarità con le relazioni, le relative proprietà o come configurarle, è consigliabile leggere prima l'articolo relazioni tra modelli in Power BI Desktop.

È anche importante avere una conoscenza della progettazione dello schema stella. Per altre informazioni, vedere Informazioni sullo schema star e sull'importanza per Power BI.

Relazioni attive

In genere, è consigliabile definire relazioni attive quando possibile. Ampliano l'ambito e il potenziale del modo in cui il modello può essere usato dagli autori di report e dagli utenti che lavorano con Q&A.

Si consideri un esempio di modello di importazione dati progettato per analizzare la puntualità dei voli aerei (OTP). Il modello ha una tabella Flight, ovvero una tabella dei fatti che archivia una riga per ogni volo. Ogni riga registra la data del volo, il numero di volo, gli aeroporti di partenza e di arrivo e qualsiasi tempo di ritardo (in minuti). Esiste anche una tabella Airport, cioè una tabella dimensionale che memorizza una riga per ogni aeroporto. Ogni riga descrive il codice dell'aeroporto, il nome dell'aeroporto e il paese o l'area geografica.

Di seguito è riportato un diagramma di modello parziale delle due tabelle.

Diagramma che mostra un modello contenente due tabelle: Flight e Airport. La progettazione delle relazioni è descritta nel paragrafo seguente.

Esistono due relazioni del modello tra le tabelle Flight e Airport. Nella tabella Flight le colonne DepartureAirport e ArrivalAirport sono correlate alla colonna Airport della tabella Airport. Nella progettazione dello schema a stella, la tabella Airport viene descritta come una dimensione ruolo . In questo modello, i due ruoli sono aeroporto di partenza e aeroporto di arrivo.

Sebbene questa progettazione funzioni bene per le progettazioni di schemi star relazionali, non funziona bene per i modelli di Power BI. Ciò è dovuto al fatto che le relazioni tra modelli sono percorsi per la propagazione dei filtri e questi percorsi devono essere deterministici. Per ulteriori informazioni su come garantire che i percorsi di propagazione dei filtri siano deterministici, vedere risolvere l'ambiguità del percorso della relazione. Pertanto, come mostrato in questo esempio, una relazione è attiva mentre l'altra è inattiva (rappresentata dalla linea tratteggiata). In particolare, si tratta della relazione con la colonna ArrivalAirport attiva, il che significa che i filtri applicati alla tabella Airport vengono propagati automaticamente alla colonna ArrivalAirport della tabella Flight.

Questa progettazione di modelli impone limitazioni severe sul modo in cui è possibile segnalare i dati. In particolare, non è possibile filtrare la tabella Airport per isolare automaticamente i dettagli dei voli per un aeroporto di partenza. Poiché i report devono filtrare (o raggruppare) in base agli aeroporti di partenza e di arrivo contemporaneamente, sono necessarie due relazioni attive. La conversione di questo requisito in una progettazione di modelli di Power BI significa che il modello deve avere due tabelle aeroportuali.

Ecco la progettazione del modello migliorata.

Diagramma che mostra un modello contenente quattro tabelle: Date, Flight, Departure Airport e Arrival Airport.

Il modello include ora due tabelle aeroportuali: Departure Airport e Arrival Airport. Ogni relazione di modello tra queste tabelle e la tabella Flight è attiva. Si noti anche che i nomi delle colonne nelle tabelle Departure Airport e Arrival Airport sono preceduti dalla parola Partenza o Arrivo.

Il modello migliorato supporta la creazione del seguente rapporto progettuale.

Diagramma che mostra una pagina del report che include due filtri e una visualizzazione tabella. I filtri sono Mese e Aeroporto di partenza.

La pagina del report filtra in base a Melbourne come aeroporto di partenza e la visualizzazione della tabella raggruppa in base agli aeroporti di arrivo.

Nota

Per i modelli di importazione, l'aggiunta di un'altra tabella delle dimensioni ha comportato un aumento delle dimensioni del modello e tempi di aggiornamento più lunghi. Di conseguenza, è in contrasto con le raccomandazioni descritte nell'articolo Tecniche di riduzione dei dati per la modellazione dell'importazione. Tuttavia, nell'esempio, il requisito di avere solo relazioni attive sostituisce queste raccomandazioni.

Inoltre, è comune che le tabelle delle dimensioni memorizzino conteggi di righe bassi rispetto ai conteggi delle righe delle tabelle dei fatti. Pertanto, è probabile che le dimensioni del modello e i tempi di aggiornamento maggiori non siano eccessivamente grandi.

Metodologia di refactoring

Ecco una metodologia per effettuare il refactoring di un modello da una singola tabella di dimensioni per un ruolo a un design con una tabella per ruolo.

  1. Rimuovere eventuali relazioni inattive.

  2. Prendere in considerazione di rinominare la tabella dimensioni di gioco di ruolo per descriverne meglio il ruolo. Nell'esempio riportato in questo articolo, la tabella Airport è correlata alla colonna ArrivalAirport della tabella Flight, quindi viene rinominata come Arrival Airport.

  3. Creare una copia della tabella con ruoli, fornendo un nome che ne rifletta il ruolo. Se si tratta di una tabella Import, è consigliabile creare una tabella calcolata. Se si tratta di una tabella DirectQuery, è possibile duplicare la query di Power Query.

    Nell'esempio la tabella Departure Airport è stata creata usando la definizione di tabella calcolata seguente.

    Departure Airport = 'Arrival Airport'

  4. Creare una relazione attiva per correlare la nuova tabella.

  5. Prendere in considerazione la ridenominazione delle colonne nelle tabelle in modo che riflettano in modo accurato il proprio ruolo. Nell'esempio riportato in questo articolo tutte le colonne sono precedute dalla parola Departure o Arrival. Questi nomi assicurano che, per impostazione predefinita, gli oggetti visivi del report abbiano etichette autodescrittive e non ambigue. Migliora anche l'esperienza Q&A, consentendo agli utenti di scrivere facilmente domande accurate.

  6. Prendere in considerazione l'aggiunta di descrizioni alle tabelle di gioco di ruolo. (In riquadro dati, viene visualizzata una descrizione in un suggerimento quando un autore di report passa il cursore sulla tabella.) In questo modo, è possibile comunicare altri dettagli sulla propagazione dei filtri agli autori di report.

Relazioni inattive

In circostanze specifiche, le relazioni inattive possono soddisfare particolari esigenze di reportistica.

Prendere in considerazione requisiti diversi per il modello e la creazione di report:

  • Un modello di vendita contiene una tabella Sales con due colonne di data: OrderDate e ShipDate.
  • Ogni riga nella tabella Sales registra un singolo ordine.
  • I filtri data vengono quasi sempre applicati alla colonna OrderDate, che archivia sempre una data valida.
  • Una sola misura richiede la propagazione del filtro data nella colonna ShipDate, che può contenere valori nulli (fino alla spedizione dell'ordine).
  • Non è necessario filtrare contemporaneamente (o raggruppare) i periodi di data di spedizione degli ordini e.

Di seguito è riportato un diagramma di modello parziale delle due tabelle.

Diagramma che mostra un modello contenente due tabelle: Sales e Date. La tabella Sales include sei misure.

Esistono due relazioni del modello tra le tabelle Sales e Date. Nella tabella Sales le colonne OrderDate e ShipDate sono correlate alla colonna Date della tabella Date. In questo modello i due ruoli per la tabella Date sono data di ordine e data di spedizione. La relazione con la colonna OrderDate è quella attiva.

Tutte le sei misure, ad eccezione di una, devono essere filtrate in base alla colonna OrderDate. La misura Orders Shipped deve tuttavia filtrare in base alla colonna ShipDate.

Ecco la definizione di misura Orders. Conta semplicemente le righe della tabella Sales all'interno del contesto di filtro. Tutti i filtri applicati alla tabella Date vengono propagati alla colonna OrderDate.

Orders = COUNTROWS(Sales)

Ecco la definizione di misura Orders Shipped. Usa la funzione DAX USERELATIONSHIP, che attiva la propagazione del filtro per una relazione specifica, ma solo durante la valutazione dell'espressione. In questo esempio viene utilizzata la relazione con la colonna ShipDate.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Questa progettazione del modello supporta la progettazione del seguente report.

Diagramma che mostra una pagina del report con un filtro del report e un elemento visivo tabellare. Il filtro del report è Trimestre e l'elemento visivo tabellare elenca le statistiche sulle vendite mensili.

La pagina del rapporto filtra per trimestre 2019 Q4. La visualizzazione della tabella raggruppa per mese e mostra varie statistiche di vendita. Le misure Orders e Orders Shipped producono risultati diversi. Ciascuno utilizza la stessa logica di riepilogo (conteggio delle righe della tabella Sales), ma diversa propagazione dei filtri della tabella Date.

Si noti che il filtro dei dati quarter include un'opzione BLANK. Questa opzione del slicer viene visualizzata in seguito all'espansione della tabella . Mentre ogni riga della tabella Sales ha una data di ordine valida, alcune righe hanno una data di spedizione VUOTA. Questi ordini sono ancora da spedire. L'espansione delle tabelle considera anche le relazioni inattive e pertanto i BLANK possono apparire a causa di BLANK nella parte con molti elementi della relazione (o a causa di problemi di integrità dei dati).

Nota

I filtri di sicurezza a livello di riga vengono propagati solo tramite relazioni attive. I filtri RLS non vengono mai propagati per relazioni inattive, anche quando la funzione DAX USERELATIONSHIP viene usata da una definizione di misura.

Consigli

Consigliamo di definire relazioni attive ogni volta che è possibile, soprattutto quando vengono definiti i ruoli di sicurezza a livello di riga per il modello di dati. Ampliano l'ambito e il potenziale del modo in cui il modello può essere usato dagli autori di report e dagli utenti che lavorano con Q&A. Ciò significa che le tabelle delle dimensioni con ruolo variabile devono essere duplicate nel tuo modello.

In circostanze specifiche, tuttavia, è possibile definire una o più relazioni inattive per una tabella di dimensioni con ruoli interpretativi. È possibile considerare questo approccio quando:

  • Non è necessario che gli oggetti visivi del report filtrino simultaneamente in base a ruoli diversi.
  • Utilizzare la funzione DAX USERELATIONSHIP per attivare una relazione specifica per i pertinenti calcoli del modello.

Contenuto correlato

Per altre informazioni relative a questo articolo, vedere le risorse seguenti: