1 / 46

SUURTE ANDMEBAASIDE PROJEKTEERIMINE

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

renee
Download Presentation

SUURTE ANDMEBAASIDE PROJEKTEERIMINE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    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!

More Related