Faktataulujen kolme tyyppiä

Ralph Kimball määrittelee dimensiotietomallinnuksessa kolmenlaisia faktatauluja. Nämä ovat:

• Transaktiotietotaulukot.
• Jaksoittaiset tilannekuvatietotaulukot ja
• Kertyvät tilannekuvatietotaulukot.

Tässä postauksessa käymme läpi kutakin näistä tietotaulukkotyypeistä ja pohdimme sen jälkeen, miten ne eivät ole muuttuneet vuosien aikana sen jälkeen, kun Kimball on viimeksi päivittänyt tietovarastotyökalupaketin. Jos nämä kolme faktataulukkoluokkaa ovat sinulle tuttuja, hyppää eteenpäin lopussa olevaan analyysiin; jos et ole, pidä tätä tiiviinä katsauksena yhteen Kimball-tyylisen tietomallinnuksen peruskomponenttiin.

Kaksi lyhyttä huomautusta ennen kuin aloitamme: ensinnäkin tässä artikkelissa oletetaan, että olet perehtynyt tähtikaavioon. Lue tämä, jos tarvitset pohjustusta – oletan, että ymmärrät faktataulukot ja dimensiotaulukot minimissään. Toiseksi huomautan, että Kimball tunnustaa neljännen faktataulukkotyypin – aikavälifaktataulun – mutta sitä käytetään vain erityistapauksissa. Jätämme sen tämän keskustelun ulkopuolelle.

Transaktiotietotaulukot

Transaktiotietotaulukot on helppo ymmärtää: asiakas tai liiketoimintaprosessi tekee jotakin; haluat tallentaa tuon tapahtuman, joten tallennat transaktion tietovarastoosi ja olet valmis.

Tämä on parhaiten havainnollistettavissa yksinkertaisella esimerkillä. Kuvitellaan, että sinulla on päivittäistavarakauppa ja sinulla on sähköinen myyntipistejärjestelmä (POS), joka tallentaa jokaisen tekemäsi myynnin.

Tyypillisessä Kimball-tyylisessä tähtikaaviossa kaavion keskellä oleva faktataulu koostuisi tilaustapahtumatiedoista. Nämä ovat pääasiassa numeerisia mittareita, kuten tilauksen loppusumma, rivikohtaiset määrät, myytyjen tuotteiden kustannukset, sovelletut alennusmäärät ja niin edelleen.

Voit siis nähdä, että transaktiotietotaulukko on juuri sitä, mitä siinä lukee: saat transaktion, kirjaat transaktion faktataulukkoon, ja siitä tulee raportointisi perusta. Transaktiotietotaulu on monella tapaa oletustyyppinen faktataulu, jota olemme tottuneet ajattelemaan.

Jaksoittaiset tilannekuvatietotaulut

Jaksoittaiset tilannekuvatietotaulut ovat looginen jatke edellä käsitellyille tavallisille faktatauluille. Jaksottaisen tilannekuvatietotaulukon rivi tallentaa jonkinlaista jaksottaista tietoa – esimerkiksi päivittäisen tilannekuvan taloudellisista tunnusluvuista tai ehkä viikoittaisen yhteenvedon myyntisaamisista tai kuukausittaisen yhteenvedon varastomääristä.

Muilla sanoilla ”jyvä” tai ”resoluutiotaso” on jakso, ei yksittäinen tapahtuma. Huomaa, että jos tietyn jakson aikana ei tapahdu yhtään tapahtumaa, jaksoittaiseen tilannekuvatauluun on lisättävä uusi rivi, vaikka jokainen tallennettu fakta olisi nolla!

Jaksoittaiset tilannekuvataulukot sisältävät yleensä uskomattoman suuren määrän kenttiä. Tämä johtuu siitä, että jaksotaulukkoon voidaan tunkea mikä tahansa kohtuullisen kiinnostava mittari. Voit tavallaan kuvitella skenaarion, jossa aluksi sinulla on viikoittain aggregoidut myynnin, liikevaihdon ja myydyn tavaran kustannusten tiedot, mutta ajan kuluessa johto pyytää sinua lisäämään muita faktoja, kuten varastotasoja, maksettavien tilien tunnuslukuja ja muita mielenkiintoisia mittaustietoja.

Miksi jaksoittaiset tilannekuvatietotaulukot ovat hyödyllisiä? No, tämä on melko suoraviivaista kuvitella. Jos haluat saada yleiskuvan yrityksesi keskeisten tunnuslukujen kehityslinjoista, on hyödyllistä tehdä kysely jaksoittaista faktataulukkoa vastaan.

Kertyvät tilannekuvataulukot

Jaksoittaisista tilannekuvataulukoista poiketen kertyviä tilannekuvataulukoita on hieman vaikeampi selittää. Ymmärtääksemme, miksi Kimball ja hänen kollegansa keksivät tämän lähestymistavan, auttaa ymmärtämään hieman sitä, millaisia kysymyksiä liike-elämältä kysyttiin 90-luvulla, jolloin Data Warehouse Toolkit -työkalupakki kirjoitettiin ensimmäisen kerran.

80-luvun loppupuolella japanilaiset valmistajat alkoivat päihittää amerikkalaiset kollegansa kaikenlaisilla ikävillä mutta ei-selkeillä tavoilla. Tärkein näistä oli keskittyminen toteutusnopeuteen.

Valmistaminen voidaan nähdä sarjana vaiheita. Tehtaan toiseen päähän viedään raaka-aine, josta toisessa päässä valmistetaan autoja, puhelimia ja vekottimia. Jokainen valmistusprosessin vaihe voidaan mitata – kuinka kauan kestää esimerkiksi muuttaa teräslohkot teräspelleteiksi? Kuinka kauan ne odottavat tehtaan varastossa? Ja kuinka kauan kestää, ennen kuin pelletit valmistetaan autonosiksi? Kuinka kauan kestää, ennen kuin niitä käytetään varsinaisissa autoissa?

70-luvun lopulla japanilaiset yritykset alkoivat ymmärtää, että tämä ”vaiheittainen” näkemys arvonluonnista voisi johtaa vakavaan kilpailuetuun, jos ne lyhentäisivät kunkin vaiheen välistä viiveaikaa. Konkreettisemmin sanottuna: jos japanilaiset valmistajat pystyivät vähentämään kunkin tuotteen valmistamiseen tarvittavien vaiheiden määrää ja kunkin vaiheen sisällä kuluvan ajan pituutta, he oppivat, että he pystyivät vähentämään materiaalihävikkiä, pienentämään vikojen määrää ja lyhentämään toimitusaikaa ja samalla lisäämään työntekijöiden tuottavuutta, kasvattamaan valmistusvolyymia, laajentamaan tuotevalikoimaa ja alentamaan hintoja – ja kaikki tämä samanaikaisesti.

90-luvulle tultaessa länsimaalaiset yritykset olivat jo tajunneet asian. Useat liikkeenjohdon konsultit – tärkeimpänä heistä George Stalk Jr Boston Consulting Groupista – alkoivat puolustaa toteutustahtia kilpailuedun lähteenä. Nämä konsultit kehottivat yrityksiä kirjaamaan tuotantoprosessin kuhunkin vaiheeseen käytetyn ajan. Kun tilaus saapui, kuinka kauan sen käsittely kesti? Kun se oli käsitelty, kauan ennen kuin tilaus lähetettiin tehtaalle? Kuinka kauan tehtaalla kesti, ennen kuin tuote valmistui? Ja kuinka kauan se odotti varastossa? Ja lopuksi, kuinka kauan kesti, ennen kuin asiakas sai tuotteen ja sai siitä arvoa?

Yritykset joutuivat siis 90-luvulla mittaamaan viiveaikoja koko liiketoiminnan toimitusprosessin ajan. Niiden oli pakko tehdä näin, koska japanilaiset kilpailijat tunkeutuivat monille toimialoille, joita länsimaiset yritykset olivat aiemmin hallinneet – joissakin tapauksissa aiheuttaen konkursseja ja häiriten kokonaisia toimitusketjuja. Tässä ympäristössä Kimball työskenteli.

Kertyvä tilannekuvan faktataulukko on siis menetelmä, jolla mitataan nopeutta liiketoimintaprosessissa. Otetaan esimerkiksi tämä liiketoimintaputki, jonka Kimball esitteli The Data Warehouse Toolkit -teoksen toisessa painoksessa:

Tälle prosessille Kimball ehdotti seuraavaa akkumuloivaa tilannekuvatietotaulukkoa:

Taulukon jokainen rivi edustaa tilausta tai tilauserää. Kutakin näistä riveistä odotetaan päivitettävän useita kertoja, kun ne etenevät tilausten täyttämisputken läpi. Huomaa erityisesti päivämääräkenttien suuri määrä skeeman yläosassa. Kun rivi luodaan ensimmäistä kertaa tähän taulukkoon, suurin osa näistä päivämääristä on aluksi nollia, mutta ne täyttyvät ajan myötä. (Huomautus: Kimball käyttää tässä päivämäärän dimensiotaulukkoa SQL:n sisäänrakennetun päivämäärän tietotyypin sijasta, koska se on The Kimball Way ™ – sen avulla voit kaapata päivämääristä enemmän tietoa kuin vain naiivit päivämäärätyypit.)

Tärkeitä ovat myös tuon listan alareunassa olevat kentät. Jokainen niistä mittaa viiveindikaattoria – eli kahden päivämäärän välistä eroa. Niinpä esimerkiksi Order to Manufacturing Release Lag on aika, joka kuluu ajasta Order Date vuoteen Release to Manufacturing Date; Inventory to Shipment Lag on aika, joka kuluu ajasta Finished Inventory Placement Date vuoteen Actual Ship Date, ja niin edelleen. Kun aika kuluu, ERP-järjestelmä tai kenties tietojen syöttäjä täyttää jokaisen näistä päivämääristä. Kunkin yksittäisen tilauksen viiveajat laskettaisiin siis sitä mukaa, kun kukin kenttä täytetään.

Voit nähdä, miten tällainen taulukko olisi hyödyllinen yritykselle, joka toimii aikapohjaisessa kilpailuympäristössä. Yhden taulukon avulla johto voisi nähdä, kasvavatko vai vähenevätkö sen tuotannon viiveajat ajan myötä. Yritys voi käyttää tällaista liiketoimintatietoa määrittääkseen, mitkä vaiheet ovat sen tuotantoprosessissa ongelmallisimpia. Ja he voivat ryhtyä toimiin niiden osien suhteen, jotka huolestuttavat heitä eniten.

Sivuhuomautus: nämä ajatukset on sovitettu ohjelmistomaailmaan ”lean”-terminologian alla; lisätietoa tuotannon mittaamisesta teknologiayrityksissä löydät Accelerate-kirjaa käsittelevistä kirjoituksistamme täällä ja täällä.

Miksi ne eivät ole muuttuneet?

Kimballin ja hänen kollegojensa ansiota on, että kolmenlaiset faktataulukot eivät ole olennaisesti muuttuneet sen jälkeen, kun ne ensimmäisen kerran muotoiltiin vuonna 1996.

Miksi näin on? Vastaus on mielestäni siinä, että tähtikaavio kuvaa jotakin olennaista liiketoiminnasta. Jos mallinnat tietosi vastaamaan liiketoimintaprosessejasi, tulet melko varmasti tallentamaan faktatietoja jollakin kolmesta tavasta: transaktioiden kautta, kootuilla ajanjaksoilla ja – jos liiketoimintasi on tarpeeksi tietoinen aikapohjaisesta kilpailusta – mittaamalla viiveaikoja arvontuottamisjärjestelmäsi kunkin vaiheen välillä.

Kimball itse sanoo jotakin vastaavaa. Vuonna 2015 julkaistussa blogikirjoituksessaan hän kirjoittaa:

Sen sijaan, että jumiudumme loogisia ja fyysisiä malleja koskeviin uskonnollisiin väitteisiin, meidän pitäisi yksinkertaisesti tunnustaa, että dimensiomalli on itse asiassa tietovaraston sovellusohjelmointirajapinta (API). Tämän API:n voima piilee johdonmukaisessa ja yhtenäisessä käyttöliittymässä, jonka kaikki tarkkailijat, sekä käyttäjät että BI-sovellukset, näkevät. Näemme, että ei ole väliä, minne bitit tallennetaan tai miten ne toimitetaan, kun API-pyyntö käynnistetään.

Tähtikaavio on aikansa elänyt. This much is obvious.

Samaisessa postauksessa Kimball jatkaa sitten väittämällä, että edes viimeaikaiset innovaatiot, kuten sarakkeellinen tietovarasto, eivät ole muuttaneet tätä tosiasiaa; suurin osa yrityksistä, joiden kanssa hän keskustelee, päätyy loppujen lopuksi edelleen dimensiomallirakenteeseen.

Mutta asiat ovat muuttuneet. Data Warehouse Toolkit -työkalupakissa on viehättäviä mainintoja siitä, että ”taulukkokohtaisten faktojen määrää on rajoitettava” ja että ”tietomallinnusstrategian suunnittelussa on otettava huomioon kaikki toimialan sidosryhmät, jotka ovat läsnä kokouksessa”. Nämä eivät vastaa sitä, mitä näemme käytännössä yrityksessämme ja asiakkaidemme dataosastoilla.

Suurin muutos on nopeus, jolla nykyiset teknologiat mahdollistavat siirtymisen ”naiivista faktataulukosta” ”Kimball-tyyliseen ulottuvuusmalliin” – mikä mahdollistaa sen, että voimme ohittaa etukäteismallinnuksen ja mallintaa sen sijaan niin vähän kuin on tarpeen. Tämän käytännön mahdollistavat monet teknologiset muutokset, joita olemme käsitelleet tässä blogissa aiemminkin (erityisesti kirjoituksessamme The Rise and Fall of the OLAP Cube), mutta käytännön vaikutukset faktataulukoiden käyttöön ovat seuraavat:

1. Transaktiotietotaulukot – olemme täysin tyytyväisiä, että meillä on paksuja faktataulukoita, joissa on kymmeniä tai jopa satoja faktoja riviä kohti! Tämä ei tarkoita sitä, että tilanne olisi ihanteellinen, vaan ainoastaan sitä, että se on erittäin hyväksyttävä kompromissi. Toisin kuin Kimballin aikana, datan lahjakkuus on nykyään kohtuuttoman kallista; tallennus- ja laskenta-aika on halpaa. Meille on siis täysin ok jättää tietyt faktataulukot sellaisina kuin ne ovat – itse asiassa meillä on useita sellaisia, joissa on yli 100 kenttää, jotka on tuotu suoraan lähdejärjestelmistämme! Filosofinen kantamme on: jos meillä on monimutkaisia raportointivaatimuksia, kannattaa käyttää aikaa ja mallintaa tiedot kunnolla. Mutta jos tarvitsemamme raportit ovat yksinkertaisia, hyödynnämme käytettävissämme olevaa laskentatehoa ja jätämme faktataulukot sellaisiksi kuin ne ovat.
2. Jaksoittaiset tilannekuvan faktataulukot – on yllättävää, kuinka paljon pystymme välttämään tämän tekemistä. Koska nykyaikaiset MPP-sarakkeelliset tietovarastot ovat niin tehokkaita, emme luo jaksottaisia tilannekuvatietotaulukoita raportteja varten, joita ei käytetä yhtä säännöllisesti. Kyselyn suoritusaika ja lisäkustannukset, joita raporttien luominen raaoista tapahtumatiedoista vaatii, ovat täysin hyväksyttäviä, varsinkin jos tiedämme, että raporttia tarvitaan vain kerran viikossa tai noin kerran (tai se asetetaan saataville ajoittaista tarkastelua varten). Muille tietokokonaisuuksille luomme Kimballin alkuperäisten suositusten mukaisia säännöllisiä tilannekuvataulukoita.
3. Tilannekuvataulukoiden kerääminen – Tämä on lähes ennallaan Kimballin aikaan verrattuna. Mutta – kuten Kimball itse sanoo – kertyvät tilannekuvataulukot ovat käytännössä harvinaisia. Emme siis pohdi tätä niin paljon kuin aikapainotteisemmat yritykset saattaisivat tehdä.

On tärkeää huomata tässä, että pidämme mallintamista tärkeänä. Erona on se, että data-analytiikkakäytäntömme antaa meille mahdollisuuden tarkastella mallinnuspäätöksiä uudelleen milloin tahansa tulevaisuudessa. Miten me teemme tämän? No, lataamme raa’at transaktiodatamme tietovarastoon ennen muunnosta. Tämä tunnetaan nimellä ”ELT” eikä nimellä ”ETL”. Koska teemme kaikki muunnokset tietovarastossa tietomallinnuskerroksen avulla, voimme tarkastella valintojamme uudelleen ja muokata tietojamme tarpeen vaatiessa.

Tämä antaa meille mahdollisuuden keskittyä ensisijaisesti liiketoiminnan arvon tuottamiseen. Se pitää tietomallinnuksen kiireisen työn vähäisenä.