Vägledning för frågedelegering i Power BI Desktop

  • Artikel

Den här artikeln riktar sig till datamodellerare som utvecklar modeller i Power BI Desktop. Det ger bästa praxis vägledning om när – och hur – du kan uppnå Power Query-frågedelegering.

Frågedelegering är möjligheten för en Power Query-fråga att generera en enda frågeuttryck som hämtar och transformerar källdata. Mer information finns i Power Query-frågedelegering.

Vägledning

Vägledningen för frågedelegering skiljer sig åt beroende på modellläget.

För en DirectQuery - eller tabell med dubbelt lagringsläge måste Power Query-frågan uppnå frågedelegering.

För en importtabell kan det vara möjligt att uppnå frågedelegering. När frågan baseras på en relationskälla – och om en enskild SELECT-instruktion kan konstrueras – får du bästa prestanda för datauppdatering genom att se till att frågedelegering sker. Om Power Query-kombinationsmotorn fortfarande krävs för att bearbeta transformeringar bör du sträva efter att minimera det arbete den behöver utföra, särskilt för stora semantiska modeller (tidigare kallade datauppsättningar).

Följande punktlista innehåller specifik vägledning.

  • Delegera så mycket bearbetning som möjligt till datakällan: När alla steg i en Power Query-fråga inte kan vikas identifierar du det steg som förhindrar frågedelegering. När det är möjligt kan du flytta senare steg tidigare i sekvens så att de kan vägas in i frågedelegeringen. Observera att Power Query-kombinationsmotorn kan vara smart nog att ändra ordning på frågestegen när den genererar källfrågan.

    För en relationsdatakälla, om steget som förhindrar frågedelegering kan uppnås i en enda SELECT-instruktion – eller inom proceduren för en lagrad procedur – bör du överväga att använda en intern SQL-fråga enligt beskrivningen härnäst.

  • Använd en intern SQL-fråga: När en Power Query-fråga hämtar data från en relationskälla är det möjligt för vissa källor att använda en intern SQL-fråga. Frågan kan i själva verket vara vilken giltig instruktion som helst, inklusive en lagrad procedurkörning. Om instruktionen genererar flera resultatuppsättningar returneras endast den första. Parametrar kan deklareras i -instruktionen och vi rekommenderar att du använder funktionen Value.NativeQuery M. Den här funktionen har utformats för att på ett säkert och bekvämt sätt skicka parametervärden. Det är viktigt att förstå att Power Query-kombinationsmotorn inte kan vika senare frågesteg, och därför bör du inkludera all– eller lika mycket – transformeringslogik i den interna frågeinstruktionen.

    Det finns två viktiga saker du måste tänka på när du använder interna SQL-frågor:

    • För en DirectQuery-modelltabell måste frågan vara en SELECT-instruktion och den kan inte använda Common Table Expressions (CTE) eller en lagrad procedur.
    • Inkrementell uppdatering kan inte använda en intern SQL-fråga. Det skulle därför tvinga Power Query-kombinationsmotorn att hämta alla källrader och sedan använda filter för att fastställa inkrementella ändringar.

    Viktigt!

    En intern SQL-fråga kan potentiellt göra mer än att hämta data. Alla giltiga instruktioner kan köras (och eventuellt flera gånger), inklusive en som ändrar eller tar bort data. Det är viktigt att du tillämpar principen om minsta behörighet för att säkerställa att kontot som används för att komma åt databasen endast har läsbehörighet för nödvändiga data.

  • Förbereda och transformera data i källan: När du identifierar att vissa Power Query-frågesteg inte kan vikas kan det vara möjligt att tillämpa transformeringarna i datakällan. Omvandlingarna kan uppnås genom att skriva en databasvy som logiskt transformerar källdata. Eller genom att fysiskt förbereda och materialisera data innan Power BI kör frågor mot dem. Ett relationsdatalager är ett utmärkt exempel på förberedda data, som vanligtvis består av förintegrerade källor till organisationsdata.

Relaterat innehåll

Mer information om den här artikeln finns i följande resurser: