Condividi tramite


Usare parametri a catena nei report impaginati

Questo articolo è destinato all'autore di report che progetta report impaginati di Power BI. Fornisce scenari per la progettazione di parametri a catena. I parametri a catena sono parametri del report con dipendenze. Quando un utente del report seleziona un valore di parametro (o valori), viene usato per impostare i valori disponibili per un altro parametro.

Nota

Un'introduzione ai parametri a catena e a come configurarle non è descritta in questo articolo. Se non si ha familiarità con i parametri a catena, è consigliabile leggere prima di tutto Aggiungere parametri a catena a un report in Power BI Generatore report.

Scenari di progettazione

Esistono due scenari di progettazione per l'uso di parametri a catena. Possono essere usati in modo efficace per:

  • Filtrare set di elementi di grandi dimensioni
  • Presentare gli elementi pertinenti

Esempio di database

Gli esempi presentati in questo articolo si basano su un database SQL di Azure. Il database registra le operazioni di vendita e contiene varie tabelle che archiviano rivenditori, prodotti e ordini di vendita.

Una tabella denominata Reseller archivia un record per ogni rivenditore e contiene molte migliaia di record. La tabella Reseller include le colonne seguenti:

  • ResellerCode (integer)
  • ResellerName
  • Country-Region
  • State-Province
  • Città
  • PostalCode

Esiste anche una tabella denominata Sales. Archivia i record degli ordini di vendita e ha una relazione di chiave esterna con la tabella Reseller nella colonna ResellerCode.

Requisito di esempio

È necessario sviluppare un report Del profilo rivenditore. Il report deve essere progettato per visualizzare informazioni per un singolo rivenditore. Non è opportuno che l'utente del report immetta un codice rivenditore, perché raramente li memorizza.

Filtrare set di elementi di grandi dimensioni

Verranno ora esaminati tre esempi che consentono di limitare grandi set di articoli disponibili, ad esempio i rivenditori. Sono:

In questo esempio l'utente del report interagisce con cinque parametri del report. Devono selezionare paese-regione, provincia, città e quindi codice postale. Un parametro finale elenca quindi i rivenditori che risiedono in tale posizione geografica.

Screenshot of Power BI paginated report parameters showing filter by related columns.

Ecco come sviluppare i parametri a catena:

  1. Creare i cinque parametri del report, ordinati nella sequenza corretta.

  2. Creare il set di dati CountryRegion che recupera valori di paese distinti usando l'istruzione di query seguente:

    SELECT DISTINCT
      [Country-Region]
    FROM
      [Reseller]
    ORDER BY
      [Country-Region]
    
  3. Creare il set di dati StateProvince che recupera i valori distinct state-province per l'area geografica selezionata usando l'istruzione di query seguente:

    SELECT DISTINCT
      [State-Province]
    FROM
      [Reseller]
    WHERE
      [Country-Region] = @CountryRegion
    ORDER BY
      [State-Province]
    
  4. Creare il set di dati City che recupera valori di città distinti per l'area geografica e la provincia di stato selezionati usando l'istruzione di query seguente:

    SELECT DISTINCT
      [City]
    FROM
      [Reseller]
    WHERE
      [Country-Region] = @CountryRegion
      AND [State-Province] = @StateProvince
    ORDER BY
      [City]
    
  5. Continuare questo modello per creare il set di dati PostalCode .

  6. Creare il set di dati Reseller per recuperare tutti i rivenditori per i valori geografici selezionati usando l'istruzione di query seguente:

    SELECT
      [ResellerCode],
      [ResellerName]
    FROM
      [Reseller]
    WHERE
      [Country-Region] = @CountryRegion
      AND [State-Province] = @StateProvince
      AND [City] = @City
      AND [PostalCode] = @PostalCode
    ORDER BY
      [ResellerName]
    
  7. Per ogni set di dati, ad eccezione del primo, eseguire il mapping dei parametri di query ai parametri del report corrispondenti.

Nota

Tutti i parametri di query (preceduti dal simbolo @) visualizzati in questi esempi possono essere incorporati all'interno di istruzioni edizione Standard LECT o passate alle stored procedure.

In genere, le stored procedure sono un approccio di progettazione migliore. Perché i piani di query vengono memorizzati nella cache per un'esecuzione più rapida e consentono di sviluppare logica più sofisticata, se necessario. Tuttavia, non sono attualmente supportati per le origini dati relazionali del gateway, ovvero SQL Server, Oracle e Teradata.

Infine, è consigliabile assicurarsi sempre che esistano indici adatti per supportare un recupero efficiente dei dati. In caso contrario, i parametri del report potrebbero essere lenti a popolare e il database potrebbe diventare sovraccarico. Per altre informazioni sull'indicizzazione di SQL Server, vedere Architettura e progettazione degli indici di SQL Server.

Filtrare in base a una colonna di raggruppamento

In questo esempio l'utente del report interagisce con un parametro del report per selezionare la prima lettera del rivenditore. Un secondo parametro elenca quindi i rivenditori quando il nome inizia con la lettera selezionata.

Screenshot of Power BI paginated report parameters showing filter by a grouping column.

Ecco come sviluppare i parametri a catena:

  1. Creare i parametri del report ReportGroup e Reseller ordinati nella sequenza corretta.

  2. Creare il set di dati ReportGroup per recuperare le prime lettere usate da tutti i rivenditori usando l'istruzione di query seguente:

    SELECT DISTINCT
      LEFT([ResellerName], 1) AS [ReportGroup]
    FROM
      [Reseller]
    ORDER BY
      [ReportGroup]
    
  3. Creare il set di dati Reseller per recuperare tutti i rivenditori che iniziano con la lettera selezionata, usando l'istruzione di query seguente:

    SELECT
      [ResellerCode],
      [ResellerName]
    FROM
      [Reseller]
    WHERE
      LEFT([ResellerName], 1) = @ReportGroup
    ORDER BY
      [ResellerName]
    
  4. Eseguire il mapping del parametro di query del set di dati Reseller al parametro del report corrispondente.

È più efficiente aggiungere la colonna di raggruppamento alla tabella Reseller . Se persistente e indicizzato, offre il risultato migliore. Per altre informazioni, vedere Specificare le colonne calcolate in una tabella.

ALTER TABLE [Reseller]
ADD [ReportGroup] AS LEFT([ResellerName], 1) PERSISTED

Questa tecnica può offrire un potenziale ancora maggiore. Si consideri lo script seguente che aggiunge una nuova colonna di raggruppamento per filtrare i rivenditori in base a bande di lettere predefinite. Crea inoltre un indice per recuperare in modo efficiente i dati richiesti dai parametri del report.

ALTER TABLE [Reseller]
ADD [ReportGroup2] AS CASE
  WHEN [ResellerName] LIKE '[A-C]%' THEN 'A-C'
  WHEN [ResellerName] LIKE '[D-H]%' THEN 'D-H'
  WHEN [ResellerName] LIKE '[I-M]%' THEN 'I-M'
  WHEN [ResellerName] LIKE '[N-S]%' THEN 'N-S'
  WHEN [ResellerName] LIKE '[T-Z]%' THEN 'T-Z'
  ELSE '[Other]'
END PERSISTED
GO

CREATE NONCLUSTERED INDEX [Reseller_ReportGroup2]
ON [Reseller] ([ReportGroup2]) INCLUDE ([ResellerCode], [ResellerName])
GO

Filtrare in base al criterio di ricerca

In questo esempio l'utente del report interagisce con un parametro del report per immettere un criterio di ricerca. Un secondo parametro elenca quindi i rivenditori quando il nome contiene il modello.

Screenshot of Power BI paginated report parameters showing filter by search pattern.

Ecco come sviluppare i parametri a catena:

  1. Creare i parametri del report Search and Reseller , ordinati nella sequenza corretta.

  2. Creare il set di dati Reseller per recuperare tutti i rivenditori che contengono il testo di ricerca usando l'istruzione di query seguente:

    SELECT
      [ResellerCode],
      [ResellerName]
    FROM
      [Reseller]
    WHERE
      [ResellerName] LIKE '%' + @Search + '%'
    ORDER BY
      [ResellerName]
    
  3. Eseguire il mapping del parametro di query del set di dati Reseller al parametro del report corrispondente.

Suggerimento

È possibile migliorare questa progettazione per fornire un maggiore controllo per gli utenti del report. Consente loro di definire il proprio valore di corrispondenza dei criteri. Ad esempio, il valore di ricerca "red%" filtra i rivenditori con nomi che iniziano con i caratteri "rosso".

Per altre informazioni, vedere LIKE (Transact-SQL).

Ecco come consentire agli utenti del report di definire il proprio modello.

WHERE
  [ResellerName] LIKE @Search

Molti professionisti non di database, tuttavia, non conoscono il carattere jolly percentuale (%). Hanno invece familiarità con il carattere asterisco (*) . Modificando la clausola WHERE, è possibile consentire loro di usare questo carattere.

WHERE
  [ResellerName] LIKE SUBSTITUTE(@Search, '%', '*')

Presentare gli elementi pertinenti

In questo scenario è possibile usare i dati dei fatti per limitare i valori disponibili. Gli utenti del report verranno presentati con gli elementi in cui è stata registrata l'attività.

In questo esempio l'utente del report interagisce con tre parametri del report. I primi due impostano un intervallo di date di date degli ordini di vendita. Il terzo parametro elenca quindi i rivenditori in cui gli ordini sono stati creati durante tale periodo di tempo.

Screenshot of Power BI paginated report parameters showing three report parameters: Start Order Date, End Order Date, and Reseller.

Ecco come sviluppare i parametri a catena:

  1. Creare i parametri del report OrderDateStart, OrderDateEnd e Reseller , ordinati nella sequenza corretta.

  2. Creare il set di dati Reseller per recuperare tutti i rivenditori che hanno creato ordini nel periodo di data usando l'istruzione di query seguente:

    SELECT DISTINCT
      [r].[ResellerCode],
      [r].[ResellerName]
    FROM
      [Reseller] AS [r]
    INNER JOIN [Sales] AS [s]
      ON [s].[ResellerCode] = [r].[ResellerCode]
    WHERE
      [s].[OrderDate] >= @OrderDateStart
      AND [s].[OrderDate] < DATEADD(DAY, 1, @OrderDateEnd)
    ORDER BY
      [r].[ResellerName]
    

Consigli

È consigliabile progettare i report con parametri a catena, quando possibile. Perché:

  • Offrire esperienze intuitive e utili per gli utenti del report
  • Sono efficienti perché recuperano set più piccoli di valori disponibili

Assicurarsi di ottimizzare le origini dati in base a:

  • Utilizzo di stored procedure, quando possibile
  • Aggiunta di indici appropriati per un recupero efficiente dei dati
  • Materializzazione dei valori delle colonne e persino delle righe per evitare valutazioni costose in fase di query

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