Suunnittelutähtiskeema semanttisille malleille
Sinä valitsit, miten data virtaa semanttiseen malliisi. Suunnittele nyt tähtiskeema, joka järjestää sen selkeitä ja suorituskykyisiä kyselyitä varten. Tähtikaavio yhdistää faktataulut ulottuvuustaulukoihin suhteiden kautta, luoden suodatinpolut, joihin raportit ja tekoälyn kulutus perustuvat. Jos tunnet tähtiskeeman rakentamisen Power BI Desktopissa, tämä yksikkö keskittyy suhteiden suunnittelupäätöksiin, joilla on merkitystä mallien monimutkaisuuden ja mittakaavan kasvaessa.
Tähtiskeema semanttisessa mallissa
Tähtikaaviossa faktataulut tallentavat mitattavat liiketoimintatapahtumat (kuten myyntitapahtumat, tilausrivit ja verkkokäynnit), ja dimensiotaulut tarjoavat kuvailevan kontekstin (kuten tuotetiedot, asiakastiedot ja päivämäärättribuutit). Dimensiotaulut suodattavat faktatauluja suhteiden kautta, jolloin käyttäjät voivat viipaloida mittareita minkä tahansalaisen kuvailevan attribuutin mukaan.
Fabric-semanttisessa mallissa tämä kuvio tarjoaa puhtaan suodattimen leviämisen sekä raportteihin että tekoälyn kulutukseen. Kun Copilot tai dataagentti generoi luonnollisen kielen kyselyn, hyvin järjestetty tähtiskeema antaa tekoälylle selkeät reitit oikeaan dataan. Epämääräiset tai kehämäiset suhteet sekoittavat sekä raportointikuluttajia että tekoälytyökaluja.
Miten tallennustila vaikuttaa ihmissuhteisiin
Semanttisen mallin suhteet käyttäytyvät eri tavoin tallennustilan mukaan. Näiden erojen ymmärtäminen on olennaista, jotta voidaan suunnitella tähtiskeema, joka toimii hyvin eri tilanteissa.
Suorat järven suhteet
Direct Lake -tilassa moottori lukee suhteita suoraan Delta-taulukon metatiedoista. Parisuhteet toimivat parhaiten, kun:
- Dimensioavainsarakkeilla on matala kardinaalisuus suhteessa faktataulun riveihin.
- Lähdeaineistossa säilytetään referenttiaalinen eheys. Kun referenttiaalinen eheys pysyy, moottori käyttää SISÄISIÄ liitoksia VASEMMAN ULKOISTEN liitoksien sijaan, mikä parantaa kyselyjen suorituskykyä.
- Suhteissa käytetyt sarakkeet indeksoidaan taustalla oleviin Delta-taulukoihin.
Huomautus
Jos kysely sisältää suhteen, joka saa mallin ylittämään muistirajat tai käyttämään tuettomia operaatioita, Direct Lake palaa DirectQueryyn, ja suhteen käyttäytyminen muuttuu vastaamaan DirectQueryn semantiikkaa.
Lähteiden väliset suhteet
Fabric-semanttiset mallit voivat yhdistää taulukoita eri tietovarastoista. Faktataululla järvenrakennuksesta voi olla suhde varaston dimensiotauluun tai SQL-analytiikkapäätepisteen kautta saavutettuun taulukkoon. Nämä ristiinlähteiset yhteydet hyödyntävät yhdistelmämallin ominaisuuksia.
Kun taulukot tulevat eri lähteistä, kunkin taulun tallennustila määrittää, miten suhde toimii kyselyn aikana. Moottori ratkaisee kummankin puolen erikseen ja yhdistää tulokset.
Suhdetyypit
Yksi-moneen-suhteet
Yksi-moneen on yleisin suhdetyyppi tähtikaaviossa. Yksi yksikäsitteinen arvo ulottuvuustaulukossa liittyy moniin riveihin faktataulussa. Esimerkiksi yksi tuoterivi Tuote-ulottuvuudessa vastaa tuhansia tilausrivejä Myynti-faktataulussa.
Määritä yksi-moneen -suhteet siten, että suodattimen suunta kulkee ulottuvuudesta ("yksi" puoli) faktatauluun ("moni"-puoli). Tämä on standardi tähtiskeeman suodatinkuvio.
Monta moneen -yhteydet
Moni-moneen-suhteet ovat välttämättömiä, jos kummallakaan taululla ei ole ainutlaatuisia arvoja suhdesarakkeelle. Käytä siltataulukkoa näiden suhteiden ratkaisemiseen. Siltapöytä sijaitsee kahden pöydän välissä ja sisältää ainutlaatuiset näppäinyhdistelmät kummaltakin puolelta.
Esimerkiksi, jos asiakkaalla voi olla useita tilejä ja tili voi kuulua useammalle asiakkaalle, Customer-Account siltataulukko ratkaisee suhteen. Siltataululla on yksi-monen suhde sekä asiakas- että tilitauluihin.
Suodatuksen suunta
Useimmissa tähtiskeeman toteutuksissa käytetään yksisuuntaista suodatusta ulottuvuudesta faktaan. Tämä mahdollistaa ennustettavan suodattimen etenemisen ja välttää kyselytulosten epäselvyyden.
Kaksisuuntainen suodatus on joskus tarpeen monen-moneen suhteissa tai silloin, kun dimensiotauluja täytyy suodattaa faktataulun arvojen mukaan. Käytä kaksisuuntaisia suodattimia säästeliäästi, koska ne voivat heikentää kyselyjen suorituskykyä ja aiheuttaa odottamatonta suodatinkäyttäytymistä raporteissa.
Referenttiaalinen eheys
Oletetaan referenttiaalinen eheysasetus käskee moottoria käyttämään SISÄISIÄ liitoksia VASEMMAN ULKOISTEN liitoksien sijaan, kun kyseletään suhteen yli. Direct Lake- ja DirectQuery-tiloissa tämä asetus voi merkittävästi parantaa suorituskykyä, koska se vähentää moottorin käsittelemien rivien määrää.
Ota tämä asetus käyttöön, kun olet varma, että jokaisella faktataulun vierasavainarvolla on vastaava arvo ulottuvuustaulukossa. Jos referenttiaalinen eheys rikotaan, rivit, joilla on yhdistämättömät avaimet, katoavat hiljaisesti kyselytuloksista.
Passiiviset suhteet ja KÄYTTÖSUHDE
Kahden pöydän välillä voi olla vain yksi aktiivinen suhde kerrallaan. Kun tarvitset useita suhdepolkuja (kuten tilauspäivä ja lähetyspäivä, jotka molemmat liittyvät samaan päivämäärä-ulottuvuuteen), tee yhdestä suhteesta aktiivinen ja toinen passiivinen.
Käytä DAX-funktiota USERELATIONSHIP aktivoidaksesi inaktiivisen suhteen laskennassa:
Shipped Amount =
CALCULATE(
SUM(Sales[Amount]),
USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)
Tämä malli pitää mallin puhtaana samalla kun se tukee useita analyyttisiä näkökulmia samoihin tietoihin.
Käsitelty lumihiutaleskeema semanttisissa malleissa
Lähdedata saapuu usein normalisoidussa lumihiutalekaaviossa, jossa dimensiotaulut jaetaan useisiin toisiinsa liittyviin tauluihin. Esimerkiksi tuotedimensio voidaan jakaa Tuote-, Alakategoria- ja Kategoria-tauluihin, joista jokainen on linkitetty vieraiden avainten kautta.
Semanttisessa mallissa on kaksi vaihtoehtoa: litistää lumihiutale tähtikaavioksi tai säilyttää normalisoitu rakenne.
Litisty tähtikaavioon
Litistäminen tarkoittaa normalisoitujen dimensioiden yhdistämistä yhdeksi denormalisoiduksi dimensiotauluksi. Product-taulukko sisältäisi suoraan Alakategoria- ja Kategoria-sarakkeet, jolloin ylimääräiset taulukot ja suhteet poistuvat.
Litistetään, kun:
- Yhdistetty dimensiotaulu on edelleen pieni suhteessa faktatauluun (mikä on lähes aina tilanne ulottuvuuksien kohdalla).
- Haluat yksinkertaisemmat suodatinreitit ulottuvuudesta faktaan. Jokainen suodatin kulkee yhden suhteen kautta ketjun sijaan.
- Tekoälyn kulutus on etusijalla. Vähemmän taulukoita ja yksinkertaisemmat suhteet antavat Copilot- ja dataagenteille selkeämmät reitit oikeaan dataan.
Tasoita dimensiotaulut datan valmistelun aikana järvitaloissa tai datavirroissa ennen kuin data saavuttaa semanttisen mallin. Käytä Power Query -yhdistelmiä, SQL-liitoksia tai muistikirjan muunnoksia yhdistääksesi normalisoidut taulut yhdeksi ulottuvuudeksi.
Säilytä lumihiutalerakenne
Joissain tapauksissa normalisoidun rakenteen säilyttäminen on järkevää:
- Ulottuvuuksien hierarkiassa on useita tasoja, ja tasoittaminen aiheuttaisi kymmeniä päällekkäisiä sarakkeita.
- Useat faktataulut jakavat alidimensiotauluja (kuten jaettu kategoriataulu, jota käyttävät sekä myynti- että varastotiedot), ja denormalisointi loisi epäjohdonmukaisia kopioita.
- Rivitason turvallisuus täytyy soveltaa hierarkian tietyllä tasolla.
Kun säilytät lumihiutalerakenteen, konfiguroi suhteet huolellisesti. Jokaisen ketjun suhteen on käytettävä yksisuuntaista suodatusta ulimmasta taulukosta faktatauluun, jotta suodattimet etenevät oikein. Suodatin Kategoriassa täytyy kulkea Alakategorian läpi, sitten Tuotteen kautta ja faktatauluun.
Huomautus
Useimmissa semanttisissa malliskenaarioissa dimensioiden tasoittaminen tähtikaavioksi on parempi valinta. Vähemmän taulukoita tarkoittaa vähemmän suhteita, yksinkertaisempaa DAXia, nopeampia kyselyjä ja parempaa tekoälyn kulutusta. Säilytä lumihiutalerakenne vain, kun siihen on vahva syy.
Milloin yhdistetyt mallit tulisi käyttää eri lähteiden välisissä skenaarioissa
Käytä komposiittimalleja, kun tähtiskeemasi kattaa useita Fabric-tietovarastoja tai sisältää ulkoisia lähteitä. Yleisiä skenaarioita ovat seuraavat:
- Faktataulukot järvimajassa, ja mittotaulukot säilytetään varastossa.
- Reaaliaikaista suoratoistodataa tapahtumatalosta yhdistettynä järvimajon historiallisiin tietoihin.
- Viitedata ulkoisesta lähteestä (Import) yhdistettynä Fabric-alkuperäisiin faktatauluihin (Direct Lake).
Näissä tilanteissa konfiguroi tallennustila jokaiselle taululle erikseen ja varmista, että lähteiden väliset suhteet toimivat hyväksyttävästi odotetuilla datavolyymeilla.