Veiledning for datahenting for paginerte rapporter

Denne artikkelen er rettet mot deg som rapportforfatter som utformer Power BI-paginerte rapporter. Den gir anbefalinger for å hjelpe deg med å utforme effektiv og effektiv datahenting.

Datakildetyper

Paginerte rapporter støtter opprinnelig både relasjonelle og analytiske datakilder. Disse kildene er ytterligere kategorisert, enten som skybasert eller lokalt. Lokale datakilder – enten de er driftet lokalt eller på en virtuell maskin – krever en datagateway for Power BI kan koble til. Skybasert betyr at Power BI koble til direkte ved hjelp av en Internett-tilkobling.

Hvis du kan velge datakildetypen (muligens tilfellet i et nytt prosjekt), anbefaler vi at du bruker skybaserte datakilder. Paginerte rapporter kan kobles til med lavere nettverksforskuendehet, spesielt når datakildene befinner seg i samme område som Power BI leieren. Det er også mulig å koble til disse kildene ved hjelp av enkel Sign-On (SSO). Det betyr at rapportbrukerens identitet kan flyte til datakilden, slik at tillatelser på radnivå per bruker kan håndheves. SSO støttes for øyeblikket ikke for lokale datakilder (det betyr SQL Server Analysis Services kan ikke håndheve tillatelser på radnivå per bruker).

Obs!

Selv om det for øyeblikket ikke er mulig å koble til lokale databaser ved hjelp av SSO, kan du fortsatt håndheve tillatelser på radnivå. Det gjøres ved å sende det innebygde UserID-feltet til en spørringsparameter for datasettet. Datakilden må lagre verdier for hovednavn for bruker (UPN) på en måte som gjør at den kan filtrere spørringsresultatene på riktig måte.

Tenk deg for eksempel at hver selger er lagret som en rad i tabellen Selger. Tabellen har kolonner for UPN og selgerens salgsområde. Ved spørring filtreres tabellen med UPN for rapportbrukeren, og den er også relatert til salgsfakterier ved hjelp av en indre kobling. På denne måten filtrerer spørringen effektivt salgsfaksrader til de i rapportbrukerens salgsområde.

Relasjonsdatakilder

Relasjonelle datakilder er generelt godt egnet for driftsstilrapporter, som salgsfakturaer. De er også egnet for rapporter som må hente svært store datasett (i overkant av 10 000 rader). Relasjonsdatakilder kan også definere lagrede prosedyrer, som kan utføres av rapportdatasett. Lagrede prosedyrer gir flere fordeler:

  • Parametrisering
  • Innkapsling av programmeringslogikk, muliggjør mer kompleks dataforberedelse (for eksempel midlertidige tabeller, markører eller skalarbrukerdefinerte funksjoner)
  • Forbedret vedlikeholdbarhet, slik at lagret prosedyrelogikk enkelt kan oppdateres. I noen tilfeller kan dette gjøres uten at behovet for å endre og publisere paginerte rapporter på nytt (ved å oppgi at kolonnenavn og datatyper forblir uendret).
  • Bedre ytelse, siden kjøreplanene hurtigbufres for gjenbruk
  • Gjenbruk av lagrede prosedyrer på tvers av flere rapporter

I Power BI Report Builder kan du bruke den relasjonelle spørringsutformeren til å grafisk konstruere en spørringssetning – men bare for Microsoft-datakilder.

Analytiske datakilder

Analytiske datakilder er godt egnet for både operasjonelle og analytiske rapporter, og kan levere raske summerte spørringsresultater selv over svært store datavolumer. Modellmål og KPI-er kan innkapsle komplekse forretningsregler for å oppnå oppsummering av data. Disse datakildene er imidlertid ikke egnet for rapporter som trenger å hente svært store datasett (i overkant av 10 000 rader).

I Power BI Report Builder har du to spørringsutforminger: den Analysis Services dax-spørringsutformeren og Analysis Services MDX-spørringsutformeren. Disse designerne kan brukes til Power BI datasettdatakilder, eller en hvilken som helst SQL Server Analysis Services eller Azure Analysis Services modell – tabell eller flerdimensjonal.

Vi foreslår at du bruker utformingsprogrammet for DAX-spørringer – slik at den oppfyller spørringsbehovene dine. Hvis modellen ikke definerer målene du trenger, må du bytte til spørringsmodus. I denne modusen kan du tilpasse spørringssetningen ved å legge til uttrykk (for å oppnå summering).

MDX-spørringsutformeren krever at modellen inkluderer mål. Utformeren har to funksjoner som ikke støttes av DAX-spørringsutformeren. Nærmere bestemt lar det deg:

  • Definer beregnede medlemmer på spørringsnivå (i MDX).
  • Konfigurer dataområder for å be om serversamlinger i grupper som ikke er detaljerte. Hvis rapporten må presentere sammendrag av halv- eller ikke-additive mål (for eksempel tidsintelligensberegninger eller distinkte antall), vil det sannsynligvis være mer effektivt å bruke server aggregater enn å hente detaljrader på lavt nivå og få oppsummeringene for rapportbehandling.

Størrelse på spørringsresultat

Generelt er det en god fremgangsmåte å hente bare dataene som kreves av rapporten. Du må derfor ikke hente kolonner eller rader som ikke kreves av rapporten.

For å begrense rader bør du alltid bruke de mest restriktive filtrene og definere aggregerte spørringer. Aggreger spørringer grupperer og oppsummerer kildedata for å hente resultater med høyere nivå. Tenk deg for eksempel at rapporten trenger å presentere et sammendrag av selgersalg. I stedet for å hente alle salgsordreradene kan du opprette en datasettspørring som grupperer etter selger, og oppsummerer salg for hver gruppe.

Uttrykksbaserte felt

Det er mulig å utvide et rapportdatasett med felt basert på uttrykk. Hvis for eksempel datasettet får kundens fornavn og etternavn, kan det hende du ønsker et felt som kjeder sammen de to feltene for å produsere kundens fulle navn. Du har to alternativer for å oppnå denne beregningen. Du kan:

  • Opprett et beregnet felt, som er et datasettfelt basert på et uttrykk.
  • Injiser et uttrykk direkte i datasettspørringen (ved hjelp av opprinnelig språk for datakilden), noe som resulterer i et vanlig datasettfelt.

Vi anbefaler det sistnevnte alternativet, når mulig. Det er to gode grunner til at det er bedre å sette inn uttrykk direkte i datasettspørringen:

  • Det er mulig datakilden er optimalisert for å evaluere uttrykket mer effektivt enn Power BI (det er spesielt tilfellet for relasjonsdatabaser).
  • Rapportytelsen er forbedret fordi det ikke er behov for Power BI å materialisere beregnede felt før rapportgjengivelsen. Beregnede felter kan merkbart utvide gjengivelsestiden for rapporter når datasett henter et stort antall rader.

Feltnavn

Når du oppretter et datasett, får feltene automatisk navnet etter spørringskolonnene. Det er mulig at disse navnene ikke er brukervennlige eller intuitive. Det er også mulig at kolonnenavn for kildespørring inneholder tegn som er forbudt i Report Definition Language (RDL)-objektidentifikatorer (for eksempel mellomrom og symboler). I dette tilfellet erstattes de forbudte tegnene med et understrekingstegn (_).

Vi anbefaler at du først bekrefter at alle feltnavn er brukervennlige, konsise, men fremdeles gir mening. Hvis ikke, foreslår vi at du gir dem nytt navn før du går i gang med rapportoppsettet. Det er fordi feltene med nye navn ikke endres gjennom uttrykkene som brukes i rapportoppsettet. Hvis du bestemmer deg for å gi nytt navn til feltene etter at du har startet rapportoppsettet, må du finne og oppdatere alle brutte uttrykk.

Filter kontra parameter

Det er sannsynlig at utforminger av paginerte rapporter vil ha rapportparametere. Rapportparametere brukes vanligvis til å be rapportbrukeren om å filtrere rapporten. Som forfatter av paginerte rapporter har du to måter å oppnå rapportfiltrering på. Du kan tilordne en rapportparameter til:

  • Et datasettfilter , der rapportparameterverdiene brukes til å filtrere dataene som allerede er hentet av datasettet.
  • En datasettparameter, der rapportparameterverdiene blir satt inn i den opprinnelige spørringen som sendes til datakilden.

Obs!

Alle rapportdatasett bufres per økt i opptil 10 minutter utover deres siste bruk. Et datasett kan brukes på nytt når du sender inn nye parameterverdier (filtrering), gjengir rapporten i et annet format eller samhandler med rapportutformingen på en eller annen måte, for eksempel å endre synlighet eller sortering.

Vurder derfor et eksempel på en salgsrapport som har én rapportparameter, for å filtrere rapporten etter ett enkelt år. Datasettet henter salg for alle år. Dette gjør den fordi rapportparameteren tilordnes til datasettfiltrene. Rapporten viser data for det forespurte året, som er et delsett av datasettdataene. Når rapportbrukeren endrer rapportparameteren til et annet år – og deretter viser rapporten – Power BI trenger du ikke å hente noen kildedata. I stedet brukes et annet filter på det allerede hurtigbufrede datasettet. Når datasettet er hurtigbufret, kan filtreringen være svært rask.

Nå bør du vurdere en annen rapportutforming. Denne gangen tilordner rapportutformingen rapportparameteren for salgsåret til en datasettparameter. På denne Power BI år-verdien inn i den opprinnelige spørringen, og datasettet henter bare data for dette året. Hver gang rapportbrukeren endrer verdien for rapportparameteren for året, og deretter viser rapporten, henter datasettet et nytt spørringsresultat for bare dette året.

Begge utformingsmåter kan filtrere rapportdata, og begge utforminger kan fungere bra for rapportutformingene. En optimalisert utforming avhenger imidlertid av de forventede datavolumene, data volatiliteten og forventet virkemåte til rapportbrukerne.

Vi anbefaler filtrering av datasett når du forventer at et annet delsett av datasettradene brukes på nytt mange ganger (dermed sparer du tid for gjengivelse, fordi det ikke er nødvendig å hente nye data). I dette scenarioet er du klar over at kostnaden ved å hente et større datasett kan bli byttet av mot antall ganger det vil bli tatt i bruk på nytt. Så det er nyttig for spørringer som er tidkrevende å generere. Men du må være forsiktig – hurtigbufring av store datasett per bruker kan ha negativ innvirkning på ytelsen og kapasitetsgjennomstrømmingen.

Vi anbefaler parametrisering av datasett når du forventer at det er lite sannsynlig at et annet delsett med datasettrader blir forespurt, eller, når antallet datasettrader som skal filtreres, sannsynligvis er svært stort (og ineffektivt å bufre). Denne tilnærmingen til utformingen fungerer bra også når datalageret er flyktig. I dette tilfellet vil hver verdiendring av rapportparameteren resultere i henting av oppdaterte data.

Ikke-opprinnelige datakilder

Hvis du trenger å utvikle paginerte rapporter basert på datakilder som ikke støttes opprinnelig av paginerterapporter, kan du først utvikle Power BI Desktop datamodell. På denne måten kan du koble til over 100 Power BI datakilder. Når den er publisert til Power BI tjenesten, kan du utvikle en paginert rapport som kobles til datasettet Power BI datasettet.

Dataintegrasjon

Hvis du trenger å kombinere data fra flere datakilder, har du to alternativer:

  • Kombiner rapportdatasett: Hvis datakildene støttes opprinnelig av paginerterapporter, kan du vurdere å opprette beregnede felt som bruker funksjonene Lookup Report Builder LookupSet.
  • Utvikle en Power BI Desktop modell : Det er sannsynligvis mer effektivt, men du utvikler imidlertid en datamodell i Power BI Desktop. Du kan bruke Power Query til å kombinere spørringer basert på alle støttede datakilder. Når den er publisert til Power BI tjenesten, kan du utvikle en paginert rapport som kobles til datasettet Power BI datasettet.

SQL Server komplekse datatyper

Fordi SQL Server er en lokal datakilde, må Power BI koble til via en gateway. Gatewayen støtter imidlertid ikke henting av data for komplekse datatyper. Komplekse datatyper inkluderer innebygde typer som GEOMETRI og GEOGRAFI-spatiale datatyperog hierarkiid. De kan også inkludere brukerdefinerte typer som implementeres gjennom en klasse for en samling i Microsoft.NET Framework Common Language Runtime (CLR).

Plotte avstandsdata og analyse i kartvisualiseringen krever SQL Server avstandsdata. Det er derfor ikke mulig å jobbe med kartvisualiseringen når SQL Server er datakilden. For å være tydelig vil det fungere hvis datakilden er Azure SQL Database fordi Power BI ikke kobles til via en gateway.

Bilder kan brukes til å legge til logoer eller bilder i rapportoppsettet. Når bilder er relatert til radene som hentes av et rapportdatasett, har du to alternativer:

  • Det er mulig at bildedata også kan hentes fra datakilden (hvis de allerede er lagret i en tabell).
  • Når bildene er lagret på en nettserver, kan du bruke et dynamisk uttrykk til å opprette nettadressebanen til bildet.

Hvis du vil ha mer informasjon og forslag, kan du se Bildeveiledning for paginerte rapporter.

Redundant datahenting

Det er mulig rapporten henter overflødige data. Dette kan skje når du sletter spørringsfelt for datasett, eller når rapporten har ubrukte datasett. Unngå disse situasjonene, da de resulterer i en unødvendig belastning på datakildene, nettverket og Power BI kapasitetsressursene.

Slettede spørringsfelt

Felt-siden i vinduet Egenskaper for datasett, er det mulig å slette datasettspørringsfelt (spørringsfelt er tilordning til kolonner som hentes av datasettspørringen). De Report Builder imidlertid ikke tilsvarende kolonner fra datasettspørringen.

Hvis du trenger å slette spørringsfelt fra datasettet, anbefaler vi at du fjerner de tilsvarende kolonnene fra datasettspørringen. Report Builder fjerner automatisk eventuelle overflødige spørringsfelt. Hvis du sletter spørringsfelt, må du også endre datasettspørringssetningen for å fjerne kolonnene.

Ubrukte datasett

Når en rapport kjøres, evalueres alle datasettene – selv om de ikke er bundet til rapportobjekter. Derfor må du fjerne eventuelle test- eller utviklingsdatasett før du publiserer en rapport.

Neste trinn

Du finner mer informasjon relatert til denne artikkelen i følgende ressurser: