Vägledning för Power BI-modellering för Power Platform
Microsoft Dataverse är standarddataplattformen för många Microsoft-företagsprogramprodukter, inklusive Dynamics 365 Customer Engagement - och Power Apps-arbetsyteappar, och även Dynamics 365 Customer Voice (tidigare Microsoft Forms Pro), Power Automate-godkännanden, Power Apps-portaler och andra.
Den här artikeln innehåller vägledning om hur du skapar en Power BI-datamodell som ansluter till Dataverse. Den beskriver skillnader mellan ett Dataverse-schema och ett optimerat Power BI-schema och ger vägledning för att utöka synligheten för dina affärsprogramdata i Power BI.
På grund av den enkla installationen, snabb distributionen och den omfattande implementeringen lagrar och hanterar Dataverse en ökande mängd data i miljöer i organisationer. Det innebär att det finns ett ännu större behov – och möjlighet – att integrera analys med dessa processer. Affärsmöjligheter är:
- Rapportera om alla Dataverse-data som går utöver begränsningarna i de inbyggda diagrammen.
- Ge enkel åtkomst till relevanta, sammanhangsberoende filtrerade rapporter i en specifik post.
- Förbättra värdet för Dataverse-data genom att integrera dem med externa data.
- Dra nytta av Power BI:s inbyggda artificiell intelligens (AI) utan att behöva skriva komplex kod.
- Öka implementeringen av Power Platform-lösningar genom att öka deras användbarhet och värde.
- Leverera värdet för data i din app till beslutsfattare inom företaget.
Ansluta Power BI till Dataverse
Att ansluta Power BI till Dataverse innebär att skapa en Power BI-datamodell. Du kan välja mellan tre metoder för att skapa en Power BI-modell.
- Importera Dataverse-data med hjälp av Dataverse-anslutningsappen: Den här metoden cachelagrar (lagrar) Dataverse-data i en Power BI-modell. Det ger snabba prestanda tack vare minnesintern frågekörning. Det ger också designflex flexibilitet för modellerare, så att de kan integrera data från andra källor. På grund av dessa styrkor är import av data standardläget när du skapar en modell i Power BI Desktop.
- Importera Dataverse-data med hjälp av Azure Synapse Link: Den här metoden är en variant av importmetoden, eftersom den även cachelagrar data i Power BI-modellen, men gör det genom att ansluta till Azure Synapse Analytics. Genom att använda Azure Synapse Link för Dataverse replikeras Dataverse-tabeller kontinuerligt till Azure Synapse eller Azure Data Lake Storage (ADLS) Gen2. Den här metoden används för att rapportera hundratusentals eller till och med miljontals poster i Dataverse-miljöer.
- Skapa en DirectQuery-anslutning med hjälp av Dataverse-anslutningsappen: Den här metoden är ett alternativ till att importera data. En DirectQuery-modell består endast av metadata som definierar modellstrukturen. När en användare öppnar en rapport skickar Power BI inbyggda frågor till Dataverse för att hämta data. Överväg att skapa en DirectQuery-modell när rapporter måste visa data i nära realtid, eller när Dataverse måste framtvinga rollbaserad säkerhet så att användarna bara kan se de data som de har behörighet att komma åt.
Viktigt!
Även om en DirectQuery-modell kan vara ett bra alternativ när du behöver rapportering i nära realtid eller tillämpning av Dataverse-säkerhet i en rapport, kan det leda till långsamma prestanda för rapporten.
Du kan lära dig mer om överväganden för DirectQuery senare i den här artikeln.
Du bör överväga följande för att fastställa rätt metod för din Power BI-modell:
- Frågeprestanda
- Datavolym
- Datasvarstid
- Rollbaserad säkerhet
- Konfigurationskomplexitet
Dricks
En detaljerad diskussion om modellramverk (import, DirectQuery eller sammansatt), deras fördelar och begränsningar samt funktioner för att optimera Power BI-datamodeller finns i Välj ett Power BI-modellramverk.
Frågeprestanda
Frågor som skickas till importmodeller är snabbare än interna frågor som skickas till DirectQuery-datakällor. Det beror på att importerade data cachelagras i minnet och är optimerade för analysfrågor (filter, grupp och sammanfattande åtgärder).
Omvänt hämtar DirectQuery-modeller endast data från källan när användaren öppnar en rapport, vilket resulterar i sekunder av fördröjning när rapporten återges. Dessutom kräver användarinteraktioner i rapporten att Power BI begär källan igen, vilket ytterligare minskar svarstiden.
Datavolym
När du utvecklar en importmodell bör du sträva efter att minimera de data som läses in i modellen. Det gäller särskilt för stora modeller eller modeller som du förväntar dig kommer att bli stora med tiden. Mer information finns i Datareduktionstekniker för importmodellering.
En DirectQuery-anslutning till Dataverse är ett bra val när rapportens frågeresultat inte är stort. Ett stort frågeresultat har fler än 20 000 rader i rapportens källtabeller, eller så returneras resultatet till rapporten efter att filter har tillämpats på mer än 20 000 rader. I det här fallet kan du skapa en Power BI-rapport med hjälp av Dataverse-anslutningsappen.
Kommentar
Radstorleken på 20 000 är inte en hård gräns. Varje datakällfråga måste dock returnera ett resultat inom 10 minuter. Senare i den här artikeln får du lära dig hur du arbetar inom dessa begränsningar och om andra designöverväganden för Dataverse DirectQuery.
Du kan förbättra prestandan för större semantiska modeller med hjälp av Dataverse-anslutningsappen för att importera data till datamodellen.
Ännu större semantiska modeller – med flera hundra tusen eller till och med miljontals rader – kan dra nytta av att använda Azure Synapse Link för Dataverse. Den här metoden konfigurerar en pågående hanterad pipeline som kopierar Dataverse-data till ADLS Gen2 som CSV- eller Parquet-filer. Power BI kan sedan köra frågor mot en serverlös SQL-pool i Azure Synapse för att läsa in en importmodell.
Datasvarstid
När Dataverse-data ändras snabbt och rapportanvändarna behöver se aktuella data kan en DirectQuery-modell leverera frågeresultat i nästan realtid.
Dricks
Du kan skapa en Power BI-rapport som använder automatisk siduppdatering för att visa realtidsuppdateringar, men bara när rapporten ansluter till en DirectQuery-modell.
Importdatamodeller måste slutföra en datauppdatering för att tillåta rapportering om de senaste dataändringarna. Tänk på att det finns begränsningar för antalet dagliga schemalagda datauppdateringsåtgärder. Du kan schemalägga upp till åtta uppdateringar per dag på en delad kapacitet. På en Premium-kapacitet eller Microsoft Fabric-kapacitet kan du schemalägga upp till 48 uppdateringar per dag, vilket kan ge en uppdateringsfrekvens på 15 minuter.
Viktigt!
Ibland refererar den här artikeln till Power BI Premium eller dess kapacitetsprenumerationer (P SKU:er). Tänk på att Microsoft för närvarande konsoliderar köpalternativ och drar tillbaka Power BI Premium per kapacitets-SKU:er. Nya och befintliga kunder bör överväga att köpa kapacitetsprenumerationer för Infrastrukturresurser (F SKU:er) i stället.
Mer information finns i Viktig uppdatering som kommer till Power BI Premium-licensiering och Vanliga frågor och svar om Power BI Premium.
Du kan också överväga att använda inkrementell uppdatering för att uppnå snabbare uppdateringar och prestanda i nära realtid (endast tillgängligt med Premium eller Fabric).
Rollbaserad säkerhet
När det finns ett behov av att framtvinga rollbaserad säkerhet kan det direkt påverka valet av Power BI-modellramverk.
Dataverse kan framtvinga komplex rollbaserad säkerhet för att styra åtkomsten av specifika poster till specifika användare. En säljare kan till exempel bara se sina försäljningsmöjligheter, medan försäljningschefen kan se alla försäljningsmöjligheter för alla säljare. Du kan skräddarsy komplexitetsnivån baserat på organisationens behov.
En DirectQuery-modell baserad på Dataverse kan ansluta med hjälp av rapportanvändarens säkerhetskontext. På så sätt ser rapportanvändaren endast de data som de har åtkomst till. Den här metoden kan förenkla rapportdesignen, förutsatt att prestanda är acceptabel.
För bättre prestanda kan du skapa en importmodell som ansluter till Dataverse i stället. I det här fallet kan du lägga till säkerhet på radnivå (RLS) i modellen om det behövs.
Kommentar
Det kan vara svårt att replikera viss rollbaserad säkerhet i Dataverse som Power BI RLS, särskilt när Dataverse tillämpar komplexa behörigheter. Dessutom kan det kräva löpande hantering för att hålla Power BI-behörigheter synkroniserade med Dataverse-behörigheter.
Mer information om Power BI RLS finns i Vägledning för säkerhet på radnivå (RLS) i Power BI Desktop.
Konfigurationskomplexitet
Att använda Dataverse-anslutningsappen i Power BI – oavsett om det gäller import- eller DirectQuery-modeller – är enkelt och kräver inte någon särskild programvara eller utökade Dataverse-behörigheter. Det är en fördel för organisationer eller avdelningar som kommer igång.
Alternativet Azure Synapse Link kräver systemadministratörsåtkomst till Dataverse och vissa Azure-behörigheter. Dessa Azure-behörigheter krävs för att konfigurera lagringskontot och en Synapse-arbetsyta.
Rekommenderade metoder
I det här avsnittet beskrivs designmönster (och antimönster) som du bör överväga när du skapar en Power BI-modell som ansluter till Dataverse. Endast ett fåtal av dessa mönster är unika för Dataverse, men de tenderar att vara vanliga utmaningar för Dataverse-tillverkare när de skapar Power BI-rapporter.
Fokusera på ett specifikt användningsfall
Fokusera på det specifika användningsfallet i stället för att försöka lösa allt.
Den här rekommendationen är förmodligen den vanligaste och enklaste antimönstret att undvika. Det är svårt att skapa en enda modell som uppnår alla rapporteringsbehov med självbetjäning. Verkligheten är att framgångsrika modeller är byggda för att besvara frågor kring en central uppsättning fakta över ett enda kärnämne. Även om det kanske till en början verkar begränsa modellen är det faktiskt stärkande eftersom du kan finjustera och optimera modellen för att besvara frågor inom det ämnet.
För att säkerställa att du har en tydlig förståelse för modellens syfte kan du ställa dig själv följande frågor.
- Vilket ämnesområde kommer den här modellen att stödja?
- Vem är målgruppen för rapporterna?
- Vilka frågor försöker rapporterna besvara?
- Vilken är den minsta livskraftiga semantiska modellen?
Motstå att kombinera flera ämnesområden i en enda modell bara för att rapportanvändaren har frågor inom flera ämnesområden som de vill att en enskild rapport ska behandla. Genom att dela upp rapporten i flera rapporter, var och en med fokus på ett annat ämne (eller faktatabell), kan du skapa mycket mer effektiva, skalbara och hanterbara modeller.
Utforma ett stjärnschema
Dataverse-utvecklare och administratörer som är bekväma med Dataverse-schemat kan frestas att återskapa samma schema i Power BI. Den här metoden är ett antimönster, och det är förmodligen det svåraste att övervinna eftersom det bara känns rätt att upprätthålla konsekvens.
Dataversum, som en relationsmodell, lämpar sig väl för sitt syfte. Den är dock inte utformad som en analysmodell som är optimerad för analysrapporter. Det vanligaste mönstret för modellering av analysdata är en star-schemadesign . Star-schema är en mogen modelleringsmetod som används i stor utsträckning av relationsdatalager. Det kräver att modellerare klassificerar sina modelltabeller som antingen dimension eller fakta. Rapporter kan filtrera eller gruppera med hjälp av dimensionstabellkolumner och sammanfatta faktatabellkolumner.
Mer information finns i Förstå star-schema och vikten för Power BI.
Optimera Power Query-frågor
Power Query-kombinationsmotorn strävar efter att uppnå frågedelegering när det är möjligt av effektivitetsskäl. En fråga som uppnår vikning delegerar frågebearbetning till källsystemet.
Källsystemet, i det här fallet Dataverse, behöver bara leverera filtrerade eller sammanfattade resultat till Power BI. En vikt fråga är ofta betydligt snabbare och effektivare än en fråga som inte viks.
Mer information om hur du kan uppnå frågedelegering finns i Power Query-frågedelegering.
Kommentar
Att optimera Power Query är ett brett ämne. Information om vad Power Query gör vid redigering och vid modelluppdatering i Power BI Desktop finns i Frågediagnostik.
Minimera antalet frågekolumner
När du använder Power Query för att läsa in en Dataverse-tabell hämtas alla rader och alla kolumner som standard. När du till exempel kör frågor mot en systemanvändartabell kan den innehålla mer än 1 000 kolumner. Kolumnerna i metadata inkluderar relationer till andra entiteter och sökningar till alternativetiketter, så det totala antalet kolumner växer med dataversumtabellens komplexitet.
Att försöka hämta data från alla kolumner är ett antimönster. Det resulterar ofta i utökade datauppdateringsåtgärder, och det gör att frågan misslyckas när den tid som krävs för att returnera data överskrider 10 minuter.
Vi rekommenderar att du bara hämtar kolumner som krävs av rapporter. Det är ofta en bra idé att omvärdera och omstrukturera frågor när rapportutvecklingen är klar, så att du kan identifiera och ta bort oanvända kolumner. Mer information finns i Datareduktionstekniker för importmodellering (Ta bort onödiga kolumner).
Se dessutom till att du introducerar Power Query Remove-kolumnerna tidigt så att de viks tillbaka till källan. På så sätt kan Power Query undvika onödigt arbete med att extrahera källdata bara för att ta bort dem senare (i ett utvecklat steg).
När du har en tabell som innehåller många kolumner kan det vara opraktiskt att använda power query-frågeverktyget. I det här fallet kan du börja med att skapa en tom fråga. Du kan sedan använda Avancerad redigerare för att klistra in en minimal fråga som skapar en startpunkt.
Tänk på följande fråga som hämtar data från bara två kolumner i kontotabellen.
let
Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false]),
dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
#"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name"})
in
#"Removed Other Columns"
Skriva interna frågor
När du har specifika omvandlingskrav kan du uppnå bättre prestanda med hjälp av en intern fråga som skrivits i Dataverse SQL, som är en delmängd av Transact-SQL. Du kan skriva en intern fråga till:
- Minska antalet rader (med hjälp av en
WHERE
sats). - Aggregera data (med hjälp av satserna
GROUP BY
ochHAVING
). - Koppla tabeller på ett specifikt sätt (med hjälp av syntaxen
JOIN
ellerAPPLY
). - Använd SQL-funktioner som stöds.
Mer information finns i:
Köra interna frågor med alternativet EnableFolding
Power Query kör en intern fråga med hjälp Value.NativeQuery
av funktionen .
När du använder den här funktionen är det viktigt att lägga EnableFolding=true
till alternativet för att säkerställa att frågor viks tillbaka till Dataverse-tjänsten. En intern fråga viks inte om inte det här alternativet läggs till. Om du aktiverar det här alternativet kan det leda till betydande prestandaförbättringar – upp till 97 procent snabbare i vissa fall.
Tänk på följande fråga som använder en intern fråga för att hämta valda kolumner från kontotabellen. Den inbyggda frågan viks eftersom alternativet EnableFolding=true
har angetts.
let
Source = CommonDataService.Database("demo.crm.dynamics.com"),
dbo_account = Value.NativeQuery(
Source,
"SELECT A.accountid, A.name FROM account A"
,null
,[EnableFolding=true]
)
in
dbo_account
Du kan förvänta dig att uppnå de största prestandaförbättringarna när du hämtar en delmängd data från en stor datavolym.
Dricks
Prestandaförbättringar kan också bero på hur Power BI frågar källdatabasen. Ett mått som använder COUNTDISTINCT
DAX-funktionen visade till exempel nästan ingen förbättring med eller utan vikningstipset. När måttformeln skrevs om för att använda SUMX
DAX-funktionen, gav frågan en förbättring på 97 procent jämfört med samma fråga utan tipset.
Mer information finns i Value.NativeQuery. (Alternativet EnableFolding
är inte dokumenterat eftersom det bara gäller vissa datakällor.)
Påskynda utvärderingssteget
Om du använder Dataverse-anslutningsappen (kallades tidigare Common Data Service) kan du lägga till CreateNavigationProperties=false
alternativet för att påskynda utvärderingssteget för en dataimport.
Utvärderingssteget för en dataimport itererar via källans metadata för att fastställa alla möjliga tabellrelationer. Dessa metadata kan vara omfattande, särskilt för Dataverse. Genom att lägga till det här alternativet i frågan meddelar du Power Query att du inte tänker använda dessa relationer. Med alternativet kan Power BI Desktop hoppa över den fasen av uppdateringen och gå vidare till att hämta data.
Kommentar
Använd inte det här alternativet när frågan är beroende av expanderade relationskolumner.
Tänk dig ett exempel som hämtar data från kontotabellen. Den innehåller tre kolumner som är relaterade till område: område, områdeid och områdeidnamn.
När du anger CreateNavigationProperties=false
alternativet förblir kolumnerna territoryid och territoryidname kvar, men områdeskolumnen, som är en relationskolumn (den visar värdelänkar), undantas. Det är viktigt att förstå att Power Query-relationskolumner är ett annat begrepp än modellrelationer, som sprider filter mellan modelltabeller.
Tänk på följande fråga som använder CreateNavigationProperties=false
alternativet (i källsteget) för att påskynda utvärderingssteget för en dataimport.
let
Source = CommonDataService.Database("demo.crm.dynamics.com"
,[CreateNavigationProperties=false]),
dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
#"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name", "address1_stateorprovince", "address1_country", "industrycodename", "territoryidname"}),
#"Renamed Columns" = Table.RenameColumns(#"Removed Other Columns", {{"name", "Account Name"}, {"address1_country", "Country"}, {"address1_stateorprovince", "State or Province"}, {"territoryidname", "Territory"}, {"industrycodename", "Industry"}})
in
#"Renamed Columns"
När du använder det här alternativet kommer du förmodligen att uppleva betydande prestandaförbättringar när en Dataverse-tabell har många relationer till andra tabeller. Eftersom tabellen SystemUser till exempel är relaterad till alla andra tabeller i databasen, skulle uppdateringsprestanda för den här tabellen ha nytta av att ange alternativetCreateNavigationProperties=false
.
Kommentar
Det här alternativet kan förbättra prestandan för datauppdatering av importtabeller eller tabeller med dubbla lagringslägen, inklusive processen för att tillämpa Power Query-redigeraren fönsterändringar. Det förbättrar inte prestandan för interaktiv korsfiltrering av DirectQuery-lagringslägestabeller.
Lösa tomma valetiketter
Om du upptäcker att Dataverse-valetiketter är tomma i Power BI kan det bero på att etiketterna inte har publicerats till TDS-slutpunkten (Tabular Data Stream).
I det här fallet öppnar du Dataverse Maker-portalen, navigerar till området Lösningar och väljer sedan Publicera alla anpassningar. Publiceringsprocessen uppdaterar TDS-slutpunkten med de senaste metadata, vilket gör alternativetiketterna tillgängliga för Power BI.
Större semantiska modeller med Azure Synapse Link
Dataverse omfattar möjligheten att synkronisera tabeller till Azure Data Lake Storage (ADLS) och sedan ansluta till dessa data via en Azure Synapse-arbetsyta. Med minimal ansträngning kan du konfigurera Azure Synapse Link för att fylla i Dataverse-data i Azure Synapse och göra det möjligt för datateam att upptäcka djupare insikter.
Azure Synapse Link möjliggör kontinuerlig replikering av data och metadata från Dataverse till datasjön. Den innehåller också en inbyggd serverlös SQL-pool som en praktisk datakälla för Power BI-frågor.
Fördelarna med detta tillvägagångssätt är betydande. Kunder får möjlighet att köra arbetsbelastningar för analys, business intelligence och maskininlärning i Dataverse-data med hjälp av olika avancerade tjänster. Avancerade tjänster omfattar Apache Spark, Power BI, Azure Data Factory, Azure Databricks och Azure Machine Learning.
Skapa en Azure Synapse Link för Dataverse
Om du vill skapa en Azure Synapse Link för Dataverse behöver du följande krav på plats.
- Systemadministratörsåtkomst till Dataverse-miljön.
- För Azure Data Lake Storage:
- Du måste ha ett lagringskonto att använda med ADLS Gen2.
- Du måste tilldelas åtkomst till lagringsblobdataägare och lagringsblobdatadeltagare till lagringskontot. Mer information finns i Rollbaserad åtkomstkontroll (Azure RBAC).
- Lagringskontot måste aktivera hierarkiskt namnområde.
- Vi rekommenderar att lagringskontot använder geo-redundant lagring med läsbehörighet (RA-GRS).
- För Synapse-arbetsytan:
- Du måste ha åtkomst till en Synapse-arbetsyta och tilldelas Åtkomst till Synapse-administratör . Mer information finns i Inbyggda Roll- och omfång för Synapse RBAC.
- Arbetsytan måste finnas i samma region som ADLS Gen2-lagringskontot.
Konfigurationen omfattar inloggning till Power Apps och anslutning av Dataverse till Azure Synapse-arbetsytan. Med en guideliknande upplevelse kan du skapa en ny länk genom att välja lagringskontot och tabellerna som ska exporteras. Azure Synapse Link kopierar sedan data till ADLS Gen2-lagringen och skapar automatiskt vyer i den inbyggda Serverlösa SQL-poolen i Azure Synapse. Du kan sedan ansluta till dessa vyer för att skapa en Power BI-modell.
Dricks
Fullständig dokumentation om hur du skapar, hanterar och övervakar Azure Synapse Link finns i Skapa en Azure Synapse Link för Dataverse med din Azure Synapse-arbetsyta.
Skapa en andra serverlös SQL-databas
Du kan skapa en andra serverlös SQL-databas och använda den för att lägga till anpassade rapportvyer. På så sätt kan du presentera en förenklad uppsättning data för Power BI-skaparen som gör att de kan skapa en modell baserat på användbara och relevanta data. Den nya serverlösa SQL-databasen blir skaparens primära källanslutning och en vänlig representation av data som kommer från datasjön.
Den här metoden levererar data till Power BI som är fokuserad, berikad och filtrerad.
Du kan skapa en serverlös SQL-databas på Azure Synapse-arbetsytan med hjälp av Azure Synapse Studio. Välj Serverlös som SQL-databastyp och ange ett databasnamn. Power Query kan ansluta till den här databasen genom att ansluta till SQL-slutpunkten för arbetsytan.
Skapa anpassade vyer
Du kan skapa anpassade vyer som omsluter serverlösa SQL-poolfrågor. Dessa vyer fungerar som enkla, rena datakällor som Power BI ansluter till. Vyerna bör:
- Ta med etiketterna som är associerade med valfält.
- Minska komplexiteten genom att endast inkludera de kolumner som krävs för datamodellering.
- Filtrera bort onödiga rader, till exempel inaktiva poster.
Tänk på följande vy som hämtar kampanjdata.
CREATE VIEW [VW_Campaign]
AS
SELECT
[base].[campaignid] AS [CampaignID]
[base].[name] AS [Campaign],
[campaign_status].[LocalizedLabel] AS [Status],
[campaign_typecode].[LocalizedLabel] AS [Type Code]
FROM
[<MySynapseLinkDB>].[dbo].[campaign] AS [base]
LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[OptionsetMetadata] AS [campaign_typecode]
ON [base].[typecode] = [campaign_typecode].[option]
AND [campaign_typecode].[LocalizedLabelLanguageCode] = 1033
AND [campaign_typecode].[EntityName] = 'campaign'
AND [campaign_typecode].[OptionSetName] = 'typecode'
LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[StatusMetadata] AS [campaign_status]
ON [base].[statuscode] = [campaign_Status].[status]
AND [campaign_status].[LocalizedLabelLanguageCode] = 1033
AND [campaign_status].[EntityName] = 'campaign'
WHERE
[base].[statecode] = 0;
Observera att vyn endast innehåller fyra kolumner, var och en alias med ett eget namn. Det finns också en WHERE
sats för att endast returnera nödvändiga rader, i det här fallet aktiva kampanjer. Vyn frågar också kampanjtabellen som är kopplad till tabellerna OptionsetMetadata och StatusMetadata , som hämtar valetiketter.
Dricks
Mer information om hur du hämtar metadata finns i Åtkomstvalsetiketter direkt från Azure Synapse Link för Dataverse.
Fråga efter lämpliga tabeller
Azure Synapse Link for Dataverse säkerställer att data synkroniseras kontinuerligt med data i datasjön. För aktivitet med hög användning kan samtidiga skrivningar och läsningar skapa lås som gör att frågor misslyckas. För att säkerställa tillförlitlighet vid hämtning av data synkroniseras två versioner av tabelldata i Azure Synapse.
- Data i nära realtid: Tillhandahåller en kopia av data som synkroniserats från Dataverse via Azure Synapse Link på ett effektivt sätt genom att identifiera vilka data som har ändrats sedan de ursprungligen extraherades eller senast synkroniserades.
- Ögonblicksbildsdata: Ger en skrivskyddad kopia av nästan realtidsdata som uppdateras med jämna mellanrum (i det här fallet varje timme). Namn på ögonblicksbilddatatabeller har _partitioned läggs till i deras namn.
Om du förväntar dig att en stor mängd läs- och skrivåtgärder körs samtidigt hämtar du data från tabellerna för ögonblicksbilder för att undvika frågefel.
Mer information finns i avsnittet Få åtkomst till data nästan i realtid och skrivskyddade ögonblicksbildsdata.
Ansluta till Synapse Analytics
Om du vill köra frågor mot en serverlös SQL-pool i Azure Synapse behöver du dess SQL-slutpunkt för arbetsytan. Du kan hämta slutpunkten från Synapse Studio genom att öppna egenskaperna för den serverlösa SQL-poolen.
I Power BI Desktop kan du ansluta till Azure Synapse med hjälp av SQL-anslutningsappen för Azure Synapse Analytics. När du uppmanas att ange servern anger du SQL-slutpunkten för arbetsytan.
Överväganden för DirectQuery
Det finns många användningsfall när du använder DirectQuery-lagringsläge kan lösa dina krav. Att använda DirectQuery kan dock påverka Prestanda för Power BI-rapporter negativt. En rapport som använder en DirectQuery-anslutning till Dataverse kommer inte att vara lika snabb som en rapport som använder en importmodell. I allmänhet bör du importera data till Power BI när det är möjligt.
Vi rekommenderar att du överväger ämnena i det här avsnittet när du arbetar med DirectQuery.
Mer information om hur du avgör när du ska arbeta med DirectQuery-lagringsläge finns i Välj ett Power BI-modellramverk.
Använda dimensionstabeller med dubbla lagringslägen
En tabell med dubbelt lagringsläge är inställd på att använda både import- och DirectQuery-lagringslägen. Vid frågetillfället avgör Power BI det mest effektiva läge som ska användas. När det är möjligt försöker Power BI uppfylla frågor med hjälp av importerade data eftersom det går snabbare.
Du bör överväga att ställa in dimensionstabeller i dubbelt lagringsläge när det är lämpligt. På så sätt renderas utsnittsvisualiseringar och filterkortlistor – som ofta baseras på dimensionstabellkolumner – snabbare eftersom de efterfrågas från importerade data.
Viktigt!
När en dimensionstabell behöver ärva Dataverse-säkerhetsmodellen är det inte lämpligt att använda dubbelt lagringsläge.
Faktatabeller, som vanligtvis lagrar stora mängder data, bör förbli som DirectQuery-lagringslägestabeller. De filtreras efter de relaterade dimensionstabellerna för dubbelt lagringsläge, som kan kopplas till faktatabellen för att uppnå effektiv filtrering och gruppering.
Överväg följande design av datamodeller. Tre dimensionstabeller, Ägare, Konto och Kampanj , har en randig övre kantlinje, vilket innebär att de är inställda på dubbelt lagringsläge.
Mer information om lagringslägen för tabeller, inklusive dubbla lagringslägen, finns i Hantera lagringsläge i Power BI Desktop.
Aktivera enkel inloggning
När du publicerar en DirectQuery-modell till Power BI-tjänst kan du använda de semantiska modellinställningarna för att aktivera enkel inloggning (SSO) med hjälp av Microsoft Entra ID OAuth2 för dina rapportanvändare. Du bör aktivera det här alternativet när Dataverse-frågor måste köras i rapportanvändarens säkerhetskontext.
När alternativet enkel inloggning är aktiverat skickar Power BI rapportanvändarens autentiserade Microsoft Entra-autentiseringsuppgifter i frågorna till Dataverse. Med det här alternativet kan Power BI uppfylla de säkerhetsinställningar som har konfigurerats i datakällan.
Mer information finns i Enkel inloggning (SSO) för DirectQuery-källor.
Replikera "Mina" filter i Power Query
När du använder Microsoft Dynamics 365 Customer Engagement (CE) och modelldrivna Power Apps som bygger på Dataverse kan du skapa vyer som endast visar poster där ett användarnamnsfält, till exempel Ägare, är lika med den aktuella användaren. Du kan till exempel skapa vyer med namnet "Mina öppna affärsmöjligheter", "Mina aktiva ärenden" och andra.
Tänk dig ett exempel på hur vyn Dynamics 365 Mina aktiva konton innehåller ett filter där Ägaren är lika med den aktuella användaren.
Du kan återskapa det här resultatet i Power Query med hjälp av en intern fråga som bäddar CURRENT_USER
in token.
Tänk dig följande exempel som visar en intern fråga som returnerar kontona för den aktuella användaren. WHERE
Observera att kolumnen ownerid filtreras av CURRENT_USER
token i -satsen.
let
Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false],
dbo_account = Value.NativeQuery(Source, "
SELECT
accountid, accountnumber, ownerid, address1_city, address1_stateorprovince, address1_country
FROM account
WHERE statecode = 0
AND ownerid = CURRENT_USER
", null, [EnableFolding]=true])
in
dbo_account
När du publicerar modellen till Power BI-tjänst måste du aktivera enkel inloggning (SSO) så att Power BI skickar rapportanvändarens autentiserade Microsoft Entra-autentiseringsuppgifter till Dataverse.
Skapa kompletterande importmodeller
Du kan skapa en DirectQuery-modell som framtvingar Dataverse-behörigheter med vetskapen om att prestandan blir långsam. Du kan sedan komplettera den här modellen med importmodeller som riktar sig till specifika ämnen eller målgrupper som kan framtvinga RLS-behörigheter.
En importmodell kan till exempel ge åtkomst till alla Dataverse-data men inte framtvinga några behörigheter. Den här modellen passar chefer som redan har åtkomst till alla Dataverse-data.
Som ett annat exempel, när Dataverse tillämpar rollbaserade behörigheter efter försäljningsregion, kan du skapa en importmodell och replikera dessa behörigheter med hjälp av RLS. Du kan också skapa en modell för varje försäljningsregion. Du kan sedan bevilja läsbehörighet till dessa modeller (semantiska modeller) till säljarna i varje region. För att underlätta skapandet av dessa regionala modeller kan du använda parametrar och rapportmallar. Mer information finns i Skapa och använda rapportmallar i Power BI Desktop.
Relaterat innehåll
Mer information om den här artikeln finns i följande resurser.