Linee guida per il recupero dei dati per i report impaginati

  • Articolo

Questo articolo è destinato all'autore di report che progetta report impaginati di Power BI. Fornisce raccomandazioni che consentono di progettare un recupero dei dati efficace ed efficiente.

Tipi di origine dati

I report impaginati supportano in modo nativo origini dati relazionali e analitiche. Queste origini sono ulteriormente classificate, come basate sul cloud o in locale. Le origini dati locali, ospitate in locale o in una macchina virtuale, richiedono un gateway dati in modo che Power BI possa connettersi. Basato sul cloud, Power BI può connettersi direttamente tramite una connessione Internet.

Se è possibile scegliere il tipo di origine dati (possibilmente nel caso in un nuovo progetto), è consigliabile usare origini dati basate sul cloud. I report impaginati possono connettersi con una latenza di rete inferiore, soprattutto quando le origini dati si trovano nella stessa area del tenant di Power BI. È anche possibile connettersi a queste origini usando Single Sign-On (SSO). Ciò significa che l'identità dell'utente del report può passare all'origine dati, consentendo l'applicazione delle autorizzazioni a livello di riga per utente. Attualmente, l'accesso Single Sign-On è supportato solo per le origini dati locali SQL Server e Oracle (vedere Origini dati supportate per i report impaginati di Power BI).

Nota

Anche se non è attualmente possibile connettersi ai database locali tramite SSO, è comunque possibile applicare autorizzazioni a livello di riga. Questa operazione viene eseguita passando il campo predefinito UserID a un parametro di query del set di dati. L'origine dati dovrà archiviare i valori UPN (User Principal Name) in modo che possa filtrare correttamente i risultati della query.

Si consideri, ad esempio, che ogni venditore sia archiviato come riga nella tabella Salesperson . La tabella contiene colonne per UPN e anche l'area di vendita del venditore. In fase di query, la tabella viene filtrata in base all'UPN dell'utente del report ed è correlata anche ai fatti di vendita usando un inner join. In questo modo, la query filtra efficacemente le righe dei fatti di vendita a quelle dell'area di vendita dell'utente del report.

Origini dati relazionali

In genere, le origini dati relazionali sono adatte ai report di stile operativo, ad esempio le fatture di vendita. Sono adatti anche per i report che devono recuperare set di dati molto grandi (in eccesso a 10.000 righe). Le origini dati relazionali possono anche definire stored procedure, che possono essere eseguite dai set di dati del report. Le stored procedure offrono diversi vantaggi:

  • Parametrizzazione
  • Incapsulamento della logica di programmazione, che consente una preparazione dei dati più complessa (ad esempio, tabelle temporanee, cursori o funzioni scalari definite dall'utente)
  • Manutenibilità migliorata, consentendo di aggiornare facilmente la logica della stored procedure. In alcuni casi, può essere eseguita senza la necessità di modificare e ripubblicare i report impaginati (specificando nomi di colonna e tipi di dati rimangono invariati).
  • Prestazioni migliori, perché i piani di esecuzione vengono memorizzati nella cache per il riutilizzo
  • Riutilizzo di stored procedure in più report

In Power BI Generatore report è possibile usare progettazione query relazionale per creare graficamente un'istruzione di query, ma solo per le origini dati Microsoft.

Origini dati analitiche

Le origini dati analitiche, note anche come modelli di dati o semplicemente modelli, sono adatte sia ai report operativi che analitici e possono offrire risultati di query riepilogati rapidi anche su volumi di dati molto grandi. Le misure del modello e gli indicatori KPI possono incapsulare regole business complesse per ottenere il riepilogo dei dati. Queste origini dati, tuttavia, non sono adatte ai report che devono recuperare volumi di dati molto grandi (oltre 10.000 righe).

In Power BI Generatore report è possibile scegliere due finestre di progettazione query: Progettazione query DAX di Analysis Services e Progettazione query MDX di Analysis Services. Queste finestre di progettazione possono essere usate per le origini dati del modello semantico di Power BI (precedentemente noto come set di dati) o per qualsiasi modello di SQL Server Analysis Services o di Azure Analysis Services, tabulare o multidimensionale.

È consigliabile usare progettazione query DAX, in modo da soddisfare completamente le esigenze di query. Se il modello non definisce le misure necessarie, è necessario passare alla modalità query. In questa modalità è possibile personalizzare l'istruzione di query aggiungendo espressioni (per ottenere il riepilogo).

Progettazione query MDX richiede che il modello includa misure. La finestra di progettazione dispone di due funzionalità non supportate dalla finestra progettazione query DAX. In particolare, consente di:

  • Definire membri calcolati a livello di query (in MDX).
  • Configurare le aree dati per richiedere aggregazioni server in gruppi non di dettaglio. Se il report deve presentare riepiloghi di misure semi-o non additivi (ad esempio calcoli di business intelligence per le gerarchie temporali o conteggi distinti), è probabile che sia più efficiente usare aggregazioni server che recuperare righe di dettaglio di basso livello e disporre dei riepiloghi di calcolo del report.

Dimensioni dei risultati della query

In generale, è consigliabile recuperare solo i dati richiesti dal report. Non recuperare quindi colonne o righe non richieste dal report.

Per limitare le righe, è consigliabile applicare sempre i filtri più restrittivi e definire query di aggregazione. Raggruppare le query e riepilogare i dati di origine per recuperare risultati con granularità più elevata. Si consideri, ad esempio, che il report debba presentare un riepilogo delle vendite del venditore. Anziché recuperare tutte le righe degli ordini di vendita, creare una query del set di dati che raggruppa per venditore e riepiloga le vendite per ogni gruppo.

Campi basati su espressioni

È possibile estendere un set di dati del report con campi basati su espressioni. Ad esempio, se il nome del cliente e il cognome del cliente sono origini del set di dati, è possibile che un campo concatena i due campi per produrre il nome completo del cliente. Per ottenere questo calcolo, sono disponibili due opzioni. È possibile:

  • Creare un campo calcolato, ovvero un campo del set di dati basato su un'espressione.
  • Inserire un'espressione direttamente nella query del set di dati (usando il linguaggio nativo dell'origine dati), che comporta un normale campo del set di dati.

È consigliabile usare quest'ultima opzione, quando possibile. Esistono due motivi validi per cui l'inserimento di espressioni direttamente nella query del set di dati è migliore:

  • È possibile che l'origine dati sia ottimizzata per valutare l'espressione in modo più efficiente rispetto a Power BI, in particolare per i database relazionali.
  • Le prestazioni dei report sono migliorate perché non è necessario che Power BI materializzi i campi calcolati prima del rendering del report. I campi calcolati possono estendere notevolmente il tempo di rendering del report quando i set di dati recuperano un numero elevato di righe.

Nomi dei campi

Quando si crea un set di dati, i relativi campi vengono denominati automaticamente dopo le colonne di query. È possibile che questi nomi non siano descrittivi o intuitivi. È anche possibile che i nomi delle colonne di query di origine contengano caratteri non consentiti negli identificatori di oggetto RDL (Report Definition Language), ad esempio spazi e simboli. In questo caso, i caratteri non consentiti vengono sostituiti con un carattere di sottolineatura (_).

È consigliabile verificare prima di tutto che tutti i nomi di campo siano descrittivi, concisi, ma ancora significativi. In caso contrario, è consigliabile rinominarli prima di iniziare il layout del report. Poiché i campi rinominati non vengono modificati in modo ondulato nelle espressioni usate nel layout del report. Se si decide di rinominare i campi dopo aver avviato il layout del report, sarà necessario trovare e aggiornare tutte le espressioni interrotte.

Filtro e parametro

È probabile che le progettazioni di report impaginate abbiano parametri di report. I parametri del report vengono comunemente usati per richiedere all'utente del report di filtrare il report. In qualità di autore di report impaginati, è possibile ottenere il filtro dei report in due modi. È possibile eseguire il mapping di un parametro del report a:

  • Un filtro del set di dati, nel qual caso i valori dei parametri del report vengono usati per filtrare i dati già recuperati dal set di dati.
  • Parametro del set di dati, nel qual caso i valori dei parametri del report vengono inseriti nella query nativa inviata all'origine dati.

Nota

Tutti i set di dati del report vengono memorizzati nella cache per sessione per un massimo di 10 minuti oltre l'ultimo utilizzo. Un set di dati può essere riutilizzato durante l'invio di nuovi valori di parametro (filtro), il rendering del report in un formato diverso o l'interazione con la progettazione del report in qualche modo, ad esempio l'attivazione o l'ordinamento della visibilità.

Si consideri quindi un esempio di un report di vendita con un singolo parametro del report per filtrare il report in base a un singolo anno. Il set di dati recupera le vendite per tutti gli anni. Lo fa perché il parametro del report esegue il mapping ai filtri del set di dati. Il report visualizza i dati per l'anno richiesto, ovvero un subset dei dati del set di dati. Quando l'utente del report modifica il parametro del report in un anno diverso e quindi visualizza il report, Power BI non deve recuperare dati di origine. Applica invece un filtro diverso al set di dati già memorizzato nella cache. Dopo aver memorizzato nella cache il set di dati, il filtro può essere molto veloce.

Si consideri ora una progettazione di report diversa. Questa volta la progettazione del report esegue il mapping del parametro del report dell'anno di vendita a un parametro del set di dati. In questo modo, Power BI inserisce il valore dell'anno nella query nativa e il set di dati recupera i dati solo per quell'anno. Ogni volta che l'utente del report modifica il valore del parametro del report dell'anno e quindi visualizza il report, il set di dati recupera un nuovo risultato della query solo per quell'anno.

Entrambi gli approcci di progettazione possono filtrare i dati del report e entrambe le progettazioni possono funzionare correttamente per le progettazioni dei report. Tuttavia, una progettazione ottimizzata dipenderà dai volumi previsti di dati, volatilità dei dati e dai comportamenti previsti degli utenti del report.

È consigliabile filtrare i set di dati quando si prevede un sottoinsieme diverso delle righe del set di dati verranno riutilizzate molte volte,risparmiando così tempo di rendering perché non è necessario recuperare nuovi dati. In questo scenario si riconosce che il costo del recupero di un set di dati di dimensioni maggiori può essere scambiato rispetto al numero di volte in cui verrà riutilizzato. Pertanto, è utile per le query che richiedono molto tempo per la generazione. Ma prestare attenzione: la memorizzazione nella cache di set di dati di grandi dimensioni su base utente può influire negativamente sulle prestazioni e sulla velocità effettiva della capacità.

È consigliabile parametrizzare il set di dati quando si prevede che sia improbabile che venga richiesto un subset diverso di righe del set di dati oppure, quando il numero di righe del set di dati da filtrare è probabilmente molto grande (e inefficiente da memorizzare nella cache). Questo approccio di progettazione funziona bene anche quando l'archivio dati è volatile. In questo caso, ogni modifica del valore del parametro del report comporterà il recupero dei dati aggiornati.

Origini dati non native

Se è necessario sviluppare report impaginati basati su origini dati non supportate in modo nativo dai report impaginati, è prima necessario sviluppare un modello di dati in Power BI Desktop. In questo modo, è possibile connettersi a centinaia di origini dati supportate da Power BI. Dopo la pubblicazione nel servizio Power BI, è possibile sviluppare un report impaginato che si connette al modello semantico di Power BI.

Integrazione dei dati

Se è necessario combinare dati da più origini dati, sono disponibili due opzioni:

  • Combinare set di dati di report: se le origini dati sono supportate in modo nativo dai report impaginati, è possibile creare campi calcolati che usano le funzioni lookup o LookupSet Generatore report.
  • Sviluppare un modello di Power BI Desktop: è probabile che sia più efficiente, tuttavia, sviluppare un modello di dati in Power BI Desktop. È possibile usare Power Query per combinare query basate su qualsiasi origine dati supportata. Dopo la pubblicazione nel servizio Power BI, è possibile sviluppare un report impaginato che si connette al modello semantico di Power BI.

Latenza di rete

La latenza di rete può influire sulle prestazioni del report aumentando il tempo necessario per consentire alle richieste di raggiungere il servizio Power BI e per il recapito delle risposte. I tenant in Power BI vengono assegnati a un'area specifica.

Suggerimento

Per determinare dove si trova il tenant, vedere Dove si trova il tenant di Power BI?

Quando gli utenti di un tenant accedono al servizio Power BI, le richieste instradano sempre a questa area. Quando le richieste raggiungono il servizio Power BI, il servizio può quindi inviare richieste aggiuntive, ad esempio all'origine dati sottostante o a un gateway dati, che sono soggette anche alla latenza di rete. In generale, per ridurre al minimo l'impatto della latenza di rete, cercare di mantenere le origini dati, i gateway e la capacità di Power BI il più vicino possibile. Preferibilmente, risiedono all'interno della stessa area. Se la latenza di rete è un problema, provare a individuare gateway e origini dati più vicine alla capacità di Power BI inserendoli all'interno di macchine virtuali ospitate nel cloud.

Tipi di dati complessi di SQL Server

Poiché SQL Server è un'origine dati locale, Power BI deve connettersi tramite un gateway. Il gateway, tuttavia, non supporta il recupero dei dati per tipi di dati complessi. I tipi di dati complessi includono tipi predefiniti come i tipi di dati spaziali GEOMETRY e GEOGRAPHY e hierarchyid. Possono anche includere tipi definiti dall'utente implementati tramite una classe di un assembly in Common Language Runtime (CLR) di Microsoft.NET Framework.

Per tracciare dati spaziali e analisi nella visualizzazione mappa sono necessari dati spaziali di SQL Server. Pertanto, non è possibile usare la visualizzazione mappa quando SQL Server è l'origine dati. Per essere chiari, funzionerà se l'origine dati è database SQL di Azure perché Power BI non si connette tramite un gateway.

Le immagini possono essere usate per aggiungere logo o immagini al layout del report. Quando le immagini sono correlate alle righe recuperate da un set di dati del report, sono disponibili due opzioni:

  • È possibile che i dati dell'immagine possano essere recuperati anche dall'origine dati (se già archiviati in una tabella).
  • Quando le immagini vengono archiviate in un server Web, è possibile usare un'espressione dinamica per creare il percorso dell'URL dell'immagine.

Per altre informazioni e suggerimenti, vedere Indicazioni sulle immagini per i report impaginati.

Recupero dei dati ridondante

È possibile che il report recuperi i dati ridondanti. Questo problema può verificarsi quando si eliminano i campi di query del set di dati o il report contiene set di dati inutilizzati. Evitare queste situazioni, perché comportano un carico non necessario per le origini dati, la rete e le risorse di capacità di Power BI.

Campi di query eliminati

Nella pagina Campi della finestra Proprietà set di dati è possibile eliminare i campi di query del set di dati (i campi di query vengono mappati alle colonne recuperate dalla query del set di dati). Tuttavia, Generatore report non rimuove le colonne corrispondenti dalla query del set di dati.

Se è necessario eliminare i campi di query dal set di dati, è consigliabile rimuovere le colonne corrispondenti dalla query del set di dati. Generatore report rimuoverà automaticamente tutti i campi di query ridondanti. Se si verificano errori di eliminazione dei campi di query, assicurarsi di modificare anche l'istruzione di query del set di dati per rimuovere le colonne.

Set di dati inutilizzati

Quando viene eseguito un report, tutti i set di dati vengono valutati, anche se non sono associati agli oggetti report. Per questo motivo, assicurarsi di rimuovere tutti i set di dati di test o sviluppo prima di pubblicare un report.

Contenuto correlato

Per altre informazioni relative a questo articolo, vedere le risorse seguenti: