DirectQuery-mallin ohjeet Power BI Desktopissa
Tämä artikkeli on suunnattu tietomallintajille, jotka kehittävät Power BI:n DirectQuery-malleja, jotka on kehitetty joko Power BI Desktopin tai Power BI -palvelu avulla. Tässä kuvataan DirectQueryn käyttötapauksia, rajoituksia ja ohjeita. Ohjeiden tarkoituksena on erityisesti auttaa selvittämään, onko DirectQuery sopiva tila mallillesi, ja parantaa raporttiesi suorituskykyä DirectQuery-mallien perusteella. Tämä artikkeli koskee Power BI -palvelu tai Power BI -raporttipalvelin isännöityjä DirectQuery-malleja.
Tämän artikkelin tarkoituksena ei ole käydä DirectQuery-mallia läpi kokonaisvaltaisesti. Katso johdanto artikkelista DirectQuery-mallit Power BI Desktopissa . Jos haluat syvempää keskustelua, lue suoraan tekninen raportti DirectQuery SQL Server 2016 Analysis Servicesissä . Kannattaa muistaa, että tekninen raportti kuvaa DirectQueryn käyttöä SQL Server Analysis Servicesissä. Suurta osasta sisältöä voidaan kuitenkin soveltaa Power BI:n DirectQuery-malleihin.
Muistiinpano
Jos haluat lisätietoja DirectQuery-tallennustilan käytöstä Dataverselle, katso Power BI -mallinnusohjeet Power Platformille.
Tämä artikkeli ei suoranaisesti käsittele yhdistelmämalleja. Yhdistelmämalli koostuu vähintään yhdestä DirectQuery-lähteestä. Tässä artikkelissa kuvatut ohjeet ovat koskevat kuitenkin – ainakin osittain – yhdistelmämallin suunnittelua. Tässä artikkelissa ei kuitenkaan käsitellä tuontitaulukoiden yhdistämisen vaikutuksia DirectQuery-taulukoihin. Lisätietoja on artikkelissa Yhdistelmämallien käyttäminen Power BI Desktopissa.
On tärkeää ymmärtää, että DirectQuery-mallit asettavat erilaisen kuormituksen Power BI -ympäristölle (Power BI -palvelu tai Power BI -raporttipalvelin) ja myös pohjana olevista tietolähteistä. Jos päätät, että DirectQuery on sopiva suunnittelumenetelmä, suosittelemme, että otat oikeat henkilöt mukaan projektiin. Huomaamme usein, että DirectQuery-mallin onnistunut käyttöönotto on seurausta siitä, että IT-ammattilaisten ryhmä työskentelee tiiviissä yhteistyössä. Ryhmä koostuu yleensä mallien kehittäjistä ja lähdetietokantojen järjestelmänvalvojista. Siihen voi kuulua myös tietoarkkitehdejä sekä tietovarasto- ja etl-kehittäjiä. Usein optimointeja on sovellettava suoraan tietolähteeseen hyvien suorituskykytulosten saavuttamiseksi.
Tietolähteen suorituskyvyn optimointi
Relaatiotietokantalähde voidaan optimoida useilla eri tavoilla, kuten seuraavassa luettelossa on kuvattu.
Muistiinpano
Ymmärrämme, että kaikilla mallintajilla ei ole käyttöoikeuksia tai taitoja relaatiotietokannan optimoinniin. Jotkin optimoinnit voidaan tehdä myös mallin rakenteessa ilman, että lähdetietokantaa muokataan, vaikka se onkin ensisijainen kerros DirectQuery-mallin tietojen valmistelemiseen. Usein parhaat optimointitulokset saavutetaan kuitenkin käyttämällä optimointeja lähdetietokannassa.
Varmista, että tietojen eheys on valmis: On erityisen tärkeää, että dimensiotyypin taulukot sisältävät yksilöiviä arvoja sisältävän sarakkeen (dimensioavain), joka yhdistetään faktatyypin taulukkoon tai taulukoihin. On myös tärkeää, että faktatyypin dimensiosarakkeet sisältävät kelvollisia dimensioavainarvoja. Niiden avulla voit määrittää tehokkaampia mallisuhteita, joissa odotetaan vastaavia arvoja suhteen molemmin puolin. Kun lähdetiedot eivät ole eheät, on suositeltavaa, että tiedot korjataan tehokkaasti lisäämällä "tuntematon" dimensiotietue. Voit esimerkiksi lisätä Tuote-taulukkoon rivin, joka edustaa tuntematonta tuotetta, ja määrittää sille sitten alueen ulkopuolisen avaimen, kuten -1. Jos Myynti-taulukon riveillä on puuttuva tuoteavainarvo, korvaa se arvolla -1. Se varmistaa, että jokaisella Myynti-tuoteavainarvolla on vastaava rivi Tuote-taulukossa.
Lisää indeksejä: Määritä taulukoille tai näkymille sopivia indeksejä, jotka tukevat tietojen tehokasta noutamista odotetun raportin visualisoinnin suodatusta ja ryhmittelyä varten. Lisätietoja indeksisuunnittelun ohjeista on SQL Serverin, Azure SQL-tietokanta:n tai Azure Synapse Analyticsin (aiemmin SQL Data Warehouse) lähteissä kohdassa SQL Serverin indeksiarkkitehtuuri- ja suunnitteluopas. Jos käytössä on SQL Serverin tai Azuren SQL-tietokanta muuttuvia lähteitä, katso reaaliaikainen toiminnallinen analytiikka sarakekaupasta.
Suunnittele jaettuja taulukoita: Arkkitehtuurinaan massiivista rinnakkaiskäsittelyä (MPP) käyttävissä Azure Synapse Analytics -lähteissä kannattaa harkita suurten faktatyyppisten taulukoiden määrittämistä hajautusarvojaetuksi ja dimensiotyypin taulukoiden määrittämistä replikoimaan kaikkiin laskentasolmuihin. Lisätietoja on artikkelissa Ohjeita jaettujen taulukoiden suunnitteluun Azure Synapse Analyticsissa (aiemmin SQL Data Warehouse).
Varmista, että tarvittavat tietojen muunnokset muodostuvat: SQL Serverin relaatiotietokantalähteissä (ja muissa relaatiotietokantalähteissä) taulukoihin voidaan lisätä laskettuja sarakkeita. Nämä sarakkeet perustuvat lausekkeeseen, kuten Määrä kertaa Yksikköhinta. Lasketut sarakkeet voivat olla pysyviä (muodostettu) ja, kuten tavalliset sarakkeet, ne voidaan joskus indeksoida. Lisätietoja on artikkelissa Laskettujen sarakkeiden indeksit.
Harkitse myös indeksoituja näkymiä, jotka voivat koostaa faktataulukon tiedot ennakkoon yksityiskohtaivasti. Jos esimerkiksi Myynti-taulukko tallentaa tiedot tilausrivin tasolle, voit luoda näkymän, joka tiivistää nämä tiedot. Näkymä voi perustua SELECT-lausekkeeseen, joka ryhmittelee Myynti-taulukon tiedot päivämäärän (kuukauden tasolla), asiakkaan ja tuotteen mukaan ja tekee yhteenvedon mittariarvoista, kuten myynti, määrä ja niin edelleen. Näkymä voidaan tämän jälkeen indeksoida. Lisätietoja SQL Serverin tai Azure SQL-tietokanta lähteistä on kohdassa Indeksoitujen näkymien luominen.
Muodosta päivämäärätaulukko: Yleinen mallinnusvaatimus liittyy päivämäärätaulukon lisäämiseen aikapohjaisen suodatuksen tueksi. Jos haluat tukea organisaatiosi tunnettuja aikapohjaisia suodattimia, luo taulukko lähdetietokantaan ja varmista, että siihen on ladattu päivämääräalue, joka kattaa faktataulukon päivämäärät. Varmista myös, että se sisältää hyödyllisiä ajanjaksosarakkeita, kuten vuosi, vuosineljännes, kuukausi, viikko jne.
Mallin rakenteen optimoiminen
DirectQuery-malli voidaan optimoida monella tavalla, kuten seuraavassa luettelossa on kuvattu.
Vältä monimutkaisia Power Query -kyselyitä: Tehokas mallin rakenne voidaan saavuttaa poistamalla tarve muunnosten käyttöön Power Query -kyselyille. Tämä tarkoittaa sitä, että jokainen kysely yhdistää yksittäiseen relaatiotietokannan lähdetaulukkoon tai näkymään. Voit esikatsella käytössä olevan Power Query -vaiheen todellista SQL-kyselylauseketta valitsemalla vaihtoehdon Näytä alkuperäinen kysely .
Tarkista laskettujen sarakkeiden käyttö ja tietotyyppimuutokset: DirectQuery-mallit tukevat laskutoimitusten ja Power Queryn vaiheiden lisäämistä tietotyyppien muuntamiseksi. Suorituskyky usein kuitenkin paranee, kun muunnoksen tulokset muodostuvat relaatiotietokantalähteeseen mahdollisuuksien mukaan.
Älä käytä Power Queryn suhteellista päivämääräsuodatusta: Power Query -kyselyssä voi määrittää suhteellisen päivämääräsuodatuksen. Voit esimerkiksi noutaa myyntitilaukset, jotka luotiin edellisenä vuonna (suhteessa kuluvan päivän päivämäärään). Tämäntyyppinen suodatin muodostaa tehomattoman natiivikyselyn seuraavasti:
… from [dbo].[Sales] as [_] where [_].[OrderDate] >= convert(datetime2, '2018-01-01 00:00:00') and [_].[OrderDate] < convert(datetime2, '2019-01-01 00:00:00'))Parempi rakennemenetelmä on sisällyttää suhteelliset aikasarakkeet päivämäärätaulukkoon. Nämä sarakkeet tallentavat siirtymäarvot suhteessa nykyiseen päivämäärään. Esimerkiksi RelativeYear-sarakkeessa arvo nolla edustaa kuluvaa vuotta, -1 edustaa edellistä vuotta jne. Mieluiten RelativeYear-sarake muodostetaan päivämäärätaulukkoon. Vaikka se ei olekaan yhtä tehokas, se voidaan lisätä myös mallin laskettuna sarakkeena, joka perustuu TODAY- ja DATE-DAX-funktioita käyttävään lausekkeeseen.
Pidä mittarit yksinkertaisina: Suosittelemme, että ainakin aluksi käytät mittareina vain yksinkertaisia koosteita. Koostefunktioihin kuuluvat SUM, COUNT, MIN, MAX ja AVERAGE. Jos mittarit ovat riittävän reagoivia, voit kokeilla monimutkaisempia mittareita kiinnittäen kuitenkin huomiota kunkin suorituskykyyn. Vaikka CALCULATE-DAX-funktiolla voidaan tuottaa kehittyneitä mittarilausekkeita, jotka muokkaavat suodatinkontekstia, ne voivat luoda kalliita natiiveja kyselyitä, joiden suorituskyky on huono.
Vältä suhteita lasketuissa sarakkeissa: Mallisuhteet voivat muodostaa suhteen ainoastaan yhden taulukon yksittäisestä sarakkeesta toisen taulukon yksittäiseen sarakkeeseen. Joskus taulukoita on kuitenkin tarpeen liittää useisiin sarakkeisiin. Esimerkiksi Myynti- ja Maantiede-taulukot liittyvät kahteen sarakkeeseen: CountryRegion ja City. Jos haluat luoda suhteen taulukoiden välille, tarvitaan yksittäinen sarake ja Maantiede-taulukossa sarakkeen on sisällettävä yksilöllisiä arvoja. Maan/alueen ja kaupungin yhdistäminen yhdysmerkki-erottimella voi saavuttaa tämän tuloksen.
Yhdistetty sarake voidaan luoda joko Power Queryn mukautetulla sarakkeella tai mallissa laskettuna sarakkeena. Tätä tulisi kuitenkin välttää, koska laskentalauseke upotetaan lähdekyselyihin. Tämä on paitsi tehotonta, mutta yleensä myös estää indeksien käyttämisen. Lisää sen sijaan muodostettuja sarakkeita relaatiotietokantalähteeseen ja harkitse niiden indeksointia. Voit myös halutessasi lisätä korvaavia avainsarakkeita dimensiotyyppisiin taulukoihin, mikä on yleinen käytäntö relaatiotietovaraston suunnittelussa.
Tähän ohjeistukseen on yksi poikkeus, ja se koskee CO Mt INEVALUES DAX-funktion käyttöä. Tämän funktion tarkoituksena on tukea monisarakkeisia mallisuhteita. Sen sijaan, että se loisi suhteen käyttämän lausekkeen, se luo monisarakkeisen SQL-liittymispredikaatin.
Vältä suhteita "Unique Identifier" -sarakkeissa: Power BI ei suoraan tue yksilöivän tunnisteen tietotyyppiä (GUID). Kun määrität suhdetta tämän tyypin sarakkeiden välille, Power BI luo lähdekyselyn, jossa on liitos, johon liittyy muunnoksen. Tämä kyselyajan tietojen muuntaminen johtaa usein heikkoon suorituskykyyn. Ellei tätä tapausta optimoida, ainoa vaihtoehtoinen menetelmä on luoda sarakkeet eri tietotyypillä taustatietokannassa.
Piilota suhteiden yhden puolen sarake: Suhteen yhden puolen sarake tulisi olla piilotettuna. (Se on yleensä dimensiotyypin taulukoiden perusavainsarake.) Kun se on piilotettu, se ei ole käytettävissä Kentät-ruudussa, joten sitä ei voi käyttää visualisoinnin määrittämiseen. Monen puolen sarake voi pysyä näkyvissä, jos raporttien ryhmitteleminen tai suodattaminen on hyödyllistä sarakkeiden arvojen mukaan. Ajatellaan esimerkiksi mallia, jossa Myynti- ja Tuote-taulukoiden välillä on suhde. Suhdesarakkeet sisältävät tuotteen SKU-arvot (varastointiyksikköarvot). Jos tuotteen SKU on lisättävä visualisointeihin, sen pitäisi näkyä vain Myynti-taulukossa. Kun tämän sarakkeen avulla suodatetaan tai ryhmitetään visualisointia, Power BI luo kyselyn, jonka ei tarvitse liittyä Myynti- ja Tuote-taulukoihin.
Pakota eheys määrittämällä suhteita:DirectQuery-suhteiden Oleta viite-eheys -ominaisuus määrittää, luoko Power BI lähdekyselyt käyttämällä sisäliitosta ulkoliitoksen sijaan. Yleensä tämä parantaa kyselyn tehokkuutta, mutta tämä riippuu kuitenkin relaatiotietokantalähteen ominaisuuksista. Lisätietoja on artikkelissa Oleta viite-eheys -asetus Power BI Desktopissa.
Vältä kaksisuuntaisen suhteen suodatuksen käyttöä: Kaksisuuntaisen suhteiden suodatuksen käyttö voi johtaa kyselylausekkeisiin, jotka eivät toimi kunnolla. Käytä tätä suhdeominaisuutta vain tarvittaessa, mikä on yleensä mahdollista, kun monta-moneen-suhde toteutetaan välitaulukon kautta. Lisätietoja on artikkelissa Moni-moneen-kardinaliteetin sisältävien suhteiden käyttäminen Power BI Desktopissa.
Rajaa rinnakkaisia kyselyitä: Voit määrittää, enimmäismäärän yhteyksille, jotka DirectQuery avaa kullekin pohjana olevalle tietolähteelle. Se määrittää, montako kyselyä tietolähteeseen lähetetään samanaikaisesti.
- Asetus on käytössä vain, kun mallissa on vähintään yksi DirectQuery-lähde. Arvoa sovelletaan kaikkiin DirectQuery-lähteisiin ja malliin lisättyihin kaikkiin uusiin DirectQuery-lähteisiin.
- Nostamalla Tietolähdekohtaisia Näyttöyhteys enimmäismäärää varmistetaan, että taustalla olevaan tietolähteeseen voidaan lähettää enemmän kyselyitä (korkeintaan määritetty enimmäismäärä). Tästä on hyötyä, kun yhdellä sivulla on lukuisia visualisointeja tai useat käyttäjät käyttävät raporttia samanaikaisesti. Kun yhteyksien enimmäismäärä on saavutettu, lisäkyselyt asetetaan jonoon, kunnes yhteys tulee saataville. Tämän rajan nostaminen lisää taustalla olevan tietolähteen kuormitusta, joten asetus ei välttämättä paranna yleistä suorituskykyä.
- Kun malli julkaistaan Power BI:hin, pohjana olevaan tietolähteeseen lähetettyjen samanaikaisten kyselyiden enimmäismäärä riippuu myös ympäristöstä. Eri ympäristöt (kuten Power BI, Power BI Premium tai Power BI -raporttipalvelin) voivat kukin määrätä erilaisia siirtorajoitteita. Lisätietoja kapasiteetin resurssien rajoituksista on artikkelissa Microsoft Fabric -kapasiteetin käyttöoikeudet ja Kapasiteettien määrittäminen ja hallinta Power BI Premiumissa.
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.
Raportin mallien optimoiminen
DirectQueryn semanttiseen malliin (aiemmin tietojoukkona) perustuvat raportit voidaan optimoida monella tavalla, kuten seuraavassa luettelossa on kuvattu.
- Ota käyttöön kyselyn pienentäminen: Power BI Desktopin Asetukset ja Asetukset sisältävät Kyselyn pienentäminen -sivun. Tällä sivulla on kolme hyödyllistä vaihtoehtoa. Ristiinkorostamisen ja ristiinsuodatuksen poistaminen käytöstä on oletusarvoisesti mahdollista, mutta se voidaan ohittaa muokkaamalla vuorovaikutuksia. Voit myös näyttää Käytä-painikkeen osittajissa ja suodattimissa. Osittajan tai suodattimen asetuksia ei käytetä, ennen kuin raportin käyttäjä napsauttaa painiketta. Jos otat nämä asetukset käyttöön, suosittelemme, että teet sen luodessasi raporttia.
- Ota suodattimet käyttöön ensin: Kun suunnittelet raportteja ensimmäistä kertaa, suosittelemme, että otat käyttöön soveltuvat suodattimet – raportti-, sivu- tai visualisointitasolla – ennen kuin yhdistät kenttiä visuaalisiin kenttiin. Sen sijaan, että vetäisit MaaAlue ja Myynti -mittarit ja suodatat sitten tietyn vuoden mukaan, ota suodatin ensin käyttöön Vuosi-kentässä. Tämä johtuu siitä, että visualisoinnin luomisen jokainen vaihe lähettää kyselyn. Vaikka voitkin tehdä toisen muutoksen, ennen kuin ensimmäinen kysely on suoritettu, tämä lisää silti tarpeetonta kuormitusta pohjana olevalle tietolähteelle. Kun otat suodattimet käyttöön aikaisessa vaiheessa, välivaiheen kyselyistä tulee kevyempää ja nopeampia. Jos et ota suodattimia käyttöön ajoissa, tämä voi johtaa miljoonan rivin rajan ylitykseen DirectQueryä koskevien ohjeiden mukaan.
- Rajoita sivun visualisointien määrää: Kun raporttisivu avataan (ja kun sivusuodattimia otetaan käyttöön) kaikki sivun visualisoinnit päivitetään. Power BI -ympäristön vuoksi ja Näyttöyhteys enimmäismäärä tietolähdettä kohden -mallin asetuksen mukaisesti rinnakkain lähetettävien kyselyiden määrää on kuitenkin rajoitettu, kuten yllä on kuvattu. Sivun visualisointien määrän kasvaessa on siis suurempi mahdollisuus, että ne päivitetään sarjamaisesti. Tämä pidentää koko sivun päivittämiseen kuluvaa aikaa, ja se lisää myös todennäköisyyttä, että visualisoinnit saattavat näyttää ristiriitaisia tuloksia (muuttuvien tietolähteiden osalta). Tästä syystä suosittelemme, että rajoitat minkä tahansa sivun visualisointien määrää. Voit käyttää sen sijaan useita yksinkertaisempia sivuja. Useiden korttien visualisointien korvaaminen yksittäisellä monirivisen kortin visualisoinnilla voi luoda samanlaisen sivun asettelun.
- Visualisointien välisen vuorovaikutuksen käytöstä poistaminen: Ristiinkorostamisen ja ristiinsuodatuksen vuorovaikutukset edellyttävät, että kyselyt lähetetään pohjana olevaan lähteeseen. Elleivät nämä vuorovaikutukset ole välttämättömiä, on suositeltavaa, että ne poistetaan käytöstä, jos käyttäjien valinteihin vastaamiseen kuluva aika olisi kohtuuttoman pitkä. Nämä vuorovaikutukset voi poistaa käytöstä joko koko raportissa (kuten yllä kuvattiin Kyselyn pienentäminen -asetusten kohdassa) tai tapauskohtaisesti. Lisätietoja on artikkelissa Visualisointien ristiinsuodatus keskenään Power BI -raportissa.
Yllä mainittujen optimointitekniikoiden lisäksi kaikki seuraavista raportointitoiminnoista voivat vaikuttaa suorituskykyongelmiin:
Mittarisuodattimet: Mittareita sisältävissä visualisoinneissa (tai sarakkeiden koosteissa) voi olla käytössä suodattimia näille mittareille. Alla olevassa visualisoinnissa näytetään myynti luokan mukaan (Myynti luokittain) vain luokille, joiden myynti on vähintään 15 miljoonaa dollaria.
Tämä voi aiheuttaa sen, että taustalähteeseen lähetetään kaksi kyselyä:
- Ensimmäinen kysely hakee luokat, jotka täyttävät ehdon (myynti > 15 000 000 000 dollaria).
- Toinen kysely hakee sitten visualisoinnissa tarvittavat tiedot ja lisää luokat, jotka täyttivät WHERE-lausekkeen ehdon
Tämä toimii yleensä hyvin, jos luokkia on satoja tai tuhansia, kuten tässä esimerkissä. Suorituskyky voi kuitenkin heikentyä, jos luokkia on paljon enemmän. Itse asiassa kysely epäonnistuu, jos ehdon täyttävillä luokilla on yli miljoona luokkaa. Tämä johtuu edellä mainitusta miljoonan rivin rajoituksesta.
Ylimmät N -suodattimet: Lisäsuodatuksen voi määrittää suodattamaan vain ylimmät (tai alimmat) N-arvot, jotka on luokiteltu mittarin mukaan. Voit esimerkiksi näyttää vain viisi ylintä luokkaa yllä olevassa visualisoinnissa. Kuten mittarisuodattimissa, tämän tuloksena on myös kaksi kyselyä, jotka lähetetään pohjana olevaan tietolähteeseen. Ensimmäinen kysely kuitenkin palauttaa kaikki luokat taustalähteestä, kun taas ylimmät N -kentät määritetään palautettujen tulosten perusteella. Käytetyn sarakkeen kardinaliteetista riippuen se voi johtaa suorituskykyongelmiin (tai kyselyn epäonnistumiseen, jos miljoonan rivin raja ylittyy).
Mediaani: Yleensä mikä tahansa kooste (Summa, Erillisten määrä jne.) lähetetään taustalähteeseen. Tämä ei kuitenkaan pidä paikkaansa mediaanin kohdalla, koska taustalähde ei tue tätä koostetta. Tässä tapauksessa haetaan tarkat tiedot taustalähteestä ja Power BI laskee mediaanin palautetuista tuloksista. Tämä ei haittaa, kun mediaani lasketaan kohtuullisen pienestä tulosmäärästä, mutta suorituskykyongelmia ilmenee, jos kardinaliteetti on suuri (tai kysely epäonnistuu, jos miljoonan rivin rajoitus ylittyy). Esimerkiksi maiden/alueiden asukaslukujen mediaanin hakeminen voi olla kohtuullista, mutta myyntihinnan mediaanin hakeminen ei välttämättä ole.
Usean osittajan valinta: Usean valinnan salliminen osittajissa ja suodattimissa voi aiheuttaa suorituskykyongelmia. Tämä johtuu siitä, että kun käyttäjä valitsee lisää osittajan kohteita (esimerkiksi rakentamalla enintään kymmenen tuotetta, joista on kiinnostunut), jokainen uusi valinta johtaa uuteen kyselyyn, joka lähetetään pohjana olevaan lähteeseen. Vaikka käyttäjä voikin valita seuraavan kohteen ennen kyselyn valmistumista, tämä aiheuttaa lisäkuormitusta pohjana olevalle lähteelle. Tilanne voidaan välttää näyttämällä Käytä-painike, kuten yllä kyselyn pienentämistekniikoissa on kuvattu.
Visuaaliset summat: Taulukot ja matriisit näyttävät oletusarvoisesti kokonaissummat ja välisummat. Monissa tapauksissa summien arvojen hakeminen edellyttää lisäkyselyiden lähettämista taustalähteeseen. Sitä sovelletaan aina, kun käytetään Erillisten määrä- tai Mediaani-koostetta, ja kaikissa tapauksissa käytettäessä DirectQueryä SAP HANAn tai SAP Business Warehousen kanssa. Tällaiset summat kannattaa poistaa käytöstä (Muotoile-ruudussa), jos niitä ei tarvita.
Yhdistelmämalliksi muuntaminen
Tuonti- ja DirectQuery-mallien edut voidaan yhdistää yhdeksi malliksi määrittämällä mallitaulukoiden tallennustila. Taulukon tallennustila voi olla Tuonti tai DirectQuery tai molemmat, joka tunnetaan nimellä kaksoistaulukko. Kun malli sisältää taulukoita, joilla on eri tallennustilat, sitä kutsutaan yhdistelmämalliksi. Lisätietoja on artikkelissa Yhdistelmämallien käyttäminen Power BI Desktopissa.
Voit toteuttaa monia toiminnallisia ja suorituskykyyn liittyviä parannuksia muuntamalla DirectQuery-mallin yhdistelmämalliksi. Yhdistelmämalli voi integroida useamman kuin yhden DirectQuery-lähteen, ja se voi sisältää myös koosteita. Koostetaulukoita voidaan lisätä DirectQuery-taulukoihin, jos haluat tuoda yhteenvetoesityksen taulukosta. Niillä voi saavuttaa merkittäviä suorituskyvyn parannuksia, kun visualisoinnit tekevät kyselyjä ylemmän tason koosteita vastaan. Lisätietoja on artikkelissa Koosteet Power BI Desktopissa.
Käyttäjien kouluttaminen
On tärkeää kouluttaa käyttäjät käsittelemään DirectQueryn semanttisiin malleihin perustuvia raportteja tehokkaasti. Raportin tekijöiden tulee tuntea Raportin mallien optimoiminen -osion sisältö.
Suosittelemme, että opetat raporttien käyttäjille directquery-semanttisiin malleihin perustuvia raportteja. Se voi auttaa ymmärtämään yleistä tietoarkkitehtuuria, myös tässä artikkelissa kuvattuja tärkeitä rajoituksia. Ilmoita, että päivityksen vastaukset ja vuorovaikutteinen suodatus saattavat toisinaan olla hitaita. Kun raportin käyttäjät ymmärtävät, miksi suorituskyky voi heikentyä, he eivät menetä helposti luottamustaan raportteihin ja tietoihin.
Kun raportteja toimitetaan muuttuvista tietolähteistä, varmista, että opetat raportin käyttäjille Päivitä-painikkeen käytön. Kerro heille myös, että on mahdollista nähdä ristiriitaisia tuloksia ja että raportin päivitys voi ratkaista mahdolliset epäyhtenäisyytet raporttisivulla.
Liittyvä sisältö
Saat lisätietoja DirectQuerystä seuraavista resursseista:
Palaute
Tulossa pian: Vuoden 2024 aikana poistamme asteittain GitHub Issuesin käytöstä sisällön palautemekanismina ja korvaamme sen uudella palautejärjestelmällä. Lisätietoja on täällä: https://aka.ms/ContentUserFeedback.
Lähetä ja näytä palaute kohteelle