Linee guida sulle relazioni attive e inattive
Questo articolo è destinato a un modello di dati che usa 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 star. Per altre informazioni, vedere Informazioni sullo schema star e sull'importanza di 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 progettato per analizzare le prestazioni dei voli in tempo reale (OTP). Il modello ha una tabella Flight , ovvero una tabella di tipo fact che archivia una riga per ogni anteprima. 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). C'è anche una tabella Airport , che è una tabella di tipo dimensione che archivia una riga per 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.
Esistono due relazioni tra i modelli tra le tabelle Flight e Airport . Nella tabella Flight le colonne DepartureAirport e ArrivalAirport sono correlate alla colonna Airport della tabella Airport. Nella struttura dello schema star la tabella Airport viene descritta come dimensione con ruoli. In questo modello i due ruoli sono l'aeroporto di partenza e l'aeroporto di arrivo.
Sebbene questa progettazione funzioni bene per le progettazioni di schemi star relazionali, non per i modelli di Power BI. Poiché le relazioni tra modelli sono percorsi per la propagazione dei filtri e questi percorsi devono essere deterministici. Per altre informazioni su come assicurarsi che i percorsi di propagazione dei filtri siano deterministici, vedere Risolvere l'ambiguità del percorso della relazione. Pertanto, come descritto in questo esempio, una relazione è attiva mentre l'altra è inattiva (rappresentata dalla linea tratteggiata). In particolare, è la relazione con la colonna ArrivalAirport attiva. Ciò 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 aeroporto per isolare automaticamente i dettagli dei voli per un aeroporto di partenza. Poiché i requisiti di segnalazione comportano il filtraggio (o il raggruppamento) in base agli aeroporti di partenza e 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.
Il modello dispone ora di due tabelle aeroportuali: Aeroporto di partenza e Aeroporto di arrivo. Le relazioni del modello tra queste tabelle e la tabella Flight sono attive. Si noti anche che i nomi delle colonne nelle tabelle Aeroporto di partenza e Aeroporto di arrivo sono preceduti dalla parola Partenza o Arrivo.
La progettazione del modello migliorata supporta la produzione della progettazione di report seguente.
La pagina del report filtra Melbourne come aeroporto di partenza e i gruppi visivi tabella in base agli aeroporti di arrivo.
Nota
Per i modelli di importazione, la tabella aggiuntiva ha comportato un aumento delle dimensioni del modello e tempi di aggiornamento più lunghi. Di conseguenza, contraddice le raccomandazioni descritte nell'articolo Tecniche di riduzione dei dati per l'importazione della modellazione . Tuttavia, nell'esempio, il requisito di avere solo relazioni attive sostituisce queste raccomandazioni.
Inoltre, è comune che le tabelle di tipo dimensione contengano conteggi di righe bassi rispetto ai conteggi delle righe delle tabelle di tipo fatto. 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 tipo dimensione con ruolo, a una progettazione con una tabella per ruolo.
Rimuovere eventuali relazioni inattive.
Prendere in considerazione la ridenominazione della tabella di tipo dimensione con ruolo per descriverne meglio il ruolo. Nell'esempio la tabella Airport è correlata alla colonna ArrivalAirport della tabella Flight , quindi viene rinominata come Aeroporto di arrivo.
Creare una copia della tabella con ruoli, fornendo un nome che ne rifletta il ruolo. Se si tratta di una tabella Import, è consigliabile definire 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'Creare una relazione attiva per correlare la nuova tabella.
Prendere in considerazione la ridenominazione delle colonne nelle tabelle in modo che riflettano in modo accurato il proprio ruolo. Nell'esempio tutte le colonne sono precedute dalla parola Partenza o Arrivo. Questi nomi assicurano che gli oggetti visivi del report, per impostazione predefinita, abbiano etichette autodescritture e non ambigue. Migliora anche l'esperienza di domande e risposte, consentendo agli utenti di scrivere facilmente le proprie domande.
Prendere in considerazione l'aggiunta di descrizioni alle tabelle con ruoli. (In Riquadro Campi , una descrizione viene visualizzata in una descrizione comando quando un autore del report passa il cursore sulla tabella. In questo modo, è possibile comunicare eventuali dettagli aggiuntivi sulla propagazione dei filtri agli autori di report.
Relazioni inattive
In circostanze specifiche, le relazioni inattive possono soddisfare esigenze di creazione di report speciali.
Si considerino ora 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 della 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 BLANK (fino a quando l'ordine non viene spedito)
- Non è necessario filtrare simultaneamente (o raggruppare per) l'ordine e i periodi di data di spedizione
Di seguito è riportato un diagramma di modello parziale delle due tabelle.
Esistono due relazioni di 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 attiva.
Tutte le sei misure, ad eccezione di una, devono essere filtrate in base alla colonna OrderDate . La misura Orders Shipped , tuttavia, deve filtrare in base alla colonna ShipDate .
Ecco la definizione della misura Orders . Conta semplicemente le righe della tabella Sales all'interno del contesto di filtro. Tutti i filtri applicati alla tabella Date verranno propagati alla colonna OrderDate .
Orders = COUNTROWS(Sales)
Ecco la definizione della misura Orders Shipped . Usa la funzione DAX U edizione Standard RELATIONSHIP, che attiva la propagazione dei filtri per una relazione specifica 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 produzione della progettazione di report seguente.
La pagina del report filtra per trimestre 2019 Q4. L'oggetto visivo tabella raggruppa per mese e visualizza varie statistiche di vendita. Le misure Orders e Orders Shipped producono risultati diversi. Ognuno usa la stessa logica di riepilogo (conteggio delle righe della tabella Sales), ma la propagazione del filtro di tabella Date diversa.
Si noti che il filtro dei dati quarter include un elemento BLANK. Questo elemento del filtro dei dati viene visualizzato come risultato dell'espansione della tabella. Mentre ogni riga della tabella Sales ha una data di ordine, alcune righe hanno una data di spedizione VUOTA, questi ordini devono ancora essere spediti. L'espansione delle tabelle considera anche le relazioni inattive e pertanto le BLANK possono apparire a causa di BLANK sul lato molti 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 di sicurezza a livello di riga non verranno propagati per le relazioni inattive anche se UseRelationship viene aggiunto in modo esplicito a una definizione di misura.
Consigli
In sintesi, è consigliabile definire relazioni attive quando possibile, soprattutto quando vengono definiti 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 nel modello devono essere duplicate le tabelle con tipo di dimensione con ruolo.
In circostanze specifiche, tuttavia, è possibile definire una o più relazioni inattive per una tabella di tipo dimensione con ruoli. È possibile considerare questa progettazione quando:
- Non è necessario che gli oggetti visivi del report filtrino simultaneamente in base a ruoli diversi
- Usare la funzione DAX U edizione Standard RELATIONSHIP per attivare una relazione specifica per i calcoli del modello pertinenti
Contenuto correlato
Per altre informazioni relative a questo articolo, vedere le risorse seguenti:
Commenti e suggerimenti
In arrivo: Nel corso del 2024 verranno ritirati i problemi di GitHub come meccanismo di feedback per il contenuto e verranno sostituiti con un nuovo sistema di feedback. Per altre informazioni, vedi: https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per