TALLINNA TEHNIKAÜLIKOOL Infotehnoloogia teaduskond

Informaatikainstituut Infosüsteemide õppetool

Arendusprotsess: andmeaida süsteemi rajamine

Bakalaureusetöö

Üliõpilane: Eero Ringmäe Üliõpilaskood: 010636LAP

Juhendaja: prof. Enn Õunapuu

Tallinn 2005

Autorideklaratsioon

Olen koostanud käesoleva töö iseseisvalt. Kõik töö koostamisel kasutatud teiste autorite tööd, olulised seisukohad, kirjandusallikatest ja mujalt pärinevad andmed on viidatud. Käesolevat tööd ei ole varem esitatud kaitsmisele kusagil mujal. Kuupäev: ........................ Autor: ............................. Allkiri:........................................

Annotatsioon

Eero Ringmäe (2005). Arendusprotsess: andmeaida süsteemi rajamine. Bakalaureusetöö. Tallinna Tehnikaülikool. Infotehnoloogia teaduskond. Informaatikainstituut. Käsikiri. Tallinn. 83 lk. 35 kasutatud allikat. 19 joonist. 3 tabelit. 9 lisa. Töö eesmärgiks oli:

1. Uurida, milliseid elutsükli mudeleid ning dokumenteerimisviise kasutatakse tänapäevase andmeaida süsteemi arendamisel, lähtudes arusaamast, et maailmas ei ole välja kujunenud de facto standardit, üht üldkasutatavat andmeaida süsteemide arendusprotsessi.

2. Uurida Eestis tegutseva tarkvaratootja, ettevõtte "X" äriintelligentsisüsteemide arenduprotsessi, identifitseerida selle probleemid ning leitud probleemide osas pakkuda protsessile täiendusi, kasutades töö eelnevas osas uuritut.

Uurimusest lähtus, et tõepoolest pakuvad teoreetikud andmeaitade arendamiseks välja suure hulga suhteliselt erinevaid elutsükli mudeleid, dokumenteerimisviise ja arendusprotsesse. Läbiva joonena rõhutatakse aga andmeaida arendamist ärinõuete ning äriprotsesside keskselt, arenduse iteratiivset ja inkrementaalset iseloomu, dimensionaalse modelleerimise olulisust, geneeriliste andmemudelite kasutamist ning karbitoodete üha suurenevat osa arendamisel. Ettevõtte "X" äriintelligentsisüsteemide arendusprotsessi uurides selgus, et tegemist on iteratiivse andmekeskse protsessiga. Täiendusi pakkusin iteratsioonide planeerimise, strateegilise analüüsi dokumentatsiooni koostamise, ärinõuete kogumise ning erinevate äri alusel loodud mudelide sidustamise osas. Bakalaureusetöö on kirjutatud eesti keeles, sisaldab teksti 78 leheküljel, lisasid 5 leheküljel, 2 peatükki, 19 joonist, 3 tabelit ja 9 lisa. Märksõnad: andmeait, andmevakk, arendusprotsess, elutsükli mudel.

Abstract

Eero Ringmäe (2005). A software development process for data warehouse systems. Bachelor thesis. Tallinn University of Technology. Faculty of Information Technology. Department of Informatics. Manuscript. Tallinn. 83 pages. 35 used sources. 19 figures. 3 tables. 9 appendices. The goal of the thesis was:

1. To find out which lifecycle models and documentation notations are used to develop modern data warehouse systems, based on an understanding that there is no de facto standard, one single commonly used data warehouse development process emerged presently.

2. Study the business intelligence systems development process for an average sized software company in Estonia, find out the problems with the process and suggest improvements to these problems based on the best practices identified in the previous research.

The research indicated that there is a large variety of lifecycle model theories, document notation suggestions and development processes in the market presently. Despite the multitude of the theories, I identified that as a common point, most authors emphasize the business centricity of a data warehouse, the iterative and incemental nature of the development process, the importance of dimensional modelling, usage of generic data models and the increasing importance of off-the-shelf solutions. When studying the development process for business intelligence systems in company "X", I identified that the current process is iterative and data-centric in its nature. I suggested improvements in the fields of iteration planning, strategic analysis documentation, business requirements gathering and associating different models about the business. The bachelor thesis is written in Estonian, it consist of 78 pages of text, 5 pages of appendices, 2 chapters, 19 figures, 3 tables and 9 appendices. Keywords: data warehouse, data mart, development process, lifecycle model.

5

Sisukord

Sisukord....................................................................................................................... 5 Jooniste nimekiri.......................................................................................................... 7 Tabelite nimekiri.......................................................................................................... 7 Lisade nimekiri ............................................................................................................ 7 Lühendite ja mõistete sõnastik...................................................................................... 8 Sissejuhatus ............................................................................................................... 10 1. Andmeaida süsteemide olemus ning arendusprotsessid maailmapraktikas ............ 12

1.1 Infosüsteem, OLTP süsteem, äriintelligentsi süsteem – mõistete analüüs ........ 12 1.2 OLTP süsteemide olemus ............................................................................... 14 1.3 Andmeaida süsteemi olemus........................................................................... 16

1.3.1 Ülevaade................................................................................................ 16 1.3.2 Süsteemi osade kirjeldused .................................................................... 18

1.3.2.1 ETL ja staging area .......................................................................... 18 1.3.2.2 Presentatsioonikiht ........................................................................... 19 1.3.2.3 Kasutajarakendused ......................................................................... 20

1.3.3 Mõisted.................................................................................................. 20 1.3.3.1 Tähtskeem........................................................................................ 20 1.3.3.2 Andmevakk...................................................................................... 21

1.3.4 Alternatiivsed lähenemised andmeaida arhitektuurile ............................. 22 1.3.5 Andmeaitade arengutee.......................................................................... 23

1.4 Tarkvarasüsteemide levinumad arendusprotsessid .......................................... 24 1.4.1 Kosemudel............................................................................................. 24 1.4.2 Iteratiivsed ja inkrementaalsed protsessid............................................... 25 1.4.3 Agiilmetoodikad – samm hägususe poole .............................................. 27 1.4.4 Statistikat iteratiivse arendusprotsessi kasutamise kohta......................... 28

1.5 Andmeaida süsteemi rajamise erijooned arendusprotsessi seisukohalt............. 30 1.6 Arendusprotsesside kasutus andmeaitade rajamisel......................................... 32

1.6.1 Süsteemi tükeldamisest lähtuv lähenemine aidasüsteemi arendamisele:.. 33 1.6.2 Fookusalast tulenev lähenemine aidasüsteemi arendamisele................... 34 1.6.3 Valik arendusprotsesse ja elutsükli mudeleid andmeaida arendamiseks.. 35

1.6.3.1 "Business Dimensional Lifecycle" – Ralph Kimball.......................... 36 1.6.3.2 "Business Intelligence Roadmap" – Shaku Atre ja Larissa T. Moss .. 37 1.6.3.3 "Data Warehouse Lifecycle Management" – Cliff Longman............. 39 1.6.3.4 "Enterprise Modeling Framework" – J.O. Chan ............................... 40

1.6.4 Dokumenteerimine, nõuete kogumine, elutsükli üksikuid samme haaravad teooriad .............................................................................................................. 41

2. Andmeaida arendusprotsessi väljapakkumine ....................................................... 46 2.1 Ettevõte "X" ja eesmärk arendusprotsessi täiendamisel................................... 46 2.2 Ülesandepüstitus arendusprotsessile täienduste pakkumisel ............................ 48 2.3 Andmeida arendusprotsess ettevõttes "X"....................................................... 48

2.3.1 Kasutatud projektid................................................................................ 48 2.3.2 Arendusprotsess ettevõttes "X" .............................................................. 49

2.3.2.1 Üldiseloomustus............................................................................... 49

6

2.3.2.2 Etappide lahtikirjutused.................................................................... 50 2.3.2.3 Nõuetele vastavuse kontrollimine..................................................... 54 2.3.2.4 Iteratsioonid, arenduse kestvus......................................................... 54

2.4 Arendusprotsessi väljapakkumine................................................................... 54 2.4.1 RUP raamistiku valiku põhjendus .......................................................... 55 2.4.2 Enne arendust (planeerimine)................................................................. 55 2.4.3 Inception (analüüs) ................................................................................ 57 2.4.4 Elaboration (disain)................................................................................ 62 2.4.5 Construction (ehitamine)........................................................................ 65 2.4.6 Transition (juurutamine) ........................................................................ 66 2.4.7 Arenduse kestus..................................................................................... 67 2.4.8 Kokkuvõte täiendustest .......................................................................... 68

2.5 Täienduste analüüs ......................................................................................... 70 2.5.1 Tegevuste mudelid................................................................................. 70 2.5.2 Põhilised arengud .................................................................................. 72 2.5.3 SWOT analüüs....................................................................................... 72

Kokkuvõte ................................................................................................................. 74 Tulemused ja järeldused ......................................................................................... 74 Tulevikuvisioon ..................................................................................................... 75

Kasutatud kirjandus.................................................................................................... 76 Lisad.......................................................................................................................... 78

7

Jooniste nimekiri

Joonis 1. Mõistete "tarkvara" ja "ettevõtte infosüsteem" kattumine............................. 12 Joonis 2. Organisatsiooni otsustustasemed (5). ........................................................... 14 Joonis 3. Näide väärtusahelast ning OLTP süsteemidest selle sees. ............................ 14 Joonis 4. Andmeaida tüüpiline ülesehitus (8).............................................................. 18 Joonis 5. Trendid ETL tööriistade kasutuses (9). ........................................................ 19 Joonis 6. ETL toimumise sagedus andmeaidas (9)...................................................... 19 Joonis 7. Tähtskeem................................................................................................... 21 Joonis 8. Kosemudeli arendusetapid........................................................................... 24 Joonis 9. Üldise iteratiivse arendusprotsessi üks võimalik tegevuste jada. .................. 27 Joonis 10. Arendusprotsesside kasutus Lamri uurimuse (7) alusel. ............................. 29 Joonis 11. Iteratiivsete arendusprotsesside osakaalud Lamri uurimuses (7)................. 29 Joonis 12. Business Dimensional Lifecycle (4)........................................................... 36 Joonis 13. BI Roadmap tegevuste skeem (20). ............................................................ 38 Joonis 14. Data Warehouse Lifecycle Management (15)............................................. 40 Joonis 15. Enterprise Modeling Framework tegevuste järjestus (22) .......................... 41 Joonis 16. Ettevõtte "X" arendusprotsessi põhitegevused ja tulemiks olevad

dokumendid........................................................................................................ 50 Joonis 17. Täiendatud arendusprotsessi skeem. .......................................................... 69 Joonis 18. Ettevõtte "X" olemasoleva arendusprotsessi tegevusdiagramm. ................. 70 Joonis 19. Täiendatud arendusprotses......................................................................... 71

Tabelite nimekiri

Tabel 1. Andmevaka ja andmeaida sarnasused ja erijooned (9)................................... 22 Tabel 2. Ärinõuete seostamine andmemudeli andmete nõuetega................................. 60 Tabel 3. Ärinõuete seostamine tehniliste nõuetega...................................................... 60

Lisade nimekiri

Lisa 1. Allika analüüsi dokumendi struktuur (ettevõtte "X" dokumendipõhi). ............. 78 Lisa 2. Analüüsi kokkuvõtte struktuur........................................................................ 81 Lisa 3. Andmeaida rajamiseks valmisoleku küsimustiku struktuur (4, lk 47). ............. 81 Lisa 4. Inkremendi valiku teljestik (4, lk 52). ............................................................. 82 Lisa 5. Alliksüsteemide ning andmeolemite sidustamise tabel (20)............................. 82 Lisa 6. CRUD maatriksi kasutamine andmeolemite ja OLTP süsteemide seostamiseks

(24). ................................................................................................................... 82 Lisa 7. Rollide, protsesside ja andmete ühendamine (17)............................................ 82 Lisa 8. Data Warehouse Bus maatriks (4)................................................................... 83 Lisa 9. ETL protsessi voodiagramm (20). ................................................................... 83

8

Lühendite ja mõistete sõnastik

Mõiste/lühend Vaste ingl. k Selgitus Tarkvara Software Arvutisüsteemi poolt töödeldav hulk infot

– programmid, andmed. Tarkvara arendusprotsess

Software development process

Tegevuste, meetodite, notatsioonide ning tehnoloogiate kogum (raamistik) – kokkulepe/standard mille alusel saab tarkvara arendada.

RUP Rational Unified Process

Iteratiivne (tsükliliselt toimiv) tarkvara arendusprotsess, mille töötas välja Rational Software Corporation (nüüdseks IBM Corporationi osa). RUP kirjeldab, kuidas tarkvara iteratiivselt ja inkrementaalselt arendada, kasutades suurt hulka tegevusi, mudeleid, ja dokumente. RUP pole jäigalt kindlaksmääratud protsess, vaid pigem raamistik ja metamudel, mida iga arendusmeeskond peaks iseenese vajaduste jaoks kohandama (1).

XP eXtreme Programming

Tarkvara arendusprotsess, mis paneb põhirõhu rigiidsuse ja formaalsuse vähendamisele, dünaamilisusele, tihedale kommunikatsioonile arendajate meeskonnas ning kasutajate tagasisidele. Loetakse agiilmetoodikaks (2).

Andmeait / Andmeladu / DWH

Data Warehouse Klassikaline definitsiooni pärineb W.H.Inmonilt aastast 1990 - "A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management's decision making process"1 (3).

Andmevakk Data Mart Ühele ainsale äriprotsessile/äri valdkonnale keskenduv integreeritud, ajast sõltuv ja vähemuutuv andmekogu.

OLTP süsteem OnLine Transaction Processing System

Operatsiooniline infosüsteem/programm/tarkvarapakett, mille ülesandeks on äri igapäevase tegevuse toetamine. Praeguse töö kontekstis enamasti andmete lähtesüsteemiks.

OLAP süsteem OnLine Analytical Süsteemid, mis on loodud suure hulga

1 "Andmeait on ettevõtte kogu äritegevust haarav, integreeritud, ajast sõltuv, mittevolatiilne andmekogum, mille eesmärgiks on toetada otsuste tegemist."

9

Processing system andmete esitamiseks ning suurt hulka kirjeid analüüsivate päringute sooritamiseks. Tihti kasutavad andmete allikama DWH-sd või ODS-i, tihti esitatakse andmed hüperkuubina.

ODS Operational Data Store

Integreeritud andmekogum organisatsioonile (ei pruugi sisaldada ülejäänud kolme andmeaidale iseloomulikku tunnust).

3NF modelleerimine

3NF modelling Andmete olemi-suhte modelleerimise metoodika, mille eesmärgiks on andmed viia kolmandale normaalkujule (35) vähendamaks anomaaliaid andmete kustutamisel, uuendamisel ja lisamisel.

Dimensionaalne modelleerimine

Dimensional modelling

Andmete olemi-suhte modelleerimine, mis keskendub kergesti arusaadava, andmete lugemisele optimiseeritud ja sellest lähtuvalt tugevasti denormaliseeritud andmemudeli loomisele.

Tähtskeem Star schema Dimensionaalse modelleerimise tulemusena saadud andmemudel.

Lumehelbeskeem Snowflake schema Tähtskeem, milles dimensioonitabelid on osaliselt normaliseeritud.

Dimensioon Dimension Dimensioonilise andmemudeli osa. Sisaldab (tekstilist, kirjeldavat) infot, mille alusel päringutes dimensionaalse andmemudeli andmeid grupeerida ning piirata.

Fakt Fact Dimensionaalse andmemudeli keskne tabel. Koosneb välisvõtmetest, mis viitavad dimensioonitabelitele ning numbrilistest väljadest, mis päringutes dimensioonide grupeerimisel agregeeritakse.

ETL/ELT Extract-Transform-Load/Extract-Load-Transform

Protseduurid/meetodid, mille abil andmed laetakse operatsioonilistest süsteemidest andmeaita, "puhastatakse", valideeritakse, integreeritakse.

Metaandmed Metadata "Andmed andmete kohta." Käesoleva töö kontekstis on metaandmed DWH andmeid (ärilist tähendust, päritolu, kosolideerimiseks ja integreerimiseks sooritatud arvutusi) kirjeldavad andmed.

CWM Common Warehouse Metamodel

Object Management Group-i poolt loodud ning arendatav standard, mis defineerib vahekihi andmeaidas olevate metaandmete vahetamiseks. Baseerub UML-il, XML-il.

10

Sissejuhatus

Andmebaasidel põhinevat tarkvara on arendatud ja kasutatud ligi pool sajandit. Pea iga keerulisem rakendustarkvara, mille ülesannete hulka kuulub inimesele tähendust omavate andmetega manipuleerimine suhtleb andmebaasisüsteemiga, mis tänapäeval väga tõenäoselt baseerub E. F. Codd'i 1970. formuleeritud relatsioonilisel loogikal. Teoreetiliselt ning tehniliselt on relatsiooniliste andmebaaside valdkonda väga põhjalikult uuritud ning kirjeldatud. Äriettevõtte infot hoidvate tarkvarasüsteemide otstarbe võime jagada kaheks. Ühelt poolt vajame süsteeme, mis hoiaksid infot äri hetkeseisundi kohta, mille peamiseks ülesandeks oleks registreerida äriprotsesside igapäevasündmusi, olla kogu aeg kättesaadavad, teenindada korraga suurt hulka kasutajaid ettevõtte seest ja väljast - "hoida kätt äri pulsil". Teisalt vajame süsteeme, mis pakuksid meile infot ettevõtte kohta üldiselt, mis tegeleksid andmetega sootuks kõrgemal, agregeeritumal tasemel ning mille ülesandeks oleks äri strateegide küsimustele vastamine. Mõlemad süsteemid baseeruvad tõenäoselt (relatsioonilisel) andmebaasil, esimesi süsteeme kutsutakse transaktsioonilisteks, teisi äriintelligentsi süsteemideks. Transaktsiooniliste süsteemide arendamiseks, loomiseks on välja pakutud müriaad teooriaid ning metoodikaid, notatsioone oma tegevuse ja eesmärkide üleskirjutamiseks ning tööriistu koodi automaatseks tekitamiseks. Populaarseimad ja levinumad on praegu iteratiivsed ja inkrementaalsed arendusprotsessid, eesotsas Rational Unified Processiga, omaette kultuuriruumi moodustavad 'kergekaalulised' , agiilsed lähenemised. Transaktsioonilise süsteemi arendusmetoodika äriintelligentsisüsteemi loomiseks aga kuigi hästi ei sobi, kuna transaktsiooniline süsteem on keskendunud tegevustele – operatsioonidele, äriintelligensissüsteemi põhiülesanne on aga otsustuste toetamine. Äriintelligentsisüsteem peab erinevalt transaktsioonilisest süsteemist pakkuma tuge kasutaja küsimustele, mis pole süsteemi loomise ajal veel teada, see peab pakkuma terviklikku ning ühtset infopilti üle terve organisatsiooni ning suutma ka väga suuri andmehulki puudutavate kasutajapäringute korral mõistliku ajaga vastuse anda. Samas pole ühtset ja üldiselt aktsepteeritud arendusprotsessi äriintelligentsi süsteemide jaoks välja kujunenud. Tõsi, on mitmed teoreetikud, keda peetakse autoriteetideks ning kelle teooriaid kasutatakse, kuid nende vaated tihti ei ühti. Ei ole selget arusaama, mil määral on võimalik äriintelligentsisüsteemide rajamiseks kasutada mõnda levinud transaktsiooniliste süsteemide arendamise meetodit ja mil määral tuleks välja töötada täiesti uus arendamise metoodika. Lähtudes probleemist, et pole üldlevinud ning –aktsepteeritud arendusprotsessi äriintelligentsi süsteemide arendamiseks, on käesoleva töö eesmärgiks:

1. uurida, milliseid levinumaid elutsüklimudeleid, arendusprotsesse ja dokumenteerimisviise pakutakse välja äriintelligentsisüsteemide arendamiseks,

11

2. kasutades eelnevas uurimuses väljaselgitatut, täiendada Eesti turul tegutseva tarkvaratootja, ettevõtte "X" praegust kergekaalulist andmeaitade arendusprotsessi.

Minu huvi antud teema vastu põhjendab see, et olen lühikest aega ettevõtte "X" äriintelligentsisüsteemide meeskonnas töötanud ning näen, kui oluline on sellise tarkvara arendamisel teadvustatud ning toimiv arendusprotsess. Füüsiliselt olen töö jaganud kaheks osaks:

1. Teoreetiline baas, kus selgitan, mis on ning kuidas erinevad üksteisest transaktsioonilised süsteemid ning äriintelligentsisüsteemid ning milliseid arendusprotsesse ning -metoodikaid andmeaitade rajamiseks kasutatakse.

2. Ettevõtte "X" praeguse andmeaitade arendusprotsessi analüüs, sellele täienduste väljapakkumine ning täienduste analüüs.

Kuna teema on väga lai ja käesoleva töö skoopi kõik ei mahu, piiritlen uuritavad äriintelligentsisüsteemid andmeaitade ja andmevakkadega ning täienduste pakkumise põhiraskuse jätan arendusprotsessi analüüsi- ja disainietappi, keskendudes eriti nõuete kogumisele ning erinevate arendusel tekkivate dokumentide sidustamisele.

12

1. Andmeaida süsteemide olemus ning arendusprotsessid

maailmapraktikas

1.1 Infosüsteem, OLTP süsteem, äriintelligentsi süsteem – mõistete

analüüs

Jõudmaks arusaamisele, mida täpselt andmeaida ning selle arendusprotsessi all silmas peetakse, piiritlen kõigepealt tarkvarasüsteemid, mida uurima hakkan, annan definitsioonid kahele suurele tarkvarasüsteemide grupile – transaktsioonilistele süsteemidele ja äriintelligentsi süsteemidele. Edaspidi asun uurima mõlema süsteemidegrupi täpsemaid omadusi, et hiljem pakkuda ettevõtte "X" olemasoleva andmeaida arendusprotsessi baasil andmeaida süsteemi rajamiseks välja täiendatud ja parandatud arendusprotses. Tarkvara juhib arvuteid ning elektroonikasüsteeme kõige eripärasemates kohtades, täites kõige erinevamaid ülesandeid. Näiteid võime tuua alates garaazhiust avava mootori lülitamisest erinevate signaalide peale, e-kirjade kuvamisest personaalarvuti ekraanil kuni marsikulguri juhtimiseni kaugel planeedil. Ettevõtete ja äride tasemel puutume infotehnoloogias enamasti kokku infosüsteemidega. Mõiste "ettevõtte infosüsteem" on peaaegu sama lai ning üldine mõiste kui "tarkvara", haarates endasse ettevõtte äriprotsesse toetava tarkvara, kogutud ettevõttesisesed ja –välised andmed ning informatsiooni, samuti arvuti riistvara ja infotehnoloogilise infrastruktuuri, mille abil infot kogutakse, vahetatakse ja kasutatakse. Kohati loetakse isegi kasutajad infosüsteemi hulka kuuluvaks. Seega võime üldistada:

Joonis 1. Mõistete "tarkvara" ja "ettevõtte infosüsteem" kattumine. Uurimuse eesmärgist lähtuvalt keskendun edaspidi alale, milles kaks ülaltoodud mõistet kattuvad – äritegevust toetavale tarkvarale infosüsteemis. Sellise tarkvara hulka võime ühelt poolt lugeda erineva ettevõtte igapäevaseid madala taseme äriprotsesse toetava tarkvara (kassasüsteemid, laosüsteemid, e-kommertsi rakendused, õppeinfosüsteemid

Tarkvara Infosüsteem

13

jms), teisalt äriintelligentsi ja otsustustoetust pakkuva tarkvara (andmeaidad, andmevakad, teadmussüsteemid, otsustussüsteemid). Esimeses jaotuses toodud operatsioonilised/transaktsioonilised süsteemid tegelevad andmete töötlemisega igapäevatööks vajalikus ulatuses. Need haaravad korraga väikese hulga kirjeid, salvestades, muutes, kustutades ja kuvades üksikute tehingute või sündmuste infot. Mõnikord kutsutakse selliseid süsteeme OnLine Transactional Processing systems. OLTP süsteeme on rajatud pikka aega ja suurtes kogustes, mistõttu on nende arendusprotsessid suhteliselt standardiseeritud ning levinumate süsteemide funktsionaalsused ei erine kasutaja jaoks kuigi palju. Võrreldes näiteks erinevaid internetipankasid, kassasüsteeme või kasvõi internetipoode kasutaja tegevuste osas – erinevused on suurel osal nüanssides või funktsionaalsuse ulatuses, mitte aga põhitegevustes. Teises jaotuses toodu - andmeanalüüsi, andmeaida ning äriintelligentsi süsteemid on fokusseeritud analüüsile – andmed on neis üsna staatilised, korraga keskendutakse suurele hulgale andmetele eesmärgiga võrrelda, hinnata, leida trende, analüüsida äri käitumist. Ärinalüüsisüsteemid ammutavad oma info traditsiooniliselt mitmetest ettevõttesisestest ja -välistest transaktsioonilistest süsteemidest. Äriintelligentsi süsteemide erijooneks on tõik, et süsteemi headus, kasutatavus ja kasumlikkus ei sõltu mitte niivõrd üks-ühesest vastavusest süsteemi rajamisel kirjeldatud nõuetele, vaid andmete analüüsil pakutavast kvaliteedist – kvaliteetse toe ja vastuse andmisest loendamatule hulgale töö käigus tekkivatele küsimustele, hüpoteesidele, arutluskäikudele. Seetõttu võime erinevaid andmeaida presentatsioonikihte võrreldes öelda, et klassikalises mõttes on funktsionaalsus sarnane – on graafikud, andmekuubid, ennustavad mudelid, mõõdikud. Kuna aga äriintelligentsi süsteemi kvaliteedi tegelikuks mõõduks on see, mil määral aitavad analüüsitud andmed teha järeldusi, otsuseid ja prognoose äri strateegilisel tasemel, on kvaliteedi üle otsustamine sootuks keerulisem. Ettevõtte protsessid ja otsuste tegemiste tasemed võib jagada laias laastus kolmele tasemele – operatsiooniline, taktikaline, strateegiline. Operatsioonilise taseme otsusete tegemisel kasutatakse selgelt struktureeritud ning üheseid andmeid – küsimused, millele vastata on suures osas teada. Operatsioonilise taseme andmete kujutamseks sobib väga hästi normaliseeritud relatsiooniline mudel. Strateegilise taseme otsused opereerivad suures osas struktureerimata ning hägusate andmete, sageli küsimustega, mis kerkivad alles analüüsi käigus, mistõttu tuleb selle taseme jaoks andmeid ka erinevalt kujutada. Üheks lahenduseks andmete analüütiline modelleerimine, nagu pakub välja Haughey (5). Kirjeldatud erinevustest lähtuvalt ei saa arendusprotsessid ning andmete kujutamine OLTP ja äriintelligentsi süsteemide jaoks olla ühesugused. Organisatsiooni otsustasemete ning neis kasutatavate andmete jaotus:

14

Joonis 2. Organisatsiooni otsustustasemed (5).

1.2 OLTP süsteemide olemus

Ettevõtet saame vaadelda kui süsteemi, mis toimib majanduskeskkonnas, mis võtab midagi keskonnast endasse (ressursid, teadmine, ...) ning millel on sellesse keskkonda väljund (tooted.teenused, uus teadmine, ...). Ettevõttesiseses tegevuses saab erinevad operatsioonid järjestada väärtusahelaks (value chain) – tegevuste jadaks, mis kulgeb sisendi (tooraine, tellimuste, teadmiste, metoodikate) poolt väljundi (kauba, teenuse) poole ning milles iga tegevus loob sisendile juurde mingit väärtust.

Joonis 3. Näide väärtusahelast ning OLTP süsteemidest selle sees.

Operatsiooniline tase

Taktikaline tase

Strateegiline tase BI süsteemide huvipiirkond

OLTP süsteemide huvipiirkond

Ettevõte Y

Tooraine, tellimus, metoodikad, teadmised

Kaubad, teenused, uued teadmised

Võta tellimus

Eralda materjalid

Teosta töö

Koosta arve

Väljasta kaup

tellimuste OLTP süsteem

ressursside OLTP süsteem

Majanduskeskkond

Struktureerimata andmed

Struktureeritud andmed

15

Nagu öeldud, loetakse transaktsiooniliseks süsteemiks ärivara, mis tegeleb ettevõtte operatsioonilise taseme andmetega. Sellised süsteemid keskenduvad 24/7 valmisolekule kasutajat teenindada, kiirusele ning turvalisusele. Päringud andmete pihta on "kitsad" (s.t. haaravad väikest hulka kirjeid). Süsteem on huvitatud ainult igapäevatööks vajalike kirjete säilitamisest, seega on kirjete ajaloo pidamine pigem rakenduse kiirust pärssivaks asjaoluks. OLTP süsteemid on reeglina ehitatud mingi kitsa ärifunktsiooni või valdkonna ümber ja reeglina on ettevõttes kasutusel mitu erinevat OLTP rakendust, mis võivad, kuid ei pea omavahel suhtlema (vt. Joonis 3). OLTP süsteemide andmete analüüsi Andmete modelleerimise osas kasutavad OLTP süsteemid normaliseeritud andmemudeleid või vähemalt püüdlevad nende poole. Normaliseerimine võimaldab luua andmestruktuure, milles ei esine andmekordusi ega anomaaliaid andmete lisamisel, muutmisel, kustutamisel. OLTP süsteemideks on enamus igapäevaseid tarkvarapakette, mida andmete haldamiseks kasutame – näiteks kassasüsteemid, e-kommertsi rakendused, raamatupidamissüsteemid, kliendi- ja dokumendihaldustarkvarad. Omadused kokkuvõtlikult:

• kasutatavad ettevõtte operatsioonilisel tasemel – peegeldavad äriprotsesside hetkeseisundit,

• tegelevad andmetega, mis on aktuaalsed käesoleval ajahetkel, • andmed neis on suuresti volatiilsed – tekivad, muutuvad ja kaovad kiiresti • keskenduvad mingile äriprotsessile või selle osale • keskenduvad kiirusele, pidevale valmisolekule kasutajat teenindada,

turvalisusele • "kitsad" päringud andmetele • ei evi põhjalikku ajaloolist vaadet • ei pruugi suhelda teiste OLTP süsteemidega • enamasti baseeruvad normaliseeritud – andmete lisamiseks ja uuendamiseks

optimeeritud andmemudelil • võivad omada piiratud analüütilist vaadet (reeglina erinevad aruanded)

16

1.3 Andmeaida süsteemi olemus

1.3.1 Ülevaade Et äriintelligentsi süsteemiks võib lugeda tervet müriaadi erineva suunitlusega tarkvarasüsteemi (andmeaita, andmekuubikute rakendust, ettevõtte infoportaali andmekaevandamise rakendust jne), piiritlen edaspidi arutelu andmeaitade ning andmevakkadega. Nagu öeldud, koosneb keskmise ettevõtte infosüsteem reeglina mitmest erinevast andmekogust – OLTP süsteemist, välisest andmeallikast (raamatupidamissüsteem välises raamatupidamisettevõttes, internetipank, tarnijate hinnakirjad tabelarvutussüsteemides). Üksik OLTP süsteem võib omada mingeid analüüsi ja aruandlusfunktsioone, ent ülevaatliku, strateegilise äritaseme info jaoks sellest selgelt ei piisa. Eriti kehtib see mitmetest erinevates asukohtades tegutsevate ettevõtete, tütarettevõtteid või autonoomseid harusid omavate firmade ja lihtsalt väga suurte ettevõtete kohta. Edgars Peics, AS Hansapank Enterprise Data Warehousing endine valdkonnajuht tõi välja, et mitmes riigis tegutsevate firmad on enamuses läinud juhtimise detsentraliseerimise teed – visioon ja strateegia luuakse ettevõttele aktsionäride ja omanike huvidest lähtuvalt ühiselt, ent täitevvõim on hajutatud. Hansapank Grupp on sellest osas üheks suurimaks näiteks Eestis – pangana tegutsetakse kolmes Balti riigis – Eestis, Lätis, Leedus, lisaks ka Venemaal. Grupi koooseisu kuulub ka liisingu ja faktoorimise tütarettevõtteid. Selline ettevõtete föderatsioon vajab eriti teravalt mingit ühtset baasi, tuge kogu organisatsiooni hõlmavate järelduste tegemiseks ning strateegiliste eesmärkide püstitamiseks ja realiseerimise jälgimiseks. OLTP süsteemidest otse päringute tegemine selleks ei sobi, kuna:

• OLTP süsteemid on optimiseeritud andmete ühekaupa töötlemiseks, suuri infoväljasid haaravad päringud takistaksid operatsioonilist tööd ning

• andmed erinevates OLTP süsteemides on o erineval kujul o erinevate tähenduste o erineva granulaarsusega o erineva kvaliteediga

• OLTP süsteemid on pidevas muutumises • andmestruktuurid transaktsioonilistes süsteemides on liiga keerulised, et

ärikasutaja neid suudaks ise mõista – seega peaks igale äriküsimusele vastamiseks olema IT-töötajatest vahekiht, kes tõlgiks küsimuse päringuks

• ühtse vaate tekitamine ärile läbi OLTP süsteemide on ülimalt keeruline Selleks, et tekitada ühtne, selge ja mõistetav, kvaliteetne andmevaade ärile on seega mõistlik andmed operatsioonilistest süsteemidest, välistest infoallikatest ja muudest organisatsioonile vajalikest andmekogudest eraldada ühtsesse andmekogusse ning teha sellele andmekogule presentatsioonikiht, mis oleks äritakasutajatele piisavalt arusaadav, et peamiste küsimuste vastamiseks ei oleks vaja IT abi.

17

Sellised andmekogud on saanud nimeks andmeait (data warehouse). Klassikalise definitsiooni järgi on andmeait: kindlale teemale orienteeritud, integreeritud, ajast sõltuv, mittevolatiilne andmekogum, mille eesmärgiks on toetada otsuste tegemist (3). Andmeaida eesmärgiks on õigete andmete esitamine ("publishing the right data") (4). Täiendatud loetelu andmeaida süsteemi omaduste ning nende lahtikirjutusega:

• Teemale orienteeritud – info aidas on jaotatav valdkondadeks, on oluline ja piiritletav, milliste teemade ja valdkondade kohta infot hoitakse. Aita ei ole enamasti otstarbekas laadida kogu infot, mida me ettevõtte kohta leiame.

• Ajast sõltuv – aeg on ärikasutajate infovajadustes üks väga oluline dimensioon. Ettevõtte muutumise jälgimine ajas on üks põhilisi analüüsivaldkondi, seega on aeg andmete läbivaks dimensiooniks aidas.

• Mittevolatiilne – ait ei ole operatsiooniline süsteem, milles andmed muutuvad, kaovad ja tekivad. Andmeid loetakse aidast kasutajarkendustesse, andmeid kantakse aita ETL protsessi abil juurde, ent aidas ei toimu üksikute kirjete tasemel uuendamist/kustutamist.

• Toetab otsuste tegemist – andmeait ei ole arhiiv ega andmete surnuaed, see on aktiivne süsteem, mille eesmärgiks on kujutada kõige paremini infot äri tänapäevast ja minevikust, vastata küsimustele.

• Integreeritud ja ühtne – andmeait loob ühtse vaate ettevõtte andmetele, sellesse laetavad andmed konsolideeritakse

• Granulaarne – andmed laetakse aita teatava täpsusega (transaktsiooni täpsusega, äripäeva täpsusega, äriüksuse täpsusega). Andmete maksimaalne detailsus on aita arendama hakates määratud ja edaspidi see ei muutu.

Tüüpilise andmeaida süsteemi ülesehitus:

Staging area

OLTP1

OLTP2

OLTP3

tabelarvutus-dokument

Allikasüsteemid

Andmeid hoitakse relatsioonilises andmebaasi-süsteemis või failides. Andmeid puhastatakse, konsolideeritakse, filtreeritakse, sorteeritakse. Kasutaja seda aida osa ei näe.

Loe

Andmevakk

Andmevakk

Päring

Päring

Esitluskiht

Lae

Lae

Multidimensionaalsed andmed (tähtskeemid). Vaka andmed käivad mingi piiritletud teema kohta.

o Ettevõtte infoportaal

o Ad hoc päringute tööriistad

o andmekaevandamise rakendused

o OLAP kuubikute rakendused

o aruannete genereerijad

Kasutajaliides

18

Joonis 4. Andmeaida tüüpiline ülesehitus (8). Jooniselt 6 on näha andmete elutsükkel andmeaidas. Kimball (4) kirjutab andmete alustsükli detailsemalt lahti järgmiselt: Loe (Extract) -> Muuda (Transform) -> Lae ja indekseeri (Load and Index) -> Kontrolli kvaliteeti (Quality Assurance) -> Esita (Publish) -> Korja tagasisidet (Feeback) -> Tee varukoopiaid (Backup & Recovery). Andmeaida süsteemi aktiivsus väljendub sammus "Korja tagasisidet". See tähendab, et andmeait on pidevalt arenev süsteem. Äri muutudes teisenevad ärikasutaja infovajadused, muutuvad andmete allikad.

1.3.2 Süsteemi osade kirjeldused Vaatlen joonisel 6 kujutatud andmeaida süsteemi osade olemust ja funktsionaalsust lähemalt.

1.3.2.1 ETL ja staging area Lähtesüsteemidest (OLTP süsteemid ettevõtte sees, erinevad muud sisemised ja välised andmeallikad) laetakse andmed puhastusalale (staging area), kus need konsolideeritakse (ühendatase), filtreeritakse, sorteeritakse, tehakse kvaliteedikontroll. Staging area on reeglina relatsiooniline andmebaas, mõnikord kasutatakse laadimiste kiirendamiseks ka tavalisi tekstifaile. Staging area on andmeaida usaldusväärsuse ja andmete korrektsuse osas kõige olulisem kiht andmeaidas. Andmete laadimine lähtesüsteemidest staging areasse ja sealt edasi andmeaita on saanud akronüümina nimeks ETL, tulenevalt laadimise tegevuste nimedest inglise keeles - Extract Transform Load. Kasutatakse ka lühendit ELT - Extract -> Load -> Transform. Kasutajad staging areasse päringuid sooritada ei saa, kuna esiteks on seal andmed teatud ajahetkedel "toored" (s.t. vigadest puhastamata andmehulgad, poolikud arvutustulemused), teiseks on enamasti kasutusel normaliseeritud andmemudel, mis pole optimiseeritud suurt hulka kirjeid haaravateks päringuteks. 1990ndatel, mil tänapäevaste andmeaitade teooria küpses ning aidad laiemalt levima hakkasid, tehti enamus ETL protsessidest käsitsi – kirjutati väga suuri ja keerulisi SQL päringuid, mis andmeid lugesid ja teisendasid. Tänapäeval pakub pea iga suurem andmeaidandusega seotud tarkvaratootja (BusinessObjects, Microsoft, Oracle) välja oma ETL tööriista, mis peaks graafilise kasutajaliidese ja koodi genereerimise abil ETL protsessi kiirendama. ETL programmeerimine võib Ralph Kimballi (8) väitel võtta kuni 2/3 andmeaida füüsilise realiseerimise ressurssidest. Tuntud IT konsultatsioonifirma Gartneri statistika kohaselt on ETL tööriistade arendamisele hakanud suurt tähelepanu pöörama just andmebaasisüsteemide tootjad (kuna see on üks müügiargument) ning üldse väheneb käsitsikirjutatud koodi osa andmeaitade rajamisel.

19

Joonis 5. Trendid ETL tööriistade kasutuses (9). Andmete uuendamise sageduse üle aidas on samuti erinevaid arvamusi. Olen puutunud kokku andmetega, mida laetakse OLTP süsteemidest ühel korral kuus, ühel korral nädalas ja ühel korral päevas. Seoses arvutiriistvara arenguga on kõneldud ka reaalajas ETL protsessidest – s.t. sündmused andmetega OLTP süsteemides tingivad kohese andmete laadimise andmeaita, kuid Gartner-i (9) uuringu järgi ei vaja enamus ettevõtteid praegu veel niisugust operatiivsust. Aidale suunatud päringud haaravad korraga pikema ajaperioodi andmeid, kui jooksva päeva või nädala andmed muuta suudaksid.

Joonis 6. ETL toimumise sagedus andmeaidas (9)

1.3.2.2 Presentatsioonikiht Presentatsioonikiht on andmebaas ja andmemudel, milles puhastatud andmed esitatakse kasutaja jaoks sobival kujul. Presentatsioonikihi põhiline eesmärk on anda selge, ühtne ning intuitiivne vaade andmetele. Presentatsioonikihi andmemudeli üle on palju vaieldud – eelkõige selle üle, kas peaks kasutatama normaliseeritud või dimensionaalset andmemudelit. Viimasel ajal domineerib dimensionaalne andmemudel. Dimensionaalse modelleerimise üks tulisemaid eestvedajaid on andmeaidanduse guru Ralph Kimball.

2001

5%15%

80%

DBMS tootjad

Iseseisvad ETLtootjad

Isekirjutatudkood

2005

30%

20%

50%

DBMS tootjad

Iseseisvad ETLtootjad

Isekirjutatudkood

2002

17%

17%

55%

11%

1 kuu1 nädal1 päevreaalajas

2006

3%

24%

44%

29% 1 kuu

1 nädal

1 päev

reaalajas

20

Tom Haughey (10) esitab alternatiivse nägemused, väites, et normaliseeritud mudel sobib andmeaida arendamiseks kontsptuaalse mudelina paremini kui dimensionaalne mudel, kuna normaliseeritud mudel on üldotstarbeline ja peegeldab äri paremini. Dimensionaalne mudel sobib samas hästi implementeerimiseks (kuna on optimiseeritud SELECT päringutele) ja soovitab andmeaitade arendamisel luua kontseptuaalsel tasemel normaliseeritud andmemudeli ning füüsilisel realiseerimisel denormaliseerida see tähtskeemiks. Dimensioonilist mudelit tuleks eelistada(10):

• andmevakkade ehitamisel – tegu on piiritletud ärivaldkondade ja väikese analüüsivaldkonnaga,

• kui relatsiooniline mudel on liiga aeglane, • andmete agregeerimisel ja summeerimisel, mil dimensiooniline mudel on

andmete loomulik olek. Normaliseeritud mudelit tuleks eelistada (10):

• keskse andmeaida jaoks – et säiliks üldpilt ärist, • kui relatsiooniline mudel töötab piisavalt kiiresti, • kui andmed peavad olema üldised, • kus peab olema maksimaalne ad hoc pärinugte tugi.

Joonisel 4 olen lähtunud Ralph Kimballi (4) (8) väljapakutud andmeaida arhitektuurist mil andmeait koosneb hulgast ühiseid dimensioone omavatest andmevakkadest.

1.3.2.3 Kasutajarakendused Presentatsioonikihi andmeid kasutatakse erinevate rakendusprogrammide abil - aruannetes, andmekuubikutes (OLAP), andmekaevandamises, vastustena ad hoc päringutele jne. Mõned näited kasutajaprogrammidest:

• Business Objects InfoView, • Hummingbird Enterprise Information Portal, • Informatica PowerAnalyzer, • Oracle Application Server Portal, • SAP Enterprise Portal, • Cognos PowerPlay.

1.3.3 Mõisted 1.3.3.1 Tähtskeem Tähtskeem on dimensionaalne andmemudel, mille eesmärgiks on pakkuda:

• lakoonilist ja intuitiivselt mõistetavat mudelit ärikasutajale, • head kiirust SELECT päringute osas, • kerget andmete agregeeritavust,

21

• intuitiivset andmete. Tähtskeem koosneb dimensiooni- ja faktitabelitest. Dimensioonitabelid sisaldavad reeglina (võrdlemisi väikest hulka) peamiselt tekstiväljadest koosnevat informatsiooni. Faktitabelid koosnevad hulgast välisvõtmetest, mis näitavad dimensioonidele ning arvulistest veergudest, mis näitavad dimensioonidekomplekti mingit omadust. Dimensioonitabelisse pannakse nende olemite andmed, mida me mõõdame – näiteks tooted, kliendid, tarnijad, ettevõtte osad, aeg. Faktitabelisse pannakse mõõdikute väärtused (toote müügimaht kuupäevade, kaupluste, müüjate ja klientide kaupa). Näiteks:

Joonis 7. Tähtskeem Niimoodi iseloomustab faktitabeli kirje 10, 555, 101010, 09.07.2005 10:10:10.00, 61.20 sündmust, mil klient identifikaatoriga 10 ostis kuupäeval kauplusest 555 toote koodiga 101010, makstes selle eest 61.20. Päringutes saame faktitabeli kirjeid kergesti grupeerida ja agregeerida (liita, kokku lugeda, leida miinimumi, maksimumi). Dimensioonitabelid võivad sisaldada denormaliseeritud hierarhiaid (veergudes näiteks "toode", "toote_grupp1", "toote_grupp2"), mille alusel saame päringutes andmeid veelgi täpsemalt grupeerida ja filtreerida.

1.3.3.2 Andmevakk Mõistel andmevakk on mitu tähendust. Esitan siin Ralph Kimball poolt propageeritava, kuna see paistab reaalsuses enim levinud olevat. Andmevakk on "mini-andmeait" – andmeait ühe piiritletud äriprotsessi jaoks. Enamasti koosneb andmevakk tähtskeemidest.

Fakt

Klient_id Kauplus_id Toode_id Kuupäev Ostusumma

Dim Klient

Klient_id ... ... ... ...

Dim Kauplus

Kauplus_id ... ... ... ...

Dim Toode

Toode_id ... ... ... ...

22

Andmevakk võib olla kas iseseisev (omades eraldi ETL protsessi ja staging area't), see võib kuuluda andmeaida presentatsioonikihi hulka. Sellisel juhul on ETL ja staging area ühine mitmetele vakkadele, samuti võib esinede ühiseid dimensioone. Andmevakk võib olla andmeallikaks andmeaidale (sellisel juhul on igal vakal oma allikad ja ETL protsess ning andmeait laeb oma andmeid neist vakkadest). Andmevaka ja andmeaida sarnasused ja erijooned (9) Andmeait Andmevakk • rakendustest sõltumatu • tsentraliseeritud • kogu äri haarav • kergelt denormaliseeritud andmemudel• suur hulk allikasüsteeme • ehitatakse kuni paar aastat • dünaamiline, laiendatav, laienev • andmekeskne

• võib olla rakendusekeskne • osakonnaspetsiifiline • ärivaldkonnaspetsiifiline • denormaliseeritud andmemudel • väike hulk allikasüsteeme • ehitatakse kuni pool aastat • vähe muutuv • projektikeskne

Tabel 1. Andmevaka ja andmeaida sarnasused ja erijooned (9).

1.3.4 Alternatiivsed lähenemised andmeaida arhitektuurile Eelnevalt näidatud andmeaida ülesehitus ei ole sugugi ainuke võimalus. Toon mõned näited andmeaida süsteemide arhitektuurilistest lahendustest. 1) Normaliseeritud andmemudel Andmeaida andmemudeliks (s.t. presentatsioonikihiks) on üks suur normaliseeritud relatsiooniline andmebaas. Eelised: väga dünaamiline ja võimalusterohke andmemudel, kiirelt ehitatav. Probleemid: normaliseeritud mudelist on keeruline aru saada, päringute kiirus võib kannatada. 2) Andmevakad presentatsioonikihiks Andmeaidal on keskne ETL ja staging area, presentatsioonikihiks on andmevakad, mis laevad admeid ühisest staging areast. Eelised: kiire, kergesti laiendatav, lihtsalt arusaadav mudel. Probleemid: kui erinevatel aegadel rajatavad andmevakad ei jälgi kogu organisatsioonile vajalikku dimensioonide, granulaarsuse mudelit, siis ei pruugi tekkida ühtset vaadet ettevõttele. 3) Iseseisvad andmevakad Igal andmevakal on oma ETL ja staging area, andmeaidaks nimetame nende vakkade kogumit. Eelis: hästi kohandatav ettevõtte allüksuste jaoks. Puudus: miski ei garanteeri, et tekiks andmete mõttes üldvaade ettevõttele.

23

1.3.5 Andmeaitade arengutee Andmeaitade ilmumine ning äriintelligentsi rakenduste laialdane levik on olnud tihedas seoses (relatsiooniliste) andmebaasisüsteemide arenguga. Esimesed andmebaasisüsteemid loodi 1960ndatel aastatel, pioneerideks võiks lugeda Charles Bachman'i (arendas esimese DBMS-i) ja Edgar Codd'i (avaldas 1970. aastal relatsioonilise andmebaasi kontsepti). 1960ndad olid ka ekspertsüsteemide (decision support systems) esimeste tunnusjoonte arenemise ajastu. 1970ndatel arenesid jõudsalt juhtimisinfosüsteemid, loodi esimesed multidimensionaalse andmeanalüüsi tööriistad ("Express" aastal 1970). 1983. aastal alustas W.H. Inmon andmeaida sarnase analüütilise andmebaasisüsteemi põhimõtete uurimist ning arendamist. 1985. juurutati firmas Procter & Gamble esimene äriintelligentsi süsteem, mis analüüsis kassasüsteemi andmeid. 1980ndate lõpp ning 1990ndate algus oli andmeaitade ja äriintelligentsi rakenduste põhimõtete kiire arengu ja idee laiema leviku periood. Sealt edasi kuni tänapäevani on andmeaida tunnused rafineerunud ning uurimuste fookus on liikunud teabeohjesüsteemide (knowledge management) poole. Andmeaitade põhiline areng on toimunud ja toimumas standardiseerumise suunas. Paika on loksunud arhitektuuripõhimõtted (enamlevinud ülesehituseks järgmises jaotises toodud mudel), dimensionaalse modelleerimise olemus ja kasutusvaldkonnad, peamised andmeanalüüsi algoritmid ja metodoloogiad, mille eest ettevõtted on nõus maksma (affinity grouping, market basket analysis, clickstream analysis), andmekuubikute tööriistad. Areneb ning levib Object Management Group-i Common Warehouse Metamodel – standard metaandmete kirjeldamiseks ning vahetamiseks. Äriintelligentsi rakenduste arengutee

• Pliiats, paber ja kalkulaator • Tabelarvutussüsteemid • Juhtimisinfosüsteemid (Executive Information Systems) • Tootjaspetsiifilised andmeaidad, OLAP tööriistad • Standardsetest komponentidest koosnevad andmeaidad, OLAP tööriistad • ? (teabeohjesüsteemid)

Autor on andmeaitade arhitektuuriotsuste tegemise suhtes jesuiitlikul seisukohal, et eesmärk pühendab abinõu. Otsus, millist lahendust eelistada, selgub ettevõtte olemusest ja aida arendusprotsessi eripäradest lähtuvalt. Selles töös uurin edaspidi andmeaida arendamist eelkõige aspektist, KUIDAS analüüsida äri / kirjeldada nõuded niimoodi, et tekiks kõige optimaalsem andmevakkade struktuur – et arendataks kõige paremini äriküsimusi lahendav ait. Tähelepanu pööran andmeaida andmemudeli väljatöötamisele ja ETL kirjeldamisele.

24

1.4 Tarkvarasüsteemide levinumad arendusprotsessid

Tarkvarasüsteemide kui suhteliselt keeruliste ning kallite projektide arendamiseks on ajalooliselt kasutatud mitmeid standardeid ja metodoloogiaid. Vaatlen siinkohal kolme olulisemat rühma, mida võib tarkvara arendusprotsessides eristada ning analüüsin nende sobivust/kasutatavust OLTP ja BI süsteemide arendamiseks. Tarkvarasüsteemi arendamist võib võtta kui tavalise inseneriprojekti läbiviimist – nagu laeva või maja ehitamist. Võime lähtuda, et kõigepealt uurime, mida tegema peaksime (analüüs), seejärel mõtleme välja, kuidas seda tegema peaksime (disain ja arhitektuur), siis teeme eelpoolkirjeldatu füüsiliselt ära (ehitamine), kontrollime, kas tuli õigesti välja (testimine), anname kliendile üle (integreerimine) ning hilisema tarbimise jooksul aeg-ajalt hooldame oma toodet (hooldus).

1.4.1 Kosemudel 1970. aastal formuleeris ja W. W. Royce sarnase lineaarse etappidest koosneva protsessi tarkvara arendamiseks, nimetades selle kosemudeliks (waterfall model). Kosemudeli järgi jaotati tarkvara arendamine eelpoolmainitud sammudeks, need sammud käidi lineaarselt läbi ning niimoodi saigi sisendist (vajadus, nõudmised ja teadmine) väljund (tarkvara).

Joonis 8. Kosemudeli arendusetapid Kosemudeli arendusetappe võib olenevalt subjektiivsetest eelistustest nimetada erinevate nimedega või jagada detailsemalt või üldisemalt, ent protsessi sisu jääb samaks – lineaarne ühekordselt läbitav tegevuste jada, mille abil muudetakse nõudmised ja vajadused raha, teadmiste ning tööriistade abil tarkvaraks.

Analüüs

Disain

Implementatsioon

Testimine ja integreerimine

Hooldus

25

Reaalses maailmas pole aga olukord nii lihtne ja lineaarne, nagu kosemudel seda ette näeb. Tarkvarasüsteemid on keerulisemad, dünaamilisemad ja kiiremini muutuvad, kui klassikalised inseneriprojektid. Tarkvarasüsteemid tegelevad äriprotsesside, erinevates rollides inimeste ning IT-vahenditega, mis on pidevas muutumises, arengus. Kosemudeli suurim puudujääk on selles, et vead, mis on tehtud varasemates arendusetappides ei ole hiljem kergelt muudetavad ning tihti võimenduvad igal edasisel sammul. Seetõttu on kosemudel arendusprotsessina pigem ideaal või utoopia, mis reaalses maailmas, ärivara arendamisel pigem tagasilööke annab. Tarkvarasüsteemi projekti erijooned tavalise inseneriprojektiga võrreldes:

• Tegeleb "pehmete" ja raskestiformaliseeritavate valdkondadega, nagu äriprotsessid, inimkasutajate mugavus.

• Nõudmiste ja tellimuste esitajad ei ole eksperdid infotehnoloogia valdkonnas, projekti arendajad ei ole eksperdid kliendi tegevuses – seetõttu ei suudeta leida ühist keelt ja/või räägitakse sageli üksteisest mööda.

• Isegi kui suudetaks vajadused arenduse alguses detailselt ja õigesti kirjeldada, muutuvad need pea kindlasti projekti käigus ning kosemudel ei suuda selliseid muutuseid arvesse võtta.

Aastad 1970 – 1980 oli kosemudeli kasutamise kõrgajaks. Kuigi paljukritiseeritud, oli kosemudel enamuse suurorganisatsioonide (USA Kaitseministeerium, IBM, jpt) ametlikuks arendusprotsessiks. Seda perioodi on nimetatud ka "tarkvarakriisi ajastuks" (6), mil tarkvara arenduses tekkisid esimesed suured ja laia kõlapinda leidnud tagasilöögid, kallid nurjumised ning tarkvaravigadest tekkinud õnnetused. Craig Larman toob välja, et aastal 1999 tehtud kokkuvõtete järgi nurjus USA ühe suurima tarkvara arendaja ja tellija - USA Kaitseministeeriumi kosemudeli alusel arendatud projektidest 75% ning ainult 2% juhtudest läks toodetud tarkvara kasutusse ilma oluliste muudatusteta (6).

1.4.2 Iteratiivsed ja inkrementaalsed protsessid Craig Larman (6) toob välja, et iteratiivne ja inkrementaalne mõtteviis inseneri juures on üllatavalt vana. Nähes, et kõik inseneriprojektid pole identsed ning esineb juhtumeid, mil projekti kirjeldus on muutlik, pakuti juba arvutiajastu eel väga alguses välja alternatiivseid arendusmeetodeid. 1930ndatest aastatel pakkus W. Shewhart (Bell Laboratories) välja tsüklilise "plan-do-study-act" teooria inseneriprojektide kvaliteedi parandamiseks. Laias laastus sarnaneb see teooria praeguste iteratiivsete ning inkrementaalsete või spiraalsete tarkvara arendusmeetoditega, mille eesmärgiks on haarata korraga alamosa kogu süsteemist, see alamosa realiseerida ning siis valida arendamiseks uus alamosa, hoides tihedat sidet kasutajaga ning üritades pidevalt muutuvate nõudmistega sammu pidada. Iteratiivne tarkvaraarendus sai alguse projektidest, kus nõudeid polnud võimalik projekti alguses piisava täpsuse või ulatusega defineerida, ent mis ometi olid missioonikriitilised. Kosemudelit täiustati mitmeti – ühelt poolt hakati seda läbima mitmekordselt, iga iteratsiooni järel klientidelt tagasisidet korjates, küll tehti analüüsifaas alguses ühekordselt ning ehitati suur tarkvarasüstem inkrementaalselt.

26

1980ndatel hakkas iteratiivse arenduse pooldajate sõnum valjemini kõlama (1986 avaldasid David Parnas and Paul Clements artikli “A Rational Design Process: How and Why to Fake It”, kus tõid esile kosemudeli eelpoolmainitud nõrkusi ning soovitasid iteratiivset arendust) – tarkvarakriisi ajastust õpiti. 1990ndad aastad olid iteratiivsete ning inkrementaalsetele arendusprotsesside kiire kasvu ajaks ning domineerimise alguseks. 1995. aastal astus iteratiivse arenduse paati Microsoft Corporation, alustades arendatavate rakenduste igaöise kompileerimisega. 1990ndate keskel töötasid Rational Corporation töötajad (sh. Krutchen, Walker, Royce) ning kliendid välja praeguseks iteratiivsete arendusprotsesside hulgas de facto standardiks saanud Rational Unified Process-i. RUP on suhteliselt lai arendusraamistik, koosnedes müriaadist notatsioonidest ning andes arendajatele võimaluse iseenda tarbeks kohandada alamosa pakutavatest meetoditest ja dokumentidest. Iteratiivse ja inkrementaalse arendusprotsessi põhilised omadused: Projekti alguses pannakse kokku üldvaade süsteemile, laskumata detailidesse. Edasine tegevus jaotatakse tsükliteks (kestvusega näiteks paarist nädalast paari kuuni). Iga tsükli eel täpsustatakse nõuded süsteemi alamosale, mida realiseerima asutakse, pidades kinni üldvaatest tehakse disainiotsused, ehitatakse, testitakse ning antakse tulemus üle kasutajale. Tagasiside alusel tehakse muudatused nõudmistesse, pannakse kokku pilt muutunud nõuetest ning minnakse uue funktsionaalsuse realiseerimisega järgmisele ringile. Arendus lõpeb, kui kogu süsteem on realiseeritud. Eelised ning puudused:

• mugav arendamiseks ebakindlas reaalses maailmas – suudab kosemudelist paremini seista analüüsi- ja disainietapil tehtud vigade ning ebakõlade vastu,

• arvestab kasutajate tagasiside ning muutuvate nõudmistega, • annab esimesed tulemused kätte kiiresti, • tähtaegade ja kulutuste haldamine on lühikeste tsüklite korral lihtsam, • on juhtimise mõttes segasem, keerulisem on jälgida projekti tegelikku arengut

ning keerulisem on määrata, millal projekt lõpetada, • kasutajate pidev kaasamine arendusprotsessi pikendab arendust ning tõstab

arenduse hinda, • võib tekkida skoobi pidev ja kontrollimatu suurenemine – "scope creep". S.t.

projekti ei suudeta piiritleda ja arendamisel ei suudeta näha terviklikku pilti ettevõttest.

27

Üks võimalik tegevuste jada iteratiivses arenduses:

Joonis 9. Üldise iteratiivse arendusprotsessi üks võimalik tegevuste jada.

1.4.3 Agiilmetoodikad – samm hägususe poole Iteratiivsete ja inkrementaalsete arendusprotsessidega võrreldes sammu formaalsusest veelgi kaugemale on astunud tarkvara arendamise agiilmetoodikad. Agiilmetoodikate läbivateks omadusteks on:

• väike tihedalt suhtlev meeskond, • nõuete kirjeldused mitteformaalsed ja nõuded ise suures ulatuses muutuvad, • kliendid tihedalt arendustegevusse seotud, • vähe dokumentatsiooni (odavam), • time-boxing (iteratsiooni kestvusel on ajapiirang, mitte funktsionaalsuse

valmisjõudmise piirang – see funktsionaalsus, mida ajapiirangu sees valmis ei jõuta, jäetakse edaspidisteks iteratsioonideks).

Agiilmetoodikad seavad esikohale arendusprotsessi selguse ning kergekaalulisuse, tiheda koostöö meeskonnasiseselt ning kliendi aktiivse kaasamise arendusse. Agiilmetoodikate abil saab edukalt rajada väikeseid ja mitte missioonikriitilisi rakendusi, ent need ei ole enamasti kasutusel suurtes arendusmeeskondades, hajutatud või missioonikriitiliste süsteemide puhul, kuna suures meeskonnas saab mitteformaalsest arendusest väga kergesti kaos. Agiilmetoodikad said populaarseks 1990ndate keskel, autori hinnangul suuresti seotuna Interneti kiire leviku ning sellest tingituna paljude väikeste mitteformaalsete tarkvara arenduse projektide ilmumisega (".com" palavik, paljude tarkvaratoodete liikumine kasutaja veebilehitsejasse). Osaliselt on agiilmeetodid vastureaktsiooniks "raskekaallastele" arendusprotsesside hulgas, nagu RUP ja Capability Maturity Model.

Esialgne äri modelleerimine ja

planeerimine Analüüs ja disain

Ehitamine

Tulemite hin-damine, järel-duste tegemine

Testimine

Juurutamine

Nõudmiste väljaselgitamine

28

Kuna andmeaida ja äriintelligentsi süsteemid on suured, tervet organisatsiooni hõlmavad ning selle andmeid integreerivad projektid, siis ei ole agiilmetoodikad nende arendamiseks kuigivõrd otstarbekad ega seetõttu ka levinud. Seetõttu jätan need edasise uurimise alt välja.

1.4.4 Statistikat iteratiivse arendusprotsessi kasutamise kohta Ettevõte, mis soovib alustada iteratiivse arendusprotsessi alusel tarkvara tootmist, seisab silmitsi üsna suure ja kariderohke ülesandega. Iteratiivsed protsessid võivad küll tunduda kosemudelist vähem formaalsed, ent reaalsuses nõuavad need head ettevõttesisest kommunikatsiooni, väga head projektijuhtimist ning tihedaid suhteid kliendiga. IT konsultatsioonifirma Lamri on avaldanud uurimistulemused arendusprotsesside kasutuse kohta neilt konsultatsiooni otsinud ettevõtetes. Siin toodud uurimuse (7) valimiks on 40 ettevõttet Lamri "Moving To Risk Driven Iterative Development" seminarilt. Võime eeldada, et ettevõtted, mis on valmis ostma sisse konsultatsiooniteenust iteratiivse arendusprotsessi juurutamiseks: a) kasutavad mõnda mitteiteratiivset protsessi ning ei ole sellega rahul, b) üritavad kasutada iteratiivset arendusprotsessi, ent seisavad probleemide ees. Seetõttu tuleks järgnevalt toodud uuringutulemusi võtta kui hulga iteratiivset tarkvara arendusprotsessi juurutavate või kasutavate ettevõtete kogemust. Uuringust (7) nähtub, et enamus ettevõtteid on pööranud pilgu uue arendusprotsessi juurutamisele, et tõsta tootlikkust või parandada toote kvaliteeti (suurusjärgus ¾ vastajatest). Uuringus osalenutest kasutab enam kui 50% ettevõtetest tarkvara loomiseks siiani mingit variatsiooni kosemudelist. Ülejäänud ettevõtted kasutavad peamiselt iteratiivseid arendusprotsesse (7).

29

Millist arendusprotsessi kasutate

0% 10% 20% 30% 40% 50% 60%

Kosemudel

Iteratiivne

Pole aimugi

Joonis 10. Arendusprotsesside kasutus Lamri uurimuse (7) alusel. Lähtudest eeltoodud tulemustest, et enamus vastanutest kasutab kosemudelit ning et enamus neist pole rahul toote kvaliteedi ning töötajate produktiivsusega. Siit võin tõmmata paralleeli kosemudeli ja toote kvaliteedi vahel. Töötajate madala produktiivsuse seostaksin pigem arendusprotsessi mittekasutamise või selle mittejärgimisega igapäevatöös kui mõne üldlevinud protsessiga. Iteratiivsetest meetoditest juhib RUP suurelt - 45% kõikidest iteratiivse protsessi valinud vastanutest kasutavad RUP-i ning 30% mõnd ise kokkupandud arendusprotsessi. Arvestades, et RUP raamistikuna pakub hulganisti võimalusi seda ettevõtte jaoks kohaldada, baseerub tõenäoselt suur osa neist 30% ise kokkupandud arendusprotsesidest Rational Unified Processil.

Iteratiivsete arendusprotsesside kasutus

0% 10% 20% 30% 40% 50%

RUP

DSDM

XP

SCRUM

Ise defineeritud

Muu

Joonis 11. Iteratiivsete arendusprotsesside osakaalud Lamri uurimuses (7).

30

Iteratiivse arendusprotsessi juurutamisega parajasti tegelevatest ettevõtetest vastas lõviosa (9/10 vastanutest), et neil on sellega probleeme. Uurimusest võime järeldada, et kosemudeli kasutamisega on seostatavad kvaliteediprobleemid ning arendusprotsessi mittejärgmisega igapäevatöös madal produktiivsus. Näeme, et arendusprotsessi muutmine ettevõttes toob tõenäoselt kaasa probleeme. See, et uuringus osalenud ettevõtetest ei märkinud keegi end agiilprotsessi kasutajaks tuleneb tõenäoselt sellest, et agiilmetoodikad on "edasijõudnute tase" ning otse kosemudeli protsessist agiilmetoodikale kohanemine on väga vähe levinud.

1.5 Andmeaida süsteemi rajamise erijooned arendusprotsessi

seisukohalt

Andmeaida süsteemi rajamine on ettevõtte jaoks pikaajaline ja kallis ettevõtmine. Õnnestunud andmeait annab ettevõttele eluliselt vajalikku äriinformatsiooni ning selle aluselt tehtud kasulikud/innovaatilised äriotsused tasuvad aida rajamise ära kordades. Keskmine andmeaida rajamise projekt USA-s kestab kaks aastat ning selle eelarve on suurusjärgus kaks miljonit dollarit (15). Häiriv statistika (15) näitab samas, et umbes iga teine andmeida projekt kukub kas osaliselt või täielikult läbi. Väga tihti peituvad läbikukkumise põhjused ebaõnnestunud nõuete analüüsis (16) (8) – andmeait, milles olevad andmed ja millelt kokkupandud raportid ei ole äriotsuste tegemiseks sobivad või olulised, mille andmed ei uuene piisavalt tihti või mis ei kata õiget ärivaldkonda, on määratud hääbumisele. Ait rajatakse selleks, et muuta äriotsused "paremaks" – vaade ärile terviklikumaks, aruandlus kiiremaks ja laiahaardelisemaks, võimadada vastused ettemääramata äriküsimustele, jpm. Nagu näha, on enamus siintoodud aida headuse kriteeriumitest hägusad, raskesti mõõdetavad. Teiselt poolt kumab enamuses aida eesmärkides sõna "äri". Seetõttu tuleb aida rajamisel seada keskseks ettevõte/äri ning alustada äriprotsesside modelleerimise ja ärinõuete õige defineerimisega – liikumine ärilt tehnoloogiale toimub siis, kui meil on selge mida on vaja teha. Andmeaida edukuse peamine kriteerium on ärikasutajatele antav informatsiooniline lisaväärtus – õigete andmete esitamine. Data warehousing is a solution to a business problem. Business problems are identified by and solved by users2. Sean Nolan & Tom Huguelet (17) Andmeait on äri- ja andmekeskne süsteem, samas kui OLTP rakendused on tegevusekesksed. Operatsioonilise süsteemi rajamisel keskendume tegevuste modelleerimisele – nõuded defineeritakse reeglina tegevuste jadana, mille tulemusena liigub süsteem ühest seisundist teise. 2 Andmeaida eesmärk on äriprobleemide lahendamine. Äriprobleemid tõstatavad ja lahendavad ärikasutajad.

31

Äriintelligentsi süsteemide puhul on tegevused kasutaja jaoks suhteliselt ettemääratud ning seetõttu ei ole need nõuete analüüsil kesksed – tegevused tulenevad infovajadustest. Aruandlus, graafikud, andmekuubikud, mõõdikud, ad hoc päringud on kõik sooritatavad mingite valmiskirjutatud rakendustega. Keskenduma peame hoopis sellele milliseid andmeid kasutaja näha tahab alles seejärel huvituma, millises vormingus talle seda kõige parem kujutada oleks. Ärinõuete kogumine (infovajaduste väljaselgitamine, nende sobitamine olemasolevate andmetega) on andmeaida rajamise protsessi olulisim osa (4).

Andmeaida headus sõltub lõppkokkuvõttes selles olevate andmete kvaliteedist ja kasutatavusest. Dimensionaalse andmemudeli valimise korral on suhteliselt paigas isegi andmemudeli kuju (tähtskeemi loogika mõttes), vaja on kokku sobitada õiged olemid, mida mõõdetakse (dimensioonid) ning nendega seotud vajalikud mõõdikud (faktid). Kuna andmeaida rajamisel modelleeritakse tihti ettevõtet tervikuna, on seda võimalik seostada äriprotsesside ümberkujundamisega (ingl. k Business Processes Reengineering) (18).

Erinevate andmebaaside, UI-rakenduste, päringutööriistade ja infrastruktuuri analüüs ja rakendamine on kõrvaltegevused, mis lähtuvad ärinõuetest ja infovajadustest.

Andmeaida süsteemi rajamise erijooned arendusprotsessi seisukohalt: • Andmekeskne, mitte tegevusekeskne rakendus – keeruline on defineerida

nõudmisi tegevusepõhiselt (näiteks kasutusjuhtudena, mis põhimõtteliselt peegeldavad mingit operatsiooni süsteemi seisundi muutmiseks).

• Keskne mõiste on "äri" – aida edukuse peamine võtmetegur on selle toetus äriotsuste tegemisel, seega on ettevõtte kui terviku mõistmine väga oluline.

• Hästi rajatud andmeaida juurutamise järel saavad ärikasutajad teada paljut, mida nad arenduse ajal ei teadnud (näiteks andmete seostamise, klasterdamise järgi), sellest lähtuvalt tekivad uued vajadused, nõudmised (15).

• Arhitektuur ja kasutajarakendused on suhteliselt ettemääratud, tundmatuks on see, milliseid andmeid ja mil viisil peaksime ärikasutajale näitama, et see tema tööd kõige paremini toetaks.

• Sõltub mitmetest heterogeensetest allikasüsteemidest, läbib kogu organisatsiooni – seetõttu tuleb suurel määral tegeleda integreerimisega.

• Andmeaida rajamine on pidev protsess – ait on aktiivne ja muutuv süsteem, kuna äri muutub, ärivajadused selginevad ja teisenevad ning otsuste jätkuvaks toetamiseks peab ka ait arenema.

• Äri modelleerimise tõttu võib andmeaida arenduse seostada Business Process Reengineering (äriprotsesside ümberkujundamine) tegevustega.

• Andmeaida tulu, rentaablus (Return Of Investment) peitub otsustes, mida selle baasilt tehakse, mitte tegevustes, funktsioonide või kasutajate arvus.

The most successful data warehouses will take an enterprise view of the requirements, perform a quick analysis of the information need to support all requirements, then work deeply in one area to build the first incrementof the DWH. Doug Ebel – NCR Business Solutions Architect, Data Warehousing – Start to Start

32

1.6 Arendusprotsesside kasutus andmeaitade rajamisel

Andmeaitade rajamise kogemust on maailmas pea paarkümmend aastat, sarnaste äriintelligentsi süsteemide arendamisega on tegeletud alates eelmise sajandi kuuekümnendatest. Samas õnnestub leida vähe autoreid, kes oleksid parima andmeaida süsteemi arendusprotsessi olemuse osas päris ühel meelel. Arvamusi ja pakutud protsesse, lahendusi dokumenteerimiseks ja arhitektuuriotsuste tegemiseks on pea samapalju kui autoreid. Ühes tõigas – arendusprotsessi iteratiivsuses – on aga valdav enamus allikad, mida peetakse oluliseks ja millele viidatakse, ühel meelel. Tulenevalt andmeaida süsteemi eripäradest - ärinõudmiste spiraalsest tekkimisest (nõudmiste ja vajaduste tekkimine on pidev protsess, nõudmised tekivad süsteemi või selle osade kasutusse võtmisel), äri muutuvast iseloomust, aida projekti suurest mahust, kõnelevad kõik olulisemad autorid spiraalsest, iteratiivsest ja inkrementaalsest, agiilsest või lihtsalt tsüklilisest arendusprotsessist. Nimedena spiraalse arenduse pooldajatest ning propageerijatest näiteks andmekeskselt lähenev "andmeaitade isa" W. H. Inmon, dimensionaalse modelleerimise pooldaja ja tuntud andmeaitade lahenduste praktik Ralph Kimball. Nende kahe teostele (3)(4)(8) toetuvad korduvalt ka tarkvarahiidude Microsoft ja Oracle autorid firmade ametlikes õpetustes ja käsiraamatutes, näiteks allikates (17) ja (19). Kosemudeli nõrkustest mistahes äritarkvara arendamisel oli juttu eespool. Oma rigiidsuse tõttu see äriintelligentsi süsteemide ehitamisse ei sobi. Agiilmetoodikatest ei räägita eriti ning neid ei praktiseerita andmeaitade rajamisel kuigi oluliselt, kuna andmeaida arenduses on OLTP süsteemidest oluliselt enam interaktsiooni infotehnoloogide ja ärikasutajate vahel ning seetõttu on vaja agiilmetoodikatest pisut formaalsemat ja "raskemat" protsessi. Arendusprotsesse liigitatakse mitmeti. Olenevalt ettevõetud nõudmiste haardest ja lähenemisest ettevõttele võib eristada big bang (suur pauk), top-down (ülalt alla) ja bottom-up (alt üles) lähenemist, olenevalt nõudmiste kogumisest data-driven (andmekeskset), process-driven (protsessikeskset) ja user-driven (kasutajakeskset) arendust. Lisaks nimetavad mitmed autorid iseloodud arendusprotsessi – Ralph Kimball koondab enda väljapakutu nime "Business Dimensional Lifecycle" alla (4)(8), Larissa T. Moss ja Shaku Atre kutsuvad enda visiooni "Business Intelligence Roadmap" (20) (seda protsessi propageerib ka W.H. Inmon (20)). Vähemtuntud teooriatest tasub mainida Cliff Longmanni kirjeldatud protsessi nimega "Data Warehouse Lifecycle Management" (15) ning mitmeid dokumenteerimismeetodeid ja arhitektuurilahendusi – DWARF (16), kasutusjuhtude defineerimine äriintelligentsi süsteemi jaoks (21), "Enterprise Modeling Framework" (22)). Kirjutan eelnevalt toodud liigitused ning protsessid konteksti tekitamiseks definitsioonide tasemel lahti. Hiljem reaalse maailma arendusprotsessi analüüsides kasutan osi siintoodud mõistetest.

33

1.6.1 Süsteemi tükeldamisest lähtuv lähenemine aidasüsteemi arendamisele: Suur pauk (big bang)

Terve andmeait ehitatakse korraga ühe suure projektina. See tähendab, et ettevõtet käsitletakse tervikuna, tulemiks on kõiki soovitud äriprotsesse haarav süsteem. Big bang ei välista iteratiivset arendusprotsessi, kuna arenduse sees võib nõuete defineerimiseks, analüüsiks ja ehitamiseks kasutada tsükleid. Sellest hoolimata jõuab süsteem kasutajate ette ühekorraga ning täies mahus. "Suurt pauku" ei saa lugeda iteratiivsele arendusprotsessile sobivaimaks lahenduseks. Pigem varitsevad seda lähenemist valides tüüpilised kosemudeli rakendamise ohud – testgrupi kasutajate tagasiside prototüübile/rakenduse fassaadile ei pruugi ilmutada olulisi vajadusi/nõudmisi. Seetõttu peab reaalse maailma big bang projektides olema tahes-tahtmata mitu iteratsiooni.

Üldiselt üksikule (top-down)

Selle lähenemise korral analüüsitakse kõigepealt süsteemi üldisena – luuakse terviklik vaade ettevõttele, seejärel keskendutakse detailsemale analüüsile ja arendusele süsteemi osade kaupa. Top-down lähenemine levis laialt struktuurprogrammeerimise ajastul 1960ndate lõpust kuni objektorienteeritud programmeerimise populaarseks saamiseni 1980ndate teisel poolel. Ülalt-alla lähenemise tuntud propageerijaks ja teoreetikuks oli programmeerimiskeele Pascal autor Niklas Wirth. Enamus eelpool mainitud andmeaida arendusprotsesse kasutab ülalt alla lähenemist. Kõigepealt luuakse ettekujutus ettevõtte kui terviku väärtusahelast ja äriprotsessidest. Seejärel prioritiseeritakse äriprotsessid andmeaita viimise osas (infost hinnanguliselt enim kasu saavad ning samas kõige kiiremalt andmeaita laetava infoga protsessid eesotsas) ning andmeait arendatakse protsesside kaupa välja. Sellist loogikat kasutab näiteks Ralph Kimball, nimetades lähenemist "Business Dimensional Lifecycle".

Üksikult üldisele (bottom-up) Vastupidiselt eelmisele jaotusele, analüüsitakse siin kõigepealt süsteemi (huvipakkuvaimaid, mingis mõttes prioriteetsemaid) üksikosi. Alamosad võidakse "üksikult üldisele" lähenemise korral realiseerida enne järgmise osa juurde liikumist. Üldvaateni jõutakse alles siis, kui kogu süsteem tükkidena on läbi uuritud ning valmis ehitatud. Probleemiks on süsteemi huvipakkuvamate osade identifitseerimine ja piiritlemine – kuna me ei evi üldvaadet, võime äriintelligentsi süsteemis ettevõtte protsessid või väärtusahela tükeldada ebaotstarbekalt. Bottom-up lähenemine sobib eriti hästi objekt-orienteeritud mõtteviisi ja hajustarkvara rakendustesse. Hajutatud vastutustega klassimudel ning hajutatud funktsionaalsusga tarkvara korral on autonoomsete tükkide analüüs, disain ja realiseerimine juba oma loomuselt bottom-up. Andmeaitade korral kasutatakse bottom-up lähenemist eelkõige pilootprojektides ja autonoomsete andmevakkade ehitamisel. Andmevakk sobib oma olemuselt bottom-up lähenemisega – see kujutab mingit alamosa üldisest süsteemist, tervikpildist huvitumata.

34

Kuna andmeaida eesmärgiks on vaade ärile ja mitte hulk koostöötavaid funktsioone (üks võimalik vaade OLTP süsteemile) ja bottom-up lähenemise eesmärgiks ega loomulikuks olekuks pole tervikvaade, siis ei pruugi me terviklikku vaadet ettevõtte ärile ka arenduse lõppedes saada.

Top-down lähenemise probleemiks on see, et süsteemi reaalne rajamine (ehitamine, testimine) saab toimuda alles siis, kui konstrueeritud on üldvaade, süsteem on tükeldatud ning valitud osiste detailanalüüs ja disain tehtud. Bottom up seevastu annab väga kiirelt kätte süsteemi mingi alamosa prototüübi, töötava lahenduse, mille alusel saab klientidelt tagasisidet. Top-down sobib andmeaitade arendamiseks keskkonnas, millest meil on lihtsalt võimalik saada ülevaade ning milles meie projekt peab lõppema sellesama üldvaatega ettevõttele. Bottom-up sobib arendamiseks eriti siis, kui nõudmised on väga vähesel määral defineeritavad, tellija on ebakindel või andmeaidast saadav kasu pole tellijale arusaadav – sel juhul on päästvaks lahenduseks rajada prototüübina bottom-up lähenemisega aida pilootprojekt, prototüüp, millest saadav tagasiside toob selgemad ärinõuded, või andmevakk.

1.6.2 Fookusalast tulenev lähenemine aidasüsteemi arendamisele See arendusmetoodikate jaotus kirjeldab kolme peamist viisi, kuidas lähtutakse tehniliste nõudmiste ning andmemudelite koostamisel (23). Andmekeskne

Andmekeskset lähenemist õigustab väide, et vastupidiselt nõuetekesksetele OLTP süsteemidele on andmeaidad puhtalt andmete kesksed ning et ärikasutaja saab tahes-tahtmata anaüüsida ainult olemasolevaid andmeid. Arendusel jäetakse kõrvale firma visioonid ning ei pühenduta kasutajate nõudmiste kogumisele. Analüüsi põhiraskus on üle-ettevõttelise andmemudeli ehitamine, tähtskeemide defineerimine (mille puhul on siiski vaja mõista ettevõtte ärimudelit ja mingil määral uurida kasutajate tegevust ja vajadusi) ning ETL programmeerimine. Põhimõtteliselt on võimalik ehitada automaatne andmemudeli denormaliseerija, mis firma normaliseeritud andmemudelist ehitab meie valitud tähtskeemid. Üks andmekeskse lähenemise põhilisi eestvedajaid on W.H. Inmon. Reaalsuses ei ole sellel lähenemisel tänapäeval palju pooldajaid, kuna on suur risk, et valminud andmeait ei ole kasutajatele mõistetav ning ei peegelda nende tegelikke analüüsitegevusi.

Protsessikeskne ehk strateegiakeskne Oluline tegur on äriprotsesside modelleerimine. Firma väärtusahel ning olulisemad äriprotsessid kaardistatakse ja viimased prioritiseeritakse andmeaidast saadava info vajalikkuse alusel. Iga äriprotsessi jaoks kaardistatakse selle olulisimad eesmärgid. Eesmärgi täitumist iseloomustavate suurustena leitakse hulk mõõdikuid. Näiteks kui tootmisprotsessi eesmärkideks on minimaalne defektide arv ja maksimaalne tootlikkus, on potentsiaalseteks mõõdikuteks defektisete detailide protsent ning kogutootlikkus. Ralph Kimball on protsessikeskse arenduse pooldaja. Kimballi arhitektuurimudeli alusel koosneb andmeait mitmest andmevakast – üks vakk iga kaardistatud äriprotsessi kohta. Andmevakkadel on läbivad dimensioonid – ettevõtte

35

väärtusahelas esinevad tähtsamad olemid (klient, toode, tarnija. jne). Andmevaka andmemudel on dimensionaalne, koosnedes hulgast tähtskeemidest. Faktitabeliteks neis tähtskeemides on äriprotsessi iseloomustavad mõõdikud. Kimballi "Business Dimensional Lifecycle" pakub välja nelja-sammulise algoritmi äriprotsessidest andmemudeli (tähtskeemi) tuletamiseks (4)(8): 1. Vali äriprotsess, 2. Vali protsessi granulaarsus (andmeallikate analüüs!), 3. Vali protsessi kirjeldavad olemid (dimensioonid), 4. Vali mõõdikud (faktid). Kimball jagab ettevõtte "protsessideks" tihti ka OLTP alliksüsteemide kaupa, mis ei lange küll teoreetilise ideaaliga (väärtusahela olulisemate tegevuste kaupa jagamisega) kokku, ent tõenäoselt on praktikas kiirem ning mugavam. Kuna lõppkokkuvõttes saab kasutajale kuvada ainult infot, mida oleme aita kogunud, tuleb protsessikeskse lähenemise korral paralleelselt siiski ka alliksüsteemide andmemudeleid analüüsida.

Kasutajakeskne Lähenemine eeldab, et ettevõtte visioon ja eesmärk on selles töötavate inimeste eesmärkide kogum. Kasutajakeskse lähenemise korral korjatakse äri liigitus protsessideks ja üksiktegevusteks, infovajadused ja äriküsimused, millele aida abil vastust otsida, kasutajatelt ning üritatakse neid nõudmisi olemasoleva reaalsuse baasil täita. Sobib see tugeva meeskonna ja hästidefineeritud äristrateegiaga ettevõtete korral, kus paljudel ärikasutajatel on visioon ka oma tuleviku infovajaduste ja otsustustoe osas. Väga suure või vähesuhtleva kasutajaskonna korral võib nõudmiste spekter saada äärmiselt suureks ning laialivalguvaks. Ohuks on see, et võttes ideaaliks kasutajate nõudmised, võib valusa reaalsuse (halvasti integreeruvate ja puudulike allikasüsteemide) korral kannatada aida andmete kvaliteet või osa nõudmistest osutuda täitmatuks. Kui avastada see liiga hilja, võib tulemuseks olla ärikasutajate usalduse vähenemine ning andmeaida projekti maine halvenemine.

Andmekeskne ja kasutajakeskne meetod liigituvad bottom-up lähenemisteks, neid peetakse otstarbekateks lühemaajalise elueaga andmeaitades (kuna nende meetodite võime äri muutusi aita "sisse programmeerida" on piiratum). Protsessikeskne meetod loetakse top-down lähenemiseks ning sobib pikema elueaga, suure arvu alliksüsteemide ning suuremahulisemate projektide jaoks.

1.6.3 Valik arendusprotsesse ja elutsükli mudeleid andmeaida arendamiseks Järgnevalt pakun välja mõned kasutatavamad või erinpärasemad arendusprotsessid andmeaitade ja äriintelligentsi süsteemide rajamiseks eesmärgiga anda kontekst hiljem väljapakutavate täiendustele ettevõtte "X" arendusprotsessi jaoks.

36

1.6.3.1 "Business Dimensional Lifecycle" – Ralph Kimball Üldiseloomustus:

Ralph Kimball (4), (8)on oma lähenemise kogunud ühtseks arendusraamistikuks, mille nime võiks eesti keelde tõlkida "ärikeskne dimensionaalne elutsükkel". Tegemist on ülalt alla lähenemisega arendusprotsessile, mis algab üldise ettevõtte äri modelleerimise ja protsessideks jaotamisega. Äri üldvaate koostamisel leitakse ühised või läbivad kirjeldajad / olemid (klient, leping, toode jne). Edasi kaardistatud äriprotsessid prioritiseeritakse ning valitakse üks neist, mille jaoks esimesel iteratsioonil andmevakk arendada. Valitud äriprotsessi kohta kogutakse täiendavalt nõudeid ning luuakse andmevaka tähtskeemid. Tegevused vakkade arendamisel on jagatud kolmeks paralleelseks haruks:

• andmed (allika analüüs, dimensionaalne modelleerimine, andmemudeli disain),

• kasutajarakendused (aruandegeneraatorid, OLAP kuupide lehitsejad, ad hoc päringute tööriistad jne),

• infrastruktuur (riistvara, arvutivõrgud, tarkvara installeerimine, kasutajaõigused, varundamine ja taastamine).

Kasutajanõudmisi kogutakse intervjuudel ja ajurünnakutel, andmeait loetakse valmisolevaks, kui kõik olulised äriprotsessid on vakkades kujutatud.

Liigitumine eelpooltoodud loeteludes: top-down, protsessikeskne

Arendusprotsessi üldine mudel:

Joonis 12. Business Dimensional Lifecycle (4)

Arhitektuurieelistused: Andmeait koosneb andmevakkadest, iga andmevakk kujutab ühte äriprotsessi

väärtusahelas. Andmevakad koosnevad tähtskeemidest, mis leitakse äriprotsessi jaoks oluliste mõõdikute ning kogu aidale ühiste dimensioonide ristamisel.

Projekti-plaan

Ärinõuete kogumine (üldvaade ärile + nõuded äri-protsesside jaoks)

Dim. modelleeri-mine

Andme-mudeli füüsiline disain

Staging area disain, ETL arendamine

Kasutaja-rakenduste valimine

Kasutajarakenduste arendamine

Tehnilise arhitektuuri disain

Infrastr. seadmete valik ja ins-talleerimine

Juurutamine

Projektijuhtimine

Hooldus ja kasvu haldamine

37

Nimeks on Kimball sellele disainimudelile andnud "The Data Warehouse Bus Architecture". Iseloomustan seda detailsemalt allpool

Andmemudel Dimensiooniline. Staging area võib olla relatsiooniline.

Head ja vead Iteratiivne ja piisavalt kergekaaluline, et reaalses maailmas populaarsust võita.

Kimball pakub välja mitmeid dokumente, mis aitaksid (DWH Bus maatriks äriprotsesside ja ühiste dimensioonide sidumiseks, toob ehitamise taseme dokumentatsiooni sisse Zachmani raamistikust).

Liiga dimensionaalse modelleerimise keskne. Arendusprotsessina võiks see anda rohkem vabadust arhitektuuriotsuste tegemisel (denormaliseeritud mudelil on omad puudused, seda eelkõige paindlikkuse osas ad hoc päringutele vastamises).

Metaandmete kogumist ei ole arendusprotsessi loomulikult sisse kodeeritud.

1.6.3.2 "Business Intelligence Roadmap" – Shaku Atre ja Larissa T. Moss Üldiseloomustus:

BI Roadmap (tõlkes näiteks "äriintelligentsi tegevusplaan") annab üldise, ärikeskse ja projektijuhtimisele suurt tähelepanu pöörava mudeli äriintelligentsi süsteemide rajamiseks (20). See läbib kõik klassikalise inseneriprojekti sammud (planeerimine, analüüs, disain, ehitamine, testimine, juurutamine), pakkudeks igaühe jaoks tegevuste järjekorrad, paralleelsuse, rollijaotused ning kompetentside vajadused äriintelligentsi süsteemi rajamisel. Arhitektuuriotsuseid protsess ette ei kirjuta ei keskenduta. Protsess pöörab tähelepanu ka andmekaevandamise rakenduste jm kasutajarakenduste loomisele. Suurt rõhku pannakse metaandmete kogumisele ning meeskonna ja tegevuste rollideks jaotamisele. Protsessi raames pakutakse välja mitmeid notatsioone dokumenteerimiseks. BI Roadmap sobib nii iteratiivseks kui mitteiteratiivseks arendamiseks. Iteratiivne lähenemine ei ole protsessi loomulikku kulgemisse sisse programmeeritud, pigem nähakse iteratiivsust protsessi terviklikus kordamises.

Liigitumine eelpooltoodud loeteludes: Top-down, kasutajakeskse ja andmekeskse hübriid. Andmekeskse lähenemise kaasamise tõttu soovitab BI Roadmap-i ka "andmeaitade isa" W.H.Inmon (20).

Arendusprotsessi üldine mudel:

38

Joonis 13. BI Roadmap tegevuste skeem (20). Kuna protsess põhineb üldisel inseneriprojektide raamistikul, peitub selle tugevus just üksiktegevuste kirjeldamises, sidumises ja dokumenteerimises, mis jooniselt väga hästi välja ei tule. Arhitektuuriotsused:

Ei sekku arhitektuuriküsimustesse. Andmemudel:

Sobib nii puhta dimensioonilise kui normaliseeritud andmemudeli rakendamiseks. Paneb paika kontseptuaalse ning füüsilise andmemudeli loomise aja üldises protsessis, kuid ei kirjuta ette andmemudeli olemust.

Head ja vead Väga põhjalik, pakub mitmeid dokumentatsioonilahendusi. Kindlasti on kasulik formaalne arendusetappide edasjõudlikkuse hindamine (mingist etapist väljumise kirteeriumid ja järgmisse etappi sisenemise kriteeriumid, mille abil oma projekti kontrollida), inimressursi planeerimise maatriks. BI Roadmap annab projektijuhile pidepunkti meeskonna rollijaotuste, arendusetappide pikkuste ning etappide ükseisest eristamise jaoks. Kohati liiga põhjalik ja detailne. Tõenäoselt tuleks seda protsessi lihtsustada ja kohandada enne reaalset kasutuselevõttu. Arhitektuuriotsuste suhtes pisut liiga pealiskaudne. Autonoomsetest andmevakkadest koosneva süsteemi arendamine ei

Põhjendamine * Äri hetkeolukorra analüüs

Planeerimine * Ettevõtte infrastruktuuri analüüs (andmekesksus!) * Projektiplaani koostamine ja kaitsmine

Ärianalüüs * Nõuete analüüs (kasutajakesksus!) * Paralleelselt andmeallikate detailne analüüs, kasutajarakenduste prototüüpimine ja metaandmete analüüs

Disain * (allikaanalüüsist ja kasutajate nõuetest tulenevalt ) andmebaasidisain, sellest lähtuvalt ETL disain * Paralleelselt eelmisega metaandmete sõnastiku disain

Ehitamine * Paralleelselt kasutajarakenduste, metaandmete sõnastiku, andmekaevandamise rakenduste ning ETL protsesside ehitamine

Juurutamine * Toote installatsioon ning kasutajakoolitus * Tagasiside korjamine, järelduste tegemine

39

pruugi kaugeltki kokku langeda tsentraalse normaliseeritud andmeaida arendamise protsessiga.

1.6.3.3 "Data Warehouse Lifecycle Management" – Cliff Longman Üldiseloomustus:

Tõlkida võiks protsessi nime "andmeaida elutsükli juhtimine". Välja on protsessi pakkunud Cliff Longman (15). DWHLM on kergekaaluline ja omadustelt agiilmetoodikate poole kalduv protsess, mille eesmärgiks on ehitada andmeaida süsteem kiiresti ja kohaneda kiiresti muutustega keskkonnas või nõudmistes. Protsess lähtub seisukohast, et ettevõtte äri muutub ning muutused äris peaksid olema selgelt eristatavad. DWHLM vastandab end arendusprotsessidele, milles üritatakse andmeaida rajamisel ärimudel mingil ajahetkel fikseerida, siis sellest mudelist lähtuvalt ait ehitada ning hiljem kui äri on piisvalt muutunud, kõik muutusi kirjeldavad nõudmised koguda ja aita sisse viia. DWHLM ei nõua kõigi nõudmiste kirjeldamist ega süsteemi üldvaadet arenduse alustamiseks. DWHLM keskendub lõdvalt tsentraliseeritud aidale ("federated", mitte "centralized") – s.t. ühisele kontseptuaalsele ärimudelile alluvate andmevakkade kogumile ning kiiretele iteratsioonidele arenduses. Lähenemine on pragmaatiline – aita pannakse andmed, mille sinnapanek on kasutajatele vajalik, ent ei maksa liiga palju. Ühist andmemudelit jälgitakse niikaua, kuni see alliksüsteemide eripärade ja kasutajate erinõudmiste osas on võimalik. Viis põhimõtet: 1) Geneeriline (standardne) andmemudel – üritakse minimiseerida organisatsioonispetsiifilisi nüansse andmemudelis ja kasutada võimalikul palju mustreid. 2) Andmeait rajatakse ärimudeli alusel, mis tähendab lähenemine on protsessikesne, peamine on äri muutuste ja andmeaida arenduse sünkroonis hoidmine. 3) Ühised põhidimensioonid, põhiandmed läbi kõigi andmevakkade (näiteks kliendid, tooted) – sarnaneb Ralph Kimballi "Data Warehouse Bus Architecture-is" kasutatavate ühiste dimensioonidega. Aitab kindlustada selle, et andmeaidast siiski ettevõtte info üldvaate saaks. 4) Äri modelleerimisele suur rõhk – kuna andmeait peab äri parimaks toetamiseks protsessidega sünkroonis olema. 5) Ajast sõltuvus / ettevõttele andmetealase "mälu" loomine.

Liigitumine eelpooltoodud loeteludes: Bottom-up, protsessikeskne.

Arendusprotsessi üldine mudel

40

Joonis 14. Data Warehouse Lifecycle Management (15). Andmeaida arendamine hoitakse sünkroonis äri arenemisega. Arhitektuuriotsused

Andmeait on lõdvalt tsentraliseeritud – teatavale üldisele mudelile alluvate andmevakkade kogum, mida toidetakse ühisest ETL protsessist.

Andmemudel Pole oluline, kas dimensiooniline või normaliseeritud, peaasi, et võimalikult üldine ning organisatsiooni eripäradest mittesõltuv.

Head ja vead Kiire, vähe administratiivset tegevust, adaptiivne. Väldib olukorda, kus andmeaita lisanduvate uute ärinõuete osa väheneb igal järgneval arenduse iteratsioonil, kuna olemasoleva aida nõuete uuestikirjeldamisele ning parandamisele kulub suur osa projekti skoobist. Iteratsioonid on andmeaida süsteemi kohta lühikesed (kuni üks kuu). Arendusprotsess on defineeritud põhimõtete tasemel. Suhteliselt suur osa tegevustest, dokumentatsioonist ning projektijuhtimisest tuleb DWHLM realiseerival ettevõttel ise välja töötada või muudest protsessidest laenata.

1.6.3.4 "Enterprise Modeling Framework" – J.O. Chan Üldiseloomustus

J.O Chan (22) pakub 1975. aastal ANSI ja SPARC poolt loodud 3-Schema mudeli täienduse andmeaitade jaoks, vastandades seda big bang ja bottom-up lähenemist kasutavatele metoodikatele. Arendusprotsess 3-schema mudeli alusel kujutab endast kolme vaate loomist ettevõttele. Need kolm vaadet on kontseptuaalne ärimudel (Conceptual Enterprise Model), operatsiooniline ärimudel (Operational Enterprise Model) ja tehniline ärimudel (Technical Enterprise Model). Kontseptuaalne ärimudel: kujutab endast ettevõtte kirjeldust kontseptuaalsel tasemel (vastab küsimusele "milline on ettevõte?"). Siia koondatakse kontseptuaalne andmemudel (notatsioonid pole EMF seisukohalt olulised), äriprotsesside mudel ning analüütiliste funktsioonide vajaduste mudel. Mudelis

Äri muutumise protsess

Andmeaida arendamise protsess

Järelda ja analüüsi

Planeeri ja disaini

Rakenda

Järelda ja analüüsi

Planeeri ja disaini

Ehita

41

eristatakse kaks osa - väline ning sisemine kontseptuaalne vaade ärile. J.O Chan pakub selle mudeli nimeks Enterprise Information Roadmap, põhjendades nime sellega, et mudel haarab ettevõtte vaate infole nii protsesside, analüüsifunktsioonide kui andmemudeli seisukohast, nii ettevõttesiseselt kui väliselt ja on seega kogu ettevõtte info peegelduseks. Operatsiooniline ärimudel: kujutab endast ettevõtte operatsioonilise taseme tegevuste mudelit. Jagatakse kaheks – analüütiliste operatsioonide ning äriprotsesside täitmiseks vajalike operatsioonide mudel. Tehniline ärimudel: Sisaldab füüsilist andmemudelit, mille abil realiseerida andmebaas ning tehnilise arhitektuuri mudelit. EMF on pigem modelleerimise raamistik üldise iteratiivse arendusprotsessi sisse kui iseseisvalt tegevusi defineeriv protsess.

Liigitumine eelpooltoodud loeteludes: Top-down, andme- ja protsessikeskse hübriid.

Arendusprotsessi üldine mudel

Joonis 15. Enterprise Modeling Framework tegevuste järjestus (22) Arhitektuuriotsused

Pakub andmeaida tüübiks lõdvalt tsentraliseeritud andmeaida, kus andmevakad baseeruvad ühisel ärimudelil ning ETL protsessil, kuid arendatakse erinevates iteratsioonides iseseisvalt.

Andmemudel Ei tegele normaliseerimise-denormaliseerimise taseme küsimustega. Rajatakse kaks andmemudelit – kontseptuaalne (ettevõttesisene ja -väline) ning tehniline (realisatsiooni mudel).

Head ja vead Üritab lahutada vaated arendatavale süsteemile ettevõttele tasemete järgi ning rakendada paralleelselt andmekeskset ja protsessikeskset lähenemist. Ei ole iseseisev arendusprotsess, pigem modelleerimisviis.

1.6.4 Dokumenteerimine, nõuete kogumine, elutsükli üksikuid samme haaravad teooriad Meetodeid mõne andmeaida elutsükli sammu sooritamiseks, dokumenteerimisviise ning arehitektuurilahendusi pakuvad välja väga mitmed autorid. Enamasti üritatakse

Konseptuaalne modelleerimine

Operatsiooniline modelleerimine

Tehniline modelleerimine

Realiseerimine

Juurutamine

42

mõnda klassikalise inseneriteooria või objektorienteeritud programmeerimisel kasutatavat diagrammi notatsiooni või diagrammimise meetodit andmeaida jaoks kohandada. Kuna keskendun edaspididses arendusprotsessi iseloomustamises ja täiendamises just analüüsiosale (eriti ärinõuete kogumisele ja formaliseerimisele) ning erinevate arendusetappide dokumentatsiooni liidestamisele (näiteks sellele, kuidas saaks ärinõuete kirjelduste dokumentide abil andmevaka tähtskeemi elemente, fakte ja dimensioone tuletada). Siinkohal toon mõned huvipakkuvamad lahendused aida arhitektuuriks, dokumenteerimiseks, nõuete kogumiseks. Alustades taaskord Ralph Kimballist, väärib mainimist Data Warehouse Bus Architecture ("andmeaida siini-arhitektuur") (4)(8). See on andmevakkadest koosneva andmeaida arhitektuuriline ülesehitus, mille järgi üldisi ärinõudeid kirjeldades identifitseeritakse kogu organisatsiooni hõlmavad andmeolemid, nagu näiteks klient, toode või leping ning luuakse neist olemitest kõiki andmevakkasid läbivad dimensioonid. See tähendab, et suvaline andmevakk (näiteks müügiprotsessi vakk) kasutab mingit osa talle eripärastest dimensioonidest (müügikanal) ning mingit osa üldistest dimensioonidest (klient, toode). Nii tagatakse aidale piisav detailsus iga äriprotsessi jaoks, säilitades samas üldvaate ärile. Andmeaida nõuete kogumisel on pakutud välja mitu dokumenteerimisviisi nõuete kogumiseks. Enamus mitte puhtalt andmekeskselt lähenevaid autoreid on ühel meelel, et ärinõudmiste kogumiseks on vaja:

• intervjueerida operatsioonilise, taktikalise ja strateegilise äritaseme kasutajaid, • viia läbi kasutajatega ajurünnakuid intervjuudel selgunud mõtete

täpsustamiseks, • uurida olemasolevat aruandlust ning muid analüüsitulemeid, • analüüsida alliksüsteeme, • hinnata ettevõtte IT infrastruktuuri.

Teooria, kuidas kasutada ka andmeaida rajamisel ära klassikalisi IT-arenduse meetodeid – olemi-suhte diagrammi (entity-relation diagram), funktsionaalset dekompositsiooni (functional decomposition) ning CRUD maatriksit andmeaitade rajamisel, pakub välja Anthony Politano (24). 1) Normaliseeritud olemi-suhte diagrammi eelised dimensioonilise mudeli ees äri kujutamisel on ärireeglite parem väljatoomine, dünaamilisem ülesehitus (tähtskeem on oma olemuselt kohe implemetatsiooni tasemel). Politano pakub välja, et Zachmani raamistikust lähtudes saaks andmeaida rajamisel kontseptuaalse taseme diagrammi teha normaliseerituna, et äriloogika ning abstraktsioon säiliksid ning loogilise taseme mudeli teha dimensionaalse, et tagada selgus ja päringute kiirus kasutajale. 2) Top-down andmeaida arenduse korral räägime äri jagamiseks protsessideks. Funktsionaalne diagrammimine – tehnoloogia, kus äri jagatakse kõigepealt funktsioonideks ning iga funktsioon omakorda protsessideks kasutab mõisteid "protsess" ja "funktsioon" vastupidiselt (Kimball jaoks on protsess üldisem ning funktsioon detailsem), kuid sobib äri struktuuri kujutamiseks väga hästi. 3) CRUD maatriks seostab kaks eelnevat mudelit. See on tabel, milles ühel teljel loetletakse olulisemad andmeolemid, teisel olulisemad protsessid/funktsioonid. Tabeli lahtrites on märked C,R,U,D vastavalt sellele, kas protsess loob (C – i.k. create, looma), loeb (R – i.k. read, lugema), muudab (U – i.k. update, muutma) või kustutab

43

(D – i.k. delete, kustutama). Politano soovitab funktsioonide asemel kasutada maatriksis "süsteeme", mille all ta peab silmas üht või mitut OLTP rakendust. Nii saame andmeolemite jaoks identifitseerida potentsiaalsed alliksüsteemid ning välja tuleb ka suur osa võimalikke probleeme andmete laadimisel (andmeid x ei looda mitte kusagil, andmeid y luuakse mitmes alliksüsteemis). Klasterdades OLTP süsteeme CRUD maatriksis, saame paika panna võimalikud andmevakad ning arendusiteratsioonid. Viini Ülikooli tarkvarateadlased pöörduvad ärinõuete defineerimisele UML kasutusjuhtude poole (25), kuigi Kimball ja enamus praktikuid on need kui protsessikesksed ja seega kasutud kõrvale jätnud. Listi, Schieferi ja Mini pakutud mudeli järgi pannakse kasutusjuhtudesse kirja äriprotsessid. Kasutusjuhtude mudel valiti, kuna:

• kasutusjuhtusid mõistavad nii äri- kui IT-pool, • kasutusjuhud on standardne meetod nõuete kirjapanekuks ning seda toetavad

CASE tööriistad, • kasutusjuhud on esitatavad kõrgel abstraktsioonitasemel, • nende notatsioon on inimesele loetav ning seetõttu saavad neid kasutada nii

äripoole inimesed kui arendajad, • kohandatava täpsusega (strateegilise analüüsi raames üldisel tasemel, hiljem

võib ), • taaskasutatavad hilisemates arendusfaasides.

Eelkõige aitab nende hinnangul äriprotsesside kirjeldamine kasutusjuhtudes vältida probleeme terminoloogia mõistmisel (kuna äri-inimeste keel ei ole tihti IT-inimestele mõistetav). Minu hinnangul see päris tõsi pole. Kindlasti paraneb äri algoritmide mõistmine, kuid äriterminoloogia täpseks lahtikirjutamiseks tuleks luua äärmiselt detailsed kasutusjuhud. Seetõttu tuleks siiski ärisõnastik metaandmete kogu ühe osana eraldi arendada. Minu hinnangul on UML kasutusjuhtude abil äriprotsesside kirjeldamine väga huvitava ideega, kuna majandustegevuste kirjeldamine IT raamistikus peaks olema just see, mida andmeait teeb. Trujillo, Palomar, Gomez ja Il-Yeong (26) lähevad tehnilisemaks ning detailsemaks kui protsesside kirjeldamine ja vaatlevad, kuidas UML keele klassidiagrammi ning Object Constraint Language-i abil kirjeldada andmeaida andmemudeli tähtskeemi, märkides peale olemite struktuuri ära ka agregeerimisvõimalused, tuletusreeglid ning pärimisstruktuuri dimensioonide andmehierarhiates. Kasutades UML Package struktuuri pakuvad nad välja skeemide grupeerimise valdkonniti ning detailsustasemeti. Kasutajanõudmiste tehniliseks kirjapanekuks kasutavad nad kuubiklasse (kuup esindab tähtskeemi, kuubiklass on klass objekt-orienteeritud mõistes). Kuubiklassi loetletakse infovajadused (vastava dimensiooniklassi tüüpi andmeväljad, kasutaja analüüsitegevused (meetodid). Sellisena kirjapandud klassistruktuurist saab CASE tööriista abil automaatselt SQL ja vajadusel ka mingit sorti objektoritenteeritud programmeerimiskeele koodi genereerida (abiks eriti UML Object Constraint Language). Autorid ise rõhutavad objekt-

44

relatsiooniliste andmebaaside kasutuselevõtmisel võimalikule andmebaasi füüsilise loomise ja muutmise automatiseerimisele. Kuigi tegu on huvitava ideega ning koodi genereerimine mudelitest on perspektiivikas valdkond IT arenduses, on siin mainitud teooria minu hinnangul täna veel liiga väikese ulatusega ja tehniline, et reaalse aidaprojekti rajamisel kasutatav olla. Klassikaliste insenerimeetodite uusversioonide jätkuna pakub Mark Dale välja tootmises kasutatavast mitteiteratiivsest Six Sigma meetodist lähtuva DMAIC protsessi andmeaida nõuete kogumiseks (27). Lahtikirjutatuna on DMAIC - Define, Measure, Analyze, Improve, Control. Tõlkida võiks akronüümi järgmiselt: Identifiseeri, Mõõda, Uuri, Paranda, Kontrolli. Nõuete kogumise tegevused igal sammul oleksid: D - Leia kasutajaintervjuude alusel probleemid M - Kontrolli, mõõda probleeme A - Analüüsi praeguse ja soovitud olukorra vahet (gap analysis) I - Loo ettekirjutused muudatuste elluviimiseks C - Kirjelda kontollimehhanismid Tõenäoselt on protsess tavaliste andmeaida projektide juures kasutamiseks liiga kallis (s.t aeganõudev) ning sobib pigem missioonikriitiliste või väga suurte projektide juurde, kus meeskonna suurusest tulenevalt on vaja ametlikumat protsessi. "Pehmemate" tehnikate juurde tagasi pöördudes on Paim ja Castro loonud NFR Framework-i - raamistiku mittefunktsionaalsete nõuete kogumiseks andmeaitade rajamisel (16). Raamistiku ülesandeks on visualiseerida mittefunktsionaalseid nõudmisi, leida ühisjooni nõudmiste vahel ja analüüsida potentsiaalseid disainilahendusi. Põhiliseks töövahendiks ja diagrammiks on puustrutktuur, milles üldisemad nõudmised kirjutatakse lahti AND/OR tingimustega seotud alamnõudmisteks ning mõjutavateks teguriteks. Puid luuakse mitu – dimensionaalse mudeli, kasutajatööriistade, infrastruktuuri jms mittefunkts. nõudmiste kirjeldamiseks. Lõpptulemuseks on kataloog nõudmistest ning neid mõjutavatest teguritest. Minu hinnangul on NFR raamistik kasulik ainult siis, kui andmeaida rajamisel põrgatakse kokku mittefunktsionaalsete nõudmistega, mida on keeruline täita või kui aida toimimisel tekib mittefunktsionaalseid probleeme, millel on hulk hägusaid põhjuseid ning tuleb teha poliitiline (s.t. klienti ja lisaraha hõlmav) otsus, milliste põhjustega probleemi lahendamiseks tegelema hakata. Väiksemahulise projekti jaoks on NFR raamistik tõenäoselt liiga kallis. Paim ja Castro pakuvad teisegi skeemi, seekord andmeaida nõudmiste üldise kogumise kohta – DWARF, Data WArehouse Requirements Definition (tõlkes "andmeaida nõudmiste kirjeldamine") (16). Algoritm on kirjeldatud väga üldisel tasemel, tegemist on tsüklilise lähenemisega, mis koosneb nõudmiste kogumise ja süstematiseerimise tegevustest, mis vahelduvad nõudmiste valideerimise tegevustega, milles tekkinud nõudmised kinnitatakse kliendiga läbi rääkides. Nõudmiste kogumise protsessi tulemuseks on dokumentatsioon UML kasutusjuhtude (nad ei täpsusta, kuidas andmeaida nõudmisi protsessikesksete kasutusjuhtude stsenaariumitesse kirjutada) ja nõudmiste valideerimise protsessi tulemusena lepingu jõuga nõudmiste kogum.

45

Autorid toovad ka tegevuste loetelu kummagi põhiprotsessi jaoks ja sisukorra soovitatavast lõppdokumentatsioonist. DWARF võib olla ettevõttele visiooniks või šablooniks oma nõudmiste kogumise protsessi väljatöötamisel, ent tuleks selgitada, kuidas saab UML kasutusjuhtude abil andmeaida nõudeid kirjeldada ning kuna ei pakuta ka välja, kuidas nõudmiste kinnitamisel analüüsi ja disainiga edasi minna, tuleb ettevõttel metoodika toodud kujul kasutuselevõtmiseks ise hulk lisatööd teha. Vaadeldes eelpoolkirjeldatud arendusmeetodeid ja nende kasutatavaid dokumenteerimisviise, näeme pea kõigis protsessides läbiva joonena iteratiivset ja inkrementaalset lähenemist ning paljud dokumentidest sobivad Zachmani raamistiku diagrammide hulka. Edaspidi kasutan siin väljapakutud elutsükli teooriaid ja dokumenteerimisviise, et pakkuda täiendusi ettevõtte "X" andmeaitade arendusprotsessile. Elutsükli raamistikuks valin üldise iteratiivse arendusprotsessi ning selle raames loetlen tegevusi ja nende poolt toodetavaid mudeleid. Keskendun nõuete kogumisele, strateegilisele analüüsile ning disainietapis analüüsidokumentatsiooni ärakasutamisele.

46

2. Andmeaida arendusprotsessi väljapakkumine

2.1 Ettevõte "X" ja eesmärk arendusprotsessi täiendamisel

Olen töö eelnevas osas andnud lühikese ülevaate andmeaitade arendamise teooriatest ning äriintelligentsi süsteemide üldiseloomust, võrrelnud äriintelligentsi süsteemi transaktsionaalsete tarkvarasüsteemidega ning pisut iseloomustanud ka enamkasutatavaid arendusptrotsesse viimaste rajamiseks. See ülevaade on tekitanud teatava konteksti andmeaitade arenduse kohast tarkvarasüsteemide hulgas ning selle tänapäevast arendamise mõttes. Kokkuvõtlikult näen, et aitade arendamises prevaleerivad mõned üldised ja läbivad ideed (ärikesksus, arenduse iteratiivsus), mõned konkureerivad teooriad (dimensionaalne modelleerimine versus normaliseeritud kujul E-R modelleerimine, andmekeskne, protsessikeskne, kasutajakeskne lähenemine), mõned erandlikud ideed (UML klassidiagramm ja Object Constraint Language tähtskeemi esitamiseks, mittefunktsionaalsete nõuete kujutamine puudena) ent de facto arendusprotsessi, üldaktsepteeritavat standardit pole välja kujunenud. Teiselt poolt olen eraldi uurinud ettevõtet "X" – Eesti turul tegutsevat, keskmisest suuremat tarkvaratootjat, mis on loodud üle tosina aasta tagasi ning oma eksistensi jooksul rajanud mitmeid suurettevõtete infosüsteeme. Ettevõttel on väga suur OLTP süsteemide arendamise kogemus, arendatud on keerulisi ning missioonikriitilisi mitmekihilisi klient-server süsteeme, geoinfosüsteeme ning suuri riiklikke andmebaase. Äriintelligentsisüsteemide arendamine on ettevõtte tarkvara arenduse meeskonna jaoks üks neljast suuremast valdkonnast. Ülejäänud valdkondadeks on Oracle-i tarkvara põhised klient-server lahendused, komponenttehnoloogial põhinevad mitmekihilised veebilahendused ning geoinfosüsteemid. Ettevõttes on läbivaks arendusmetoodikaks RUP-ist enesele kohandatud versioon, arendusel on märksõnadeks iteratiivsus, komponent-orienteeritus ja objektorienteeritus. Andmeaitade rajamiseks on kujunenud välja "kergekaaluline" iteratiivne protsess – eesmärgiks on kliendi soovide põhjal teha rätsepatööna sobiv andmeait ilma suuremate lisakuludeta, milleks põhjalik analüüsiprotsess kahtlemata on. Kirjeldan protsessi detailsemalt edaspidi. Äriintelligentsi süsteemide arendusprotsess ettevõttes "X" on algselt üle võetud OLTP süsteemide arendamiselt ning seda pole edaspidi sihipäraselt kujundatud. Muutused protsessis on toimunud üsna juhuslikult, põhiliselt on samme ja dokumente muudetud enese mugavuse ning parajasti käesoleva projekti kitsaskohtade tõttu. Andmeaitade arendajad leiavad praeguse protsessi juures mitmeid puudusi:

• palju infot on olemas ainult meeskonnaliikmete peades, seetõttu pole tiimiliikmetel lihtne projekte vahetada, puhkuseid võtta,

• siiamaani on lähenetud andmekeskselt, soovitaks arendust rohkem protsessikeskseks muuta, see tähendab, et eriti oluliseks muutub arenduses äri modelleerimise ja ärikasutajate intervjueerimise osa,

47

• kliendile on dokumentatsioonist vähe kasu, kuna see on mõistmiseks enamasti liiga tehniline (s.t. klient ei saa dokumentatsiooni vaadates aru, mis tema süsteemis valmis on ja mida tema sellest süsteemist saab),

• strateegilise analüüsi dokumentatsiooni tekib vähe, seetõttu tuleb hilisematel sammudel (disain) osa küsimusi uuesti küsida,

• dokumentatsiooni ei ole seni omavahel sidustatud (näiteks nõudmise kirjeldusest tuletatud andmemudeli olulisemaid olemeid), seetõttu tuleb osa tööd teha mitmekordselt,

• projektist tekkinud teadmist on raske taaskasutada, kuna see pole kusagil ühtselt ja standardselt kirjas.

Seega vajaks ettevõtte "X" olemasolev andmeaitade arendusprotsess täiendusi eelkõige strateegilise analüüsi läbiviimise, protsessikeskse lähenemise rakendamise ning dokumenteerimise standardiseerimise osas. Teretulnud on ideed erinevate arendusetappide dokumentatsiooni sidustamise osas. Protsessi täiendamise eesmärgiks on:

• nõudmiste kogumise mudeli täiendamine (protsessikesksus), • erinevate arendusetappide sidustamine (ühe tulem teise lähteandmeteks).

Dokumentatsiooni täiendamise eesmärgiks on:

• erinevate arendusetappide sidustamine, • arendusel tekkiva teadmise formaliseerimine, et seda hilisemates etappides

kergesti taaskasutada, • arendusel tekkiva teadmise kõigile osapooltele nähtavaks tegemine, • kliendile arusaadav vaade süsteemist.

Edasise uurimuse käigus esitan ettevõtte "X" olemasoleva äriintelligentsi süsteemide arendusprotsessi kirjelduse ning ülevaate kasutatavatest dokumenteerimisviisidest. Seejärel pakun arendusprotsessile välja täiendused ülaltoodud eesmärke silmas pidades. Toetun olemasolevale raamistikule ning töö teoreetilise tausta osas kirjeldatud metoodikatele ning teooriatale. Keskendun täiendustele strateegilise analüüsi ja eriti nõuete kogumise vallas, kuna need on ettevõtte "X" arendusmeeskonna hinnangul kõige olulisemad. Peale täiendatud protsessi kirjeldamist toon ka lühikese ülevaate muudatustest ning hindan enda väljapakutu kasulikkust ja olulisust.

48

2.2 Ülesandepüstitus arendusprotsessile täienduste pakkumisel

Pakun ettevõtte "X" andmeaida arendusprotsessile täiendusi, toetudes uuritud teoreetilisele taustale ning olemasolevale protsessile.

Arendusprotsessi uurimisel leitud probleemid: • Kuidas tajuda, et ettevõttel on vajadus andmeaida süsteemi järele? • Kuidas prognoosida andmeaida süsteemi ulatust (andmevakad versus

andmeait, milliseid andmeid haarata jne)? • Milline peaks olema andmeaida arenduse elutsükkel, arvestades ettevõtte

"X" praegust kogemust ja protsessi? • Kuidas identifitseerida ja dokumenteerida nõudmised? • Kas ja kui palju kirjeldada äriprotsesse, mille andmed aita lähevad?

Millises notatsioonis? • Kuidas sidustada erinevate etappide dokumentatsiooni? • Kuidas otsustada, millal on aida arendamine valmis?

2.3 Andmeida arendusprotsess ettevõttes "X"

Toon põhjalikuma kirjelduse ettevõttes "X" andmeaida süsteemide rajamiseks väljakujunenud arendusprotsessist. Loon sellele niiöelda "as is"3 vaate, et hiljem kirjeldalda "to be"4 vaade, kasutades käesolevat kontekstina. Lähtuvalt tõstatatud eesmärkidest keskendun protsessi vaatlemisel analüüsifaasile.

2.3.1 Kasutatud projektid Minu kasutada oli teadmine ning dokumentatsioon kolmest andmeaida rajamise projektist: 1. Suure infrastruktuuriettevõtte andmeaida rajamine.

Projekti eesmärk: andmeaida pilootprojekt, esimeseks tulemiks andmevakk ühe äriprotsessi tarbeks. Dokumentatsioon: kogu protsessi ulatuses (lepingud, analüüsi- ja disainidokumentatsioon, testimise dok., kasutajajuhendid jne). Lähenemine: andmekeskne, bottom-up. Tulem: andmevakk ühe äriprotsessi jälgimiseks.

2. Riigiameti andmeaida rajamine.

Projekti üldiseloom: alliksüsteemide analüüs, andmete kvaliteedi hindamine, andmeaida rajamine kliendi kirjeldatud infovajadustest lähtuvalt.

3 Eesti keelde tõlgituna 'praegune', 'olemasolev' 4 Eesti keelde tõlgituna 'soovitud', 'eesmärgiks olev'

49

Dokumentatsioon: pakkumised, projektijuhtimise dokumentatsioon, vahearuanded, metaandmete sõnastik. Lähenemine: kasutajakeskne, top-down. Tulem: andmeait, lähtuvalt kliendi poolt kirjeldatud infovajadustest.

3. Kommunikatsiooniteenuste ettevõtte andmeaida rajamine.

Projekti üldiseloom: andmeaida rajamine. Dokumentatsioon: disainidokumentatsioon, testimise aruanded, kasutajajuhendid. Lähenemine: andmekeskne, top-down. Tulem: andmeait.

2.3.2 Arendusprotsess ettevõttes "X" 2.3.2.1 Üldiseloomustus Äriintelligentsisüsteemide arendusprotsess ettevõttes "X" toetub firma üldisele arendusraamistikule – Rational Unified Processist iseendale kohandatud iteratiivsele arendusprotsessile. Tavaline meeskonna suurus andmeaida projektide juures varieerub, ent keskmiselt on kaasatud pool tosinat töötajat. Ühel inimesel võib olla mitu rolli ja ühte rolli võib kanda mitu inimest. Põhirollid ja neid kandvate inimeste arvud on jaotatud järgmiselt:

• Analüütik-arhitekt: 1 inimene, vastutab projekti skoobis hoidmise, kliendi vajaduste kirjeldamise ja andmeaida üldiste äriotsuste ja arhitektuuriotsuste eest.

• Projektijuht: 1 inimene, tegutseb ressursside ja eelarve jaotamisega. • Kasutajarakenduste programmeerija-juurutaja: programmeerijad firma tarkvara

arenduse meeskonnast või rakenduste administraator(id), reeglina kaks kuni kolm inimest.

• Andmebaasi ja ETL programmeerija-testija: 1-3 inimest, andmeaitade spetsialistid.

• Kasutajate koolitaja: 1 inimene (reeglina) meeskonnast, kes viib läbi koolituse. Peamiseks arhitektuurilahenduseks on ühisel andmemudelil baseeruvate andmevakkade kogum (olenevalt kliendi soovist võib see valmida kas inkrementaalselt andmevakkade kaupa või "suure pauguna" tervikuna). Andmevakkadel on ühine staging area, mida toidetakse andmetega ühest kesksest ETL protsessist. Iteratsiooni ulatuseks on tavaliselt ühe äriprotsessi infot peegeldava andmevaka rajamine (s.t. ärivajaduste analüüs, allikasüsteemide analüüs, andmemudeli disain ja ehitamine, ETL protsesside loomine, kasutajarakendust valimine või arendamine, testimine ja kasutajakoolitus). Iteratsiooni kestvuseks on keskmiselt üks kvartal. Arenduse kestvuse paneb paika leping kliendiga ning projekti esimeste iteratsioonide edukus. S.t. arendatakse seni, kuni klient leiab, et on äriprotsesse, mille kohta oleks tasuv andmevakkasid rajada. Vajaduse tajumine, ulatuse prognoosimine Vajaduse tajumisel on ettevõtte "X" praktikas kaks peamist mudelit.

50

1. Ettevõte "X" oli kliendile eelnevalt pakkunud tooteid ja teenuseid. Selle protsessi käigus võis kliendi ettevõtte infosüsteemi jaoks tehtud strateegiline analüüs (ärireeglid kirja pandud, andmemudel, alliksüsteemid kaardistatud). Ettevõttes "X" nähti võimalust kliendile ärianalüüsi süsteemi müüa ning võimalus realiseeriti kliendi huvitumisel pakkumisena. 2. Klient tajus ise vajadust andmeaida süsteemi järele / palus mingilt IT ettevõttelt konsultatsiooni, misjärel määrati potentsiaalse andmeaida ulatus, ning tehti pakkumiskutsed mitmetele ettevõtetele. Alternatiivi 2 puhul (näiteks kasutatud projekt "nr 2", riigiameti andmeaida rajamine) oli tihti kliendil suhteliselt selge arusaam oma vajadustest ja projekti ulatusest. Sellisel puhul oli töö põhiosaks alliksüsteemide analüüs, andmeaida disain ja ehitamine. Kasutatud projektide nr 1 ja 3 puhul oli ettevõttes "X" olemas strateegilisest analüüsist saadud teadmine klientide infosüsteemidest ja seetõttu keskenduti samuti alliksüsteemide analüüsile, andmeaida disainile ja ehitamisele. Arendusprotsessi olemus Üldine skeem:

Joonis 16. Ettevõtte "X" arendusprotsessi põhitegevused ja tulemiks olevad dokumendid.

2.3.2.2 Etappide lahtikirjutused Plaanimine:

Põhitegevused: • vajaduse tunnetamine, • projekti skoobi (nii tegevuste, üldise eelarve kui tähtaegade)määramine.

Sisenddokumendid: - Väljunddokumendid:

• leping kliendi ja ettevõtte "X" vahel, • vajadusel strateegilise analüüsi leping (äri toimimise analüüs) eraldi.

Plaanimine Analüüs

Disain

Ehitamine Juurutamine

- Leping (skoop) - Strat. analüüsi leping eraldi

- Alliksüsteemide kirjeldused - Analüüsi kokkuvõte - Ärisõnastik

- Disainidokumentatsiooni täpsustused - Testide kirjeldused testirobotile (SQL)

- Alliktabelite detailsed kirjeldused (ärireeglid andmebaasis) - Aida andmemudel - ETL ülevaade

- Kasutajajuhend - Hoolduse juhend

51

Puudused/vajadused: • Kuidas valida projekti skoop? • Kuidas, lähtuvalt kliendi olemusest, valida top-down ja bottom-up projekti

vahel? Kas elutsüklit saaks kuidagi optimiseerida? • Kuidas planeerida iteratsioonid (kestvus, skoop)?

Analüüs

Põhitegevused: • nõuete kirjeldamine, • olemasoleva andmete reaalsuse kirjeldamine.

Nõudeid formaalselt üles ei kirjutata (mitteformaalselt jäävad intervjuude kokkuvõtted, e-kirjad, memod, ettevõttes olemasolev aruandlus), piirdutakse lepingus nõutuga. Andmete reaalsuse uurimise all pean silmas alliksüsteemides olevate andmetabelite uurimist ning kirjeldamist. Oluline on leida ärireeglid (s.t. mittetehnilised piirangud andmetele – näiteks kirjeldab ärireeglit lause "klienti loetakse aktiivseks ajahetkel x, kui tal on sel ajahetkel vähemalt üks kehtiv leping"). Sisenddokumendid:

• lepingust tulenevad üldiste eesmärkide kirjeldused.

Väljunddokumendid: • allika analüüsi dokument, • andmesõnastik, • analüüsi kokkuvõte.

Puudused/vajadused: • Kuidas modelleerida äriprotsesse? • Kuidas vormistada analüüsitulem kliendile arusaadavalt (milliseid

notatsioone tuleks kasutada)? • Kuidas leida ja formaliseerida nõuded (lähtudes ärikasutajate vajadustest JA

allikandmete reaalsusest)? Disain

Põhitegevused: • alliktabelite detailne analüüs, • aida andmemudeli kirjeldamine, • ETL spetsifikatsiooni loomine, • kasutajarakenduste valimine.

Sisenddokumendid: • allika analüüsi dokumendid, • andmesõnastik.

Väljunddokumendid:

52

• allikabelite kirjeldused, • testide kirjeldused (SQL), • andmeaida andmemudel, • ETL kirjeldused, • disainietapi kokkuvõte.

Puudused/vajadused: • Kas analüüsidokumentatsioonist saaks automaatselt disainiotsuseid tuletada? • Kuidas kirja panna ETL protsessi nõudmised?

Ehitamine ja testimine

Põhitegevused: • andmeaida andmebaasi füüsiline loomine, • ETL protseduuride loomine, • kasutajarakenduste installeerimine, • testimine (sh testiroboti protseduuride jooksutamine).

Sisenddokumendid:

• andmemudel, • alliktabelite kirjeldused.

Väljunddokumendid: • täpsustatud andmemudel, • täpsustatud ETL kirjeldustesse.

Puudused/vajadused:

• Kuidas peaks ehitamise käigus realiseeritama metaandmete sõnastik? • Kuidas korraldada ja dokumenteerida testimine nii, et kontrollitaks kliendi

olulisimaid tegevusi ja infovajadusi ja tulem oleks kliendile arusaadav? Juurutamine

Põhitegevused: • andmebaasi ning kasutajarakenduste installeerimine, • kasutajatele süsteemi tutvustamine ning selle võimaluste õpetamine.

Sisenddokumendid: - Väljunddokumendid:

• kasutajajuhend, • hoolduse juhend.

Puudused/vajadused: • Kuidas dokumenteerida klientide tagasiside?

Seni kasutatavate dokumentide olemus:

53

1. Leping Eesmärk: panna paika projekti eesmärk, ulatus, eelarve ja tähtajad. Kuju: kliendi ja ettevõtte vahel allkirjastatud leping, juriidiline tekst.

2. Allika analüüsi dokument (v.t. Lisa 1) Eesmärk: kirjeldada OLTP süsteemis esinevat olulist ning aita laetavat andmeolemit. Kuju: dokument, mis annab andmetabelite kirjeldused, ärireeglite kirjeldused (andmete esinemise omapärad) ja küsimuste-vastuste stiilis arutelu andmekvaliteedi probleemidest.

3. Andmesõnastik Eesmärk: ühtlustada ja arendusmeeskonna ning kasutajate jaoks lahti selgitada kliendi ettevõtte äriterminoloogia. Kuju: loetelu terminitest ning nende lahtiseletustest (sh. definitsioon, vajadusel arvutusreegel või –valem, andmete asukoht OLTP süsteemis).

4. Analüüsi kokkuvõte (v.t. Lisa 2) Eesmärk: fikseerida analüüsietapi tulemused arendusmeeskonna, kliendi ning ettevõtte "X" juhtkonna jaoks. Kuju: esitlus, milles loetletakse iteratsiooni ulatus, nõudmised, allika analüüsi tulemused, probleemid, mis analüüsil kerkisid.

5. Andmemudel Eesmärk: kujutada rajatava andmevaka tähtskeeme kontseptuaalsel tasemel visuaalselt. Kuju: olemi-suhte diagramm (või UML klassidiagramm, millest kasutusel ainult klassikalise entity-relationship diagrammi osa).

6. Alliktabelite kirjeldused Eesmärk: kirjeldab andmeaida tabeleid, neis esinevaid andmeid ning laadimisptrotseduure detailselt. Kuju: dokument, milles kirjutatakse veerghaaval lahti tabeli struktuur, piirangud andmetele ning andmete laadimisprotseduurid alliksüsteemidest (SQL).

7. Testide kirjeldused Eesmärk: kirjeldada testiroboti (programmi, mis automaatselt teatud intervalli tagant jooksutab päringuid ning jägib, kas andmed aidas vastavad testis kirjeldatudle). Kuju: SQL SELECT päringute kirjeldused andmeaida vastu, testi käivitamise intervalli ja oodatava tulemuse kirjeldused.

8. Disainietapi kokkuvõte Eesmärk: kirjeldada disainietapi tulemusi arendusmeeskonnale, kliendile ja ettevõtte "X" juhtkonnale (etapi skoop, andmemudel, peamiste objektide tunnused, probleemid). Kuju: esitlus, millesse ülejäänud disainietapi dokumentidest on tehtud kokkuvõte ja üldistus.

9. Kasutajajuhend Eesmärk: kirjeldada valminud projekti osa kasutajatele, abimaterjal kasutajakoolituseks. Kuju: tekstidokument.

10. Hoolduse juhend Eesmärk: kirjeldada andmeaida süsteemi komponendid, komponentide nõudmised, asukohad, omavahelised suhted ja kriitilisus, kirjeldada ETL

54

protsessi toimumist, panna paika kasutajaõigused. Kuju: tekstidokument.

2.3.2.3 Nõuetele vastavuse kontrollimine Kliendiga kooskõlastatakse analüüsietapi ja disainietapi vahetulemid ning valminud andmeait tootena. Analüüsietapi kooskõlastamiseks ja vastuvõtmiseks kasutatakse analüüsi kokkuvõtte dokumenti. Lõplik otsus ja kinnitamine (või parandusettepanekute tegemine) toimub koosolekul. Disainietapp võetakse vastu samamoodi – disaini kokkuvõtte dokumendi alusel ning otsustamine toimub koosolekul. Valminud andmeaita ei testita enam mitte kliendi sõnastatud nõudmiste, vaid kliendiga kooskõlastatud analüüsi- ja disainidokumentide vastu. Seda ettevõtte "X" arendajate kaitseks, kuna on selge, et kliendi nõudmised muutuvad ajas. Probleemiks praeguse lähenemise juures on tõik, et kuna põhidokumendid analüüsi ja disainietapist on väga tehnilised andmebaasi kirjeldused, siis kliendi esindajad ei suuda päris täpselt mõista, mida nad peavad heaks kiitma või halvaks laitma ja seega tekivad tegelike nõudmiste ja heakskiidetud arendustvaldkonna vahele "käärid".

2.3.2.4 Iteratsioonid, arenduse kestvus Reeglina pannakse arenduse ulatus juba lepingus paika ning arenduse käigus see eriti ei muutu. See on tõenäoselt tingitud suurettevõtetest klientide äri iseloomust – IT kulutuste eelarve ning saadavad tooted plaanitakse pikalt ette ja seetõttu käsitletakse uuendusi ja muudatusi meelsamini uue projektina. Arenduse iteratsioonideks jagamine käib kliendi soovidest lähtuvalt. Kui soovitakse kindla temaatikaga andmevakkasid, siis loetakse iga andmevaka rajamist üheks iteratsiooniks, kui lepingust nii selgeid arendustsükleid näha pole, siis otsustatakse peale nõuete analüüsi, kuidas aida rajamine osadeks jagada (s.t. olulisemad, ent samal ajal kergemini realiseeritavad osad enne). Arendus lõpeb, kui lepingujärgne viimane funktsionaalsus on vastu võetud. Kliendi tagasiside dokumenteerimiseks praegu mingit kokkulepet ei ole. Tagasiside säilib e-kirjade, memode ja koosoleku protokollidena.

2.4 Arendusprotsessi väljapakkumine

Pakun eelmises jaotuses toodud arendusprotsessile täiendusi lähtudes ülalkirjeldatud probleemidest ning keskendudes nõuete analüüsile ning analüüsi- ja disainidokumentatsiooni sidustamisele. See tähendab, et realisatsiooni eripäradele ning tehnilistele üksikasjadele täienduste pakkumisele ei keskendu. Samuti vaatlen ma ainult andmeaida (s.t. andmemudeli, andmebaasi, ETL protseduuride ja aida presentatsioonikihi) loomist ja mitte kasutajatööriistade ja päringuprogrammide valimist või arendamist. Täienduste pakkumisel kasutan baasina töö teoreetilises osas toodut, eriti aga peatüki "Arendusprotsesside kasutus andmeaitade rajamisel" sisu. Lähenemiste osas üritan liikuda andmekeskselt protsessikeskseks ning võimaldada nii top-down kui bottom-up arendust. Põhilised elutsükli teooriad, millest lähtun, on "Business Dimensional

55

Lifecycle", "Business Intelligence Roadmap" ja "Data Warehouse Lifecycle Management". Dokumentatsiooni täiendamise osas on põhilisteks allikateks Ralph Kimballi näited (4)(8), UML ja klassikalised infotehnoloogias kasutatavad notatsioonid (CRUD maatriks, funktsionaalne dekompositisioon).

2.4.1 RUP raamistiku valiku põhjendus Kasutan arendusprotsessi tsüklite nimedena Rational Unified Processi sammude nimesid, kuna:

• RUP ideed on väga vabas vormis ettevõttes "X" juba kasutusel (s.t. olemas on kogemus),

• RUP on väga levinud (palju infot, toetus CASE tööriistades), • RUP on väga põhjalik ja paindlik raamistik – s.t. täiendamine, kohandamine on

sellele loomuomane. Et hoida elutsükkel kergekaaluline ja kohandada seda spetsiaalselt andmeaitadele, ei uuri ma siinkohal Rational Unified Processi ennast, vaid kasutan ainult selle põhisamme. Nimetan samme selguse huvides inglisekeelsete nimedega, tuues eestikeelsed tõlked. Kirjeldan igat sammu järgmiselt:

• Praegune algoritm: praeguse arendusetapi tegevuste loetelu. • Täiendused: minu pakutud lisad, arvestades eelnevalt tõstatud probleeme ja

vajadusi. • Täiendatud algoritm: täiendatud arendusetapi tegevuste loetelu. • Lisandunud dokumentatsioon: lisanunud dokumentide kirjeldused.

2.4.2 Enne arendust (planeerimine) Praegune algoritm:

1) Klient saadab pakkumiskutse (tellitava süsteemi ulatus, eesmärk). 2) Ettevõte "X" vastab eelarve ja tähtaegadega, planeeritakse meeskonna suurus. 3) Klient ja ettevõte sõlmivad lepingu, milles määratakse süsteemi ulatus, süsteemi eesmärgid, eelarve ja tähtajad.

Täiendused: Kuidas tajuda vajadust andmeaida järele? Ettevõtte "X" poolne tegevus piirdub reeglina lepingu läbirääkimiste ning väga pinnapealse kliendi ettevõtte uurimisega, siis saab põhiliselt lähenemist täiendada andmeaida ulatuse ja selle arendamise õigustamise osas. Ralph Kimball (4)(8) pakub välja nimekirja küsimustest ning testi, millele peaks kliendiga läbi rääkides vastused saama ning mille alusel saab teha otsuse, kas: a) andmeaida süsteemi rajamine on üleüldse otstarbekas (alternatiiviks oleks välja pakkuda mõni aruandluse karbitoode või arendada OLTP süsteemidele piiratud aruandlusvõimalused), b) tuleks kliendile vajaduste ja kasu selgekssaamiseks läheneda bottom-up ja teha kitsa valdkonnaga andmevaka projekt, c) klient on valmis tervet ettevõtet haarava andmeaida süsteemi rajamiseks.

56

Küsimustik peaks sisaldama vähemalt järgnevaid teemasid: 1) Kust tuleb nõudmine äriintelligentsisüsteemi järele? Kes on eestvedaja?

• Ettevõtte juhtkond – väga hea. • Ettevõtte osakond Y – kui ülejäänud ettevõte pole projektiga oluliselt

seotud, tuleks kaaluda kõigepealt osakonna andmevaka rajamist. • IT osakond – kas on sõnastatud selged ärieesmärgid ja on olemas

2) Kes andmeaida projekti jaoks raha eraldab? On väga oluline, et see, kelle eelarvest andmeaida rajamise finantsid tulevad, ise aidast kasu saaks ja arenduses osaleks. 3) Milleks aita soovitakse? Kui klient ei oska selgeid mõõdetavaid, saavutatavaid ärieesmärke sõnastada, tuleks kõigepealt pakkuda neile strateegilise analüüsi projekti, milles need eesmärgid leida. Mõõdetavate eesmärkide olemasolul saab välja tuua numbrilisi suurusjärkusid, mille võrra andmeaidast pärinevad otused ärile tulu juurde toovad. Näiteks kauplusteketi jaoks võiksime sõnastada järgmise kasunumbri: "laoseisu optimeerimine andmeaida aruannete põhjal nii, et aegunud toiduaineid oleks 5% vähem tähendaks aastas 150 000 kroonist võitu". Andmeaida süsteemi puhul ei saa me enamasti siiski rääkida kulude kokkuhoiust kliendi jaoks, vaid tulude suurendamisest. 4) Kliendiga koos arutada läbi valmisoleku küsimustik. Kui selgub olulisi puudujääke, tuleks kõigepealt asuda nende kõrvaldamisele. Kas ja millises ulatuses teha strateegiline analüüs? NCR korporatsiooni ärirakenduste arhitekt Doug Ebel on öelnud (24): The most successful data warehouses will take an enterprise view of the requirements, perform a quick analysis of the information need to support all requirements, then work deeply in one area to build the first incrementof the DWH. 5 Selle seisukohaga nõustub enamus autoriteetsemaid allikaid - (4), (20), (15), (17). Minimaalselt on andmeaida projekti alustamiseks vaja:

• kontseptuaalset andmemudelit üle kogu meid huvitava ärivaldkonna • organisatsiooni ülesehituse mudelit (rollid, kasutajad) • OLTP süsteemide jaoks arhitektuurimudelit • äri funktsionaalse dekompositsiooni mudelit

5 Edukaimad andmeaidad on arendatud, luues üldvaate ärinõuetest, tehes kiire analüüsi nõudmiste täitmiseks vajaminevast üle kogu äri ning siis minnes süvitsi ühte ärivaldkonda, ehitades andmeaida esimese inkremendi.

57

Nende abil saame kogutud ärinõudmised jagada rollide ning protsesside vahel, identifitseerida milliseid OLTP süsteeme nõudmised puudutavad ning selle alusel teha koos kliendiga otsuse, mida esimesel arenduse iteratsioonil andmeaita lisada. Kui kliendilt ei ole võimalik eeltoodud dokumentatsiooni saada, tuleks lepingusse ka strateegilise analüüsi läbiviimine selles osas sisse kirjutada. Kuidas prognoosida aida ulatust ja lähenemisviisi? Üldine reegel: kui kliendi ettevõttel on olemas eeldused andmeaida süsteemi rajamiseks, tuleks läheneda top-down ning talitada Doug Ebeli sõnade järgi. Kui klient pole kogu ettevõtet hõlmava süsteemi jaoks valmis (puudu eesmärgid, OLTP süsteemide kvaliteet vilets), peaks alustama pilootprojektina andmevaka ehitamisest ning selle valmimisel sõlmima uue lepingu. Selleks, et valida, milline andmevakk realiseerida (esimesena), pakub (4) välja lihtsa heuristilise tabeli, eesti keede võiks selle tõlkida kui andmevakkade prioritisatsiooni teljestik (v.t. Lisa 3). Dokument kujutab endast andmevakkade (eeldusel, et iga väärtusahela äriprotsessi jaoks tehakse andmevakk) kujutamist kahel teljel – "arendamise keerukus" versus "kasu ärile". Esimesena peaksime arendama vaka, mis toob ärile suurima kasu väikseima arenduseks vajamineva pingutuse juures. Hinnangud, kuidas äriprotsessid teljestikku paigutada, annab klient kogemuse alusel. (20) pakub välja riskide hindamise tabeli, kus kõigi arendust mõjutavad riskid (tehnoloogilised piirangud, keerukus, OLTP süsteemide integreeritavus, meeskond, eelarve) antakse hinnangud kolmepallisel skaalal.

Täiendatud algoritm:

1) Klient saadab pakkumiskutse. 2) Ettevõte "X" täidab kliendiga andmeaida rajamiseks valmisoleku küsimustiku ning uurib olemasolevat strat. analüüsi dokumentatsiooni. 3) Ettevõte "X" vastab pakkumisega, kus on määratud lähenemisviis, strat. analüüsi vajadus, esimeste iteratsioonide plaan. 4) Klient ja ettevõte sõlmivad lepingu, milles määratakse süsteemi ulatus, süsteemi eesmärgid, eelarve ja tähtajad.

Lisandunud dokumentatsioon: • Andmeaida rajamiseks valmisoleku küsimustik (v.t. Lisa 3), • Inkremendi valiku kvadrant (v.t. Lisa 4).

2.4.3 Inception (analüüs) Praegune algoritm:

1) Projekti ulatuse ja alliksüsteemide leidmiseks viiakse läbi intervjuud, kogutakse näidisandmeid. 2) Paralleelselt tehakse alliksüsteemide analüüsi (kirjeldatakse andmetabeleid ja ärireegleid). 3) Terminoloogia kohta peetakse sõnastikku. 4) Etapi lõppdokumendina luuakse analüüsi kokkuvõte, mille klient kinnitab.

58

Täiendused: Kas ja kuidas modelleerida äri? Selleks, et andmeaita arendama asuda, tuleks ärist üldisel tasemel aru saada. Allikate (4), (20), (15) ja (17) hinnangul tuleks äri vaadelda kolmest aspektist:, andmed, protsessid/kasutajad ja infrastruktuur. Andmete vaatlemiseks tuleks kokku panna kogu äri hõlmav kontseptuaalne andmemudel (soovitavalt normaliseeritud). Andmemudelina võib kasutada näiteks UML klassidiagrammi. Infrastruktuuri saab kujutada arhitektuuridiagrammil – näiteks UML deployment diagamm, Zachmani raamistikust valitud Business Modeling taseme võrgudiagramm või vabalt valitud notatsiooniga diagramm. Äriprotsesse saab lahti kirjutada klassikalise fuktsionaalse dekompositsiooni notatsioonis. Andmeolemid andmemudelis tuleks lahti seletada metaandmete sõnastikus, samuti tuleks sinna lisada funktsioonide hierarhia. Andmeolemid tuleks OLTP süsteemidega siduda. Seda võib teha kas klassikaliselt tabelis (v.t. Lisa 5) või (24) soovitusel klassikalises CRUD maatriksis (v.t. Lisa 6), kus ridadeks on maatriksi veergudeks on OLTP süsteemid ja ridadeks andmeolemid andmemudelist ning tabeli lahtrites on tähed C, R, U või D, mis tähistavad vastavalt, et OLTP süsteem kas loob (Create), loeb (Read), uuendab (Update) või kustutab (Delete) andmeolemi instantse. Nii saame leida eripärasid andmete esinemisel (andmeolem on esindatud mitmes süsteemis, andmeid ei esinegi), saame maatriksis andmeid klasterdada ning leida andmete ja OLTP süsteemide kogumid, mis manipuleerivad teatava hulga andmeolemitega. Funktsionaalse dekompositsiooni käigus kirjutame ettevõtte äriprotsesside puukujuliselt lahti, juurelemendiks on terve ettevõte, siis peamised äriprotsessid, nende alamprotsessid ja lehtelementideks operatsioonilised tegevused. Andmevakk peaks haarama teise taseme äriprotsessil vajatava info. Andmeolemid saame äriprotsessidega samamoodi seostada läbi CRUD maatriksi. Klasterdades maatriksi saame leida, milliste andmeolemitega milline äriprotsess manipuleerib ja niimoodi piirata ära dimensionaalsel modelleerimisel vajaminevate dimensioonide/faktide hulk. Kasutajate infovajadusi võime kujutada lihtsas maatriksis, milles veergudeks äriprotsesside nimed ja ridadeks kasutajate nimed ja tabeli lahtris on märge lahtris, kui kasutaja vajab antud äriprotsessi andmeid. Selle tabeli alusel on hiljem ka lihtne kasutajaõigusi määrata. Rollide, protsesside ja andmete vaheliste seoste näitamiseks pakub (17) välja lihtsa notatsiooni (v.t. Lisa 7). Alternatiivina pakub (22) äri modelleerimiseks välja 3-Schema Architecture, mille abil analüüsitakse ettevõtet kolmel tasemel (kontseptuaalne, operatsiooniline, tehniline) erinevate levinud diagrammide abil, ent kuna oma olemuselt on see väga sarnane eeltoodule, samas nõuab mitmete ettevõtte "X" jaoks liiga spetsiifiliste (kasutajarakenduste vaade, analüütiline andmediagramm) vaadete loomist, siis seda praegu välja ei paku.

59

Kuidas koguda ja dokumenteerida nõudmisi? Andmeaida nõudmiste ning vajaduste kogumiseks soovitatakse enamasti kolme viisi – alliksüsteemide analüüsi, kliendi olemasoleva aruandluse ja äridokumentatsiooni uurimist ja kasutajate intervjueerimist. Alliksüsteemide analüüsi tehakse ettevõttes "X" juba praegu põhjalikult, seega keskendun intervjueerimisele ning aruandluse uurimisele. (31) Annab üldise algoritmi intervjueerimiseks:

• Identifitseeri kasutajad. Enne intervjueerimist tuleb kokku panna nimekiri kasutajatest, kellega kohtuda soovitakse (rollide alusel) ning koguda aruandluse dokumente. (4) soovitab alustada intervjuusid kesktaseme juhtidest ja analüütikutest, saamaks ettevõtte üldise aruandluse ja andmeanalüüsi olukorra selgeks, peale seda liikuda tipptaseme juhtide intervjueerimisele saamaks visiooni ja andmeaida strateegilised eesmärgid ning peale seda intervjueerida reatöötajaid, et saada aimu, kuidas andmeid tekitatakse ja hallatakse. Peale intervjueerimise lõppu soovitab (4) pidada mõned koosolekud, kus koos kasutajatega peamisi nõuetegruppe vaadeldakse ning ajurünnaku vormis ideid juurde luuakse.

• Uuri praegust olukorda. Intervjuude esimese osa peaksid moodustama küsimused seniste tööülesannete, senise aruandluse sisu ja vormi kohta, infovajadused (olem, OLTP süsteem), peamised takistused, olulisimad kriteeriumid edukaks aruandluseks.

• Uuri soovitavat olukorda. Intervjuude teises pooles tuleks uurida, milliseid otsuseid peavad ärikasutajad langetama ning milliste otsuste jaoks neil täna piisavalt infot pole, küsida tuleks aruandluse vajakajäämiste ja mittefunktsionaalsete soovide kohta.

Intervjuudes kogutud nõudmiste üleskirjutamiseks mingeid erilisi notatsioone välja ei pakuta. (17) soovitab kogutud teabe jagada ülalt alla tasemeteks:

1. äri olemust kajastav, 2. ärieesmärke kajastav, 3. analüütilise taseme andmed, 4. rollide ja protsesside andmed, 5. peamised edukuse mõõdikud (Key Performance Indicators - KPI), 6. äri kirjeldavad dimensioonid (tähtskeemi koos KPI-dega), 7. andmeallikad ja andmete teisendused.

Selle jaotuse põhjal saame kirjutada tekstilise ülevaatedokumendi, mis sisaldab:

• süsteemi ülevaadet (äriprotsessid, rollid, peamised eesmärgid, strateegiad, kitsaskohad),

• projekti ülevaadet (ulatus, peamised eesmärgid), • ärinõudeid (milliseid andmeid soovitakse näha, millise täpsusega),

60

• dimensioonide ja faktide kandidaate (ärinõuetest lähtuvalt), • analüüsinõudeid (milliseid operatsioone peab andmetega võimalik olema

teha, võimalikud arvutusvalemid, jms), • mittefunktsionaalsed nõudmisi (kiirus, turvalisus, andmemahud jms), • alliksüsteemide analüüs (millised on peamised alliksüsteemid, milline on

nende senine aruandluse toetus), • peamised edufaktorid (millest sõltub süsteemi vastuvõtmine).

Ärinõuded saame alliksüsteemide andmetele esitatavate nõuetega siduda tabelis: Ärinõue Andmemudeli andmete nõue Analüütik "X" vajab ostetud materjalide aruannet päeva ja tarnija täpsusega.

Andmemudelis peavad materjalide ostutehingud evima kuupäeva ning olema seostatavad tarnijatega.

... Tabel 2. Ärinõuete seostamine andmemudeli andmete nõuetega Ärinõuded saame tehniliste nõuetega siduda tabelis: Ärinõue Sellest tulenev tehniline nõue Osakonnajuhatajad soovivad andmekuupi kliendipõhisest kasumlikkusest.

Vaja on andmekuubi serverit (MS SQL Server Analysis Services) ning andmekuupide visualiseerimise tööriista (Cognos PowerPlay, MS Office Excel)

... Tabel 3. Ärinõuete seostamine tehniliste nõuetega. (4) soovitab dimensioonide ühtlustamiseks üle mitme andmevaka luua "Data Warehouse Bus Architecture" diagramm (v.t. Lisa 8) – tabel, mille veergudeks on dimensioonid (andmemudelist olulisemad kirjeldavad andmeolemid, nagu näiteks aeg, klient, toode, kauplus), ridadeks aga andmevakad (andmevakk iga olulise äriprotsessi kohta). Tabelis on märge dimensiooni ja andmevaka ristumiskohas, kui dimensioon selle vaka tähtskeemides esineb. Nii saame veelkord identifitseerida, milliseid andmeolemeid millistesse vakkadesse kanda. Peale dimensioonikandidaatide ja äriprotsesside eristamist, saame kasutada inkremendi valiku kvadranti, et uurida, milline on potentsiaalne järgmine arendatav alamosa. Kuidas vormistada tulem kliendile arusaadavalt? Kliendile peaksime esitama kogu analüüsil kogutud dokumentatsiooni. Kuna nõudmiste dokument on tekstiline ning palju on kasutusel tabeleid ja maatrikseid, saab ka klient ehitatava süsteemi funktsionaalsusest ning ulatusest aimu, samas kui arendusmeeskonnale on lisatoeks alliksüsteemide analüüsi dokument ja kontseptuaalne andmemudel. Plaanimise etapist võib analüüsi kokkuvõtvasse dokumentatsiooni tuua inkremendi valiku kvadrant (v.t. Lisa 4).

61

Analüüsietapi kokkuvõtvas dokumentatsioonis peaks sisalduma:

• kontseptuaalne andmemudel, • äri funktsionaalne dekompositsioon, • infrastruktuuri mudel, • esialgne metaandmete sõnastik, • kasutajanõudmiste kokkuvõte, • alliksüsteemide analüüsi kokkuvõte.

Analüüsietapi kokkuvõtvas dokumentatsioonis võib vajadusel sisalduda:

• Data Warehouse Bus maatriks (Lisa 8), • inkremendi valiku kvadrant, • CRUD maatriks (andmeolemid versus OLTP süsteemid), • CRUD maatriks (andmeolemid versus äriprotsessid), • kasutajarollide/äriprotsesside seostamise tabel, • rollide-protsesside-andmete seostamise diagramm, • ärinõuete ja andmeolemite seoste tabel, • ärinõuete ja tehniliste nõuete seoste tabel.

Täiendatud algoritm:

1) Kasutajate vajaduste leidmiseks viiakse läbi intervjuud, kogutakse olemasoleva aruandluse dokumente. 2) Paralleelselt tehakse alliksüsteemide analüüsi (kirjeldatakse andmetabeleid ja ärireegleid). 3) Intervjuude alusel kirjutatakse nõudmiste dokument ning ettevõtte infrastruktuuri ülevaade. 4) Seostatakse alliksüsteemide analüüsi tulemused nõuetega, luuakse CRUD maatriksid, seosetabelid ja Data Warehouse Bus maatriks. 5) Etapi lõppdokumendina luuakse analüüsi kokkuvõte, mille klient kinnitab. Arendusel tekkinud terminoloogia kogutakse metaandmete sõnastikku. 6) Langetatakse otsus, millist inkrementi järgmisena arendama asuda.

Dokumentatsioon: Peamised dokumendid:

• kontseptuaalne andmemudel, • äri funktsionaalne dekompositsioon, • infrastruktuuridiagramm, • kasutajanõudmiste kokkuvõte.

Lisaks valik: • Data Warehouse Bus maatriks (Lisa 8), • inkremendi valiku kvadrant, • CRUD maatriks (andmeolemid versus OLTP süsteemid), • CRUD maatriks (andmeolemid versus äriprotsessid),

62

• kasutajarollide/äriprotsesside seostamise tabel, • rollide-protsesside-andmete seostamise diagramm, • ärinõuete ja andmeolemite seoste tabel, • ärinõuete ja tehniliste nõuete seoste tabel.

2.4.4 Elaboration (disain) Praegune algoritm:

1) Lähtuvalt allika analüüsist luuakse kontseptuaalne andmemudel. 2) Iga tabeli kohta tehakse kirjeldus, milles andmed selle kuju, andmete iseloomu, laadimiste ning testimise kohta (ETL spetsifikatsioon sisaldub andmetabelite disaini dokumendis, testide kirjeldused on eraldi). 3) Etapi lõpudokumendina luuakse disainietepi kokkuvõte, mille klient kinnitab.

Täiendused: Kuidas tuletada tähtskeemi analüüsidokumentatsioonist? Disainietapi põhiülesanne on tuletada alliksüsteemidest ning erinevatest nõuetest andmeaida (valitud inkremendi) andmemudel, ETL spetsifikatsioon ning testide kirjeldused. Siin teeme ka täiendusi metaandmete sõnastikku. Disainietapis keskendume alati ainult valitud inkremendile (ehk siis valitud andmevakale). 1. Staging area andmemudel (15) soovitab kasutada andmeaida staging area andmemudelina võimalikult üldist ja 3. normaalkujul andmemudelit, tuletades selle otseselt analüüsietapis kokkupandud ettevõtte kontseptuaalsest andmemudelist. NCR läheb veelgi kaugemale, müües andmeaida abstraktset normaliseeritud andmemudelit erinevatele ettevõttetüüpidele (finantsettevõte, jaekaubanduse ettevõte) koos oma Teradata RDBMS-iga. Need normaliseeritud mudelid ei saa toimida presentatsioonikihina kliendi jaoks, kuna normaliseeritud mudel kogu äri kohta on reeglina liiga keerukas, et ärikasutaja seda intuitiivselt mõistaks ning otsustusel kasutada suudaks ja lisaks ei ole need suurte ja keeruliste analüütiliste päringute kirjutamise ja käivitamise jaoks otstarbekad. Olen Eestis kohanud lähenemist, et ettevõttes disainitakse andmeaidale staging areaks abstraktne normaliseeritud andmemudel, lepitakse OLTP arendajatega kokku liidesed (andmemudelid, millega peidetakse OLTP süsteemide anomaaliad ja muutused andmeaida laadimisprotseduuride eest) ning ehitatakse presentatsioonikihiks hulk tähtskeeme SQL vaadetena. Abstraktse ja normaliseeritud staging area eelisteks on:

• dünaamilisus (sellelt võib kergelt ehitada mistahes tähtskeeme, mille andmeid me aita laeme),

• vastupidavus andmeaida nõudmiste ja OLTP süsteemide muutustele, kuna me peame ümber ehitama kas laadimisprotseduurid või tähtskeemid presentatsioonikihis, ent mitte kogu andmeaida.

2. Presentatsioonikiht - tähtskeemid

63

Ärinõuete ning allika analüüsi dokumentide abil saame kokku panna mõõdikute nimekirja. Need saavad andmeaida andmemudeli faktideks. (20) soovitab analüüsietapis Key Performance Indicatorid (KPI-d) automaatselt tähtskeemis faktideks lugeda. Ralph Kimball (4) pakub andmeaida tähtskeemi tuletamiseks nelja-sammulise algoritmi: 1. vali äriprotsess, 2. vali granulaarsus, 3. vali dimensioonid, 4. vali faktid. Äriprotsessi me valitud lähenemise juures disainietapis valida enam ei saa, kuna keskendume ühe äriprotsessi jaoks andmevaka rajamisele. Granulaarsus sõltub ühelt poolt ärinõuetest, kui üleüldine soovitus on, et kui tehnoloogiliselt võimalik (andmemahud allika analüüsi dokumentidest!), tuleks valida minimaalne granulaarsus – s.t. laadida andmed alliksüsteemi täpsusega. Sealjuures tuleb meeles pidada, et kui andmed laetakse mitmest alliksüsteemist, siis peame valima andmeaida faktitabeli granulaarsuseks maksimaalse graanuliga andmebaasi andmete detailsuse või looma eraldi faktitabelid. Faktitabeli kõigil andmetel peab olema sama detailsuseaste (kuna vastasel juhul ei oleks need agregeeritavad). Dimensioonide valimine on otseselt seotud ärinõuete kogumisel saadud infovajaduste ning alliksüsteemide andmete seostamisega. Intervjuudes küsisime kasutajatelt, milliseid olulisi andmeolemeid nad mõõdavad? Milliste olemite vahelisi seoseid nad aruannetes uurivad? Enamasti on dimensioonideks aeg, olulised tegutsejad (actors) OLTP süsteemides (klient, müüja, tarnija), organisatsiooni struktuur (osakond, tütarettevõte), kesksemad andmeolemid (leping). Olles loonud nimekirja kõigist soovitud olemitest, peaksime pöörduma alliksüsteemide poole ning denormaliseerima dimensioonideks valitud olemeid ümbritsevad staatuse, tüübi jms tabelid, et saada dimensioonist hierarhia (Hierarhia klient: segment -> staatus - > ostja isik). Olles rahul dimensioonide nimedega, valime mõõdikud (numbrilised suurused, faktid), mis antud olemitekomplekti suhteid iseloomustavad. Selle jaoks tuleks ärinõuete kirjeldustest leida meie valitud dimensioonidekomplekti ühised mõõdikud ning sobitada need andmete reaalsusega. Tähtskeemi disain on balansseerimine ärinõuete ideaali ja alliksüsteemide andmete reaalsuse vahel. Analüüsietapi infrastruktuuridokumendist ja ärinõuete ning tehniliste nõuete seoste tabelist saame teha detailse arhitektuurimudeli (näiteks koosnevana Zachmani raamistiku tehnoloogilise taseme funktsionaalsuse ja võrgu diagrammid), kirjeldada tekstiliselt riist- ja tarkvaratooted, mida vaja paigaldada (alus hilisemaks installatsioonijuhendiks). Kuidas kirja panna ETL spetsifikatsioon?

64

Ralph Kimball soovitab allikandmete analüüsi ja andmeaida tähtskeemide lahtikirjutmise järel nende kahe andmed seostada tabeli abil, mille sturkuur võiks olla järgmine:

• DWH tabeli nimi, • DWH veeru nimi, • DWH veeru andmetüüp, • DWH veeru kirjeldus, • OLTP süsteemi nimi, • OLTP tabeli nimi, • OLTP veeru nimi, • Laadimisel tehtud muudatused (identifikaatori määramine jms), • Laadimisel tehtud arvutused, • Laadimisel kasutatud filtrid.

Laadimisel tehtavate muudatuste vajalikkuse ja kuju leiame, võrreldes alliksüsteemi tabeli veerge andmeaida andmemudeli veergudega (eelkõige OLTP ärireeglite ja DWH ärinõudmiste kõrvutamisel). See on mahukas ja keeruline töö. Laadimisel tehtavate muudatuste kirjeldused peaksid olema SQL kujul, kui kasutame ETL-s ise kirjutatud SQL päringuid. Kui kasutame mõnd ETL tööriista võime need kirjutada vabas vormis. ETL protsessi kirjeldamiseks andmiseks soovitab (20) ETL Process Flow Diagrammi (ETL protsessi voodiagrammi). Sellel kujutatakse erinevad protsessid, kasutatud kasutatud tarkvara ja andmehoidlad (programmimoodulid, tööfailid, andmetabelid) ning nendevahelised suhted (v.t. Lisa 9). ETL voodiagrammi aluseks on ühelt poolt OLTP ja DWH andmetabelite seoste tabel, teisalt arhitektuurimudel, kust saame andmebaasid ning ärireeglite ja ärinõuete käsitsi võrdlemine. Kuidas vormistada disainietapi dokumentatsioon kliendile arusaadavalt? Kuna disainietapp arenduses peaks olema tehniliste lahenduste ning analüüsil kirjeldatud vajaduste ja nõuete kokkuviimine, leian, et klient ei peaks disainidokumente eraldi kinnitama. Kliendi IT osakonna inimesed peaksid küll olema aktiivselt kaasatud otsuste tegemisse ja probleemide lahendamisse ning peaksid evima ligipääsu dokumentidele, ent äriinimestega laua taha istuda pole vaja. Disainietappi kokkuvõtva dokumentatsiooni hulka kuuluvad:

• staging area füüsiline andmemudel, • andmevaka füüsiline andmemudel, • ETL alliktabelite ning andmeaida tabelite seosedokument, • ETL protsessi voodiagramm, • andmeaida tabelite detailne disainidokument (sh. testid).

Täiendatud algoritm:

65

1) Lähtuvalt analüüsietapi kontseptuaalsest andmemudelist ja allika analüüsi tulemustest luuakse normaliseeritud staging area andmemudel (või täiendus olemasolevale mudelile käesoleva iteratsiooni jaoks). 2) Ärinõuete kirjeldustest ja allikandmete analüüsist tuletatakse tähtskeemid. 3) Iga tähtskeemis esineva tabeli kohta tehakse kirjeldus, milles andmed selle kuju, andmete iseloomu, laadimiste ning testimise kohta (ETL spetsifikatsioon sisaldub andmetabelite disaini dokumendis, testide kirjeldused on eraldi). 4) Alliksüsteemi tabelite ja andmeaida tabelite vahel luuakse seosed (source to target mapping). 5) Seostatud alliktabelite ja andmeaida tabelite alusel luuakse ETL protsessi voodiagramm. 6) Etapi lõpudokumendiks on eelnevalt loodud dokumentide ühend. Kirjeldatud tabelite ning ETL loogika info salvestatakse metaandmete hoidlasse.

Lisandunud dokumentatsioon: • staging area normaliseeritud andmemudel, • OLTP süsteemidest laadimiseks kokkulepitud liidesed – s.t.

andmemudelid, mis kirjeldavad OLTP süsteemi väljundandmete kuju ning suhteid,

• ETL source to target mapping (alliktabeli ning andmeaida tabeli seos), • ETL voodiagramm.

2.4.5 Construction (ehitamine) Praegune algoritm:

1) Rajatakse andmebaasid (füüsilist andmemudelit eraldi ei dokumenteerita, see tekib andmetabelite disainidokumentidest ja kontseptuaalsest andmemudelist). 2) Luuakse ETL skriptid. 3) Tehakse katselaadimised, testirobot jooksutab kirjeldatud teste. Aluseks on disainidokumentatsioon. Seda täiendatakse vajadusel.

Täiendused: Mida peaks sisaldama metaandmete sõnastik? Metaandmete kogum on andmeaida kasutatavuse ning andmekvaliteedi probleemide vältimise võtmeks. Sisult on see hulk tabeleid ja diagramme, mis selgitavad lahti, mida tähendavad andmeaita laetavad andmed, kust need tulevad ning kudas need andmeaita laetakse. Vormilt on metaandmete sõnastik kas dokument või (interneti)rakendus. Parim lahendus metaandmete haldamiseks oleks kasutada tooteid (RDBMS-id, ETL tööriistad), mis on võimelised metaandmeid vahetama Object Management Group-i Common Warehouse Metamodel alusel (30). Sellisteks toodeteks on näiteks Oracle 9i RDBMS, Business Objects, Informatica ja SAS andmeanalüüsitööriistad. Business Objects pakub ka metaandmete sõnastiku funktsionaalsust. (17) peab metaandmete sõnastikku põhiliseks andmeaida navigeerimise tööriistaks. (4), (20) ja (17) alusel tuleb arenduse käigus metaandmete hoidlasse lisada:

66

• kogu äri andmemudel, • ärireeglid (andmemudelis), • äriprotsesside kirjeldused, • äriterminite kirjeldused, • andmete kuuluvus (kes vastutab, kes lisab, kes loeb), • OLTP süsteemide nimetused ja asukohad, • alliktabelite definitsioonid OLTP süsteemides, • alliktabelite ja andmeaida tabelite seosed (s.t. milline DWH tabeli veerg

laetakse millisest OLTP tabeli veerust ning mida laadimise käigus tehakse),

• ETL protsesside kirjeldused (kust andmeid võetakse, kuhu suunatakse), • andmeaida andmemudel.

Metaandmete sõnastiku rakendus tuleb kliendile eraldi müüa või arendada, ent see ei mahu käesoleva töö skoopi.

Kuidas kliendile arusaadavalt näidata, mis on valmis? Dokumentatsiooni ehitamise etapil enam juurde ei peaks looma. Juhul, kui teadmine on vaja veel visualiseerida, tuleks see analüüsi ja disainimudelite abil üles kirjutada. S.t. ehitamise etapis ei ole koht analüüsi ja disaini jaoks.

Täiendatud algoritm: 1) Rajatakse andmebaasid (füüsilist andmemudelit eraldi ei dokumenteerita, see tekib andmetabelite disainidokumentidest ja kontseptuaalsest andmemudelist). 2) Luuakse ETL skriptid. 3) Tehakse katselaadimised, testirobot jooksutab kirjeldatud teste. Igal sammul tekkinud infoga täiendatakse metaandmete sõnastikku. Aluseks on disainidokumentatsioon. Seda täiendatakse vajadusel.

Dokumentatsioon: • Metaandmete kogum (mingi rakenduse abil salvestatud näiteks Common

Warehouse Metamodel standardi alusel).

2.4.6 Transition (juurutamine) Praegune algoritm:

1) Peale testide õnnestumist luuakse kasutajajuhend ja hooldusjuhend. 2) Installeeritakse toodangukeskkond (s.t. uus tühi koopia testkeskkonnast, luuakse ühendused OLTP süsteemidesse, antakse kasutajaõigused, installeeritakse kasutajatooted). 3) Kasutajatele viiakse läbi kokkulepitud hulk koolitussessioone (see eeldab kasutajatööriistade olemasolu, mille valimist ja arendamist ma ei käsitle).

Täiendused: Kuidas dokumenteerida tagasiside? Iteratiivse arenduse korral muutub klientide tagasiside valmissaadud rakenduse kohta järgmise arendustsükli nõudmisteks. Seega tuleks igasugune tagasiside kirja

67

panna üldistesse nõudmiste dokumenti ning käsitleda seda võrdselt intervjuude ja koosolekute ajal teadasaaduga. Milline peaks olema kliendile üleantav dokumentatsioon? Kliendile tuleks arenduse lõppedes üle anda:

• analüüsietappi kokkuvõttev dokumentatsioon, • disainietappi kokkuvõttev dokumentatsioon, • kasutajajuhend, • hooldusjuhend, • Service Level Agreement (Teenuste kvaliteedi leping).

Service Level Agreement (SLA) on kokkulepe kliendi ja ettevõtte "X" vahel, millega pannakse paika andmeaida vigade esinemise lubatud määr (tõsi, klient sooviks kindlasti utoopilist 100% veakindlat süsteemi), hoolduse ja vigade parandamise teostamise edasine käik ning "garantiiremondi" alla kuuluvad vead, maksimaalsed vastuseajad, andmete kvaliteedi piirangud jms. SLA peab kindlasti olema kokkulepe, mitte ühepoolne ultimaatum, kuna vastasel juhul võib kas ettevõte "X" kliendi ootusi petta või klient nõuda midagi utoopilist. Äriintelligentsisüsteemi SLA koostamist peetakse äärmiselt keerukaks ja väheuuritud valdkonnaks, seega tuleks ettevõttes "X" koostada lihtne ja kogemustest lähtuv leping. Ülevaade SLA koostamisest äriintelligentsisüsteemide jaoks võiks olla magistritöö skoobiga uurimus.

Täiendatud algoritm: 1) Peale testide läbiviimist lepitakse kokku Service Level Agreement, koostatakse kasutusjuhend ja hooldusjuhend. 2) Installeeritakse toodangukeskkond (s.t. uus tühi koopia testkeskkonnast, luuakse ühendused OLTP süsteemidesse, antakse kasutajaõigused, installeeritakse kasutajatooted). 3) Kasutajatele viiakse läbi kokkulepitud mahus koolitus (see eeldab kasutajatööriistade olemasolu, mille valimist ja arendamist ma ei käsitle).

Lisandunud dokumentatsioon: • Service Level Agreement.

2.4.7 Arenduse kestus Praegune lähenemine:

Ühel iteratsioonil arendatakse valmis üks andmevakk. Andmevaka ulatuseks on loogiline tükk lepingus ettenähtud andmetest (üks ärivaldkond, üks OLTP süsteem). Iteratsioonide hulk tuleneb suhteliselt üheselt lepingust määratust (lepingus on kirjas, milliseid andmeid soovitakse andmeaita laadida). Kliendi tagasisidet ei dokumenteerita, sellega arvestatakse töö käigus.

Täiendused: Milline peaks olema iteratsioonide arv? Milline peaks olema ühe iteratsiooni kestus ja skoop? (29) toob elulise näite andmeaida projekti lõppemisest:

68

A World War II British pilot, when asked how he knew when the Battle of Britain was over, responded, “We got out of bed one morning and the Germans didn’t come.” OLAP projects are finished, or as finished as they are going to be, when the phone stops ringing or e-mails stop coming with user feedback.6 Ralph Kimball (4), (8) soovitab iga äriprotsessi kohta teha vähemalt ühe arenduse iteratsiooni. See tähendab, et arenduse esimesel tsüklil koostame lakoonilise üldvaate organisatsioonile ning siis loome iga väärtusahela olulise äriprotsessi jaoks andmevaka, kogudes nõudmisi, disainides, ehitades, testides ja juurutades. Keerulisemate äriprotsesside korral soovitab Kimball teha vakk valmis mitme iteratsiooniga – näiteks teha esimesel iteratsioonil andmelaadimised ilma olulise hulga ajalooliste andmeteta või luua ainult madalaima granulaarsusega faktitabelid ning jätta neist sõltuvad või agregeeritud tulemusi sisaldavad tähtskeemid teiseks iteratsiooniks. Esimene iteratsioon, kus luuakse üldvaade organisatsiooni andmetele ning kogutakse kõrgtasemel nõuded kogu andmeaidale, on pikem, edasised iteratsioonid lühemad. Konkreetsed ajalised pikkused sõltuvad otseselt meeskonna suurusest ning kliendi andmete ja nõudmiste iseloomust, ent Eesti ettevõtete arendusmeeskondada ja klientide korral peaks üks andmeait valmima umbes kvartali jooksul.

2.4.8 Kokkuvõte täiendustest Täiendatud arenduse elutsükkel, kursiivis on tulemid, mis ei ole täiendustega lisatud või oluliselt muudetud:

6 Kui II Maailmasõja aegselt Briti piloodilt küsiti, kuidas nad teadsid, millal lahing Suurbritannia kohal oli läbi, vastas ta järgmiselt: "Ühel hommikul sakslasi enam ei tulnud." OLAP rakendused on nii valmis kui valmis nad olla saavad, kui kasutajatelt enam olulist tagasisidet ei tule.

69

Joonis 17. Täiendatud arendusprotsessi skeem. Põhilised täiendused on seotud projekti alustamise ja iteratsioonide plaanimise, stateegilise analüüsi ja edasistel iteratsioonidel nõuete kogumise ja mudelite omavaheliste seostamiste osas. Keerulisim ülesanne arendamisel oli enne allikandmete analüüs – tuli leida võimalikult palju andmeid kliendi spetsifitseeritud üldise teema kohta ja need aita laadida. Täiendatud protsessi keerulisim koht on kliendi soovide ning reaalse maailma andmete kokkuviimine. S.t. ei ole oluline kõigi andmete laadimine, vaid nende andmete identifitseerimine, mida analüüsil kasutada tahetakse. Selle töö kergendamiseks pakkusin erinevate allikate toel välja hulga seosetabeleid, maatrikseid ning mõned diagrammid (inkremendi valiku kvadrant, andmete-protsesside-rollide seoste diagramm).

Business justification Inception

Elaboration

Construction Transition

- Kliendi valmisoleku hindamine - Strat analüüsi dokumentatsiooni hindamine, lähenemisviisi valik, iteratsiooniplaan - Leping

- Konts. andmemudel - Funktsionaalne dekompositsioon - Infrastruktuuri mudel - Alliksüsteemide kirjeldused - >Mitmesugused seosemaatriksid ja mudelid omal valikul - Analüüsi kokkuvõte - Ärisõnastik

- Disainidokumentatsiooni täpsustused - Metamudel

- Füüsiline staging area andmemudel - Füüsiline andmevaka andmemudel - Andmevaka tabelite detailsed kirjeldused - ETL mapping - ETL voodiagramm - Testide kirjeldused testirobotile (SQL)

- Kasutajajuhend - Hoolduse juhend - Service Level Agreement

For each iteratsioon in plaan

70

2.5 Täienduste analüüs 2.5.1 Tegevuste mudelid Ettevõtte "X" andmeaitade arendusprotsess seni:

Vastab pakkumisega

Sõlmib lepingu

Määratakse alliksüsteemid

Alliksüsteemi analüüsid

Uuritakse praegust aruandlust

Analüüsi kokkuvõte

Luuakse DWH andmemudel

Luuakse tabelite kirjeldused ja testid

Disainietapi kokkuvõte

Ehitatakse ja testitakse

Juurutatakse

Esitab pakkumiskutse

Sõlmib lepingu

Vastab küsimustele

Võtab vastu

Võtab vastu

Võtab vastu

Iteratsioon läbi

KlientEttevõte X

Joonis 18. Ettevõtte "X" olemasoleva arendusprotsessi tegevusdiagramm.

71

Täiendatud arendusprotsess:

Kliendi ettevõtte valmisoleku uurimine

Vastab pakkumisega

Sõlmib lepingu

Kasutajate intervjueerimine

Ajurünnakud

Andmeallikate määramine ja analüüs

Koostatakse nõuete dokument

Koostatakse strat analüüsi mudelid ja seoste dokumendid

Analüüsi kokkuvõte

Otsustatakse, millist inkrementi järgmisena ehitada

Luuakse staging area mudel

Dimensionaalne modelleerimine - luuakse presentatsioonikihi andmemudel

Luuakse DWH tabelite kirjeldused

Luuakse source to target mappings

Luuakse ETL spetsifikatsioonid

Ehitatakse ja testitakse

Juurutatakse

Iteratsioon läbi

Esitab pakkumiskutse

Vastab küsimustele

Sõlmib lepingu

Vastab küsimustele

Vastab küsimustele

Võtab vastu

Võtab vastu

KlientEttev õte X

Joonis 19. Täiendatud arendusprotses

72

2.5.2 Põhilised arengud Põhilised muutused tegevustes:

• enne kliendiga lepingu sõlmimist uuritakse ettevõtte valmisolekut, • stateegilise analüüsi raames luuakse ettevõtte andmetest, protsessidest ja

rollidest kindlaksmääratud mudelid, • nõuete kogumise ja kokkuvõtliku dokumentatsiooni skeem on paika pandud, • tähtskeemide loomisel saame kasutada andmete ja süsteemide ning andmete ja

nõuete seostabeleid ja –maatrikseid, • analüüsi käigus luuakse seoseid andmete ja rollide ning andmete ja protsesside

vahel, • juurutamisel sõlmitakse Service Level Agreement, mis määratleb, mida võib

süsteemi käitumisel vigadeks pidada ja milline osa vastutusest jääb arendaja, milline osa kliendi kanda.

Põhilised muutused dokumentatsioonis:

• kolm vaadet andmetele: andmemudel, funktsionaalne mudel ja rollidele kahel tasemel – kontseptuaalne ja füüsiline,

• seosdokumendid erinevate vaadete vahel. Põhilised muutused kliendisuhtluses:

• skeem läbirääkimisteks enne lepingu sõlmimist, • skeem nõudmiste kogumiseks, • disainidokumentatsiooni enam äri-tellijatel kinnitada ei lasta, kuna see on liiga

tehniline. Küll aga suheldakse kliendi IT poolega, • Service Level Agreement määratleb poolte kohustused ja vastutused.

2.5.3 SWOT analüüs Kirjutan Strengths-Weaknesses-Opportunities-Threats7 tabelis lahti oma nägemuse täiendatud protsessi eelistest ning puudustest võrreldes vana protsessiga: S (tugevused) • Kliendile ülevaade, kas ettevõte on

andmeaida projektiks valmis. • Lähenemise valiku ja

iteratsiooniplaani tegemine formaalsem.

• Parem ülevaade ettevõttest (analüüs). • Kliendikesksem lähenemine

nõudmiste osas. • Kliendile arusaadavad mudelid.

W (nõrkused) • Protsessis on rohkem tegevusi, s.t. aja-

ja töökulu suurem. • Kasutajate nõudmised ei pruugi

andmete reaalsusega kokkupandavad olla.

• Klient ei pruugi teada, mida ta soovib.

7 Eesti keelde tõlgituna "Tugevused-Nõrkused-Võimalused-Ohud"

73

• Parem dokumentatsiooni seostatus. • Enam tähelepanu metaandmetele O (võimalused) • Disainietapi otsuste tegemine ja

mudelite ehitamine tuletamise teel (tähtskeemi elementide tuletamine nõuete tekstilistest kirjeldustest).

• Analüüsidokumentatsiooni võimalik hilisemates projektides ära kasutada.

T (ohud) • Dokumentatsiooni tootmine

dokumenteerimise pärast, mitte edasise töö lihtsustamiseks.

• Analüüsi ja disainietappide mudeleid mitte sidustades, üksteisest mitte tuletades teeme sarnast tööd mitu korda.

• Metaandmete sõnastik vananeb unarusse jäädes kiiresti, selle täiendamine peab olema pidev protsess.

• Service Level Agreementi andmeaitadele on väga keeruline koostada, valede otsuste korral võib see aga ühele osapoolele palju probleeme tuua (näiteks ei ole analüütiliste andmebaaside päringutele vastamise kiiruse nõuete määramine kaugeltki nii ühene, kui OLTP andmebaaside päringute kiiruse nõuete väljatöötamine).

74

Kokkuvõte

Tulemused ja järeldused

Uurides maailmapraktikat andmeaidasüsteemide arendamisel näen, et lähenemisi äriettevõtte tükeldamisele, andmeaida ülesehitusele, ehitamise protsessile ning dokumentatsiooni tootmisele on palju ning ka olulisemate autorite seisukohad ei lange kaugeltki kokku. Projekti tükeldamise osas ehitamisel eristatakse näiteks big-bang, top-down ja bottom-up lähenemist, nõuete kogumise osas andmekeskset, protsessikeskset ja kasutajakeskset lähenemist. Eraldi arendusprotsessidena pakutakse välja teiste hulgas protsessid nimedega Business Dimensional Lifecycle, Business Intelligence Roadmap, Data Warehouse Lifecycle Management. Dokumenteerimiseks soovitatakse erinevates paljusid levinud diagramme, näiteks erinevates otstarvetes UML kasutusjuhtusid, klassikalist olemi-suhte diagrammi, funktsionaalse dekompositsiooni diagrammi ning CRUD maatriksit. Olulisemateks autoriteks ning teoreetikuteks peetakse W.H. Inmonit, Ralph Kimballi, Craig Larmanit. Läbiva joonena rõhutavad mitmetes peamised teooriad:

• äri modelleerimise vajalikkust, • ärikasutaja infovajaduste prioriteediks seadmist, • arendusprotsessi iteratiivsuse ja inkrementaalsuse vajalikkust, • multidimensionaalse andmemudeli (tähtskeemi) eelistamist, • ise programmeeritava osa vähenemist ning karbitoodete osakaalu suurenemist

arendamises (ETL tööriistad, geneerilised andmemudelid). Ettevõtte "X" olemasolevat andmeaitade arendusprotsessi analüüsides leidsin, et see on üsna kergekaaluline, iteratiivne ja peamiselt andmekeskne protsess. Leidsin, et põhiprobleemiks peetakse ärikasutaja vajaduste vähest uurimist (s.t. liiga andmekeskset lähenemist), projektidokumentatsiooni liigset tehnilisust ning erinevate arendusel tekkinud mudelite ja vaadete vähest seostamist. Lähtudes teoreetilisest baasist ning väljatoodud probleemidest pakkusin ettevõtte "X" andmeaitade arendusprotsessile täiendusi. Täienduste põhiraskus langes:

• andmeaida skoobi määramisele ja projekti iteratsioonide planeerimisele • strateegilisel analüüsil kolme vaate – andmed, protsessid, arhitektuur loomisele • ärinõuete kogumisele • erinevate arendusel loodud mudelite seostamisele

Täiendatud protsess on andmekeskse ja protsessikeskse lähenemise hübriid. Protsessi olulisimaks sammuks on kogutud ärinõuete ja alliksüsteemide andmete kokkupanemine ning selle alusel andmeaida tähtskeemide dimensioonitabelite ja faktitabelite valimine. Tööst järeldan, et ettevõtte "X" jaoks sobib andmeaida arendusprotsess, mis baseerub järgmistel põhimõtetel:

75

• kõigepealt modelleeritakse kiiresti (s.t. odavalt) äri andmete, protsesside ja rollide vaadetes (ärikasutajate intervjueerimine, alliksüsteemide analüüs),

• seejärel valitakse järjest seatud kriteeriumitele sobivaim äriprotsess ning arendatakse selle jaoks andmevakk (täpsustades nõuded, tehes detailsema analüüsi ning disaini, ehitades, testides ja juurutades andmevaks),

• arendus lõpeb, kui kõik soovitavad äriprotsessid omavad andmevakka, • tulemiks on ühist staging areat ning ühist ETL protsessi eviv andmevakkade

kogum.

Tulevikuvisioon

Ralph Kimball prognoosib (4), et andmeaitade arengu võtmesõnad lähitulevikus on modulaarsus, odavnemine, hajusus. See tähendab, et andmeaidad pannakse üha enam kokku karbitoodetest (ETL tööriistad, ostetavad-müüdavad geneerilised andmemudelid, standardiseeritud ärimõõdikud) ja rätsepatööks jääb toodete kohandamine kliendi tarbeks. Ennustatakse, et edaspidi keskendutakse peale transaktsionaalsete andmete (s.t. tehingute, lepingute) ka kliendi käitumise andmete analüüsile (näiteks clickstream analüüs veebilehtedel või RFID sensorite abil inimeste teekondade analüüs kauplustes, töökohtades). Kerschberg (32) ennustab, et andmeaidad teisenevad andmebaasist üha enam teabeohjesüsteemideks, kogudes alliksüsteemidest mitte ainult andmeid, vaid teadmisi, eesmärgistatud informatsiooni. Juba praegu kogutakse andmeaida metaandmete sõnastikku palju teadmist äri toimimise, reeglite ja andmete kohta. Warmer (33) kirjeldab, kuidas UML arenedes on võimalik luua mudelitele juurde käitumise ja tegevuste kirjeldusi, kasutades UML keeli Object Constraint Language ja Object Query Language. Nii saaksime näiteks andmete metamudelis kirjeldada ärireeglid ning päringud ja automaatselt luua koodi näiteks ETL jaoks. White (34) iseloomustab andmeaidale ehitatud ettevõtte infoportaali, mis annab kasutajale märku andmete soovitud viisil muutumisest, sündmustest andmetega, annab proaktiivselt soovitusi otsuste tegemiseks ja suudab ise reeglite põhjal käivitada protsesse ja manipuleerida andmetega ettevõtte infosüsteemis. Ettevõtte "X" andmeaitade arendusprotsessi edasise täiendamise osas vääriks kindlasti uurimist see, kas ja kuidas saaks agiilmetoodikaid andmeaitade või andmevakkade rajamisel kasutada, kas oleks võimalik dimensionaalset modelleerimist teataval määral automatiseerida (tuletada tähtskeemi elemendid automaatselt andmemudelist ja nõudmiste alusel kokku pandud reeglitest) ning milline peaks olema äriintelligentsisüsteemi Service Level Agreement.

76

Kasutatud kirjandus

1. "Rational Unified Process". http://en.wikipedia.org/wiki/RUP, 06.07.2005. 2. "What is Extreme Programming".

http://www.extremeprogramming.org/what.html, 06.07.2005. 3. Inmon, W.H. "Building the Data Warehouse". New York, USA: John Wiley &

Sons, 1993. 4. Kimball, R. & Reeves, L. & Ross, M. & Thorntwaite W. "The Data Warehouse

Lifecycle Toolkit". New York, USA: John Wiley & Sons, 2000. 5. Haughey, T. "An Analytical Model Manifesto".

http://www.infomodelusa.com/Articles/DWDM_Manifesto_Part_One_v7a.pdf, 18.06.2005.

6. Larman, C & Basili V.R., "Iterative and Incremental Development: A Brief History". http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf, 18.06.2005.

7. "RUP Leads as the Basis for Iterative Development". http://www.lamri.com/Lamri_Survey_results2.pdf, 18.06.2005.

8. Kimball, R. & & Ross, M. "The Data Warehouse Toolkit". New York, USA: John Wiley & Sons, 2000.

9. Friedman, T. "Building an Agile Infrastructure for Business Intelligence". Business Intelligence Summit, Amsterdam, Holland, 2004.

10. Haughey, T, An Analytical Modeling Manifesto, http://www.infomodelusa.com/Articles/DWDM_Manifesto_Part_One_v7a.pdf, 18.06.2005.

11. Wu, J. "Developing World Class BI, DW and BPM Solutions in the 21st Century". DCI Business Intelligence and Data Warehousing Conference; Boston, USA, 2004.

12. Firestone, J.M. "Data Warehouses and Data Marts: A Dynamic View". http://www.dkms.com/papers/dwdmdv.pdf, 07.06.2005.

13. Hayes, F. "The Story So Far: Business Intelligence". http://www.computerworld.com/databasetopics/data/story/0,10801,80227,00.html, 07.06.2005.

14. Perkins, A. "Data Warehouse Architecture: A Blueprint for Success", http://www.dmreview.com/whitepaper/dwb.pdf, 18.06.2005.

15. Longman, C. "Data Warehouse Lifecycle Management: Concepts and Principles". http://www.dmreview.com/whitepaper/WID1002691.pdf, 18.06.2005.

16. Paim, F. R. S. & Castro, J. F. B. "DWARF – An Approach for Requirements Definition and Management of Data Warehouse Systems". http://www.di.ufpe.br/~ler/publicacoes/pub_2003/RE03_DWARF.pdf, 07.06.2005.

17. Nolan, S. & Huguelet, T. "Microsoft SQL Server 7.0 Data Warehousing Training Kit". USA: Microsoft Press, 2003.

18. Simon, A. K. "Towards a theoretical framework for Business Process Reengineering". http://www.informatik.gu.se/~kai/pub/thesis.pdf, 18.06.2005.

19. Lane, P. "Oracle 9i Data Warehousing Guide". USA: Oracle Corporation, 2002. 20. Moss, L. T. & Atre S. "Business Intelligence Roadmap". USA: Addison-

Wesley, 2001.

77

21. Bruckner, R. M & List, B & Schiefer J. "Developing Requirements for Data Warehouse Systems With Use Cases". http://www.ifs.tuwien.ac.at/~bruckner/pubs/amcis2001_requirements.pdf, 07.06.2005.

22. Chan, J. O. "Building Data Warehouses Using the Enterprise Modeling Framework". http://www.iima.org/JITIM/JITIM%2013%20Downloads/P9-Chan.pdf, 07.06.2005.

23. Bruckner, R. M & List, B & Schiefer J. "A Comparison Of Data Warehouse Development Methodologies. Case Study Of The Process Warehouse". http://www.ifs.tuwien.ac.at/~bruckner/pubs/dexa2002_dwh_development.pdf, 07.06.2005.

24. Politano, A.L. "Salvaging Information Engineerin Techniques in a Data Warehouse Environment". http://www.dmreview.com/whitepaper/wid321.pdf, 07.06.2005.

25. List, B. & Schiefer, J. & Min, A. "T, Process-Oriented Requirement Analysis Supporting the Data Warehouse Design Process: A Use Case Driven Approach". http://www.ifs.tuwien.ac.at/~tjoa/pub_pdf/lis_dexa00.pdf, 07.06.2005.

26. Trujillo, J. & Palomar, M. & Gomez, J. & Il-Yeol, S. "Designing Data Warehouses with OO Conceptual Models". http://www.dlsi.ua.es/~mpalomar/gold.pdf, 07.06.2005.

27. Dale, M. "Defining User Requirements for a Large Corporate Data Warehouse: An Experiential Case Study". http://awre2004.cis.unisa.edu.au/5%20pdf%20paper%20awre.pdf, 18.06.2005.

28. "The Zachman Framework For Enterprise Architecture". http://www.zifa.com/framework.pdf, 13.07.2005.

29. "The Impact of the OLAP/OLTP Cultural Conflict on Data Warehousing". http://www.georgetown.edu/users/allanr/Impact.pdf, 08.06.2005.

30. Luis, R. "Common Warehouse Metamodel". http://berlin.inesc-id.pt/cadeiras/pfsi/PFSI2003/SEMINARIO/pdfs/PFSI_Rui_Luis_M5148.pdf, 08.06.2005.

31. Winter, R. & Strauch, B. "Demand-driven Information Requirements Analysis in Data Warehousing". http://verdi.unisg.ch/org/iwi/iwi_pub.nsf/wwwPublRecentEng/1070FBEF50671021C1256F03004B2915/$file/jdw%202003.pdf, 08.06.2005.

32. Kerschberg, L. "Knowledge Management in Heterogenous Data Warehouse Environments". http://eceb.gmu.edu/pubs/KerschbergDaWak2001.pdf, 08.06.2005.

33. Warmer, J. "The Future of UML". http://www.klasse.nl/english/uml/uml2.pdf, 26.05.2005.

34. White, C. "Delivering Business Intelligence to Business Users". DCI Business Intelligence and Data Warehousing Conference, Boston, USA, September 2004.

35. "Database Normalization". http://en.wikipedia.org/wiki/Third_normal_form, 22.07.2005.

78

Lisad

Lisa 1. Allika analüüsi dokumendi struktuur (ettevõtte "X" dokumendipõhi).

Klient "x"

ANALÜÜTILISE ANDMEHOIDLA ALLIKA ANALÜÜS „ANDMEOLEM "Y"“ (OLTP SÜSTEEM "Z")

Kuupäev:

Teostajad

79

Allkirjastajad

Nimi Kontakt Firma Allkiri Kuupäev

Teostajad

Nimi Firma Ülesannete kirjeldus Kontakt

Dokumendi andmed: Versioon: 1.1 Lehti dokumendis Fail

Sisukord 1. Sissejuhatus ........................................................................................................ 79

1.1. Dokumendi eesmärk ....................................................................................... 80 1.2. Viited ............................................................................................................. 80 1.3. Lühendid ........................................................................................................ 80

2. Tabeli kirjeldus .................................................................................................. 80 3. Küsimuste kirjeldused ...................................................................................... 80

3.1 Küsimus 1 ...................................................................................................... 80 3.2 Küsimus 2 ...................................................................................................... 81 3.3 Küsimus 3 ...................................................................................................... 81 3.4 Küsimus 4 ...................................................................................................... 81 4. Esitatud päringud tabeli "X" veergude lõikes .................................................. 81

1. Sissejuhatus

80

1.1. Dokumendi eesmärk

1.2. Viited

1.3. Lühendid

2. Tabeli kirjeldus Alliktabel "x", OLTP süsteem "y"

Nimi Kohustuslik Andmetüüp Kirjeldus

3. Küsimuste kirjeldused

3.1 Küsimus 1

81

3.2 Küsimus 2

3.3 Küsimus 3

3.4 Küsimus 4

4. Esitatud päringud tabeli "x" veergude lõikes Lisa 2. Analüüsi kokkuvõtte struktuur (vormilt on tegu esitlusega, seetõttu pole seda otstarbekas siia täielikult kopeerida).

• Realiseeritavad ärivajadused (nõuded) • Seotud ärivajadused • Ärivajadus 1 analüüs

o Ärivajadus 1 sisu o Ärivajadus 1 allikad

• Ärivajadus 2 o ...

• Probleemid andmetega • Projekti seis

Lisa 3. Andmeaida rajamiseks valmisoleku küsimustiku struktuur (4, lk 47). Faktor Madal Keskmine Kõrge Andmeaida rajamise tugi äripoolelt

• Andmeaida ärisponsori positsioon • Juhtide huvitatus projektist • Juhtide lähenemise realistlikkus • ...

x

x

x

Äripoole motiveeritus • ...

IT/ärikasutajate suhted • .. x

Ärianalüüs praegusel hetkel

82

• ... Tehnoloogiline valmisolek

• ... Lisa 4. Inkremendi valiku teljestik (4, lk 52).

Lisa 5. Alliksüsteemide ning andmeolemite sidustamise tabel (20). Olem Allikas Omanik

(äri) Omanik (IT)

Platvorm Asukoht Kirjeldus

Kliendid CRM andmebaas

Pille Rebane

Juta Jänes

Oracle 9i Klientide tabel (klienditeenindus ja tellimuste andmebaas)

... Lisa 6. CRUD maatriksi kasutamine andmeolemite ja OLTP süsteemide seostamiseks (24). Andmeolem \ OLTP süsteem CRM andmebaas Kassasüsteem Klient x Toode x ... Lisa 7. Rollide, protsesside ja andmete ühendamine (17).

Madal Kõrge

Kõrge

Arendamise lihtsus

Nõudmistekogum äriprotsessile 1

Nõudmistekogum äriprotsessile 2 Nõudmistekogum

äriprotsessile 3 Mõj

u är

ile

83

Osakonnajuhataja

Analyytik Turustus

Tarnimine

Kliendid

Tooted

"Kriipsujukud" sümboliseerivad rolle, ristkülikud protsesse ja alt lõigatud ristkülikud andmeolemeid. Lisa 8. Data Warehouse Bus maatriks (4). Äriprotsess \ Andmeolem Klient Toode Kauplus Turundus x x x Tarnimine x Lisa 9. ETL protsessi voodiagramm (20).

Tooted

Tarnijatefail

Tarned

Tarnijad

Teenused

DWHtooted

Ühenda

Lae

Vead

Ühenda

Sorteeri Tarned

Notatsioon:

Andmeolem

Protsess

Andmefail