Vejledning til datahentning for sideinddelte rapporter

Denne artikel henvender sig til rapportforfattere, der designer sideinddelte rapporter i Power BI. Det indeholder anbefalinger, der kan hjælpe dig med at designe effektive og effektive datahentning.

Datakildetyper

Sideinddelte rapporter understøtter i oprindeligt både Relations-og analyse datakilder. Disse kilder er yderligere kategoriseret som enten skybaseret eller i det lokale miljø. datakilder i det lokale miljø – uanset om det er hostet i det lokale miljø eller på en virtuel maskine – kræver en data gateway, så Power BI kan oprette forbindelse. Cloud-baseret betyder, at Power BI kan oprette forbindelse direkte ved hjælp af en Internet forbindelse.

Hvis du kan vælge datakildetypen (muligvis i et nyt projekt), anbefaler vi, at du bruger skybaserede datakilder. sideinddelte rapporter kan forbindes med en lavere netværksventetid, især når datakilderne er placeret i samme område som din Power BI lejer. Det er også muligt at oprette forbindelse til disse kilder ved hjælp af en enkelt Sign-On (SSO). Det betyder, at rapport brugerens identitet kan flyde til datakilden, hvilket gør det muligt at gennemtvinge tilladelser på rækkeniveau. i øjeblikket understøttes SSO for datakilder i det lokale miljø (dvs. SQL Server Analysis Services kan ikke gennemtvinge tilladelser på rækkeniveau pr. bruger.

Relationelle datakilder

Almindelige datakilder er også velegnede til drifts stil rapporter som f. eks. salgsfakturaer. De er også egnet til rapporter, der skal hente meget store datasæt (i overstiger 10.000 rækker). Relationelle datakilder kan også definere lagrede procedurer, som kan udføres af rapport datasæt. Lagrede procedurer giver flere fordele:

• Parameterisering
• Indkapsling af programmerings logik, der giver mulighed for mere komplekse data tilberedninger (f. eks. midlertidige tabeller, markører eller brugerdefinerede skalarfunktion)
• Forbedret vedligeholdelse, så stored procedure Logic nemt opdateres. I nogle tilfælde kan det ske, uden at der er behov for at ændre sideinddelte rapporter og publicere dem igen (hvis kolonnenavne og datatyper forbliver uændrede).
• Bedre ydeevne, da deres udførelses planer cachelagres til genbrug
• Genbrug af lagrede procedurer på tværs af flere rapporter

i Power BI Report Builder kan du bruge den relationelle forespørgselsdesigner til at konstruere en forespørgselssætning grafisk, men kun for Microsoft-datakilder.

Analytiske datakilder

Analyse datakilder er velegnede til både drifts-og analyserapporter, og de kan levere hurtige opsummerede forespørgselsresultater, der også overstiger meget store datamængder. Model målinger og KPI'er kan indkapsle komplekse forretningsregler for at opnå en opsummering af data. Disse datakilder er dog ikke velegnede til rapporter, der skal hente meget store datasæt (i overstiger 10.000 rækker).

i Power BI Report Builder kan du vælge mellem to forespørgsels designere: Analysis Services DAX-forespørgselsdesigneren og Analysis Services MDX-forespørgselsdesigneren. disse designere kan bruges til Power BI datakilder til datasæt eller en hvilken som helst SQL Server Analysis Services eller Azure Analysis Services model – tabel eller flerdimensionel.

Vi foreslår, at du bruger DAX-forespørgselsdesigneren – og det opfylder kun dine behov i din forespørgsel. Hvis modellen ikke definerer de målinger, du har brug for, skal du skifte til forespørgselstilstand. I denne tilstand kan du tilpasse forespørgsels sætningen ved at tilføje udtryk (for at opnå opsummering).

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

• Definer beregnede medlemmer på forespørgsels niveau (i MDX).
• Konfigurer dataområder, så der kan anmodes om Server aggregater i grupper, der ikke er oplysninger om. Hvis din rapport har brug for at fremvise 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 server aggregater til at hente detaljerækker på lavt niveau og have en opsummering af rapport beregningerne.

Størrelse af forespørgselsresultat

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

Hvis du vil begrænse rækker, skal du altid anvende de mest restriktive filtre og definere aggregatforespørgsler. Saml forespørgsler gruppen, og Opsummer kildedata for at hente resultater med højere korn. Du kan f. eks. overveje, at rapporten skal vise en oversigt over sælgers salg. I stedet for at hente alle salgsordre rækker kan du oprette en DataSet-forespørgsel, der grupperer efter sælger, og som opsummerer salg for hver gruppe.

Udtryks baserede felter

Det er muligt at udvide et rapport datasæt med felter, der er baseret på udtryk. Hvis data for dit datasæt f. eks. kunde fornavn og efter navn, vil du måske gerne have et felt, der sammenkæder de to felter for at give kunden det fulde navn. Du har to muligheder for at opnå denne beregning. Du kan:

• Opret et beregnet felt, der er et DataSet-feltbaseret på et udtryk.
• Indsæt et udtryk direkte i forespørgslen DataSet (ved hjælp af det oprindelige sprog i datakilden), hvilket resulterer i et almindeligt datasæt felt.

Vi anbefaler den sidste mulighed, når det er muligt. Der er to gode årsager til, at det er bedst at indsætte udtryk direkte i forespørgslen datasæt.

• det er muligt, at datakilden er optimeret til at evaluere udtrykket mere effektivt end Power BI (det er især tilfældet for relationelle databaser).
• rapportens ydeevne er forbedret, fordi der ikke er behov for Power BI til materialize beregnede felter før rapportgengivelse. Beregnede felter kan samtidig forlænge rapport gengivelses tiden, når datasæt henter et stort antal rækker.

Feltnavne

Når du opretter et datasæt, navngives dens felter automatisk efter forespørgslens kolonner. Det er muligt, at disse navne ikke er brugervenlige eller intuitive. Det er også muligt, at navne på kildeforespørgslen indeholder tegn, der ikke er tilladt i Report Definition Language (RDL) objekt-id'er (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 klar, præcis, men alligevel meningsfulde. Hvis ikke, foreslår vi, at du omdøber dem, før du begynder rapportlayoutet. Det skyldes, at omdøbte felter ikke ripple ændringer til de udtryk, der bruges i dit rapportlayout. Hvis du beslutter at omdøbe felter, efter at du har påbegyndt rapportlayoutet, skal du finde og opdatere alle brudte udtryk.

Filter vs-parameter

Det er sandsynligt, at dine sideinddelte rapportdesign vil have rapportparametre. Rapportparametre bruges normalt til at bede din rapport bruger om at filtrere rapporten. Som en sideinddelt rapport forfatter har du to måder til at opnå rapportfiltrering. Du kan knytte en rapportparameter til:

• Et DataSet- filter, hvor du kan bruge værdierne for rapportparameteren (s) til at filtrere de data, der allerede er hentet af datasættet.
• En parameter af datasættet, hvor værdierne for rapportparameteren (s) indsprøjtes i den oprindelige forespørgsel, der sendes til datakilden.

Overvej, og derefter et eksempel på en salgsrapport, der har en enkelt rapportparameter til at filtrere rapporten med et enkelt år. Datasættet henter salg for alle år. Det gør vi, fordi rapportparameteren er knyttet til filtre for datasæt. Rapporten viser data for det ønskede år, som er et undersæt af data for datasættet. når brugeren ændrer rapportparameteren til et andet år – og derefter får vist rapporten, er Power BI ikke nødt til at hente nogen kildedata. Den anvender i stedet et andet filter på datasættet, der allerede er cachelagret. Når datasættet er cachelagret, kan det være meget hurtigt at filtrere.

Overvej nu et andet rapportdesign. Denne gang rapportdesignet knyttes rapportparameteren Sales Year til en parameter af datasættet. 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 rapportens bruger ændrer værdien for rapportparameteren Year – og derefter får vist rapporten – får du vist et nyt forespørgselsresultat for det samme år i datasættet.

Begge design metoder kan filtrere rapportdata, og begge design kan fungere godt i dine rapportdesign. Et optimeret design er dog afhængigt af de forventede datamængder, data ustabilitet og de forventede funktionsmåder for dine rapportbrugere.

Vi anbefaler filtrering af datasæt , når du forventer et andet undersæt af datasætnes rækker genbruges mange gange (derved gemmes gengivelses tidspunktet, fordi der ikke skal hentes nye data). I dette scenarie er du klar over, at omkostningerne ved at hente et større datasæt kan handles på i forhold til det antal gange, det genbruges. Det er derfor nyttigt for forespørgsler, der er tidskrævende at generere. Men vær forsigtig – cachelagring af store datasæt pr. bruger kan påvirke ydeevnen og kapacitetens gennemløb negativt.

Vi anbefaler parameterisering af datasæt, når du forventer, at der sandsynligvis ikke bliver anmodet om et andet undersæt af rækkerne i datasættet – eller når antallet af rækker i datasættet filtreres, er sandsynligvis meget stort (og ineffektivt at cachelagre). Denne designtilgang fungerer også godt, når datalageret er svingende. I dette tilfælde resulterer hver ændring af rapportparameterværdien i hentning af opdaterede data.

Datakilder, der ikke er oprindelige

Hvis du har brug for at udvikle sideindderede rapporter, der er baseret på datakilder, der ikke oprindeligt understøttes af sideinddelige rapporter,kan du først udvikle en Power BI Desktop datamodel. På denne måde kan du oprette forbindelse til mere end 100 Power BI datakilder. Når du har publiceret Power BI tjenesten, kan du derefter udvikle en sideindtindret rapport, der opretter forbindelse til Power BI datasættet.

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 sideindde sidende rapporter,kan du overveje at oprette beregnede felter, der bruger opslags- eller opslagssættet til Report Builder funktioner.
• Udvik Power BI Desktop model: Det er 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 Power BI tjenesten, kan du derefter udvikle en sideindtindret rapport, der opretter forbindelse til Power BI datasættet.

SQL Server komplekse datatyper

Da SQL Server 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 som datatyperne GEOMETRY og GEOGRAPHY spatiale datatyperog hierarkiid. De kan også indeholde brugerdefinerede typer, der implementeres via en klasse af en assembly i Microsoft.NET CLR (Framework common language runtime).

Afbildning af afstandsdata og analyse i kortvisualisering kræver SQL Server rumlige data. Det er derfor ikke muligt at arbejde med kortvisualisering, når SQL Server er din datakilde. For at gøre det helt klart fungerer det, hvis din datakilde er Azure SQL Database, Power BI ikke opretter forbindelse via en gateway.

Datarelaterede billeder

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 under Billedvejledning til sideindde sidende 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 har 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 forespørgslen for datasættet). Men Report Builder fjerner ikke tilsvarende kolonner fra forespørgslen for datasættet.

Hvis du har brug for at slette forespørgselsfelter fra dit datasæt, anbefaler vi, at du fjerner de tilsvarende kolonner fra forespørgslen for datasættet. Report Builder alle redundante forespørgselsfelter automatisk. Hvis du kommer til at slette forespørgselsfelter, skal du også ændre forespørgselssætningen for datasættet 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 fjerne alle test- eller udviklingsdatasæt, før du publicerer en rapport.

Næste trin

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

• Understøttede datakilder for sideinddelte rapporter i Power BI
• Har du spørgsmål? Prøv at spørge Power BI-community'et
• Forslag? Få ideer til at forbedre Power BI