Download
1 / 46
460 likes | 724 Views
LOENGU KAVA. Mned tdemused andmebaasidest ja infossteemidestSuured andmebaasid (ja infossteemid)Andmelaod - teliselt suured andmebaasid. MNED TDEMUSED ANDMEBAASIDEST JA INFOSSTEEMIDEST. 1. TDEMUS. Korrektselt toimiva infossteemi thtsaimaks aluseks on kll igesti" projekteeritud ANDMEB
E N D
1. SUURTE ANDMEBAASIDE PROJEKTEERIMINE
2. LOENGU KAVA Mõned tõdemused andmebaasidest ja infosüsteemidest
Suured andmebaasid (ja infosüsteemid)
Andmelaod - tõeliselt suured andmebaasid
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 andmemudel.
5. 2. TÕDEMUS Andmebaaside projekteerimisel võib rikkuda KÕIKI andmebaaside projekteerimise teooria poolt esitatud printsiipe - iga 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 seotud protseduure 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 ERISTAB SUURT JA VÄIKEST ANDMEBAASI ? 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 ERINEV SUURE 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 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:
38. ANDMELAO TOIMIMISE KESKKOND
39. ANDMELAO TÜÜPILINE ANDMEVOOG
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: 380 GB (07.11.2002)
Sisalduv ajalugu: 3 aastat
Suurim tabel: 0,5 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!
