Suurte andmebaaside projekteerimine
This presentation is the property of its rightful owner.
Sponsored Links
1 / 46

SUURTE ANDMEBAASIDE PROJEKTEERIMINE PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on
  • Presentation posted in: General

SUURTE ANDMEBAASIDE PROJEKTEERIMINE. Priit Raspel. [email protected] LOENGU KAVA. Mõned tõdemused andmebaasidest ja infosüsteemidest Suured andmebaasid (ja infosüsteemid) Andmelaod - tõeliselt suured andmebaasid Formalism andmemudelite loomisel.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Suurte andmebaaside projekteerimine

SUURTE ANDMEBAASIDE PROJEKTEERIMINE

Priit Raspel

[email protected]


Loengu kava

LOENGU KAVA

  • Mõned tõdemused andmebaasidest ja infosüsteemidest

  • Suured andmebaasid (ja infosüsteemid)

  • Andmelaod - tõeliselt suured andmebaasid

  • Formalism andmemudelite loomisel


M ned t demused andmebaasidest ja infos steemidest

MÕNED TÕDEMUSED ANDMEBAASIDEST JA INFOSÜSTEEMIDEST


1 t demus

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.


2 t demus

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.


3 t demus

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.


4 t demus

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.


5 t demus

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.


6 t demus

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.


7 t demus

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, …)


8 t demus

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.


9 t demus

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.


10 t demus

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”.


Suured andmebaasid ja infos steemid

SUURED ANDMEBAASID ( JA INFOSÜSTEEMID )


Andmebaas kogum seostatud andmeid

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, …)

  • ...


Aga lisaks sellele

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, …)

  • ...


Mida m ista suurte andmebaaside all

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 ?


Mis eristab suurt ja v ikest andmebaasi

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.


Mis on erinev suure ja v ikese andmebaasi loomise protsesis

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.


Omadused mis pole suurele andmebaasile kohustuslikud

OMADUSED, MIS POLE SUURELE ANDMEBAASILE KOHUSTUSLIKUD

  • SUUR KASUTAJATE ARV

  • KASUTAJATE PAIKNEMISE LAI GEORAAFILINE PIIRKOND

  • ANDMEKOGUDE PAIKNEMISE LAIGEOGRAAFILINE 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” !


Kontseptsioonide ja vahendite valimine

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.


Eesm rkide p stitamine

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.


Anal s toetatavad infot d

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?


Anal s andmemahtude hindamine

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


Anal s kasutajate hulga hindamine

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?


Anal s kasutajate aktiivsuse hindamine

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?


Anal s ressursi koormatuse hindamine

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?


Anal si eesm rk j udlus

ANALÜÜSI EESMÄRK:JÕUDLUS


Valik infos steemi arhitektuur

VALIK:INFOSÜSTEEMI ARHITEKTUUR


Valik andmebaasi keskkond

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


Valik valmisprogrammid

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.


Valik arendusvahendid

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.


Valik turvameetmed

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


Andmelaod t eliselt suured andmebaasid

ANDMELAOD - TÕELISELT SUURED ANDMEBAASID


Infot tluse eesm rk

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


Eeldused andmete muutmisel informatsiooniks

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!


Andmeladu

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)


Andmelao toimimise keskkond

ANDMELAO TOIMIMISE KESKKOND


Andmelao t piline andmevoog

ANDMELAO TÜÜPILINE ANDMEVOOG

Andmed

Informatsioon


Andmev tt p hilised liigid

ANDMEVÕTT - PÕHILISED LIIGID

  • Staatiline andmevõtt

  • Tehingusüsteemidega juhitav andmevõtt

  • Baasihaldussüsteemi trigeritel põhinev andmevõtt


Staatiline andmev tt

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


Trigerip hine andmev tt

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


Metaandmete liigid

METAANDMETE LIIGID

  • tehingusüsteemide, üldhoidla, erihoidlate ja hõiveprotseduuride projekteerimise ja modelleerimise metaandmeid — kavandi metaandmed

  • andmehoidla — haldamise metaandmed

  • andmehoidla — kasutamise metaandmed


Metaandmed eluts klis

METAANDMED ELUTSÜKLIS


Eesti hispanga andmeladu

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


Tegelikult on see k ik palju kordi keerulisem ja rohkem m ramatust sisaldav

Tegelikult on see kõik palju kordi keerulisem...... ja rohkem määramatust sisaldav!

[email protected]


  • Login