Usare modelli compositi in Power BI

I modelli semantici di Power BI possono avere tabelle da una o più origini dati usando una delle modalità di archiviazione tabelle supportate. Il modello è considerato un modello semantico composito quando le tabelle hanno modalità di archiviazione diverse e, nel caso della modalità di archiviazione tabelle DirectQuery, quando le tabelle DirectQuery hanno origini dati diverse.

Nota

Le tabelle di importazione da una o più origini dati non vengono considerate modelli compositi fino a quando non vengono combinate con tabelle non importate. Lo stesso vale per i modelli semantici con tabelle Direct Lake da una o più origini dati.

Nota

Si assume che la modalità di archiviazione delle tabelle Direct Lake sia Direct Lake in OneLake per i modelli compositi. La modalità di archiviazione delle tabelle SQL usando Direct Lake è disponibile solo come origine singola e non può essere aggiunta a nessun modello composito. Per ulteriori informazioni sulle differenze nella modalità di archiviazione delle tabelle Direct Lake, vedere aka.ms/DirectLake.

Tipi di modelli compositi

Esistono diversi tipi di modelli compositi a seconda della combinazione di modalità di archiviazione tabelle nel modello semantico. Ogni tipo ha le proprie considerazioni sulle funzionalità e gli strumenti

Tipo di modello composito	Strumenti disponibili	Notes
DirectQuery verso un altro modello semantico di Power BI con o senza tabelle aggiuntive in modalità di archiviazione di importazione o DirectQuery	Solo Power BI Desktop	Connettersi a un modello semantico di Power BI e quindi scegliere Apporta modifiche a questo modello o connettersi dopo l'aggiunta di una tabella in modalità di importazione o archiviazione DirectQuery.
Tabelle DirectQuery provenienti da origini dati diverse	Solo Power BI Desktop	Ad esempio, la tabella A deriva dal database SQL A e dalla tabella B proviene dal database SQL B
Importare e DirectQuery delle tabelle nello stesso modello semantico	Solo Power BI Desktop
Importare e integrare le tabelle del Lake diretto nello stesso modello semantico	Solo modellazione Web di Power BI	Le tabelle Import o Direct Lake possono essere aggiunte in Desktop, ma combinate solo nella modellazione Web.
Tabelle DirectQuery e Direct Lake nello stesso modello semantico	Solo XMLA	Combinare utilizzando uno script XMLA o strumenti della comunità XMLA. Può essere aperto nella modellazione Web per le modifiche del modello semantico solo senza alcuna opzione di aggiornamento o modifica delle tabelle.

Creare modelli compositi in Power BI Desktop

In Power BI Desktop è possibile creare modelli semantici con tabelle di importazione o DirectQuery in locale. È quindi possibile aggiungere tabelle aggiuntive dal pulsante Recupera dati della barra multifunzione nell'altra modalità di archiviazione per essere considerata un modello composito.

Nota

Se le tabelle di importazione e DirectQuery sono entrambe in un modello semantico e dalla stessa origine dati, è disponibile la modalità di archiviazione doppia. La modalità doppia usata invece di DirectQuery può evitare relazioni limitate con le tabelle di importazione. Per ulteriori informazioni sulla modalità di doppia archiviazione, consulta la documentazione sulla modalità di archiviazione.

L'aggiunta di tabelle DirectQuery da un altro modello semantico di Power BI ha un paio di percorsi di creazione diversi.

1. In un file di Power BI vuoto, connettiti prima al modello semantico di Power BI. Dopo la connessione dinamica, è possibile apportare modifiche a questo modello. Se si seleziona Apporta modifiche a questo modello dalla barra multifunzione o dal piè di pagina, la connessione dinamica verrà convertita in una connessione DirectQuery. La connessione DirectQuery crea un nuovo modello semantico locale con le tabelle in modalità di archiviazione DirectQuery. È possibile aggiungere nuove tabelle in modalità di archiviazione import o DirectQuery, oltre a offrire la possibilità di eseguire l'override di alcune proprietà di colonna nel modello semantico di origine.

2. Nel modello semantico con tabelle di importazione o DirectQuery è già possibile connettersi a un modello semantico di Power BI e le tabelle scelte verranno aggiunte come DirectQuery.

I modelli semantici creati con le tabelle Direct Lake vengono modificati in tempo reale in Power BI Desktop. È supportata l'aggiunta di altre tabelle Direct Lake. Aprire il modello semantico nella modellazione Web di Power BI per aggiungere tabelle di importazione. Utilizzare XMLA solo per aggiungere tabelle DirectQuery.

La modifica in tempo reale di un modello semantico di importazione e direct Lake è possibile in Desktop, ma non è possibile aggiungere tabelle aggiuntive. Le tabelle possono essere aggiunte solo dalla modellazione Web di Power BI per Direct Lake e importare modelli compositi.

Creare modelli compositi nella modellazione Web

In Power BI i modelli semantici di modellazione Web possono essere creati con tabelle di importazione o Direct Lake. Non è possibile aggiungere tabelle DirectQuery. È quindi possibile aggiungere altre tabelle nell'altra modalità di archiviazione e essere considerate un modello composito.

Usare i modelli compositi

Con i modelli compositi è possibile connettersi a diversi tipi di origini dati quando si usa Power BI Desktop o il servizio Power BI. È possibile effettuare tali connessioni dati in due modi:

• Importando i dati in Power BI, che è il modo più comune per ottenere i dati.
• Connettendosi direttamente ai dati nel relativo repository di origine tramite DirectQuery. Per altre informazioni su DirectQuery, vedere DirectQuery in Power BI.

Quando si usa DirectQuery, i modelli compositi consentono di creare un modello di Power BI, ad esempio un singolo file .pbix di Power BI Desktop, che consente di eseguire una o entrambe le azioni seguenti:

• Combina i dati da una o più origini DirectQuery.
• Combina i dati da origini DirectQuery e dati importati.

Ad esempio, usando i modelli compositi è possibile creare un modello che combina i tipi di dati seguenti:

• Dati di vendita da un data warehouse aziendale.
• Dati di destinazione delle vendite da un database di SQL Server di reparto.
• Dati importati da un foglio di calcolo.

Un modello semantico che combina tabelle da più di un'origine DirectQuery, oppure combina tabelle DirectQuery, Direct Lake e/o tabelle di importazione, è un modello semantico composito.

È possibile creare relazioni tra le tabelle come sempre, anche quando le tabelle provengono da origini diverse. Tutte le relazioni tra origini vengono create con una cardinalità molti-a-molti, indipendentemente dalla cardinalità effettiva. È possibile modificarle in uno-a-molti, molti-a-uno o uno-a-uno. Indipendentemente dalla cardinalità impostata, le relazioni tra origini hanno un comportamento diverso. Non è possibile usare le funzioni DAX (Data Analysis Expressions) per recuperare i valori sul lato one dal lato many. Si potrebbe anche osservare un impatto sulle prestazioni rispetto alle relazioni molti-a-molti all'interno della stessa origine.

Nota

Nel contesto dei modelli compositi, tutte le tabelle importate rappresentano in effetti una singola origine, indipendentemente dall'effettiva origine dati sottostante.

Esempio di un modello composito

Per un esempio di modello composito, esaminare un report che si connette a un data warehouse aziendale in SQL Server usando DirectQuery. In questo caso, il data warehouse contiene i dati Sales by Country (Vendite per paese), Quarter (Trimestre) e Bike (Product) (Bici - Prodotto), come illustrato nell'immagine seguente:

A questo punto è possibile creare oggetti visivi semplici usando i campi da questa origine. L'immagine seguente illustra il totale delle vendite per ProductName, per un trimestre selezionato.

E se fossero disponibili dati in un foglio di calcolo di Office sul responsabile del prodotto assegnato a ogni prodotto insieme alla relativa priorità di marketing? Se si vuole visualizzare l'importo delle vendite (Sales Amount) in base al responsabile del prodotto (Product Manager), potrebbe non essere possibile aggiungere questi dati locali nel data warehouse aziendale o nella migliore delle ipotesi potrebbero essere necessari dei mesi.

Potrebbe essere possibile importare i dati sulle vendite dal data warehouse, invece di usare DirectQuery. E i dati sulle vendite potrebbero quindi essere combinati con i dati importati dal foglio di calcolo. Tuttavia, questo approccio è irragionevole, per i motivi che conducono all'uso di DirectQuery in primo luogo. I motivi possono includere i seguenti:

• Una combinazione delle regole di sicurezza applicate nell'origine sottostante.
• La necessità di essere in grado di visualizzare i dati più recenti.
• L'enorme quantità di dati.

Questi sono gli scenari in cui entrano in gioco i modelli compositi. I modelli compositi consentono di connettersi al data warehouse usando DirectQuery e quindi di usare Recupera dati per altre origini. In questo esempio, viene prima di tutto stabilita una connessione DirectQuery al data warehouse aziendale. Si usa Recupera dati, si sceglie Excel e quindi si passa al foglio di calcolo che contiene i dati locali. Infine, si importa il foglio di calcolo che contiene i nomi dei prodotti (ProductName), il responsabile del prodotto assegnato (Product Manager) e la priorità (Priority).

Nell'elenco Campi è possibile visualizzare due tabelle: la tabella Bike originale da SQL Server e una nuova tabella ProductManagers. La nuova tabella contiene i dati importati da Excel.

Allo stesso modo, nella visualizzazione Relazioni in Power BI Desktop è ora disponibile un’altra tabella denominata ProductManagers.

È ora necessario mettere in relazione le tabelle con le altre tabelle nel modello. Come sempre, si crea una relazione tra la tabella Bike da SQL Server e la tabella ProductManagers importata. La relazione è tra Bike[ProductName] e ProductManagers[ProductName]. Come illustrato in precedenza, tutte le relazioni che attraversano l'origine sono impostate sulla cardinalità predefinita molti-a-molti.

La relazione così stabilita è ora inclusa nella visualizzazione Relazione in Power BI Desktop, come prevedibile.

È ora possibile creare oggetti visivi usando uno qualsiasi dei campi nell'elenco Campi. Questo approccio consente di unire facilmente i dati da più origini. Ad esempio, l'importo totale SalesAmount per ogni Product Manager viene visualizzato nell'immagine seguente:

L'esempio seguente mostra un caso comune di una tabella delle dimensioni, ad esempio Product oppure Customer, che viene estesa con dati aggiuntivi importati da altre origini. È anche possibile configurare le tabelle per l'uso di DirectQuery per connettersi a varie origini. Per continuare con questo esempio, si immagini che i valori di SalesTargets per ogni Country e Period siano archiviati in un database di reparto separato. È possibile usare Recupera dati per connettersi a tali dati come di consueto, come illustrato nell'immagine seguente:

Come in precedenza, è possibile creare relazioni tra la nuova tabella e altre tabelle nel modello. È quindi possibile creare degli oggetti visivi che combinano i dati della tabella. Di seguito è raffigurata di nuovo la visualizzazione Relazioni in cui sono state stabilite nuove relazioni:

L'immagine successiva si basa sui nuovi dati e sulle nuove relazioni creati. L'oggetto visivo in basso a sinistra mostra il totale di Sales Amount rispetto al Target e il calcolo della varianza mostra la differenza. I dati Sales Amount e Target provengono da due database di SQL Server diversi.

Impostare la modalità di archiviazione

Ogni tabella in un modello composito ha una modalità di archiviazione che indica se la tabella è basata su DirectQuery o importazione. La modalità di archiviazione può essere visualizzata e modificata nel riquadro Proprietà. Per visualizzare la modalità di archiviazione, fare clic con il pulsante destro del mouse su una tabella nell'elenco Campi e quindi scegliere Proprietà. L'immagine seguente illustra la modalità di archiviazione per la tabella SalesTargets.

La modalità di archiviazione può anche essere visualizzata nella descrizione comando per ogni tabella.

Per qualsiasi file di Power BI Desktop (PBIX) che contiene alcune tabelle da DirectQuery e alcune tabelle importate importazione, la barra di stato visualizza la modalità di archiviazione Mista. È possibile selezionare tale termine nella barra di stato e passare facilmente a tutte le tabelle da importare.

Per altre informazioni sulla modalità di archiviazione, vedere Gestire la modalità di archiviazione in Power BI Desktop.

Nota

È possibile usare la modalità di archiviazione Mista in Power BI Desktop e nel servizio Power BI.

Tabelle calcolate

È possibile aggiungere tabelle calcolate a un modello in Power BI Desktop che usa DirectQuery. Le espressioni DAX (Data Analysis Expression) che definiscono la tabella calcolata possono fare riferimento a tabelle importate o che usano DirectQuery o a una combinazione delle due.

Le tabelle calcolate vengono sempre importate e i dati vengono aggiornati quando si aggiornano le tabelle. Se una tabella calcolata fa riferimento a una tabella DirectQuery, gli oggetti visivi che fanno riferimento alla tabella DirectQuery mostrano sempre i valori più recenti nell'origine sottostante. In alternativa, gli oggetti visivi che fanno riferimento alla tabella calcolata mostrano i valori al momento dell'ultimo aggiornamento della tabella calcolata.

Importante

Le tabelle calcolate non sono supportate nel servizio Power BI usando questa funzionalità, a meno che non siano soddisfatti dei requisiti specifici. Per altre informazioni, vedere la sezione Uso di un modello composito basato su un modello semantico in questo articolo.

Implicazioni per la sicurezza

Per i modelli compositi esistono alcune implicazioni per la sicurezza. Una query inviata a un'origine dati può includere valori di dati recuperati da un'altra origine. Nell'esempio precedente, l'oggetto visivo che mostra (Sales Amount) secondo il Product Manager invia una query SQL al database relazionale delle vendite. Tale query SQL potrebbe contenere i nomi dei Product Manager e dei Product a loro associati.

Pertanto, le informazioni archiviate nel foglio di calcolo sono ora incluse in una query inviata al database relazionale. Se queste informazioni sono riservate, è necessario considerare le implicazioni per la sicurezza. In particolare, tenere conto dei punti seguenti:

• Qualsiasi amministratore del database che può visualizzare le tracce o i log di controllo può visualizzare queste informazioni, anche senza autorizzazioni per i dati nell'origine iniziale. In questo esempio, l'amministratore dovrebbe avere le autorizzazioni per il file di Excel.

• Devono essere considerate le impostazioni di crittografia per ogni origine. È opportuno evitare il recupero di informazioni da un'origine usando una connessione crittografata per poi includerle inavvertitamente in una query inviata a un'altra origine usando una connessione non crittografata.

Per ottenere una conferma che sono state prese in considerazione le implicazioni per la sicurezza, Power BI Desktop visualizza un messaggio di avviso quando viene creato un modello composito.

Inoltre, se un autore aggiunge Tabella1 dal Modello A a un modello composito (chiamiamolo Modello C per riferimento), un utente che visualizza un report basato sul Modello C potrebbe eseguire una query su qualsiasi tabella nel Modello A non protetta con la sicurezza a livello di riga RLS.

Per motivi analoghi, prestare attenzione quando si apre un file di Power BI Desktop inviato da un'origine non attendibile. Se il file contiene modelli compositi, le informazioni recuperate da qualcuno da un'origine con le credenziali dell'utente che apre il file verrebbero inviate a un'altra origine dati come parte della query. Le informazioni potrebbero essere visualizzate dall'autore malintenzionato del file di Power BI Desktop. Quando si apre inizialmente un file di Power BI Desktop che contiene più origini, Power BI Desktop visualizza un avviso. Questo avviso è simile a quello visualizzato quando si apre un file che contiene query SQL native.

Implicazioni per le prestazioni

Quando si usa DirectQuery, occorre tenere sempre conto delle prestazioni, principalmente per garantire che l'origine back-end abbia risorse sufficienti per offrire una buona esperienza agli utenti. Un'esperienza ottimale significa che gli oggetti visivi vengono aggiornati in massimo cinque secondi. Per altri consigli per le prestazioni, vedere DirectQuery in Power BI.

Esistono altre considerazioni per le prestazioni di cui tenere conto quando si usano i modelli compositi. Un singolo oggetto visivo può comportare l'invio di query a più origini, operazione che implica spesso il passaggio dei risultati da una query attraverso una seconda origine. Questa situazione può portare alle forme di esecuzione seguenti:

• Una query di origine che include un numero elevato di valori letterali: ad esempio, un oggetto visivo che richiede il totale di Sales Amount per un set di Product Manager selezionati dovrebbe prima di tutto trovare i Product gestiti da tali responsabili di prodotto. Questa sequenza deve verificarsi prima che la visualizzazione invii una query SQL che include tutti gli ID prodotto in una clausola WHERE.

• Una query di origine che esegue una query a un livello inferiore di granularità, con i dati aggregati in locale: man mano che aumenta il numero di Product che soddisfano i criteri di filtro per Product Manager, può diventare inefficiente o non fattibile includere tutti i prodotti in una clausola WHERE. È invece possibile eseguire una query sull'origine relazionale al livello inferiore di Product e quindi aggregare i risultati in locale. Se la cardinalità di Product supera il limite di 1 milione, la query ha esito negativo.

• Più query di originare, una per ogni valore di raggruppamento: quando l'aggregazione usa DistinctCount, con raggruppamento in base a una colonna dall'altra origine, se l'origine esterna non supporta il passaggio efficiente di molti valori letterali che definiscono il raggruppamento, è necessario inviare una query SQL per ogni valore di raggruppamento.

  Un oggetto visivo che richiede il conteggio di valori univoci per CustomerAccountNumber (dalla tabella di SQL Server) in base a Product Manager (importato dal foglio di calcolo) dovrebbe passare i dettagli dalla tabella Product Managers nella query inviata a SQL Server. Su altre origini, ad esempio Redshift, questa azione non è fattibile. Verrebbe invece inviata una query SQL per ogni Sales Manager fino a un limite pratico e la query avrebbe poi esito negativo.

Per ognuno di questi casi esistono implicazioni specifiche per le prestazioni e i dettagli esatti variano per ogni origine dati. Anche se la cardinalità delle colonne usate nella relazione che unisce le due origini resta ridotta (alcune migliaia), non dovrebbero esserci effetti sulle prestazioni. Man mano che aumenta la cardinalità, è necessario prestare maggiore attenzione all'impatto sulle prestazioni risultanti.

Inoltre, l'uso delle relazioni molti-a-molti significa che è necessario inviare query separate all'origine sottostante per ogni livello totale o subtotale, anziché aggregare i valori dettagliati in locale. Un oggetto visivo tabella semplice con totali invierebbe due query di origine, anziché una.

Gruppi di origine

Un gruppo di origine è una raccolta di elementi, ad esempio tabelle e relazioni, da un'origine DirectQuery o da tutte le origini di importazione coinvolte in un modello di dati. Un modello composito è costituito da uno o più gruppi di origine. Vedi gli esempi seguenti:

• Un modello composito che si connette a un modello semantico di Power BI denominato Sales e arricchisce il modello semantico aggiungendo una misura Sales YTD, che non è disponibile nel modello semantico originale. Questo modello è costituito da un gruppo di origine.
• Modello composito che combina i dati importando una tabella da un foglio di Excel denominato Targets e un file CSV denominato Regions e creando una connessione DirectQuery a un modello semantico di Power BI denominato Sales. In questo caso, esistono due gruppi di origine, come illustrato nell'immagine seguente:
  • Il primo gruppo di origine contiene le tabelle del foglio Excel Targets e il file CSV Regions.
  • Il secondo gruppo di origine contiene gli elementi del modello semantico Sales Power BI.

Se è stata aggiunta un'altra connessione DirectQuery a un'altra origine, ad esempio una connessione DirectQuery a un database di SQL Server denominato Inventory, gli elementi di tale origine vengono aggiunti come un altro gruppo di origine:

Nota

L'importazione di dati da un'altra origine non aggiungerà un altro gruppo di origine, perché tutti gli elementi di tutte le origini importate si trovano in un gruppo di origine. Anche le tabelle Direct Lake e import sono considerate lo stesso gruppo di origine.

Gruppi di origine e relazioni

Esistono due tipi di relazioni in un modello composito:

• Relazioni tra gruppi di origine. Queste relazioni riguardano gli elementi all'interno di un gruppo di origine insieme. Queste relazioni sono sempre relazioni regolari, a meno che non siano molti-a-molti, nel qual caso sono limitate.
• Relazioni tra gruppi tra origini. Queste relazioni iniziano in un gruppo di origine e terminano in un gruppo di origine diverso. Queste relazioni sono sempre relazioni limitate.

Altre informazioni sulla distinzione tra relazioni regolari e limitate e il relativo impatto.

Nell'immagine seguente, ad esempio, sono state aggiunte tre relazioni tra gruppi di origine, correlando le tabelle tra i vari gruppi di origine insieme:

Ambiente locale e remoto

Qualsiasi elemento incluso in un gruppo di origine che è un gruppo di origine DirectQuery viene considerato remoto, a meno che l'elemento non sia stato definito localmente come parte di un'estensione o un arricchimento all'origine DirectQuery e non faccia parte dell'origine remota, ad esempio una misura o una tabella calcolata. Una tabella calcolata basata su una tabella del gruppo di origine DirectQuery appartiene al gruppo di origine "Importa" ed è considerata locale. Qualsiasi elemento incluso nel gruppo di origine "Importa" viene considerato locale. Ad esempio, se si definisce la misura seguente in un modello composito che usa una connessione DirectQuery all'origine Inventario, la misura viene considerata locale:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Gruppi di calcolo, query e valutazione delle misure

I gruppi di calcolo consentono di ridurre il numero di misure ridondanti e raggruppare le espressioni di misura comuni. I casi d'uso tipici sono calcoli di business intelligence per le gerarchie temporali in cui si vuole essere in grado di passare dai calcoli effettivi a quelli mensili, da trimestre a data o da anno a data. Quando si lavora con modelli compositi, è importante tenere presente l'interazione tra i gruppi di calcolo e se una misura fa riferimento solo agli elementi di un singolo gruppo di origine remoto. Se una misura fa riferimento solo agli elementi di un singolo gruppo di origine remoto e il modello remoto definisce un gruppo di calcolo che influisce sulla misura, tale gruppo di calcolo viene applicato, anche se la misura è stata definita nel modello remoto o nel modello locale. Tuttavia, se una misura non fa riferimento agli elementi di un singolo gruppo di origine remoto, ma fa riferimento esclusivamente agli elementi di un gruppo di origine remoto in cui viene applicato un gruppo di calcolo remoto, i risultati della misura potrebbero comunque essere interessati dal gruppo di calcolo remoto. Si consideri l'esempio seguente:

• Reseller Sales è una misura definita nel modello remoto.
• Il modello remoto contiene un gruppo di calcolo che modifica il risultato di Reseller Sales
• Internet Sales è una misura definita nel modello locale.
• Total Sales è una misura definita nel modello locale e ha la definizione seguente:

[Total Sales] = [Internet Sales] + [Reseller Sales]

In questo scenario, la misura Internet Sales non è influenzata dal gruppo di calcolo definito nel modello remoto perché non fanno parte dello stesso modello. Tuttavia, il gruppo di calcolo può modificare il risultato della misura Reseller Sales, perché si trovano nello stesso modello. Questo significa che i risultati restituiti dalla misura Total Sales devono essere valutati attentamente. Si supponga di usare il gruppo di calcolo nel modello remoto per restituire risultati da inizio anno. Il risultato restituito da Reseller Sales è ora un valore da anno a data, mentre il risultato restituito da Internet Sales è ancora un valore effettivo. Il risultato di Total Sales è probabilmente imprevisto, perché aggiunge un risultato effettivo a un risultato da anno a data.

Modelli compositi in modelli semantici di Power BI e Analysis Services

Usando modelli compositi con modelli semantici di Power BI e Analysis Services, è possibile creare un modello composito usando una connessione DirectQuery per connettersi a modelli semantici di Power BI, Azure Analysis Services (AAS) e SQL Server 2022 Analysis Services. Usando un modello composito, è possibile combinare i dati in queste origini con altri dati DirectQuery e importati. Questa funzionalità è particolarmente utile per gli autori di report che vogliono combinare i dati del modello semantico aziendale con altri dati in loro possesso, ad esempio un foglio di calcolo di Excel, o che vogliono personalizzare o arricchire i metadati del proprio modello semantico aziendale.

Gestione di modelli compositi nei modelli semantici di Power BI

Per abilitare la creazione e l'utilizzo di modelli compositi nei modelli semantici di Power BI, il tenant deve disporre delle opzioni seguenti abilitate:

• Consenti endpoint XMLA e Analizza in Excel con modelli semantici locali. Se questa opzione è disabilitata, non è possibile stabilire una connessione DirectQuery a un modello semantico di Power BI.
• Gli utenti possono usare modelli semantici di Power BI in Excel usando una connessione dinamica. Se questa opzione è disabilitata, gli utenti non possono stabilire connessioni dinamiche ai modelli semantici di Power BI in modo che non sia possibile raggiungere il pulsante Apportare modifiche a questo modello.
• Consentire la connessione DirectQuery ai modelli semantici di Power BI. Per altre informazioni su questa opzione e sull'effetto della disabilitazione, vedere i paragrafi seguenti.

Inoltre, per le capacità Premium e Premium per utente l'impostazione "endpoint XMLA" deve essere abilitata e impostata su "Sola lettura" o "Lettura/Scrittura".

Gli amministratori tenant possono abilitare o disabilitare le connessioni DirectQuery ai modelli semantici di Power BI nel portale di amministrazione. Anche se questa opzione è abilitata per impostazione predefinita, la disabilitazione impedisce agli utenti di pubblicare nuovi modelli compositi nei modelli semantici di Power BI nel servizio.

I report esistenti che usano un modello composito in un modello semantico di Power BI continuano a funzionare e gli utenti vi possono comunque creare il modello composito usando Desktop, ma non possono pubblicare nel servizio. Al contrario, quando si crea una connessione DirectQuery al modello semantico di Power BI selezionando Apporta modifiche a questo modello, verrà visualizzato il messaggio di avviso seguente:

In questo modo è comunque possibile esplorare il modello semantico nell'ambiente Power BI Desktop locale e creare il modello composito. Tuttavia, non è possibile pubblicare il report nel servizio. Quando si pubblica il report e il modello, viene visualizzato il messaggio di errore seguente e la pubblicazione viene bloccata:

Le connessioni dinamiche ai modelli semantici di Power BI non sono influenzate dall'opzione, né sono connessioni dinamiche o DirectQuery ad Analysis Services. Questi continuano a funzionare indipendentemente dal fatto che l'opzione sia stata disattivata. Inoltre, tutti i report pubblicati che usano un modello composito in un modello semantico di Power BI continueranno a funzionare anche se l'opzione è stata disattivata dopo la pubblicazione.

Creazione di un modello composito in un modello semantico o in un modello

La creazione di un modello composito in un modello semantico di Power BI o in un modello di Analysis Services richiede che il report disponga di un modello locale. È possibile iniziare da una connessione dinamica e aggiungere o aggiornare a un modello locale oppure iniziare con una connessione DirectQuery o dati importati per creare automaticamente un modello locale nel report.

Per visualizzare le connessioni in uso nel modello, controllare la barra di stato in basso a destra in Power BI Desktop. Se si è connessi solo a un'origine di Analysis Services, viene visualizzato un messaggio simile all'immagine seguente:

Se si è connessi a un modello semantico di Power BI, viene visualizzato un messaggio che indica il modello semantico di Power BI a cui si è connessi:

Se si vuole personalizzare i metadati dei campi nel modello semantico con connessione dinamica, selezionare l'opzione Modifica questo modello nella barra di stato. In alternativa, è possibile selezionare il pulsante Modifica questo modello nella barra multifunzione, come illustrato nella figura seguente. Nella visualizzazione report il pulsante Make changes to this model (Modifica questo modello) è nella scheda Modellazione. Nella visualizzazione modello il pulsante si trova nella scheda Home.

Se si seleziona il pulsante, viene visualizzata una finestra di dialogo che conferma l'aggiunta di un modello locale. Selezionare Aggiungi un modello locale per abilitare la creazione di nuove colonne o la modifica dei metadati, per i campi di modelli semantici Power BI o Analysis Services. L'immagine seguente mostra la finestra di dialogo.

Quando si esegue la connessione dinamica a un'origine Analysis Services non è disponibile alcun modello locale. Per usare DirectQuery per le origini con connessione dinamica, ad esempio modelli semantici Power BI e Analysis Services, è necessario aggiungere un modello locale al report. Quando si pubblica un report con un modello locale nel servizio Power BI, viene pubblicato anche un modello semantico per tale modello locale.

Concatenamento

I modelli semantici e i modelli semantici su cui sono basati su quindi formano una catena. Questo processo, denominato concatenamento, consente di pubblicare un report e un modello semantico basato su altri modelli semantici di Power BI.

Si immagini, ad esempio, che un collega pubblichi un modello semantico Power BI denominato Sales and Budget basato su un modello di Analysis Services denominato Sales e lo combini con un foglio di Excel denominato Budget. Quindi si crea e si pubblica un modello semantico composito e un report, denominato Sales and Budget Europe, usando il modello semantico di Power BI Sales and Budget con le proprie modifiche. Questo modello semantico è terzo nella catena.

1. La prima catena è il modello Sales Analysis Services.
2. La seconda catena è il modello semantico composito Sales and Budget di Power BI.
3. La terza catena è il modello semantico composito Sales and Budget Europe di Power BI.

L'immagine seguente illustra questo processo di concatenamento.

La lunghezza della catena nell'immagine precedente è tre, ovvero la lunghezza massima. L'estensione della catena oltre la lunghezza tre non è supportata e genera errori.

Autorizzazioni e licenze

Gli utenti che accedono ai report usando un modello composito devono disporre delle autorizzazioni appropriate per tutti i modelli semantici e i modelli nella catena.

Il proprietario del modello composito richiede l'autorizzazione di compilazione per i modelli semantici usati come origini in modo che altri utenti possano accedere a tali modelli per conto del proprietario. Di conseguenza, la creazione della connessione al modello composito in Power BI Desktop o la creazione del report in Power BI richiedono autorizzazioni di compilazione per i modelli semantici usati come origini.

Gli utenti che visualizzano i report che usano il modello composito richiedono in genere autorizzazioni di lettura per il modello composito stesso e i modelli semantici usati come origini. Le autorizzazioni di compilazione potrebbero essere necessarie se i report si trovano in un'area di lavoro Pro. Queste opzioni del tenant devono essere abilitate per l'utente.

Le autorizzazioni necessarie possono essere illustrate con l'esempio seguente:

• Modello composito A (di proprietà del proprietario A)

  • Origine dati A1: Modello semantico B.
    Il proprietario A deve disporre dell'autorizzazione di compilazione per il modello semantico B per consentire agli utenti di visualizzare il report usando il modello composito A .

• Modello composito C (di proprietà del proprietario C)

  • Origine dati C1: Modello semantico D
    Il proprietario C deve disporre dell'autorizzazione di compilazione per modello semantico D per consentire agli utenti di visualizzare il report usando modello composito C.
  • Origine dati C2: Modello composito A
    Il proprietario C deve disporre dell'autorizzazione di compilazione per il modello composito A e l'autorizzazione lettura per il modello semantico B.

Un utente che visualizza i report usando il modello composito A deve disporre delle autorizzazioni di lettura sia per il modello composito A che per il modello semantico B, mentre un utente che visualizza i report con il modello composito C deve disporre delle autorizzazioni di lettura per il modello composito C, il modello semantico D, il modello composito A e il modello semantico B.

Nota

Fare riferimento a questo post di blog per informazioni importanti sulle autorizzazioni necessarie per i modelli compositi nei modelli semantici di Power BI e nei modelli di Analysis Services.

Se un set di dati nella catena si trova in un'area di lavoro Premium per utente, l'utente che accede richiede una licenza Premium per utente. Se un set di dati nella catena si trova in un'area di lavoro Pro, l'utente che accede richiede una licenza Pro. Se tutti i set di dati nella catena si trovano su capacità Premium o Fabric F64 o una capacità superiore, un utente può accedervi usando una licenza gratuita.

Avviso di sicurezza

L'uso della funzionalità modelli compositi nei modelli semantici di Power BI e nei modelli di Analysis Services offre una finestra di dialogo di avviso di sicurezza, illustrata nell'immagine seguente.

È possibile eseguire il push dei dati da un'origine a un'altra e si tratta dello stesso avviso di sicurezza relativo alla combinazione di DirectQuery e delle origini dell'importazione in un modello di dati. Per altre informazioni su questo comportamento, vedere Uso dei modelli compositi in Power BI Desktop.

Scenari supportati

È possibile compilare modelli compositi usando dati di modelli semantici di Power BI o modelli di Analysis Services per gestire gli scenari seguenti:

• Connessione ai dati da varie origini: importazione (ad esempio file), modelli semantici di Power BI, modelli di Analysis Services
• Creazione di relazioni tra origini dati diverse
• Scrittura di misure che usano i campi di origini dati diverse
• Creazione di nuove colonne per le tabelle da modelli semantici di Power BI o di Analysis Services
• Creazione di oggetti visivi che usano colonne di origini dati diverse
• È possibile rimuovere una tabella dal modello usando l'elenco dei campi per mantenere i modelli il più possibile concisi e snelli (se ci si connette a una prospettiva, non è possibile rimuovere tabelle dal modello)
• È possibile specificare le tabelle da caricare, invece di dover caricare tutte le tabelle quando si vuole solo un subset specifico di tabelle. Vedere Caricamento di un subset di tabelle più avanti in questo documento.
• È possibile specificare se aggiungere eventuali tabelle aggiunte successivamente al modello semantico dopo aver effettuato la connessione nel modello.

Uso di un modello composito basato su un modello semantico

Quando si usa DirectQuery per i modelli semantici di Power BI e Analysis Services, prendere in considerazione le informazioni seguenti:

• Se si aggiornano le origini dati e si verificano errori a causa di conflitti dei nomi di campo o di tabella, Power BI risolve gli errori.

• Non è possibile modificare, eliminare o creare nuove relazioni nello stesso modello semantico di Power BI o nella stessa origine di Analysis Services. Se si dispone dell'accesso di modifica a queste origini, è possibile apportare le modifiche direttamente nell'origine dati.

• Non è possibile modificare i tipi di dati delle colonne caricate da un modello semantico di Power BI o da un'origine Analysis Services. Se è necessario modificare il tipo di dati, modificarlo nell'origine o usare una colonna calcolata.

• Per compilare report nel servizio Power BI su un modello composito basato su un altro modello semantico, è necessario impostare tutte le credenziali.

• Le connessioni a un server SQL Server 2022 e versioni successive di Analysis Services in locale o IAAS richiedono un gateway dati locale (modalità Standard).

• Tutte le connessioni ai modelli semantici di Power BI remoti vengono effettuate usando l'accesso Single Sign-On. L'autenticazione con un'entità servizio non è attualmente supportata.

• Le regole di sicurezza a livello di riga vengono applicate all'origine in cui sono definite, ma non vengono applicate ad altri modelli semantici nel modello. La RLS definita nel report non viene applicata alle origini remote e la RLS impostata nelle origini remote non viene applicata ad altre origini dati. Inoltre, non è possibile definire la sicurezza a livello di riga in una tabella caricata da un'origine remota e la sicurezza a livello di riga definita nelle tabelle locali non filtra le tabelle caricate da un'origine remota.

• Gli indicatori KPI, la sicurezza a livello di riga e le traduzioni non vengono importati dall'origine.

• Quando si usa una gerarchia di date, è possibile che si verifichi un comportamento imprevisto. Per risolvere questo problema, usare una colonna della data. Dopo aver aggiunto una gerarchia di date a un oggetto visivo, è possibile passare a una colonna della data facendo clic sulla freccia verso il basso nel nome del campo e quindi facendo clic sul nome del campo anziché usare Gerarchia data:

  

  Per altre informazioni sull'uso di colonne di data e gerarchie di date, vedere Applicare la data o l'ora automatica in Power BI Desktop.

• La lunghezza massima di una catena di modelli è tre. L'estensione della catena oltre la lunghezza tre non è supportata e genera errori.

• Un flag scoraggiare il concatenamento può essere impostato su un modello per impedire la creazione o l'estensione di una catena. Per altre informazioni, vedere Gestire le connessioni DirectQuery a un modello semantico pubblicato.

• La connessione a un modello semantico di Power BI o a un modello di Analysis Services non viene visualizzata in Power Query.

Quando si usa DirectQuery per i modelli semantici di Power BI e Analysis Services, si applicano le limitazioni seguenti:

• I parametri per i nomi di database e server attualmente sono disabilitati.
• La definizione della sicurezza a livello di riga per le tabelle di un'origine remota non è supportata.
• L'uso di una delle origini seguenti come origine DirectQuery non è supportato:
  • Modelli tabulari di SQL Server Analysis Services (SSAS) precedenti alla versione 2022
  • Modelli multidimensionali di SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Modelli semantici in tempo reale
  • Modelli semantici di esempio
  • Aggiornamento di Excel Online
  • Dati importati da file di Excel o CSV nel servizio
  • Metriche di utilizzo
  • Modelli semantici archiviati in "Area di lavoro personale"
• L'uso di Power BI Embedded con modelli semantici che includono una connessione DirectQuery a un modello di Analysis Services esterno (Azure Analysis Services/SQL Server Analysis Services) non è attualmente supportato.
• La pubblicazione di un report sul Web tramite la funzionalità pubblica sul Web non è supportata.
• I gruppi di calcolo per le origini remote non sono supportati e i risultati delle query non sono definiti.

• Le tabelle calcolate e le colonne calcolate che fanno riferimento a una tabella DirectQuery da un'origine dati con autenticazione Single Sign-On (SSO) sono supportate nel servizio Power BI con una connessione cloud condivisibile assegnata e/o un controllo di accesso granulare.

• Se si rinomina un'area di lavoro dopo la configurazione della connessione DirectQuery, è necessario aggiornare l'origine dati in Power BI Desktop per continuare a funzionare.
• L'aggiornamento automatico della pagina è supportato solo per alcuni scenari, a seconda del tipo di origine dati. Per altre informazioni, vedere l'articolo Aggiornamento automatico delle pagine in Power BI.
• L'assunzione di un modello semantico che utilizza DirectQuery verso altri modelli semantici non è attualmente supportata.
• Come per qualsiasi origine dati DirectQuery, le gerarchie definite in un modello di Analysis Services o in un modello semantico di Power BI non vengono visualizzate quando ci si connette al modello o al modello semantico in modalità DirectQuery tramite Excel.

Quando si usa DirectQuery per i modelli semantici di Power BI e Analysis Services, è necessario prendere in considerazione alcuni altri aspetti:

• Usare colonne a cardinalità bassa nelle relazioni tra gruppi di origine: quando si crea una relazione tra due gruppi di origine diversi, le colonne che partecipano alla relazione (dette anche colonne di join) devono avere una cardinalità bassa, idealmente 50.000 o meno. Questa considerazione si applica alle colonne chiave non stringa; per le colonne chiave stringa, vedere la considerazione seguente.
• Evitare di usare colonne chiave di stringhe di grandi dimensioni nelle relazioni tra gruppi di origine: quando si crea una relazione tra gruppi di origine, evitare di usare colonne stringa di grandi dimensioni come colonne di relazione, in particolare per le colonne con cardinalità maggiore. Quando è necessario usare le colonne stringhe come colonna della relazione, calcolare la lunghezza della stringa prevista per il filtro moltiplicando la cardinalità (C) per la lunghezza media della colonna stringa (A). Assicurarsi che la lunghezza della stringa prevista sia inferiore a 250.000, in modo che A ∗ C < 250.000.

Per altre considerazioni e indicazioni, vedere linee guida per i modelli compositi.

Considerazioni sul tenant

Qualsiasi modello con una connessione DirectQuery a un modello semantico di Power BI o ad Analysis Services deve essere pubblicato nello stesso tenant, particolarmente importante quando si accede a un modello semantico di Power BI o a un modello di Analysis Services usando identità guest B2B, come illustrato nel diagramma seguente. Vedere Utenti guest che possono modificare e gestire il contenuto per trovare l'URL del tenant per la pubblicazione.

Si consideri il diagramma seguente. I passaggi numerati nel diagramma sono descritti nei paragrafi che seguono.

Nel diagramma Ash funziona con Contoso e accede ai dati forniti da Fabrikam. Con Power BI Desktop, Ash crea una connessione DirectQuery a un modello di Analysis Services ospitato nel tenant di Fabrikam.

Per eseguire l'autenticazione, Ash usa un'identità utente guest B2B (passaggio 1 nel diagramma).

Se il report viene pubblicato nel servizio Power BI di Contoso’(passaggio 2), il modello semantico pubblicato nel tenant Contoso non può eseguire correttamente l'autenticazione con il Modello di Analysis Services Fabrikam (passaggio 3). Di conseguenza, il report non funziona.

In questo scenario, poiché il modello di Analysis Services usato è ospitato nel tenant di Fabrikam, il report deve essere pubblicato anche nel tenant di Fabrikam. Dopo aver completato la pubblicazione nel tenant di Fabrikam (passaggio 4) il modello semantico può accedere correttamente al modello di Analysis Services (passaggio 5) e il report funziona correttamente.

Uso della sicurezza a livello di oggetto

Quando un modello composito ottiene dati da un modello semantico di Power BI o Analysis Services tramite DirectQuery e tale modello di origine è protetto dalla sicurezza a livello di oggetto, i consumer del modello composito possono notare risultati imprevisti. Nella sezione seguente viene illustrato il modo in cui questi risultati potrebbero verificarsi.

La sicurezza a livello di oggetto consente agli autori di modelli di nascondere gli oggetti che costituiscono lo schema del modello (ovvero tabelle, colonne, metadati e così via) dai consumer di modelli (ad esempio, un generatore di report o un autore di modelli compositi). Nella configurazione di OLS per un oggetto, l'autore del modello crea un ruolo e quindi rimuove l'accesso all'oggetto per gli utenti assegnati a tale ruolo. Dal punto di vista di tali utenti, l'oggetto nascosto semplicemente non esiste.

OLS viene definito per e applicato al modello di origine. Non può essere definita per un modello composito basato sul modello di origine.

Quando un modello composito si basa su un modello semantico di Power BI protetto da OLS o su un modello di Analysis Services tramite connessione DirectQuery, lo schema del modello di origine viene copiato nel modello composito. Ciò che viene copiato dipende da ciò che all'autore del modello composito è consentito vedere nel modello di origine in base alle regole OLS applicabili. I dati non vengono copiati nel modello composito, ma vengono sempre recuperati tramite DirectQuery dal modello di origine quando necessario. In altre parole, il recupero dei dati torna sempre al modello di origine, in cui si applicano le regole OLS.

Poiché il modello composito non è protetto dalle regole OLS, gli oggetti visualizzati dai consumer del modello composito sono quelli che l'autore del modello composito potrebbe visualizzare nel modello di origine anziché quello a cui potrebbero avere accesso. Ciò potrebbe comportare le situazioni seguenti:

• Un utente che esamina il modello composito potrebbe visualizzare gli oggetti nascosti nel modello di origine da OLS.
• Al contrario, potrebbero NON visualizzare un oggetto nel modello composito che possono vedere nel modello di origine, perché tale oggetto è stato nascosto dall'autore del modello composito dalle regole OLS che controllano l'accesso al modello di origine.

Un punto importante è che, nonostante il caso descritto nel primo punto elenco, i consumer del modello composito non vedono mai i dati effettivi che non dovrebbero vedere, perché i dati non si trovano nel modello composito. Invece, a causa di DirectQuery, viene recuperato in base alle esigenze dal modello semantico di origine, in cui OLS blocca l'accesso non autorizzato.

Tenendo presente questo contesto, prendere in considerazione lo scenario seguente:

1. Admin_user ha pubblicato un modello semantico aziendale usando un modello semantico di Power BI o un modello di Analysis Services con una tabella Cliente e una tabella Territorio. Admin_user pubblica il modello semantico nel servizio Power BI e imposta le regole OLS che hanno l'effetto seguente:

   • Gli utenti finanziari non possono visualizzare la tabella Cliente
   • Gli utenti di marketing non possono visualizzare la tabella Territorio

2. Finance_user pubblica un modello semantico denominato "Modello semantico Finanze personali" e un report denominato "Report delle Finanze personali" che si connette tramite DirectQuery al modello semantico aziendale pubblicato nel passaggio 1. Il report Finanze personali include un oggetto visivo che usa una colonna della tabella Territorio.

3. Marketing_user apre il report Finanze personali. L'oggetto visivo che usa la tabella Territorio viene visualizzato, ma restituisce un errore, perché quando il report viene aperto, DirectQuery tenta di recuperare i dati dal modello di origine usando le credenziali del Marketing_user, a cui viene impedito di visualizzare la tabella Territorio in base alle regole OLS impostate nel modello semantico dell'organizzazione.

4. Marketing_user crea un nuovo report denominato "Report marketing" che usa il modello semantico Finanze personali come origine. L'elenco dei campi mostra le tabelle e le colonne a cui Finance_user ha accesso. Di conseguenza, la tabella Territorio viene visualizzata nell'elenco dei campi, mentre la tabella Cliente no. Tuttavia, quando il Marketing_user tenta di creare un oggetto visivo che usa una colonna dalla tabella Territorio, viene restituito un errore, perché a quel punto DirectQuery tenta di recuperare dati dal modello di origine usando le credenziali di Marketing_user e le regole OLS attivano nuovamente e bloccano l'accesso. La stessa cosa accade quando Marketing_user crea un nuovo modello semantico e un report che si connettono al modello semantico Finanze personali con una connessione DirectQuery. Viene visualizzata la tabella Territorio nell'elenco dei campi, poiché è ciò che Finance_user potrebbe vedere, ma quando tentano di creare un oggetto visivo che usa tale tabella, vengono bloccati dalle regole OLS nel modello semantico aziendale.

5. Si supponga ora che Admin_user aggiorni le regole OLS nel modello semantico aziendale per impedire a Finanze personali di visualizzare la tabella Territorio.

6. Le regole OLS aggiornate vengono riflesse solo nel modello semantico Finance quando viene aggiornato. Pertanto, quando il Finance_user aggiorna il modello semantico Finanze personali, la tabella Territorio non viene più visualizzata nell'elenco dei campi e l'oggetto visivo nel report Finanze personali che usa una colonna della tabella Territorio restituisce un errore per Finance_user, perché non è ora consentito accedere alla tabella Territorio.

Per concludere:

• I consumer di un modello composito visualizzano i risultati delle regole OLS applicabili all'autore del modello composito al momento della creazione del modello. Pertanto, quando viene creato un nuovo report in base al modello composito, l'elenco dei campi mostra le tabelle a cui l'autore del modello composito aveva accesso al momento della creazione del modello, indipendentemente da ciò a cui l'utente corrente ha accesso nel modello di origine.
• Le regole OLS non possono essere definite nel modello composito stesso.
• Un consumer di un modello composito non visualizzerà mai i dati effettivi che non dovrebbe visualizzare, perché le regole OLS pertinenti nel modello di origine lo bloccano quando DirectQuery tenta di recuperare i dati usando le credenziali.
• Se il modello di origine aggiorna le regole OLS, tali modifiche hanno effetto solo sul modello composito quando viene aggiornato.

Caricamento di un subset di tabelle da un modello semantico di Power BI o da un modello di Analysis Services

Quando ci si connette a un modello sematico di Power BI o a un modello di Analysis Services tramite una connessione DirectQuery, è possibile decidere a quali tabelle connettersi. È anche possibile scegliere di aggiungere automaticamente qualsiasi tabella che possa essere aggiunta al modello semantico o al modello dopo aver effettuato la connessione al modello. Quando ci si connette a una prospettiva, il modello contiene tutte le tabelle nel modello semantico e tutte le tabelle non incluse nella prospettiva vengono nascoste. Inoltre, tutte le tabelle che potrebbero essere aggiunte alla prospettiva verranno aggiunte automaticamente. Nel menu Impostazioni è possibile decidere di connettersi automaticamente alle tabelle aggiunte al modello semantico dopo aver configurato la connessione.

Questa finestra di dialogo non viene visualizzata per le connessioni dinamiche.

Nota

Questa finestra di dialogo verrà visualizzata solo se si aggiunge una connessione DirectQuery a un modello semantico di Power BI o a un modello di Analysis Services esistente. È anche possibile aprire questa finestra di dialogo modificando la connessione DirectQuery al modello semantico di Power BI o al modello Analysis Services nelle impostazioni dell'origine dati dopo averla creata.

Configurazione delle regole di deduplicazione

È possibile specificare regole di deduplicazione per mantenere univoci i nomi di misura e tabella in un modello composito usando l'opzione Impostazioni nella finestra di dialogo illustrata in precedenza:

Nell'esempio precedente è stato aggiunto "(marketing)" come suffisso a qualsiasi nome di tabella o misura in conflitto con un'altra origine nel modello composito. È possibile:

• immettere un testo da aggiungere al nome di tabelle o misure in conflitto
• specificare se si desidera aggiungere il testo alla tabella o al nome della misura come prefisso o suffisso
• applicare la regola di deduplicazione a tabelle, misure o entrambi
• Scegliere di applicare la regola di deduplicazione solo quando si verifica un conflitto di nomi o applicarla sempre. Il valore predefinito consiste nell'applicare la regola solo quando si verifica la duplicazione. In questo esempio, qualsiasi tabella o misura dall'origine di marketing che non ha un duplicato nell'origine di vendita non otterrà una modifica del nome.

Dopo aver stabilito le connessioni e configurato la regola di deduplicazione, l'elenco dei campi mostrerà sia "Customer" che "Customer (marketing)" in base alla regola di deduplicazione configurata nell'esempio:

Se non si specifica una regola di deduplicazione o le regole di deduplicazione specificate non risolvono il conflitto di nomi, le regole di deduplicazione standard vengono comunque applicate. Le regole di deduplicazione standard aggiungono un numero al nome dell'elemento in conflitto. Se si verifica un conflitto di nomi nella tabella 'Customer' una delle tabelle 'Customer' viene rinominata 'Customer 2'.

Modifiche XMLA e modelli compositi

Quando si modifica un modello semantico utilizzando XMLA, è necessario aggiornare l'insieme ChangedProperties e PBI_RemovedChildren affinché l'oggetto modificato includa le proprietà modificate o rimosse. Se non si esegue l'aggiornamento, gli strumenti di modellazione di Power BI potrebbero sovrascrivere le modifiche alla successiva sincronizzazione dello schema con l'origine dati.

Altre informazioni sui tag di derivazione degli oggetti del modello semantico sono disponibili nell'articolo tag di derivazione per i modelli semantici di Power BI.

Considerazioni e limitazioni

I modelli compositi presentano alcune considerazioni e limitazioni:

Connessioni in modalità mista: quando si usa una connessione in modalità mista che contiene dati online (ad esempio un modello semantico di Power BI) e un modello semantico locale (ad esempio una cartella di lavoro di Excel), è necessario che venga stabilito il mapping del gateway per la corretta visualizzazione degli oggetti visivi.

Attualmente l'aggiornamento incrementale è supportato solo per i modelli compositi che si connettono a origini dati SQL, Oracle e Teradata.

Non è possibile usare modelli compositi con le origini tabulari Live Connect seguenti:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services precedente alla versione 2022
• Metriche di utilizzo (area di lavoro personale)

L'uso di modelli semantici di streaming nei modelli compositi non è supportato.

Le limitazioni esistenti per DirectQuery sono valide anche quando si usano i modelli compositi. Molte di queste limitazioni si riferiscono attualmente a ogni singola tabella, a seconda della modalità di archiviazione della tabella. Ad esempio, una colonna calcolata in una tabella di importazione può fare riferimento ad altre tabelle che non si trovano in DirectQuery, ma una colonna calcolata in una tabella DirectQuery può comunque fare riferimento solo alle colonne della 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, la funzionalità Informazioni rapide non è disponibile per un modello se per una delle tabelle all'interno di esso è impostata la modalità di archiviazione DirectQuery.

Se si usa la sicurezza a livello di riga in un modello composito con alcune delle tabelle in modalità DirectQuery, è necessario aggiornare il modello per applicare nuovi aggiornamenti dalle tabelle DirectQuery. Ad esempio, se una tabella Users in modalità DirectQuery contiene nuovi record utente nell'origine, i nuovi record verranno inclusi solo dopo l'aggiornamento successivo del modello. Il servizio Power BI memorizza nella cache la query Users per migliorare le prestazioni e non ricarica i dati dall'origine fino al successivo aggiornamento manuale o pianificato.

Contenuto correlato

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

• Applicare le relazioni molti-a-molti in Power BI Desktop
• Gestire la modalità di archiviazione in Power BI Desktop
• DirectQuery in Power BI
• Origini dati di Power BI
• Relazioni nei modelli in Power BI Desktop