SUURTE ANDMEBAASIDE PROJEKTEERIMINE

1. SUURTE ANDMEBAASIDE PROJEKTEERIMINE Priit Raspel priit.raspel@eyp.ee

2. LOENGU KAVA • Mõned tõdemused andmebaasidest ja infosüsteemidest • Suured andmebaasid (ja infosüsteemid) • Andmelaod - tõeliselt suured andmebaasid • Formalism andmemudelite loomisel

3. MÕNED TÕDEMUSED ANDMEBAASIDEST JA INFOSÜSTEEMIDEST

4. 1. TÕDEMUS • Korrektselt toimiva infosüsteemi tähtsaimaks aluseks on küll “õigesti” projekteeritud ANDMEBAAS, kuid see, mis peab olema “õigesti” projekteeritud, on oma mõõtmetelt tunduvalt laiem kui seda on andmebaas KLASSIKALISES (teoreetilises) mõttes.

5. 2. TÕDEMUS • Andmebaaside projekteerimisel võib rikkuda KÕIKI andmebaaside projekteerimise teooria poolt esitatud printsiipe - see rikkumine peab olema aga TEADLIK ja PÕHJENDATUD.

6. 3. TÕDEMUS • CASE-vahendid ei ole mingid “imerelvad”, mille rakendamine garanteerivad vajadustele vastavate ja korrektselt toimivate mudelite loomise - nad võimendavad lollust palju paremini kui tarkust. • Standardite järgimine tagab korrektselt vormistatud aga mitte igal juhul töötava mudeli • Vaatamata sellele on CASE-süsteemide kasutamine korrektse tulemuse saamiseks vältimatu • Loota tuleb ainult iseendale, mitte CASE-süsteemile.

7. 4. TÕDEMUS • Töötava mudeli loomiseks ei piisa olemasoleva situatsiooni fikseerimisest - selleks on vaja vaadata asju tunduvalt laiemalt, kui seda eeldab konkreetse ülesande lahendamine ja tunduvalt kaugemale tulevikku kui seda on • Hea mudel on see, kus on suudetud kristalliseerida “ajatus” st. mudeli dünaamiline muutumine koos objektiga, mida ta kirjeldab.

8. 5. TÕDEMUS • Olenemata andmebaasi või infosüsteemi väiksusest peab kogu tema modelleerimine olema läbi viidud sama põhjalikkusega kui mistahes suure infosüsteemi korral - esialgselt väikestel süsteemidel on kalduvus kasvada suurteks. • Hästi projekteeritud infosüsteemi saab erinevate mahtude muutumisel laiendada, halvasti projekteeritud infosüsteem tuleb aga välja vahetada.

9. 6. TÕDEMUS • Infosüsteemidel on kalduvus elada kauem, kui nende loojad seda oma kõige halvemaski unenäos näinud on. • Mida paremini on projekteeritud infosüsteem, seda kauem ta elab. • Kõige aluseks on hästi projekteeritud ja realiseeritud andmebaas.

10. 7. TÕDEMUS • Reaalselt eksisteeriv andmebaas omab oma terviklikku ja tegelikku tähendust ainult vaadelduna koos tema kasutuskeskkonna ja selle arenguga (eesmärgid, meetodid, vahendid, areng, kasutajad, …)

11. 8. TÕDEMUS • Infosüsteemide loomisel tuleb meeles pidada, et kahjuks eksisteerib selline segav faktor nagu seda on tegelik elu: • infosüsteemi ükski komponent ei tohi sättida piiranguid, mida tegelik elu ei sea, • ükski infosüsteemi poolt seatud piirang ei tohi olla nii jäik, et mingil hetkel peaks hakkama “reaalset maailma” “häälestama” infosüsteemi järgi.

12. 9. TÕDEMUS • Peaaegu kunagi ei õnnestu alustada tühjalt kohalt. See tähendab aga seda, et nii uue loomisel kui vana täiendamisel tuleb paratamatult jälgida ja arvestada sellega, mis on tehtud varem. • Mudeli vahetusel: “Hea mudel” realiseerib endas “vana” ilma eelmist mudelit kopeerimata. • Mudeli muutusel: “Head mudelit” on võimalik muuta ilma olemasolevaid, mudeliga seotudprotseduure rikkumata.

13. 10. TÕDEMUS • Korrektselt projekteeritud ja realiseeritud infosüsteemid (ka suured) “lubavad” oma loojatel elus veel mõndagi huvitavat teha. • “Ligadi-logadi” infosüsteemid muudavad enda loojad oma “orjadeks”.

14. SUURED ANDMEBAASID ( JA INFOSÜSTEEMID )

15. ANDMEBAAS - KOGUM SEOSTATUD ANDMEID? • Struktureeritud andmed (schemas, tables, views, ...) • Seosed (referential integrity) • Andmeotsingu kiirendid (indexes) • Piirangud (data types, formats, constraints) • Sündmuste lokaliseerijad (triggers) • Meetodid (procedures) • Käsitluskeel (SQL, DBMS specific RLA, …) • ...

16. AGA LISAKS SELLELE... • Monitooringu vahendid • Administreerimisvahendid • kasutajate haldamine(user rights administration) • kindluskoopiate tegemine/taastamine(backup/restore) • jõudluse häälestamine (performance tuning) • ... • Õiguste tagamise vahendid • Liidesed teiste süsteemidega (ODBC, JDBC, native links, XML, MQ support, external procedures,…) • Arendusvahendid (3GL, 4GL programming tools, CASE-systems, team managing, version control, …) • ...

17. MIDA MÕISTA SUURTE ANDMEBAASIDE ALL ? • “Suur” ANDMEMAHULT ? • “Suur” ERINEVATE ANDMEKOGUDE ARVU POOLEST ? • “Suur” KASUTAJATE ARVULT ? • “Suur” KASUTAJATE PAIKNEMISE LAIA GEORAAFILISE PIIRKONNA POOLEST ? • “Suur” ANDMEKOGUDE PAIKNEMISE LAIA GEOGRAAFILISE PIIRKONNA POOLEST ? • “Suur” ÄRILOOGIKA KEERUKUSE POOLEST ? • “Suur” PÖÖRDUMISTE ARVU (REAKTSIOONI KIIRUSE) POOLEST ? • “Suur” ERINEVATE MUUTUSTE SAGEDUSE POOLEST ? • “Suur” INFO KONFIDENTSIAALSUSE POOLEST ?

18. MIS ERISTABSUURTJAVÄIKESTANDMEBAASI ? • “Füüsilistelt mõõtmetelt” on (tavaliselt) suure andmebaasi enamik numbriliselt väljendatavaid parameetreid kas palju suuremad või palju väiksemad kui väikestel andmebaasidel. • Rakendamise seisukohalt vaadatuna on suurte andmebaaside “elukeskkond” struktuurilt palju keerulisem ja kallim kui väikestel andmebaasidel(erinev halduskulude suurus). • Tavaliselt esitatakse suurtele andmebaasidele suuremad töökindluse ja turvalisuse nõuded.

19. MIS ON ERINEVSUURE JA VÄIKESE ANDMEBAASI LOOMISE PROTSESIS • Oma funktsioneerimise alguses on enamik andmebaase “väikesed”. • Projekteerimise ja loomise protsessi kulgemise seisukohalt vaadatuna ei tohiks olla mingit vahet(kui töö tehakse korrektselt). • Andmebaaside korral, mis eeldatavasti oma “elu jooksul” muutuvad “suurteks”, tuleb analüüsi ja projekteerimise käigus pöörata tähelepanu paljudele faktoritele, mille uurimiseks “väikestena elavate” andmebaaside puhul pole mingit mõtete aega ja raha kulutada. • Riskide hulk on tunduvalt suurem.

20. OMADUSED, MIS POLE SUURELE ANDMEBAASILE KOHUSTUSLIKUD • SUUR KASUTAJATE ARV • KASUTAJATE PAIKNEMISE LAI GEORAAFILINE PIIRKOND • ANDMEKOGUDE PAIKNEMISE LAI GEOGRAAFILINE PIIRKOND • TEGEVUS-LOOGIKA KEERUKUS • ANDMEBAASI POOLE PÖÖRDUMISTE SUUR ARV • ERINEVATE MUUTUSTE SUUR SAGEDUS • INFO RANGEIM KONFIDENTSIAALSUS Aga just need võivad olla omadused, mis teevad andmebaasist “SUURE” !

21. KONTSEPTSIOONIDE JA VAHENDITE VALIMINE • Analüüs ja eesmärkide spetsifitseerimine (!) • Infosüsteemi loogiline arhitektuur (tsentraliseeritud, hajus; 2-kihiline, 3-kihiline, N-kihiline, 0-kihiline; …) • Infosüsteemi füüsiline arhitektuur (riistvara, süsteemitarkvara, teenuse pakkujad/vahendajad, ...) • Info-logistika mudel (andmete liikumine baaside ja rakenduste vahel) • Andmebaasisüsteemid (üks või mitu?) • Arenduskeskkonnad (arendustarkvara või outsourcing?) • Kasutatavad valmisprogrammid (ka outsourcing) • Andmekaitse metoodika ja vahendid • IT organisatsioon ja funktsioonide jaotus.

22. EESMÄRKIDE PÜSTITAMINE • Ilma eesmärki püstitamata (spetsifitseerimata) ei ole võimalik luua ei suurt ega väikest andmebaasi. Kuid mida “suurem” on andmebaas seda täpsemalt tuleb spetsifitseerida eesmärgid. • Lisaks eesmärgile tuleb projekteerida (spetsifitseerida) ka selle eesmärgini jõudmise tee (sammud). Kuid mida “suurem” on andmebaas seda detailsem tuleb see spetsifikatsioon koostada. • Esimene samm on tavaliselt pikem aga see ei tohi olla liiga pikk. Tuleb minimiseerida esimese sammu pikkust. • Lühemaid samme on lihtsam (loe: odavam) tagasi võtta. • Andmebaasi loomine saab olla ainult alam-eesmärk - mitte eesmärk omaette - andmebaasi saab hakata projekteerima alles pärast süsteemi üldvaate spetsifitseerimist.

23. ANALÜÜS:TOETATAVAD INFOTÖÖD • Milliseid infotöid teeme me praegu? • Milliseid infotöid teeme me aasta pärast? • Kahe aasta pärast? • Kolme aasta pärast? Viie aasta pärast? (hulk, keerukus võrreldes praeguste tegevustega) • Kui suur on eeldatavalt/soovitavalt infotöö tegijate arv? Millise aja jooksul? • Millise tasemeni läheme me infosüsteemi poolse toetusega? Millise aja jooksul? • Kas planeeritav infosüsteemi poolt toetatav infotööde kogum esitab nõudmisi infosüsteemi struktuurile?

24. ANALÜÜS:ANDMEMAHTUDE HINDAMINE • Millised andmebaasid meil on praegu olemas? • Milline on andmete maht praegu? • Millised andmekogumid me peame juurde looma? • Milliseid andmekogusid peame me täiendama? • Milline on andmete eeldatav maht viie aasta pärast? • Milline on andmete eeldatav maht kümne aasta pärast? • Milline on maksimaalne võimalik andmemaht? • Kas planeeritav andmemaht ja struktuur esitab nõudmisi infosüsteemi struktuurile

25. ANALÜÜS:KASUTAJATE HULGA HINDAMINE • Palju meil on infosüsteemi kasutajad praegu? • Kus nad paiknevad? Milline on nende profiil? • Kas me tahame kasutajate arvu suurendada, vähendada või hoida samades piirides? • Palju meil on kasutajaid eeldatavalt kahe aasta pärast? Milline on nende struktuur? • Palju meil on kasutajaid eeldatavalt viie aasta pärast? Milline on nende struktuur? • Milline on maksimaalne võimalik kasutajate arv? • Kas planeeritav kasutajate arv või struktuur esitab nõudmisi infosüsteemi struktuurile?

26. ANALÜÜS:KASUTAJATE AKTIIVSUSE HINDAMINE • Kui palju koormab meie ressurssi üks kasutaja? • Mitu pöördumist teeb ta keskmiselt süsteemi poole päevas? • Tunnis? Minutis? Sekundis? • Milline on kasutaja maksimaalne aktiivsus? • Kuidas muutub kasutaja aktiivsus eeldatavasti ühe aasta jooksul? • Kahe aasta jooksul? Viie aasta jooksul? • Kui suur on võimalik maksimaalne kasutajate aktiivsus? • Kas kasutajate planeeritud aktiivsus või selle suur muutumine esitab nõudmisi infosüsteemi struktuurile?

27. ANALÜÜS:RESSURSI KOORMATUSE HINDAMINE • Kui suur/väike on kõige suurem/väiksem tunni jooksul süsteemi poole tehtavate pöördumiste arv? • Tunnis? Minutis? Sekundis? • Kui suur on keskmine tunni jooksul süsteemi poole tehtavate pöördumiste arv? • Tunnis? Minutis? Sekundis? • Mitu andmebaasitransaktsiooni genereerib iga süsteemi poole pöördumine? • Kas süsteemi planeeritud koormatus või selle lühikese aja jooksul suurtes piirides muutumine esitab nõudmisi infosüsteemi struktuurile?

28. ANALÜÜSI EESMÄRK:JÕUDLUS

29. VALIK:INFOSÜSTEEMI ARHITEKTUUR

30. VALIK:ANDMEBAASI KESKKOND • Komplektina koos tuleb valida server(id) ja andmebaasimootor • Kriteeriumiks on – võime teenindada analüüsi etapil määratletud arv transaktsioone sekundis • Oluline on valiku hetkel teada andmete üldist struktuuri ja andmebaasi poole pöördumise metoodikat, kuna just see võib määrata ühe või teise komplekti valiku

31. VALIK:VALMISPROGRAMMID • Esmaselt määrab võimalike valitavate valmisprogrammide kogumi IS valitud arhitektuur • Valmistarkvara saab valida etapiliselt üldiselt üksikule. Iga järgmine tase piirab järgmise taseme valikuid. • Nii palju kui võimalik tuleb kasutada olemasolevaid valmisprogramme – nende töövõimet ja jõudlust on võimalik testida. Jõudlustestid on väga olulised • Jõudluse testil on mõtet ainult siis, kui seda tehakse reaalsele töökeskkonnale ligilähedases keskkonnas • Valmisprogrammid annavad tavaliselt kiire, kuid mitte parima (kõige sobivama) lahenduse. Kiire lahenduse huvides tuleb nad võtta kasutusele “nii nagu nad on”, kohandades äriprotsesse.

32. VALIK:ARENDUSVAHENDID • Iga arendusvahend on spetsiifilise otstarbega “valmisprogramm”, mis tuleb sobitada kõigi teiste “valmisprogrammidega” • Arendusvahendid peavad olema “sama kaliibriga” võrreldes püstitatud ülesandega ja teiste valitud tehnoloogiliste lahendustega.

33. VALIK:TURVAMEETMED • Ei ole olemas täiesti universaalseid lahendusi - iga rakendus esitab mingeid spetsiifilisi, temale ainuomaseid nõudmisi • “Standardlahendused” ei paku üldjuhul piisavat kaitset • Kaitsma peab nii andmeid kui tehnoloogiat • Turvasüsteemi nõrgim lüli on inimene, kelle “ustavuse tagamiseks” tuleb tema “järele valvata” • Meetmete võimsuse määrab kaitstava “vara” väärtus - turvasüsteemi ei ole mõtet üldjuhul ehitada kallimat kui on “vara”, mida see kaitsma peab

34. ANDMELAOD - TÕELISELT SUURED ANDMEBAASID

35. INFOTÖÖTLUSE EESMÄRK Infotöötluse eesmärgiks on andmete muutmine informatsiooniks ! Miks? Sellepärast, et äriprotsessi juhtimises tekkivatele küsimustele on võimalik vastata ainult siis kui omada informatsiooni ja teadmisi kuidas seda informatsiooni kasutada eksisteerivate probleemide lahendamisel

36. EELDUSED ANDMETE MUUTMISEL INFORMATSIOONIKS Andmeid on informatsiooniks võimalik muuta siis ja ainult siis: • Kui sul on andmed olemas ja • Sa tead millised andmed Sul on olemas ja • Sa oled suuteline vajalikud andmed kätte saama ja • Sa võid usaldada nende andmete õigsust!

37. ANDMELADU • Andmeladu (Data Warehouse) on see osa terviklikust infosüsteemi andmearhitektuurist, mis esitab andmetöötlusprotsessi jaoks andmeid kui üks ja ühtne allikas, mis on: • integreeritud kogum andmeid • subjekt-orienteeritud • ajalugu kajastav • pidev (katkematu)

38. ANDMELAO TOIMIMISE KESKKOND

39. ANDMELAO TÜÜPILINE ANDMEVOOG Andmed Informatsioon

40. ANDMEVÕTT - PÕHILISED LIIGID • Staatiline andmevõtt • Tehingusüsteemidega juhitav andmevõtt • Baasihaldussüsteemi trigeritel põhinev andmevõtt

41. STAATILINE ANDMEVÕTT Staatiline andmevõtt (momentvõtte-tehnoloogia, snapshot): • võtab allikast (tehingubaasist) andmete jooksva seisu • ei sõltu andmeallika muutumistest • ei sõltu allika andmete perioodilisusest • on lihtsaim

42. TRIGERIPÕHINE ANDMEVÕTT Baasihaldussüsteemi trigeritel põhinev andmevõtt (inkrement-tehnoloogia): • andmebaasi sisseehitatud või tehinguhalduri omadus • sidustöötlus • kohene, st. ajalise viiteta • võetakse vaid uued ja muutunud andmed

43. METAANDMETE LIIGID • tehingusüsteemide, üldhoidla, erihoidlate ja hõiveprotseduuride projekteerimise ja modelleerimise metaandmeid — kavandi metaandmed • andmehoidla — haldamise metaandmed • andmehoidla — kasutamise metaandmed

44. METAANDMED ELUTSÜKLIS

45. EESTI ÜHISPANGA ANDMELADU • Andmelao süsteem: SyBase IQ • Analüüsisüsteem: Business Objects • Andmelao maht: 280 GB (07.11.2002) • Sisalduv ajalugu: 3 aastat • Suurim tabel: 0,7 miljardit rida • Raporti moodustamise tavaline aeg: 2-5 sek • Raporti moodustamise keskmine aeg: 18 sek • Raporti moodustamise max. aeg: 2 min

46. Tegelikult on see kõik palju kordi keerulisem...... ja rohkem määramatust sisaldav! priit.raspel@eyp.ee