Hei,
Edellisessä kirjoituksessa käsittelin sitä, miksi semanttinen kerros kannattaa rakentaa datamallinnuksen kautta. Perusajatus oli yksinkertainen: jos data tarvitsee kontekstia, sitä kontekstia ei voi jättää vain dokumentaation, BI-työkalun tai data-alustan metadatan varaan.
Tähän liittyy kuitenkin vielä yksi tärkeä kysymys.
Missä merkitys oikeastaan asuu?
Tämä on mielestäni koko keskustelun ytimessä.
Kun puhumme semanttisesta kerroksesta, käsitemalleista tai AI-valmiudesta, kyse ei ole lopulta vain siitä, että saamme määritelmät kirjattua jonnekin. Yhtä tärkeää on se, rakennetaanko merkitys itse datan rakenteeseen vai jätetäänkö se sääntöjen, tulkintojen ja erillisten ohjeiden varaan.
Tässä kohtaa vastaan tulee kaksi erilaista ajattelutapaa.
Ensimmäinen on sääntöpohjainen lähestyminen.
Toinen on rakenteeseen perustuva lähestyminen.
Sääntöpohjainen tapa: merkitys päätellään myöhemmin
Tämä on monelle tuttu tapa toimia, vaikka sitä ei aina ajatella tietoisesti.
Data tulee lähdejärjestelmistä sellaisena kuin se tulee. Sen jälkeen merkitystä yritetään tulkita erilaisten sääntöjen avulla:
- SQL-kyselyissä
- ETL- tai ELT-putkissa
- raportointikerroksessa
- BI-työkalun laskennoissa
- dokumentaatiossa
- tai sovelluslogiikassa
Tämä toimii usein ihan hyvin siihen asti, kunnes maailma muuttuu vähän monimutkaisemmaksi.
Esimerkiksi voidaan sopia, että:
- jos tilan arvo on “X”, tilaus tulkitaan toimitetuksi
- jos asiakkaalla on kaksi eri tunnistetta, valitaan aina uusin
- jos tuotteen nimi on muuttunut, käytetään raportoinnissa uusinta nimeä
- jos tapahtumatyyppi on palautus, se vähennetään myynnistä
Kaikki nämä voivat olla ihan järkeviä sääntöjä.
Ongelma ei olekaan siinä, etteivätkö ne toimisi. Ongelma on siinä, että merkitys ei ole itse datassa, vaan niissä järjestelmissä ja kyselyissä, jotka dataa käyttävät.
Toisin sanoen, sama asia pitää selittää uudestaan ja uudestaan.
Ja kun poikkeuksia alkaa tulla lisää, sääntöjä syntyy lisää:
- “yleensä näin, paitsi jos…”
- “raportilla tämä lasketaan näin, mutta tuossa dashboardissa vähän eri tavalla…”
- “teknisesti tämä on sama asiakas, mutta myynnin raportissa ei kuitenkaan ole…”
Kuulostaa varmasti tutulta.
Rakenteellinen tapa: merkitys rakennetaan dataan
Toinen tapa on pyrkiä siihen, että merkitys näkyy jo datan rakenteessa.
Tällöin emme pelkästään kirjoita auki, mitä jokin käsite tarkoittaa, vaan mallinnamme sen niin, että rakenne itsessään ohjaa oikeaan tulkintaan.
Esimerkiksi:
- asiakas on oma käsitteensä
- tuote on oma käsitteensä
- tilaus on oma käsitteensä
- toimitus on oma käsitteensä
- ja niiden väliset suhteet on määritelty eksplisiittisesti
Tämä kuulostaa ehkä yksinkertaiselta tai jopa vanhanaikaiselta, mutta juuri tässä on datamallinnuksen ydin.
Ajatuksena ei ole vain dokumentoida maailmaa, vaan jäsentää sitä.
Kun rakenne on kunnossa, kuluttajan ei tarvitse joka kerta arvailla, mitä data tarkoittaa. Merkitys ei ole irrallinen selite datan vieressä, vaan osa itse mallia.
Yksinkertainen esimerkki
Otetaan hieman eri esimerkki kuin ensimmäisessä kirjoituksessa.
Ajatellaan huolto- ja palveluliiketoimintaa.
Yrityksellä on:
- asiakkaita
- laitteita
- huoltosopimuksia
- huoltokäyntejä
- varaosia
Jos tämä maailma on mallinnettu huonosti, päädytään helposti tilanteeseen, jossa pitää tehdä paljon sääntöjä.
Esimerkiksi:
- päätellään erikseen, kuuluuko tietty huoltotapahtuma sopimuksen piiriin
- päätellään, liittyykö tietty varaosa tiettyyn laitteeseen
- päätellään, onko asiakas aktiivinen vai entinen
- päätellään, mikä käynti on korjaava huolto ja mikä ennakoiva huolto
Kaikki tämä voidaan kyllä tehdä säännöillä.
Mutta jos nämä käsitteet ja suhteet on mallinnettu kunnolla, kysymykset muuttuvat heti helpommiksi.
Silloin voidaan kysyä esimerkiksi:
Mitkä asiakkaat ovat riskissä jäädä ilman huoltoa, jos tietyn laitetyypin varaosat loppuvat?
Tämä ei ole enää yksi mittari.
Tämä vaatii ymmärrystä siitä, miten seuraavat asiat liittyvät toisiinsa:
- asiakas
- laite
- huoltosopimus
- huoltokäynti
- varaosa
Eli taas sama ydinajatus: merkitys syntyy suhteista, ei vain yksittäisistä kentistä tai lasketuista mittareista.
Sama asia kuvana
Tämän voi hahmottaa myös näin:
Kun tällainen rakenne on selkeä, järjestelmät ja ihmiset pystyvät paljon helpommin vastaamaan kysymyksiin, jotka ylittävät yhden raportin tai yhden taulun rajat.
Miksi tämä on tärkeää juuri nyt?
Tämä keskustelu ei ole uusi. Dataa on mallinnettu vuosikymmeniä.
Uutta on ehkä se, että nyt moni huomaa saman asian tekoälyn kautta.
Kun ihminen katsoo sekavaa dataa, hän pystyy usein paikkaamaan puutteita kokemuksella, taustatiedolla ja tulkinnalla. Hän voi arvata, mitä jollain kentällä tarkoitetaan tai mitä kaksi lähes samanlaista käsitettä oikeastaan tarkoittaa.
Kone ei tee tätä samalla tavalla.
Jos merkitys on hajautettu dokumentteihin, raportteihin, dashboardeihin, pipelineihin ja hiljaiseen tietoon, tekoäly joutuu päättelemään enemmän kuin olisi tarpeen.
Se voi onnistua joskus hyvin, mutta kustannus kasvaa:
- enemmän tulkintaa
- enemmän epävarmuutta
- enemmän virhemahdollisuuksia
- enemmän laskentaa
Kun taas rakenne kantaa merkitystä valmiiksi, koneen työ helpottuu huomattavasti.
Tämä ei tarkoita, että kaikki pitäisi normalisoida äärimmilleen tai että jokainen ongelma ratkeaa yhdellä täydellisellä tietomallilla.
Tarkoitan vain sitä, että semanttinen kerros ei voi olla pelkkä sanasto tai lista määritelmiä. Sen pitää näkyä myös tavassa, jolla data on järjestetty.
Missä kohtaa säännöt ovat silti tarpeen?
On myös hyvä todeta, että säännöt eivät ole “vihollinen”.
Niitä tarvitaan aina.
Aina tulee vastaan tilanteita, joissa:
- lähdedata on epäsiistiä
- samasta asiasta on useita versioita
- tunnisteet puuttuvat
- liiketoimintaprosessi ei ole täysin vakioitu
- vanhat järjestelmät eivät tue hyvää rakennetta
Eli käytännössä emme koskaan elä täysin “puhtaassa mallissa”.
Mutta tässäkin tärkeä ero on se, mihin pyritään.
Pyritäänkö siihen, että merkitys jää pysyvästi sääntöjen varaan?
Vai pyritäänkö siihen, että sääntöjä käytetään välivaiheena, jolla data jalostetaan parempaan rakenteeseen?
Minusta jälkimmäinen on paljon kestävämpi ajattelutapa.
Mitä tämä tarkoittaa käytännössä datatiimille?
Käytännössä tämä tarkoittaa ainakin kolmea asiaa.
1. Kaikkea ei kannata ratkaista raportointikerroksessa
Jos samaa tulkintaa joudutaan toistamaan jokaisessa dashboardissa tai mittarissa, se on usein merkki siitä, että mallissa on parantamisen varaa.
2. Käsitteet pitää erottaa toisistaan ajoissa
Jos esimerkiksi “asiakas”, “sopimus”, “toimitus” ja “laskutus” sekoittuvat samaan rakenteeseen, niitä on myöhemmin vaikea käyttää johdonmukaisesti.
3. Suhteet ovat vähintään yhtä tärkeitä kuin attribuutit
Usein puhutaan paljon kentistä, kuvauksista ja määritelmistä. Mutta käytännössä kaikkein tärkeintä on usein se, miten käsitteet liittyvät toisiinsa.
Juuri suhteiden kautta syntyy mahdollisuus vastata monimutkaisempiin kysymyksiin.
Entä normalisointi?
Tämä on ehkä se kohta, jossa osa lukijoista alkaa miettiä, puhutaanko tässä nyt vain vanhasta kunnon normalisoinnista uudella nimellä.
Osittain kyllä.
Mutta en itse ajattelisi tätä vain teknisenä tietokantakeskusteluna. Tärkeämpi pointti on se, että datamallinnuksen tehtävä ei ole ensisijaisesti säästää levytilaa tai tehdä tietokannasta eleganttia. Sen tehtävä on tehdä datan merkityksestä selkeämpää.
Kun rakenne rajaa, mitä yhdistelmiä voi olla olemassa ja miten asiat liittyvät toisiinsa, data muuttuu helpommin tulkittavaksi.
Ja juuri tätä tarvitsemme myös semanttisen kerroksen rakentamisessa.
Yhteenveto
Jos edellisen kirjoituksen ydin oli tämä:
semanttinen kerros kannattaa rakentaa liiketoiminnan käsitteiden, suhteiden ja datamallinnuksen varaan
niin tämän kirjoituksen ydin on:
merkitystä ei kannata jättää vain sääntöjen varaan, se kannattaa rakentaa mahdollisimman paljon myös datan rakenteeseen
Säännöillä pääsee alkuun. Rakenteella pääsee pidemmälle.
Ja ehkä juuri tästä syystä tiedon mallinnus kiinnostaa taas.
Ei siksi, että olisimme palaamassa johonkin vanhaan maailmaan, vaan siksi, että tekoälyn aikakaudella merkityksen täytyy olla aiempaa eksplisiittisempää, jaettavampaa ja koneellisesti hyödynnettävämpää.
Meillä on todella mielenkiintoinen Tiedon mallinnus -koulutus tulossa keväällä, jossa syvennytään juuri näihin teemoihin! Katso lisätiedot täältä.
Ystävällisin terveisin,
Johannes Hovi
