Suurin osa yrityksen talletetusta kiinteämuotoisesta tietoresurssista sijaitsee operatiivisten järjestelmien tietokannoissa. Nämä järjestelmät palvelevat yleensä hyvin operatiivista toimintaa. Tietojen analysointia, raportointia ja satunnaisia kyselyjä sen sijaan on usein hidasta ja vaikeaa tehdä. Tiedot voivat myös sijaita eri järjestelmissä, maantieteellisesti hajautettuna. Tiedot saattavat sisältää paljon koodeja ja teknisiä vipuja. Kyselyihin ja raportteihin taas tarvitaan yksiselitteistä ja selväkielisempää tietoa. Operatiivisissa kannoissa ei myöskään yleensä voida tallettaa kovin paljon historiaa.
Käyttäjät ja johto yrityksissä ovat usein turhautunutta tiedon vaikeaan ulossaantiin järjestelmistä. Tiedetään, että tarvittava data on olemassa, mutta yhteenvetojen ja pikaraporttien saanti on niin hidasta, työlästä ja kallista, että on luovuttu toivosta. Kuitenkin tarvittaisiin nopeita yhteenvetoja, "täsmäraportteja" sekä trendianalyysejä (esim. myynti nyt vs. edellisenä. vuonna). Isoissa yrityksissä on monia operatiivisia järjestelmiä, ehkä hajautettuna. Käytössä on myös ostettuja sovelluspaketteja. Näiden eri järjestelmien tietokannat eivät yleensä ole saman toimittajan. Vaikka tällainen tilanne olisikin, on vaikeaa tehdä yhteenvetoraportteja erilaisista systeemeistä.
Operatiiviset kannat on suunniteltu tehokkaaseen tapahtumankäsittelyyn, joka on usein päivityspainotteista. Niinpä tietojen toistoa ja summaamista vältetään, koska päivitykset tällöin hidastuvat. Kannat on hyvin normalisoitu. Operatiiviset kannat ovat usein raskaassa tapahtumakäytössä. Jos käyttäjät alkaisivat tehdä raskaita kyselyjä operatiivisiin kantoihin, olisi seurauksena operatiivisen toiminnan huomattava hidastuminen. Useinkaan operatiiviset järjestelmät eivät kestä päiväsaikaan tehtäviä kyselyjä ja laajasti kantaa selaavia raporttiajoja. Operatiiviset tietokannat eivät usein myöskään rakenteeltaan tue helppoja kyselyä ja raportointia.
Ratkaisu edellä kuvattuihin ongelmiin on Data Warehouse eli Tietovarasto. Tiedot poimitaan operatiivisista järjestelmistä ja ladataan erilliseen Data Warehouse -kantaan, kts. kuva. Tämä kanta on nimenomaan suunniteltu kyselyjä silmälläpitäen. Niinpä tietojen toistoa ei vältetäkään vaan päinvastoin, tietoja toistetaan eli denormalisoidaan. Tällöin taulujen määrä ja samalla tarvittavien liitosten määrä pienenee, jolloin kyselyjen suorituskyky on huomattavasti parempi kuin täysin normalisoidun kannan.
Data Warehouse-kantaan myös monasti summataan valmiiksi usein kysyttäviä tietoja kuten esim. tuotteiden kuukausi-kohtaiset myynnit, asiakasryhmien myynnit tai myynti vuoden alusta. Summataulut ovat kooltaan murto-osia tapahtumatauluista, mikä on omiaan nopeuttamaan kyselyjä. Kyselyt ovat myös helpompia tehdä.
Herää kysymys: eikö tiedon eheys ole vaarassa kun näin paljon tietoja toistetaan. Eikö sama tieto eri paikoissa voi mennä epäsynkrooniin? Data Warehouse kanta ladataan ja päivitetään keskitetysti yhdestä pisteestä. Tällöin otetaan huomioon jo kaikki tiedon toistamiset ja tehdään summaukset. Suorapäivityksiä ei sallita. Vaara epäeheydelle on siis hyvin pieni.
Operatiivisten sovellusten raportointipuoli voi tässä arkkitehtuurissa jäädä huomattavasti aiempaa pienemmäksi, mikä parataa sovellus-kehityksen tuottavuutta.
Tiedot siirretään ajoittain operatiivisista kannoista Data Warehouse -kantaan. Tiedot eivät siis ole ajantasalla. Siirtotiheys voi olla esim. kuukausi, viikko tai päivä. Tietojen analysointia, raportointia ja kyselyjä varten harvoin tarvitaan tiukempaa ajantasaisuutta kuin korkeintaan yksi päivä. Käyttäjien täytyy tietysti tietää tietojen ajantasaisuuden aste.
Kuten jo mainittiin, operatiivisten kantojen tiedot ovat usein koodattuja, jopa useita koodeja samassa kentässä. Eri järjestelmissä saattaa samalle asialle olla eri tietotyyppi. Pvm-muodot voivat olla erilaisia. Jopa käytetään eri tunnuksia (esim. asiakastunnus) eri järjestelmissä. Kaikki tämä on "siivottava" Data Warehouse - kantaan ladattaessa. Virheelliset tiedot on hylättävä. Koodit ehkä puretaan teksteiksi. Lisäksi tehdään summauksia valmiiksi.
Data Warehouse -kantaan halutaan yleensä säilöä myös historiaa. Tämä tarkoittaa sitä, että kannan tietoja ei päivitetä, vaan kantaan aina lisätään uusia tietoja esim. kaudella tai pvm:lla varustettuna. Näin Data Warehouse - kantaan alkaa kertyä trendianalyysejä varten historiaa, jota käyttäjät jatkuvasti tarvitsevat businesta analysoidessaan. Tietokannan koko samalla myös kasvaa. Kannan koko riippuukin ratkaisevasti siitä, paljonko historiaa halutaan säilyttää ja millä tarkkuus- tai summaustasolla.
Data Warehouse -kannasta voidaan ajaa vakioraportteja, jotka sijoitetaan esim verkon palvelimelle käyttäjien katsottavaksi. Käyttäjille voidaan laatia helppokäyttöisiä raportintilaussovelluksia, joilla he voivat tilata parametroituja raportteja. Parametreina voi olla esim. pvm-väli, tuoteryhmä, alue tai piiri, organisaatioyksikkö tai tietysti jokin näiden yhdistelmä.
Osa käyttäjistä voi käyttää Data Warehouse -kantaa suoraankin. On suuri määrä erilaisia käyttäjien työkaluja, joilla voidaan kytkeytyä tietokantaan kyselyjä ja raportteja tekemään. Tämä tietysti edellyttää, että käyttäjillä on hyvä tietämys Data Warehouse-kannan rakenteesta ja kenttien merkityksistä. Tarvitaan tietoa tiedosta eli metadataa. Metadata tulisi kuvata hyvin ja olla tarvitsevien saatavilla.
Osastotasolle, toiminnolle tai työryhmälle voidaan laatia oma, suppeampi tietovarasto. Tällaista tietovarastoa kutsutaan termillä Datamart. Datamart voidaan tehdä suoraan operatiivisesta kannasta tai sitten otoksena yrityksen isosta Data Warehouse-kannasta, tavallaan jatkojalostuksena. Pienimuotoinen Datamart voidaan jopa kopioida kannettaviin koneisiin. Esim. myyntimiesten kannettavissa on asiakkaita, tuotteita ja tilauksia käsittelevä sovellus, jonka tietokanta ajoittain ladataan Data Warehouse:sta tai paikallisemmasta Datamartista.
Eräs, toisin harvinaisempi arkkitehtuuri on rakentaa käyttäjien ja useiden Datamarttien väliin välityskerros, joka ottaa vastaan käyttäjien kysely ja reitittää ne oikeille Datamareteille eri koneille. Vastausrivijoukot myös yhdistellään tässä välikerroksessa ja toimitetaan kyselijälle. Apuna tässä välitystoiminnassa on eräänlainen hakemisto, jossa on kuvattu Datamerttien sijainnit ja niissä olevat tiedot. Tässä ratkaisussa ei välttämättä ole lainkaan isoa Data Warehouse-kantaa.
Data Warehouse-kanta sijoitetaan usein verkon palvelimelle, esim. UNIX tai NT-koneeseen. UNIXiin on nykyisin saatavissa erittäin tehokkaita rinnakkaisprosessointiin kykeneviä koneita. Monet tietokantajärjestelmät osaavat hyödyntää näitä prosessoreita tarjoten näin hyvää suorituskykyä nimenomaan useille yhtäaikaisille kyselykäyttäjille.
Mainframe voi tietysti myös olla Data Warehouse-kannan alustana. Jos käytössä on palvelukeskuksen kone, riippuu veloitus usein käytön määrästä. Tämä ei houkuttele Data Warehouse-kannan käytön lisäämiseen.
Data Warehouse-tietokantoina käytetään enimmäkseen relaatiokantoja, kuten Oracle, Sybase, Ingres, DB2 ja SQL Server. Etuna on tuotteiden kypsyys ja SQL:n ansiosta avoimuus ja monikäyttöisyys. Haittana on se, että nämä tuotteet ovat tavallaan liiankin monipuolisia kyselykäyttöön. Niissähän on ominaisuudet operatiivisiin, tiukkoihin tapahtumankäsittely-ympäristöihin. SQL:n ja Middleware-tuotteiden (etenkin ODBC) ansioista niiden käytettävyys kyselykantanakin on kuitenkin hyvä.
Toinen vaihtoehto on käyttää suljetumpia erikoiskantoja kuten SAS-tietokantaa tai Information Buildersin Focus-kantaa. Nämä eivät ole puhtaita relaatiokantoja eivätkä niin avoimia ja yleiskäyttöisiä. Sen sijaan ne saattavat olla helppokäyttöisiä ja suorituskykyisiä.
Relaatiomallin kehittäjä E.F.Codd julkaisi termin OLAP (Online Analytical Processing) v. 1993. Hän kritisoi SQL:lla ja nykyisiä relaatiokantatuotteita niiden huonosta tuesta joustavalle analyysille ja esitti tilalle erikoisia analyyttisiä tietokantatuotteita.
Tietojen analysoinnissa tarkastellaan dataa usein moniuloitteisesti. Esim. myyntiä analysoidaan ajallisesti, tuotteittain, alueittain, organisaatioyksiköittäin. Tämä voidaan hoitaa relaatiokannoillakin, mutta tarkoitusta varten on viime aikoina kehitetty ns. moniuloitteisia kantoja (Multidimensional Databases,MDD), jotka siis perustuvat OLAP-ajatteluun. Ne eivät ole yleiskantoja, vaan nimenomaan tarkoitettu moniuloitteisen datan talletukseen ja kyselyihin. Tiedot talletetaan käyttäjän määrittelemiin ulottuvuuksiin, ei tauluihin. Näissä kannoissa on yleensä erittäin tehokkaat, ns. bittimapatut indeksoinnit. Käyttöliittymät muistuttavat taulukkolaskimia tai suorastaan perustuvat taulukkolaskimeen.
Data Warehouse-toimittajat pitävät moniuloitteisia kantoja yleensä varsinaisen Data Warehouse-kannan kylkiäisinä. Ongelmana on niiden uutuus ja suljetuissa. Suurten tietomassojen käsittelykyky epäilyttää monia. Työkaluissa sitoudutaan helposti vain ko. toimittajan välineisiin.
Suuri joukko erilaisia Data Warehouse -työkaluja on ilmaantunut markkinoille. Monet toimittajat tarjoavat työkaluja tietojen hakuun ja poimintaan operatiivisista tietokannoista. Omia tuotteitaan on tietojen siirtoon ja lataukseen infokantaan. Myös tietokantatoimittajien replikointituotteita tarjotaan tähän tarkoitukseen. Kaikki nämä vaiheet voi tietysti myös koodata perinteisin välinein. Lisäksi löytyy Metadatan hallintavälineitä.
Mielenkiintoisilta näyttävät relaatiokantojen uudenlaiset indeksointitekniikat, jotka ovat erikoisen tehokkaita hauissa, mutta huonoja päivityksissä, millä taas ei olekaan niin väliä infokannoissa.
Tietovarastossa olevien tietojen kyselyissä, raportoinnissa ja analysoinnissa nojaudutaan nykyisin yleensä Asiakas-palvelin-arkkitetuuriin. Palvelin hoitaa raskaat tietokantapoiminnat ja ryhmittelevät summaukset ja lähettää verkon yli vain halutut tietueet tai summaukset. Välissä on Middlewaretuotteita, joista ehkä eniten on yleistynyt ODBC (Open DataBase Connectivity).
Kyselyvälineitä on suuri valikoima. Ne ovat graafisia, hiirikäyttöisiä ja yleensä generoivat SQL:aa palvelimelle lähetettäväksi. Raportteja varten on runsaasti toinen toistaan helppokäyttöisempiä välineitä. Taulukkolaskimet ovat erittäin tärkeitä ja käyttökelpoisia työkaluja tietojen analysoinnissa ja jatkojalostuksessa. Kaikissa suosituimmissa taulukkolaskimissa voi nykyisin tehdä kyselyjä suoraan relaatiokantaan ja jolloin tiedot kannasta siirtyvät kätevästi taulukon soluihin. Tietoja voi sitten jatkojalostaa ja tehdä helposti vaikka grafiikkaa, piiraita ja pylväitä.
Amerikassa on valtaosa suurimmista yrityksistä ilmoittanut rakentavansa tietovaraston lähiaikoina. Näiden jättiyritysten tietokannoistakin tulee tietysti suuria ja kalliita. Pienemmissä yrityksissä on helpompaa.
Tietovarastoa kannattaa lähteä rakentamaan palatsille ja kokemuksia vähitellen hankkien. Käyttäen yleisiä ohjelmistoja ja standardirautaa eivät kustannuksetkaan välttämättä kohoa huimiksi. Kiintolevyjen hinta on halventunut rajusti, gigan saa jo alle kahdella tuhannella markalla.
Tietovaraston rakentaminen on miellettävä kunnon projektiksi. Protoilu on mainio väline havainnollistamisessa. Kannan suunnitteluun on paneuduttava ja on syytä opetella uusi ns. star schema -tyyppinen tietokannan suunnittelutapa. Yllätyksiä voi tulla operatiivisten tietojen laadun tarkastamisen työläydessä. Väärä data tietovarastossa on aina tietynlainen katastrofi, jonka jälkeen käyttäjien luottamuksen takaisin saanti vie aikaa.
Ari Hovi Ari Hovi Oy,