Del via


Veiledning for spørringsdelegering i Power BI Desktop

Denne artikkelen er rettet mot datamodellerere som utvikler modeller i Power BI Desktop. Den gir anbefalte fremgangsmåter for når – og hvordan – du kan oppnå Power Query-spørringsdelegering.

Spørringsdelegering er muligheten for en Power Query-spørring til å generere en enkelt spørringssetning som henter og transformerer kildedata. Hvis du vil ha mer informasjon, kan du se Power Query-spørringsdelegering.

Veiledning

Veiledning for spørringsdelegering er forskjellig basert på modellmodus.

For en DirectQuery - eller Dual Storage-modustabell må Power Query-spørringen oppnå spørringsdelegering.

For en importtabell kan det være mulig å oppnå spørringsdelegering. Når spørringen er basert på en relasjonskilde, og hvis en enkelt SELECT-setning kan konstrueres, oppnår du best ytelse for dataoppdatering ved å sikre at spørringsdelegering skjer. Hvis Power Query-mashup-motoren fremdeles er nødvendig for å behandle transformasjoner, bør du strebe etter å minimere arbeidet den trenger å gjøre, spesielt for store semantiske modeller.

Følgende punktliste gir spesifikk veiledning.

  • Deleger så mye behandling til datakilden som mulig: Når alle trinnene i en Power Query-spørring ikke kan brettes, oppdager du trinnet som hindrer spørringsdelegering. Når det er mulig, flytter du senere trinn tidligere i rekkefølge, slik at de kan tas med i spørringsdelegeringen. Vær oppmerksom på at power query-mashup-motoren kan være smart nok til å endre rekkefølgen på spørringstrinnene når den genererer kildespørringen.

    Hvis trinnet som forhindrer spørringsdelegering for en relasjonsdatakilde, kan oppnås i én enkelt SELECT-setning, eller innenfor prosedyrelogikken i en lagret prosedyre, bør du vurdere å bruke en opprinnelig SQL-spørring, som beskrevet neste gang.

  • Bruk en opprinnelig SQL-spørring: Når en Power Query-spørring henter data fra en relasjonskilde, er det mulig for enkelte kilder å bruke en opprinnelig SQL-spørring. Spørringen kan faktisk være en hvilken som helst gyldig setning, inkludert en lagret prosedyrekjøring. Hvis setningen produserer flere resultatsett, returneres bare den første. Parametere kan deklareres i setningen, og vi anbefaler at du bruker Value.NativeQuery M-funksjonen. Denne funksjonen ble utformet for å sende parameterverdier trygt og enkelt. Det er viktig å forstå at Power Query-mashup-motoren ikke kan brette senere spørringstrinn, og derfor bør du inkludere alle – eller så mye – transformasjonslogikk i den opprinnelige spørringssetningen.

    Det finnes to viktige hensyn du må huske på når du bruker opprinnelige SQL-spørringer:

    • For en DirectQuery-modelltabell må spørringen være en SELECT-setning, og den kan ikke bruke Vanlige tabelluttrykk (CTE-er) eller en lagret prosedyre.
    • Trinnvis oppdatering kan ikke bruke en opprinnelig SQL-spørring. Så det ville tvinge Power Query-mashup-motoren til å hente alle kilderader, og deretter bruke filtre for å bestemme trinnvise endringer.

    Viktig

    En opprinnelig SQL-spørring kan potensielt gjøre mer enn å hente data. Alle gyldige setninger kan kjøres (og muligens flere ganger), inkludert en som endrer eller sletter data. Det er viktig at du bruker prinsippet om minst mulig rettighet for å sikre at kontoen som brukes til å få tilgang til databasen, bare har lesetillatelse på nødvendige data.

  • Klargjøre og transformere data i kilden: Når du identifiserer at bestemte power query-spørringstrinn ikke kan brettes, kan det være mulig å bruke transformasjonene i datakilden. Transformasjonene kan oppnås ved å skrive en databasevisning som logisk transformerer kildedata. Eller, ved å fysisk forberede og materialisere data, før Power BI spør etter dem. Et relasjonsdatalager er et utmerket eksempel på klargjorte data, som vanligvis består av forhåndsintegrerte kilder til organisasjonsdata.

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