Yhdistelmämallien käyttäminen Power BI Desktopissa

Kun aiemmin Power BI Desktopissa käytit DirectQuerya raportissa, muita tietoyhteyksiä, DirectQuerya tai tuontia, ei sallittu tälle raportille. Yhdistelmämalleissa tämä rajoitus on poistettu. Raporttiin voi saumattomasti sisällyttää tietoyhteyksiä useasta DirectQuerysta tai tietojen tuontiyhteydestä valitsemanasi yhdistelmänä.

Power BI Desktopin yhdistelmämallit koostuvat kolmesta toisiinsa liittyvästä ominaisuudesta:

• Yhdistelmämallit: Sallii raportille kaksi tietolähdettä tai useampia tietoyhteyksiä eri lähderyhmistä. Nämä lähderyhmät voivat olla vähintään yksi DirectQuery-yhteys ja tuontiyhteys, kaksi DirectQuery-yhteyttä tai useampi DirectQuery-yhteys tai mikä tahansa näiden yhdistelmä. Tässä artikkelissa kuvataan tarkemmin yhdistelmämallit.

• Monta moneen -yhteydet: Yhdistelmämallien avulla voit muodostaa monta moneen -yhteyksiä taulukoiden välille. Tämä lähestymistapa poistaa vaatimuksen siitä, että taulukoiden arvojen pitäisi olla yksilöllisiä. Se poistaa myös aiemmat vaihtoehtoiset menetelmät, kuten uusien taulukoiden käyttöönoton vain suhteiden luomiseksi. Lisätietoja on artikkelissa Monta-moneen-yhteyksien käyttäminen Power BI Desktopissa.

• Tallennus tila: Voit nyt määrittää, mitkä visualisoinnit tekevät kyselyjä taustatietolähteisiin. Tämä ominaisuus parantaa suorituskykyä ja vähentää taustakuormitusta. Aiemmin jopa osittajien kaltaiset yksinkertaiset visualisoinnit käynnistivät kyselyjä taustalähteisiin. Lisätietoja on kohdassa Tallennustilan hallinta Power BI Desktopissa.

Yhdistelmämallien käyttäminen

Yhdistelmämalleilla voit muodostaa yhteyden erilaisiin tietolähteisiin, kun käytät Power BI Desktopia tai Power BI -palvelu. Voit tehdä nämä tietoyhteydet muutamalla eri tavalla:

• Tuomalla tiedot Power BI:hin, mikä on yleisin tapa hakea tietoja.
• Muodostamalla yhteyden suoraan tietoihin niiden alkuperäisessä lähdesäilössä käyttämällä DirectQueryä. Lisätietoja DirectQuerystä on artikkelissa DirectQuery Power BI:ssä.

DirectQuerya käytettäessä yhdistelmämalleilla on mahdollista luoda Power BI -malli, kuten Power BI Desktopin yksittäinen .pbix-tiedosto , joka toimii jommallakummalla tai kummallakin seuraavista toiminnoista:

• Yhdistää tietoja yhdestä tai useammasta DirectQuery-lähteestä.
• Yhdistää tietoja DirectQuery-lähteistä ja tuo tietoja.

Yhdistelmämalleilla voit esimerkiksi luoda mallin, joka yhdistää seuraavantyyppisiä tietoja:

• Yrityksen tietovaraston myyntitiedot.
• Osaston SQL Server -tietokannan myyntikohdetiedot.
• Laskentataulukosta tuodut tiedot.

Sellaista mallia, johon yhdistetään useamman kuin yhden DirectQuery-lähteen tietoja ja tuotuja tietoja, kutsutaan yhdistelmämalliksi.

Voit luoda suhteita taulukoiden välille niin kuin ennenkin, vaikka nämä taulukot ovat peräisin eri lähteistä. Kaikki eri lähteitä käyttävät suhteet luodaan käyttäen kardinaliteettia monta moneen riippumatta niiden todellisesta kardinaliteetista. Voit muuttaa ne yksi moneen-, monta yhteen- tai yksi yhteen -arvoiksi. Riippumatta siitä, minkä kardinaliteetin määrität, ristilähdesuhteilla on eri käytös. Et voi käyttää Data Analysis Expressions (DAX) -funktioita -puolen many arvojen one noutamiseen -puolelta. Saatat myös nähdä suorituskykyvaikutuksen verrattuna saman lähteen sisäisiin monta moneen -suhteisiin.

Muistiinpano

Yhdistelmämallien kontekstissa kaikki tuodut taulukot ovat käytännössä yksittäinen tietolähde riippumatta taustalla olevista tietolähteistä.

Yhdistelmämallin esimerkki

Yhdistelmämallin esimerkkinä voidaan ajatella raporttia, joka muodostaa yhteyden yrityksen tietovarastoon SQL Serverissä DirectQueryn avulla. Tässä tapauksessa tietovarasto sisältää myynnin maan mukaan, vuosineljänneksen ja polkupyörän (tuote) tietoja seuraavassa kuvassa esitetyllä tavalla:

Tässä vaiheessa voit luoda yksinkertaisia visualisointeja käyttämällä tästä lähteestä peräisin olevia kenttiä. Seuraava kuva näyttää myynnin kokonaismäärän tuotenimen mukaan valitulla vuosineljänneksellä.

Mutta entä jos sinulla on Excel-laskentataulukossa tietoja kullekin tuotteelle määritetystä tuotepäälliköstä sekä markkinointiprioriteetista? Jos haluat tarkastella myynnin määräätuotepäällikön mukaan, näitä paikallisia tietoja ei ehkä voi lisätä yrityksen tietovarastoon. Tai ainakin siinä kestäisi ainakin kuukausia.

Myyntitiedot voidaan ehkä tuoda tietovarastosta DirectQueryn käyttämisen sijaan. Myyntitiedot voidaan sitten yhdistää tietoihin, jotka toit laskentataulukosta. Tämä lähestymistapa on kuitenkin kohtuuton johtuen syistä, joiden vuoksi DirectQueryä alun perin käytettiin. Syitä voivat olla seuraavat:

• Pohjana olevan tietolähteen suojaussääntöjen yhdistelmä.
• Tarve tarkastella uusimpia tietoja.
• Tietojen suuri määrä.

Yhdistelmämallit ratkaisevat tämän. Yhdistelmämallit antavat mahdollisuuden muodostaa yhteys tietovarastoon käyttämällä DirectQueryä ja noutaa sitten tietoa muista lähteistä Nouda tiedot -toiminnolla. Tässä esimerkissä muodostamme ensin DirectQuery-yhteyden yrityksen tietovarastoon. Käytämme Nouda tiedot -toimintoa, valitsemme Excelin ja siirrymme sitten paikalliset tiedot sisältävään laskentataulukkoon. Lopuksi tuomme laskentataulukon, joka sisältää tuotenimet, määritetyt myyntipäälliköt ja prioriteetin.

Kentät-luettelossa on kaksi taulukkoa: alkuperäinen Polkupyörä-taulukko SQL Serveristä ja uusi Tuotepäälliköt-taulukko. Uusi taulukko sisältää Excelistä tuodut tiedot.

Power BI Desktopin suhdenäkymässä voimme vastaavasti nähdä toisen taulukon nimeltä Tuotepäälliköt.

Nämä taulukot on nyt liitettävä mallin muihin taulukoihin. Kuten aina, luomme suhteen SQL Serverin Polkupyörä-taulukon ja tuodun Tuotepäälliköt-taulukon välille. Suhde on välillä Bike [ProductName] ja ProductManagers[ProductName]. Aiemmin kuvatulla tavalla kaikissa lähteiden välisissä suhteissa on oletusarvona monta moneen -kardinaliteetti.

Kun tämä suhde on luotu, se näkyy Power BI Desktopin suhdenäkymässä .

Voimme nyt luoda visualisointeja käyttämällä Kentät-luettelon kenttiä. Tämä lähestymistapa yhdistää saumattomasti tietoja useista lähteistä. Esimerkiksi salesAmount-summa kullekin tuotepäällikölle näkyy seuraavassa kuvassa:

Seuraavassa esimerkissä esitetään yleinen tapaus, jossa on dimensiotaulukko , kuten Tuote tai Asiakas, joka laajennetaan joillakin muualta tuoduilla lisätiedoilla. On myös mahdollista käyttää DirectQueryä yhteyden muodostamiseksi eri lähteisiin. Oletetaan esimerkkitaulukon jatkamiseksi, että maa- ja kausikohtaisetmyyntitavoitteet tallennetaan erilliseen osastokohtaiseen tietokantaan. Voit muodostaa yhteyden tietoihin Nouda tiedot -parametrin avulla tavalliseen tapaan seuraavassa kuvassa esitetyllä tavalla:

Kuten teimme aiemmin, voimme luoda suhteita uuden taulukon ja mallin muiden taulukoiden välille. Sitten voimme luoda visualisointeja, jotka yhdistävät taulukon tiedot. Suhdenäkymässä näemme uudet muodostellut yhteydet:

Seuraava kuva perustuu uusiin tietoihin ja suhteisiin, jotka loimme. Vasemmassa alakulmassa oleva visualisointi näyttää yhteensä myynnin kokonaismäärän verrattuna tavoitteeseen, ja varianssin laskutoimitus näyttää eron. Myyntisumma- ja Tavoite-tiedot ovat peräisin kahdesta eri SQL Server -tietokannasta.

Tallennustilan tilan määrittäminen

Jokaisella yhdistelmämallin taulukolla on tallennustilan tila, joka ilmaisee, onko taulukko DirectQuery- vai tuontipohjainen. Tallennustilan tilaa voi tarkastella ja muokata Ominaisuus-ruudussa. Tuo tallennustilan tila näkyviin napsauttamalla taulukkoa hiiren kakkospainikkeella Kentät-luettelossa ja valitsemalla sitten Ominaisuudet. Seuraavassa kuvassa näkyy SalesTargets-taulukon tallennustilan tila.

Tallennustilan tilaa voi tarkastella myös kunkin taulukon työkaluvihjeessä.

Kaikille Power BI Desktop -tiedostoille ( .pbix-tiedostoille ), jotka sisältävät joitakin DirectQuery-taulukoita ja joitakin tuontitaulukoita, tilarivin ilmaisema tallennustilan tila on Yhdistelmä. Voit valita kyseisen termin tilarivillä ja vaihtaa kaikki taulukot tuontitaulukoiksi.

Lisätietoja tallennustilan tilasta on kohdassa Tallennustilan hallinta Power BI Desktopissa.

Muistiinpano

Voit käyttää yhdistelmätallennustilan tilaa Power BI Desktopissa ja Power BI -palvelu.

Lasketut taulukot

Voit lisätä laskettuja taulukoita Power BI Desktopin malliin, joka käyttää DirectQueryä. Lasketun taulukon määrittävät DATA Analysis Expressions (DAX) -lausekkeet voivat viitata joko tuotuihin tai DirectQuery-taulukoihin tai niiden yhdistelmään.

Lasketut taulukot ovat aina tuotuja, ja niiden tiedot päivitetään, kun taulukot päivitetään. Jos laskettu taulukko viittaa DirectQuery-taulukkoon, DirectQuery-taulukkoon viittaavat visualisoinnit näyttävät aina pohjana olevan lähteen uusimmat arvot. Sen sijaan visualisoinnit, jotka viittaavat laskettuun taulukkoon, näyttävät arvot siltä ajalta, kun laskettu taulukko on viimeksi päivitetty.

Tärkeä

Laskettuja taulukoita ei tueta Power BI -palvelu tällä ominaisuudella, ellet täytä tiettyjä vaatimuksia. Lisätietoja tästä on tämän artikkelin osiossa Semanttiseen malliin perustuvan yhdistelmämallin käyttäminen.

Vaikutukset tietoturvaan

Yhdistelmämalleilla on tiettyjä vaikutuksia tietoturvaan. Yhteen tietolähteeseen lähetetty kysely voi sisältää arvoja, jotka on noudettu toisesta lähteestä. Aiemmassa esimerkissä visualisointi, joka näyttää myynnin määräntuotepäällikön mukaan, lähettää SQL-kyselyn Myynti-relaatiotietokantaan. KYSEINEN SQL-kysely saattaa sisältää tuotepäälliköiden ja heidän tuotteidensa nimiä.

Laskentataulukkoon tallennetut tiedot sisältyvät nyt kyselyyn, joka lähetetään relaatiotietokantaan. Jos nämä tiedot ovat luottamuksellisia, sinun on pohdittava asiaa tietoturvan kannalta. Ota erityisesti huomioon seuraavat asiat:

• Kaikki tietokannan järjestelmänvalvojat, jotka voivat tarkastella jäljitys- tai valvontalokeja, voivat tarkastella näitä tietoja, vaikka heillä ei olisi alkuperäisen tietolähteen käyttöoikeuksia. Tässä esimerkissä järjestelmänvalvoja tarvitsee Excel-tiedoston käyttöoikeudet.

• Kunkin lähteen salausasetukset on otettava huomioon. Haluat välttää tietojen noutamista yhdestä lähteestä salatulla yhteydellä ja tietojen sisällyttamista tahattomasti kyselyyn, joka lähetetään toiseen lähteeseen salaamattomalla yhteydellä.

Kun luot yhdistelmämallin, Power BI Desktop näyttää varoitussanoman, joka vahvistaa, että olet huomioinut mahdolliset tietoturvavaikutukset.

Jos tekijä lisää taulukon 1 mallista A yhdistelmämalliin (kutsutaan sitä malliksi C), malliin C pohjautuvaa raporttia tarkasteleva käyttäjä voi kysellä mitä tahansa sellaista taulukkoa mallissa A, jota ei ole suojattu rivitason suojauksella RLS:llä.

Vastaavista syistä varovaisuus on varovaista, kun avaat epäluotettavasta lähteestä lähetetyn Power BI Desktop -tiedoston. Jos tiedostossa on yhdistelmämalleja, yhdestä lähteestä haetut tiedot lähetetään toiseen tietolähteeseen osana kyselyä käyttämällä tiedoston avaavan käyttäjän tunnistetietoja. Tietoja voi tarkastella haitallisen Power BI Desktop -tiedoston tekijä. Power BI Desktop näyttää varoituksen, kun avaat Power BI Desktop -tiedoston, joka sisältää useita lähteitä. Tämä varoitus on samanlainen kuin se, jonka näet avatessasi alkuperäisiä SQL-kyselyitä sisältävän tiedoston.

Vaikutukset suorituskykyyn

DirectQuerya käytettäessä suorituskyky on aina otettava huomioon ensisijassa sen varmistamiseksi, että taustalähteellä on riittävästi resursseja hyvän käyttökokemuksen tarjoamiseen. Hyvä käyttökokemus tarkoittaa, että visualisoinnit päivittyvät korkeintaan viidessä sekunnissa. Lisätietoja suorituskyvystä on artikkelissa DirectQuery Power BI:ssä.

Yhdistelmämallien käyttäminen tuo myös muita suorituskykyyn liittyviä huomioon otettavia seikkoja. Yksittäinen visualisointi voi saada aikaan kyselyiden lähettämisen useisiin lähteisiin, mikä usein välittää tulokset yhdestä kyselystä toiseen lähteeseen. Tällainen tilanne voi tuottaa seuraavanlaisia suorituksia:

• Lähdekysely, joka sisältää suuren määrän literaaliarvoja: Esimerkiksi visualisoinnin, joka pyytää kokonaissummaajoukolle valittuja tuotepäälliköitä, on ensin löydettävä, mitkä tuotteet näille tuotepäälliköille on määritetty. Tämän on tapahduttava ennen kuin visualisointi lähettää SQL-kyselyn, joka sisältää kaikki tuotetunnukset -lausekkeessa WHERE .

• Lähdekysely, joka tekee kyselyn alemmalla rakeisuustasolla ja jossa tiedot koostetaan myöhemmin paikallisesti: Kun tuotteiden määrä, joka täyttää tuotepäällikön suodatusehdot, kasvaa suureksi, kaikkia tuotteita WHERE ei ehkä ole järkevää sisällyttää -lausekkeeseen. Sen sijaan voit tehdä kyselyn relaatiolähteeseen tuotteiden alemmalla tasolla ja koostaa sitten tulokset paikallisesti. Jos Tuotteet-taulukon kardinaliteetti ylittää miljoonan rajan, kysely epäonnistuu.

• Usean lähteen kyselyt, yksi per ryhmä arvon mukaan: Kun koostaminen käyttää DistinctCount-arvoa toisen lähteen jonkin sarakkeen ryhmittelemänä ja jos ulkoinen lähde ei tue ryhmittelyn määrittävien useiden literaaliarvojen tehokasta välittämistä, on lähetettävä yksi SQL-kysely per ryhmä arvon mukaan.

  Visualisointi pyytää erillistä Asiakastilinumero-määrää SQL Server -taulukosta tuotepäällikköjen mukaan laskentataulukosta tuotuna. Silloin visualisoinnin on välitettävä Tuotepäälliköt-taulukon tiedot SQL Serveriin lähetettävässä kyselyssä. Esimerkiksi Redshiftin muissa lähteissä tämä ei olisi mahdollista. Sen sijaan lähetettäisiin yksi SQL-kysely per myyntipäällikkö johonkin käytännölliseen rajaan asti, minkä ylittämisen jälkeen kysely epäonnistuu.

Jokaisella näistä tapauksista on suorituskykyyn omat vaikutukset, joiden yksityiskohdat vaihtelevat tietolähteittäin. Jos kahden lähteen yhdistämiseen käyttävien sarakkeiden kardinaliteetti säilyy alhaisena, muutamassa tuhannessa, suorituskyvyn ei pitäisi heitellä. Kardinaliteetin kasvaessa sinun tulee kiinnittää enemmän huomiota suorituskykyyn.

Lisäksi monta moneen -yhteyksien käyttäminen tarkoittaa, että jokaista summan tai välisumman tasoa varten on lähetettävä erilliset kyselyt pohjana olevaan tietolähteeseen – sen sijaan, että yksityiskohtaiset arvot koostetaan paikallisesti. Kokonaisarvoja sisältävä yksinkertainen taulukkovisualisointi lähettäisi yhden sijaan kaksi lähdekyselyä.

Lähderyhmät

Lähderyhmä on kokoelma kohteita, kuten taulukoita ja suhteita, DirectQuery-lähteestä tai kaikista tietomalliin liittyvistä tuontilähteistä. Yhdistelmämalli on tehty yhdestä tai useammasta lähderyhmästä. Esimerkkejä:

• Yhdistelmämalli, joka muodostaa yhteyden Power BI:n semanttiseen malliin nimeltä Myynti ja täydentää semanttista mallia lisäämällä Myynti YTD -mittarin, joka ei ole käytettävissä alkuperäisessä semanttisessa mallissa. Tämä malli koostuu yhdestä lähderyhmästä.
• Yhdistelmämalli, joka yhdistää tiedot tuomalla taulukon Excel-taulukosta nimeltä Tavoitteet ja CSV-tiedostosta nimeltä Alueet ja muodostamalla DirectQuery-yhteyden Myynti-nimiseen Power BI -semanttiseen malliin. Tässä tapauksessa lähderyhmiä on kaksi seuraavan kuvan mukaisesti:
  • Ensimmäinen lähderyhmä sisältää taulukot Targets Excel -taulukosta ja Regions CSV -tiedostosta.
  • Toinen lähderyhmä sisältää Myynti Power BI:n semanttisen mallin kohteet.

Jos olet lisännyt toisen DirectQuery-yhteyden toiseen lähteeseen, kuten DirectQuery-yhteyden SQL Server -tietokantaan, jonka nimi on Inventory, tämän lähteen kohteet lisätään toiseen lähderyhmään:

Muistiinpano

Tietojen tuominen toisesta lähteestä ei lisää toista lähderyhmää, koska kaikki kohteet kaikista tuoduista lähteistä ovat yhdessä lähderyhmässä.

Lähderyhmät ja suhteet

Yhdistelmämallissa on kahdenlaisia suhteita:

• Lähderyhmän sisäiset suhteet. Nämä suhteet liittävät lähderyhmän kohteet yhteen. Nämä suhteet ovat aina tavallisia suhteita, elleivät ne ole moni-moneen-suhteita, jolloin ne ovat rajoitettuja.
• Lähderyhmien väliset suhteet. Nämä suhteet alkavat yhdestä lähderyhmästä ja päättyvät eri lähderyhmään. Nämä suhteet ovat aina rajoitettuja suhteita.

Lue lisää tavallisten ja rajoitettujen suhteiden erottelusta ja niiden vaikutuksesta.

Esimerkiksi seuraavassa kuvassa lisäsimme kolme lähderyhmien välistä yhteyttä, jotka liittivät eri lähderyhmien taulukot yhteen:

Paikallinen ja etä

Mikä tahansa lähderyhmään kuuluva kohde, joka on DirectQuery-lähderyhmä, katsotaan etäkohteeksi, ellei kohdetta ole määritetty paikallisesti DirectQuery-lähteen laajennukseksi tai täydennykseksi, eikä se ole osa etälähdettä, kuten mittaria tai laskettua taulukkoa. DirectQuery-lähderyhmästä taulukkoon perustuva laskettu taulukko kuuluu Tuonti-lähderyhmään, ja sitä pidetään paikallisena. Mitä tahansa kohdetta, joka kuuluu Tuonti-lähderyhmään, pidetään paikallisena. Jos esimerkiksi määrität seuraavan mittarin yhdistelmämallissa, joka käyttää DirectQuery-yhteyttä Varasto-lähteeseen, mittaria pidetään paikallisena:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Laskentaryhmät, kyselyt ja mittarien arviointi

Laskentaryhmät ovat tapa vähentää päällekkäisten mittareiden määrää ja ryhmitellä yleisiä mittarilausekkeita yhteen. Tyypillisiä käyttötapauksia ovat aikatietojen laskutoimituksia, joissa haluat pystyä vaihtamaan todellisista kuukausi-, vuosineljännes tähän mennessä- tai vuoden alusta -laskutoimituksiin. Yhdistelmämalleja käsiteltäessä on tärkeää tiedostaa laskentaryhmien välinen vuorovaikutus ja se, viittaako mittari vain yksittäisen etälähderyhmän kohteisiin. Jos mittari viittaa vain yhden etälähderyhmän kohteisiin ja etämalli määrittää laskentaryhmän, joka vaikuttaa mittariin, kyseistä laskentaryhmää käytetään, vaikka mittayksikkö olisi määritetty etämallissa tai paikallisessa mallissa. Jos mittari ei kuitenkaan viittaa yksittäisen etälähderyhmän kohteisiin pelkästään mutta viittaa etälähderyhmän kohteisiin, joissa käytetään etälaskutoimitusryhmää, etälaskentaryhmä saattaa silti vaikuttaa mittarin tuloksiin. Katso seuraavaa esimerkkiä:

• Jälleenmyyjän myynti on etämallissa määritetty mittari.
• Etämalli sisältää laskentaryhmän, joka muuttaa jälleenmyyjän myynnin tulosta
• Internet-myynti on mittari, joka on määritetty paikallisessa mallissa.
• Total Sales on paikallisessa mallissa määritetty mittari, joka sisältää seuraavan määritelmän:

[Total Sales] = [Internet Sales] + [Reseller Sales]

Tässä skenaariossa etämallissa määritetty laskentaryhmä ei vaikuta Internet-myynnin mittariin , koska se ei kuulu samaan malliin. Laskentaryhmä voi kuitenkin muuttaa Jälleenmyyjän myynti -mittarin tulosta, koska ne ovat samassa mallissa. Tämä tarkoittaa sitä, että Total Sales -mittarin palauttamat tulokset on arvioitava huolellisesti. Kuvitellaan, että käytämme etämallin laskentaryhmää palauttaaksemme tulokset vuoden alusta. Jälleenmyyjän myynnin palauttama tulos on nyt vuoden alusta , kun taas Internet-myynnin palauttama tulos on edelleen todellinen. Kokonaismyynnin tulos on nyt todennäköisesti odottamaton, koska se lisää todellisen tuloksen vuoden alusta.

Semanttisten Power BI -mallien ja Analysis Servicesin yhdistelmämallit

Yhdistelmämallien ja semanttisten Power BI -mallien ja Analysis Servicesin avulla voit luoda yhdistelmämallin DirectQuery-yhteyden avulla muodostaaksesi yhteyden Power BI:n semanttisiin malleihin, Azure Analysis Servicesiin (AAS) ja SQL Server 2022 Analysis Servicesiin. Yhdistelmämallin avulla voit yhdistää näiden lähteiden tiedot muihin DirectQuery-tietoihin ja tuotuihin tietoihin. Tämä toiminto on erityisen hyödyllinen niille raporttien tekijöille, jotka haluavat yhdistää yrityksen semanttisen mallin tiedot muihin omistaihinsa, kuten Excel-laskentataulukkoon, tai haluavat mukauttaa tai täydentää yrityksen semanttisen mallin metatietoja.

Yhdistelmämallien hallinta semanttisissa Power BI -malleissa

Yhdistelmämallien luomisen ja kulutuksen mahdollistamiseksi Power BI:n semanttisissa malleissa vuokraajallasi on oltava seuraavat valitsimet käytössä:

• Salli XMLA-päätepisteet ja Analysoi Excelissä paikallisten semanttisten mallien kanssa. Jos tämä valitsin on poistettu käytöstä, DirectQuery-yhteyttä Power BI:n semanttiseen malliin ei voi muodostaa.
• Käyttäjät voivat käyttää Excelin semanttisia Power BI -malleja reaaliaikaisen yhteyden avulla. Jos tämä valitsin on poissa käytöstä, käyttäjät eivät voi muodostaa reaaliaikaisia yhteyksiä Power BI: n semanttisiin malleihin, joten Tee muutoksia tähän malliin -painiketta ei voi saavuttaa.
• Salli DirectQuery-yhteys Power BI:n semanttisiin malleihin. Seuraavissa kappaleissa on lisätietoja tästä valitsimesta ja sen käytöstä poistamisen vaikutuksista.

Lisäksi Premium-kapasiteeteissa ja käyttäjäkohtaisessa Premiumissa XMLA-päätepisteasetuksen tulisi olla käytössä ja sen asetuksena tulisi olla joko "Vain luku" tai "Luku/kirjoitus".

Vuokraajan järjestelmänvalvojat voivat hallintaportaalissa ottaa käyttöön tai poistaa käytöstä DirectQuery-yhteyksiä Power BI:n semanttisiin malleihin. Vaikka tämä on oletusarvoisesti käytössä, sen poistaminen käytöstä estää käyttäjiä julkaisemasta palvelussa uusia yhdistelmämalleja Power BI:n semanttisissa malleissa.

Aiemmin luodut raportit, jotka käyttävät yhdistelmämallia Power BI:n semanttisessa mallissa, toimivat edelleen. Käyttäjät voivat edelleen luoda yhdistelmämallin desktopissa, mutta eivät voi julkaista palveluun. Kun luot DirectQuery-yhteyden Semanttiseen Power BI -malliin valitsemalla Tee muutoksia tähän malliin , näkyviin tulee sen sijaan seuraava varoitussanoma:

Näin voit yhä tutustua semanttiseen malliin paikallisessa Power BI Desktop -ympäristössäsi ja luoda yhdistelmämallin. Et kuitenkaan voi julkaista raporttia palveluun. Kun julkaiset raportin ja mallin, näet seuraavan virhesanoman, ja julkaisu on estetty:

Vaihtaminen ei vaikuta reaaliaikaisiin Power BI -semanttisiin malleihin eikä reaaliaikaisiin tai DirectQuery-yhteyksiin Analysis Servicesiin. Ne toimivat edelleen riippumatta siitä, onko valitsin poistettu käytöstä. Lisäksi kaikki julkaistut raportit, jotka käyttävät yhdistelmämallia Power BI:n semanttisessa mallissa, toimivat edelleen, vaikka valitsin olisi poistettu käytöstä julkaisun jälkeen.

Yhdistelmämallin luominen semanttisen mallin tai mallin pohjalta

Yhdistelmämallin luominen semanttisen Power BI -mallin tai Analysis Services -mallin avulla edellyttää, että raportissasi on paikallinen malli. Voit aloittaa reaaliaikaisella yhteydellä ja lisätä tai päivittää paikalliseen malliin tai aloittaa DirectQuery-yhteydellä tai tuoduilla tiedoilla, mikä luo raporttiin automaattisesti paikallisen mallin.

Jos haluat nähdä, mitä yhteyksiä mallissasi käytetään, tarkista Power BI Desktopin oikeassa alakulmassa oleva tilarivi. Jos olet muodostanut yhteyden vain Analysis Services -lähteeseen, näet seuraavan kuvan kaltaisen viestin:

Jos olet muodostanut yhteyden semanttiseen Power BI -malliin, näyttöön tulee viesti, jossa kerrotaan, mihin Power BI:n semanttiseen malliin olet muodostanut yhteyden:

Jos haluat mukauttaa reaaliaikaisesti yhdistetyn semanttisen mallin kenttien metatietoja, valitse tilarivillä Tee muutoksia tähän malliin . Vaihtoehtoisesti voit valita valintanauhasta Tee muutoksia tähän malliin -painikkeen seuraavassa kuvassa esitetyllä tavalla. RaporttinäkymässäMallinnus-välilehden Tee muutoksia tähän malliin-painike. Mallinäkymässä painike on Aloitus-välilehdellä.

Kun painiketta valitaan, näyttöön tulee valintaikkuna, jossa vahvistetaan paikallisen mallin lisääminen. Valitse Lisää paikallinen malli , jos haluat luoda uusia sarakkeita tai muokata metatietoja Power BI:n semanttisten mallien tai Analysis Servicesin kentissä. Valintaikkuna tulee näkyviin seuraavassa kuvassa.

Kun olet muodostanut reaaliaikaisen yhteyden Analysis Services -lähteeseen, paikallista mallia ei ole. Jos haluat käyttää DirectQueryä reaaliaikaisesti yhdistetyissä lähteissä, kuten Power BI:n semanttisissa malleissa ja Analysis Servicesissa, sinun on lisättävä paikallinen malli raporttiin. Kun julkaiset paikallisen mallin sisältävän raportin Power BI -palvelu, myös kyseisen paikallisen mallin semanttinen malli julkaistaan.

Ketjuttamalla

Semanttiset mallit ja semanttiset mallit, joihin ne perustuvat, muodostavat ketjun. Tämän ketjutusta kutsutun prosessin avulla voit julkaista muihin Power BI:n semanttisiin malleihin perustuvan raportin ja semanttisen mallin, joka ei aiemmin ollut mahdollista.

Kuvitellaan esimerkiksi, että työtoverisi julkaisee Semanttisen Power BI -mallin nimeltä Myynti ja budjetti Analysis Services -mallin perusteella ja yhdistää sen Budjetti-nimiseen Excel-taulukkoon.

Kun julkaiset uuden raportin (ja semanttisen mallin), jonka nimi on Myynti ja budjetti Euroopassa työtoverisi julkaiseman semanttisen Myynti ja budjetti -mallin perusteella, ja teet siihen joitakin muutoksia tai laajennuksia, lisäät raportin ja semanttisen mallin kolmanneksi pituiseksi ketjuksi, joka alkoi Myyntianalyysipalvelut-mallista. päättyy myös Myynti ja budjetti Euroopassa -nimiseen semanttiseen Power BI -malliin. Seuraavassa kuvassa esitetään tämä ketjutusprosessi.

Edellisen kuvan ketju on kolmeosainen, joka on enimmäispituus. Yli kolmeosaisia ketjuja ei tueta, ja ne johtavat virheisiin.

Käyttöoikeudet ja lisenssit

Yhdistelmämallia käyttävillä käyttäjillä on oltava asianmukaiset oikeudet kaikkiin ketjun semanttisiin malleihin ja malleihin.

Yhdistelmämallin omistaja edellyttää muodostamisoikeutta lähteinä käytettäviin semanttisiin malleihin, jotta muut käyttäjät voivat käyttää malleja omistajan puolesta. Tämän seurauksena yhdistelmämalliyhteyden luominen Power BI Desktopissa tai raportin luominen Power BI:ssä edellyttää muodostamisoikeuksia lähteinä käytettyihin semanttisiin malleihin.

Käyttäjät, jotka tarkastelevat raportteja yhdistelmämallia käyttäen, tarvitsevat yleensä lukuoikeudet yhdistelmämalliin ja lähteinä käytettyihin semanttisiin malleihin. Koontiversio-käyttöoikeudet saattavat olla pakollisia, jos raportit ovat Pro-työtilassa. Nämä vuokraajakytkimet tulee ottaa käyttöön käyttäjälle.

Vaaditut käyttöoikeudet voidaan näyttää seuraavassa esimerkissä:

• Yhdistelmämalli A (omistaja A:n omistama)

  • Tietolähde A1: Semanttinen malli B.
    Omistajalla A on oltava semanttisen mallin B muodostamisoikeus, jotta käyttäjät voivat tarkastella raporttia yhdistelmämallia A käyttämällä.

• Yhdistelmämalli C (omistaja C)

  • Tietolähde C1: Semanttinen malli D
    Omistajalla C on oltava semanttisen mallin D muodostamisoikeus, jotta käyttäjät voivat tarkastella raporttia yhdistelmämallia C käyttämällä.
  • Tietolähde C2: Yhdistelmämalli A
    Omistajalla C on oltava koontioikeudet yhdistelmämalliin A ja lukuoikeudet semanttiseen malliin B.

Yhdistelmämalli A:n avulla raportteja tarkastelevalla käyttäjällä on oltava lukuoikeudet sekä yhdistelmämalliin Aettä semanttiseen malliin B, kun taas käyttäjällä, joka tarkastelee raportteja yhdistelmämallilla C, on oltava lukuoikeudet yhdistelmämalliin C, semanttiseen malliin D, yhdistelmämalliin A ja semanttiseen malliin B.

Muistiinpano

Katso tästä blogikirjoituksesta tärkeitä tietoja siitä, mitä käyttöoikeuksia tarvitaan yhdistelmämalleissa Power BI:n semanttisissa malleissa ja Analysis Services -malleissa.

Jos ketjun jokin tietojoukko on käyttäjäkohtaisessa Premium-työtilassa, sitä käyttävä käyttäjä tarvitsee käyttäjäkohtaisen Premium-käyttöoikeuden. Jos ketjun jokin tietojoukko on Pro-työtilassa, sitä käyttävä käyttäjä tarvitsee Pro-käyttöoikeuden. Jos kaikki ketjun tietojoukot ovat Premium-kapasiteeteissa tai Fabric F64 -kapasiteetissa tai suuremmassa kapasiteetissa, käyttäjä voi käyttää sitä ilmaisella käyttöoikeudella.

Suojausvaroitus

Semanttisten Power BI -mallien ja Analysis Services -mallien yhdistelmämallien käyttäminen tuo näyttöön seuraavassa kuvassa esitetyn suojausvaroituksen.

Tietoja voidaan siirtää yhdestä tietolähteestä toiseen, mikä on sama suojausvaroitus yhdistettäessä DirectQuery-lähteitä ja tuotuja lähteitä tietomalliin. Lisätietoja tästä toiminnosta on artikkelissa Yhdistelmämallien käyttäminen Power BI Desktopissa.

Tuetut skenaariot

Voit luoda yhdistelmämalleja käyttämällä Power BI:n semanttisten mallien tai Analysis Services -mallien tietoja seuraavien skenaarioiden palvelemiseksi:

• Näyttöyhteys tietoja eri lähteistä: tuominen (kuten tiedostot), Power BI:n semanttiset mallit, Analysis Services -mallit
• Suhteiden luominen eri tietolähteiden välille
• Kirjoittamalla eri tietolähteiden kenttiä käyttäviä mittareita
• Uusien sarakkeiden luominen semanttisten Power BI -mallien tai Analysis Services -mallien taulukoille
• Luomalla eri tietolähteiden sarakkeita käyttäviä visualisointeja
• Voit poistaa taulukon mallistasi kenttäluettelon avulla, jotta mallit pysyvät mahdollisimman ytimekkäinä ja laihoina (jos muodostat yhteyden perspektiiviin, et voi poistaa taulukoita mallista)
• Voit määrittää, mitkä taulukot ladataan sen sijaan, että kaikki taulukot pitäisi ladata, kun haluat vain tietyn taulukoiden alijoukon. Katso taulukoiden alijoukon lataaminen myöhemmin tässä asiakirjassa.
• Voit määrittää, lisätäänkö taulukoita, jotka lisätään myöhemmin semanttiseen malliin sen jälkeen, kun olet muodostanut yhteyden mallissasi.

Semanttiseen malliin perustuvan yhdistelmämallin käyttäminen

Kun käytät DirectQueryä power BI:n semanttisille malleille ja Analysis Servicesille, ota huomioon seuraavat tiedot:

• Jos päivität tietolähteesi ja niissä on ristiriitaisia kenttien tai taulukoiden nimiä, Power BI ratkaisee virheet puolestasi.

• Et voi muokata, poistaa tai luoda uusia suhteita samassa Power BI:n semanttisessa mallissa tai Analysis Services -lähteessä. Jos sinulla on muokkausoikeus näihin lähteisiin, voit tehdä muutokset suoraan tietolähteessä.

• Et voi muuttaa tietotyyppejä sarakkeille, jotka on ladattu Power BI:n semanttisesta mallista tai Analysis Services -lähteestä. Jos sinun on muutettava tietotyyppiä, muuta se lähteessä tai käytä laskettua saraketta.

• Jotta voit luoda raportteja Power BI -palvelu yhdistelmämalliin toisen semanttisen mallin perusteella, kaikki tunnistetiedot on määritettävä.

• SQL Server 2022:n ja sitä uudempien Analysis Services -palvelimen paikallisen tai IAAS:n Näyttöyhteys edellyttää paikallista tietoyhdyskäytävää (vakiotila).

• Kaikki yhteydet semanttisiin Power BI -etämalleihin muodostetaan kertakirjautumisen avulla. Todentamista palvelun päänimen avulla ei tällä hetkellä tueta.

• RLS-sääntöjä käytetään lähteessä, jossa ne on määritetty, mutta niitä ei käytetä mallin muissa semanttisissa malleissa. Raportissa määritettyä RLS:ää ei käytetä etälähteissä, eikä etälähteissä määritettyä RLS:ää käytetä muihin tietolähteisiin. Et myöskään voi määrittää rivitason suojausta etälähteestä ladatussa taulukossa, eikä paikallisissa taulukoissa määritetty RLS suodata etälähteestä ladattuja taulukoita.

• Suorituskykyilmaisimia, rivitason suojausta ja käännöksiä ei tuoda lähteestä.

• Saatat kohdata odottamatonta toimintaa päivämäärähierarkiaa käytettäessä. Voit ratkaista tämän ongelman käyttämällä päivämääräsaraketta sen sijaan. Kun olet lisännyt päivämäärähierarkian visualisointiin, voit vaihtaa päivämääräsarakkeeseen napsauttamalla kentän nimen kohdalla olevaa alanuolta ja napsauttamalla sitten kentän nimeä Päivämäärähierarkian käyttämisen sijaan:

  

  Lisätietoja päivämääräsarakkeiden käyttämisestä verrattuna päivämäärähierarkioihin on artikkelissa Automaattisen päivämäärän ja ajan käyttö Power BI Desktopissa.

• Malliketjun enimmäispituus on kolme. Yli kolmeosaisia ketjuja ei tueta, ja ne johtavat virheisiin.

• Malliin voidaan määrittää ketjutuksen estämisen merkintä, joka estää ketjun luomisen tai laajentamisen. Lisätietoja on kohdassa Julkaistun semanttisen mallin DirectQuery-yhteyksien hallinta.

• Yhteyttä Power BI:n semanttiseen malliin tai Analysis Services -malliin ei näytetä Power Queryssa.

Seuraavat rajoitukset koskevat semanttisten Power BI -mallien ja Analysis Servicesin DirectQueryn käyttöä:

• Tietokannan ja palvelimen nimien parametrit ovat tällä hetkellä poissa käytöstä.
• Etälähteestä peräisin olevista taulukoista peräisin olevan rivitason suojauksen määrittämistä ei tueta.
• Minkään seuraavien lähteiden käyttämistä DirectQuery-lähteenä ei tueta:
  • TAULUKKOmallit ENNEN versiota 2022 SQL Server Analysis Services (SSAS)
  • Monidimensiomallit SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Reaaliaikaiset semanttiset mallit
  • Semanttisten mallien mallit
  • Excel Online -päivitys
  • Excelistä tai palvelun CSV-tiedostoista tuodut tiedot
  • Käyttötiedot
  • Omaan työtilaan tallennetut semanttiset mallit
• Power BI Embeddedin käyttämistä semanttisissa malleissa, jotka sisältävät DirectQuery-yhteyden Analysis Services -malliin, ei tällä hetkellä tueta.
• Raportin julkaisemista verkkoon Julkaise verkkoon -ominaisuuden avulla ei tueta.
• Etälähteiden laskentaryhmiä ei tueta, ja kyselyn tulokset ovat määrittämättömiä.

• Lasketut taulukot ja lasketut sarakkeet, jotka viittaavat kertakirjautumisen (SSO) todennuksen sisältävän tietolähteen DirectQuery-taulukkoon, tukevat Power BI -palvelu määritetyllä jaettavan pilviyhteyden ja/tai rakeisen käytön hallinnalla.

• Jos nimeät työtilan uudelleen DirectQuery-yhteyden määrittämisen jälkeen, sinun on päivitettävä tietolähde Power BI Desktopissa, jotta raportti toimii edelleen.
• Automaattista sivun päivitystä tuetaan vain joissakin tilanteissa tietolähteen tyypistä riippuen. Katso lisätietoja artikkelista Automaattinen sivun päivitys Power BI:ssä.
• Ota haltuun semanttinen malli, joka käyttää DirectQueryä muihin semanttisiin malleihin -ominaisuutta, ei tällä hetkellä tueta.
• Kuten minkä tahansa DirectQuery-tietolähteen kohdalla, Analysis Services -mallissa tai Power BI:n semanttisessa mallissa määritettyjä hierarkioita ei näytetä yhdistettäessä malliin tai semanttiseen malliin DirectQuery-tilassa Exceliä käyttämällä.

Power BI:n semanttisten mallien ja Analysis Servicesin DirectQueryn käytössä on otettava huomioon muutama muu asia:

• Käytä pienen kardinaliteetin sarakkeita lähderyhmien välisissä yhteyksissä: Kun luot yhteyden kahteen eri lähderyhmään, yhteyteen osallistuvien sarakkeiden (joita kutsutaan myös liitossarakkeiksi) kardinaliteetin on oltava pieni, ihannetapauksessa 50 000 tai vähemmän. Tämä koskee avainsarakkeita, jotka ovat ei-merkkiä. lisätietoja merkkijonon avainsarakkeista:
• Vältä suurten merkkijonojen avainsarakkeiden käyttämistä lähderyhmien välisissä suhteissa: Kun luot lähderyhmien välistä suhdetta, vältä suurten merkkijonosarakkeiden käyttämistä yhteyssarakkeina erityisesti sarakkeissa, joiden kardinaliteetti on suurempi. Kun sinun on käytettävä merkkijonosarakkeita suhdesarakkeena, laske suodattimen odotettu merkkijonon pituus kertomalla kardinaliteetti (C) merkkijonosarakkeen (A) keskimääräisellä pituudella. Varmista, että odotetun merkkijonon pituus on alle 250 000 siten, että A-∗ C < 250 000.

Lisätietoja ja ohjeita on yhdistelmämallin ohjeissa.

Huomioitavaa vuokraajasta

Mallit, joilla on DirectQuery-yhteys Power BI:n semanttiseen malliin tai Analysis Servicesiin, on julkaistava samassa vuokraajassa. Tämä on erityisen tärkeää, kun käytetään power BI:n semanttista mallia tai Analysis Services -mallia käyttäen B2B-vierasidentiteettejä seuraavassa kaaviossa esitetyllä tavalla. Katso vuokraajan URL-osoite julkaisua varten kohdasta Vieraskäyttäjät, jotka voivat muokata ja hallita sisältöä.

Katso seuraavaa kaaviota. Kaavion numeroidut vaiheet on kuvattu seuraavissa kappaleissa.

Kaaviossa Ash toimii Contoson kanssa ja käyttää Fabrikamin toimittamia tietoja. Power BI Desktopin avulla Ash luo DirectQuery-yhteyden Analysis Services -malliin, jota isännöidään Fabrikamin vuokraajassa.

Todennuksena Ash käyttää B2B-vieraskäyttäjätietoja (kaavion vaihe 1).

Jos raportti julkaistaan Contoson Power BI -palvelu (vaihe 2), Contoso-vuokraajassa julkaistu semanttinen malli ei voi suorittaa todennusta Fabrikamin Analysis Services -mallin mukaisesti (vaihe 3). Tämän seurauksena raportti ei toimi.

Tässä skenaariossa, koska käytetty Analysis Services -malli isännöi Fabrikamin vuokraajaa, raportti on julkaistava myös Fabrikamin vuokraajassa. Kun julkaiseminen Fabrikamin vuokraajassa (vaihe 4) onnistui, semanttinen malli voi käyttää Analysis Services -mallia (vaihe 5) onnistuneesti, ja raportti toimii oikein.

Objektitason suojauksen käsitteleminen

Kun yhdistelmämalli noutaa tietoja Power BI:n semanttisesta mallista tai Analysis Servicesistä DirectQueryn kautta ja kyseinen lähdemalli suojataan objektitason suojauksella, yhdistelmämallin kuluttajat saattavat huomata odottamattomia tuloksia. Seuraavassa osiossa kerrotaan, miten nämä tulokset voivat syntyä.

Objektitason suojauksen (OLS) avulla mallin tekijät voivat piilottaa objekteja, jotka muodostavat mallin rakenteen (eli taulukot, sarakkeet, metatiedot jne.) mallin kuluttajilta (esimerkiksi raportin muodostimelta tai yhdistelmämallin tekijältä). Määrittäessään OLS-objektia mallin tekijä luo roolin ja poistaa sitten -objektin käyttöoikeuden käyttäjiltä, jotka on määritetty kyseiseen rooliin. Näiden käyttäjien näkökulmasta piilotettua objektia ei yksinkertaisesti ole.

OLS on määritetty lähdemallille ja käytössä siinä. Sitä ei voi määrittää lähdemalliin rakennetulle yhdistelmämallille.

Kun yhdistelmämalli on luotu OLS-suojatun Power BI -semanttisen mallin tai Analysis Services -mallin päälle DirectQuery-yhteyden kautta, lähdemallin mallirakenne kopioidaan yhdistelmämalliin. Kopioitavat tiedot määräytyvät sen mukaan, mitä yhdistelmämallin tekijä saa nähdä lähdemallissa sitä koskevien OLS-sääntöjen mukaisesti. Tietoja ei kopioida yhdistelmämalliin, vaan ne noudetaan aina DirectQueryn kautta lähdemallista tarvittaessa. Toisin sanoen tietojen nouto palaa aina lähdemalliin, jossa sovelletaan OLS-sääntöjä.

Koska yhdistelmämallia ei suojata OLS-säännöillä, yhdistelmämallin kuluttajat näkevät ne objektit, jotka yhdistelmämallin tekijä voi nähdä lähdemallissa sen sijaan, että niillä itsellään olisi käyttöoikeus. Tämä voi johtaa seuraaviin tilanteisiin:

• Yhdistelmämallia tarkastelemalla henkilö saattaa nähdä objekteja, jotka on piilotettu heiltä OLS-lähdemallissa.
• Sitä vastoin he eivät välttämättä näe yhdistelmämallissa objektia, jonka he voivat nähdä lähdemallissa, koska tämä objekti oli piilotettu yhdistelmämallin tekijältä OLS-säännöillä, jotka ohjaavat lähdemallin käyttöä.

Tärkeä seikka on se, että ensimmäisessä tiedotteessa kuvatusta tapauksesta huolimatta yhdistelmämallin kuluttajat eivät koskaan näe todellisia tietoja, joita heidän ei pitäisi nähdä, koska tiedot eivät sijaitse yhdistelmämallissa. Sen sijaan DirectQueryn vuoksi se noudetaan tarpeen mukaan lähteen semanttisesta mallista, jossa OLS estää luvattoman käytön.

Pidä tämä mielessä seuraavasti:

1. Hallinta_user julkaissut yrityksen semanttisen mallin, joka käyttää Power BI:n semanttista mallia tai Analysis Services -mallia, jossa on Asiakas-taulukko ja Alue-taulukko. Hallinta_user julkaisee semanttisen mallin Power BI -palvelu ja määrittää OLS-säännöt, joilla on seuraava vaikutus:

   • Talous-käyttäjät eivät näe Asiakas-taulukkoa
   • Markkinoinnin käyttäjät eivät näe Alue-taulukkoa

2. Finance_user julkaisee semanttisen mallin nimeltä "Talous-semanttinen malli" ja raportin nimeltä "Talousraportti", joka muodostaa yhteyden DirectQueryn kautta vaiheessa 1 julkaistuun yrityksen semanttiseen malliin. Talous-raportti sisältää visualisoinnin, joka käyttää Territory-taulukon saraketta.

3. Marketing_user avaa Talous-raportin. Visualisointi, joka käyttää Territory-taulukkoa, näytetään, mutta palauttaa virheen, koska kun raportti avataan, DirectQuery yrittää noutaa tiedot lähdemallista käyttämällä Marketing_user tunnistetiedoilla. Käyttäjä ei saa nähdä Alue-taulukkoa yrityksen semanttisen mallin OLS-sääntöjen mukaisesti.

4. Marketing_user luo uuden raportin nimeltä "Markkinointiraportti", jonka lähteenä on talous-semanttinen malli. Kenttäluettelossa näkyvät taulukot ja sarakkeet, joihin Finance_user voivat käyttää. Näin ollen Alue-taulukko näkyy Kentät-luettelossa, mutta Asiakas-taulukko ei. Kun Marketing_user yrittää luoda visualisoinnin, joka käyttää saraketta Alue-taulukosta, palautetaan kuitenkin virhe, koska tässä vaiheessa DirectQuery yrittää noutaa tietoja lähdemallista käyttämällä Marketing_user tunnistetietoja, ja OLS-säännöt käynnistyvät ja estävät käytön uudelleen. Sama tapahtuu, kun Marketing_user luo uuden semanttisen mallin ja raportin, joka muodostaa yhteyden talous-semanttiseen malliin DirectQuery-yhteydellä. He näkevät Alue-taulukon kentät-luettelossa, koska näin Finance_user voi nähdä. Kun hän yrittää luoda kyseistä taulukkoa käyttävän visualisoinnin, yrityssmanttisen mallin OLS-säännöt estävät ne.

5. Oletetaan sitten, että Hallinta_user päivittää yrityksen semanttisen mallin OLS-säännöt, jotta Finance ei näe Territory-taulukkoa.

6. Päivitetyt OLS-säännöt näkyvät talous-semanttisessa mallissa vain, kun se päivitetään. Kun Finance_user päivittää talous-semanttisen mallin, Alue-taulukkoa ei enää näytetä Kentät-luettelossa. Lisäksi Talous-raportin visualisointi, joka käyttää Territory-taulukon saraketta, palauttaa virheen Finance_user, koska heillä ei nyt ole oikeutta käyttää Territory-taulukkoa.

Yhteenveto:

• Yhdistelmämallin kuluttajat näkevät niiden OLS-sääntöjen tulokset, joita voidaan soveltaa yhdistelmämallin tekijään mallia luotaessa. Näin ollen, kun uusi raportti luodaan yhdistelmämallin perusteella, kenttäluettelossa näytetään taulukot, joihin yhdistelmämallin tekijällä oli käyttöoikeus mallia luodessaan, riippumatta siitä, mihin nykyisellä käyttäjällä on käyttöoikeus lähdemallissa.
• OLS-sääntöjä ei voi määrittää yhdistelmämallissa itse.
• Yhdistelmämallin kuluttaja ei koskaan näe varsinaisia tietoja, joita hänen ei pitäisi nähdä, koska lähdemallin asianmukaiset OLS-säännöt estävät niitä, kun DirectQuery yrittää noutaa tietoja tunnistetiedoillaan.
• Jos lähdemalli päivittää OLS-sääntönsä, nämä muutokset vaikuttavat yhdistelmämalliin vain, kun se päivitetään.

Taulukoiden alijoukon lataaminen Power BI:n semanttisesta mallista tai Analysis Services -mallista

Kun muodostat yhteyttä Power BI:n semanttiseen malliin tai Analysis Services -malliin DirectQuery-yhteyden avulla, voit päättää, mihin taulukoihin muodostat yhteyden. Voit myös lisätä automaattisesti minkä tahansa taulukon, joka lisätään semanttiseen malliin tai malliin, kun olet muodostanut yhteyden malliin. Kun muodostat yhteyden perspektiiviin, mallisi sisältää kaikki semanttisen mallin taulukot ja kaikki taulukot, jotka eivät sisälly perspektiiviin, ovat piilotettuja. Lisäksi mikä tahansa taulukko, joka saatetaan lisätä perspektiiviin, lisätään automaattisesti. Asetukset valikossa voit yhdistää automaattisesti taulukoihin, jotka lisätään semanttiseen malliin, kun olet määrittänyt yhteyden ensimmäisen kerran.

Tämä valintaikkuna ei näy reaaliaikaisille yhteyksille.

Muistiinpano

Tämä valintaikkuna näkyy vain, jos lisäät DirectQuery-yhteyden Power BI:n semanttiseen malliin tai Analysis Services -malliin aiemmin luotuun malliin. Voit avata tämän valintaikkunan myös muuttamalla DirectQuery-yhteyttä Tietolähdeasetukset-kohdan semanttiseen Power BI- tai Analysis Services -malliin luomisen jälkeen.

Määrityssäännöt

Voit määrittää mittarien ja taulukoiden nimet yksilöivät deduplication-säännöt käyttämällä aiemmin näytetyssä valintaikkunassa Asetukset-vaihtoehtoa:

Edellisessä esimerkissä lisäsimme jälkiliitteenä minkä tahansa taulukon tai mittarin nimen, joka on ristiriidassa toisen lähteen kanssa yhdistelmämallissa. Voit tehdä seuraavia toimintoja:

• kirjoita ristiriitaisten taulukoiden tai mittareiden nimeen lisättävä teksti
• määritä, haluatko lisätä tekstin taulukkoon vai mittayksikön nimeen etuliitteenä vai jälkiliitteenä
• käytä deduplication-sääntöä taulukoissa, mittareissa tai molemmissa
• Valitse käyttää deduplication-sääntöä vain, kun nimiristiriita ilmenee, tai käytä sitä koko ajan. Oletusarvona on käyttää sääntöä vain kaksoiskappaleen ilmetessä. Tässä esimerkissä mikään markkinointilähteen taulukko tai mittari, jolla ei ole kaksoiskappaletta myyntilähteessä, ei saa nimenmuutosta.

Kun olet muodostanut yhteydet ja määrittänyt deduplication-säännön, kenttäluettelossasi näkyvät sekä "Asiakas" että "Asiakas (markkinointi)" esimerkissä määritetyn deduplication-säännön mukaisesti:

Jos et määritä deduplication-sääntöä tai määrittämäsi deduplication-säännöt eivät ratkaise nimiristiriitaa, vakiomuotoisia deduplicaatiosääntöjä sovelletaan edelleen. Vakiomuotoiset suodatussäännöt lisäävät luvun ristiriitaisen kohteen nimeen. Jos Customer-taulukossa on nimiristiriita, yksi Customer-taulukoista nimetään uudelleen Nimellä Customer 2.

Huomioitavat asiat ja rajoitukset

Yhdistelmämalleissa on muutamia huomioon otettavia seikkoja ja rajoituksia:

Yhdistelmätilan yhteydet – Kun käytät yhdistelmätilaa, joka sisältää online-tietoja (kuten Power BI:n semanttisen mallin) ja paikallisen semanttisen mallin (kuten Excel-työkirjan), sinulla on oltava yhdyskäytävän yhdistämismääritys määritettynä, jotta visualisoinnit näkyvät oikein.

Tällä hetkellä yhdistelmämallien asteittaista päivittämistä tuetaan vain SQL-, Oracle- ja Teradata-tietolähteisiin yhdistettäessä.

Seuraavia reaaliaikaisia Näyttöyhteys taulukkomuotoisia lähteitä ei voi käyttää yhdistelmämallien kanssa:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services, aiempi kuin versio 2022
• Käyttötiedot (Oma työtila)

Semanttisten virtautettavien mallien käyttämistä yhdistelmämalleissa ei tueta.

DirectQueryn olemassa olevat rajoitukset koskevat edelleen yhdistelmämallien käyttämistä. Monet näistä rajoituksista ovat nyt taulukkokohtaisia ja riippuvat taulukon tallennustilan tilasta. Esimerkiksi tuontitaulukon laskettu sarake voi viitata muihin taulukoihin, jotka eivät ole DirectQueryssä, mutta DirectQuery-taulukon laskettu sarake voi viitata vain saman taulukon sarakkeisiin. Muut rajoitukset koskevat vain mallia kokonaisuutena, jos jokin mallin taulukoista on DirectQuery-taulukko. Esimerkiksi QuickInsights-ominaisuus ei ole käytettävissä mallissa, jos jollakin sen taulukoista on DirectQuery-tallennustilan tila.

Jos käytät rivitason suojausta yhdistelmämallissa ja jotkin DirectQuery-tilan taulukot, malli on päivitettävä, jotta directquery-taulukoista voidaan ottaa käyttöön uusia päivityksiä. Jos Esimerkiksi DirectQuery-tilassa olevalla Käyttäjät-taulukolla on uusia käyttäjätietueita lähteessä, uudet tietueet sisällytetään vain mallin seuraavan päivityksen jälkeen. Power BI -palvelu tallentaa Käyttäjät-kyselyn välimuistiin suorituskyvyn parantamiseksi. Se lataa tiedot lähteestä vasta seuraavaan manuaaliseen tai ajoitettuun päivitykseen.

Liittyvä sisältö

Lisätietoja yhdistelmämalleista ja DirectQuerysta on seuraavissa artikkeleissa:

• Monta moneen -yhteyksien käyttäminen Power BI Desktopissa
• Tallennustilan hallinta Power BI Desktopissa
• DirectQuery Power BI:ssä
• Power BI -tietolähteet
• Mallien suhteet Power BI Desktopissa