Dimensiomallinnus Microsoft Fabric Warehousessa: dimensiotaulukot

Koskee: SQL-analytiikan päätepiste ja Microsoft Fabric -varasto

Muistiinpano

Tämä artikkeli on osa dimensiomallinnussarjaa . Tässä sarjassa keskitytään microsoft Fabric Warehousen dimensiomallinnukseen liittyviin ohjauksen ja suunnittelun parhaisiin käytäntöihin.

Tässä artikkelissa on ohjeita ja parhaita käytäntöjä dimensiotaulukoiden suunnitteluun dimensiomallissa . Se tarjoaa käytännön ohjeita Microsoft Fabric Warehouselle. Se on kokemus, joka tukee monia T-SQL-ominaisuuksia, kuten taulukoiden luomista ja tietojen hallintaa taulukoissa. Hallitset siis dimensiomallitaulukoiden luomista ja niiden lataamista tiedoilla.

Muistiinpano

Tässä artikkelissa termi tietovarasto viittaa yrityksen tietovarastoon, joka tarjoaa tärkeiden tietojen kattavan integroinnin koko organisaatioon. Sen sijaan erillinen termivarasto viittaa Fabric Warehouseen, joka on Ohjelmisto palveluna (SaaS) -relaatiotietokanta, jonka avulla voit toteuttaa tietovaraston. Selkeyden vuoksi tässä artikkelissa jälkimmäinen mainitaan nimellä Fabric Warehouse.

Vihje

Jos et ole ennen kokenut dimensiomallinnusta, harkitse tätä artikkelisarjaa ensimmäisessä vaiheessasi. Sen tarkoituksena ei ole käydä läpi koko dimensiomallinnuksen rakennetta. 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.

Dimensiomallissa dimensiotaulukko kuvaa entiteetin, joka on olennainen liiketoimintasi ja analytiikkasi vaatimusten kanssa. Dimensiotaulukot edustavat laajasti asioita , joita mallinnat. Asiat voivat olla tuotteita, ihmisiä, paikkoja tai mitä tahansa muuta käsitettä, mukaan lukien päivämäärä ja aika. Dimensiotaulukoiden helpoksi tunnistamiseksi niiden nimien d_ etuliitteenä on yleensä tai Dim_.

Dimensiotaulukon rakenne

Jos haluat kuvata dimensiotaulukon rakennetta, tarkastele seuraavaa esimerkkiä myyjän dimensiotaulukosta nimeltä d_Salesperson. Tässä esimerkissä sovelletaan hyviä suunnittelukäytäntöjä. Kaikki sarakeryhmät on kuvattu seuraavissa osissa.

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Korvaava avain

Mallidimensiotaulukossa on korvaava avain, jonka nimi Salesperson_SKon . Korvaava avain on yksisarakkeinen yksilöivä tunnus, joka luodaan ja tallennetaan dimensiotaulukkoon. Se on perusavainsarake, jota käytetään dimensiomallin muihin taulukoihin liittyen.

Korvaavat avaimet pyrkivät eristämään tietovaraston lähdetietojen muutoksista. Ne tarjoavat myös monia muita etuja, joiden avulla voit:

• Yhdistä useita tietolähteitä (vältä tunnisteiden kaksoiskappaleiden yhteensörmäystä).
• Yhdistä monisarakkeiset luonnolliset avaimet tehokkaammaksi yksisarakkeiseksi avaimeksi.
• Seuraa dimensiohistoriaa hitaasti muuttuvalla dimensiotyypillä 2.
• Rajoita faktataulukon leveyttä tallennustilan optimoinnissa (valitsemalla pienin mahdollinen kokonaislukutietotyyppi).

Korvaava avainsarake on suositeltu käytäntö, vaikka luonnollinen avain (kuvattu seuraavaksi) vaikuttaa hyväksyttävältä hakijalta. Vältä myös merkityksen antamista avainarvoille (lukuun ottamatta päivämäärä- ja aikadimension avaimia, jotka kuvataan myöhemmin).

Luonnolliset avaimet

Mallidimensiotaulukossa on myös luonnollinen avain, jonka nimi EmployeeIDon . Luonnollinen avain on lähdejärjestelmään tallennettu avain. Se sallii dimensiotietojen liittämisen lähdejärjestelmään, jonka yleensä suorittaa dimensiotaulukon lataaminen Poimi-, Lataa- ja Muunna (ETL) -prosessilla. Joskus luonnollista avainta kutsutaan liiketoiminta-avaimeksi, ja sen arvot saattavat olla merkityksellisiä yrityskäyttäjille.

Joskus dimensioilla ei ole luonnollista avainta. Näin voi olla päivämäärädimension tai hakudimensioiden kohdalla tai silloin, kun luot dimensiotietoja normalisoimalla tietuetiedoston.

Dimension määritteet

Mallidimensiotaulukolla on myös dimensiomääritteitä, kuten FirstName sarake. Dimensiomääritteet tarjoavat kontekstin liittyviin faktataulukoihin tallennettuihin numeerisiin tietoihin. Ne ovat yleensä tekstisarakkeita, joita käytetään analytiikkakyselyissä suodattamiseen ja ryhmittelyyn (osittamiseen ja hakuun), mutta ei koostamista itse. Jotkin dimensiotaulukot sisältävät vähän määritteitä, kun taas toiset sisältävät useita määritteitä (jopa sen, mitä tarvitaan dimensiomallin kyselyvaatimusten tukemiseen).

Vihje

Hyvä tapa määrittää, mitä dimensioita ja määritteitä tarvitset, on etsiä oikeat henkilöt ja esittää oikeat kysymykset. Tarkemmin sanottuna, pysy valppaana sanan mainitsemista varten. Kun esimerkiksi joku sanoo, että hänen on analysoitava myyntiä myyjän, kuukauden ja tuoteluokan mukaan, hän kertoo tarvitsevansa dimensioita, joilla on nämä määritteet.

Jos aiot luoda semanttisen Direct Lake -mallin, sisällytä mukaan kaikki mahdolliset sarakkeet, joita tarvitaan suodatukseen ja ryhmittelyun dimension määritteinä. Tämä johtuu siitä, että semanttiset Direct Lake -mallit eivät tue laskettuja sarakkeita.

Viiteavaimet

Mallidimensiotaulukossa on myös viiteavain, jonka nimi SalesRegion_FKon . Muut dimensiotaulukot voivat viitata viiteavaimeen, ja niiden näkyvyys dimensiotaulukossa on erikoistapaus. Se ilmaisee, että taulukko liittyy toiseen dimensiotaulukkoon, mikä tarkoittaa sitä, että se voi olla osa Snowflake-dimensiota tai se liittyy peukalointidimensioon.

Fabric Warehouse tukee viiteavainrajoitteita , mutta niitä ei voi pakottaa. Siksi on tärkeää, että ETL-prosessisi testaa liittyvien taulukoiden eheyden, kun tiedot ladataan.

Viiteavaimia kannattaa silti luoda. Yksi hyvä syy luoda pakottamattomia viiteavaimia on se, että mallinnustyökalut, kuten Power BI Desktop, voivat tunnistaa ja luoda suhteita semanttisen mallin taulukoiden välille automaattisesti.

Historialliset seurantamääritteet

Mallidimensiotaulukolla on myös useita historiallisia seurantamääritteitä. Historialliset seurantamääritteet ovat valinnaisia sen mukaan, että sinun täytyy seurata tiettyjä muutoksia, kun ne tapahtuvat lähdejärjestelmässä. Niiden avulla voidaan tallentaa arvoja, jotka tukevat tietovaraston ensisijaista roolia, joka kuvaa menneisyyttä tarkasti. Tarkemmin sanottuna nämä määritteet tallentavat historiallisen kontekstin, kun ETL-prosessi lataa uudet tai muutetut tiedot dimensioon.

Lisätietoja on tämän artikkelin kohdassa Historiallisten muutosten hallinta.

Audit attributes

Mallidimensiotaulukolla on myös useita valvontamääritteitä. Valvontamääritteet ovat valinnaisia, mutta suositeltavia. Niiden avulla voit seurata, milloin ja miten dimensiotietueita on luotu tai muokattu. Ne voivat sisältää ETL-prosessien aikana esiin tulleita diagnostiikka- tai vianmääritystietoja. Voit esimerkiksi seurata, kuka (tai mikä prosessi) on päivittänyt rivin ja milloin. Valvontamääritteet voivat myös auttaa diagnosoimaan haastavaa ongelmaa, kuten sitä, milloin ETL-prosessi pysähtyy odottamattomasti. He voivat myös merkitä dimension jäseniä virheiksi tai johdettuiksi jäseniksi.

Dimensiotaulukon koko

Usein dimensiomallin hyödyllisimmät ja monipuolisimmat mitat ovat suuria, leveitä ulottuvuuksia. Ne ovat suuria rivejen (yli miljoonien) ja leveiden dimensiomääritteiden määrän (mahdollisesti satojen) suhteen. Koko ei ole kovin tärkeä (vaikka sinun pitäisi suunnitella ja optimoida pienin mahdollinen koko). Tärkeää on se, että dimensio tukee vaadittua faktatietojen suodatusta, ryhmittelyä ja tarkkaa historiallista analyysia.

Suuret dimensiot saattavat olla peräisin useista lähdejärjestelmistä. Tässä tapauksessa dimension käsittelyn on yhdistettävä, yhdistettävä, määritettävä ja standardisoitava tietoja. ja määritä korvaavat avaimet.

Vertailun vuoksi, jotkut mitat ovat pieniä. Ne saattavat edustaa hakutaulukoita, jotka sisältävät vain useita tietueita ja määritteitä. Usein nämä pienet dimensiot tallentavat faktataulukoiden tapahtumiin liittyvät luokka-arvot, ja ne otetaan käyttöön dimensioina, joilla on korvaavia avaimia liittyen faktatietueisiin.

Vihje

Kun sinulla on useita pieniä dimensioita, harkitse niiden yhdistämistä roskadimensioon.

Dimension suunnittelun käsitteet

Tässä osiossa kuvataan dimension suunnittelun eri käsitteitä.

Denormalisointi vs. normalisointi

Dimensiotaulukoita tulee lähes aina denormalisoida. Vaikka normalisointi on termi, jota käytetään kuvaamaan tietoja, jotka on tallennettu tavalla, joka vähentää toistuvia tietoja, denormalisointi on termi, jota käytetään määrittämään, missä ennalta lasketut tarpeettomat tiedot ovat olemassa. Tarpeettomia tietoja on olemassa yleensä hierarkioiden tallennustilan (josta keskustellaan myöhemmin) vuoksi, mikä tarkoittaa, että hierarkiat tasoitetaan. Tuotedimensio voi esimerkiksi tallentaa aliluokan (ja siihen liittyvät määritteet) ja luokan (ja siihen liittyvät määritteet).

Koska dimensiot ovat yleensä pieniä (verrattuna faktataulukoihin), tarpeettomien tietojen tallennuskustannukset ovat lähes aina suuremmat kuin kyselyjen parempi suorituskyky ja käytettävyys.

Snowflake-dimensiot

Yksi poikkeus denormalisointiin on Snowflake-dimension suunnittelu. Snowflake-dimensio normalisoidaan, ja se tallentaa dimensiotiedot useisiin liittyviin taulukoihin.

Seuraavassa kaaviossa esitetään Snowflake-dimensio, joka koostuu kolmesta toisiinsa liittyvästä dimensiotaulukosta: Product, Subcategoryja Category.

Harkitse Snowflake-dimension toteutusta, kun:

• Dimensio on erittäin suuri, ja tallennuskustannukset ovat suuremmat kuin kyselyn suorituskyky. (Arvioi kuitenkin säännöllisesti uudelleen, että näin on edelleen.)
• Tarvitset avaimia, jotka liittävät dimension yksityiskohtaisiin tietoihin. Esimerkiksi myynnin faktataulukkoon tallennetaan rivejä tuotetasolla, mutta myyntikohteen faktataulukkoon tallennetaan aliluokan tason rivejä.
• Sinun on seurattava historiallisia muutoksia korkeammilla rakeisuustasoilla.

Muistiinpano

Muista, että Semanttisen Power BI -mallin hierarkia voi perustua vain yksittäisen semanttisen mallitaulukon sarakkeisiin. Siksi Snowflake-dimension pitäisi tuottaa denormalisoitu tulos käyttämällä näkymää, joka liittää Snowflake-taulukot yhteen.

Hierarkiat

Yleensä dimensiosarakkeet tuottavat hierarkioita. Hierarkiat mahdollistavat tietojen tutkimisen eri yhteenvetotasoilla. Matriisivisualisoinnin alkunäkymässä saattaa esimerkiksi näkyä vuosimyyntiä, ja raportin käyttäjä voi halutessaan porautua alaspäin paljastaakseen neljännesvuosittaisen ja kuukausittaisen myynnin.

Hierarkia voidaan tallentaa dimensioon kolmella tavalla. Seuraavia voi käyttää:

• Sarakkeet yhdestä denormalisoidusta dimensiosta.
• Snowflake-dimensio, joka koostuu useista toisiinsa liittyvistä taulukoista.
• Pää-alikohde (itseensä viittaava) suhde dimensiossa.

Hierarkiat voidaan tasapainottaa tai tasapainottaa. On myös tärkeää ymmärtää, että jotkin hierarkiat ovat vaillinaisia.

Tasapainotetut hierarkiat

Tasapainotetut hierarkiat ovat hierarkian yleisin tyyppi. Tasapainoisella hierarkialla on sama määrä tasoja. Yleinen esimerkki tasapainotetusta hierarkiasta on kalenterihierarkia päivämäärädimensiossa, joka sisältää vuoden, vuosineljänneksen, kuukauden ja päivämäärän tasot.

Seuraavassa kaaviossa esitetään myyntialueiden tasapainoinen hierarkia. Se koostuu kahdesta tasosta, joita ovat myyntialueryhmä ja myyntialue.

Tasapainotetun hierarkian tasot perustuvat joko yhden denormalisoidun dimension sarakkeisiin tai taulukoihin, jotka muodostavat Snowflake-dimension. Kun perustuu yhteen denormalisoituun dimensioon, korkeammat tasot edustavat sarakkeet sisältävät tarpeettomia tietoja.

Tasapainoisten hierarkioiden osalta faktat liittyvät aina hierarkian yksittäiseen tasoon, joka on yleensä alin taso. Näin faktat voidaan koota (koostaa) hierarkian ylimmälle tasolle. Faktat voivat liittyä mihin tahansa tasoon, joka määritetään faktataulukon rakeen mukaan. Esimerkiksi myynnin faktataulukko saatetaan tallentaa päivämäärätasolle, kun taas myynnin kohde-faktataulukko saatetaan tallentaa vuosineljänneksen tasolle.

Tasapainottomat hierarkiat

Epätasapainoisen hierarkian tyyppi on harvinaisempi hierarkiatyyppi. Epätasapainoisella hierarkialla on pää-alikohdesuhteeseen perustuvia tasoja. Tästä syystä dimensiorivit, eivät tietyt dimensiotaulukon sarakkeet, määrittävät tasapainottoman hierarkian tasojen määrän.

Yleinen esimerkki epätasapainottomasta hierarkiasta on työntekijähierarkia, jossa jokainen työntekijädimension rivi liittyy saman taulukon reporting manager -riviin. Tässä tapauksessa kuka tahansa työntekijä voi olla esimies, jolla on raportoivat työntekijät. Joillakin hierarkian haaroilla on luonnollisesti enemmän tasoja kuin toisilla.

Seuraavassa kaaviossa esitetään epätasapainoinen hierarkia. Se koostuu neljästä tasosta, ja jokainen hierarkian jäsen on myyjä. Huomaa, että myyjillä on hierarkiassa eri määrä esi-isiä sen mukaan, kenelle he raportoivat.

Muita yleisiä esimerkkejä epätasapainoisista hierarkioista ovat esimerkiksi materiaalilasku, yrityksen omistajuusmallit ja kirjanpito.

Epätasapainoisille hierarkioille faktat liittyvät aina dimension rakeisiin. Esimerkiksi myyntitiedot liittyvät eri myyjiin, joilla on erilaiset raportointirakenteet. Dimensiotaulukossa on korvaava avain (nimeltään Salesperson_SKReportsTo_Salesperson_FK ) ja viiteavainsarake, joka viittaa perusavainsarakkeeseen. Jokainen myyjä, jolla ei ole ketään hallittavaa, ei välttämättä ole hierarkian minkä tahansa haaran alimmalla tasolla. Kun myyjä ei ole alimmalla tasolla, hän saattaa myydä tuotteita ja saada raportoivia myyjiä, jotka myös myyvät tuotteita. Faktatietojen koonnin on siis otettava huomioon yksittäiset myyjät ja kaikki heidän jälkeläisensä.

Kyselyn tekeminen pää- ja alikohteiden hierarkioista voi olla monimutkaista ja hidasta erityisesti suurissa dimensioissa. Lähdejärjestelmä saattaa tallentaa suhteita pääkohde-alikohteiksi, mutta suosittelemme, että naturalisoit hierarkian. Tässä esiintymässä naturalisointi tarkoittaa dimension hierarkiatasojen muuntamista ja tallentamista sarakkeina.

Vihje

Jos päätät olla naturalisoimatta hierarkiaa, voit silti luoda hierarkian pää-alikohdesuhteen perusteella Power BI:n semanttisessa mallissa. Tätä menetelmää ei kuitenkaan suositella suurille dimensioille. Lisätietoja on artikkelissa Tietoja pää- ja alielementtihierarkioiden funktioista DAXissa.

Vaillinainen hierarkia

Joskus hierarkia on vaillinainen , koska hierarkiassa olevan jäsenen pääkohde on sellaisella tasolla, joka ei ole heti sen yläpuolella. Näissä tapauksissa puuttuvat tason arvot toistavat päätason arvon.

Otetaan esimerkiksi tasapainotettu maantieteellinen hierarkia. Vaillinainen hierarkia on olemassa, kun maassa tai alueella ei ole osavaltioita tai provinsseja. Esimerkiksi Uudessa-Seelannissa ei ole osavaltioita eikä provinsseja. Kun siis lisäät Uuden-Seelannin rivin, sinun tulee tallentaa myös maa/alue-arvo sarakkeeseen StateProvince .

Seuraavassa kaaviossa esitetään maantieteellisten alueiden vaillinainen hierarkia.

Historiallisen muutoksen hallinta

Tarvittaessa historiallista muutosta voidaan hallita ottamalla hitaasti muuttuva dimensio käyttöön. Hitaasti muuttuva lisääminen säilyttää historiallisen kontekstin, kun siihen ladataan uusia tai muutettuja tietoja.

Tässä ovat yleisimmät hitaasti muuttuvan dimension tyypit.

• Tyyppi 1: Korvaa olemassa oleva dimension jäsen.
• Tyyppi 2: Lisää uusi aikaan perustuva versiollinen dimension jäsen.
• Tyyppi 3: Seuraa rajoitettua historiaa määritteiden avulla.

On mahdollista, että dimensio tukee sekä tyypin 1 hitaasti muuttuvan dimension että tyypin 2 hitaasti muuttuvan dimension muutoksia.

Hitaasti muuttuvan dimension tyyppiä 3 ei yleisesti käytetä, mikä johtuu osittain siitä, että sitä on vaikea käyttää semanttisessa mallissa. Harkitse tarkkaan, sopiiko tyypin 2 hitaasti muuttuva tyypille parempi vastaavuus.

Vihje

Jos odotat nopeasti muuttuvaa dimensiota, joka on dimensio, jonka määrite muuttuu usein, harkitse kyseisen määritteen lisäämistä faktataulukkoon . Jos määrite on numeerinen, kuten tuotehinta, voit lisätä sen mittarina faktataulukkoon. Jos määrite on tekstiarvo, voit luoda kaikkiin tekstiarvoihin perustuvan dimension ja lisätä sen dimensioavaimen faktataulukkoon.

Hitaasti muuttuvan dimension tyyppi 1

Hitaasti muuttuvan dimension tyypin 1 muutokset korvaavat olemassa olevan dimensiorivin, koska muutoksia ei tarvitse seurata. Tätä hitaasti muuttuvan dimension tyyppiä voidaan käyttää myös virheiden korjaamiseen. Se on yleinen hitaasti muuttuva määritetyyppi, ja sitä tulisi käyttää useimpiin muuttuviin määritteisiin, kuten asiakkaan nimeen, sähköpostiosoitteeseen ja muihin.

Seuraavassa kaaviossa esitetään myyjädimension jäsenen ennen ja jälkeen -tila, jossa hänen puhelinnumeronsa on muuttunut.

Tämä hitaasti muuttuvan dimension tyyppi ei säilytä historiallista perspektiiviä, koska olemassa olevaa riviä päivitetään. Tämä tarkoittaa, että tyypin 1 hitaasti muuttuvan dimension muutokset voivat aiheuttaa erilaisia ylemmän tason koosteita. Jos esimerkiksi myyjä on määritetty eri myyntialueelle, scd-tyypin 1 muutos korvaa dimensiorivin. Myyjien historiallisten myyntitulosten koonti alueelle tuottaisi sitten erilaisen tuloksen, koska se käyttää nyt uutta nykyistä myyntialuetta. On kuin kyseinen myyjä olisi aina määritetty uudelle myyntialueelle.

Hitaasti muuttuvan dimension tyyppi 2

Hitaasti muuttuvan dimension tyypin 2 muutokset aiheuttavat uusia rivejä, jotka edustavat dimension jäsenen aikapohjaista versiota. Käytössä on aina nykyinen versiorivi, joka kuvastaa dimension jäsenen tilaa lähdejärjestelmässä. Dimensiotaulukon säilön historialliset seurantamääritteet , joiden avulla voidaan tunnistaa nykyinen versio (nykyinen merkintä on TRUE) ja sen voimassaoloaika. Korvaava avain vaaditaan, koska luonnolliset avaimet sisältävät kaksoiskappaleita, kun useita versioita tallennetaan.

Se on yleinen hitaasti muuttuvan dimension tyyppi, mutta se tulee varata määritteille, joiden on säilytettävä historiallinen perspektiivi.

Jos esimerkiksi myyjä on määritetty eri myyntialueelle, hitaasti muuttuvan dimension tyypin 2 muutokseen liittyy päivitystoiminto ja lisäystoiminto.

1. Päivitystoiminto korvaa nykyisen version historiallisten seurantamääritteiden määrittämiseksi. Erityisesti voimassaoloaikasarakkeen arvona on ETL-käsittelypäivä (tai sopiva aikaleima lähdejärjestelmässä) ja nykyinen merkintä on FALSE.
2. Lisäämistoiminto lisää uuden, nykyisen version, joka asettaa start-kelpoisuussarakkeen end validity-sarakkeen arvoon (käytetään aiemman version päivittämiseen) ja nykyisen merkinnän arvoksi TRUE.

On tärkeää ymmärtää, että liittyvien faktataulukoiden askelväli ei ole myyjätasolla, vaan myyjän versiotasolla . Näiden historiallisten myyntitulosten koonti alueelle tuottaa oikeita tuloksia, mutta analysoitavien myyjien jäsenversioita on vähintään kaksi.

Seuraavassa kaaviossa esitetään myyjädimension jäsenen ennen ja jälkeen -tila, jossa hänen myyntialueensa on muuttunut. Koska organisaatio haluaa analysoida myyjien työtä sen alueen mukaan, jolle heidät on määritetty, tämä käynnistää tyypin 2 hitaasti muuttuvan dimension muutoksen.

Vihje

Kun dimensiotaulukko tukee tyypin 2 hitaasti muuttuvaa dimensiota, sinun on sisällytettävä otsikkomäärite, joka kuvaa jäsentä ja versiota. Otetaan esimerkiksi tilanne, jossa Adventure Worksin myyjä Lynn Tsoflias muuttaa määritystä Australian myyntialueelta Yhdistyneen kuningaskunnan myyntialueelle. Ensimmäisen version otsikkomääritteenä voisi olla "Lynn Tsoflias (Australia)" ja uuden, nykyisen version otsikkomääritteenä voisi olla "Lynn Tsoflias (Yhdistynyt kuningaskunta)." Jos siitä on hyötyä, saatat myös lisätä otsikoseen kelpoisuuspäivämäärät.

Tasapainota historiallisen tarkkuuden tarve käytettävyyden ja tehokkuuden välillä. Yritä välttää liian monen hitaasti muuttuvan dimension tyypin 2 muutoksia dimensiotaulukkoon, koska se voi aiheuttaa valtavan versiomäärän, joka voi vaikeuttaa analyytikoiden ymmärtämistä.

Liian monet versiot saattavat myös tarkoittaa, että muuttuva määrite voidaan tallentaa paremmin faktataulukkoon. Jos aiemman esimerkin laajennetaan, jos myyntialueen muutokset olivat yleisiä, myyntialue voidaan tallentaa faktataulukkoon dimension avaimena sen sijaan, että toteuttaisi hitaasti muuttuvan dimension tyypin 2.

Harkitse seuraavia historiallisen seurannan määritteitä tyypin 2 hitaasti muuttuvan dimension mukaan.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

Tässä ovat historiaseurannan määritteiden tarkoitukset.

• Sarake RecChangeDate_FK sisältää päivämäärän, jolloin muutos tuli voimaan. Sen avulla voit tehdä kyselyn, kun muutoksia tehdään.
• - RecValidFromKey ja RecValidToKey -sarakkeisiin tallennetaan rivin voimassa olevat voimassaolopäivämäärät. Harkitse aikaisimman päivämäärän tallentamista päivämäärädimensiosta alkuperäisen version esittämiseksi RecValidFromKey sekä nykyisten versioiden tallentamista 01/01/9999RecValidToKey .
• Sarake RecReason on valinnainen. Se sallii version lisäämisen syyn dokumentoimisen. Se voi koodata, mitkä määritteet ovat muuttuneet, tai se voi olla lähdejärjestelmän koodi, joka ilmoittaa tietyn liiketoimintasyyn.
• Sarakkeen RecIsCurrent avulla on mahdollista hakea vain nykyiset versiot. Sitä käytetään, kun ETL-prosessi etsii dimensioavaimia faktataulukoiden lataamisen yhteydessä.

Muistiinpano

Jotkin lähdejärjestelmät eivät tallenna historiallisia muutoksia, joten on tärkeää, että dimensio käsitellään säännöllisesti muutosten havaitsemiseksi ja uusien versioiden käyttöön miseksi. Näin voit havaita muutokset pian niiden ilmaantumisen jälkeen, jolloin niiden voimassaoloajat ovat tarkkoja.

Hitaasti muuttuvan dimension tyyppi 3

Hitaasti muuttuvan dimension tyypin 3 muutokset seuraavat rajoitettua historiaa määritteiden avulla. Tämä lähestymistapa voi olla hyödyllinen, kun viimeinen muutos tai uusimpien muutosten määrä on tallennettava.

Tämä hitaasti muuttuvan dimension tyyppi säilyttää rajoitetun historiallisen perspektiivin. Siitä voi olla hyötyä, kun vain alkuperäiset ja nykyiset arvot tallennetaan. Tässä tapauksessa väliaikaisia muutoksia ei tarvittaisi.

Jos esimerkiksi myyjä on määritetty eri myyntialueelle, hitaasti muuttuvan dimension tyyppi 3 korvaa dimensiorivin. Erityisesti edellisen myyntialueen tallentava sarake määritetään edelliseksi myyntialueeksi, ja uudelle myyntialueelle määritetään nykyinen myyntialue.

Seuraavassa kaaviossa esitetään myyjädimension jäsenen ennen ja jälkeen -tila, jossa hänen myyntialueensa on muuttunut. Koska organisaatio haluaa määrittää aiemman myyntialuemäärityksen, se käynnistää tyypin 3 hitaasti muuttuvan dimension muutoksen.

Erityisdimension jäsenet

Voit lisätä dimensioon rivejä, jotka edustavat puuttuvia, tuntemattomia, ei-A-, tai virhetiloja. Voit esimerkiksi käyttää seuraavia korvaavia avainarvoja.

Avainarvo	Tarkoitus
0	Puuttuu (ei käytettävissä lähdejärjestelmässä)
-1	Tuntematon (hakuvirhe faktataulukon lataamisvaiheessa)
-2	N/A (ei käytettävissä)
-3	Virhe

Kalenteri ja aika

Faktataulukot tallentavat mittareita lähes poikkeuksetta tiettyihin kellonajan kohtiin. Jos haluat tukea analyysia päivämäärän (ja mahdollisesti ajan) mukaan, siinä on oltava kalenterin (päivämäärä ja aika) dimensiot.

On harvinaista, että lähdejärjestelmässä on kalenteridimension tietoja, joten ne on luotava tietovarastoon. Yleensä se luodaan kerran, ja jos se on kalenteridimensio, se laajennetaan tulevilla päivämäärillä tarvittaessa.

Päivämäärän dimensio

Päivämäärän (tai kalenterin) dimensio on yleisin analyysiin käytetty dimensio. Se tallentaa yhden rivin päivämäärää kohti, ja se tukee yleistä vaatimusta suodattaa tai ryhmitellä tiettyjen päivämäärien jaksojen, kuten vuosien, vuosineljännesten tai kuukausien, mukaan.

Tärkeä

Päivämäärädimensiossa ei pitäisi olla raketta, joka ulottuu päivänaikaan. Jos kellonaika-analyysi vaaditaan, sinulla tulee olla sekä päivämäärädimensio että aikadimensio (kuvattu seuraavaksi). Faktataulukoissa, jotka tallentavat päivän faktat, on oltava kaksi viiteavainta, yksi kuhunkin näistä dimensioista.

Päivämäärädimension luonnollisessa avaimessa tulee käyttää päivämäärätietotyyppiä. Korvaavan avaimen tulisi tallentaa päivämäärä käyttämällä YYYYMMDD muotoa ja int-tietotyyppiä. Tämän hyväksytyn käytännön tulee olla ainoa poikkeus (aikadimension rinnalla), kun korvaavan avaimen arvolla on merkitys ja se on ihmisen luettavissa. Tietojen tallentaminen YYYYMMDD int-tietotyyppinä ei ole ainoastaan tehokasta ja lajiteltua numeerisesti, vaan se noudattaa myös yksiselitteistä International Standards Organization (ISO) 8601 -päivämäärämuotoa.

Seuraavassa on joitakin yleisiä määritteitä, jotka sisällytetään päivämäärädimensioon.

• Year, Quarter, Month, Day
• QuarterNumberInYear, MonthNumberInYear – joka saattaa vaatia tekstiotsikoiden lajittelua.
• FiscalYear, FiscalQuarter – eräät yrityksen kirjanpitoaikataulut alkavat vuoden puolivälissä, jotta kalenterivuoden ja tilikauden alku/loppu ovat erilaiset.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear – joka saattaa vaatia tekstiotsikoiden lajittelua.
• WeekOfYear – Vuoden viikko voidaan merkitä useilla tavoilla, mukaan lukien ISO-standardi, jolla on joko 52 tai 53 viikkoa.
• IsHoliday, HolidayText – jos organisaatiollasi on useita alueita, säilytä useita juhlapäiväluetteloita, joita kukin maantieteellinen alue pitää erillisenä dimensiona tai naturalisoituna useissa päivämäärädimension määritteissä. Määritteen lisääminen voi auttaa tunnistamaan HolidayText lomat raportointia varten.
• IsWeekday – joillakin alueilla normaali työviikko ei ole maanantaista perjantaihin. Esimerkiksi työviikko on sunnuntaista torstaihin monilla Lähi-idän alueilla, kun taas muilla alueilla käytetään neljän tai kuuden päivän työviikkoa.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset, RelativeDayOffset – joka saattaa vaatia tukemaan suhteellista päivämääräsuodatusta (esimerkiksi edellinen kuukausi). Nykyiset jaksot käyttävät nollan siirtymää (0); edelliset jaksot tallentavat siirtymät arvolle -1, -2, -3...; tulevat jaksot tallentavat 1, 2, 3....

Kuten minkä tahansa dimension kohdalla, on tärkeää, että se sisältää määritteitä, jotka tukevat tunnettuja suodatuksen, ryhmittelyn ja hierarkian vaatimuksia. Joihinkin määritteisiin voi tallentaa selitteiden käännöksiä muille kielille.

Kun dimensiota käytetään yksityiskohtaisiin faktoihin liittyen, faktataulukko voi käyttää päivämääräkauden ensimmäistä päivää. Esimerkiksi neljännesvuosittaisten myyjien tavoitteet tallentava myynnin tavoitetaulukko tallentaisi vuosineljänneksen ensimmäisen päivämäärän päivämäärädimensioon. Vaihtoehtoisesti voit luoda avainsarakkeita päivämäärätaulukkoon. Vuosineljännesavain voi esimerkiksi tallentaa vuosineljännesavaimen käyttämällä YYYYQ muotoa ja pienintä tietotyyppiä.

Dimensioon tulee lisätä kaikkien faktataulukoiden käyttämä tunnettu päivämääräalue. Sen tulee sisältää myös tulevat päivämäärät, jolloin tietovarasto tallentaa faktoja kohteista, budjeteista tai ennusteista. Kuten muissakin dimensioissa, saatat sisällyttää rivejä, jotka edustavat puuttuvia, tuntemattomia, ei-A-rivejä tai virhetilanteita.

Vihje

Etsi Internetistä päivämäärädimensiogeneraattori ja etsi komentosarjoja ja laskentataulukoita, jotka luovat päivämäärätietoja.

Yleensä seuraavan vuoden alussa ETL-prosessin tulee laajentaa päivämäärän dimensiorivit tiettyyn määrään edellä olevia vuosia. Kun dimensio sisältää suhteellisia siirtymämääritteitä, ETL-prosessi on suoritettava päivittäin, jotta siirtymämääritearvot päivitetään nykyisen päivämäärän (tänään) perusteella.

Aikadimensio

Joskus faktat on tallennettava tiettyyn aikaan (kuten kellonaikaan). Luo tässä tapauksessa ajan (tai kellon) dimensio. Siinä voi olla muutamia minuutteja (24 x 60 = 1 440 riviä) tai jopa sekunteja (24 x 60 x 60 = 86 400 riviä). Muita mahdollisia jyviä ovat puoli tuntia tai tunti.

Aikadimension luonnollisen avaimen tulee käyttää aikatietotyyppiä . Korvaava avain voi käyttää asianmukaista muotoa ja tallentaa arvot, joilla on merkitys ja jotka ovat ihmisen luettavissa, esimerkiksi käyttämällä - tai HHMMSS -HHMMmuotoa.

Seuraavassa on joitakin yleisiä määritteitä, jotka sisällytetään aikadimensioon.

• Hour, HalfHour, QuarterHour, Minute
• Ajankohdan otsikot (aamu, iltapäivä, ilta, yö)
• Työvuoron nimet
• Huippu- tai huipun ulkopuoliset liput

Vaatimusten mukaiset dimensiot

Jotkin dimensiot voivat olla vaatimustenmukaisia dimensioita. Vaatimusten mukaiset dimensiot liittyvät useisiin faktataulukoihin, joten ne jaetaan useiden tähtien kesken dimensiomallissa. Ne toimittavat yhdenmukaisuuden ja voivat auttaa sinua vähentämään jatkuvaa kehitystä ja ylläpitoa.

On esimerkiksi tyypillistä, että faktataulukoihin tallennetaan vähintään yksi päivämäärädimensioavain (koska aktiviteetti tallennetaan lähes aina päivämäärän ja/tai ajan mukaan). Tästä syystä päivämäärädimensio on yleinen vaatimusten mukainen dimensio. Varmista siis, että päivämäärädimensio sisältää määritteitä, jotka ovat olennaisia kaikkien faktataulukoiden analyysille.

Seuraavasta kaaviosta Sales näet faktataulukon ja faktataulukon Inventory . Jokainen faktataulukko liittyy dimensioon Date ja Product dimensioon, jotka ovat vaatimustenmukaisia dimensioita.

Toinen esimerkki on se, että työntekijäsi ja käyttäjäsi voivat olla samoja henkilöitä. Tässä tapauksessa voi olla järkevää yhdistää kunkin entiteetin määritteet yhden vaatimusten mukaisen dimension tuottamiseksi.

Rooliulottuvuudet

Kun dimensioon viitataan useita kertoja faktataulukossa, sitä kutsutaan rooliulottuvuudeksi.

Jos esimerkiksi myynnin faktataulukossa on tilauspäivämäärän, lähetyspäivämäärän ja toimituspäivämäärän dimensioavaimet, päivämäärädimensio liittyy kolmeen tapaan. Jokainen tapa edustaa erillistä roolia, mutta fyysisiä päivämäärädimensioita on vain yksi.

Seuraavassa kaaviossa Flight esitetään faktataulukko. Airport Dimensio on rooliulottuvuus, koska se liittyy faktataulukkoon kahdesti dimensiona Departure Airport ja dimensionaArrival Airport.

Roskadimensiot

Roskadimensio on hyödyllinen, kun dimensioita on useita itsenäisiä, etenkin silloin, kun ne sisältävät muutamia määritteitä (ehkä yhden) ja kun näiden määritteiden kardinaliteetti on pieni (vähän arvoja). Roskadimension tavoitteena on koota useita pieniä dimensioita yhdeksi dimensioksi. Tämä rakennemenetelmä voi pienentää dimensioiden määrää ja pienentää faktataulukon avainten ja näin ollen faktataulukon tallennuskoon määrää. Ne myös helpottävät tietoruudun sekoamista , koska käyttäjille on vähemmän taulukoita.

Roskadimensiotaulukko tallentaa yleensä kaikkien dimensiomääritearvojen karteesisen tuotteen, jossa on korvaava avainmäärite.

Hyviä ehdokkaita ovat liput ja indikaattorit, tilauksen tila ja asiakkaiden demografiset osavaltiot (sukupuoli, ikäryhmä ja muut).

Seuraavassa kaaviossa esitetään roskadimensio, jonka nimi Sales Status on ja joka yhdistää tilauksen tila-arvot ja toimituksen tila-arvot.

Johdetut dimensiot

Johdettu dimensio voi ilmetä, kun dimensio on samassa rakeessa kuin liittyvät faktat. Yleinen esimerkki johdettavasta dimensiosta on myyntitilausnumeron dimensio, joka liittyy myynnin faktataulukkoon. Laskunumero on yleensä faktataulukossa yksittäinen, ei-hierarkkinen määrite. Siksi on hyväksytty käytäntö olla kopioimatta näitä tietoja erillisen dimensiotaulukon luomiseksi.

Seuraavassa kaaviossa Sales Order esitetään dimensio, joka on johdettu dimensio myynnin faktataulukon sarakkeen SalesOrderNumber perusteella. Tämä dimensio toteutetaan näkymänä, joka noutaa erilliset myyntitilausnumeroarvot.

Vihje

Fabric Warehouseen voi luoda näkymän, joka esittää johdetun dimension dimensiona kyselyille.

Power BI:n semanttisen mallinnuksen näkökulmasta johdettu dimensio voidaan luoda erillisenä taulukkona Power Queryn avulla. Näin semanttinen malli noudattaa parasta käytäntöä, jonka mukaan suodatukseen tai ryhmään käytetyt kentät ovat peräisin dimensiotaulukoista, ja faktayhteenvedon tekemiseen käytetyt kentät ovat peräisin faktataulukoista.

Ulommat mitat

Kun dimensiotaulukko liittyy muihin dimensiotaulukoihin, sitä kutsutaan poikkeavaksi dimensioksi. Ulompi dimensio voi auttaa määritysten vaatimustenmukaisuutta ja uudelleenkäyttöä dimensiomallissa.

Voit esimerkiksi luoda paikkatietodimension, joka tallentaa jokaisen postinumeron maantieteelliset sijainnit. Tähän dimensioon voidaan sitten viitata asiakasdimensiossa ja myyjädimensiossa, johon tallennetaan maantiededimension korvaava avain. Näin asiakkaita ja myyjiä voidaan sitten analysoida käyttämällä yhtenäisiä maantieteellisiä sijainteja.

Seuraavassa kaaviossa Geography esitetään dimensio, joka on peukalointiulottuvuus. Se ei liity suoraan faktataulukkoon Sales . Sen sijaan se liittyy epäsuorasti dimension Customer ja dimension Salesperson kautta.

Huomaa, että päivämäärädimensiota voidaan käyttää peukalointidimensiona, kun muut dimensiotaulukon määritteet tallentavat päivämääriä. Esimerkiksi asiakasdimension syntymäaika voidaan tallentaa käyttämällä päivämäärädimensiotaulukon korvaavaa avainta.

Moniarvoiset dimensiot

Kun dimensiomääritteen on tallennettava useita arvoja, sinun on suunniteltava moniarvoinen dimensio. Moniarvoisen dimension toteuttaa luomalla siltataulukon(jota kutsutaan joskus liitostaulukoksi). Siltataulukko tallentaa entiteettien välisen monta-moneen-suhteen.

Ajattele esimerkiksi, että on olemassa myyjädimensio ja että jokainen myyjä on määritetty yhteen tai mahdollisesti useampaan myyntialueeseen. Tässä tapauksessa on järkevää luoda myyntialuedimensio. Kyseinen dimensio tallentaa kunkin myyntialueen vain kerran. Erillinen taulukko, jota kutsutaan siltataulukoksi, tallentaa rivin kullekin myyjä- ja myyntialuesuhteelle. Fyysisesti myyjädimensiosta on yksi-moneen-suhde siltataulukkoon ja toinen yksi moneen -suhde myyntialue-dimensiosta siltataulukkoon. Loogisesti myyjien ja myyntialueiden välillä on monta-moneen-suhde.

Seuraavassa kaaviossa Account dimensiotaulukko liittyy Transaction faktataulukkoon. Koska asiakkailla voi olla useita tilejä ja tileillä voi olla useita asiakkaita, Customer dimensiotaulukko liittyy toisiinsa siltataulukon Customer Account kautta.

Liittyvä sisältö

Tämän sarjan seuraavassa artikkelissa kerrotaan faktataulukoiden ohjeista ja suunnittelusta.