Tietomallit osana informaatioarkkitehtuuria

Mitä ovat organisaation tietomallit?

Tietomallit ovat osa kokonaisarkkitehtuurin osa-aluetta informaatioarkkitehtuuri. Tyypillisesti tietomallit jaetaan kolmelle tasolle:

• Käsitteellinen tietomalli
• Looginen tietomalli
• Fyysinen tietomalli

Tietomalleja ei pidä sotkea rakennustietomallintamiseen eli BIM:iin!

Tietomallinnus ei ole pelkästään ICT:n vastuulla oleva implementointikysymys vaan kysymys on hyvin keskeinen osa liiketoimintaa.

Tietomallien tasot

Käsitemalli kuvaa keskeiset asiat organisaation toiminnassa eli käsitteen, käsitteiden välisen suhteen sekä suhteen luonteen.

Käsitemallia voidaan kuvata

• UML - luokkakaaviolla
• ER - kaaviolla

Looginen tietomalli tuo lisää sisältöä käsitemalliin, mutta ei kuitenkaan sanele sitä teknistä toteutustapaa jolla tietomalli implementoidaan. Käsitteen attribuutit, attribuutin datatyyppi ja erilaiset rajoitteet ovat lisäystä suhteessa käsitemalliin. Myöskin supertyyppi – ja alityyppi ovat loogisen tietomallin tason asioita.

Fyysinen tietomalli on kohdejärjestelmäkohtainen kuvaus siitä miten tietomalli esiintyy juuri kyseisessä järjestelmässä. Perinteinen fyysinen tietomalli on tietokantataulujen sekä muiden kantaobjektien kokoelma.

• Fyysisen mallin implementointi voi tapahtua esimerkiksi DDL – lauseet sisältävän .sql – skriptin avulla

Yleisesti ottaen ei kuitenkaan kannata rajoittua pelkästään tietokantamaailmaan, vaan myös joku dokumenttikanta voidaan ajatella tietomallin implementaationa.

Dimensiomallintaminen organisaation toiminnan analyyttisena kuvauksena

Ralf Kimballin 1990 – luvulla kehittämä tietomallintamisen lähestymistapa data-alustan ja BI / DW kehittämisen tarpeisiin. Periaatteessa myös uudempien Analytics Lakehouse Platform – teknologioiden medallion architecture on muunnelma tästä.

Keskeisiä dimensiomallintamiseen liittyviä asioita

• Dimensio
• Fakta
• Liiketoimintaprosessi
• Mittari ja KPI
• Dimension attribuutti
• Luonnollinen avain / liiketoiminta-avain
• Surrogaattiavain
• SCD – dimensiotyyppi

Dimensiomalli ja organisaation toiminnallinen kuvaus

Hyvä lähtökohta on sen mieltäminen että liiketoimintamallit ja liiketoimintaprosessit useimmiten edustavat organisaation toiminnassa pysyvyyttä suhteessa toiminnan organisoitumisen muotoihin eli organisaatiorakenteeseen. Tämä ei kuitenkaan tarkoita sitä etteikö Legal Entity / Organizational Unit / Business Unit / Cost Centre – rakenteilla olisi väliä, ne vain muuttuvat useammin.

Ralf Kimball kehitti eräänlaisen ”kytkentämatriisin” kuvaamaan toiminnan ja siinä jaettujen asioiden välistä suhdetta, tämä tunnetaan nimellä Enterprise Data Warehouse Bus Architecture.

Kun organisaation toiminnan kuvausta määritellään niin määrittelyvaiheen työpajoissa olisi syytä käydä läpi kokonaisuudet jotta ymmärretään asioiden liittyminen toisiinsa. Alla on eräs malli jonka mukaan voidaan toimia, perustuu Kimball Groupin julkaisuun.

Kuvio kuvaa organisaation liiketoimintaprosessit ja näiden prosessien jakamat yhteiset dimensiot matriisina. Periaatteessa liiketoimintaprosessin lisäksi voitaisiin ottaa kantaa vaikkapa omistavaan funktioon sekä asiakkuuden elinkaareen. Useimmiten toimintaa mitataan joidenkin tunnuslukujen avulla, nämä on myös syytä huomioida määrittelyvaiheessa.

Dimensiosta dimensio-objektiksi

Ensin määritetään dimensiotaulun liiketoiminta-avain eli luonnollinen avain joka voi olla muutaman attribuutin arvojen kombinaatio. Dimensio-objektiin, joka voisi olla tietokantataulu taikka parquet-deltatiedosto, luodaan erikseen surrogaattiavain sekä lisäksi liiketoiminta-avain. Surrogaattiavain voi olla generoitu numerosarja taikka jonkinlainen tiivistearvo.

Teknisiä kenttiä voidaan määritellä muutosvertailua sekä prosessimetadatan keräämistä varten.

Faktasta faktaobjektiksi

Faktat ovat olioita, jotka sisältävät liiketoimintaprosessiin liittyviä numeerisia tunnuslukuja eli mittareita. Yhden liiketoimintaprosessin osalta voidaan mallintaa 1..N faktaa. Faktoja ovat sekä tapahtumat että poikkileikkaustilanteet jonkun tapahtumahetken osalta. Tietokantataulu ja siitä johdettu näkymä ovat faktan perinteisiä ilmentymiä fyysisen tietomallin tasolla mutta yhtä hyvin faktataulu voi olla delta-taulu eli tietynlainen relaatiomallin mukainen kerros parquet - tiedostojen yläpuolella.

Faktaobjektin toiminnallisia kenttiä voivat olla erilaiset tiivistearvojen kentät jotka sisältävät muutosvertailua varten tiivistearvot.

Faktaobjektin luomisen vaiheet:

• Määritetään faktaobjektin hienojakoisuuden taso eli granulariteetti
• Määritetään faktaobjektin pääavain surrogaattiavaimena taikka suoraan eri dimensioiden arvojen perusteella
• Lisätään teknistä ja prosessimetadataa sisältäviä kenttiä
• Lisätään mahdollisesti muutosvertailun kentät

Granulariteetin vaihto on tietyssä mielessä kallis operaatio, mieti siis etukäteen!

Tyypillisesti faktatauluun lataus on UPSERT – operaatio eli uudet rivit lisätään ja vanhoilla päivitetään mittarien arvot jos muutoksia on tullut. Joskus harvoin voi joutua rakentamaan historioivan faktan, mutta sen tulisi olla poikkeus yleisestä käytännöstä.

Mittari ja KPI

Mittari on jonkun liiketoimintaprosessin tilaa kuvaava numeerinen suure, samaan liiketoimintaprosessiin voi liittyä useita faktoja sekä mittareita. Liiketoiminnan suorituskyvyn analytiikassa mallinnetaan kokonaisuus faktaobjekteina sekä niiden mittari - kenttinä.

On olemassa ”faktattomia faktoja”

• Vaikkapa työsuhteiden poikkileikkausfakta
• Sähkösopimuksen tuoterivit

KPI:t ovat tyypillisesti eri faktojen mittarien perusteella johdettuja päätöksenteon apuvälineitä, avaintunnuslukuja ei voi olla satoja mutta ”prosessimittareita” kyllä. KPI esitetään useimmiten suhteessa johonkin asetettuun tavoitearvoon.

Dimensiomalli käyttöliittymänä dataan

Ralf Kimballin esittämän ajattelun ohella on vaihtoehtoisia tapoja ajatella dimensiomallia, joillekin kyse on eräänlaisesta teknisestä ratkaisusta tarjota käyttöliittymä dataan. Tällaisessa tapauksessa dimensiomallia hyödynnetään data-alustalla eräänlaisena data mart - kerroksena ja on erikseen tietovarastokerros.

Tietomallintaminen mahdollistaa analytiikan ja kokonaisvaltaisen organisaation suorituskyvyn seurannan

Ready Solutionin data-alustojen kehittämisen palveluiden yhteydessä kehitystiimillä on tarvittava tietomallintamisen osaaminen jolla asiakkaan tavoitteet muutetaan teknisiksi ratkaisuiksi. Laita viestiä ohessa olevalla lomakkeella jos haluat kuulla miten ratkaisisimme haasteesi!