Tietovaraston rakentaminen kannattaa aloittaa käsitemallinnuksesta, koska se luo kestävän ja pitkäikäisen perustan tietovarastolle. Jos rakentaminen perustuu koko organisaation laajuisiin yhteisiin käsitteisiin, eri järjestelmien tiedot pystytään integroimaan. Näin tietovaraston tietojen hyödyntäjille tuotetaan todellista lisäarvoa. Kun käsitemallinnus on tehty, voidaan itse tietovaraston suunnittelu aloittaa. Suunnittelussa kannattaa ottaa huomioon useita tärkeitä asioita, kuten tiedon integrointi ja historiointi, rakentaminen sopivan kokoisissa osissa ja tietovaraston laajennettavuus. Kaikki nämä vaatimukset täyttää yksi menetelmä eli Data Vault 2.0 (DV2), jossa mallinnus perustuu joukkoon sääntöjä. Säännöstön ansiosta suunnittelun pystyykin automatisoimaan siihen tarkoitetulla välineellä.
Yksi hyvä automatisoinnin väline on Wherescape, joka mahdollistaa suunnittelun mallin näkökulmasta (model driven approach). Tällöin käsitemallista generoidaan looginen malli välineeseen syötettyjen konversiosääntöjen pohjalta. Tietovarastoon halutut tiedot lisätään loogiseen malliin lähdejärjestelmärajapinnoista, jonka jälkeen ne tyypitetään DV2 -tyypein. Tyypityksen jälkeen DV2 -tietovarastokannan suunnittelun ja toteutuksen voi jättää Wherescape -ohjelmiston huoleksi.
Seuraavissa luvuissa syvennytään tarkemmin nykyaikaisen tietovaraston kolmikerrosarkkitehtuurin osa-alueisiin, eli käsitemallinnukseen, loogiseen malliin sekä latausalueen ja DV2 -tietovarastoalueen automatisointiin (fyysinen mallinnus). Nämä pyritään käymään läpi toteutuksen kautta kronologisessa järjestyksessä.
Käsitemallinnus
Tietovaraston käsitemallinnuksessa mallinnetaan käsitteitä joiden takana on aina dataa. Mallinnuksen tavoitteena on löytää organisaation laajuiset yhteiset käsitteet. Käsitemalli on ensisijaisesti kommunikaatioväline tietovarastoprojektin eri osapuolten kesken, sillä sen avulla yhtä kuvaa katsomalla saadaan selville mitä asioita tietovarastoon on tarkoitus tuoda tai mitä siellä jo on.
Käsitemallissa (Kuva 1) käsitteet jaetaan eri tyyppeihin. Masterdata on rekisterityyppistä tietoa, kuten kauppa tai asiakas, joka on koko organisaatiolle yhteistä. Sopimustieto on sellaista tietoa jolla on selkeä voimassaoloaika, kuten asiakkuus. Tapahtumatietoa taas on esimerkiksi asiakkaaseen liittyvä kuitti. Mikäli tapahtumatieto sisältää kahdentasoista tietoa, esimerkiksi kuitti-kuittirivi, voidaan tapahtuma jakaa kahteen käsitetyyppiin, otsikko (header) - yksityiskohta (detail). Viimeisenä tyyppinä on referenssidata eli koodistot, jotka ovat tietoa joka muuttuu harvoin. Kun käsite tuodaan käsitemalliin, se kiinnitetään muihin käsitteisiin suhteilla. Suhteet ovat yleensä yksi moneen, esimerkiksi asiakas - kuitti, jossa asiakkaalla voi olla monta kuittia, mutta kuitti kuuluu vain yhdelle asiakkaalle.
Käsitemallin yhteen käsitteeseen liittyy koko organisaation laajuinen liiketoiminnan yksikäsitteinen avaintieto. Jos käsitteet on mallinnettu kuvaamaan liiketoimintaa, operatiivisen järjestelmän vaihtuminen ei aiheuta isoja tietovaraston muutostöitä. Liiketoiminnan avaimet ovat koko tietovaraston tärkein komponentti, jotka mallinnetaan kenttätasolle tietovarastoarkkitehtuurin loogisessa mallissa.
Looginen mallinnus
Kun käsitteet ja niiden väliset suhteet on mallinnettu, käsitemallin pohjalta voidaan tehdä tietovaraston looginen mallintaminen. Wherescape -ohjelmistossa looginen malli on mahdollista konvertoida suoraan käsitemallista konversiosäännöstöön perustuen (Kuva 2). Loogisen mallin muodostamisen jälkeen tehdään kytkentä lähdejärjestelmistä löytyviin tietoihin. Kaikkiin loogiseen malliin automaattisesti generoituneisiin avainkenttiin mäpätään vastaavat avainkentät lähdejärjestelmärajapinnan tauluista.
Loogisessa mallissa täytyy olla tieto siitä mitä DV2 -tyyppiä mikäkin loogisen mallin kenttä vastaa. Mallin käsitteille konversiossa generoituneet avainkentät tyypitetään konversion aikana säännöstön perusteella. Myös lähdejärjestelmistä lisättyjen attribuuttien tyypitystä varten voi luoda konversiosäännöt, jotka ajetaan attribuuttien tuonnin jälkeen. Eniten esiintyviä ja samalla keskeisiä DV2 -tyyppejä ovat business key, unit of work, reference attribute ja low velocity attribute. Tyypityksen jälkeen looginen malli on valmis latausalueen eli staging arean muodostamiseen.
Latausalue eli staging area
Loogisesta mallista generoidaan konversiosäännöstön perusteella latausalue (Kuva 3), jossa yhtä loogisen mallin käsitettä vastaa yksi latausalueen taulu. Taulun kentät koostuvat loogisessa mallissa määritellyistä kentistä sekä DV2 -mallinnuksen kannalta oleellisista kentistä kuten hash -kentistä ja aikaleimoista. Hash -kenttiä on kahdenlaisia, liiketoiminnan avaimista muodostettuja (_hk) ja tiedon historiointiin tarkoitettuja dss_change_hash -kenttiä. Koodistojen eli referenssitietojen osalta edellä mainittuja kenttiä ei muodosteta. Referenssitaulut voidaankin jättää mallitasolla latausalueelle.
Latausalue voidaan muodostaa jo tässä vaiheessa kantaan. Wherescape -ohjelmisto tekee sen automaattisesti, generoi taulunluontilauseet ja ajaa ne tietovarastokantaan. Luontilauseiden lisäksi ohjelmisto luo myös latausskriptit ja näin ollen manuaalinen ETL/ELT -työ jää kokonaan pois.
Data Vault 2.0
Mikäli edellisen vaiheen latausalue on muodostettu oikein, voidaan edetä DV2 -mallin muodostamiseen (Kuva 4). Mallin muodostamisessa yhdestä latausalueen taulusta generoituu yksi hub-taulu ja sille oma satelliittitaulu mikäli liiketoiminnan avaimelle on määritelty attribuutteja. Kun käsitteiden, eli siis kahden liiketoiminnan avaimen, välillä on suhde, siitä generoituu linkkitaulu. Linkkitaulu voi kuvata myös useamman avaimen keskinäistä suhdetta.
Kuvan 2 loogisesta mallista generoituu DV2 -malliin taulut seuraavasti:
1. Asiakas -mastertiedosta muodostuu hub_asiakas ja sat_asiakas
2. Kauppa -mastertiedosta muodostuu hub_kauppa ja sat_kauppa
3. Asiakkuus -sopimustiedosta muodostuu hub_asiakkuus ja sat_asiakkuus
4. Kuitti -tapahtumasta muodostuu hub_kuitti ja sat_kuitti
5. Kuittirivi -tapahtumasta muodostuu hub_kuittirivi ja sat_kuittirivi
6. Asiakas - Asiakkuus -suhteesta muodostuu link_asiakkuus
7. Asiakas - Kuitti -suhteesta muodostuu link_kuitti
8. Kuitti - Kuittirivi -suhteesta muodostuu link_kuittirivi
Asuinkaupunki -referenssitiedosta ei muodostu DV2-malliin tauluja. Taulu muodostuu jo Latausalueelle, mutta se luodaan samaan kantaskeemaan kuin DV2-taulutkin.
Kun DV2 -malli on muodostettu, sen taulut ja latauskriptit luodaan automaattisesti samalla tavalla kuin latausalueenkin osalta. Tämän jälkeen tietovarasto on mallinnettu ja toteutettu kaikkien käsitemallin käsitteiden osalta.
Toteutuksen työmäärät
Asiakkaan uuden sukupolven arkkitehtuurilla toteutettuun tietovarastoon haluttiin mukaan uusi tärkeä tietokokonaisuus. Uusi kokonaisuus sisälsi neljä sopimus-, kaksi tapahtuma-, yhden masterdata- ja kymmenkunta referenssitietotyyppistä käsitettä. Toteutus voitiin aloittaa kun lähdejärjestelmänä toiminut MS Azure datalake store sisälsi tarvittavat tiedot ja ne saatiin tietovaraston laiturialueelle eli ns. Load table arealle. Aluetta käytettiin toteutuksessa lähdejärjestelmän tietojen mäppäyksessä tietovaraston loogiseen malliin. Looginen malli oli tätä ennen generoitu käsitemallista.
Loogisen mallin mäppäysten kanssa aikaa kului eniten, sillä se on ainut vaihe jossa manuaalista työtä ei voi välttää. Jonkun täytyy vieläkin kertoa koneelle mitä minkäkin kentän data tarkoittaa. Kokonaistyöaika oli kuitenkin täysin eri luokkaa kuin perinteisissä tietovarastoprojekteissa. Työn osa-alueisiin meni aikaa seuraavasti:
Käsitemallin luominen Wherescapeen ja loogisen mallin generointi 2h
Tietojen haku Azure Datalake storesta laiturille 3h
Tietojen mäppäys loogiseen malliin 15h
Latausalueen (staging area) ja DV2 -alueen generointi 1h
Siirto fyysiseen toteutukseen (kannan rakenteiden ja latausskriptien automaattinen luonti) 1h
ELT/ETL -työt 0h
Työmäärän vertaaminen perinteiseen esim. 3NF -mallinnuksella ja Informatica -ETL -työkalulla toteutettuun tietovarastoon on epäreilua, sillä uuden sukupolven arkkitehtuurissa automatiikka hoitaa mekaanisen puurtamisen ja tekee sen sekunneissa. Siis sen johon ennen olisi mennyt viikkokausia aikaa saman tietokokonaisuuden saamiseksi tietovarastoon.
Yhteenveto
Mikäli lähdejärjestelmien data on eheää ja niistä on tunnistettavissa tarvittavat tiedot, uuden sukupolven tietovarastoarkkitehtuuri takaa sen, että tietovaraston toteutus voidaan tehdä käsitemallin pohjalta ketterästi ja inkrementaalisesti. Lisäksi pitkälle viety automatisointi tuo huomattavia kustannussäästöjä manuaalisen työn minimoinnin ansiosta.