Hei,
Kuvailen tässä blogissa eri mallinnuksen eri tasoja. Näitä ovat käsitemallinnus, looginen mallinnus ja fyysinen mallinnus ja kuvaus suunnittelusta aina tietokantatasolle asti.
Mukana on käytännön esimerkkejä Elliellä tehtynä, sisältäen myös tähtimallin.
Tasojen eroista
Eri mallinnusmenetelmiä vertailussa on hyvä ensin tutkia tasoajattelua ja tasoihin liittyvää yleistämisen eli abstraktion käsitettä. Jos jokin kuvaus on yleistetty (abstraktio), siinä ikään kuin jätetty jotain pois.
Kuten esimerkiksi Suomen kartasta on jätetty paljon yksityiskohtia pois, jotta koko maa saadaan näkymään kerralla, jotta saisimme kokonaiskuvan. Helsingin Punavuoren kartassa näkyy paljon enemmän yksityiskohtia – kuten kadun nimiä.
Taustalla on se tosiasia, että me ihmiset emme voi yhdellä kertaa ymmärtää laajoja kokonaisuuksien kuvauksia ja tarkkoja yksityiskohtien kuvauksia.
Datan mallintamisen alueella on tärkeää, että meillä on erilaisia abstraktiotasoja. Juuri näitä ovat käsitemalli, looginen malli ja fyysinen malli.
Kohdealue
Kohdealue (scope) tarkoittaa sitä aluetta, jota jokin malli kuvaa. Yrityksen käsitemallinnuksessa kohdealue voi olla koko yritys (vrt. Suomen kartta). Alemmalla tasolla kohdealue on tyypillisesti pienempi, ns. domain, kuten henkilöstöalue tai laskutus (vrt. Punavuori).
Käsitemalli
Käsitemallin (Conceptual model) tehtävänä on kuvata datamaailmaa liiketoiminnan näkökulmasta. Siis ei-teknisesti ja käyttäen liiketoiminnan kieltä ja terminologiaa. Niinpä käsitemallinnuksessa on tärkeää olla mukana liiketoiminnan edustajia, samoin kuin IT-henkilöitä.
Käsitemalleja tehdään eri tasoilla. Koko yrityksen käsitemalli on ylätasolla, ja kuvaa yrityksen pääkäsitteitä. Ylätason mallissa saattaa olla esim. 10–15 käsitettä, esimerkkeinä asiakas, organisaatioyksikkö, tuote, lasku, tilaus, työtekijä.
Alemmalla tasolla käsitemallin kohdealueena on tavallisesti jokin domain, kuten talous, tuotanto tai laskutus. Näistä käsitemalleista syntyy yrityksen käsitemallien verkosto, jotka liittyvät toisiinsa yhteisten käsitteiden avulla. Tyypillisiä yhteisiä ovat asiakas, työntekijä tai lasku.
Käsitemalli muodostuu käsitteistä (entity), niiden välisistä riippuvuuksista (relationhip) ja tarvittaessa attribuuteista. Tässä esitetyt esimerkit on tehty yleisesti käytetyllä ER-menetelmällä (Entity Relatioship modeling).
Käsitemalliesimerkki
Alla on pieni, pelkistetty käsitemalli myyntiorganisaation laskutuksesta. Tämä on siis yhden domainin malli, lisäksi tarvitaan tarjouspuolen, tilauksen, toimituksen, reklamaatioiden yms. mallinnukset.
Asiakkaille (yrityksiä) on muodostettu laskuja heidän ostamistaan tuotteista. On tärkeää tietää kuka myyjä on kunkin laskun takana. Myyjät voivat kuulua myyntitiimiin ja kuuluvat aina hallinnollisesti johonkin organisaatioyksikköön.
Tuotteet kuuluvat tuoteryhmiin. Asiakkaiden kanssa on voitu tehdä hintasopimuksia, joista on etukäteen sovittu tuoteryhmätasoisia alennusprosentteja. Asiakkaille on merkitty kunta.
Tiettyä tuotetta kohti voi olla monta laskua ja yksi lasku voi sisältää monta tuotetta. Tämä ns. moni-moneen yhteys (harakanvarvas molemmissa päissä) puretaan loogisessa mallissa. Ne voidaan purkaa myös alemman tason käsitemallissa.
Looginen malli
Looginen malli (Logical model) käsitemallia tarkempi kuvaus datamaailmasta. Se on yleensä domain -tasolla, eli kuvaa esim. talous- tai henkilöstödataa.
Nimitys ”looginen” tulee siitä, että malli ei ole fyysinen malli. Se ei siis ota kantaa toteutusasioihin, kuten siihen, millä tietokantajärjestelmällä tuleva tietokanta toteutetaan.
Loogisilla malleilla on alatyyppejä, riippuen siitä millä menetelmällä ne tehdään. Esimerkkejä ovat perusrelaationaalinen malli, tähtimalli ja Data Vault -malli.
Myös loogisen mallin yhteydessä puhutaan käsitteistä, riippuvuuksista ja attribuuteista.
Alla on esimerkit yleisestä perusmallista sekä tähtimallista.
Loogisen mallin esimerkki
Tässä oleva looginen malli on muodostettu yllä olevasta käsitemallista.
Malliin on ilmestynyt laskurivi, joka purkaa käsitemallissa olleen laskun ja laskurivin välisen moni-moneen-yhteyden. Laskurivi liittyy laskun lisäksi tuotteeseen, sillä kullakin laskurivillä on yksi tuote. Lasku puolestaan liittyy asiakkaaseen ja myyjähenkilöön.
Loogiseen malliin voidaan merkata relaatiomallintamiseen kuuluvat perusavaimet (primary key) ja viiteavaimet (foreign key). Yllä lyhenteet ovat PK ja FK. Perusavain on sarake (tai useampi), joka on yksilöivä tunniste ko. käsitteelle. Viiteavain viittaa isä-käsitteen perusavaimeen.
Tietokantaa luotaessa seuraava vaihe on rakentaa tästä fyysinen malli.
Fyysinen malli
Fyysinen malli (Physical model) kuvaa teknistä tasoa. Siinä määritellään, miten tehty looginen malli toteutetaan jollakin tietokantajärjestelmällä, kuten SQL Serverillä tai Snowflakella.
Fyysisessä mallissa viritetään usein myös tietokantatoteutuksen suorituskykyä.
Lopuksi muodostetaan ko. tietokannan taulujen luontilauseet SQL-kielellä. Näin saadaan tietokanta perustetuksi.
Operatiivisen järjestelmän tietokannan mallintaminen
Jos tavoitteena on luoda operatiivisen järjestelmän tietokanta, on erittäin suositeltavaa tehdä ensin kohdealueen käsitemallinnus ja edetä sitten loogisten mallien kautta fyysisiin malleihin ja lopulta SQL-luontilauseisiin.
Käsitemalleja ja loogisia malleja testataan kokeilemalla niitä vasten kaikenlaisia tietotarpeita, kuten raportteja, käyttöliittymiä, API-rajapintoja ja eräajoja. Näin tiedetään jo etukäteen, että mallinnuksen kautta suunniteltu tietokanta toimii.
Tietokannan suunnittelu on siis tärkeä oma vaiheensa, joka kannattaa tehdä etupainotteisesti itse sovellukseen nähden. Sovelluksen toteutus on nopeampaa, kun tietokannassa on jo valmiiksi tarvittavat rakenteet.
Näin tietokannasta tulee huomattavasti pitkäikäisempi ja helpommin laajennettava kuin yleinen tapa, jossa kukin ohjelmoija toteuttaa tietokantaa ”kädestä suuhun” menetelmällä, yleensä ilman malleja.
Tietovaraston, analytiikan ja raportoinnin ratkaisut
Tällä ns tiedon toisiokäytön alueella on käsitemallinnus tärkeä aloitusvaihe. Siinä saadaan liiketoiminnan näkemykset kuvattua, jotka sitten eri vaiheiden kautta heijastuvat itse tietovaraston rakenteeseen.
Tietovaraston rakentamisessa käytetään yleisesti käsitemallien jälkeen loogisia malleja. Tällä tasolla on yleistynyt Data Vault-menetelmä, joka pitää sisällään tietyt säännöt loogisen mallin muodostuksessa. Palaan siihen myöhäisemmässä blogissa.
Myös tietovarastoympäristössä muodostetaan loogisista malleista fyysiset mallit ja lopulta SQL-luontilauseet, jotta tietokanta saadaan pystyyn.
Tietovaraston kylkeen rakennetaan yleensä ns. esityskerros (datamartit). Niiden mallinnuksessa on tähtimalli yleisin menetelmä.
Tähtimalli
Tähtimalli on siis tietojen raportoinnissa ja analysoinnissa yleinen mallinnusmenetelmä. BI-työkalut, kuten Power BI ja Tableau ”ymmärtävät” hyvin tähtimallia. SQL-kielellä on myös helppo tehdä kyselyjä tähtimalliin.
Tähtimalli noudattaa tiettyjä sääntöjä. Siinä käytetään pääosin vain kahdenlaisia tauluja: dimensioita (alla D-alkuiset) ja faktoja (F-alkuinen). Yksinkertainen rakenne helpottaa kyselyjä.
Tähtimalleja rakennetaan yleensä aikamoinen rypäs, perustuen eri käyttötarpeisiin.
Tähtimalli esimerkki
Alla oleva esimerkki kuvaa laskutuksesta tehtyä tähtimallia. Se on tehty Ellien loogisena mallina.
Tähtimallin laatikot kuvaavat relaatiokannan tauluja.
Mallista on nyt helppo kysellä vaikkapa tietyn tuotteen myyntiä tammi-helmikuussa kunnittain. Liitos tauluihin D_Pvm, F_Myynti, D_Asiakas, summataan myynnit. Hakuehdot: vuosi 2021, kuukaudet 01 ja 02, tuotekoodi PK12345.
Tai tietyn myyjän tai tiimin tietyn tuoteryhmän myynnit yhteensä vuoden alusta. Malli siis tukee hyvin monenlaisia haku- ja raportointitarpeita.
Lisäksi tähtimalli pitää huolen historioinnista. Jos esim. asiakas vaihtaa kuntaa, jää vanhankin kunnan aika talteen. Tässä tulevat avuksi mallissa näkyvät alku- ja loppupäivämäärät.
Lopuksi
Mallinnus on loistava menetelmä, koska sen lisäksi, että käsitemallit kuvaavat datamaailmaa liiketoimintalähtöisesti ja ymmärrettävästi, käsitemalleista malleista on selkeä polku tekniseen tietokantatoteutukseen asti.
Tai toisinpäin: voimme kuvata toteutetun tietokannan ylös asti, ymmärrettäviksi käsitemalleiksi. Näin saadaan mustat laatikot ja umpipurkit auki, ymmärrettävään muotoon.
Mallinnus mahdollistaa liiketoiminnan näkemysten heijastumisen aina tekniseen toteutukseen asti. Sen lisäksi syntyy hyvät dokumentit, joiden avulla jatkokehittäminen ja laajentaminen sujuu hyvin.
Kyse on toisin sanoen kommunikoinnista eri heimojen välillä, kuten liiketoiminta, IT-henkilöt ja toimittajat. Kyse on myös siitä, että ns enterprise-tasolla ei tehdä huonoja ratkaisuja, jotka kasvattavat ns ”teknistä velkaa”. Nykypäivänä moni koodari saattaa skipata tietyt vaiheest ylläkuvastusta ja ratkaisu voi näyttää siinä kohdassa nopealta.
Tässä on kuitenkin riskialtista ja lyhytnäköistä: organisaatiotason kehittämisessä myös muiden tulee ymmärtää tietoalustojen rakennetta, koska niitä kuitenkin kehitetään jatkuvasti erilaisia tarpeita tulee satavarmasti myöhemmin.
Ylläkuvatun menettelyn kaikkein tärkein ominaisuus on kuitenkin liiketoimintalähtöisyys – data-alustojen tulee hyödyttää oikeasti liiketoimintaa ja esittelemäni vaiheistus on tästä usein paras tae – voin näin sanoa lähes 30 vuoden kokemuksella.
Ystävällisin terveisin,
Ari Hovi
Ps. Ari Hovi järjestää nyt upouuden kurssin Data Mesh-aiheeseen liittyen:
Creating Data Products in a Data Mesh, Data Lake or Lakehouse for Use In Analytics 03.02 – 04.02.2022
Miten rakennetaan datatuotteita uusilla teknologioilla?
Mike Ferguson on yksi maailman johtavia data-alan teknologia-analyytikoita ollen hyvin perillä uusista trendeistä ja teknologioista. Nyt kannattaa säästää aikaa ja tulla kuulemaan parin päivän ajan, mitä maailmalla tapahtuu ja voisiko sinun organisaatiosi hyötyä alan uusista suuntauksista, kun Data Mesh ja Data Lakehouse. Kuulet käytännön toteutuksista sekä parhaista käytännöistä, tule siis mukaan!
Lisätiedot ja ilmoittautuminen tästä.
