Sissejuhatus Objekt-Orienteeritud (O-O) andmebaasidesse ja ülevaade andmemudelite ajaloost.

Transcription

1 Sissejuhatus Objekt-Orienteeritud (O-O) andmebaasidesse ja ülevaade andmemudelite ajaloost. Mõisted: O-O andmebaaside kohustuslikud omadused; OID, O-O paradigma mõisted O-O andmebaasides (kapseldamine, peitmine, signatuur, meetod, polümorfism). Andmebaaside loomise metoodika võimalused. Oskused: suudab jälgida O-O andmebaasikirjeldust, saades ette keele kirjelduse 1. Miks on veel üht mudeli vaja? Seni oleme vaadelnud kahte andmemudelit, mis on andmebaasisüsteemi aluseks või nende projekteerimise vahendiks - kõige lähemalt tutvusime relatsioonilise mudeliga, aga käsitlesime ka graafilise mudeli kahte vormi (E-R mudel ja UML klassimudel). Ajalooliselt pakuvad huvi ka hierarhiline ja võrkmudel. Mitmed mudelid on olnud konkreetsete andmebaasi juhtimissüsteemide loomise aluseks. Kuid igal neist on omad puudused. Seepärast ei ole uute mudelite loomine sugugi lõppenud. Eriti viimasel ajal, kui andmebaasid on kujunenud mitmete uute ülesannete lahendamise vahenditeks: CAD/CAM (ingl.k. Computer Aided Design / Computer Aided Manufacturing) süsteemid, graafilist infot sisaldavad andmebaasid, väga spetsiifilise kujuga andmete andmebaasid (näiteks DNA_järjestused), multimeedia andmebaasid, mitmesugused repositooriumid (näiteks õpiobjektide oma), mitmest andmebaasist koosnevad teaduslikud süsteemid jne. Need uued valdkonnad nõuavad modelleerimise vahendeid, mis erinevad traditsioonilistest majandusvaldkonnas kasutatavate andmebaaside vahenditest - viimase kasutusvaldkonna jaoks aga andmebaasid tekkisidki. Üheks mudeliks, mis on välja pakutud just neid uusi keerulisemaid rakendusi silmas pidades on objekt - orienteeritud (O-O) andmemudelid ja neil baseeruvad O-O andmebaasisüsteemid. Võtmeküsimuseks selles mudelis on vahendid, mida ta annab keeruliste objektide ehitamiseks ja operatsioonid, mida andmebaasi looja saab osaliselt ise disainida. Traditsiooniliselt on andmete struktureerimise vahendid andmebaasi juhtimissüsteemi sisse ehitatud, andmetega manipuleerimine aga mitte, andmetega manipuleerimise jaoks on loodud ABJS välised spetsiaalsed keeled nagu näiteks SQL. O-O andmebaaside üheks erinevuseks on ka võimalus kirjeldada osa andmete käitumisest meetoditega andmebaasi juhtimissüsteemi tasandil. 2. O-O andmemudelite kohustuslikud omadused 1995.a. avaldatud O-O andmebaaside manifest loetleb kohustuslikke omadusi, mis peavad igas O-O mudeli nimele pretendeerival süsteemil kohustuslikult olemas olema: o/manifesto.html 1. vahendid keerulise struktuuriga objektide ehitamiseks (korteežid, hulgad, massiivid, multihulgad (ingl.k. bags), jne.); kuitahes suure sügavusega, 2. objekti süsteemisisene identifikatsioon, 3. kapseldamine (ingl.k. encapsulation) objekti füüsiline realisatsioon on objekti siseasi, mis välja ei paista, 4. tüübid ja klassid, nende hierarhia, 5. pärimine, üledeklareerimine need toetavad taaskasutamist, 1

2 6. arvutuslik täielikkus - mistahes algoritm peab olema väljendatav. NB! SQL ei ole selles mõttes täielik, on vaid Codd i mõttes täielik(võrreldes relatsioonalgebra ja relatsioonarvutusega). Seda nõuet on võimalik saavutada, sidudes andmebaasisüsteemi universaalsete programmeerimiskeeltega nagu Java või Python. 7. laiendatavus andmetüüpe peab olema võimalik juurde tekitada nii, et pole vahet vanade ja uute tüüpide kasutamisel. Konstruktorite hulk (korteežid, hulgad, massiivid jne.) ei pea olema laiendatav. 8. alalisus andmed peavad elama oma elu, sõltumata programmidest (AB loomulik omadus, aga uudis O-O programmeerimiskeeltele), 9. mälu haldamise vahendid pole nähtavad kasutajale, on sisemine vahend. 10. multikasutus, andmete taastamine 11. mistahes päringule peab olema võimalik vastata (võib võtta palju aega). 2. Kust hankida lisateavet O-O andmebaaside kohta? Sõltub, millist lisateavet. Esimene küsimus: kus on konkreetsed O-O andmebaasijuhtimissüsteemid? O-O mudelil baseeruvad mitmed eksperimentaalsed andmebaasisüsteemid, aga on olemas ka kommerts-realisatsioone. Eksperimentaalsed ja/või vabavaralised: Orion (MCC, Texas), OpenOODB (TI), IRIS (HP), ODE (Bell), ENCORE (Brown Univ.), Cerebrum, Databeans, Eloquera, GOODS (Generic Object Oriented Database System), Magma Object Database, MyOODB, Db4o jpt. Kommertssüsteemid: ONTOS DB, Caché, GemStone/Opal, Objectivity, Versant, ObjectStore, O2, IBM San Francisco, JADE, Matisse jpt.. Suur O-O andmebaaside analüüs on aadressil: Oriented%20Database%20Mgmt%20Systems%20Revisited%20-%20SOAR.pdf (Ei avane otse viitest, aga kui kopeerida sama aadress brauseri aadressväljale, siis avaneb) Konkreetsete süsteemide saidid: Caché - reklaamib ennast, kui maailma kiireim O-O andmebaasisüsteem, mis töötab kiiremini kui relatsiooniline andmebaas. GemStone Mis on O-O andmebaasid? O-O mudel kasutab palju O-O programmeerimise kontseptsioone (O-O andmebaasid on O-O programmeerimise ja andmebaaside kontseptsioonide abielu ). O-O programmeerimisel on üsna pikk ajalugu. Esimesed kontseptsioonid, mida tänapäeval tunnustatakse kindlalt O-O paradigmasse kuuluvaks ilmusid Simula keeles 60-nendate lõpus (klassid, abstraktsed andmetüübid, mille realisatsioon on varjatud). Täielikult O-O paradigmale üles ehitatud keel, SmallTalk, ilmus 70-ndatel. Sealt edasi on palju arendatud nn. hübriidseid O-O keeli, kus O-O vahendid majutatakse juba olemasolevasse (mitte O-O ) keelde. Parim näide: C++. Nagu andmebaasid üldse, nii ka O-O andmebaasid on loodud selleks, et anda objektidele, mis programmeerimisekeeltes elavad vaid programmi töötamise ajal, elu ka väljaspool programmi; võimaldavad neid jagada mitme programmi poolt (kas 2

3 samal ajal, või järjekorras). O-O andmebaasidele on loodud liides ühe või enama O-O programmeerimiskeelega, et need saaksid kasutada permanentselt või ajutiselt andmebaasis säilitatud objekte. Üks O-O andmebaaside ülesanne on luua side reaalelus eksisteerivate ja ABs olevate objektide vahel. Kui andmed ühe ja sama objekti kohta paiknevad ABs erinevates relatsioonides, mis kasutavad erinevaid võtmeid, pole meil vahendeid aru saamaks, et tegu sama reaalse objekti andmetega. O-O mudelis aga seotakse objektiga sisemine objekti identifikaator (süsteemi poolt genereeritud) ja see seob teda reaalse objektiga. Teine O-O mudeli omapära on see, et O-O mudeli objekt võib olla suvalise keerukusega (pole piiratud 1NF normaalkujus relatsiooniga, kus vähegi keerulisema objekti andmed on laiali paljudes relatsioonides). Lisaks võib objekt sisaldada nn. seisundi muutujaid, mis välisele kasutajale pole nähtavad. Need muutujad võivad olla kuitahes keerulise struktuuriga. Üks põhilisi mõisteid O-O ABs on klasside hierarhia. See annab võimaluse kasutada kord loodud andmetüüpe (koos nende jaoks defineeritud operatsioonidega) järjest uute ja uute andmetüüpide loomisel. Uue andmebaasi loomist pole vaja alustada päris nullist. Vastav ingliskeelne termin: reusability, eesti keeles taaskasutatavus. Kuna eksisteerib kapseldamise (ingl.k. encapsulation) mehhanism, siis O-O andmemudeli algaastail tekkis raskusi andmetevaheliste sidemete realiseerimisega. Ei olnud vahendeid seoste esitamiseks nii, et ka kasutajad neid näeksid - kõik tuli peita operatsioonidesse (meetoditesse). Nüüd kasutavad paljud süsteemid viiteid (ingl.k. references), paigutades viidatava objekti unikaalse identifikaatori otse andmetena viitavasse objekti sisse. Paljud süsteemid lubavad objektist hoida mitut eksemplari, näiteks vanu koopiaid uuendatud objektidest (näiteks elektroonsete instrumentide disaini ajas muutuv täiendamine, kus muudetakse komponente jne.). O-O andmebaasid peaks paremini kui teised võimaldama ka andmebaasi skeemi evolutsiooni. O-O omaduste hulka kuulub ka operatsioonide polümorfism, mis väljendub selles, et samanimelist operatsiooni saab rakendada eri tüüpi objektidele, kus ta on eri moodi defineeritud. Näiteks mingite kujundite pindala leidmise operatsioon rakendab ruudu ja ringi puhul eri algoritmi. 4. O-O andmebaaside põhikontseptsioonid Vaatame neid punktis 3 käsitletud O-O andmebaaside kontseptsioone lähemalt. 4.1 Objekti identifikatsioon O-O andmebaas annab unikaalse identifikaatori igale objektile, mis andmebaasi pannakse. Selleks tekitab süsteem lisatunnuse objekti andmetele, mida nimetatakse OID - Object IDentifier. Seda tunnust kasutaja ei näe, kuid süsteem ise kasutab seda objekti identifitseerimiseks ja objektidevaheliste seoste käsitlemiseks. OID ei ole muudetav. Kogu objekti eluaja vältel on OID ühe ja sama väärtusega - see lihtsustab tema sidumist reaalsuses eksisteeriva objektiga. On soovitatav, et üht OID väärtust kasutatakse kogu AB elu ajal üks kord, s.t. reaalse objekti kadumise järel ei anta sama 3

4 OID d teisele objektile. OID ei tohi sõltuda mingi(te) atribuu/di(tide) väärtusest, sest viimased võivad muutuda. Samuti ei tohi OID olla otseselt seotud objekti füüsilise paiknemisega - AB reorganiseerimisel viimane muutub (kuid mõned süsteemid viimast võtet siiski kasutavad). Mõned süsteemid nõuavad, et üleüldse kõik, mis on ABs, oleks esitatud objektina, ka arvud, stringid jne. Viimasel juhul on igal neist ka oma OID! Näit. Vanus 50 ja kaal 50 saab salvestada erinevate OID dega - teatud juhtudel on see kasulik. Selline üdini objektlik lähenemine on küll üsna huvitav teoreetilisest vaatekohast, kuid praktikas tülikas - kogu see OID de loomise mehhanism muutub väga tülikaks. Seega enamus O-O AB-sid eristab objekte ja väärtusi ja salvestab viimaseid ilma OID deta. 4.2 Objekti struktuur O-O vahendid lubavad keeruliste objektide eksemplare ehitada juba olemasolevatest objektidest, kasutades tüübi konstruktoreid. Süsteemis on tavaliselt olemas elementaarväärtused: täisarvud, sümbolid, stringid, loogilised väärtused jne. On konstruktorid, mis olemaolevatest objektidest ja väärtustest lubavad uusi konstrueerida. Tüüpilisemad: aatom, korteež (tuple), hulk (set), ka list, massiiv (array) jne. Loomulikult saab vastavaid konstruktsioone kasutada üksteise sees kuitahes keerulise struktuuriga objektide loomiseks. Ainult atomaarsed väärtused on kohe objekti enda eksemplari sees, kõik teised esitatakse läbi vastavate objektide OID de. Et hoida ära OID de eskalatsiooni, lubatakse tavaliselt samade konstruktsioonidega keeruliste väärtuste loomist. Viimased on väärtused ja seega ei oma OID d. 4.3 Tüübikonstruktorid O-O andmekirjelduskeeles (OODDL- Object-Oriented Data Description Language) saab eeltoodud konstruktoreid kasutada mingi rakenduse jaoks vajalike objektide loomiseks, aga neid saab kasutada ka andmebaasis olevate andmete kirjelduse s.o. andmebaasi skeemi loomiseks. 4.4 Operatsioonid (meetodid) Operatsioonid on O-O paradigma järgi kapseldatud objektidesse. Mitte-O-O andmebaasides on põhilised operatsioonid rakendatavad kõikidele objektidele ja andmete struktuur oli nähtav kõigile kasutajatele, kellel seda vaja oli teada (vaated!, programmid). Näiteks relatsioonilises mudelis saab operatsioone select, insert, delete jne. rakendada mistahes relatsioonile ja nende semantika oli kõigi puhul sama. O-O paradigmast tulenevat info peitmist (ingl.k. hiding) ja kapseldamist (encapsulation) saab rakendada ka andmebaaside puhul. Peamine idee: defineerida objekti tüübi käitumine vastavalt operatsioonidele, mida saab väljastpoolt rakendada antud tüüpi objektidele. Andmete struktuur, eriti see, kuidas ta realiseeritud on, jääb peidetuks objekti sisse, andmeid kasutada saab ainult nende antud objektitüübi jaoks defineeritud operatsioonide kaudu. Selleks on kasutaja jaoks defineeritud objekti liides (interface), mis defineerib iga operatsiooni parameetrid. Selliselt defineeritud liidest nimetatakse operatsiooni signatuuriks. Operatsiooni realisatsiooni (mis on kasutaja eest peidetud) nimetatakse meetodiks. Meetod käivitatakse, saates objektile teate (ingl.k. message). Meetodi käivitamisel võib see omakorda saata teateid teistele objektidele. Erinevalt tavalisest O-O programmeerimisest, on nõue täielikust kapseldamisest liiga range. Siin jagatakse objekti struktuur nähtavaks ja peidetud osaks (nähtavateks ja peidetud atribuutideks). Nähtavatele osadele saab juurde kõrgema taseme 4

5 operatsioonidega või otse kõrgtaseme päringukeelt kasutades. Peidetud osa on kättesaadav parajasti objekti oma operatsioonidega. Enamus O-O AB süsteeme kasutab kõrgtaseme päringukeeli ja mitmed on laiendanud SQL i selleks otstarbeks. Enamusel juhtudest on andmete modifitseerimise operatsioonid kapseldatud, sellega saab anda neile operatsioonidele objektitüübist sõltuva semantika. Andmebaasis rakendatavad kitsendused andmetele (ingl.k. integrity constraints) on O-O AB-s realiseeritud just modifitseerimisprogrammide kapseldamise teel. Terminit klass kasutatakse OOABs objekti tüübi definitsiooni kohta, kus objekti tüüp on defineeritud koos oma operatsioonidega. Tüüpiliseks klassiga seotud operatsiooniks on objekti loomise operatsioon ja objekti hävitamise operatsioon. Eraldi operatsioonid on andmete modifitseerimiseks. Konkreetsete operatsioonide realisatsioonid kirjutatakse tavaliselt mingis O-O programmeerimiskeeles ja neid hoitakse eraldi objektide kirjeldustest ja objektidest endist. Mitte kõik objektid pole loodud selleks, et neid alaliselt andmebaasis hoida - ajutised objektid luuakse programmi töö käigus ja nad kaovad, kui programm lõpetab oma töö. Alalised AB objektid säilitatakse andmebaasis ja nad ei kao programmi töö lõppemisega. Selleks antakse objektile alaline nimi (mille kaudu teised programmid ta kätte saavad) või tehakse objekt kättesaadavaks (ingl.k. reachable) mõne teise objekti kaudu. Def. Objekt B on kättesaadav objektist A, kui leidub tee objektide graafis objektist A objektini B. Kui mingi objekt tehakse alaliseks, siis kõik temaga seotud (tema kaudu kättesaadavad) objektid muutuvad ka alalisteks. Klassikalises andmebaasis on kõik objektid (relatsiooni korteežid relatsioonis) alalised. O-O mudelis klassi definitsioon annab ainult objekti tüübi kirjelduse (ja operatsioonid). Kasutaja peab eraldi defineerima veel alaliste seda tüüpi objektide hulga. Näiteks: tüüp Tudeng ja alaline hulk set (Tudeng). Viimase väärtuseks on viidad alalistele objektidele tüüpi Tudeng. Sama objektitüübi definitsiooni abil saab vajadusel luua mitu alalist objektihulka (näiteks erinevate teaduskondade tudengid erinevate hulkadena). 4.5 Klasside hierarhia Nagu O-O süsteemides ikka, saab ka O-O AB-des tekitada klasside hierarhiaid ja pärida omadusi. Kui on vaja luua uus objektitüüp, mis sarnane mõne juba eksisteerivaga, pole seda vaja looma hakata tühjast kohast. Saab luua uue tüübi kui olemasoleva klassi alamklassi. Reeglina pärib alamklass kõik oma ülemklassi tunnused ja talle saab juurde defineerida uusi, ainult talle spetsiifilisi atribuute ja operatsioone. Osa O-O andmebaasisüsteeme lubab olemasolevaid asju ka ümber nimetada ja ümber defineerida. Näiteks ülemklassi Kujund baasil, kus on defineeritud atribuut Pindala, saab alamklassidena defineerida klassid Ring, Ruut jne., andes igale erineva meetodi atribuudi Pindala (mis on päritud ülemklassist) arvutamiseks. NB! klasside defineerimine ei tekita iseenesest mingeid AB objekte! Selleks on vaja nad vastavate meetoditega luua ja kuulutada alalisteks (siduda alalise objektiga). Kui luuakse ja paigutatakse alaliselt andmebaasi näiteks konkreetne ruut, siis ta kuulub nii klassi Ruut kui Kujund. Seega: iga klassi liige kuulub ka selle klassi ülemklassi liikmete hulka. Osades O-O andmebaasides on loodud nn. süsteemne klass (tavaliselt nimega Root või Object), kuhu kuuluvad kõik süsteemis säilitatavad objektid ja mis 5

6 seega on kõigi teiste klasside ülemklass. Klassifitseerimine läheb siis sealt edasi alamklasside kaupa. Leidub ka nn. tüübituid O-O süteeme (näiteks SmallTalk), kus objekte säilitatakse vaatamata nende tüübile. 5. Uued objektitüübid O-O andmebaasides 5.1. Struktureerimata andmed Üks põhjus O-O andmebaaside sünniks oli eelnevate andmemudelite võimetus käsitleda suuri struktureerimata andmekogumeid nagu mahukad täistekstid, pildid jne. On küll loodud spetsialiseeritud andmebaasisüsteeme ühe sellise tüübiga töötamiseks, näiteks täisteksti andmebaasid, aga vajati kombineeritud andmebaasi, kus oleksid koos nii struktureeritud andmed (nagu tüüpilistes majandusülesannetes) ja struktureerimata mahukad andmed. Tavaliselt, kui teistes mudelites isegi olid vahendid selliste suurte struktureerimata objektide säilitamiseks, ei võimaldatud andmebaasi süsteemi poolt isegi mitte nende selekteerimise operatsiooni, kuna selekteerimisvahendid süsteemides olid sisseehitatud (SQL!) ja mitte kohaldatud seda tüüpi andmetele. Tänu oma O-O andmemudelile suudavad O-O andmebaasid haarata iga objektitüübi spetsiifilisi operatsioone (näiteks piltide võrdlemise operatsioone) ja selle abil ka seda tüüpi andmeid koos teistega töödelda. Näiteks saab pildi tüüpi andmetele defineerida kujundite äratundmise operatsiooni ja selle abil päringukeeles andmeid O-O andmebaasist hankida. Kuna O-O andmebaas võimaldab kasutajal omal uusi operatsioone defineerida, nimetatakse O-O andmemudelit laiendatavate tüüpidega (extensible type) andmemudeliks. 5.2 Struktureeritud keerulised andmed Kasutatakse kaht tüüpi pärimist. Omanikusemantika (ingl.k. ownership semantics) rakendub, kui objekt sisaldab teisi objekte ja need on kui tema objekti osa, peidetud selle objekti sisse. Teine tüüp - viitesemantika (ingl.k. reference semantics) rakendub, kui objekti komponendid on iseseisvad objektid, millele antud objektist on viit (ingl.k. reference). Näiteks Osakonna kirjes on olemas Osakonna Juhataja, mis omakorda on alaline AB objekt tüüpi Isik. Esimest tüüpi andmeid saab kätte ainult läbi omaniku, teist tüüpi andmeid saab ka viitajast sõltumatult käsitleda. Selleks, et antud objektist, mis viitab teisele objektile, seda objekti kätte saada, tuleb kasutada selle teise objekti jaoks defineeritud meetodeid. Kustutamisel: kui omanik kustutatakse, eemaldatakse ka tema sees olevad komponentobjektid. Viidatavaid objekte ei kustutata. Viidatavad objektid võivad olla viidatud ka teiste objektide poolt, omaniku objektid kuuluvad täielikult omanikule. 5.3 Polümorfism Operatsioonide polümorfism on samuti üks O-O paradigma klassikalisi omadusi. See on omadus, kus üks operatsioon omab kaht või enamat realisatsiooni, sõltuvalt objekti tüübist, millele teda rakendatakse. Me oleme harjunud, et programmeerimiskeeltes operatsioon + teab ise, kas teha täisarvude liitmise operatsioon või reaalarvude oma (vms.), sõltuvalt argumentide tüüpidest, vajadusel ka teisendusi teostades. Kujundi pindala arvutamisel rakendatakse alamtüübiga määratud programmi. Isegi kui kujundi puhul on võimalik anda mingi üldine algoritm näiteks polügooni (mida nii ruut kui kolmnurk jt. ka on) algoritm, siis alamklassi vastav meetod määrab üle ülemklassi vastava meetodi. Siit tuleb ka nn. sidumisaja probleem. Enamustes tüübiga keeltes saab Pindala operatsiooni poole pöördumise siduda konkreetse programmiga 6

7 transleerimise ajal, tüübita keeltes, nagu SmallTalk tuleb seda teha täitmise ajal (hiline/varajane sidumine). 5.4 Mitmene ja valikuline pärimine Mitmene pärimine toimub siis, kui alamklass omab kahte või enamat ülemklassi. Enamus O-O andmebaase lubavad seda. Siis alamklass pärib oma atribuudid ja meetodid kahest (erinevast) ülemklassist. Mida teha siis, kui seal on samanimelised, aga erinevad operatsioonid? Üks võimalikke lahendeid on see, kui süsteem saab sellisest olukorrast aru ja sel hetkel, kui vastav klassi kirjeldus tekitatakse, laseb kasutajal (vastava mitmese pärivusega klassi loojal) ise otsustada, kumba neist kahest erinevast operatsioonist rakendada. Teine võimalus on lasta süsteemil ise vaikimisprintsiibiga asi otsustada. Kolmas võimalus - keelata sellised alamklassid ära. Osa süsteeme kasutab seda kolmandat võimalust s.t. ei luba mitmest pärimist üldse. Leidub ka teisi lahendusi. Üks neist on lubada alamtüübil valikuliselt pärida (ingl.k. selective inheritance) oma ülemuselt. Tavaliselt kasutatakse siis EXEPT-lauset, näitamaks, milliseid atribuute ja operatsioone ei ole vaja pärida. See viimane meetod on enam levinud tehisintellekti kui AB süsteemides. 5.5 Versioonid Versioonid on objektide omadus omada enam kui üht koopiat oma eksemplarist. Vajalik näiteks inseneridele-konstruktoritele, aga ka näiteks programmeerijatele siis, kui enam kui üks inimene töötab antud toote (programmi) kallal. Kummalegi luuakse oma eksemplar, kus nad muutusi teevad, mingil hetkel on vaja need aga ühte ja samasse objektieksemplari kokku panna, seega luua veel kolmas koopia. Selliseid muutjaid võib olla muidugi enam kui kaks. Kui objekte hoitakse AB-s siis AB süsteem tavaliselt annab vahendid erinevate versioonide hoidmiseks AB-s, kokkupanemine jäetakse aga mitte AB vahenditele, vaid konkreetsele rakendusprogrammile. Viimane teab andmete semantikat. Osades süsteemides on olemas vahendid objektieksemplari kahe versioon võrdlemiseks, et aidata leida ühitamatuid kohti muutustes, teised hoiavad spetsiaalseid versioonigraafe, mis näitavad versioonide omavahelisi seoseid. Kui sellised objektieksemplaride versioonide esitamise vahendid on süsteemis olemas, on kohe vaja ka muid uusi vahendeid. Versioonidega objektid on tavaliselt osad suuremast, neid hõlmavast objektist. Viimase jaoks hoitakse siis nn. konfiguratsiooni - ühe versiooni (parajasti käibelolevat) eksemplari igast alamobjektist. 6. Näiteid O-O andmebaasisüsteemidest 6.1 Süsteem O2 Andmete defineerimiseks on O2 süsteemis atomaarsed andmetüübid (Boolean, Char, integer, real, string, bits jne.) ja konstruktorid (tuple, list, set, unique set). Set lubab dublikaate. Klassi definitsioon koosneb kahest osast: objekti tüübi kirjeldusest ja meetoditest. Mõisted väärtus (value) ja objekt on erinevad. Väärtus esindab iseennast ja ei kuulu klassi. Objekt kuulub klassi ja omab tüüpi ja käitumist, mis on määratud klassi meetoditega. Igal objektil on unikaalne identifikaator (OID) ja seisund (mis ei sisalda OID d!). O2 kasutab keelt O2C nii andmete defineerimiseks kui objektide loomiseks. Objektid saavad olla nii alalised kui ajutised. Ajutised objektid muutuvad alaliseks ainult siis, kui nad saavad osaks mingist alalisest objektist. Pärimisel saab kasutada rename lauset, defineerimaks ümber atribuute ja 7

8 meetodeid. Meetodite ümberdefineerimise puhul nad kõigepealt nimetatakse ümber rename lausega ja siis defineeritakse uus meetod. Rakendusprogramme saab kirjutada nii O2 omades keeltes: päringukeeleks loodud O2SQL ja programmeerimiskeeles O2C. Saab aga kasutada ka traditsioonilisi O-O keeli nagu C++. Süsteemis on olemas kasutajaliidese generaator O2Look, programmeerimist hõlbustav O2Tools. 6.2 Ullmanni ODL (Object Definition Language) ODL on J.Ullmanni poolt loodud keel, mis on CORBA osaks oleva IDL (Interactive Data Language), kui O-O programmeerimiskeelte standardiks kujunenud keele, laiendiks. Ta on otseselt teisendatav andmete kirjelduseks keeltes C++ ja SmallTalk. Viimased on tavaliselt O-OAB andmete manipuleerimiskeelteks. Seni me vaatasime andmebaaside loomist järgmise skeemi järgi: Vajadus E-R/UML mudel relatsiooniline ABJS Nüüd on mitu võimalust sellesse skeemi lisada O-O lähenemisstiili: Vajadus ODL E-R O-O AB relatsiooniline AB Seega saame O-O paradigmat kasutada kas ainult modelleerimise etapil, minnes üle relatsioonilisele süsteemile rakenduses, või nii modelleerimise kui realisatsioonietapil, ehitades O-O süsteemi. Viimasel juhul O-O mudel teisendatakse automaatselt O-O andmebaasikirjelduseks. Näide. (kohandatud allikast [2, lk.34]). Ülesande püstitus: olgu meil vaja koostada andmebaas filmidest, neis esinenud filmistaaridest ja filme valmistanud stuudiotest, kus iga filmi kohta on muude andmete seas andmed ka selles filmis osalevate staaride kohta ja vastupidi iga staari kohta saab leida, millistes filmides ta on esinenud. elementaarsed tüübid: integer float character string boolean enumeration Viimane tüüp seab arvudele 0, 1, vastavusse etteantud nimekirja literaale Näit: enumeration {Humaniora, Socialia, Medicina, Realia} seab need literaalid vastavusse arvudega 0, 1, 2, 3. Vahendid struktuursete tüüpide ehitamiseks: 1. Set kui T on andmetüüp, siis uue tüübi set <T> väärtuseks on T väärtuste mistahes lõplik alamhulk nendest andmetest tüüpi T; 2. Bag sama, mis set, aga korduvate elementidega; 8

9 3. List vt. String kui list < char >, näide: (1,2,1) ja (2,1,1) kui kaks eksemplari tüübist bag on samad, listina aga mitte. 4. Array <T, n> - massiiv n elemendist, kõik tüüpi T, näit. Array <char,10>; saab pöörduda indeksiga; 5. Struct nimi {T1 F1, T2 F2,, Tn Fn} kirjeldab struktuuri, mille esimene väli on nimega F1 tüüpi T1, teine väli nimega F2 on tüüpi T2 jne. Näiteks Struct Kursus {string nimi, string kood, int punkte, enumeration {sügis, kevad } loetakse} Objektid ehitatakse võtmesõnaga interface. Näiteks: interface Movie {attribute string title, attribute integer year}; Seoste loomiseks: Relationship lause. Seoseid luuakse vaadatuna ühe objektitüübi seisukohast. Teisest otsast vaadatuna, tuleb kasutada lisalauset inverse. Vaatame näidet. 1) interface Movie { 2) attribute string title; 3) attribute integer year; 4) attribute integer length; 5) attribute enum Film {color, blackandwhite} filmtype; 6) relationship Set <Star> stars inverse Star::starredIn; 7) relationship Studio ownedby inverse Studio::owns; }; 8) interface Star { 9) attribute string name; 10) attribute Struct Addr {string street, string city} address; 11) relationship Set <Movie> starredin inverse Movie::stars; }; 12) interface Studio { 13) attribute string name; 14) attribute string address ; 15) relationship Set <Movie> owns inverse Movie :: ownedby; }; NB! Star ja Movie vaheline seos on mitu-mitmele (mõlemalt poolt Set konstruktoriga). Seos Movie-Studio on mitu-ühele (ühelt poolt Set konstruktoriga) Kui kummasgi otsast pole kasutatud Set konstruktorit, siis on tegu 1-1 seosega. Alamklassid keeles ODL Olgu meil näiteks klass Movie defineeritud nii, nagu eelmises näites. Kui me tahame sellele klassile moodustada alamklassi joonisfilm (ingl.k. cartoon), kus muude 9

10 tunnuste seas on sellele alamklassile omane tunnus hääl, mis annab seose näitlejatega, kelle hääl esineb antud joonisfilmis. Interface Cartoon: Movie { Relationship Set <Star> voices; } Nüüd on objektitüübil Cartoon need neli atribuuti, mis ta päris objektilt Movie, 2 seost pärituna objektilt Movie ja lisaks oma seos voices. Võtmed Võtmed deklareeritakse lauses interface, kasutades võtmesõna key või keys, millele sulgudes järgneb tunnuste loetelu. Näide: interface Movie (key (title, year)) { Üheatribuudilise võtme puhul võib sisemised sulud ära jätta: interface Tudeng (key matrikli_number) { Toetatakse ka mitut võtit ühe objekti puhul, sel juhul eraldatakse erinevad võtmed komaga. interface Tudeng (key matrikli_number, (perekonnanimi, eesnimi, sünnikuupäev)) Võtmed võivad ka puududa. Süsteem identifitseerib objekti OID järgi, seda isegi siis, kui kahe objekti kõikide tunnuste väärtused langevad kokku. Reeglid: 1. Atribuut on kas elementaarne või ehitatud elementaarsetest kasutades vahendeid struktuursete tüüpide ehitamiseks. 2. Seoseid (relationship) saab tekitada teise (või sama) objektitüübiga, kasutada saab ka konstruktoreid (set, bag, list, array). 3. Objektitüüp ei saa olla atribuudiks. 4. Elementaarsed atribuuditüübid ei saa olla seoses. 5. Struktuuri (struct) ei saa kasutada seose defineerimisel. 7. O-O ja relatsioonilisel mudelil põhinevate andmebaaside suhted Käesolevaks on O-O andmebaasid haaranud erivajadustega süsteemide turu: e- kaubandus, uue tehnoloogia loomise insenerivahendite ülesanded, turvateenistus ja spetsiaalsed meditsiiniülesanded. Hierarhilise ja võrkmudeli kõrvale relatsioonilise mudeli tekkimisel (70-ndatel) arutati ca 10 aastat kes keda välja tõrjub. Nagu me nüüd teame, lõppes see relatsioonilise andmemudeli võiduga ja võidu põhiliseks tagatiseks oli tema kasutajasõbralik keel andmete käsitlemiseks. Praegu on valitsevateks andmemudeliteks relatsiooniline ja objekt-orienteeritud mudel, aga ei räägita sellest, kes kelle turult välja tõrjub. Selle asemel on nad turu segmendid omavahel ära jagatud. Esimese, suurema osa moodustavad suure mahuga mitte väga keeruliste andmetega ülesanded (nagu enamus klassikalisi operatiivarvestuse ülesandeid) nende vajadusi rahuldavad hästi relatsioonilised andmebaasid. Keskmise andmemahuga, aga keerulise struktuuriga andmetega ülesandeid rahuldab paremini O-O tüüpi andmebaasisüsteem. Aga O-O mudeli arengu tunnuseks on mitmete standardiseerimis-organisatsioonide tekkimine: Object Management Group OMG ( ), Object Database Management Group ODMG (lühikirjeldus ), ja X3H7 ( viimane on üks X3 tehnilisi komiteesid 10

11 tegelemaks O-O ABJS standarditega nagu O-O andmemudel ja SQL-keele O-O laiendused. Ja O-O andmemudelite käsitluse lõpetuseks lõik ODBMS FAQ-st ( Q. Will ODBMSs replace RDBMSs? A. That is highly unlikely. Someone once told me that, "Data tends to stick where it lands." There are many applications built on existing RDBMSs. It's difficult, if not impossible, to move off those databases. That would be unrealistic. Where you primarily see ODBMSs is in new development. In these cases, someone has figured out how to use high performance on complex data to meet a business need. And you often see ODBMSs working side by side with RDBMSs. Mõtle! 1. Millised erinevused on graafilise (E-R või UML klassimudeli) ja O-O andmemudelil? 2. Kuidas teisendada O-O mudel relatsiooniliseks? 8. Andmemudelitest üldiselt Oleme seni lähemalt vaadanud relatsioonilist ja objekt-orienteeritud andmemudeleid andmebaaside loomiseks. Andmemudeleid on andmebaaside pika ajaloo vältel (kuuekümnendatest tänaseni) välja töötatud mitmeid, nad on pidevas arengus - täiendatakse olemasolevaid (näiteks luuakse uusi normaalkujusid relatsioonilise mudeli jaoks), luuakse uusi mudeleid, mis paremini vastavad reaalsete ülesannete vajadustele, vastavad infotehnoloogia ja tarkvaratootmise arengutasemele. Olemasolevate ja uute mudelite baasil realiseeritakse konkreetseid andmebaasi juhtimissüsteeme. Andmemudel on abstraktne mõiste, mis hõlmab neid vahendeid, mis on vaadeldavas paradigmas olemas andmete struktuuri kujutamiseks ja andmetega mitmesuguste operatsioonide tegemiseks. Andmemudel koosneb kahest osast: A. Vahendid andmete kirjeldamiseks B. Operatsioonid nende andmetega manipuleerimiseks. Mudeleid on loodud väga palju ja kerkib küsimus, kas on olemas üks, parim mudel. Kahjuks peab kohe vastama, et nn. parimat pole olemas, maailm on keeruline, sealt käsiteldavate osade kirjeldamiseks ja selle osaga manipuleerimiseks loodud vahenditel on kõigil omad head ja vead. Haritud inimene lihtsalt tunneb neid ja suudab teha teadlikke valikuid. Mudeleid saab võrrelda omavahel väga mitmest seisukohast lähtudes. 1. Eesmärk. Enamus mudeleid ehitatud konkreetse andmebaasisüsteemi andmete kirjeldamiseks ja nendega manipuleerimiseks; mudeli omadused kajastavad vastava keele omadusi. Aga näiteks graafilised mudelid (nagu E-R mudel ja UML klassimudel) on loodud hoopis kontseptuaalse taseme kirjeldamiseks ja nad pole otseselt seotud mitte ühegi AB keelega. Neil puudub operatsioonide osa täiesti ja on alust väita, et nende näol polegi tegemist andmemudeliga. Enamus mudeleid 11

12 on loodud operatiivsete andmete haldamiseks, osa aga arhiveeritud andmete kasutamiseks muutuste trendide leidmiseks, andmekaevandamiseks. 2. Objektile või tunnusele orienteeritud mudel. Esimesed mudelid (hierarhiline, võrkmudel) olid objekti mõistele orienteeritud, põhiliseks käsitluselemendiks oli olem, mingi objekt. Relatsiooniline mudel on tunnusele orienteeritud, olem pole põhimõiste, olemeid identifitseeritakse kaudselt, tunnuste kaudu. Uuemad, objektorienteeritud mudelid annavad jälle vahendid olemi identifitseerimiseks. Ka E-R mudel nõuab olemitüübi identifikatsiooni. 3. Andmeliiasus. Kõik mudelid aitavad kasutajal hoiduda salvestamast üht ja sama fakti mitmekordselt. Üldiselt käsitlevad objektorienteeritud mudelid liiasust paremini. Relatsioonilises mudelis on selle jaoks välja arendatud spetsiaalne normaliseerimise teooria, mis aitab andmeskeemi konstrueerida minimaalse andmeliiasusega. Relatsioonilise mudeli seoste kujutamine (tunnus ühes failis on välisvõti teises) sisaldab endas andmeliiasust, seega pole relatsioonilises mudelis andmeliiasust päriselt likvideerida võimalik. 4. N-M seoste käsitlemine. Andmebaasi efektiivsuse määrab suures osas see, kuidas n:m seoseid esitletakse. Näiteks: seos tudengite ja ainete vahel on tüüpiline n-m seos (iga tudeng kuulab palju aineid, iga ainet kuulab palju tudengeid). Andmebaas peab vastama ühtmoodi efektiivselt (ilma täisläbivaatuseta!) küsimusele: kes kuulavad antud ainet, kui ka küsimusele, milliseid aineid kuulab antud tudeng. Esimesed süsteemid andmebaaside loomiseks tekkisid 60-ndatel aastatel, tõuke selleks andis otsejuurdepääsuga mäluseadmete loomine ja arvutite välismälu mahu tõus. Sel ajal hakati tõsiselt mõtlema kontoritöö automatiseerimisele ja andmebaasisüsteemid tekkisidki vahendina operatiivandmete haldamiseks. Selleks ajaks oli turule ilmunud mitmeid süsteeme aruannete genereerimise toetamiseks (ingl.k. report generation) - ka need süsteemid on andmebaasisüsteemide üheks tõukejõuks. Järgnevalt vaatame kahte ajalooliselt olulist andmemudelit. 9. Ajaloolised märkmed. Hierarhiline mudel Ajalooliselt esimene andmebaasisüsteem oli hierarhilise mudeliga. See mudel on ajalooliselt esimene (loodud 60-ndate keskel) seetõttu, et lihtsamate ülesannete, mida tol aja lahendati, andmed on oma olemuselt tihti hierarhilise struktuuriga: kaadriülesandes vastab andmete struktuur administratiivsele hierarhiale; pangas osakond-klient-käibedokumendid hierarhiale, haigla voodikohtade arvestus haigla osakond palat hierarhiale jne. Andmebaasi kirjeldus hierarhilise andmebaasi korral: Valdkond Realia Andmed: üliõpilane Kask a35543 eksam algebra B 12

13 Hierarhilise andmebaasi manipuleemiskeel on kirje- ja puu-orienteeritud, andes elementaaroperatsioonid puus liikumiseks. Find käskudega leitakse mingi kirje andmebaasis, get käsuga tõstetakse see kasutajaprogrammi töövälja. On ka käsud andmete lisamiseks andmebaasi ja olemasolevate andmete modifitseerimiseks. Andmebaasi manipuleerimiskeel on tavaliselt mingi programmeerimiskeel (näiteks Cobol, Fortran), millele on lisatud protseduurid andmebaasiga tööks. Manipuleerimise ideoloogia: üks kirje korraga. Tsüklid andmete leidmiseks ja nendega töötamiseks koostas programmeerija oma rakendusprogrammis. Kui lisaks lihtsatele, hierarhilise andmestruktuuriga üksikülesannetele hakati lahendama ka keerulisemaid, mitme kasutaja ülesandeid ja tekkis vajadus mittehierarhiliste seoste järele, täiendati olemasolevat süsteemi nn. virtuaalse kirje mõistega. tudeng Õppejõud eksam eksam Tuntuim hierarhiline süsteem on IMS - Information Management System. Loodud Rockwell kompanii poolt 60-ndate keskel, üle võetud IBM poolt 1967 (kasutati Apollo projekti haldamiseks), areneb tegelikult IBM toel edukalt veel siiamaani. Ainult hierarhiliste struktuuride kasutamine loob süsteemile aura ülilihtsusest, mis tegelikkuses osutub aga keeruliseks tegevuseks reaalsuse kirjeldamiseks olemasolevate kitsaste vahenditega, vrdl. kahvliga maakaevamisega. Hierarhilised süsteemid on praktiliselt väljatõrjutud relatsiooniliste ja O-O poolt, aga kuna IMS baasil jõuti realiseerida tuhandeid olulisi rakendusi, püsis ta elus väga pikka aega pärast oma ideoloogilist surma. Tegelikult puudub abstraktse hierarhilise mudeli mõiste hierarhiliseks loetakse süsteemis IMS kasutatud andmemudelit. Aga leidub palju vähemlevinud varaseid andmebaasisüsteeme, mille mudel oli põhistruktuurilt samuti hierarhiline (näit. Moskvas 70-ndatel arendatud INES). 10. Ajaloolised märkmed. Võrkmudel Erinevalt hierarhilisest mudelist, kus mudel tuletatakse ühe konkreetse süsteemi (IMS) omadustest, on võrkmudel loodud abstraktse mudelina, millele siis on hiljem tehtud konkreetseid realisatsioone. Selle mudeli töötas välja CODASYL (COnference on DAta SYstem Languages) DBTG (Data Base Task Group) 1971.a. Tööd alustati List Processing Task Force nime all juba 1965.a., uus nimi 1967.a.. Kuna CODASYL on ka programmeerimiskeele COBOL autor, siis algul vaadati asja COBOLi laiendusena. Esimene ametlik dokument 1968 COBOL extension to handle data bases. Samal ajal arendas IBM programmeerimiskeelt PL/1 ja sundis DBTG i ka selle oma plaanidesse sisse võtma. Põhidokument sai valmis 1971a., täiendatud parandatud aruanded tekkis kuni 1981.a.-ni. Kommertsiaalsed süsteemid, mis baseeruvad võrkmudelil: IDS/2(Honeywell), DMS (Univac), IDMS (Intergrated Database Management System, Cullinane, hiljem ümber nimetatud Cullinet), UDS (Universal Data Structure, Siemens, ka IBM ja ICL arvutitel). 13

14 10.1 Andmestruktuurid võrkmudelis. Põhimõisted: kirje tüüp (record type) ja komplekti tüüp (set type). Kirje tüüp võib olla üsna keeruline, vastates üldiselt tolleaegsete programmeerimiskeelte (Cobol, PL/1) ettekujutusele kirjest. S.t. kirje sees on olemas väljade hierarhiline struktuur (näiteks kuupäev),vektorid (korduvad elemendid), korduvad grupid ja lisaks nn. aktuaalsetele väljadele (kus säilitatakse andmete väärtusi) on lubatud ka virtuaalsed väljad (millede väärtus arvutatakse vastava elemendi poole pöördudes, kasutades etteantud protseduuri või AB päringut). Virtuaalsete väljade näited: vanus (arvutatakse protseduuri poolt, kasutades andme-elementi sünnikuupäev ja süsteemset muutujat tänane kuupäev); alluvate arv (kasutatakse andmebaasi päringut). Komplekti tüüp on võrkmudeli põhistruktuur. Kirjeldab 1-n seost kahe või enama kirjetüübi vahel. Sellisel seosel on alati: nimi, omaniku kirjetüüp ja alluva(te) kirjetüüp(/bid). Kasutatakse ka graafilist nn. Bachman i diagrammi: Näide: üldine konkreetne Kirje tasemel: arsti Matem.-inf. omanik teaduskond... alluv seosenimi üliõpilane õpib Kask Kuusk Jõgi Komplekt määrab muu seas ka juurdepääsu kirjetele ja ka alluvate järjestuse. Seepärast eksisteerivad ka nn. singulaarsed komplektid, mille omanikuks on ühe tühja fiktiivse kirje eksemplariga nn. süsteem. Komplekti tüüpide kasutamisel pole piire: üks kirjetüüp võib olla omanikuks kuitahes paljudele komplektidele ja samas ka alluvaks piiramatule arvule komplektidele. On lubatud ka rekursiivsed seosed. Eraldi probleem on n-m seoste kujutamine. Kuna lubatud on ainult 1-n seosed, siis tuleb n-m seos lammutada ja esitada kahe 1-n seose abil, tuues sisse fiktiivse, tihti ilma andmeväljadeta, seosekirje. Näide. töötaja - projekt, mis on n-m seos, saab esitada järgmiselt: töötaja töötab projekt t-t p-t Joonistage sellele skeemile vastav kirje tasemel skeem kolme projektiga ja nelja töötajaga, kellest igaüks osalevad parajasti kahes projektis. Võrkmudeli andmekirjelduskeeles on palju elemente, mis määravad mitte niivõrd komplektide tüüpe, kui andmemanipuleerimiskeele semantika. 14

15 Näide. insertion is manual/automatic komplekti liikme kirjelduses näitab, kas liikme saab lisada ilma teda kohe komplekti lülitamata (manual), või tuleb koos lisamisega anda ka andmed omaniku määramiseks, et saaks automaatselt komplekti lülitada. Näiteks tudengite immatrikuleerimisel peaks lisamine olema automaatne, sest tudeng võetakse vastu konkreetsesse teaduskonda, ilma teaduskonnata tudengeid pole olemas. retention is optional/mandatory/fixed komplekti liikme kirjelduses näitab, mida teha liikmetega, kui omaniku eksemplar eemaldatakse ja kas teda saab töö käigus teise omanikuga siduda (disconnect, connect käsud) Võrkmudeli andmemanipuleerimiskeel (Data Manipulation Language DML). Võrkmudelis on andmemanipuleerimiskeel protseduur-orienteeritud keel ühe kirje kaupa tööks. Kogu töö ajal on olemas hulk indikaatorid: aktiivne kirje igas kirjetüübis, aktiivne kirje komplekti tüübis jne. Käsud: FIND, GET, STORE, ERASE, MODIFY, CONNECT, DISCONNECT. Need käsud realiseeritakse programmeerimiskeele (Cobol, PL/1, Fortran jne.) protseduuridena. 11. Kokkuvõte Ajalooliselt tekkisid mudelid selles järjestuses: 16) Hierarhiline mudel 60ndate keskel (mudel tuletatud ühest konkreetsest süsteemist IMS - - Information Management System). 17) Võrkmudel 70ndate algul (mudel loodud CODASYL DBTG poolt abstraktsena, palju realisatsioone). 18) Relatsiooniline mudel teoreetiliselt: 70ndate algul (Codd i artiklid), realisatsioonid alates 70ndate lõpust. 19) Objekt-orienteeritud teoreetilised alused 80-ndate keskel, kui selgus, et tol ajal massiliselt levinud relatsioonilised süsteemid ei suuda korralikult hallata multimeedia andmeid jms., reaalselt turule 90-ndatel, peale seda, kui O-O paradigma muutus programmeerimises valdavaks. 20) Viimase kahe, relatsioonilise ja O-O mudeli baasil on tekkinud Objekt- Relatsiooniline mudel, mis püüab tuua O-O omadusi relatsioonilisse süsteemi kasutajaliidesesse. Lisaks neile üldtuntud mudelitele on loodud hulgaliselt muid: näit. binaarsetel relatsioonidel põhinev binaarne mudel, semantiline mudel, kus eriline rõhk on vahenditel andmete omavaheliste seoste ja kitsenduste kirjeldamiseks, loogiline mudel, mis on mõjutatud programmeerimiskeele Prolog poolt ja palju teisi. Kogu see ligi 50-aastane areng on toimunud arvutite endi ja nende välismäluseadmete kiire arengu taustal, viimased 20 aastat mõjustatuna ka Interneti arengust. Andmebaasisüsteemid ise olid mitmesuguste andmetele juurdepääsu meetodite arengu initsiaatoriteks. Läbi aegade on kogu aeg kasvanud andmebaasides hoitavate andmete maht. Kui esimese relatsioonilise mudeliga andmebaasisüsteemi kohta on teada, et teda testiti andmehulgaga, mille maht oli 8 MB, siis kaasaegsete suurimate andmebaaside mahtu mõõdetakse juba terabaitides. CERN kavandas 2005a. andmebaasi, mille info maht oleks Eksabaitides. On aeg omandada Mega (10 6 ), Giga (10 9 ) ja Tera (10 12 ) kõrval ka järgmised mahuühikud: Petabait = baiti, Eksabait = 1000 petabaiti = baiti. 15

16 90-nde keskel muutus aktuaalseks veebi ja andmebaasi koostöö. Andmebaaside kasutusvaldkond kasvas eksponentsiaalselt. Selle mõjul tekivad paljud vahendid, mis võimaldavad andmebaase veebiga siduda (Active Server Pages, Front Page, Java Servlets, JDBC, Enterprise Java Beans, ColdFusion, Dream Weaver, Oracle Developer 2000 jne.). Sellest valdkonnast on meie teaduskonnas olnud mitmeid kursusi nii külalislektoriga kui ilma. Ühe asutuse tööks kasutatud andmebaasisüsteemid on läbi aegade kogu aeg muutunud ja operatiivandmete haldamise ülesande kõrvalproduktina on tekkinud suured heterogeensed arhiivid, kuhu on ladestatud aastakümnete info antud organisatsiooni tegevuse kohta. Kaasaegse infotöötluse võimete jaoks kujutavad need kullauku, kust saab organisatsiooni arengu planeerimiseks vajalikku üldinformatsiooni ja otseselt mittenähtavaid seaduspärasusi avastada spetsiaalsete meetoditega. Seda viimast nimetatakse andmekaevandamiseks (ingl.k. data mining) ja ühes järgnevatest loengutest tutvume andmekaevandamisega: kuidas on andmekaevandamine seotud andmebaasidega ja milliste probleemidega ta tegeleb. Kuigi tundub, et SQL on muutunud andmebaaside valdkonnas prevaleerivaks keeleks ja ilma SQL-ta pole töö andmebaasidega üldse võimalik, siis viimasel ajal kogub pooldajaid NoSQL nimeline uue generatsiooni andmebaaside liikumine. Üheks selle liikumise taganttõukajaks on vajadus käsitleda XML (extensible Markup Language) tüüpi dokumentide andmeid. NoSQL andmebaase iseloomustab väga suurte andmemahtude juures ülikiire andmete kättesaamise kiirus, normaliseerimata ja strukturiseerimata andmete kasutamine, JOIN tüüpi operatsioonide vältimine. Lisamaterjal: 1. A Short Database History 2. J. D. Ullman, J. Widom, A First Course in Database Systems. Prentice Hall International, Inc., 1997,pp