Usare 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: consentono di includere in un report due o più connessioni dati da gruppi di origine diversi, ad esempio una o più connessioni DirectQuery e una connessione di importazione, due o più connessioni DirectQuery o qualsiasi altra 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. Annulla anche 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 gli oggetti visivi che 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 Uso di 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.

Nota

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

Esempio di un modello composito

Per un esempio di modello composito, esaminare un report connesso 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:

Visualizzazione delle relazioni per i modelli compositi

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.

Oggetto visivo basato sui dati

E se fossero disponibili dati in un foglio di calcolo di Office Excel 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 origini aggiuntive. 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).

Finestra Strumento di navigazione

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.

Visualizzazione dei campi delle tabelle

Allo stesso modo, nella visualizzazione Relazioni in Power BI Desktop è ora disponibile una tabella aggiuntiva denominata ProductManagers.

Visualizzazione delle relazioni delle tabelle

È 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.

Finestra

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

Visualizzazione della nuova relazione

È 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:

Riquadro Campi

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:

Finestra Strumento di navigazione

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

Visualizzazione Relazioni con molte tabelle

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.

Immagine che mostra altri dati

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.

Descrizione comando che visualizza la modalità di archiviazione

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 fare clic su tale termine nella barra di stato e passare facilmente a tutte le tabelle da importare.

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

Nota

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

Tabelle calcolate

È possibile aggiungere tabelle calcolate a un modello 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.

Script che mostra le implicazioni per la sicurezza

Per questo motivo, le informazioni archiviate nel foglio di calcolo vengono 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 che viene 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 (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.

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 Informazioni sull'uso di DirectQuery in Power BI.

Esistono considerazioni aggiuntive 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 l'importo totale delle vendite per un set di Product Manager selezionati dovrà prima trovare i Prodotti gestiti da tali product manager. 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.

  • Query di origine che esegue query a un livello inferiore di granularità, con i dati aggregati in un secondo momento in locale: poiché 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 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 origine, una per ogni gruppo per valore: quando l'aggregazione usa DistinctCount ed è 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 gruppo per valore.

    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 invierà due query di origine, anziché una.

Gruppi di origine

Un gruppo di origine è una raccolta di elementi (tabelle, relazioni e così via) 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. Considera gli esempi che seguono:

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

Diagramma che mostra i gruppi di origine Import and Sales contenenti le tabelle delle rispettive origini.

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

Diagramma che mostra i gruppi di origine Import, Sales e Inventory contenenti le tabelle delle rispettive origini.

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 e relazioni di origine

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. 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.

Di seguito, ad esempio, sono state aggiunte tre relazioni tra gruppi di origine, correlando le tabelle tra i vari gruppi di origine insieme:

Diagramma che mostra i gruppi di origine Import, Sales e Inventory contenenti le tabelle delle rispettive origini e relazioni tra i gruppi di origine, come descritto in precedenza.

Locale e remoto

Qualsiasi elemento che si trova 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 arricchimento nell'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 "Import" e viene 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 di raggruppare le espressioni di misura comuni. I casi d'uso tipici sono calcoli di business intelligence per le gerarchie temporali in cui si vuole fornire la possibilità di passare da effettivi a calcoli da inizio mese a data, da trimestre a data o da anno a data. Quando si utilizzano modelli compositi, è importante essere consapevoli dell'interazione tra 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, indipendentemente dal fatto che la misura sia 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 esclusivamente ma fa riferimento a 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 ad esempio quanto segue:

  • 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 è interessata 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. Ciò 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 i 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.

Considerazioni e limitazioni

Esistono alcune limitazioni per questa versione dei modelli compositi:

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

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

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 per una tabella di importazione può fare riferimento ad altre tabelle, ma una colonna calcolata per una tabella di DirectQuery può fare riferimento solo alle colonne nella stessa tabella. Altre limitazioni si applicano al modello nel suo complesso, se una qualsiasi delle tabelle all'interno del modello è in modalità DirectQuery. Ad esempio, la funzionalità QuickInsights non è disponibile in un modello se una delle tabelle all'interno ha una modalità di archiviazione di DirectQuery.

Passaggi successivi

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