Relazioni nei modelli in Power BI Desktop

Questo articolo è destinato all'importazione dei modellatori di dati usati in Power BI Desktop. Si tratta di un importante argomento di progettazione del modello essenziale per la distribuzione di modelli intuitivi, accurati e ottimali.

Per una discussione più approfondita sulla progettazione ottimale del modello, inclusi i ruoli e le relazioni delle tabelle, vedere Informazioni su uno schema a stella e sull'importanza di questo schema per Power BI.

Scopo delle relazioni

Una relazione di modello propaga i filtri applicati alla colonna di una tabella del modello a una tabella del modello diversa. I filtri verranno propagati a condizione che sia presente un percorso di relazione da seguire, che può comportare la propagazione in più tabelle.

I percorsi delle relazioni sono deterministici, ovvero i filtri vengono sempre propagati nello stesso modo e senza variazioni casuali. Tuttavia, le relazioni possono essere disabilitate o il contesto del filtro può essere modificato dai calcoli del modello che usano funzioni DAX specifiche. Per altre informazioni, vedere l'argomento Funzioni DAX rilevanti più avanti in questo articolo.

Ecco come le relazioni propagano i filtri con un esempio animato.

In questo esempio il modello è costituito da quattro tabelle: Categoria, Prodotto, Anno e Vendite. La tabella Categoria è correlata alla tabella Prodotto e la tabella Prodotto è correlata alla tabella Vendite. La tabella Anno è correlata anche alla tabella Vendite. Tutte le relazioni sono uno-a-molti (i cui dettagli vengono descritti più avanti in questo articolo).

Una query, forse generata da un oggetto visivo scheda di Power BI, richiede la quantità totale di vendite per gli ordini di vendita effettuati per una singola categoria, Cat-A, e per un singolo anno, CY2018. Per questo motivo è possibile visualizzare i filtri applicati nelle tabelle Categoria e Anno. Il filtro nella tabella Categoria viene propagato alla tabella Prodotto per isolare due prodotti assegnati alla categoria Cat-A. I filtri della tabella Prodotto vengono quindi propagati alla tabella Vendite per isolare solo due righe di vendita per questi prodotti. Queste due righe di vendita rappresentano le vendite dei prodotti assegnati alla categoria Cat-A. La loro quantità combinata è di 14 unità. Allo stesso tempo, il filtro della tabella Anno viene propagato per filtrare ulteriormente la tabella Vendite, ottenendo solo una riga di vendita per i prodotti assegnati alla categoria Cat-A e ordinati nell'anno CY2018. Il valore di quantità restituito dalla query è di 11 unità. Si noti che quando vengono applicati più filtri a una tabella (ad esempio la tabella Vendite in questo esempio), si tratta sempre di un'operazione AND, che richiede che tutte le condizioni siano vere.

Applicare i principi di progettazione dello schema star

È consigliabile applicare i principi di progettazione dello schema star per produrre un modello che include tabelle delle dimensioni e tabelle dei fatti. È comune configurare Power BI per applicare regole che filtrano le tabelle delle dimensioni, consentendo alle relazioni del modello di propagare in modo efficiente tali filtri alle tabelle dei fatti.

L'immagine seguente è il diagramma del modello di dati per l'analisi delle vendite di Adventure Works. Mostra una struttura dello schema star costituita da una singola tabella dei fatti denominata Sales (Vendite). Le altre quattro tabelle sono tabelle delle dimensioni che supportano l'analisi delle misure di vendita in base a data, stato, area e prodotto. Si notino le relazioni tra modelli che connettono tutte le tabelle. Queste relazioni propagano i filtri, direttamente o indirettamente, nella tabella Sales (Vendite).

Tabelle disconnesse

È insolito che una tabella del modello non sia correlata a un'altra tabella del modello. Una tabella di questo tipo in una progettazione di un modello valida è descritta come tabella disconnessa. Una tabella disconnessa non è progettata per propagare i filtri ad altre tabelle del modello. Accetta l'input dell'utente (ad esempio con un oggetto visivo filtro dei dati), consentendo ai calcoli del modello di usare il valore di input in modo significativo. Si consideri, ad esempio, una tabella disconnessa caricata con un intervallo di valori di tassi di cambio. Se un filtro viene applicato per filtrare in base a un singolo valore di tasso, un'espressione di misura può usare tale valore per convertire i valori delle vendite.

Il parametro di simulazione di Power BI Desktop è una funzionalità che crea una tabella disconnessa. Per altre informazioni, vedere Creare e usare un parametro analisi di simulazione per visualizzare le variabili in Power BI Desktop.

Proprietà della relazione

Una relazione del modello consente di correlare una colonna di una tabella a una colonna di un'altra tabella. Esiste un unico caso specifico in cui questo requisito non è vero e vale solo per le relazioni tra più colonne nei modelli DirectQuery. Per altre informazioni, vedere l'articolo sulla funzione DAX COMBINEVALUES.

Tipi di dati di colonne

Il tipo di dati per la colonna "da" e "a" della relazione deve essere lo stesso. L'utilizzo di relazioni definite in colonne DateTime potrebbe non avere il comportamento previsto. Il motore che archivia i dati di Power BI usa solo tipi di dati DateTime; i tipi di dati Data, Time e Date/Time/Timezone sono costrutti di formattazione di Power BI implementati in primo piano. Tutti gli oggetti dipendenti dal modello verranno comunque visualizzati come DateTime nel motore, ad esempio relazioni, gruppi e così via. Di conseguenza, se un utente seleziona Data dalla scheda Modellazione per tali colonne, non viene comunque registrato come la stessa data, perché la parte relativa all'ora dei dati è ancora in fase di considerazione da parte del motore. Altre informazioni su come vengono gestiti i tipi di data/ora. Per correggere il comportamento, i tipi di dati della colonna devono essere aggiornati nell'editor di Power Query per rimuovere la parte Tempo dai dati importati, quindi quando il motore gestisce i dati, i valori verranno visualizzati nello stesso modo.

Cardinalità

Ogni relazione del modello deve essere definita da un tipo di cardinalità. Sono disponibili quattro opzioni per il tipo di cardinalità, che rappresentano le caratteristiche dei dati delle colonne correlate con "da" e "a". Il lato "uno" indica che la colonna contiene valori univoci. Il lato "molti" indica che la colonna può contenere valori duplicati.

Le quattro opzioni, insieme alle relative notazioni abbreviate, sono descritte nell'elenco puntato seguente:

• Uno-a-molti (1:*)
• Molti-a-uno (*:1)
• Uno-a-uno (1:1)
• Molti-a-molti (*:*)

Quando si crea una relazione in Power BI Desktop la finestra di progettazione rileva e imposta automaticamente il tipo di cardinalità. Power BI Desktop esegue una query sul modello per sapere quali colonne contengono valori univoci. Per i modelli di importazione usa le statistiche di archiviazione interna; per i modelli DirectQuery invia query di profilatura all'origine dati. A volte, tuttavia, Power BI Desktop può sbagliare. Ciò si verifica quando le tabelle devono essere ancora caricate con i dati o perché le colonne che si prevede contengano valori duplicati contengono attualmente valori univoci. In entrambi i casi, è possibile aggiornare il tipo di cardinalità a condizione che le colonne lato "uno" contengano valori univoci (o che la tabella debba ancora essere caricata con le righe di dati).

Cardinalità uno-a-molti (e molti-a-uno)

Le opzioni di cardinalità uno-a-molti e molti-a-uno sono essenzialmente identiche e sono anche i tipi di cardinalità più comuni.

Quando si configura una relazione uno-a-molti o molti-a-uno, si sceglie ciò che corrisponde all'ordine in cui sono state correlate le colonne. Si consideri come configurare la relazione dalla tabella Product alla tabella Sales usando la colonna ProductID presente in ogni tabella. Il tipo di cardinalità sarà Uno-a-molti, perché la colonna ProductID nella tabella Product contiene valori univoci. Se le tabelle vengono correlate nella direzione inversa, da Sales a Product, la cardinalità sarà molti-a-uno.

Cardinalità uno-a-uno

Un relazione uno-a-uno indica che entrambe le colonne contengono valori univoci. Questo tipo di cardinalità non è comune ed è probabile che rappresenti una progettazione del modello non ottimale a causa dell'archiviazione di dati ridondanti.

Per altre informazioni sull'uso di questo tipo di cardinalità, vedere Linee guida per relazioni uno-a-uno.

Cardinalità molti-a-molti

Un relazione molti-a-molti indica che entrambe le colonne possono contenere valori duplicati. Questo tipo di cardinalità viene usato raramente. È in genere utile quando si progettano requisiti di modelli complessi. È possibile usarla per correlare fatti molti-a-molti o per correlare fatti con intervallo maggiore. Ad esempio, quando i fatti di destinazione delle vendite vengono archiviati a livello di categoria di prodotto e la tabella delle dimensioni del prodotto viene archiviata a livello di prodotto.

Per istruzioni sull'uso di questo tipo di cardinalità, vedere Linee guida per le relazioni molti-a-molti.

Direzione filtro incrociato

Ogni relazione del modello viene definita con una direzione del filtro incrociato. L'impostazione determina la direzione o le direzioni in cui i filtri verranno propagati. Le opzioni di filtro incrociato possibili dipendono dal tipo di cardinalità.

La direzione filtro incrociato Singola significa "singola direzione" e Entrambe significa "entrambe le direzioni". Una relazione che consente di filtrare in entrambe le direzioni viene comunemente descritta come bidirezionale.

Per le relazioni uno-a-molti, la direzione del filtro incrociato è sempre dal lato "uno" e, facoltativamente, dal lato "molti" (bidirezionale). Per le relazioni uno-a-uno, la direzione del filtro incrociato è sempre da entrambe le tabelle. Infine, per le relazioni molti-a-molti, la direzione del filtro incrociato può essere da una delle due tabelle o da entrambe le tabelle. Si noti che quando il tipo di cardinalità include un lato "uno", i filtri vengono sempre propagati da tale lato.

Quando la direzione del filtro incrociato è impostata su Entrambi, diventa disponibile un'altra proprietà. Può applicare un filtro bidirezionale quando Power BI applica le regole di Sicurezza a livello di riga. Per altre informazioni sulla sicurezza a livello di riga, vedere Sicurezza a livello di riga con Power BI Desktop.

È possibile modificare la direzione del filtro incrociato della relazione, inclusa la disabilitazione della propagazione del filtro, usando un calcolo del modello. Per ottenere questo risultato, è possibile usare la funzione DAX CROSSFILTER.

Tenere presente che le relazioni bidirezionali possono influire negativamente sulle prestazioni. Inoltre, il tentativo di configurare una relazione bidirezionale potrebbe provocare percorsi di propagazione del filtro ambigui. In questo caso, Power BI Desktop potrebbe non riuscire a eseguire il commit della modifica della relazione e verrà generato un avviso con un messaggio di errore. In alcuni casi, tuttavia, Power BI Desktop può consentire di definire percorsi di relazione ambigui tra le tabelle. La risoluzione dell'ambiguità del percorso delle relazioni è descritta più avanti in questo articolo.

Si consiglia di usare il filtro bidirezionale solo se necessario. Per altre informazioni, vedere Linee guida per la relazione bidirezionale.

Imposta come relazione attiva

Tra due tabelle del modello può essere presente un solo percorso di propagazione del filtro attivo. Tuttavia, è possibile introdurre percorsi di relazione aggiuntivi, anche se queste relazioni devono essere tutte configurate come inattive. Le relazioni inattive possono essere rese attive solo durante la valutazione del calcolo di un modello. Per ottenere questo risultato, è possibile usare la funzione DAX USERELATIONSHIP.

In genere, è consigliabile definire relazioni attive laddove possibile. Viene ampliato l'ambito e il potenziale del modo in cui gli autori di report possono usare il modello. Se si usano solo relazioni attive, le tabelle delle dimensioni con ruoli multipli devono essere duplicate nel modello.

In circostanze specifiche, tuttavia, è possibile definire una o più relazioni inattive per una tabella delle dimensioni con ruoli multipli. È possibile considerare questa progettazione quando:

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

Per altre informazioni, vedere Linee guida per relazioni attive e inattive.

Considera integrità referenziale

La proprietà Considera integrità referenziale è disponibile solo per le relazioni uno-a-molti e uno-a-uno tra due tabelle in modalità di archiviazione DirectQuery che appartengono allo stesso gruppo di origine. È possibile abilitare questa proprietà solo quando la colonna lato "molti" non contiene valori NULL.

Se abilitata, le query native inviate all'origine dati creeranno un join tra le due tabelle usando INNER JOIN anziché OUTER JOIN. In generale, l'abilitazione di questa proprietà migliora le prestazioni delle query, anche se ciò dipende dalle specifiche dell'origine dati.

Abilitare sempre questa proprietà quando esiste un vincolo di chiave esterna del database tra le due tabelle. Anche quando non esiste un vincolo della chiave esterna, è consigliabile abilitare la proprietà, a condizione che esista l'integrità dei dati.

Funzioni DAX rilevanti

Sono disponibili diverse funzioni DAX rilevanti per le relazioni del modello. Ogni funzione è descritta brevemente nell'elenco puntato seguente:

• RELATED: recupera il valore da "un" lato di una relazione. È utile quando si hanno calcoli di tabelle diverse valutate in contesto di riga.
• RELATEDTABLE: recuperare una tabella di righe dal lato "molti" di una relazione.
• USERELATIONSHIP: consente a un calcolo di usare una relazione inattiva. Tecnicamente, questa funzione modifica il peso di una relazione specifica del modello inattivo, contribuendo a influenzarne l'uso. È utile quando il modello include una tabella delle dimensioni con ruoli e si sceglie di creare relazioni inattive da questa tabella. È anche possibile usare questa funzione per risolvere l'ambiguità nei percorsi di filtro.
• CROSSFILTER: modifica la direzione filtro incrociato della relazione (in una o entrambe) oppure disabilita la propagazione del filtro (nessuno). È utile quando è necessario modificare o ignorare le relazioni del modello durante la valutazione di un calcolo specifico.
• COMBINEVALUES: unisce due o più stringhe di testo in una sola. Lo scopo di questa funzione è supportare relazioni a più colonne nei modelli DirectQuery quando le tabelle appartengono allo stesso gruppo di origine.
• TREATAS: applica il risultato di un'espressione di tabella come filtri alle colonne di una tabella non correlata. È utile negli scenari avanzati quando si vuole creare una relazione virtuale durante la valutazione di un calcolo specifico.
• Funzioni padre e figlio: famiglia di funzioni correlate che è possibile usare per generare colonne calcolate per naturalizzare una gerarchia padre-figlio. È quindi possibile usare queste colonne per creare una gerarchia a livello fisso.

Valutazione della relazione

Le relazioni del modello, dal punto di vista della valutazione, vengono classificate come regolari o limitate. Non si tratta di una proprietà della relazione configurabile. Viene infatti dedotta dal tipo di cardinalità e dall'origine dati delle due tabelle correlate. È importante comprendere il tipo di valutazione poiché potrebbero verificarsi implicazioni o conseguenze sulle prestazioni in caso di compromissione dell'integrità dei dati. Queste implicazioni e conseguenze sull'integrità sono descritte in questo argomento.

Per prima cosa, è necessaria una teoria di modellazione per comprendere completamente le valutazioni delle relazioni.

Un modello di importazione o DirectQuery genera tutti i dati dalla cache Vertipaq o dal database di origine. In entrambi i casi, Power BI è in grado di determinare l'esistenza di un lato "uno" di una relazione.

Un modello composito, tuttavia, può includere tabelle che usano diverse modalità di archiviazione (importazione, DirectQuery o doppia) o più origini DirectQuery. Ogni origine, inclusa la cache Vertipaq dei dati importati, viene considerata un gruppo di origine. Le relazioni tra modelli possono quindi essere classificate come all'interno di un gruppo di origine o tra gruppi di origine. Una relazione tra gruppi di origine correla due tabelle all'interno di un gruppo di origine, mentre una relazione tra gruppi di origine correla le tabelle tra due gruppi di origine. Si noti che le relazioni nei modelli di importazione o DirectQuery sono sempre all'interno del gruppo di origine.

Di seguito è riportato un esempio di modello di insieme.

In questo esempio, il modello composito è costituito da due gruppi di origine: un gruppo di origine Vertipaq e un gruppo di origine DirectQuery. Il gruppo di origine Vertipaq contiene tre tabelle e il gruppo di origine DirectQuery ne contiene due. Esiste una relazione tra gruppi di origini per correlare una tabella nel gruppo di origine Vertipaq a una tabella nel gruppo di origine DirectQuery.

Relazioni regolari

Una relazione del modello è regolare quando il motore di query è in grado di determinare il lato "uno" della relazione. Ha la conferma che la colonna lato "uno" contiene valori univoci. Tutte le relazioni uno-a-molti all'interno di un gruppo di origine sono relazioni regolari.

Nell'esempio seguente sono presenti due relazioni regolari, entrambe contrassegnate come R. Le relazioni includono la relazione uno-a-molti contenuta nel gruppo di origine Vertipaq e la relazione uno-a-molti nell'origine DirectQuery.

Per i modelli di importazione, in cui tutti i dati vengono archiviati nella cache Vertipaq, Power BI crea una struttura dei dati per ogni relazione regolare al momento dell'aggiornamento dati. Le strutture dei dati sono costituite da mapping indicizzati di tutti i valori da colonna a colonna e hanno lo scopo di accelerare l'unione di tabelle in fase di query.

In fase di query, le relazioni regolari consentono l'espansione della tabella. L'espansione della tabella comporta la creazione di una tabella virtuale includendo le colonne native della tabella di base e quindi espandendosi in tabelle correlate. Per le tabelle di importazione, l'espansione viene eseguita nel motore di query, per le tabelle DirectQuery viene eseguita nella query nativa inviata al database di origine, purché non sia abilitata la proprietà Considera integrità referenziale. Il motore di query agisce quindi sulla tabella espansa applicando filtri e raggruppando i risultati in base ai valori nelle colonne della tabella espansa.

Per le relazioni uno-a-molti, l'espansione della tabella si verifica dal lato "molti" al lato "uno" usando la semantica LEFT OUTER JOIN. Quando non esiste un valore corrispondente dal lato "molti" al lato "uno", viene aggiunta una riga virtuale vuota alla tabella lato "uno". Questo comportamento si applica solo alle relazioni regolari, non alle relazioni limitate.

L'espansione della tabella si verifica anche per le relazioni uno-a-uno all'interno del gruppo di origine, ma usando la semantica FULL OUTER JOIN. Questo tipo di join garantisce che le righe virtuali vuote vengano aggiunte su entrambi i lati, quando necessario.

Le righe virtuali vuote sono effettivamente membri sconosciuti. I membri sconosciuti rappresentano violazioni di integrità referenziale in cui il valore del lato "molti" non ha un valore corrispondente del lato "uno". Idealmente questi spazi vuoti non dovrebbero esistere. Possono essere eliminati pulendo o riparando i dati di origine.

Vediamo come funziona l'espansione della tabella con un esempio animato.

In questo esempio il modello è costituito da tre tabelle: Categoria, Prodotto e Vendite. La tabella Category è correlata alla tabella Product con una relazione Uno-a-molti e la tabella Product è correlata alla tabella Sales con una relazione Uno-a-molti. La tabella Category contiene due righe, la tabella Product contiene tre righe e le tabelle Sales contiene cinque righe. Sono presenti valori corrispondenti in entrambi i lati di tutte le relazioni, il che significa che non esistono violazioni di integrità referenziale. Viene rilevata una tabella espansa in fase di query. La tabella è costituita dalle colonne di tutte e tre le tabelle. Si tratta in realtà di una prospettiva denormalizzata dei dati contenuti nelle tre tabelle. Una nuova riga viene aggiunta alla tabella Sales e ha un valore identificatore produzione (9) che non ha un valore corrispondente nella tabella Product. Si tratta di una violazione dell'integrità referenziale. Nella tabella espansa la nuova riga contiene valori (vuoti) per le colonne della tabella Category e Product.

Relazioni limitate

Una relazione del modello è limitata quando non esiste un lato "uno" garantito. Una relazione limitata può verificarsi per due motivi:

• La relazione usa un tipo di cardinalità Molti-a-molti (anche se una o entrambe le colonne contengono valori univoci).
• La relazione è tra gruppi di origini (che può esistere solo per i modelli compositi).

Nell'esempio seguente sono presenti due relazioni limitate, entrambe contrassegnate come L. Le due relazioni includono la relazione molti-a-molti contenuta nel gruppo di origine Vertipaq e la relazione uno-a-molti tra gruppi di origine.

Per i modelli di importazione, le strutture dei dati non vengono mai create per le relazioni limitate. In tal caso, Power BI risolve i join di tabelle in fase di query.

L'espansione della tabella non viene mai eseguita per le relazioni limitate. I join di tabella vengono realizzati usando la semantica INNER JOIN e per questo motivo non vengono aggiunte righe virtuali vuote per compensare le violazioni di integrità referenziale.

Sono presenti ulteriori restrizioni relative alle relazioni limitate:

• Non è possibile usare la funzione DAX RELATED per recuperare i valori della colonna lato "uno".
• L'applicazione della Sicurezza a livello di riga presenta restrizioni topologiche.

Risolvere l'ambiguità del percorso della relazione

Le relazioni bidirezionali possono introdurre più percorsi di propagazione del filtro, e pertanto ambigui, tra le tabelle del modello. Quando si valuta l'ambiguità, Power BI sceglie il percorso di propagazione del filtro in base alla priorità e al peso.

Priorità

I livelli di priorità definiscono una sequenza di regole usate da Power BI per risolvere l'ambiguità del percorso delle relazioni. La prima corrispondenza della regola determina il percorso che verrà seguito da Power BI. Ogni regola seguente descrive il flusso dei filtri da una tabella di origine a una tabella di destinazione.

1. Percorso costituito da relazioni uno-a-molti.
2. Percorso costituito da relazioni uno-a-molti o molti-a-molti.
3. Percorso costituito da relazioni molti-a-uno.
4. Percorso costituito da relazioni uno-a-molti dalla tabella di origine a una tabella intermedia seguita da relazioni molti-a-uno dalla tabella intermedia alla tabella di destinazione.
5. Percorso costituito da relazioni uno-a-molti o molti-a-molti dalla tabella di origine a una tabella intermedia seguita da relazioni molti-a-uno o molti-a-molti dalla tabella intermedia alla tabella di destinazione.
6. Qualsiasi altro percorso.

Quando una relazione viene inclusa in tutti i percorsi disponibili, viene rimossa dalla considerazione da tutti i percorsi.

Weight

Ogni relazione in un percorso ha un peso. Per impostazione predefinita, ogni peso della relazione è uguale, a meno che non venga usata la funzione USERELATIONSHIP. Il peso percorso è il massimo di tutti i pesi di relazione lungo il percorso. Power BI usa i pesi del percorso per risolvere l'ambiguità tra più percorsi nello stesso livello di priorità. Non sceglierà un percorso con una priorità più bassa, ma sceglierà quello con il peso maggiore. Il numero di relazioni nel percorso non influisce sul peso.

È possibile influenzare il peso di una relazione usando la funzione USERELATIONSHIP. Il peso è determinato dal livello di annidamento della chiamata a questa funzione, in cui la chiamata più interna riceve il peso più alto.

Si consideri l'esempio seguente. La misura Vendite prodotti assegna un peso maggiore alla relazione tra Sales[ProductID] e Product[ProductID], seguita dalla relazione tra Inventory[ProductID] e Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Preferenza per le prestazioni

Nell'elenco seguente vengono ordinate le prestazioni di propagazione del filtro, dalle prestazioni più veloci a quelle più lente:

1. Relazioni uno-a-molti all'interno di un gruppo di origine
2. Relazioni del modello Molti-a-molti ottenute con una tabella intermedia e che implica almeno una relazione bidirezionale
3. Relazioni di cardinalità Molti-a-molti
4. Relazioni tra gruppi tra origini

Contenuto correlato

Per altre informazioni su questo articolo, consultare le risorse seguenti:

• Informazioni su uno schema star e sull'importanza di questo schema per Power BI
• Linee guida per relazioni uno-a-uno
• Linee guida per le relazioni molti-a-molti
• Linee guida per relazioni attive e inattive
• Linee guida per la relazione bidirezionale
• Linee guida per la risoluzione dei problemi relativi alle relazioni
• Video: The Do's and Don'ts of Power BI Relationships (Operazioni consigliate e sconsigliate nelle relazioni di Power BI)
• Domande? Contattare la community di Power BI
• inviare suggerimenti, Contribuire con idee per migliorare Power BI