Tietomallinnus – Data Vault

Robin Aro

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