Tämä blogikirjoitus jatkaa toimitusjohtajamme Jani K. Savolaisen blogisarjaa tietomallinnuksesta. Käsittelen tässä kirjoituksessa Dan Linstedtin kehittämää Data Vault -mallinnusmenetelmää. Edellisessä postauksessa Jani kävi läpi Enterprise Data Warehouse BUS -mallinnusmenetelmän (Enterprise Data Warehouse BUS).

Mikä on Data Vault?

Data Vault on tietomallinnuksen ja tietovarastoinnin menetelmä, joka soveltuu monimutkaisen ja muuttuvan tiedon liiketoimintaympäristöön. Tällaisissa liiketoimintaympäristöissä dataa luetaan tietovarastoon useista eri lähteistä suurilla volyymeilla.    

Data Vault -menetelmän ajatuksena on rakentaa yksilöllisesti linkitetty joukko normalisoituja tietokantatauluja ja mahdollistaa näin tarkka tiedontaso. Data Vault -menetelmässä yhdistetään kolmannen normaalinmuodon (OLTP) ja dimensionallisen tietomallintamisen parhaat puolet yhdeksi hybridimalliksi.    

Data Vault -tietomalli on joustava ja skaalautuva, painottaen tietojen integrointia ja historiointia. Nämä ominaisuudet luovat pohjan Data Vault -tietovaraston asteittaiselle kehittämiselle, missä tietovarastoa laajennetaan yksi tieto- tai toteutusalue kerrallaan.

Perehdytään tässä blogissa tarkemmin (menemättä kuitenkaan syvälle teknisiin yksityiskohtiin) Data Vault arkkitehtuuriin, sen taulurakenteeseen, yleisiin Data Vault -mallinnussääntöihin sekä tietoalueittain toteutettavaan Data Vault -tietovarastoon.

Data Vaultin taulurakenne ja yleisiä mallinnussääntöjä

Data Vaultin taulut kategorisoidaan kolmeen päätyyppiin, jotka ovat hubi (hub), linkki (link) ja satelliitti (satellite). Taulut liittyvät toisiinsa surrogaattiavaimilla. Kerron alempana näiden taulujen ominaisuuksista ja luonteenpiirteistä tarkemmin.  

Jokaisessa taulutyypissä toistuu Data Vault -mallille yhteisiä tietueita, jotka mallinnetaan ja toteutetaan jokaiseen päätypin tauluun:

• Surrogaattiavain (yleisesti Hash-avain)
  • Hash-avain luo abstraktiokerroksen lähdejärjestelmän luonnollisten avainten ja tietovaraston surrogaattiavainten välille.
  • Hash-avain tekee historioinnista johdonmukaisempaa ja eristää tietovaraston lähdejärjestelmien muutoksilta.
  • Surrogaattiavaimia käytetään hubin ja linkin perusavaimina.
• Lähdejärjestelmä
  • Lähdejärjestelmätieto luo läpinäkyvyyttä ja mahdollistaa tiedon lähteen jäljitettävyyden.
• Aikaleima
  • Kertoo hetken, jolloin tieto on luettu ensimmäisen kerran tietovarastoon. Se kertoo, milloin tietoon on tullut muutoksia ja uusi rivi on alkanut. 

Data Vaultin taulut:

• Hubi – Ydinliiketoiminnan kokonaisuuksia ja käsitteitä, kuten asiakas tai tuote:
  • Hubiin listataan käsitteen yksilöivät uniikit liiketoiminta-avaimet (Business Key (BK)) tai luonnolliset-avaimet (Natural Key (NK)).
    • Esimerkiksi laskulle laskun numero (BK), tilaukselle tilausnumero (BK) ja henkilölle henkilötunnus (NK).
  • Yksilöivien luonnollisten avainten lisäksi Hub sisältää Surrogaattiavaimen (Hash-avain)
  • Hub ei voi yhdistyä toiseen hubiin. Hubien väliset yhteydet toteutetaan aina link -taulun avulla.
  • Hub voi olla isäntä usealle satelliitti -taululle.
  • Hub mallinnetaan tietomalliin aina ensimmäisenä.
• Satelliitti – Sisältää käsitteiden yksityiskohtaisen tietosisällön:
  • Tietosisältö, joka liittyy käsitteeseen Hash-avaimella. Voidaan liittää joko hubiin tai linkkiin.
    • Sisältää ainoastaan oman liiketoimintakäsitteen tietoja.
    • Satelliitilla pitää olla aina oma käsitetaulu, joko hub tai link.
    • Satelliitti ei voi yhdistyä suoraan toiseen satelliittiin.
  • Satelliitin avain muodostuu hub- tai link-taulun Hash-avaimesta ja aikaleimasta.
  • Tiedon historiointi tapahtuu satelliiteissa. Rivillä on tieto rivin voimassaolon alkamisesta ja päättymisestä.
  • Satelliitti on luonteeltaan samanlainen kuin tähtimallin normalisoitu dimensiotaulu, mutta voi sisältää myös faktatietoa (esim. tilausrivin hinta ja määrä)
  • Satelliitti mallinnetaan aina viimeisenä tai hubin jälkeen, jos hubeja yhdistäviä link-tauluja ei kehityshetkellä tarvita.
• Linkki – Tietojen yhteydet ja suhteet:
  • Link-taulut edustavat liiketoimintakomponenttien välisiä suhteita yleensä hub-taulujen välillä. Link-tauluun voi yhdistyä myös satelliitti.
  • Link-taulu sisältää oman Hash-avaimen sekä kontekstiin liittyvien hubien Hash-avaimet.
  • Link-taulu voi yhdistää useita hub-tauluja toisiinsa.
  • Mallinnetaan yleensä hubin tai hubien jälkeen.
• Yllä mainittujen taulutyyppien lisäksi Data Vault tietomallia voi rikastaa erilaisilla koodistoilla ja referenssitauluilla.

Esimerkki Data Vault arkkitehtuuri

Yleensä Data Vault -arkkitehtuuri rakentuu neljästä eri osa-alueesta. Vaikka kuva onkin perinteisempi lähestymistapa, soveltuu Data Vault myös moderniin Lakehouse -arkkitehtuuriin Silver medallion -kerroksen ratkaisuksi.

Käydään yllä olevan kuvan osa-alueita tarkemmin läpi alla rakenteen ja tietomallintamisen näkökulmasta:

• Landing Area
  • Landing Area on perinteistä tietovarastointia vastaava tiedon tallennuskerros, johon tieto luetaan ja tallennetaan lähdejärjestelmistä väliaikaisesti tai pysyvästi Data Integraatio -työvälineillä.
  • Dataa luetaan useista lähdejärjestelmistä erilaisin ETL-prosessein ennen datan siirtoa Data Vault -tietorakenteeseen. Landing Area ei ole varsinainen osa Data Vault -tietomallia.
  • Tiedot tallennetaan sellaisenaan Landing Areaan. Tietojoukkoon lisätään teknistä metadataa, esimerkiksi latausaika ja lähdejärjestelmä.
  • Mallintamismenetelmä Landing Areaa varten pyritään yleensä pitämään yksinkertaisena. Esimerkiksi:
    • Tietomalliin kuvataan lähdejärjestelmästä haetut taulut sellaisinaan lähdejärjestelmittäin.
    • Taulujen välisiä yhteyksiä ei kuvata.  
    • Taulujen nimeämisessä voidaan mainita Landing taulun lähdejärjestelmä.
• Raw Vault
  • Data Vault -tietomallin raakadatan kerros.
    • Lähdejärjestelmien tiedot mallinnetaan Data Vaultin hub-, link- ja satelliittimuotoon jaoteltuna asiakokonaisuuksiksi.
  • Data tallennetaan Raw Vaultiin alkuperäisessä tilassa ETL-prosesseilla Landing Arean datasta muuntamalla se Data Vault -tietomallin rakenteeseen.
• Business Vault
  • Hub-, link-, ja satelliittitaulut periytetään Raw Vaultista.
  • Yhtenäistetään lähdejärjestelmien päällekkäiset tiedot yhtenäisiksi käsitteiksi.
  • Voidaan toteuttaa yksinkertaisia liiketoimintasääntöjä.
  • Voidaan hyödyntää koodistoja ja referenssitauluja tiedon rikastamiseen.
  • Tarvittaessa luodaan Business Vault spesifejä linkkejä tai hubeja.
  • Business Vault voidaan toteuttaa virtualisoituna näkymillä ja ulkoisilla tauluilla (external tables) Raw Vaultin datasta. 
• Information Delivery
  • Sisältää Data Vault -tietomallin päälle rakentuvia Data Marteja.
  • Mallinnetaan raportoinnin osa-alueita tähtimallina fakta- ja dimensiotauluiksi.
  • Raportoinnin ja analytiikan pääasiallinen hyödyntämiskerros.
  • Voidaan toteuttaa virtualisoituna.
    

Data Vault inkrementaalinen kehitys

Yllä oleva Data Vault -tietomalli havainnollistaa iteratiivisen kehittämisen hyötyjä Data Vault -tietovaraston kehityksessä ja toteutuksessa:

• Ensimmäisessä iteraatiossa toteutetaan hub asiakas ja satelliitti asiakkaan yhteystiedot.
• Toisessa iteraatiossa luodaan hub tilaus, link asiakastilaus, joka mahdollistaa tilaus ja asiakas hubien yhteyden, ja satelliitti tilaus, joka sisältää tilauksen tietosisällön.
• Kolmannessa iteraatiossa toteutetaan tuote ja tilausrivi kokonaisuus, mikä yhdistyy tilausrivi linkillä aiemmin toteutettuun tietomalliin.

Kun toteutusta tehdään näin vaiheissa toteutusalueittain, jo olemassa olevaan tietovarastoon ja sen rakenteisiin ei kohdistu muutoksia. Tietomalli niin sanotusti laajentuu uudella osa-alueella, joka muodostuu tietokannan näkökulmasta uusina tauluina ja niiden välisinä yhteyksinä olemassa-olevaan rakenteeseen avainparein.

Kokonaisuutena ketterä kehitys toimii myös tehokkaasti Data Vault -menetelmällä. Avataan prosessia yksinkertaisella esimerkillä:

• Data Vault -toteutuksen ensimmäisen iteraation ollessa käynnissä, voidaan samalla mallintaa Information Deliveryn ensimmäistä osaa. Kun ensimmäinen iteraatio on toteutettu Data Vault -tietovarastoon, voidaan toisen iteraation aikana aloittaa Data Marttien toteutus rinnakkain Data Vaultin kehityksen kanssa. Luodaan tähtimalli asiakastiedolle samalla, kun Data Vaultissa toteutetaan toisen iteraation tilausosiota.      

Data Vault -menetelmän tunnistettuja hyötyjä

Data Vault -menetelmällä on useita tunnistettuja hyötyjä, listataan alla niistä tärkeimpiä:

• Ketteryys ja joustavuus:
  • Data Vault -menetelmä mahdollistaa ketterän kehittämisen. Sitä voidaan toteuttaa pienillä muutoksilla olemassa oleviin kokonaisuuksiin ja laajentamalla tietomallia uusin kokonaisuuksin pienissä osissa.
  • Tietovaraston eri kerroksia esim. Raw Vault ja Information Delivery voidaan kehittää rinnakkain.
  • Jatkuvassa muutoksen tilassa olevat lähdeympäristöt voivat olla haasteellisia toteuttaa esim. perinteisellä tähtimallilla. Data Vaultin tietomalli sietää paremmin tällaisia muutoksia.
• Skaalautuvuus:
  • Sopii hyvin suurille datamassoille ja useiden lähdejärjestelmien integroimiselle yhteiseen tietomalliin.  
• Historiatiedot:
  • Data Vault -menetelmällä tallennetaan satelliitteihin käsitteisiin liittyvät historiatiedot. Tämä mahdollistaa tarkat historialliset trendianalyysit.
• Johdonmukaisuus:
  • Data Vault menetelmän johdonmukainen tietojen mallintaminen ja nimeäminen varmistaa, että organisaation tiedot noudattavat standardoituja rakenteita ja nimeämiskäytäntöjä. Tämä helpottaa organisaation kehittäjiä ja liiketoimintaa ymmärtämään ja käsittelemään dataansa yhdellä kielellä.

Data Vaultin haasteet ja sopivuus yrityksen tietovaraston rakenteeksi

Yleistettynä Data Vault -tietovarasto sopii paremmin suurille yrityksille, joiden tietovarastolla on useita lähdejärjestelmiä ja usein muuttuva tai kasvava tietoympäristö. Vastaavasti Data Vault on verrattain raskas mallinnusmenetelmä pienempiin tietovarastototeutuksiin kerroksellisuutensa vuoksi.

Data Vault ei sovellu raportoinnin- ja analytiikkaratkaisuille suoraan, vaan tarvitsee aina informaationjakokerroksen. Tämä on yksi syy miksi Data Vaultin toteutus ja mallintaminen vaatii laajan osaamisportfolion: Kehittäjän tulee hallita useampia eri tietovarastoinnin menetelmiä kokonaisuuden rakentamiseksi.

Tietomallin kasvaessa suureksi, historian seuranta ja taulujen liiallinen normalisointi voi aiheuttaa kyselyjen suorituskyvyissä ongelmia vaativien (join) kyselyiden takia. Toisaalta huolella suunniteltu ja rakennettu Data Vault on usein riittävän suorituskykyinen.

Yhteenveto

Data Vault -mallilla on paikkansa silloin kun tietovarastolla on useita lähdejärjestelmiä ja halutaan saada yksi toimiva kokonaisuus. Normalisoinnilla voi kuitenkin olla hintansa, eritoten ylläpidettävyyden ja SQL-kyselyiden suorituskyvyn suhteen.

Data Vault voi ratkaista usean siiloutuneen tietokannan yhtenäistämisen pilviympäristöön yhdeksi selkeäksi kokonaisuudeksi. Data Vault soveltuu myös osaksi perinteistä ja modernimpia, kuten Lakehouse, tietokantaratkaisuja.

Haluatko keskustella lisää tietomallintamisesta? Ota yhteyttä niin jutellaan.

Robin Aro

robin.aro@dbproservices.fi

Lead Data Engineer

DB Pro Services Oy

Jatkan taasen blogisarjaani tietomallinnuksesta. Edellisessä postauksessani kuvasin lumihiutalemallia. (Tietomallinnus – Lumihiutalemalli (Snowflake schema)). Tänään läpikäyn Ralph Kimballin koulukunnan ns. Enterprise Data Warehouse BUS -mallinnusmenetelmää. Toiselta nimeltään tämä tunnetaan myös Conformed Data Warehouse BUS:ina.

Mikä on Enterprise Data Warehouse BUS?

Enterprise Data Warehouse BUS on eräs fyysisen tietomallinnuksen menetelmä, tai enemmänkin arkkitehtuurinen tapa ajatella tietomallinnusta, jolla voidaan rakentaa konsernitietovarastoja tähtimallin päälle siten, että se ottaa huomioon bisneksen ns. 360-näkymän. Tämä tarkoittaa käytännössä eri järjestelmien välistä yhteistä master dataa, jotka mallinnetaan dimensioiksi.

Enterprise Data Warehouse BUS:in ideana on:

–  Selkeyttää riippuvuussuhdetta master datan kehityksen ja EDW-kehityksen välillä

–  Toimia nimensä mukaisesti tehokkaana EDW-mallinnusmenetelmänä

–  Maksimoida 360-näkymä bisnekseen

–  Minimoida muutostarpeet fyysisessä tietomallissa ajan saatossa

Master data ja Enterprise Data Warehouse BUS

Yleisesti ajatellaan, että monilähteisen konsernitietovaraston voi rakentaa vasta, kun master-datan hallinta on implementoitu. Tämä onkin lähtökohtaisesti suotavaa, koska tällöin saadaan ns. ”yksi totuus” eri järjestelmien välisestä datasta ja datan laatu sekä rikastamisprosessit ovat paremmin hallussa. Koska kuitenkin usein tähän ruhtinaallisuuteen ei ole aikaa, päätetään silti tehdä konsernitietovarasto, vaikka master datan osalta oltaisiinkin vaiheessa, tai joskus jopa alkutekijöissään. Se, mitä minimissään kannattaa kuitenkin tehdä tällaisissa tapauksissa, on se, että määritellään sellainen master data, joka halutaan tuoda konsernitietovarastoon raportoinnin piiriin. Nämä ovat ns. konformoituja dimensioita (”conformed dimensions”). Kussakin tällaisessa dimensiossa määritellään se ja vain se data, joka esiintyy eri järjestelmien välillä samanmuotoisena, kun kaikki osajärjestelmät yhdistetään yksilöivien tietojen (=natural key) kautta keskenään. Tyypillisiä konformoituja dimensioita ovat esimerkiksi kalenteridimensiot, kuten kuukausi, päivä ja tunti sekä tuote-, yritys- ja henkilötietoihin sekä geografiaan ja demografiaan liittyvät dimensiot.

Kuinka Enterprise Data Warehouse BUS -väylä rakennetaan

Kun konformoidut dimensiot on ensiksi määritelty, voidaan tämän päälle sitten menestyksellisesti rakentaa joko syklisellä tai iteroivalla metodilla konsernitietovarasto. Tätä voidaan tehdä joko osajärjestelmä kerrallaan tai sitten sisällyttäen skeemaan ensin kriittiset, sitten tärkeät ja sitten vähemmän tärkeät tiedot, kunhan faktataulujen granulariteetti pysyy samana. Tällöin tähän konformoitujen dimensioiden ”väylään” (BUS) syntyy vähitellen yhä enemmän viitteitä yhä useammista faktatauluista ja säästytään isolta refaktorointityöltä sekä fyysisen tietomallin, että integraatioajojen (ETL / ELT) osalta.

Konformoitujen dimensioiden matriisi osana suunnittelua

Konformoitujen dimensioiden määrittämistä selkeyttää paljon, mikäli laaditaan organisaation keskeiset bisnesprosessit ja dimensiotietoineen. Tämä harjoitus kannattaa tehdä Kimballin mukaan siksi, ettei unohdeta yhtäkään sellaista dimensiota, jotka ovat tietyille bisnesprosesseille yhteisiä. Yksi bisnesprosessi synnyttää aina yhdestä useampaan faktaskeemaa itse tietovarastoon, ja tällä tavalla nähdään helposti, mitkä dimensiot ovat konformoituja useamman bisnesprosessin suhteen.

Esimerkkimme: Enterprise Data Warehouse BUS Matrix

Enterprise Data Warehouse BUS – haitat

–  Vaatii ainakin osittaista panostamista master dataan (on toisaalta hyväkin asia)

–  Vie alussa hieman enemmän aikaa toteuttaa kuin puhdas tähtimalli; ensimmäinen julkaisusykli on pidempi

Enterprise Data Warehouse BUS – hyödyt

–  Säästytään isolta refaktorointityöltä fyysisen skeeman ja tietomallin osalta ajan kuluessa

–  Luo säästöjä ja nopeuttaa Time-To-Solutionia kokonaisratkaisussa

–  Saadaan maksimaalinen 360-näkymä bisnesdataan

–  Tietomalli yksinkertaistuu (vähemmän tauluja)

Esimerkkimme – Enterprise Data Warehouse BUS dimensionaalinen malli

Yhteenveto

Conformed Data Warehouse BUS on yksinkertainen ja nerokas tapa säästää aikaa ja vaivaa monilähteisessä tietovarastoinnissa, kuten EDW-hankkeissa. Vanhaa japanilaista viisautta pilke silmäkulmassa soveltaen: ”Mikään ei ole niin tärkeää tietovarastoinnissa kuin täysin valmis master data – eikä sekään ole niin kovin tärkeää.”

Haluatko keskustella kanssani tietomallinnuksesta? Ota yhteyttä!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

CEO & Chairman

DB Pro Services Oy

Jatkan jälleen blogisarjaani tietomallintamisesta. Edellisessä postauksessani kuvasin tähtimallin keskeisiä elementtejä. (Tietomallinnus – Tähtimalli (Star schema)). Tänään läpikäyn lumihiutalemallia (=Snowflake schema).

Lumihiutalemalli on eräs fyysisen tietomallintamisen menetelmä, jolla voidaan rakentaa tietovarastoja ja data martteja. Se on läheistä sukua tähtimallille ja hieman etäisempi esi-isä data vaultille.

Itse miellän lumihiutalemallin skeeman eräänlaiseksi OLTP-mallin ja tähtimallin välimuodoksi. Sillä kun on piirteitä sekä ei-toiminnallisia ominaisuuksia molemmista. Lumihiutalemallissa on enemmän tauluja sekä niiden välisiä liitoksia kuin tähtimallissa, toisin sanoen malli on normalisoidumpi kuin tähtimallissa mutta denormalisoidumpi kuin OLTP-mallissa: Siinä missä tähtimallissa kunkin faktataulun ympärille generoituu yksiulotteisia ”tähden sakaroita” eli dimensioita, lumihiutalemallissa normalisoidaan dimensiorakennetta niveltämällä tähtien sakaroihin ns. ”alidimensioita”, aivan kuten lumihiutaleen kiderakenteessa. Esimerkiksi; sen sijaan, että kasvattaisimme faktataulun viiteavainmäärää, luomme uuden alidimension jatkoksi tarkimman granulariteetin omaavalle dimensiolle, johon viittaamme tästä karkeamman granulariteetin dimensiosta. Tässä reunaehtona on, että dimensiot liittyvät loogisesti toisiinsa, kuten esim. Tuotedimensio ja Tuoteryhmädimensio. (Tuotteella on yksi Tuoteryhmä ja Tuoteryhmässä voi olla monta Tuotetta).

Lumihiutalemallin keskeiset sudenkuopat

–       Erillisiä hierarkioita ei kannata yleensä purkaa lähinnä suorituskykynäkökulmasta omiksi lumihiutaleikseen, ellei tällä sitten saavuteta esimerkiksi konkreettista tilansäästöä tai esimerkiksi käytettävä BI-teknologiaratkaisu suosii ko. mallia.

–       Lumihiutalemallissa taululiitosten määrä aina kasvaa ja komplisoi tietomallia sekä hidastaa SQL-kyselyitä konkreettisesti. Siksi se sopii vain tiettyihin käyttötapauksiin.

–       Lumihiutalemallin ylläpitäminen voi ajan saatossa tulla kankeaksi ja työlääksi ETL-prosessin osalta, eritoten mikäli lähdejärjestelmien tietomallit elävät paljon.

Lumihiutalemallin hyödyt

–       Tilansäästöt voivat olla merkittäviäkin tietyissä käyttötapauksissa.

–       Eräs lumihiutalemallin eduista on ns. ”bridge”-tekniikka eli siltaus, jonka avulla voidaan purkaa monen suhde moneen -relaatio järkevästi siten, että meillä on faktataulu, johon kytketään dimensiotaulu siten, että alidimension ja dimension välille syntyy bridgetaulu, joka normalisoi monen suhde moneen -relaation viittaamalla yhtä aikaa dimensioon ja sen alidimensioon; näin atomisoiden dimensio-alidimensio -arvoparit. Esimerkiksi; mikäli meillä on Tuote joka voi kuulua moneen Tuoteryhmään ja Tuoteryhmä joka voi linkittyä moneen Tuotteeseen. Edelleen; bridgetauluun voidaan tuoda ns. ”weighting factor” -kenttä, joka pilkotaan alidimension esiintymien suhteessa per dimensio tietuetasolla murto-osaksi sadasta prosentista. Esimerkiksi; jos meillä on vaikkapa sairaalajärjestelmässä potilas, joka saa 3 diagnoosia ajanhetkellä t, on hänen diagnostinen weighting factorinsa 100% / 3 = 0,333… (desimaalilukuna). Tällöin voidaan laskea faktoja sekä dimension että alidimension suhteen, koska datan summautuvuus on grainin suhteen vakio (3 x 0,333… = 1).

Esimerkkimme lumihiutalemallista.

Oheisesta tietomallista voitaisiin kysellä varsin triviaalisti vaikkapa laskutustiedot potilaittain ja kohteittain tai vastaavasti summata vastaavat tiedot diagnooseittain. Mikäli sama tulos haluttaisiin saavuttaa tähtimallilla, voisi vaihtoehtona olla esim: 1) syventää granulariteettia ja linkittää diagnostinen dimensio suoraan faktan piiriin tai: 2) luoda diagnostisia filtterikenttiä potilasdimensioon, joka voisi toisaalta johtaa hankalasti ylläpidettävään tietomalliin, koska diagnoosit voivat elää ajan funktiona sekä edelleen: 3) luoda useampi faktataulu.

Yhteenveto

Lumihiutalemallilla voi olla paikkansa silloin kun tietomalli on todella kompleksinen tai datamäärä muutoin nousee tähtimallin kanssa ongelmaksi. Normalisoinnilla on kuitenkin hintansa, eritoten ylläpidettävyyden ja SQL-kyselyiden suorituskyvyn suhteen.

Haluatko keskustella tietomallintamisesta? Ote yhteyttä niin jutellaan.

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

CEO & Chairman

DB Pro Services Oy

Tämä kirjoitus jatkaa blogisarjaani tietomallintamisesta. Edellisessä blogipostauksessani käsittelin kolmatta normaalimuotoa. (Tietomallinnus – Kolmas normaalimuoto (OLTP)). Tänään puhutaan tähtimallista (=star schema).

Eräs fyysisten tietomallien tyypeistä on ns. tähtimalli. Se on raportointitietokannoissa (data mart, EDW) yleisimmin käytetty tietomalli. Tähtimalli on myös OLAP-teknologiassa käytetty skeema ja sitä käytetään hyvin yleisesti myös Power BI-raportoinnissa. Tähtimallin skeema sijoitetaan lähes poikkeuksetta omaan tietokantaansa sen intensiivisten lataus- / tietokantakyselykuormien takia, jotka poikkeavat merkittävästi perinteisten OLTP-kantojen työkuormatyypeistä (vrt. OLTP:n purskeiset vs. DW:n sekventiaaliset työkuormat). Vaikka tähtimallilla onkin tyypillisesti helppoa ja nopeaa mallintaa DW-tietokanta, ei sekään automaattisesti sovellu kaikkiin DW-käyttötapauksiin parhaalla mahdollisella tavalla.

Itse sain ensi puraisuni tähtimallista jo 90-luvun loppupuolella. Tämän jälkeen olen ehtinyt suunnitella ja toteuttaa vuosien varrella useita kymmeniä tähtimallisia tietokantoja moniin eri käyttötarkoituksiin.

Esimerkkicase

Esimerkkiasiakkaamme, kuvitteellinen B2C-yritys myy globaalisti yksityishenkilöasiakkailleen erilaisia tuotteita. Tuotteita voi ostaa kerralla useamman kappaleen ja niillä on aina kunakin ajanhetkenä tietty yksikkö- sekä näin ollen kokonaismyyntihinta. Asiakkaallamme on tarve tuottaa monipuolisesti raportteja sekä hyödyntää edistynyttä analytiikkaa erillisestä raportointikannasta ilman, että tuotantopalvelimen CRM-kanta häiriintyy (CPU-kuorma, levylatenssit, muistinkäyttö, lukitukset jne.). Ratkaisuksi tähän luodaan tähtimallinen data mart -tietokanta, johon tiedot ladataan operatiivisesta tietokannasta yöllisinä eräajoina.

Esimerkkimme tähtimallista.

Tähtimallin taulut

Tähtimallissa on periaatteessa vain kahdenlaisia tauluja: Faktatauluja sekä niitä ympäröiviä dimensiotauluja. Sen normalisointi toteutetaan toisessa normaalimuodossa (2NF), jolloin sama tieto toistuu (=redundanssi) useamman kerran tietokannassa. Tällä tekniikalla saavutetaan kuitenkin merkittäviä helppokäyttöisyys- ja suorituskykyhyötyjä luotaessa erilaisia raportteja sekä analyysejä historiatyyppisestä datasta. Kuinka temppu sitten käytännössä tehdään?

Faktat ja dimensiot

Faktataulu sisältää tapahtumamuotoista tietoa, eli laskennallisia suureita, sekä niiden viittaukset tapahtumia kuvaaviin olioihin (dimensiot) sekä dimensioattribuutteihin. Jokaisesta faktataulun tapahtumasta (=transaction) on viittaukset sitä ympäröiviin dimensiotauluihin. Tätä voidaan ajatella siten, että jokaisen “tähden” ytimenä toimii faktataulu ja dimensiot ovat tähteä ympäröiviä sakaroita. Edelleen huomataan, että faktataulu sisältää avaimien lisäksi ainoastaan laskennallisia, aggregoitavia tietojäseniä eli mittaritietoa (=measure). Tarvittaessa faktataulun suorituskykyä voi parantaa lisäämällä sinne erilaisia laskennallisia kolumneja (=calculated members), jotka summautuvat eri tasoilla dimensioiden suhteen. Mitä nämä dimensiot sitten ovat?

Dimensionaalisissa tauluissa kuvataan kunkin faktarivin ominaisuuksia halutulla tiedon tarkkuustasolla. Eli esimerkiksi sitä, mikä oli tuotteen myyntipäivä tai että kuka ja mistä osti tietyn tuotteen. Kaikki dimensioattribuutit on jalostettu helposti ymmärrettävään muotoon ja NULL-arvot korvataan ns. ”undefined” -referensseillä eli default-arvoilla jotka kuvaavat sitä, että kentälle ei ole määritelty arvoa lainkaan, jotta turhalta kolmikantalogiikalta vältytään raportoinnin yhteydessä. Kirjainlyhenteiden ja koodien lisäksi monissa attribuuteissa käytetään luonnollista kieltä, jolloin datamassa muodostuu informatiivisemmaksi sekä helpommaksi raportoida ja analysoida. Tämän lisäksi on tyypillistä, että yksittäisistä dimensiojäsenistä (=dimension members) päätellään erilaisia ryhmitteleviä tekijöitä, kuten vaikkapa yrityksen liikevaihtoluokka. Operatiiviset e. luonnolliset avaimet (=natural key) kuljetetaan massalatausten (=ETL, ELT) mukana dimensiotauluihin omiksi kentikseen.

Tähtimallin avaimet

Tähtimallille ominaista ovat inkrementaaliset kokonaislukuavaimet eli nk. surrogaattiavaimet (=surrogate keys), jolloin skeeman suorituskyky on mahdollisimman hyvä. SQL Server -maailmassa kannattaa lähtökohtaisesti käyttää bigint -tietotyyppiä taulujen pääavaimille (=primary key) silloin, kun on odotettavissa, että kantaan tullaan hilloamaan vähintään miljardeja tietueita. Lisäksi annan pienen näppärän vinkin päivädimension pääavaimen luomiseen: Siihen kannattaa sijoittaa suoraan päivämäärä muodossa YYYYMMDD. Tämä mahdollistaa mm. sen, että faktataulun viiteavaimesta näkee suoraan, mille ajanjaksolle faktatieto sijoittuu.

Tähtimallin nimeämiskäytännöistä

Käytännön syistä on hyödyllistä nimetä fakta- ja dimensiotaulut aina siten, että niiden tyyppi voidaan tunnistaa kirjoitusasunsa perusteella. Itse pidän käytännöstä, jossa nimetään faktataulut “F_” -prefiksillä ja tarpeen tullen “Fact” -postfiksillä sekä dimensiotaulut “D_” -prefiksillä. Tämä mahdollistaa tunnistettavuuden lisäksi myös tietokantaympäristössä erilaisten skriptiautomaatioiden luonnin helpottumisen. Pääavaimet kannattaa nimetä selkeyden vuoksi “PK_” ja viiteavaimet (=referential key) “FK_”.

Tähtimallin granulariteetti

Faktataulun dimensioreferenssit käytännössä määrittelevät yhdessä tiedon esitystarkkuuden (=granularity). Tätä tarkkuustasoa ei voi myöhemmin enää tarkentaa rikkomatta koko dimensionaalista mallia, refaktoroimalla sitä ja tekemällä ETL-latauksia kokonaan uudelleen. Tämän vuoksi onkin tärkeää, että ensimmäinen mietitty asia per yksittäinen tähtimallin skeema (=fakta + dimensiot) on juurikin sen granulariteetti: Esimerkin data marttiimme onkin päätetty kerätä CRM-kannasta tuotemyyntien tapahtumatietoa päivätasolla, tuotteittain, henkilöittäin sekä kohdekaupungeittain. Jos esimerkiksi haluaisimme tietää jälkeenpäin tunnin tarkkuudella, että mihin aikaan jotain tiettyä tuotetta on tilattu, emme saisi tätä tietoa raportoitua data martin kautta, koska granulariteetti aikadimension suhteen on päivä (D_Date).

Faktataulun summautuvuus (=additivity)

Faktataulun kukin mitta-arvo voi summautua eri tavoin. Näitä on kolmea eri tyyppiä. Ne ovat:

–       Non-additive measures. Tällaisia ovat sellaiset mitta-arvot, jotka eivät aggregoidu millään dimensiotasolla.

–       Semi-additive measures. Tällaisia ovat sellaiset mitta-arvot, jotka aggregoituvat oikein vain tietyillä dimensiotasoilla.

–       Full-additive measures. Tällaisia ovat sellaiset mitta-arvot, jotka aggregoituvat oikein kaikkien dimensiotasojen suhteen.

Aikadimensio ja dimensiohierarkiat

Aikadimensio sisältää hierarkkisen (=dimension hierarchy) kuvauksen kuhunkin faktataulun tapahtumaan liittyvästä ajankohdasta, esimerkiksi vuosi-kuukausi-päivämäärä. Esimerkissämme on jokseenkin kattava aikadimensio, mutta perusteellisissa aikasarja-aritmetiikkaa vaativissa ympäristöissä saattaa olla tarvetta jopa kymmenille hierarkian tasoille (=level). Myös rinnakkaisia hierarkioita voi olla useita, esim. vuosi-kuukausi-päivämäärä vs. vuosi-kvartaali-kuukausi. Aikadimension generointi kannattaa automatisoida erillisellä skriptillä, jolloin sen ylläpitäminen on vaivatonta.

Role playing -dimensiot

Tähtimallille ominaista on dimensiotaulujen monikäyttöisyys. Ajatellaanpa vaikkapa aikadimensiota (D_Date). Voimme haluta seurata tuotteen myyntiä esimerkiksi sekä myyntipäivän (FK_SalesDate), että tilauspäivän (FK_OrderDate) suhteen. Tämä on mahdollista luomalla yksinkertaisesti kullekin tällaiselle tarpeelle oma viiteavaimensa faktatauluun, joka sitten viittaa samaan dimensioon mutta mahdollisesti eri riviin kyseisessä taulussa. Esimerkiksi siten, että FK_OrderDate viittaa tilauspäivämäärätietueeseen ’18.6.2023’ aikadimensiossa (D_Date) ja FK_SalesDate viittaa vastaavasti tuotteen myyntipäivämäärään ’19.6.2023’.

Parent-Child -hierarkiat

Parent-Child-hierarkialla (Parent-Child hierarchy) voidaan kuvata hierarkkista dimensiota, jonka syvyys vaihtelee. Tällainen tyypillinen hierarkia on esimerkiksi organisaatiodimensio, jossa organisaation eri tasoilla voi olla vaihteleva määrä esihenkilöitä sekä alaisia. Viittaukseen käytetään tyypillisesti ns. ParentId -kenttää, joka viittaa dimensiotauluun itseensä (=implosion).

Hitaasti muuttuvat dimensiot (SCD, Slowly Changing Dimension)

Hitaasti muuttuvat dimensiot (=SCD) kuvaavat dimensiotiedon muutosta ajan funktiona. Tämä on tietovaraston merkittävä etu verrattuna operatiivisiin tietokantoihin, joissa on tyypillistä että niistä säilötään vain viimeisin tieto. Näitä ovat SCD0, SCD1, SCD2, SCD3, SCD4, SCD5, SCD6 sekä SCD7, joista yleisimpiä ovat SCD0, SCD1 ja SCD2. Kaikki nämä tietueet identifioidaan luonnollisen avaimen perusteella. Tyypillisimmät SCD:t ovat:

–       SCD0-dimensiossa säilytetään aina alkuperäinen arvo. Tällaista tietoa ovat mm. auton rekisterinumero sekä henkilön syntymäpäivä. Tämän SCD-tyypin heikkous on se, että dimensiohistoriaa ei synny.

–       SCD1-tyyppisessä dimensiossa kenttäkohtaiset muutokset jyrätään aina yli ilman historiointia. Tämän SCD-tyypin heikkous on se, että vanhaa dimensiohistoriaa ei säilötä siihen linkitetyn faktan suhteen, vaan ainoastaan viimeinen arvo merkkaa.

–       SCD2-tyyppisessä dimensiossa joko lisätään aina kokonaan uusi rivi tietueen muuttuessa höystettynä versioattribuutilla tai sitten lisätään start date- ja end date -kentät näyttämään mihin kukin tietue on voimassa (NULL end datena nykytilanteessa). Kolmas vaihtoehto on merkata kullekin tietueelle effective date ja current flag (N/Y). Tämän SCD-tyypin heikkous on lähinnä se, että mikäli dimension muutostiheys on suuri ja attribuutteja on paljon, dataa voi kertyä todella runsaasti – tämä voi olla joskus haaste latausajoille sekä taulun indeksoinnin suhteen.

Monsteridimensiot

Monstereita ovat sellaiset dimensiot, joissa tietuemäärä kasvaa niin suureksi, että se alkaa vaikuttamaan tietovarastokannan suorituskykyyn. Näitä dimensioita kannattaa usein pilkkoa pienemmiksi, luokitteleviksi dimensioiksi, jotta suorituskyky paranee. Samalla säästetään tilaa. Tähän on olemassa lukuisia eri tekniikoita sekä parhaita käytäntöjä. Eräs tekniikka on luoda ns. identity-profile-dimensiopareja, joista identity-dimensioon säilötään dimension muuttumattomat attribuutit ja profile-dimensioon dimension muuttuvat tiedot. Tämän seurauksena tietuemäärät vähenevät ja turhalta toisteisuudelta vältytään. Tietovarastossakin rajulla denormalisoinnilla on hintansa.

Yhteenveto

Tähtimalli voi kuulostaa simppeliltä ja pitkälle sitä onkin, mutta isommissa ja kompleksisemmissa ympäristöissä huono mallintamistekniikka johtaa helposti kömpelöön tietomalliin, jota on hankala ylläpitää ja jonka suorituskyky ja tilantarpeet ovat haastavat ja raportoitavuus sekä tuki kehittyneelle analytiikalle ovat puutteelliset. Tämän takia tähtimallista sekä siihen liittyvästä ns. dimensiomallintamisesta on jokaisen päteväksi tietomallintajaksi tähyävän syytä tuntea enemmänkin kuin vain perusteet. Tässä blogipostauksessani kävin läpi pääsääntöisesti vain perusteita. Erinomaista syväluotausta tähtimalliin liittyen löydät mm. Ralph Kimballin kirjasta ”The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling”.

Onko organisaatiossanne tietovarastointitarpeita? Otathan yhteyttä niin keskustellaan lisää!

Jani K. Savolainen
jani.savolainen@dbproservices.fi
0440353637
CEO & Chairman
DB Pro Services Oy

Tämä postaus jatkaa blogisarjaani tietomallintamisesta (Tietomallinnus – intro). 

Operatiiviset eli ns. OLTP-tietokannat ovat transaktiointensiivisiä. Tämä tarkoittaa, että dataa kirjoitetaan ja päivitetään tietokantaan tiuhaan tahtiin lukuoperaatioiden lisäksi, usein 60/40 – 90/10 RW-suhteessa. Tällaisia ovat mm. ERP-tietokannat. OLTP-työkuormille tyypillisiä piirteitä ovat pienet tulosjoukot sekä yksinkertaiset kyselyt. Edelleen; OLTP-työkuormat ovat luonteeltaan satunnaisista luku- ja kirjoitusoperaatioista koostuvia, joissa on pienempi tallennusblokkikoko kuin tietovarastojärjestelmissä. OLTP-työkuormille on tyypillistä myös latenssiherkkyys. 

Kaikki tämä asettaa erityisiä vaatimuksia tietomallille, jotta tietokannanhallintajärjestelmän suorituskyky ja skaalautuvuus ei muodostu pullonkaulaksi, kun sen työkuormat ja käyttäjämäärät lisääntyvät. Tämän takia hyvä OLTP-tietomalli onkin varsin polarisoitunut verrattuna hyvään tähtimalliin (tietovarasointi). Hyvä OLTP-tietomalli onkin summeerattuna sellainen, jossa oliot ja niiden ominaisuudet esitetään kerran ja vain kerran, relaatioineen. Täten saadaan tietokannan transaktionaalinen suorituskyky maksimoitua ja mahdolliset lukitustilanteet minimoitua. 

Mihin OLTP-tietokanta ei sovellu 

Koska operatiivisen tietokannan tietomalli on optimoitu transaktionaaliseen dataan, on siitä usein hidasta ja monimutkaista kysellä suuria tietomääriä. Juuri tästä syystä OLTP-kannat eivät sovellu hyvin raportointiin, koska raportoinnissa on tyypillistä yhdistellä, summata ja jalostaa suuria datamääriä keskenään. Kaikki tämä johtaa OLTP-kannassa helposti korkeaan prosessorin käyttöasteeseen, muistiongelmiin sekä hallitsemattomiin levykuormiin ja lukitustilanteisiin.  

Tyypillinen raportoinnin evoluutio tällaisissa tietokannoissa on ns. ”laastariratkaisu”, eli ensin tehdään erillisiä raportointitauluja tai muistinvaraisia tauluja OLTP-kantaan. Sitten kun tämä ei enää riitä, aletaan replikoida reaaliaikaisesti dataa kantakopioon, joka on tarkoitettu vain kyselykäyttöön. Kaikki tämä johtaa kuitenkiin hitaaseen, kompleksiseen, virhealttiiseen ja siiloutuneeseen raportointiin. Viimeistään tässä vaiheessa onkin järkevää mallintaa erillinen datamart tai konsernitietovarasto (EDW), joka on tietomalliltaan optimoitu suurien tietomäärien pitkäkestoiseen varastointiin ja suoraviivaiseen raportointiin. Tietovarastomallinnuksen menetelmistä ja parhaista käytännöistä kerron lisää tulevissa blogipostauksissani. 

Tietokannan normalisointi 

Tietokannan normalisointi on systemaattinen metodi, joka tähtää maksimaaliseen tiedon saatavuuteen ja tallennuksen eheyteen. Metodia seuraamalla voidaan kehittää tehokkaita operatiivisia tietokantoja. Normalisoinnin ideana on asteittain pienentää tiedon toisteisuutta eli redundanssia sekä parantaa tietomallin eheyttä. Nyrkkisääntönä voidaan pitää, että: 

• Kukin tieto on esitetty vain yhdessä paikassa 

• Relaatiossa voi esiintyä vain siihen kuuluvaa dataa 
• Päivitys kohdistuu vain yhteen paikkaan kerrallaan 

Normalisointi tarkoittaa käytännössä tietokantataulujen (=oliot ja niiden ominaisuudet sekä relaatiot) järjestämistä tietyllä tavalla. Tauluja voidaan tarpeen mukaan luoda uusia ja niiden välillä voidaan siirtää attribuutteja. Alkuperäisenä normaalimuotojen kehittäjänä tunnetaan herra nimeltään Edgar F. Codd. 

Ensimmäinen normaalimuoto (1NF) 

Ensimmäinen normaalimuoto esittää, että tietokannan jokaisen sarakkeen arvot ovat atomisia. Normalisointi toteutuu pilkkomalla moniarvoiset attribuutit omiin tauluihinsa. Otetaan hauska esimerkki. Meillä on viulisteja, jotka omistavat on kukin yhdestä moneen stradivariusta: 

Tämä tulisi jakaa kahteen erilliseen tauluun:  

• Muusikoiden tiedot 
• Stradivariukset 

Toinen normaalimuoto (2NF) 

Määritelmän mukaisesti; toinen normaalimuoto kieltää muiden kuin avainattribuuttien ei-triviaalit toiminnalliset riippuvuudet avainehdokkaan osaan.  

• Jos jokaisen taulun avain koostuu vain yhdestä attribuutista, tietokanta on toisen normaalimuodon mukainen. 
• Jos kantaan kuuluu tauluja, joiden avainkandidaatti koostuu useasta eri attribuutista (=komposiittiavain), ei mikään attribuutti, joka ei ole avain, saa olla osittain toiminnnallisesti riippuva mistään avainehdokkaasta. 
• Jos attribuutti on riippuvainen koko avaimesta, eikä pelkästään osa-avaimesta, se saa sijaita taulussa toisen normaalimuodon mukaan. 

Esimerkki. Stradivarius -taulussa on komposiittiavain eli ehdokasavain (Stradivarius, valmistusmaa). Taulu ei siis ole 2NF-muodossa: 

Kaikki kentät, jotka eivät ole riippuvaisia komposiittiavaimesta (pituus, paino), riippuvat Stradivarius-kentästä, mutta ainoastaan hinta riippuu myös valmistusmaasta. Tämä taulu voidaan muuttaa toiseen normaalimuotoon tekemällä Stradivariuksesta ehdokasavain, jotta jokainen ei-ehdokasavainmäärite riippuu koko ehdokasavaimesta, sekä poistamalla hinta erilliseen taulukkoon, jotta sen riippuvuus Valmistusmaasta voidaan säilyttää: 

Kolmas normaalimuoto (3NF) 

Kolmas normaalimuoto kieltää nbiiltä attribuuteilta, jotka eivät ole avaimia, “ei-triviaalit funktionaaliset riippuvuudet” muihin kuin avainehdokkaiden ylijoukkoon (=superset). Esimerkkitapauksessamme; Stradivarius-taululla on edelleen ei-triviaali funktionaalinen riippuvuus (väri on riippuvainen Stradivariuksesta). Siksi skeema ei ole 3NF:ssä, joten ei-triviaalit funktionaaliset riippuvuudet poistetaan sijoittamalla väri omaan tauluunsa sekä valmistusmaa omaan tauluunsa, johon viitataan hinnastotaulusta, ja lopuksi vielä lisätään puuttunut relaatio Viulistin ja Stradivariuksen väliltä: 

Yhteenveto

Normaalimuotoja on kaikkiaan 6NF saakka. Kuitenkin OLTP-mallintamisessa harvoin tarvitaan edes neljättä normaalimuotoa.  

Tarvitseeko organisaatiosi apua OLTP-tietokannan mallintamisessa? Ota yhteyttä allekirjoittaneeseen niin jutellaan lisää! 

Jani K. Savolainen 
jani.savolainen@dbproservices.fi 
0440353637 
CEO & Chairman 
DB Pro Services Oy

Tämä postaus aloittaa blogisarjani tietomallinnuksesta.

Tietomallinnus, eli tietomallintaminen on tärkein yksittäinen vaihe reaaliaikaisen (OLTP) tietojärjestelmän tai tietovaraston (DW, Datamart) toteutuksessa. Tämän tehtävän suorittaa tyypillisesti asiaan vihkiytynyt tietomallintaja. Tietomallinnus kuvataan usein kaksivaiheisena prosessina: Sen ensisijaisena tarkoituksena on luoda ylätasolla yhteinen käsitekartta liiketoiminnan, tietokantaosaajien (data-arkkitehti, DBA), datainsinöörien (Data Engineer) sekä data-analyytikoiden (Data Analyst) välille. Tällöin puhutaan käsiteanalyysistä. Kun käsiteanalyysi on valmis, valitaan skenaarioon parhaiten sopiva tietomallinnusmetodi ja suunnitellaan ns. fyysinen tietomalli. Fyysisen tietomallin pohjalta voidaan sitten toteuttaa varsinainen tietokanta. Fyysisiä tietomalleja ovat mm.

• OLTP- eli relaatiomalli (3NF)
• Star Schema (tähtimalli)
• Snowflake Schema (lumihiutalemalli)
• Conformed Data Warehouse BUS
• Data Vault

Fyysisen tietomallin tehtävänä on palvella liiketoiminnan tarpeita mahdollisimman tehokkaasti. Hyvä fyysinen tietomalli ottaa liiketoimintatarpeiden lisäksi huomioon mm. seuraavat seikat:

• Tietokantaratkaisun suorituskyky sekä skaalautuvuus käyttöskenaarion mukaan
• Tietomallin ymmärrettävyys
• Tietomallin ylläpidettävyys sekä:
• Tietomallin helppokäyttöisyys tietokantakyselyiden laatimisessa

Usein tietomallinnuksessa tehdään sellainen virhe, että käsiteanalyysin sijaan lähdetään kuvaamaan suoraan tietokannan fyysistä tietomallia, joka johtaa mm. siihen, että DBA tuo turhaan monimutkaisia teknisiä yksityiskohtia liiketoiminnan pohdittavaksi. Lisäksi tuollaisessa lähestymistavassa on merkittävä vaara, että liiketoiminta tulee tähän fyysiseen tietomalliin väärinkuvatuksi ja sitä kautta fyysisen datamallin refaktorointikustannukset voivat olla dramaattiset, etenkin jos ollaan jo tuotannossa. Vaikka jotkin fyysiset tietomallit kuten Data Vault 2.0 ja suoraviivaisesti toteutettu Star schema (full load), antavatkin paremmin anteeksi mahdollisia ”suunnittelukukkasia”. Tämän takia tietomallintamiseen kannattaa suhtautuakin iteratiivisena prosessina, jossa tietomallia hiotaan asteittain, kunnes lopputulos vastaa tarkasti liiketoimintaa. Lisäksi on hyvä tiedostaa, että hyväkään fyysinen tietomalli ei millään tavoin korvaa kyvykkään DBA:n osuutta tietokannan suorituskyvyllisten ominaisuuksien maksimoimisessa, vaan ainoastaan antaa siihen ainoastaan parhaan mahdollisen pohjan. Jos verrattaisiin datahanketta talonrakentamiseen, voitaisiinkin ajatella, että tietomallintaminen on eräänlaista arkkitehtityötä ja tietokannan fyysinen koodaaminen insinöörityötä.

Ylätason käsiteanalyysi

Tietomallinnuksessa olennaisia ovat oliot, olioiden ominaisuudet sekä olioiden väliset suhteet eli relaatiot. Reaalimaailmassa voidaan kuvata miltei mikä tahansa kokonaisuus mielekkäästi ja ymmärrettävästi nk. käsitemallin avulla. Reaalimaailmassa olioita ovat ne asiat, joilla voi olla useita ominaisuuksia eli attribuutteja. Yksittäinen olio voi sitten joko liittyä tai olla liittymättä toisiin olioihin. Tätä suhdetta olioiden välillä kutsutaan relaatioksi.

Ohessa yksinkertaistettu esimerkki koulumaailmasta, jossa mallinnetaan lukion oppilastietojärjestelmää:

Olioita ovat:

• Opettaja
• Oppilas
• Oppiaine
• Kurssi

Ominaisuudet jakautuvat olioittain:

Opettajan ominaisuuksia ovat esimerkiksi:

• Etunimi
• Sukunimi
• Syntymäaika
• Opettajanumero (numero, joka identifioi oppilaan tietojärjestelmässä)

Oppilaan ominaisuuksia ovat esimerkiksi:

• Etunimi
• Sukunimi
• Syntymäaika
• Oppilasnumero (numero, joka identifioi oppilaan tietojärjestelmässä)

Oppiaineen ominaisuuksia ovat esimerkiksi.

• Nimi (Englanti, Matematiikka, Psykologia jne.)
• Kategoria (Kielet, Luonnontieteet, Kasvatustieteet jne.)

Kurssin ominaisuuksia ovat esimerkiksi:

• Nimi (Englannin preppauskurssi abeille, Tilastotieteen perusteet, Johdanto psykologiaan)
• Kesto (Kurssin kesto opintoviikkoina)
• Alkupvm (Esim. 1.4.2023)
• Loppupvm (Esim. 30.5. 2023)

Relaatio siis kuvaa olioiden välistä suhdetta. Relaatioita voi olla erilaisia. Niitä kuvataan käsitteillä ”nolla”, ”yksi” tai ”monta”. Esimerkiksi:

• Opettajalla voi olla ”yhdestä moneen” kurssia opetettavanaan
• Kurssi voi liittyä vain ”yhteen” (=tiettyyn) oppiaineeseen
• Oppilaalla voi olla ”nollasta moneen” kurssia valittuna (kun oppilas aloittaa kurssien valitsemisen niitä ei ole yhtään valittuna)

Tästä voidaan edelleen olemassa olevien sääntöjen varassa päätellä että:

• Opettajalla voi olla ”yhdestä moneen” oppiainetta (joku oppiaine on oltava ja jotkut opettaja hallitsevat useammankin oppiaineen)
• Opettajalla voi olla ”nollasta moneen” oppilasta tietyssä kurssissa (joskus oppilaat eivät valitse tiettyä kurssia ollenkaan)
• Oppilaalla voi olla ”yhdestä moneen” oppiainetta valittuna (pakko olla ainakin yksi oppiaine)

Käsiteanalyysissä muodostuvaa tietomallia voidaan ylätasolla kuvata yksinkertaisimmillaan näin:

Ylätason käsiteanalyysissä on keskeistä kuvata myös olioiden ja attribuuttien synonyymit, kuten liiketoiminnallisten käsitteiden suhde teknisempiin ja ”slangiutuneisiin” termeihin.

Kiinnostuitko aiheesta? Onko organisaatiossasi ehkä käynnistymässä tietojärjestelmähanke, johon tarvitset tietomallintamisen ammattilaisen apua? Ole hyvä ja ota meihin yhteyttä, ehkä voimme olla avuksi!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

CEO & Chairman

DB Pro Services Oy