Jaa

Sivutettujen raporttien tietojen nouto-ohjeet

  • Artikkeli

Tämä artikkeli koskee raportin laatijaa, joka suunnittelee Power BI :n sivutettuja raportteja. Siinä on suosituksia, joiden avulla voit suunnitella tehokasta ja tehokasta tietojen noutoa.

Tietolähdetyypit

Sivutetut raportit tukevat suoraan sekä relaatiotietolähteitä että analytiikkatietolähteitä. Nämä lähteet luokitellaan edelleen joko pilvipohjaisiksi tai paikallisiksi. Paikalliset tietolähteet, joita isännöidään paikallisesti tai näennäiskoneessa, edellyttävät tietoyhdyskäytävää, jotta Power BI voi muodostaa yhteyden. Pilvipohjainen tarkoittaa, että Power BI voi muodostaa yhteyden suoraan Internet-yhteyden avulla.

Jos voit valita tietolähdetyypin (mahdollisesti uudessa projektissa), suosittelemme, että käytät pilvipohjaisia tietolähteitä. Sivutetut raportit voivat muodostaa yhteyden pienemmällä verkkoviiveellä etenkin silloin, kun tietolähteet sijaitsevat samalla alueella kuin Power BI -vuokraajasi. Voit myös muodostaa yhteyden näihin lähteisiin kertakirjautumisen (SSO) avulla. Tämä tarkoittaa sitä, että raportin käyttäjän käyttäjätiedot voidaan siirtää tietolähteeseen, jolloin käyttäjäkohtaisten rivitason käyttöoikeuksien pakottaminen on mahdollista. Tällä hetkellä kertakirjautumista tuetaan vain paikallisissa tietolähteissä SQL Server ja Oracle (katso Power BI:n sivutettujen raporttien tuetut tietolähteet).

Muistiinpano

Vaikka yhteyden muodostaminen paikallisiin tietokantoihin kertakirjautumisen avulla ei ole tällä hetkellä mahdollista, voit silti pakottaa käyttöön rivitason käyttöoikeuksia. Se tehdään välittämällä sisäinen UserID-kenttä tietojoukon kyselyparametriin. Tietolähteen on talletettava täydellinen käyttäjätunnus (UPN) arvot siten, että se voi suodattaa kyselytulokset oikein.

Oletetaan esimerkiksi, että kukin myyjä tallennetaan rivinä taulukon Myyjä-kohtaan . Taulukossa on upn-sarakkeet sekä myyjän myyntialue. Kyselyn aikana taulukko suodatetaan raportin käyttäjän upn:n mukaan, ja se liittyy myös myyntitietoihin käyttämällä sisäliitosta. Näin kysely suodattaa tehokkaasti myyntitietojen rivit raportin käyttäjän myyntialueen mukaan.

Relaatiotietolähteet

Yleensä relaatiotietolähteet sopivat hyvin toimintatyylisiin raportteihin, kuten myyntilaskuihin. Ne soveltuvat myös raporteille, joiden on noudettava erittäin suuria tietojoukkoja (yli 10 000 riviä). Relaatiotietolähteet voivat myös määrittää tallennettuja toimintosarjoja, jotka raportin tietojoukot voivat suorittaa. Tallennetut menettelyt tarjoavat useita etuja:

  • Parametrisointi
  • Ohjelmointilogiikan kapselointi, joka mahdollistaa monimutkaisemman tietojen valmistelun (esimerkiksi väliaikaiset taulukot, kohdistimet tai käyttäjän määrittämät skalaariset funktiot)
  • Parannettu ylläpidettävyys, jonka avulla tallennetun toimintosarjan logiikka on helppo päivittää. Joissakin tapauksissa se voidaan tehdä ilman, että sivutettuja raportteja tarvitsee muokata ja julkaista uudelleen (sarakkeiden nimet ja tietotyypit pysyvät muuttumattomina).
  • parempi suorituskyky, sillä niiden suoritussuunnitelmat tallennetaan välimuistiin uudelleenkäyttöä varten
  • Tallennettujen toimintosarjojen uudelleenkäyttö useissa raporteissa

Power BI:n raportin muodostimessa voit käyttää relaatiokyselyjen suunnittelutyökalua kyselylausekkeen graafiseen muodostamiseen – mutta vain Microsoftin tietolähteille.

Analyysitietolähteet

Analyysitietolähteet – joita kutsutaan myös tietomalleiksi tai vain malleiksi – sopivat hyvin sekä toiminnallisiin että analytiikkaraportteihin, ja ne voivat tuottaa nopeita yhteenvetokyselytuloksia jopa erittäin laajoista tietomääristä. Mallimittarit ja suorituskykyilmaisimet voivat koostaa monimutkaisia liiketoimintasääntöjä tietojen yhteenvedon saavuttamiseksi. Nämä tietolähteet eivät kuitenkaan sovellu raportteihin, joiden on noudettava erittäin suuria tietomääriä (yli 10 000 riviä).

Power BI:n raportin muodostimessa voit valita kaksi kyselyjen suunnittelutyökalua: Analysis Servicesin DAX-kyselyjen suunnittelutyökalu ja Analysis Services MDX -kyselyjen suunnittelutyökalu. Näitä suunnittelutyökaluja voidaan käyttää Power BI:n semanttisen mallin tietolähteissä tai missä tahansa SQL Server Analysis Servicesissä tai Azure Analysis Services mallia – taulukkomuotoista tai moniulotteista.

Suosittelemme, että käytät DAX-kyselyjen suunnittelutyökalua, kunhan se vastaa täysin kyselytarpeitasi. Jos malli ei määritä tarvitsemiasi mittareita, sinun on siirryttävä kyselytilaan. Tässä tilassa voit mukauttaa kyselylauseketta lisäämällä lausekkeita (yhteenvedon saavuttamiseksi).

MDX-kyselyjen suunnittelutyökalu edellyttää, että mallisi sisältää mittareita. DAX-kyselyjen suunnittelutyökalu ei tue suunnittelutoimintoa kahdella ominaisuuslla. Sen avulla voit:

  • Määritä kyselytason lasketut jäsenet (MDX:ssä).
  • Määritä tietoalueet pyytämään palvelimen koosteita ryhmille, jotka eivät ole yksityiskohtaisia. Jos raporttisi on esitettävä puolittain tai ei-lisäävien mittareiden yhteenvedot (kuten aikatietojen laskelmat tai erilliset määrät), on todennäköisesti tehokkaampaa käyttää palvelimen koosteita kuin hakea alemman tason tietorivejä ja käyttää raportin käsittelyyhteenvetoja.

Kyselyn tuloksen koko

Yleensä on parasta hakea vain raportin edellyttämät tiedot. Älä siis nouda sarakkeita tai rivejä, joita raportti ei vaadi.

Jos haluat rajoittaa rivejä, sinun tulee aina käyttää rajoittavimpia suodattimia ja määrittää koostekyselyt. Koosta kyselyt ryhmittele ja tee yhteenveto lähdetiedoista suuren rakeisen tuloksen noutamiseksi. Ajattele esimerkiksi, että raporttisi on esitettävä myyjämyynnin yhteenveto. Sen sijaan, että noutaisi kaikki myyntitilausrivit, luo tietojoukkokysely, joka ryhmittelee myyjän mukaan, ja tekee yhteenvedon kunkin ryhmän myynnistä.

Lausekepohjaiset kentät

Raportin tietojoukkoa voidaan laajentaa lausekkeisiin perustuvilla kentillä. Jos tietojoukkosi esimerkiksi lähteet ovat asiakkaan etu- ja sukunimi, haluat ehkä kentän, joka yhdistää kaksi kenttää asiakkaan koko nimen tuottamiseksi. Tämän laskutoimituksen saavuttamiseksi sinulla on kaksi vaihtoehtoa. Voit tehdä seuraavia toimintoja:

  • Luo laskettu kenttä, joka on lausekkeeseen perustuva tietojoukkokenttä.
  • Lisää lauseke suoraan tietojoukkokyselyun (käyttämällä tietolähteesi alkuperäistä kieltä), jolloin tuloksena on tavallinen tietojoukkokenttä.

Suosittelemme jälkimmäistä vaihtoehtoa aina kun se on mahdollista. On kaksi hyvää syytä, miksi lausekkeiden lisääminen suoraan tietojoukkokyselyysi on parempi:

  • On mahdollista, että tietolähteesi on optimoitu arvioimaan lauseketta tehokkaammin kuin Power BI (tämä koskee erityisesti relaatiotietokantoja).
  • Raportin suorituskykyä on parannettu, koska Power BI:n ei tarvitse muodostaa laskettuja kenttiä ennen raportin hahmontamista. Lasketut kentät voivat huomattavasti pidentää raportin hahmonnusaikaa, kun tietojoukot noutavat suuren määrän rivejä.

Kenttien nimet

Kun luot tietojoukon, sen kentät nimetään automaattisesti kyselysarakkeiden mukaan. On mahdollista, että nämä nimet eivät ole ystävällisiä tai intuitiivisia. On myös mahdollista, että lähdekyselyn sarakkeiden nimet sisältävät merkkejä, jotka ovat kiellettyjä RdL-objektitunnisteissa (kuten välilyönnit ja symbolit). Tässä tapauksessa kiellettyjä merkkejä korvataan alaviivamerkin (_) avulla.

Suosittelemme ensin tarkistamaan, että kaikkien kenttien nimet ovat ystävällisiä, ytimekkäitä mutta silti merkityksellisiä. Jos näin ei ole, suosittelemme nimeämaan ne uudelleen ennen raportin asettelun aloittamista. Tämä johtuu siitä, että uudelleennimetut kentät eivät muuta raportin asettelussa käytettyjen lausekkeiden muutoksia. Jos päätät nimetä kenttiä uudelleen raportin asettelun aloittamisen jälkeen, sinun on etsittävä ja päivitettävä kaikki rikkinäiset lausekkeet.

Suodatin vs. parametri

Sivutetuissa raporttimalleissa on todennäköisesti raportin parametrit. Raporttiparametreja käytetään yleisesti kehottamaan raportin käyttäjää suodattamaan raportti. Sivutetun raportin tekijänä sinulla on kaksi tapaa saavuttaa raportin suodatus. Voit yhdistää raporttiparametrin kohteeseen:

  • Tietojoukkosuodatinta, jossa raporttiparametrien arvoja käytetään tietojoukon jo noutamien tietojen suodattamiseen.
  • Tietojoukkoparametri, jolloin raporttiparametrin arvot lisätään alkuperäiseen kyselyyn, joka lähetetään tietolähteeseen.

Muistiinpano

Kaikki raportin tietojoukot tallennetaan välimuistiin istuntokohtaisesti enintään 10 minuutin ajan niiden edellistä käyttöä pidemmälle. Tietojoukkoa voidaan käyttää uudelleen lähetettäessä uusia parametriarvoja (suodatusta), hahmontaessa raporttia eri muodossa tai käsiteltäessä raportin rakennetta jollakin tavalla, kuten näkyvyyden vaihto tai lajittelu.

Otetaan esimerkiksi myyntiraportti, jossa on yksi raporttiparametri raportin suodattamiseksi yksittäisen vuoden mukaan. Tietojoukko noutaa kaikkien vuosien myynnin. Näin tapahtuu, koska raporttiparametri yhdistää tietojoukon suodattimiin. Raportti näyttää pyydetyn vuoden tiedot, joka on tietojoukon tietojen alijoukko. Kun raportin käyttäjän muuttaa raportin parametrin eri vuodeksi ja tarkastelee sitten raporttia, Power BI:n ei tarvitse noutaa lähdetietoja. Sen sijaan se käyttää eri suodatinta jo välimuistiin tallennetussa tietojoukossa. Kun tietojoukko on tallennettu välimuistiin, suodatus voi olla erittäin nopeaa.

Mieti nyt eri raporttirakennetta. Tällä kertaa raportin rakenne yhdistää myyntivuoden raporttiparametrin tietojoukon parametriin. Näin Power BI lisää vuosiarvon alkuperäiseen kyselyyn, ja tietojoukko noutaa vain kyseisen vuoden tiedot. Aina, kun raportin käyttäjä muuttaa vuoden raportin parametriarvoa ja tarkastelee sitten raporttia, tietojoukko hakee uuden kyselytuloksen vain kyseiselle vuodelle.

Molemmilla rakennetavoilla voidaan suodattaa raporttitietoja, ja molemmat mallit voivat toimia hyvin raporttisuunnitelmissasi. Optimoitu rakenne riippuu kuitenkin odotetuista tietomääristä, tietojen volatiliteettista ja raportin käyttäjien odotetuista toiminnoista.

Suosittelemme tietojoukon suodatusta , kun odotat, että tietojoukon rivien eri alijoukkoa käytetään uudelleen monta kertaa (mikä säästää hahmonnusaikaa, koska uusia tietoja ei tarvitse hakea). Tässä skenaariossa huomaat, että suuremman tietojoukon noutokustannukset voidaan vaihtaa suhteessa siihen, kuinka monta kertaa sitä uudelleenkäytetään. Tästä on hyötyä kyselyissä, joiden luominen vie paljon aikaa. Ole kuitenkin varovainen – suurten tietojoukkojen tallentaminen välimuistiin käyttäjäkohtaisesti voi heikentää suorituskykyä ja kapasiteetin siirtomäärää.

Suosittelemme tietojoukon parametrisointia , kun odotat, että tietojoukon rivejä pyydetään eri alijoukkoa. Jos suodatettavien tietojoukon rivien määrä on todennäköisesti erittäin suuri (ja välimuistiin tehoton). Tämä rakennemenetelmä toimii hyvin myös silloin, kun tietosäilösi on epävakaa. Tässä tapauksessa kunkin raportin parametrin arvon muutos johtaa ajantasaisten tietojen noutamiseen.

Muut kuin alkuperäiset tietolähteet

Jos sinun on kehitettävä sivutettuja raportteja, jotka perustuvat tietolähteisiin, joita ei suoraan tueta sivutetuissa raporteissa, sinun on ensin kehitettävä tietomalli Power BI Desktopissa. Näin voit muodostaa yhteyden sadoihin Power BI:n tukemiin tietolähteisiin. Kun olet julkaissut Power BI -palveluun, voit kehittää sivutetun raportin, joka muodostaa yhteyden semanttiseen Power BI -malliin.

Tietojen integrointi

Jos sinun on yhdistettävä tietoja useista tietolähteistä, sinulla on kaksi vaihtoehtoa:

  • Yhdistä raportin tietojoukkoja: Jos sivutetut raportit tukevat suoraan tietolähteitä, voit harkita laskettujen kenttien luomista, jotka käyttävät Lookup- tai LookupSet Report Builder -funktioita.
  • Power BI Desktop -mallin kehittäminen: On kuitenkin todennäköistä, että kehität tietomallin Power BI Desktopissa. Power Queryn avulla voit yhdistää kyselyjä minkä tahansa tuetun tietolähteen perusteella. Kun olet julkaissut Power BI -palveluun, voit kehittää sivutetun raportin, joka muodostaa yhteyden semanttiseen Power BI -malliin.

Verkon viive

Verkon viive voi vaikuttaa raportin suorituskykyyn kasvattamalla aikaa, jonka pyynnöt vaativat saavuttaakseen Power BI -palvelun, ja vastausten toimitusaikaa. Vuokraajille määritetään Power BI:ssä tietty alue.

Vihje

Jos haluat tietää, missä vuokraajasi sijaitsee, lue artikkeli Missä Power BI -vuokraajani sijaitsee?

Kun vuokraajan käyttäjät käyttävät Power BI -palvelua, heidän pyyntönsä reititetään aina tälle alueelle. Kun pyynnöt saavuttavat Power BI -palvelun, palvelu voi tämän jälkeen lähettää lisäpyyntöjä esimerkiksi taustalla olevaan tietolähteeseen tai tietoyhdyskäytävään, joita verkkoviive koskee myös. Yleensä voit minimoida verkkoviiveen vaikutuksen pyrkimalla pitämään tietolähteet, yhdyskäytävät ja Power BI -kapasiteettisi mahdollisimman lähellä. Mielellään ne sijaitsevat samalla alueella. Jos verkkoviive on ongelma, voit kokeilla yhdyskäytävien ja tietolähteiden sijoittamista lähemmäs Power BI -kapasiteettiasi sijoittamalla ne pilvipalvelussa isännöitäviin näennäiskoneisiin.

SQL Serverin monimutkaiset tietotyypit

Koska SQL Server on paikallinen tietolähde, Power BI:n on muodostettava yhteys yhdyskäytävän kautta. Yhdyskäytävä ei kuitenkaan tue monimutkaisten tietotyyppien tietojen noutamista. Monimutkaiset tietotyypit sisältävät valmiita tyyppejä, kuten GEOMETRIA- ja MAANTIEDE-paikkatietotyypit sekä hierarkian. Ne voivat myös sisältää käyttäjän määrittämiä tyyppejä, jotka on toteutettu Microsoftin kokoonpanoluokan kautta.NET Framework yleinen kielen suorituspalvelu (CLR).

Paikkatietojen ja analytiikan piirtäminen karttavisualisointiin edellyttää SQL Server -paikkatietoja. Tämän vuoksi kartan visualisointia ei voi käyttää, kun SQL Server on tietolähteesi. Selvyyden vuoksi tämä toimii, jos tietolähteesi on Azure SQL -tietokanta, koska Power BI ei muodosta yhteyttä yhdyskäytävän kautta.

Kuvien avulla voidaan lisätä logoja tai kuvia raporttiasetteluun. Kun kuvat liittyvät raportin tietojoukon noutamiin riveihin, sinulla on kaksi vaihtoehtoa:

  • On mahdollista, että myös kuvatiedot voidaan noutaa tietolähteestä (jos ne on jo tallennettu taulukkoon).
  • Kun kuvat on tallennettu verkkopalvelimeen, voit luoda kuvan URL-polun dynaamisen lausekkeen avulla.

Katso lisätietoja ja ehdotuksia sivutettujen raporttien kuva-ohjeista.

Ylimääräinen tietojen nouto

On mahdollista, että raporttisi noutaa tarpeettomia tietoja. Näin voi käydä, kun poistat tietojoukon kyselykentät tai raportissa ei ole tietojoukkoja. Vältä näitä tilanteita, sillä tietolähteet, verkko ja Power BI -kapasiteettiresurssit aiheuttavat tarpeetonta taakkaa.

Poistetut kyselykentät

Tietojoukon ominaisuudet -ikkunan Kentät-sivulla on mahdollista poistaa tietojoukon kyselykenttiä (kyselykenttien yhdistäminen tietojoukkokyselyn noutamiin sarakkeisiin). Raportin muodostin ei kuitenkaan poista vastaavia sarakkeita tietojoukkokyselystä.

Jos sinun on poistettava kyselykenttiä tietojoukosta, suosittelemme poistamaan vastaavat sarakkeet tietojoukkokyselystä. Raportin muodostin poistaa automaattisesti kaikki ylimääräiset kyselykentät. Jos poistat kyselykenttiä, muista myös muokata tietojoukon kyselylauseketta sarakkeiden poistamiseksi.

Käyttämättömät tietojoukot

Kun raportti suoritetaan, kaikki tietojoukot arvioidaan, vaikka niitä ei olisi sidottu raporttiobjekteihin. Varmista tästä syystä, että poistat kaikki testi- tai kehitystietojoukot ennen raportin julkaisemista.

Liittyvä sisältö

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