Tapahtumat
Liity seuraamme FabCon Vegasiin
31. maalisk. klo 23 - 2. huhtik. klo 23
Lopullinen Microsoft Fabric-, Power BI-, SQL- ja tekoälyyhteisöjohtoinen tapahtuma. 31.3.–2.4.2025.
Rekisteröidy jo tänäänTätä selainta ei enää tueta.
Päivitä Microsoft Edgeen, jotta voit hyödyntää uusimpia ominaisuuksia, suojauspäivityksiä ja teknistä tukea.
Tämä artikkeli on suunnattu Power BI Desktopin tietomallintajille. Artikkelissa kuvaillaan tähtirakenne ja sen merkitys, kun kehitetään suorituskykyyn ja käytettävyyteen optimoituja Power BI:n semanttisia malleja.
Tärkeä
Semanttiset Power BI -mallit ovat riippuvaisia Power Querysta tietojen tuomista tai niihin yhdistämistä varten. Tämä tarkoittaa sitä, että sinun on käytettävä Power Queryä lähdetietojen muuntamiseen ja valmisteluun, mikä voi olla haastavaa, kun tietomääriä on paljon, tai kun sinun on otettava käyttöön kehittyneitä käsitteitä, kuten hitaasti muuttuvia dimensioita (kuvataan myöhemmin tässä artikkelissa).
Kun sinulle esitetään nämä haasteet, suosittelemme, että kehität ensin tietovaraston sekä Poimi-, Muunna- ja Lataa (ETL) -prosessit, jotta voit ladata tietovaraston säännöllisin väliajoin. Semanttinen malli voi sitten muodostaa yhteyden tietovarastoon. Lisätietoja on artikkelissa Dimensiomallinnus Microsoft Fabric Warehousessa.
Vihje
Tämän artikkelin tarkoituksena ei ole käydä tähtirakennetta läpi kokonaisvaltaisesti. Lisätietoja on suoraan laajasti hyväksytyssä julkaistussa sisällössä, kuten The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3. painos, 2013), Ralph Kimball ja muut.
Tähtirakenne on kypsä mallinnusmenetelmä, joka on laajasti käytössä relaatiotietovarastoissa. Tämä edellyttää, että mallintajat luokittelevat mallitaulukot joko dimensioksi tai faktaksi.
Date
ja ProductKey
. On helppo ymmärtää, että taulukossa on kaksi dimensiota. Rakeisuutta ei kuitenkaan voida määrittää ottamatta huomioon dimension avainarvoja. Tässä esimerkissä otetaan huomioon, että sarakkeeseen Date
tallennetut arvot ovat kunkin kuukauden ensimmäinen päivä. Tässä tapauksessa rakeisuus on kuukauden tuotetasolla.Yleensä dimensiotaulukot sisältävät suhteellisen vähän rivejä. Faktataulukot taas voivat sisältää suuren määrän rivejä ja kasvaa ajan myötä.
Tässä artikkelissa kuvattujen tähtirakenteen käsitteiden ymmärtämiseksi on tärkeää tuntea kaksi termiä: normalisointi ja denormalisointi.
Normalisointi on termi, jota käytetään kuvaamaan tietoja, jotka on tallennettu tavalla, joka vähentää toistuvia tietoja. Otetaan esimerkiksi tuotetaulukko, jossa on yksilöivä avainarvosarake, kuten tuoteavain, ja muut sarakkeet, jotka kuvaavat tuotteiden ominaisuuksia, kuten tuotteen nimeä, luokkaa, väriä ja kokoa. Myyntitaulukkoa pidetään normalisoituna, kun se tallentaa vain avaimia, kuten tuoteavaimen. Huomaa, että seuraavassa kuvassa vain ProductKey
sarake kirjaa tuotteen.
Jos myyntitaulukko kuitenkin tallentaa tuotetiedot avaimen ulkopuolelle, sitä pidetään denormalisoituna. Huomaa seuraavassa kuvassa, että tuotteeseen ProductKey
liittyvät sarakkeet ja muut tuotteisiin liittyvät sarakkeet tallentavat tuotteen.
Kun lähdetiedot ovat vientitiedostosta tai tietokatkelmasta, on todennäköistä, että ne edustavat denormalisoitua tietojoukkoa. Tässä tapauksessa voit Power Queryn avulla muuntaa ja muotoilla lähdetiedot useisiin normalisoituihin taulukoihin.
Kuten tässä artikkelissa on kuvattu, sinun tulee pyrkiä kehittämään optimoituja Power BI:n semanttisia malleja, joissa on normalisoituja fakta- ja dimensiotietoja edustavia taulukoita. On kuitenkin yksi poikkeus, jossa Snowflake-dimensio saatetaan denormalisoida yksittäisen mallitaulukon tuottamiseksi.
Tähtirakenne ja monet tässä artikkelissa esitellyt liitännäiskäsitteet ovat erittäin merkityksellisiä suorituskyvyn ja käytettävyyden kannalta optimoitujen Power BI -mallien kehittämisessä.
Huomaa, että jokainen Power BI -raportin visualisointi luo kyselyn, joka lähetetään Power BI:n semanttiseen malliin. Yleensä kyselyt suodattavat, ryhmittelevät ja vetävät yhteen mallin tiedot. Hyvin suunniteltu malli on siis sellainen, joka tarjoaa taulukoita suodatusta ja ryhmittelyä varten ja taulukoita yhteenvedon luomista varten. Tämä malli sopii hyvin tähtirakenteen periaatteisiin:
Mallintajat eivät ole määrittäneet taulukkotyypiksi dimensio- tai faktaominaisuutta. Se määritetään mallien yhteyksien perusteella. Malliyhteys muodostaa suodatuksen välityspolun kahden taulukon välille. Yhteyden kardinaliteettiominaisuus määrittää taulukkotyypin. Yleinen yhteyden kardinaliteetti on yksi moneen tai sen käänteinen vastakkain monta yhteen. "Yksi" puoli on aina dimensiotaulukko, kun taas "monta"-puoli on aina faktataulukko.
Hyvin jäsennetty mallirakenne sisältää taulukoita, jotka ovat joko dimensiotaulukoita tai faktataulukoita. Vältä kahden tyypin sekoittamista yhteen taulukkoon. Suosittelemme myös, että pyrit antamaan oikean määrän taulukoita, joihin on määritetty oikeat suhteet. On myös tärkeää, että faktataulukot lataavat aina tiedot yhdenmukaisella rakeilla.
Lopuksi on tärkeää ymmärtää, että optimaalinen mallirakenne on osatiede ja osataidetta. Joskus hyviä ohjeita kannattaa rikkoa, kun siitä on hyötyä.
Tähtirakenteeseen liittyy monia käsitteitä, joita voidaan käyttää Power BI:n semanttisessa mallissa. Näitä käsitteitä ovat esimerkiksi seuraavat:
Tähtirakenteessa mittari on faktataulukon sarake, johon on tallennettu yhteenvedossa käytettävät arvot. Semanttisessa Power BI -mallissa mittarin määritelmä on erilainen, mutta samankaltainen. Malli tukee sekä eksplisiittisiä että implisiittisiä mittareita.
SUM
, MIN
MAX
, AVERAGE
ja muita, skalaariarvotuloksen tuottamiseen kyselyn aikana (arvoja ei koskaan tallenneta malliin). Mittayksikkölauseke voi vaihdella yksinkertaisesta sarakekoostuksesta kehittyneeseen kaavaan, joka ohittaa suodatinkontekstin ja/tai yhteyden välityksen. Lisätietoja on artikkelissa DAX-perusteet Power BI Desktopissa.Sales Amount
sarake voidaan vetää yhteen monella tavalla (summa, määrä, keskiarvo, mediaani, minimi, maksimi ja muut), ilman, että tarvitsee luoda mittari jokaiselle mahdolliselle koostamistyypille.Tiedot-ruudussa eksplisiittisiä mittareita edustaa laskinkuvake, kun taas implisiittisiä mittareita edustaa sigma-symboli (∑).
Mittareiden luomiseen on kuitenkin kolme vakuuttavaa syytä myös yksinkertaisissa saraketason yhteenvedoissa:
Kun tiedät, että raportin tekijät tekevät kyselyn semanttiseen malliin MDX-lausekkeella, mallissa on oltava eksplisiittisiä mittareita. Tämä johtuu siitä, että MDX ei voi vetää yhteen sarakearvoja. MDX:ää käytetään etenkin Analysoi Excelissä -toimintoa käytettäessä, koska Pivot-taulukot tekevät MDX-kyselyitä.
Kun tiedät, että raportin tekijät luovat Power BI:n sivutettuja raportteja MDX-kyselyjen suunnittelutyökalulla, semanttisen mallin on sisällettävä eksplisiittisiä mittareita. Vain MDX-kyselyjen suunnittelutyökalu tukee palvelimen koosteita. Jos Power BI:n on arvioitava raportin tekijöiden mittarit (sivutettujen raporttien moduulin sijaan), heidän on käytettävä MDX-kyselyjen suunnittelutyökalua.
Kun haluat hallita sitä, miten raportin tekijät tekevät yhteenvedon sarakkeista tietyllä tavalla. Esimerkiksi jälleenmyyjän myyntisarakkeeseen Unit Price
(joka edustaa yksikkökohtaista hintaa) voidaan tehdä yhteenveto, mutta vain käyttämällä tiettyjä koostamisfunktioita. Sitä ei tule koskaan laskea yhteen, mutta se voidaan tiivistää käyttämällä muita koostamisfunktioita (esimerkiksi minimi, maksimi tai keskiarvo). Tässä esiintymässä mallintaja voi piilottaa sarakkeen Unit Price
ja luoda mittareita kaikille sopiville koostamisfunktioille.
Tämä rakennemenetelmä toimii hyvin Power BI -palvelussa ja Q&A:ssa laadituille raporteille. Power BI Desktopin reaaliaikaisten yhteyksien avulla raportin tekijät voivat kuitenkin näyttää Tieto-ruudussa piilotetut kentät, minkä ansiosta tämä rakennemenetelmä voidaan kiertää.
Korvaava avain on yksilöivä tunniste, joka lisätään taulukkoon tähtirakenteen tukemiseksi. Määrittelyn mukaan sitä ei ole määritetty tai tallennettu lähdetietoihin. Yleensä korvaavat avaimet lisätään relaatiotietovaraston dimensiotaulukoihin, jotta kullekin dimensiotaulukon riville voidaan antaa yksilöivä tunnus.
Power BI:n semanttiset malliyhteydet perustuvat yksittäiseen yksilöivään sarakkeeseen yhdessä taulukossa, joka levittää suodattimia yksittäiseen sarakkeeseen eri taulukossa. Kun semanttisen mallin dimensiotaulukko ei sisällä yksittäistä yksilöivää saraketta, sinun on lisättävä yksilöivä tunnus, josta tulee suhteen "yksi"-puoli. Power BI Desktopissa tämä vaatimus voidaan toteuttaa lisäämällä Power Query - indeksisarake.
Tämä kysely on yhdistettävä "monta"-puolen kyselyyn, jotta siihenkin voi lisätä indeksisarakkeen. Kun lataat nämä kyselyt semanttiseen malliin, voit luoda yksi moneen -suhteen mallitaulukoiden välille.
Snowflake-dimensio on joukko normalisoituja taulukoita yksittäiselle liiketoimintaentiteetille. Esimerkiksi Adventure Works luokittelee tuotteet luokan ja aliluokan mukaan. Tuotteet on määritetty aliluokkiin, ja aliluokat on puolestaan määritetty luokkiin. Adventure Works -relaatiotietovarastossa tuotedimensio normalisoidaan ja tallennetaan kolmeen liittyvään taulukkoon: DimProductCategory
, DimProductSubcategory
ja DimProduct
.
Mielikuvitusta hyödyntäen voit kuvitella normalisoidut taulukot sijoitettuina ulospäin faktataulukosta, mistä syntyy Snowflake-rakenne.
Power BI Desktopissa voit halutessasi jäljitellä Snowflake-dimensiorakennetta (koska lähdetiedot tekevät niin) tai yhdistää lähdetaulukot muodostamaan yksittäisen, denormalisoidun mallitaulukon. Yleensä yksittäisen mallitaulukon edut ovat merkittävämpiä kuin useista mallitaulukoista saatavat edut. Optimaalinen päätös voi riippua mallin tietomääristä ja käytettävyysvaatimuksista.
Kun päätät jäljitellä Snowflake-dimension rakennetta:
Kun päätät integroida yksittäiseen mallitaulukkoon, voit myös määrittää hierarkian, joka kattaa dimension suurimman ja pienimmän rakeen. Tarpeettomien denormalisoitujen tietojen tallennus voi kasvattaa mallin tallennuskokoa erityisesti suurissa dimensiotaulukoissa.
Hitaasti muuttuva dimensio (tai hitaasti muuttuva dimensio) on sellainen, joka hallitsee dimension jäsenten muutosta ajan mittaan asianmukaisesti. Sitä käytetään, kun liiketoimintaentiteetin arvot muuttuvat hitaasti ajan mittaan suunnittelemattomalla tavalla. Hyvä esimerkki hitaasti muuttuvasta dimensiosta on asiakasdimensio, koska sen yhteystietosarakkeet, kuten sähköpostiosoite ja puhelinnumero, muuttuvat harvoin. Sen sijaan joidenkin dimensioiden katsotaan muuttuvan nopeasti , kun dimension määrite muuttuu usein, kuten varaston markkinahinta. Näissä tapauksissa yleinen rakennemenetelmä on tallentaa nopeasti muuttuvat määritearvot faktataulukon mittariin.
Tähtirakenneteoriassa viitataan kahteen yleiseen hitaasti muuttuvan dimension tyyppiin: tyyppi 1 ja tyyppi 2. Dimensiotaulukko voi olla tyyppiä 1 tai 2 tai tukea molempia tyyppejä samanaikaisesti eri sarakkeissa.
Tyypin 1 hitaasti muuttuva dimensio vastaa aina uusimpia arvoja. Kun lähdetiedoissa havaitaan muutoksia, dimensiotaulukon tiedot korvataan. Tämä rakennemenetelmä on yleinen sarakkeissa, joihin tallennetaan täydentäviä arvoja, kuten asiakkaan sähköpostiosoite tai puhelinnumero. Kun asiakkaan sähköpostiosoite tai puhelinnumero muuttuu, uudet arvot päivittyvät dimensiotaulukkoon asiakasriville. Vaikuttaa siltä, kuin asiakkaalla olisi aina ollut nämä yhteystiedot.
Power BI -mallin dimensiotaulukon ei-lisäävä päivitys saa aikaan tyypin 1 hitaasti muuttuvan dimension tuloksen. Taulukkotiedot päivitetään sen varmistamiseksi, että uusimmat arvot ladataan.
Tyypin 2 hitaasti muuttuva dimensio tukee dimension jäsenten versioinnia. Jos lähdejärjestelmä ei tallenna versioita, yleensä tietovaraston lataamisprosessi havaitsee muutokset ja hallitsee dimensiotaulukon muutosta asianmukaisella tavalla. Tässä tapauksessa dimensiotaulukon on käytettävä korvaavaa avainta, jotta dimension jäsenen versio saa yksilöivän viittauksen. Se sisältää myös sarakkeet, jotka määrittävät version päivämääräalueen (esimerkiksi StartDate
ja ) ja EndDate
mahdollisesti merkintäsarakkeen (esimerkiksi IsCurrent
), jotta suodattaminen nykyisten dimension jäsenten mukaan on helppoa.
Esimerkiksi Adventure Works määrittää jokaisen myyjän myyntialueelle. Kun myyjä siirtyy toiselle alueelle, myyjästä on luotava uusi versio sen varmistamiseksi, että historialliset tiedot pysyvät liitettynä entiseen alueeseen. Myyjän myyntihistorian tarkan analyysin tukemista varten dimensiotaulukkoon on talletettava myyjien ja myyjiin liittyvien alueiden versiot. Taulukossa on oltava myös ajan määrittävät alkamis- ja päättymispäivämäärän arvot. Nykyiset versiot saattavat määrittää tyhjän päättymispäivämäärän (tai 31.12.9999), mikä osoittaa, että rivi on nykyinen versio. Taulukossa on oltava myös korvaava avain , koska liiketoiminta-avain (tässä esiintymässä työntekijän tunnus) ei ole yksilöivä.
On tärkeää ymmärtää, että kun lähdetiedot eivät tallenna versioita, on käytettävä välijärjestelmää (kuten tietovarastoa) muutosten tunnistamiseen ja tallentamiseen. Taulukon lataamisprosessin on säilytettävä olemassa olevat tiedot ja havaittava muutokset. Kun muutos havaitaan, taulukon lataamisprosessin on vanhenettava nykyinen versio. Nämä muutokset tallentuvat EndDate
päivittämällä arvon ja lisäämällä uuden version, jonka StartDate
arvo alkaa edellisestä EndDate
arvosta. Aiheeseen liittyvissä faktoissa on lisäksi käytettävä aikapohjaista hakua dimension faktan päivämäärälle olennaisen avainarvon noutamiseksi. Semanttinen Power BI -malli käyttää Power Queryä, joten se ei voi tuottaa tätä tulosta. Se voi kuitenkin ladata tiedot valmiiksi ladatusta tyypin 2 hitaasti muuttuvan dimension taulukosta.
Vihje
Jos haluat oppia ottamaan käyttöön tyypin 2 hitaasti muuttuvan dimension taulukon Fabric-varastossa, katso Historiallisen muutoksen hallinta.
Power BI:n semanttisen mallin tulee tukea jäsenen historiallisten tietojen kyselyä muutoksesta riippumatta ja jäsenen version kyselyä, mikä edustaa jäsenen tiettyä tilaa tietyllä hetkellä. Adventure Worksin yhteydessä tämän mallin avulla voit tehdä myyjäkyselyn riippumatta määritetystä myyntialueesta tai kyselyn myyjän tietystä versiosta.
Tämän vaatimuksen saavuttamiseksi Power BI:n semanttisen mallin dimensiotaulukossa on oltava sarake myyjän suodatusta varten ja toinen sarake tietyn myyjän version suodatusta varten. On tärkeää, että versiosarake sisältää yksiselitteisen kuvauksen, kuten David Campbell (12/15/2008-06/26/2019)
tai David Campbell (06/27/2019-Current)
. On myös tärkeää kouluttaa raportin tekijöitä ja käyttäjiä tyypin 2 hitaasti muuttuvan dimension perusteista ja sopivien raporttimallien luomisesta käyttämällä oikeita suodattimia.
Hyvä rakennekäytäntö on sisällyttää hierarkia, jonka avulla visualisoinnit voivat porautua versiotasolle.
Rooliulottuvuus on dimensio, joka voi suodattaa liittyvät faktat eri tavalla. Esimerkiksi Adventure Worksissa päivämäärän dimensiotaulukolla on kolme yhteyttä jälleenmyyjän faktoihin. Samaa dimensiotaulukkoa voidaan käyttää suodattamaan faktat tilauspäivämäärän, lähetyspäivämäärän tai toimituspäivämäärän mukaan.
Tietovarastossa hyväksytty rakennemenetelmä on yksittäisen päivämäärän dimensiotaulukon määrittäminen. Kyselyn aikana päivämäärädimension "rooli" määräytyy sen mukaan, mitä faktasaraketta käytetään taulukoiden yhdistämiseen. Kun esimerkiksi myyntiä analysoidaan tilauspäivämäärän mukaan, taulukon yhdistäminen liittyy jälleenmyyjän myynnin tilauspäivämäärän sarakkeeseen.
Semanttisessa Power BI -mallissa tätä rakennetta voidaan jäljitellä luomalla useita yhteyksiä kahden taulukon välille. Adventure Worksin esimerkissä päivämäärän ja jälleenmyyjän myynnin taulukoissa on kolme yhteyttä.
Vaikka tämä rakenne on mahdollinen, kahden Power BI:n semanttisen mallitaulukon välillä voi olla vain yksi aktiivinen yhteys. Kaikki jäljellä olevat suhteet on asetettava passiivisiksi. Kun aktiivisia suhteita on yksi, käytettävissä on oletusarvoinen suodattimen lisäys päivämäärästä jälleenmyyjän myyntiin. Tässä esiintymässä aktiiviseksi yhteydellä määritetään yleisin raporttien käyttämä suodatin, joka Adventure Worksissa on tilauspäivämäärän yhteys.
Ainoa tapa käyttää passiivista suhdetta on määrittää DAX-lauseke, joka käyttää USERELATIONSHIP-funktiota . Esimerkissä mallin kehittäjän on luotava mittareita, joiden avulla voidaan analysoida jälleenmyyjän myynti lähetyspäivämäärän ja toimituspäivämäärän mukaan. Tämä voi olla työlästä etenkin silloin, kun jälleenmyyjätaulukko määrittää useita mittareita. Se luo myös tarpeettomia tietoruutuja , joissa on liikaa mittareita. Muita rajoituksia on myös:
Näiden rajoitusten ohittamiseksi Power BI -mallinnuksen avulla luodaan usein dimensiotaulukko kullekin rooliesiintymälle. Voit luoda kunkin dimensiotaulukon viittaavana kyselynä Power Queryn avulla tai laskettuna taulukkona DAX:n avulla. Malli voi sisältää Date
taulukon, Ship Date
taulukon ja taulukon, joilla kullakin on yksi aktiivinen yhteys jälleenmyyjän myyntitaulukon Delivery Date
sarakkeisiinsa.
Tämä rakennemenetelmä ei edellytä useiden mittareiden määrittämistä eri päivämäärärooleille ja se mahdollistaa samanaikaisen suodattamisen eri päivämääräroolien mukaan. Tässä rakennemenetelmässä ongelmana on se, että päivämäärän dimensiotaulukko monistetaan, minkä seurauksena mallin tallennuskoko kasvaa. Koska dimensiotaulukoissa on yleensä vähemmän rivejä suhteessa faktataulukoihin, tämä ei yleensä aiheuta huolta.
Suosittelemme, että noudatat hyvän suunnittelun käytäntöjä, kun luot mallin dimensiotaulukoita kullekin roolille:
Year
kaikissa päivämäärätaulukoissa (sarakkeiden nimet ovat yksilöllisiä taulukon sisällä), kyseessä ei ole itsestäänkuvaileva oletusarvoinen visualisoinnin otsikko. Harkitse sarakkeiden nimeämistä uudelleen kussakin dimensioroolin taulukossa siten, että Ship Date
taulukossa on vuosisarake, jonka nimi Ship Year
on , ja niin edelleen.Date
, jota käytetään useiden faktataulukoiden suodattamiseen. Jos tässä taulukossa on esimerkiksi aktiivinen suhde jälleenmyyjän myynnin tilauspäivämäärän sarakkeeseen, harkitse taulukon kuvauksen, kuten Filters reseller sales by order date
.Lisätietoja on artikkelissa Aktiivisten ja passiivisten suhteiden ohjeet.
Roskadimensio on hyödyllinen, kun dimensioita on useita, ne sisältävät vähän määritteitä (ehkä yhden) ja näillä määritteillä on vähän arvoja. Hyviä ehdokkaita ovat tilauksen tilan sarakkeet tai asiakkaan demografiset sarakkeet, kuten sukupuoli tai ikäryhmä.
Roskadimension rakennetavoitteena on koota useita pieniä dimensioita yhdeksi dimensioksi mallin tallennuskoon pienentämiseksi ja tietoruudun sekasotkun vähentämiseksi mallitaulukoiden vähäisemmillä taulukoilla.
Roskadimensiotaulukko on yleensä kaikkien dimensiomääritteiden jäsenten karteesinen tuote, jossa on korvaava avainsarake kunkin rivin yksilöimiseksi. Voit luoda dimension tietovarastoon tai luoda Power Queryn avulla kyselyn, joka suorittaa täyden ulomman kyselyn liitokset, ja lisää sitten korvaavan avaimen (indeksisarake).
Tämä kysely ladataan malliin dimensiotaulukkona. Tämä kysely on myös yhdistettävä faktakyselyyhteyteen, jotta indeksisarake ladataan malliin yksi moneen -mallisuhteen tukemiseksi.
Johdettu dimensio viittaa faktataulukon määrittimeen, joka tarvitaan suodattamiseen. Adventure Worksissa jälleenmyyjän myyntitilauksen numero on hyvä esimerkki. Tässä tapauksessa ei ole järkevää luoda itsenäistä taulukkoa, joka koostuu vain tästä yhdestä sarakkeesta, koska se kasvattaa mallin tallennuskokoa ja aiheuttaa tarpeettomia osia tietoruudussa.
Semanttisessa Power BI -mallissa myyntitilauksen numeron sarake voidaan lisätä faktataulukkoon, jotta suodattaminen tai ryhmittely myyntitilauksen numeron mukaan on mahdollista. Tämä on poikkeus aiemmin käyttöön otettuun sääntöön siitä, että taulukkotyyppejä ei pidä sekoittaa (yleensä mallitaulukoiden on oltava joko dimensioita tai faktaja).
Jos Adventure Works -jälleenmyyjien myyntitaulukossa on tilausnumero ja tilausrivin numerosarakkeet ja niitä tarvitaan suodattamiseen, johdetun dimensiotaulukon luominen olisi kuitenkin hyvä rakenne. Lisätietoja on artikkelissa Yksi-yhteen-suhteen ohjeet (Johdettu dimensiot)..
Faktaton faktataulukko ei sisällä mitään mittarisarakkeita. Se sisältää vain dimensioavaimia.
Faktaton faktataulukko voi tallentaa dimensioavainten määrittämät havainnot. Esimerkiksi tietty asiakas on kirjautunut verkkosivustoosi tiettynä päivänä ja tiettynä ajankohtana. Voit määrittää mittarin, joka laskee faktattoman faktataulukon rivit sen analysoimiseksi, milloin asiakkaat ovat kirjautuneet ja kuinka monta asiakasta on kirjautuneena.
Vakuuttava syy käyttää faktatonta faktataulukkoa on dimensioiden välisten suhteiden tallentaminen. Se on semanttinen Power BI -mallirakenne, jota suosittelemme monta moneen -dimensioyhteyksien määrittämiseen. Monta moneen -dimensiosuhteen rakenteessa faktatonta faktataulukkoa kutsutaan välitaulukoksi.
Esimerkiksi myyjille voidaan määrittää yksi tai useampi myyntialue. Välitaulukko voidaan suunnitella faktattomana faktataulukkona, joka koostuu kahdesta sarakkeesta: myyjäavaimesta ja alueavaimesta. Arvojen kaksoiskappaleet voidaan tallentaa molempiin sarakkeisiin.
Tämä monta-moneen-rakennemenetelmä on hyvin dokumentoitu, ja se voidaan saavuttaa ilman välitaulukkoa. Välitaulukkomenetelmää pidetään kuitenkin parhaana käytäntönä kahden dimension yhdistämisessä. Lisätietoja on artikkelissa Monta-moneen-suhteen ohjeet (Liitä kaksi dimensiotyyppistä taulukkoa).
Lisätietoja tähtirakenteesta tai Power BI:n semanttisen mallin rakenteesta on seuraavissa artikkeleissa:
Tapahtumat
Liity seuraamme FabCon Vegasiin
31. maalisk. klo 23 - 2. huhtik. klo 23
Lopullinen Microsoft Fabric-, Power BI-, SQL- ja tekoälyyhteisöjohtoinen tapahtuma. 31.3.–2.4.2025.
Rekisteröidy jo tänäänOpetus
Moduuli
Semanttisen mallin suunnitteleminen Power BI:ssä - Training
Monimutkaisen semanttisen mallin luominen Power BI:ssä on yksinkertaista. Jos tiedot ovat peräisin vähintään kahdesta tapahtumajärjestelmästä, sinulla voi piankin olla kymmeniä taulukoita, joita sinulla on käsiteltävä. Suuren semanttisen mallin rakentamisessa on kyse epäjärjestyksen yksinkertaistamisesta. Tähtirakenne on yksi tapa yksinkertaistaa semanttista mallia, ja saat lisätietoja sen terminologiasta ja toteutuksesta tässä moduulissa. Opit myös, miksi tietojen oikean askelvälin valitseminen on tärkeää
Sertifiointi
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.