Richtlijnen voor het ophalen van gegevens voor gepagineerde rapporten

  • Artikel

Dit artikel is bedoeld voor u als auteur van rapporten die gepagineerde Power BI-rapporten ontwerpen. Het biedt aanbevelingen om u te helpen bij het ontwerpen van effectief en efficiënt ophalen van gegevens.

Gegevensbrontypen

Gepagineerde rapporten ondersteunen zowel relationele als analytische gegevensbronnen. Deze bronnen worden verder gecategoriseerd, als cloud of on-premises. On-premises gegevensbronnen, ongeacht of deze on-premises of op een virtuele machine worden gehost, vereisen een gegevensgateway, zodat Power BI verbinding kan maken. Cloudgebaseerde betekent dat Power BI rechtstreeks verbinding kan maken via een internetverbinding.

Als u het gegevensbrontype (mogelijk het geval in een nieuw project) kunt kiezen, wordt u aangeraden cloudgegevensbronnen te gebruiken. Gepagineerde rapporten kunnen verbinding maken met een lagere netwerklatentie, met name wanneer de gegevensbronnen zich in dezelfde regio bevinden als uw Power BI-tenant. Het is ook mogelijk om verbinding te maken met deze bronnen met behulp van eenmalige aanmelding (SSO). Dit betekent dat de identiteit van de rapportgebruiker naar de gegevensbron kan stromen, zodat machtigingen op rijniveau per gebruiker kunnen worden afgedwongen. Momenteel wordt eenmalige aanmelding alleen ondersteund voor on-premises gegevensbronnen SQL Server en Oracle (zie Ondersteunde gegevensbronnen voor gepagineerde Power BI-rapporten).

Notitie

Hoewel het momenteel niet mogelijk is om via eenmalige aanmelding verbinding te maken met on-premises databases, kunt u nog steeds machtigingen op rijniveau afdwingen. Dit wordt gedaan door het ingebouwde veld UserID door te geven aan een parameter voor een gegevenssetquery. De gegevensbron moet UPN-waarden (User Principal Name) opslaan op een manier die queryresultaten correct kan filteren.

Denk er bijvoorbeeld aan dat elke verkoper wordt opgeslagen als een rij in de tabel Verkoper . De tabel bevat kolommen voor UPN en ook de verkoopregio van de verkoper. Tijdens query's wordt de tabel gefilterd op de UPN van de rapportgebruiker en is deze ook gerelateerd aan verkoopfeiten met behulp van een inner join. Op deze manier filtert de query de feitenrijen van de verkoop effectief naar die van de verkoopregio van de rapportgebruiker.

Relationele gegevensbronnen

Over het algemeen zijn relationele gegevensbronnen goed geschikt voor operationele rapporten, zoals verkoopfacturen. Ze zijn ook geschikt voor rapporten die zeer grote gegevenssets moeten ophalen (meer dan 10.000 rijen). Relationele gegevensbronnen kunnen ook opgeslagen procedures definiëren, die kunnen worden uitgevoerd door rapportgegevenssets. Opgeslagen procedures bieden verschillende voordelen:

  • Parameterisering
  • Inkapseling van programmeerlogica, waardoor complexere gegevensvoorbereiding mogelijk is (bijvoorbeeld tijdelijke tabellen, cursors of scalaire door de gebruiker gedefinieerde functies)
  • Verbeterde onderhoudbaarheid, waardoor opgeslagen procedurelogica eenvoudig kan worden bijgewerkt. In sommige gevallen kan dit worden gedaan zonder dat u gepagineerde rapporten hoeft te wijzigen en opnieuw te publiceren (waarbij kolomnamen en gegevenstypen ongewijzigd blijven).
  • Betere prestaties, omdat hun uitvoeringsplannen in de cache worden opgeslagen voor hergebruik
  • Opgeslagen procedures opnieuw gebruiken in meerdere rapporten

In Power BI Report Builder kunt u de ontwerpfunctie voor relationele query's gebruiken om een query-instructie grafisch samen te stellen, maar alleen voor Microsoft-gegevensbronnen.

Analytische gegevensbronnen

Analytische gegevensbronnen, ook wel gegevensmodellen of alleen modellen genoemd, zijn zeer geschikt voor zowel operationele als analytische rapporten en kunnen snel samengevatte queryresultaten leveren, zelfs ten opzichte van zeer grote gegevensvolumes. Modelmetingen en KPI's kunnen complexe bedrijfsregels inkapselen om samenvatting van gegevens te bereiken. Deze gegevensbronnen zijn echter niet geschikt voor rapporten die zeer grote hoeveelheden gegevens moeten ophalen (meer dan 10.000 rijen).

In Power BI Report Builder hebt u een keuze uit twee queryontwerpers: de DAX-ontwerpfunctie voor DAX-query's van Analysis Services en de ONTWERPfunctie voor MDX-query's van Analysis Services. Deze ontwerpers kunnen worden gebruikt voor gegevensbronnen van het semantische Power BI-model (voorheen een gegevensset genoemd) of een SQL Server Analysis Services- of Azure Analysis Services-model, tabellair of multidimensionaal.

U wordt aangeraden de ONTWERPfunctie voor DAX-query's te gebruiken, zodat deze volledig voldoet aan uw querybehoeften. Als het model niet de metingen definieert die u nodig hebt, moet u overschakelen naar de querymodus. In deze modus kunt u de query-instructie aanpassen door expressies toe te voegen (om samenvatting te bereiken).

De MDX-ontwerpfunctie voor query's vereist dat uw model metingen bevat. De ontwerpfunctie heeft twee mogelijkheden die niet worden ondersteund door de DAX-ontwerpfunctie voor query's. In het bijzonder kunt u het volgende doen:

  • Berekende leden op queryniveau definiëren (in MDX).
  • Configureer gegevensregio's om serveraggregaties aan te vragen in niet-detailgroepen. Als uw rapport samenvattingen van semi- of niet-additieve metingen (zoals tijdintelligentieberekeningen of afzonderlijke aantallen) moet presenteren, is het waarschijnlijk efficiënter om serveraggregaties te gebruiken dan om detailrijen op laag niveau op te halen en de berekeningssamenvattingen van het rapport te hebben.

Queryresultaatgrootte

Over het algemeen is het raadzaam om alleen de gegevens op te halen die vereist zijn voor uw rapport. Haal dus geen kolommen of rijen op die niet vereist zijn voor het rapport.

Als u rijen wilt beperken, moet u altijd de meest beperkende filters toepassen en statistische query's definiëren. Statistische query's groeperen en brongegevens samenvatten om hogere resultaten op te halen. Denk er bijvoorbeeld aan dat uw rapport een samenvatting van de verkoopmedewerker moet presenteren. In plaats van alle rijen met verkooporders op te halen, maakt u een gegevenssetquery die per verkoper wordt gegroepeerd en geeft u een overzicht van de verkoop voor elke groep.

Velden op basis van expressies

Het is mogelijk om een rapportgegevensset uit te breiden met velden op basis van expressies. Als de voornaam en achternaam van de klant bijvoorbeeld uw gegevenssetbronnen zijn, wilt u misschien een veld dat de twee velden samenvoegt om de volledige naam van de klant te produceren. U hebt twee opties om deze berekening te bereiken. U kunt:

  • Maak een berekend veld, een gegevenssetveld op basis van een expressie.
  • Injecteer een expressie rechtstreeks in de gegevenssetquery (met behulp van de systeemeigen taal van uw gegevensbron), wat resulteert in een normaal gegevenssetveld.

We raden de laatste optie aan, indien mogelijk. Er zijn twee goede redenen waarom het rechtstreeks injecteren van expressies in uw gegevenssetquery beter is:

  • Het is mogelijk dat uw gegevensbron is geoptimaliseerd om de expressie efficiënter te evalueren dan Power BI (dit is met name het geval voor relationele databases).
  • De rapportprestaties worden verbeterd omdat power BI geen berekende velden hoeft te materialiseren vóór de rapportweergave. Berekende velden kunnen de rapportweergavetijd aanzienlijk verlengen wanneer gegevenssets een groot aantal rijen ophalen.

Veldnamen

Wanneer u een gegevensset maakt, worden de bijbehorende velden automatisch benoemd naar de querykolommen. Het is mogelijk dat deze namen niet vriendelijk of intuïtief zijn. Het is ook mogelijk dat namen van bronquerykolommen tekens bevatten die niet zijn toegestaan in RDL-object-id's (zoals spaties en symbolen). In dit geval worden de verboden tekens vervangen door een onderstrepingsteken (_).

We raden u aan eerst te controleren of alle veldnamen beschrijvend, beknopt, maar nog steeds zinvol zijn. Zo niet, dan wordt u aangeraden de naam ervan te wijzigen voordat u begint met de rapportindeling. Dit komt doordat hernoemde velden geen wijzigingen veroorzaken in de expressies die in de rapportindeling worden gebruikt. Als u besluit om de naam van velden te wijzigen nadat u de rapportindeling hebt gestart, moet u alle verbroken expressies zoeken en bijwerken.

Filter versus parameter

Het is waarschijnlijk dat uw gepagineerde rapportontwerpen rapportparameters hebben. Rapportparameters worden vaak gebruikt om uw rapportgebruiker te vragen het rapport te filteren. Als auteur van een gepagineerd rapport hebt u twee manieren om rapportfiltering te bereiken. U kunt een rapportparameter toewijzen aan:

  • Een gegevenssetfilter, in dat geval worden de rapportparameterwaarden gebruikt om de gegevens te filteren die al door de gegevensset zijn opgehaald.
  • Een gegevenssetparameter, in welk geval de rapportparameterwaarde(s) worden geïnjecteerd in de systeemeigen query die naar de gegevensbron wordt verzonden.

Notitie

Alle rapportgegevenssets worden gedurende maximaal 10 minuten na het laatste gebruik in de cache opgeslagen per sessie. Een gegevensset kan opnieuw worden gebruikt bij het verzenden van nieuwe parameterwaarden (filteren), het weergeven van het rapport in een andere indeling of het werken met het rapportontwerp, zoals het in- of uitschakelen van zichtbaarheid of sorteren.

Bekijk vervolgens een voorbeeld van een verkooprapport met één rapportparameter om het rapport één jaar te filteren. De gegevensset haalt de verkoop voor alle jaren op. Dit gebeurt omdat de rapportparameter wordt toegewezen aan de filters van de gegevensset. In het rapport worden gegevens weergegeven voor het aangevraagde jaar. Dit is een subset van de gegevenssetgegevens. Wanneer de rapportgebruiker de rapportparameter wijzigt in een ander jaar en vervolgens het rapport weergeeft, hoeft Power BI geen brongegevens op te halen. In plaats daarvan wordt een ander filter toegepast op de al in de cache opgeslagen gegevensset. Zodra de gegevensset in de cache is opgeslagen, kan filteren zeer snel zijn.

Overweeg nu een ander rapportontwerp. Deze keer wijst het rapportontwerp de rapportparameter verkoopjaar toe aan een gegevenssetparameter. Op deze manier injecteert Power BI de jaarwaarde in de systeemeigen query en haalt de gegevensset alleen gegevens op voor dat jaar. Telkens wanneer de rapportgebruiker de parameterwaarde van het jaarrapport wijzigt en vervolgens het rapport weergeeft, haalt de gegevensset voor dat jaar een nieuw queryresultaat op.

Beide ontwerpmethoden kunnen rapportgegevens filteren en beide ontwerpen kunnen goed werken voor uw rapportontwerpen. Een geoptimaliseerd ontwerp is echter afhankelijk van de verwachte gegevensvolumes, gegevensvolatiliteit en het verwachte gedrag van uw rapportgebruikers.

Het is raadzaam om gegevenssetfilters te filteren wanneer u verwacht dat een andere subset van de gegevenssetrijen vaak opnieuw wordt gebruikt (waardoor de renderingtijd wordt bespaard omdat nieuwe gegevens niet hoeven te worden opgehaald). In dit scenario herkent u dat de kosten voor het ophalen van een grotere gegevensset kunnen worden afgeschreven van het aantal keren dat deze opnieuw wordt gebruikt. Het is dus handig voor query's die tijdrovend zijn om te genereren. Maar let op: het opslaan van grote gegevenssets per gebruiker kan negatieve gevolgen hebben voor de prestaties en de doorvoer van de capaciteit.

We raden u aan gegevenssetparameterisatie uit te voeren wanneer u verwacht dat het onwaarschijnlijk is dat een andere subset van gegevenssetrijen wordt aangevraagd, of wanneer het aantal te filteren gegevenssetrijen waarschijnlijk zeer groot is (en inefficiënt is voor cache). Deze ontwerpbenadering werkt ook goed wanneer uw gegevensarchief vluchtig is. In dit geval leidt elke wijziging van de parameterwaarde van het rapport tot het ophalen van actuele gegevens.

Niet-systeemeigen gegevensbronnen

Als u gepagineerde rapporten wilt ontwikkelen op basis van gegevensbronnen die niet systeemeigen worden ondersteund door gepagineerde rapporten, moet u eerst een gegevensmodel ontwikkelen in Power BI Desktop. Op die manier kunt u verbinding maken met honderden gegevensbronnen die worden ondersteund door Power BI. Zodra het is gepubliceerd naar de Power BI-service, kunt u vervolgens een gepagineerd rapport ontwikkelen dat verbinding maakt met het semantische Power BI-model.

Gegevensintegratie

Als u gegevens uit meerdere gegevensbronnen wilt combineren, hebt u twee opties:

  • Rapportgegevenssets combineren: als de gegevensbronnen systeemeigen worden ondersteund door gepagineerde rapporten, kunt u overwegen berekende velden te maken die gebruikmaken van de functies Lookup of LookupSet Report Builder.
  • Een Power BI Desktop-model ontwikkelen: het is waarschijnlijk efficiënter om een gegevensmodel te ontwikkelen in Power BI Desktop. U kunt Power Query gebruiken om query's te combineren op basis van elke ondersteunde gegevensbron. Zodra het is gepubliceerd naar de Power BI-service, kunt u vervolgens een gepagineerd rapport ontwikkelen dat verbinding maakt met het semantische Power BI-model.

Netwerklatentie

Netwerklatentie kan van invloed zijn op de rapportprestaties door de tijd te verhogen die nodig is voor aanvragen om de Power BI-service te bereiken en om reacties te leveren. Tenants in Power BI worden toegewezen aan een specifieke regio.

Tip

Als u wilt bepalen waar uw tenant zich bevindt, raadpleegt u Waar bevindt mijn Power BI-tenant zich?

Wanneer gebruikers van een tenant toegang hebben tot de Power BI-service, worden hun aanvragen altijd doorgestuurd naar deze regio. Wanneer aanvragen de Power BI-service bereiken, kan de service vervolgens aanvullende aanvragen verzenden, bijvoorbeeld naar de onderliggende gegevensbron of een gegevensgateway, die ook onderhevig zijn aan netwerklatentie. Om de impact van netwerklatentie te minimaliseren, streeft u ernaar om gegevensbronnen, gateways en uw Power BI-capaciteit zo dicht mogelijk bij elkaar te houden. Bij voorkeur bevinden ze zich binnen dezelfde regio. Als netwerklatentie een probleem is, kunt u gateways en gegevensbronnen dichter bij uw Power BI-capaciteit zoeken door ze in de cloud gehoste virtuele machines te plaatsen.

Complexe SQL Server-gegevenstypen

Omdat SQL Server een on-premises gegevensbron is, moet Power BI verbinding maken via een gateway. De gateway biedt echter geen ondersteuning voor het ophalen van gegevens voor complexe gegevenstypen. Complexe gegevenstypen omvatten ingebouwde typen, zoals de gegevenstypen GEOMETRIE en GEOGRAFIE, en hiërarchie-id. Ze kunnen ook door de gebruiker gedefinieerde typen bevatten die zijn geïmplementeerd via een klasse van een assembly in de Microsoft.NET Framework Common Language Runtime (CLR).

Voor het plotten van ruimtelijke gegevens en analyses in de kaartvisualisatie zijn ruimtelijke SQL Server-gegevens vereist. Daarom is het niet mogelijk om met de kaartvisualisatie te werken wanneer SQL Server uw gegevensbron is. Om duidelijk te zijn, werkt dit als uw gegevensbron Azure SQL Database is, omdat Power BI geen verbinding maakt via een gateway.

Afbeeldingen kunnen worden gebruikt om logo's of afbeeldingen toe te voegen aan uw rapportindeling. Wanneer afbeeldingen betrekking hebben op de rijen die zijn opgehaald door een rapportgegevensset, hebt u twee opties:

  • Het is mogelijk dat afbeeldingsgegevens ook kunnen worden opgehaald uit uw gegevensbron (als deze al in een tabel zijn opgeslagen).
  • Wanneer de afbeeldingen worden opgeslagen op een webserver, kunt u een dynamische expressie gebruiken om het pad naar de afbeeldings-URL te maken.

Zie De richtlijnen voor afbeeldingen voor gepagineerde rapporten voor meer informatie en suggesties.

Redundante gegevens ophalen

Het is mogelijk dat uw rapport redundante gegevens ophaalt. Dit kan gebeuren wanneer u gegevenssetqueryvelden verwijdert of als het rapport ongebruikte gegevenssets bevat. Vermijd deze situaties, omdat ze leiden tot een onnodige belasting van uw gegevensbronnen, het netwerk en Power BI-capaciteitsbronnen.

Verwijderde queryvelden

Op de pagina Velden van het venster Eigenschappen van gegevensset kunt u gegevenssetqueryvelden verwijderen (queryvelden worden toegewezen aan kolommen die zijn opgehaald door de gegevenssetquery). Report Builder verwijdert echter geen bijbehorende kolommen uit de gegevenssetquery.

Als u queryvelden uit uw gegevensset wilt verwijderen, raden we u aan de bijbehorende kolommen uit de gegevenssetquery te verwijderen. Report Builder verwijdert automatisch redundante queryvelden. Als u wel queryvelden verwijdert, moet u ook de instructie van de gegevenssetquery wijzigen om de kolommen te verwijderen.

Ongebruikte gegevenssets

Wanneer een rapport wordt uitgevoerd, worden alle gegevenssets geëvalueerd, zelfs als ze niet zijn gebonden aan rapportobjecten. Zorg er daarom voor dat u test- of ontwikkelingsgegevenssets verwijdert voordat u een rapport publiceert.

Gerelateerde inhoud

Raadpleeg de volgende bronnen voor meer informatie over dit artikel: