Del via

Vejledning til datahentning for sideinddelte rapporter

  • Artikel

Denne artikel henvender sig til dig som rapportforfatter, der designer sideinddelte Power BI-rapporter. Den indeholder anbefalinger, der kan hjælpe dig med at designe effektiv datahentning.

Datakildetyper

Sideinddelte rapporter understøtter oprindeligt både relations- og analysedatakilder. Disse kilder kategoriseres yderligere som enten cloudbaserede eller i det lokale miljø. Datakilder i det lokale miljø – uanset om de hostes i det lokale miljø eller på en virtuel maskine – kræver en datagateway, så Power BI kan oprette forbindelse. Cloudbaseret betyder, at Power BI kan oprette direkte forbindelse ved hjælp af en internetforbindelse.

Hvis du kan vælge datakildetypen (muligvis i et nyt projekt), anbefaler vi, at du bruger cloudbaserede datakilder. Sideinddelte rapporter kan oprette forbindelse med lavere netværksventetid, især når datakilderne er placeret i det samme område som din Power BI-lejer. Det er også muligt at oprette forbindelse til disse kilder ved hjælp af Enkeltlogon (SSO). Det betyder, at rapportbrugerens identitet kan overføres til datakilden, hvilket gør det muligt at gennemtvinge tilladelser på rækkeniveau pr. bruger. I øjeblikket understøttes SSO kun for datakilder i det lokale miljø SQL Server og Oracle (se Understøttede datakilder til sideinddelte rapporter i Power BI).

Bemærk

Selvom det i øjeblikket ikke er muligt at oprette forbindelse til databaser i det lokale miljø ved hjælp af SSO, kan du stadig gennemtvinge tilladelser på rækkeniveau. Det gøres ved at overføre det indbyggede UserID-felt til en forespørgselsparameter for et datasæt. Datakilden skal gemme UPN-værdier (User Principal Name) på en måde, så den kan filtrere forespørgselsresultater korrekt.

Overvej f.eks., at hver sælger er gemt som en række i tabellen Salesperson a. Tabellen indeholder kolonner til UPN og også sælgerens salgsområde. På forespørgselstidspunktet filtreres tabellen efter rapportbrugerens UPN, og den er også relateret til salgsfakta ved hjælp af en indre joinforbindelse. På denne måde filtrerer forespørgslen effektivt rækkerne med salgsoplysninger til rækkerne for rapportbrugerens salgsområde.

Relationsdatakilder

Relationelle datakilder er generelt velegnet til rapporter med driftsstil, f.eks. salgsfakturaer. De er også velegnede til rapporter, der skal hente meget store datasæt (mere end 10.000 rækker). Relationsdatakilder kan også definere lagrede procedurer, som kan udføres af rapportdatasæt. Lagrede procedurer giver flere fordele:

  • Parameterindstilling
  • Indkapsling af programmeringslogik, hvilket giver mulighed for mere kompleks dataforberedelse (f.eks. midlertidige tabeller, markører eller skalar brugerdefinerede funktioner)
  • Forbedret vedligeholdelse, så logikken for lagrede procedurer nemt kan opdateres. I nogle tilfælde kan det gøres, uden at det er nødvendigt at ændre og publicere sideinddelte rapporter igen (med kolonnenavne og datatyper forbliver uændrede).
  • Bedre ydeevne, da deres udførelsesplaner cachelagres til genbrug
  • Genbrug af lagrede procedurer på tværs af flere rapporter

I Power BI Report Builder kan du bruge relationsforespørgselsdesigneren til grafisk at oprette en forespørgselssætning – men kun til Microsoft-datakilder.

Analysedatakilder

Analysedatakilder – også kendt som datamodeller eller blot modeller – er velegnede til både drifts- og analyserapporter og kan levere hurtigt opsummerede forespørgselsresultater, selv over meget store datamængder. Modelmålinger og KPI'er kan indkapsle komplekse forretningsregler for at opnå opsummering af data. Disse datakilder er dog ikke velegnede til rapporter, der har brug for at hente meget store datamængder (mere end 10.000 rækker).

I Power BI Report Builder kan du vælge mellem to forespørgselsdesignere: Analysis Services DAX-forespørgselsdesigneren og Analysis Services MDX-forespørgselsdesigneren. Disse designere kan bruges til power BI-semantiske modeldatakilder eller en hvilken som helst SQL Server Analysis Services- eller Azure Analysis Services-model – tabellarisk eller flerdimensionel.

Vi anbefaler, at du bruger DAX-forespørgselsdesigneren– forudsat at den fuldt ud opfylder dine forespørgselsbehov. Hvis modellen ikke definerer de målinger, du har brug for, skal du skifte til forespørgselstilstand. I denne tilstand kan du tilpasse forespørgselssætningen ved at tilføje udtryk (for at opnå opsummering).

MDX-forespørgselsdesigneren kræver, at din model indeholder målinger. Designeren har to funktioner, der ikke understøttes af DAX-forespørgselsdesigneren. Det giver dig specifikt mulighed for at:

  • Definer beregnede medlemmer på forespørgselsniveau (i MDX).
  • Konfigurer dataområder for at anmode om serveraggregater i ikke-detaljegrupper. Hvis din rapport skal vise oversigter over semi- eller ikke-additive målinger (f.eks. time intelligence-beregninger eller særskilte optællinger), vil det sandsynligvis være mere effektivt at bruge serveraggregater end at hente detaljerækker på lavt niveau og få opsummeringerne af rapportens beregning.

Forespørgselsresultatstørrelse

Generelt er det bedste praksis kun at hente de data, der kræves i din rapport. Så hent ikke kolonner eller rækker, der ikke kræves af rapporten.

Hvis du vil begrænse rækker, skal du altid anvende de mest restriktive filtre og definere aggregerede forespørgsler. Aggregerede forespørgsler grupperer og opsummerer kildedata for at hente resultater med højere detaljering. Forestil dig f.eks., at rapporten skal vise en oversigt over sælgersalg. I stedet for at hente alle salgsordrerækker skal du oprette en datasætforespørgsel, der grupperer efter sælger, og opsummerer salg for hver gruppe.

Udtryksbaserede felter

Det er muligt at udvide et rapportdatasæt med felter, der er baseret på udtryk. Hvis dit datasæt f.eks. kilder kundens fornavn og efternavn, vil du måske have et felt, der sammenkæder de to felter for at oprette kundens fulde navn. Du har to muligheder for at opnå denne beregning. Du kan:

  • Opret et beregnet felt, som er et datasætfelt, der er baseret på et udtryk.
  • Indsæt et udtryk direkte i datasætforespørgslen (ved hjælp af datakildens oprindelige sprog), hvilket resulterer i et almindeligt datasætfelt.

Vi anbefaler sidstnævnte indstilling, når det er muligt. Der er to gode grunde til, at det er bedre at indsætte udtryk direkte i din datasætforespørgsel:

  • Det er muligt, at din datakilde er optimeret til at evaluere udtrykket mere effektivt end Power BI (det er især tilfældet for relationsdatabaser).
  • Rapportens ydeevne er forbedret, fordi der ikke er behov for, at Power BI materialiserer beregnede felter før rapportgengivelse. Beregnede felter kan mærkbart forlænge gengivelsestiden for rapporter, når datasæt henter et stort antal rækker.

Feltnavne

Når du opretter et datasæt, navngives felterne automatisk efter forespørgselskolonnerne. Det er muligt, at disse navne ikke er brugervenlige eller intuitive. Det er også muligt, at navne på kildeforespørgsler indeholder tegn, der ikke er tilladt i RDL-objekt-id'er (Report Definition Language) (f.eks. mellemrum og symboler). I dette tilfælde erstattes de forbudte tegn med et understregningstegn (_).

Vi anbefaler, at du først bekræfter, at alle feltnavne er brugervenlige, præcise, men stadig meningsfulde. Hvis ikke, anbefaler vi, at du omdøber dem , før du begynder rapportlayoutet. Det skyldes, at omdøbte felter ikke ændrer sig i de udtryk, der bruges i dit rapportlayout. Hvis du beslutter at omdøbe felter, når du har påbegyndt rapportlayoutet, skal du finde og opdatere alle brudte udtryk.

Filter vs. parameter

Det er sandsynligt, at dine sideinddelte rapportdesign har rapportparametre. Rapportparametre bruges ofte til at bede din rapportbruger om at filtrere rapporten. Som forfatter af sideinddelte rapporter har du to måder at opnå rapportfiltrering på. Du kan knytte en rapportparameter til:

  • Et datasætfilter, i hvilket tilfælde rapportparameterværdien eller -værdierne bruges til at filtrere de data, der allerede er hentet af datasættet.
  • En datasætparameter, i hvilket tilfælde rapportparameterværdien eller -værdierne overføres til den oprindelige forespørgsel, der sendes til datakilden.

Bemærk

Alle rapportdatasæt cachelagres pr. session i op til 10 minutter efter deres seneste brug. Et datasæt kan genbruges, når du sender nye parameterværdier (filtrering), gengiver rapporten i et andet format eller interagerer med rapportdesignet på en eller anden måde, f.eks. ved at skifte synlighed eller sortere.

Overvej derefter et eksempel på en salgsrapport, der har en enkelt rapportparameter for at filtrere rapporten efter et enkelt år. Datasættet henter salg for alle år. Det gør den, fordi rapportparameteren er knyttet til filtrene for datasættet. Rapporten viser data for det ønskede år, som er et undersæt af datasættets data. Når rapportbrugeren ændrer rapportparameteren til et andet år – og derefter får vist rapporten – behøver Power BI ikke at hente kildedata. Det anvender i stedet et andet filter på det datasæt, der allerede er cachelagret. Når datasættet er cachelagret, kan filtreringen være meget hurtig.

Overvej nu et andet rapportdesign. Denne gang knytter rapportdesignet parameteren sales year report til en datasætparameter. På denne måde indsætter Power BI værdien year i den oprindelige forespørgsel, og datasættet henter kun data for det pågældende år. Hver gang rapportbrugeren ændrer parameterværdien for rapporten Year – og derefter får vist rapporten – henter datasættet et nyt forespørgselsresultat for netop det pågældende år.

Begge designmetoder kan filtrere rapportdata, og begge design kan fungere godt i dine rapportdesign. Et optimeret design afhænger dog af de forventede datamængder, datavolatilitet og dine rapportbrugeres forventede funktionsmåde.

Vi anbefaler filtrering af datasæt, når du forventer, at et andet undersæt af datasætrækkerne genbruges mange gange (hvilket sparer gengivelsestid, fordi nye data ikke behøver at blive hentet). I dette scenarie kan du se, at omkostningerne ved at hente et større datasæt kan afskrives i forhold til det antal gange, det genbruges. Det er derfor nyttigt for forespørgsler, der er tidskrævende at generere. Men pas på – cachelagring af store datasæt pr. bruger kan påvirke ydeevnen og kapacitetsoverførselshastigheden negativt.

Vi anbefaler parameterisering af datasæt, når du forventer, at det er usandsynligt, at der anmodes om et andet undersæt af datasætrækker – eller når antallet af datasætrækker, der skal filtreres, sandsynligvis vil være meget stort (og ineffektivt at cachelagre). Denne designtilgang fungerer også godt, når dit datalager er ustabilt. I dette tilfælde medfører hver ændring af rapportparameterværdien, at der hentes opdaterede data.

Ikke-oprindelige datakilder

Hvis du har brug for at udvikle sideinddelte rapporter baseret på datakilder, der ikke understøttes oprindeligt af sideinddelte rapporter, skal du først udvikle en datamodel i Power BI Desktop. På den måde kan du oprette forbindelse til hundredvis af datakilder, der understøttes af Power BI. Når du har publiceret til Power BI-tjeneste, kan du derefter udvikle en sideinddelt rapport, der opretter forbindelse til den semantiske Power BI-model.

Dataintegration

Hvis du har brug for at kombinere data fra flere datakilder, har du to muligheder:

  • Kombiner rapportdatasæt: Hvis datakilderne oprindeligt understøttes af sideinddelte rapporter, kan du overveje at oprette beregnede felter, der bruger funktionerne Opslag eller Opslagssæt Report Builder.
  • Udvikl en Power BI Desktop-model: Det er dog sandsynligvis mere effektivt, at du udvikler en datamodel i Power BI Desktop. Du kan bruge Power Query til at kombinere forespørgsler baseret på en hvilken som helst understøttet datakilde. Når du har publiceret til Power BI-tjeneste, kan du derefter udvikle en sideinddelt rapport, der opretter forbindelse til den semantiske Power BI-model.

Netværksventetid

Netværksventetid kan påvirke rapportens ydeevne ved at øge den tid, det tager for anmodninger at nå Power BI-tjeneste, og for at svar kan leveres. Lejere i Power BI tildeles til et bestemt område.

Tip

Hvis du vil finde ud af, hvor din lejer er placeret, skal du se Hvor er min Power BI-lejer placeret?

Når brugere fra en lejer får adgang til Power BI-tjeneste, dirigeres deres anmodninger altid til dette område. Når anmodninger når Power BI-tjeneste, kan tjenesten derefter sende yderligere anmodninger, f.eks. til den underliggende datakilde eller en datagateway, som også er underlagt netværksventetid. For at minimere virkningen af netværksventetid skal du generelt bestræbe dig på at holde datakilder, gateways og din Power BI-kapacitet så tæt som muligt. De skal helst være placeret i det samme område. Hvis netværksventetid er et problem, kan du prøve at finde gateways og datakilder, der er tættere på din Power BI-kapacitet, ved at placere dem på virtuelle maskiner, der hostes i cloudmiljøet.

Komplekse SQL Server-datatyper

Da SQL Server er en datakilde i det lokale miljø, skal Power BI oprette forbindelse via en gateway. Gatewayen understøtter dog ikke hentning af data til komplekse datatyper. Komplekse datatyper omfatter indbyggede typer, f.eks. geodatatyperne GEOMETRI og GEOGRAFI og hierarki-id. De kan også omfatte brugerdefinerede typer, der implementeres via en klasse af en assembly i Microsoft Microsoft .NET Framework CLR (Common Language Runtime).

Afbildning af afstandsdata og analyser i kortvisualiseringen kræver AFSTANDsdata i SQL Server. Det er derfor ikke muligt at arbejde med kortvisualiseringen, når SQL Server er din datakilde. Det fungerer, hvis din datakilde er Azure SQL Database, fordi Power BI ikke opretter forbindelse via en gateway.

Billeder kan bruges til at føje logoer eller billeder til dit rapportlayout. Når billeder er relateret til de rækker, der hentes af et rapportdatasæt, har du to muligheder:

  • Det er muligt, at billeddata også kan hentes fra din datakilde (hvis de allerede er gemt i en tabel).
  • Når billederne er gemt på en webserver, kan du bruge et dynamisk udtryk til at oprette url-stien til billedet.

Du kan finde flere oplysninger og forslag i Billedvejledning til sideinddelte rapporter.

Redundant datahentning

Det er muligt, at din rapport henter redundante data. Dette kan ske, når du sletter forespørgselsfelter for datasæt, eller rapporten indeholder ubrugte datasæt. Undgå disse situationer, da de medfører en unødvendig byrde for dine datakilder, netværket og Power BI-kapacitetsressourcer.

Slettede forespørgselsfelter

På siden Felter i vinduet Egenskaber for datasæt er det muligt at slette forespørgselsfelter for datasæt (forespørgselsfelter knyttes til kolonner, der hentes af datasætforespørgslen). Report Builder fjerner dog ikke tilsvarende kolonner fra datasætforespørgslen.

Hvis du har brug for at slette forespørgselsfelter fra dit datasæt, anbefaler vi, at du fjerner de tilsvarende kolonner fra datasætforespørgslen. Report Builder fjerner automatisk alle overflødige forespørgselsfelter. Hvis du sletter forespørgselsfelter, skal du også ændre forespørgselssætningen for datasæt for at fjerne kolonnerne.

Ubrugte datasæt

Når en rapport køres, evalueres alle datasæt – også selvom de ikke er bundet til rapportobjekter. Derfor skal du sørge for at fjerne alle test- eller udviklingsdatasæt, før du publicerer en rapport.

Relateret indhold

Du kan få flere oplysninger, der er relateret til denne artikel, i følgende ressourcer: