Jaa

DirectQuery-mallin ohjeet Power BI Desktopissa

  • Artikkeli

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 -palvelun 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 -palvelussa tai Power BI -raporttipalvelimessa 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 -palvelulle tai Power BI -raporttipalvelimelle) 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ä dimensiotaulukot sisältävät yksilöiviä arvoja sisältävän sarakkeen (dimensioavaimen), joka yhdistetään faktataulukkoon. On myös tärkeää, että faktataulukon 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ä Product taulukkoon rivin, joka edustaa tuntematonta tuotetta, ja määrittää sille sitten alueen ulkopuolisen avaimen, kuten -1. Jos Sales taulukon riveillä on puuttuva tuoteavainarvo, korvaa se arvolla -1. Se varmistaa, että jokaisella Sales taulukon tuoteavainarvolla on vastaava rivi Product-taulukossa.

  • Lisää indeksejä -: Määritä taulukoille tai näkymille sopivia indeksejä, jotka tukevat tietojen tehokasta noutamista odotetun raportin visualisoinnin suodatusta ja ryhmittelyä varten. Katso SQL Serverin, Azuren SQL-tietokannan tai Azure Synapse Analyticsin (aiemmin SQL Data Warehouse) lähteistä hyödyllisiä indeksisuunnittelun ohjeita artikkelista SQL Serverin indeksiarkkitehtuuri- ja suunnitteluopas. Jos käytössä ovat SQL Serverin tai Azuren SQL-tietokannan muuttuvat lähteet, tutustu ohjeartikkeliin Reaaliaikainen toiminnallinen analytiikka sarakekauppa-kohdassa.

  • Designin hajautetut taulukot: Arkkitehtuurinaan massiivista rinnakkaiskäsittelyä (MPP) käyttävissä Azure Synapse Analytics -lähteissä kannattaa harkita suurten faktataulukoiden määrittämistä hajautusarvojaelmiksi ja dimensiotaulukoiden 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 Sales-taulukko tallentaa tiedot tilausrivin tasolle, voit luoda näkymän, joka tiivistää nämä tiedot. Näkymä voi perustua SELECT lausekkeeseen, joka ryhmittelee Sales 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 Azuren SQL-tietokannan lähteistä saat artikkelista 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 .

    Näyttökuva, jossa on Power BI Desktop ja Näytä natiivi kysely -vaihtoehto Käytössä olevat vaiheet -kohdassa.

    Näyttökuva, jossa näkyvät Power BI Desktop ja alkuperäinen kyselyikkuna. Kyselylauseke liittää kaksi lähdetaulukkoa.

  • Tarkista laskettujen sarakkeiden käyttö ja tietotyypin muutokset: 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 toteutuu päivämäärätaulukossa. 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 yhdistää vain yhden taulukon yksittäisen sarakkeen toisen taulukon yksittäiseen sarakkeeseen. Joskus taulukoita on kuitenkin tarpeen liittää useisiin sarakkeisiin. Esimerkiksi Sales- ja Geography-taulukot liittyvät toisiinsa kahdella sarakkeella: CountryRegion ja City. Jos haluat luoda suhteen taulukoiden välille, tarvitaan yksittäinen sarake ja Geography-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 dimensiotaulukoihin, mikä on yleinen käytäntö relaatiotietovaraston malleissa.

    Tähän ohjeistukseen on yksi poikkeus, ja se koskee COMBINEVALUES 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 (GUID) tietotyyppiä. 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ä dimensiotaulukoiden perusavainsarake.) Kun se on piilotettu, se ei ole käytettävissä Data -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. Harkitse esimerkiksi mallia, jossa Sales ja Product 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 Sales taulukossa. Kun tätä saraketta käytetään visualisoinnin suodattamiseen tai ryhmittelyyn, Power BI luo kyselyn, jonka ei tarvitse liittyä Sales ja Product taulukoihin.

  • Pakota eheysmäärittämällä suhteita: DirectQuery-suhteiden Oleta viite-eheys -ominaisuus määrittää, luoko Power BI lähdekyselyt käyttämällä INNER JOIN-OUTER JOINsijaan. 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.
    • Yhteyksien enimmäismäärä tietolähdettä kohden -arvon lisääminen varmistaa sen, 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

Semanttiseen DirectQuery-malliin perustuvat raportit voidaan optimoida monella tavalla, kuten seuraavassa luettelossa on kuvattu.

  • Ota käyttöön kyselyn vähentämistekniikat: Power BI Desktop Asetukset ja vaihtoehdot sisältää 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.
  • Käytä suodattimia ensimmäisen: 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äisimme CountryRegion ja Sales mittarit ja suodatat sitten tietyn vuoden mukaan, ota suodatin ensin käyttöön Year-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 Yhteyksien enimmäismäärä tietolähdettä kohden mallin asetuksen mukaisesti rinnakkain lähetettävien kyselyiden määrää on kuitenkin rajoitettu edellä kuvatulla tavalla. 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 poistaminen käytöstä: 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.

    Näyttökuva, jossa on Power BI Desktop ja taulukkomuotoiset tiedot ja käytössä olevat suodattimet.

    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 -lauseen 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.

  • TopN-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).

  • mediaanin: Yleensä mikä tahansa kooste (Summa, Erillisten määrä jne.) lähetetään pohjana olevaan lä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.

  • Monivalintaosittajat: 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: