Lue englanniksi

Jaa


Tutustu tähtirakenteeseen ja sen merkitykseen Power BI:ssä

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ähtirakenteen yleiskatsaus

Tähtirakenne on kypsä mallinnusmenetelmä, joka on laajasti käytössä relaatiotietovarastoissa. Tämä edellyttää, että mallintajat luokittelevat mallitaulukot joko dimensioksi tai faktaksi.

  • Dimensiotaulukot kuvailevat liiketoiminnan entiteettejä eli mallinnettavaa. Entiteetit voivat sisältää tuotteita, henkilöitä, paikkoja ja käsitteitä aika mukaan luettuna. Yhdenmukaisin tähtirakenteessa oleva taulukko on päivämäärän dimensiotaulukko. Dimensiotaulukko sisältää avainsarakkeen (tai -sarakkeet), joka toimii yksilöivänä tunnisteena, ja muita sarakkeita. Muut sarakkeet tukevat tietojen suodatusta ja ryhmittelyä.
  • Faktataulukot sisältävät huomioita tai tapahtumia: ne voivat olla myyntitilauksia, varastosaldoja, valuuttakursseja, lämpötiloja ja paljon muuta. Faktataulukko sisältää dimension avainsarakkeita, jotka liittyvät dimensiotaulukoihin, ja numeerisia mittarisarakkeita. Dimension avainsarakkeet määrittävät faktataulukon dimensiot , kun taas dimension avainarvot määrittävät faktataulukon rakeisuuden . Harkitse esimerkiksi faktataulukkoa, joka on suunniteltu tallentamaan myyntitavoitteet, joissa on kaksi dimension avainsaraketta 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ä.

Kaavio, joka näyttää kuvan tähtirakenteesta.

Normalisointi vs. denormalisointi

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.

Kaavio, joka näyttää tietotaulukon, joka sisältää Product Key -sarakkeen.

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.

Kaavio, joka näyttää tietotaulukon, joka sisältää tuoteavaimen ja muita tuotteisiin liittyviä sarakkeita, kuten Luokka, Väri ja Koko.

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ähtirakenteen merkitys Power BI:n semanttisten mallien kanssa

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:

  • Dimensiotaulukot mahdollistavat suodatuksen ja ryhmittelyn.
  • Faktataulukot mahdollistavat yhteenvedon.

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.

Kaavio, joka näyttää tähtirakenteen käsitteellisen kuvan.

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:

Mittarit

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.

  • Eksplisiittiset mittarit luodaan erikseen, ja ne perustuvat Data Analysis Expressions (DAX) -lausekkeella kirjoitettuun kaavaan, joka toteuttaa yhteenvedon. Mittarilausekkeet käyttävät usein DAX-koostefunktioita, kuten SUM, MINMAX, AVERAGEja 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.
  • Implisiittiset mittarit ovat sarakkeita, joista voidaan tehdä yhteenveto raportin visualisoinnilla tai Q&A:lla. Niistä on hyötyä mallin kehittäjille, koska monissa esiintymissä ei tarvitse luoda (eksplisiittisiä) mittareita. Esimerkiksi Adventure Works -jälleenmyyjämyynnin 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 (∑).

Kaavio, joka näyttää Tieto-ruudusta löytyneet kuvakkeet.

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ää.

Korvaavat avaimet

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.

Kaavio, joka näyttää Luo indeksisarake -komennon Power Query -editorissa.

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-dimensiot

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, DimProductSubcategoryja DimProduct.

Kaavio, joka näyttää esimerkin Snowflake-kaaviosta, joka koostuu kolmesta toisiinsa liittyvästä taulukosta.

Mielikuvitusta hyödyntäen voit kuvitella normalisoidut taulukot sijoitettuina ulospäin faktataulukosta, mistä syntyy Snowflake-rakenne.

Kaavio, joka näyttää käsitteellisen esimerkin Snowflake-kaaviosta, joka koostuu kolmesta toisiinsa liittyvästä taulukosta.

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:

  • Power BI lataa enemmän taulukoita, mikä ei ole yhtä tehokasta tallennuksen ja suorituskyvyn kannalta. Näissä taulukoissa on oltava sarakkeet, jotka tukevat malliyhteyksiä, ja se voi johtaa suurempaan mallikokoon.
  • Pidemmät suhteeseen suodatuksen välitysketjut on kuljettava läpi, mikä voi olla vähemmän tehokasta kuin yksittäiseen taulukkoon käytetyt suodattimet.
  • Tietoruudussa on enemmän mallitaulukoita raportin tekijöille, mikä voi johtaa vähemmän intuitiivisiin käyttökokemisiin erityisesti silloin, kun Snowflake-dimension taulukot sisältävät vain yhden tai kaksi saraketta.
  • Et voi luoda hierarkiaa, joka koostuu useamman kuin yhden taulukon sarakkeista.

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.

Kaavio, joka näyttää esimerkin hierarkiasta dimensiotaulukossa, jossa on sarakkeita, kuten Luokka, Aliluokka ja Tuote.

Hitaasti muuttuvat dimensiot

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 määrite

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.

Kaavio, joka näyttää esimerkin hitaasti muuttuvasta dimensiotyypistä 1, jossa työntekijän puhelinnumero päivitetään.

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 määrite

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 EndDatemahdollisesti 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ä.

Kaavio, joka näyttää esimerkin hitaasti muuttuvasta dimensiotyypistä 2, jossa työntekijän myyntialuetta päivitetään luomalla uusi versio.

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.

Kaavio, joka näyttää Tiedot-ruudun, jossa on myyjän ja myyjän version sarakkeet.

Rooliulottuvuudet

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.

Kaavio, joka näyttää käsitteellisen esimerkin yksittäisestä rooliulottuvuudesta ja suhteista. Päivämäärä-taulukolla on kaksi yhteyttä tilauspäivämäärän ja lähetyspäivämäärän faktataulukkoon.

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ä.

Kaavio, joka näyttää esimerkin yksittäisestä rooliulottuvuudesta ja suhteista. Päivämäärä-taulukolla on kolme yhteyttä faktataulukkoon.

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:

  • Kun raportin tekijät luottavat sarakkeiden yhteenvetoon mittareiden määrittämisen sijaan, yhteenveto ei onnistu passiivisissa yhteyksissä ilman raporttitason mittarin luomista. Raporttitason mittareita voidaan määrittää vain luotaessa raportteja Power BI Desktopissa.
  • Kun päivämäärän ja jälleenmyyjän myynnin välillä on vain yksi aktiivinen yhteys, jälleenmyyjän myyntiä ei voi suodattaa samanaikaisesti erityyppisten päivämäärien mukaan. Et voi esimerkiksi luoda visualisointia, joka piirtää tilauspäivämäärän myynnin toimitettujen myyntien mukaan.

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.

Kaavio, joka näyttää esimerkin rooliulottuvuuksista ja suhteista. Faktataulukkoon liittyy kolme erilaista päivämäärädimensiotaulukkoa.

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:

  • Varmista, että sarakkeiden nimet ovat kuvaavia ja kuvaavia. Vaikka saraketta voidaan käyttää 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 Yearon , ja niin edelleen.
  • Varmista tarvittaessa, että taulukon kuvaukset antavat raportin tekijöille (Tietoruudun työkaluvihjeiden kautta) tietoa siitä, miten suodattimien levitys on määritetty. Tämä selkeys on tärkeää, kun malli sisältää yleisesti nimetyn taulukon, kuten 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.

Roskadimensiot

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).

Kaavio, joka näyttää esimerkin roskadimensiotaulukosta. Tilauksen tilassa on kolme tilaa, kun taas Toimituksen tilassa on kaksi tilaa. Roskadimensiotaulukko sisältää kaikki kuusi kahden tilan yhdistelmää.

Tämä kysely ladataan malliin dimensiotaulukkona. Tämä kysely on myös yhdistettävä faktakyselyyhteyteen, jotta indeksisarake ladataan malliin yksi moneen -mallisuhteen tukemiseksi.

Johdetut dimensiot

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).

Kaavio, joka näyttää Tiedot-ruudun ja myynnin faktataulukon, joka sisältää Tilausnumero-kentän.

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)..

Faktattomat faktataulukot

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.

Kaavio, joka näyttää faktattoman faktataulukon, joka välitää Myyjä- ja Alue-dimensiot. Faktaton faktataulukko koostuu kahdesta sarakkeesta, jotka ovat dimensioavaimia.

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: