VISOKA KOLA STRUKOVNIH STUDIJA ZA INFORMACIONE I KOMUNIKACIONE TEHNOLOGIJE

INTERNET TEHNOLOGIJE

OBJEKTNE BAZE PODATAKA

DIPLOMSKI RAD

Mentor:

Kandidat:

ime mentora

ime kandidata sa brojem indeksa

Beograd, 2010.

VISOKA KOLA STRUKOVNIH STUDIJA ZA INFORMACIONE I KOMUNIKACIONE TEHNOLOGIJE

INTERNET TEHNOLOGIJE

Predmet: Baze Podataka Tema: Objektne Baze

Ocena ____ ( __________ )

lanovi komisije: 1. ______________________________ 2. ______________________________ 3. ______________________________

Uvod: 1. Pojam baza podataka

Baze podataka predstavljaju najvii domet u oblasti informatike- automatskog uvanja, pretraivanja i obrade podataka. Problem sakupljanja, organizacije, memorisanja podataka datira od davnih vremena. Automatska obrada podataka se razvijala u dva pravca (od druge polovine 19. veka): -numerika, izraunavanje po sloenim obrascima i postupcima, i -informatika masovno uvanje, pretraivanje i obrada podataka Prvi sistem za automatsku obradu podataka napravio je engleski naunik Bebid, 1837. Vrlo sloen mehaniki ureaj koji je sadrao, za to vreme mogue, komponente savremenog raunarskog sistema: procesor, radnu memoriju, ulaznu jedinicu (buene kartice), izlaznu jedinicu (tampana traka). Ureaj se zvao analitika maina. Od 1946. nastupa era elektronskih raunara (vrlo iroko reeno) za numeriku obradu podataka. Od tada do danas su komponente doivele vrtoglav razvoj (uvedene su nove tehnologije poluprovodnika integrisana kola, magnetni zapisi). U ovoj oblasti je dolo do najveeg pada cena. Ekvivalent dananjeg PC, da je bilo mogue napraviti ga, 1960.godine bi bio 100.000 puta skuplji. Po nekim autorima, uz razvoj modela relacionih baza, dve tehnologije su doprinele izgledu dananjeg sistema baza podataka po modelu klijent-server: - razvoj personalnih raunara i LAN (local area network) mree i njihova integracija u razne sisteme.

1.1 Definicija baze podataka

1. Kolekcija podataka koja postoji relativno dugo, koristi je i odrava vie korisnika. Ili 2. Organizovane elektronske kartice, kolekcije informacija vezanih za odreeni subjekt, pojavu(realni deo sveta aparat, radnik, raunapstraktni pojam boja, koliina, zvanje dogaaj upis studenata, prijem bolesnika, transport asocijacije firma slubenik, predmet nastavnik) Ili 3. Skup povezanih podataka, organizovanih na odreen nain, u odreenim meusobnim vezama. Osnovna ideja baze podataka je da uva podatke na organizovan nain. To donosi dve koristi: podaci su dostupni za razna korienja unutar poslovnog sistema. Drugo, obzirom da je struktura baze poznata, softverski sistem u kome je smetena prua mone alatke za proirivanje mogunosti korienja. Baze postoje da bi sluile potrebama aplikacija. Aplikacija je jedinica softvera koja postoji da bi sluila potrebama neke aktivnosti: Igra, poslovni sistem, sistem oglaavanja, gotovo svaki proces koji moe da se zamisli. Potrebe aktivnosti odreuju zahteve aplikacije, a potrebe aplikacije odruju zahteve baze podataka. Baze podataka se fiziki sastoje od raunarskih datoteka. Aplikacije koje koriste baze, ne koriste direktno te datoteke. Aplikacije alju komande (zahteve) i primaju povratne informacije od DBMS (npr SQL server, Access).

1.2 Pojam sistema

U stvarnosti smo okrueni stvarima (osobama, stvarima u materijalnom smislu, konceptualnim celinama...), sa raznim osobinama, izmeu kojih postoje odnosi koji mogu biti promenljivi u vremenu. Tako bi se sistem mogao nazvati skupom objekata (stvari), entiteta i odnosa (veza) koji postoje meu njima. Svi objekti u sistemu se ne tretiraju kao jedan skup, ve se grupiu prema nekim osobinama, u zavisnosti od konkretne potrebe. U modelu nekog sistema objekti se opisuju preko svojih svojstava (atributa). Da bi omoguio sagledavanje stanja realnog sistema, informacioni sistem treba da reflektuje ponaanje realnog sistema. U tom smislu informacioni sistem treba da bude model realnog sistema u kome deluje (pa je projektovanje IS, na neki nain, modelovanje realnog sistema). Definiu se granice sistema, odnosno skup objekata koji predstavlja sistem, a sve izvan toga je okolina sistema. Dejstvo okoline na sistem ostvaruje se preko ulaza, a obrnuto preko izlaza. Stanje sistema se menja pod dejstvom ulaza. Stanje sistema se definie kao skup informacija o prolosti i sadanjosti sistema, koji je potreban da bi se pod dejstvom buduih poznatih ulaza mogli odrediti budui izlazi. Stanje opisuje fundamentalne karakteristike sistema (u nekom trenutku vremena predstavlja skup objekata sistema, skup njihovih meusobnih veza i vrednosti atributa). Osnovu informacionog sistema ini dobro projektovana baza podataka. Alati za opisivanje odnosno modelovanje sistema su modeli podataka. Podela modela podataka na vrste je odraz podele na vrste baza podataka. Sutinska razlika izmeu pojedinih vrsta modela je u strukturnoj komponenti.

1.3 Modeli podataka

Mogu se posmatrati kao: - osnova za izgradnju DBMS, - alat za projektovanje baze podataka. Osnovni problem u modelovanju realnih sistema je sloenost zbog: - postojanja velikog broja objekata, - sloenih veza medju objektima. Opti metodoloki pristup za prevazilaenje sloenosti je apstrakcija: postepeno i kontrolisano ukljuivanje detalja u opis sistema, odnosno izvlaenje i prikazivanje optih osobina sistema i odlaganje opisivanja detaljnih osobina. Generalno, koriste se sledee apstrakcije u modelima sistema:
1. Tipizacija (klasifikacija) objekata- podataka: objekti koji imaju isti skup osobina i isto dinamiko ponaanje mogu se predstaviti tipom ili klasom objekata 2. Generalizacija skup slinih tipova objekata se predstavlja optijim, generikim tipom ili nadtipom. Slini su oni tipovi objekata koji imaju neke zajednike osobine i ponaanje. 3. Agregacija skup objekata i njihovih meusobnih veza se tretira kao novi, jedinstveni, agregatni tip.

Prouavanju baza se pristupa sa 2 meusobno povezana aspekta: a) sistem za upravljanje bazom Database Management Systems DBMS, softverski sistem koji obezbeuje osnovne funkcije obrade velike koliine podataka - jednostavno pretraivanje i odravanje podataka - viestruko paralelno (konkurentno) korienje istog skupa podataka, - pouzdanost, - sigurnost. b) modeli podataka - specifine teorije pomou kojih se specifikuje i projektuje neka baza

1.4 KOMPONENTE SISTEMA ZA UPRAVLJANJE BAZOM PODATAKA

SUBP je, praktino, posrednik izmeu korisnika i operativnog sistema. To je aktivno deo baze podataka, skup postupaka za odravanje i korienje. 1. Baza podataka. Najei sluaj je BP smetena na disku. Za neke izuzetno velike sisteme BP moe biti smetena na tzv. Tercijarnoj memoriji, npr. sistem CD-ova sa robotom za izbor konkretnog diska (kapacitet i do 1000GB). Pored podataka u bazi su i metapodaci, renik podataka(data dictionary, catalog), koji opisuju bazu podataka: strukturu, pravila korienja, pravila integriteta... To je, praktino, baza o bazi. Termin integritet se koristi pri odreivanju tanosti (dozvoljene vrednosti) i konzistentnosti (dozvoljeni odnosi) podataka. Pravila integriteta definiu i radnje koje treba preduzeti kada je naruena tanost ili konzistentnost (to se moze desiti usled greke u programu ili sistemskog otkaza). Sistem odrava i bazu indeksa. Renik indeksa sadri opis indeksa za posmatranu bazu. Indeks oznaava strukturu podataka koja omoguava brz pristup indeksiranim podacima baze. 2. Sistem za upravljanje skladitenjem podataka sastoji se od dve komponente:
upravljanje baferima (Buffer Manager) odnosi se na lokacije datoteka preko kojih se realizuje baza i pristupe blokovima podataka na zahtev, upravljanje datotekama (File Manager)

3. Ulazi u sistem za upravljanje su: - Upiti (zahtevi sa podacima iz baze, sa navedenim uslovima koje podaci treba da zadovoljavaju) Preko njih moe da se menja sadraj baze. - Aplikacije (programi koji realizuju unapred definisane zahteve korisnika). Koristi se standardni programski jezik u koji se ugrauje jezik baze podataka. - Odravanje eme baze podataka. ema baze opisuje strukturu baze, pravila integriteta i pravila korienja. Odravanje, kreiranje i modifikovanje opisa koji se uva u reniku podataka. Ova tri ulaza realizuju se preko jezika baze podataka (Databse Language), koji se sastoji od dve komponente: - jezik za opis podataka (Data Definition Language), koristi se za odravanje eme baze, - opis baze podataka sveukupno, a i sa gledita pojedinih korisnika jezik za manipulaciju podataka (Data Manipulation Language), koristi za realizaciju upita i modifikacije baze. Preko jezika baze podataka definiu se tipovi podataka u bazi, oitavanje ili menjanje podataka, odreuje se pristup bazi. Generalno, jezici baze mogu biti proceduralni i neproceduralni.

4. Upravljanje transakcijama i oporavkom obezbeuje da baza ostane u konzistentnom stanju u konkurentnoj obradi podataka, ak i pri ozbiljnim otkazima sistema. Sistem za upravljenje treba da obezbedi efikasan oporavak baze (periodinim kopiranjem baze podataka na arhivske memorije i registrovanjem promena izmeu dva kopiranja). Transakcija predstavlja niz operacija nad bazom podataka koji odgovara jedoj logikoj jedinici posla u realnom vremenu. Logika jedinica posla, najmanji, atomski, posla koji ima neko realno znaenje. Ona se, u nekom programu, moe sastojati i od vie operacija nad bazom podataka (generalno, svaka operacija menja stanje baze ali od interesa, ovom sluaju je samo zbirni efekat ovih operacija). Sa korisnike take gledita stanje baze se moe menjati samo po okonanju logike jedinice posla. Prilikom izvravanja, transakcija mora da ima ACID osobine: 1. Atomnost (Atomicity): nad bazom podataka e se izvriti ili sve operacije ili nijedna. Za ostvarivanje ove osobine definiu se dve operacije nad bazom podataka: - COMMIT oznaava uspean kraj transakcije i potvruje sve promene u bazi podataka koje je proizvela transakcija - ROLLBACK kojom se ponitavaju efekti svih prethodnih operacija izvrenih nad BP u jednoj transakciji, ukoliko ona moe ugrozi konzistentnost baze podataka. 2. Konzistentnost (Consistency) pre i posle okonanja transakcije BP mora da zadovoljava uslove konzistentnosti. 3. Izolacija (Isolation): kada se izvravaju dve ili vie transakcija, njihovi efekti moraju biti meusobno izolovani. Odn. efekti koje izazovu transakcije koje se izvravaju istovremeno moraju biti jednaki efektima izvrenja transakcija jedne za drugom. 4. Trajnost (Durability): po zavretku transakcije, njeni efekti ne smeju biti izgubljeni ak i ako se desi otkaz sistema. Kontrola pristupa BP podrazumeva mogunost definicije kontrole na vie nivoa: - ko moe da pristupa BP, - kojim delovima BP korisnici mogu da pristupe, - ta korisnici mogu da rade sa delovima baze kojima imaju pristup.

1.5 KORISNICI BAZE PODATAKA

Korisnik postavlja upit preoko tastature...kao rezultat ovih upita pojavljuju se liste, da pomognu korisnicima. Sistem baze podataka nije spreman za korienje u trenutku kad je operativan-gotov na kompjuterskoj platformi. Naime, baza podataka mora i dalje biti projektovana, napunjena i drana aurnom a aplikacioni programi da moraju biti pisani da obezbede jednostavan interfejs preko menija za neiskusne (neupuene) krajnje korisnike. Ideja ljubaznosti ka korisniku u bazi podataka mora biti uslovljena razumevanjem postojanja vie tipova korienja. Specijalisti su odgovorni za obezbeivanje jednog okruenja kojem korisnici vieg nivoa mogu da rade, pri emu svaki tip korisnika ima zahteve za jednostavou korienja.

1.

Krajnji korisnici- interaktivni korisnici a) Obini korisnici- pristupaju DBMS sa SQL upitima b) Naivni korisnici- pristupaju bazi kroz menije Programeri aplikacija- koji piu aplikacije sa meniima Administratori BP-Specijalisti koji nadgledaju DBMS

2. 3.

Krajnji korisnici. Neki obini korisik od njeg se oekuje da ima lakou korienja SQL-a, to i nije tako jednostavno. Termin obian implicira da korisnik ima promenljive zahteve od sesije do sesije pa nije ekonomino pokuavati da se napie program baziran na meniju. Upiti - da odgovore neposredim potrebama su poznati kao interaktivni upiti ad hoc upiti, grubo, za specifinu namenu. Naivni korisnik obavlja sve - sa BP kroz aplikacije sa meniima i izbegava da konstruie upite u SQL sintaksi. Banke, avioni.. Programeri aplikacija- u smislu korienja DBMS, pie aplikacije koje koriste krajnji korisnici. Programi moraju predvideti potrebe korisnika i biti sposobni da postave SQL upite za vreme izvrenja da se dohvati eljena informacija iz baze podataka. Programeri su iskusni u radu sa tekim problemima sintakse i konceptualnim problemima. Oni provode dug period izvodei kompleksnu sintaksu upita da odgovori na neke upite koji mogu biti poslani od strane naivnog korisnika. Na utedu korisnikih napora programi obezbeuju vie konfidens poverenja da ne postoji podmukla greka u upitu koja moe da vrati pogrean odgovor. to je kompleksniji SQL upiti su tei za konstrukciju na ad hoc nain bez nekog rizika za greku. Treba da razume sve osobine zahtevane od administratora baze da bi planirao efikasne programe.

Razrada: 2. Objektne baze podataka

Poslednja decenija u softverskom ininjerstvu je decenija objektne orijentacije. Objektna orijentacija je pristup u kome se neki sistem organizuje kao kolekcija meusobno povezanih podataka koji, saraujui ostvaruju postavljene ciljeve. Objektna orijentacija je danas preovlaujua u programiranju i programskim jezicima, metodolokim pristupima razvoju softvera i informacionih sistema a postepeno preuzima primat i u sistemima za upravljanje bazom podataka, bilo preko istih SUBP bilo preko objektno-relacionih SUBP koji predstavljaju proirenje relacionih sa objektnim konceptima.

2.1 Tipovi podataka

Jedna od najbitnijih karakteristika SUBP-a je skup tipova podataka koje on podrava. Konvencionalni SUBP su zasnovani na tipu rekorda koje predstavlja agregaciju polja definisanih nad standardnim tipovima. U relacionom modelu se jo definie i tabela kao skup rekorda, u mrenom se uvodi pojam rekord seta a u hijerarhijskom pojam stabla rekorda. Objektni SUBP su postavljali sebi cilj da stvore mnogo bogatiji skup tipova i time omogue prirodniju manipulaciju podacima u aplikacijama koje se razvijaju nad bazom. U konvencionalnom SUBP tronivoska ANSI/SPARC arhitektura imala je za cilj da omogui da se baza podataka tretira kao samostalna komponenta nekog informacionog sistema. Zbog toga je jezik baze podataka DDL i DML u ovim SUBP potpuno odvojen od programskih jezika u kojima se razvijaju aplikacije, omoguujui na taj nain da se nad jednom bazom podataka razvijaju I izvravaju aplikacije napisane i u razliitim programskim jezicima. Nezavisnost jezika SUBP od programskih jezika bez obzira na problem koje su proisticali iz njihove mogue nesaglasnosti tretirala se kao prednost a ne kao nedostatak ovih SUBP. Objektni SUBP tee da integriu funkciju SUBP-a u programski jezik da bi se nesaglasnost jezika baze podataka i programskog jezika eliminisale i znaajno poboljale performanse sistema. Tei se tome da se izjednae u potpunosti objekti baze podataka i objekti aplikacija napisanih u nekom objektnom programskom jeziku. Objekti u aplikacijama su tranzijentni, ivotni vek im je jednak trajanju aplikacije, dok su objekti u bazi podataka perzistentni, nezavisni od postojanja aplikacija koje ih koriste. Ne eliminie se mogunost da vie programa , napisanih, ak i u razliitim objektnim jezicima koriste istu bazu podataka. Raspolaui sa mnogo bogatijim skupom tipova, objektni SUBP treba da podre i znatno moniji upitni jezik od relacionog SQL.

grafik 2.1.1

U nekom objektnom jeziku jednostavno se mogu realizovati sloene strukture podataka i takve uskladititi u objektnu bazu podataka. U sluaju relacionih baza podataka ta struktura podataka se prvo transformie u odgovarajui skup tabela relacione baze to je ponekad sloen i vremenski zahtevan postupak. Rani komercijalni objektni SUBP nisu bili zasnovani na jedinstvenom standardu, navedene ciljeve su ostvarivali sa manje ili vie uspeha, na razliite naine. Njihov komercijalni prodor je bio zanemarljiv. Uspeh relacionih SUBP pored ve diskutovanih prednosti bio je i u tome to su zasnovani na jedinstvenom standardu, SQL-u, to je znaajno podiglo njihovu prihvatljivost, prenosivost i mogunost kooperacije razliitih sistema. Zbog toga se u poslednjih nekoliko godina intezivno razvija standard za objektne baze podataka u okviru takozvane ODMG ( Object Database Management Group). Verzija ODMG 1.2 standarda pojavila se 1996. a znaajno izmenjena i dopunjena verzija 2.0 1997. godine . Ovde se izlau elementi ODMG 2.0 standarda.

2.2 Arhitektura objektnih SUBP komponente

Objektni model Objektni specifikacioni jezici Objektni upitni jezici C++, SmallTalk, Java Language Binding

Objektni model: Objektni model na kome treba da bude zasnovan svaki objektni SUBP ( ODMG model ) izveden je iz OMG ( Object Management Group ) objektnog modela. OMG je objektni model definisan kao zajednika osnova za objektne orijentisane programe i jezike, komunikaciju objekata u nekoj klijent-server arhitekturi ( Object Request Brockers, ORB, na primer CORBA ) i objektne baze podataka.

Objektni specifikacioni jezici: Slue da opiu sistem kao skup meusobno povezanih objekata. Objektni specifikacioni jezik ODL ima istu ulogu koju JOP (DDL) ima u konvencionalnim jezicima. Objektni upitni jezik: Neproceduralni jezik za postavljanje upita i modifikaciju baze podataka. Ovaj upitni jezik nazvan OQL ( Object Query Language) je namerno veoma slian SQL-u sa veim mogunostima koje prua objektni model. C++, Smalltalk, Java Binding Language Posebne nezavisne komponente arhitekture koje pokazuju kako se u C++ (Smalltalk, Java) ugrauju mogunosti manipulacije perzistentnim objektima, mehanizmi za povezivanje sa OQL-om , upravljanje transakcijama i slino. Za razliku od konvencionalnih JMP jezika, JMP u objektnim bazama se kroje prema jeziku domainu.

2.3 Korienje SUBP

grafik 2.3.1 blok ema korienja SUBP

Bilo koji sistem se moe posmatrati kao skup meusobno povezanih objekata. Pod objektima u nekom sistemu se podrazumevaju fiziki objekti, koncepti, apstrakcije, bilo ta to ima jasne granice i jasno znaenje, to se jasno razlikuje od drugih objekata u sistemu. U realnom sistemu objekti i nain ostvarivanja njihovih veza mogu da budu veoma raznovrsni. U nekoj vrsti modela realnog sistema svi ti raznovrsni objekti i njihove veze predstavljaju se sa odredjenim brojem precizno definisanih koncepata. Modeli koji slue za opis baze podataka nazivaju se modeli podataka.

2.4 Osnovni pojmovi

Osnovni primitivni koncepti objektnog modela su objekat i literal . Pod objektom se podrazumeva entitet koji je sposoban da uva svoja stanja i koji stavlja okolini na raspolaganje skup operacija preko kojih se ta stanja prikazuju ili menjaju Literar je u osnovi vrednost, podatak koji se koristi u modelu. Brojevi i karakteri su primeri atomskih literala, a datum je primer sloenog literala. Analogija sa objektno-orijentisanim programskim jezicima: Objekti neke klase su vrednosti datog tipa (immutable object literal) ili promenljive koje mogu uzimati vrednosti datog tipa (muttable object objekat) . Posebno je potrebno naglasiti sledeu razliku objekta i literala: Objekat ima jedinstveni indentifikator a literal nema. Objekti i literali se kategorizuju u tipove. Svi objekti, odnosno literali istog tipa imaju zajedniki skup stanja i jedinstveno ponaanje. Konkretan objekat se ponekad naziva pojavljivanje instance istog tipa. Za postavljanje literala se pretpostavlja da implicitno postoje. Stanje objekta se predstavlja vrednostima njegovih osobina. Osobine su atributi objekta i njegove veze sa drugim objektima u sistemu. Ponaanje objekta se opisuje preko skupa operacija koje on izvrava ili se nad njim izvravaju. Svaka operacija ima kao implicitni argument objekat kome je pridruena. Operacija moe da ima i listu ulaznih parametara definisanih tipova a moe i da se vrati tipizovan rezultat. Baza podataka skladiti objekte i stavlja ih na korienje veem broju korisnika, odnosno aplikacija. Baza podataka se opisuje preko svoje eme koja se specifikuje preko ODL-a. U emi se definiu tipovi objekata ija se pojavljivanja uvaju u bazi.

2.5 Specifikacija i implementacija tipa

Svaki tip ima jednu specifikaciju i jednu ili vie implementacija. Specifikacija definie eksterne karakteristike vidljive korisniku tipa: operacije koje mogu biti pozvane, osobine kojima se moe pristupiti i izuzeci (exceptions) koje operacije pobuuju. Implementacija tipa definie interne karakteristike objekata datog tipa. Mogue je definisati vie implementacija jedne specifikacije u jednom ili vie razliitih jezika. Odvajanje specifikacije od implementacije tipa je veoma bitno jer se na taj nain ostvaruje uaurenje (encapsulation) objekta, korienje servisa koji objekat prua okolini bez poznavanja implementacije. Specifikacija tipa se daje preko: - interfejsa koji predstavlja samo apstraktno ponaanje - klase koja predstavlja i apstraktno stanje i apstraktno ponaanje tipa objekta - definicija daje samo apstraktno stanje tipa literala Primer: interface Radnik {} ; class Lice {}; struct Kompleks { float reldeo, float imdeo}; Klasa je tip koji se moe direktno instancirati, pojavljivanja ovog tipa mogu se kreirati u nekom programu ili bazi. Interfejs je tip koji se ne moe direktno instancirati. Implementacija tipa u bilo kom programskom jeziku, ostvaruje se preko structure podataka za opis stanja i skupa metoda, preko kojih su implementirane operacije tipa. U veini objektnih jezika postoji koncept klase pa se moe rei da je u njima klasa osnovni mehanizam za

implementaciju tipova objekata. Koncept klase u objektnim jezicima ne treba izjednaavati sa pojmom klase u ODMG. Specifikacija tipova neke baze podataka se definie preko ODL-a a njihova implementacija u okviru povezivanja sa jezicima Language Bindings. Oni definiu nain transformacije klase ODMG u sopstveni implementacioni koncept klase.

2.6 Ugraeni tipovi

Atomski tipovi: long, short, unsigned long, unsigned short, float, double, Boolean, octet, char, string, enum < t > Kolekcije literala: set < t > , bag < t > , list < t > , array < t > , dictionary < t , p > Struktuirani literali: date, time, timestamp, interval, structure < t > Kolekcije objekata: set < t > , bag < t > , list < t > , array < t > , dictionary < t , p > Struktuirani objekti: date, time, timestamp, interval Ne postoji ugraeni tip atomskog objekta. Svi atomski objekti su korisniki definisani.

2.7 Hijerarhija ugraenih tipova objekata

grafik 2.7.1 hijerarhija ugraenih tipova objekata

U ODMG svi objekti nasleuju operacije osnovnog interfejsa OBJECT. Objekti se kreiraju pozivajui operacije interfejsa ObjectFactory a kolekcije pozivanjem operacija interfejsa CollectionFactory. interface ObjectFactory { Object new (); } ; interface Object { boolean same_as ( in Object ime_Objekta); Object copy (); void delete (); } ;

Operacije se primenjuju na objekte korienjem dot notacije. o.same_as (p) ; Poto jedan objektni SUBP moe da upravlja sa vie baza podataka definie se objekat za fabrikovanje baza kao i objekat koji definie samu bazu. interface databaseFactor { Database new ( ) ; } ; interface database { exception ElementNotFound { } ; void open ( in string ime_baze); void close ( ) ; void bind ( in any neki_obj, in string ime_obj); Object unbind ( in string ime_objekta ); Object lookup ( in string ime_objekta ) raises ( ElementNotFound ); }; interface CollectionFactory : ObjectFactory { Collection new_of_size (in long velicina) ; };

interface Collection { exception InvalidCollectionType { } ; exception ElementNotFound { bilo koji element } ; unsigned Long cardinality ( ) ; boolean is_empty ( ) ; boolean is_ordered ( ) ; boolean allows_duplicates ( ) ; boolean contains_element ( in neki_element ) ; void insert_element ( in neki_element ) ; void remove_element ( in neki_element ) ; raises ( ElementNotFound ) ; iterator create_Iterator ( in boolean stable ) ; bidirectionalIterator create_bidirectional_iterator ( in boolean stable ) ; raises ( InvalidCollectionType ); }

interface Iterator { exception NoMoreElements { } ; exception InvalidCollectionType { } ; boolean is_stable ( ) ; boolean at_end ( ) ; void reset ( ) ; any get_element ( ) raises ( NoMoreElements ); void next_position ( in neki_element ) ; void replace_element ( in neki_element ) ; raises InvalidCollectionType ( ); }

interface Set : Collection { Set create_union ( in Set drugi_skup ) ; Set create_intersection ( in Set drugi_skup ) ; Set create_difference ( in Set drugi_skup ) ; boolean is_subset_of ( in drugi_skup) ; boolean is_proper_subset_of ( in drugi_skup) ; boolean is_superset_of ( in drugi_skup) ; boolean is_proper_superset_of ( in drugi_skup ) ; }

2.8 Modeliranje stanja

Stanje pojavljivanja nekog tip a objekta iskazuje se preko vrednosti njegovih osobina. Postoje dve vrste osobina: atributi i veze . Atribut: Atributi nekog objekta se specifikuju preko tipova literala ili tipova objekta. Drugim reima, vrednost atributa moe da bude literal ili indentifikator nekog objekta. Primer definisanja atributa klase: interface Lice { attribute short starost ; attribute string ime ; attribute enum pol { muski, zenski } ; attribute Adresa kucna_adresa ; attribute set <string> telefon ; attribute Organizacija zaposlen ; ( pretpostavlja se da je definisan objekat Adresa i Organizacija) npr. struct Adresa { string grad, string ulica_i_broj } ;

Veze: ODMG podrava samo binarne veze ( relationship ) tj. veze izmeu dva tipa objekata. Veza se definie implicitno unutar opisa tipa objekta kao tzv. prelazna putanja ( travelsal path). Prelazna putanja se uvek deklarie u paru, u okviru deklaracije oba tipa koji su u vezi. Deklarie se, na primer, da radnik radi u preduzeu (u okviru tipa Radnik) i da preduzee zapoljava radnika (u okviru tipa Preduzee). injenica da ovakve dve deklaracije predstavljaju jednu vezu iskazuje se u ODL-u preko klauzule INVERSE . Primer deklarisanja veze: interface Radnik { .... relationship Preduzece radi inverse Preduzece : : zaposljava ; ....};

interface Preduzece { .... relationship set <Radnik> zaposljava inverse Radnik : : radi ; .... }; Kardinalnost veze se definie preko injenice da veza uzima kao vrednost jedan atomski objekat ( kardinalnost jedan ) ili neku njihovu kolekciju ( kardinalnost vie ). Objektni SUBP treba da ostvari integritet veze: ako je objekat koji uestvuje u vezi izbrisan iz baze tada se i svaka prelazna putanja prema tom objektu takoe brie. Veza u OMG-u je uvek dvosmerna. Pri implementaciji veze u nekom pridruenom jeziku veza se moe uiniti jednosmernom. Isto tako, kao to je ranije pokazano, atribut ije je vrednost indentifikator nekog objekta moe da poslui za iskaz jednosmernih veza.

2.9 Modelovanje ponaanja OPERACIJE

Ponaanje tipa predstavlja se skupom operacija. Sintaksa za specifikaciju operacije je : Specifik_oper : : tip_rezult naziv_oper ( lista_argum ) raises ( lista_naziv_izuzetka ) ; Lista_argum : : argument | argument, lista_argum argument : : parametar_argumenta specific_tipa_argumenta naziv_argumenta parameter_argumenta : : in | out | inout Lista_naziv_izuzetka : : naziv_izuzetka | naziv_izuzetka, lista_naziv_izuzetka ;

Primer operacije je : Boolean upisan_na_predmet ( in insinged short kurs ) raises ( nema_uslova , popunjen_broj );

2.10 Nasleivanje
U ODMG se definiu dve posebne vrste nasleivanja: 1. Nasleivanje ponaanja 2. Nasleivanje stanja Za nasleivanje ponaanja se koristi veza nadtip-podtip ( koja se ponekad naziva veza generalizacija-specijalizacija ili ISA veza ). Nadtip u nasleivanju ponaanja mora da bude interfejs. Za nasleivanje stanja koristi se specifina veza EXTENDS. U ovoj vezi izmeu klasa, podreena klasa nasleuje celokupno stanje i ponaanje klase koju proiruje. 1. Nasleivanje ponaanja Za nasleivanje ponaanja se koristi veza nadtip-podtip.

Primer: injenica da je Nastavnik podtip Radnika a asistent podtip Nastavnika oznaava se na sledei nain: interface Radnik { . . . specifikacija tipa Radnik . . . } interface Nastavnik : Radnik { . . . spec tipa Nastavnik . . . } interface Asistent : Nastavnik { . . . spec tipa Asistent . . . } class StalniRadnik : Radnik { . . .spec tipa StalniRadnik } class PrivremeniRadnik : Radnik { spec tipa PrivremeniRadnik } U podtipu se moe i redefinisati ponaanje specifikovano u nadtipu. Na pr. ako je u tipu Radnik specifikovana operacija ObraunZarade ista operacija se moe razliito implementirati za podtipove StalniRadnik i PrivremeniRadnik. Osobina da se ista operacija izvrava na razliit nain u zavisnosti od tipa objekta sa kojim se izvrava naziva se polimorfizam. U ODMG modelu podrano je viestruko nasleivanje ponaanja. Tada se, meutim moe desiti da dve ili vie nasleenih operacija imaju isti naziv, a razliiti broj i/ili tip argumenata. Da bi se ovaj problem izbegao nije dozvoljeno preoptereenje (overloading) imena operacije (davanje istih imena operacija razliitih tipova) u takvoj hijerarhiji nasleivanja. 2. Nasleivanje stanja ODMG model uvodi EXTENDS vezu za definisanje nasleivanja stanja. Na primer, class Lice { attribute string ime; attribute Date datumRodjenja; class ZaposlenoLice extends Lice:Radnik { attribute Date datumZaposljavanja; attribute Currency plata ; relationship Rukovodilac sef inverse Rukovodilac : : podredjeni ; } ; class Rukovodilac extends ZaposlenoLice { relationship set <ZaposlenoLice> podredjeni inverse ZaposlenoLice sef ; } ; Odnos tip-podtip (generalizacija-specijalizacija) u ODMG modelu se primenjuje samo na nasleivanje ponaanja. Zbog toga interfejs i klasa mogu biti podtipovi samo interfejsa. Interfejsi i klase ne mogu biti podtipovi klasa. Poto se interfejs ne moe instancirati, on ( slino apstraktnoj klasi u nekim OO jezicima ) slui samo za to da se iz njega naslede neke operacije. Poto se preko odnosa podtip/nadtip nasleuje samo ponaanje, ako se eli u podtipu isti atribut koji postoji u interfejsu koji je nadtip, on se u podtipu mora kopirati.

grafik 2.10.1 nasleivanje UML notacija

Opseg tipa je skup svih instanci datog tipa u okviru posmatrane baze podataka. Ako je neki objekat instanca tipa A, tada je on element opsega A. U konvencionalnim bazama podataka uvaju se sva pojavljivanja tipova definisanih u njima. U objektnim bazama , projektant moe da odlui da li e se opseg tipa uvati u bazi ili ne. Objektni SUBP treba da obezbedi ubacivanje i izbacivanje pojavljivanja u i iz opsega, kao i kreiranje indeksa. Mogue je definisati da jedan atribut ili vie atributa predstavljaju korisniki klju tipa. Klju slui za jedinstvenu identifikaciju, preko atributa definisanih u njegovoj specifikaciji, jednog pojavljivanja u opsegu tipa.
grafik 2.10.2jedinstvene oznake za prikaz eme BP u ODMG

Primer 1 Geometrijski oblici : interface GeometrijskiObjekat { attribute enum Oblik {Pravougao, Trougao, Krug} oblik; attribute struct Tacka { short x, short y } referentna_tacka; float obim ( ); float povrsina ( ); void pomeri ( short x_pomeraj, short y_pomeraj ); void rotiraj (short ugao) ; } ; class Pravougaonik : Geometrijski oblik (extent pravougaonici ) { attribute struct Tacka {short x, short y } referentna_tacka; attribute short duzina ; attribute short sirina ; } ; Primer 2 Prikaz eme sa ODMG oznakama:

Primer 2 Prikaz eme sa UML oznakama

Primer 2 : class Kurs (extent kursevi key sif_kurs ) { attribute string sif_kurs; attribute string naziv; relationship set <Kurs> zahteva_se inverse Kurs : : zahtevan ; relationship set <Kurs> zahtevan inverse Kurs : : zahteva_se ; relationship set < Slusalac > slusaju inverse Slusalac : : slusa ; relationship Asistent drzi_vezb inverse Asistent: :vezba; relationship Profesor drzi_pred inverse Profesor : : predaje; Boolean drzi_se (in unsigned short semestar ) raises (vec_plan); Boolean izostavljen ( in unsigned short semestar) raises ( vec_izost ); } ;

class Radnik ( extent radnici key id ) { attribute short id ; attribute Plata mesecna_plata ; void ( ) zaposli; void otpusti ( ) raises ( nema_tog_radnika ) ; } ; class Plata { attribute float osnovna; attribute float prekovremena ; attribute float minuli_rad ; } ;

class Profesor extends Radnik ( extent radnici ) { attribute enum Zvanje { redovni, vanredni, docent } zvanje; relationship set <Kurs> predaje inverse Kurs : : drzi_pred ; } ; interface Slusalac { struct Adresa { string grad, string ulica_i_broj } ; attribute string ime; attribute string broj_indeksa; attribute Adresa adresa-stud; relationship set <Kurs> slusa inverse Kurs : : slusaju ; Boolean upisan_za_kurs ( in unsigned short Kurs) raises (nema_preduslove, popunjeno ); void ispisi ( in unsigned short Kurs ) raises ( nije_upisan ); } ;

class Asistent extends Radnik : Slusalac { attribute string ime; attribute string broj_indeksa; attribute Adresa adresa-stud; relationship set <Kurs> slusa inverse Kurs : : slusaju ; relationship set <Kurs> vezba inverse Kurs : : drzi_vezb; } ; class Student: Slusalac ( extent studenti ) { attribute string broj_indeksa ; attribute Adresa adresa-stud; relationship set <Kurs> slusa inverse Kurs : : slusaju ; } ;