Guide till datahämtning i sidnumrerade rapporter

  • Artikel
  • 9 minuter för att läsa

Den här artikeln är avsedd för rapportförfattare som skapar sidnumrerade rapporter i Power BI. Den ger rekommendationer som hjälper dig att utforma effektiv datahämtning.

Typer av datakälla

Sidnumrerade rapporter har inbyggt stöd för både relations- och analysdatakällor. Dessa källor kategoriseras ytterligare, antingen som molnbaserade eller lokala. Lokala datakällor – oavsett om de finns lokalt eller på en virtuell dator – kräver en datagateway så att Power BI kan ansluta. Molnbaserade innebär att Power BI kan ansluta direkt via en Internetanslutning.

Om du kan välja typ av datakälla (eventuellt i ett nytt projekt) rekommenderar vi att du använder molnbaserade datakällor. Sidnumrerade rapporter kan ansluta med kortare nätverksfördröjning, särskilt när datakällorna finns i samma region som din Power BI klientorganisation. Det är också möjligt att ansluta till dessa källor med enkel inloggning Sign-On (SSO). Det innebär att rapportanvändarens identitet kan flöda till datakällan, vilket gör att behörigheter på radnivå per användare kan tillämpas. För närvarande stöds inte enkel inloggning för lokala datakällor (vilket innebär SQL Server Analysis Services inte kan framtvinga behörigheter på radnivå per användare).

Anteckning

Även om det för närvarande inte går att ansluta till lokala databaser med enkel inloggning kan du fortfarande framtvinga behörigheter på radnivå. Det görs genom att skicka det inbyggda fältet UserID till en frågeparameter för datauppsättningen. Datakällan måste lagra UPN-värden (User Principal Name) på ett sätt som gör att frågeresultaten kan filtreras korrekt.

Tänk dig till exempel att varje säljare lagras som en rad i tabellen Säljare. Tabellen innehåller kolumner för UPN och även säljarens försäljningsregion. Vid frågetiden filtreras tabellen efter rapportanvändarens UPN och den är också relaterad till försäljningsfakta med hjälp av en inre koppling. På så sätt filtrerar frågan effektivt försäljningsdefrågerader till rapportanvändarens försäljningsregion.

Relationsdatakällor

I allmänhet är relationsdatakällor väl lämpade för rapporter i driftformat, till exempel försäljningsfakturor. De passar också för rapporter som behöver hämta mycket stora datauppsättningar (över 10 000 rader). Relationsdatakällor kan också definiera lagrade procedurer som kan köras av rapportdatamängder. Lagrade procedurer ger flera fördelar:

  • Parameterisering
  • Inkapsling av programmeringslogik, vilket möjliggör mer komplex dataförberedelse (till exempel temporära tabeller, markörer eller skalära användardefinierade funktioner)
  • Förbättrad underhållbarhet, vilket gör det enkelt att uppdatera lagrad procedurlogik. I vissa fall kan det göras utan att behöva ändra och publicera om sidnumrerade rapporter (förutsatt att kolumnnamn och datatyper förblir oförändrade).
  • Bättre prestanda eftersom deras körningsplaner cachelagras för återanvändning
  • Återanvändning av lagrade procedurer i flera rapporter

I Power BI Report Builder kan du använda relationsfrågedesignern för att grafiskt konstruera en frågesats, men endast för Microsoft-datakällor.

Analytiska datakällor

Analytiska datakällor passar bra för både operativa och analytiska rapporter och kan leverera snabba sammanfattade frågeresultat även över mycket stora datavolymer. Modellmått och KPI:er kan kapsla in komplexa affärsregler för att få en sammanfattning av data. Dessa datakällor passar dock inte för rapporter som behöver hämta mycket stora datamängder (över 10 000 rader).

I Power BI Report Builder kan du välja mellan två frågedesigners: Analysis Services DAX-frågedesignern och Analysis Services MDX-frågedesignern. Dessa designers kan användas för Power BI datauppsättningsdatakällor eller valfri SQL Server Analysis Services eller Azure Analysis Services modell – tabell eller flerdimensionell.

Vi rekommenderar att du använder DAX-frågedesignern, förutsatt att den uppfyller dina frågebehov. Om modellen inte definierar de mått du behöver måste du växla till frågeläge. I det här läget kan du anpassa frågeuttryck genom att lägga till uttryck (för att uppnå sammanfattning).

MDX-frågedesignern kräver att din modell innehåller mått. Designern har två funktioner som inte stöds av DAX-frågedesignern. Mer specifikt kan du:

  • Definiera beräknade medlemmar på frågenivå (i MDX).
  • Konfigurera dataområden för att begära serveraggregeringar i icke-detaljerade grupper. Om rapporten behöver presentera sammanfattningar av halv- eller icke-additiva mått (till exempel tidsinformationsberäkningar eller distinkta antal) är det förmodligen mer effektivt att använda serveraggregeringar än att hämta rader med detaljerad information på låg nivå och få rapportens beräkningssammanfattningar.

Frågeresultatstorlek

I allmänhet är det bästa praxis att endast hämta de data som krävs av rapporten. Hämta därför inte kolumner eller rader som inte krävs av rapporten.

Om du vill begränsa rader bör du alltid använda de mest restriktiva filtren och definiera mängdfrågor. Aggregera frågor grupperar och sammanfattar källdata för att hämta resultat med högre kornighet. Tänk dig till exempel att rapporten måste visa en sammanfattning av säljares försäljning. I stället för att hämta alla försäljningsorderrader skapar du en datamängdsfråga som grupperar efter säljare och sammanfattar försäljningen för varje grupp.

Uttrycksbaserade fält

Det går att utöka en rapportdatamängd med fält som baseras på uttryck. Om din datauppsättning till exempel använder kundens förnamn och efternamn kanske du vill ha ett fält som sammanfogar de två fälten för att skapa kundens fullständiga namn. För att uppnå den här beräkningen har du två alternativ. Du kan:

  • Skapa ett beräknat fält, som är ett datauppsättningsfält baserat på ett uttryck.
  • Mata in ett uttryck direkt i datauppsättningsfrågan (med det inbyggda språket i datakällan), vilket resulterar i ett vanligt datauppsättningsfält.

Vi rekommenderar det senare alternativet när det är möjligt. Det finns två bra skäl till varför det är bättre att mata in uttryck direkt i datauppsättningsfrågan:

  • Det är möjligt att datakällan är optimerad för att utvärdera uttrycket mer effektivt än Power BI (särskilt för relationsdatabaser).
  • Rapportprestandan förbättras eftersom det inte finns något behov Power BI att materialisera beräknade fält innan rapporten återges. Beräknade fält kan märkbart utöka rapportens återgivningstid när datauppsättningar hämtar ett stort antal rader.

Fältnamn

När du skapar en datauppsättning namnges dess fält automatiskt efter frågekolumnerna. Det är möjligt att dessa namn inte är användarvänliga eller intuitiva. Det är också möjligt att källfrågekolumnnamn innehåller tecken som är Report Definition Language (RDL) objektidentifierare (till exempel blanksteg och symboler). I det här fallet ersätts de otillåtna tecknen med ett understreck (_).

Vi rekommenderar att du först kontrollerar att alla fältnamn är användarvänliga, koncisa men ändå meningsfulla. Annars föreslår vi att du byter namn på dem innan du påbörjar rapportlayouten. Det beror på att omdöpta fält inte ändras till de uttryck som används i din rapportlayout. Om du bestämmer dig för att byta namn på fält när du har påbörjat rapportlayouten måste du hitta och uppdatera alla brutna uttryck.

Filtrera jämfört med parameter

Det är troligt att din sidnumrerade rapportdesign har rapportparametrar. Rapportparametrar används ofta för att uppmana rapportanvändaren att filtrera rapporten. Som sidnumrerad rapportförfattare har du två sätt att uppnå rapportfiltrering. Du kan mappa en rapportparameter till:

  • Ett datamängdsfilter, i vilket fall rapportparametervärdena används för att filtrera data som redan hämtats av datauppsättningen.
  • En datamängdsparameter, i vilket fall rapportparametervärdet(erna) matas in i den interna frågan som skickas till datakällan.

Anteckning

Alla rapportdatauppsättningar cachelagras per session i upp till 10 minuter efter den senaste användningen. En datauppsättning kan användas på nytt när du skickar nya parametervärden (filtrering), återger rapporten i ett annat format eller interagerar med rapportdesignen på något sätt, som att växla synlighet eller sortering.

Tänk dig sedan ett exempel på en försäljningsrapport som har en enda rapportparameter för att filtrera rapporten efter ett enda år. Datauppsättningen hämtar försäljning för alla år. Det beror på att rapportparametern mappar till datamängdsfiltren. Rapporten visar data för det begärda året, vilket är en delmängd av datauppsättningens data. När rapportanvändaren ändrar rapportparametern till ett annat år – och sedan visar rapporten – Power BI behöver inte hämta några källdata. I stället tillämpas ett annat filter på den redan cachelagrade datauppsättningen. När datauppsättningen har cachelagrats kan filtreringen gå mycket snabbt.

Överväg nu en annan rapportdesign. Den här gången mappar rapportdesignen rapportparametern försäljningsår till en datamängdsparameter. På så Power BI in årsvärdet i den interna frågan och datauppsättningen hämtar endast data för det året. Varje gång rapportanvändaren ändrar årsrapportparametervärdet – och sedan visar rapporten – hämtar datauppsättningen ett nytt frågeresultat för just det året.

Båda designsmetoderna kan filtrera rapportdata, och båda designerna kan fungera bra för din rapportdesign. En optimerad design beror dock på de förväntade datavolymerna, datavolatiliteten och de förväntade beteendena hos rapportanvändarna.

Vi rekommenderar datamängdsfiltrering när du förväntar dig att en annan delmängd av datauppsättningsraderna återanvänds många gånger (vilket sparar återgivningstid eftersom nya data inte behöver hämtas). I det här scenariot är du medveten om att kostnaden för att hämta en större datamängd kan bytas ut mot det antal gånger den återanvänds. Det är därför användbart för frågor som är tidskrävande att generera. Men var försiktig – cachelagring av stora datamängder per användare kan påverka prestanda och kapacitetsdataflöde negativt.

Vi rekommenderar parameterisering av datauppsättningen när du förväntar dig att det är osannolikt att en annan delmängd av datauppsättningsrader begärs, eller om antalet rader i datauppsättningen som ska filtreras sannolikt är mycket stort (och ineffektivt att cachelagra). Den här design metoden fungerar också bra när ditt datalager är instabilt. I det här fallet leder varje ändring av rapportparameterns värde till att aktuella data hämtas.

Icke-interna datakällor

Om du behöver utveckla sidnumrerade rapporter baserat på datakällor som inte har inbyggt stöd i sidnumrerade rapporter kandu först utveckla en Power BI Desktop datamodell. På så sätt kan du ansluta till över 100 Power BI datakällor. När den har publicerats Power BI tjänsten kan du utveckla en sidnumrerad rapport som ansluter till den Power BI datauppsättningen.

Dataintegrering

Om du behöver kombinera data från flera datakällor har du två alternativ:

  • Kombinera rapportdatauppsättningar: Om datakällorna har inbyggt stöd av sidnumrerade rapporter kandu skapa beräknade fält som använder funktionerna Lookup eller LookupSet Report Builder.
  • Utveckla en Power BI Desktop modell: Det är förmodligen mer effektivt att du utvecklar en datamodell i Power BI Desktop. Du kan använda Power Query för att kombinera frågor baserat på alla datakällor som stöds. När den har publicerats Power BI tjänsten kan du utveckla en sidnumrerad rapport som ansluter till den Power BI datauppsättningen.

SQL Server komplexa datatyper

Eftersom SQL Server är en lokal datakälla måste Power BI ansluta via en gateway. Gatewayen stöder dock inte hämtning av data för komplexa datatyper. Komplexa datatyper omfattar inbyggda typer som rumsliga datatyperna GEOMETRY och GEOGRAPHYoch hierarchyid. De kan även innehålla användardefinierade typer som implementeras via en klass av en sammansättning i clr Microsoft.NET Framework CLR (Common Language Runtime).

Att rita rumsliga data och analyser i kartvisualiseringen kräver SQL Server rumsliga data. Därför går det inte att arbeta med kartvisualiseringen när SQL Server är din datakälla. För att vara tydlig fungerar det om datakällan är Azure SQL Database eftersom Power BI inte ansluter via en gateway.

Bilder kan användas för att lägga till logotyper eller bilder i rapportlayouten. När bilder relaterar till de rader som hämtas av en rapportdatauppsättning har du två alternativ:

  • Det är möjligt att bilddata också kan hämtas från din datakälla (om de redan lagras i en tabell).
  • När bilderna lagras på en webbserver kan du använda ett dynamiskt uttryck för att skapa bildens URL-sökväg.

Mer information och förslag finns i Bildvägledning för sidnumrerade rapporter.

Redundant datahämtning

Det är möjligt att rapporten hämtar redundanta data. Detta kan inträffa när du tar bort frågefält för datauppsättningen eller om rapporten har oanvända datauppsättningar. Undvik dessa situationer eftersom de leder till en onödig belastning på dina datakällor, nätverket och Power BI kapacitetsresurser.

Borttagna frågefält

På sidan Fält i fönstret Egenskaper för datamängd går det att ta bort frågefält för datauppsättningen (frågefälten mappas till kolumner som hämtats av datauppsättningsfrågan). Men Report Builder tar inte bort motsvarande kolumner från datauppsättningsfrågan.

Om du behöver ta bort frågefält från datauppsättningen rekommenderar vi att du tar bort motsvarande kolumner från datauppsättningsfrågan. Report Builder automatiskt bort alla redundanta frågefält. Om du råkar ta bort frågefält måste du också ändra frågeutdraget för datauppsättningen för att ta bort kolumnerna.

Oanvända datauppsättningar

När en rapport körs utvärderas alla datauppsättningar, även om de inte är bundna till rapportobjekt. Därför bör du ta bort alla test- eller utvecklingsdatauppsättningar innan du publicerar en rapport.

Nästa steg

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