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
Télécharger la présentation

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 Mned tdemused andmebaasidest ja infossteemidest Suured andmebaasid (ja infossteemid) Andmelaod - teliselt suured andmebaasid

    3. MNED TDEMUSED ANDMEBAASIDEST JA INFOSSTEEMIDEST

    4. 1. TDEMUS Korrektselt toimiva infossteemi thtsaimaks aluseks on kll igesti projekteeritud ANDMEBAAS, kuid see, mis peab olema igesti projekteeritud, on oma mtmetelt tunduvalt laiem kui seda on andmemudel.

    5. 2. TDEMUS Andmebaaside projekteerimisel vib rikkuda KIKI andmebaaside projekteerimise teooria poolt esitatud printsiipe - iga rikkumine peab olema aga TEADLIK ja PHJENDATUD.

    6. 3. TDEMUS CASE-vahendid ei ole mingid imerelvad, mille rakendamine garanteerivad vajadustele vastavate ja korrektselt toimivate mudelite loomise - nad vimendavad lollust palju paremini kui tarkust. Standardite jrgimine tagab korrektselt vormistatud aga mitte igal juhul ttava mudeli Vaatamata sellele on CASE-ssteemide kasutamine korrektse tulemuse saamiseks vltimatu Loota tuleb ainult iseendale, mitte CASE-ssteemile.

    7. 4. TDEMUS Ttava 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 dnaamiline muutumine koos objektiga, mida ta kirjeldab.

    8. 5. TDEMUS Olenemata andmebaasi vi infossteemi viksusest peab kogu tema modelleerimine olema lbi viidud sama phjalikkusega kui mistahes suure infossteemi korral - esialgselt vikestel ssteemidel on kalduvus kasvada suurteks. Hsti projekteeritud infossteemi saab erinevate mahtude muutumisel laiendada, halvasti projekteeritud infossteem tuleb aga vlja vahetada.

    9. 6. TDEMUS Infossteemidel on kalduvus elada kauem, kui nende loojad seda oma kige halvemaski unenos ninud on. Mida paremini on projekteeritud infossteem, seda kauem ta elab. Kige aluseks on hsti projekteeritud ja realiseeritud andmebaas.

    10. 7. TDEMUS Reaalselt eksisteeriv andmebaas omab oma terviklikku ja tegelikku thendust ainult vaadelduna koos tema kasutuskeskkonna ja selle arenguga (eesmrgid, meetodid, vahendid, areng, kasutajad, )

    11. 8. TDEMUS Infossteemide loomisel tuleb meeles pidada, et kahjuks eksisteerib selline segav faktor nagu seda on tegelik elu: infossteemi kski komponent ei tohi sttida piiranguid, mida tegelik elu ei sea, kski infossteemi poolt seatud piirang ei tohi olla nii jik, et mingil hetkel peaks hakkama reaalset maailma hlestama infossteemi jrgi.

    12. 9. TDEMUS Peaaegu kunagi ei nnestu alustada thjalt kohalt. See thendab aga seda, et nii uue loomisel kui vana tiendamisel tuleb paratamatult jlgida ja arvestada sellega, mis on tehtud varem. Mudeli vahetusel: Hea mudel realiseerib endas vana ilma eelmist mudelit kopeerimata. Mudeli muutusel: Head mudelit on vimalik muuta ilma olemasolevaid, mudeliga seotud protseduure rikkumata.

    13. 10. TDEMUS Korrektselt projekteeritud ja realiseeritud infossteemid (ka suured) lubavad oma loojatel elus veel mndagi huvitavat teha. Ligadi-logadi infossteemid muudavad enda loojad oma orjadeks.

    14. SUURED ANDMEBAASID ( JA INFOSSTEEMID )

    15. ANDMEBAAS - KOGUM SEOSTATUD ANDMEID? Struktureeritud andmed (schemas, tables, views, ...) Seosed (referential integrity) Andmeotsingu kiirendid (indexes) Piirangud (data types, formats, constraints) Sndmuste lokaliseerijad (triggers) Meetodid (procedures) Ksitluskeel (SQL, DBMS specific RLA, ) ...

    16. AGA LISAKS SELLELE... Monitooringu vahendid Administreerimisvahendid kasutajate haldamine (user rights administration) kindluskoopiate tegemine/taastamine (backup/restore) judluse hlestamine (performance tuning) ... iguste tagamise vahendid Liidesed teiste ssteemidega (ODBC, JDBC, native links, XML, MQ support, external procedures,) Arendusvahendid (3GL, 4GL programming tools, CASE-systems, team managing, version control, ) ...

    17. MIDA MISTA 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 PRDUMISTE ARVU (REAKTSIOONI KIIRUSE) POOLEST ? Suur ERINEVATE MUUTUSTE SAGEDUSE POOLEST ? Suur INFO KONFIDENTSIAALSUSE POOLEST ?

    18. MIS ERISTAB SUURT JA VIKEST ANDMEBAASI ? Fsilistelt mtmetelt on (tavaliselt) suure andmebaasi enamik numbriliselt vljendatavaid parameetreid kas palju suuremad vi palju viksemad kui vikestel andmebaasidel. Rakendamise seisukohalt vaadatuna on suurte andmebaaside elukeskkond struktuurilt palju keerulisem ja kallim kui vikestel andmebaasidel (erinev halduskulude suurus). Tavaliselt esitatakse suurtele andmebaasidele suuremad tkindluse ja turvalisuse nuded.

    19. MIS ON ERINEV SUURE JA VIKESE ANDMEBAASI LOOMISE PROTSESIS Oma funktsioneerimise alguses on enamik andmebaase vikesed. 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 analsi ja projekteerimise kigus prata thelepanu paljudele faktoritele, mille uurimiseks vikestena elavate andmebaaside puhul pole mingit mtete 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 PRDUMISTE SUUR ARV ERINEVATE MUUTUSTE SUUR SAGEDUS INFO RANGEIM KONFIDENTSIAALSUS Aga just need vivad olla omadused, mis teevad andmebaasist SUURE !

    21. KONTSEPTSIOONIDE JA VAHENDITE VALIMINE Anals ja eesmrkide spetsifitseerimine (!) Infossteemi loogiline arhitektuur (tsentraliseeritud, hajus; 2-kihiline, 3-kihiline, N-kihiline, 0-kihiline; ) Infossteemi fsiline arhitektuur (riistvara, ssteemitarkvara, teenuse pakkujad/vahendajad, ...) Info-logistika mudel (andmete liikumine baaside ja rakenduste vahel) Andmebaasissteemid (ks vi mitu?) Arenduskeskkonnad (arendustarkvara vi outsourcing?) Kasutatavad valmisprogrammid (ka outsourcing) Andmekaitse metoodika ja vahendid IT organisatsioon ja funktsioonide jaotus.

    22. EESMRKIDE PSTITAMINE Ilma eesmrki pstitamata (spetsifitseerimata) ei ole vimalik luua ei suurt ega vikest andmebaasi. Kuid mida suurem on andmebaas seda tpsemalt tuleb spetsifitseerida eesmrgid. Lisaks eesmrgile tuleb projekteerida (spetsifitseerida) ka selle eesmrgini judmise 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. Lhemaid samme on lihtsam (loe: odavam) tagasi vtta. Andmebaasi loomine saab olla ainult alam-eesmrk - mitte eesmrk omaette - andmebaasi saab hakata projekteerima alles prast ssteemi ldvaate spetsifitseerimist.

    23. ANALS: TOETATAVAD INFOTD Milliseid infotid teeme me praegu? Milliseid infotid teeme me aasta prast? Kahe aasta prast? Kolme aasta prast? Viie aasta prast? (hulk, keerukus vrreldes praeguste tegevustega) Kui suur on eeldatavalt/soovitavalt infot tegijate arv? Millise aja jooksul? Millise tasemeni lheme me infossteemi poolse toetusega? Millise aja jooksul? Kas planeeritav infossteemi poolt toetatav infotde kogum esitab nudmisi infossteemi struktuurile?

    24. ANALS: ANDMEMAHTUDE HINDAMINE Millised andmebaasid meil on praegu olemas? Milline on andmete maht praegu? Millised andmekogumid me peame juurde looma? Milliseid andmekogusid peame me tiendama? Milline on andmete eeldatav maht viie aasta prast? Milline on andmete eeldatav maht kmne aasta prast? Milline on maksimaalne vimalik andmemaht? Kas planeeritav andmemaht ja struktuur esitab nudmisi infossteemi struktuurile

    25. ANALS: KASUTAJATE HULGA HINDAMINE Palju meil on infossteemi kasutajad praegu? Kus nad paiknevad? Milline on nende profiil? Kas me tahame kasutajate arvu suurendada, vhendada vi hoida samades piirides? Palju meil on kasutajaid eeldatavalt kahe aasta prast? Milline on nende struktuur? Palju meil on kasutajaid eeldatavalt viie aasta prast? Milline on nende struktuur? Milline on maksimaalne vimalik kasutajate arv? Kas planeeritav kasutajate arv vi struktuur esitab nudmisi infossteemi struktuurile?

    26. ANALS: KASUTAJATE AKTIIVSUSE HINDAMINE Kui palju koormab meie ressurssi ks kasutaja? Mitu prdumist teeb ta keskmiselt ssteemi poole pevas? 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 vimalik maksimaalne kasutajate aktiivsus? Kas kasutajate planeeritud aktiivsus vi selle suur muutumine esitab nudmisi infossteemi struktuurile?

    27. ANALS: RESSURSI KOORMATUSE HINDAMINE Kui suur/vike on kige suurem/viksem tunni jooksul ssteemi poole tehtavate prdumiste arv? Tunnis? Minutis? Sekundis? Kui suur on keskmine tunni jooksul ssteemi poole tehtavate prdumiste arv? Tunnis? Minutis? Sekundis? Mitu andmebaasitransaktsiooni genereerib iga ssteemi poole prdumine? Kas ssteemi planeeritud koormatus vi selle lhikese aja jooksul suurtes piirides muutumine esitab nudmisi infossteemi struktuurile?

    28. ANALSI EESMRK: JUDLUS

    29. VALIK: INFOSSTEEMI ARHITEKTUUR

    30. VALIK: ANDMEBAASI KESKKOND Komplektina koos tuleb valida server(id) ja andmebaasimootor Kriteeriumiks on vime teenindada analsi etapil mratletud arv transaktsioone sekundis Oluline on valiku hetkel teada andmete ldist struktuuri ja andmebaasi poole prdumise metoodikat, kuna just see vib mrata he vi teise komplekti valiku

    31. VALIK: VALMISPROGRAMMID Esmaselt mrab vimalike valitavate valmisprogrammide kogumi IS valitud arhitektuur Valmistarkvara saab valida etapiliselt ldiselt ksikule. Iga jrgmine tase piirab jrgmise taseme valikuid. Nii palju kui vimalik tuleb kasutada olemasolevaid valmisprogramme nende tvimet ja judlust on vimalik testida. Judlustestid on vga olulised Judluse testil on mtet ainult siis, kui seda tehakse reaalsele tkeskkonnale ligilhedases keskkonnas Valmisprogrammid annavad tavaliselt kiire, kuid mitte parima (kige sobivama) lahenduse. Kiire lahenduse huvides tuleb nad vtta kasutusele nii nagu nad on, kohandades riprotsesse.

    32. VALIK: ARENDUSVAHENDID Iga arendusvahend on spetsiifilise otstarbega valmisprogramm, mis tuleb sobitada kigi teiste valmisprogrammidega Arendusvahendid peavad olema sama kaliibriga vrreldes pstitatud lesandega ja teiste valitud tehnoloogiliste lahendustega.

    33. VALIK: TURVAMEETMED Ei ole olemas tiesti universaalseid lahendusi - iga rakendus esitab mingeid spetsiifilisi, temale ainuomaseid nudmisi Standardlahendused ei paku ldjuhul piisavat kaitset Kaitsma peab nii andmeid kui tehnoloogiat Turvassteemi nrgim lli on inimene, kelle ustavuse tagamiseks tuleb tema jrele valvata Meetmete vimsuse mrab kaitstava vara vrtus - turvassteemi ei ole mtet ldjuhul ehitada kallimat kui on vara, mida see kaitsma peab

    34. ANDMELAOD - TELISELT SUURED ANDMEBAASID

    35. INFOTTLUSE EESMRK Infottluse eesmrgiks on andmete muutmine informatsiooniks ! Miks? Selleprast, et riprotsessi juhtimises tekkivatele ksimustele on vimalik 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 ktte saama ja Sa vid usaldada nende andmete igsust!

    37. ANDMELADU Andmeladu (Data Warehouse) on see osa terviklikust infossteemi andmearhitektuurist, mis esitab andmettlusprotsessi jaoks andmeid kui ks ja htne allikas, mis on:

    38. ANDMELAO TOIMIMISE KESKKOND

    39. ANDMELAO TPILINE ANDMEVOOG

    40. ANDMEVTT - PHILISED LIIGID Staatiline andmevtt Tehingussteemidega juhitav andmevtt Baasihaldusssteemi trigeritel phinev andmevtt

    41. STAATILINE ANDMEVTT Staatiline andmevtt (momentvtte-tehnoloogia, snapshot): vtab allikast (tehingubaasist) andmete jooksva seisu ei sltu andmeallika muutumistest ei sltu allika andmete perioodilisusest on lihtsaim

    42. TRIGERIPHINE ANDMEVTT Baasihaldusssteemi trigeritel phinev andmevtt (inkrement-tehnoloogia): andmebaasi sisseehitatud vi tehinguhalduri omadus sidusttlus kohene, st. ajalise viiteta vetakse vaid uued ja muutunud andmed

    43. METAANDMETE LIIGID tehingussteemide, ldhoidla, erihoidlate ja hiveprotseduuride projekteerimise ja modelleerimise metaandmeid kavandi metaandmed andmehoidla haldamise metaandmed andmehoidla kasutamise metaandmed

    44. METAANDMED ELUTSKLIS

    45. EESTI HISPANGA ANDMELADU Andmelao ssteem: SyBase IQ Analsissteem: 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 kik palju kordi keerulisem... ... ja rohkem mramatust sisaldav!

More Related