T Vaatimusmäärittelydokumentti. ETL-työkalu

Transkriptio

1 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 1 (20) T Vaatimusmäärittelydokumentti ETL-työkalu ExtraTerrestriaLs Versio Pvm Tekijä Jani Malmi Alustava versio Mikko Ruokojoki Pieniä muokkauksia ja oikolukua Jani Malmi Lisätty toiminnalliset ja ei-toiminnalliset vaatimukset Jani Honkanen Lisätty järjestelmän yleiskuvaus, rajoitteet ja ratkaisuideoita Jani Malmi Koostettu ensimmäinen versio Mikko Ruokojoki Muokattu käyttäjiä ja dokumentin rakenne korjattu Mikko Ruokojoki Korjattu kappaletta 2 ja lisätty Jani H aineisto Teemu Lisätty ei-toiminnallisia vaatimuksia Nousiainen Jani Malmi Koostettu 1.4 versio ja pieniä muokkauksia Jani Honkanen Pieniä muutoksia Jani Malmi Lisätty muutoksia lähes jokaiseen kappaleeseen Mikko Ruokojoki Muokattu vaatimuksia ja dokumentin muotoilua Mika Suvanto Korjattu kpl 8 alkutekstiä Mikko Ruokojoki Versio 2.0 Sisällysluettelo 1 DOKUMENTIN TARKOITUS LIIKETOIMINNAN TAVOITTEET SOVELLUSALUEEN YLEISKUVAUS JÄRJESTELMÄN YLEISKUVAUS JÄRJESTELMÄN KÄYTTÄJÄT TOIMINNALLISET VAATIMUKSET EI-TOIMINNALLISET VAATIMUKSET KÄYTTÖTILANTEET RAJOITTEET RATKAISUIDEOITA TERMEJÄ VIITTEET... 20

2 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 2 (20) 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. Tämän dokumentin käyttäjät on kuvattu Taulukossa 1. Taulukko 1 - Dokumentin lukijakunta Käyttäjä Motivaatio Projektiryhmä Ylläpitää vaatimuksia ja käyttää suunnittelussa, kehityksessä ja testauksessa apuna. Asiakas Tarkistaa vaatimusten paikkaansa pitävyys eli onko tässä dokumentissa kuvattu järjestelmä todella se jota he haluavat. Tulevat kehittäjät Tarkistaa järjestelmän alkuperäiset vaatimukset eli mitä alun perin oli tarkoitus toteuttaa. Kurssin mentori Tarkistaa vaatimusmäärittely ja antaa korjausehdotuksia sekä arvostella.

3 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 3 (20) 2 Liiketoiminnan tavoitteet Aureoliksen työ tietovarastoinnin alueella sisältää nykyisin paljon käsityötä ja manuaalista SQLohjelmointia. 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. Lisäkomponentti, jolla voidaan käsitellä aineistoa ja tarjota lisäarvoa raportointiin tms.

4 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 4 (20) 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ähdeainesto Datamart ETL XML SQL DW, tietovarasto Ks. kappale 11: termistö Ks. kappale 11: termistö Ks. kappale 11: termistö Extended 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 11: termistö Työtietokanta Erillinen tietokanta itse tietovarastotietokannasta, jossa voidaan käyttää aputauluja tarkistuksien, jalostuksien ja summauksien tekemiseen. Operatiivinen Tietokanta, jota käytetään yrityksen päivittäisessä toiminnassa, johon kohdistuu tietokanta 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.

5 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 5 (20) 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. 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

6 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 6 (20) Kuva 2 - Kaksi erillistä toimenpidettä: taulujen liittäminen helppolukuisemmaksi tauluksi (join) sekä kuukausittaisten aggregaattien tuottaminen. 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.

7 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 7 (20) 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. 5.1 Aureoliksen käyttäjäroolit Taulukko 3 - Aureoliksen käyttäjäroolit Käyttäjä Ohjelmoija Ohjelmistoarkkitehti Testaaja Dokumentoija Asentaja Käyttötilanteet Toimenpiteiden ohjelmointi Javalla, prosessien tutkiminen, lokien tutkinta, muutokset asetuksiin, dokumentaation lukeminen jne. Prosessin suunnittelu kuvauskielellä, prosessien tutkiminen/muokkaaminen, muutokset asetuksiin, dokumentaation lukeminen jne. Toimenpiteiden testaus, prosessien ja toimenpiteiden testaus, lokien tutkinta, prosessidokumenttien poiminta, metadatan muokkaus jne. Prosessidokumenttien poiminta ja metadatan muokkaus. Asennusmääritysten muokkaus, metadatan muokkaus, lokien tutkinta ja käynnistys/ sulkeminen. 5.2 Aureoliksen asiakkaan roolit Taulukko 4 - Aureoliksen asiakkaan roolit Käyttäjä Ylläpitäjä Asentaja Käyttötilanteet Prosessien suunnittelu kuvauskielellä, prosessien tutkiminen, lokien tutkinta, muutokset asetuksiin, toimenpiteiden ohjelmointi Javalla jne. Asennusmääritysten muokkaus, metadatan muokkaus, lokien tutkinta ja käynnistys/ sulkeminen.

8 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 8 (20) 6 Toiminnalliset vaatimukset Toiminnallisten sekä ei-toiminnallisten vaatimusten priorisointiin käytetään alla olevaa luokittelua: 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 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 vaatimuksiin. Tärkeintä olisi luoda mahdollisimman luotettava ja hyvä pohja tulevalle järjestelmälle. Taulukko 6 Toiminnalliset vaatimukset ID Kategoria Vaatimus Status P1 Prosessi Prosessi koostuu toimenpiteistä. Kriittinen P2 Prosessi Yhden toimenpiteen tulos voi olla muiden toimenpiteiden syöte. Kriittinen P3 Prosessi Toimenpiteen syötteet ja tulosteet ovat yhteistä rajapintaa toteuttavia olioita. Kriittinen P4 Prosessi Toimenpiteen syöte/tuloste-oliot ovat relaatiotauluja. Kriittinen P5 Prosessi Toimenpiteen syötteet ja tulosteet ovat ASCII-peräkkäistiedostoja. Matala P6 Prosessi Datan käsittely tehdään tietokannan sisällä aina kun mahdollista. P7 Prosessi Syötteessä olevia virheitä pitää tunnistaa ja ilmoittaa niistä ylläpitäjälle. P8 Prosessi Kyky lähettää sähköpostia virhetilanteessa. Matala T1 Toimenpide Join (right / left / full). Liittää kaksi oliota yhteen. Kriittinen T2 Toimenpide Summaus. Summaa sarakkeen kaikki rivit yhteen. Kriittinen T3 Toimenpide Keskiarvo. Laskee keskiarvon sarakkeen kaikista luvuista. T4 Toimenpide Count. Laskee rivien lukumäärän taulusta. T5 Toimenpide Min. Hakee tietystä sarakkeesta minimin. Matala T6 Toimenpide Max. Hakee tietystä sarakkeesta maksimin. Matala T7 Toimenpide Copy. Kopioi olio. Kriittinen

9 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 9 (20) T8 Toimenpide Toimenpiteet kytketään ETL-moottoriin jollain rajapinnalla. Kriittinen T9 Toimenpide Merge. T10 Toimenpide Insert / append. Rivien lisäys. T11 Toimenpide Delete. Rivien / olioiden tuhoaminen. T12 Toimenpide Update. Rivien / olioiden korvaaminen. Matala T13 Toimenpide Rajaus / filtteröinti. Vastaa SQL:n wherelausetta. Kriittinen T14 Toimenpide Sarakkeen / sarakkeiden tyyppimuunnos ja muokkaus. Matala T15 Toimenpide Union, intersection, difference. Rivijoukon / oliojoukon yhdiste, leikkaus tai erotus. T16 Toimenpide Sort. Rivien / olioiden järjestäminen. Matala T17 Toimenpide Distinct. Duplikaattien poisto. Matala T18 Toimenpide Indeksien tekeminen / poistaminen. Matala T19 Toimenpide Pivotointi ja unpivotointi. Rivien muuttaminen sarakkeiksi ja päinvastoin. T20 Toimenpide SCD, slowly changing dimensions. Harvoin muuttuvan tiedon muutoksien seuranta. K1 kieli Prosessi kuvataan kuvauskielen avulla ETL-moottorin ymmärtämään muotoon. Kriittinen K2 kieli Mahdollisuus toteuttaa uusia toimenpidekomponentteja Javalla K3 kieli Parametrien välittäminen kuvauskielestä yksittäisille toimenpidekomponenteille. Kriittinen K4 kieli Parametrien välittäminen kuvauskielestä toimenpideryhmille. K5 kieli Asiakkaan konfiguraatioparametrit (tietokannan osoite yms.) erilliseen tiedostoon. K6 kieli Toimenpiteen lähde- ja kohdetaulujen sarakkeiden automaattinen mätsäys Matala (sarakenimen perusteella). K7 kieli Toimenpiteet, jotka lisäävät tai muokkaavat osia olemassaolevasta taulusta tai muusta dataoliosta (vrt tulosten kirjoittaminen tyhjään tauluun). K8 kieli Alaprosessien kuvaaminen joko samassa tai eri tiedostossa itse pääprosessin kanssa. K9 kieli Yksilöllisten nimien antaminen / generointi toimenpiteille. K10 kieli Yksilöllisten nimien antaminen / generointi alaprosesseille. K11 kieli Yksilöllisten nimien antaminen / generointi väliaikaistauluille. K12 kieli Prosessin eheyden tarkistus / validointi.

10 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 10 (20) E1 E2 E3 ETL-moottori ETL-moottori ETL-moottori ETL-moottori suorittaa kuvauskielellä kuvatun prosessin. Moottorin tulee havaita riippuvuudet ja järjestää toimenpiteiden suoritus sen mukaisesti. Moottori pystyy rinnakkaiseen toimenpiteiden suoritukseen. Kriittinen Kriittinen Matala E4 ETL-moottori Moottorin tulee hallita ajastukset. E5 E6 E7 E8 E9 D1 D2 D3 U1 ETL-moottori ETL-moottori ETL-moottori ETL-moottori ETL-moottori Dokumentaation generointi Dokumentaation generointi Dokumentaation generointi Käyttöliittymä Toimenpiteet ovat dynaamisesti ladattavia Java-luokkia, jotka toteuttavat toimenpiderajapintaa. Eritasoiset lokiviestit (debug / info / warning / error / fatal) Step-by-step. Prosessin suorittaminen askel kerrallaan ja etenemisen seuraaminen. Historian siivous, eli vanhojen tietojen poistaminen tietovarastosta ja väliaikaisvarastoista. Ajetun prosessin peruuttaminen ja tuloksien pyyhkiminen tietovarastosta. Prosessin kuvauskielellä tehdystä kuvauksesta on mahdollista muodostaa dokumentaatio automaattisesti. Dokumentaatioon kuuluu toimenpiteiden, syötteiden ja tulosten selkeä kuvaus ja prosessin graafinen esitys. Matala Matala Matala Matala Lopputuloksesta saadaan relaatiomalli. Matala Luonnos prosessin kuvaukseen käytettävästä käyttöliittymästä. Matala

11 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 11 (20) 7 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ä. Taulukko 7 Ei-toiminnalliset vaatimukset ID Kategoria Vaatimus ET1 kieli kielen on oltava tarpeeksi selkeä ja toimiva, jotta sitä Kriittinen 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 CVS-versiointia 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ää, 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ä Uusien toimenpideluokkien lisääminen pitää olla riittävän helppoa ET11 Järjestelmä Järjestelmän on oltava vakaa ja kyettävä säilyttämään datan eheys sekä toipumaan virhetilanteista. ET12 Dokumentaatio Dokumentaatiossa tule välttää toisteisuutta ylläpidettävyyden ja luettavuuden helpottamiseksi. Tieto pitää löytyä loogisesti oikeasta paikasta. Kriittinen

12 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 12 (20) 8 Käyttötilanteet Alla olevassa luettelossa kuvataan kaikki oleellisimmat käyttötilanteet. Oleellisina pidetään 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 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ä 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 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 Arkkitehti Suunnittelija pyytää järjestelmää tarkistamaan, onko tehty ETL-prosessi 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 K12 OhjelmoiToimenpide Ohjelmoija Suunnittelija ohjelmoi Javalla toimenpidekomponentin, joka lukee tarvittavan datan, muokkaa sitä ja lähettää lopputuloksen seuraavalle toimenpiteelle.

13 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 13 (20) K2 TestaaProsessi 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 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 Kriittinen - Asenna 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 PoistaVanhaTieto 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 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

14 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 14 (20) Puhdistusloki 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 Ylläpitäjä Voidaan tarkistaa lokista, millaisia virheitä tapahtui prosessiajon aikana. (ks. erikseen DebugLoki-käyttötilanne). On ajettu ETL-prosessi. E6 TilaaVirheilmoitus 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 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 Arkkitehti, ohjelmoija Generoidaan dokumentaatiota tehdystä ETL-prosessista (kaavioita, taulukkoja, kuvia yms.) On luotu ETL-prosessi. Dx MyyntiDemo Myyntihenkilö Myyntihenkilö esittelee järjestelmän ominaisuuksia potentiaaliselle asiakkaalle ilman raskasta tuotantoympäristöä.

15 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 15 (20) Matala - 9 Rajoitteet Rajoitteilla tarkoitetaan suunnittelun valinnanvapautta rajoittavia tekijöitä, esimerkiksi laitealustoja, joilla järjestelmän tulee toimia. Taulukko 8 - Projektin rajoitteet ID Vaatimus Tietokantatuki: Toimittava kahdella eri tietokannanhallintajärjestelmällä siten R1 Kriittinen että kehitys ryhmälle helpointa (esim. Oracle ja MySQL) R2 Käyttöjärjestelmät: Unix, Windows Kriittinen R3 Java-ympäristöt: J2SE Kriittinen 10 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 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ä? 10.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ä.

16 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 16 (20) 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 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ä? o Helpottaisi suunnittelua, kun taulurakenteet nähdään tarkasti jo o 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 Valmiita toimenpidekomponentteja Atomiset: o olion kopiointi (kannan sisällä tai kannasta toiseen) o summaus (+ muut statistiikat kuten keskiarvo = mean / average, freq = count, min, max) o rivien lisäys = insert / append o olion tuhoaminen / rivien tuhoaminen = delete o korvaaminen = update o rajaus (where) o lookup (tarkistus dimensiota vastaan) o sarakkeen/sarakkeiden tyyppimuunnos ja muokkaus o join (right / left / full) o merge (poikkeaa hieman left joinista) o union, intersection, difference (minus) o lajittelu o distinct (duplikaattien poisto)

17 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 17 (20) o o o indeksien generointi / droppaus pivotointi ja unpivotointi (voisi ehkä toteuttaa myös "templaattina") "data step" + "by processing" Templaatit (kombinaatiot/räätälöidyt): o SCD (Slowly Changing Dimensions) o massatarkistus (useamman sarakkeen samanaikainen tarkistus ohjaustaulun avulla) o historian siivous o "OLAP-rakenteen" muodostus (summatasot relaatio-taulu(un/ihin)) 10.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 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? 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 10.7 Toimenpiteiden toteutusframework Tietokantayhteyksien avaaminen ja pollaaminen. Parametrien välittäminen prosessikuvauksesta toimenpidekomponentille, helposti luettavassa muodossa

18 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 18 (20) 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 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) 10.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) Puhdistus Suodatetaan esim. kirjoitusvirheitä vertaamalla eri lähteistä saatua dataa Kategorisoidaan jotkut toimenpiteet puhdistustoimenpiteiksi, jotta niiden vaikutuksia voidaan keskitetysti seurata? Tarvitaan asiakkaalta lisää vaatimuksia ja toteutusideoita Virhetilanteiden hallinta Koko prosessia ei saa peruuttaa pienten virheiden takia, vaan pikkuvirheistä annetaan ilmoitus käyttäjälle ja suoritetaan prosessi mahdollisimman hyvin loppuun Dokumentaatiogeneraattori Melko erillinen komponentti, mutta pitää miettiä, mitä tietoja tarvitaan prosessista

19 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 19 (20) 11 Termejä Taulukko 9 - Termistö Suomeksi Englanniksi Selitys Lähdeaineisto, Data source datalähde 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 ETL-prosessissa 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. 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 ODS, operational data store Working area, working data store Lähdeaineistosta kopioitu data voidaan tallentaa tänne väliaikaisesti ennen puhdistusta ETL-prosessin aloittamista. ETL-prosessi käsittelee dataa (yleensä tietokannoista koostuvalla) työalueella ennen lopulliseen tietovarastoon tallentamista.

20 T Vaatimusmäärittelydokumentti ETL-työkalu (Aureolis Oy) Sivu 20 (20) 12 Viitteet [1] Vaatimusmäärittelydokumentin pohja. [2] Asiakkaan projektiesittely. [3] Ari Hovi Tietovarastot liiketoiminnan tukena. 1. p. Jyväskylä. Gummerus Kirjapaino oy. 276 s