Univerza v Mariboru

Fakulteta za elektrotehniko, raunalnitvo in informatiko

Izpit podiplomskega tudija:

PODATKOVNE BAZE

Nosilec predmeta: doc. dr. Tatjana Welzer Druovec

Datum: 26.05.2002

Avtor: Jurij Laznik

Kazalo

Seznam slik

Uvod
Objektne podatkovne baze so predmet raziskav zadnjih 20 let, za komercialno uporabo pa so na voljo nekje zadnjih 11 let. Razvoj dananjih informacijskih sistemov temelji predvsem na objektno orientirani paradigmi.Uporaba objektne tehnologije pa povzroa teave razvijalcem, e imajo opravka z relacijskimi bazami. Teave lahko predstavimo z naslednjim primerom: uporaba objektne tehnologije ob hkratni uporabi relacijske baze zahteva preskok med dvema paradigmama, objektno in relacijski. Ob uporabi objektne baze to vrzel zapolnimo. Objektne podatkovne baze se danes uporabljajo na mnogih podrojih. Natejmo nekatere od njih: CAD/CAM (Computer Added Design/Manufacturing) objektna podatkovna baza hrani podatke o mehanskih, elektronskih nartih. Podatkovne baze vsebujejo lahko narte letal, stavb in avtomobilov. Poleg tega podatkovne baze omogoajo hrambo podatkov o industrijskih linijah in o strojih. CASE (Computer Aided Software Engineering) objektne podatkovne baze hranijo podatke o stanju projektov, dokumentacijo razlinih faz projektov (zbiranje zahtev, nartovanje, implementacija, testiranje in vzdrevanje). OA (Office Automation) objektne podatkovne baze vsebujejo podatke oziroma dokumente, ki jih sreujemo v vsakdanjem ivljenju v pisarni (naslovi, rauni, poslovne knjige, okronice, razline pravne listine). CAP (Computer - Aided Publishing) objektna podatkovna baza vsebuje podatke o kompleksnih dokumentih in je poseben primer objektne podatkovne baze za avtomatizacijo pisarn. Ta podatkovna baza omogoa tudi shranjevanje zvoka, slik, tekstov in animacij. V tej nalogi bomo najprej opisali osnovne koncepte objektne paradigme, ki jih v veliki meri uporabljamo tudi pri objektnih bazah, opisali bomo kriterije, ki jim mora zadostiti objektni sistem za uporabljanje podatkovnih baz, nato se bomo sreali z metodo nartovanja objektnih baz, v zakljuku pa bomo opisali nekaj izdelkov najbolj znanih in aktualnih proizvajalcev in prikazali primer uporabe objektne podatkovne baze na primeru. Skozi celotno nalogo pa bomo skuali prikazati uporabnost objektnih

podatkovnih baz na podroju elektronskega bannitva in elektronskega poslovanja.

OSNOVNI KONCEPTI OBJEKTNO ORIENTIRANE PARADIGME

V tem poglavju bomo predstavili osnovne koncepte objektne tehnologije. Objektno orientirani jeziki in orodja omogoajo laje reevanje tehnolokih problemov. Z objektno tehnologijo lahko izraamo reitve problemov na bolj enostaven in naraven nain. Osnovni koncepti objektne paradigme so tirje: ograjevanje (enkapsulacija) in abstrakcija, dedovanje, objekti in prenos (poiljanje sporoil). Vsakega od teh konceptov bomo opisali v naslednjih podpoglavjih. Omenimo e, da poleg osnovnih konceptov objektne podatkovne baze vkljuujejo e lastnosti upravljanja podatkovnih baz, kot so: trajnost podatkov, transakcije in povpraevalne jezike.

Ograjevanje in abstrakcija Abstrakcija je proces kjer iemo loimo pomembne vidike uporabe objekta od nepomembnih. To pomeni, da se osredotoimo na to kaj objekt "dela" preden se odloimo kako bomo to implementirali. S tem odloimo implementacijo na kasneje faze razvoja, ko bi lahko naleteli na teave, e bi imeli objekt e implementiran. Ograjevanje ali enkapsulacija pomeni skrivanje podatkov. Medtem, ko samo implementacijo in podatke skrijemo pred zunanjim svetom, omogoimo dostop do objekta le preko metod. Najveja prednost ograjevanja je v tem, da spremembe v objektu ne vplivajo na samo aplikacijo. Z drugimi besedami to pomeni, da koncept ograjevanja zagotavlja neodvisnost podatkov. Na ograjevanje lahko gledamo z dveh zornih kotov: vidik objektno orientiranih programskih jezikov in vidik prilagoditve ograjevanja objektnim bazam. Vidik ograjevanja objektno orientiranih programskih jezikov V objektno orientiranih programskih jezikih doseemo ograjevanje preko abstraktnih podatkovnih tipov (ADT). Tako vsak objekt vsebuje vmesniki del in implementacijski

del. Vmesniki del omogoa specifikacijo operacij, ki jih lahko izvedemo nad objektom. Implementacijski del sestavljata podatkovna struktura za ADT in funkcije za realizacijo vmesnikega dela. Drugim objektom in uporabnikom je viden samo vmesniki del. Vidik prilagoditve ograjevanja objektnim bazam Pravilno ograjevanje v objektnih podatkovnih bazah zagotovimo tako, da imajo uporabniki dostop samo do vmesnikega dela. Tako omogoimo podatkovno neodvisnost: lahko spreminjamo implementacijski del ADT ne da bi ob tem spreminjali katerikoli drug del aplikacije, ki uporablja ta ADT. Dedovanje Pogosto imajo objekti podobne vendar ne enake atribute in metode, zato je smiselno omogoiti izkorianje skupnih lastnosti veim objektom. Dedovanje omogoa objektu, da postane objekt specialni primerek bolj splonega razreda objektov. Specialne primerke imenujemo podrazrede, splone razrede pa imenujemo nadrazredi. Proces izdelave nadrazredov imenujemo generalizacija, proces izdelave podrazredov pa specializacija. Obiajno podrazred podeduje vse lastnosti svojega nadrazreda ob tem pa ima dodanih e nekaj svojih lastnosti. Ob tem e omenimo, da lahko podrazred spremeni podedovane metode. Vsi primerki doloenega podrazreda so pravtako primerki svojih nadrazredov. Poznamo ve tipov dedovanja: enkratno dedovanje, vekratno dedovanje, ponavljajoe dedovanje in selektivno dedovanje. Enkratno dedovanje Ko podrazred deduje metode in atribute samo od enega nadrazreda govorimo o enkratnem dedovanju. Objekt, ki je podrazred nekega nadrazreda je lahko hkrati tudi nadrazred nekega drugega podrazreda. Tako tvorimo razredno hierarhijo. Primer enkratnega dedovanja vidimo na sliki 1.1.

Slika 1.1: Enkratno dedovanje Vekratno dedovanje Slika 1.2 prikazuje vekratno dedovanje kjer podrazred podeduje metode in atribute veih nadrazredov. Vidimo lahko, da podrazred "Vodja oddelka" podeduje tako operacije in atribute nadrazreda "Oddelek", kot tudi operacije in atribute nadrazreda "Zaposleni". Vsi jeziki ne podpirajo vekratnega dedovanja. Eden taknih jezikov je Java. Mnenja glede uporabe vekratnega dedovanja so razlina. Ena stran zagovarja uporabo vekratnega dedovanja saj le tako lahko opiemo objekte v realnem svetu, drugi pa so proti temu, saj vekratno dedovanje prinaa poveano mero kompleksnosti, ki pa jo je zelo teko varno upravljati in nadzorovati.

Slika 1.2: Vekratno dedovanje Ponavljajoe dedovanje Ponavljajoe dedovanje je poseben primer vekratnega dedovanja v katerem podrazredi dedujejo od veih nadrazredov. Primer ponavljajoega dedovanja je prikazan na sliki

1.3, kjer vidimo da podrazreda "Vodja" in "Prodajalec" dedujeta atribute in metode od nadrazreda "Zaposlen". Vidimo pa tudi, da podrazred "Vodja Prodaje" podeduje atribute in metode od svojih nadrazredov "Vodja" in "Prodajalec". Pri ponavljajoem dedovanju moramo vsekakor paziti, da podrazred ne podeduje dvakratno iste metode ali atribute od svojih nadrazredov.

Slika 1.3: Ponavljajoe dedovanje Selektivno dedovanje Selektivno dedovanje uporabimo takrat kadar elimo uporabniku omogoiti uporabo samo del nabora operacij in atributov. V tem primeru podrazredu povemo katere metode in atributi so dostopni uporabniku in kateri ne.

Objekti Objekti so osnovni gradniki oziroma temelji objektne tehnologije. Vsak objekt vsebuje informacije, ki govorijo o njegovem stanju in aktivnosti s katerimi modeliramo obnaanje objekta. DEFINICIJA OBJEKTA: Objekt je nedvoumno definirana entiteta. Vsebuje atribute in pripadajoe aktivnosti , ki opisujejo stanje in obnaanje objekta. Koncept definicije objekta je zelo enostaven in hkrati zelo moen saj lahko vsak objekt definiramo in ga spreminjamo neodvisno od drugih objektov. 7

Stanje objekta Stanje objekta lahko opiemo z enim ali ve atributi imenovanimi tudi spremenljivke primerka objekta. Atribute lahko razdelimo na dve skupini, ki sta: enostavni atributi in kompleksni atributi. Enostavne atribute sestavlja skupina primitivnih tipov (integer, string, real, ...). Na sliki 1.4 so takni atributi Mesto, Ulica, Vodja, itd. Kompleksni atributi ve zbirk ali referenc na druge tipe. Na sliki 1.4 je taken atribut Zaposleni. Poznamo e referenne atribute, ki predstavljajo povezave med objekti. Referenni atribut vsebuje vrednosti ali zbirko vrednosti, ki so sami povezave na druge objekte. Konceptualno gledano je referenni atribut enak tujemu kljuu v relacijskem podatkovnem modelu. Objekt, ki vsebuje ve kompleksnih atributov imenujemo kompleksni objekt. V mnogih primerih lahko sestavlja objekte ve objektov. Objekt, ki ga sestavlja ve objektov je navzven viden kot en sam objekt. Do atributov v objektu obiajno dostopimo preko takoimenovane "pika" ali "dot" notacije. Na primer, do atributa "Ulica" v objektu "Poslovalnica1" dostopimo na naslednji nain: "Poslovalnica1.Ulica".

Slika 1.4: Primer definicije objekta Identifikacija objekta Pomemben del definicije objekta je enolino doloena identifikacijska tevilka objekta (OID-Object Identifier). V objektno orientiranem sistemu ima vsak objekt svojo OID tevilko, ki je nevidna uporabniku. Ta tevilka spremlja objekt skozi celotno ivljenje objekta. Dva objekta se lahko nahajata v enakem stanju, vendar ne moreta imeti nikoli enake OID tevilke. Tudi ko uniimo objekt z neko OID tevilko, noben drugi objekt ne more

pridobiti te tevilke. Identifikacija objektov avtomatino omogoa integriteto sistema. Obstaja ve nainov kako implementiramo identifikacijo objektov. V relacijskih sistemih podobno funkcijo opravlja primarni klju, v objektnih sistemih pa OID. Vendar pa primarni klju ne opravlja takne funkcije v objektno orientiranih sistemih.Razloga sta predvsem dva: 1.Primarni klju je nedvoumno dololjiv le v relacijah in ne v celotnem sistemu. 2.Primarni klju je obiajno izbran iz mnoice atributov kar lahko mono omeji stanja objektov v objektnih sistemih. Natejmo e nekaj razlogov zakaj je uporaba OID bolja kot uporaba kljuev: OID so uinkoviti.OID imajo namre minimalne zahteve po prostoru v kompleksnih objektih. Obiajno so manji kot tekstna imena, tuji kljui ali druge semantine reference. Hitrost. OID kaejo na dejanski naslov v tabeli, ki hrani reference na objekte. Tako lahko uinkovito in hitro poiemo eleni objekt, ki je lahko shranjen v pomnilniku ali na trdem disku. Neodvisnost od vsebine. OID so neodvisni od vsebine, ki je shranjena v objektih. Nevidnost uporabniku. OID so nevidni uporabniku, s tem pa je zmanjana monost nepravilne rabe pri manj izkuenih uporabnikih. Opomnimo e na nejasnost, ki lahko izhaja iz zadnjih dveh alinej. Predpostavimo, da imamo dva objekta, ki vsebujeta iste atribute in metode, vendar razline OID. Vpraamo se, kako uporabnik loi med tema objektoma, e vemo, da OID niso vidni? Zakljuimo lahko, da e vedno rabimo neke vrste primarne kljue, da uporabniku dovolimo razlikovanje med objekti. Vendar pa obstaja tudi druga reitev za loevanje istovetnih objektov. Za vsak OID, ki ga definiramo v objektno orientiranem sistemu moramo v tem sistemu obstajati tudi objekt. S tem se izognemo obviselim referencam. V objektno orientiranih sistemih uporabljamo OID, da zagotavljamo referenno integriteto. Gledano s tega zornega kota lahko razlikujemo med objektno identiteto in objektno ekvivalenco. Dva objekta sta identina takrat in samo takrat ko vsebujeta isto OID tevilo (primerjamo ju z operatorjem '=') in sta enaka, ko sta v istem stanju (primerjamo ju z

operatorjem '=='). Sporoila in metode Objektna tehnologija omogoa, da atribute in metode predstavimo kot samostojne entitete. To pomeni, da atribute skrijemo pred zunanjim svetom, preko metod pa omogoimo dostop do teh atributov zunanjim uporabnikom. Na sliki 1.5 je prikazan primer objekta.

Slika 1.5: Primer splonega vidika objekta Metode predstavljajo obnaanje objekta. Z njimi lahko spreminjamo stanje objekta, spreminjamo lahko atribute, lahko pa tudi povpraujemo po vrednostih atributov v objektu. Lahko imamo na primer metode, s kateri povpraujemo po naslovu doloene poslovalnice, imamo lahko tudi metode, ki dodajo nove zaposlene. Metoda je sestavljena iz imena in telesa metode, ki izvede doloeno aktivnost v objektu. Slika 1.6 prikazuje primer metode vrni_naslov_poslovalnice, ki uporabniku vrne vrednost atributa ulica v primerku objekta s slike 1.4.

Slika 1.6: Primer definicije metode Sporoila uporabljajo objekti za medsebojno komuniciranje. Sporoilo predstavlja preprosto zahtevo enega objekta, ki je namenjena drugemu objektu, da izvede eno

10

svojih metod. Seveda lahko objekt polje zahtevo tudi sam sebi. Tudi tu se obiajno uporablja "pika" notacija. e je sporoilo namenjeno istemu objektu obiajno ne piemo imena objekta pred metodo, v ostalih primerih pa se sklicujemo na tono doloen objekt.

11

OBJEKTNI SISTEM ZA UPRAVLJANJE S PODATKOVNIMI BAZAMI

V prejnjem poglavju smo spoznali osnovne koncepte objektne tehnologije, v tem poglavju pa bomo spoznali kako so ti koncepti vkljueni v objektne podatkovne baze. Opisali bomo tudi katerim zahtevam moram ustrezati objektni sistem za upravljanje s podatkovnimi bazami (OSUPB). Zgodovina sistemov za upravljanje s podatkovnimi bazami V poznih 60-ih in zgodnjih 70-ih letih sta obstajala dva glava podatkovna modela. To sta bila hierarhini in mreni podatkovni model. Skupaj sta ta dva podatkovna modela predstavljala prvo generacijo sistemov za upravljanje s podatkovnimi bazami. Zaradi nekaterih pomanjkljivosti v hierarhinem in mrenem podatkovnem modelu je Codd v 70-ih letih razvil teorijo o relacijskem podatkovnem modelu, ki je kasneje postal temelj za mnoge sisteme za upravljanje s podatkovnimi bazami. SUPB, ki temeljijo na relacijskem podatkovnem modelu predstavljajo drugo generacijo SUPB. Zaradi vse bolj zahtevnih in obsenih aplikacij, predvsem pa pojava objektne tehnologije poznamo v zadnjem asu predvsem dve pomembni smeri razvoja podatkovnih modelov. Prvi je objektni podatkovni model in drugi razirjeni entitetno relacijski podatkovni model. SUPB, ki temeljijo na objektnem podatkovnem modelu in razirjenem entitetno relacijskem modelu pa predstavljajo SUPB tretje generacije. V tem poglavju bomo govorili ravno o SUPB tretje generacije. Objektni in razirjeni entitetno relacijski podatkovni model V tem podpoglavju bomo opisali oba podatkovna modela. Objektni podatkovni model predstavlja podlago OSUPB medtem, ko razirjeni entitetno relacijski podatkovni model predstavlja osnovo za raziritev funkcionalnosti SUPB relacijskih podatkovnih baz.

12

Objektni podatkovni model Objektni podatkovni model zajema semantiko podpore objektov v objektno orientiranem programiranju. Objektna podatkovna baza je trajen nabor objektov definiranih s objektnim podatkovnim modelom. Objektni sistem za upravljanje s podatkovnimi bazami je upravitelj objektne podatkovne baze.

Omeniti moramo, da trenutno ne obstaja objektni podatkovni model, ki bi bil ekvivalenten relacijskemu podatkovnemu modelu. Objektni podatkovni model ima lastnosti, ki jih je pridobil iz mnogih podroij raunalnitva in informatike, kot so: tradicionalni relacijski podatkovni sistemi, semantini podatkovni modeli, objektno orientirano programiranje in pa ostale posebnosti. Vsa podroja in lastnosti, ki sestavljajo OSUPB so prikazani na sliki 2.1.

Slika 2.1: Objektni podatkovni model Manifest objektnih podatkovnih baz Osnova OSUPB predstavlja Manifest objektnih podatkovnih baz, ki je bil sprejet leta 1989. Manifest vsebuje trinajst tok katerim mora zadostiti OSUPB. Prvih osem tok predstavlja objektno orientirane karakteristike, naslednjih pet tok pa predstavlja karakteristike sistema za upravljanje s podatkovnimi bazami. 13

1.Podpora kompleksnim objektom Omogoiti moramo izdelavo kompleksnih objektov. Minimalna zahteva je podpora zbirkam (SET), zapisom (TUPLE), seznamom (LIST) in poljem (ARRAY). Prva dva tipa sta pomembna, ker sta pridobila pomembno vlogo v relacijskem modelu. 2.Podpora identifikacije objektov Objektom moramo zagotoviti identifikacijo neodvisno od stanja in vrednosti objektov. 3.Ograjevanje mora biti omogoeno Ograjevanje v OSUPB doseemo tako, da loimo podatke v objektu od zunanjega sveta. To doseemo z metodami preko katerih uporabnik dostopa do podatkov v objektu. Obstajajo pa tudi primeri kjer ograjevanje ne potrebujemo. Takna izjema so "ad-hoc" povpraevanja. Pri taknih povpraevanjih namre dostopimo direktno do spremenljivke v objektu. 4.Omogoeno mora biti definiranje tipov in razredov Manifest zahteva podporo samo enemu konceptu: tip ali razred. To pomeni, da OSUPB ni dolan skrbeti in vzdrevati mnoice razredov istega tipa, e pa ima to lastnost, ni nujno dostopna uporabnikom. 5.Tipom in razredom moramo omogoiti dedovanje od njihovih prednikov Tipi in razredi lahko dedujejo od svojih prednikov zato jim moramo v OSUPB tudi to omogoiti. 6.Dinamino povezovanje Poznamo dva naina povezovanja, statino in dinamino povezovanje. Pri statinem povezovanju vemo v asu prevajanja katera metoda se bo izvedla v katerem razredu. Pri dinaminem povezovanju pa tega ne vemo vse do izvajanja programa. 7.Jezik za delo s podatki mora biti popoln Z drugimi besedami lahko reemo, da mora biti jezik za delo s podatki splono namenski programski jezik. 8.Nabor podatkovnih tipom mora biti razirljiv Uporabniku moramo omogoiti definiranje novih podatkovnih tipov na osnovi e obstojeih tipov. e ve, zahtevamo da OSUPB ne sme razlikovati uporabe sistemskih

14

in uporabniko definiranih tipov. 9.Trajnost podatkov mora biti zagotovljena Omogoiti moramo, da podatki ostanejo trajno shranjeni etudi zakljuimo delo z aplikacijo. Zahtevamo tudi, da uporabniku ni potrebno eksplicitno premakniti ali kopirati objekte v podatkovno bazo. 10.Omogoeno mora biti obvladovanje zelo velikih podatkovnih baz Tradicionalni SUPB vsebuje mehanizme za obvladovanje velikih podatkovnih baz, kot so indeksi in vmesni pomnilniki prostori (buffers). Tudi OSUPB mora vsebovati podobne mehanizme, ki so nevidni uporabnikom ob tem pa omogoajo laje obvladovanje velike koliine podatkov. 11.OSUPB mora biti veuporabniki sistem OSUPB mora vsebovati mehanizme za konkurenni dostop veih uporabnikov do sistema. 12.OSUPB mora vsebovati mehanizme za odpravljanje napak v primeru napak na strojni oziroma programski opremi 13.OSUPB mora vsebovati enostaven jezik za povpraevanja Jezik za povpraevanja mora biti implementiran na visokem nivoju, omogoati mora "ad-hoc" povpraevanja, mora biti uinkovit. Za OSUPB ni nujno da vsebuje povpraevalni jezik, namesto tega lahko vsebuje grafini pregledovalnik.

Manifest predlaga naslednje dodatne lastnosti, ki jih lahko vsebuje OSUPB: vekratno dedovanje, preverjanje tipov, distribuirane podatkovne baze, mehanizem transakcij in upravljanje konfiguracij. Zanimivo je, da ni nikjer zaslediti postavk glede varnosti, integritete ali pogledov.

Razirjeni entitetno relacijski podatkovni model Mnogo proizvajalcev relacijskih SUPB se zaveda gronje, ki jo predstavljajo objektne podatkovne baze. Vsi se hkrati strinjajo, da relacijski SUPB ne zadoajo vse kompleksnejim aplikacijam in da je posodobitev nujna.

15

Trenutno najuinkovitejo reitev predstavlja raziritev obstojeega relacijskega modela. Reitve se nanaajo predvsem na vkljuevanje novih funkcionalnosti, kot so: objekti, procedure in verzije. Vendar ne obstaja samo en razirjen entitetno relacijski podatkovni model ampak obstaja mnoica podatkovnih model, ki se vsak razlikuje od drugega glede na stopnjo in namen raziritve. Z namenom poenotenja raziritev obstojeega entitetno relacijskega podatkovnega modela je bil leta 1990 predstavljen manifest tretje generacije podatkovnih baz. Ta manifest vsebuje naslednjih trinajst tok: 1.SUPB tretje generacije mora imeti bogat nabor podatkovnih tipov. 2.Dedovanje je dobra ideja, ni pa nujno. 3.Funkcije, procedure, metode in ograjevanje so tudi dobra ideja. 4.Identifikacija zapisov v SUPB se uporabi le, e uporabnik ne definira primarnega kljua. 5.Pravila (proilci in omejitve) bodo postali v prihodnosti zelo pomembni, zato jih moram SUPB tretje generacije podpirati. 6.Vsi programski dostopi do podatkovne baze se na visokem nivoju. 7.Obstajati morata vsaj dva naina za specificiranje lanov, to je preko tevilenja lanov ali preko povpraevalnega jezika za specificiranje lanov. 8.Pogledi z monostjo osveevanja so nujni. 9.Mehanizmi za izboljanje sposobnosti podatkovne baze nimajo ni skupnega z podatkovnimi modeli zato se naj ne pojavljajo v SUPB. 10. SUPB tretje generacije mora biti dostopen imvejemu tevilu visokonivojskih jezikov. 11. Poenotenje visokonivojskega jezika za upravljanje podatkovne baze je zelo pomembno, saj tako postane dostop do podatkovne baze iz ostalih visokonivojskih programskih jezikov zelo enostaven. 12. SQL e vedno ostaja edini povpraevalni jezik podatkovnih baz tretje generacije. 13. Povpraevanja in odgovori morajo biti najniji nivo komunikacije med odjemalcem

16

in strenikom.

Prednosti in slabosti OSUPB V tem podpoglavju bomo nateli prednosti in slabosti objektnega sistema za upravljanje s podatkovnimi bazami (Tabela 1).

Prednosti OSUPB Slabosti OSUPB Bogate zmogljivosti glede modeliranja.Ne obstaja univerzalni podatkovni Objektni podatkovni model omogoa boljemodel. modeliranje problemov iz realnega sveta.Omenili smo e, da je za OSUPB ne obstaja Objekt bolj naravno predstavlja stvari izuniverzalni podatkovni model kar realnega sveta. Objekte lahko z lahkotoonemogoa napredek pri razvoju OSUPB. zdruujemo v kompleksne objekte, pravReitev tega problema bi bilo sprejetje tako pa shranimo v objekte vse relacije,standarda, ki ga ponuja skupina ODMG tudi mnogo proti mnogo. (Object Database Management Group) Razirljivost. Pomanjkanje izkuenj. OSUPB omogoa definiranje novih tipov.Uporaba OSUPB je e vedno precej Z monostjo zbiranja skupnih lastnosti vomejena kar pomeni, da e ne obstaja nivo nadrazrede in uporabe teh skupnih lastnostiznanja, ki trenutno je v tradicionalnih podrazredom zmanjamo redundanco vrelacijskih sistemih. Nadalje velja, da je sistemu. Ponovna uporaba omogoa tudiuenje uporabe OSUPB precej teavno kar hitreji razvoj in vzdrevanje podatkovnihse kae v pogostem zavraanju uporabe te baz v sistemu. tehnologije. Odstranitev impedanne vrzeli. Pomanjkanje standardov.

Enotni vmesnik med programskimi jeziki inOmenili smo e, da OSUPB nima enotnega jezikom za delo s podatki omogoa lajepodatkovnega modela. Prav tako tudi ne obvladovanje impedannih vrzeli.Vobstaja enotni povpraevalni jezik Tudi na tradicionalnih sistemih potekapodroju objektnih povpraevalnih jezikov komunikacija od podatkovne bazeje ODMG naredil pomemben korak s (deklarativni jezik) do aplikacijepredlogom standardiziranega objektnega (imperativni jeziki C). povpraevalnega jezika (OQL Object Query Language). Na splono lahko reemo, da je glavni zaviralni element razvoja objektnih podatkovnih baz pomanjkanje standardov. Bolj izrazno zmogljiv povpraevalniOptimizacija povpraevanj. jezik. Optimizacija povpraevanj zahteva Najbolj osnovno opravilo v OSUPB jepoznavanje implementacije podatkovne sprehod od enega objekta do drugega.baze kar predstavlja oviro za manj izkuene Takni sprehodi so zelo primerni zauporabnike in razvijalce objektnih rekurzivna povpraevanja. Vendar pa taknipodatkovnih baz. sprehodi niso vedno tisto kar zahtevajo 17

Prednosti OSUPB Slabosti OSUPB konni uporabniki OSUPB. Zato obiajno OSUPB vsebujejo tudi deklarativni povpraevalni jezik, ki sloni na SQL. Razvoj sheme. Zaklepanje. Mona povezava med podatki in aplikacijoVeliko OSUPB uporablja metodo v OSUPB omogoa laji razvoj inzaklepanja kot mehanizem za nadgradnjo objektne podatkovne baze.veuporabniki dostop do objektne Princip generalizacije in dedovanjapodatkovne baze. e zaklepanje dovoljujejo laji razvoj sheme podatkovneuporabljamo na nivoju objektov, lahko baze, s imer zajamemo velik del semantikenastanejo problemi pri zaklepanju aplikacije. podedovane hierarhije. Podpora dolgim transakcijam. Kompleksnost. Trenutni SUPB zahtevajo, da transakcijeMnoge nove funkcionalnosti, kot so uporabljajo serializacijo podatkovgnezdene transakcije, upravljanje predvsem pri dolgotrajnih transakcijah. Dakonfiguracije in podobno zahtevajo bolj SUPB lahko streejo dolgotrajnekompleksno delo kot v tradicionalnih transakcije uporabljajo posebneSUPB. V splonem pa veja kompleksnost mehanizme. Izpopolnjene mehanizme jeprivede do drajih in teje obvladljivih prevzel tudi OSUPB, kar mu daje prednostizdelkov. pred SUPB. Prilagodljivost kompleksnim Pogledi. problemom. Trenutno OSUPB ne omogoajo definiranje Omenili smo e, da se relacijski SUPB nipogledov. Kot vemo pa imajo pogledi posebno uspeno obnesel na tevilnihmnogo prednosti: podrojih: raunalniko podprto- definiranje dostopa za vsak pogled; nartovanje (CAD), raunalniko podprta proizvodnja (CAM), raunalniko podprto- zmanjana kompleksnost; nartovanje programske opreme (CASE) in- prilagodljivost zahtevam uporabnikov; drugi. OSUPB pa se je prilagodil ravno za ta podroja. Izboljana kakovost in izvajanje. Varnost. Merilo za hitrost in izvajanje operacij vOSUPB trenutno ne omogoajo dovolj objektnih podatkovnih bazah je postal letavisokega nivoja varnosti. Veina 1992 Object Operations Version 1. Po temmehanizmov je zasnovanih preve grobo, merilu OSUPB mono prekaa relacijskizato ne omogoajo nastavitev razlinih SUPB na podrojih za katere je namenjen,dovoljenj za posamezne objekte. kar pa ne pomeni, da relacijski SUPB nima svojih prednosti. Tabela 1: Prednosti in slabosti OSUPB

18

PRIMERI RAZVOJA APLIKACIJ

V tem poglavju bomo opisali primer razvoja dela aplikacije za elektronsko bannitvo. Primer bomo razvili na tri naine, in sicer: razvoj aplikacije primer za entitetnorelacijski podatkovni model, razvoj aplikacije primeren za razirjen entitetno-relacijski podatkovni model in razvoj aplikacije primeren za objektni podatkovni model. Podatkovne baze, ki jih bomo uporabili za realizacijo nae aplikacije bodo Microsoft Access [1], Oracle 8i Personal [2] in ObjectStore [3]. Pri vsakem od primerov implementacije bomo opisali tudi prednosti in slabosti posameznega pristopa.

Uporabnike zahteve aplikacije Preden se lotimo samega razvoja aplikacije mora spoznati zahteve uporabnikov nae aplikacije. Primer katerega bomo implementirali bo vseboval naslednje funkcije: pregled stanja na tekoem raunu; monost plaila polonice; naroilo ekovnih blanketov in limita; Ob vseh natetih monosti moramo seveda omogoiti tudi administracijo omenjenih monosti s strani bannega uslubenca.

Razvoj aplikacije za entitetno-relacijski SUPB Za implementacijo nae aplikacije smo uporabili programski jezik Java in SUPB Microsoft Access. Za povezavo aplikacije in podatkovne baze smo uporabili JDBC ODBC most, ki podpira irok nabor komunikacijskih vmesnikov. Aplikacija je grajena v vseh treh primerih po modelu MVC (Model View Controller). Najprej smo izdelali entitetno relacijski diagram za aplikacijo, ki jo bomo zgradili. Ta diagram je prikazan na sliki 3.1, izdelali pa smo ga z orodjem Microsoft Visio 2000.

19

Slika 3.1: Entitetno - relacijski diagram podatkovne baze Primer dostopa Javanske aplikacije je prikazan na sliki 3.2. Javanska aplikacija naprej dostopa do JDBC ODBC mostu, le ta pa naprej dostopa do ODBC sistemskega gonilnika, ki ima monost dostopa do podatkovne baze.

Slika 3.2: Dostop do podatkov Kot smo e omenili smo aplikacijo izdelali po modelu MVC. To pomeni, da je aplikacija grajena v treh slojih oziroma paketih: podatkovni sloj (dostop do podatkovne baze), sloj poslovne logike in predstavitveni sloj. 20

Sedaj bomo na primeru pokazali zapis plaila uporabnika v podatkovno bazo. Zaeli bomo s predstavitvenim nivojem. Na sliki 3.3 je primer vnosne maske uporabnikega vmesnika za plailo polonice. Uporabnik lahko vpie razline podatke o plailu, plailo pa izvri s pritiskom na gumb "Izvedi plailo".

Slika 3.3: Primer vnosne maske za plailo polonice Potek plaila se prenese na nivo poslovne logike. V tem delu e sestavimo primerno SQL povpraevanje in izraunamo novo stanje uporabnika. Na koncu e izvedemo klic za zapis podatkov v podatkovni nivo. Slika 3.4 prikazuje primer programske kode nivoja poslovne logike za zapis plaila v podatkovno bazo.

Slika 3.4: Primer programske kode v nivoju poslovne logike - Access V podatkovnem nivoju se dejanski podatki zapiejo v podatkovno bazo. Ker veino 21

dostopov do podatkovne baze opravimo z SQL klici smo v ta namen izdelali univerzalno metodo v podatkovnem nivoju za dostope do podatkovne baze. Metoda sprejme na vhod SQL stavek in ga izvri. Izvorna koda te metode je prikazana na sliki 3.5.

Slika 3.5: Izvorna koda metode za izvrevanje SQL stavkov Ugotovimo lahko, da je delo z relacijsko podatkovno bazo razmeroma enostavno, tudi uenje dela z relacijskimi podatkovnimi baze je bolj enostavno saj obstaja ve literature in tudi gradiva v elektronski obliki, kot na primer za objektne podatkovne baze. Pri tem moramo omeniti tudi standardiziran jezik za povpraevanja SQL. Pomanjkljivost relacijskih podatkovnih baz pa je, da ne moremo uinkovito uporabiti in izrabiti moi objektne tehnologije. Razvoj aplikacije za razirjen SUPB Pri implementaciji smo uporabili programski jezik Java, za podatkovno bazo pa smo izbrali Oracle 8i. Oraclova podatkovna baza z verzijo 8.1.X navzgor omogoa uporabo objektov oziroma struktuiranih tipov v podatkovni bazi. Ta podpora nam omogoa meanje entitetno relacijskega in objektnega podatkovnega modela. To pomeni, da najprej kreiramo tabelo v katerih uporabljamo standardne podatkovne tipe, kot tip pa lahko dodatno uporabimo tudi struktuirani podatkovni tip. Primer definicije in uporabe objekta je prikazan na sliki 3.6.

22

Slika 3.6: Definicija in uporaba objekta v tabeli Entitetno relacijski model za Oracle podatkovno bazo je rahlo spremenjen (Slika 3.7), saj smo se trudili imbolj olajati delo z uvedbo objektov za razline funkcionalnosti aplikacije. Tako smo tabele, kot so: Status, Trajanje, Posta in Stanje_narocila pustili nespremenjene, medtem ko smo v drugih tabelah uvedli objekte.

23

Slika 3.7: Entitetno relacijski diagram za razirjen SUPB ER diagram za razirjen SUPB smo izdelali s programom Together, ki omogoa tudi izdelavo DDL (Data Definition Language) za podatkovne baze Oracle. Primer takne definicije vidimo tudi na sliki 3.6. Ravno tako kot v prejnjem podpoglavju bomo tu opisali primer zapisa plaila v podatkovno bazo Oracle. Z opisom bomo zaeli v sloju poslovne logike, ker je predstavitveni nivo enak kot pri prejnji razlagi. Na sliki 3.8 vidimo, da nam e predstavitveni nivo vrne objekt, ki ga elimo shraniti v podatkovno bazo. Tako samo izraunamo novo stanje stranke in objekt ter novo stanje zapiemo v podatkovno bazo.

24

Slika 3.8: Primer programske kode v nivoju poslovne logike Oracle Narava nove funkcionalnosti oziroma uporaba objektov za shranjevanje podatkov, nam je onemogoeno enostavno shranjevanje preko SQL klicev. Metoda za shranjevanje podatkov na podatkovnem nivoju je bolj zapletena, kot tista v prejnjem podpoglavju, kar vidimo na sliki 3.9.

Slika 3.9: Izvorna koda metode za zapis plail v podatkovno bazo Zakljuimo lahko, da je delo z Oraclovo podatkovno bazo in objekti zelo enostavno, koliina znanja, ki ga moramo osvojiti za uporabo objektov v podatkovni bazi je razmeroma majhna. Prednost temu tipu podatkovnih baz daje monost uporabe tako entitetno relacijskega kot tudi objektnega modela. Pomanjkljivost tega pristopa pa je rahlo teavneje dostopanje do podatkovne baze, vsaj tako smo opazili, v primeru programskega jezika Java.

25

Razvoj aplikacije za OSUPB Pristop k razvoju aplikacije je bil drugaen od prejnjih dveh. V tem primeru smo izhajali iz razrednega diagrama, katerega del je prikazan na sliki 3.10.

Slika 3.10: Del razrednega diagrama aplikacije Najve dela smo imeli na podatkovnem nivoju, saj ima baza podporo samo za osnovna opravila. Veliko teav nam je predstavljala tudi manipulacija s podatki, saj ObjectStore podatkovna baza nima povpraevalnega jezika. Veino manipulacij s podatki lahko opravimo preko razredov OSVector, OSHashtable, OSMap. Opiimo e na tem primeru zapis plaila v podatkovno bazo. Predstavitveni nivo je enak kot pri prejnjih dveh primeru, zato se osredotoimo na nivo poslovne logike in podatkovni nivo. Na nivoju poslovne logike je delo najteavneje, saj moramo vsak dostop do objekta opraviti kot samostojno transakcijo. Tako nastane veliko izvorne kode, ki pa se ji ne moremo izogniti (Slika 3.11).

26

Slika 3.11: Primer izvorne kode nivoja poslovne logike za zapis plaila v objektno bazo ObjectStore S slike 3.12 pa je razvidno, da imamo veliko laje delo pri zapisu plaila v podatkovno bazo. Z zelo enostavnim klicem podatkovne baze shranimo plailo.

Slika 3.12: Izvorna koda podatkovnega nivoja za zapis plaila v podatkovno bazo ObjectStore Pri implementaciji aplikacija smo prili do naslednjih ugotovitev: vse objekte moramo rono implementirati, kar je zelo zamudno predvsem pri popravkih objektov; za primerjavo povejmo, da ima Oracle za kreiraje objektov samo eno tekstovno datoteko, pri Accessu pa lahko tabele kreiramo preko uporabnikega vmesnika, ni enotnega povpraevalnega jezika; e ne potrebujemo vseh podatkov lahko predstavlja branje podatkov velik problem glede asovne zahtevnosti; oteeno je iskanje po tujem kljuu, saj moramo za takno iskanje prebrati dva objekta; obstaja pa bolji mehanizem za iskanje po primarnem kljuu, saj so vrednosti primarnega kljua shranjeni v sekljalni tabeli (Hashtable).

27

4. PREDSTAVITEV APLIKACIJE
V tem poglavju bomo na kratko opisali aplikacijo, ki smo jo razvili kot primer dostopa in manipulacije podatkov do razlini tipov podatkovnih baz; v naem primeru Microsoft Access, Oracle in ObjectStore. Aplikacija je sestavljena iz dveh vidikov: administratorskega in uporabnikega. Administrator je v tem primeru uslubenec banke medtem, ko je uporabnik stranka, ki ima raun odprt pri doloeni banki. 4.1 Namizje Ob zagonu aplikacije se moramo najprej prijaviti v sistem. Po uspeni prijavi pa dobimo na zaslon namizje aplikacije (Slika 4.1).

Slika 4.1: Prijava v sistem in namizje aplikacije

28

4.2 Stanje na raunu Ta funkcija omogoa vpogled v stanje na raunu tako uporabnika, kot tudi administratorja. Administrator ima omejen nabor informacij stranke; preveri lahko samo stanje (Slika 4.2).

Slika 4.2: Stanje na raunu 4.3 Plaila Ta monost omogoa uporabnikom plaevanje raunov (polonic) s tekoega rauna, administratorji pa lahko preverijo vse plaane raune stranke (Slika 4.3).

29

Slika 4.3: Plaila 4.4 Naroilo limita in ekovnih blanketov Tu lahko stranka naroi limit za doloeno obdobje, ali pa lahko naroi ekovne blankete. V administratorskem pogledu ta funkcija omogoa odobritev ali zavrnitev limitov oziroma naroil ekovnih blanketov (Slika 4.4).

30

Slika 4.4: Naroilo limita in ekovnih blanketov 4.5 Uporabnik Ta funkcija je omogoena samo v administratorskem pogledu, namenjena pa odpiranju novih raunov in spreminjanju podatkov na obstojeih raunih (Slika 4.5).

31

Slika 4.5: Uporabnik

32

5. ZAKLJUEK
Skozi celotno nalogo smo spoznavali lastnosti razlinih tipov podatkovnih baz. Medtem ko so se nekatere izkazale za zelo uinkovite (Oracle), smo pri drugih odkrili nekaj pomankljivosti. Omenili smo e nestandardiziran jezik za povpraevanje pri objektnih bazah kar daje veliko prednost relacijskim bazam. Tudi znanje, ki ga potrebujemo za obvladovanje podatkovnih baz je na podroju relacijskih baz obseno, medtem ko je objektna tehnologija razmeroma nova tehnologija. Najveja pomanjkljivost, ki smo jo zasledili pri razvoju objektnih podatkovnih baz in smo to tudi vekrat zapisali v nalogi je pomanjkanje standardov in lahko reemo, da se bo z standardizacijo objektnih podatkovnih baz poveala tudi uporaba le-teh. Vseeno pa imajo tudi objektne podatkovne baze nekaj prednosti. Pri razvoju aplikacij lahko tako za odjemalce kot tudi za strenike in s tem podatkovne baze uporabimo objektni pristop. Nadaljnja prednost je prostor, ki ga objektne podatkovne zasedejo na pomnilnikih enotah. V naem primeru smo imeli tri podatkovne baze katere so vse vsebovale priblino 10 zapisov. Tako je podatkovna baza Access zasedala priblino 420 kB prostora na trdem disku, Oracle podatkovna baza 270 MB in ObjectStore podatkovna baza vsega 20 kB. Ti podatki nedvomno priajo, da objektne podatkovne baze najbolj smotrno izkoriajo razpololjivi pomnilniki prostor. Za konec zapiimo e nekaj stavkov glede uporabe teh treh tipov podatkovnih baz v elektronskem bannitvu. Glede na izkunje in teave pri razvoju nae aplikacije lahko reemo, da bi bila najprimerneja podatkovna baza za podporo aplikacijam elektronskega bannitva Oracle. eprav se zavedamo, da ta podatkovna baza zasede veliko pomnilnikega prostora, ima ta podatkovna baza prednost uporabe tako objektnega kot tudi klasinega entitetno-relacijskega podatkovnega modela. Ta lastnost predstavlja predvsem prednost pri povezavi s starejimi tipi bannih aplikacij in podatkovnih baz. baze

33

LITERATURA:
[1] [2] [3] [4] [5] [6] [7] [8] [9] Microsoft Access: http://www.microsoft.com Oracle 8i Personal Edition: http://www.oracle.com ObjectStore: http://www.ObjectDesign.com OTS '98 zbornik tretjega strokovnega sreanja, Marjan Heriko, Ivan Rozman, Zalonika tiskarska dejavnost Tehnikih fakultet v Mariboru, 1998 Gradnja informacijskih sistemov (Objektni pristop), Marjan Heriko, Ivan Rozman,..., Zalonika tiskarska dejavnost Tehnikih fakultet v Mariboru, 1999 MODELS AND LANGUAGES OF OBJECT-ORIENTED DATABASES, Georg Lausen, Gottried Vossen, ADDISON-WESLEY, 1998 OBJECT DATABASE DEVELOPMENT, David W. Embley, ADDISONWESLEY, 1998 OBJECT-ORIENTED DATABASES, Setrag Khoshafian, WILEY, 1993 DATABASE SYSTEMS, Thomas Connoly, Carolyn Begg, Anne Strachan, ADDISON-WESLEY, 1996

34