Share via

Vägledning för datahämtning för sidnumrerade rapporter

  • Artikel

Den här artikeln riktar sig till dig som rapportförfattare och utformar sidnumrerade Power BI-rapporter. Den innehåller rekommendationer som hjälper dig att utforma effektiv och effektiv datahämtning.

Typer av datakällor

Sidnumrerade rapporter har inbyggt stöd för både relations- och analysdatakällor. Dessa källor kategoriseras ytterligare som antingen 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. Molnbaserad innebär att Power BI kan ansluta direkt med en Internetanslutning.

Om du kan välja datakälltyp (eventuellt fallet i ett nytt projekt) rekommenderar vi att du använder molnbaserade datakällor. Sidnumrerade rapporter kan ansluta med lägre nätverkssvarstid, särskilt när datakällorna finns i samma region som din Power BI-klientorganisation. Dessutom är det möjligt att ansluta till dessa källor med enkel inloggning (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 enkel inloggning endast för lokala datakällor SQL Server och Oracle (se Datakällor som stöds för sidnumrerade Power BI-rapporter).

Kommentar

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

Anta till exempel att varje säljare lagras som en rad i tabellen Säljare . Tabellen har kolumner för UPN och även säljarens försäljningsregion. Vid frågetillfället 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äljningsfaktarader till dem i rapportanvändarens försäljningsregion.

Relationsdatakällor

I allmänhet är relationsdatakällor väl lämpade för rapporter i driftstil, till exempel försäljningsfakturor. De passar även för rapporter som behöver hämta mycket stora datamängder (över 10 000 rader). Relationsdatakällor kan också definiera lagrade procedurer som kan köras av rapportdatauppsättningar. 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ållsbarhet, vilket gör att lagrad procedurlogik enkelt kan uppdateras. I vissa fall kan det göras utan att du behöver ändra och publicera om sidnumrerade rapporter (om du anger 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ågeuttryck – men bara för Microsofts datakällor.

Analysdatakällor

Analysdatakällor – även kallade datamodeller eller bara modeller – passar bra för både drifts- och analysrapporter 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 uppnå sammanfattning av data. Dessa datakällor passar dock inte för rapporter som behöver hämta mycket stora datavolymer (ö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-semantiska modelldatakällor (tidigare kallade datamängder) eller sql Server Analysis Services- eller Azure Analysis Services-modeller – tabellbaserade eller flerdimensionella.

Vi rekommenderar att du använder DAX-frågedesignern – förutsatt att den helt 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ågeuttrycket 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 dataregioner för att begära serveraggregeringar i icke-detaljgrupper. Om rapporten behöver presentera sammanfattningar av semi- eller icke-additiva mått (t.ex. tidsinformationsberäkningar eller distinkta antal) är det sannolikt mer effektivt att använda serveraggregat än att hämta detaljrader på låg nivå och få sammanfattningar av rapportberäkning.

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 aggregerade frågor. Aggregera frågor grupperar och sammanfattar källdata för att hämta resultat med högre kornighet. Anta till exempel att rapporten måste presentera en sammanfattning av säljarnas försäljning. I stället för att hämta alla försäljningsorderrader skapar du en datamängdsfråga som grupperas efter säljare och sammanfattar försäljningen för varje grupp.

Uttrycksbaserade fält

Det går att utöka en rapportdatauppsättning med fält baserat på uttryck. Om din datauppsättning till exempel hämtar 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 datamängdsfrågan (med datakällans inbyggda språk), 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 datamängdsfrågan:

  • Det är möjligt att din datakälla är optimerad för att utvärdera uttrycket mer effektivt än Power BI (det är särskilt fallet för relationsdatabaser).
  • Rapportprestandan förbättras eftersom Power BI inte behöver materialisera beräknade fält före rapportrendering. Beräknade fält kan märkbart utöka rapportåtergivningstiden när datauppsättningar hämtar ett stort antal rader.

Fält-namn:

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 förbjudna i 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 vä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 namnbytet inte ändras till de uttryck som används i rapportlayouten. 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.

Filter kontra parameter

Det är troligt att dina sidnumrerade rapportdesigner kommer att ha 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 datauppsättningsfilter, 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ärdena matas in i den interna frågan som skickas till datakällan.

Kommentar

Alla rapportdatauppsättningar cachelagras per session i upp till 10 minuter efter den senaste användningen. En datauppsättning kan återanvändas 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 sortera.

Tänk sedan på 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 gör den eftersom rapportparametern mappar till datamängdsfiltren. Rapporten visar data för det begärda året, vilket är en delmängd av datamängdsdata. När rapportanvändaren ändrar rapportparametern till ett annat år – och sedan visar rapporten – behöver Power BI inte hämta några källdata. I stället tillämpas ett annat filter på den redan cachelagrade datauppsättningen. När datamängden har cachelagrats kan filtreringen vara mycket snabb.

Överväg nu en annan rapportdesign. Den här gången mappar rapportdesignen parametern sales year report till en datamängdsparameter. På så sätt matar 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 värdet för årsrapportparametern – och sedan visar rapporten – hämtar datamängden ett nytt frågeresultat för just det året.

Båda designmetoderna kan filtrera rapportdata och båda designerna kan fungera bra för dina rapportdesigner. En optimerad design beror dock på de förväntade datavolymerna, datavolatiliteten och rapportanvändarnas förväntade beteende.

Vi rekommenderar att datauppsättningsfiltrering när du förväntar dig att en annan delmängd av datauppsättningsraderna återanvänds många gånger (vilket sparar återgivningstiden eftersom nya data inte behöver hämtas). I det här scenariot inser du att kostnaden för att hämta en större datamängd kan bytas ut mot antalet gånger den återanvänds. Därför är det 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 kapacitetsgenomflöde negativt.

Vi rekommenderar datamängdsparameterisering när du förväntar dig att det är osannolikt att en annan delmängd av datamängdsrader kommer att begäras, eller när antalet datamängdsrader som ska filtreras sannolikt är mycket stort (och ineffektivt att cachelagra). Den här designmetoden fungerar också bra när datalagret är instabilt. I det här fallet resulterar varje ändring av rapportparameterns värde i hämtningen av uppdaterade data.

Icke-inbyggda datakällor

Om du behöver utveckla sidnumrerade rapporter baserat på datakällor som inte stöds internt av sidnumrerade rapporter bör du först utveckla en datamodell i Power BI Desktop. På så sätt kan du ansluta till hundratals datakällor som stöds av Power BI. När du har publicerat till Power BI-tjänst kan du sedan utveckla en sidnumrerad rapport som ansluter till Power BI-semantikmodellen.

Dataintegrering

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

  • Kombinera rapportdatauppsättningar: Om datakällorna stöds internt av sidnumrerade rapporter kan du skapa beräknade fält som använder funktionerna Lookup eller LookupSet Report Builder.
  • Utveckla en Power BI Desktop-modell: Det är dock sannolikt 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 du har publicerat till Power BI-tjänst kan du sedan utveckla en sidnumrerad rapport som ansluter till Power BI-semantikmodellen.

Svarstid för nätverk

Nätverksfördröjning kan påverka rapportprestanda genom att öka den tid som krävs för att begäranden ska nå Power BI-tjänst och för svar som ska levereras. Klienter i Power BI tilldelas till en viss region.

Dricks

Information om var din klient finns finns i Var finns min Power BI-klient?

När användare från en klientorganisation får åtkomst till Power BI-tjänst dirigeras deras begäranden alltid till den här regionen. När begäranden når Power BI-tjänst kan tjänsten sedan skicka ytterligare begäranden, till exempel till den underliggande datakällan eller en datagateway, som också är föremål för nätverksfördröjning. För att minimera effekten av nätverksfördröjning bör du i allmänhet sträva efter att hålla datakällor, gatewayer och din Power BI-kapacitet så nära som möjligt. Helst finns de inom samma region. Om nätverksfördröjningen är ett problem kan du prova att hitta gatewayer och datakällor närmare din Power BI-kapacitet genom att placera dem i molnbaserade virtuella datorer.

KOMPLEXA SQL Server-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 spatiala datatyperna GEOMETRI och GEOGRAPHY och hierarchyid. De kan också innehålla användardefinierade typer som implementeras via en klass för en sammansättning i Microsoft.NET Framework common language runtime (CLR).

För att rita rumsliga data och analyser i kartvisualiseringen krävs rumsliga SQL Server-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 din datakälla ä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 datakällan (om de redan lagras i en tabell).
  • När avbildningarna lagras på en webbserver kan du använda ett dynamiskt uttryck för att skapa sökvägen till bildens URL.

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 datamängdens frågefält eller om rapporten har oanvända datauppsättningar. Undvik dessa situationer, eftersom de resulterar i en onödig börda för dina datakällor, nätverket och Power BI-kapacitetsresurser.

Borttagna frågefält

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

Om du behöver ta bort frågefält från datauppsättningen rekommenderar vi att du tar bort motsvarande kolumner från datamängdsfrågan. Report Builder tar automatiskt bort alla redundanta frågefält. Om du råkar ta bort frågefält måste du också ändra datauppsättningens frågeuttryck 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.

Relaterat innehåll

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