Dimensioiden mallinnus

Kirjoittanut Samu Lahdenperä · Julkaistu 1.6.2026

Dimensio on dataa kuvaileva taulu joka vastaa kysymyksiin kuka, mitä, missä, milloin ja miten. Dimensioita käytetään usein kertomaan tapahtumien lisätietoja esim. asiakaskohtaisesti. Faktataulussa on luvut ja dimensiossa konteksti sekä metatiedot. Ilman hyvin mallinnettuja dimensioita faktataulun rivit ovat pelkkää numerosarjaa.

Dimensiot toimivat 1:M relaatioiden kautta. Jokaiselle faktataulun riville löytyy tasan yksi vastaava rivi dimensiossa. Tämä yksi-moneen-suhde (1:*) on tähtimallin perusrakenne.

Dimension rakenne

Hyvin rakennettu dimensio on leveä ja litteä: paljon kuvailevia sarakkeita, ei alatauluja. Tämä on tietoista denormalisointia. Loppukäyttäjät haluavat suodattaa asiakasta maan, segmentin ja toimialan mukaan yhdestä taulusta, ei kolmesta liittyneestä taulusta. Jos data tulee hierarkkisena lumihiutalemallina, se on hyvä yhdistää yhdeksi tauluksi ennen lataamista — katso taulujen litistäminen.

Taulukko 1, Asiakasrakenne – Esimerkki siitä mitä sarakkeita dimensiotaulut pitävät sisällään ja miksi
Osa	Rooli	Esimerkki
Surrogaattiavain (SK)	Dimension pääavain (PK). Aina kokonaisluku, aina järjestelmän generoima — ei koskaan lähdejärjestelmän avain. Mahdollistaa historian säilyttämisen.	AsiakasAvain INT
Luonnollinen avain (NK / Business Key)	Lähdejärjestelmän tunniste. Säilytetään dimensiossa hakua ja debug-työtä varten, mutta ei käytetä relaatioihin.	AsiakasTunnus VARCHAR
Attribuutit	Kuvailevat sarakkeet, joilla raportissa suodatetaan, ryhmitellään ja leikataan. Matala kardinaliteetti = nopea suorituskyky.	Maa, Kaupunki, Segmentti, Toimiala
Voimassaoloaika	SCD Type 2 -mallinnuksessa: mistä alkaen ja mihin saakka rivi on voimassa.	AlkuPvm DATE, LoppuPvm DATE, OnkoNykyinen BIT

Parhaat käytännöt

Dimension mallinnuksen kultaiset säännöt:

Ei tyhjiä rivejä. Jos faktataulun FK ei löydä vastaavaa dimensioriviä, se jää tyhjäksi. Tämä ei ole "normaali" tila, tämä on virhe. Korjaa ETL-prosessi tai korvaa se erillisellä "Tuntematon"-rivillä.
Blankeille ja tuntemattomille omat rivit. Luo dimensioon rivit kuten Tuntematon asiakas, Ei kohdistettavissa, Uusi asiakas (ei rekisteröity). Näin faktataulun jokainen rivi löytää parinsa ja raportit pysyvät luvultaan oikeina.
Surrogaattiavain on aina kokonaisluku. VertiPaq pakkaa kolmunääripohjaisen pakkauksen myötä INT-sarakkeet erittäin tehokkaasti. GUID- tai merkkijono-avaimet turvottavat mallia ja hidastavat laskentaa.
Yksi rivi per yksilö (nykyinen tila). Ellei käytetä SCD Type 2 -historiaa, dimensiossa on täsmälleen yksi rivi per asiakas, tuote tai muu kokonaisuus. Duplikaattiavaimet rikkovat relaation ja vääristävät laskurit. Duplikaattirivi on aina virhe.
Leveä, ei syvä. Denormalisoi eli litistä alataulut päädimensioon. AsiakasDimensio sisältää suoraan Maa, Maanosa, Alue — ei erillistä MaaDimensiota joka linkittyy AsiakasDimensioon.
Attribuuttien kardinaliteetti matalaksi. Vältä sarakkeita, joilla on miljoonia uniikkeja arvoja dimensiossa. Päivämäärä-timestamp (sekunti-tarkkuus) dimensioattribuuttina tuhoaa pakkauksen ja tekee kaikesta hitaampaa ja huonompaa.
INT-tyyppiset relaatiot ovat aina nopeampia kuin muut relaatiot. Isoissa, yli miljoonan rivin dimensioissa STRING/VARCHAR-relaatiot ovat noin 1/3 hitaampia kuin INT-avaimiin perustuvat yhteydet. Nimeä avainkenttä miten tahansa, mutta varmista että sen tietotyyppi on kokonaisluku jos viet sen Power BI:hin.
Hyvin tehty dimensio on käytettävissä monessa paikassa. AsiakasDimensio voi liittyä Myynti-, Tilaus- ja Reklamaatio-faktatauluihin. Tee dimensiosta niin kattava, että sitä ei tarvitse rakentaa erikseen joka raporttiin.

Slowly Changing Dimensions (SCD) — muutostyypit

Lähes kaikki dimensiot muuttuvat ajan myötä: asiakas vaihtaa kaupunkia, tuote vaihtaa kategoriaa, myyjä siirtyy toiseen tiimiin. SCD-tyyppi määrittää, miten dimensio käsittelee muutokset — säilytetäänkö historia vai ylikirjoitetaanko vanha tieto.

Taulukko 2, Slowly Changing Dimensions (SCD) – Taulukossa käydään lävitse erilaiset SCD-tallenustyypit ja käyttötilanteet dimensioilla
Tyyppi	Nimi	Toiminta	Historia	Käyttötilanne
Type 0	Kiinteä	Arvo ei muutu koskaan latauksen jälkeen.	Ei	Syntymäpäivä, alkuperäinen rekisteröintipäivä
Type 1	Ylikirjoita	Vanha arvo korvataan uudella. Yksinkertaisin toteutus.	Ei, historia katoaa	Kirjoitusvirheen korjaus, osoitteen päivitys kun historialla ei ole merkitystä
Type 2	Lisää uusi rivi	Muutos luo uuden rivin uudella surrogaattiavaimella. Vanha rivi suljetaan (LoppuPvm). Faktataulun historialliset rivit viittaavat edelleen vanhan rivin avaimeen.	Kyllä, täydellinen historia	Asiakkaan siirtyminen toiseen segmenttiin, myyjän tiimivaihdos, silloin kun historiatiedolla on liiketoiminnallinen merkitys
Type 3	Lisää sarake	Lisätään erillinen sarake "edellinen arvo" varten. Tallentaa vain yhden historiavaiheen.	Osittain, vain yksi askel taaksepäin	Harvinainen. Toimii kun tarvitaan vain "nykyinen vs. edellinen" -vertailu
Type 4	Historiataulu	Nykyarvot pysyvät päädimensiossa. Muutoshistoria tallennetaan erilliseen historiatauluun.	Kyllä, erillisessä taulussa	Kun dimensio on erittäin suuri ja historiamuutoksia paljon — Type 2 turpoaa liikaa
Type 6	Hybridi (1+2+3)	Yhdistää tyypit 1, 2 ja 3: uusi rivi muutoksesta (Type 2), nykyarvo päivitetään kaikkiin riveihin (Type 1), edellinen arvo säilyy omassa sarakkeessa (Type 3).	Kyllä + nykyarvo helposti saatavilla	Kun tarvitaan sekä historia että helppo suodatus nykyisellä arvolla ilman monimutkaisia DAX-kaavoja

Type 2 käytännössä — esimerkki:

Asiakas Matti Meikäläinen (AsiakasTunnus = CU-001) siirtyy segmentistä "Pienasiakas" segmenttiin "Avainasiakas" 15.3.2024.

Taulukko 3, SCD 2 – Esimerkki miltä SCD 2 muutokset näyttävät datassa
AsiakasAvain (SK)	AsiakasTunnus (NK)	Nimi	Segmentti	AlkuPvm	LoppuPvm	OnkoNykyinen
1001	CU-001	Matti Meikäläinen	Pienasiakas	2020-01-01	2024-03-14	0
1847	CU-001	Matti Meikäläinen	Avainasiakas	2024-03-15	9999-12-31	1

Faktataulun myyntirivit ennen 15.3.2024 viittaavat AsiakasAvaimeen 1001 → segmentti "Pienasiakas". Myyntirivit sen jälkeen viittaavat avaimeen 1847 → segmentti "Avainasiakas". Historia säilyy täydellisenä ilman erillistä muutoslokia.

Koko, kardinaliteetti ja suorituskyky Power BI:ssä

Power BI:n VertiPaq-moottori pakkaa sarakkeet kardinaliteetin perusteella: mitä vähemmän uniikkeja arvoja, sitä parempi pakkaussuhde ja sitä nopeampi kysely. Surrogaattiavain on ainoa sarake, jolla odotetaan korkea kardinaliteetti — kaikki muut attribuutit tulisi pyrkiä pitämään matalana.

Taulukko 4, Dimensioiden kardinaliteetit – Kardinaliteetin vaikutus Power BI dimensioiden suorituskykyyn
Dimension koko	Uniikkeja avaimia	Esimerkki	Muistivaikutus	Huomiot
Pieni	< 1 000	Maa, alue, tuotekategoria, myyntikanava	Minimaali	Erinomainen pakkaus. Ei suorituskykyhuolia missään tilanteessa.
Pieni–keski	1 000 – 100 000	Tuotedimensio (laaja katalogi), kustannuspaikat	Matala	Toimii hyvin. Varmista että attribuuttisarakkeet eivät ole korkean kardinaliteetin tekstikenttiä.
Keski	100 000 – 1 000 000	Asiakasdimensio (keskisuuri yritys)	Kohtalainen	VertiPaq pakkaa edelleen hyvin jos attribuutit ovat koodeja/kategorioita. Vältä vapaamuotoisia tekstisarakkeita.
Suuri	1 000 000 – 10 000 000	Asiakasdimensio (suuri yritys tai kuluttajapalvelu)	Merkittävä	Suunnittele huolellisesti. Poista turhat sarakkeet. Harkitse Type 4 -historiamallinnusta Type 2:n sijasta ettei rivisarakkeiden määrä räjähdä.
Erittäin suuri	> 10 000 000	Verkkosivuston käyttäjät, IoT-laitteet	Korkea — arkkitehtuurivalinta	Harkitse aggregointeja tai hierarkkista rakennetta. Taulussa on enemmän rivejä kuin tavanomaisessa faktataulussa — varmista onko se oikeasti dimensio vai fakta.

Kardinaliteetin vaikutus pakkaussuhteeseen — esimerkki:

Asiakasdimensio, 2 000 000 riviä:

Taulukko 5, Ongelmalliset korkean kardinaliteetin sarakkeet – Ongelmalliset yksilöidyt korkean kardinaliteetin sarakkeet nostavat 10 mb dimension koon lähes 700 mb kokoiseksi
Sarake	Uniikkeja arvoja	Tyyppi	Arvioitu koko muistissa
AsiakasAvain (SK)	2 000 000	INT	~8 MB, INT pakkautuu erinomaisesti
Segmentti	5	VARCHAR	< 1 MB, lähes ilmainen
Maa	40	VARCHAR	< 1 MB, lähes ilmainen
Sähköposti (korkea kardinaliteetti)	2 000 000	VARCHAR	~200–400 MB, ei pakkaudu, jokainen arvo tallennetaan erikseen
Rekisteröintiaika (timestamp)	~1 800 000	DATETIME	~150–300 MB, lähes jokainen arvo uniikki, pakkaus epäonnistuu

Ratkaisu: Poista raporteille hyödyttömät korkean kardinaliteetin sarakkeet (sähköposti, puhelin) dimensiosta tai lataa ne erilliseen dimensioon josta niihin viitataan vain tarvittaessa. Timestamp-sarakkeet muunna DATE-tyypiksi tai liitä erilliseen Päivämääradimensioon.

Dataneuvoksen mielipide

Kolme asiaa, jotka on tehtävä oikein ennen kaikkea muuta:

Ei tyhjiä rivejä dimensioissa. Tyhjä rivi on oire, ei ominaisuus. Se syntyy kun faktataulussa on FK-arvo jolla ei ole vastinetta dimensiossa. Tämä johtuu yleensä ETL-virheestä tai puuttuvasta "tuntematon"-rivistä. Power BI luo tällöin automaattisesti "Blank"-rivin, joka näkyy raporteissa eikä siihen voi liittää attribuutteja. Korjaa ennen julkaisua.
Blankeille ja nollatiedoille omat rivit. Kun et tiedä asiakkaan segmenttiä, faktataulun rivi ei silti saa jäädä kohdistamatta. Luo dimensioon eksplisiittiset rivit: Tuntematon, Ei kohdistettavissa, Ei sovellettavissa. Näin kaikki luvut summautuvat oikein ja tiedät aina kuinka suuri osuus datasta on tunnistamatonta — se itsessään on liiketoiminnallisesti arvokas tieto.
Hyvin tehty dimensio on käytettävissä monessa paikassa. AsiakasDimensio, jossa on kaikki tarvittavat attribuutit, liittyy yhtä hyvin Myynteihin, Tilauksiin kuin Reklamaatioihinkin. Älä rakenna "Myynti-AsiakasDimensiota" ja "Tilaukset-AsiakasDimensiota" erikseen. Ne ovat sama asia ja kaksi versiota tarkoittaa kaksi kertaa enemmän ylläpitoa ja kaksi kertaa enemmän mahdollisuuksia ristiriitaisuuksiin.