Använda sammanhängande parametrar i sidnumrerade rapporter

Den här artikeln riktar sig till dig som rapportförfattare och utformar sidnumrerade Power BI-rapporter. Den innehåller scenarier för att utforma sammanhängande parametrar. Sammanhängande parametrar är rapportparametrar med beroenden. När en rapportanvändare väljer ett parametervärde (eller värden) används det för att ange tillgängliga värden för en annan parameter.

Kommentar

En introduktion till sammanhängande parametrar och hur du konfigurerar dem beskrivs inte i den här artikeln. Om du inte är helt bekant med sammanhängande parametrar rekommenderar vi att du först läser Lägg till sammanhängande parametrar i en rapport i Power BI Report Builder.

Designscenarier

Det finns två designscenarier för att använda sammanhängande parametrar. De kan användas effektivt för att:

• Filtrera stora uppsättningar med objekt
• Presentera relevanta objekt

Exempeldatabas

Exemplen som presenteras i den här artikeln baseras på en Azure SQL Database. Databasen registrerar försäljningsåtgärder och innehåller olika tabeller som lagrar återförsäljare, produkter och försäljningsorder.

En tabell med namnet Reseller lagrar en post för varje återförsäljare och innehåller tusentals poster. Tabellen Reseller innehåller följande kolumner:

• ResellerCode (heltal)
• ResellerName
• Country-Region
• State-Province
• Ort
• PostalCode

Det finns också en tabell med namnet Försäljning. Den lagrar försäljningsorderposter och har en sekundärnyckelrelation till tabellen Återförsäljare i kolumnen ResellerCode .

Exempelkrav

Det finns ett krav på att utveckla en resellerprofilrapport. Rapporten måste vara utformad för att visa information för en enda återförsäljare. Det är inte lämpligt att låta rapportanvändaren ange en återförsäljarkod, eftersom de sällan memorerar dem.

Filtrera stora uppsättningar med objekt

Låt oss ta en titt på tre exempel som hjälper dig att begränsa stora uppsättningar av tillgängliga objekt, till exempel återförsäljare. Dessa är:

• Filtrera efter relaterade kolumner
• Filtrera efter en grupperingskolumn
• Filtrera efter sökmönster

Filtrera efter relaterade kolumner

I det här exemplet interagerar rapportanvändaren med fem rapportparametrar. De måste välja land-region, delstat-provins, stad och sedan postnummer. En sista parameter visar sedan återförsäljare som finns på den geografiska platsen.

Så här kan du utveckla de sammanhängande parametrarna:

1. Skapa de fem rapportparametrarna, ordnade i rätt sekvens.

2. Skapa datauppsättningen CountryRegion som hämtar distinkta värden för land-region med hjälp av följande frågeuttryck:

   SELECT DISTINCT
     [Country-Region]
   FROM
     [Reseller]
   ORDER BY
     [Country-Region]
   

3. Skapa datauppsättningen StateProvince som hämtar distinkta delstatsprovinsvärden för den valda land-regionen med hjälp av följande frågeuttryck:

   SELECT DISTINCT
     [State-Province]
   FROM
     [Reseller]
   WHERE
     [Country-Region] = @CountryRegion
   ORDER BY
     [State-Province]
   

4. Skapa datauppsättningen Stad som hämtar distinkta stadsvärden för den valda regionen och delstatsprovinsen med hjälp av följande frågeuttryck:

   SELECT DISTINCT
     [City]
   FROM
     [Reseller]
   WHERE
     [Country-Region] = @CountryRegion
     AND [State-Province] = @StateProvince
   ORDER BY
     [City]
   

5. Fortsätt det här mönstret för att skapa postnummerdatauppsättningen.

6. Skapa datauppsättningen Reseller för att hämta alla återförsäljare för de valda geografiska värdena med hjälp av följande frågeuttryck:

   SELECT
     [ResellerCode],
     [ResellerName]
   FROM
     [Reseller]
   WHERE
     [Country-Region] = @CountryRegion
     AND [State-Province] = @StateProvince
     AND [City] = @City
     AND [PostalCode] = @PostalCode
   ORDER BY
     [ResellerName]
   

7. För varje datauppsättning utom den första mappar du frågeparametrarna till motsvarande rapportparametrar.

Kommentar

Alla frågeparametrar (prefix med @-symbolen) som visas i dessa exempel kan bäddas in i SELECT-instruktioner eller skickas till lagrade procedurer.

I allmänhet är lagrade procedurer en bättre designmetod. Det beror på att deras frågeplaner cachelagras för snabbare körning, och de gör att du kan utveckla mer avancerad logik när det behövs. De stöds dock inte för närvarande för gateway-relationsdatakällor, vilket innebär SQL Server, Oracle och Teradata.

Slutligen bör du alltid se till att det finns lämpliga index för effektiv datahämtning. Annars kan rapportparametrarna vara långsamma att fylla i och databasen kan bli överbelastad. Mer information om SQL Server-indexering finns i ARKITEKTUR och designguide för SQL Server-index.

Filtrera efter en grupperingskolumn

I det här exemplet interagerar rapportanvändaren med en rapportparameter för att välja den första bokstaven i återförsäljaren. En andra parameter visar sedan återförsäljare när namnet börjar med den valda bokstaven.

Så här kan du utveckla de sammanhängande parametrarna:

1. Skapa rapportparametrarna ReportGroup och Reseller, ordnade i rätt ordning.

2. Skapa reportgroup-datauppsättningen för att hämta de första bokstäverna som används av alla återförsäljare med hjälp av följande frågeuttryck:

   SELECT DISTINCT
     LEFT([ResellerName], 1) AS [ReportGroup]
   FROM
     [Reseller]
   ORDER BY
     [ReportGroup]
   

3. Skapa datauppsättningen Reseller för att hämta alla återförsäljare som börjar med den valda bokstaven med hjälp av följande frågeuttryck:

   SELECT
     [ResellerCode],
     [ResellerName]
   FROM
     [Reseller]
   WHERE
     LEFT([ResellerName], 1) = @ReportGroup
   ORDER BY
     [ResellerName]
   

4. Mappa frågeparametern för datauppsättningen Reseller till motsvarande rapportparameter.

Det är mer effektivt att lägga till grupperingskolumnen i tabellen Återförsäljare . När det sparas och indexeras ger det det bästa resultatet. Mer information finns i Ange beräknade kolumner i en tabell.

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

Den här tekniken kan ge ännu större potential. Tänk på följande skript som lägger till en ny grupperingskolumn för att filtrera återförsäljare efter fördefinierade teckenband. Det skapar också ett index för att effektivt hämta de data som krävs av rapportparametrarna.

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

Filtrera efter sökmönster

I det här exemplet interagerar rapportanvändaren med en rapportparameter för att ange ett sökmönster. En andra parameter visar sedan återförsäljare när namnet innehåller mönstret.

Så här kan du utveckla de sammanhängande parametrarna:

1. Skapa rapportparametrarna Sök och Återförsäljare, ordnade i rätt ordning.

2. Skapa datauppsättningen Reseller (Återförsäljare) för att hämta alla återförsäljare som innehåller söktexten med hjälp av följande frågeuttryck:

   SELECT
     [ResellerCode],
     [ResellerName]
   FROM
     [Reseller]
   WHERE
     [ResellerName] LIKE '%' + @Search + '%'
   ORDER BY
     [ResellerName]
   

3. Mappa frågeparametern för datauppsättningen Reseller till motsvarande rapportparameter.

Dricks

Du kan förbättra den här designen för att ge mer kontroll för dina rapportanvändare. Det gör att de kan definiera sitt eget mönstermatchningsvärde. Till exempel filtrerar sökvärdet "red%" till återförsäljare med namn som börjar med tecknen "röd".

Mer information finns i LIKE (Transact-SQL).

Så här kan du låta rapportanvändarna definiera sitt eget mönster.

WHERE
  [ResellerName] LIKE @Search

Många icke-databasproffs vet dock inte om jokertecknet i procent (%). I stället är de bekanta med asterisktecknet (*). Genom att ändra WHERE-satsen kan du låta dem använda det här tecknet.

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

Presentera relevanta objekt

I det här scenariot kan du använda faktadata för att begränsa tillgängliga värden. Rapportanvändare visas med objekt där aktiviteten har registrerats.

I det här exemplet interagerar rapportanvändaren med tre rapportparameter. De två första anger ett datumintervall för försäljningsorderdatum. Den tredje parametern visar sedan återförsäljare där beställningar har skapats under den tidsperioden.

Så här kan du utveckla de sammanhängande parametrarna:

1. Skapa rapportparametrarna OrderDateStart, OrderDateEnd och Reseller, ordnade i rätt ordning.

2. Skapa datauppsättningen Reseller (Återförsäljare ) för att hämta alla återförsäljare som skapade beställningar under datumperioden med hjälp av följande frågeuttryck:

   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]
   

Rekommendationer

Vi rekommenderar att du utformar dina rapporter med sammanhängande parametrar när det är möjligt. Det är för att de:

• Tillhandahålla intuitiva och användbara upplevelser för rapportanvändarna
• Är effektiva eftersom de hämtar mindre uppsättningar med tillgängliga värden

Se till att optimera dina datakällor genom att:

• Använda lagrade procedurer, när det är möjligt
• Lägga till lämpliga index för effektiv datahämtning
• Materialisera kolumnvärden – och till och med rader – för att undvika dyra frågetidsutvärderingar

Relaterat innehåll

Mer information om den här artikeln finns i följande resurser:

• Rapportparametrar i Power BI Report Builder
• Lägga till sammanhängande parametrar i en rapport (Report Builder)
• Frågor? Prova att fråga Power BI Community
• Förslag? Bidra med idéer för att förbättra Power BI