DirectQuery in Power BI

In Power BI Desktop o nella servizio Power BI è possibile connettersi a molte origini dati diverse in modi diversi. È possibile importare dati in Power BI, che è il modo più comune per ottenere i dati. È anche possibile connettersi direttamente ad alcuni dati nel repository di origine originale, denominato DirectQuery. Questo articolo illustra principalmente le funzionalità di DirectQuery.

L'articolo illustra:

• Opzioni di connettività dei dati di Power BI diverse.
• Indicazioni su quando usare DirectQuery anziché importare.
• Limitazioni e implicazioni dell'uso di DirectQuery.
• Consigli per l'uso corretto di DirectQuery.
• Come diagnosticare i problemi di prestazioni di DirectQuery.

L'articolo è incentrato sul flusso di lavoro DirectQuery quando si crea un report in Power BI Desktop, ma illustra anche la connessione tramite DirectQuery nel servizio Power BI.

Modalità di connettività dei dati di Power BI

Power BI si connette a un numero elevato di origini dati diverse, ad esempio:

• Servizi online come Salesforce e Dynamics 365.
• Database come SQL Server, Access e Amazon Redshift.
• File semplici in Excel, JSON e altri formati.
• Altre origini dati, ad esempio Spark, siti Web e Microsoft Exchange.

È possibile importare dati da queste origini in Power BI. Per alcune origini, è anche possibile connettersi usando DirectQuery. Per un riepilogo delle origini che supportano DirectQuery, vedere Origini dati supportate da DirectQuery. Le origini abilitate per DirectQuery sono principalmente origini che possono offrire prestazioni di query interattive ottimali.

È consigliabile importare i dati in Power BI laddove possibile. L'importazione sfrutta il motore di query ad alte prestazioni di Power BI e offre un'esperienza estremamente interattiva e completa.

Se non è possibile soddisfare gli obiettivi importando dati, ad esempio se i dati cambiano frequentemente e i report devono riflettere i dati più recenti, è consigliabile usare DirectQuery. DirectQuery è fattibile solo quando l'origine dati sottostante può fornire risultati di query interattive in meno di cinque secondi per una query di aggregazione tipica e può gestire il carico di query generato. Considerare attentamente le limitazioni e le implicazioni dell'uso di DirectQuery.

Le funzionalità di importazione e DirectQuery di Power BI si evolvono nel tempo. Le modifiche che offrono maggiore flessibilità quando si usano i dati importati consentono di importare più spesso ed eliminare alcuni degli svantaggi dell'uso di DirectQuery. Indipendentemente dai miglioramenti, le prestazioni dell'origine dati sottostante sono una considerazione importante quando si usa DirectQuery. Se un'origine dati sottostante è lenta, l'uso di DirectQuery per tale origine rimane non verificabile.

Le sezioni seguenti illustrano le tre opzioni per la connessione ai dati: importazione, DirectQuery e connessione dinamica. La parte restante dell'articolo è incentrata su DirectQuery.

Importare connessioni

Quando ci si connette a un'origine dati come SQL Server e si importano dati in Power BI Desktop, si verificano i risultati seguenti:

• Quando si recuperano inizialmente dati, ogni set di tabelle selezionato definisce una query che restituisce un set di dati. È possibile modificare tali query prima di caricare i dati, ad esempio per applicare filtri, aggregare i dati o unire tabelle diverse.

• Al caricamento, tutti i dati definiti dalle query importano nella cache di Power BI.

• La compilazione di un oggetto visivo all'interno di Power BI Desktop esegue una query sui dati memorizzati nella cache. L'archivio di Power BI garantisce che la query sia veloce e che tutte le modifiche apportate all'oggetto visivo riflettano immediatamente.

• Gli oggetti visivi non riflettono le modifiche apportate ai dati sottostanti nell'archivio dati. È necessario reimportare per aggiornare i dati.

• La pubblicazione del report nel servizio Power BI come file con estensione pbix crea e carica un modello semantico che include i dati importati. È quindi possibile pianificare l'aggiornamento dei dati, ad esempio reimportare i dati ogni giorno. A seconda del percorso dell'origine dati originale, potrebbe essere necessario configurare un gateway dati locale per l'aggiornamento.

• Aprire un report esistente o creare un nuovo report nella servizio Power BI esegue di nuovo una query sui dati importati, assicurando l'interattività.

• È possibile aggiungere oggetti visivi o intere pagine del report come riquadri del dashboard nella servizio Power BI. I riquadri vengono aggiornati automaticamente ogni volta che il modello semantico sottostante viene aggiornato.

Connessioni DirectQuery

Quando si usa DirectQuery per connettersi a un'origine dati in Power BI Desktop, si verificano i risultati seguenti:

• Usare Recupera dati per selezionare l'origine. Per le origini relazionali, è comunque possibile selezionare un set di tabelle che definiscono una query che restituisce logicamente un set di dati. Per le origini multidimensionali come SAP Business Warehouse (SAP BW), è possibile selezionare solo l'origine.

• Al caricamento, non viene importato alcun dato nell'archivio di Power BI. Al contrario, quando si compila un oggetto visivo, Power BI Desktop invia query all'origine dati sottostante per recuperare i dati necessari. Il tempo necessario per aggiornare l'oggetto visivo dipende dalle prestazioni dell'origine dati sottostante.

• Le modifiche apportate ai dati sottostanti non vengono immediatamente riflesse negli oggetti visivi esistenti. È comunque necessario eseguire l'aggiornamento. Power BI Desktop invia nuovamente le query necessarie per ogni oggetto visivo e aggiorna l'oggetto visivo in base alle esigenze.

• La pubblicazione del report nel servizio Power BI crea e carica un modello semantico, come per l'importazione. Tuttavia, tale modello semantico non include dati.

• Aprire un report esistente o creare un nuovo report nella servizio Power BI esegue una query sull'origine dati sottostante per recuperare i dati necessari. A seconda del percorso dell'origine dati originale, potrebbe essere necessario configurare un gateway dati locale per ottenere i dati.

• È possibile aggiungere oggetti visivi o intere pagine del report come riquadri del dashboard. Per assicurarsi che l'apertura di un dashboard sia veloce, i riquadri vengono aggiornati automaticamente in base a una pianificazione, ad esempio ogni ora. È possibile controllare la frequenza di aggiornamento a seconda della frequenza di modifica dei dati e dell'importanza di visualizzare i dati più recenti.

• Quando si apre un dashboard, i riquadri riflettono i dati al momento dell'ultimo aggiornamento, non necessariamente le modifiche più recenti apportate all'origine sottostante. È possibile aggiornare un dashboard aperto per assicurarsi che sia aggiornato.

Connessioni dinamiche

Quando ci si connette a SQL Server Analysis Services, è possibile scegliere di importare i dati o di usare una connessione dinamica al modello di dati selezionato. L'uso di una connessione dinamica è simile a DirectQuery. Non vengono importati dati e viene eseguita una query sull'origine dati sottostante per aggiornare gli oggetti visivi.

Ad esempio, quando si usa l'importazione per connettersi a SQL Server Analysis Services, si definisce una query sull'origine esterna di SQL Server Analysis Services e si importano i dati. Se ci si connette in tempo reale, non si definisce una query e l'intero modello esterno viene visualizzato nell'elenco dei campi.

Questa situazione si applica anche quando ci si connette alle origini seguenti, ad eccezione del fatto che non è possibile importare i dati:

• Modelli semantici di Power BI, ad esempio la connessione a un modello semantico di Power BI già pubblicato nel servizio, per creare un nuovo report su di esso.

• Microsoft Dataverse.

Quando si pubblicano report di SQL Server Analysis Services che usano connessioni dinamiche, il comportamento nella servizio Power BI è simile ai report DirectQuery nei modi seguenti:

• L'apertura di un report esistente o la creazione di un nuovo report nella servizio Power BI esegue una query sull'origine SQL Server Analysis Services sottostante, eventualmente richiedendo un gateway dati locale.

• I riquadri del dashboard vengono aggiornati automaticamente in base a una pianificazione, ad esempio ogni ora.

Una connessione dinamica differisce anche da DirectQuery in diversi modi. Ad esempio, le connessioni dinamiche passano sempre l'identità dell'utente che apre il report all'origine SQL Server Analysis Services sottostante.

Casi d'uso di DirectQuery

Connessione con DirectQuery può essere utile negli scenari seguenti. In molti di questi casi, lasciare i dati nella posizione di origine originale è necessario o vantaggioso.

DirectQuery in Power BI offre i vantaggi maggiori negli scenari seguenti:

• I dati cambiano frequentemente e sono necessari report quasi in tempo reale.
• È necessario gestire dati di grandi dimensioni senza dover preaggregare.
• L'origine sottostante definisce e applica le regole di sicurezza.
• Si applicano restrizioni di sovranità dei dati.
• L'origine è un'origine multidimensionale contenente misure, ad esempio SAP BW.

Modifiche ai dati di frequente ed è necessario creare report quasi in tempo reale

È possibile aggiornare i modelli con dati importati al massimo una volta all'ora, più frequentemente con le sottoscrizioni di Power BI Pro o Power BI Premium. Se i dati cambiano continuamente ed è necessario che i report visualizzino i dati più recenti, l'uso dell'importazione con l'aggiornamento pianificato potrebbe non soddisfare le proprie esigenze. È possibile trasmettere i dati direttamente in Power BI, anche se esistono limiti per i volumi di dati supportati per questo caso.

L'uso di DirectQuery significa che l'apertura o l'aggiornamento di un report o di un dashboard visualizza sempre i dati più recenti nell'origine. I riquadri del dashboard possono anche essere aggiornati più frequentemente, ogni 15 minuti.

I dati sono molto grandi

Se i dati sono molto grandi, non è possibile importarli tutti. DirectQuery non richiede un trasferimento di dati di grandi dimensioni, perché esegue query su dati sul posto. Tuttavia, i dati di grandi dimensioni potrebbero anche rendere le prestazioni delle query su tale origine sottostante troppo lenta.

Non è sempre necessario importare dati dettagliati completi. Il editor di Power Query semplifica la pre-aggregazione dei dati durante l'importazione. Tecnicamente, è possibile importare esattamente i dati aggregati necessari per ogni oggetto visivo. Anche se DirectQuery è l'approccio più semplice ai dati di grandi dimensioni, l'importazione di dati aggregati potrebbe offrire una soluzione se l'origine dati sottostante è troppo lenta per DirectQuery.

Questi dettagli si riferiscono solo all'uso di Power BI. Per altre informazioni sull'uso di modelli di grandi dimensioni in Power BI, vedere Modelli semantici di grandi dimensioni in Power BI Premium. Non esiste alcuna restrizione sulla frequenza di aggiornamento dei dati.

L'origine sottostante definisce le regole di sicurezza

Quando si importano dati, Power BI si connette all'origine dati usando le credenziali di Power BI Desktop dell'utente corrente o le credenziali configurate per l'aggiornamento pianificato dal servizio Power BI. Nella pubblicazione e nella condivisione di report che hanno importato dati, è necessario prestare attenzione alla condivisione solo con gli utenti autorizzati a visualizzare i dati oppure è necessario definire la sicurezza a livello di riga come parte del modello semantico.

DirectQuery consente a un visualizzatore di report di passare le credenziali all'origine sottostante, che applica regole di sicurezza. DirectQuery supporta l'accesso Single Sign-On (SSO) alle origini dati SQL di Azure e tramite un gateway dati a server SQL locali. Per altre informazioni, vedere Panoramica dell'accesso Single Sign-On (SSO) per i gateway in Power BI.

Si applicano restrizioni di sovranità dei dati

Alcune organizzazioni dispongono di criteri per la sovranità dei dati, ovvero che i dati non possono lasciare l'organizzazione locale. Questi dati presentano problemi per le soluzioni basate sull'importazione dei dati. Con DirectQuery, i dati rimangono nella posizione di origine sottostante. Tuttavia, anche con DirectQuery, il servizio Power BI mantiene alcune cache di dati a livello di oggetto visivo, a causa dell'aggiornamento pianificato dei riquadri.

L'origine dati sottostante usa misure

Un'origine dati sottostante, ad esempio SAP HANA o SAP BW, contiene misure. Le misure indicano che i dati importati sono già a un determinato livello di aggregazione, come definito dalla query. Oggetto visivo che richiede dati a un'aggregazione di livello superiore, ad esempio TotalSales by Year, aggrega ulteriormente il valore aggregato. Questa aggregazione è adatta alle misure additive, ad esempio Sum e Min, ma può essere un problema per le misure non additive, ad esempio Average e DistinctCount.

Ottenere facilmente i dati aggregati corretti necessari per un oggetto visivo direttamente dall'origine richiede l'invio di query per oggetto visivo, come in DirectQuery. Quando ci si connette a SAP BW, la scelta di DirectQuery consente questo trattamento delle misure. Per altre informazioni, vedere DirectQuery e SAP BW.

Attualmente DirectQuery su SAP HANA tratta i dati come un'origine relazionale e produce un comportamento simile all'importazione. Per altre informazioni, vedere DirectQuery e SAP HANA.

Limitazioni di DirectQuery

L'uso di DirectQuery ha alcune implicazioni potenzialmente negative. Alcune di queste limitazioni variano leggermente a seconda dell'origine esatta usata. Le sezioni seguenti elencano le implicazioni generali dell'uso di DirectQuery e le limitazioni correlate a prestazioni, sicurezza, trasformazioni, modellazione e creazione di report.

Implicazioni generali

Di seguito sono riportate alcune implicazioni generali e limitazioni dell'uso di DirectQuery:

• Se i dati cambiano, è necessario aggiornare per visualizzare i dati più recenti. Dato l'uso delle cache, non esiste alcuna garanzia che gli oggetti visivi visualizzino sempre i dati più recenti. Ad esempio, un oggetto visivo potrebbe mostrare transazioni nell'ultimo giorno. Una modifica del filtro dei dati potrebbe aggiornare l'oggetto visivo per visualizzare le transazioni degli ultimi due giorni, incluse le transazioni recenti appena arrivate. Tuttavia, la restituzione del filtro dei dati al valore originale potrebbe comportare di nuovo la visualizzazione del valore precedente memorizzato nella cache. Selezionare Aggiorna per cancellare tutte le cache e aggiornare tutti gli oggetti visivi nella pagina per visualizzare i dati più recenti.

• Se i dati cambiano, non esiste alcuna garanzia di coerenza tra gli oggetti visivi. Gli oggetti visivi diversi, che si tratti della stessa pagina o di pagine diverse, potrebbero essere aggiornati in momenti diversi. Se i dati nell'origine sottostante cambiano, non esiste alcuna garanzia che ogni oggetto visivo mostri i dati nello stesso momento.

  Dato che più query potrebbero essere necessarie per un singolo oggetto visivo, ad esempio per ottenere i dettagli e i totali, anche la coerenza all'interno di un singolo oggetto visivo non è garantita. Per garantire questa coerenza, è necessario l'overhead dell'aggiornamento di tutti gli oggetti visivi ogni volta che viene aggiornato qualsiasi oggetto visivo, oltre all'uso di funzionalità costose, ad esempio l'isolamento dello snapshot nell'origine dati sottostante.

  È possibile attenuare questo problema in gran parte selezionando Aggiorna per aggiornare tutti gli oggetti visivi nella pagina. Anche per la modalità di importazione, esiste un problema simile a quello di mantenere la coerenza quando si importano dati da più tabelle.

• Per riflettere le modifiche dello schema, è necessario eseguire l'aggiornamento in Power BI Desktop. Dopo la pubblicazione di un report, aggiorna nella servizio Power BI aggiorna gli oggetti visivi nel report. Tuttavia, se lo schema di origine sottostante cambia, il servizio Power BI non aggiorna automaticamente l'elenco dei campi disponibili. Se le tabelle o le colonne vengono rimosse dall'origine sottostante, potrebbe verificarsi un errore di query al momento dell'aggiornamento. Per aggiornare i campi nel modello in modo che riflettano le modifiche, è necessario aprire il report in Power BI Desktop e scegliere Aggiorna.

• Un limite di 1 milione di righe può restituire su qualsiasi query. Esiste un limite fisso di 1 milione di righe che possono restituire in qualsiasi singola query all'origine sottostante. Questo limite in genere non ha implicazioni pratiche e gli oggetti visivi non visualizzano molti punti. Tuttavia, il limite può verificarsi nei casi in cui Power BI non ottimizza completamente le query inviate e richiede un risultato intermedio che supera il limite.

  Il limite può verificarsi anche durante la creazione di un oggetto visivo, nel percorso di uno stato finale più ragionevole. Ad esempio, l'inclusione di Customer e TotalSalesQuantity potrebbe raggiungere questo limite se sono presenti più di 1 milione di clienti, fino a quando non si applica un filtro. L'errore restituito è: il set di risultati di una query all'origine dati esterna ha superato le dimensioni massime consentite delle righe "1000000".

  Nota

  Le capacità Premium consentono di superare il limite di un milione di righe. Per altre informazioni, vedere Numero massimo di set di righe intermedi.

• Non è possibile modificare un modello dall'importazione alla modalità DirectQuery. È possibile cambiare un modello dalla modalità DirectQuery alla modalità di importazione se si importano tutti i dati necessari. Non è possibile tornare alla modalità DirectQuery, principalmente a causa del set di funzionalità non supportato dalla modalità DirectQuery. Per le origini multidimensionali come SAP BW, non è possibile passare da DirectQuery alla modalità di importazione, a causa del diverso trattamento delle misure esterne.

Implicazioni per le prestazioni e il carico

Quando si usa DirectQuery, l'esperienza complessiva dipende dalle prestazioni dell'origine dati sottostante. Se l'aggiornamento di ogni oggetto visivo, ad esempio dopo la modifica di un valore del filtro dei dati, richiede meno di cinque secondi, l'esperienza è ragionevole, anche se potrebbe risultare lenta rispetto alla risposta immediata con i dati importati. Se la lentezza dell'origine causa l'aggiornamento di singoli oggetti visivi richiede più di decine di secondi, l'esperienza diventa poco ragionevole. Le query potrebbero anche verificarsi un timeout.

Oltre alle prestazioni dell'origine sottostante, il carico posizionato sull'origine influisce anche sulle prestazioni. Ogni utente che apre un report condiviso e ogni riquadro del dashboard che viene aggiornato invia almeno una query per oggetto visivo all'origine sottostante. L'origine deve essere in grado di gestire tale carico di query mantenendo prestazioni ragionevoli.

Implicazioni per la sicurezza

A meno che l'origine dati sottostante non usi l'accesso SSO, un report DirectQuery usa sempre le stesse credenziali fisse per connettersi all'origine dopo la pubblicazione nel servizio Power BI. Subito dopo la pubblicazione di un report DirectQuery, è necessario configurare le credenziali dell'utente da usare. Finché non si configurano le credenziali, il tentativo di aprire il report nel servizio Power BI genera un errore.

Dopo aver specificato le credenziali utente, Power BI usa tali credenziali per chiunque apra il report, come per i dati importati. Ogni utente visualizza gli stessi dati, a meno che la sicurezza a livello di riga non sia definita come parte del report. È necessario prestare la stessa attenzione alla condivisione del report per i dati importati, anche se sono presenti regole di sicurezza definite nell'origine sottostante.

• Connessione ai modelli semantici di Power BI e Analysis Services in modalità DirectQuery usa sempre l'accesso SSO, quindi la sicurezza è simile alle connessioni dinamiche ad Analysis Services.

• Le credenziali alternative non sono supportate quando si effettuano connessioni DirectQuery a SQL Server da Power BI Desktop. È possibile usare le credenziali correnti di Windows o il database.

• È possibile usare più origini dati in un modello DirectQuery usando modelli compositi. Quando si usano più origini dati, è importante comprendere le implicazioni di sicurezza del modo in cui i dati si spostano tra le origini dati sottostanti.

Limitazioni della trasformazione dei dati

DirectQuery limita le trasformazioni dei dati che è possibile applicare all'interno di editor di Power Query. Con i dati importati, è possibile applicare facilmente un set sofisticato di trasformazioni per pulire e rimodellare i dati prima di usarli per creare oggetti visivi. Ad esempio, è possibile analizzare documenti JSON o dati pivot da una colonna a una maschera di riga. Queste trasformazioni sono più limitate in DirectQuery.

Quando ci si connette a un'origine OLAP (Online Analytical Processing) come SAP BW, non è possibile definire alcuna trasformazione e l'intero modello esterno viene ricavato dall'origine. Per le origini relazionali come SQL Server, è comunque possibile definire un set di trasformazioni per ogni query, ma tali trasformazioni sono limitate per motivi di prestazioni.

Tutte le trasformazioni devono essere applicate a ogni query all'origine sottostante, anziché una volta all'aggiornamento dati. Le trasformazioni devono essere in grado di tradurre ragionevolmente in una singola query nativa. Se si usa una trasformazione troppo complessa, viene visualizzato un errore che indica che deve essere eliminato o che il modello di connessione è passato all'importazione.

Inoltre, la finestra di dialogo Recupera dati o editor di Power Query usare le selezioni secondarie all'interno delle query generate e inviate per recuperare i dati per un oggetto visivo. Le query definite in editor di Power Query devono essere valide all'interno di questo contesto. In particolare, non è possibile usare una query con espressioni di tabella comuni, né una query che richiama stored procedure.

Limitazioni di modellazione

Il termine modellazione in questo contesto significa l'atto di perfezionare e arricchire i dati non elaborati come parte della creazione di un report usando i dati. Esempi di modellazione includono:

• Definizione delle relazioni tra tabelle.
• Aggiunta di nuovi calcoli, ad esempio colonne calcolate e misure.
• Ridenominazione e nascondere colonne e misure.
• Definizione di gerarchie.
• Definizione della formattazione delle colonne, riepilogo predefinito e ordinamento.
• Raggruppamento o clustering di valori.

È comunque possibile apportare molti di questi arricchimenti del modello quando si usa DirectQuery e usare il principio di arricchimento dei dati non elaborati per migliorare l'utilizzo successivo. Tuttavia, alcune funzionalità di modellazione non sono disponibili o sono limitate con DirectQuery. Le limitazioni vengono applicate per evitare problemi di prestazioni.

Le limitazioni seguenti sono comuni a tutte le origini DirectQuery. Altre limitazioni possono essere applicate alle singole origini.

• Nessuna gerarchia di date predefinita: con i dati importati, ogni colonna date/datetime include anche una gerarchia data predefinita disponibile. Ad esempio, se si importa una tabella di ordini di vendita che include una colonna OrderDate e si usa OrderDate in un oggetto visivo, è possibile scegliere il livello di data appropriato da usare, ad esempio anno, mese o giorno. Questa gerarchia di date predefinita non è disponibile con DirectQuery. Se nell'origine sottostante è disponibile una tabella Date , come avviene in molti data warehouse, è possibile usare le funzioni di business intelligence per le gerarchie temporali DAX (Data Analysis Expressions) come di consueto.

• Supporto di data/ora solo a livello di secondi: per i modelli semantici che usano colonne di tempo, Power BI genera query sull'origine DirectQuery sottostante solo fino al livello di dettaglio dei secondi, non ai millisecondi. Rimuovere i dati in millisecondi dalle colonne di origine.

• Limitazioni nelle colonne calcolate: le colonne calcolate possono essere solo all'interno di righe, ovvero possono fare riferimento solo ai valori di altre colonne della stessa tabella, senza usare funzioni di aggregazione. Inoltre, le funzioni scalari DAX consentite, ad esempio LEFT(), sono limitate a quelle che possono essere push nell'origine sottostante. Le funzioni variano a seconda delle funzionalità esatte dell'origine. Le funzioni non supportate non sono elencate nel completamento automatico durante la creazione della query DAX per una colonna calcolata e generano un errore se usato.

• Nessun supporto per le funzioni DAX padre-figlio: quando in modalità DirectQuery non è possibile usare la famiglia di DAX PATH() funzioni che in genere gestiscono strutture padre-figlio, ad esempio grafici di account o gerarchie dei dipendenti.

• Nessun clustering: quando si usa DirectQuery, non è possibile usare la funzionalità di clustering per trovare automaticamente i gruppi.

Limitazioni per la creazione di report

Quasi tutte le funzionalità di creazione di report sono supportate per i modelli DirectQuery. Se l'origine sottostante offre un livello di prestazioni appropriato, è possibile usare lo stesso set di visualizzazioni per i dati importati.

Una limitazione generale è che la lunghezza massima dei dati in una colonna di testo per i modelli semantici DirectQuery è di 32.764 caratteri. La segnalazione di testi più lunghi genera un errore.

Le funzionalità di creazione di report di Power BI seguenti possono causare problemi di prestazioni nei report basati su DirectQuery:

• Filtri di misura: gli oggetti visivi che usano misure o aggregazioni di colonne possono contenere filtri in tali misure. Ad esempio, il grafico seguente mostra SalesAmount by Category, ma solo per le categorie con più di 20 milioni di vendite.

  

  Questo approccio causa l'invio di due query all'origine sottostante:

  • La prima query recupera le categorie che soddisfano la condizione SalesAmount maggiore di 20 milioni.
  • La seconda query recupera i dati necessari per l'oggetto visivo, che include le categorie che soddisfano la WHERE condizione.

  Questo approccio funziona in genere bene se sono presenti centinaia o migliaia di categorie, come in questo esempio. Le prestazioni possono peggiorare se il numero di categorie è molto maggiore. La query ha esito negativo se sono presenti più di un milione di categorie.

• Filtri TopN: è possibile definire filtri avanzati per filtrare solo i valori superiore o inferiore N classificati da una misura. Ad esempio, i filtri possono includere le prime 10 categorie. Questo approccio invia nuovamente due query all'origine sottostante. Tuttavia, la prima query restituisce tutte le categorie dall'origine sottostante e quindi vengono TopN determinate in base ai risultati restituiti. A seconda della cardinalità della colonna interessata, questo approccio può causare problemi di prestazioni o errori di query a causa del limite di un milione di righe nei risultati della query.

• Mediana: qualsiasi aggregazione, ad esempio Sum o Count Distinct, viene inserita nell'origine sottostante. Tuttavia, in genere l'aggregazione median non è supportata dall'origine sottostante. Per median, i dati di dettaglio vengono recuperati dall'origine sottostante e la mediano viene calcolata dai risultati restituiti. Questo approccio è ragionevole per calcolare la median su un numero relativamente ridotto di risultati.

  I problemi di prestazioni o gli errori di query possono verificarsi se la cardinalità è elevata a causa del limite di un milione di righe. Ad esempio, l'esecuzione di query per la popolazione di paese/area mediano potrebbe essere ragionevole, ma il prezzo di vendita mediano potrebbe non essere ragionevole.

• Filtri di testo avanzati come 'contains': il filtro avanzato per una colonna di testo consente filtri come contains e begins with. Questi filtri possono comportare prestazioni ridotte per alcune origini dati. In particolare, non usare il filtro predefinito contains se è necessaria una corrispondenza esatta. Anche se i risultati potrebbero essere uguali a seconda dei dati effettivi, le prestazioni potrebbero essere drasticamente diverse a causa degli indici.

• Filtri dei dati con selezione multipla: per impostazione predefinita, i filtri dei dati consentono solo di effettuare una singola selezione. Consentire la selezione multipla nei filtri può causare problemi di prestazioni. Ad esempio, se l'utente seleziona 10 prodotti di interesse, ogni nuova selezione comporta l'invio di query all'origine. Anche se l'utente può selezionare l'elemento successivo prima del completamento della query, questo approccio comporta un carico aggiuntivo sull'origine sottostante.

• Totali per gli oggetti visivi di tabella: per impostazione predefinita, le tabelle e le matrici visualizzano totali e subtotali. In molti casi, ottenere i valori per tali totali richiede l'invio di query separate all'origine sottostante. Questo requisito si applica ogni volta che si usa l'aggregazione DistinctCount o in tutti i casi che usano DirectQuery su SAP BW o SAP HANA. È possibile disattivare tali totali usando il riquadro Formato .

Raccomandazioni per DirectQuery

Questa sezione fornisce indicazioni generali su come usare correttamente DirectQuery, in base alle implicazioni.

Prestazioni dell'origine dati sottostante

Verificare che gli oggetti visivi semplici vengano aggiornati entro cinque secondi, per offrire un'esperienza interattiva ragionevole. Se l'aggiornamento degli oggetti visivi richiede più di 30 secondi, è probabile che altri problemi dopo la pubblicazione del report rendano impossibile la soluzione.

Se le query sono lente, esaminare le query inviate all'origine sottostante e il motivo della lentezza delle prestazioni. Per altre informazioni, vedere Diagnostica delle prestazioni.

Questo articolo non tratta l'ampia gamma di raccomandazioni di ottimizzazione del database nell'intero set di origini sottostanti potenziali. Per la maggior parte delle situazioni si applicano le procedure di database standard seguenti:

• Per prestazioni migliori, le relazioni di base sulle colonne integer anziché unire colonne di altri tipi di dati.

• Creare gli indici appropriati. La creazione dell'indice indica in genere l'uso degli indici dell'archivio di colonne nelle origini che li supportano, ad esempio SQL Server.

• Aggiornare le statistiche necessarie nell'origine.

Progettazione del modello

Quando si definisce il modello, seguire queste indicazioni:

• Evitare query complesse in editor di Power Query. editor di Power Query converte una query complessa in una singola query SQL. La singola query viene visualizzata nella sottoseleziona di ogni query inviata a tale tabella. Se la query è complessa, potrebbero verificarsi problemi di prestazioni in ogni query inviata. È possibile ottenere la query SQL effettiva per un set di passaggi facendo clic con il pulsante destro del mouse sull'ultimo passaggio in Passaggi applicati in editor di Power Query e scegliendo Visualizza query nativa.

• Mantenere le misure semplici. Almeno inizialmente, limitare le misure alle aggregazioni semplici. Se le misure operano in modo soddisfacente, è possibile definire misure più complesse, ma prestare attenzione alle prestazioni.

• Evitare relazioni sulle colonne calcolate. Nei database in cui è necessario eseguire join a più colonne, Power BI non consente relazioni di base su più colonne come chiave primaria o chiave esterna. La soluzione alternativa comune consiste nel concatenare le colonne usando una colonna calcolata e basare il join su tale colonna.

  Questa soluzione alternativa è ragionevole per i dati importati, ma per DirectQuery comporta un join in un'espressione. Questo risultato in genere impedisce l'uso di indici e comporta prestazioni scarse. L'unica soluzione alternativa consiste nel materializzare effettivamente più colonne in una singola colonna nell'origine dati sottostante.

• Evitare relazioni sulle colonne 'uniqueidentifier'. Power BI non supporta in modo nativo un uniqueidentifier tipo di dati. La definizione di una relazione tra uniqueidentifier colonne comporta una query con un join che implica un cast. Anche in questo caso, questo approccio porta in genere a prestazioni scarse. L'unica soluzione alternativa consiste nel materializzare le colonne di un tipo alternativo nell'origine dati sottostante.

• Nascondere la colonna "to" nelle relazioni. La to colonna relativa alle relazioni è in genere la chiave primaria nella to tabella. La colonna deve essere nascosta, ma se nascosta non viene visualizzata nell'elenco dei campi e non può essere usata negli oggetti visivi. Spesso le colonne su cui si basano le relazioni sono in realtà colonne di sistema, ad esempio chiavi surrogate in un data warehouse. È comunque consigliabile nascondere tali colonne.

  Se la colonna ha un significato, introdurre una colonna calcolata visibile e con un'espressione semplice uguale alla chiave primaria, ad esempio:

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• Esaminare tutte le colonne calcolate e le modifiche del tipo di dati. È possibile usare tabelle calcolate quando si usa DirectQuery con modelli compositi. Queste funzionalità non sono necessariamente dannose, ma generano query che contengono espressioni anziché semplici riferimenti alle colonne. Tali query potrebbero comportare l'uso di indici.

• Evitare il filtro incrociato bidirezionale per le relazioni. L'uso di filtri incrociati bidirezionali può portare a istruzioni di query che non funzionano correttamente. Per altre informazioni sul filtro incrociato bidirezionale, vedere Abilitare il filtro incrociato bidirezionale per DirectQuery in Power BI Desktop o scaricare il white paper filtro incrociato bidirezionale . Gli esempi nel documento sono relativi a SQL Server Analysis Services, ma i punti fondamentali si applicano anche a Power BI.

• Sperimentare con l'impostazione Assume integrità referenziale. L'impostazione Assume integrità referenziale sulle relazioni consente alle query di usare INNER JOIN anziché OUTER JOIN istruzioni. Queste indicazioni migliorano in genere le prestazioni delle query, anche se dipendono dalle specifiche dell'origine dati.

• Non usare il filtro dati relativo in editor di Power Query. È possibile definire il filtro della data relativa in editor di Power Query. Ad esempio, è possibile filtrare in base alle righe in cui la data si trova negli ultimi 14 giorni.

  

  Tuttavia, questo filtro si traduce in un filtro basato su una data fissa, ad esempio l'ora di creazione della query, come si può vedere nella query nativa.

  

  Questi dati probabilmente non sono quello desiderato. Per assicurarsi che il filtro venga applicato in base alla data in cui viene eseguito il report, applicare il filtro data nel report. È possibile creare una colonna calcolata che calcola il numero di giorni fa usando la DAX DATE() funzione e usare tale colonna calcolata nel filtro.

Progettazione del report

Quando si crea un report che usa una connessione DirectQuery, seguire queste indicazioni:

• Prendere in considerazione l'uso delle opzioni di riduzione delle query: Power BI offre opzioni di report per inviare meno query e disabilitare determinate interazioni che causano un'esperienza scarsa se l'esecuzione delle query risultanti richiede molto tempo. Queste opzioni si applicano quando si interagisce con il report in Power BI Desktop e si applicano anche quando gli utenti usano il report nel servizio Power BI.

  Per accedere a queste opzioni in Power BI Desktop, passare a Opzioni file>e impostazioni>Opzioni e selezionare Riduzione query.

  

  Le selezioni nella schermata Riduzione query consentono di visualizzare un pulsante Applica per filtri dei dati o selezioni di filtro. Nessuna query viene inviata finché non si seleziona il pulsante Applica nel filtro o nel filtro dei dati. Le query usano quindi le selezioni per filtrare i dati. Questo pulsante consente di effettuare diverse selezioni di filtro dei dati e filtro prima di applicarle.

• Applicare prima i filtri: applicare sempre tutti i filtri applicabili all'inizio della compilazione di un oggetto visivo. Ad esempio, anziché trascinare in TotalSalesAmount e ProductName, quindi filtrare in base a un determinato anno, applicare il filtro all'inizio anno .

  Ogni passaggio della compilazione di un oggetto visivo invia una query. Sebbene sia possibile apportare un'altra modifica prima del completamento della prima query, questo approccio lascia comunque carico non necessario sull'origine sottostante. L'applicazione dei filtri in genere rende le query intermedie meno costose. Se non si applicano i filtri in anticipo, è possibile che si raggiunga il limite di un milione di righe.

• Limitare il numero di oggetti visivi in una pagina: quando si apre una pagina o si modifica un filtro dei dati o un filtro a livello di pagina, tutti gli oggetti visivi nell'aggiornamento della pagina. Esiste un limite al numero di query parallele. Con l'aumentare del numero di oggetti visivi, alcuni oggetti visivi vengono aggiornati in modo seriale, aumentando il tempo necessario per aggiornare la pagina. Pertanto, è consigliabile limitare il numero di oggetti visivi in una singola pagina e avere invece pagine più semplici.

• Valutare la possibilità di disattivare l'interazione tra oggetti visivi: per impostazione predefinita, le visualizzazioni in una pagina del report possono essere usate per applicare filtri incrociati ed evidenziare in modo incrociato le altre visualizzazioni nella pagina. Ad esempio, se si seleziona 1999 nel grafico a torta, l'istogramma viene evidenziato in modo incrociato per visualizzare le vendite per categoria per il 1999.

  

  Il filtro incrociato e l'evidenziazione incrociata in DirectQuery richiedono l'invio di query all'origine sottostante. È consigliabile disattivare questa interazione se il tempo impiegato per rispondere alle selezioni degli utenti è eccessivamente lungo.

  È possibile usare le impostazioni di riduzione delle query per disabilitare l'evidenziazione incrociata in tutto il report o caso per caso. Per altre informazioni, vedere Come gli oggetti visivi si filtrano tra loro in un report di Power BI.

Numero massimo di connessioni

È possibile impostare il numero massimo di connessioni che DirectQuery apre per ogni origine dati sottostante, che controlla il numero di query inviate simultaneamente a ogni origine dati.

DirectQuery apre un numero massimo predefinito di 10 connessioni simultanee. Per modificare il numero massimo per il file corrente in Power BI Desktop, passare a Opzioni file>e Impostazioni> Opzioni e selezionare DirectQuery nella sezione File corrente del riquadro sinistro.

L'impostazione è abilitata solo quando è presente almeno un'origine DirectQuery nel report corrente. Il valore si applica a tutte le origini DirectQuery e a tutte le nuove origini DirectQuery aggiunte a tale report.

L'aumento delle connessioni massime per origine dati consente di inviare più query, fino al numero massimo specificato, all'origine dati sottostante. Questo approccio è utile quando molti oggetti visivi si trovano in una singola pagina o molti utenti accedono contemporaneamente a un report. Una volta raggiunto il numero massimo di connessioni, vengono accodate altre query fino a quando non diventa disponibile una connessione. Un limite più elevato comporta un carico maggiore sull'origine sottostante, pertanto l'impostazione non garantisce un miglioramento delle prestazioni complessive.

Dopo aver pubblicato un report nella servizio Power BI, il numero massimo di query simultanee dipende anche dai limiti fissi impostati nell'ambiente di destinazione in cui viene pubblicato il report. Power BI, Power BI Premium e Server di report di Power BI imporre limiti diversi. La tabella seguente elenca i limiti superiori delle connessioni attive per ogni origine dati per ogni ambiente Power BI. Questi limiti si applicano alle origini dati cloud e alle origini dati locali, ad esempio SQL Server, Oracle e Teradata.

Ambiente	Limite massimo per origine dati
Power BI Pro	10 connessioni attive
Power BI Premium	Dipende dalla limitazione dello SKU del modello semantico
Server di report di Power BI	10 connessioni attive

DirectQuery nel servizio Power BI

Tutte le origini dati DirectQuery sono supportate da Power BI Desktop e alcune origini sono disponibili direttamente dall'interno del servizio Power BI. Un utente aziendale può usare Power BI per connettersi ai dati in Salesforce, ad esempio e ottenere immediatamente un dashboard, senza usare Power BI Desktop.

Solo le due origini abilitate per DirectQuery seguenti sono disponibili direttamente nel servizio Power BI:

• Spark
• Azure Synapse Analytics (in precedenza SQL Data Warehouse)

Anche per queste due origini, è comunque consigliabile iniziare a usare DirectQuery in Power BI Desktop. Sebbene sia facile stabilire inizialmente la connessione nel servizio Power BI, esistono limitazioni per migliorare ulteriormente il report risultante. Ad esempio, nel servizio non è possibile creare calcoli o usare molte funzionalità analitiche o aggiornare i metadati per riflettere le modifiche apportate allo schema sottostante.

Le prestazioni di un report DirectQuery nella servizio Power BI dipendono dal grado di carico posizionato sull'origine dati sottostante. Il carico dipende da:

• Numero di utenti che condividono il report e il dashboard.
• Complessità del report.
• Indica se il report definisce la sicurezza a livello di riga.

Segnalare il comportamento nel servizio Power BI

Quando si apre un report nella servizio Power BI, tutti gli oggetti visivi nell'aggiornamento della pagina attualmente visibile. Ogni oggetto visivo richiede almeno una query all'origine dati sottostante. Alcuni oggetti visivi potrebbero richiedere più query. Ad esempio, un oggetto visivo potrebbe mostrare valori aggregati di due tabelle dei fatti diverse o contenere una misura più complessa o contenere totali di una misura non additivi come Count Distinct. Lo spostamento in una nuova pagina aggiorna tali oggetti visivi. L'aggiornamento invia un nuovo set di query all'origine sottostante.

Ogni interazione dell'utente nel report potrebbe comportare l'aggiornamento degli oggetti visivi. Ad esempio, la selezione di un valore diverso in un filtro dei dati richiede l'invio di un nuovo set di query per aggiornare tutti gli oggetti visivi interessati. Lo stesso vale per la selezione di un oggetto visivo per l'evidenziazione incrociata di altri oggetti visivi o la modifica di un filtro. Analogamente, la creazione o la modifica di un report richiede l'invio di query per ogni passaggio nel percorso per produrre l'oggetto visivo finale.

Sono presenti alcuni risultati nella cache. L'aggiornamento di un oggetto visivo è istantaneo se gli stessi risultati sono stati ottenuti di recente. Se viene definita la sicurezza a livello di riga, queste cache non vengono condivise tra gli utenti.

L'uso di DirectQuery impone alcune limitazioni importanti in alcune delle funzionalità offerte dalla servizio Power BI per i report pubblicati:

• Le informazioni rapide non sono supportate: Power BI consente di eseguire ricerche rapide nei diversi subset del modello semantico applicando un set di algoritmi sofisticati per individuare informazioni potenzialmente interessanti. Poiché le informazioni rapide richiedono query ad alte prestazioni, questa funzionalità non è disponibile nei modelli semantici che usano DirectQuery.

• L'uso di Esplora in Excel comporta prestazioni scarse: è possibile esplorare un modello semantico usando la funzionalità Esplora in Excel , che consente di creare tabelle pivot e grafici pivot in Excel. Questa funzionalità è supportata per i modelli semantici che usano DirectQuery, ma le prestazioni sono più lente rispetto alla creazione di oggetti visivi in Power BI. Se si usa Excel è importante per gli scenari, tenere conto di questo problema per decidere se usare DirectQuery.

• Excel non mostra gerarchie: ad esempio, quando si usa Analizza in Excel, Excel non mostra alcuna gerarchia definita nei modelli di Azure Analysis Services o nei modelli semantici di Power BI che usano DirectQuery.

Aggiornamento del dashboard

Nella servizio Power BI è possibile aggiungere singoli oggetti visivi o intere pagine ai dashboard come riquadri. I riquadri basati sui modelli semantici DirectQuery vengono aggiornati automaticamente inviando query alle origini dati sottostanti in base a una pianificazione. Per impostazione predefinita, i modelli semantici vengono aggiornati ogni ora, ma è possibile configurare l'aggiornamento tra ogni settimana e ogni 15 minuti come parte delle impostazioni del modello semantico.

Se nel modello non è definita alcuna sicurezza a livello di riga, ogni riquadro viene aggiornato una sola volta e i risultati vengono condivisi tra tutti gli utenti. Se si usa la sicurezza a livello di riga, ogni riquadro richiede l'invio di query separate per utente all'origine sottostante.

Può esserci un effetto moltiplicatore di grandi dimensioni. Un dashboard con 10 riquadri, condivisi con 100 utenti, creati in un modello semantico usando DirectQuery con sicurezza a livello di riga, comporta l'invio di almeno 1000 query all'origine dati sottostante per ogni aggiornamento. Prestare attenzione all'uso della sicurezza a livello di riga e alla configurazione della pianificazione dell'aggiornamento.

Timeout della query

Un timeout di quattro minuti si applica alle singole query nel servizio Power BI. Le query che richiedono più di quattro minuti hanno esito negativo. Questo limite è progettato per evitare problemi causati da tempi di esecuzione eccessivamente lunghi. È consigliabile usare DirectQuery solo per le origini che possono offrire prestazioni di query interattive.

Performance Diagnostics

Questa sezione descrive come diagnosticare i problemi di prestazioni o come ottenere informazioni più dettagliate per ottimizzare i report.

Iniziare a diagnosticare i problemi di prestazioni in Power BI Desktop, anziché nel servizio Power BI. I problemi di prestazioni sono spesso basati sulle prestazioni dell'origine sottostante. È possibile identificare e diagnosticare più facilmente i problemi nell'ambiente Power BI Desktop più isolato.

Questo approccio elimina inizialmente determinati componenti, ad esempio il gateway di Power BI. Se i problemi di prestazioni non si verificano in Power BI Desktop, è possibile esaminare le specifiche del report nel servizio Power BI.

Power BI Desktop Performance Analyzer è uno strumento utile per identificare i problemi. Provare a isolare eventuali problemi con un oggetto visivo, anziché molti oggetti visivi in una pagina. Se un singolo oggetto visivo in una pagina di Power BI Desktop è lento, usare Analizzatore prestazioni per analizzare le query inviate da Power BI Desktop all'origine sottostante.

È anche possibile visualizzare tracce e informazioni di diagnostica che alcune origini dati sottostanti generano. Anche se non sono presenti tracce dall'origine, il file di traccia potrebbe contenere dettagli utili su come viene eseguita una query e su come migliorarlo. È possibile usare il processo seguente per visualizzare le query inviate da Power BI e i relativi tempi di esecuzione.

Usare SQL Server Profiler per visualizzare le query

Per impostazione predefinita, Power BI Desktop registra gli eventi durante una determinata sessione in un file di traccia denominato FlightRecorderCurrent.trc. Il file di traccia si trova nella cartella di Power BI Desktop per l'utente corrente, in una cartella denominata AnalysisServicesWorkspaces.

Per alcune origini DirectQuery, questo file di traccia include tutte le query inviate all'origine dati sottostante. Le origini dati seguenti inviano query al log:

• SQL Server
• Database SQL di Microsoft Azure
• Azure Synapse Analytics (in precedenza SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

È possibile leggere i file di traccia usando SQL Server Profiler, parte del download gratuito di SQL Server Management Studio.

Per aprire il file di traccia per la sessione corrente:

1. Durante una sessione di Power BI Desktop selezionare Opzioni file>e impostazioni>Opzioni e quindi Selezionare Diagnostica.

2. In Raccolta dump di arresto anomalo del sistema selezionare Apri cartella dump/tracce di arresto anomalo del sistema.

   

   Verrà visualizzata la cartella Power BI Desktop\Traces .

3. Passare alla cartella padre e quindi alla cartella AnalysisServicesWorkspaces , che contiene una cartella dell'area di lavoro per ogni istanza aperta di Power BI Desktop. Queste cartelle vengono denominate con un suffisso integer, ad esempio AnalysisServicesWorkspace2058279583. La cartella dell'area di lavoro viene eliminata al termine della sessione di Power BI Desktop associata.

   All'interno della cartella dell'area di lavoro per la sessione corrente di Power BI, la cartella \Data contiene il file di traccia FlightRecorderCurrent.trc . Prendi nota dell'ubicazione.

4. Aprire SQL Server Profiler e selezionare File>Apri>file di traccia.

5. Passare o immettere il percorso del file di traccia per la sessione di Power BI corrente e aprire FlightRecorderCurrent.trc.

SQL Server Profiler visualizza tutti gli eventi della sessione corrente. Lo screenshot seguente evidenzia un gruppo di eventi per una query. Ogni gruppo di query ha gli eventi seguenti:

• Un Query Begin evento eQuery End, che rappresenta l'inizio e la fine di una query DAX generata modificando un oggetto visivo o un filtro nell'interfaccia utente di Power BI o filtrando o trasformando i dati nella editor di Power Query.

• Una o più coppie di DirectQuery Begin eventi e DirectQuery End , che rappresentano le query inviate all'origine dati sottostante, come parte della valutazione della query DAX.

È possibile eseguire più query DAX in parallelo, in modo che gli eventi di gruppi diversi possano essere interleaved. È possibile usare il ActivityID valore per determinare quali eventi appartengono allo stesso gruppo.

Anche le colonne seguenti sono di interesse:

• TextData: dettagli testuali dell'evento. Per Query Begin gli eventi e Query End , il dettaglio è la query DAX. Per DirectQuery Begin gli eventi e DirectQuery End , il dettaglio è la query SQL inviata all'origine sottostante. Il textData per l'evento attualmente selezionato viene visualizzato anche nel riquadro nella parte inferiore della schermata.
• EndTime: ora di completamento dell'evento.
• Durata: durata, in millisecondi, necessaria per eseguire la query DAX o SQL.
• Errore: indica se si è verificato un errore, nel qual caso l'evento viene visualizzato anche in rosso.

Per acquisire una traccia per diagnosticare un potenziale problema di prestazioni:

1. Aprire una singola sessione di Power BI Desktop per evitare la confusione di più cartelle dell'area di lavoro.

2. Eseguire il set di azioni di interesse in Power BI Desktop. Includere alcune altre azioni per assicurarsi che gli eventi di interesse vengano scaricati nel file di traccia.

3. Aprire SQL Server Profiler ed esaminare la traccia. Tenere presente che la chiusura di Power BI Desktop elimina il file di traccia. Inoltre, non vengono visualizzate immediatamente altre azioni in Power BI Desktop. Per visualizzare nuovi eventi, è necessario chiudere e riaprire il file di traccia.

Mantenere le singole sessioni ragionevolmente piccole, forse 10 secondi di azioni, non centinaia. Questo approccio semplifica l'interpretazione del file di traccia. Esiste anche un limite per le dimensioni del file di traccia. Per sessioni lunghe, è possibile eliminare gli eventi iniziali.

Informazioni sul formato delle query

Il formato generale delle query di Power BI Desktop usa le selezioni secondarie per ogni tabella a cui fanno riferimento. La query editor di Power Query definisce le query di selezione secondaria. Si supponga, ad esempio, di avere le tabelle TPC-DS seguenti in SQL Server:

Esecuzione della query seguente:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Risultati nell'oggetto visivo seguente in Power BI:

L'aggiornamento dell'oggetto visivo genera la query SQL nell'immagine seguente. Sono disponibili tre query di selezione secondaria per Web_Sales, Iteme Date_dim, che restituiscono tutte le colonne nella rispettiva tabella, anche se l'oggetto visivo fa riferimento solo a quattro colonne.

editor di Power Query definisce le query di selezione secondaria esatte. Questo uso di query di selezione secondaria non è stato mostrato per influire sulle prestazioni per le origini dati supportate da DirectQuery. Le origini dati come SQL Server ottimizzano i riferimenti alle altre colonne.

Power BI usa questo modello perché l'analista fornisce direttamente la query SQL. Power BI usa la query come specificato, senza alcun tentativo di riscriverla.

Contenuto correlato

Per altre informazioni su DirectQuery in Power BI, vedere:

• Usare DataQuery in Power BI Desktop

Questo articolo descrive gli aspetti di DirectQuery comuni in tutte le origini dati. Per informazioni dettagliate su origini specifiche, vedere gli articoli seguenti:

• DirectQuery e SAP HANA
• DirectQuery e SAP BW
• Usare DirectQuery per modelli semantici di Power BI e Analysis Services