Usare i modelli compositi in Power BI Desktop

In precedenza in Power BI Desktop, quando è stata usata una DirectQuery in un report, non sono state consentite altre connessioni dati, se DirectQuery o importate, per tale report. Con i modelli compositi, tale restrizione viene rimossa. Un report può includere facilmente connessioni dati da più di una connessione DirectQuery o importare dati, 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 in dettaglio i modelli compositi.

• Relazioni molti-a-molti: con i modelli compositi è possibile stabilire relazioni molti-a-molti tra tabelle. Questo approccio rimuove 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 relazioni molti-molti in Power BI Desktop.

• Archiviazione modalità: è ora possibile specificare quali oggetti visivi eseguono query su origini dati back-end. Questa funzionalità consente di migliorare le prestazioni e ridurre il carico back-end. In precedenza, anche oggetti visivi semplici, ad esempio filtri dei dati, avviava query alle origini back-end. Per altre informazioni, vedere Gestire la modalità di archiviazione in Power BI Desktop.

Usare 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 queste connessioni dati in due modi:

• Importando dati in Power BI, che è il modo più comune per ottenere i dati.
• Connettendosi direttamente ai dati nel repository di origine originale 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 con estensione pbix di Power BI Desktop che esegue una o entrambe le azioni seguenti:

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

Ad esempio, usando 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 i dati di più di un'origine DirectQuery o che combina DirectQuery con i dati di importazione viene definito modello composito.

È possibile creare relazioni tra tabelle come sempre, anche quando tali tabelle provengono da origini diverse. Tutte le relazioni tra origini vengono create con cardinalità molti-a-molti, indipendentemente dalla cardinalità effettiva. È possibile modificarli 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 one lato dal many lato. È anche possibile che si verifichi un impatto sulle prestazioni rispetto alle relazioni molti-a-molti all'interno della stessa origine.

Nota

All'interno del contesto dei modelli compositi, tutte le tabelle importate sono effettivamente una singola origine, indipendentemente dalle origini dati sottostanti effettive.

Esempio di modello composito

Per un esempio di modello composito, prendere in considerazione un report connesso a un data warehouse aziendale in SQL Server tramite DirectQuery. In questo caso, il data warehouse contiene i dati Sales by Country, Quarter e Bike (Product), come illustrato nell'immagine seguente:

A questo punto, è possibile creare oggetti visivi semplici usando i campi di questa origine. L'immagine seguente mostra le vendite totali di ProductName per un trimestre selezionato.

Ma cosa accade se si dispone di dati in un foglio di calcolo di Excel relativo al product manager assegnato a ogni prodotto, insieme alla priorità di marketing? Se si vuole visualizzare Sales Amount by Product Manager, potrebbe non essere possibile aggiungere questi dati locali al data warehouse aziendale. Oppure potrebbero essere necessari mesi al meglio.

Potrebbe essere possibile importare i dati di vendita dal data warehouse anziché usare DirectQuery. E i dati di vendita possono quindi essere combinati con i dati importati dal foglio di calcolo. Tuttavia, questo approccio è irragionevole, per i motivi che hanno portato all'uso di DirectQuery in primo luogo. I motivi possono includere:

• Alcune combinazioni delle regole di sicurezza applicate nell'origine sottostante.
• Deve essere in grado di visualizzare i dati più recenti.
• Scala più ampia dei dati.

Ecco dove vengono inseriti i modelli compositi. I modelli compositi consentono di connettersi al data warehouse usando DirectQuery e quindi usare Recupera dati per altre origini. In questo esempio viene prima stabilita la connessione DirectQuery al data warehouse aziendale. Si usa Recupera dati, scegliere Excel e quindi passare al foglio di calcolo che contiene i dati locali. Infine, importiamo il foglio di calcolo che contiene i nomi dei prodotti, il responsabile vendite assegnato e la priorità.

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

Analogamente, nella visualizzazione Relazione in Power BI Desktop viene ora visualizzata un'altra tabella denominata ProductManagers.

È ora necessario correlare queste tabelle alle altre tabelle nel modello. Come sempre, viene creata una relazione tra la tabella Bike di SQL Server e la tabella ProductManagers importata. Ovvero, la relazione è tra Bike[ProductName] e ProductManagers[ProductName]. Come illustrato in precedenza, tutte le relazioni che passano tra l'origine e la cardinalità molti-a-molti.

Dopo aver stabilito questa relazione, questa relazione viene visualizzata nella visualizzazione Relazione in Power BI Desktop, come previsto.

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

Nell'esempio seguente viene visualizzato un caso comune di una tabella delle dimensioni , ad esempio Product o Customer, estesa con alcuni dati aggiuntivi importati da un'altra posizione. È anche possibile che le tabelle usino DirectQuery per connettersi a varie origini. Per continuare con l'esempio, si supponga che le destinazioni di vendita per paese e periodo siano archiviate in un database di reparto separato. Come di consueto, è possibile usare Recupera dati per connettersi a tali dati, come illustrato nell'immagine seguente:

Come in precedenza, è possibile creare relazioni tra la nuova tabella e altre tabelle nel modello. È quindi possibile creare oggetti visivi che combinano i dati della tabella. Si esaminerà di nuovo la visualizzazione Relazioni , in cui sono stati stabilite le nuove relazioni:

L'immagine successiva si basa sui nuovi dati e sulle relazioni create. L'oggetto visivo in basso a sinistra mostra il totale Sales Amount rispetto a 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 importa. 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 mostra la modalità di archiviazione per la tabella SalesTargets .

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

Per qualsiasi file di Power BI Desktop (file con estensione pbix ) che contiene alcune tabelle da DirectQuery e alcune tabelle di importazione, la barra di stato visualizza una modalità di archiviazione denominata Misto. È possibile selezionare il 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 di analisi dei dati (DAX) che definiscono la tabella calcolata possono fare riferimento a tabelle importate o DirectQuery o a una combinazione dei due.

Le tabelle calcolate vengono sempre importate e i relativi 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 nella servizio Power BI usando questa funzionalità. Per altre informazioni, vedere la sezione Uso di un modello composito basato su un modello semantico in questo articolo.

Implicazioni per la sicurezza

I modelli compositi hanno 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) da Product Manager invia una query SQL al database relazionale Sales. La query SQL potrebbe contenere i nomi dei Product Manager e dei relativi prodotti associati.

Le informazioni archiviate nel foglio di calcolo vengono quindi incluse in una query inviata al database relazionale. Se queste informazioni sono riservate, è consigliabile prendere in considerazione le implicazioni per la sicurezza. In particolare, considerare i punti seguenti:

• Qualsiasi amministratore del database che può visualizzare tracce o log di controllo potrebbe visualizzare queste informazioni, anche senza autorizzazioni per i dati nell'origine originale. In questo esempio, l'amministratore deve disporre delle autorizzazioni per il file di Excel.

• Le impostazioni di crittografia per ogni origine devono essere considerate. Si vuole evitare di recuperare informazioni da un'origine tramite una connessione crittografata e quindi inavvertitamente includerla in una query inviata a un'altra origine da una connessione non crittografata.

Per consentire la conferma che sono state considerate implicazioni per la sicurezza, Power BI Desktop visualizza un messaggio di avviso quando si crea un modello composito.

Inoltre, se un autore aggiunge Table1 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 dalla sicurezza a livello di riga.

Per motivi simili, 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 un'origine, usando le credenziali dell'utente che apre il file, verranno inviate a un'altra origine dati come parte della query. Le informazioni potrebbero essere visualizzate dall'autore dannoso 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. L'avviso è simile a quello visualizzato quando si apre un file che contiene query SQL native.

Implicazioni per le prestazioni

Quando si usa DirectQuery, è consigliabile considerare sempre le prestazioni, principalmente per assicurarsi che l'origine back-end disponga di risorse sufficienti per offrire un'esperienza ottimale per gli utenti. Un'esperienza ottimale significa che gli oggetti visivi vengono aggiornati in cinque secondi o meno. Per altri consigli sulle prestazioni, vedere DirectQuery in Power BI.

L'uso di modelli compositi aggiunge altre considerazioni sulle prestazioni. Un singolo oggetto visivo può comportare l'invio di query a più origini, che spesso passano i risultati da una query a una seconda origine. Questa situazione può comportare le seguenti forme di esecuzione:

• Query di origine che include un numero elevato di valori letterali: ad esempio, un oggetto visivo che richiede l'importo totale delle vendite per un set di Product Manager selezionati dovrà prima trovare i Prodotti gestiti da tali responsabili dei prodotti. Questa sequenza deve verificarsi prima che l'oggetto visivo invii una query SQL che include tutti gli ID prodotto in una WHERE clausola .

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

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

  Un oggetto visivo che richiede un conteggio distinto di CustomerAccountNumber dalla tabella SQL Server importata dai Product Manager importati dal foglio di calcolo deve passare i dettagli dalla tabella Product Manager nella query inviata a SQL Server. Su altre origini, Redshift, ad esempio, questa azione non è verificabile. Al contrario, ci sarebbe una query SQL inviata per ogni Sales Manager, fino a un limite pratico, a questo punto la query avrebbe esito negativo.

Ognuno di questi casi ha implicazioni specifiche sulle prestazioni e i dettagli esatti variano per ogni origine dati. Anche se la cardinalità delle colonne usate nella relazione che unisce le due origini rimane bassa, alcune migliaia di prestazioni non devono essere interessate. Man mano che questa cardinalità cresce, è consigliabile prestare maggiore attenzione all'impatto sulle prestazioni risultanti.

Inoltre, l'uso di relazioni molti-a-molti significa che le query separate devono essere inviate all'origine sottostante per ogni livello totale o subtotale, anziché aggregare i valori dettagliati localmente. 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 verranno 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.

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 di origine. 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, correlate 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 quello mensile, da trimestre a data o da inizio anno. 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 verrà 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. Gli autori di report che vogliono combinare i dati del modello semantico aziendale con altri dati di cui sono proprietari, ad esempio un foglio di calcolo di Excel, o vogliono personalizzare o arricchire i metadati dal modello semantico aziendale, troveranno questa funzionalità particolarmente utile.

Gestione di modelli compositi in 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 Apporta 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 impedirà agli utenti di pubblicare nuovi modelli compositi nei modelli semantici di Power BI nel servizio.

I report esistenti che sfruttano un modello composito in un modello semantico di Power BI continueranno a funzionare e gli utenti possono comunque creare il modello composito in usando Desktop, ma non saranno in grado di 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 sarà possibile pubblicare il report nel servizio. Quando si pubblica il report e il modello, verrà visualizzato il messaggio di errore seguente e la pubblicazione verrà bloccata:

Si noti che le connessioni dinamiche ai modelli semantici di Power BI non sono influenzate dall'opzione, né sono connessioni dinamiche o DirectQuery ad Analysis Services. Questi continueranno a funzionare indipendentemente dal fatto che l'opzione sia stata disattivata. Inoltre, tutti i report pubblicati che sfruttano 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 i dati importati, che crea automaticamente un modello locale nel report.

Per vedere quali connessioni vengono usate nel modello, controllare la barra di stato nell'angolo in basso a destra di 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:

Per personalizzare i metadati dei campi nel modello semantico connesso live, selezionare Apporta modifiche a questo modello nella barra di stato. In alternativa, è possibile selezionare il pulsante Apporta modifiche a questo modello nella barra multifunzione, come illustrato nell'immagine seguente. In Visualizzazione report il pulsante Apporta modifiche a questo modello nella scheda Modellazione . In Visualizzazione modello il pulsante si trova nella scheda Home .

Selezionando 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 da modelli semantici di Power BI o Analysis Services. L'immagine seguente mostra la finestra di dialogo visualizzata.

Quando si è connessi in tempo reale a un'origine di Analysis Services, non esiste alcun modello locale. Per usare DirectQuery per origini connesse in tempo reale, ad esempio modelli semantici di Power BI e Analysis Services, è necessario aggiungere un modello locale al report. Quando si pubblica un report con un modello locale nella servizio Power BI, viene pubblicato 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 basato su altri modelli semantici di Power BI, una funzionalità che in precedenza non era possibile.

Si supponga, ad esempio, che il collega pubblica un modello semantico di Power BI denominato Sales and Budget basato su un modello di Analysis Services denominato Sales e lo combina con un foglio di Excel denominato Budget.

Quando si pubblica un nuovo report (e un modello semantico) denominato Sales and Budget Europe basato sul modello semantico Sales and Budget Power BI pubblicato dal collega, apportando altre modifiche o estensioni, si aggiunge in modo efficace un report e un modello semantico a una catena di lunghezza tre, che ha iniziato con il modello Sales Analysis Services, e termina con il modello semantico Di Power BI Sales and Budget Europe . L'immagine seguente visualizza questo processo di concatenamento.

La catena nell'immagine precedente è di lunghezza tre, ovvero la lunghezza massima. L'estensione oltre una lunghezza della catena di 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 il modello semantico D per consentire agli utenti di visualizzare il report usando il modello composito C.
  • Origine dati C2: Modello composito A
    Il proprietario C deve disporre dell'autorizzazione di compilazione per il modello composito A el'autorizzazione lettura per il modello semantico B.

Un utente che visualizza i report usando il modello composito A deve disporredelle autorizzazioni di lettura sia per il modello composito Ache 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 della catena si trovano su capacità Premium o Infrastruttura F64 o maggiore, un utente può accedervi usando una licenza gratuita.

Avviso di sicurezza

L'uso della funzionalità DirectQuery per i modelli semantici di Power BI e Analysis Services visualizzerà una finestra di dialogo di avviso di sicurezza, illustrata nell'immagine seguente.

È possibile eseguire il push dei dati da un'origine dati a un'altra, ovvero lo stesso avviso di sicurezza per combinare DirectQuery e importare origini in un modello di dati. Per altre informazioni su questo comportamento, vedere Uso di 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: importare (ad esempio file), modelli semantici di Power BI, modelli di Analysis Services
• Creazione di relazioni tra origini dati diverse
• Scrittura di misure che usano 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ù conciso possibile e snella (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 desidera 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, tenere presente quanto segue:

• Se si aggiornano le origini dati e si verificano errori con nomi di campo o tabella in conflitto, Power BI risolve automaticamente 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 in un modello composito basato su un altro modello semantico, è necessario impostare tutte le credenziali.

• Connessione ions a un server SQL Server 2022 e versioni successive 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 verranno applicate all'origine in cui sono definite, ma non verranno applicate ad altri modelli semantici nel modello. La sicurezza a livello di riga definita nel report non verrà applicata alle origini remote e la sicurezza a livello di riga impostata su origini remote non verrà 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 verranno importati dall'origine.

• È possibile che venga visualizzato un comportamento imprevisto quando si usa una gerarchia di date. Per risolvere questo problema, usare invece una colonna data. Dopo aver aggiunto una gerarchia di date a un oggetto visivo, è possibile passare a una colonna data facendo clic sulla freccia giù nel nome del campo e quindi facendo clic sul nome del campo invece di 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 oltre la lunghezza della catena di tre non è supportata e genera errori.

• Un flag di concatenamento sconsigliabile 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 verrà 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 sono attualmente disabilitati.
• La definizione della sicurezza a livello di riga nelle tabelle da 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 non è attualmente supportato.
• La pubblicazione di un report sul Web tramite la funzionalità pubblica sul Web non è supportata.
• I gruppi di calcolo sulle origini remote non sono supportati, con risultati di query non definiti.
• Le tabelle calcolate non sono supportate nel servizio usando questa funzionalità. Il tentativo di eseguire un aggiornamento su un modello semantico con una tabella calcolata o una colonna calcolata che fa riferimento a un'origine dati DirectQuery genererà un messaggio di errore "La credenziale Single Sign-On (SSO) non viene fornita".
• 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 delle pagine è supportato solo per alcuni scenari, a seconda del tipo di origine dati. Per altre informazioni, vedere l'articolo Aggiornamento automatico della pagina in Power BI .
• L'uso di un modello semantico che usa 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 verranno visualizzate durante la connessione 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 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. Usando 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 di Fabrikam (passaggio 3). Di conseguenza, il report non funzionerà.

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 funzionerà 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 potrebbero 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 l'autore del modello composito è consentito vedere nel modello di origine in base alle regole OLS applicabili. I dati stessi 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 vedranno mai i dati effettivi che non dovrebbero vedere, perché i dati non si trovano effettivamente nel modello composito. Piuttosto, 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, considerare lo scenario seguente:

1. Amministrazione_user ha pubblicato un modello semantico aziendale usando un modello semantico di Power BI o un modello di Analysis Services con una tabella Customer e una tabella Territory. Amministrazione_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 Customer
   • Gli utenti di marketing non possono visualizzare la tabella Territory

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

3. Marketing_user apre il report Finance. L'oggetto visivo che usa la tabella Territory 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, che viene impedito di visualizzare la tabella Territory 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 Finance come origine. L'elenco dei campi mostra le tabelle e le colonne a cui Finance_user ha accesso. Di conseguenza, la tabella Territory viene visualizzata nell'elenco dei campi, ma la tabella Customer non è. Tuttavia, quando il Marketing_user tenta di creare un oggetto visivo che sfrutta una colonna dalla tabella Territory, 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 nuovo report che si connettono al modello semantico Finance con una connessione DirectQuery: visualizzano la tabella Territory nell'elenco dei campi, poiché questo è ciò che Finance_user potrebbe vedere, ma quando tentano di creare un oggetto visivo che sfrutta tale tabella, verranno bloccati dalle regole OLS nel modello semantico aziendale.

5. Si supponga ora che Amministrazione_user aggiorna le regole OLS nel modello semantico aziendale per impedire a Finance di visualizzare la tabella Territory.

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

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 mostrerà le tabelle a cui l'autore del modello composito aveva accesso al momento della creazione del modello, indipendentemente da ciò che l'utente corrente ha accesso a 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 dovrebbero visualizzare, perché le regole OLS pertinenti nel modello di origine li bloccherà quando DirectQuery tenta di recuperare i dati usando le credenziali.
• Se il modello di origine aggiorna le regole OLS, tali modifiche avranno 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 semantico di Power BI o a un modello di Analysis Services usando 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 conterrà tutte le tabelle nel modello semantico e tutte le tabelle non incluse nella prospettiva verranno 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 verrà 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 a un modello 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 origine dati dopo averla creata.

Configurazione delle regole di deduplicazione

È possibile specificare le 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 si è deciso di aggiungere "(marketing)" come suffisso a qualsiasi nome di tabella o misura in conflitto con un'altra origine nel modello composito. Si noti che è 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 marketing che non dispone di un duplicato nell'origine vendite 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 del nome, le regole di deduplicazione standard vengono comunque applicate. Le regole di deduplicazione standard aggiungono un numero al nome dell'elemento in conflitto. In caso di conflitto di nomi nella tabella 'Customer' una delle tabelle 'Customer' verrà rinominata 'Customer 2'.

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 visualizzare correttamente gli oggetti visivi.

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

Con i modelli compositi non è possibile usare le seguenti origini live Connessione tabulari:

• 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 di DirectQuery si applicano ancora quando si usano modelli compositi. Molte di queste limitazioni sono ora per 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 delle tabelle all'interno del modello è DirectQuery. Ad esempio, la funzionalità QuickInsights non è disponibile in un modello se una delle tabelle all'interno ha una modalità di archiviazione di DirectQuery.

Contenuto correlato

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

• Applicare 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 tra modelli in Power BI Desktop