Applicare relazioni molti-a-molti in Power BI Desktop

Con le relazioni con cardinalità molti-a-molti in Power BI Desktop, è possibile unire tabelle che usano una cardinalità molti-a-molti. È possibile creare modelli di dati più facilmente e intuitivi che contengono due o più origini dati. Le relazioni con cardinalità molti-a-molti fanno parte delle funzionalità dei modelli compositi più grandi in Power BI Desktop. Per altre informazioni sui modelli compositi, vedere Usare modelli compositi in Power BI Desktop

Che relazione con una cardinalità molti-a-molti risolve

Prima che le relazioni con cardinalità molti-a-molti siano diventate disponibili, la relazione tra due tabelle è stata definita in Power BI. Almeno una delle colonne di tabella coinvolte nella relazione doveva contenere valori univoci. Spesso, tuttavia, nessuna colonna contiene valori univoci.

Ad esempio, due tabelle potrebbero avere una colonna denominata CountryRegion. Tuttavia, i valori di CountryRegion non sono univoci in nessuna delle due tabelle. Per unire tali tabelle, è necessario creare una soluzione alternativa. Una soluzione alternativa potrebbe consistere nell'introdurre tabelle aggiuntive con i valori univoci necessari. Con le relazioni con cardinalità molti-a-molti, è possibile unire direttamente tali tabelle, se si usa una relazione con cardinalità molti-a-molti.

Usare relazioni con cardinalità molti-a-molti

Quando si definisce una relazione tra due tabelle in Power BI, è necessario definire la cardinalità della relazione. Ad esempio, la relazione tra ProductSales e Product, usando le colonne ProductSales[ProductCode] e Product[ProductCode], verrebbe definita come Many-1. La relazione viene definita in questo modo, perché ogni prodotto ha molte vendite e la colonna nella tabella Product (ProductCode) è univoca. Quando si definisce una cardinalità di relazione come Molti-1, 1-Molti o 1-1, Power BI la convalida, in modo che la cardinalità selezionata corrisponda ai dati effettivi.

Ad esempio, esaminare il modello semplice in questa immagine:

Si supponga ora che la tabella Product visualizzi solo due righe, come illustrato di seguito:

Si supponga anche che la tabella Sales contenga solo quattro righe, inclusa una riga per un prodotto C. A causa di un errore di integrità referenziale, la riga C del prodotto non esiste nella tabella Product .

ProductName e Price (dalla tabella Product), insieme alla Qty totale per ogni prodotto (dalla tabella ProductSales), verranno visualizzati come illustrato:

Come si può notare nell'immagine precedente, una riga ProductName vuota è associata alle vendite per il prodotto C. Questa riga vuota tiene conto delle considerazioni seguenti:

• Tutte le righe della tabella ProductSales per le quali non esiste alcuna riga corrispondente nella tabella Product . Esiste un problema di integrità referenziale, come illustrato per il prodotto C in questo esempio.

• Qualsiasi riga nella tabella ProductSales per cui la colonna chiave esterna è Null.

Per questi motivi, la riga vuota in entrambi i casi rappresenta le vendite in cui ProductName e Price sono sconosciuti.

In alcuni casi le tabelle sono unite in join da due colonne, ma nessuna delle due colonne è univoca. Si considerino ad esempio queste due tabelle:

• Nella tabella Sales vengono visualizzati i dati sulle vendite per Stato e ogni riga contiene l'importo delle vendite per il tipo di vendita in tale stato. Gli stati includono CA, WA e TX.

  

• La tabella CityData visualizza i dati sulle città, tra cui popolazione e stato (ad esempio CA, WA e New York).

  

Una colonna per State è ora presente in entrambe le tabelle. È ragionevole segnalare sia le vendite totali per stato che la popolazione totale di ogni stato. Esiste tuttavia un problema: la colonna State non è univoca in nessuna delle due tabelle.

Soluzione alternativa precedente

Prima della versione di luglio 2018 di Power BI Desktop, non è stato possibile creare una relazione diretta tra queste tabelle. Una soluzione alternativa comune consiste nel:

• Creare una terza tabella contenente solo gli ID di stato univoci. La tabella può essere qualsiasi o tutto:

  • Tabella calcolata (definita tramite Data Analysis Expressions [DAX]).
  • Tabella basata su una query definita in editor di Power Query, che potrebbe visualizzare gli ID univoci disegnati da una delle tabelle.
  • Set completo combinato.

• Correlare quindi le due tabelle originali alla nuova tabella usando relazioni Molti-1 comuni.

È possibile lasciare visibile la tabella delle soluzioni alternative. In alternativa, è possibile nascondere la tabella delle soluzioni alternative, in modo che non venga visualizzata nell'elenco Campi . Se si nasconde la tabella, le relazioni Molti-1 vengono in genere impostate per filtrare in entrambe le direzioni e è possibile usare il campo Stato da una delle due tabelle. Quest'ultimo filtro incrociato viene propagato all'altra tabella. Questo approccio è illustrato nell'immagine seguente:

Un oggetto visivo che visualizza State (dalla tabella CityData), insieme al totale Population e total Sales, viene quindi visualizzato come segue:

Nota

Poiché lo stato della tabella CityData viene usato in questa soluzione alternativa, vengono elencati solo gli stati in tale tabella, quindi TX viene escluso. Inoltre, a differenza delle relazioni Molti-1 , mentre la riga totale include tutte le vendite (incluse quelle di TX), i dettagli non includono una riga vuota che copre tali righe non corrispondenti. Analogamente, nessuna riga vuota coprirà Sales per cui è presente un valore Null per state.

Si supponga di aggiungere anche City a tale oggetto visivo. Anche se la popolazione per città è nota, le vendite visualizzate per City ripetono semplicemente le vendite per lo stato corrispondente. Questo scenario si verifica normalmente quando il raggruppamento di colonne non è correlato ad alcune misure di aggregazione, come illustrato di seguito:

Si supponga di definire la nuova tabella Sales come combinazione di tutti gli Stati qui e renderla visibile nell'elenco Campi . Lo stesso oggetto visivo visualizzerà State (nella nuova tabella), il totale Population e il totale Sales:

Come si può notare, TX, con dati Sales ma dati popolamenti sconosciuti e New York, con dati popolamenti noti ma senza dati sales, verrebbero inclusi. Questa soluzione alternativa non è ottimale e presenta molti problemi. Per le relazioni con cardinalità molti-a-molti, i problemi risultanti vengono risolti, come descritto nella sezione successiva.

Per altre informazioni sull'implementazione di questa soluzione alternativa, vedere Linee guida per le relazioni molti-a-molti.

Usare una relazione con una cardinalità molti-a-molti anziché la soluzione alternativa

È possibile correlare direttamente le tabelle, ad esempio quelle descritte in precedenza, senza dover ricorrere a soluzioni alternative simili. È ora possibile impostare la cardinalità della relazione su molti-a-molti. Questa impostazione indica che nessuna delle tabelle contiene valori univoci. Per tali relazioni, è comunque possibile controllare la tabella che filtra l'altra tabella. In alternativa, è possibile applicare filtri bidirezionali, in cui ogni tabella filtra l'altra.

In Power BI Desktop, per impostazione predefinita la cardinalità è molti-a-molti quando determina che nessuna delle due tabelle contiene valori univoci per le colonne della relazione. In questi casi, un messaggio di avviso conferma che si vuole impostare una relazione e che la modifica non è l'effetto imprevisto di un problema di dati.

Ad esempio, quando si crea una relazione direttamente tra CityData e Sales, in cui i filtri devono passare da CityData a Sales, Power BI Desktop visualizza la finestra di dialogo Modifica relazione :

La visualizzazione Relazione risultante visualizza quindi la relazione diretta molti-a-molti tra le due tabelle. L'aspetto delle tabelle nell'elenco Campi e il relativo comportamento successivo quando vengono creati gli oggetti visivi sono simili a quando è stata applicata la soluzione alternativa. Nella soluzione alternativa, la tabella aggiuntiva che visualizza i dati distinct State non è resa visibile. Come descritto in precedenza, verrà visualizzato un oggetto visivo che mostra i dati Di stato, Popolamento e Vendite :

Le principali differenze tra le relazioni con una cardinalità molti-a-molti e le relazioni molti-1 più tipiche sono le seguenti:

• I valori visualizzati non includono una riga vuota che indica le righe non corrispondenti nell'altra tabella. Inoltre, i valori non usano l'account per le righe in cui la colonna usata nella relazione nell'altra tabella è Null.

• Non è possibile usare la RELATED() funzione perché è possibile corredare più righe.

• L'uso della ALL() funzione in una tabella non rimuove i filtri applicati ad altre tabelle correlate da una relazione molti-a-molti. Nell'esempio precedente, una misura definita come illustrato di seguito non rimuove i filtri per le colonne nella tabella CityData correlata:

  

  Un oggetto visivo che mostra i dati relativi allo stato, alle vendite e al totale delle vendite genera questo grafico:

  

Tenendo presenti le differenze precedenti, assicurarsi che i calcoli che usano ALL(<Table>), ad esempio % del totale complessivo, restituiscano i risultati previsti.

Considerazioni e limitazioni

Esistono alcune limitazioni per questa versione delle relazioni con cardinalità molti-a-molti e modelli compositi.

Le origini live Connessione (multidimensionali) seguenti non possono essere usate con i modelli compositi:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services
• Modelli semantici di Power BI
• Azure Analysis Services

Quando ci si connette a queste origini multidimensionali usando DirectQuery, non è possibile connettersi a un'altra origine DirectQuery o combinarla con i dati importati.

Le limitazioni esistenti dell'uso di DirectQuery si applicano ancora quando si usano relazioni con cardinalità molti-a-molti. Molte limitazioni sono ora per tabella, a seconda della modalità di archiviazione della tabella. Ad esempio, una colonna calcolata in una tabella importata può fare riferimento ad altre tabelle, ma una colonna calcolata in una tabella DirectQuery può comunque fare riferimento solo alle colonne della stessa tabella. Altre limitazioni si applicano all'intero modello se le tabelle all'interno del modello sono DirectQuery. Ad esempio, le funzionalità QuickInsights e Q&A non sono disponibili in un modello se una tabella all'interno ha una modalità di archiviazione di DirectQuery.

Contenuto correlato

Per altre informazioni sui modelli compositi e DirectQuery, vedere gli articoli seguenti:

• Usare i modelli compositi in Power BI Desktop
• Gestire la modalità di archiviazione in Power BI Desktop
• DirectQuery in Power BI
• Origini dati di Power BI