Richtlijnen voor het ophalen van gegevens voor gepagineerde rapporten

Dit artikel is bedoeld voor u wanneer u als auteur gepagineerde rapporten in Power BI gaat ontwerpen. Het biedt aanbevelingen om u te helpen effectief en efficiënt gegevens ophalen te ontwerpen.

Typen gegevensbronnen

Ge pagineerde rapporten ondersteunen standaard zowel relationele als analytische gegevensbronnen. Deze bronnen worden verder gecategoriseerd, als cloud of on-premises. Voor on-premises gegevensbronnen, ongeacht of deze on-premises of op een virtuele machine worden gehost, is een gegevensgateway vereist, zodat Power BI verbinding kan maken. Cloudgebaseerd betekent dat Power BI rechtstreeks verbinding kunnen maken via een internetverbinding.

Als u het type gegevensbron kunt kiezen (mogelijk het geval in een nieuw project), raden we u aan gegevensbronnen in de cloud te gebruiken. Ge pagineerde 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 Single Sign-On (SSO). Dit betekent dat de identiteit van de rapportgebruiker naar de gegevensbron kan stromen, waardoor machtigingen op rijniveau per gebruiker kunnen worden afgedwongen. Eenmalige aanmelding wordt momenteel niet ondersteund voor on-premises gegevensbronnen (SQL Server Analysis Services kan geen machtigingen per gebruiker op rijniveau afdwingen).

Relationele gegevensbronnen

Relationele gegevensbronnen zijn over het algemeen zeer 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
• Inkapsling van programmeerlogica, waardoor complexere gegevensvoorbereiding mogelijk is (bijvoorbeeld tijdelijke tabellen, cursors of scalaire door de gebruiker gedefinieerde functies)
• Verbeterde onderhoudbaarheid, zodat opgeslagen procedurelogica eenvoudig kan worden bijgewerkt. In sommige gevallen kan dit worden gedaan zonder gepagineerde rapporten te hoeven wijzigen en opnieuw te publiceren (mits kolomnamen en gegevenstypen ongewijzigd blijven).
• Betere prestaties, omdat hun uitvoeringsplannen in de cache worden opgeslagen voor hergebruik
• Opgeslagen procedures hergebruiken in meerdere rapporten

In Power BI Report Builder kunt u de relationele queryontwerpfunctie gebruiken om grafisch een query-instructie te maken, maar alleen voor Microsoft-gegevensbronnen.

Analytische gegevensbronnen

Analytische gegevensbronnen zijn zeer geschikt voor zowel operationele als analytische rapporten en kunnen snel samengevatte queryresultaten leveren, zelfs voor zeer grote gegevensvolumes. Model metingen en KPI's kunnen complexe bedrijfsregels inkapseld om een samenvatting van gegevens te krijgen. Deze gegevensbronnen zijn echter niet geschikt voor rapporten die zeer grote gegevenssets moeten ophalen (meer dan 10.000 rijen).

In Power BI Report Builder kunt u kiezen uit twee queryontwerpers: de Analysis Services DAX-queryontwerper en de Analysis Services MDX-queryontwerper. Deze ontwerpers kunnen worden gebruikt voor Power BI gegevensbronnen van gegevenssets, of voor een SQL Server Analysis Services of Azure Analysis Services-model, in tabelvorm of multidimensionaal.

We raden u aan de DAX-queryontwerpfunctie te gebruiken, mits 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 een samenvatting te krijgen).

Voor de MDX-queryontwerpfunctie moet uw model metingen bevatten. De ontwerpfunctie heeft twee mogelijkheden die niet worden ondersteund door de DAX-queryontwerpfunctie. Met name hiermee kunt u het volgende doen:

• Berekende leden op queryniveau definiëren (in MDX).
• Gegevensgebieden configureren om serveraggregaties in niet-gedetailleerde groepen aan te vragen. Als uw rapport samenvattingen van semi- of niet-additieve metingen moet presenteren (zoals time intelligence-berekeningen of afzonderlijke tellingen), is het waarschijnlijk efficiënter om serveraggregaties te gebruiken dan om detailrijen op laag niveau op te halen en de samenvattingen van de rapportberekeningen te hebben.

Grootte van queryresultaat

Over het algemeen is het best practice 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 aggregatiequery's definiëren. Statistische query's groepeert en vat brongegevens samen om resultaten met een hoger niveau op te halen. Houd er bijvoorbeeld rekening mee dat uw rapport een samenvatting van de verkoopcijfers van verkopers moet presenteren. In plaats van alle rijen van verkooporders op te halen, maakt u een gegevenssetquery die wordt gegroepeerd op verkoper en geeft u een overzicht van de verkoop voor elke groep.

Op expressies gebaseerde velden

Het is mogelijk om een rapportset uit te breiden met velden op basis van expressies. Als uw gegevensset bijvoorbeeld de voor- en achternaam van de klant bevat, wilt u mogelijk een veld dat de twee velden samenvoegt om de volledige naam van de klant te produceren. Als u deze berekening wilt uitvoeren, hebt u twee opties. U kunt:

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

Indien mogelijk raden we de laatste optie aan. Er zijn twee goede redenen waarom het beter is om expressies rechtstreeks in uw gegevenssetquery in te voeren:

• Het is mogelijk dat uw gegevensbron is geoptimaliseerd om de expressie efficiënter te evalueren dan Power BI (dit geldt met name voor relationele databases).
• De rapportprestaties zijn verbeterd omdat het niet nodig is om berekende Power BI te materialiseren voordat het rapport wordt weergeven. Berekende velden kunnen de rendertijd van het rapport aanzienlijk verlengen wanneer gegevenssets een groot aantal rijen ophalen.

Veldnamen

Wanneer u een gegevensset maakt, worden de velden automatisch genoemd naar de querykolommen. Het is mogelijk dat deze namen niet gebruiksvriendelijk of intuïtief zijn. Het is ook mogelijk dat kolomnamen van bronquery's tekens bevatten die niet zijn toegestaan in Report Definition Language (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 gebruiksvriendelijk, beknopt, maar nog steeds zinvol zijn. Zo niet, dan raden we u aan de naam ervan te wijzigen voordat u begint met de rapportindeling. Dit komt doordat de naam van velden niet wordt gewijzigd in de expressies die worden gebruikt in de rapportindeling. Als u besluit de naam van velden te wijzigen nadat u de rapportindeling hebt gestart, moet u alle verbroken expressies zoeken en bijwerken.

Filteren versus parameter

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

• Een gegevenssetfilter. In dat geval worden de waarde(en) van rapportparameters gebruikt om de gegevens te filteren die al zijn opgehaald door de gegevensset.
• Een gegevenssetparameter. In dat geval worden de waarde(en) van de rapportparameters geïnjecteerd in de native query die naar de gegevensbron wordt verzonden.

Neem vervolgens een voorbeeld van een verkooprapport met één rapportparameter om het rapport op één jaar te filteren. De gegevensset haalt de verkoop voor alle jaren op. Dit gebeurt omdat de rapportparameter wordt toegewezen aan de gegevenssetfilters. 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 bekijkt, hoeft Power BI geen brongegevens op te halen. In plaats daarvan wordt een ander filter toegepast op de gegevensset die al in de cache is opgeslagen. Zodra de gegevensset in de cache is opgeslagen, kan het filteren zeer snel gaan.

Overweeg nu een ander rapportontwerp. Deze keer wordt met het rapportontwerp de rapportparameter verkoopjaar toegewezen aan een gegevenssetparameter. Op deze manier Power BI de jaarwaarde in de native query en haalt de gegevensset alleen gegevens voor dat jaar op. Telkens als de rapportgebruiker de parameterwaarde jaarrapport wijzigt en vervolgens het rapport bekijkt, haalt de gegevensset een nieuw queryresultaat op voor dat jaar.

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

We raden u aan om gegevenssets te filteren wanneer u verwacht dat een andere subset van de gegevenssetrijen vaak opnieuw wordt gebruikt (waardoor de weergavetijd wordt bespaart omdat er geen nieuwe gegevens hoeven te worden opgehaald). In dit scenario herkent u dat de kosten van het ophalen van een grotere gegevensset kunnen worden inruilen tegen het aantal keren dat deze opnieuw wordt gebruikt. Het is dus handig voor query's die veel tijd in beslag nemen om te genereren. Maar zorg er wel voor dat het in deaching van grote gegevenssets per gebruiker een negatieve invloed kan hebben op de prestaties en de capaciteitsdoorvoer.

We raden parameterisering van gegevenssets aan wanneer u verwacht dat er waarschijnlijk geen andere subset van gegevenssetrijen wordt aangevraagd, of wanneer het aantal gegevenssetrijen dat moet worden gefilterd waarschijnlijk erg groot is (en inefficiënt is voor de cache). Deze ontwerpbenadering werkt ook goed als uw gegevensopslag vluchtig is. In dit geval resulteert elke wijziging in de rapportparameterwaarde in het ophalen van actuele gegevens.

Niet-native gegevensbronnen

Als u ge pagineerde rapporten moet ontwikkelen op basis van gegevensbronnen die niet standaard worden ondersteund door ge pagineerde rapporten,kunt u eerst een Power BI Desktop ontwikkelen. Op deze manier kunt u verbinding maken met meer dan 100 Power BI gegevensbronnen. Na publicatie naar de Power BI service kunt u vervolgens een ge pagineerd rapport ontwikkelen dat verbinding maakt met de Power BI gegevensset.

Gegevensintegratie

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

• Rapportgegevenssets combineren: als de gegevensbronnen systeemeigen worden ondersteund door ge pagineerde rapporten,kunt u overwegen berekende velden te maken die gebruikmaken van de functies Lookup of LookupSet Report Builder gebruiken.
• Een Power BI Desktop ontwikkelen: het is waarschijnlijk efficiënter, maar u ontwikkelt een gegevensmodel in Power BI Desktop. U kunt Power Query query's combineren op basis van elke ondersteunde gegevensbron. Na publicatie naar de Power BI service kunt u vervolgens een ge pagineerd rapport ontwikkelen dat verbinding maakt met de Power BI gegevensset.

SQL Server complexe gegevenstypen

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

Het plotten van ruimtelijke gegevens en analyses in de kaartvisualisatie vereist SQL Server ruimtelijke gegevens. Het is daarom niet mogelijk om met de kaartvisualisatie te werken wanneer SQL Server uw gegevensbron is. Voor de duidelijkheid: het werkt als uw gegevensbron niet Azure SQL Database omdat Power BI geen verbinding maakt via een gateway.

Gegevensgerelateerde afbeeldingen

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 rapportset, hebt u twee opties:

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

Zie Richtlijnen voor afbeeldingen voor ge pagineerderapporten voor meer informatie en suggesties.

Redundante gegevens ophalen

Het is mogelijk dat uw rapport redundante gegevens op haalt. Dit kan gebeuren wanneer u queryvelden voor gegevenssets verwijdert of wanneer het rapport ongebruikte gegevenssets bevat. Vermijd deze situaties, omdat deze leiden tot een onnodige belasting voor uw gegevensbronnen, het netwerk en Power BI resources.

Verwijderde queryvelden

Op de pagina Velden van het venster Eigenschappen van gegevensset is het mogelijk om queryvelden voor gegevenssets te verwijderen (queryvelden worden toegewezen aan kolommen die zijn opgehaald door de gegevenssetquery). Met Report Builder worden de bijbehorende kolommen echter niet uit de gegevenssetquery verwijderd.

Als u queryvelden uit uw gegevensset wilt verwijderen, raden we u aan de bijbehorende kolommen uit de gegevenssetquery te verwijderen. Report Builder redundante queryvelden worden automatisch verwijderd. Als u queryvelden verwijdert, moet u ook de query-instructie van de gegevensset 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. Daarom moet u alle test- of ontwikkelingssets verwijderen voordat u een rapport publiceert.

Volgende stappen

Bekijk de volgende resources voor meer informatie over dit artikel:

• Ondersteunde gegevensbronnen voor gepagineerde rapporten in Power BI
• Vragen? Misschien dat de Power BI-community het antwoord weet
• Suggesties? Ideeën bijdragen om Power BI te verbeteren