Mitä on tietomallintaminen?

Tietomallintaminen lyhyesti

Tietomallintaminen (myös tietomallinnus, data modeling) on mallinnustyötä, jossa organisaation käsittelemät asiat kuvataan käsitteinä ja niiden suhteina ja toteutetaan lopulta tietojärjestelmien rakenteiksi.

Tietomalli määrittää alla olevia asioita.

• Mitkä asiat organisaatio tunnistaa, kuten asiakas, sopimus, lasku ja työsuhde
• Miten asiat liittyvät toisiinsa, esimerkiksi asiakkaalla voi olla useita sopimuksia ja laskulla yksi tai useampi rivi
• Millä tunnisteella kukin asia yksilöidään ja mitä tietoja siitä tallennetaan
• Miten muutokset ja historia käsitellään
• Millä tarkkuudella tapahtumat tallennetaan analytiikkaa varten

Tietomallit ovat osa kokonaisarkkitehtuurin informaatioarkkitehtuuria. Sama tietomallimalli voidaan periaatteessa toteuttaa millä tahansa data-alustalla, joten mallintamisen voi aloittaa ennen teknologiavalintoja.

Tietomallintaminen alkaa liiketoiminnasta

Liiketoimintamalli ja liiketoimintaprosessit ovat monesti pysyvämpiä kuin organisaatiorakenne tai yksittäiset järjestelmät. ERP vaihtuu ja organisaatio järjestäytyy uudelleen, mutta asiakas, tilaus ja lasku säilyvät. Siksi tietomalli rakennetaan prosessien ja niiden käsitteiden varaan. Jos malli kopioi lähdejärjestelmän taulut, se perii järjestelmän oletukset, ja se pitää tehdä uudelleen, kun järjestelmä vaihtuu.

Mallintamisen vaikeimmat kysymykset ovat liiketoiminnan kysymyksiä:

• Onko asiakas henkilö, yritys vai yrityksen toimipiste? Entä konsernin tytäryhtiö?
• Syntyykö myynti tilauksesta, toimituksesta vai laskusta, ja minkä päivän myynnistä hyvityslasku vähennetään?
• Lasketaanko henkilöstömäärään tuntityöntekijät ja pitkällä vapaalla olevat?
• Kun asiakas siirtyy segmentistä toiseen, siirtyykö sen aiempi myynti mukana?

Jokainen kysymys tarvitsee päätöksen, ja jokainen päätös omistajan liiketoiminnasta. Datatiimi ei voi päättää niitä datan perusteella, mutta se voi näyttää, miltä luvut näyttävät kunkin vaihtoehdon kanssa. Jos päätöstä ei tehdä, jokainen raportti, analyytikko ja data-agentti tekee oman tulkintansa, ja samasta asiasta liikkuu useita lukuja.

Tietomalli määrittää rakenteen. Mittarien laskentasäännöt ja käyttöoikeudet raporteille ja data-agenteille määritellään sen päällä semanttisessa kerroksessa.

Tietomallin kolme tasoa

Tietomallintaminen etenee liiketoiminnan käsitteistä tekniseen toteutukseen kolmella tasolla.

Käsitteellistä mallia kuvataan tyypillisesti UML-luokkakaaviolla tai ER-kaaviolla.

Looginen malli on yhä teknologiariippumaton, joten sen voi toteuttaa lakehouse-alustalle, relaatiotietokantaan tai dokumenttikantaan. Fyysinen malli on se mikä lopulta suoritetaan data-alustalla esimerkiksi taulut luovina .sql-skripteinä.

Mallinnusmenetelmät: valinta käyttötarkoituksen mukaan

Analytiikan fyysinen malli rakennetaan yleensä jollakin vakiintuneella menetelmällä. Menetelmät eroavat siinä, mihin ne on optimoitu. Esimerkkinä kaikissa on sama aihepiiri: myyntilasku, tuote ja asiakas.

Dimensiomalli (Kimball)

Ralph Kimball toi dimensiomallinnuksen tietovarastointiin vuonna 1996 kirjallaan The Data Warehouse Toolkit. Malli jakaa datan faktoihin eli mitattaviin tapahtumiin ja dimensioihin eli tapahtumien kontekstiin kuten kuka, mitä, missä ja milloin. Myyntiesimerkissä laskurivit ovat faktataulu, jossa on määrä ja nettosumma, ja asiakas, tuote ja päivä ovat dimensioita.

Tähtimalli on helppo ymmärtää, ja raportointityökalut laskevat siitä summat ja osasummat perustoiminnoillaan. Kääntöpuolena malli tallentaa samaa tietoa useaan kertaan, sen jyvä ja dimensiot pitää päättää etukäteen, eikä sitä ole tarkoitettu operatiivisten järjestelmien pohjaksi.

Normalisoitu tietomalli (3NF)

E. F. Coddin 1970-luvun alussa esittämä normalisointi tallentaa jokaisen tiedon vain kerran. Kolmas normaalimuoto riittää yleensä poistamaan lisäys-, päivitys- ja poisto-operaatioiden anomaliat, ja sitä käytetään operatiivisissa järjestelmissä, joihin dataa kirjoitetaan jatkuvasti. Myyntiesimerkissä asiakas, lasku, laskurivi, tuote ja tuoteryhmä ovat kukin omia taulujaan.

Bill Inmon sovelsi normalisoitua mallia keskitettyyn tietovarastoon. Data-alustalla se sopii kerrokseen, jossa usean lähdejärjestelmän data sovitetaan yhteen. Raportointiin se vaatii paljon liitoksia.

Data Vault (Linstedt)

Dan Linstedtin Data Vault erottaa liiketoiminta-avaimet (hub), avainten väliset suhteet (link) ja kuvailevat tiedot muutoshistorioineen (satellite) omiin tauluihinsa. Myyntiesimerkissä asiakkaalla, laskulla ja tuotteella on kullakin oma hub. Laskun ja asiakkaan suhde sekä laskurivit laskun ja tuotteen välillä ovat linkkejä, ja nimet, hinnat ja segmentit ovat satelliiteissa.

Data Vault tallentaa lähes kaikki lähdejärjestelmien muutokset, joten se sopii ympäristöihin, joissa datan alkuperä ja historia pitää pystyä jäljittämään. Tauluja on selvästi enemmän kuin muissa menetelmissä ja kyselyt ovat monimutkaisempia, joten raportoinnin pohjaksi sen päälle rakennetaan yleensä dimensiomalli.

Activity Schema (Elsamadisi)

Ahmed Elsamadisin Narratorissa kehittämä Activity Schema mallintaa, mitä asiakas tekee ajan kuluessa. Kaikki tapahtumat tallennetaan yhteen kapeaan aikasarjatauluun, aktiviteettivirtaan, jonka jokaisella rivillä on asiakas, aktiviteetin nimi, aikaleima ja aktiviteetin omat ominaisuudet. Myyntiesimerkissä tilauksen tekeminen ja laskun maksaminen ovat aktiviteetteja. Kysymykset muotoillaan ajallisina suhteina, kuten "viimeisin markkinointikanava ennen ensimmäistä tilausta".

Menetelmä sopii tuote- ja verkkoanalytiikkaan. Hierarkioita ja kauden lopun saldoja vaativaan talousraportointiin tarvitaan edelleen dimensiomalli.

Vertailu

Lakehouse-arkkitehtuurin kerrokset eivät sanele menetelmää. Raakadatan kerros (bronze) tallentaa lähdedatan sellaisenaan, integraatiokerroksessa (silver) lähteet puhdistetaan ja sovitetaan yhteen, ja käyttökerros (gold) palvelee raportteja, analytiikkaa ja data-agentteja. Lakehouse-analytiikassa käyttökerroksen suoraviivaisin valinta on useimmiten dimensiomalli.

Dimensiot ja hierarkiat

Dimensio ja sen avaimet

Dimensio kokoaa asian, jonka mukaan dataa suodatetaan ja ryhmitellään, asiakas, tuote, organisaatio, tili tai päivä. Dimension rakentaminen alkaa liiketoiminta-avaimesta eli luonnollisesta avaimesta, jolla asia tunnistetaan. Avain voi olla usean tiedon yhdistelmä, esimerkiksi yhtiö ja asiakasnumero, kun konsernin yhtiöillä on omat asiakasrekisterinsä.

Liiketoiminta-avaimen lisäksi dimensioon luodaan surrogaattiavain, joka ei riipu lähdejärjestelmästä. Se voi olla juokseva numero tai liiketoiminta-avaimesta laskettu tiivistearvo. Tietokantatuotteissa juokseva numero on tavallinen, mutta lakehouse-alustoilla tiivistearvo on usein helpompi, koska sen voi laskea missä tahansa latauksen vaiheessa ilman keskitettyä numerointia. Tekniset kentät, kuten muutosvertailun tiivisteet ja latausaikaleimat, kannattaa piilottaa loppukäyttäjiltä.

Hierarkiat ja hierarkiaversiot

Dimension jäsenten välillä on usein hierarkia. Tuote kuuluu tuoteryhmään ja tuoteryhmä tuotelinjaan, kustannuspaikka yksikköön ja yksikkö liiketoimintaan. Hierarkian avulla raportin käyttäjä porautuu osasummasta alemmalle tasolle.

Hierarkiaversio tarkoittaa, että samalle dimensiolle on useampi tapa ryhmitellä jäsenet. Kirjanpidon tilit ryhmitellään ulkoiseen tuloslaskelmaan ja taseeseen eri tavalla kuin sisäisen laskennan raportteihin, ja toimialalla voi olla sekä virallinen että organisaation oma luokittelu.

Kolme tapaa toteuttaa hierarkia

1. Tasot dimension sarakkeiksi. Tähtimallin perinteinen tapa tuo hierarkiaversioiden tasot dimensiotauluun omiksi sarakkeikseen. Jos toimialadimensiolla on kaksi hierarkiaversiota, joissa on viisi ja kolme tasoa, dimensioon tulee alimman tason lisäksi (5 − 1) + (3 − 1) = 6 saraketta. Tapa olettaa, että alin taso on molemmille versioille yhteinen, eikä oletus aina pidä.
2. Erillinen hierarkiataulu. Dimensiotaulu sisältää jäsenet ilman hierarkioita, ja hierarkiat ovat erillisessä parent–child-taulussa, jossa on ylä- ja alajäsenen lisäksi tieto hierarkiaversiosta. Tapa sopii hierarkioille, joiden haarat ovat eri syvyisiä tai joihin lisätään usein uusia versioita.
3. Lumihiutalemalli. Jokaisella hierarkian tasolla on oma taulunsa, ja taulut liittyvät toisiinsa varsinaiseen dimensiotauluun asti.

Valinnassa punnitaan ylläpitoa ja käyttäjien tarpeita. Controller tarvitsee useita tilihierarkioita, johtoryhmän kuukausiraportti yhden. Kimball Groupin tekniikkaluettelo kuvaa ratkaisut sekä kiinteän että vaihtelevan syvyyden hierarkioille.

Esimerkkejä analytiikasta

Mallinnuspäätökset näkyvät suoraan raporttien luvuissa. Seuraavat neljä esimerkkiä ovat eri analytiikan alueilta.

Talousanalytiikka: toteuma ja budjetti eri tarkkuudella

Talousanalytiikka kokoaa pääkirjan viennit, osajärjestelmien tiedot sekä budjetoinnin ja ennustamisen luvut samaan malliin. Tyypillisiä dimensioita ovat aika, tili, organisaatio ja kustannuspaikka. Kaksi mallinnuspäätöstä erottuu:

• Jyvä. Toteuma tallennetaan vientitasolla, mutta budjetti tehdään karkeammin, esimerkiksi kuukauden, tilin ja kustannuspaikan tasolla. Ne mallinnetaan kahtena faktana omalla tarkkuudellaan, ja vertailu tehdään niiden yhteisten dimensioiden tasolla.
• Tilihierarkiat. Sama tili kuuluu ulkoisessa tuloslaskelmassa ja sisäisen laskennan raportissa eri riville. Hierarkiaversiot tuottavat molemmat näkymät samasta datasta.

Liiketoiminta päättää, millä tasolla budjettia seurataan ja mikä hierarkia on johtoryhmän virallinen.

Myyntianalytiikka: laskurivi ja asiakkaan historia

Myynnin analytiikassa faktan jyvä on usein laskurivi eli yksi rivi jokaisesta laskutetusta tuotteesta. Dimensioita ovat asiakas, tuote, päivä ja myyvä yksikkö. Hyvityslaskut ovat usein samassa lähdetaulussa kuin laskut, ja mallin pitää kertoa, vähennetäänkö hyvitys hyvityksen vai alkuperäisen laskun päivälle.

Historia on toinen päätös. Kun asiakas siirtyy kesken vuoden pk-asiakkaista suurasiakkaisiin, viime vuoden myynti voidaan raportoida laskuhetken segmentillä tai nykyisellä segmentillä. Laskuhetken segmentti vaatii asiakasdimensioon muutoshistorian (SCD-tyyppi 2), nykyiselle segmentille riittää päivittyvä arvo (tyyppi 1). Kumpikin vastaa eri kysymykseen, ja malli voi tukea molempia.

Henkilöstöanalytiikka: tilanne kuun viimeisenä päivänä

Henkilöstöanalytiikassa henkilöstömäärä ja henkilötyövuodet (FTE) raportoidaan tietyn päivän tilanteena. Ne mallinnetaan poikkileikkausfaktana, jossa on yksi rivi jokaisesta voimassa olevasta työsuhteesta jokaisen kuukauden viimeisenä päivänä. Työsuhteen tiedot, kuten osa-aikaisuus ja yksikkö, muuttuvat, joten niistä tarvitaan historia. Organisaatiorakenne muuttuu uudelleenjärjestelyissä, ja jos viime vuoden lukuja halutaan verrata uuden rakenteen mukaan, organisaatiodimensio tarvitsee hierarkiaversiot.

Liiketoiminta päättää, lasketaanko henkilöstöön tuntityöntekijät ja pitkällä vapaalla olevat. Lisäksi sovitaan pienin ryhmäkoko, jonka luvut näytetään, ettei yksittäinen henkilö tunnistu.

Tuoteanalytiikka: tapahtumien järjestys

Tuoteanalytiikan kysymykset koskevat usein järjestystä: mistä kanavasta käyttäjä tuli ennen ensimmäistä tilausta, ja käyttikö hän keskeistä ominaisuutta ensimmäisen viikon aikana. Activity Schemassa jokainen tapahtuma on aktiviteettivirran rivi, ja kysymys muotoillaan kahden aktiviteetin suhteena, esimerkiksi "viimeisin istunto ennen tilausta". Anonyymin kävijän tapahtumilla on aluksi vain selaintunniste. Kun kävijä kirjautuu, rivi, jossa on sekä selaintunniste että asiakastunniste, liittää aiemmat käynnit asiakkaaseen.

Yhteiset dimensiot sitovat alueet yhteen

Kimballin väylämatriisi (Enterprise Data Warehouse Bus Matrix) kuvaa, mitkä dimensiot kukin liiketoimintaprosessi jakaa. Kun organisaatiodimensio on sama talous-, myynti- ja henkilöstöanalytiikassa, myyntiä ja henkilöstökuluja voi verrata saman organisaatiohierarkian mukaan.

Väylämatriisi tehdään käsitteellisen mallintamisen aikana ennen fyysistä toteutusta. Dimensioiden, faktojen ja mittarien suunnittelua käsitellään tarkemmin kirjoituksessa Tietomallit osana informaatioarkkitehtuuria.

Tietomallintaminen data-alustan kehittämisprojektissa

Data-alustaprojektissa tietomallintaminen kulkee mukana kartoituksesta jatkuvaan kehitykseen. Malli syntyy domain kerrallaan ja tarkentuu, kun oikea data paljastaa, miten lähdejärjestelmiä on todellisuudessa käytetty.

Projektissa kannattaa huomioida kolme asiaa:

• Aikaa varataan domainia kohden. Suurissa organisaatioissa aikaa kuluu myös domainien väliseen yhteensovittamiseen, esimerkiksi siihen, mitä asiakas tarkoittaa myynnissä ja asiakaspalvelussa.
• Ensimmäinen läpivienti testaa mallin. Kun yhden lähdejärjestelmän data viedään kaikkien kerrosten läpi raporttiin asti, jyvä, avaimet ja historiointi kohtaavat oikean datan.
• Malli sidotaan sopimuksiin ja tuotteisiin. Datasopimus tekee mallista tuottajan ja käyttäjän välisen sopimuksen, ja datatuote paketoi mallin, käsittelylogiikan ja metatiedot omistetuksi kokonaisuudeksi.

Projektin vaiheet ja riskit on kuvattu tarkemmin kirjoituksessa Millainen on data-alustan kehittämisprojekti?

Agenttinen tietomallintaminen

AI-avusteisessa mallintamisessa kielimalli on mallintajan työpari. Se ehdottaa sarakkeelle tietotyyppiä, kirjoittaa pyynnöstä taulun luontilauseen tai selittää olemassa olevan kyselyn. Mallintaja pyytää jokaisen vaiheen erikseen ja kokoaa tuloksen itse.

Agenttisessa mallintamisessa agentti saa kokonaisen tehtävän, esimerkiksi "mallinna myyntilaskut analytiikkaan", ja etenee siinä itse. Se lukee tiedostoja, ajaa kyselyjä kehitysympäristössä, kirjoittaa koodia ja ajaa testejä. Ihminen hyväksyy suunnitelman, tekee liiketoimintapäätökset ja katselmoi lopputuloksen.

Mitä agentti tekee mallinnustehtävässä

1. Lähtöaineisto. Agentti lukee prosessikuvauksen, käsitesanaston, aiemmat mallinnuspäätökset ja nykyisen mallin repositoriosta.
2. Lähdedatan profilointi. Agentti ajaa kyselyt kehitysympäristössä ja selvittää, yksilöivätkö laskunumero ja rivinumero rivin, löytyykö jokaiselle laskulle asiakas, missä sarakkeissa on tyhjiä arvoja ja miten asiakkaiden segmentit ovat muuttuneet.
3. Luonnos. Agentti laatii käsitteellisen mallin, väylämatriisin rivin ja loogisen mallin tekstimuotoisena kaaviona sekä ehdotuksen jyväksi ja historioinniksi.
4. Päätettävät asiat. Agentti ei ratkaise liiketoiminnan kysymyksiä vaan kirjaa ne. Jos hyvityslaskut ovat samassa taulussa kuin laskut, agentti kysyy, kummalle päivälle hyvitys kohdistetaan, ja laskee viime vuoden myynnin kummallakin tavalla. Työpaja näkee päätöksen vaikutuksen euroina ennen kuin päätös tehdään.
5. Toteutus. Kun malli on hyväksytty, agentti generoi taulujen luontiskriptit, latauslogiikan historiointeineen, semanttisen mallin mittarimäärittelyt ja dokumentaation.
6. Testit ja katselmointi. Agentti johtaa laatutestit mallista: pääavaimista yksilöllisyys- ja tyhjäarvotarkistukset, viiteavaimista viite-eheystarkistukset ja rajoitteista arvoaluetarkistukset. Se ajaa testit, korjaa virheet ja avaa pull requestin, jonka ihminen katselmoi.

Kun lähdejärjestelmä myöhemmin muuttuu, agentti tekee saman kierroksen pienempänä. Se selvittää, mihin tauluihin, testeihin ja mittareihin muutos vaikuttaa, ja päivittää mallin ja toteutuksen samassa pull requestissa.

Malli tekstinä, jota agentti voi lukea

Agentti tarvitsee mallin muodossa, jota se voi lukea ja muokata. Toimiva tapa on kuvata looginen malli tekstipohjaisena kaaviona, esimerkiksi Mermaid-kielellä, samassa Git-repositoriossa kuin koodi. GitHub piirtää kaavion suoraan Markdown-tiedostosta, ja mallin muutokset katselmoidaan pull requesteina kuten koodi.

Alla oleva kaavio on myyntiesimerkin looginen malli: asiakas saa laskuja, lasku sisältää yhden tai useamman rivin ja jokainen laskurivi kohdistuu yhteen tuotteeseen.

```mermaid
erDiagram
    accTitle: Myyntilaskun looginen malli
    accDescr: Asiakas saa laskuja, lasku sisältää yhden tai useamman rivin ja jokainen laskurivi kohdistuu yhteen tuotteeseen.
    ASIAKAS ||--o{ LASKU : "saa"
    LASKU ||--|{ LASKURIVI : "sisältää"
    TUOTE ||--o{ LASKURIVI : "laskutetaan"
    ASIAKAS {
        string asiakasnumero PK
        string nimi
        string segmentti
    }
    LASKU {
        string laskunumero PK
        string asiakasnumero FK
        date laskupaiva
        string laskutyyppi
    }
    LASKURIVI {
        string laskunumero PK, FK
        int rivinumero PK
        string tuotekoodi FK
        decimal maara
        decimal nettosumma
    }
    TUOTE {
        string tuotekoodi PK
        string nimi
        string tuoteryhma
    }
```

Mitä agentti tarvitsee

• Kirjoitetut konventiot ja päätökset. Nimeämiskäytännöt ja historioinnin säännöt ovat repositorion ohjetiedostossa. Käsitteiden määritelmät ja aiemmat päätökset ovat tietämysartikkeleina, jotka agentti lukee jokaisen tehtävän alussa.
• Rajatut oikeudet. Agentti työskentelee kehitysympäristössä tehtävään rajatuilla oikeuksilla. Henkilötietoja sisältävä data profiloidaan anonymisoituna.
• Testit. Testit ovat agentin palautesilmukka. Ilman niitä agentti ei pysty toteamaan, onko tehtävä valmis.
• Päätöspisteet. Ihminen hyväksyy suunnitelman, tekee liiketoimintapäätökset ja katselmoi pull requestin ennen kuin muutos yhdistetään.

Mikä jää ihmiselle

Agentti lyhentää matkaa päätöksestä testattuun toteutukseen. Ihmiset kuitenkin päättävät mitä käsite tarkoittaa, missä domainien rajat kulkevat, mikä on faktan jyvä ja miten historia käsitellään. Niistä sovitaan useiden sidosryhmien kesken, eikä tätä työtä kannata leikata projektin työmääräarviosta agenttien vuoksi.

Lue myös: Tekoälyavusteinen data engineering, mitä se tarkoittaa käytännössä?

Mistä liikkeelle?

1. Valitse yksi prosessi. Aloita prosessista, jonka luvuista kysytään eniten, esimerkiksi myynnistä tai henkilöstömäärästä.
2. Kirjaa käsitteet ja avoimet kysymykset. Nimeä jokaiselle kysymykselle päättäjä liiketoiminnasta.
3. Tee malli tekstinä versionhallintaan. Vie käsitteellinen ja looginen malli sekä väylämatriisi samaan repositorioon kuin koodi.
4. Vie prosessi raporttiin asti. Yksi lähdejärjestelmä kaikkien kerrosten läpi testaa mallin oikealla datalla.
5. Anna toistuva työ agentille. Kun malli, konventiot ja testit on kirjoitettu, agentti toteuttaa seuraavat prosessit samalla tavalla.

Suunnitteletko data-alustaa tai tietomallintamista siihen liittyen?

Kerro meille, mitkä luvut herättävät teillä nyt eniten kysymyksiä. Käydään 30 minuutissa läpi, mistä prosessista mallintaminen kannattaa aloittaa ja minkä osan työstä agentti voi tehdä.

Varaa maksuton kartoituskeskustelu →

Lue lisää palvelustamme: Data-alustan kehittäminen