Power BI -mallinnusohjeet Power Platformille

Microsoft Dataverse on vakiotietoalusta monille Microsoftin yrityssovellustuotteille, kuten Dynamics 365 Customer Engagement - ja Power Apps -pohjasovelluksille sekä Dynamics 365 Customer Voicelle (aiemmin Microsoft Forms Pro), Power Automaten hyväksynnöille, Power Apps -portaaleille ja muille.

Tässä artikkelissa annetaan ohjeita siitä, miten voit luoda Power BI -tietomallin, joka muodostaa yhteyden Dataverseen. Siinä kuvataan Dataverse-rakenteen ja optimoidun Power BI -rakenteen väliset erot ja annetaan ohjeita yrityssovellustietojen näkyvyyden laajentamiseen Power BI:ssä.

Käyttöönoton helppouden, nopean käyttöönoton ja laaja-alaisen käyttöönoton vuoksi Dataverse tallentaa ja hallitsee kasvavaa tietomäärää organisaatioissa. Tämä tarkoittaa, että analytiikan integrointi näihin prosesseihin on vieläkin suurempi tarve ja mahdollisuus. Mahdollisuuksia ovat muun muassa seuraavat:

• Raportti kaikista Dataverse-tiedoista, jotka ylittävät sisäänrakennettujen kaavioiden rajoitukset.
• Tarjoaa helpon pääsyn merkityksellisiin, tilannekohtaisiin suodatettuihin raportteihin tietyssä tietueessa.
• Paranna Dataverse-tietojen arvoa integroimalla ne ulkoisiin tietoihin.
• Hyödynnä Power BI:n sisäistä tekoälyä kirjoittamatta monimutkaista koodia.
• Lisää Power Platform -ratkaisujen käyttöönottoa lisäämällä niiden hyödyllisyyttä ja arvoa.
• Anna sovelluksesi tietojen arvo liiketoiminnan päätöksentekijöille.

Yhdistä Power BI Dataverseen

Power BI:n yhdistäminen Dataverseen edellyttää Power BI -tietomallin luomista. Voit valita kolmesta menetelmästä Power BI -mallin luomiseksi.

• Tuo Dataverse-tietoja Dataverse-liittimen avulla: Tämä menetelmä tallentaa (tallentaa) Dataverse-tiedot Power BI -malliin. Se tarjoaa nopean suorituskyvyn muistissa olevien kyselyiden ansiosta. Mallintajat voivat myös hyödyntää suunnittelun joustavuutta, jolloin he voivat integroida tietoja muista lähteistä. Näiden vahvuuksien vuoksi tietojen tuominen on oletustila, kun mallia luodaan Power BI Desktopissa.
• Tuo Dataverse-tietoja käyttämällä Azure Synapse Link: Tämä menetelmä on muunnelma tuontimenetelmässä, koska se myös tallentaa Power BI -mallin tiedot välimuistiin, mutta se tekee sen yhdistämällä Azure Synapse Analyticsiin. Azure Synapse Link for Dataversen avulla Dataverse-taulukot replikoidaan jatkuvasti Azure Synapse tai Azure Data Lake Storage (ADLS) Gen2:een. Tämän lähestymistavan avulla raportoidaan sadoista tuhansista tai jopa miljoonista dataverse-ympäristöjen tietueista.
• Luo DirectQuery-yhteys Dataverse-liittimen avulla: Tämä menetelmä on vaihtoehto tietojen tuomiseen. DirectQuery-malli koostuu vain metatiedoista, jotka määrittävät mallin rakenteen. Kun käyttäjä avaa raportin, Power BI lähettää alkuperäiset kyselyt Dataverseen tietojen noutamista varten. Harkitse DirectQuery-mallin luomista, kun raporteissa on näytettävä lähes reaaliaikaisia Dataverse-tietoja tai kun Dataversen on valvottava roolipohjaista suojausta niin, että käyttäjät voivat nähdä vain tiedot, joihin heillä on oikeudet.

Tärkeä

Vaikka DirectQuery-malli voi olla hyvä vaihtoehto, kun tarvitset raporttiin lähes reaaliaikaista raportointia tai Dataverse-suojauksen pakottamista, se voi hidastaa raportin suorituskykyä.

Lisätietoja DirectQueryä koskevista seikoista on jäljempänä tässä artikkelissa.

Sinun kannattaa harkita, mikä on oikea menetelmä Power BI -mallillesi:

• Kyselyn suorituskyky
• Tietojen määrä
• Tietojen viive
• Rooliin perustuva turvallisuus
• Asennuksen monimutkaisuus

Vihje

Jos haluat käydä yksityiskohtaista keskustelua mallikehyksistä (tuonti, DirectQuery tai yhdistelmä), niiden eduista ja rajoituksista sekä ominaisuuksista, jotka auttavat Power BI -tietomallien optimoimisessa, lue ohjeartikkeli Power BI -mallikehyksen valitseminen.

Kyselyn suorituskyky

Tuontimalleihin lähetetyt kyselyt ovat nopeampia kuin DirectQuery-tietolähteisiin lähetetyt alkuperäiset kyselyt. Tämä johtuu siitä, että tuodut tiedot tallennetaan välimuistiin ja ne on optimoitu analytiikkakyselyille (suodatus-, ryhmä- ja yhteenvetotoiminnot ).

Sitä vastoin DirectQuery-mallit hakevat tietoja lähteestä vain sen jälkeen, kun käyttäjä avaa raportin. Tämä aiheuttaa sekunteja viiveitä raportin hahmontamisessa. Lisäksi raportin käyttäjien vuorovaikutukset edellyttävät, että Power BI lähettää lähteen uudelleen, mikä vähentää vasteaikaa entisestään.

Tietojen määrä

Kun kehität tuontimallia, pyri minimoimaan malliin ladatut tiedot. Tämä pätee erityisesti suuriin malleihin tai malleihin, joiden odotetaan kasvavan suuriksi ajan myötä. Lisätietoja on artikkelissa Tietojen vähentämisen tekniikat tuonnin mallinnusta varten.

DirectQuery-yhteys Dataverseen on hyvä valinta, kun raportin kyselyn tulos ei ole suuri. Suuren kyselyn tuloksessa on yli 20 000 riviä raportin lähdetaulukoissa, tai raporttiin suodattimien käyttöönoton jälkeen palautettu tulos on yli 20 000 riviä. Tässä tapauksessa voit luoda Power BI -raportin käyttämällä Dataverse-liitintä.

Muistiinpano

20 000 rivin koko ei ole kiinteä. Kunkin tietolähdekyselyn on kuitenkin palautettava tulos 10 minuutin kuluessa. Jäljempänä tässä artikkelissa kerrotaan, miten voit käyttää näitä rajoituksia ja muita Dataverse DirectQuery -suunnittelussa huomioon otettavia seikkoja.

Voit parantaa suurempien semanttisten mallien suorituskykyä tuomalla tiedot tietomalliin Dataverse-liittimellä .

Vielä suuremmat semanttiset mallit – joissa on useita satoja tai jopa miljoonia rivejä – voivat hyötyä Azure Synapse Link for Dataversen käytöstä. Tämä lähestymistapa määrittää jatkuvan hallitun putken, joka kopioi Dataverse-tiedot ADLS Gen2:ksi CSV- tai Parquet-tiedostoiksi. Power BI voi sitten tehdä kyselyn Azure Synapse palvelimettomassa SQL-varannossa tuontimallin lataamiseksi.

Tietojen viive

Kun Dataverse-tiedot muuttuvat nopeasti ja raportin käyttäjien on nähtävä ajantasaiset tiedot, DirectQuery-malli voi tuottaa lähes reaaliaikaisia kyselytuloksia.

Vihje

Voit luoda Power BI -raportin, joka käyttää automaattista sivun päivitystä reaaliaikaisten päivitysten näyttämiseen, mutta vain kun raportti muodostaa yhteyden DirectQuery-malliin.

Tuontitietomallien on suoritettava tietojen päivitys, jotta viimeisimpien tietojen muutoksista ilmoittaminen on mahdollista. Huomaa, että päivittäisten ajoitettujen tietojen päivitystoimintojen määrällä on rajoituksia. Voit ajoittaa enintään kahdeksan päivitystä päivässä jaetulle kapasiteetille. Premium- tai Microsoft Fabric -kapasiteetissa voit ajoittaa jopa 48 päivitystä päivässä, jolloin päivitysväli voi olla 15 minuuttia.

Tärkeä

Joskus tämä artikkeli viittaa Power BI Premiumiin tai sen kapasiteettitilauksiin (P-varastointiyksiköt). Ota huomioon, että Microsoft vahvistaa parhaillaan ostovaihtoehtoja ja poistaa käytöstä Kapasiteettikohtaisen Power BI Premiumin. Uusien ja nykyisten asiakkaiden kannattaa harkita Fabric-kapasiteettitilausten (F-varastointiyksiköiden) ostamista.

Lisätietoja on artikkelissa Power BI Premium -käyttöoikeuksien tärkeä päivitys ja Power BI Premiumin usein kysytyt kysymykset.

Voit myös harkita lisäävän päivityksen käyttämistä päivitysten nopeuttamiseksi ja lähes reaaliaikaisen suorituskyvyn saavuttamiseksi (saatavilla vain Premiumilla tai Fabricilla).

Rooliin perustuva turvallisuus

Kun roolipohjainen suojaus on tarpeen, se voi vaikuttaa suoraan Power BI -mallikehyksen valintaan.

Dataverse voi pakottaa monitasoisen roolipohjaisen suojauksen tiettyjen tietueiden käytön valvomiseksi tietyille käyttäjille. Esimerkiksi myyjä voi nähdä vain myyntimahdollisuutensa, kun taas myyntipäällikkö voi nähdä kaikki myyntimahdollisuudet kaikille myyjille. Voit räätälöidä monimutkaisuutta organisaatiosi tarpeiden mukaan.

Dataverseen perustuva DirectQuery-malli voi muodostaa yhteyden käyttämällä raportin käyttäjän suojauskontekstia. Näin raportin käyttäjä näkee vain tiedot, joihin hänellä on lupa käyttää. Tämä lähestymistapa voi yksinkertaistaa raportin suunnittelua, kunhan suorituskyky on hyväksyttävää.

Jos haluat parantaa suorituskykyä, voit luoda tuontimallin, joka muodostaa sen sijaan yhteyden Dataverseen. Tässä tapauksessa voit lisätä malliin rivitason suojauksen (RLS ).

Muistiinpano

Joidenkin roolipohjaisten Dataverse-suojausten replikoiminen Power BI:n rivitason suojauksena voi olla haastavaa, etenkin silloin, kun Dataverse pakottaa monimutkaiset käyttöoikeudet. Lisäksi se saattaa edellyttää jatkuvaa hallintaa, jotta Power BI -käyttöoikeudet pysyvät synkronoituina Dataverse-käyttöoikeuksien kanssa.

Lisätietoja Power BI:n RLS-suojauksesta on artikkelissa Rivitason suojauksen (RLS) ohjeet Power BI Desktopissa.

Asennuksen monimutkaisuus

Dataverse-liittimen käyttö Power BI:ssä – tuonti- tai DirectQuery-malleissa – on yksinkertaista eikä se edellytä erityisiä ohjelmistoja eikä laajennettuja Dataverse-käyttöoikeuksia. Se on etu sille organisaatioille tai osastoille, jotka ovat aloittamassa.

Azure Synapse Linkki -vaihtoehto edellyttää järjestelmänvalvojan pääsyä Dataverseen ja tiettyjä Azure-käyttöoikeuksia. Näitä Azure-käyttöoikeuksia tarvitaan tallennustilin ja Synapse-työtilan määrittämiseen.

Suositellut käytännöt

Tässä osiossa kuvataan suunnittelumalleja (ja mallien vastaisia malleja), jotka tulee ottaa huomioon, kun luot Power BI -mallin, joka muodostaa yhteyden Dataverseen. Vain muutama näistä malleista on Ainutlaatuisia Dataverselle, mutta ne ovat yleensä yleisiä haasteita Dataversen tekijöille, kun he laativat Power BI -raportteja.

Keskity tiettyyn käyttötapaukseen

Keskity sen sijaan, että yrittäisit ratkaista kaiken, keskittyä tiettyyn käyttötapaukseen.

Tämä suositus on luultavasti yleisin ja helposti haastavin anti-pattern vältettävä. On haastavaa yrittää luoda yksi malli, joka saavuttaa kaikki omatoimisen raportoinnin tarpeet. Tosiasia on, että onnistuneet mallit on luotu vastaamaan kysymyksiin, jotka koskevat keskeistä faktajoukkoa yhdessä ydinaiheessa. Vaikka tämä saattaa aluksi tuntua rajoittavan mallia, se on itse asiassa voimamahdollisuuksia, koska voit hienosäätää ja optimoida mallia vastaamaan kyseisen aiheen kysymyksiin.

Varmista, että ymmärrät selvästi mallin tarkoituksen, kysymällä itseltäsi seuraavat kysymykset.

• Mitä aihealuetta tämä malli tukee?
• Mikä on raporttien yleisö?
• Mitä kysymyksiä raportit yrittävät vastata?
• Mikä on pienin toimiva semanttinen malli?

Vastusta useiden aihealueiden yhdistämistä yhdeksi malliksi vain siksi, että raportin käyttäjällä on kysymyksiä useilla aihealueilla, joita hän haluaa käsitellä yksittäisellä raportilla. Jakamalla raportin useisiin raportteihin, jotka keskittyvät eri aiheeseen (tai faktataulukkoon), voit tuottaa paljon tehokkaampia, skaalautuvia ja hallittavampia malleja.

Tähtirakenteen suunnitteleminen

Dataverse-kehittäjät ja järjestelmänvalvojat, jotka ovat tyytyväisiä Dataverse-rakenteeseen, saattavat haluta toistaa saman rakenteen Power BI:ssä. Tämä lähestymistapa on anti-pattern, ja se on todennäköisesti vaikein voittaa, koska tuntuu oikealta säilyttää johdonmukaisuus.

Dataverse sopii relaatiomallina hyvin tarkoitukseen. Sitä ei kuitenkaan ole suunniteltu analyysiraportteja varten optimoituna analyysimallina. Analytiikkatietojen mallinnuksen yleisin malli on tähtirakenne. Tähtirakenne on kypsä mallinnusmenetelmä, joka on laajasti käytössä relaatiotietovarastoissa. Tämä edellyttää, että mallintajat luokittelevat mallitaulukot joko dimensioksi tai faktaksi. Raportit voivat suodattaa tai ryhmitellä käyttämällä dimensiotaulukon sarakkeita ja tehdä yhteenvedon faktataulukon sarakkeista.

Lisätietoja on kohdassa Tutustu tähtirakenteeseen ja sen merkitykseen Power BI:ssä.

Power Query -kyselyiden optimointi

Power Queryn koostemoduuli pyrkii tekemään kyselyn delegoinnin lähteeseen aina kun se on mahdollista tehokkuuden vuoksi. Kysely, joka suorittaa delegoinnin lähteeseen delegoivan kyselyn käsittelyn lähdejärjestelmään.

Lähdejärjestelmän, tässä tapauksessa Dataversen, tarvitsee toimittaa vain suodatetut tai yhteenvedetyt tulokset Power BI:hin. Lähteeseen delegoitu kysely on usein huomattavasti nopeampi ja tehokkaampi kuin kysely, jota ei ole lähteeseen.

Lisätietoja kyselyn delegoimisesta lähteeseen on artikkelissa Power Query -kyselyn delegointi lähteeseen.

Muistiinpano

Power Queryn optimointi on laaja aihealue. Jos haluat ymmärtää paremmin, mitä Power Query tekee sisällön tuottamisen aikana ja mallin päivitysaikana Power BI Desktopissa, katso Kyselydiagnostiikka.

Kyselysarakkeiden määrän pienentäminen

Oletusarvoisesti, kun lataat Dataverse-taulukon Power Queryn avulla, se noutaa kaikki rivit ja kaikki sarakkeet. Kun suoritat kyselyn esimerkiksi järjestelmän käyttäjätaulukosta, se voi sisältää yli 1 000 saraketta. Metatietojen sarakkeet sisältävät suhteita muihin entiteetteihin ja hakuja asetusotsikoihin, joten sarakkeiden kokonaismäärä kasvaa Dataverse-taulukon monimutkaisuuden myötä.

Tietojen noutaminen kaikista sarakkeista on anti-pattern. Tämä johtaa usein laajennettuihin tietojen päivitystoimintoihin, ja se aiheuttaa kyselyn epäonnistumisen, kun tietojen palauttamiseen tarvittava aika on yli 10 minuuttia.

Suosittelemme, että haet vain raportit vaatimat sarakkeet. Kyselyt kannattaa usein arvioida uudelleen ja muodostaa uudelleen, kun raportin kehitys on valmis, jolloin käyttämättömät sarakkeet voidaan tunnistaa ja poistaa. Lisätietoja on artikkelissa Tietojen vähentämisen tekniikat tuonnin mallinnusta varten (poista tarpeettomat sarakkeet).

Varmista myös, että otat Power Queryn poista sarakkeet -vaiheen käyttöön aikaisessa vaiheessa, jotta se taittuu takaisin lähteeseen. Näin Power Query voi välttää lähdetietojen tarpeettoman poimimisen vain niiden myöhemmäksi hylkäämiseksi (avaamattomassa vaiheessa).

Jos sinulla on taulukko, joka sisältää useita sarakkeita, Power Queryn vuorovaikutteisen kyselyn muodostimen käyttäminen voi olla mahdotonta. Tässä tapauksessa voit aloittaa luomalla tyhjän kyselyn. Voit sitten Laajennettu editori liittää siihen vähimmäiskyselyn, joka luo aloituskohdan.

Harkitse seuraavaa kyselyä, joka hakee tiedot vain kahdesta tilitaulukon sarakkeesta.

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"

Alkuperäisten kyselyiden kirjoittaminen

Jos sinulla on tiettyjä muunnosvaatimuksia, voit saavuttaa paremman suorituskyvyn käyttämällä alkuperäistä kyselyä, joka kirjoitetaan Dataverse SQL:llä, joka on Transact-SQL:n alijoukko. Voit kirjoittaa alkuperäisen kyselyn kohteeseen:

• Vähennä rivien määrää (käyttämällä -lausetta WHERE ).
• Koosta tiedot (käyttämällä - ja HAVING -GROUP BYlausekkeita).
• Liitä taulukot tietyllä tavalla (tai APPLY -syntaksin JOIN avulla).
• Käytä tuettuja SQL-funktioita.

Lisätietoja:

• Tietojen kyseleminen SQL:n avulla
• Miten Dataverse SQL eroaa Transact-SQL:stä

Suorita alkuperäiset kyselyt EnableFolding-asetuksella

Power Query suorittaa alkuperäisen kyselyn -funktion Value.NativeQuery avulla.

Tätä funktiota käytettäessä on tärkeää lisätä EnableFolding=true vaihtoehto, jolla varmistetaan, että kyselyt delegoidaan takaisin Dataverse-palveluun. Alkuperäistä kyselyä ei taiteta, ellei tätä asetusta ole lisätty. Tämän asetuksen ottaminen käyttöön voi johtaa merkittäviin suorituskykyparannuksiin – joissakin tapauksissa jopa 97 prosenttia nopeammin.

Harkitse seuraavaa kyselyä, joka käyttää alkuperäistä kyselyä valittujen sarakkeiden lähteeseen tilitaulukosta . Alkuperäinen kysely taittuu, EnableFolding=true koska asetus on määritetty.

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

Voit odottaa saavuttavasi suurimmat suorituskykyparannukset noudettaessa tietojen alijoukkoa suuresta tietomäärästä.

Vihje

Suorituskyvyn parannus voi myös riippua siitä, miten Power BI tekee kyselyjä lähdetietokantaan. Esimerkiksi DAX-funktiota käyttävä COUNTDISTINCT mittari ei osoittanut juurikaan parannusta lähteeseen delegointivihjeen kanssa tai ilman. Kun mittarin kaava kirjoitettiin uudelleen käyttämään SUMX DAX-funktiota, kysely taitettiin lähteeseen, mikä paransi 97 prosenttia samaan kyselyyn ilman vihjettä.

Lisätietoja on kohdassa Value.NativeQuery. (Asetusta EnableFolding ei dokumentoida, koska se koskee vain tiettyjä tietolähteitä.)

Arviointivaiheen nopeuttaminen

Jos käytät Dataverse-yhdistintä (aiemmalta nimeltään Common Data Service), voit lisätä CreateNavigationProperties=false asetuksen tietojen tuonnin arviointivaiheen nopeuttamiseksi.

Tietojen tuonnin arviointivaihe iteroi lähteen metatietojen läpi määrittääkseen kaikki mahdolliset taulukkosuhteet. Metatiedot voivat olla laajoja erityisesti Dataversen osalta. Kun lisäät tämän asetuksen kyselyyn, kerrot Power Querylle, että et aio käyttää kyseisiä suhteita. Tämän asetuksen avulla Power BI Desktop voi ohittaa päivityksen kyseisen vaiheen ja siirtyä tietojen noutamiseen.

Muistiinpano

Älä käytä tätä vaihtoehtoa, kun kysely määräytyy laajennettujen suhdesarakkeiden mukaan.

Harkitse esimerkkiä, joka noutaa tiedot tilitaulukosta. Se sisältää kolme alueeseen liittyvää saraketta: territory, territoryid ja territoryidname.

Kun määrität CreateNavigationProperties=false asetuksen, territoryid - ja territoryidname-sarakkeet säilyvät, mutta aluesarake , joka on suhdesarake (se näyttää Arvo-linkit ), jätetään pois. On tärkeää ymmärtää, että Power Query -yhteyssarakkeet ovat erilainen käsite kuin malliyhteydet, jotka levittävät suodattimia mallitaulukoiden välillä.

Harkitse seuraavaa kyselyä, joka käyttää CreateNavigationProperties=false vaihtoehtoa ( Lähde-vaiheessa ) tietojen tuonnin arviointivaiheen nopeuttamiseksi.

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"

Kun käytät tätä asetusta, saavutat todennäköisesti merkittäviä suorituskyvyn parannuksia, kun Dataverse-taulukolla on useita suhteita muihin taulukoihin. Esimerkiksi koska SystemUser-taulukko liittyy tietokannan kaikkiin muihin taulukoihin, tämän taulukon päivityssuorituskyky hyötyisi asetuksen määrittämisestä CreateNavigationProperties=false .

Muistiinpano

Tämä asetus voi parantaa tuontitaulukoiden tai kaksoistallennustilan taulukoiden tietojen päivittämisen suorituskykyä, mukaan lukien Power Query -editori-ikkunan muutosten käyttöönottoprosessin. Se ei paranna DirectQuery-tallennustilataulukoiden vuorovaikutteisen ristiinsuodatuksen suorituskykyä.

Ratkaise tyhjät valintaotsikot

Jos huomaat, että Dataverse-valintaotsikot ovat tyhjiä Power BI:ssä, tunnisteita ei ehkä ole julkaistu TDS-päätepisteeseen.

Avaa tässä tapauksessa Dataverse Maker-portaali, siirry Ratkaisut-alueelle ja valitse sitten Julkaise kaikki mukautukset. Julkaisuprosessi päivittää TDS-päätepisteeseen uusimmat metatiedot, jolloin asetusotsikot ovat Power BI:n käytettävissä.

Suuremmat semanttiset mallit ja Azure Synapse linkki

Dataverse sisältää mahdollisuuden synkronoida taulukot Azure Data Lake Storage (ADLS) ja muodostaa sitten yhteys tietoihin Azure Synapse työtilan kautta. Pienellä vaivalla voit määrittää Azure Synapse Linkin, jos haluat täyttää Dataverse-tiedot Azure Synapse ja antaa tietoryhmille mahdollisuuden löytää syvällisempiä merkityksellisiä tietoja.

Azure Synapse Link mahdollistaa tietojen ja metatietojen jatkuvan replikoinnin Dataversesta Data Lakeen. Se tarjoaa myös sisäänrakennettun palvelimettoman SQL-varannon kätevänä tietolähteenä Power BI -kyselyille.

Tämän lähestymistavan vahvuudet ovat merkittäviä. Asiakkaat voivat suorittaa analytiikka-, liiketoimintatiedon ja koneoppimisen kuormituksia Dataverse-tietojen välillä käyttämällä erilaisia kehittyneitä palveluita. Lisäpalveluita ovat Apache Spark, Power BI, Azure Data Factory, Azure Databricks ja Azure Machine Learning.

Luo Azure Synapse-linkki Dataverselle

Jotta voit luoda Azure Synapse Link for Dataversen, tarvitset seuraavat edellytykset.

• Järjestelmänvalvojan pääsy Dataverse-ympäristöön.
• Azure Data Lake Storage:
  • Sinulla on oltava tallennustili, jotta voit käyttää ADLS Gen2:ta.
  • Sinulle on määritettävä Blob-tietojen tallennustilan omistaja ja blob-tietojen tallennustilan osallistujan käyttöoikeus tallennustiliin. Lisätietoja on artikkelissa Roolipohjaisen käytön hallinta (Azure RBAC).
  • Tallennustilin on otettava käyttöön hierarkkinen nimitila.
  • On suositeltavaa, että tallennustili käyttää maantieteellisesti vikasietoiseen tallennustilaan (RA-GRS) lukemista.
• Synapse-työtila:
  • Sinulla on oltava synapse-työtilan käyttöoikeus ja synapse-järjestelmänvalvojan oikeudet. Lisätietoja on kohdassa Sisäiset Synapse RBAC -roolit ja -alueet.
  • Työtilan on oltava samalla alueella kuin ADLS Gen2 -tallennustili.

Määritykseen kuuluu kirjautuminen Power Appsiin ja Dataversen yhdistäminen Azure Synapse työtilaan. Ohjatun toiminnon kaltaisen kokemuksen avulla voit luoda uuden linkin valitsemalla tallennustilin ja vietävät taulukot. Azure Synapse Linkki kopioi sitten tiedot ADLS Gen2 -tallennustilaan ja luo automaattisesti näkymiä sisäiseen Azure Synapse palvelimettomaan SQL-varannoseen. Voit sitten muodostaa yhteyden näihin näkymiin Power BI -mallin luomiseksi.

Vihje

Täydelliset ohjeet Azure Synapse linkkien luomisesta, hallinnasta ja valvonnasta on kohdassa Luo Azure Synapse linkki Dataverselle Azure Synapse -työtilasi kanssa.

Toisen palvelimettoman SQL-tietokannan luominen

Voit luoda toisen palvelimettoman SQL-tietokannan ja lisätä mukautettuja raporttinäkymiä sen avulla. Näin voit esittää Power BI -tekijälle yksinkertaistetun tietojoukon, jonka avulla he voivat luoda hyödyllisiin ja merkityksellisiin tietoihin perustuvan mallin. Uudesta palvelimettomasta SQL-tietokannasta tulee luojan ensisijainen lähdeyhteys ja ystävällinen esitys Data Lake -tallennustilasta peräisin olevista tiedoista.

Tämä lähestymistapa tarjoaa Power BI:hin tietoja, jotka ovat kohdistettuja, täydennettyjä ja suodattuja.

Voit luoda palvelimettoman SQL Azure Synapse tietokannan työtilassa Azure Synapse Studion avulla. Valitse SQL-tietokantatyypiksi Palvelimeton ja kirjoita tietokannan nimi. Power Query voi muodostaa yhteyden tähän tietokantaan yhdistämällä työtilan SQL-päätepisteeseen.

Mukautettujen näkymien luominen

Voit luoda mukautettuja näkymiä, jotka paketoivat palvelimettomia SQL-varantokyselyitä. Nämä näkymät toimivat yksinkertaisina ja siisteinä tietolähteinä, joihin Power BI muodostaa yhteyden. Näkymien pitäisi:

• Sisällytä valintakenttiin liittyvät selitteet.
• Vähentää monimutkaisuutta sisällyttämällä vain sarakkeet, joita tarvitaan tietojen mallinnusta varten.
• Suodata tarpeettomat rivit pois, kuten passiiviset tietueet.

Harkitse seuraavaa näkymää, joka noutaa kampanjatiedot.

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;

Huomaa, että näkymässä on vain neljä saraketta, joista kullakin on kutsumanimi. On myös lause, joka WHERE palauttaa vain tarvittavat rivit, tässä tapauksessa aktiiviset kampanjat. Lisäksi näkymä tekee kyselyjä OptionsetMetadata- ja StatusMetadata-taulukoihin yhdistetystä kampanjataulukosta, jotka noutavat valintaotsikoita.

Vihje

Lisätietoja metatietojen noutamisesta on kohdassa Valintaotsikoiden käyttö suoraan Azure Synapse Link for Dataverse.

Kysely sopivista taulukoista

Azure Synapse Link for Dataverse varmistaa, että tiedot synkronoidaan jatkuvasti Data Lake -tallennustilan tietoihin. Paljon käyttöä varten samanaikaiset kirjoitukset ja lukeminen voivat luoda lukituksia, jotka aiheuttavat kyselyiden epäonnistumisen. Jotta tietojen noutaminen olisi luotettavaa, kaksi taulukkotietojen versiota synkronoidaan Azure Synapse.

• Lähes reaaliaikaiset tiedot: Tarjoaa kopion Dataversesta synkronoiduista tiedoista Azure Synapse Linkin kautta tehokkaasti havaitsemalla, mitä tietoja on muutettu sen jälkeen, kun ne alun perin poimittiin tai synkronoitiin viimeksi.
• Tilannevedostiedot: Antaa vain luku -kopion lähes reaaliaikasista tiedoista, jotka päivitetään säännöllisin väliajoin (tässä tapauksessa kerran tunnissa). Tilannevedoksen tietotaulukoiden nimien nimen vieressä on _partitioned .

Jos odotat, että paljon luku- ja kirjoitustoimintoja suoritetaan samanaikaisesti, nouda tiedot tilannevedostaulukoista kyselyvirheiden välttämiseksi.

Lisätietoja on kohdassa Käytä lähes reaaliaikaisia tietoja ja vain luku -tilannevedostietoja.

Yhdistä Synapse Analyticsiin

Jos haluat tehdä kyselyn Azure Synapse palvelimettomassa SQL-varannossa, tarvitset sen työtilan SQL-päätepisteen. Voit noutaa päätepisteen Synapse Studiosta avaamalla palvelimettoman SQL-varannon ominaisuudet.

Power BI Desktopissa voit muodostaa yhteyden Azure Synapse käyttämällä Azure Synapse Analytics SQL -yhdistintä. Anna palvelimelle pyydettäessä työtilan SQL-päätepiste.

DirectQueryn huomioitavat seikat

DirectQuery-tallennustilan käyttö voi vastata vaatimuksesi usein käyttötilanteissa. DirectQueryn käyttö voi kuitenkin vaikuttaa kielteisesti Power BI -raportin suorituskykyyn. Raportti, joka käyttää DirectQuery-yhteyttä Dataverseen, ei ole yhtä nopea kuin tuontimallia käyttävä raportti. Yleensä tiedot kannattaa tuoda Power BI:hin aina, kun se on mahdollista.

Suosittelemme, että harkitset tämän osion aiheita, kun käytät DirectQueryä.

Lisätietoja DirectQuery-tallennustilan käyttötilan määrittämisestä on kohdassa Power BI -mallin kehyksen valitseminen.

Kaksoistallennustilan dimensiotaulukoiden käyttäminen

Tallennustilan kaksoistaulukko on määritetty käyttämään sekä tuonti- että DirectQuery-tallennustiloja. Kyselyn aikana Power BI määrittää tehokkaimman käytettävän tilan. Aina kun mahdollista, Power BI yrittää vastata kyselyihin käyttämällä tuotuja tietoja, koska ne ovat nopeampia.

Harkitse dimensiotaulukoiden asettamista tarvittaessa kaksoistallennustilaan. Näin osittajan visualisoinnit ja suodatinkorttiluettelot, jotka perustuvat usein dimensiotaulukon sarakkeisiin, hahmonnetaan nopeammin, koska niistä tehdään kyselyjä tuoduista tiedoista.

Tärkeä

Kun dimensiotaulukon on perittävä Dataverse-suojausmalli, ei ole tarkoituksenmukaista käyttää kaksoistallennustilan tilaa.

Faktataulukoiden, jotka yleensä tallentavat suuria tietomääriä, tulee pysyä DirectQuery-tallennustilan taulukoina. Ne suodatetaan aiheeseen liittyvien kaksoistallennustilan dimensiotaulukoiden mukaan, jotka voidaan liittää faktataulukkoon tehokkaan suodatuksen ja ryhmittelyn saavuttamiseksi.

Kokeile seuraavaa tietomallin rakennetta. Kolmessa dimensiotaulukossa Omistaja, Tili ja Kampanja on raidallinen yläreuna, mikä tarkoittaa, että ne on määritetty kaksoistallennustilaan.

Lisätietoja taulukon tallennustiloista, mukaan lukien kaksoistallennustila, on kohdassa Tallennustilan hallinta Power BI Desktopissa.

Kertakirjautumisen käyttöönotto

Kun julkaiset DirectQuery-mallin Power BI -palveluun, voit semanttisen mallin asetusten avulla ottaa kertakirjautumisen (SSO) käyttöön käyttämällä Microsoft Entra ID OAuth2:ta raportin käyttäjille. Ota tämä asetus käyttöön, kun Dataverse-kyselyiden on toimittava raportin käyttäjän suojauskontekstissa.

Kun SSO-asetus on käytössä, Power BI lähettää raportin käyttäjän todennetut Microsoft Entra -tunnistetiedot kyselyissä Dataverseen. Tämän asetuksen avulla Power BI voi noudattaa tietolähteessä määritettyjä suojausasetuksia.

Lisätietoja on kohdassa DirectQuery-lähteiden kertakirjautuminen.

Replikoi Omat-suodattimet Power Queryssa

Kun käytät Microsoft Dynamics 365 Customer Engagement (CE) - ja mallipohjaisia Power Apps -sovelluksia, jotka on rakennettu Dataverseen, voit luoda näkymiä, jotka näyttävät vain tietueet, joissa käyttäjänimen kenttä, kuten Omistaja, on sama kuin nykyinen käyttäjä. Voit esimerkiksi luoda näkymiä nimeltä "Omat avoimet mahdollisuudet", "Omat aktiiviset tapaukset" ja muita.

Harkitse esimerkkiä siitä, miten Dynamics 365 Omat aktiiviset tilit - näkymä sisältää suodattimen, jossa Omistaja on yhtä kuin nykyinen käyttäjä.

Voit toistaa tämän tuloksen Power Queryssa käyttämällä alkuperäistä kyselyä, joka upottaa CURRENT_USER tunnuksen.

Katso seuraavaa esimerkkiä, joka näyttää alkuperäisen kyselyn, joka palauttaa nykyisen käyttäjän tilit. Huomaa -lausekkeessa, että ownerid-sarake on suodatettu tunnuksen mukaanCURRENT_USER.WHERE

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

Kun julkaiset mallin Power BI -palveluun, sinun on otettava kertakirjautuminen käyttöön niin, että Power BI lähettää raportin käyttäjän todennetut Microsoft Entra -tunnistetiedot Dataverseen.

Lisätuontimallien luominen

Voit luoda DirectQuery-mallin, joka valvoo Dataverse-käyttöoikeuksia tietäen , että suorituskyky on hidas. Voit sitten täydentää tätä mallia tuontimalleilla, jotka on suunnattu tietyille henkilöille tai yleisöille, jotka voivat pakottaa rivitason suojauksen käyttöoikeudet.

Tuontimalli voi esimerkiksi tarjota käyttöoikeuden kaikkiin Dataverse-tietoihin, mutta ei pakottaa mitään käyttöoikeuksia. Tämä malli sopisi johtajille, joilla on jo käyttöoikeus kaikkiin Dataverse-tietoihin.

Toinen esimerkki on, että kun Dataverse pakottaa roolipohjaiset käyttöoikeudet myyntialueittain, voit luoda yhden tuontimallin ja replikoida nämä oikeudet rivitason suojauksen avulla. Vaihtoehtoisesti voit luoda mallin kullekin myyntialueelle. Voit sitten myöntää lukuoikeuden näihin malleihin (semanttisiin malleihin) kunkin alueen myyjille. Voit helpottaa näiden alueellisten mallien luomista käyttämällä parametreja ja raporttimalleja. Lisätietoja on artikkelissa Raporttimallien luominen ja käyttäminen Power BI Desktopissa.

Liittyvä sisältö

Saat lisätietoja tähän artikkeliin liittyen tutustumalla seuraaviin resursseihin.

• Azure Synapse Link for Dataverse
• Tutustu tähtirakenteeseen ja sen merkitykseen Power BI:ssä
• Tietojen vähentämisen tekniikat tuonnin mallinnusta varten
• Kysyttävää? Voit esittää kysymyksiä Power BI -yhteisössä
• Ehdotuksia? Kerro ideasi Power BI:n parantamiseksi