Kehittynyt lisäävä päivitys ja reaaliaikaiset tiedot XMLA-päätepisteen avulla

  • Artikkeli

Semanttiset mallit Premium-kapasiteetissa, jossa XMLA-päätepiste on käytössä luku- ja kirjoitustoiminnoille, mahdollistavat kehittyneemmät päivitykset, osion hallinnan ja metatietojen käyttöönotot vain työkalun, komentosarjojen ja ohjelmointirajapintatuen kautta. Lisäksi XMLA-päätepisteen kautta suoritettuja päivitystoimintoja ei ole rajoitettu 48 päivitykseen päivässä eikä ajoitetun päivityksen aikarajaa käytetä.

Osiot

Semanttisen mallin taulukon osiot eivät ole näkyvissä, eikä niitä voi hallita Power BI Desktopin tai Power BI -palvelu avulla. Premium-kapasiteettiin määritetyn työtilan malleissa osioita voidaan hallita XMLA-päätepisteen kautta käyttämällä työkaluja, kuten SQL Server Management Studiota (SSMS), avoimen lähdekoodin taulukkomuotoista editoria, komentosarjaa, taulukkomallin komentosarjakieltä (TMSL) ja ohjelmallisesti taulukkomuotoista objektimallia (TOM).

Kun julkaiset mallin Power BI -palvelu ensimmäisen kerran, jokaisella uuden mallin taulukolla on yksi osio. Taulukoissa, joilla ei ole lisäävän päivityksen käytäntöä, yksi osio sisältää kaikki kyseisen taulukon tietorivit, ellei suodattimia ole käytetty. Taulukoissa, joissa on lisäävän päivityksen käytäntö, yksi ensimmäinen osio on olemassa vain, koska Power BI ei ole vielä ottanut käytäntöä käyttöön. Määrität alkuperäisen osion Power BI Desktopissa, kun määrität päivämäärä- ja aika-aluesuodattimen taulukolle - ja RangeEnd -parametrien ja muiden Power Query -editori käytettyjen suodattimien perusteellaRangeStart. Tämä ensimmäinen osio sisältää vain ne tietorivit, jotka täyttävät suodatusehtosi.

Kun suoritat ensimmäisen päivitystoiminnon, taulukot, joilla ei ole lisäävän päivityskäytännön käytäntöä, päivittävät kaikki kyseisen taulukon oletusarvoisen yksittäisen osion sisältämät rivit. Taulukoissa, joissa on lisäävän päivityksen käytäntö, päivitys ja historialliset osiot luodaan automaattisesti ja rivit ladataan niihin kunkin rivin päivämäärän ja ajan mukaan. Jos lisäävän päivityksen käytäntö sisältää tietojen reaaliaikaisen noutamisen, Power BI lisää taulukkoon myös DirectQuery-osion.

Tämä ensimmäinen päivitystoiminto voi kestää melko kauan sen mukaan, kuinka paljon tietoja tietolähteestä on ladattava. Mallin monimutkaisuus voi myös olla merkittävä tekijä, koska päivitystoiminnoissa on tehtävä enemmän käsittelyä ja uudelleenlaskentaa. Tämä toiminto voidaan käynnistää. Lisätietoja on kohdassa Aikakatkaisujen estäminen ensimmäisen täyden päivityksen yhteydessä.

Osiot luodaan lle ja nimetään jakson askelvälin mukaan: Vuodet, vuosineljännekset, kuukaudet ja päivät. Uusimmat osiot, päivityksen osiot, sisältävät rivejä käytännölle määrittämäsi päivitysjakson aikana. Historialliset osiot sisältävät rivejä täyden jakson mukaan päivitysjaksoon asti. Jos reaaliaikainen on käytössä, DirectQuery-osio poimii tiedot muutokset, jotka tapahtuivat päivitysjakson päättymispäivän jälkeen. Päivityksen ja historiallisten osioiden askelvälit riippuvat päivitys- ja historiajaksoista, jotka valitset käytännön määrittämisen aikana.

Jos esimerkiksi tämän päivän päivämäärä on 2.2.2021 ja tietolähteen FactInternetSales-taulukko sisältää rivejä, jotka ovat tähän päivään saakka, jos käytäntömme määrittää sisältämään reaaliaikaisia muutoksia, päivittämään rivit viimeisen päivän päivitysjaksolta ja tallentamaan rivit viimeisten kolmen vuoden historialliselta kaudelta. Sitten ensimmäisellä päivitystoiminnolla luodaan DirectQuery-osio tuleville muutoksille. Tämän päivän riveille luodaan uusi tuontiosio. Historiallinen osio luodaan eilisille koko päiväjaksolle 1.2.2021. Historialliset osiot luodaan koko edelliselle kuukausijaksolle (tammikuu 2021), edelliselle koko vuoden kaudelle (2020) luodaan historiallinen osio ja historialliset osiot vuosille 2019 ja 2018 koko vuoden jaksoille. Kokonaisia vuosineljänneksen osioita ei luoda, koska emme ole vielä suorittaneet vuoden 2021 ensimmäistä täyttä vuosineljännestä.

Diagram shows the partition naming granularity described in the text.

Kunkin päivitystoiminnon yhteydessä vain päivitysjakson osiot päivitetään ja DirectQuery-osion päivämääräsuodatinta päivitetään sisältämään vain ne muutokset, jotka ilmenevät nykyisen päivitysjakson jälkeen. Uusi päivitysosio luodaan uusille riveille, joilla on uusi päivämäärä/aika päivitetyn päivitysjakson aikana, ja päivitysjakson olemassa oleviin riveihin, joilla on jo päivitysjakson päivämäärä/aika-arvo, päivitetään päivityksiä. Rivejä, joiden päivämäärä/aika on päivitysjaksoa vanhempi, ei enää päivitetä.

Kun koko jaksot sulkeutuvat, osiot yhdistetään. Jos esimerkiksi käytännölle on määritetty yhden päivän päivitysjakso ja kolmen vuoden historiasäilön jakso, kuukauden ensimmäisenä päivänä kaikki edellisen kuukauden päivän osiot yhdistetään kuukauden osioon. Uuden vuosineljänneksen ensimmäisenä päivänä kaikki kolme edellisen kuukauden osiota yhdistetään vuosineljänneksen osioon. Uuden vuoden ensimmäisenä päivänä kaikki neljä edellisen vuosineljänneksen osiota yhdistetään vuoden osioon.

Malli säilyttää aina osiot koko historialliselta säilöjaksolta sekä kokonaisen jakson osiot ylöspäin nykyisen päivitysjakson ajan. Esimerkissä täydelliset kolme vuotta historiallisia tietoja säilytetään osioissa vuosille 2018, 2019, 2020 ja myös osiot vuoden 2021Q101 kuukausijaksolle, 2021Q10201 päiväjaksolle ja nykyiselle päivän päivitysjakson osiolle. Koska esimerkissä säilytetään historiatietoja kolmen vuoden ajan, vuoden 2018 osio säilytetään 1.1.2022 ensimmäiseen päivitykseen saakka.

Power BI:n lisäävän päivityksen ja reaaliaikaisten tietojen avulla palvelu käsittelee osion hallinnan puolestasi käytännön perusteella. Vaikka palvelu pystyy käsittelemään osion kaiken hallinnan puolestasi, voit XMLA-päätepisteen työkaluilla päivittää osiot valikoivasti yksitellen, järjestyksessä tai rinnakkain.

Päivitysten hallinta SQL Server Management Studiolla

SQL Server Management Studion (SSMS) avulla voidaan tarkastella ja hallita osioita, jotka on luotu lisäävän päivityksen käytännöillä. SSMS:n avulla voit esimerkiksi päivittää tietyn historiallisen osion, joka ei ole lisäävän päivitysjakson aikana. Näin voit suorittaa takautuvan päivityksen päivittämättä kaikkia historiallisia tietoja. SSMS:tä voidaan käyttää myös käynnistyessä suurten mallien historiallisten tietojen lataamiseen lisäämällä/päivittämällä historiaosiot vähitellen erissä.

Screenshot shows the Partitions window in SSMS.

Lisäävän päivityksen toiminnan kumoaminen

SSMS:n avulla voit hallita paremmin päivitysten käynnistämistä käyttämällä taulukkomallin komentosarjakieltä ja taulukkomuotoista objektimallia. Napsauta esimerkiksi SSMS:n Object Explorerissa taulukkoa hiiren kakkospainikkeella, valitse Prosessitaulukko-valikkovaihtoehto ja valitse sitten Komentosarja-painike TMSL-päivityskomennon luomiseksi.

Screenshot shows the Script button in Process Table dialog.

Näiden parametrien avulla TMSL-päivityskomento voi kumota lisäävän päivityksen oletustoiminnon:

  • applyRefreshPolicy. Jos taulukolle on määritetty lisäävän päivityksen käytäntö, määrittää, applyRefreshPolicy käytetäänkö käytäntöä vai ei. Jos käytäntöä ei käytetä, prosessin koko toiminto jättää osion määritelmät muuttumatta, jolloin taulukon kaikki osiot päivitetään täysin. Oletusarvo on tosi.

  • effectiveDate. Jos lisäävän päivityksen käytäntöä käytetään, sen on tiedettävä nykyinen päivämäärä, jotta se voi tarkistaa lisäävän päivityksen ja historiajaksojen vieritysikkuna-alueet. Parametrin effectiveDate avulla voit ohittaa nykyisen päivämäärän. Tästä parametrista on hyötyä testauksessa, demoissa ja liiketoimintatilanteissa, joissa tietoja päivitetään lisäävästi tiettyyn menneeseen tai tulevaan päivään saakka, esimerkiksi tulevat budjetit. Oletusarvo on nykyinen päivämäärä.

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

Lisätietoja TMSL:n oletusarvoisen lisäävän päivitystoiminnon ohittamisesta on artikkelissa Päivitä-komento.

Optimaalisen suorituskyvyn varmistaminen

Kunkin päivitystoiminnon yhteydessä Power BI -palvelu voi lähettää alustuskyselyjä tietolähteeseen kutakin lisäävän päivityksen osiota varten. Voit ehkä parantaa lisäävän päivityksen suorituskykyä vähentämällä alustuskyselyiden määrää varmistamalla seuraavat määritykset:

  • Lisäävän päivityksen määrittämäsi taulukon pitäisi noutaa tiedot yhdestä tietolähteestä. Jos taulukko saa tietoja useammasta kuin yhdestä tietolähteestä, palvelun lähettämien kyselyjen määrä kullekin päivitystoiminnolle kerrotaan tietolähteiden määrällä, mikä saattaa vähentää päivitysten suorituskykyä. Varmista, että lisäävän päivitystaulukon kysely on tarkoitettu yhdelle tietolähteelle.
  • Ratkaisuissa, joissa on sekä lisäävä tuontiosioiden päivitys että reaaliaikaiset tiedot Direct Querylla, kaikkien osioiden on tehtävä tietokysely yhdestä tietolähteestä.
  • Jos suojausvaatimukset sallivat, aseta tietolähteen tietosuojatason asetukseksi Organisaatio tai Julkinen. Oletusarvoisesti yksityisyystaso on yksityinen, mutta tämä taso voi estää tietojen vaihdon muiden pilvilähteiden kanssa. Jos haluat määrittää yksityisyystason, valitse Lisää asetuksia -valikko ja valitse sitten Asetukset> Tietolähteen tunnistetiedot>Muokkaa tunnistetietoja>Tämän tietolähteen Yksityisyystaso-asetus. Jos Yksityisyystaso on määritetty Power BI Desktop -mallissa ennen palveluun julkaisemista, sitä ei siirretä palveluun julkaisun yhteydessä. Se on silti määritettävä palvelun semanttisissa malliasetuksissa. Lisätietoja on artikkelissa Yksityisyystasot.
  • Jos käytät paikallista tietoyhdyskäytävää, varmista, että käytät versiota 3000.77.3 tai uudempaa versiota.

Aikakatkaisujen estäminen ensimmäisen täyden päivityksen yhteydessä

Kun olet julkaissut Power BI -palvelu, mallin ensimmäinen täysi päivitystoiminto luo osiot lisäävän päivityksen taulukolle, lataa ja käsittelee lisäävän päivityskäytännön koko kauden historiatiedot. Joissain malleissa, jotka lataavat ja käsittelevät suuria tietomääriä, ensimmäisen päivitystoiminnon käyttämä aika voi ylittää palvelun asettaman päivitysajan tai tietolähteen asettaman kyselyn aikarajan.

Ensimmäisen päivitystoiminnon käynnistymisen avulla palvelu voi luoda osio-objekteja lisäävälle päivitystaulukolle mutta ei ladata ja käsitellä historiallisia tietoja mihinkään osioon. SSMS:n avulla osiot käsitellään valikoivasti. Sen mukaan, kuinka paljon tietoja kullekin osiolle ladataan, voit käsitellä jokaisen osion järjestyksessä tai pieninä erinä vähentääksesi mahdollisuuksia, että vähintään yksi näistä osioista aiheuttaa aikakatkaisun. Seuraavat menetelmät toimivat missä tahansa tietolähteessä.

Päivityskäytännön käyttäminen

Avoimen lähdekoodin Tabular Editor 2 -työkalu mahdollistaa helpon tavan käynnistää ensimmäinen päivitystoiminto. Kun olet julkaissut mallin, sille on määritetty lisäävän päivityskäytännön Power BI Desktopista palveluun, muodosta yhteys malliin XMLA-päätepisteen avulla luku- ja kirjoitustilassa. Suorita Lisäävän päivityksen taulukossa Käytä päivityskäytäntöä . Kun vain käytäntö on käytössä, osiot luodaan, mutta niihin ei ladata mitään tietoja. Muodosta sitten yhteys SSMS:iin, jotta osiot päivitetään järjestyksessä tai erissä tietojen lataamista ja käsittelyä varten. Jos haluat lisätietoja, katso Lisäävä päivitys Tabular Editorin dokumentaatiosta.

Screenshot show the Tabular Editor with Apply Refresh Policy selected.

Power Query -suodatin tyhjille osioille

Ennen kuin julkaiset mallin palveluun, lisää Power Query -editori sarakkeeseen toinen suodatinProductKey, joka suodattaa pois minkä tahansa muun arvon kuin 0 tai suodattaa tehokkaasti pois kaikki tiedot FactInternetSales-taulukosta.

Screenshot shows the Power Query Editor with code that filters out the product key.

Kun olet valinnut Sulje ja käytä Power Query -editori, määrittänyt lisäävän päivityksen käytännön ja tallentanut mallin, malli julkaistaan palveluun. Palvelussa mallissa suoritetaan ensimmäinen päivitystoiminto. FactInternetSales-taulukon osiot luodaan käytännön mukaan, mutta mitään tietoja ei ladata ja käsitellä, koska kaikki tiedot on suodatettu pois.

Kun ensimmäinen päivitystoiminto on suoritettu, Power Query -editori sarakkeen ProductKey toinen suodatin poistetaan. Kun olet valinnut Sulje ja käytä Power Query -editori ja tallentanut mallin, mallia ei julkaista uudelleen. Jos malli julkaistaan uudelleen, se korvaa lisäävän päivityksen käytäntöasetukset ja pakottaa mallin täyden päivityksen, kun palvelu suorittaa seuraavan päivitystoiminnon. Suorita sen sijaan metatietojen vain käyttöönotto käyttämällä Application Lifecycle Management (ALM) Toolkitiä, joka poistaa sarakkeen suodattimen ProductKey mallista. SSMS:n avulla voidaan sitten valikoivasti käsitellä osioita. Kun kaikki osiot on käsitelty täysin, minkä täytyy sisältää prosessin uudelleenlaskenta kaikkiin osioihin SSMS:stä lähtien, mallin myöhemmät päivitystoiminnot palvelusta päivittävät vain lisäävän päivityksen osiot.

Vihje

Muista tutustua videoihin, blogteihin ja muihin Power BI -asiantuntijoiden yhteisön tarjoamiin videoihin.

Lisätietoja taulukoiden ja osioiden käsittelystä SSMS:stä on artikkelissa Prosessin tietokanta, taulukko tai osiot (Analysis Services). Lisätietoja mallien, taulukoiden ja osioiden käsittelystä TMSL:n avulla on artikkelissa Päivitä-komento (TMSL).

Tietojen muutosten havaitseminen mukautetuilla kyselyillä

TMSL:n ja TOM:n avulla voidaan kumota tunnistettujen tietojen muutosten toiminta. Tämän menetelmän avulla voidaan paitsi välttää pysyvä viimeisimmän päivityksen sarake välimuistissa, mutta se voi myös ottaa käyttöön skenaarioita, joissa määritys tai ohjetaulukko valmistellaan poimimalla, muuntamalla ja lataamalla (ETL) prosesseja, joilla kirjataan vain ne osiot, jotka on päivitettävä. Tällä menetelmällä voidaan luoda tehokkaampi lisäävän päivityksen prosessi, jossa vain vaadittavat jaksot päivitetään riippumatta siitä, kuinka kauan tietojen päivitykset tapahtuivat.

pollingExpression on tarkoitettu kevyeksi M-lausekkeeksi tai toisen M-kyselyn nimeksi. Sen täytyy palauttaa skalaariarvo ja se suoritetaan jokaiselle osiolle. Jos arvo palauttaa eri arvon kuin edellisen lisäävän päivityksen yhteydessä, osio merkitään täyttä käsittelyä varten.

Seuraava esimerkki kattaa kaikki 120 kuukautta historialliselta kaudelta takautuville muutoksille. 120 kuukauden määrittäminen 10 vuoden asemennuksesta tarkoittaa, että tietojen pakkaus ei ehkä ole aivan yhtä tehokasta, mutta tällä tavalla voidaan välttää koko historiallisen vuoden päivittäminen, mikä olisi kalliimpaa, kun kuukausi riittäisi takautuvalle muutokselle.

"refreshPolicy": {
    "policyType": "basic",
    "rollingWindowGranularity": "month",
    "rollingWindowPeriods": 120,
    "incrementalGranularity": "month",
    "incrementalPeriods": 120,
    "pollingExpression": "<M expression or name of custom polling query>",
    "sourceExpression": [
    "let ..."
    ]
}

Vihje

Muista tutustua videoihin, blogteihin ja muihin Power BI -asiantuntijoiden yhteisön tarjoamiin videoihin.

Vain metatietojen käyttöönotto

Kun julkaiset .pbix-tiedoston uuden version Power BI Desktopista työtilaan ja samanniminen malli on jo olemassa, sinua kehotetaan korvaamaan olemassa oleva malli.

Screenshot shows the Replace model dialog.

Joissakin tapauksissa et ehkä halua korvata mallia, varsinkaan lisäävän päivityksen yhteydessä. Power BI Desktopin malli voi olla paljon pienempi kuin Power BI -palvelu. Jos Power BI -palvelu mallissa on käytössä lisäävän päivityksen käytäntö, siinä voi olla useiden vuosien historiallisia tietoja, jotka menetetään, jos malli korvataan. Kaikkien historiallisten tietojen päivittäminen voi kestää tunteja ja aiheuttaa käyttäjille järjestelmän käyttökatkoja.

Sen sijaan on parempi suorittaa vain metatietojen käyttöönotto, jolloin uudet objektit voidaan ottaa käyttöön menettämättä historiallisia tietoja. Jos olet esimerkiksi lisännyt muutamia mittareita, voit ottaa käyttöön vain ne ilman tietojen päivittämistä, mikä säästää aikaa.

Jos työtilalle on määritetty Premium-kapasiteetti, joka on määritetty XMLA-päätepisteen luku- ja kirjoitustoiminnolle, yhteensopivat työkalut mahdollistavat vain metatietojen käyttöönoton. ALM Toolkit esimerkiksi on rakenne-erotyökalu Power BI -malleille, ja sen avulla voidaan ottaa käyttöön vain metatiedot.

Lataa ja asenna ALM Toolkitin uusin versio Analysis Services Git -säilöstä. ALM Toolkitin vaiheittaiset ohjeet eivät sisälly Microsoftin dokumentaatioon. ALM Toolkitin käyttöohjeiden linkit ja tiedot tuesta ovat saatavilla Ohje-valintanauhassa. Jos haluat suorittaa vain metatietojen käyttöönoton, suorita vertailu ja valitse lähteeksi käynnissä oleva Power BI Desktop -esiintymä ja kohteeksi Power BI -palvelu olemassa oleva malli. Ota huomioon näytetyt erot ja ohita lisäävän päivityksen osiot sisältävän taulukon päivitys. Asetusten valintaikkunassa voit myös säilyttää osiot taulukkopäivityksille. Vahvista valinta ja varmista kohdemallin eheys. Päivitä sitten.

Screenshot shows the ALM Toolkit window.

Lisäävän päivityskäytännön ja reaaliaikaisten tietojen lisääminen ohjelmallisesti

Voit myös lisätä lisäävän päivityskäytännön olemassa olevaan malliin XMLA-päätepisteen kautta TMSL:n ja TOM:n avulla.

Muistiinpano

Yhteensopivuusongelmien välttämiseksi on varmistettava, että käytät Analysis Services -asiakaskirjastojen uusinta versiota. Jos haluat esimerkiksi käyttää hybridikäytäntöjä, version on oltava 19.27.1.8 tai uudempi.

Prosessi sisältää seuraavat vaiheet:

  1. Varmista, että kohdemallilla on pakollinen vähimmäisyhteensopivuustaso. Napsauta SSMS:ssä [mallin nimi]>ominaisuuksien>yhteensopivuustasoa hiiren kakkospainikkeella. Voit suurentaa yhteensopivuustasoa joko createOrReplace TMSL -komentosarjan avulla tai tarkistamalla esimerkiksi seuraavan TOM-mallikoodin.

    a. Import policy - 1550
b. Hybrid policy - 1565

  2. Lisää - ja RangeEnd -RangeStartparametrit mallilausekkeisiin. Lisää tarvittaessa myös funktio, joka muuntaa päivämäärä/aika-arvot päivämääräavaimille.

  3. RefreshPolicy Määritä objekti halutulla arkistoinnilla (vieritysikkuna) ja lisäävän päivityksen jaksoilla sekä lähdelauseke, joka suodattaa kohdetaulukon -ja RangeEnd -RangeStartparametrien perusteella. Määritä päivityskäytännön tilaksi Tuonti tai Yhdistelmä reaaliaikaisten tietojen vaatimusten mukaan. Yhdistelmän ansiosta Power BI lisää taulukkoon DirectQuery-osion, jolla se noutaa viimeisimmän päivitysajan jälkeen tapahtuneen tietolähteen uusimmat muutokset.

  4. Lisää päivityskäytäntö taulukkoon ja suorita täydellinen päivitys niin, että Power BI osioi taulukon tarpeidesi mukaan.

Seuraava koodiesimerkki esittelee, miten voit suorittaa edelliset vaiheet TOM:n avulla. Jos haluat käyttää tätä mallia sellaisenaan, sinulla on oltava kopio AdventureWorksDW-tietokannalle ja tuotava FactInternetSales-taulukko malliin. Koodinäytteessä oletetaan, että - RangeStart ja RangeEnd -parametreja ja DateKey -funktioita ei ole mallissa. Tuo Vain FactInternetSales-taulukko ja julkaise malli Power BI Premiumin työtilaan. Päivitä sitten - workspaceUrl tiedosto, jotta koodimalli voi muodostaa yhteyden malliisi. Päivitä muut koodirivit tarpeen mukaan.

using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
    class Program
    {
        static string workspaceUrl = "<Enter your Workspace URL here>";
        static string databaseName = "AdventureWorks";
        static string tableName = "FactInternetSales";
        static void Main(string[] args)
        {
            using (var server = new TOM.Server())
            {
                // Connect to the dataset.
                server.Connect(workspaceUrl);
                TOM.Database database = server.Databases.FindByName(databaseName);
                if (database == null)
                {
                    throw new ApplicationException("Database cannot be found!");
                }
                if(database.CompatibilityLevel < 1565)
                {
                    database.CompatibilityLevel = 1565;
                    database.Update();
                }
                TOM.Model model = database.Model;
                // Add RangeStart, RangeEnd, and DateKey function.
                model.Expressions.Add(new TOM.NamedExpression {
                    Name = "RangeStart",
                    Kind = TOM.ExpressionKind.M,
                    Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
                });
                model.Expressions.Add(new TOM.NamedExpression
                {
                    Name = "RangeEnd",
                    Kind = TOM.ExpressionKind.M,
                    Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
                });
                model.Expressions.Add(new TOM.NamedExpression
                {
                    Name = "DateKey",
                    Kind = TOM.ExpressionKind.M,
                    Expression =
                        "let\n" +
                        "    Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
                        "in\n" +
                        "    Source"
                });
                // Apply a RefreshPolicy with Real-Time to the target table.
                TOM.Table salesTable = model.Tables[tableName];
                TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
                {
                    Mode = TOM.RefreshPolicyMode.Hybrid,
                    IncrementalPeriodsOffset = -1,
                    RollingWindowPeriods = 1,
                    RollingWindowGranularity = TOM.RefreshGranularityType.Year,
                    IncrementalPeriods = 1,
                    IncrementalGranularity = TOM.RefreshGranularityType.Day,
                    SourceExpression =
                        "let\n" +
                        "    Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
                        "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
                        "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
                        "in\n" +
                        "    #\"Filtered Rows\""
                };
                salesTable.RefreshPolicy = hybridPolicy;
                model.RequestRefresh(TOM.RefreshType.Full);
                model.SaveChanges();
            }
            Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
            Console.ReadLine();
        }
    }
}

Liittyvä sisältö