Usare i modelli compositi in Power BI Desktop

In precedenza, quando si usava DirectQuery in un report in Power BI Desktop, non erano consentite altre connessioni dati per tale report, sia di tipo DirectQuery che Importa. Con i modelli compositi questa restrizione non esiste più. Un report può includere senza problemi connessioni dati da più di una connessione dati DirectQuery o Importa, in qualsiasi combinazione scelta.

La funzionalità dei modelli compositi in Power BI Desktop è costituita da tre funzionalità correlate:

• Modelli compositi: consente a un report di avere due o più connessioni dati da gruppi di origine diversi. Questi gruppi di origine possono essere una o più connessioni DirectQuery e una connessione di importazione, due o più connessioni DirectQuery o qualsiasi combinazione. Questo articolo descrive i modelli compositi in dettaglio.

• Relazioni molti-a-molti: con i modelli compositi è possibile stabilire relazioni molti-a-molti tra le tabelle. Questo approccio consente di rimuovere i requisiti per i valori univoci nelle tabelle. oltre a eliminare le soluzioni alternative precedenti, ad esempio l'introduzione di nuove tabelle solo per stabilire relazioni. Per altre informazioni, vedere Applicare le relazioni molti-a-molti in Power BI Desktop.

• Modalità di archiviazione: è ora possibile specificare quali oggetti visivi eseguono query sulle origini dati back-end. con conseguente miglioramento delle prestazioni e riduzione del carico per il back-end. In precedenza, anche oggetti visivi semplici, come i filtri dei dati, attivavano query per le origini back-end. Per altre informazioni, vedere Gestire la modalità di archiviazione in Power BI Desktop.

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 che combina dati da più di un'origine DirectQuery o combina origini DirectQuery con dati importati è noto come modello 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.

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.

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.

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 rappresenta (Sales Amount) per Product Manager invia una query SQL al database relazionale Sales. 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 essere eseguita prima che l'oggetto visivo invii una query SQL che include tutti gli ID di 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 un altro 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 formano una catena. Questo processo, denominato concatenamento, consente di pubblicare un report e un modello semantico basati su altri modelli semantici Power BI, una funzionalità che in precedenza non era disponibile.

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.

Quando si pubblica un nuovo report (e modello semantico) denominato Sales and Budget Europe basato sul set di dati Power BI Sales and Budget pubblicato dal collega, se si apportano altre modifiche o estensioni, si aggiunge un report e un set di dati a una catena di lunghezza tre, che inizia con il modello Sales di Analysis Services e termina con il modello semantico Power BI Sales and Budget Europe. L'immagine seguente illustra questo processo di concatenamento.

La catena nell'immagine precedente è di lunghezza 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.

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 sicurezza a livello di riga definita nel report non viene applicata alle origini remote e la sicurezza a livello di riga impostata per le 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"
• Quando si usa Power BI Embedded con modelli semantici che includono una connessione DirectQuery a un modello di Analysis Services, è necessario includere gli ID modello semantico di origine e l'identità dell'origine dati AAS quando si usa Genera Token.
• 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'uso di un modello semantico che usa la funzionalità DirectQuery per altri modelli semantici non è attualmente supportato.
• 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.

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