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

Tämän artikkelin tarkoituksena ei ole käydä tähtirakennetta läpi kokonaisvaltaisesti. Jos haluat lisätietoja, tutustu muuhun julkaistuun sisältöön, 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 kuvaavia sarakkeita.

Faktataulukot sisältävät huomioita tai tapahtumia: ne voivat olla myyntitilauksia, varastosaldoja, valuuttakursseja, lämpötiloja jne. 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 : Päivämäärä ja Tuoteavain. 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ä Päivämäärä-sarakkeeseen 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ää erittäin paljon rivejä ja kasvavat ajan mittaan.

Image shows an illustration of a star schema.

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, sekä muita sarakkeita, jotka kuvaavat tuotteen 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-sarakkeessa näkyy tuote.

Image shows a table of data that includes a Product Key column.

Jos myyntitaulukko kuitenkin tallentaa tuotetiedot avaimen ulkopuolelle, sitä pidetään denormalisoituna. Huomaa seuraavassa kuvassa, että Tuoteavain ja muut tuotteisiin liittyvät sarakkeet tallentavat tuotteen.

Image shows a table of data that includes a Product Key and other product-related columns, including Category, Color, and Size.

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 -tietomalleja, jotka sisältävät normalisoituja fakta- ja dimensiotietoja edustavia taulukoita. On kuitenkin yksi poikkeus, jossa Snowflake-dimensio tulee denormalisoida yhden mallitaulukon luomiseksi.

Tähtirakenteen merkitys Power BI -malleille

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 -malliin (jota Power BI -palvelu kutsuu semanttiseksi malliksi , joka tunnetaan aiemmin tietojoukkona). Näitä kyselyitä käytetään mallitietojen suodattamiseen, ryhmittelemiseen ja yhteenvedon tekemiseen. 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 tukevat suodatusta ja ryhmittelyä
  • Faktataulukot tukevat yhteenvetoa.

Ei ole olemassa mitään taulukon ominaisuutta, jolla mallintajat määrittävät taulukkotyypin dimensioksi tai faktaksi. Se määritetään mallien yhteyksien perusteella. Malliyhteys muodostaa suodatuksen välityspolun kahden taulukon välille. Yhteyden Kardinaliteetti-ominaisuus määrittää taulukkotyypin. Yleinen yhteyden kardinaliteetti on yksi moneen tai sen käänteinen vastakkain monta yhteen. "Yksi" puoli on aina dimensiotyyppinen taulukko ja "monta" puoli on aina faktatyyppinen taulukko. Lisätietoja suhteista on artikkelissa Mallien suhteet Power BI Desktopissa.

Image shows a conceptual illustration of a star schema.

Hyvin jäsennellyssä mallirakenteessa on oltava taulukoita, jotka ovat joko dimensiotyyppisiä taulukoita tai faktatyyppisiä taulukoita. 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ä faktatyyppiset taulukot lataavat aina tiedot yhdenmukaisella rakeillisella tiedolla.

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 muita käsitteitä, joita voidaan käyttää Power BI -mallissa. Näitä käsitteitä ovat esimerkiksi seuraavat:

Mittarit

Tähtirakenteessa mittari on faktataulukon sarake, johon on tallennettu yhteenvedossa käytettävät arvot.

Power BI -mallissa mittarin määritelmä on erilainen, mutta samankaltainen. Se on Data Analysis Expressions (DAX) -lausekkeella kirjoitettu kaava, joka toteuttaa yhteenvedon. Mittayksikkölausekkeet hyödyntävät usein DAX-koostefunktioita, kuten SUM, MIN, MAX, AVERAGE jne. niiden avulla tuotetaan skalaariarvotulos, kyselyhetkellä (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-kielen perusteet Power BI Desktopissa .

On tärkeää ymmärtää, että Power BI -mallit tukevat toista menetelmää yhteenvedon saavuttamiseksi. Mikä tahansa sarake – ja yleensä numerosarakkeet – voidaan vetää yhteen raportin visualisoinnin tai Q&A:n avulla. Näitä sarakkeita kutsutaan implisiittisiksi mittareiksi. Niistä on hyötyä mallin kehittäjille, koska monissa esiintymissä ei tarvitse luoda mittareita. Esimerkiksi Adventure Works -jälleenmyyjämyynnin sarake Myynnin määrä voidaan vetää yhteen monella tavalla (summa, määrä, keskiarvo, mediaani, minimi, maksimi jne.) ilman, että tarvitsee luoda mittari jokaiselle mahdolliselle koostamistyypille.

Image shows icons found in the Fields pane.

Mittareiden luomiseen on kuitenkin kolme vakuuttavaa syytä myös yksinkertaisissa saraketason yhteenvedoissa:

  • Kun tiedät, että raportin tekijät tekevät kyselyn malliin MDX-lausekkeella, mallissa on oltava eksplisiittisiä mittareita. Eksplisiittiset mittarit määritetään DAX:n avulla. Tämä rakennemenetelmä on erittäin merkityksellinen, kun Power BI -tietojoukkoon tehdään kysely MDX:llä, koska MDX ei tue sarakearvojen yhteenvetoja. 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, mallissa on oltava eksplisiittiset mittarit. 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 varmistaa, että raportin tekijät voivat tehdä yhteenvedon sarakkeista vain tietyllä tavalla. Esimerkiksi jälleenmyyjämyynnin Yksikköhinta-sarakkeesta (joka on yksikkökohtainen hinta) 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, keskiarvo jne.). Tässä esiintymässä mallintaja voi piilottaa Yksikköhinta-sarakkeen ja luoda mittareita kaikille sopiville koostamisfunktioille.

Tämä rakennemenetelmä toimii hyvin Power BI -palvelu ja Q&A:ssa laadituille raporteille. Power BI Desktopin reaaliaikaisten yhteyksien avulla raporttien tekijät voivat näyttää Kentät-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 malliyhteydet perustuvat yksittäiseen yksilölliseen sarakkeeseen yhdessä taulukossa, joka levittää suodattimet yksittäiseen sarakkeeseen eri taulukossa. Kun mallissa oleva dimensiotyyppinen taulukko 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 onnistuu helposti luomalla Power Query -indeksisarake.

Image shows the Create index column command in Power Query Editor.

Tämä kysely on yhdistettävä "monta"-puolen kyselyyn, jotta siihenkin voi lisätä indeksisarakkeen. Kun lataat nämä kyselyt 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, DimProductSubcategory ja DimProduct.

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

Image shows an example of a snowflake diagram comprising three related tables.

Power BI Desktopissa voit halutessasi jäljitellä Snowflake-dimensiorakennetta (koska lähdetiedot rakenteen vuoksi) tai integroida (denormalisoida) lähdetaulukot yhdeksi mallitaulukoksi. 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ä on todennäköisesti vähemmän tehokasta kuin yksittäiseen taulukkoon käytetyt suodattimet.
  • Kentät-ruudussa on enemmän mallitaulukoita raportin tekijöille, mikä voi vähentää käyttökokemuksen intuitiivista kokemusta etenkin silloin, kun Snowflake-dimension taulukot sisältävät vain yhden tai kaksi saraketta.
  • Taulukoita kattavaa hierarkiaa ei voi luoda.

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 erittäin suurissa dimensiotaulukoissa.

Image shows an example of a hierarchy within a dimension table that has columns like Category, Subcategory, and Product.

Hitaasti muuttuvat dimensiot

Hitaasti muuttuva dimensio (SCD) on sellainen, joka hallitsee dimension jäsenten muutosta ajan mittaan asianmukaisesti. Sitä käytetään, kun liiketoimintaentiteetin arvot muuttuvat ajan kuluessa ja tapauskohtaisesti. Hyvä esimerkki hitaasti muuttuvasta dimensiosta on asiakasdimensio ja erityisesti sen yhteystietosarakkeet, kuten sähköpostiosoite ja puhelinnumero. 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. Dimensiotyyppinen taulukko voi olla tyyppiä 1 tai 2 tai tukea molempia tyyppejä samanaikaisesti eri sarakkeissa.

Tyypin 1 hitaasti muuttuva määrite

Tyypin 1hitaasti 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 dimensiotyypin taulukon 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 2hitaasti 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, kuten StartDate ja EndDate, sekä mahdollisesti merkintäsarakkeen, kuten IsCurrent, jotta suodattaminen nykyisten dimension jäsenten mukaan on helppoa.

Adventure Works esimerkiksi määrittää myyjät myyntialueisiin. 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 voivat määrittää tyhjän päättymispäivämäärän (tai 31.12.9999), mikä osoittaa, että rivi on nykyinen versio. Taulukossa on myös määritettävä 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 päivittämällä EndDate-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. Tätä tulosta ei voi tuottaa Power Querya käyttävä Power BI -malli. Se voi kuitenkin ladata tiedot valmiiksi ladatusta tyypin 2 hitaasti muuttuvan dimension taulukosta.

Power BI -mallin tulee tukea jäsenen historiallisten tietojen kyselyä muutoksesta riippumatta ja jäsenen version kyselyä, mikä edustaa jäsenen tiettyä tilaa ajan mukaan. 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 -mallin dimensiotyypin taulukossa 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 "Michael Blythe (15.12.2008-26.6.2019)" tai "Michael Blythe (nykyinen)". 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 myös se, että hierarkia sisällytetään siten, että visualisoinneissa voidaan porautua version tasolle.

Image shows the Fields pane with columns for Salesperson and Salesperson Version.

Image shows the resulting hierarchy, including levels for Salesperson and Salesperson Version.

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.

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.

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, on tärkeää ymmärtää, että kahden Power BI -mallin taulukon 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 raporteissa käytetty suodatin, joka Adventure Worksissa on tilauspäivämäärän yhteys.

Image shows an example of a single role playing dimension and relationships. The Date table has three relationships to the fact table.

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. Sen myötä Kentät-ruutu on sekava ja mittareita on liikaa. 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 dimensiotyyppinen taulukko kullekin rooliesiintymälle. Yleensä lisädimensiotaulukot luodaan laskettuina taulukoina DAX:n avulla. Laskettuja taulukoita käyttämällä malli voi sisältää Päivämäärä-taulukon , Lähetyspäivämäärä-taulukon ja Toimituspäivämäärä-taulukon , joilla kullakin on yksi aktiivinen yhteys jälleenmyyjän myyntitaulukon sarakkeisiin.

Image shows an example of role playing dimensions and relationships. There are three different date dimension tables related to the fact table.

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 dimensiotyyppisissä taulukoissa on tallennuksia yleensä vähemmän rivejä faktatyyppisiin taulukoihin verrattuna, tämä ei yleensä aiheuta huolta.

Noudata seuraavia hyvän rakenteen käytäntöjä, kun luot mallin dimensiotyyppisiä taulukoita kullekin roolille:

  • Varmista, että sarakkeiden nimet ovat kuvaavia ja kuvaavia. Vaikka Vuosi-saraketta voidaan käyttää kaikissa päivämäärätaulukoissa (sarakenimet ovat yksilöllisiä taulukon sisällä), kyseessä ei ole itsestään selvä kuvaus oletusarvoisten visualisointien otsikoista. Harkitse sarakkeiden nimeämistä uudelleen kussakin dimensioroolin taulukossa siten, että lähetyspäivämäärä-taulukon vuosisarakkeen nimi on esimerkiksi Lähetysvuosi ja niin edelleen.
  • Varmista tarvittaessa, että taulukon kuvaukset antavat raportin tekijöille (Kentät-ruudun työkaluvihjeiden kautta) palautetta siitä, miten suodattimien levitys on määritetty. Tämä selkeys on tärkeää, kun malli sisältää yleisesti nimetyn taulukon, kuten Päivämäärä, jota käytetään useiden faktatyyppisten taulukoiden suodattamiseen. Jos tässä taulukossa on esimerkiksi aktiivinen yhteys jälleenmyyjän myynnin tilauspäivämäärän sarakkeeseen, voit esittää taulukon kuvauksen, kuten "Suodattaa jälleenmyyjän myynnin tilauspäivämäärän mukaan".

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 (sukupuoli, ikäryhmä jne.).

Roskadimension rakennetavoitteena on koota useita pieniä dimensioita yhdeksi dimensioksi mallin tallennuskoon pienentämiseksi ja Kentät-ruudun sekasotkun vähentämiseksi mallitaulukoiden vähäisemmillä taulukoilla.

Roskadimensiotaulukko on yleensä kaikkien dimensiomääritteiden jäsenten karteesinen tulos, jossa on korvaava avainsarake. Korvaava avain tarjoaa yksilöivän viittauksen kuhunkin taulukon riviin. Voit luoda dimension tietovarastoon tai luoda Power Queryn avulla kyselyn, joka suorittaa täyden ulomman kyselyn liitokset, ja lisää sitten korvaavan avaimen (indeksisarake).

Image shows an example of a junk dimension table. Order Status has three states while Delivery Status has two states. The junk dimension table stores all six combination of the two statuses.

Tämä kysely ladataan malliin dimensiotyyppisenä taulukkona. Tämä kysely on yhdistettävä myös faktakyselyun, jotta indeksisarake ladataan malliin yksi moneen -mallisuhteen tukemista tukeaksesi.

Johdetut dimensiot

Johdettu dimensio viittaa faktataulukon määritteen, joka tarvitaan suodattamiseen. Adventure Worksissa jälleenmyyjän myyntitilauksen numero on hyvä esimerkki. Tässä tapauksessa mallin hyvän rakenteen kannalta ei ole järkevää luoda itsenäistä taulukkoa, joka sisältää vain tämän yhden sarakkeen, koska se kasvattaa mallin tallennuskokoa ja aiheuttaa tarpeettomia osia Kentät-ruudussa .

Power BI -mallissa myyntitilauksen numeron sarake voidaan lisätä faktatyyppiseen taulukkoon, 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 dimensiotyyppisiä tai faktatyyppisiä).

Image shows the Fields pane and the sales fact table, which includes the Order Number field.

Jos Adventure Works -jälleenmyyjien myyntitaulukossa on tilausnumero ja tilausrivin numerosarakkeet ja niitä tarvitaan suodattamiseen, johdettu dimensiotaulukko 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 verkkosivustoon tiettynä päivänä ja tiettynä ajankohtana. Voit määrittää mittarin, joka laskee faktattoman faktataulukon rivit sen analysoimiseksi, milloin asiakkaat ovat kirjautuneet ja kuinka moni asiakas on kirjautunut.

Vakuuttava syy käyttää faktatonta faktataulukkoa on dimensioiden välisten suhteiden tallentaminen. Tässä Power BI -mallimallissa suosittelemme monta moneen -dimensioyhteyksien määrittämistä. 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.

Image shows a factless fact table bridging Salesperson and Region dimensions. The factless fact table comprises two columns, which are the dimension keys.

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 mallin rakenteesta on seuraavissa artikkeleissa: