Puhuttaessa modernista tietovarastoinnista ja sen arkkitehtuureista ei voi olla törmäämättä erilaisten tietojärvien ja tietovarastojen käsitteisiin. Tässä blogikirjoituksessa käsitellään tietoalustojen evoluutiota perinteisestä tietoalustasta ja tietovarastoinnista kohti Lakehouse-tietoarkkitehtuuria, erityisesti tarkastellen Lakehousea ja sen mahdollistavaa Delta Lakea -teknologiaa.   

Kuvataan Lakehouse- ja Mitaliarkkitehtuuri Microsoftin Fabric SaaS-palvelun ratkaisuna. Microsoft Fabric on kattava analytiikan ja tietovarastoinnin ratkaisu, joka sisältää tärkeimmät modernit työkalut tietojenkäsittelyyn, tallentamiseen ja analysointiin reaaliajassa.

Miksi Lakehouse ja Delta Lake

Perinteiset tietoalustat ja tietovarastot ovat keskeisessä roolissa organisaatioiden datanhallinnassa. Kuitenkin teknologisen kehityksen myötä tarve entistä joustavammille ja monipuolisemmille ratkaisuille on kasvanut. Tässä evoluutiossa Lakehouse edustaa innovatiivista askelta, joka yhdistää perinteisen tietovaraston (Data Warehouse) luotettavuuden ja rakenteisen datan käsittelyn tietojärven (Data Lake) joustavuuteen ja monimuotoisuuteen erilaisten tietojen hallinnassa ja käsittelyssä.

Delta Lake puolestaan on avainasemassa tämän kehityksen toteuttamisessa, tarjoten avoimen lähdekoodin tallennuskerroksen, joka tuo ACID-transaktiot (Atomicity, Consistency, Isolation, and Durability), metadatan hallinnan ja luotettavuuden tietojärven ympäristöön. Delta Lake -teknologia antaa tiedon varastoinnille joustavuutta  ja tehokkuutta. Lakehouse-tietoarkkitehtuurin, erityisesti Delta Laken, merkitys korostuu jatkossakin datavetoisten yritysten keskuudessa.

Tietovarastot ja tietojärvet ovat vakiintuneita tietoalustoja, joita käytetään yhdessä tai erikseen riippuen datan volyymista ja käyttötarkoituksista. Molemmilla on vahvuutensa ja haasteensa, ja seuraavassa käsitellään näitä näkökohtia sekä pohditaan, miksi Lakehouse-tietoarkkitehtuuri on luonnollinen kehitysaskel tietovarastoratkaisuna.

Perinteisen ja modernin tietoalustan haasteita jotka Lakehouse pyrkii ratkomaan

Perinteiset tietovarastot mahdollistavat historiallisten datajoukkojen järjestämisen analytiikan ja Business Intelligencen (BI) tarpeisiin. Datamäärien kasvaessa perinteiset tietovarastot voivat muuttua kustannustehottomiksi laskentaresurssien ja tallennustilan yhdistetyn käytön vuoksi. Lisäksi ne eivät sovellu optimaalisesti reaaliaikaisen suoratoistodatan käsittelyyn, ja eräajoprosessit voivat olla haasteellisia sopeutumaan nopeasti muuttuviin datavirtoihin. Rakenteellisen datan (Structured) hallinta on perinteisen tietovaraston vahvuus, mutta ne kohtaavat vaikeuksia puolirakenteellisen (Semi-structured) ja rakenteettoman (Unstructured) datan käsittelyssä.

Perinteisen tietovaraston haasteiden monimutkaisuuden ratkaisemiseksi rinnalle on otettu käyttöön tietojärviä. Tietojärvet tarjoavat alhaisen tallennuskustannuksen ja kyvyn käsitellä dataa eri formaateissa. Niiden monipuolisuus tekee niistä sovellettavia eri käyttötarkoituksiin, kuten edistyneeseen analytiikkaan ja koneoppimiseen.

Yksinkertaistettuna modernissa pilvipohjaisessa tietoalustaratkaisussa rakenteellinen data luetaan tietovarastoon ja sen rinnalla toimii tietojärvi puolirakenteellisen ja rakenteettoman datan säilömiseen. Tietojärveä voidaan käyttää myös datan syöttökerroksena tietovarastolle.

Tietojärvillä on kuitenkin myös rajoituksensa. Tiedostomuodossa tallentaminen ilman määriteltyä rakennetta tekee kriittisen tietojenhallinnan vaikeaksi, mikä vaikeuttaa ETL-transaktioiden suorittamista ja johtaa haasteisiin datan eheyden ja yhdenmukaisuuden hallinnassa. Delta Lake ja Lakehouse-tietoarkkitehtuuri pyrkivät ratkomaan yllä mainittuja haasteita.

Alla oleva kuva kuvaa evoluutiota perinteisestä tietoalustasta moderniin pilvipohjaiseen tietoalustaan ja siitä aina Lakehouse-tietoarkkitehtuuriin. Katsotaan seuraavassa kappaleessa tarkemmin Delta Lakea ja Lakehouse-tietoarkkitehtuuria.

Delta Lake Lakehouse-tietoarkkitehtuurin mahdollistaja

Delta Lake mahdollistaa Lakehouse-tietoarkkitehtuurin käyttöönoton tarjoamalla vahvan perustan tiedon tallennuskerroksena. Lakehouse-tietoarkkitehtuuri taas pyrkii jatkuvaan ja yksinkertaistettuun tapaan järjestää tietoa hyödyntäen Delta Laken tuomia etuja.

Yhdellä tietoalustalla toimiminen poistaa siiloja ja yksinkertaistaa prosesseja. Data tallennetaan Delta Lakeen delta-formaatissa parquet-tiedostoiksi. Tämä pienentää datan varastoinnin kustannuksia ja parantaa kyselysuorituskykyä. Tehokkaan datan varastoinnin ja nopean kyselysuorituskykynsä ansiosta Delta Lake tukee erinomaisesti suoratoisto ja eräajoprosessointia, mikä tekee siitä monipuolisen ratkaisun erilaisten tietokäsittelytarpeiden täyttämiseksi.

Lisäksi Delta Lake käyttää JSON-metadatatiedostoja, jotka sisältävät tiedot tauluista, tiedostojen sijainneista ja määritellyistä rakenteista. JSON-metadatat mahdollistavat tietojen hallinnan ja käsittelyn, mikä on keskeistä tietoalustan tehokkaassa toiminnassa. Metadata mahdollistaa aikamatkustamisen (time travel). Aikamatkustuksen avulla voi palauttaa tietyn hetken tilanteen aiempiin versioihin, eli tiettyyn ajanhetkeen, ja tämä kyky perustuu tarkkaan metadatatiedostojen hallintaan. Aikamatkustamisessa on rajoituksensa: se rajoittuu niihin versioihin, jotka on tallennettu Delta Lakeen, ja määrityksiin historiatietojen säilytysajoista.

Lakehouse-tietoarkkitehtuuri Microsoft Fabric

Mitaliarkkitehtuuri – Kuinka Organisoida Data Lakehousessa?

Käydään läpi Lakehouse-tietoarkkitehtuuria tarkemmin Microsoftin Fabric SaaS-palvelun ratkaisuna. Esimerkin avulla saamme käytännönläheisemmän kuvan.  Alla olevaan kuvaan olen piirtänyt yksinkertaistetun Lakehouse-ratkaisun, jossa tietoalustaan luetaan useasta eri tietolähteestä tai lähdejärjestelmästä tietoa, joko reaaliajassa tai eräajoin eli tiettyinä ennakkoon määriteltyinä hetkinä.

Data luetaan tietoalustaan integraatiotyökalulla, tässä tapauksessa Azure Data Factory, joko suoraan tai hyödyntäen väliaikaista laskeutumisalustaa (valinnainen, ei kuvattu ratkaisussa), ja tallennetaan Lakehouseen. Fabric mahdollistaa myös olemassa olevien tietojärvien nopean hyödyntämisen shortcut-toiminnolla. Fabricissa tiedot tallennetaan parquet-tiedostomuodossa One Lake -tietoalustaan riippumatta siitä, onko kyseessä Lakehouse vai Warehouse -tietovarasto. One Lake perustuu Delta Lake -teknologiaan. Olipa kyseessä T-SQL-datavarastointi, Spark tai KQL-suoratoisto, jokainen Fabricin työkuorma toimii delta-taulukoiden kanssa.

Lakehouse-tietoarkkitehtuuri rakennetaan usein Databricksin kehittämää mitaliarkkitehtuuria hyödyntäen. Mitaliarkkitehtuurissa ja kuvan esimerkissä on kolme kerrosta tiedon säilyttämiseen, muokkaamiseen, prosessointiin ja jakamiseen. Esimerkkiarkkitehtuurissa hyödynnetään muistikirjoja (Notebook) tiedon muokkaamiseen, rikastamiseen ja siirtämiseen kerrokselta toiselle. Muistikirjat voidaan ajastaa ja orkestroida Azure Data Factoryn putkilla (Pipeline). Muistikirjojen ajastamiseen ja ajamiseen voidaan hyödyntää myös muita tekniikoita.

Mitaliarkkitehtuurin tavoite on organisoida dataa loogisesti Lakehousen sisällä eri kerrosten välillä. Kerrokset on nimetty mitalien mukaan pronssi, hopea ja kulta. Mitalin kirkkaampi väri viittaa datan laatuun eli tavoitteena on prosessoida, yhdistää ja parantaa datanlaatua kerroksittain aina loppukäyttäjälle asti. On hyvä tunnistaa, että mitaliarkkitehtuurin kolmekerroksinen tietovarastointimetodi on hyvin samankaltainen perinteisempien source, staging ja curated ratkaisujen kanssa.

Mitaliarkkitehtuurin etuja ovat:  

  • Yksinkertainen ja looginen rakenne.
  • Mahdollistaa inkrementaalisen kehittämisen.
  • Tukee erilaisia työmääriä ja soveltuu erilaisiin käyttötarkoituksiin.
  • Hopeakerros voidaan toteuttaa erilaisilla tietomalleilla tarpeen mukaan, kuten esimerkiksi Data Vault tai malleilla, jotka ovat lähellä kolmannen normaalimuodon rakennetta.
  • Arkkitehtuuri tukee joustavuutta analytiikassa ja datankäsittelyssä. Data tieteilijät ja analyytikot voivat työskennellä viimeisimpien saatavilla olevien tietojen kanssa ja edistää nopeampaa päätöksentekoa ja analytiikkaa.
  • Mitaliarkkitehtuurin modulaarinen luonne edistää yhteensopivuutta eri komponenttien ja järjestelmien välillä. Tämä on erityisen arvokasta heterogeenisissä dataympäristöissä, joissa käytetään erilaisia työkaluja ja alustoja.
  • Taulukkojen uudelleen rakentaminen raakatiedoista milloin tahansa.
  • ACID-tapahtumat ja Time Travel -toiminnallisuudet

Mitaliarkkitehtuurin kerrosten tehtävät:

  • Pronssikerros (Bronze)
    • Yleisesti pronssikerrokseen tiedot tallennetaan raakamuodossa eli kopiona lähdejärjestelmästä ilman muuntoja:
      • Pronssikerroksessa dataa ei muunneta alkuperäisestä muodostaan, jotta alkuperäinen tieto säilyy ja on saatavilla sellaisenaan tulevia tarpeita varten.
    • Data on pronssikerroksessa vain lukumuodossa:
      • Dataa voidaan lukea ja käyttää, mutta siihen ei tehdä muutoksia.
    • Tietoja voidaan säilöä eri tietomuodoissa, esimerkiksi erilaisina tiedostoina (Parquet, JSON tai CSV) tai delta-tauluina:
      • Pronssikerroksessa tarjotaan joustavuutta tallennettavan datan muodossa. Se voi sisältää eri tietomuotoja, mikä mahdollistaa erilaisten tietojen tehokkaan käsittelyn.
    • Pronssikerroksen data voidaan syöttää kokonaisuudessaan aina uudelleen lähdejärjestelmästä (Full load) tai lisätä ainoastaan muuttuneet tiedot olemassa olevan datan jatkoksi inkrementaalisesti (Delta load).
    • Sallii lähteeksi transaktiopohjaisen tai reaaliaikaisen prosessoinnin:
      • Pronssikerros tarjoaa joustavuutta datan keräämisessä, ja se voi käsitellä tietoa sekä transaktiopohjaisesti että reaaliaikaisesti lähteen luonteesta riippuen.

  • Hopeakerros (Silver)
    • Pääasiallinen tiedonsäilytyskerros:
      • Hopeakerros toimii pääsäilytysalueena, jossa dataa pidetään ensisijaisesti lähdejärjestelmästä tuotuna. Tämä varmistaa, että alkuperäinen data säilyy turvallisesti ja eheänä.
    • Järjestetään, siivotaan ja yhdistetään pronssikerroksen data yhtenäiseen tietomalliin:
      • Hopeakerroksessa toteutetaan toimet, kuten tietojen järjestely, puhdistaminen ja yhdistäminen yhtenäiseen rakenteeseen. Näin varmistetaan, että data on valmiina siirrettäväksi seuraavaan kehitysvaiheeseen.
    • Luodaan historiointikäytännöt ja historioidaan dataa:
      • Hopeakerroksessa implementoidaan historiointikäytännöt, jotka mahdollistavat datan historian seuraamisen ajan myötä. Tämä tarjoaa kattavan näkymän datan kehityksestä ja muutoksista.
    • Yhtenäistetään tietomuoto:
      • Microsoft Fabric tallentaa datan yhtenäisessä muodossa parquet-tiedostoformaatissa One Lake -tietoalustaan. Tämä varmistaa, että dataa voidaan käsitellä yhdenmukaisesti ja tehokkaasti.

  • Kultakerros (Gold)
    • Data on järjestetty valmiiksi ja käytettävissä raportoinnille ja loppukäyttäjille:
      • Kultakerros tarjoaa valmiiksi järjestetyn datan, joka on helposti käytettävissä raportoinnissa ja loppukäyttäjien tarpeisiin. Tämä edistää nopeaa ja tehokasta päätöksentekoa.
    • Data mallinnetaan yleensä tähtimalliin faktoiksi ja dimensioiksi:
      • Kultakerroksessa suoritetaan tietomallinnus, yleensä tähtimalliin, jotta data voidaan tehokkaasti kuvata faktoiksi ja dimensioiksi. Tämä parantaa tiedon käsiteltävyyttä ja ymmärrettävyyttä.
    • Voidaan organisoida projektikohtaisiin tai liiketoimintakohtaisiin kokonaisuuksiin:
      • Kultakerroksessa dataa voidaan organisoitua projektikohtaisesti tai liiketoimintakohtaisesti tarpeiden mukaan. Tämä mahdollistaa joustavan käytön eri liiketoiminta-alueilla.
    • Sovelletaan liiketoimintasääntöjä ja tehdään monimutkaisia transformaatioita sekä laskentaa:
      • Kultakerroksessa toteutetaan liiketoimintasääntöjä ja suoritetaan monimutkaisia transformaatioita ja laskentaa. Tämä varmistaa, että data vastaa tarkasti liiketoiminnan tarpeita.
    • Kokonaisuus edustaa datatuotetta:
      • Kultakerroksen lopputulos muodostaa laadukkaan datatuotteen, joka vastaa liiketoiminnan tarpeisiin. Datatuote tarjoaa vahvan perustan tehokkaalle päätöksenteolle ja liiketoiminnan kehittämiselle.

Mitaliarkkitehtuurin kultakerros on hyödynnettävissä raportoinnille. Data on jalostettu valmiiksi ja hyödynnettävissä liiketoiminta-alueittain kokonaisuuksina tai osina. Power BI mahdollistaa datan visualisoinnin ja mahdollisten uusien mittareiden luomisen kultakerroksen datasta.

Kultakerrosta voidaan hyödyntää myös Data Science ja AI pohjaisten ratkaisujen rakentamiseen. Data Science ja AI ratkaisut käyttävät usein mallien kouluttamiseen dataa mahdollisimman läheltä lähdettä joten Lakehouse-tietoarkkitehtuuri mahdollistaa datan hyödyntämisen Data Science ja AI ratkaisuihin myös pronssi- ja hopeakerroksesta, joskin pronssikerrosta hyödyntäessä datan laatu saattaa olla riittämätön.

Yhteenveto

Lakehouse-tietoarkkitehtuuri luo tehokkaan skaalautuvan tietoalustan, jossa tietoa järjestetään ja muokataan asteittain kerrosten välillä. Lakehouse soveltuu erinomaisesti edistyneelle analytiikalle ja vaativille hybridiratkaisuille, joissa tietoa luetaan eri lähteistä, joko reaaliajassa tai eräajoin.

On hyvä huomioida, että modernit ratkaisut, kuten Microsoft Fabricin Delta Lake-pohjaisen yhtenäisen tiedonvarastoinnin (One Lake) menetelmien avulla mahdollistetaan Lakehouse ja Warehouse ratkaisujen sujuva yhteensopivuus. Tämä taas antaa lähes rajattomat mahdollisuudet luoda hybridiratkaisuja, jotka vastaavat monimutkaisiin liiketoiminta- ja teknisiin vaatimuksiin.

Perinteisille ratkaisulle on yhä paikkansa erilaisissa käyttötapauksissa. Aina pilvimigraatioissa ja tietovarastoinnin uudistushankkeissa on tärkeää tehdä kattava analyysi eri vaihtoehdoista uudeksi tietoalustaksi ja datastrategiasta.

Liikkeelle Datastrategiasta Tietoalusta-ratkaisua valittaessa

Tietoalustan arkkitehtuuria valittaessa tulee aina tehdä tarkat strategiset linjaukset:

  • Käyttötapausanalyysi
    • Mihin kerättävää dataa käytetään ja hyödynnetään.
    • Data ja liiketoimintastrategian yhtenäisyys.
  • Missä muodossa ja mistä lähdedata on saatavissa
    • Rakenteellinen, puolirakenteellinen ja ei-rakenteellinen data.
    • Reaaliaikainen vai eräajo.
    • Sisäinen vai ulkoinen data.
    • Minkälaisia integraatioita tarvitaan.
  • Millä syklillä dataa tietoalustaan tallennetaan.
  • Arkkitehtuuri, työkalut ja komponentit
  • Tiedonhallinta.
  • Tietoturva ja käyttäjähallinta.

Me DB Pro Servicellä teemme kattavia datastrategiakonsultaatioita. Voit lukea tarkemmin datastrategiasta blogeissamme: Kuinka määritellä datastrategian suunta 

DB Pro Services tarjoaa kattavia ratkaisuja ja asiantuntijapalveluita tekoälyn käyttöönottoon liittyviin haasteisiin. Tarjontamme kattaa muun muassa datastrategian, modernien data-alustojen sekä edistyneen analytiikan kokonaisuudet. Ota yhteyttä, niin autamme sinua ja organisaatiotasi hyödyntämään tietoa tehokkaasti ja menestymään kilpailussa!

Robin Aro

Lead Data Engineer

robin.aro@dbproservices.fiDB Pro Services Oy

Johdanto

Tietoon perustuva päätöksenteko on nykypäivän liiketoiminnassa yhä tärkeämpää. Se auttaa yrityksiä tekemään parempia päätöksiä, optimoimaan toimintaa ja saavuttamaan kilpailuetua. Tiedon jalostamisen peruspilareina toimivat tietovarastointi ja raportointi. Tässä blogikirjoituksessa käsitellään näitä kahta keskeistä osa-aluetta ja selitetään, miksi ne ovat niin tärkeitä liiketoiminnalle.

Mitä on tietovarastointi?

Tietovarastointi tarkoittaa yläkäsitteenä prosessia, jossa yrityksen eri toiminnoista kerätty data tallennetaan keskitettyyn paikkaan yhtenäistetysti. Tämä tietovarasto on suunniteltu niin, että dataa on helppo käsitellä, jakaa ja tutkia erilaisten raporttien ja analyysien muodossa. Tietovarastoinnilla ei tarkoiteta pelkästään datan säilyttämistä, vaan se kattaa myös muita datan elinkaareen kuuluvia asioita. Tietovarasto parantaa operatiivisten järjestelmien suorituskykyä ja saatavuutta, koska raportointia ei tarvitse tehdä enää niiden päältä, vaan raportoinnin työkuormat ohjataan kulkemaan tietovaraston kautta. Myös raporttien teko tietovarastosta on helpompaa kuin vastaavan tiedon onkiminen operatiivisista järjestelmistä. Käydään seuraavaksi läpi laadukkaan tietovarastoinnin ominaisuuksia.

Tietoturva

Datan turvallisuus on erityisen tärkeää nykypäivän digitaalisessa ympäristössä, jossa tietomurrot ja -vuodot ovat yleistyneet. Laadukkaat tietovarastot ovat suunniteltu noudattamaan tietoturvan parhaita käytäntöjä, kuten laadukkaan salauksen ja pääsynhallinnan. Monet tietovarastot hyödyntävät monitasoista autentikointia (MFA) ja roolipohjaista pääsynhallintaa varmistaakseen, että vain oikeutetut henkilöt pääsevät käsiksi arkaluontoiseen tietoon. Lisäksi ne voivat sisältää erilaisia valvontamekanismeja, jotka ilmoittavat epäilyttävästä toiminnasta, jotta mahdollisiin tietoturvariskeihin voidaan puuttua välittömästi.

Tietoturva ei ole vain tekninen vaatimus, vaan myös liiketoiminnallinen tarve. Se on olennainen osa yrityksen mainetta ja luottamusta, ja sen laiminlyönti voi johtaa paitsi taloudellisiin tappioihin, myös vahinkoon yrityksen brändille.

Lähdeintegraatiot

Lähdeintegraatiolla tarkoitetaan tietovarastoinnin prosessia, jossa eri datalähteistä kerätty tieto yhdistetään yhteen keskitettyyn tietovarastoon. Tämä ei ole pelkästään datan siirtämistä paikasta toiseen, vaan se sisältää usein myös datan muuntamista, puhdistamista ja rikastamista, jotta se on sisällöltään eheää ja yhdenmukaista, ymmärrettävässä muodossa raportointia ja analytiikkaa varten, sekä yhteismitallista muiden lähteiden kanssa.

Laadunhallinta

Datan laadunhallinta on olennainen osa tietovarastoinnin prosessia. Huonolaatuinen tai virheellinen data voi johtaa väärään analyysiin ja päätöksentekoon, mikä voi olla kallista yritykselle. Siksi tietovarastointiin sisältyy useita vaiheita datan laadun varmistamiseksi. Esimerkiksi datan puhdistaminen tarkoittaa virheellisen tai puuttuvan tiedon korjaamista, normalisointi puolestaan tarkoittaa datan muuttamista yhteensopivaan ja vertailukelpoiseen muotoon. Validointi taas on prosessi, jossa varmistetaan, että data on luotettavaa ja täyttää ennalta määritellyt laatuvaatimukset.

Nämä toimenpiteet eivät ole yksittäisiä tehtäviä, vaan ne ovat osa jatkuvaa laadunhallintaprosessia, joka alkaa datan keräämisestä ja jatkuu läpi koko sen elinkaaren. Tämä takaa tietovarastosta saadun tiedon olevan aina mahdollisimman tarkkaa, ajantasaista ja luotettavaa, mikä on välttämätöntä tehokkaalle päätöksenteolle.

Saatavuus

Laadukaskaan tieto ei tuota lisäarvoa, mikäli se ei ole kenenkään saatavilla. Datan saatavuus on kriittinen tekijä tietovarastoinnin onnistumisessa ja vaikuttaa suoraan yrityksen kykyyn tehdä informoituja päätöksiä. Laadukas tietovarasto on suunniteltu niin, että se mahdollistaa datan helpon ja nopean jakamisen eri osastojen, tiimien ja jopa ulkoisten sidosryhmien, kuten asiakkaiden tai kumppaneiden, kesken. Tämä poistaa pullonkauloja ja tehostaa päätöksentekoprosessia.

Nykyteknologian ansiosta tietovarastot tarjoavat dataa reaaliaikaisesti ja eri laitteille – mukaan lukien mobiililaitteet. Tämä mahdollistaa joustavuuden ja liikkuvuuden, mikä on erityisen tärkeää etätyöympäristöissä ja globaaleissa organisaatioissa.

Lisäksi hyvin suunniteltu tietovarasto tukee erilaisia käyttöoikeusasetuksia, jolloin voidaan varmistaa, että henkilöt pääsevät käsiksi vain heille relevanttiin tietoon. Tämä ei ainoastaan paranna tietoturvaa, vaan myös tekee datan hyödyntämisestä tehokkaampaa, kun jokainen tiimi tai osasto voi keskittyä juuri siihen dataan, joka on heille olennaista.

Arkistointi ja varmuuskopiointi

Datan pitkäaikainen säilyttäminen ja varmuuskopiointi ovat keskeisiä tietovarastoinnin elementtejä, jotka toimivat yrityksen datan turvaverkkona. Ne eivät ainoastaan suojaa arvokasta dataa, vaan myös mahdollistavat sen palauttamisen odottamattomissa tilanteissa, kuten tietojärjestelmäongelmissa. Tämä sisältää säännölliset varmuuskopiot ja datan elinkaaren hallinnan kattaen myös arkistoinnin ja versionhallinnan. Nämä toimet yhdessä varmistavat datan eheyden ja saatavuuden – myös kriisitilanteissa.

Mitä on raportointi?

Raportointi on keskeinen osa yrityksen tiedonhallintaa ja päätöksentekoprosessia, joka linkittyy vahvasti tietovarastointiin. Se tarkoittaa prosessia, jossa kerätty ja tietovarastossa säilytetty data muunnetaan merkitykselliseksi tiedoksi erilaisten raporttien ja analyysien avulla. Raportit voivat olla monimuotoisia, kattaen kaiken yksinkertaisista myyntitilastoista aina johdon mittaristoihin, monimutkaisiin ennakoiviin analyyseihin ja algoritmeihin, jotka ennustavat yrityksen tulevaisuuden suuntaviivoja. Käydään seuraavaksi läpi raportoinnin keskeisimpiä elementtejä.

Laadukas raportointijärjestelmä

Laadukas raportointijärjestelmä on joustava, skaalautuva ja helppokäyttöinen. Se mahdollistaa datan nopean ja tehokkaan analysoinnin, ja sen tulokset ovat helposti jaettavissa eri sidosryhmille. Nykyaikaiset raportointityökalut, kuten Microsoft Power BI, tarjoavat mahdollisuuden reaaliaikaiseen seurantaan, automatisoituun raportointiin ja monipuolisiin visualisointeihin, jotka tiivistävät tiedosta helpommin ymmärrettävää ja hyödynnettävää.

Visualisointi

Raportoinnin yksi keskeisistä elementeistä on datan visualisointi, joka tarkoittaa tiedon esittämistä graafisessa muodossa, kuten kuvaajina ja taulukoina. Hyvä visualisointi auttaa tekemään monimutkaisesta datasta helpommin ymmärrettävää ja saavutettavaa, ja se voi tuoda esiin näkemyksiä, jotka jäisivät helposti huomaamatta pelkästään raakadatan tarkastelussa. Visualisointien esittämisen tulee olla selkeää ja ytimekästä, keskittyen olennaisiin tietoihin ja mahdollistaen nopeat ja informoidut päätökset.

Laadukas visualisointi helpottaa tiedon esittämistä. Huomataan helposti tuotteen 2 poikkeava käytös päivinä 15–20.

Käyttäjäystävällisyys

Raporttien tulee olla helposti saatavilla ja ymmärrettäviä kaikille niille, joille ne on tarkoitettu. Tämä tarkoittaa, että raporttien tulisi olla selkeitä, visuaalisesti houkuttelevia ja helppolukuisia. Nykyaikaiset raportointityökalut mahdollistavat usein interaktiivisen raportoinnin, jossa käyttäjät voivat tutkia dataa itsenäisesti ja porautua yksityiskohtiin tarpeen mukaan.

Reaaliaikaisuus

Yhä useammin raportoinnin odotetaan olevan reaaliaikaista tai lähes reaaliaikaista, jotta päätöksentekijät voivat reagoida nopeasti muuttuviin tilanteisiin ja hyödyntää mahdollisuuksia ajoissa. Reaaliaikainen raportointi voi auttaa organisaatioita pysymään kilpailukykyisinä dynaamisessa liiketoimintaympäristössä, ja se voi tukea proaktiivista, dataohjattua, päätöksentekoa. Tämä edellyttää vahvaa teknologista infrastruktuuria ja kykyä käsitellä ja analysoida suuria datamääriä tehokkaasti ja luotettavasti.

Kuinka tietovarastointi ja raportointi liittyvät toisiinsa?

Tietovarastointi ja raportointi ovat syvästi kytkeytyneitä prosesseja, jotka yhdessä mahdollistavat informaation muuntamisen merkityksellisiksi oivalluksiksi ja päätöksenteon tueksi. Tietovarastointi kattaa datan keräämisen, integroinnin, pitkäaikaisen säilyttämisen sekä hallinnan, ja luo näin vankan perustan, jolle raportointi rakentuu. Raportointi puolestaan keskittyy datan analysointiin, visualisointiin ja jakamiseen. Näin organisaation jäsenille luodaan mahdollisuus ymmärtää ja hyödyntää dataa tehokkaasti.

Kun nämä kaksi elementtiä – tietovarastointi ja raportointi – toimivat saumattomasti yhdessä, mahdollistavat ne yrityksille kyvyn navigoida datavetoisessa maailmassa, tehdä informoituja päätöksiä ja luoda strategioita, jotka ovat linjassa yrityksen tavoitteiden ja markkinatilanteen kanssa. Tämä yhdistelmä on erityisen voimakas, kun se integroidaan osaksi yrityksen kulttuuria ja päätöksentekoprosesseja, mahdollistaen aidosti datavetoisen organisaation.

Esimerkkitapaus: Sirpaloituneesta datasta laadukkaaksi tietovarastoksi

Sirpaloituneen datan ongelma

Yrityksissä dataa syntyy monista eri lähteistä, kuten myynnistä, markkinoinnista, tuotannosta ja asiakaspalvelusta. Tämä data on usein tallennettu erillisiin järjestelmiin, jotka eivät välttämättä ole yhteensopivia keskenään. Tämä johtaa sirpaloituneeseen dataympäristöön, joka tekee tiedon hallinnasta ja analysoinnista haastavaa.

Ratkaisuna keskitetty tietovarastointi

Ensimmäinen askel sirpaloituneen datan kokoamisessa on dataintegraatio. Tässä vaiheessa eri lähteistä tuleva data tuodaan yhteen, keskitettyyn, sijaintiin. Nykyään raakadata tuodaan yleensä pilvessä toimivaan tietoaltaaseen (data lake). Raakadata jatkaa matkaansa tietoaltaasta tietomalliltaan strukturoituun tietovarastoon, josta se on saatavilla eri raportointi- ja analytiikkatyökalujen käyttöön. Etenkin taulukkomuotoisen datan tietovarastona käytetään usein SQL-tietokantoja.

Dataintegraatio ELT-prosessilla

Yksi yleisimmin käytetty menetelmä datan integroimiseksi on ELT-prosessi, joka on lyhenne sanoista Extract, Load ja Transform (kerää, lataa, muunna). ELT:llä tarkoitetaan kolmiosaista prosessia, jossa data ensin kerätään lähdejärjestelmistä, ladataan tietoaltaaseen ja lopulta muokataan yhdenmuotoiseksi tietovarastoon.

Lopputuloksena keskitetty tietovarasto

Lopputuloksena saatu tietovarasto suunnitellaan niin, että sieltä on helppo hakea, käsitellä ja analysoida dataa. Se toimii yrityksen keskeisenä tietopankkina, josta eri osastot ja johdon edustajat voivat helposti saada tarvitsemansa tiedot.

Tämä keskitetty lähestymistapa ratkaisee monia sirpaloituneen datan aiheuttamia ongelmia, kuten tiedon eheyden ja saatavuuden haasteet. Se mahdollistaa myös tehokkaan, konsolidoidun raportoinnin ja analyysin, jotka ovat keskeisiä tiedolla johtamisessa.

Kokonaisuudessaan keskitetty tietovarastointi ei ole vain tekninen toimenpide, vaan strateginen investointi yrityksen tulevaisuuteen. Se luo perustan, jolle voidaan rakentaa tehokas tiedolla johtamisen ekosysteemi.

Lopuksi

Datavetoinen päätöksenteko on enemmän kuin vain numeroiden tuijottamista; se on kokonaisvaltainen lähestymistapa, joka yhdistää tietovarastoinnin ja raportoinnin voiman. Joten, jos haluat tehdä parempia päätöksiä, optimoida toimintaasi ja saada kilpailuetua, on aika panostaa peruspilareihin: tietovarastointiin ja raportointiin.

Tiedolla johtaminen vaatii oikeanlaista osaamista ja työkaluja. Me DB Pro Servicellä ymmärrämme nämä haasteet ja olemme erikoistuneet auttamaan yrityksiä rakentamaan tehokkaita tietovarastointi- ja raportointiratkaisuja. Tarjoamme kattavia palveluita, jotka kattavat koko tiedolla johtamisen elinkaaren – lähtien datan keräämisestä ja integroinnista aina edistyneeseen analytiikkaan ja raportointiin.

Olemme työskennelleet monenlaisten yritysten ja toimialojen parissa, ja meillä on laaja kokemus erilaisten dataympäristöjen hallinnasta. Käytämme alan parhaita käytäntöjä ja uusimpia teknologioita varmistaaksemme, että saat parhaan mahdollisen hyödyn datastasi.

Ota yhteyttä meihin, jos olet kiinnostunut viemään datasi seuraavalle tasolle. Asiantuntijamme ovat valmiita auttamaan sinua löytämään juuri sinun yrityksellesi sopivan ratkaisun. Katsotaan yhdessä, kuinka voimme auttaa sinua saavuttamaan tavoitteesi datan avulla.

DB Pro Services asiantuntijatiimi

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.

Tietomallinnuksen hyödyt

Tietomallinnus on keskeinen vaihe tietokantojen suunnitteluprosessissa, ja sillä on useita hyötyjä. Tietomallinnuksen avulla voidaan varmistaa, että tietokanta on tehokas, joustava ja laajennettavissa tulevaisuuden tarpeisiin. Tässä on joitakin tärkeimpiä hyötyjä, joita tietomallinnuksesta on tietokantojen suunnittelussa:

1. Ymmärryksen parantaminen: Tietomallinnus auttaa suunnittelijoita ja sidosryhmiä ymmärtämään liiketoiminnan prosesseja ja tiedonkäsittelyn vaatimuksia syvällisemmin. Se tarjoaa visuaalisen esityksen tiedon rakenteesta, suhteista ja rajoitteista, mikä helpottaa yhteistä ymmärrystä ja kommunikointia.

2. Tehokkuuden lisääminen: Hyvin suunniteltu tietomalli mahdollistaa tietokannan tehokkaamman käytön, koska se minimoi tarpeettoman datan toistumisen ja optimoi tiedon tallennuksen ja haun.

3. Joustavuus ja laajennettavuus: Kun tietokanta on suunniteltu huolellisesti tietomallinnuksen avulla, sen rakenne on joustavampi ja helpommin mukautettavissa muuttuviin liiketoiminnan tarpeisiin ja teknologisiin vaatimuksiin.

4. Laadun parantaminen: Tietomallinnus auttaa tunnistamaan ja korjaamaan suunnitteluvirheitä varhaisessa vaiheessa, mikä vähentää virheitä ja parantaa tietokannan laatua ja suorituskykyä.

5. Tietoturvan ja yksityisyyden varmistaminen: Tietomallinnuksen avulla voidaan suunnitella tietokannan turvatoimet ja yksityisyydensuoja alusta alkaen, mikä varmistaa arkaluonteisen tiedon asianmukaisen käsittelyn ja suojauksen.

6. Kustannusten vähentäminen: Vaikka tietomallinnus vaatii alkuinvestointia, aikaa ja resursseja, se voi säästää merkittävästi kustannuksia pitkällä aikavälillä vähentämällä tarvetta tietokannan jälkikäteisille muutoksille ja korjauksille.

7. Standardisoinnin edistäminen: Tietomallinnus auttaa noudattamaan alan standardeja ja parhaita käytäntöjä, mikä helpottaa integraatiota muiden järjestelmien kanssa ja edistää tiedon yhteentoimivuutta.

Tietomallinnus on siis olennainen osa tietokantojen suunnittelua, joka auttaa rakentamaan tehokkaita, luotettavia ja tulevaisuuden tarpeisiin mukautuvia tietokantoja.

Miksi ja milloin tietomallinnus tehdään

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)
  • Enterprise 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:

Nyt kun ylätason käsitemalli on selkeä, introan fyysisiä tietomalleja.

Fyysinen tietomalli – OLTP- eli relaatiomalli (3NF)

Operatiiviset eli ns. OLTP-tietokannat ovat transaktiointensiivisiä. Tämä tarkoittaa, että dataa kirjoitetaan ja päivitetään tietokannassa tiuhaan tahtiin lukuoperaatioiden lisäksi. Tällaisia ovat mm. ERP-järjestelmien tietokannat. OLTP-työkuormille tyypillisiä piirteitä ovat pienet tulosjoukot sekä yksinkertaiset kyselyt. Hyvä OLTP-tietomalli on sellainen, jossa oliot ja niiden ominaisuudet esitetään hyvin normalisoituna, kerran ja vain kerran, relaatioineen. Täten saadaan tietokannan transaktionaalinen suorituskyky maksimoitua ja mahdolliset lukitustilanteet minimoitua.

Fyysinen tietomalli – Star Schema (tähtimalli)

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ä. Tähtimallissa esitetään laskennallinen data ns. faktatauluissa, joita ympäröivät laskennallista tietoa tyypittävät dimensiotaulut.

Fyysinen tietomalli – Snowflake Schema (lumihiutalemalli)

Lumihiutalemalli on eräs fyysisen tietomallintamisen menetelmä, jolla voidaan rakentaa tietovarastoja ja data martteja. Se on läheistä sukua tähtimallille ja hieman etäisemmin data vaultille. 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”.

Fyysinen tietomalli – 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.

Fyysinen tietomalli – 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.

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

CEO & Chairman

DB Pro Services Oy

Raportointitietokannan auditointi Verolle

Microsoftin suosituksen pohjalta DB Pro Services päätyi keskustelemaan laajasta raportointitietokannan auditoinnista Verohallinnolle. DB Pro Servicen kokeneille konsulteille tämä on  yksi tyypillisimmistä projekteista joissa pitää nopeasti analysoida nykytoteutus, tunnistaa sen mahdolliset ongelmakohdat ja ehdottaa korjaavat toimenpiteet. Joten tälläkin kertaa saimme asiakkaan vakuutettua, että meistä voisi olla merkittävää apua tunnistettujen haasteiden selvittämisessä ja korjaamisessa.

Usein tämäntyyppisiin projekteihin liittyy lisäksi valittujen kehityskohteiden toteutus, mutta tässä tapauksessa testasimme ehdottamiamme muutoksia erillisessä ympäristössä ja saimme erinomaisia tuloksia. Projekti eteni sovitussa aikataulussa ja budjetissa. Ohessa asiakkaan palaute suoritetusta työstä:

“Annoimme DB Pro Servicen asiantuntijoille toimeksiannon auditoida laaja raportointitietokantamme. Asiantuntijat tekivät havaintoja, analysoivat syitä ja kokeilivat / suosittelivat korjaustoimia, joilla saatiin aikaiseksi selkeitä parannuksia. Kokemus yhteistyöstä oli erittäin positiivinen.”

Mikko Laakso, Verohallinto

Yksi DB Pro Servicen fokusalueita on Microsoft-pohjaisten tietokanta-, tietovarasto- integraatio- ja raportointiratkaisuiden auditointi ja sen pohjalta tehtävä kehityssuunnittelu ja toteutus. Auditointeja on tehty yrityksen historian alusta alkaen ja tähän mennessä yli 50 eri asiakasympäristöä on läpikäytyinä. Auditoinnin lopputuloshan voisi olla myös se, että kaikki on täydellisessä iskussa. Sellaista toteutusta ei kuitenkaan ole vielä tähän päivään mennessä tullut vastaan vaan aina on jotain kehitettävää löytynyt. Useimmiten riittää nykyisen toteutuksen parametrien ja muiden asetusten optimointi, mutta luonnollisesti voi tulla eteen myös tilanteita, joissa todetaan, että tavoitellun suorituskyvyn varmistamiseksi vaaditaan isompaa arkkitehtuuri- tai alustapäivitystä ja / tai koodioptimointia.

Uskallamme luvata, että historian myötä konsulttiemme kokemuksesta ja matkan varrella kehittämistämme tehokkaista diagnostiikkatyökaluista ja -menetelmistä on varmasti hyötyä jokaiselle organisaatiolle, joka kaipaa apua Microsoft-pohjaisten kanta- tai raportointiratkaisuiden suorituskykyhaasteisiin. Olipa sitten kysymyksessä on premise -pohjainen toteutus tai Azure-pilviratkaisu.

Kannattaa muistaa, että ohjelmiston suorituskykyongelmat voivat johtua ihan yhtä hyvin kantaratkaisusta, integraatiopisteistä tai sovelluksen ja kannan välisen rajapinnan toteutuksesta kuin ohjelmistonkin toteutuslogiikasta. Teettämällä meillä DW / BI / ETL / kantaratkaisun diagnostiikan saa varmuuden siitä, että onko kunkin osa-alueen suorituskyky riittävä. Mikäli ei, meiltä löytyy ongelmien tunnistamiseen ja korjaamiseen huippukonstit ja -konsultit!

Kerromme mielellämme lisää, jos tunnistat tämäntyyppisiä haasteita omassa organisaatiossasi.

Milloin tietokanta-alustan modernisointi on perusteltua?

Tietokanta-alusta kehittyy jatkuvasti sen myötä, kun organisaatioon tulee uusia sovelluksia, käyttäjiä ja lisää dataa. Yleensä juurisyynä on kasvava ja kehittyvä liiketoiminta, mutta myös stabiilimmissa tilanteissa tietokanta-alusta ja siihen kohdistuva kuormitus voi ajan saatossa muuttua merkittävästikin. Siten se alustakokonaisuus, joka aikanaan on rakennettu parhaiden käytäntöjen mukaisesti ja sen hetkisen kuormituksen pohjalta, ei välttämättä enää 3-4 vuoden jälkeen vastaakaan tämän päivän liiketoimintavaatimuksiin.

Tarve modernisointiin voi tulla myös versiotuen loppumisen myötä. Nythän olemme tilanteessa, jossa SQL Server 2008 ja 2008 R2 -versioiden tuki loppuu tulevana kesänä (9.7.2019). Microsoftin linjaus asiasta on, että ”tuen päättyminen tarkoittaa, että säännöllisten tietoturvapäivitysten julkaiseminen loppuu. Kyberhyökkäykset yleistyvät ja kehittyvät jatkuvasti. Sovellusten ja datan käyttäminen ilman tukea jäävillä ohjelmistoversioilla voi aiheuttaa merkittäviä tietoturva- ja vaatimustenmukaisuusriskejä. On erittäin suositeltavaa, että asiakkaat päivittävät järjestelmänsä niiden uusimpiin versioihin. Se takaa parhaan suorituskyvyn ja tehokkuuden sekä säännölliset tietoturvapäivityksen”.  

Liiketoiminta-, tai tietoturvakriittisten järjestelmien yhteydessä ei pidä käyttää vanhentuneita, ohjelmistotoimittajan tuen piiristä pudonneita tietokantaversioita. Tai jos käyttöä kuitenkin jatketaan niin sen taustalla tulee olla tietoinen päätös ja siihen liittyvä riskiarviointi on tehtävä.

Microsoftin tuotetuen loppuminen vaikuttaa myös sovellustoimittajiin: uudet sovellukset eivät välttämättä toimi vanhan SQL Server -version kanssa, ja tällöin liiketoiminnan sovelluspäivitys voi muuttua laajemmaksi hankkeeksi kantakerroksesta alkaen.

Uudet SQL Server -versiot sisältävät merkittäviä parannuksia

Jos edellä oleva olikin hieman peloittelua niin sitten positiivisiin puoliin, joita modernisoinnilla on saatavilla. SQL Server 2008R2 on oivallinen kantamoottori, mutta merkittävää kehitystä on vuosikymmenen aikana tapahtunut. Uudet versiot tuovat mukanaan parannuksia ja mahdollisuuksia data-alustan kehittämiseen on valtava määrä. Ja mikä parasta, monet uudet ominaisuudet eivät vaadi Enterprise -versiota vaan ne on tuotu myös Standard -versioon.

SQL Server -versiopäivitys

Muutamia esimerkkejä uudempien SQL Server -versioiden sisältämistä parannuksista:

  • Ylläpitäjiä ilahduttavia ominaisuuksia ovat parannukset vikasietoisuuteen ja järjestelmän valvontaan sekä suorituskykyyn. AlwaysOn Availability Groupit mahdollistavat vikasietoisuuden yksinkertaisten DAS-ratkaisujen (Direct Attached Storage) avulla. Korkean käytettävyyden ratkaisun voi toteuttaa ilman mutkikasta infraa vaativaa SAN -ratkaisua, FibreChannelia, iSCSI -verkkoja tai virtualisointialustan raakalevyjä.
  • QueryStore kerää automaattisesti tietoja kyselyistä ja niiden suorituskyvyssä tapahtuneista muutoksista. Tämä helpottaa merkittävästi järjestelmän suorituskyvyn seuraamista, eikä erillistä valvontasovellusta välttämättä tarvita.
  • Resource Governor mahdollistaa työkuormien jaottelun ja sekä levy- että prosessoriajan kiintiöinnin. Esimerkiksi pitkille analysointi- ja ETL -latausajoille voidaan asettaa kiintiö, joka hillitsee niiden vaikutusta muuhun käyttöön.
  • Valtaosa tietokantapalvelimista kärsii levyjen hitaudesta, ja tämä korostuu iäkkäämmässä ympäristössä jossa myös levyjärjestelmä on vuosia vanha. Tyypillistä on myös suorittimien suhteellisen suuri joutenolo. Kun palvelin odottaa tietojen hakua levyltä, ei prosessoreillakaan ole juuri tekemistä. Tässä SQL Server tarjoaa uusia mahdollisuuksia: käytetään vähän suoritinaikaa datan pakkaamiseen ja purkamiseen lennossa. Tällöin levyn käsittely vähenee ja suorituskyky paranee. Rivi- ja sivutason pakkaaminen ovat olleet aiemmin Enterprise -version herkkuja, mutta SQL Server 2016 SP2 toi ne myös standardiversioon.
  • Columnstore index sekä pakkaa että ryhmittelee tiedot sarakkeittain perinteisen rivityksen sijaan. Tämä mahdollistaa analytiikkalaskennassa merkittäviä suorituskykyparannuksia.
  • Sovelluskehittäjien aika on yrityksessä merkittävä menoerä. Heitä ilahduttavatkin uudet ominaisuudet, kuten R- ja Python -tuki, natiivituki Json -tietorakenteille, uusia T-SQL -funktoita merkkijonojen käsittelyyn,  DML-toimenpiteisiin sekä viimeinkin surullisen kuuluisan String or binary data would be truncated -virheilmoituksen paremmat diagnosointimahdollisuudet.

Kuinka onnistut tietokanta-alustan modernisointihankkeessa

Modernisointi on järkevää aloittaa nykyisen alustan auditoinnilla. Auditoinnilla selvitetään resurssivaatimukset (CPU, muisti ja levytila), jotta pystytään varmistamaan uuden alustan resurssien riittävyys vuosiksi eteenpäin  ̶   eli tyypillisesti 4-5 vuodeksi. Resurssien tarve voidaan ennustaa seuraamalla nykyisen alustan resurssien käyttöä esimerkiksi kolmen kuukauden ajalta. Seurantaa voidaan tehdä käsipelillä tai käyttämällä siihen soveltuvaa ohjelmistoa, kuten SQL Governor. Mitä pidemmältä ajalta seurantaa tehdään sitä tarkempi ennuste tulevaisuuden tarpeista voidaan luoda.

SQL Governor uuden tietokanta-alustan suunnittelu ja optimointi

Modernisoinnissa tulee huomioida myös uuden alustan optimointi tulevan käytön vaatimuksiin. Tietokanta-alustan optimoinnin voi jakaa karkeasti kolmeen vaiheeseen; rauta/virtuaali-palvelimen optimointi, käyttöjärjestelmä-asetusten määrittely sekä itse SQL Server -asetusten optimointi. Jokaisen osa-alueen määrittely on tehtävä tarkoin, jotta vältytään tulevaisuuden suorituskykyongelmilta.

Siirtovaiheessa voidaan, ja kannattaakin, tehdä myös tietokantatason optimointia, muun muassa ottamalla käyttöön uuden SQL Server -version tuomia ominaisuuksia (Columnstore index, kompressointi jne..). Muutenkin on hyvä ottaa käyttöön parhaita tietokantatason käytäntöjä, kuten datan jakaminen useaan tiedostoon, suurten taulujen partitiointi, jne.

Uuden alustan käyttöönoton jälkeen on hyvä tehdä uusi auditointi noin kuukauden käytön jälkeen. Uudella alustalla esimerkiksi kyselyiden suorituspolut voivat olla hyvinkin erilaisia vanhaan verrattuna. Indeksien käyttö ja uusien indeksien tarve voikin olla hyvä selvittää.

Esimerkki onnistuneesta tietokanta-alustan uudistamisesta

Lopuksi käytännön esimerkki toteutetusta modernisointiprojektista, jossa DB Pro Servicen asiantuntijoilla oli merkittävä rooli.

Asiakkaamme Versowoodin modernisointiprojektissa uudistettiin sekä käyttöjärjestelmä- että tietokanta-alusta, tavoitteena kokonaisuus, joka vastaa tarpeisiin pitkälle tulevaisuuteen. Hankkeen lopputuloksena saavutettiin uusi tietokanta-alusta, jolla asiakas sai merkittäviä parannuksia tietokanta-alustan suorituskykyyn  ̶  parannukset vaihtelivat parhaimmillaan 40% ja 80 % välillä.

”Kokonaisuudessaan projekti onnistui hyvin ja täytti tavoitteensa, joka oli saavuttaa tarpeisiimme optimoitu alustakokonaisuus, joka palvelee meitä useita vuosia”, totesi Versowoodin Antti Kari meille projektin jälkeen.

Häämöttääkö sinullakin tietokanta-alustan uudistamishanke edessäsi? Ota yhteyttä ja jutellaan, miten voimme olla avuksi!

DB Pro Services
Jani Savolainen, CEO
Mikko Hyvärinen, Principal Consultant, Data Platform
Panu Mäntylahti, Senior Database Administrator