T-76.115 Vaatimusmäärittely ETL-työkalu ExtraTerrestriaLs / Aureolis Oy Sivu 1 / 25
Versio Päivämäärä Tekijä Muutos 0.1 19.10.2004 Jani Malmi Alustava versio 0.2 19.10.2004 Mikko Ruokojoki Pieniä muokkauksia ja oikolukua 0.3 19.10.2004 Jani Malmi Lisätty toiminnalliset ja ei-toiminnalliset vaatimukset 0.4 20.10.2004 Jani Honkanen Lisätty järjestelmän yleiskuvaus, rajoitteet ja ratkaisuideoita 1.0 21.10.2004 Jani Malmi Koostettu ensimmäinen versio 1.1 25.10.2004 Mikko Ruokojoki Muokattu käyttäjiä ja dokumentin rakenne korjattu 1.2 26.10.2005 Mikko Ruokojoki Korjattu kappaletta 2 ja lisätty Jani H aineisto 1.3 26.10.2004 Teemu Nousiainen Lisätty ei-toiminnallisia vaatimuksia 1.4 27.10.2004 Jani Malmi Koostettu 1.4 versio ja pieniä muokkauksia 1.5 27.10.2005 Jani Honkanen Pieniä muutoksia 1.6 28.10.2004 Jani Malmi Lisätty muutoksia lähes jokaiseen kappaleeseen 1.7 28.10.2004 Mikko Ruokojoki Muokattu vaatimuksia ja dokumentin muotoilua 1.8 29.10.2004 Mika Suvanto Korjattu kpl 8 alkutekstiä 2.0 29.10.2004 Mikko Ruokojoki Versio 2.0 2.1 15.11.2004 Mika Suvanto Korjattu ja täydennetty mentorin palautteen pohjalta (kpl 5, 6, 8) 2.2 18.11.2004 Mika Suvanto Pientä korjailua 2.3 23.11.2004 Timo Sallinen Konvertoitu.doc ->.sxw, lisätty käyttöskenaariot 2.4 27.11.2004 Jani Malmi Lisätty vaatimusten muutoksia ja pieniä korjauksia 2.5 29.11.2004 Mikko Ruokojoki Otsikoinnin korjausta 2.6 29.11.2004 Mika Suvanto Päivitetty toiminnalliset vaatimukset -kohtaa 2.7 29.11.2004 Jani Honkanen Muokattu toiminnallisten vaatimusten statuksia 2.8 25.01.2005 Jani Malmi Päivitetty vaatimusten statuksia. Lisätty lookup. 2.9 29.01.2005 Asiakaskokous Päivitetty toiminnalliset vaatimukset ja arvioitu eitoiminallisia vaatimuksia. 3.0 30.01.2005 Jani Malmi Päivitetty toiminnallisia statuksia ja lisätty uusi sarake eitoiminnallisille vaatimuksille. 3.1 05.02.2005 Jani Malmi Päivitetty vaatimusten statuksia. 3.2 07.02.2005 Timo Sallinen Päivitetty vaatimusten statuksia Sivu 2 / 25
Sisällysluettelo T-76.115 Vaatimusmäärittely... 1 1 Dokumentin tarkoitus... 4 2 Liiketoiminnan tavoitteet... 4 3 Sovellusalueen yleiskuvaus... 5 4 Järjestelmän yleiskuvaus... 5 5 Järjestelmän käyttäjät... 7 5.1 Aureoliksen käyttäjäroolit... 7 5.2 Aureoliksen asiakkaan roolit... 7 6 Käyttöskenaariot... 8 6.1 Rooli: Asentaja... 8 6.1.1 SA-1 Asennus... 8 6.1.2 SA-2 Ajastaminen... 8 6.2 Rooli: Ylläpitäjä... 8 6.2.1 SY-1 Virhetilanteiden selvitys... 8 6.2.2 SY-2 Ajastuksien ja ylimääräisen ajon ajaminen... 9 6.3 Rooli: Ohjelmoija... 9 6.3.1 SO-1 Prosessin toteutus... 9 6.3.2 SO-2 Toimenpiteiden ohjelmointi... 9 6.3.3 SO-3 Versionhallinta... 9 6.4 Rooli: Ohjelmistoarkkitehti... 9 6.4.1 SD-1 Prosessin suunnittelu... 9 6.4.2 SD-2 Prosessin muutokset ja kuvauksen ylläpito... 10 6.5 Rooli: Testaaja... 10 6.5.1 ST-1 Prosessien testaus... 10 6.5.2 ST-2 Toimenpiteiden testaus... 10 6.5.3 ST-3 Integraatiotestaus... 10 7 Toiminnalliset vaatimukset... 10 8 Ei-toiminnalliset vaatimukset... 14 9 Käyttötilanteet... 15 10 Rajoitteet... 19 11 Ratkaisuideoita... 20 11.1 Ulkoisia komponentteja... 20 11.2 ETL-prosessin kuvauskieli... 20 11.3 Toimenpiteiden väliset rajapinnat... 21 11.4 Valmiita toimenpidekomponentteja... 21 11.5 Lähdeaineiston lukeminen... 22 11.6 Toimenpiteiden skedulointi (prosessimanageri?)...22 11.7 Toimenpiteiden toteutusframework... 23 11.8 Toimenpiteiden sisäinen toteutus... 23 11.9 Tietovarasto... 23 11.10 Puhdistus... 23 11.11 Virhetilanteiden hallinta... 24 11.12 Dokumentaatiogeneraattori... 24 12 Termejä... 24 13 Viitteet... 25 Sivu 3 / 25
1 Dokumentin tarkoitus Tämä on vaatimusmäärittelydokumentti ETL-projektille. Tämän dokumentin tarkoituksena on määritellä ja ylläpitää asiakkaan vaatimuksia toteutettavalle järjestelmälle. Vaatimukset kuvaavat järjestelmän toimintoja ja ominaisuuksia. Eri osapuolet voivat käyttää tätä dokumenttia apuna toteutettavan järjestelmän eri piirteiden ja ominaisuuksien kuvaamiseen ja ymmärtämiseen. Tämä dokumentti auttaa järjestelmän kehittäjiä ja tilaajaa ymmärtämään toisiaan projektin eri vaiheissa, jotta toteutettava järjestelmä todella täyttäisi todelliset tarpeet ja odotukset. Vaatimusmäärittely on sopimus kehittäjien ja tilaajan välillä. Tätä dokumenttia tullaan käyttämään myös hyväksymistestauksessa apuna tutkimaan toteuttaako järjestelmä todella alkuperäiset vaatimukset. Vaatimuksia tullaan päivittämään tähän dokumenttiin koko projektin ajan. Taulukko 1: Dokumentin lukijakunta Käyttäjä Projektiryhmä Asiakas Tulevat kehittäjät Kurssin mentori Motivaatio Ylläpitää vaatimuksia ja käyttää suunnittelussa, kehityksessä ja testauksessa apuna. Tarkistaa vaatimusten paikkaansa pitävyys eli onko tässä dokumentissa kuvattu järjestelmä todella se jota he haluavat. Tarkistaa järjestelmän alkuperäiset vaatimukset eli mitä alun perin oli tarkoitus toteuttaa. Tarkistaa vaatimusmäärittely ja antaa korjausehdotuksia sekä arvostella. 2 Liiketoiminnan tavoitteet Aureoliksen työ tietovarastoinnin alueella sisältää nykyisin paljon käsityötä ja manuaalista SQL-ohjelmointia. Tämä työllistää työntekijöitä tarpeettomasti ja vie aikaa ongelmien loogiselta ratkaisulta. Tavoitteena on, että työnteossa voitaisiin keskittyä enemmän ylemmän tason ongelmanratkaisuun ja ETL-työkalu vähentää yleensäkin asiakasprojektien tekemiseen menevää aikaa. Kaupallisista ETL-työkaluista on harkittu/tutkittu mm. SAS ETL Studiota, Sunopsista ja Oraclen ETL-työkalua. Kaupalliset ETL-työkalut ovat usein joustamattomia ja ne on tarkoitettu eri käyttäjäryhmälle. Ne ovat myös hyvin kalliita välineitä. Tämän projektin, eli itse tehdyn ETL-työkalun liiketoiminnalliset tavoitteet ovat lueteltu alla. ETL-työkalun itse tekemisen mielekkyyden arviointi. Verrataan oman työkalun ja kaupallisten työkalujen kustannuksia. Manuaalista SQL-ohjelmointia ja käsityötä halutaan vähentää, jotta pystytään keskittymään enemmän ongelmanratkaisuun ja varsinaiseen työhön. Asiakaskunnan kasvattaminen ja uusien asiakkaiden aloituskynnyksen alentaminen. Pystytään tarjoamaan ratkaisuja halvemmalla, kun voidaan välttää lisenssimaksut ja tuotteiden tuottaminen on helpompaa. Pystytään myös demoamaan ohjelman toimintaa ennen tilausta. Mahdollinen lisenssimyynti, jos ETL-työkalusta luodaan valmis tuote. Tuotteistamisen järkevyys arvioidaan myöhemmin, kun todetaan työkalun käyttökelpoisuus. Embedded -käyttö. Työkalu osaksi/komponentiksi muihin isoihin järjestelmiin. Sivu 4 / 25
Lisäkomponentti, jolla voidaan käsitellä aineistoa ja tarjota lisäarvoa raportointiin tms. 3 Sovellusalueen yleiskuvaus Tietovarastointi (Data warehousing) on kasvattanut suosiotaan viime vuosina ja sitä käytetään hyväksi lähes kaikilla liiketoiminnan alueilla. Sen merkitys on yrityksille hyvin tärkeä ja se luo pohjan hyvin monille muille palveluille ja lisäarvotuotteille. Raporttien tuottaminen tietovarastoista on kätevää, mutta se vaatii pohjalle hyvin suunnitellun tietovarastopuolen. ETL-työkalut auttavat tietovarastopuolen kehittämisessä. Niiden avulla voidaan mm. operatiivisten kantojen dataa muokata helpompaan muotoon raportointia varten. Ei tarvita niin paljon manuaalista käsityötä, kun ETL-työkalu hoitaa datan poimimisen, prosessoinnin ja tallentamisen uusiin tauluihin tai tiedostoihin. Taulukko 2: Sovellusalueeseen liittyviä termejä Käsite Lähdeaineisto Datamart ETL XML SQL DW, tietovarasto Työtietokanta Operatiivinen tietokanta Ks. kappale 12: termistö Ks. kappale 12: termistö Ks. kappale 12: termistö Extensible Markup Language. XML on yleisesti tuettu standardi ja merkkikieli datan kuvaamiseen. Se tulee olemaan keskeinen metatietojen välityksessä eri työkalujen välillä. Structured Query Language. Erityinen kieli tietojen päivittämiseen, poistamiseen ja kyselyyn tietokannoista. Ks. kappale 12: termistö Erillinen tietokanta itse tietovarastotietokannasta, jossa voidaan käyttää aputauluja tarkistuksien, jalostuksien ja summauksien tekemiseen. Tietokanta, jota käytetään yrityksen päivittäisessä toiminnassa, johon kohdistuu runsaasti transaktioita. Relaatiotietokanta Relaatiotietokanta kostuu joukosta relaatioita eli tauluja. kieli ETL-moottori Ohjelmointikieli, jonka avulla ETL-moottori suorittaa halutun prosessin. ETL-ohjelman osa, joka suorittaa kuvauskielellä kuvatun prosessin. 4 Järjestelmän yleiskuvaus ETL-prosessilla voidaan esimerkiksi tuottaa tietovarastoon viikoittainen yhteenveto kaikista asiakkaan operatiivisissa tietojärjestelmissä ja muissa tietolähteissä olevasta aineistosta. Tarkoituksena on saattaa tieto sellaiseen muotoon, että sitä on helppo selata sekä tuottaa erilaisia raportteja ja tunnuslukuja. Toteutettavaan järjestelmään kuuluu tiedon lukeminen asiakkaan tietojärjestelmistä, tiedon muokkaus ETL-prosessin mukaisesti sekä tiedon varastointi tietovarastoon. Raporttien tai tunnuslukujen tuottaminen tietovarastosta ei kuulu järjestelmän piiriin. Sivu 5 / 25
ETL-prosessin alkupäässä ovat asiakkaan liiketoimintaa tai muuta tietoa sisältävät tietokannat ja muut tietolähteet. Prosessin alkuvaiheessa näistä tietolähteistä kopioidaan kaikki ETL-prosessissa tarvittava aineisto ns. ODS-alueelle, johon yleensä säilötään kopioita asiakkaan tiedoista vähintään useiden päivien ajaksi. ETL-prosessi koostuu toimenpiteistä, jotka ovat viime kädessä Java-pohjaisia komponentteja. Jokaisen toimenpidekomponentin tarkoitus on suorittaa jokin datan käsittelyyn liittyvä tehtävä, kuten tietyn lähdedatan osajoukon kopioiminen eteenpäin määrätynmuotoiseen tauluun tai kahden taulun liittäminen. Lopulta data on saatu muokattua sellaiseen muotoon, johon se halutaan varastoida itse tietovarastossa, missä sitä ei enää tulla muokkaamaan. Data tallennetaan tietovarastoon mahdollisimman helppolukuisena ja tarvittaessa voidaan tallentaa paljonkin redundanttia tietoa. Tietovarastossa dataa säilytetään pitkään, yleensä vuosia. Yksittäiset toimenpiteet ovat yleensä yksinkertaisia (kahden taulun liittäminen tai erottaminen, denormalisointi tms.), mutta ETL-prosessiin voi myös koota useammista toimenpiteistä koostuvia ryhmiä, eli alaprosesseja. Tietovarasto Toimenpiteet ja niiden väliaikaisvarastot (työalue) ODS Asiakkaan tietolähteet Text file Kuva 1: ETL-prosessista Kuva 2: Kaksi erillistä toimenpidettä: taulujen liittäminen helppolukuisemmaksi tauluksi (join) sekä kuukausittaisten aggregaattien tuottaminen. Sivu 6 / 25
Asiakkaan ETL-prosessi kuvataan erityisellä kuvauskielellä, jossa määritellään toimenpide-/alaprosessiverkon rakenne ja kussakin osaprosessissa suoritettavat toimenpiteet. Toimenpiteitä ovat esimerkiksi taulujen (tai niiden osien) kopiointi, liittäminen, hajottaminen jne. Lisäksi on mahdollista kirjoittaa tarvittaessa asiakaskohtaisia toimenpidekomponentteja Javalla. 5 Järjestelmän käyttäjät Järjestelmän käyttäjät ovat määritelty eri roolien mukaan. Roolien avulla havainnollistetaan käyttäjän tavoite toiminnassa ja sen avulla voidaan paremmin määritellä käyttötilanteet. Käyttäjiä voivat olla Aureoliksen henkilöstö, Aureoliksen asiakasyrityksen henkilöstö ja asiakasyrityksen asiakkaat. Ohjelmiston käyttö keskittyy pääasiassa suunnittelu- ja asennusvaiheeseen, jolloin Aureoliksen sekä Aureoliksen asiakkaan käyttäjät konfiguroivat ohjelmiston asiakkaan tarpeisiin soveltuvaksi. Tämän jälkeen interaktiivista käyttöä on vähän - pääasiassa ylläpitotöitä. ovat taustaltaan asiantuntijoita, joilta voidaan odottaa sovellusalueen tuntemusta sekä ohjelman käytön perustuntemusta. 5.1 Aureoliksen käyttäjäroolit Taulukko 3: Aureoliksen käyttäjäroolit Käyttäjä Lkm Käyttötilanteet Ohjelmoija 1-3 Uusien toimenpiteiden ohjelmointi Javalla, prosessien tutkiminen, lokien tutkinta, muutokset asetuksiin, dokumentaation lukeminen jne. Ohjelmistoarkkitehti 1-2 Prosessin suunnittelu kuvauskielellä, prosessien tutkiminen/muokkaaminen, muutokset asetuksiin, dokumentaation lukeminen jne. Testaaja 1-3 Toimenpiteiden testaus, prosessien testaus, integrointitestaus, lokien tutkinta ja lokien tarkkuuden säätö, prosessidokumenttien poiminta Dokumentoija 1-3 Prosessidokumenttien poiminta ja metadatan muokkaus. Asentaja 1 Asennusmääritysten muokkaus, metadatan muokkaus, lokien tutkinta ja ohjelman käynnistys / sulkeminen, ajastusten teko 5.2 Aureoliksen asiakkaan roolit Sivu 7 / 25
Taulukko 4: Aureoliksen asiakkaan roolit Käyttäjä Lkm Käyttötilanteet Ylläpitäjä 1-2 Prosessien suunnittelu kuvauskielellä, prosessien tutkiminen, lokien tutkinta, muutokset asetuksiin, toimenpiteiden ohjelmointi Javalla, ajastusten muokkaus. Asentaja 1 Asennusmääritysten muokkaus, metadatan muokkaus, lokien tutkinta ja ohjelman käynnistys / sulkeminen, ajastusten teko. 6 Käyttöskenaariot Käyttöskenaarioiden tarkoitus on kuvata käyttötilanteita järjestelmän käyttäjien näkökulmasta. Käyttöskenaarioiden kuvaukseen käytetään vapaata tekstikuvausta, jossa yritetään välttää teknisiin ratkaisuihin liittyviä mainintoja. Käyttöskenaariot ovat yksilöity seuraavasti: Ensimmäisenä kirjaimena S kuvaamassa sanaa skenaario Seuraava kirjain tulee suurimmassa osassa roolin ensimmäisestä kirjaimesta. Poikkeuksena ovat ohjelmistoarkkitehdin skenaariot, joissa on käytetty kirjainta D. Juokseva numero 6.1 Rooli: Asentaja 6.1.1 SA-1 Asennus Asentaja asentaa ETL-työvälineen asiakkaalle. Hän asettaa tietokannat konfiguraatiotiedostoon ja määrittää niille tyypin ja id:n, johon viitataan prosessikuvauksissa. Tämän jälkeen hän asentaa, jo mahdollisesti etukäteen luodut prosessikuvaukset, ja suorittaa niille ajastamisen. Lopuksi asentaja käynnistää ETLmoottorin. 6.1.2 SA-2 Ajastaminen Asentaja määrittää prosessikuvaustiedostoon ajankohdat, milloin prosessi tulee ajaa. Spesifikaatiot tähän hän saa asiakkaalta ja ohjelmistoarkkitehdiltä. Ajastukset määritellään UNIXin cronin tapaan, kuukausien, päivien, viikonpäivien ja kellonaikojen avulla. 6.2 Rooli: Ylläpitäjä 6.2.1 SY-1 Virhetilanteiden selvitys Virheen tapahtuessa Ylläpitäjä selvittää ensin karkealla tasolla virheen todennäköisen sijainnin. Tässä hänellä on apuna dokumentaatio prosessista sekä järjestelmän toiminnasta, sekä ohjelmiston tuottama lokitiedosto. Hän suodattaa lokitiedostosta kiinnostavan tiedon ja tarvittaessa vertailee sitä edellisten ajojen tuottamaan lokidataan. Tarvittaessa Ylläpitäjä ottaa yhteyttä Ohjelmoijaan tai Ohjelmistoarkkitehtiin, mikäli vika löytyy prosessista tai järjestelmästä, tai jos vian syytä ei löydy. Sivu 8 / 25
6.2.2 SY-2 Ajastuksien ja ylimääräisen ajon ajaminen Järjestelmän ollessa jo toiminnassa havaitaan tarve muuttaa olemassa olevia prosessien ajastuksia. Ylläpitäjä avaa ajastukset sisältävän tiedoston, ja tämän tiedoston dokumentaation avulla hän löytää oikean kohdan muutoksille. Hän muuttaa valmiita ajastuksia, poistaa niitä tai lisää kokonaan uusia prosessiajoja. Ylläpitäjän tallennettua muutokset järjestelmä havaitsee ajastusten muuttuneen ja käynnistää prosessit uuden aikataulun mukaan. 6.3 Rooli: Ohjelmoija 6.3.1 SO-1 Prosessin toteutus Ohjelmoija saa tehtäväkseen toteuttaa jonkin suunnitellun prosessin. Hän pystyttää kehitysympäristön, joka sisältää kannan ja tarvittavat ohjelmat kuten Javan. Mikäli suunniteltu prosessi sisältää uusia toimenpiteitä, niin ohjelmoija toteuttaa ne Javalla ja integroi ETL-ohjelmaan. Mikäli kuvauskielellä kuvatussa prosessissa on puutteita, ohjelmoija keskustelee siitä ohjelmistoarkkitehdin kanssa ja prosessi täydennetään toimivaksi. Ohjelmoija syöttää prosessin ETL-ohjelmaan ja ajaa sen kehitysympäristössä. Kun prosessi näyttää toimivan, antaa hän sen testattavaksi testaajalle ja lopulta tuotannossa ajettavaksi. Jos testauksessa tarvitaan erillinen testiympäristö, niin ohjelmoija auttaa sen luomisessa ja mahdollisissa tuotantoympäristön ongelmissa. 6.3.2 SO-2 Toimenpiteiden ohjelmointi Ohjelmoija saa tehtäväkseen ohjelmoida jonkin uuden toimenpiteen Javalla. Hän suunnittelee toimenpiteen sisäisen prosessoinnin ja käy lävitse yhdessä ohjelmistoarkkitehdin kanssa rajapinnan ETL-moottoriin. Suunnittelun jälkeen ohjelmoija ohjelmoi uuden toimenpiteen ja tekee tarvittavat muutokset ETL-moottoriin ja muualle sovellukseen. Toteutuksen ja alustavan testauksen jälkeen hän luovuttaa muutetun sovelluksen testaajalle testattavaksi. 6.3.3 SO-3 Versionhallinta Ohjelmiston kehittämisessä ja sen eri versioiden hallitsemiseen käytetään versionhallintaohjelmistoa kuten CVS:ää. Mikäli ohjelmoija haluaa muuttaa olemassa olevaa luokkaa tai tiedostoa, ottaa hän sen aina ensin omalle koneelle CVS:stä. Sitten hän tekee siihen tarvittavat muutokset ja jos se kääntyy, niin hän voi viedä sen takaisin CVS:ään (cvs commit). Jos ohjelmoija toteuttaa jonkin täysin uuden luokan, niin hän voi viedä sen CVS:ään kun se kääntyy. Aina kun ohjelmoija vie jonkin muutoksen CVS:ään niin hän kirjoittaa jonkin kommentin, jotta myöhemmin on helppo nähdä mitä kyseinen versio sisältää. Mikäli CVS herjaa konfliktista on joku toinen ohjelmoija muokannut samanaikaisesti juuri samaa kohtaa. Tällöin ohjelmoijan täytyy yhdistää versiot yhdeksi ja kokeilla että se kääntyy ja viedä uudestaan CVS:ään. 6.4 Rooli: Ohjelmistoarkkitehti 6.4.1 SD-1 Prosessin suunnittelu Ohjelmistoarkkitehti saa tehtäväkseen suunnitella asiakkaan tarpeisiin soveltuva ETLprosessi. Hän tutustuu asiakkaan ja lähdejärjestelmään. Näiden tietojen pohjalta ohjelmistoarkkitehti voi suunnitella prosessin. Hän aloittaa suunnittelun luomalla prosessin rungon kuvauskielellä. Tässä hän voi hyödyntää olemassa olevia Sivu 9 / 25
prosessikuvauksia ja muokata niitä, tai luoda kokonaan uuden. Apuna kuvauksen kirjoittamisessa hän tarvitsee kuvausta kielen syntaksista ja semantiikasta sekä esimerkkikuvauksia. Ohjelmistoarkkitehti suunnittelee prosessin kulun ja sisällön. Tarkemmat määrittelyt hän voi halutessaan jättää ohjelmoijan huoleksi. Hän luo prosessista dokumentaation ja tarkistaa loogisen toimivuuden. Ohjelmistoarkkitehti luovuttaa prosessin eteenpäin joko ohjelmoijalle tai testaajalle. 6.4.2 SD-2 Prosessin muutokset ja kuvauksen ylläpito Ohjelmistoarkkitehti saa tehtäväkseen muokata prosessin kulkua uusien määritysten mukaisesti. Hän ottaa esille prosessin kuvauksen ja muokkaa tarvittavia kohtia. Muokkauksien tekemiseen hänen tarvitsee tietää kuvauskielen syntaksi, semantiikka ja käyttää mahdollisesti apuna esimerkkikuvauksia prosesseista. Muokkauksien jälkeen hän tarkistaa prosessin loogisen toimivuuden ja luo dokumentaation uudelleen. Ohjelmistoarkkitehti luovuttaa prosessin eteenpäin joko ohjelmoijalle tai testaajalle. 6.5 Rooli: Testaaja 6.5.1 ST-1 Prosessien testaus Testaaja suorittaa testit Ohjelmoijan / Ohjelmistoarkkitehdin määrittämälle prosessikuvaukselle. Tämä voi sisältää itse prosessin testaamisen lisäksi uusien toimenpidekomponenttien testaamisen (ST-2). Testauksessa ajetaan prosessi kehitysympäristössä ja tutkitaan prosessin tuloksia sekä seuraamalla jatkuvasti lokitietoja ja tutkimalla kantoihin tehtyjä muutoksia. Prosessi voidaan ongelmatilanteissa ajaa operaatio kerrallaan. 6.5.2 ST-2 Toimenpiteiden testaus Testataan yksittäisten toimenpiteiden toimivuutta. Toiminnallisuus voidaan testata joko määrittämällä triviaali kuvaustiedosto (prosessinohjaus) tai luomalla stub-tyyppinen rajapinta korvaamaan ETL-moottori. Toimenpiteet palauttavat virhetilanteessa kutsuvalle rajapinnalle (normaalisti ETL-moottori) virheilmoituksen. Tarvittaessa tutkitaan myös toimenpiteen tulostaulua vähintään satunnaisotoksella komponentin oikean toiminnallisuuden varmistamiseksi. 6.5.3 ST-3 Integraatiotestaus Testaaja testaa Ohjelmistoarkkitehdin tai Ohjelmoijan tuottamien komponenttien integrointia sovellukseen. Käytännössä integroitavat komponentit ovat uusia toimenpidekomponentteja. Testattava versio toimenpiteistä ja prosessikuvaus haetaan versionhallintajärjestelmästä ennen testaamista (katso SO-3). Tarvittaessa liitetään toimenpiteen käyttö kuvauskieleen, jolla testausprosessi ajetaan. 7 Toiminnalliset vaatimukset Toiminnallisten sekä ei-toiminnallisten vaatimusten priorisointiin käytetään alla olevaa luokittelua: Sivu 10 / 25
Taulukko 5: Vaatimusten luokittelu niiden tärkeyden mukaan Kriittinen Matala Vaatimuksia, jotka ovat pakollisia ja oleellisia järjestelmän toiminnan kannalta ja ilman niitä järjestelmä ei ole käyttökelpoinen. Vaatimuksia, jotka ovat tärkeitä, mutta eivät puuttuessaan estä järjestelmän perustoimintaa. Vaatimuksia, jotka tuovat lisäarvoa järjestelmälle, mutta eivät haittaa suuresti puuttuessakaan. Tehdään jos resursseja riittää. Alla olevassa taulukossa (Taulukko 6) on lueteltu kaikki toiminnalliset vaatimukset mitä järjestelmältä vaaditaan. Priorisointi on tärkeää, koska tehtävänanto on hyvin laaja ja projekti voi lähteä helposti käsistä jos keskitymme liikaa epäoleellisiin. Tärkeintä olisi luoda mahdollisimman luotettava ja hyvä pohja tulevalle järjestelmälle. Käyttötilanne sarake viittaa kappaleessa 9 määriteltyihin käyttötilanteisiin. Tila -sarake kertoo, mikä on toiminnallisen vaatimuksen tilanne toteutuksen suhteen. Tila voi olla: Toteuttamatta Suunnitelmia ei ole Suunniteltu Suunnitelmat tehty Kesken Toteutus aloitettu Toteutettu Toteuttava koodi olemassa Vahvistettu Toteuttava koodi testattu ja toimii Hylätty Asiakas hylännyt vaatimuksen Taulukko 6: Toiminnalliset vaatimukset Kategoria Vaatimus Tila Käyttötila nne P1 Prosessi Prosessi koostuu toimenpiteistä. Kriittinen Toteutettu KT1 KT7, KT10 P2 Prosessi Yhden toimenpiteen tulos voi olla Kriittinen Toteutettu KT2, KT5 muiden toimenpiteiden syöte. P3 Prosessi Toimenpiteen syötteet ja tulosteet Kriittinen Toteutettu KT5 ovat yhteistä rajapintaa toteuttavia olioita. P4 Prosessi Toimenpiteen syöte/tuloste-oliot ovat Kriittinen Toteutettu KT5, KT7 relaatiotauluja. P5 Prosessi Toimenpiteen syötteet ja tulosteet Matala Toteuttamatta KT7 voivat olla ASCII-peräkkäistiedostoja. P6 Prosessi Datan käsittely tehdään tietokannan Toteutettu KT7 sisällä aina kun mahdollista. P7 Prosessi Syötteessä olevia virheitä pitää tunnistaa ja siihen on integroitavissa virheidenkäsittely. P8 Prosessi Kyky lähettää sähköpostia virhetilanteessa. Kesken KT12 KT14 Matala Toteuttamatta KT13 Sivu 11 / 25
Kategoria Vaatimus Tila Käyttötila nne T1 Toimenpide Join (right / left). Liittää kaksi oliota Kriittinen Toteutettu KT1, KT7 yhteen. (ei full, koska kantariippuvainen) T2 Toimenpide Summaus. Summaa sarakkeen Kriittinen Toteutettu KT1, KT7 kaikki rivit yhteen. T3 Toimenpide Keskiarvo. Laskee keskiarvon Toteutettu KT1, KT7 sarakkeen kaikista luvuista. T4 Toimenpide Count. Laskee rivien lukumäärän Toteutettu KT1, KT7 taulusta. T5 Toimenpide Min. Hakee tietystä sarakkeesta Matala Toteutettu KT1, KT7 minimin. T6 Toimenpide Max. Hakee tietystä sarakkeesta Matala Toteutettu KT1, KT7 maksimin. T7 Toimenpide Copy. Kopioi olio. Kriittinen Toteutettu KT1, KT7 T8 Toimenpide Toimenpiteet kytketään ETLmoottoriin Kriittinen Toteutettu KT1, KT7 jollain rajapinnalla. T9 Toimenpide Merge. Hylätty KT1, KT7 (28.1.2005) T10 Toimenpide Append. Rivien lisäys. Toteutettu KT1, KT7 T11 Toimenpide Delete. Rivien / olioiden tuhoaminen. Toteutettu KT1, KT7 T12 Toimenpide Update. Rivien / olioiden Matala Toteutettu KT1, KT7 korvaaminen. T13 Toimenpide Rajaus / filtteröinti. Vastaa SQL:n Kriittinen Toteutettu KT1, KT7 where-lausetta. T14 Toimenpide Sarakkeen / sarakkeiden Matala Toteuttamatta KT1, KT7 tyyppimuunnos ja muokkaus. T15 Toimenpide Union, intersection, difference. Hylätty KT1, KT7 Rivijoukon / oliojoukon yhdiste, leikkaus tai erotus. (28.1.2005) T16 Toimenpide Sort. Rivien / olioiden järjestäminen. Matala Hylätty KT1, KT7 T17 Toimenpide Distinct. Duplikaattien poisto. Matala Toteuttamatta KT1, KT7 T18 Toimenpide Indeksien tekeminen / poistaminen. Matala Toteuttamatta KT1, KT7 T19 Toimenpide Pivotointi. Rivien muuttaminen sarakkeiksi. T20 Toimenpide Unpivotointi. Sarakkeiden muuttaminen riveiksi. T21 Toimenpide SCD, slowly changing dimensions. Harvoin muuttuvan tiedon muutoksien seuranta. (Kehitysohjeeseen) T22 Toimenpide Toimenpiteissä on oltava indeksien käyttö tehokasta. Tarvittaessa on pystyttävä poistamaan ja lisäämään indeksejä tehokkuuden saamiseksi. T23 Toimenpide Lookup. Toteutetaan joiniin uutena moodina flagin avulla. Join menee virheeseen lookup-moodissa jos joinin ehdolle löytyy useita rivejä. K1 kieli Prosessi kuvataan kuvauskielen avulla ETL-moottorin ymmärtämään muotoon. Toteutettu KT1, KT7 Toteuttamatta KT1, KT7 Matala Suunniteltu KT1, KT7 Hylätty (28.1.2005) KT1, KT7 Matala Toteuttamatta KT1, KT7 Kriittinen Toteutettu KT1-KT4, KT6 Sivu 12 / 25
Kategoria Vaatimus Tila Käyttötila nne K2 kieli Mahdollisuus toteuttaa uusia Toteutettu KT5 toimenpidekomponentteja Javalla (Kehitysohje) K3 kieli Muuttujien välittäminen Kriittinen Toteutettu KT1 kuvauskielestä yksittäisille toimenpidekomponenteille. K4 kieli Muuttujien välittäminen Toteutettu KT1, KT3 kuvauskielestä toimenpideryhmille. K5 kieli Asiakkaan konfiguraatioparametrit Toteutettu KT8 (tietokannan osoite yms.) erilliseen tiedostoon. K6 kieli Toimenpiteen lähde- ja Matala Toteutettu KT1 kohdetaulujen sarakkeiden automaattinen mätsäys (sarakenimen perusteella). K7 kieli Moottorissa ja kuvauskielessä tuki Toteutettu KT1 toimenpiteille, jotka eivät tee uutta taulua vaan muokkaavat olemassa olevaa taulua. K8 kieli Alaprosessien kuvaaminen joko Toteutettu KT1 samassa tai eri tiedostossa itse pääprosessin kanssa. K9 kieli Yksilöllisten nimien antaminen / Toteutettu KT1 generointi toimenpiteille. K10 kieli Yksilöllisten nimien antaminen / Hylätty KT1 generointi alaprosesseille. (28.1.2005) K11 kieli Yksilöllisten nimien antaminen / Toteutettu KT1 generointi väliaikaistauluille. K12 kieli Prosessin eheyden tarkistus / Toteutettu KT4 validointi. E1 ETL-moottori ETL-moottori suorittaa kuvauskielellä Kriittinen Toteutettu KT7 kuvatun prosessin. E2 ETL-moottori Moottorin tulee havaita riippuvuudet Kriittinen Toteutettu KT7 ja järjestää toimenpiteiden suoritus sen mukaisesti. E3 ETL-moottori Moottori pystyy rinnakkaiseen Matala Toteutettu KT7 toimenpiteiden suoritukseen. E4 ETL-moottori Moottorin tulee hallita ajastukset. Toteutettu KT1 E5 ETL-moottori Toimenpiteet ovat dynaamisesti ladattavia Java-luokkia, jotka toteuttavat toimenpide-rajapintaa. E6 ETL-moottori Eritasoiset lokiviestit (debug / info / warning / error / fatal) E7 ETL-moottori Step-by-step. Prosessin suorittaminen askel kerrallaan ja etenemisen seuraaminen. E8 ETL-moottori Historian siivous, eli vanhojen tietojen poistaminen tietovarastosta ja väliaikaisvarastoista. E9 ETL-moottori Ajetun prosessin peruuttaminen ja tuloksien pyyhkiminen tietovarastosta. Matala Toteuttamatta KT5 Toteutettu KT12, KT14 Matala Suunniteltu KT6 Matala Toteutettu KT9 Matala Hylätty (28.1.2005) KT10 Sivu 13 / 25
Kategoria Vaatimus Tila Käyttötila nne D1 Dokumentaation generointi Prosessin kuvauskielellä tehdystä kuvauksesta on mahdollista muodostaa dokumentaatio Toteutettu KT15 D2 Dokumentaation generointi automaattisesti. Dokumentaatioon kuuluu toimenpiteiden, syötteiden ja tulosten selkeä kuvaus ja prosessin graafinen esitys. D3 Dokumentaation generointi Lopputuloksesta saadaan relaatiomalli. U1 Käyttöliittymä Luonnos prosessin kuvaukseen käytettävästä käyttöliittymästä. Matala Kesken KT15, KT16 Matala Hylätty KT15 (28.1.2005) Matala Toteuttamatta KT1 8 Ei-toiminnalliset vaatimukset Alla olevassa taulukossa on lueteltu järjestelmältä vaadittavat ei-toiminnalliset vaatimukset. Priorisoinnissa on käytetty samaa systeemiä kuin toiminnallistenkin vaatimusten kohdalla (priorisointi-taulukko edellisessä kappaleessa). Ei-toiminnallisista vaatimuksista yksi tärkeimmistä on luotettavuus, koska järjestelmän on tarkoitus toimia joskus tuotantokannoissakin. Jos järjestelmä ei ole luotettava niin sen käyttömahdollisuudet ovat pienet. Toinen hyvin tärkeä vaatimus on kuvauskielen toimivuus, koska ilman sitä järjestelmä ei välttämättä ole käytettävä. Tila -sarake kertoo, mikä on ei-toiminnallisen vaatimuksen tilanne toteutuksen suhteen. Tila voi olla: Huono Vaatimus toteutuu huonosti tai ei ollenkaan Kehitettävä Vaatii vielä kehitettävää, mutta toteutuu osittain Hyvä Vaatimus toteutuu hyvin? Vaatii vielä testaamista ja tarkistamista Sivu 14 / 25
Taulukko 7: Ei-toiminnalliset vaatimukset Kategoria Vaatimus Tila ET1 kieli kielen on oltava tarpeeksi selkeä ja toimiva, jotta sitä voi käyttää käsinkin ilman käyttöliittymää. ET2 kieli kielen on oltava looginen, eli operaation nimet on oltava englanniksi ja tuettava tietovarastoinnin teoriaa mm. nimeämisellään. ET3 kieli kielen on tuettava CVSversiointia siten, että kuvausta voi muokata kahdesta eri kohtaa siten, että muutosten automaattinen yhdisteleminen on mahdollista. ET4 kieli kielen on vältettävä toisteisuutta hyvän ylläpidettävyyden saavuttamiseksi. ET5 kieli kielen on perustuttava olemassa olevaan teoriaan ja menetelmään ET6 Koodi Koodin täytyy olla helposti ylläpidettävää, jotta sovelluksen jatkokehitys olisi mahdollista. ET7 Koodi Koodin on oltava hyvin dokumentoitua ja kommentoitua. ET8 Järjestelmä Järjestelmän tulee olla luotettava ja hyvin testattu, jotta sitä voidaan käyttää tuotantokannoissa. ET9 Järjestelmä Sovittuja rajapintoja on noudatettava kautta linjan säilyttäen yhdenmukaisuus ja loogisuus. ET10 Järjestelmä ET11 Järjestelmä ET12 Dokumentaatio Uusien toimenpideluokkien lisääminen pitää olla riittävän helppoa Järjestelmän on oltava vakaa ja kyettävä säilyttämään datan eheys sekä toipumaan virhetilanteista. Dokumentaatiossa tule välttää toisteisuutta ylläpidettävyyden ja luettavuuden helpottamiseksi. Tieto pitää löytyä loogisesti oikeasta paikasta. Kriittinen Kriittinen Hyvä Hyvä Hyvä Hyvä Hyvä Hyvä Kehitettävä Kehitettävä Hyvä Hyvä Kehitettävä Kehitettävä 9 Käyttötilanteet Alla olevassa luettelossa kuvataan kaikki oleellisimmat käyttötilanteet. Oleellisina pidetään Sivu 15 / 25
tässä tapauksessa käyttötilanteita, jotka ovat (1) keskeisiä järjestelmän käytön kannalta sekä (2) sellaisia, joilla on suurin vaikutus suunnittelu- ja toteutustyöhön. LuoProsessi KT1 Arkkitehti Suunnittelija luo uuden kuvaustiedoston. Myöhemmässä vaiheessa tämän voi tehdä graafisen käyttöliittymän avulla. Kriittinen Px, Kx, U1 MuokkaaToimenpiteitä KT2 Arkkitehti Suunnittelija määrittelee kuvaustiedostoon uuden toimenpiteen ja antaa sille tarvittavat parametrit. Lisäksi hän määrittelee, mistä edeltävästä toimenpiteestä ko. toimenpide saa syötteensä sekä mihin se tallentaa tuloksensa. On luotu ETL-prosessi Myöhemmässä vaiheessa tämän voi tehdä graafisen käyttöliittymän avulla. Kriittinen Px, Kx, U1 Ryhmäparametrit KT3 Arkkitehti Suunnittelija määrittelee tietylle toimenpideryhmälle parametreja, jotka koskevat kaikkia näitä toimenpiteitä (esim. tietokannan URL). On luotu ETL-prosessi ja lisätty siihen toimenpiteitä. Myöhemmässä vaiheessa tämän voi tehdä graafisen käyttöliittymän avulla. K4 TarkistaProsessi KT4 Arkkitehti Suunnittelija pyytää järjestelmää tarkistamaan, onko tehty ETLprosessi eheä, eli onko esimerkiksi virheitä parametrien määrittelyissä. On luotu ETL-prosessi ja lisätty siihen toimenpiteitä. Myöhemmässä vaiheessa tämän voi tehdä graafisen käyttöliittymän avulla. Matala Sivu 16 / 25
K12 OhjelmoiToimenpide KT5 Ohjelmoija Suunnittelija ohjelmoi Javalla toimenpidekomponentin, joka lukee tarvittavan datan, muokkaa sitä ja lähettää lopputuloksen seuraavalle toimenpiteelle. K2 TestaaProsessi KT6 Arkkitehti, ohjelmoija, testaaja Suunnittelija ajaa ETL-prosessin testimielessä, käyttäen lähdedatana ennalta valmisteltua testidataa. On luotu eheä ETL-prosessi. On valmisteltu riittävä testiaineisto. On luotu tarvittavat tietokannat. E1, E6, E7 AjaProsessi KT7 Ylläpitäjä, asentaja tai ajastettu tehtävä ETL-prosessi ajetaan ja tuotetaan lopputulos tietovarastoon. On luotu toimiva ETL-prosessi. On luotu tarvittavat tietokannat (ei välttämättä tauluja). Kriittinen E1 Asenna KT8 Asentaja Asennetaan tehty ETL-prosessi asiakkaan ympäristöön: konfiguroidaan asiakkaan tietokantojen tai muiden tietolähteiden osoitteet asennetaan väliaikais- ja tietovarastotietokannat ja konfiguroidaan niiden osoitteet Sivu 17 / 25
Kriittinen - PoistaVanhaTieto KT9 Ylläpitäjä tai ajastettu tehtävä Poistetaan tietovarastosta ja/tai ODS-alueelta tietoja, jotka ovat vanhentuneet, eivätkä ole enää tarpeellisia. On otettu käyttöön toimiva ETL-prosessi. Poistaminen voidaan tehdä aluksi käsin tietokannasta, mutta myöhemmässä vaiheessa myös jonkin työkalun avulla. E8 PeruProsessi KT10 Ylläpitäjä Jos ajetun prosessin lopputulos ei ole tyydyttävä (esim. liikaa virheitä), voidaan peruuttaa ajo tuhoamalla tietovarastosta kaikki ko. ajon tuottamat tiedot. On otettu käyttöön toimiva ETL-prosessi. Poistaminen voidaan tehdä aluksi käsin tietokannasta, mutta myöhemmässä vaiheessa myös jonkin työkalun avulla. Kriittinen E9 Puhdistusloki KT11 Ylläpitäjä Voidaan tarkistaa lokista, minkälaisia puhdistustoimenpiteitä datalle on prosessiajon aikana tehty (so. lähdedatassa olevien virheiden korjaamista). On ajettu ETL-prosessi. E6 Virheloki KT12 Ylläpitäjä Voidaan tarkistaa lokista, millaisia virheitä tapahtui prosessiajon aikana. (ks. erikseen DebugLoki-käyttötilanne). On ajettu ETL-prosessi. Sivu 18 / 25
E6 TilaaVirheilmoitus KT13 Ylläpitäjä Ylläpitäjä määrittelee, että järjestelmä lähettää hänelle sähköpostitse virheilmoituksen, jos annetut virherajat ylittyvät prosessin (ajastetun) ajon aikana. On otettu käyttöön toimiva ETL-prosessi. Matala P7 Debugloki KT14 Arkkitehti, ohjelmoija, testaaja Suunnittelija näkee lokista tarkasti, mitä prosessiajon aikana tapahtui. On ajettu ETL-prosessi. Tuotantoympäristössä voidaan joutua karsimaan tallennettavien lokiviestien määrää, jolloin debug-tason viestejä ei ehkä ole saatavilla. E6 TuotaDokumentaatio KT15 Arkkitehti, ohjelmoija Generoidaan dokumentaatiota tehdystä ETL-prosessista (kaavioita, taulukkoja, kuvia yms.) On luotu ETL-prosessi. Dx MyyntiDemo KT16 Myyntihenkilö Myyntihenkilö esittelee järjestelmän ominaisuuksia potentiaaliselle asiakkaalle ilman raskasta tuotantoympäristöä. Matala - 10 Rajoitteet Sivu 19 / 25
Rajoitteilla tarkoitetaan suunnittelun valinnanvapautta rajoittavia tekijöitä, esimerkiksi laitealustoja, joilla järjestelmän tulee toimia. Taulukko 8: Projektin rajoitteet Vaatimus R1 Tietokantatuki: Toimittava kahdella eri tietokannanhallintajärjestelmällä siten että kehitys ryhmälle helpointa (esim. Oracle ja MySQL) R2 Käyttöjärjestelmät: Unix, Windows R3 Java-ympäristöt: J2SE 1.4.2 Kriittinen Kriittinen Kriittinen 11 Ratkaisuideoita Tarkoituksena on ideoida jo vaatimusmäärittelyvaiheessa, miten joitakin järjestelmän runko-osiin liittyviä suunnitteluongelmia voitaisiin ratkaista. Alla on lueteltu näitä alustavia ratkaisuideoita 11.1 Ulkoisia komponentteja XML:n parsiminen. Castor? Joku tavallinen DOM-parseri? Tietokantojen JDBC-ajurit Loki (Java 1.4:n loki? log4j? Onko joku parempi?) Käytetään JDBC:tä mieluummin kuin lähdetään kikkailemaan EJB:n / Hibernate:n tms kanssa (aikaa on vähän). Vai voisiko esim. hajautetuista transaktioista olla hyötyä? Tai yleensäkin Java Transaction APIn käytöstä? 11.2 ETL-prosessin kuvauskieli Käytetään XML:ää ja tehdään XML-schema. Kohtuullisen hyvä luettavuus, helppo tehdä parseri ja helppo virheentarkistus. Ehkä hiukan kankea (esim. kun tarvitaan räätälöityjä toimenpiteitä). XML:ää on kätevä käsitellä sekä koneellisesti että käsin, tekstimuotoisena myös CVS tuki onnistuu. Koodataan ETL-prosessi Javalla, eli luodaan toimenpideoliot ja liitetään ne toisiinsa suoraan Java -koodista käsin. Hyvä joustavuus, mutta heikot mahdollisuudet toteuttaa graafinen editori tai käyttää muita editoreja ja ehkä hankala generoida dokumentaatiota. Jos prosessi on erittäin iso, Javassa on paremmat mahdollisuudet ryhmitellä toimenpiteitä (esim. eri luokkiin/pakkauksiin). Tutkitaan voidaanko kuvauskieli perustaa jo olemassa oleviin kuvauskieliin, kuten XPDL tai PSL. Tehdään kokonaan oma kuvauskieli. Tehokkaampi käyttää kuin XML pitkällä tähtäimellä (opettelun jälkeen), mutta alkuvaiheessa käyttö kankeaa ja parserin tekeminen työlästä. Toimenpideolioille pitää pystyä antamaan parametreja kuvauskielestä käsin. Tehdään mahdollisuus määritellä parametreja yksittäisille toimenpiteille tai toimenpideryhmille. Mahdollisuus mäpätä esim. kopioitaessa lähdetaulun kenttiä kohdetaulun kenttiin yksitellen. Jos mäppäystä ei ole määritelty, kopioidaan lähdetaulun kentät samannimisiin kohdetaulun kenttiin. Sivu 20 / 25
11.3 Toimenpiteiden väliset rajapinnat Tyypillisesti yksi toimenpide tallentaa tuloksensa väliaikaiseen tietokantatauluun, josta seuraava toimenpide käy lukemassa sen. Voisi antaa toimenpideluokalle parametreina (kuvauskielestä käsin) esim. taulun ja mahdollisesti sarakkeen. Toimenpiteet eivät kutsu toistensa Java-metodeja suoraan, synkronointiongelmien takia. Synkronointiongelman voisi kiertää myös asynkronisilla metodikutsuilla, mutta toisaalta tarvitsee ehkä antaa enemmän vapauksia schedulerille päättää esim. toimenpiteiden ajastuksista. Muitakin tiedonvälitystapoja pitää tukea myöhemmin (esim. suoraan Java-olioina), joten ei sidota tätä rajapintaa pelkästään SQL-tauluihin. Toimenpiteen käsittelemät taulut (lähde- ja kohdetaulut, molempia voi olla useita) saattavat olla eri tietokannoissa => ei voida välttämättä suoraan SQL-komennolla kopioida dataa taulusta toiseen. Onko liian kova vaatimus, että välitettävän datan rakenne (taulut) pitää pystyä selvittämään ennen prosessin käynnistystä? Helpottaisi suunnittelua, kun taulurakenteet nähdään tarkasti jo suunnitteluvaiheessa Muussa tapauksessa rakenteesta tulee helposti sekava, jos taulurakenteet muuttuvat ajosta toiseen Toisaalta asettaa tiukkoja vaatimuksia toimenpidekomponenttien suunnittelulle. (Mitä mahdollisia ongelmatilanteita?) Taulut, joihin toimenpiteen lopputulos tallennetaan, pitää pystyä luomaan/päivittämään suoraan Javalla. Ts. ei voi olettaa, että joku olisi tehnyt tietokantaan taulut käsin valmiiksi tai että ne olisivat ajan tasalla. Taulujen create-lauseita tms. ei ole saatavilla mistään, vaan taulujen rakenne riippuu kuvauskielessä määritellystä toimenpiteen tyypistä ja annetuista parametreista. Dokumentaatiogeneraattorin pitää saada tietoa toimenpiteiden välisistä rajapinnoista, taulurakenteista jne. 11.4 Valmiita toimenpidekomponentteja Atomiset: olion kopiointi (kannan sisällä tai kannasta toiseen) summaus (+ muut statistiikat kuten keskiarvo = mean / average, freq = count, min, max) rivien lisäys = insert / append olion tuhoaminen / rivien tuhoaminen = delete korvaaminen = update rajaus (where) lookup (tarkistus dimensiota vastaan) sarakkeen/sarakkeiden tyyppimuunnos ja muokkaus join (right / left / full) Sivu 21 / 25
merge (poikkeaa hieman left joinista) union, intersection, difference (minus) lajittelu distinct (duplikaattien poisto) indeksien generointi / droppaus pivotointi ja unpivotointi (voisi ehkä toteuttaa myös "templaattina") "data step" + "by processing" Templaatit (kombinaatiot/räätälöidyt): SCD (Slowly Changing Dimensions) massatarkistus (useamman sarakkeen samanaikainen tarkistus ohjaustaulun avulla) historian siivous "OLAP-rakenteen" muodostus (summatasot relaatio-taulu(un/ihin)) 11.5 Lähdeaineiston lukeminen Lähdeaineiston lukemisessa voidaan tehdä hiukan enemmän asiakaskohtaista koodaustyötä, jotta aineisto saadaan mahdollisimman näppärästi luettua monenlaisista järjestelmistä. Toteutetaanko lähdeaineiston lukeminen joukkona toimenpiteitä, jotka ajetaan ensimmäisenä? Tai erillisenä ETL-prosessina? Tarvitaan varmaankin myös pollausta, eli tehdään kyselyjä lähdeaineistoon tiheästi, mutta ajetaan ETL-prosessi vasta sitten kun aineisto on muuttunut. Push-tyyppinen data voidaan hoitaa siten, että datan saapuessa triggeröidään ko. toimenpidekomponentit. 11.6 Toimenpiteiden skedulointi (prosessimanageri?) Pitää ajaa toimenpiteet oikeassa järjestyksessä Pitää lukea snapshot kaikesta lähdeaineistosta riittävän nopeasti, jotta kaikki tieto on riittävän samanaikaista Ajetun prosessin peruuttaminen, jos esim. ylläpitäjä toteaa että tuli liikaa virheitä Pitäisikö antaa toimenpiteen itse määrätä, lähetetäänkö data eteenpäin ja kontrolloida siten ETL-prosessin edistymistä? Ei riitä, koska pitää myös käsitellä tilanne, että joku komponentti unohtaa lähettää datan eteenpäin. Väliaikaistietokantojen keskitetty hallinnointi, esim. taulujen nimeämiskäytännöt ja taulujen luominen/muuttaminen. Pitää varautua siihen, että toinen prosessi saattaa käyttää samaa tietokantaa Jos ETL-prosessi on pitkä (sisältää pitkäaikaista välivarastointia tms.), pitää olla mahdollista käynnistää moottori uudestaan ja tunnistaa tietokannan perusteella, mitä prosesseja pitää ajaa seuraavaksi. Pitäisikö tämä jättää pitkäaikaista varastointia tekevien toimenpidekomponenttien harteille? Sivu 22 / 25
Nimeämiskäytäntö prosessiajoille? Jotta voidaan tunnistaa, mikä tulokseksi saatu data saatiin mistäkin ajosta (esim. virheidenhallintatilanteessa). Ongelmalliseksi homma tulee, jos pitää pystyä suorittamaan joitakin toimenpideryhmiä harvemmin kuin toisia. Pitää pystyä suorittamaan toisistaan riippumattomia prosesseja rinnakkain (ei ihan alkuvaiheessa pakollista) Pitää olla thread pool, koska toimenpiteitä voi olla paljonkin 11.7 Toimenpiteiden toteutusframework Tietokantayhteyksien avaaminen ja pollaaminen. Parametrien välittäminen prosessikuvauksesta toimenpidekomponentille, helposti luettavassa muodossa Taulurakenteen välittäminen viereisille toimenpiteille Jotkut toimenpiteet sisältävät ajastettuja toimintoja, kuten pollausta tai väliaikaisvarastojen tyhjennystä. Myös osia ETL-prosessista voidaan joutua triggeröimään ajastetusti. Dokumentaatiogeneraattorin pitää pystyä kysymään komponentilta dokumentaation generointiin liittyviä tietoja (nimi, luokka, parametrit jossain muodossa, viereisten toimenpiteiden nimet jne.) Scheduleri ilmoittaa toimenpidekomponentille, kun se pitää ajaa. Toimenpide ilmoittaa schedulerille, kun tulos on valmis. Toimenpide voi myös käynnistää itse itsensä, mutta tästä ei ehkä tarvitse ilmoittaa schedulerille. 11.8 Toimenpiteiden sisäinen toteutus Pitää käyttää suoraan tietokantojen komentoja aina kun mahdollista Osa toimenpiteiden koodista pitää tehdä erikseen eri tietokannoille. Annetaan tietokantatyypeille jotkut tunnistettavat nimet (esim. oracle, mysql )? Osa toimenpiteistä tukee useampaa lähde/kohdekantaa ja osa ei? Myös yksittäisen toimenpiteen suorituksen aikana voidaan tarvita väliaikaisia tauluja => nämä taulut pitää pystyä tekemään automaattisesti (jos joku yleiskäyttöinen toimenpiderajapintoja varten tehty taulugeneraattori ei sitä tee) 11.9 Tietovarasto Pitäisikö olla jotain kontrollia, millä tavalla toimenpidekomponentit saavat käsitellä tietovarastotauluja? Etteivät ne vahingossa tee muutoksia tai riko vanhaa historiadataa Erillinen toimenpidekomponentti, joka odottaa että koko ETL-prosessi on suoritettu, ennen kuin tallentaa kaiken datan tietovarastoon? Tietovarastoon voi kuulua myös useita kantoja. Tällä on vaikutusta ainakin prosessin perumismenettelyyn (täytyy pitää yllä tietoa, mitkä datat kuuluivat mihinkin prosessiajoon). 11.10 Puhdistus Suodatetaan esim. kirjoitusvirheitä vertaamalla eri lähteistä saatua dataa Sivu 23 / 25
Kategorisoidaan jotkut toimenpiteet puhdistustoimenpiteiksi, jotta niiden vaikutuksia voidaan keskitetysti seurata? Tarvitaan asiakkaalta lisää vaatimuksia ja toteutusideoita 11.11 Virhetilanteiden hallinta Koko prosessia ei saa peruuttaa pienten virheiden takia, vaan pikkuvirheistä annetaan ilmoitus käyttäjälle ja suoritetaan prosessi mahdollisimman hyvin loppuun. 11.12 Dokumentaatiogeneraattori Melko erillinen komponentti, mutta pitää miettiä, mitä tietoja tarvitaan prosessista 12 Termejä Taulukko 9: Termistö Suomeksi Englanniksi Selitys Lähdeaineisto, datalähde Data source Tietolähde, josta dataa luetaan ETL-prosessin alkupäässä. Esim. yrityksen omat tietokannat, tekstitiedostot,... DW, tietovarasto DW, data warehouse Kohdetietokanta, johon tallennetaan kunkin ETLprosessin suorituksesta saatu lopputulos. Tietovarastoa ei juuri muokata (paitsi silloin kun suoritetaan ETL-prosessi), vaan siihen tehdään ainoastaan kyselyjä. ETL-prosessi (myös ETT tai ETM) Toimenpide, operaatio Alaprosessi, osaprosessi ETL process Action, operation Subprocess Prosessikuvaus Process description / configuration Datan lukeminen lähdeaineistosta (extract), muokkaaminen (transformation) ja tallentaminen tietovarastoon (load / transportation / move) ETL-prosessiin kuuluva yksittäinen datan muokkaus-, kopiointi- tai muu toimenpide. Useamman yksinkertaisen toimenpiteen muodostama ryhmä, joka käyttäytyy ETLprosessissa kuten yksittäinen monimutkaisempi toimenpide. kielellä tehty kuvaus, joka kertoo, mitä osaprosesseja / tehtäviä ajetaan missäkin vaiheessa ETL-prosessia ja mitä niiden syötteet ja tulosteet ovat. Summaus Aggregation Datan kerääminen tietyiltä jaksoilta ja summaaminen esim. kuukausittaisiksi aggregaateiksi. Puhdistus Cleansing Datassa olevien virheiden (kuten käyttäjän kirjoitusvirheiden) havaitseminen ja korjaaminen. Virheidenhallinta Error control Prosessin ajon aikana tapahtuvien virheiden hallinta ja niistä toipuminen sekä käyttäjän informoiminen. Sivu 24 / 25
Suomeksi Englanniksi Selitys Data mart Data mart Tietynlaiseen dataan (myynti, asiakkaat tms) erikoistunut pienempi varasto, johon luetaan dataa yleensä yrityksen isommasta tietovarastosta. Faktataulu Fact table Tähtimallissa keskustassa oleva taulu, jonka sarakkeina ovat avaimet (tuote, asiakas) ja faktat (esim. hinta). Faktoille suoritetaan usein laskutoimituksia (summaus, keskiarvo). Dimensiotaulu Dimension table Tähtimallissa sakaroissa olevat taulut, joiden primary key:nä on faktatauluun viittaava avain. Itse taulu voi kuvata esim. tuotteita tai asiakkaita. Summataulu Summary table Taulukko, johon on laskettu valmiiksi useammista faktataulun riveistä koostettua dataa (esim. summia / keskiarvoja ajanjakson yli). ODS-alue Työalue, työvarasto 13 Viitteet ODS, operational data store Working area, working data store [1] Vaatimusmäärittelydokumentin pohja. Lähdeaineistosta kopioitu data voidaan tallentaa tänne väliaikaisesti ennen puhdistusta ETLprosessin aloittamista. ETL-prosessi käsittelee dataa (yleensä tietokannoista koostuvalla) työalueella ennen lopulliseen tietovarastoon tallentamista. http://www.soberit.hut.fi/t-76.115/04-05/ohjeet/template/requirements.html [2] Asiakkaan projektiesittely. http://www.soberit.hut.fi/t-76.115/04-05/aiheet/arffman.html [3] Ari Hovi. 2001. Tietovarastot liiketoiminnan tukena. 1. p. Jyväskylä. Gummerus Kirjapaino oy. 276 s. 951-762-777-7 Sivu 25 / 25