Del via

Veiledning for datahenting for paginerte rapporter

  • Artikkel

Denne artikkelen er rettet mot deg som rapportforfatter som utformer paginerte rapporter i Power BI. 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 skybaserte eller lokale. Lokale datakilder – enten de driftes lokalt eller på en virtuell maskin – krever en datagateway, slik at Power BI kan koble til. Skybasert betyr at Power BI kan 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 koble til med lavere nettverksventetid, 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 pålogging (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 bare for lokale datakilder SQL Server og Oracle (se støttede datakilder for paginerte rapporter i Power BI).

Merk

Selv om det for øyeblikket ikke er mulig å koble til lokale databaser ved hjelp av SSO, kan du fortsatt fremtvinge tillatelser på radnivå. Det gjøres ved å sende det innebygde UserID-feltet til en datasettspørringsparameter. Datakilden må lagre UPN-verdier (User Principal Name) på en måte som kan filtrere spørringsresultater på riktig måte.

Tenk deg for eksempel at hver selger lagres som en rad i selgeren, en tabell. Tabellen har kolonner for UPN, og selgerens salgsområde. Tabellen filtreres etter UPN-en til rapportbrukeren, og den er også relatert til salgsfakta ved hjelp av en indre sammenføyning. På denne måten filtrerer spørringen effektivt faktarader for salg til de i rapportbrukerens salgsområde.

Relasjonelle datakilder

Vanligvis er relasjonsdatakilder godt egnet til rapporter i driftsstil, for eksempel 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:

  • Parameterisering
  • Innkapsling av programmeringslogikk, noe som gir mer kompleks dataforberedelse (for eksempel midlertidige tabeller, markører eller skalarbrukerdefinerte funksjoner)
  • Forbedret vedlikeholdsevne, slik at lagret prosedyrelogikk enkelt kan oppdateres. I noen tilfeller kan det gjøres uten å måtte endre og publisere paginerte rapporter på nytt (forutsatt at kolonnenavn og datatyper forblir uendret).
  • Bedre ytelse ettersom utførelsesplanene bufres for gjenbruk
  • Gjenbruk av lagrede prosedyrer på tvers av flere rapporter

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

Analytiske datakilder

Analytiske datakilder , også kjent som datamodeller eller bare modeller , er godt egnet til både operasjonelle og analytiske rapporter, og kan levere raske oppsummerte 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 til rapporter som må hente svært store mengder data (i overkant av 10 000 rader).

I Power BI Report Builder har du et utvalg av to spørringsutformere: Analysis Services DAX-spørringsutforming og ANALYSIS Services MDX-spørringsutforming. Disse utformerne kan brukes for power bi semantiske modell (tidligere kjent som et datasett) datakilder, eller en SQL Server Analysis Services- eller Azure Analysis Services-modell – tabell eller flerdimensjonal.

Vi anbefaler at du bruker DAX-spørringsutformingen – forutsatt at den oppfyller spørringsbehovene dine fullstendig. 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å oppsummering).

MDX-spørringsutformingen krever at modellen inneholder mål. Utformeren har to funksjoner som ikke støttes av DAX-spørringsutformingen. Spesielt lar det deg:

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

Spørringsresultatstørrelse

Generelt sett er det anbefalt fremgangsmåte å hente bare dataene som kreves av rapporten. Så ikke hent kolonner eller rader som ikke kreves av rapporten.

Hvis du vil 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 korn. Tenk deg for eksempel at rapporten må presentere et sammendrag av selgersalg. I stedet for å hente alle salgsordrerader, oppretter du 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 henter kundens fornavn og etternavn, vil du kanskje ha et felt som kjeder sammen de to feltene for å gi kunden fullt navn. Du har to alternativer for å oppnå denne beregningen. Du kan gjøre følgende:

  • Opprett et beregnet felt, som er et datasettfelt basert på et uttrykk.
  • Sett inn et uttrykk direkte i datasettspørringen (ved hjelp av det opprinnelige språket i datakilden), noe som resulterer i et vanlig datasettfelt.

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

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

Feltnavn

Når du oppretter et datasett, blir feltene automatisk oppkalt etter spørringskolonnene. Det er mulig at disse navnene ikke er vennlige eller intuitive. Det er også mulig at kolonnenavn for kildespørring inneholder tegn som er forbudt i objektidentifikatorer for rapportdefinisjonsspråk (RDL) (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 egendefinerte, konsise, men likevel meningsfulle. Hvis ikke, foreslår vi at du gir dem nytt navn før du starter rapportoppsettet. Det er fordi felt med nytt navn ikke endres til uttrykkene som brukes i rapportoppsettet. Hvis du bestemmer deg for å gi nytt navn til felt etter at du har startet rapportoppsettet, må du finne og oppdatere alle brutte uttrykk.

Filter kontra parameter

Det er sannsynlig at de paginerte rapportutformingene har rapportparametere. Rapportparametere brukes vanligvis til å be rapportbrukeren om å filtrere rapporten. Som sideformatert rapportforfatter har du to måter å oppnå rapportfiltrering på. Du kan tilordne en rapportparameter til:

  • Et datasettfilter, i så fall brukes rapportparameterverdiene til å filtrere dataene som allerede er hentet av datasettet.
  • En datasettparameter, i så fall settes rapportparameterverdien(e) inn i den opprinnelige spørringen som sendes til datakilden.

Merk

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

Vurder deretter et eksempel på en salgsrapport som har én enkelt rapportparameter for å filtrere rapporten etter ett år. Datasettet henter salg for alle år. Det gjør det 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, trenger ikke Power BI å hente kildedata. I stedet bruker det et annet filter på det allerede bufrede datasettet. Når datasettet er hurtigbufret, kan filtreringen være svært rask.

Vurder nå en annen rapportutforming. Denne gangen tilordner rapportutformingen rapportparameteren for salgsår til en datasettparameter. På denne måten setter Power BI inn årsverdien i den opprinnelige spørringen, og datasettet henter bare data for det året. Hver gang rapportbrukeren endrer parameterverdien for årsrapporten, og deretter viser rapporten, henter datasettet et nytt spørringsresultat for akkurat det året.

Begge utformingsmetodene kan filtrere rapportdata, og begge utformingene kan fungere bra for rapportutformingene. En optimalisert utforming vil imidlertid avhenge av forventede datavolumer, datavolatilitet og forventet virkemåte for rapportbrukerne.

Vi anbefaler at datasettfiltrering når du forventer at et annet delsett av datasettradene brukes på nytt mange ganger (og dermed lagrer gjengivelsestid fordi nye data ikke trenger å hentes). I dette scenarioet innser du at kostnadene ved å hente et større datasett kan byttes mot antall ganger det vil bli gjenbrukt. Det er derfor nyttig for spørringer som er tidkrevende å generere. Vær imidlertid oppmerksom på at hurtigbufring av store datasett per bruker kan ha negativ innvirkning på ytelsen og gjennomstrømming av kapasitet.

Vi anbefaler parameterisering 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 vil være svært stort (og ineffektivt å bufre). Denne utformingstilnærmingen fungerer også bra når datalageret er flyktig. I dette tilfellet vil hver verdiendring for 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 paginerte rapporter, bør du først utvikle en datamodell i Power BI Desktop. På den måten kan du koble til hundrevis av datakilder som støttes av Power BI. Når du har publisert til Power Bi-tjeneste, kan du deretter utvikle en paginert rapport som kobler til semantisk Power BI-modell.

Dataintegrasjon

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

  • Kombinere rapportdatasett: Hvis datakildene støttes opprinnelig av paginerte rapporter, kan du vurdere å opprette beregnede felt som bruker funksjonene Lookup eller LookupSet Report Builder.
  • Utvikle en Power BI Desktop-modell: Det er sannsynligvis mer effektivt at du utvikler en datamodell i Power BI Desktop. Du kan bruke Power Query til å kombinere spørringer basert på alle støttede datakilder. Når du har publisert til Power Bi-tjeneste, kan du deretter utvikle en paginert rapport som kobler til semantisk Power BI-modell.

Nettverksventetid

Nettverksventetid kan påvirke rapportytelsen ved å øke tiden som kreves for forespørsler om å nå Power Bi-tjeneste, og for svar som skal leveres. Leiere i Power BI er tilordnet til et bestemt område.

Tips

Hvis du vil finne ut hvor leieren er plassert, kan du se Hvor er Power BI-leieren min plassert?

Når brukere fra en leier får tilgang til Power Bi-tjeneste, rutes alltid forespørslene deres til dette området. Når forespørsler kommer til Power Bi-tjeneste, kan tjenesten deretter sende flere forespørsler– for eksempel til den underliggende datakilden eller en datagateway – som også er underlagt nettverksventetid. Generelt sett, for å minimere virkningen av nettverksventetid, bør du arbeide for å holde datakilder, gatewayer og Power BI-kapasiteten så nær som mulig. Fortrinnsvis befinner de seg innenfor samme område. Hvis nettverksventetid er et problem, kan du prøve å finne gatewayer og datakilder nærmere Power BI-kapasiteten ved å plassere dem i skybaserte virtuelle maskiner.

Komplekse datatyper for SQL Server

Siden 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, for eksempel geometri- og GEOGRAFI-romlige datatyper og hierarki-ID. De kan også inkludere brukerdefinerte typer implementert gjennom en klasse i en samling i Microsoft.NET Framework common language runtime (CLR).

Plotting av romlige data og analyser i kartvisualiseringen krever romlige data for SQL Server. Derfor er det ikke mulig å arbeide med kartvisualiseringen når SQL Server er datakilden. Det vil fungere hvis datakilden er Azure SQL Database fordi Power BI ikke kobler 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 url-banen for bildet.

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

Overflødig datahenting

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

Slettede spørringsfelt

På Felt-siden i vinduet Egenskaper for datasett er det mulig å slette datasettspørringsfelt (spørringsfelt tilordnes til kolonner som hentes av datasettspørringen). Report Builder fjerner 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 datasett – selv om de ikke er bundet til rapportobjekter. Av denne grunn må du fjerne eventuelle test- eller utviklingsdatasett før du publiserer en rapport.

Relatert innhold

Hvis du vil ha mer informasjon om denne artikkelen, kan du se følgende ressurser: