Ryhmittele BI-tieto dimensioihin
Jos tieto on järjestyksessä, löytää helposti etsimänsä. Kun menen kirjastoon etsimään uusia kiinnostavia talouskirjoja, kävelen liiketalouden hyllylle 69. Minun ei tarvitse tutkia kaikkia hyllyjä, koska kirjaston luokitusjärjestelmän takia samankaltainen tieto on ryhmitelty samaan paikkaan. Mielestäni yritysten tulisi pyrkiä kirjaston kaltaiseen kurinalaisuuteen tiedonjärjestelyssä. Kirjastojen YKL-järjestelmän sijaan tarvitsemme toisenlaisen yritysdatalle sopivan järjestelmän, joista esittelen Ralph Kimballin dimensiomallinnuksen.
Miltä dimensio näyttää?
Kirjaston hyllyjen ja luokkien sijaan tietovaraston ylläpitäjä ryhmittelee datan dimensioihin, joissa on yhden aihepiirin tietoa. Esimerkiksi asiakastieto kerätään asiakasdimensioon, johon on listattu kaikki perustiedot asiakkaasta.
Asiakasavain | Asiakastunniste | Asiakasnimi | Osoite | Asiakasluokka |
---|---|---|---|---|
1 | 101A | Osmo Ostaja | Ostokuja 3 | A |
2 | 103F | Pauli Pihi | Saitakatu 1 | C |
3 | 104A | Taru Tarkkamarkka | Tilitie 2 | B |
Tietovaraston tiedonsiirto-ohjelma hakee päivittäin myyntijärjestelmästä uudet asiakastiedot ja siirtää ne asiakasdimensioon. Sarake asiakastunniste on myyntijärjestelmän luoma yksilöivä tunniste asiakkaalle ja asiakasluokka on myyntitiimin ideoima luokittelu, joka kertoo asiakkaan ostokäyttäytymisestä.
Asiakasavain on poikkeuksellinen sarake, sillä tietovaraston ylläpitäjä on luonut sen pelkästään raportoinnin tarkoituksiin. Pohjimmiltaan sillä on sama tarkoitus kuin asiakastunnisteella, mutta se tarjoaa muutaman edun verrattuna myyntijärjestelmän tunnisteeseen, jotka esitän myöhemmin. Avain on yhdistävä tekijä, jolla asiakastiedon saa linkitettyä esimerkiksi laskutustietoihin. Kun laskutustietoja sisältävässä faktataulussa viitataan asiakkaaseen avainarvolla 1, tiedämme heti, että kyse on Osmo Ostajasta ja asiakasluokasta A, ilman että joudumme kirjoittamaan kaikkia asiakastiedon sarakkeita faktataulun riville.
Miten dimensioviittaus käytännössä toimii?
Ilman dimensiomallinnusta ja -viittausta keräisimme kaiken mahdollisen tiedon yhteen tauluun. Jos tutkisimme laskutustietoa, meillä olisi yksi rivi jokaista laskua kohden ja sarakkeista näkisimme, kuka on ostoksen tehnyt ja millä hinnalla.
Laskunumero | Asiakastunniste | Asiakasnimi | Osoite | Asiakasluokka | Summa |
---|---|---|---|---|---|
1001 | 101A | Osmo Ostaja | Ostokatu 3 | A | 150 |
1002 | 101A | Osmo Ostaja | Ostokatu 3 | A | 120 |
1003 | 101A | Osmo Ostaja | Ostokatu 3 | A | 190 |
1004 | 103F | Pauli Pihi | Saitakatu 1 | C | 50 |
1005 | 103F | Pauli Pihi | Saitakatu 1 | C | 40 |
Yllä oleva datataulukko on Excel-taulukointiohjelman taitajalle helppo ymmärtää ja muokata. Meillä on kaikki tarvittava tieto yhdessä paikassa. Vaikka malli vaikuttaa ensisilmäyksellä hyvältä, on siinä puutteita, jotka hankaloittavat BI-raportointia:
- kun sarakkeita on paljon, taulukosta tulee iso ja raporteista hitaita
- kun asiakastieto muuttuu, pitää muutos korjata useille laskuriveille
- kun aloitamme uuden BI-projektin, joudumme aloittamaan tyhjästä
Dimensioiden avulla pystymme välttämään yllä mainitut ongelmat. Sen sijaan, että kirjoittaisimme kaikki asiakastiedot jokaiselle laskuriville, viittaamme asiakkaaseen pelkällä avaimella. Laskuriviltä näemme silloin, että lasku liittyy asiakasavaimeen 1, ja asiakasdimensiosta näemme, että asiakasavain 1 liittyy asiakkaaseen Osmo Ostaja.
Laskunumero | Asiakasavain | Summa |
---|---|---|
1001 | 1 | 150 |
1002 | 1 | 120 |
1003 | 1 | 190 |
1004 | 2 | 50 |
1005 | 2 | 40 |
Eikö ole vaivalloista selvittää, mihin asiakkaaseen avain viittaa? Olisi, jos yhdistely olisi ihmisen vastuulla. Onneksi tietokannat ovat erinomaisia tämän tyylisissä yhdistelytöissä, eikä yhdistelyvaihetta näytetä raportin luojille tai käyttäjille. Jos Power BI -työkalun käyttäjä haluaa asiakkaan nimen näkyviin, riittää että hän raahaa asiakasnimikentän raportille. Tietokanta tekee yhdistelyn, eli tietokantaliitoksen, kulissien takana, jolloin käyttäjä saa dimensiomallinnuksen hyödyt mutta ei haittoja.
Tyyppi 1: Mitä jos asiakkaan sukunimi muuttuu?
Asiakkaamme Osmo Ostaja on mennyt naimisiin ja vaihtanut sukunimensä Tuhlariksi. Jos käytössämme olisi yhden taulun malli, joutuisimme etsimään kaikki laskurivit, jotka liittyvät Osmoon, ja muuttaisimme niissä sukunimen. Tämä ei ole iso työ, jos laskutustaulu on pieni, mutta laskutustaulu voi olla miljoonien rivien kokoinen. Voimme joutua korjaamaan tuhansia rivejä yhden nimimuutoksen takia.
Jos taas hallinnoimme asiakastietoa asiakasdimensiossa, riittää että korjaamme tiedon yhteen paikkaan. Etsimme asiakasdimensiosta oikean rivin ja muutamme asiakasnimeksi Osmo Tuhlari. Meidän ei tarvitse koskea laskuriveille ollenkaan, sillä avaimet viittaavat asiakasdimensioon, joka on jo ajan tasalla.
Dimensiomallinnuksen termein kyse on tyypin 1 muutoksesta, eli ylikirjoitamme vanhan arvon uudella. Tyypin 1 muutos on yleisin käytetty dimensiomallinnuksen muutos.
Tyyppi 2: Mitä jos asiakas muuttaa uuteen osoitteeseen?
Pauli Pihi on muuttanut uuteen edulliseen asuntoon Itaratielle. Asiakastieto on muuttunut, mutta mihin tieto tulisi korjata? Emme halua muuttaa vanhoilla laskuilla olevia osoitteita, sillä ne olivat myyntihetkellä oikeita toimitusosoitteita. Uuden osoitteen tulisi näkyä vain uusilla laskuilla.
Laskunumero | Asiakastunniste | Asiakasnimi | Osoite | Asiakasluokka | Summa |
---|---|---|---|---|---|
1004 | 103F | Pauli Pihi | Saitakatu 1 | C | 50 |
1005 | 103F | Pauli Pihi | Saitakatu 1 | C | 40 |
1006 | 103F | Pauli Pihi | Itaratie 2 | C | 30 |
Yllä olevassa yhden taulun mallissa muutos onnistuu helposti. Tilanne monimutkaistuu, kun käytämme asiakasdimensioita. Jos korvaisimme asiakasdimensiossa olevan vanhan osoitteen uudella, laskurivit viittaisivat edelleen oikeaan asiakkaaseen, mutta meillä ei olisi enää tietoa vanhasta osoitteesta. Silloin näyttäisi siltä, että vanhatkin toimitukset ovat menneet uuteen osoitteeseen.
Jotta asiakasdimensiossa olisi tieto sekä uudesta ja vanhasta osoitteesta, joudumme käyttämään toisenlaista muutostapaa eli tyyppiä 2. Sen sijaan, että korvaisimme vanhan tiedon uudelle, lisäämmekin kokonaan uuden asiakasrivin ja voimassaolon ajanjaksot.
Avain | Tunniste | Asiakasnimi | Osoite | Luokka | Alkaa | Päättyy |
---|---|---|---|---|---|---|
1 | 101A | Osmo Ostaja | Ostokuja 3 | A | 2010-01-01 | 9999-12-31 |
2 | 103F | Pauli Pihi | Saitakatu 1 | C | 2010-01-01 | 2019-08-31 |
3 | 104A | Taru Tarkkamarkka | Tilitie 2 | B | 2010-01-01 | 9999-12-31 |
4 | 103F | Pauli Pihi | Itaratie 2 | C | 2019-09-01 | 9999-12-31 |
Nyt meillä on kaksi riviä Paulille, joista ensimmäinen on voimassa aikavälillä 1.1.2010 - 31.8.2019 ja toinen 1.9.2019 - 31.12.9999. Vuosi 9999 on keinotekoinen päiväys, jolla kerromme, että rivi on voimassa toistaiseksi. Jos Pauli muuttaisi joulukuussa uudelleen, lisäisimme uuden rivin ja muuttaisimme rivin 4 päättymispäiväksi 31.12.2019.
Laskutustaulussa viittaisimme Pauliin kahdella eri avaimella. Avain 2 viittaisi vanhaan osoitteeseen ja avain 4 uuteen.
Laskunumero | Asiakasavain | Summa |
---|---|---|
1004 | 2 | 50 |
1005 | 2 | 40 |
1006 | 4 | 30 |
Vaikka loimme samalle asiakkaalle kaksi eri riviä, meillä ei ole raporteilla kuitenkaan kahta eri Paulia. Jos Power BI:n käyttäjä raahaa asiakasnimen raporttitauluun, hän näkee edelleen yhden asiakasnimen. Jos hän olisi raahannut osoitteen, näkyisi raporttitaulussa uusi ja vanha osoite.
Dimensioiden muutosten hallinta
Esittelin yllä kaksi yleistä tapaa, joilla dimensioiden muutoksia hallitaan. Jos BI-kehittäjä ymmärtää nämä kaksi muutostyyppiä, selviää hän kehitystyössä todella pitkälle. Voisin esittää asian myös rajummin, eli jos näitä kahta muutostyyppiä ei hallitse, ei pysty hoitamaan business intelligence -asiantuntijan tehtäviä kunniallisesti.
Muutostyyppejä on muitakin ja tarkka määrä vaihtelee vastaajan mukaan. Dimensiomallinnuksen johtohahmo Ralph Kimball listaa dimensiomallinnusta käsittelevässä kirjassaan1 kahdeksan erilaista muutostyyppiä:
Tyyppi | Säilytettävä arvo | Toteutus |
---|---|---|
0 | Vain alkuperäinen arvo | Ei muutosta |
1 | Nykyinen arvo | Ylikirjoita dimension kenttä |
2 | Historiallinen arvo | Lisää dimensioon uusi rivi |
3 | Nykyinen ja edeltävä arvo | Lisää dimensioon uusi sarake |
4 | Historiallinen arvo | Viittaa faktataulussa minidimensioon |
5 | Historiallinen ja uusin arvo | Viittaa faktataulussa ja dimensiossa minidimensioon |
6 | Historiallinen ja uusin arvo | Lisää dimensioon uusi rivi ja sarake |
7 | Historiallinen ja uusin arvo | Viittaa faktataulussa historialliseen ja nykyiseen dimensioon |
Käytännössä tyypit 0–3 ovat riittäviä lähes kaikkiin BI-projekteihin, sillä niiden avulla mallintaja selviää tyypillisistä muutosongelmista. Tyyppi 4 auttaa tilanteissa, joissa dimension arvo muuttuu jatkuvasti ja tyypin 2 muutos synnyttäisi liikaa uusia rivejä. Tyypit 5–7 ovat hybridimalleja eli yhdistelmiä aiemmista muutostyypeistä.
Suosittelen Kimballin teoksia kaikille dimensiomallinnuksesta kiinnostuneille, sillä hitaasti muuttuvat dimensiot on taiteenala, johon BI-kehittäjien täytyy syventyä.
Kimball & Ross (2013) The Data Warehouse Toolkit - The Definitive Guide to Dimensional Modeling. Wiley. ↩︎