Eventi
Ottieni gratuitamente la certificazione in Microsoft Fabric.
19 nov, 23 - 10 dic, 23
Per un periodo di tempo limitato, il team della community di Microsoft Fabric offre buoni per esami DP-600 gratuiti.
Prepara oraQuesto browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
Questo articolo è rivolto agli autori di report che progettano report impaginati di Power BI. Offre indicazioni utili per progettare un recupero dei dati efficace ed efficiente.
I report impaginati supportano in modo nativo le origini dati relazionali e analitiche. Queste origini sono ulteriormente categorizzate, come basate sul cloud o archiviate in locale. Le origini dati locali, ospitate in locale o in una macchina virtuale, richiedono un gateway dati per consentire la connessione di Power BI. Le origini dati basate sul cloud consentono invece a Power BI di connettersi direttamente tramite Internet.
Se è possibile scegliere il tipo di origine dati, ad esempio nel caso di 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. È inoltre possibile connettersi a queste origini usando l'accesso Single Sign-On (SSO). Ciò significa che l'identità dell'utente del report può essere passata all'origine dati, consentendo l'applicazione di 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 a database locali tramite SSO, è comunque possibile applicare autorizzazioni a livello di riga. A tale scopo, passare il campo predefinito UserID a un parametro della query del set di dati. L'origine dati dovrà archiviare i valori del nome dell'entità utente (UPN) in modo da poter filtrare correttamente i risultati della query.
Si supponga, ad esempio, che ogni venditore venga archiviato come riga nella tabella Venditori. La tabella contiene colonne per l'UPN e anche per l'area di vendita del venditore. In fase di query, la tabella viene filtrata in base all'UPN dell'utente del report ed è anche correlata ai fatti di vendita tramite un inner join. In questo modo, la query filtra anche le righe dei fatti di vendita in base a quelle dell'area di vendita dell'utente del report.
In genere le origini dati relazionali sono ideali per i report di tipo operativo, ad esempio le fatture di vendita. Sono inoltre adatte ai report che devono recuperare set di dati di dimensioni molto grandi (oltre le 10.000 righe). Le origini dati relazionali possono anche definire stored procedure, che possono essere eseguite dai set di dati dei report. Le stored procedure offrono diversi vantaggi:
In Power BI Report Builder è possibile usare lo strumento di progettazione di query relazionali per creare graficamente un'istruzione di query, ma solo per le origini dati Microsoft.
Le origini dati analitiche, conosciute anche come modelli di dati o semplicemente modelli, sono particolarmente adatte ai report operativi e analitici e possono restituire velocemente risultati di query riepilogativi anche su volumi di dati molto grandi. Le misure e gli indicatori KPI del modello possono incapsulare regole di business complesse per ottenere un riepilogo dei dati. Queste origini dati non sono tuttavia adatte ai report che devono recuperare volumi di dati di dimensioni molto grandi (oltre 10.000 righe).
In Generatore report di Power BI è possibile scegliere due strumenti di progettazione query: lo strumento di progettazione di query DAX di Analysis Services e quello di query MDX di Analysis Services. Queste finestre di progettazione possono essere usate per le origini dati del modello semantico di Power BI o per qualsiasi modello di SQL Server Analysis Services o Azure Analysis Services, tabulare o multidimensionale.
È consigliabile usare lo strumento di progettazione di query DAX, purché che soddisfi pienamente le proprie 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 il riepilogo dei dati).
Per l'uso dello strumento di progettazione di query MDX è necessario che il modello includa misure. Questo strumento presenta due funzionalità che non sono supportate dallo strumento di progettazione di query DAX. In particolare, consente di eseguire queste operazioni:
È in genere consigliabile recuperare solo i dati necessari per il report. Evitare quindi di recuperare le colonne o le righe che non sono necessarie per il report.
Per limitare le righe, si dovrebbero sempre applicare i filtri più restrittivi e definire query di aggregazione. Le query di aggregazione raggruppano e riepilogano i dati di origine per recuperare i risultati con maggiore granularità. Si supponga, ad esempio, che il report debba presentare un riepilogo delle vendite dei venditori. Invece di recuperare tutte le righe degli ordini di vendita, creare una query del set di dati che raggruppa i dati per venditore e riepiloga le vendite per ogni gruppo.
È possibile estendere un set di dati del report con campi basati su espressioni. Se, ad esempio, il set di dati è l'origine del nome e del cognome del cliente, può essere opportuno definire un campo che concatena i due campi per generare il nome completo del cliente. Per ottenere questo calcolo, sono disponibili due opzioni. È possibile:
È consigliabile usare la seconda opzione, quando possibile. Esistono due buoni motivi per cui è preferibile inserire espressioni direttamente nella query del set di dati:
Quando si crea un set di dati, ai campi vengono assegnati automaticamente i nomi delle colonne della query. È possibile che questi nomi non siano semplici o intuitivi. È inoltre possibile che i nomi delle colonne della 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 innanzitutto che tutti i nomi dei campi siano semplici e concisi, benché significativi. In caso contrario, è consigliabile rinominarli prima di avviare la generazione del layout del report. Questo perché i campi rinominati non trasferiscono le modifiche alle espressioni usate nel layout del report. Se si decide di rinominare i campi dopo aver avviato la generazione del layout del report, sarà necessario trovare e aggiornare tutte le espressioni che presentano interruzioni.
È probabile che le progettazioni di report impaginati includano parametri di report. Questi parametri vengono in genere usati per richiedere all'utente di filtrare il report. Gli autori di report impaginati hanno a disposizione due modi per consentire l'applicazione di filtri ai report. Possono eseguire il mapping di un parametro del report agli elementi seguenti:
Nota
Tutti i set di dati del report vengono memorizzati nella cache a livello di singola sessione per un massimo di 10 minuti dall'ultimo utilizzo. Un set di dati può essere riutilizzato quando si inviano nuovi valori di parametro (filtro), si esegue il rendering del report in un formato diverso o si interagisce in qualche modo con la progettazione del report, ad esempio attivando la visibilità o modificando l'ordinamento.
Si consideri, ad esempio, un report relativo alle vendite con un solo parametro per filtrare i dati di un singolo anno. Il set di dati recupera le vendite per tutti gli anni. Questo avviene perché il parametro del report è mappato ai filtri del set di dati. Nel report vengono visualizzati i dati relativi all'anno richiesto, ovvero un subset del set di dati. Quando l'utente del report modifica il parametro del report impostando un anno diverso e quindi visualizza il report, Power BI non deve recuperare i dati dall'origine, ma semplicemente applicare un filtro diverso al set di dati già memorizzato nella cache. Quando il set di dati è memorizzato nella cache, l'applicazione di filtri può essere molto veloce.
Si consideri ora una diversa progettazione del report. Questa volta viene eseguito il mapping del parametro del report relativo all'anno delle vendite a un parametro del set di dati. Power BI inserisce quindi il valore dell'anno nella query nativa e il set di dati recupera i dati solo per tale anno. Ogni volta che l'utente del report modifica il valore del parametro relativo all'anno, e quindi visualizza il report, il set di dati recupera un nuovo risultato della query solo per tale anno.
Entrambi gli approcci di progettazione possono filtrare i dati del report ed entrambe le soluzioni possono essere usate per le progettazioni di report. La soluzione ottimale, tuttavia, dipenderà dai volumi di dati previsti, dalla volatilità dei dati e dai comportamenti previsti degli utenti del report.
È consigliabile adottare la soluzione basata sull'applicazione di un filtro al set di dati quando si prevede che vengano usati più volte subset diversi di righe del set di dati. Questa soluzione consente di infatti di risparmiare il tempo di rendering perché non comporta il recupero di nuovi dati. In questo scenario è evidente che il costo legato al recupero di un set di dati più grande può essere controbilanciato dal numero di volte in cui verrà riutilizzato. Una soluzione di questo tipo è quindi utile per le query la cui generazione richiede molto tempo. Prestare tuttavia attenzione al fatto che la memorizzazione nella cache di set di dati di grandi dimensioni per singolo utente può influire negativamente sulle prestazioni e sulla velocità effettiva della capacità.
È consigliabile adottare la soluzione basata sulla parametrizzazione del set di dati quando è poco probabile che venga richiesto un subset diverso di righe del set di dati oppure quando il numero di righe da filtrare è presumibilmente molto grande (e quindi la memorizzazione nella cache può risultare poco efficiente). Questo approccio di progettazione è efficace anche quando l'archivio dati è volatile. In questo caso, ogni modifica del valore del parametro del report comporterà il recupero dei dati aggiornati.
Se è necessario sviluppare report impaginati basati su origini dati che non sono supportate in modo nativo dai report impaginati, è necessario sviluppare prima di tutto 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.
Se è necessario combinare dati da più origini dati, sono disponibili due opzioni:
La latenza di rete può influire sulle prestazioni dei report allungando i tempi necessari alle richieste per raggiungere il servizio Power BI e per restituire le risposte. I tenant in Power BI sono assegnati a un'area specifica.
Suggerimento
Per determinare la posizione del tenant, vedere Dove si trova il tenant di Power BI?
Quando gli utenti in un tenant accedono al servizio Power BI, le richieste vengono sempre indirizzate a quest'area. Quando le richieste raggiungono il servizio Power BI, il servizio può inviare richieste aggiuntive, ad esempio al gateway dati o all'origine dati sottostante, a loro volta soggette alla latenza di rete. In generale, per ridurre al minimo l'impatto della latenza di rete, cercare di tenere le origini dati, i gateway e la capacità di Power BI il più vicini possibile. Preferibilmente all'interno della stessa area. Se la latenza di rete costituisce un problema, provare a cambiare l'area di gateway e origini dati posizionandoli in macchine virtuali ospitate nel cloud in un'area più vicina alla capacità di Power BI.
Poiché SQL Server è un'origine dati locale, Power BI deve connettersi tramite un gateway. Quest'ultimo, tuttavia, non supporta il recupero di dati per tipi di dati complessi, tra cui i tipi di dati spaziali GEOMETRY e GEOGRAPHY e hierarchyid. Sono anche inclusi i tipi definiti dall'utente implementati tramite una classe di un assembly in Microsoft .NET Framework Common Language Runtime (CLR).
Per tracciare i dati spaziali e le analisi nella visualizzazione mappa sono necessari i dati spaziali di SQL Server. Non è quindi possibile usare la visualizzazione mappa quando SQL Server è l'origine dati. Questo è invece possibile se l'origine dati è il database SQL di Azure, perché in tal caso Power BI non si connette tramite un gateway.
È possibile usare le immagini per aggiungere logo o foto al layout del report. Quando le immagini sono correlate alle righe recuperate da un set di dati del report, sono disponibili due opzioni:
Per altre informazioni e suggerimenti, vedere Linee guida per l'uso di immagini nei report impaginati.
È possibile che il report recuperi dati ridondanti. Questo può verificarsi quando si eliminano campi di query del set di dati o se nel report sono presenti set di dati inutilizzati. Evitare situazioni di questo tipo, perché comportano un carico di lavoro superfluo sulle origini dati, la rete e le risorse di capacità di Power BI.
Nella pagina Campi della finestra Proprietà set di dati è possibile eliminare i campi della query del set di dati (i campi della query sono mappati alle colonne recuperate dalla query del set di dati). In questo caso, tuttavia, Report Builder non rimuove le colonne corrispondenti dalla query del set di dati.
Se è necessario eliminare campi della query dal set di dati, è consigliabile rimuovere le colonne corrispondenti dalla query. Report Builder eliminerà automaticamente eventuali campi della query ridondanti. Se si eliminano i campi della query, assicurarsi di modificare anche l'istruzione della query del set di dati in modo da rimuovere le colonne.
Quando si esegue un report, vengono valutati tutti i set di dati, anche se non sono associati a oggetti di report. Per questo motivo, assicurarsi di rimuovere tutti i set di dati di test o di sviluppo prima di pubblicare un report.
Per altre informazioni correlate a questo articolo, vedere le risorse seguenti:
Eventi
Ottieni gratuitamente la certificazione in Microsoft Fabric.
19 nov, 23 - 10 dic, 23
Per un periodo di tempo limitato, il team della community di Microsoft Fabric offre buoni per esami DP-600 gratuiti.
Prepara oraFormazione
Modulo
Creazione di un set di dati per un report Power BI in Dynamics 365 Business Central - Training
Informazioni su come creare un set di dati per un report Power BI in Business Central usando l'impostazione della creazione report assistita e i set di dati personalizzati.