Applicare relazioni molti-a-molti in Power BI Desktop

  • Articolo

Con le relazioni con cardinalità molti-a-molti di Power BI Desktop è possibile unire le tabelle che usano la cardinalità molti-a-molti. Ciò consente di creare in modo più semplice e intuitivo modelli di dati che contengono due o più origini dati. Le relazioni con cardinalità molti-a-molti fanno parte delle funzionalità dei modelli compositi, più ampie, di Power BI Desktop. Per altre informazioni sui modelli compositi, vedere Usare modelli compositi in Power BI Desktop

Screenshot di una relazione molti-a-molti nel riquadro Modifica relazione.

Quali problemi permette di risolvere una relazione con cardinalità molti-a-molti

Prima che le relazioni con cardinalità molti-a-molti fossero disponibili, la relazione tra due tabelle era definita in Power BI. Almeno una delle colonne della tabella interessate dalla relazione doveva contenere valori univoci. Spesso, tuttavia, nessuna colonna conteneva valori univoci.

Ad esempio, due tabelle potevano includere una colonna CountryRegion. Tuttavia, i valori di CountryRegion non erano univoci nelle due tabelle. Per unire queste tabelle, era necessario escogitare una soluzione alternativa, che potevano consistere nell'introduzione di tabelle aggiuntive con i valori univoci necessari. Grazie alle relazioni con cardinalità molti-a-molti, è ora possibile unire direttamente le tabelle usando 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 specificare la cardinalità della relazione. Ad esempio, la relazione tra ProductSales e Product usando le colonne ProductSales[ProductCode] e Product [ProductCode] verrebbe definita come molti-a-uno. La relazione viene definita in questo modo perché per ogni prodotto sono presenti molti valori Sales e la colonna della tabella Product (ProductCode) è univoca. Quando si definisce una relazione con cardinalità molti-a-uno, uno-a-molti o uno-a-uno, Power BI la convalida per verificare che la cardinalità selezionata corrisponda effettivamente ai dati.

Esaminare ad esempio il modello semplice nell'immagine seguente:

Screenshot della tabella ProductSales e Product nella vista Relazione.

Ora, si supponga che la tabella Product contenga solo due righe, come illustrato:

Screenshot di un oggetto visivo tabella Product con due righe.

Si immagini anche che la tabella Sales includa solo quattro righe, con una riga per un prodotto C e che, a causa di un errore di integrità referenziale, il prodotto C non esiste nella tabella Product.

Screenshot di un oggetto visivo tabella Sales con quattro righe.

ProductName e Price, della tabella Product, insieme al valore totale di Qty per ogni prodotto, della tabella ProductSales, verrebbe visualizzato come segue:

Screenshot di un oggetto visivo che mostra il nome, il prezzo e la quantità del prodotto.

Come si vede nella figura precedente, una riga ProductName vuota è associata alle vendite per il prodotto C. Questa riga vuota porta alle considerazioni seguenti:

  • Tutte le righe della tabella ProductSales per le quali non esistono righe corrispondenti nella tabella Product. Si verifica un problema di integrità referenziale, come illustrato per il prodotto C in questo esempio.

  • Tutte le righe della tabella ProductSales per cui la colonna chiave esterna è Null.

Per questi motivi, in entrambi i casi, la riga vuota corrisponde alle vendite per cui sono sconosciuti i valori ProductName e Price.

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

  • La tabella Sales contiene dati di vendita per State, con ogni riga che contiene l'importo delle vendite per il tipo di vendita in tale stato, inclusi gli stati CA, WA e TX.

    Screenshot di una tabella Sales che mostra le vendite in base allo stato.

  • La tabella CityData contiene i dati sulle città, inclusi popolazione e stato (ad esempio, gli stati CA, WA e New York).

    Screenshot di una tabella Sales che mostra città, stato e popolazione.

Una colonna State si trova ora in entrambe le tabelle ed è ragionevole voler creare un report sulle vendite totali per stato e sulla popolazione totale di ogni stato. Esiste tuttavia un problema: la colonna State non è univoca in nessuna delle due tabelle.

La soluzione alternativa precedente

Nelle versioni di Power BI Desktop precedenti a luglio 2018, gli utenti non potevano creare una relazione diretta tra queste tabelle. Una soluzione comune a questo problema prevedeva di:

  • Creare una terza tabella contenente solo gli ID di State univoci. La tabella potrebbe avere una o tutte le caratteristiche seguenti:

    • Una tabella calcolata, definita tramite il linguaggio DAX (Data Analysis Expressions).
    • Una tabella basata su una query definita nell'Editor di Power Query che potrebbe visualizzare gli ID univoci prelevati da una delle tabelle.
    • Il set completo combinato.

  • Correlare quindi le due tabelle originali nella nuova tabella usando relazioni molti-a-uno comuni.

La tabella della soluzione alternativa può essere lasciata visibile 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-a-uno verrebbero normalmente impostate per filtrare in entrambe le direzioni, e si potrebbe utilizzare il campo State di una qualsiasi delle due tabelle. Il filtro incrociato successivo verrebbe propagato all'altra tabella. Questo approccio è illustrato nell'immagine seguente:

Screenshot di una tabella State nascosta nella vista Relazione.

Un oggetto visivo che visualizza i valori State (dalla tabella CityData) insieme ai totali per Population e Sales sarebbe quindi simile al seguente:

Screenshot che mostra una tabella con dati relativi a Stato, popolazione e vendite.

Nota

Poiché in questa soluzione alternativa viene usata la colonna State della tabella CityData, vengono elencati solo gli stati in tale tabella e, di conseguenza, viene escluso lo stato TX. A differenza delle relazioni molti-a-uno, inoltre, mentre la riga del totale include tutti i valori Sales, incluse le vendite di TX, i dettagli non includono una riga vuota a copertura delle righe non abbinate. Analogamente, non sarebbe presente alcuna riga vuota a copertura di eventuali valori Sales contraddistinti dal valore Null per State.

Se all'oggetto visivo si aggiunge anche City, nonostante la popolazione di ogni valore City sia nota, i valori Sales mostrati per City si limiteranno a ripetere semplicemente i valori Sales dell'elemento State corrispondente. Questo scenario si verifica in genere quando il raggruppamento di colonne non è correlato a una misura di aggregazione, come illustrato di seguito:

Screenshot di una tabella che mostra la popolazione e le vendite per Stato e città.

Si supponga ora di definire la nuova tabella Sales come combinazione di tutti gli i valori State e di renderla visibile nell'elenco Campi. Nello stesso oggetto visivo verrebbe visualizzato sia il valore State (nella nuova tabella), il valore totale di Population e il totale di Sales:

Screenshot di un oggetto visivo che mostra Stato, popolazione e vendite.

Come si può notare, verrebbero inclusi TX, con dati Vendite ma dati relativi alla Popolazione sconosciuti e New York, con dati relativi alla Popolazione noti ma senza dati Vendite. Questa soluzione alternativa non è ottimale e presenta molti problemi. Per le relazioni con cardinalità molti-a-molti, questi problemi vengono risolti, come descritto nella sezione seguente.

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

Usare una relazione con 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 due tabelle contiene valori univoci. Per tali relazioni, è comunque possibile controllare quale tabella filtra l'altra. o applicare un filtro bidirezionale in cui entrambe le tabelle si filtrano a vicenda.

In Power BI Desktop, la cardinalità predefinita è molti-a-molti quando viene determinato che nessuna delle due tabelle contiene valori univoci per le colonne coinvolte nella relazione. In questi casi, un messaggio di avviso conferma la configurazione di una relazione e informa che la modifica non è l'effetto imprevisto di un problema di dati.

Ad esempio, quando si crea una relazione diretta tra CityData e Sales in cui il flusso dei filtri va da CityData a Sales, Power BI Desktop visualizza la finestra di dialogo Modifica relazione:

Screenshot della finestra di dialogo Modifica relazione con cardinalità e direzione filtro incrociato evidenziata.

La visualizzazione Relazioni risultante conterrebbe la relazione molti-a-molti diretta tra le due tabelle. L'aspetto delle tabelle dell'elenco Campi, e il successivo comportamento quando vengono creati gli oggetti visivi, è simile a quando è stata applicata la soluzione alternativa. Nella soluzione alternativa, la tabella aggiuntiva che visualizza i distinti dati di State non è resa visibile. Come descritto nella sezione precedente, verrebbe visualizzato un oggetto visivo che mostri i dati delle tabelle State, Population e Sales:

Screenshot di una tabella State, Population and Sales.

Le principali differenze tra le relazioni con cardinalità molti-a-molti e le più comuni relazioni molti-a-uno sono le seguenti:

  • I valori mostrati non includono una riga vuota che tenga conto delle righe non abbinate nell'altra tabella. Né i valori tengono conto delle righe in cui la colonna usata nella relazione nell'altra tabella ha valore Null.

  • Non è possibile usare la funzione RELATED() perché più di una riga potrebbe essere correlata.

  • L'uso della funzione ALL() su una tabella non rimuove i filtri applicati alle altre tabelle correlate tramite una relazione molti-a-molti. Nell'esempio precedente, una misura definita come illustrato nello script seguente non rimuoverebbe i filtri sulle colonne nella tabella CityData correlata:

    Screenshot di un esempio di script. L'esempio è Sales total = Calculate(Sum('Sales'[Sales]), All('Sales')).

    Un oggetto visivo che mostra i dati per State, Sales e Sales total avrebbe quindi l'aspetto seguente:

    Screenshot di un oggetto visivo tabella che mostra Stato, vendite e vendite totali risultanti dalla formula.

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

Considerazioni e limitazioni

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

Non è possibile usare modelli compositi con le origini Live Connect (multidimensionali) seguenti:

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

Quando ci si connette a tali origini multidimensionali tramite DirectQuery, non è possibile connettersi a un'altra origine DirectQuery o attuare combinazioni con dati importati.

Le limitazioni esistenti per l'uso di DirectQuery si applicano anche quando si usano le relazioni con cardinalità molti-a-molti. Molte limitazioni si riferiscono attualmente a ogni singola tabella, a seconda della modalità di archiviazione della tabella. Ad esempio, una colonna calcolata per una tabella importata può fare riferimento ad altre tabelle, ma una colonna calcolata per una tabella di DirectQuery può fare riferimento solo alle colonne nella stessa tabella. Altre limitazioni si applicano al modello nel suo complesso, se una qualsiasi delle tabelle all'interno del modello è in modalità DirectQuery. Ad esempio, le funzionalità Informazioni rapide e Domande e risposte non sono disponibili per un modello se per una delle tabelle all'interno di esso è impostata la modalità di archiviazione DirectQuery.

Contenuto correlato

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