sirotic kako koristiti ordbms

Kako (ne) koristiti

objektno-relacijske mogućnosti baze podataka

Zlatko Sirotić, dipl.ing.

Istra informatički inženjering d.o.o.

Pula

Sadržaj:

1. Uvod ............................................................................................................ 1

2. Tipovi podataka ........................................................................................... 2

3. Relacijski model podataka........................................................................... 5

4. Nasljeñivanje tipova .................................................................................... 8

5. Objektno-orijentirani (OODBMS)

i objektno-relacijski (ORDBMS) sustavi ...................................................... 11

6. Oracle tipovi podataka............................................................................... 15

7. Oracle objektno-relacijske tablice ............................................................. 20

8. Oracle objektne tablice .............................................................................. 34

9. Zaključak ................................................................................................... 45

Literatura ....................................................................................................... 46

1

1. Uvod

Relacijski model podataka teoretski je razradio E.F.Codd i prvi put ga opisao u radu "A

Relational Model of Data for Large Shared Data Banks", CACM 13, No. 6 (June 1970). Date

(2004, str. 170) navodi da je taj rad i danas vrijedan proučavanja, iako su, naravno, neke ideje u

meñuvremenu doživjele promjene, ali su te promjene više evolucijske nego revolucionarne.

Na temelju relacijskog modela, u desetljeću 1970.-1979. intenzivno se radilo na dizajniranju

RDBMS sustava - relacijskih sustava za upravljanje bazama podataka. Prvi ("laboratorijski")

sustav razvijen je 1974. u IBM-u (u kojem je tada radio i E.F.Codd), u okviru projekta System R.

U tom projektu stvoren je i jezik SEQUEL (Structured English Query Language), čije je ime

kasnije skraćeno na SQL. Taj je projekt potaknuo šire zanimanje za relacijski model i za jezik

SQL. Prvi komercijalni RDBMS sustav pod imenom Oracle ponudila je 1979. godine kompanija

Relational Software Inc. (osnovana je 1977., kasnije je preimenovana u Oracle Corporation).

RDBMS sustavi nisu prvi DBMS sustavi na tržištu. Prije njih postojali su hijerarhijski i

mrežni DBMS. Meñutim, Date ističe (2004, str. 27) da je neprimjereno govoriti o hijerarhijskom

i mrežnom modelu podataka, jer su, za razliku od relacijskog modela, hijerarhijski i mrežni

"model" nastali nakon pojave tržišnih hijerarhijskih i mrežnih DBMS sustava, pa su "modeli"

prikazivali ono što je bilo realizirano u tržišnim produktima.

Prvi objektno-orijentirani programski jezik (OOPL) Simula 67 nastao je daleke 1967. godine

(autori su mu Kristen Nygaard i Ole-Johan Dahl) – dakle, prije pojave relacijskog modela! Jezik

Simula 67 inspirirao je kreatore drugih OOPL jezika (npr. jezika Smalltalk, C++, Eiffel). Do

naglog razvoja OOPL jezika došlo je početkom i sredinom 80-tih godina prošlog stoljeća. Na

krilima uspjeha OOPL-a, kasnih 80-tih i ranih 90-tih godina prošlog stoljeća počeli su se

pojavljivati prvi objektni DBMS sustavi, a kasnih 90-tih prvi objektno-relacijski DBMS sustavi.

No, poznati znanstvenik na području relacijskog modela i relacijskih sustava C.J.Date

napisao je u svojoj knjizi "Database in Depth" (2005, str. 32): "After all, the whole point of an

"object/relational" system is precisely that we can have attribute values in relations that are of

arbitrary complexity. Perhaps a better way to say it is this: a proper object/relational system is

just a relational system with proper type support - which just means it's a proper relational

system, no more and no less.".

U ovom radu se prikazuju objektno-relacijske mogućnosti Oracle 11g (i 10g) DBMS-a i daju

se preporuke na koji bi se način te mogućnosti trebale koristiti (takoñer, na koji način se ne bi

trebale koristiti !) u skladu s Dateovim radovima.

2

2. Tipovi podataka

Da bi se prikazao relacijski model, a posebno onaj dio koji govori o strukturi podataka, vrlo

je važno definirati tip podataka. Prema (Date 2004, str. 136) tip podataka je imenovani skup

vrijednosti koje zadovoljavaju odreñena ograničenja nad tipom (type constraint). Svakom tipu

podataka pridruženi su operatori (read-only i update) za operiranje nad vrijednostima i

varijablama toga tipa. Date naglašava da je potrebno uvijek voditi brigu o razlici izmeñu

vrijednosti i varijable – za razliku od vrijednosti, varijabla se može mijenjati, tj. tekuća

vrijednost varijable može se zamijeniti nekom drugom vrijednošću. Vrijednosti i varijable uvijek

moraju biti odreñenog tipa.

Tipovi podataka mogu biti sistemski ili korisnički-definirani. Tipovi podataka mogu biti i

skalarni ili neskalarni - skalarni tip nema korisnički-vidljivih komponenti. Tip podataka mora

imati jednu (ili više) mogućih (potencijalnih) fizičkih reprezentacija (possible physical

representation). Fizička reprezentacija trebala bi korisniku biti sakrivena.

Date na puno mjesta u (2004) i (2005) navodi da je jezik SQL dosta loša realizacija

relacijskog jezika. Zbog lakšeg objašnjavanja relacijskog modela, Date je razvio vlastiti

relacijski jezik Tutorial D. Evo kako u jeziku Tutorial D izgleda definicija tipa POINT

(geometrijska točka u dvodimenzionalnom prostoru) sa dvije moguće fizičke reprezentacije:

TYPE POINT

POSSREP CARTESIAN {X RATIONAL, Y RATIONAL}

POSSREP POLAR {R RATIONAL, ALFA RATIONAL};

Date naglašava (2004, str. 116) da je tip POINT skalaran, iako moguće fizičke reprezentacije

imaju više komponenti (u ovom slučaju obje reprezentacije imaju po dvije komponente).

Evo kako u jeziku Tutorial D izgleda definicija ograničenja nad tipom:

TYPE WEIGHT

POSSREP {D DECIMAL (5, 1)

CONSTRAINT D > 0.0 AND D < 5000.0};

Osim tipova podataka, Date (2004, str 127) navodi potrebu za postojanjem generatora

tipova (type generators). Npr. u Tutorial D možemo napisati:

VAR SALES ARRAY INTEGER [[[[12]]]];

3

Varijabla SALES je tipa ARRAY INTEGER [[[[12]]]], a ARRAY je generator tipa. U ovom je

slučaju ARRAY sistemski generator tipa, ali generatori tipa mogu biti i korisnički-definirani.

Generatori tipa poznati su u literaturi i pod drugim imenima, npr. generički tipovi. Meyer (1997,

str. 318) ih naziva generičkim apstraktnim tipovima podataka, u Java jeziku zovu se generics, u

C++ jeziku zovu se template(s). Date (2004, str. 115) navodi da pojam apstraktni tip

podataka (ADT) nije adekvatan, jer na neki način upućuje da postoje i "ne-apstraktni" tipovi

podataka, a tip se, po njemu, uvijek treba razlikovati od moguće fizičke reprezentacije.

Ipak, držimo da Dateova definicija tipa podataka ima nekih dodirnih točaka sa definicijom

ADT-a koju prikazuje Meyer u (1997, poglavlje 6). Meyer kaže da apstraktni tipovi podataka

predstavljaju teorijsku (matematičku) osnovu za njegovu DBC metodu, pa i za cijeli Eiffel jezik

(koji je on dizajnirao) i da nam apstraktni tipovi podataka omogućavaju specificiranje

softverskog sustava na precizan i kompletan (koliko je to potrebno) način, ali bez

prespecifikacije (overspecification), tj. bez ulaženja u detalje softverskog rješenja. Drugim

riječima, ADT omogućavaju da se precizno definira što se želi dobiti, a da se ne mora ulaziti u

detalje kako to postići (aplikativni, a ne imperativni pristup). Meyer prikazuje da se definicija

ADT-a sastoji od definicije tipova, funkcija, aksioma i pretkondicija.

Npr. kompletna ADS specifikacija za stog (stack) izgleda ovako (Meyer, 1997, str. 139):

TYPES

STACK [[[[G]]]]

FUNCTIONS

put: STACK [[[[G]]]] X [[[[G]]]] →→→→ STACK [[[[G]]]]

remove: STACK [[[[G]]]] -/→→→→ STACK [[[[G]]]]

item: STACK [[[[G]]]] -/→→→→ [[[[G]]]]

empty: STACK [[[[G]]]] →→→→ BOOLEAN

make: STACK [[[[G]]]]

AXIOMS

For any x: G, s: STACK [[[[G]]]]

A1: item (put (s, x)) = x

A2: remove (put (s, x)) = s

A3: empty (make)

A4: not empty (put (s, x)

4

PRECONDITIONS

remove (s: STACK [[[[G]]]]) require not empty (s)

item (s: STACK [[[[G]]]]) require not empty (s)

Slično kao što Dateov Tutorial D jezik ima ograničenja nad tipovima podataka

(TYPE…CONSTRAINT), tako Meyer-ov ADT prikazuje ograničenja kroz aksiome i

pretkondicije.

Date naglašava (2004, str. 129-136) da, za razliku od jezika Tutorial D, SQL nema nešto

slično CONSTRAINT specifikaciji, pa bi SQL standard definicija skalarnog tipa WEIGHT bila:

CREATE TYPE weight AS DECIMAL (5, 1);

Dalje, SQL ne podržava niti specifikaciju moguće fizičke reprezentacije, već se u SQL-u

uvijek definira aktualna fizička reprezentacija. Zato će prije navedeni tip POINT, koji je u jeziku

Tutorial D bio skalarni tip, u SQL-u biti neskalarni (strukturirani) tip:

CREATE TYPE point AS (

x FLOAT,

y FLOAT

) NOT FINAL;

Napomena: prethodna naredba ima SQL standard sintaksu, a Oracle varijanta iza AS

obavezno mora imati riječ OBJECT.

5

3. Relacijski model podataka

Relacijski model je (matematički) temelj moderne tehnologije baza podataka. Kako kaže

Date (2005, str. 1-4) poznavanje osnova relacijskog modela važno je za svakog tko se

profesionalno bavi bazama podataka, jer profesionalci u svakoj disciplini moraju poznavati

temelje svog polja rada. Pritom su važni principi, a ne samo konkretni produkti i tehnologije,

jer se principi mijenjaju daleko sporije nego konkretni produkti i tehnologije.

Danas postoji mnoštvo knjiga koje objašnjavaju relacijski model. Npr. (Date, 2004,

8.izdanje) je fundamentalna (i voluminozna) knjiga koja se široko koristi na sveučilištima širom

svijeta i prodana je u preko 750.000 primjeraka. (Date, 2005) je relativno kratka (nešto preko

200 stranica) knjiga namijenjena profesionalcima koji bi htjeli svoje praktično znanje učvrstiti

teoretskim temeljima.

Relacijski model (Date, 2004, str. 109) bavi se strukturom podataka (data structure),

operacijama nad podacima (data manipulation) i integritetom podataka (data integrity).

Ovdje ćemo operacije nad podacima i integritet podataka samo ukratko prikazati. Nešto

detaljnije će biti prikazana struktura podataka, jer je to važno za razumijevanje Dateove kritike

nekih objektno-relacijskih aspekata SQL:1999 i SQL:2003 standarda (i konkretnih tržišnih

ORDBMS sustava koji to podržavaju).

Najvažniji koncepti u relacijskom modelu jesu relacijska vrijednost ili relacija i relacijska

varijabla. No, prvo treba definirati pojam (koristit ćemo engleski termin) tuple vrijednost

(tuple value) ili samo tuple.

(Date 2004, str. 141) definira tuple (value) kao skup ureñenih trojki u obliku <Ai, Ti, vi>,

gdje i poprima vrijednost 1..n, Ai je ime atributa, Ti je ime tipa, a vi je vrijednost (koja je tipa

Ti). Ureñeni par <Ai, Ti> je atribut tuple-a. Skup svih atributa je zaglavlje (heading) tuple-a.

Tuple tip (tuple type) je determiniran tim zaglavljem. Za razliku od tuple vrijednosti, tuple

varijable (tuple variables) nisu dio relacijskog modela, ali su tuple varijable važne za korištenje

u host programskom jeziku koji koristimo za pisanje aplikacije (Date 2004, str. 143).

Relacijska vrijednost (relational value) ili relacija (Date 2004, str. 146) sastoji se od

zaglavlja (heading) i tijela (body). Zaglavlje relacije je isto kao i zaglavlje tuple-a. Tijelo relacije

je skup svih tuple-a koji imaju isto zaglavlje. Relacijski tip (relational type) je determiniran

zaglavljem relacije.

Date (2004, str. 149) navodi neke važne osobine relacije, koje proizlaze iz činjenice da

(matematički) skup po definiciji nema ureñenja elemenata i nema duplih elemenata:

1. atributi su neureñeni u smislu lijevo-desno,

6

2. tuple-ovi su neureñeni u smislu gore-dolje,

3. relacija nema duplih tuple-ova.

Za razliku od prethodno navedenih pojmova relacija, tuple i atribut, SQL koristi pojmove

tablica, redak i stupac, ali ti pojmovi nisu (potpuno) ekvivalentni. Npr., za razliku od prethodno

navedenih osobina relacije, SQL tablica ima ureñene stupce, ima ureñene retke i može imati

duple retke. Date naročito kritizira ovo zadnje.

Osim prethodnog, Date (2004, str. 149) naglašava da su relacije uvijek u 1.normalnoj formi,

tj. (suprotno onome što smo uobičajeno učili) vrijednosti u atributima relacije mogu biti druge

relacije – to su tzv. RVA (relational-valued attributes). No, to ne znači da Date preporuča

takav dizajn relacija – uglavnom preporuča upravo suprotno (2005, str. 143), ali činjenica je da

relacijski model to dozvoljava.

Osim relacija (relacijskih vrijednosti), relacijski model čine i relacijske varijable ili relvar.

Date ih (2004, str. 156) dijeli u bazne relvar-e i virtualne relvar-e ili poglede (view). U jeziku

Tutorial D sintaksa za deifniranje baznog relvar-a je sljedeća:

VAR <relvar name>

BASE <relation type>

<candidate key def list>

[[[[<foreign key def list>]]]]

SQL koristi isti termin tablica i za "tablične vrijednosti" i za "tablične varijable" (Date 2004,

str. 163).

Osim strukture podataka, relacijski model definira i operacije nad podacima, bilo kroz

relacijsku algebru, bilo kroz njoj ekvivalentan relacijski račun, ili kroz račun domena (Date

2004, poglavlje 7 i 8), (Radovan 1993, poglavlje 5).

Što se tiče SQL-a Date (2004, str. 231) napominje da SQL nije baziran niti na relacijskoj

algebri, niti na relacijskom računu, već malo na jednome, malo na drugome (a malo ni na

jednom, ni na drugom). Dakle, nikako ne stoji da "relacijski model = SQL". No, Date je svjestan

(2005, str. 175-176) da se SQL ne može tek tako izbaciti (on vidi SQL kao database COBOL),

pa preporuča da se SQL izgradi na temelju (on top) nekog pravog relacijskog jezika i da se,

naravno, korisnicima (programerima ili krajnjim korisnicima) dozvoli upotreba (uz SQL) i tog

pravog relacijskog jezika.

Treći dio relacijskog modela, integritet podataka, najviše je zanemaren od strane

proizvoñača RDBMS sustava, ali je (Date 2004, str. 164) doživio i najveće (evolucijske, ne

7

revolucionarne) promjene u okviru relacijskog modela. Integritetna ograničenja ili samo

ograničenja (constraints) Date (2004, str 266) dijeli u 4 kategorije:

1. ograničenja na razini baze,

2. ograničenja na razini relacijske varijable,

3. ograničenja na razini atributa,

4. ograničenja nad tipom (type constraint).

Današnji RDBMS sustavi uz deklarativna ograničenja: PK za primarni ključ, UK za

jedinstveni ključ, FK za strani ključ, CK za provjeru vrijednosti u jednom retku i NOT NULL

(što bi po Dateu trebalo biti obavezno) podržavaju i okidače (triggers). Okidači su u biti

procedure i mogu služiti i za druge namjene, a ne samo za očuvanje integriteta podataka. Date

preferira deklarativna ograničenja. To ne znači da je on protiv okidača – trebamo ih koristiti dok

nemamo (deklarativne) alternative. Date (2004, str 293) navodi da su u zadnje vrijeme

integritetna ograničenja ponovno postala zanimljiva – ovaj put pod imenom poslovna pravila

(business rules). Poslovna pravila su zapravo user-friendly (tj. manje formalan ili neakademski)

način govora o integritetu baze podataka. Date drži taj trend pozitivnim, te preporuča knjige koje

je napisao R.G.Ross, jedan od autoriteta na području poslovnih pravila. Dobra knjiga iz područja

poslovnih pravila je i Von Halle (2002).

Još je jedna Dateova napomena (2005, str. 122) vezana je za integritetna ograničenja - ona

ne bi trebala biti odgoñena (deferred), npr. odgoñena do pred kraj transakcije. Naime, za razliku

od uobičajenog mišljenja da je transakcija jedinica integriteta (u akronimu ACID - Atomicity,

Consistency, Isolation, Durability - to predstavlja Consistency), Date drži da bi naredba

(statement) trebala biti jedinica integriteta, pa integritetna ograničenja ne bi smjela biti

odgoñena.

Što se tiče teorije dizajna baze podataka (database design theory), koju čine prije svega

pravila za normalizaciju podataka, Date joj posvećuje dosta prostora u (2004, poglavlja 11-

14) i (2005, poglavlje 7), ali u (2005, str. 136) navodi da teorija dizajna baze podataka nije dio

relacijskog modela, već da je ona posebna teorija temeljena (on top) na relacijskom modelu.

Vezano za normalizaciju podataka, Date navodi (2004, str. 704-709) da se u području

skladišta podataka često koriste zvjezdaste sheme (star schema) koje po njegovom mišljenju

imaju dosta problema, izmeñu ostalog i problema sa normalizacijom. Date ističe (kao negativnu)

preporuku "odoli normalizaciji" koju npr. u svojoj knjizi (Kimball, 2002) navodi jedan od

autoriteta na području skladišta podataka.

8

4. Nasljeñivanje tipova

Nasljeñivanje tipova (type inheritance) ili nasljeñivanje klasa svakako je važno za

objektno-orijentirane programske jezike i za objektne DBMS sustave, ali kako tvrdi Date - i za

relacijski model i za relacijske DBMS sustave.

Kod relacijskog modela Date (2004, str. 609) navodi da nas zanima ono što se inače naziva

nasljeñivanje domena, što je isto što i nasljeñivanje tipova (podataka), jer su po njemu

domena (termin koji se nekad često koristio u okviru relacijskog modela) i tip jedno te isto.

Dakle, vrijedi "domena = tip".

S druge strane, Date smatra i da su tip i klasa jedno te isto. B.Meyer, autoritet na području

OOPL-a slaže se da je klasa (i) tip, ali je i modul (1997, str. 170): "U pristupu koji nije

objektno orijentiran, koncepti modula i klase jasno su odvojeni. Najvažnije svojstvo pojma klasa

je da obuhvaća oba koncepta, stapajući ih u jednu lingvističku tvorevinu. Klasa je modul, ili

jedinica dekompozicije softvera. Meñutim, klasa je takoñer i tip (ili, u slučajevima u kojima

učestvuje generičnost, uzorak tipa).". Dakle, vrijedi "klasa = tip = modul". Napomenimo da je

u prethodnom citatu Meyer koristio izraz uzorak (pattern) tipa za ono što Date naziva

generator tipa.

Za razliku od nasljeñivanja tipova (nasljeñivanja domena) što smatra korisnim, Date (2004,

str. 609) navodi da je skeptičan prema ideji nasljeñivanja tablica, tj. postojanja (kako ih SQL

standard naziva) podtablica i nadtablica (subtables, supertables), s osobinom da podtablica

nasljeñuje sve stupce nadtablice i dodaje nove.

U jeziku Tutorial D, ovako se prikazuje hijerarhija tipova PLANE_FIGURE, ELLIPSE,

CIRCLE:

TYPE PLANE_FIGURE …;

TYPE ELLIPSE IS PLANE_FIGURE

POSSREP {

A LENGTH,

B LENGTH,

CTR POINT

CONSTRAINT A >= B

};

9

TYPE CIRCLE IS ELIPSE

CONSTRAINT

THE_A (ELLIPSE) = THE_B (ELLIPSE)

POSSREP {

R = THE_A (ELLIPSE)

CTR = THE_CTR (ELLIPSE)

};

Tip ELLIPSE je definiran kao pravi podtip tipa PLANE_FIGURE (PLANE_FIGURE je

pravi nadtip tipa ELLIPSE). Tip CIRCLE je podtip tipa ELLIPSE, ali mu je uvedeno

ograničenje da je poluos A jednaka poluosi B (tj. ima polumjer R).

Date (2004, str. 613) navodi da je pravi smisao nasljeñivanja u tome da ako je B podtip tipa

A, tada svi operatori (ili, drugim riječima: procedure, funkcije, metode) koji su primjenjivi na tip

A istovremeno primjenjivi i na tip B. Dakle, parametri (u drugoj terminologiji - formalni

parametri) operatora mogu biti jednog deklariranog tipa, a argumenti (u drugoj terminologiji

– aktualni parametri) kod poziva operatora mogu biti ili deklariranog tipa, ili njegovog podtipa.

Kaže se (Date 2004, str. 615) da je operator polimorfan. Meñutim, u ovom slučaju govorimo o

tzv. inkluzijskom polimorfizmu, a postoji i polimorfizam sa preopterećenjem (overloading)

operatora, kod kojeg dva ili više operatora imaju isto ime i različite parametre. Meñutim, kada se

govori o nasljeñivanja tipova (ili nasljeñivanju klasa) pod pojmom polimorfizam misli se na

inkluzijski polimorfizam.

Slično kao kod parametara i argumenata operatora, polimorfnost se manifestira i kod rada sa

varijablama. Npr. varijabli E čiji je deklarirani tip ELLIPSE može se pridružiti varijabla C čiji je

deklarirani tip CIRCLE. Meyer (1997, str. 467) takvo pridruživanje naziva polimorfno

pridruživanje.

Kod nasljeñivanja tipova, podtip može imati specifičnu implementacijsku verziju odreñenog

operatora. U toku poziva operatora, sistem će sam pozvati odgovarajuću verziju operatora (Date

2004, str. 616), na temelju run-time vezivanja (run-time binding) ili (drugi naziv) dinamičkog

vezivanja.

Vezano za nasljeñivanje klasa, Meyer (1997, str. 494) naglašava dvojako značenje

nasljeñivanja, koje proizlazi iz dvojne uloge klase – kao tipa i kao modula. Sa stanovišta modula,

najvažnija je prednost nasljeñivanja u tome da modul može biti istovremeno i zatvoren i otvoren

za mijenjanje (princip otvoren-zatvoren). Naime, metode nadklase mogu biti zatvorene za

10

mijenjanje, ali možemo napraviti podklasu u kojoj ćemo nadjačati (Meyer kaže redefinirati)

neku metodu i time je modul postao otvoren.

Navedimo sada analogan primjer definiranja hijerarhije tipova po SQL standardu (bez

definiranja operatora):

CREATE TYPE plane_figure

NOT INSTANTIABLE NOT FINAL;

CREATE TYPE ellipse UNDER plane_figure AS (

a LENGTH,

b LENGTH,

ctr POINT

) INSTANTIABLE NOT FINAL;

CREATE TYPE circle UNDER ellipse AS (

r LENGTH

) INSTANTIABLE NOT FINAL;

Kako je rečeno i prije, za razliku od jezika Tutorial D, SQL ne podržava ograničenja tipa i

moguće fizičke reprezentacije. Zbog toga u SQL-u tip ELLIPSE ima tri atributa (što je u redu),

ali podtip CIRCLE ima četiri atributa, a ne dva, koliko bi ih trebao imati. Naravno, atributi a, b, i

r u podtipu CIRCLE morali bi imati uvijek jednaku vrijednost, inače dobijamo "ne-okrugli

krug".

Možemo primijetiti da je ovaj nedostatak SQL jezika u odnosu na Tutorial D sličan

nedostatku DBC metode (posebno nedostatku invarijanti klase) u OOPL jezicima (npr.) C++ i

Java u odnosu na jezik Eiffel (koji podržava DBC).

11

5. Objektno-orijentirani (OODBMS)

i objektno-relacijski (ORDBMS) sustavi

Date (2004, str. 813) navodi kako se kasnih 80-tih i ranih 90-tih godina prošlog stoljeća

javio velik interes za objektno-orijentirane (ili kraće: objektne) DBMS sustave. Jedan od razloga

bio je taj što su SQL produkti tada sigurno bili neadekvatni za rješavanje nekih specifičnih

aplikacijskih područja kao što su npr. CAD/CAM i CIM sustavi, CASE sustavi, GIS sustavi,

specifične znanstvene i medicinske aplikacije, sustavi za pohranu i pretraživanje dokumenata i

sl.

S druge strane, tada su se u upotrebi već dokazali objektno-orijentirani programski jezici,

kao što su npr. Smaltalk ili C++. Objektni DBMS sustavi imaju svoj izvor u objektnim

programskim jezicima. Kao i objektni programski jezici, tako i objektni DBMS djeluju

obećavajuće u smislu povećavanja razine apstrakcije na kojoj se programira. Često se tvrdi da

je objektni pristup bliži realnom svijetu, tj. da su softverski objekti slika objekata realnog svijeta.

Meñutim, kako ističe Meyer (1997, str. 231): "Softverski sistem nije model stvarnosti; u

najboljem slučaju to je model modela nekog dijela stvarnosti. Sistem za praćenje pacijenata u

bolnici nije model bolnice, već … model modela podskupa bolničke stvarnosti.".

Treći razlog povećane potrebe (ili želje) za objektnim DBMS sustavom proizlazi takoñer

kao posljedica povećane upotrebe OOPL jezika. Naime, programerima je potreban neki sistem

perzistencije, koji će omogućiti da se tranzijentni objekti sačuvaju i nakon kraja izvršenja

programa, tj. da postanu perzistentni objekti. Naravno, kao mehanizam perzistencije mogu

poslužiti (i najčešće to jesu) relacijski DBMS sustavi. Meñutim, RDBMS sustavi nisu (ili nisu

bili) dobro prilagoñeni za pohranjivanje kompleksnih struktura objekata, što se naziva (Meyer

1997, str. 1050) neslaganje impedancije (impedance mismatch) izmeñu objektnog modela

podataka (objektnog) programskog jezika i relacijskog modela podataka (relacijskog) DBMS

sustava. Za rješavanje tog problema često se (Larman 2002, poglavlje 34) koriste (softverski)

okviri za perzistenciju (persistence framework), kao skup apstraktnih i konkretnih klasa koje

služe za realiziranje servisa za perzistenciju objekata.

Što se tiče navedena tri razloga za upotrebu ODBMS sustava umjesto RDBMS sustava,

može se reći da su današnji RDBMS sustavi puno prilagoñeniji za rad sa CAD/CAM i ostalim

prije navedenim specifičnim sustavima, jer današnji RDBMS sustavi podržavaju različite tipove

podataka koje prije nisu podržavali.

S druge strane, uvoñenjem korisnički definiranih tipova podataka i nasljeñivanja tipova,

RDBMS sustavi približili su se objektnim sustavima, što znači da je i kod njih povećana razina

12

apstrakcije, a u radu s OOPL jezicima smanjeno je (ali ne i potpuno uklonjeno) neslaganje

impedancije.

Meyer (1997, str. 1053) navodi da je minimalan skup osobina koje objektni DBMS sustav

treba imati sljedeći: treba imati one osobine koje ima (relacijska) baza podataka, treba podržavati

učahurivanje, identitet objekata i reference. Meyer nasljeñivanje (jednostruko ili višestruko)

drži dodatnom, korisnom, ali ne i nužnom osobinom. Osim nasljeñivanja, Meyer kao dodatne

mogućnosti navodi: praćenje verzija objekata, praćenje verzija klasa i evolucija sheme,

dugačke transakcije, zaključavanje, upite. Blaha i Premerlani (1998, poglavlje 15) ne navodi

opće osobine koje treba imati ODBMS sustav, već navodi osobine produkta ObjectStore. Meyer

(1997, str. 1056-1057) ukratko opisuje ODBMS sustave Matisse i Versant.

Zanimljivo je napomenuti da informativno-propagandni materijali firme Matisse Software

(www.matisse.com) naglašavaju kako njihov DBMS sustav Matisse predstavlja "Object-SQL

Database" (na početnoj web stranici piše da je "Post-Relational SQL Database"). U materijalima

ističu da je greška ranih ODBMS sustava upravo u tome što perzistenciju objekata omogućavaju

na "prelagan" (tj. nekontroliran) način, te da nijedan DBMS sustav ne može biti uspješan ako ne

podržava SQL, i to u samoj jezgri (kernel) DBMS sustava. Ističu kako je njihovo rješenje, tj.

objektna-SQL baza, fuzija najboljeg iz oba svijeta – lakoće objektnog razvoja i sveprisutnosti

SQL jezika. Možemo primijetiti da se proizvoñači RDBMS i ODBMS sustava sve više trude da

svoje sustave naprave kao hibridne.

Što se tiče ODBMS sustava, postojala je organizacija za njihovu standardizaciju – Object

Data Management Group (ODMG), u kojoj su se nalazili manje-više svi proizvoñači ODBMS

sustava. ODMG je napravio standard poznat kao ODMG Object Model, čija je zadnja verzija

3.0 napravljena 2001. godine. ODMG 3.0 definira Object Model, Object Definition Language

(ODL), Object Query Language (OQL), ali ne definira nešto kao "Object Manipulation

Language", već se manipulacija objektima radi sa programskim jezicima za koje ODMG

standard pruža podršku vezivanja jezika (language bindings): C++, Smalltalk i Java.

Organizacija ODMG se rasformirala, a pravo na njihov standard preuzela je poznata organizacija

(sličnog naziva) Object Management Group (OMG), koja je 2006. objavila da će napraviti

"4th generation" standard za objektne baze podataka.

Treba napomenuti da postoje i razmišljanja o tome da ODBMS (pa ni RDBMS) sustavi

uopće nisu potrebni, jer se perzistencija može učiniti dovoljno snažnom već u okviru odreñenog

OOPL jezika. Npr. kod jezika Java poznat je standard Java Data Objects (JDO). Larman (2002,

str. 537) mišljenja je da "tehnologije kao one bazirane na JDO specifikaciji nude parcijalna

rješenja". Meyer (1997, str. 1058-1060) navodi jedan mehanizam (u jeziku Eiffel) koji bi

13

omogućio da svi objekti budu predefinirani kao perzistentni, a da tranzijentni objekti budu

izuzetak. Po njemu, taj mehanizam nalazi potporu u rastućoj dostupnosti 64-bitnog virtualnog

adresnog prostora. No, ipak kaže: "Sve je ovo spekulativno i ne pruža nikakav dokaz da bi se

trebalo odreći tradicionalnog pojma baze podataka.".

Prije desetak godina, skoro svi proizvoñači relacijskih DBMS sustava izašli su na tržište sa

objektno-relacijskim nadogradnjama (ili opcijama). Kako navodi Date (2004, str. 859) jasna

ideja bila je da njihovi proizvodi trebaju podržavati i objektne i relacijske mogućnosti, tj.

proizvodi predstavljaju približavanje izmeñu te dvije tehnologije. Dateovo strogo mišljenje je da

to približavanje treba ići tako da se zadrže temelji relacijskog modela, koji bi trebao evoluirati

tako da uključi dobre osobine objektnih sustava.

Date je mišljenja da je najvažnija (i možda jedina) dobra ideja koja je uvedena u relacijski

model iz objektnog svijeta – odgovarajuća podrška za tipove podataka. Druga dobra ideja

(ako se računa odvojeno) je podrška za nasljeñivanje tipova. Zapravo, riječ je o tome da

RDBMS sustavi konačno implementiraju nešto što je u relacijskom modelu davno predviñeno, a

to su domene, koje jednostavno možemo zvati tipovi podataka. Relacijski sustav koji na pravilan

način podržava domene (tj. tipove) može podržavati sve one vrste podataka za koje se prije

koristilo ODBMS sustave (CAD/CAM podaci, GIS podaci, multimedija, biomedicinski podaci i

dr.).

Vezano za približavanje izmeñu objekata i relacija, Date (2004, str 862) postavlja jedno

krucijalno pitanje: "Koji je koncept u relacijskom svijetu blizanac konceptu (objektna) klasa

u objektnom svijetu?". Date nudi dva moguća odgovora:

1. domena = (objektna) klasa,

2. relvar (relacijska varijabla) = klasa.

Date kaže da je jedini ispravan odgovor prvi, jer i domena i klasa su zapravo tip. Budući je

relvar varijabla, a varijable nisu tipovi, drugi odgovor mora biti očito pogrešan.

No, neki produkti polaze od tog pogrešnog odgovora i takvu grešku Date naziva (slobodno

prevedeno) prva gruba greška (The First Great Blunder). Iz te greške proizlaze mnoge

posljedice pa i ta da se u nekim produktima javlja koncept nadtablice i podtablice (gdje se

podtablica kreira kao podklasa nadtablice). Date (2004, str. 869) pretpostavlja da prva gruba

greška ima korijenje u nedostatku konsenzusa oko značenja nekih temeljnih termina u objektnom

svijetu, a naročito ističe upotrebu termina objekt u "objektnoj analizi i dizajnu" ili "objektnom

14

modeliranju", gdje zapravo nije riječ o objektima, nego o onome što se u području baza podataka

obično naziva entitet.

Druga gruba greška (Date 2004, str. 870) je miješanje pokazivača (pointer) i relacija.

Pokazivači pokazuju na varijable, a ne na vrijednosti. Ali, ako relacijska varijabla R1 ima atribut

čija je vrijednost pokazivač u relacijsku varijablu R2, tada ti pokazivači pokazuju na tuple

varijablu, a pojam tuple varijable ne postoji u relacijskom modelu jer se relacijski model

(slobodno rečeno) bavi relacijama (relacijskim vrijednostima) koje su skupovi tuple vrijednosti,

koji su pak skupovi skalarnih vrijednosti. Date pretpostavlja da druga gruba greška dolazi od

toga što objektni sustavi i objektni jezici uključuju pokazivače kao neku formu objektnog ID-a,

pa se onda ideja o miješanju pokazivača i relacija javila iz želje da relacijski sustavi budu što

više "object-like".

15

6. Oracle tipovi podataka

Oracle baza 11g (i prethodne verzije) podržava prije svega sistemski definirane ili

ugrañene (built-in) tipove podataka (Oracle ih naziva native), koji mogu biti skalarni

("jednostavni") ili neskalarni. Slijedi kratak popis nekih sistemski definiranih skalarnih tipova

podataka. Znakovni tipovi podataka su (izmeñu ostalih) CHAR za fiksan broj znakova

(maksimum je 2000), VARCHAR2 za varijabilan broj znakova (maksimum je 4000), CLOB

(Character Large OBject – zapravo, nije riječ o objektu) za veliki broj znakova (4 GB i više).

Najvažniji numerički tip podataka je NUMERIC. Najvažniji datumski, a istovremeno i

vremenski tip podataka je DATE, koji služi za pamćenje podataka o stoljeću, godini, mjesecu,

danu, satu, minuti i sekundi. Ne postoji tip podataka BOOLEAN (odnosno, postoji u PL/SQL-u,

ali ne i u SQL-u), kojega Date (2005, str. 165) smatra fundamentalnim tipom podataka.

Od neskalarnih sistemski definiranih tipova podataka vjerojatno je najzanimljiviji

XMLTYPE (uveden je u bazi 9i), koji služi za pohranu XML dokumenata i manipulaciju njima

pomoću brojnih ugrañenih metoda (operatora). Iako je riječ o sistemskom tipu podataka, on se

koristi na sličan način kao korisnički definirani (user-defined) tipovi podataka. Osim iz SQL-a,

XMLTYPE može se koristiti i iz PL/SQL-a i Jave: programske varijable, parametri procedure,

povratne vrijednosti funkcije i sl. - mogu biti tipa XMLTYPE.

Oracle je 1997. godine objavio 8.0 verziju baze i nazvao ju objektno-relacijskom. U skladu s

tim nadopunjeni su i SQL i Oracle specifični programski jezik PL/SQL. U bazu 8.0 uvedeni su

novi tipovi podataka poznati kao kolekcije (collection; termin se često koristi neprecizno, jer se

ponekad misli na tip, a ponekad na objekt tog tipa), kao i objektni tip (object type) za koji

možemo reći da je ekvivalent OOPL klasi (napomena: vjerojatno bi pravilnije bilo reći tip

objekta, ali zbog lakšeg razumijevanja kod upotrebe tog izraza u rečenicama, koristit ćemo izraz

objektni tip – želimo dati naglasak na pojam tip, a ne na pojam objekt). Kolekcije se u Oracle

literaturi obično navode zajedno sa objektnim tipom, tj. kolekcije se smatraju objektno-

relacijskim mogućnostima (značajkama). Zanimljivo je da su u bazi 8.0 te objektno-relacijske

mogućnosti činile opciju koja se posebno prodavala, ali već u bazi 8i Oracle ih je ugradio u

standardne (bez posebne doplate) mogućnosti Oracle baze.

Oracle SQL poznaje dva tipa-kolekcije: tip-ugniježñena tablica (nested table type;

uobičajeni ne-Oracle pojam je MULTISET, a mi ćemo ga nazivati tablični tip) i tip-niz

(VARRAY type). VARRAY je skraćenica za variable-sized array, ali se definirani broj

elemenata može naknadno mijenjati tek od baze 10g. Jezik PL/SQL poznaje još jednu vrstu

16

kolekcije – asocijativne nizove (associative array), koji imaju porijeklo još iz baze Oracle 7, kada

su se zvali PL/SQL tablice.

Primjer definiranja tabličnog tipa:

CREATE TYPE list_of_names AS TABLE OF VARCHAR2(100)

/

Primjer definiranja tipa-niza sa 10 elemenata, te povećanja broja elemenata (od baze 10g) na

20:

CREATE TYPE array_of_names AS VARRAY(10) OF VARCHAR2(100)

/

ALTER TYPE array_of_names MODIFY LIMIT 20 CASCADE

/

Nažalost, pojedinačnim elementima VARRAY tipa ne može se pristupiti kroz SQL, već

samo kroz PL/SQL. Zapravo, jedno (naše) rješenje postoji, ali je poprilično složeno – tekst

"Updating the Individual Elements of a Varray" na adresi

www.revealnet.com/pipelines/plsql/tips04.htm#JANUARY.

Objektni tip pojavio se u bazi 8.0, ali u bazi 8i Oracle je stavio naglasak na ugrañivanje JVM

(Java Virtual Machine) u bazu - otuda potječe ono "i" (kao Internet) u nazivu 8i. Zanimljivo je

pročitati (Feuerstein 2005, str. 982) da se u vrijeme pojave baze 8i smatralo da se programski

jezik PL/SQL neće nadograñivati sa novim objektnim mogućnostima. Meñutim, objektni tip je u

bazi 9i (i u SQL-u i u PL/SQL-u) dobio neke važne objektne mogućnosti kao što su

nasljeñivanje, nadjačavanje metoda, polimorfizam. U bazi 10g uvedene su operacije za

usporedbu tabličnih tipova i operacije za manipulaciju nad njima (MULTISET operacije, npr.

MULTISET UNION, MULTISET INTERSECT i sl.).

SQL i PL/SQL objektni tip se (barem za sada) može definirati samo kao objekt baze (u

odreñenoj shemi). Objektni tip ima dva dijela - specifikaciju i tijelo. U specifikaciji se

deklariraju atributi i metode (funkcije i procedure), a u tijelu se metode (deklarirane u

specifikaciji) u potpunosti definiraju. Metode mogu biti statične (STATIC) tj. metode koje se ne

primjenjuju na odreñeni objekt, već na cijelu klasu, te MEMBER metode. U sljedećem primjeru

prikazan je objektni tip (samo njegova specifikacija) koji ima dva atributa i tri (MEMBER)

metode, od kojih je jedna metoda konstruktor (mora se zvati isto kao objektni tip):

17

CREATE OR REPLACE TYPE osoba AS OBJECT (

ime VARCHAR2 (20),

tezina_u_kg NUMBER,

CONSTRUCTOR FUNCTION osoba (

p_ime VARCHAR2,

p_tezina_u_kg NUMBER

) RETURN SELF AS RESULT,

MEMBER PROCEDURE prikazi_podatke,

MEMBER FUNCTION tezina_u_funtama RETURN NUMBER

) NOT FINAL

/

Budući da prethodni objektni tip nije finalan (označen je sa NOT FINAL), možemo

napraviti podklasu i nadjačati bilo koju njenu MEMBER metodu (Oracle STATIC metode ne

mogu se nadjačati, već sakriti), jer je default kod metoda NOT FINAL. Npr. u nastavku radimo

podklasu prethodne klase i u njoj nadjačavamo metodu PRIKAZI_PODATKE, te uvodimo novu

metodu JEDI_MALO_I_DOBRO, koja se dalje ne može nadjačati, jer je označena sa FINAL (a

podklasa je označena sa NOT FINAL, kako bi se mogle raditi i njene podklase):

CREATE OR REPLACE TYPE gurman UNDER osoba (

omiljena_hrana VARCHAR2(20),

CONSTRUCTOR FUNCTION gurman (

p_ime VARCHAR2,

p_tezina_u_kg NUMBER,

p_omiljena_hrana VARCHAR2

) RETURN SELF AS RESULT,

OVERRIDING MEMBER PROCEDURE prikazi_podatke,

FINAL MEMBER PROCEDURE jedi_malo_i_dobro

) NOT FINAL

/

18

Oracle objektni tipovi mogu se koristiti za kreiranje perzistentnih objekata (kroz SQL) i za

kreiranje tranzijentnih objekata (kroz PL/SQL). Nažalost, za sada Oracle PL/SQL ne podržava

reference (ili pokazivače) na tranzijentne objekte (to bi vjerojatno uvelo dodatnu komplikaciju

dizajnerima PL/SQL-a – potrebu za automatskim sakupljanjem smeća, jer ne želimo da

programer mora sam, kao u jeziku C++, voditi brigu o brisanju nepotrebnih objekata). Kao

primjer rada sa tranzijentnim objektima može se pogledati naš tekst "The Template Design

Pattern in PL/SQL" na web adresi www.revealnet.com/pipelines/plsql/tips06.htm#OCTOBER).

Jedan drugi naš tekst pokazuje pak moguće greške kod istovremene upotrebe nadjačavanja i

preopterećenja metoda - "Dynamic Method Dispatch and Method Overloading in a Subtype" na

web adresi www.quest-pipelines.com/newsletter-v4/0503_C.htm.

Za razliku od referenci na tranzijentne objekte, koje (za sada) ne podržava, Oracle podržava

reference na tranzijentne objekte, i to ne samo unutar PL/SQL jezika, već i unutar samog SQL-a.

To znači da jedna relacija može imati reference na retke druge relacije – to je ono što Date

smatra (drugom) grubom greškom. Referentni tip (REF) na neki drugi tip ne definira se u bazi

direktno (pomoću CREATE TYPE naredbe), već u okviru neke druge definicije, npr. kao u

sljedećem primjeru (REF dept_type):

CREATE TYPE emp_type AS OBJECT (

empno NUMBER,

ename VARCHAR2(20),

deptno REF dept_type

)

/

U bazi 9i Oracle je uveo i specijalne tipove podataka ANYDATA, ANYDATASET i

ANYTYPE. ANYDATA je samoopisujući tip (self-describing) i podržava refleksivnost (kroz

odgovarajući API). ANYDATA tip omogućava da stupci (tablice) tog tipa ili (PL/SQL) varijable

tog tipa sadrže podatak bilo kojeg sistemski ili korisnički definiranog tipa. ANYDATASET tip je

sličan, ali omogućava pohranu skupa podataka (a ne jednog podatka) bilo kojeg tipa. ANYTYPE

je tip podataka koji sadrži opis drugog (bilo kojeg) tipa, bez obzira da li je taj drugi tip podataka

perzistentan tip (definiran kroz SQL), ili je čak tranzijentan tip, tj. tip podataka koji se generira

dinamički za vrijeme izvršavanja (PL/SQL) programa.

ANYDATA tipovi omogućavaju veliku fleksibilnost u programiranju, ali su zbog svoje

fleksibilnosti i teški za razumijevanje, pa su programi koji ih koriste teško čitljivi i mogu biti

19

pogrešno napisani, a greška se pokaže tek kod izvoñenja. Ukoliko nam zaista ne treba

refleksivno programiranje, bolje ih je ne koristiti. Jedan (naš) primjer korištenja ANYDATA i

ANYTYPE tipova podataka je "Inserting a 'Generic Record Type' Using

ANYDATA/ANYTYPE Types" na web adresi

www.revealnet.com/pipelines/plsql/tips04.htm#MARCH.

20

7. Oracle objektno-relacijske tablice

Imenom objektne-relacijske tablice (object-relational tables) možemo nazvati one tablice

kod kojih je jedan ili više stupaca (ali ne redak kao cjelina) temeljen na objektnom tipu ili tipu-

kolekciji. Date smatra da su takve vrste tablica sasvim prihvatljive i da su to zapravo relacijske

tablice.

U sljedećem primjeru kreiramo tip ADRESA_T i koristimo ga za definiciju stupca

ADRESA u objektno-relacijskoj tablici OSOBA:

CREATE TYPE adresa_t AS OBJECT (

grad VARCHAR2(20),

ulica VARCHAR2(30)

)

/

CREATE TABLE osoba (

ime VARCHAR2(40) PRIMARY KEY,

adresa adresa_t

)

/

Kada iz Oracle alata SQL+ pogledamo pomoću naredbe DESCRIBE opis tablice OSOBA,

vidjet ćemo da ona ima dva stupca:

Name Type

------ ------------

IME VARCHAR2(40)

ADRESA ADRESA_T

Meñutim, tablica OSOBA zapravo ima 4 stupca: skalarni stupac IME, dva stupca koja

predstavljaju komponente stupca-objekta ADRESA (njihova imena počinju sa SYS), te poseban

stupac (dužine 1 byte), koji se zove kao stupac-objekt (u ovom slučaju ADRESA) - njega Oracle

koristi za interne potrebe, kao oznaku tipa:

21

SELECT segcol#, name, segcollength, type#

FROM sys.col$

WHERE obj# =

(SELECT object_id

FROM user_objects

WHERE object_name = 'OSOBA'

)

ORDER BY segcol#;

SEGCOL# NAME SEGCOLLENGTH TYPE#

---------- --------------------------- ------------ ----------

1 IME 40 1

2 ADRESA 1 121

3 SYS_NC00003$ 20 1

4 SYS_NC00004$ 30 1

Unos i izmjena redaka nad tablicom OSOBA prikazani su u nastavku. Primijetimo da se kod

unosa vrijednosti neskalarnog stupca ADRESA mora pozvati (default) konstruktor ADRESA_T,

a kod izmjene komponente neskalarnog tipa mora se koristiti alias tablice, dok se kod izmjene

kompletnog skalarnog stupca opet koristi konstruktor (a alias tablice nije nužan):

INSERT INTO osoba VALUES (

'Ana',

adresa_t ('G1', 'U1')

);

UPDATE osoba o

SET o.adresa.ulica = 'U2'

WHERE ime = 'Ana';

UPDATE osoba

SET adresa = adresa_t ('G2', 'U3')

WHERE ime = 'Ana';

22

Slijede dvije varijante SELECT naredbe nad tablicom OSOBA – prva selektira neskalarni

stupac kao cjelinu, a druga selektira komponente skalarnog stupca (u drugom slučaju je nužan

alias tablice):

SELECT ime, adresa

FROM osoba;

IME ADRESA(GRAD, ULICA)

---- -----------------------

Ana ADRESA_T('G2', 'U3')

SELECT ime,

o.adresa.grad,

o.adresa.ulica

FROM osoba o;

IME ADRESA.GRAD ADRESA.ULICA

---- ----------- ------------

Ana G2 U3

Izbrišimo sada tablicu i tip, da nam ne smetaju u nastavku:

DROP TABLE osoba;

DROP TYPE adresa_t;

Prikažimo sada kako izgleda nasljeñivanje tipova podataka, nadjačavanje metoda i

polimorfizam kod objektno-relacijskih tablica. Prvo ćemo kreirati nadtip ADRESA_T:

CREATE TYPE adresa_t AS OBJECT (

grad VARCHAR2(20),

ulica VARCHAR2(30),

MEMBER FUNCTION adresa_f RETURN VARCHAR2

) NOT FINAL -- OBAVEZNO

/

23

CREATE TYPE BODY adresa_t AS

MEMBER FUNCTION adresa_f RETURN VARCHAR2 IS

BEGIN

RETURN 'Generalna adresa:' || grad || ' ' || ulica;

END;

END;

/

Kreirajmo sada tablicu OSOBA i unesimo jedan redak:



adresa adresa_t

);


'Ana',

adresa_t ('G1', 'U1')

);

Kreirajmo sada podtipove KUCNA_ADRESA_T i POSL_ADRESA_T, u kojima ćemo

dodati atribute i nadjačati metodu (funkciju) ADRESA_F:

CREATE TYPE kucna_adresa_t UNDER adresa_t (

dodatak1 VARCHAR2(11),

OVERRIDING MEMBER FUNCTION adresa_f RETURN VARCHAR2

);

/

CREATE TYPE BODY kucna_adresa_t AS

OVERRIDING MEMBER FUNCTION adresa_f RETURN VARCHAR2 IS

BEGIN

RETURN

'Kućna adresa:' || grad || ' ' || ulica || ' ' || dodatak1;

END;

END;

/

24

CREATE TYPE posl_adresa_t UNDER adresa_t (




OVERRIDING MEMBER FUNCTION adresa_f RETURN VARCHAR2

);

/

CREATE TYPE BODY posl_adresa_t AS

OVERRIDING MEMBER FUNCTION adresa_f RETURN VARCHAR2 IS

BEGIN

RETURN

'Poslovna adresa:' || grad || ' ' || ulica || ' ' ||

dodatak1 || ' ' || dodatak2 || ' ' || dodatak3;

END;

END;

/

Sada možemo unijeti retke sa konstruktorima podtipova KUCNA_ADRESA_T,

POSL_ADRESA_T, jer se tablica OSOBA automatski proširila sa 4 dodatna stupca (1 + 3):


FROM sys.col$

WHERE obj# =

(SELECT object_id

FROM user_objects

WHERE object_name = 'OSOBA'

)

ORDER BY segcol#;

25


---------- --------------------------- ------------ ----------

1 IME 40 1

2 ADRESA 256 121

3 SYS_NC00003$ 16 23

4 SYS_NC00004$ 20 1

5 SYS_NC00005$ 30 1

6 SYS_NC00006$ 11 1

7 SYS_NC00007$ 12 1

8 SYS_NC00008$ 13 1

9 SYS_NC00009$ 14 1


'Pero',

kucna_adresa_t ('G2', 'U2', 'D1')

);


'Mira',

posl_adresa_t ('G3', 'U3', 'D1', 'D2', 'D3')

);

Sada možemo propustiti dvije varijante SELECT naredbe – u prvoj se navode imena

stupaca, a u drugoj se navodi ime stupca i ime metode (funkcije). Vidimo da u drugom SELECT-

u moramo koristiti alias tablice i zagrade iza imena metode, iako (u ovom slučaju) metoda nema

parametara:

SELECT ime, adresa

FROM osoba;

IME ADRESA(GRAD, ULICA)

---- --------------------------

Ana ADRESA_T('G1', 'U1')

Pero KUCNA_ADRESA_T('G2', 'U2')

Mira POSL_ADRESA_T('G3', 'U3')

26

-- obavezne zagrade iza imena metode

-- (PL/SQL ima uniformni pristup, SQL ne)

SELECT ime, o.adresa.adresa_f()

FROM osoba o;

IME O.ADRESA.ADRESA_F()

---- ---------------------

Ana Generalna adresa:G1 U1

Pero Kućna adresa:G2 U2

Mira Poslovna adresa:G3 U3

Dalje - selekcija na retke kojima je adresa odreñenog tipa

-- samo tip kucna_adresa_t ili njegovi podtipovi

-- (sada ih nema)

SELECT ime, adresa

FROM osoba

WHERE adresa IS OF (kucna_adresa_t);

-- samo tip adresa_t ili njegovi podtipovi (sada su to svi)

SELECT ime, adresa

FROM osoba

WHERE adresa IS OF (adresa_t);

-- samo tip adresa_t, bez podtipova

SELECT ime, adresa

FROM osoba

WHERE adresa IS OF (ONLY adresa_t);

27

Kako prikazati samo odreñene atribute objektnog stupca (one koji odgovaraju

odreñenim atributima iz nadtipa adresa ili iz njegovih podtipova)?

Atribute koji odgovaraju atributima iz nadtipa adresa možemo lako prikazati:

SELECT ime, o.adresa.grad FROM osoba o;

IME ADRESA.GRAD

---------------------------------------- --------------------

Ana G1

Pero G2

Mira G3

Ali, ne možemo (direktno) prikazati atribute koji odgovaraju atributima podtipa:

SELECT ime, o.adresa.dodatak1

FROM osoba o;

ERROR at line 1: ORA-00904: "O"."ADRESA"."DODATAK1":

invalid identifier

Istina, moguće je navesti sistemsko ime stupca:

SELECT ime, SYS_NC00009$ FROM osoba;

No, "čišće" je koristiti TREAT ("object_column" AS "subtype"):

SELECT ime, TREAT (adresa AS posl_adresa_t).dodatak1

FROM osoba;

IME TREAT(ADRESA

---------------------------------------- ------------

Ana

Pero

Mira D1

Ili, prikažimo samo osobe koje imaju poslovnu adresu:

28

SELECT ime, TREAT (adresa AS posl_adresa_t).dodatak1

FROM osoba

WHERE adresa IS OF (posl_adresa_t);

IME TREAT(ADRESA

---------------------------------------- ------------

Mira D1

Kako raditi UPDATE objektnog stupca – cijelog ili pojedinih atributa?

Kako smo i prije vidjeli, lako je ažurirati cijeli stupac:

UPDATE osoba

SET adresa = adresa_t ('G2', 'U3')

WHERE ime = 'Ana';

Možemo ažurirati i atribute objektnog stupca koji odgovaraju atributima iz nadtipa adresa:

UPDATE osoba o

SET o.adresa.grad = 'G3'

WHERE ime = 'Ana';

Ali, ne možemo (direktno) ažurirati atribute koji odgovaraju atributima podtipa (npr.

podtipa posl_adresa_t). Napomenimo da u sljedećoj naredbi razlog greške nije taj što 'Ana' ima

generalnu adresu (tipa adresa_t) koja nema stupac dodatak1 – isto bi bilo sa 'Pero' i 'Mira', iako

njihove adrese (tipa kucna_adresa_t i posl_adresa_t) imaju taj stupac:

UPDATE osoba o

SET o.adresa.dodatak1 = 'D2'

WHERE ime = 'Ana';

SET o.adresa.dodatak1 = 'D2'

*

ERROR at line 2:

ORA-00904: "O"."ADRESA"."DODATAK1": invalid identifier

29

Istina, mogli bismo koristiti sistemska imena stupaca dodatak1 (napomena - imamo ih dva),

kao kod SELECT, ali to nije "čisto". No, za razliku od SELECT, kod UPDATE ne pomaže

TREAT:

UPDATE osoba o

SET TREAT (adresa AS posl_adresa_t).dodatak1 = 'D2'

WHERE ime = 'Ana';

SET TREAT (adresa AS posl_adresa_t).dodatak1 = 'D2'

*

ERROR at line 2:

ORA-00927: missing equal sign

Ali, ovo radi - UPDATE inline wiew:

UPDATE (SELECT TREAT (adresa AS posl_adresa_t).dodatak1 dod1

FROM osoba

WHERE ime = 'Ana'

)

SET dod1 = 'D2';

ili

UPDATE (SELECT ime,

TREAT (adresa AS posl_adresa_t).dodatak1 dod1

FROM osoba

)

SET dod1 = 'D2'

WHERE ime = 'Ana';

Nažalost, moramo primijetiti da smo u ovom konkretnom slučaju dobili

nekonzistentnost, iako u UPDATE nismo koristili sistemsko ime stupca (što nije "čisto").

Naime, 'Ana' sada ima napunjen stupac dodatak1, iako je njena adresa i dalje ostala tipa adresa_t,

a adresa_t nema taj stupac.

30

Kako napraviti INDEX ili CONSTRAINT nad atributima objektnog stupca?

Ne mora se koristiti "sistemsko ime" (u sljedećem poglavlju vidjet ćemo da ponekad

moramo, npr. kod FK i objektnih tablica, u nekim slučajevima), može i ovako:

CREATE INDEX dodatak3_i ON osoba

(TREAT (adresa AS posl_adresa_t).dodatak3);

Izbrišimo opet tablice i tipove, da nam ne smetaju u nastavku (to ćemo raditi i poslije):

DROP TABLE osoba;

DROP TYPE posl_adresa_t;

DROP TYPE kucna_adresa_t;

DROP TYPE adresa_t;

Pogledajmo sada kako bi izgledala tablica u kojoj je stupac TELEFONI deklariran kao

NIZ_TELEFONA_T (niz ima pet elemenata). Elementi niza u ovom slučaju su skalarne

vrijednosti, ali mogu biti i neskalarne. Primijetimo da kod INSERT naredbe nije nužno navesti

sve elemente niza (navedena su samo dva telefona):

CREATE TYPE niz_telefona_t AS VARRAY (5) OF VARCHAR2(20)

/



telefoni niz_telefona_t

)

/


'Mira',

niz_telefona_t ('12345', '54321')

);

DROP TABLE osoba;

DROP TYPE niz_telefona_t;

31

Kako smo već naveli u 6.poglavlju, pojedinačnim elementima VARRAY tipa ne može se

pristupiti kroz SQL (osim na vrlo složen način), već samo kroz PL/SQL. Zato u Oracle bazi nije

preporučljivo koristiti VARRAY tip za stupce tablice.

Na kraju, pogledajmo kako objektno-relacijska tablica OSOBA može imati stupac čija je

vrijednost neki skup redaka telefona. Za takav slučaj uobičajeno bi se reklo da tablica OSOBA

nije u 1.normalnoj formi, ali (kako smo vidjeli u 3.poglavlju) Date naglašava da ta tablica jeste

u 1.normalnoj formi ali je njen atribut TELEFONI tzv. RVA (relational-valued attribute).

Oracle to zove ugniježñena tablica (nested table):

CREATE TYPE telefon_t AS OBJECT (

vrsta VARCHAR(10),

broj VARCHAR2(20)

)

/

CREATE TYPE tablica_telefona_t AS TABLE OF telefon_t

/



telefoni tablica_telefona_t

) NESTED TABLE telefoni STORE AS telefoni_tab

/

Vidimo da se u stvarnosti stupac TELEFONI realizira kao odvojena tablica

TELEFONI_TAB. Interno, tablice-roditelj OSOBA i tablica-dijete TELEFONI_TAB imaju

dodatne stupce koji služe za njihovo povezivanje. No, kako kaže Date, nije važna interna

realizacija, već vanjski pogled (korisnika, uključujući i programera). Evo kako bi izgledao

INSERT nad tablicom OSOBA:

32


'Ana',

tablica_telefona_t (

telefon_t ('kućni', '123'),

telefon_t ('posl.', '456'),

telefon_t ('mobil', '789')

)

);

UPDATE možemo raditi na dva načina. Prvi način, mijenjanje vrijednosti cijelog RVA

stupca TELEFONI, je jednostavniji:

UPDATE osoba

SET telefoni =

tablica_telefona_t (

telefon_t ('posl.', '000'),

telefon_t ('mobil', '111')

)

WHERE ime = 'Ana';

U drugom načinu mijenjamo samo neke retke ugniježñene tablice (nula, jedan ili više), ali

uvijek retke-djecu koji pripadaju odabranom (samo jednom) retku-roditelju, inače Oracle

javlja grešku (u nastavku mijenjamo samo telefone koji pripadaju osobi Ana; konkretno

mijenjamo samo jedan telefon). U ovom načinu moramo koristiti operator TABLE, kojim

pretvaramo odabrani skup redaka ugniježñene tablice u virtualnu tablicu:

UPDATE

TABLE (SELECT telefoni

FROM osoba

WHERE ime = 'Ana'

)

SET broj = '111'

WHERE vrsta = 'kućni';

33

DROP TABLE osoba;

DROP TYPE tablica_telefona_t;

DROP TYPE telefon_t;

Tablice sa RVA stupcima najčešće nisu dobar dizajnerski izbor, jer sa njima model

podataka sliči na nekadašnje hijerarhijske baze podataka, u kojima se tablici-djetetu moglo

pristupati samo preko tablice-roditelja, a rijetko u stvarnosti imamo tablice kojima ne želimo

pristupati i direktno. Kako smo već rekli u 3.poglavlju, i Date (2005, str. 143) drži da RVA

atributi najčešće nisu dobar dizajnerski izbor, iako su u relacijskom modelu dozvoljeni.

Inače, poznati Oracle ekspert (i Oracle zaposlenik) Tom Kyte kaže (2005, str. 417) da on

uopće ne upotrebljava objektno-relacijske ili objektne tablice, već koristi objektne mogućnosti

unutar jezika PL/SQL i koristi objektne poglede (object views) napravljene nad relacijskim

tablicama.

34

8. Oracle objektne tablice

Za razliku od objektno-relacijskih tablica, kod kojih je stupac tablice temeljen na objektnom

tipu ili tipu-kolekciji, Oracle objektne tablice ili tablice objekata (object tables) su one tablice

kod kojih cijeli redak reprezentira jedan objekt - to je onaj slučaj koji Date naziva prvom

grubom greškom (napomena: kao i kod izraza objektni tip u odnosu na izraz tip objekata, tako

nam se i izraz objektna tablica čini pogodnijim za upotrebu od izraza tablica objekata).

Evo kako izgleda objektna tablica ODJEL, temeljena na objektnom tipu ODJEL_T:

CREATE TYPE odjel_t AS OBJECT (

sifra VARCHAR(10),

naziv VARCHAR2(20)

)

/

CREATE TABLE odjel OF odjel_t

(PRIMARY KEY (sifra)) OBJECT IDENTIFIER IS PRIMARY KEY

/

Tablici ODJEL definiran je primarni ključ na temelju stupca SIFRA. Oracle bi tablici

automatski kreirao i nevidljivi stupac za object identifier – OID (plus još jedan nevidljivi stupac

za oznaku tipa), ali smo klauzulom OBJECT IDENTIFIER IS PRIMARY KEY kazali da će

primarni ključ biti zamjena za pravi OID.

INSERT, SELECT i UPDATE naredbe nad objektnom tablicom ODJEL izgledaju isto kao

naredbe nad običnom relacijskom tablicom (kako je pokazano, INSERT možemo raditi i pomoću

konstruktora, ali jednostavnije je bez njega):

INSERT INTO odjel VALUES ('10', 'Analiza');

INSERT INTO odjel VALUES (odjel_t ('20', 'Dizajn'));

SELECT sifra, naziv

FROM odjel;

35

SIFRA NAZIV

---------- --------

10 Analiza

20 Dizajn

UPDATE odjel

SET naziv = 'Design'

WHERE SIFRA = '20';

Sada ćemo definirati objektni tip RADNIK_T koji ima referencu na objektni tip ODJEL_T,

te ćemo na temelju objektnog tipa RADNIK_T napraviti objektnu tablicu RADNIK:

CREATE TYPE radnik_t AS OBJECT (

sifra VARCHAR(10),

naziv VARCHAR2(20),

odjel_oid REF odjel_t

)

/

CREATE TABLE radnik OF radnik_t


/

ALTER TABLE radnik MODIFY odjel_oid NOT NULL;

ALTER TABLE radnik ADD SCOPE FOR (odjel_oid) IS odjel;

Sa SCOPE FOR (ODJEL_OID) IS ODJEL ograničili smo referencu ODJEL_OID tako da

pokazuje na OID (baš) tablice ODJEL, a ne na OID neke druge objektne tablice koja je

napravljena na temelju objektnog tipa ODJEL_T. Mogućnost da više objektnih tablica bude

kreirano na temelju istog objektnog tipa Date drži (lošom) posljedicom prve grube greške.

Inače, napomenimo da se reference mogu koristiti ne samo kod deklaracije objektnog tipa, nego i

stupac objektno-relacijske tablice može biti deklariran kao referenca na objektni tip (što znači da

i objektno-relacijska tablica može imati referencu na objektnu tablicu).

36

Tablicu RADNIK sada ćemo napuniti sa dva retka:

INSERT INTO radnik VALUES (

'101', 'Ana',

(SELECT REF (o)

FROM odjel o

WHERE sifra = '10'

)

);

INSERT INTO radnik VALUES (

'102', 'Pero',

(SELECT REF (o)

FROM odjel o

WHERE sifra = '20'

)

);

Sada ćemo vidjeti kako se nad objektnom tablicom (ponekad) može napraviti upit bez JOIN-

a. Naime, baza sama napravi JOIN – to je tzv. implicitno dereferenciranje referenci (implicit

dereferencig of REFs). Ta mogućnost na prvi pogled djeluje spektakularno, ali kako kaže Date

(2004, str 881-882), to je samo sintaktička skraćenica i nije jasno kada se smije, a kada se ne

smije koristiti:

SELECT sifra,

naziv,

r.odjel_oid.naziv

FROM radnik r;

SIFRA NAZIV ODJEL_OID.NAZIV

------ ------ ----------------

101 Ana Analiza

102 Pero Dizajn

37

Nažalost, klauzula SCOPE FOR ne osigurava referencijalni integritet, jer ćemo uspjeti

izbrisati odjel 20 (Dizajn) u kojem radi neki radnik (konkretno, Pero):

DELETE odjel

WHERE sifra = '20';

SELECT sifra,

naziv,

r.odjel_oid.naziv

FROM radnik r;

SIFRA NAZIV ODJEL_OID.NAZIV

------ ------ ----------------

101 Ana Analiza

102 Pero

Reference koje pokazuju na nepostojeći objekt zovu se viseće reference (dangling REFs).

Ako želimo izbjeći viseće reference, tj. osigurati referencijalni integritet (a u pravilu želimo),

moramo tablici RADNIK kreirati vanjski ključ na tablicu ODJEL:

-- Dodavanje FK neće proći sa tekućim podacima,

-- jer je narušen integritet:

-- ORA-02298: cannot validate (OBUKA.RADNIK_ODJEL_FK)

-- parent keys not found

-- Zato moramo dodati redak roditelja

-- (kojega smo prije izbrisali)

INSERT INTO odjel VALUES

(odjel_t ('20', 'Dizajn'));

ALTER TABLE radnik

ADD CONSTRAINT radnik_odjel_fk

FOREIGN KEY (odjel_oid) REFERENCES odjel;

DROP TABLE radnik;

DROP TYPE radnik_t;

38

Pogledajmo malo kako idu zajedno nasljeñivanje i objektne tablice. Napravit ćemo dva

objektna tipa RADNIK_T (radi jednostavnosti ovdje nećemo raditi reference na tip ODJEL_T) i

PROGRAMER_T, od kojih je drugi podtip prvoga. Te objektne tipove koristit ćemo na dva

različita načina. U prvom načinu pokušat ćemo ih koristiti za kreiranje nadtablice i podtablice:

CREATE TYPE radnik_t AS OBJECT (

sifra VARCHAR(10),

naziv VARCHAR2(20),

odjel_sifra VARCHAR2(10)

) NOT FINAL

/

CREATE TABLE radnik OF radnik_t


/

ALTER TABLE radnik

ADD CONSTRAINT radnik_odjel_fk

FOREIGN KEY (odjel_sifra) REFERENCES odjel (sifra);

INSERT INTO radnik VALUES

('101','Ana','10');


('102','Pero','20');

CREATE TYPE prog_jezik_t AS OBJECT (

sifra VARCHAR(10),

naziv VARCHAR2(20)

) NOT FINAL

/

CREATE TABLE prog_jezik OF prog_jezik_t


/

39

INSERT INTO prog_jezik VALUES

('1','COBOL');

INSERT INTO prog_jezik VALUES

('2','Java');

CREATE TYPE programer_t UNDER radnik_t (

pjezik_sifra VARCHAR(10)

) NOT FINAL;

-- kreiranje FK na tablicu prog_jezik za sada ne radimo

CREATE TABLE programer OF programer_t

(PRIMARY KEY (sifra)) OBJECT IDENTIFIER IS PRIMARY KEY;

Postojanje nadtablica i podtablica je ono što Date (2004, str. 882-884) smatra lošom

posljedicom prve grube greške. No, moramo napomenuti da gornja varijanta nije ista kao ona

koju Date navodi u knjizi (i koja je SQL standard). Naime, Oracle nema sintaksu:

CREATE TABLE podtab UNDER nadtab

već

CREATE TABLE tablica OF podtip.

Možemo reći kako Oracle ne poznaje pojam nadtablice i podtablice u smislu SQL

standarda. Budući da Date kritizira nadtablice i podtablice, ispada da je to nepodudaranje sa

SQL standardom u ovom slučaju pozitivno. Unos redaka nad prethodne dvije Oracle tablice je

nezavisan - ako unesemo redak u tablicu PROGRAMERI, taj redak neće se pojaviti u tablici

RADNIK, a u SQL standard varijanti hoće.

No, Oracle na neki način ipak ima nadtablice i podtablice, ali recimo da su one implicitne –

obje se nalaze u jednoj fizičkoj tablici. Pokušajmo nad prethodno kreiranom tablicom RADNIK

napraviti sljedeće dvije INSERT naredbe:


('103', 'Ivo', '10');


(programer_t ('104', 'Nina', '20', 1));

40

Obje naredbe uspijevaju! Jasno je da uspijeva prva naredba, ali kako to da uspijeva i druga

naredba, koja unosi programera u tablicu RADNIK? Razlog je taj što tablica RADNIK ima i

(nevidljivi) stupac PROGRAMERSKI_STAZ. Naime, budući da je tablica RADNIK kreirana

nad tipom RADNIK_T, čim smo napravili podtip PROGRAMER_T (iako je to bilo nakon što

smo kreirali tablicu RADNIK), Oracle je tablici RADNIK automatski dodao nove stupce koji

odgovaraju novim atributima koje ima podtip PROGRAMER_T (u ovom slučaju je to samo

jedan atribut/ stupac):


FROM sys.col$

WHERE obj# =

(SELECT object_id

FROM user_objects

WHERE object_name = 'RADNIK'

)

ORDER BY segcol#;


---------- --------------------------- ------------ ----------

0 SYS_NC_OID$ 61 23

0 SYS_NC_ROWINFO$ 1 121

1 SYS_NC_TYPEID$ 16 23

2 SIFRA 10 1

3 NAZIV 20 1

4 ODJEL_SIFRA 10 1

5 SYS_NC00007$ 10 1

-- SYS_NC00007$ = pjezik_sifra

41

SELECT sifra, naziv,

SYS_NC00007$,

SYS_TYPEID (VALUE(r)) typeid

FROM radnik r;

SIFRA NAZIV SYS_NC00007 TYPEID

---------- -------------------- ---------- ------------------

---------

101 Ana 01

102 Pero 01

103 Ivo 01

104 Nina 1 03

-- još neki zanimljivi upiti

SELECT VALUE (r), SYS_TYPEID (VALUE (r))

-- VALUE vraca redak kao objekt

FROM radnik r;

SELECT VALUE (r)

FROM radnik r

WHERE VALUE (r) IS OF (programer_t);

Dakle, nismo uopće trebali kreirati tablicu PROGRAMER!

No, mislimo da se Dateu ne bi sviñale niti ovakve "implicitne nadtablice i podtablice" jer

i ovdje kreiramo (objektnu) tablicu na temelju (objektnog) tipa, što znači da i ovdje tablica ima

OID, pa onda možemo kreirati reference (u drugim tablicama) na taj OID.

Dalje, moramo primijetiti da postoji (barem) još jedan praktičan problem sa prethodnom

objektnom tablicom RADNIK. Kad bismo npr. željeli da "implicitna podtablica PROGRAMER"

(podsjećamo da ona u stvarnosti ne postoji) ima (neki) stupac koji predstavlja vanjski ključ na

neku treću tablicu (npr. pretpostavimo da ima stupac PROG_JEZ_ID koji predstavlja vanjski

ključ na tablicu PROGRAMSKI_JEZIK) onda taj vanjski ključ trebamo napraviti na temelju

"sistemski imenovanog stupca":

42

-- radi kreiranje indeksa na temelju stupca iz podtipa

CREATE INDEX programer_jezik_fk_i ON radnik r

(TREAT (VALUE (r) AS programer_t).pjezik_sifra);

-- ali ne radi kreiranje FK na temelju stupca iz podtipa

ALTER TABLE radnik r

ADD CONSTRAINT programer_jezik_fk

FOREIGN KEY (TREAT (VALUE (r) AS programer_t).pjezik_sifra)

REFERENCES prog_jezik (sifra);

ALTER TABLE radnik r

*

ERROR at line 1:

ORA-01735: invalid ALTER TABLE option

-- ne radi kreiranje FK na temelju stupca iz podtipa

-- niti na ovaj način

ALTER TABLE radnik


FOREIGN KEY (TREAT (radnik AS programer_t).pjezik_sifra)


FOREIGN KEY (TREAT (radnik AS programer_t).pjezik_sifra)

*

ERROR at line 3:

ORA-00904: : invalid identifier

-- ne radi kreiranje FK na temelju stupca iz podtipa

-- niti na ovaj način

ALTER TABLE radnik


FOREIGN KEY (radnik.pjezik_sifra)


FOREIGN KEY (radnik.pjezik_sifra)

43

*

ERROR at line 3:

ORA-00904: "RADNIK"."PJEZIK_SIFRA": invalid identifier

-- ovako radi - kreiranje FK na temelju

-- "sistemski imenovanog stupca" SYS_NC00007$ (= pjezik_sifra)

ALTER TABLE radnik


FOREIGN KEY (SYS_NC00007$) REFERENCES prog_jezik (sifra);

-- DROP TABLE: programer (nije niti trebala),

-- radnik, prog_jezik, odjel

-- DROP TYPE: programer_t, radnik_t, prog_jezik_t, odjel

Inače, Date navodi (2004, str. 423-424) da je jednostavno i ispravno rješenje primjera

RADNIK-PROGRAMER (tj. primjera nadtip-podtip) moguće bez objektnih tablica. Prvo

napravimo tablicu RADNIK. Zatim napravimo tablicu PROGRAMER sa dodatnim stupcima, ali

i sa stupcem koji je isti kao PK tablice RADNIK i koji će istovremeno biti PK tablice

PROGRAMER i FK na tablicu RADNIK. Nakon toga napravimo pogled (view)

V_RADNIK_PROGRAMER kao JOIN izmeñu te dvije tablice:

CREATE TABLE radnik (

sifra VARCHAR(10) PRIMARY KEY,

naziv VARCHAR2(20)

)

/

CREATE TABLE programer (

sifra VARCHAR(10) PRIMARY KEY REFERENCES radnik (sifra),

programerski_staz NUMBER

)

/

44

CREATE VIEW v_radnik_programer AS

SELECT r.sifra,

r.naziv,

p.programerski_staz

FROM radnik r,

programer p

WHERE p.sifra = r.sifra

/

Sada možemo raditi sljedeće:

- ako želimo čitati samo radnike koji nisu programeri, radimo SELECT nad tablicom

RADNIK

- ako želimo čitati samo radnike koji jesu programeri, radimo SELECT nad pogledom

V_RADNIK_PROGRAMER

- ako želimo unijeti/mijenjati radnika koji nije programer, radimo INSERT/UPDATE nad

tablicom RADNIK

- ako želimo unijeti/mijenjati radnika koji je programer, radimo INSERT/UPDATE nad

pogledom V_RADNIK_PROGRAMER, s tim da možemo koristiti Oracle INSTEAD OF okidač

da bismo istovremeno ažurirali dvije tablice (koje čine pogled).

45

9. Zaključak

Ako gledamo SQL:1999 i SQL:2003 standarde i stanje na tržištu RDBMS sustava, možemo

reći da objektno-relacijski DBMS (ORDBMS) sustavi u stvarnosti postoje.

Meñutim, možemo se složiti sa Dateom da neke objektno-orijentirane osobine koje imaju

ORDBMS sustavi zapravo pripadaju relacijskom modelu i "običnim" RDBMS sustavima. Prije

svega, misli se na mogućnost definiranja korisničkih tipova podataka, koji onda mogu poslužiti

za definiranje atributa relacije.

Date (2004, str. 891) citira Davida Maiera, poznatog stručnjaka na području objektnih baza

(on je jedan od kreatora poznatog teksta "The Object-Oriented Database System Manifesto"),

koji kaže: "… I think that type extensibility is the key. Identity, complex state, and

encapsulation are still important, but only insomuch as they support the creation of new data

types.".

S druge strane, mogućnost da korisnički definirane tipove podataka koristimo i za

definiranje "objektnih tablica", sa svim posljedicama koje to donosi (npr. posljedica je uvoñenje

nadtablica i podtablica), Date naziva "prva gruba greška". Uvoñenje pokazivača (ili referenci,

REFs) u relacijske baze Date naziva "druga gruba greška". Takve "čiste objektne osobine"

trebalo bi u relacijskoj bazi (u pravilu) izbjegavati.

Budući da se pojedinačnim elementima VARRAY tipa ne može pristupiti kroz SQL, već

samo kroz PL/SQL, u Oracle bazi nije preporučljivo koristiti VARRAY tip za stupce tablice.

Na kraju, tablice sa RVA stupcima (u Oracle terminologiji - stupci tipa ugniježñene tablice)

najčešće nisu dobar dizajnerski izbor, jer sa njima model podataka sliči na nekadašnje

hijerarhijske baze podataka.

46

Literatura

[1] Blaha, M. & Premerlani, W. (1998):

Object-Oriented Modeling and Design for Database Applications,

Prentice Hall

[2] Date, C.J. (2004): An introduction to Database Systems (8.izdanje), Addison-Wesley

[3] Date, C.J. (2005): Database in Depth, O'Reilly

[4] Date, C.J. (2006): Date on Databases – Writings 2000-2006, Apress

[5] Date, C.J. (2007): Logic and Databases – The Roots of Relational Theory, Trafford

Publishing

[6] De Haan, L. i Koppelaars T. (2007): Applied Mathematics for Database Professionals,

Apress

[7] Feuerstein S. i Pribyl B. (2005): Oracle PL/SQL Programming (4.izdanje), O'Reilly

[8] Kimball, R. i Ross, M. (2002): The Data Warehouse Toolkit (2. izdanje), John Wiley & Sons

[9] Kyte, T. (2003): Effective Oracle by Design, McGraw-Hill/Osborne

[10] Kyte, T. (2005): Expert Oracle Database Architecture, Apress

[11] Larman, C. (2002): Applying UML and Patterns (2.izdanje), Prentice Hall

[12] Maleković, M. (2009), Integritet i sigurnost baza podataka – materijali sa predavanja, FOI

[13] Meyer, B. (1997): Object-Oriented Software Construction (2.izdanje), Prentice Hall

[14] Radovan, M. (1993): Baza podataka: Relacijski pristup i SQL, Informator, Zagreb

47

[15] Von Halle, B. (2002):

Business Rules Applied: Building Better Systems Using the Business Rules Approach,

John Wiley & Sons

[16] Oracle priručnik 11g Release 1 (2007): Advanced Application Developer's Guide

[17] Oracle priručnik 11g Release 1 (2007): Concepts

[18] Oracle priručnik 11g Release 1 (2007): Object-Relational Developer's Guide

[19] Oracle priručnik 11g Release 1 (2007): PL/SQL Language Reference

[20] Oracle priručnik 11g Release 1 (2007): PL/SQL Packages and Types Reference

[21] Oracle priručnik 11g Release 1 (2007): SQL Language Reference

sirotic kako koristiti ordbms

Documents