R E F E R A T I - Media Zona - My Paper

R E F E R A T I 

16. KONFERENCIJA HRVATSKE UDRUGE ORACLE KORISNIKA 

18. – 22. LISTOPADA 2011. ROVINJ 

1

REFERATI 2 

KONFERENCIJSKE AKTIVNOSTI - REFERATI PO TEMATSKIM CJELINAMA 

Na strani 

1 201 

200 Strategija i upravljanje IS - opće ICT teme 

Klaudio Lazarić, Hrvatski Telekom 

Cloud Computing - Sveti Gral poslovnog računarstva 

3 

2 202 Rajko Kuzma, Intesa Sanpaolo Card 

Kontinuirano nadziranje kvalitete razvoja Oracle aplikacija 

11 

3 207 Dubravka Mendeš Poljak, Grad Zagreb 

Cijena aplikacije – Zašto software toliko košta? 

21 

300 Alati za razvoj aplikacija i aplikacijska rješenja 

1 301 Zlatko Sirotić, Istra informatički inženjering 28 

Konkurentno programiranje - Oracle baza, Java, Eiffel 

400 Tehnologija – DBA, Linux i Open Source rješenja 

1 402 Alen Prodan, LOGIN 67 

Korištenje histograma u optimizaciji SQL naredbi 

2 409 Zlatko Sirotić, Istra informatički Inženjering 79 

Kriptografija u Oracle bazi 

500 Oracle Fusion Middleware 

1 502 Dubravko Miljković, HEP SIT 107 

BI Publisher 11g – što je novo? 

600 Poslovni IS - rješenja, infrastruktura i integracija 

1 601 Dubravko Miljković, HEP SIT 125 

Metode balansiranja opterećenja (load balancinga) za aplikacijske servere 

2 607 Josip Matanović, Infosistem 137 

Integracija Oracle aplikacija i JasperReports-a 

3 608 Andro Milanović, Ivan Žiger, 147 

ISŽO-ADs: Integracija transakcijskog sustava s dokumentacijskim sustavom 

4 612 Nataša Dvoršak, Uljanik IRI 162 

Oracle VPD u primjeni 

700 Specifični podsustavi – GIS, OCM, …, 

1 703 Martin Martić, Mario Starčević, Multisoft 177 

Oracle/Oracle Spatial i FME ETL - Razmjena podataka neovisno o formatu 

2 706 Bojan Franc, Miroslav Šturlan Ivo Uglešić, Ivan Goran Kuliš, FER, Končar KET 188 

Programska podrška sustava za lociranje munja u Hrvatskoj

CLOUD COMPUTING - SVETI GRAL POSLOVNOG RAČUNARSTVA 

Klaudio Lazarić 

Hrvatski Telekom d.d. 

Petra Kobeka 15, 

51000 Rijeka 

+385 51 226029 

+385 98 425999 

klaudio.lazaric@t.ht.hr 

SAŽETAK 

Informatika je svaki dan bogatija za novi pojam iako ga temelji na idejama iz prošlosti. Težnja 

da sva rješenja moraju biti optimizirana usmjerava ih prema centralizaciji, a onda ih složenost 

problema ponovo vraća decentralizaciji. „Računarstvo u oblaku“ doživljava vrtoglavi razvoj i sve 

veću primjenu u poslovnom računarstvu, zato je potrebno utvrditi sve njegove prednosti i 

nedostatke. Navikli smo živjeti virtualno, ali još uvijek moramo živjeti stvarno. 

Koliko je Cloud Computing: Sveti Gral – izvor svih rješenja poslovnog računarstva? 

Postoji li jednostavno rješenje za složene probleme? Koliko su slični pojmovi „crna kutija“ i 

„oblak“? U vrijeme kada se sve više osoba osjeća informatičarima – koju vrstu organizacije u 

poslovanju trebamo? 

UVOD 

Informatika proživljava vrlo burno razdoblje. Ušla je u sve pore čovjekovog života i postala 

svakodnevna potreba kao što su voda i zrak. Međutim, javlja se i nezadovoljstvo jer sve češće 

informatika gubi sposobnost brzog rješavanja novo postavljenih zahtjeva. Zato se ponovno posegnulo 

za davno stvorenim idejama kada se predlagalo da informatika bude na usluzi korisnicima, na način, 

kao što se to radi s vodom, strujom i plinom. Potrebni preduvjeti nastali su razvojem interneta koji je 

idealna struktura za raspodjelu podataka i informacija, te primjenom virtualizacije. Mnogobrojni 

znanstvenici preuzeli su zadaću da računarstvo u oblaku pretvore u najpoželjniju, najekonomičniju i 

jedinu vezu između korisnika i isporučitelja informatičkih resursa. Ovaj osvrt ima za cilj da ukaže na 

neke dileme, prednosti i nedostatke koje nosi ovo rješenje. 

Centralizacijom svih resursa i njihovim stavljanjem u Oblak stvorila se mogućnost da se dio ostavi 

nepoznat i tajanstven u svojim rješenjima, ali otvoren u mogućnostima. Magična moć novih metoda, 

metodologija i tehnologija pružila je novu priliku kojom se korisnika može i treba zadiviti, te ga na taj 

način stvoriti potpuno ovisnim. 

Koliko je računarstvo u oblaku samo Sveti Gral koji nudi ogromne potencijalne mogućnosti, a koje 

zbog svoje izdvojenosti nose opasnost da ostanu nedovoljno iskorištene, pokazati će vrijeme. Glavni 

nedostatak leži u tome što se nove tehnologije i rješenja uvode u informatiku prebrzo bez da ih se 

pažljivo analizira, testira, shvati i razumije. Brzina uvođenja i korištenja jednostavnih rješenja 

zasljepljuje. Međutim, onda kada implementacija složenih rješenja bude trajala duže od očekivanog 

opet će se krenuti u novu potragu za boljim rješenjima. 

Teorija je uvijek korak ispred prakse, ali je praksa uvijek svjesnija puta po kojem se kreće. 

3

1. PROIZVOD – USLUGA (CRNA KUTIJA – OBLAK) 

Nove tehnologije nastoje sve svoje mogućnosti korištenja što brže uvesti u svakodnevnu 

primjenu i to često bez sustavne provjere i potvrde. Pažljivim pristupom u građenju tajanstvenosti i 

znatiželje korisnika se dovodi u stanje potpune ovisnosti. 

Složeni proizvodi sadrže novo oblikovane cjeline, a postojeće usluge stalno se prebacuju u 

novo stvorena područja koja su nejasna ili nepoznata osobama s nedovoljnim stručnim 

znanjem. Najbolji primjer kod složenih proizvoda su takozvane crne kutije gdje su poznate ulazno 

- izlazne vrijednosti, a uglavnom je nepoznata struktura odnosno sadržaj. Samo je ograničeni 

broj školovanih odnosno specijaliziranih osoba u stanju razumjeti pojedinosti crne kutije čije se 

funkcionalnosti najčešće prikazuju u shematskom obliku. 

Kod mnogobrojnih usluga koje danas pruža informatika, nastoji se sve važnije pojedinosti i 

rješenja smjestiti u novo stvoreni pojam Cloud – Oblak. Ovaj izraz nastao je kao metafora za 

Internet i prvobitno je bio korišten u prikazima predstavljanja telefonske mreže, dok se kasnije u 

računalnoj mreži počeo koristi u dijagramima Interneta kao apstrakcija osnovne infrastrukture koju 

predstavlja. 

Cloud je simbol koji se prvenstveno koristi za označavanje točke razgraničenja između 

onoga što je odgovornost davatelja usluge i onoga što je odgovornost korisnika. Kao što se 

kod proizvoda nastojalo složene dijelove zatvoriti u nepoznanicu crnih kutija tako se kod 

informatičkih usluga nastoji sve posebnosti odvojiti od korisnika u Oblak. Ovaj način pruža veću 

mogućnost apstrakcije, a i lakšeg iznošenja različitih tvrdnji i pretpostavki budući da korisnik nema 

izravnu mogućnost uvida, a time i nadzora nad procesima koji se odvijaju u informatičkim sustavima. 

Nelogičnost stvara i način usporedbe sustava, koji u stvarnosti ne postoje, pa zahtijevaju 

proizvoljno postavljanje troškovnih veličina, a tada se rezultati mogu lako prilagoditi namjerama 

i željama onoga koji određenu tvrdnju dokazuje. 

2. NESAVRŠENOST I STVARALAŠTVO (INCIDENTI – RJEŠENJA) 

Virtualno računalo razvijeno je u težnji da mu se logičkim predstavljanjem pokuša programski 

pridijeliti inteligenciju. Međutim, inteligencija koja se stvara kroz pravila i standarde nije ona 

„prava“. Najbolji dokaz za ovu tvrdnju su teškoće koje su postojale i postoje pri pokušaju razvoja 

umjetne inteligencije. Ovakav način rješavanja problema najčešće je samo željena pretpostavka 

ostvarivanja očekivanog ponašanja sustava uz unaprijed zadane preduvjete i na osnovu njih 

iskustveno poznatih mogućih stanja. Stvaralaštvo se u informatici neprekidno kretalo između 

hardvera i softvera. Najnovije je stremljenje da se hardver odvoji od operativnog sustava. Međutim, tu 

se onda zahtijevaju automatizirani procesi koji trebaju sadržavati kvalitetne kontrolne mehanizme. 

Nažalost, programski vođeno odvijanje procesa često dovodi do nepredvidivih problema u 

kojima je onda alarm jedina prava mogućnost upozorenja potrebe za intervencijom i rješavanjem 

incidentne situacije. 

Informatičku tehnologiju oduvijek se pokušavalo prekriti velom nadnaravnih sposobnosti i 

predstaviti ju kao savršenu osnovu za uspješno rješavanje svakog problema, tvrdeći i iznova 

pokušavajući dokazati da je ona u stanju riješiti sve i to uvijek brže i jednostavnije. 

Čarobna riječ iscjeljenja bolesnih područja današnje informatičke tehnologije određena je 

novim pojmom – Cloud Computing odnosno računarstvo u oblaku. Mnogobrojni savjetnici na 

području informatike zadnjih deset godina pokušavaju kao jedini mogući izvor svih rješenja prikazati – 

Cloud Computing. Prema njima, mistični Oblak pruža nove nesagledive sposobnosti, pa više neće 

biti potrebe da svaki servis, podatak ili informacija bude pohranjena na računalu korisnika, već će se 

sve moći, morati i trebati pohraniti u Oblaku. Za sve one koji nisu u duhu današnje informatike, 

savjetnici proročki ponavljaju mantru (snagu koja može dovesti do duhovnog buđenja) da će 

računarstvo u oblaku preuzeti cjelokupan IT, pri čemu će se svi korisnici u nekom svetom činu ITuskrsnuća 

dematerijalizirati i otići u nebo i tako virtualni, promatrati s visine one materijalne, od mesa 

sačinjene smrtnike koji još uvijek imaju lokalne hard diskove, lokalne aplikacije, lokalno sadržane 

podatke i za koje je potrebno raditi sigurnosne kopije. 

Međutim, nesavršenost rješenja iznova će generirati incidente i tjerati na novo stvaralaštvo 

kroz nove tehnološke mogućnosti. 

4

3. NAPRAVITI – KUPITI – IZNAJMITI 

Poznate su mnogobrojne znanstvene rasprave koje se vode oko traženja prave metode za 

utvrđivanje izbora najekonomičnijeg rješenja. Što je bolje: napraviti, kupiti ili iznajmiti? Odluka 

je oduvijek bila podložna trenutnoj ponudi i potražnji koja je određivala pravila, a s njima prednosti 

odnosno nedostatke. Neprekidnim preslagivanjem vrijednosti mijenja se procjena o pojmu bogatstva. 

U vrijeme kada bogataš preko noći može postati siromah, ali gdje i siromah (istina nešto malo teže) 

može postati bogataš teško je utvrditi gdje su prava mjerila i granice posjedovanja vrijednih stvari 

budući da se njihova cijena mijenja vrtoglavom brzinom u jednom trenutku na gore, a već u 

slijedećem na dolje. Razdoblje globalizacije najveću prednost daje posjedovanju energetskih 

resursa koji su tako postali mjerilo bogatstva pojedinih područja. Političke odluke stalno mijenjaju 

sliku moći, a s njom važnost ponude i potražnje. Trgovina je pak ta koja stvara dodatne 

nestabilnosti svojim procesom: kupi – pričekaj pravi trenutak za prodaju – prodaj i zaradi. U izjavi: 

Imati ili nemati, pitanje je sad? leži i dio odgovora. Što je vrijedno, a što je bezvrijedno? Najčešće je 

vrijedno ono čega ima malo ili ono čega uopće nema, a ne ono čega ima u izobilju. Uz različitu 

raspodjelu prirodnih bogatstava, uz vlasnike koji svoje bogatstvo ulažu u investicije, često na 

suprotnom kraju svijeta, sve su procjene vrlo upitne jer su samo slika trenutnog stanja. Ono što je 

danas pametno, često je već sutra potpuno glupo odnosno pogrešno. 

Kakvo je stanje u informatici? Kamo se kreću razmišljanja o ekonomičnosti rješenja? 

Nema više potrebe za vlastitim podatkovnim centrom, sve što treba smješteno je tamo 

negdje u Oblaku, uvijek dostupno uz dogovorenu vrijednost naknade. Težnja je da se plaća 

koliko se koristi, pa ako poslovi lošije idu, manje se koristi i manje se plaća. Pitanje ekonomičnosti 

postaje pitanje optimalnosti. Međutim, optimalno nije uvijek i ekonomično kao što ekonomično 

nije uvijek optimalno. Problem je taj što onaj tko pruža iznajmljivanje propada, ako ga se ne 

koristi optimalno. Ekonomična cijena za ekonomično korištenje obično nije optimalna cijena, jer 

da bi se isporučitelj usluge osigurao za razdoblje kriznih vremena, (a da bi uz to i zaradio) on mora 

uzimati više kako bi sakupio „bijele novce za crne dane“. 

Ono što se koristi jednokratno ili kratkotrajno, najbolje je iznajmiti, ali i pri tome uvijek 

analizirajući cijenu kupljeno - iznajmljeno. Ono što se koristi svakodnevno, najbolje je kupiti. Ono 

što je jednostavno ili za što postoje potrebni resursi, najbolje je napraviti. Zašto plaćati ono što se 

ne koristi, ali zašto imati i nešto što se ne koristi? Razlog je taj što se čovjek boji da neće imati, kada 

mu bude trebalo, pa se nastoji osigurati sakupljanjem i spremanjem i onoga što mu u određenom 

trenutku ne treba, ali za što misli da će mu trebati. Napravljeno i kupljeno je ipak vidljivo odnosno 

postoji, ali iznajmljeno je uvijek tuđe i do njega korisnik ima pravo pristupa samo dok postoji 

dozvola korištenja. Iznajmljeno nije korisnikovo i kada se on raziđe od vlasnika, ništa mu ne ostaje. 

Korištenje je obično jeftinije, ali i opasnije ako stvari krenu ka prekidu, a u današnja krizna 

vremena prekidi postaju sve češći i sve teže predvidljivi. 

4. PODRŠKA – ODRŽAVANJE (SAVJETNICI – OUTSOURCING) 

U poslovnom se svijetu neprekidno pojavljuju novi zahtjevi koje treba ugrađivati u informatičke 

sustave. Težnja je osmisliti što ekonomičnije rješenje koje istovremeno treba biti jednostavno i 

lako primjenjivo u praksi. Međutim, zbog mnogobrojnih posebnosti nastaju vrlo složeni sustavi 

koje treba neprekidno nadzirati, a zbog incidenata koji su neminovnost nesavršenosti rješenja 

potrebno je imati kvalitetnu podršku koja je u stanju na vrijeme reagirati i spriječiti daljnje stvaranje 

problema. Nastojanje da se stalno ide u korak s novim mogućnostima, jer se tehnologije 

neprekidno mijenjaju, dovodi do slučajeva u kojima su zbog nedovoljnog znanja pogreške sve 

prisutnije, a uz to često uzročno povezane. Potreba za prijelazom na nove sustave zahtjeva vrlo 

stručno poznavanje ponašanja postojećih i budućih sustava kako bi se svaka migracija mogla obaviti 

kvalitetno, brzo i jednostavno. 

Održavanje i podrška traže sve više sredstava jer rješenja u uvjetima stalnih poslovnih 

promjena postaju sve složenija, a time i skuplja. U poslovnom okruženju nastaje tako „bolesno 

stanje“ koje traži liječnike, takozvane savjetnike, koji su onda u stanju ponuditi pravi lijek za 

svaku situaciju. Poznato je da svaki lijek kod nečega pomaže, ali da istovremeno kod drugoga 

odmaže. Nedovoljno znanje zahtjeva iznajmljivanje tuđeg iskustva. Postalo je najlakše zatražiti 

specijalizirane timove izvan organizacije koji se onda u već poznatom obliku iznajmljivanja znanja 

i rada (outsourcinga) uključuju u sređivanje problema. Međutim, takvo „liječenje“ postaje sve 

skuplje jer traži sve više tuđeg rada, brige i znanja koji se onda pretvara u nove troškove 

povećavajući već ionako visoka ulaganja u informatiku. 

5

Svako plaćanje obavljenog posla riješeno je ugovorom koji nosi skrivene ciljeve u kojem jedna 

strana želi što više zaraditi, a druga što manje platiti. Znači ciljevi su dijametralno suprotni. U 

outsourcingu se tako javlja paradoks dok jedna strana želi što manje učešće druge strane jer 

svaki trenutak njenog rada znači trošak, druga pak teži većem uključivanju u svrhu stvaranja 

prihoda. Prisutna je često i neskrivena težnja isporučitelja usluge napraviti što manji transfer 

znanja na korisnika kako bi se ovisnošću mogao stvoriti dodatni izvor zarade. Pružatelju usluge 

najviše odgovara kada uspije uvjeriti korisnika da ne treba stvarati vlastita ili kupovati gotova rješenja, 

već da sve što mu je potrebno može jednostavno iznajmljivati od njega, pa će se oslobođen brige o 

održavanju sustava više usmjeriti na vlastiti posao. Na početku sve to izgleda lijepo i krasno jer se 

obavlja na dogovoren i primamljiv način, ali postepeno se pretvara u potpunu ovisnost. Sve se 

usmjerava prema stvaranju čvrstih veza koje će osiguravati sigurnu i stabilnu podršku i odražavanje, 

ali se na taj način smanjuje mogućnost za novi izbor. Stvorene veze teško je brzo i u potpunosti 

zamijeniti jer uvijek postoji mogućnost pojave problema koji u slučaju prekida ostavljaju duboke ožiljke 

i nose opasnost od ozbiljnih i dugotrajnih posljedica. 

Ovisnost se stvara svakim izborom. Oslanjanje na točno određenog pojedinca nosi u sebi rizik 

da se njegovim odlaskom izgubi stabilnost u odvijanju procesa. Oslonac na jednu osobu uvijek nosi 

rizik, na dvoje već gradi sigurnost, na troje stvara stabilnost. Međutim, ovo je još jedan dokaz da 

optimalno rješenje najčešće nije ono ekonomično. 

5. RAČUNARSTVO U OBLAKU 

Računarstvo u oblaku nudi se i reklamira kao najekonomičniji način rješavanja svih sadašnjih 

i budućih informatičkih zahtjeva. Nastalo je kroz pretpostavku da se mogućnost „opskrbe“ 

resursima može napraviti na isti način na koji je organizirana opskrba vode, struje i plina. 

Masovne zahtjeve raspodjele i korištenja takvih usluga rješava se organizirano, izdvojeno i 

centralizirano, pa se iz toga rodila tvrdnja da se i obrada podataka može, mora i treba riješiti na isti 

način. Glavna je prednost što se ovakvim pristupom osiguravaju ogromne količine raspoloživih 

resursa. Mogućnosti se zasnivaju na stalnoj dostupnosti, dok je odluka o korištenju bilo da se 

radi o količini ili vremenu potrošnje prepuštena korisniku. Vrlo se rijetko i to najčešće samo površno 

razmatraju posebnosti ove vrste zahtjeva i rizici ovakvog načina opskrbe. Posljedice se nikada ni ne 

pokušavaju uspoređivati s prednostima. Vješto se izbjegava analiza koja bi mogla otkriti 

nedostatke. Sve poznate probleme nastoji se obrazložiti pripremom dodatnih akcija za takve situacije. 

U slučaju nastanka štete obavlja se saniranje posljedica uz često prikrivanje prave istine o njenim 

razmjerima. 

Računarstvo u oblaku je model za koji zagovornici ovakvog rješenja navode da omogućava 

jednostavan, na korisnikov zahtjev organizirani pristup mreži uz zajedničku akumulaciju podesivih 

računalnih resursa (mreža, poslužitelja, smještajnih kapaciteta, aplikacija i usluga) koje se mogu 

brzo pružiti i primijeniti uz minimalan napor i učešće korisnika. Svaki je model vrlo uspješan u 

teoriji jer je tada izdvojen i oslobođen svih smetnji i nepredvidivih događanja koje praksa sa sobom 

donosi. U steriliziranoj okolini teško se zaraziti. U nadgledanom okruženju koje je za potrebe testiranja 

vrlo pažljivo organizirano lakše je potvrditi prednosti i umanjiti rizike koje stvaraju nedostaci. U 

nenadanoj ali očekivanoj situaciji lakše je brzo i pravovremeno reagirati. 

Međutim, problemi računarstva u oblaku postoje i oni su danas još uvijek posebno izraženi u 

zahtjevima sigurnosti, pouzdanosti, intelektualnom vlasništvu softverskih rješenja, pohrani 

podataka koje treba imati u slučaju oštećenja smještajnih kapaciteta – backup, različitosti 

operativnih sustava, a poseban zahtjev je izrada kvalitetnih sučelja na web osnovi. Jednostavnije 

rečeno, problemi su prisutni u svemu onome što informatiku određuje. Prirodno je da svi oni koji 

zagovaraju računarstvo u oblaku sve ove nedostatke nastoje riješiti ili barem smanjiti opasnost od 

mogućih rizika, ali očito je da je za sada uspješnost rješenja više izuzetak nego li pravilo. 

Računarstvo u oblaku je obećavajući poslovni koncept. Potrebno je samo riješiti sigurnost, 

sigurnost i samo sigurnost. Nažalost, za svaki se urušeni sigurnosni sustav u početku mislilo i tvrdilo 

da je nepogrješiv. Prepustiti sigurnost i nadzor odluci koja je zasnovana na povjerenju vrlo je opasno, 

pa čak i kada se radi o manje važnim aplikacijama, a za posebne svakako da to nije ni poželjno. 

Zamislite što je sve moguće s novim rješenjima, ali nemojte zaboraviti kakve sve to rizike nosi. 

Avanturizam je lijep dok ne krene po zlu, a onda se poteškoće samo gomilaju i gomilaju. Važan je 

integritet podataka, povjerljivost,dostupnost i raspoloživost. Ako veće vjerovanje znači smanjenje 

sigurnosti onda problem postoji i treba ga riješiti. Kako biti siguran da korištenje neće prijeći 

granice ekonomičnog korištenja? Kako biti optimalan u uvjetima u kojima postoji potreba ili 

sloboda da se koristi sve više i više? Kako postići da se zahtjevi ne prošire više od potrebnog? 

6

U nastojanju da se umanji strah od potencijalnih problema pružatelji usluga računarstva u 

oblaku pokušavaju tvrditi da su njihova rješenja sigurna i preporučljiva. U svojim reklamama 

navode - Sigurnost je ugrađena u DNK naših proizvoda. Kao što se u glazbenoj industriji teško 

boriti protiv piratstva, tako je u Oblaku teško pružiti potpunu sigurnost. Prijelomne tehnologije brzaju u 

odnosu na donošenje novih zakona. Svakako ne treba ići ni u krajnost, pa nametnuti stroge zakone jer 

bi to moglo donijeti više štete nego li koristi. Standardi su po svojoj prirodi ograničenja. Različitost 

pristupa određivanju standarda izražena je po područjima i državama. Dok je u Evropi velika zaštita 

privatnosti, u SAD bi se moglo reći da je uopće nema. Pomiriti sve moguće pretpostavke nije i neće 

biti lako i uvijek će postojati problemi koji će stvarati potencijalnu opasnost i gdje će se opskrba iz 

Oblaka vrlo lako i brzo pretvoriti u lutanje kroz nepoznato. Dodatne teškoće nastaju i zato jer 

postojeća intenzivna transakcijska opterećenja i drugi važni aspekti velikih tvrtki kod IT produkcije 

nisu još uvijek dobili uspješna rješenja kroz računarstvo u oblaku - barem ne još za sada. 

Rješenja koja su razvijena usmjerena su prvenstveno na pitanja opskrbe iz ogromnog bazena, 

podataka i informacija. Građenje iskustva i stvaralaštvo u Oblaku suzuje se u uske okvire 

mogućnosti koje su osim toga ograničene sposobnošću onih koji ih koriste. 

Opet će se na nove načine graditi posebnosti. Kroz računarstvo u oblaku početi će prodirati zrake 

novih stvaralačkih ideja koje će stvoriti pretpostavku da rastjeraju ili rasplinu Oblake u koje se 

danas ugrađuju nova informatička rješenja. 

6. CENTRALIZACIJA – DECENTRALIZACIJA (PRIHOD – TROŠKOVI) 

U svim područjima čovjekovog života prisutna je vječna težnja prema centralizaciji. Zasniva se 

na tvrdnji da je ona sigurnija, ekonomičnija i poželjnija. Posebno je to izraženo u kriznim 

vremenima. U centraliziranom sustavu sve je povezano, standardizirano i s minimalnim 

razlikama. Standard je ograničenje, smanjenje mogućnosti zbog nastojanja da se sve pojednostavi. 

Potrebu nadzora i upravljanja lakše je riješiti u centraliziranom sustavu. Iako je izuzetak uvijek skuplji 

od masovnog slučaja, odnos procjene se mijenja ako se za njega postavi standard. Kada se utvrdi 

postojanje posebnog slučaja, osiguraju se sredstva i nastaje prirodan zahtjev koji traži 

rješenje. Izuzetak tako postaje pravilo. Znači bitna je samo dozvola postojanja, a onda se sve može, 

treba i mora riješiti da bude ekonomično. U informatici se stalno balansira između želje i potrebe 

za ekonomičnim hardverom i softverom. Dugoročno gledano nije problem u hardveru, već u 

softveru odnosno iskorištenosti tog hardvera. Na tim postavkama računarstvo u oblaku našlo je 

najjači oslonac i mnoge izuzetke pretvorilo u pravilo. Standardiziranjem svega, pa i izuzetaka, kroz 

centralizirani sustav nastoji se onda sve obuhvaćeno prikazati ekonomičnim. 

Centralizacijom se umanjuju troškovi održavanja infrastrukture. Smanjuju se ukupni 

troškovi, ali postoje granice gdje se sve većim prostiranjem neproporcionalno povećavaju 

troškovi zbog potrebe za sve širim područjem održavanja. Da bi se ostvarila što bolja kvaliteta 

centraliziranog sustava karakteristike infrastrukture moraju biti izuzetne jer sve se odvija negdje 

drugdje, pa veza mora biti stalna, brza i jednostavna. Na jednoj su strani želje i zahtjevi, a na 

drugoj, obično negdje daleko, nalaze se svi procesi koji to rješavaju. Nakon iznajmljivanja usluga bilo 

je prirodno za očekivati da će se početi iznajmljivati i skupe investicije to jest infrastruktura. 

Koliki je trošak informatike? Kako mjeriti korištenje? Koja je cijena mjerne jedinice? Koliko je 

ona promjenjiva? Poremećaji na tržištu često stvaraju sve veće potrebe, a sredstva su tada obično 

sve manja. Bez informatike se više ne može. Toliko je usađena u poslovanje da i kratkotrajni 

neplanirani prekid stvara gužvu i nervozu. U trenucima panike sve bi se dalo da sustav bude 

operativan i često se nakon takvih problema, pričuvnim rješenjima, potroše sve prethodne uštede. 

Koji su troškovi stvarni i prirodni? Kako utvrditi ekonomičnu vrijednost informatike? Što 

određuje vrijednost usluge: kvaliteta – količina – zadovoljstvo? Pokušavalo se, a još se 

pokušava utvrditi koliko informatika uspijeva vratiti od onoga što se u nju ulaže. Poduzeća vrlo 

teško utvrđuju stvarne troškove informatičkih usluga, pa zato ni ne mogu znati što im je bolje i kolika 

je prednost ili nedostatak korištenja računarstva u oblaku. Informatiku se stalno gura u nove i ne 

istražene mogućnosti pokušavajući slijediti primjenu najnovijih tehnoloških dostignuća. Pokazalo se da 

su prednosti novih rješenja teško mjerljive. Dok neke primjene informatike mogu vrlo brzo prikazati 

velike uštede, druge traže dugo razdoblje da bi do povrata došlo. Financijskim stručnjacima trošenje 

sredstava predviđenih za ulaganja u investicije najmanje je prihvatljivo. Zbog toga postoji težnja da se 

što više troškova veže uz produkciju da bi ih se onda uzročno posljedično opravdalo mogućim rizicima 

do kojih bi nedostatak sredstava mogao dovesti. Računarstvo u oblaku postiglo je dodatnu prednost 

jer se kod njega svaki kapitalni izdatak smatra operativnim izdatkom. 

7

Oblak nije moguće nadzirati jer je virtualan. U transakcijskom načinu rada najčešće nema 

većih problema, ali izvođenje obrade, te nadzor i praćenje što i kako se odvija često je nepoznanica. 

Zbog posebnosti web servisa mnogo se toga još mora unaprijediti i napraviti kako bi se moglo lakše 

rješavati poteškoće koje imaju krajnji korisnici s dugim vremenima odziva ili dohvata podataka. Sve 

što danas Internet dobro i loše pruža kod računarstva u oblaku mnogostruko je izraženo. Sigurnosni 

problemi koje donosi virtualizacija povezani su s činjenicom da su i virtualni sustavi ranjivi kao i 

stvarni. Sve je odlično dok je stanje prirodno, ali kad sustav krene nizbrdo, teško ga je vratiti u 

ravnotežu. Traži se brza prilagodba zahtjevima na tržištu. U stabilnim vremenima to je moguće, ali u 

uvjetima krize i stalnih promjena to postaje vrlo složeno. Da bi se čovjek približio virtualnom 

svijetu, u stvarnom svijetu mora stalno biti u središtu. Život na periferiji je život u pustinji – nema 

struje, nema vode, nema plina, nema podataka, nema informacija. Preostaje zadovoljstvo samo s 

onim što priroda pruža i kada to pruži. U stvarnom svijetu treba u pravo vrijeme biti na pravom 

mjestu. 

Sve je jače izraženo predviđanje da će računarstvo u oblaku postati izvjesnost. Ulažu se 

ogromna sredstva da tako bude, pa će tako i biti. Poduzeća će sve više koristiti računarstvo u oblaku 

za osnovne poslovne funkcije. Sve u informatici postaje neki oblik usluge – korištenje poslužitelja, 

memorije, skladišnih prostora, mrežne infrastrukture, aplikacija. Mogućnosti su sve veće, pa se oblici 

korištenja šire. 

Problem povjerenja postaje sve izraženiji u odnosima dobavljača i korisnika. Vjerovanje u 

poštenje šetnja je tamnom stranom ulice i uvijek pruža mogućnost prevare ili obmane. Kada netko 

drugi vrši nadzor i procjenu onda mu se može vjerovati, ali i ne, treba biti svjestan da u uvjetima želje 

za što većom zaradom istina nije sveta. Gdje je granica poštenja? Na granici s nepoštenjem. 

Nakon razdoblja centralizacije uvijek se jave želje i potrebe vraćanja prema decentralizaciji. 

Stvaralaštvo i znatiželja uvijek će izbacivati čovjeka iz strogih klišeja centralizacije. Bijeg od strogo 

organiziranog ustrojstva opet će tražiti nove prostore i rješenja. 

7. SVETI GRAL - OBLAK 

Nažalost danas informatika sve češće nije ni na nebu ni na zemlji. Poslovni zahtjevi i 

informatička rješenja sve više lutaju od idealnog ostvarenja do potpunog promašaja. U takvim 

uvjetima virtualnost i s njom stvoreno računarstvo u oblaku vratili su opet duh i dah mistike u 

informatičke tehnologije. Nude se obećanja da će računarstvo u oblaku pružiti mogućnost za 

ostvarenje i nemogućeg. U trenutku kada je informatika već počela gubiti svoju mistiku, otkrivši grubu 

stvarnost, stvoreni su novi preduvjeti koji vraćaju vjeru da se sve može napraviti. Često su zahtjevi i 

rješenja u informatičkim sustavima na granici znanstvene fantastike. Uvijek se tražio i traži sveti gral 

koji će biti onaj pravi perpetum mobile znanstvene misli. Oblak je zbog svoje nejasnosti i prividnosti, a 

istovremeno velikih potencijalnih obećanja postao za to idealan. Izgleda da je ovdje, a u stvari je samo 

iluzija. On ima svoju fizičku komponentu, ali je nedodirljiv. Oblak je samo simboličko predstavljanje 

mogućnosti s podjelom odgovornosti. Ponovo je sve vraćeno u područje simbola koje informatiku 

prekriva novim velom tajanstvenosti, obećavajući brda i doline, te što je korisniku najvažnije, život 

bez incidenata, bez problema i nerješivih stanja. Budi se optimizam jer će svi problemi nestati, a 

svi će se zahtjevi rješavati brzo i jednostavno. Opasnost je samo da se ne sakriju u Oblaku. 

Nastoji se izgraditi povjerenje i vjerovanje u sposobnosti Oblaka usmjeravanjem na ono što 

najviše nedostaje, a to su sigurnost, nadzor, odgovornost i privatnost. Intenzivno se radi na 

rješavanju nedostataka, pa će se tako sigurno doći do cilja ili će se bar uspjeti uvjeriti korisnike da 

mogućnosti postoje. Za sve one nevjerne Tome koji sumnjaju uvijek će se naći način kako ih 

potisnuti ili pritisnuti. Upornim ponavljanjem sve iluzije postaju opipljive i stvarne. 

Računarstvo u oblaku je prirodna evolucija rasprostranjenog usvajanja virtualizacije, 

uslužno orijentirane arhitekture, autonomnog i uslužnog računarstva. Krajnji korisnici, već 

odavno, a s Oblakom sve više nemaju potrebu za prevelikom i raznorodnom stručnošću ili brigu oko 

infrastrukture koja ih podupire. Računarstvo u oblaku je danas najbolji model za pokretanje 

informatičkih sustava izvan poduzeća. Riječ je o iznajmljivanju standardiziranih informatičkih 

sposobnosti – pamćenja, pohrane, procesne obrade, softvera na zahtjev, i sve to preko 

Interneta, dok se naplata obavlja na osnovu njihovog korištenja. Računarstvo u oblaku ima 

mogućnosti pružiti poslovanju brži, veći i izravniji pristup informatičkim resursima koji su postali 

sveti kaleži poslovnog računarstva. Čak i tvrtke koje prodaju informatičke usluge, kupuju dio onoga 

što im je potrebno preko Oblaka. Računarstvo u oblaku je u stvari uslužni program na koji se 

može lako i jednostavno priključiti. Mreže su vrlo značajan element u njegovom korištenju, pa 

njihova važnost postaje sve izraženija, ali zbog zahtjeva za kvalitetom, cijena sve više raste. 

8

ZAKLJUČCI 

Čak i onda kada davatelji usluge računarstva u oblaku riješe sva poznata kritična pitanja, 

ostati će ih još mnogo za rješavanje. Trenutno se tržište relativno dugo zadržava na istoj 

tehnologiji, a vrlo kratko na usluzi, pa će poduzeća trebati iskusne osobe koje će biti u stanju 

donijeti brzu i kvalitetnu odluku. Smanjivati će se potreba za posebnim stručnim znanjem, a rasti će 

zahtjev za kvalitetnim iskustvom u različitim znanstvenim područjima. Može li se znanje kupiti? 

Može. Može li se iskustvo kupiti? Ne može. Iskustvo treba izgraditi ili ga treba iznajmiti. 

Poduzeća uglavnom obavljaju više od jedne poslovne usluge, pa kada se neki programi budu 

premjestili u Oblak, a neki ostanu izvan, pojaviti će se problem njihove integracije. Ne može se 

neku uslugu postaviti u Oblak djelomično i onda očekivati istu razinu integracije kao da je sve na 

jednom mjestu. Složenija rješenja ostati će zato izvan Oblaka, ali će se jednostavnija sve više 

ugrađivati u njega. 

Dobre vijesti putuju brzo, ali loše putuju još brže. Dobre vijesti za računarstvo u oblaku su: 

donosi poboljšanja, pruža nove mogućnosti, a loše su: ostaje problem performansi, kritični su 

prekidi u radu. Značajan problem u informatičkim sustavima su performanse, ali tu često nije 

uzrok količina podataka, već rukovanje tim podacima – bilo programski, bilo pri korištenju. 

Pojednostavljenje procesa na mali broj aktivnosti postati će prioritetna zadaća. Web servisi 

pružaju veće mogućnosti, ali zahtijevaju da je način korištenja što lakši i razumljiviji. 

Kolikogod se pokušavalo dokazivati suprotno, računarstvo u oblaku ipak nije sasvim savršeno, 

a još manje je čarobni štapić kojim se u kratkom vremenu sve može riješiti. Već se kroz planove 

implementacije za zahtjevnije sustave može vidjeti da je predviđeno razdoblje za migraciju oko 6 

godina. Gdje li će tada biti informatička tehnologija? Ipak računarstvo u oblaku predstavlja 

danas Sveti Gral, čarobni lijek iscjeljenja za bolesnu informatiku. 

Virtualizacija treba osigurati put kojim će se kretati rješavanje zahtjeva, ali veća uspješnost 

pokazala se samo kod jednostavnijih slučajeva. Ukoliko se radi o računalno zahtjevnijim primjenama, 

virtualizacija može više štetiti nego li koristiti. Računarstvo u oblaku pogodno je za sustave koji su 

manje iskorišteni. Glavna značajka virtualizacije je ekonomičnije korištenje resursa i opreme. 

Poseban problem može nastati ako davatelj usluge propadne, a nažalost i to se događa. 

Oblikuju se različite vrste organizacije Oblaka. Privatni Oblak doživljava kritiku lošeg rješenja jer ga 

treba kupiti, graditi i održavati, a osim toga vrlo je sličan današnjem načinu organizacije data centara. 

U želji da se zadivi i time pridobije korisnika da ustraje na putu korištenja, planira se izgradnja 

Oblaka svih Oblaka koji se naziva Intercloud. Pretpostavlja se da će on postati data centar 

budućnosti. 

Postoji stalna težnja savršenstvu koju čovjek nažalost nije u stanju postići čak ni virtualno. 

Potreba da se viđeno sačuva, da se prodiskutira s nekim, da se u slučaju nerazumijevanja ponovi 

čitanje, znači da zabilješka o povijesti mora postojati. Računalo treba dio za zapis (pohranu), a onda i 

dio za obradu tog zapisa (procesor), a preko zaslona i tipkovnice opet nastaje potreba za dosadašnjim 

načinom komunikacije kolikogod je on promijenjen novim načinom korištenja preko osjetljivih zaslona 

na kojima se sve obavlja na dodir. Čovjek zbog ne savršenosti i ne sposobnosti da brzo obrađuje 

veliku količinu podataka, da ju dugotrajno pamti morati će opet iznova tražiti iste, već tražene 

stvari. Istina davatelji usluge će upravo na tome graditi i svoje trajanje i svoje bogaćenje. Neznanje je 

stvarnost i dok jednome stvara prihod drugome je trošak. Međutim, znanje je virtualno – prividno i 

ponekad mu je prihod jednak nuli. Vrijednost ima samo ono znanje koje se može naplatiti, sve ostalo 

je bezvrijedno odnosno neiskorišteno znanje koje ima samo prividnu vrijednost odnosno sadrži 

potencijal koji može ostati neupotrebljen, pa tako i ne stvoriti prihod. 

U razvijenim zemljama sve se više sredstava ulaže u informatičku sigurnost. Povjerenje 

između isporučitelja i korisnika postaje sve važnije. Težnja prema stvaranju sigurnosti traži 

povjerenje, ali osobe iz sigurnosti takav način ne zadovoljava. Zahtjevi na mrežu postaju sve složeniji. 

Sporazum o razini isporuke usluge pruža mogućnost da se obveze propišu, ali u slučaju njihovog 

neispunjavanja nikada se ne dobiva prava naknada za nastale probleme. Ovisnost o isporučitelju 

stvara se svakim izborom. Vjerovanje može vrlo brzo i jednostavno svaku stvarnu sliku događaja 

pretvoriti u virtualnu – prividnu. Ne uklanja se rizik u informatici novim pojmovima, već se samo 

mijenja priroda rizika. 

Završava li opskrba informacijama upravo na svojoj sličnosti s opskrbom vode, struje, plina? 

Rješenja za sve informatičke zahtjeve trebaju čekati neka strožija pravila u kojima će informacije 

postati jednoznačne i oslobođene mogućnosti mijenjanja. Sužavanjem izbora i stvaranjem 

ovisnosti o takvim pravilima nestati će mnogobrojni današnji nedostaci. 

9

Dozvoljeni uvid u ograničeni skup informacija uz ograničavanje dozvoljenog biti će prvi 

korak prema stvaranju sigurnosti, koja je inače rak rana računarstva u oblaku. Kod slučajeva u 

kojima se samo obavlja pristup informacijama najlakše je i najjednostavnije riješiti pitanje 

zaštite i sigurnosti. Upisivanje nudi veće mogućnosti za nedozvoljene aktivnosti. Mijenjanje već 

donosi opasnost da se podaci prepravljaju. Brisanje pruža najveći rizik i jedino se 

pravovremenim zaštitnim kopiranjem podatke može sačuvati od neplaniranog uništenja. 

Živimo u dinamičnom svijetu transakcija u kojem informacije putuju i razmjenjuju se velikom 

brzinom. Pristup informacijama je sve brži, ali poslovi sakupljanja podataka i njihova obrada 

ostaje ipak i dalje u posjedu informatičkih službi. Odlazak u područje Web usluga je poput odlaska 

u dućan – može se donijeti kući mnogo namirnica, ali se još uvijek nakon toga mora napraviti večeru. 

CASE alati u vrijeme kada su se pojavili izgledali su kao nova budućnost programiranja i 

lagan način za rješavanje svih zahtjeva poslovanja. Prijetili su čak ukidanju zvanja – programer. 

Međutim, samo su korisno poslužili u jednom razdoblju i postepeno su zamijenjeni novim metodama i 

alatima. 

Oblak danas prijeti da u potpunosti promijeni stvarnost informatike, ali ograničenja koja u 

njemu postoje pokazuju da će mnogo toga morati i u njemu biti promijenjeno da bi zadovoljilo 

potrebe koje poslovanje postavlja pred informatiku. O tome koliko se Oblak uspije prilagoditi ili 

koliko uspije prilagoditi informatiku ovisi njegov životni vijek. Prilagodba je uvijek pružala 

priliku za uspješnost u evoluciji, pa će i računarstvo u oblaku opstati koliko se uspješno uspije 

prilagođavati novim zahtjevima i potrebama poslovanja. 

Dodatni izvori: 

1. Michael Miller, Cloud Computing – Web-Based Applications That Change the Way You Work and 

Collaborate Online, Que Publishing, 2009. 

2. Anthony T. Velte – Toby J. Velte – Robert Elsenpeter, Cloud Computing – A Practical Approach, 

Mc Graw Hill, 2010. 

3. Eric A Marks – Bob Lozano, Executive's Guide to Cloud Computing, John Wiley & Sons, Inc, 

2010. 

4. Bill Thompson, Storm Warning for Cloud Computing, BBC News, 2008. 

5. David Rosenbaum, Can Cloud Computing Clear the Air, CFO Magazine, 2011. 

6. Bernard Golden, Cloud Computing: 2011 Predictions, CIO US, 2010. 

7. Vincent Ryan, A Place in the Cloud, CFO Magazine, 2008. 

8. Pat Romanski, Virtualization – The Engine That Enables Cloud Computing, Sys-Con Media, 2011. 

9. Jill Tummler Singer, Is Cloud Computing for Real?, Sys-Con Media, 2011. 

10. Wikipedia – (preuzeti različiti termini i pojmovi) 

10

Rajko Kuzma, dipl. ing. 

Intesa Sanpaolo Card d.o.o. 

Lastovska 23 

10000 Zagreb 

099 231-7180 

rajko.kuzma@intesasanpaolocard.com 

www.intesasanpaolocard.com 

KONTINUIRANO NADZIRANJE KVALITETE RAZVOJA ORACLE APLIKACIJA 

SAŽETAK 

Životni vijek Oracle aplikacije počinje sa strategijom koja definira svrhu aplikacije. Proteže se od 

dizajna aplikacije, preko razvoja pa sve do zadovoljstva njenim korištenjem od strane krajnjeg 

korisnika. Cilj je kontinuirano pružiti podršku svim segmentima životnog vijeka aplikacije, što uključuje 

mjerenje kvalitete usluge, od funkcionalnih, pa sve do performansnih testiranja. Prepuštanje kvalitete 

slučaju je neprihvatljivo rješenje, dok je ručno provjeravanje funkcionalnosti Oracle aplikacija vrlo 

često nezadovoljavajuće. Ova prezentacija će prikazati metode automatizacije i podrške Oracle 

razvojnom timu za funkcionalna testiranja produkcijskih verzija, odnosno, performansna mjerenja 

odziva Oracle aplikacija. 

CONTINUOUS MONITORING OF ORACLE APPLICATION DEVELOPMENT 

QUALITY 

SUMMARY 

Oracle application life cycle starts with the strategy that defines purpose of application. It 

stretches over application design, through development and ends with the customer satisfaction. The 

goal is to continuously provide support to all segments of application cycle, including quality of service 

measurements, from functional to performance testing. Leaving application quality to a chance is 

unacceptable, while testing application functionalities manually is often not satisfactory. This 

presentation will show methods of testing automation and support to Oracle development team for 

production application versions functional testing and application response measurements. 

11

1. UVOD 

U referatu su opisani načini kako pružiti maksimalnu podršku kvaliteti Oracle aplikacija. Kako sa 

ovim metodama napraviti spregu između dizajna aplikacije i samog mjerenja kvalitete. Kako pružiti 

podršku u svim stanjima života Oracle aplikacije te primjer kako je ovo implementirano u tvrtci Intesa 

Sanpaolo Card. 

2. STRATEGIJA I DIZAJN 

Poznato je da se u svijetu informatike koriste razne metodologije kako pristupiti problemu izrade 

nove aplikacije. Tako danas svi teže ITIL procesu, pa tako i mi isto primjenjujemo ITIL metodologije da 

zadovoljimo sve potrebe radi implementacije i održavanja života aplikacije. 

Strategija, koja se proteže preko područja koja raspolažu prikupljenim informacijama o uslugama, 

potražnji, financijama i rizicima, mora znati da rezultat mora biti zadovoljavajući. Odnosno, predvidjeti 

sredstva da se to može, što korisnik traži i zadovoljiti. 

Dizajn, koji bolje raspolaže informacijama o samoj arhitekturi i mogućnostima što se može 

implementirati, treba predvidjeti da se u sljedećim fazama razvoja moraju obavljati testiranja. Ta 

testiranja se sastoje redom od unit testiranja, integracijskih, pa sve do nekih stres testiranja. Često se 

nakon integracije, od kompleksnosti same razvijene aplikacije ne može elegantno pronaći uzrok 

pronađene greške ili se premalo posvećuje ovome. Zato je vrlo bitno da sam proces dizajna predvidi 

mjerne točke u modelu izrade same Oracle aplikacije. 

3. TRANZICIJA 

Proces tranzicije se svodi na modifikaciju aplikacije u produkcijskom okruženju. Odnosno, 

primjenjuje se change management procedura, koja je usko povezana sa release i deployment 

managementom. Da se proces tranzicije uredno obavi, potrebno je imati prikupljene podatke za bazu 

znanja. To su razne dokumentacije o novim, odnosno, promijenjenim funkcionalnostima same 

aplikacije. 

Do procesa tranzicije se može doći tek tada kada su svi preduvjeti stavljanja nove verzije Oracle 

aplikacije zadovoljeni. Sve promjene koje će se raditi nad Oracle aplikacijom su unaprijed najavljene, 

te je sam korisnik obaviješten o toj akciji. 

4. OPERACIJE 

Nakon procesa tranzicije, aplikacija se daje na korištenje. Sve radnje koje korisnik treba odnosno 

smije raditi se ovdje mogu modificirati. To su razna prava pristupa, upravljanja problemima u radu kao 

i kritični problemi s radom, tj. incidentima. 

Slučaj detekcije problema nad Oracle aplikacijom od strane korisnika nije baš dobrog karaktera. 

Već ovo ukazuje da prethodni koraci koji su prethodili dijelu operacija (strategija, dizajn, tranzicija) nisu 

dovoljno dobro pokrili sve situacije s kojima se korisnik susreće. 

5. KONTINUIRANO UNAPRIJEĐENJE 

Spomenute četiri glavne cjeline nisu sva područja koja se bave ciklusom života Oracle aplikacije. 

Potrebno je proaktivno pratiti život i ponašanje Oracle aplikacije i obrađivati sve te informacije. 

Ciklus prikupljanja informacija ovdje ne završava, već se daju smjernice prema strategiji. Takvo 

definirano ponašanje opisuje Slika 1. 

12

Slika 1 ITIL v3 pojednostavljena shema 

Vidljivo je da su svi koraci međusobno isprepleteni te jedni ovise o drugome. Kao što je u poglavlju 

ranije navedeno, potrebno je imati pripremljene točke za mjerenja. Ovime se, kao adapterom, 

možemo spojiti na kritične dijelove Oracle aplikacije i time raditi određena mjerenja kvalitete. 

6. RAZVOJ I IMPLEMENTACIJA 

Kada se specifikacija za promjenu ili za novu implementaciju Oracle aplikacije napiše, po njoj je 

potrebno raditi razvoj tih specificiranih funkcionalnosti. U toku razvoja, razvojni inženjer radi lokalno, 

tokom implementacije, svoja vlastita testiranja. Takva testiranja su tzv. unit testiranja. 

U tvrtci Intesa Sanpaolo Card u razvoju Oracle aplikacija rade nekoliko desetaka razvojnih 

inženjera. Paralelno traje razvoj za više projekata, te je vrlo važno raditi kvalitetna testiranja. Stoga je 

potrebno kontinuirano raditi kontrolu kvalitete razvijenih funkcionalnosti. Ovdje unit testiranja dosežu 

svoj limit, te je potrebno provjeravati kompleksnije funkcionalnosti. 

U narednim poglavljima će biti riječi o tipovima testiranja kao i prednosti pojedinih grupa. 

6.1. Unit testiranja 

Standardni razvoj Oracle aplikacija podrazumijeva testiranje funkcionalnosti u trenutku 

implementiranja. Dokumenti koji proizlaze kao rezultat testiranje je excel tablica sa pobrojanim 

funkcionalnostima iz same specifikacije sa pripadnim rezultatima. 

Često se testiraju samo ključne točke Oracle sustava te je vrlo šturo. Akcije koje se rade nad 

Oracle aplikacijom rade se ručno. Ovo traži jako puno vremena, pa je očito da razvojni inženjer sam 

procjeni što je potrebno testirati te na koji način. Uz ovo, često se zna dokumentacija nekvalitetno 

odraditi, te nije potpuno pouzdana, tj. ne pokriva sve testne slučajeve. 

Slika 2 predstavlja primjer dokumenta koji proizlazi iz unit testiranja. Vidljivo je da boja 

statusa definira rezultat testnog scenarija, ispravan ili krivi. 

13

Ime testa korak detalji status 

start 1 

login 2 

pokretanje Oracle 

aplikacije OK 

prijava na Oracle 

aplikaciju OK 

AMEX pin 

zadavanje promjene pina 

za American express 

change 3 karticu OK 

stop 4 logout OK 

start 1 

login 2 

promjena 

matičnih 

podataka 3 

pokretanje Oracle 

aplikacije OK 

prijava na Oracle 

aplikaciju OK 

promjena prezimena, 

djevojačko prezime KO 

stop 4 logout OK 

Slika 2 Ručna unit test dokumentacija 

Također se teško iz dokumenta vidi, što i na koji način su napravljeni testovi. 

6.2. Integracija 

Integracija Oracle kôda se svodi na prikupljanje svih izlaza što razvojni inženjeri proizvedu. U 

velikom timu inženjera, version control sustav puno pomaže u tome. Uz ovo, potrebno je izolirati 

integracijsku okolinu od razvojne okoline. 

Objedinjuje se cijeli programski kôd u jedan kumulativni patch koji se kontrolirano spušta na tu 

Slika 3 Osnovne 3 podjele okolina 

14

izoliranu okolinu. Slika 3 predstavlja osnovni pregled podjela i izolacija okolina. Vidljivo je da su 

međusobno neovisne, potpuno odvojene okoline. Nakon objedinjenja programskog kôda koji radi 

promjene nad bazom, isti princip se odnosi i na Oracle Forme. Njih korisnik napada, odnosno, one su 

vidljiv dio Oracle aplikacije od strane krajnjeg korisnika. 

Slika 4 Proces promjena 

Build management sustav u procesu tranzicije osigurava samo da se odabrane promjene 

(kumulativni patch) baznih objekata i Oracle Forme uspješno apliciraju. Ova automatika radi kontrolu 

ispravnosti kôda, dok se kontrola funkcionalnosti mora raditi u odvojenom procesu. 

Generalno, testiranje koordinira Quality Assurance (QA) team. Sve što developeri isporuče na 

integracijsku okolinu, biva u nekom obliku testirano. 

Kasnije u ovom dokumentu će biti više riječi o načinu automatizacije provjere funkcionalnosti 

Oracle (Forms) aplikacije. 

6.3. User Acceptance Test 

User Acceptance Test, skraćeno UAT, je finalna provjera svih definiranih testnih slučajeva koje 

promijenjena ili nova Oracle aplikacija mora podržavati. U pravilu ovo je masovno testiranje svih 

funkcionalnosti koje općenito Oracle aplikacija mora podržavati. Ova testiranja rade sami korisnici. 

Izlazni dokument je dokumentacija koja potvrđuje da je Oracle aplikacija preuzeta na način da 

podržava sve funkcionalnosti koje su definirane funkcionalnom specifikacijom, odnosno, zahtjevima 

korisnika. 

Također, ako korisnik opravdano pronađe grešku, zahtjev za popravak ide prema razvojnom 

inženjeru koji traži uzrok problema. Nakon popravka problema, slijede svi koraci koji su prethodili do 

samog UAT testiranja, te se obavještava korisnik da je dotična greška uspješno uklonjena. 

6.4. Performansno testiranje - stres test 

Svaka promjena nad Oracle aplikacijom, bilo arhitekture tablica, programskog kôda, ili samih 

formi, direktno utječe na brzinu Oracle aplikacije. Često se desi problem da na razvojnim i testnim 

okolinama aplikacija radi zadovoljavajućom brzinom, neobraćajući pažnju na to da u Oracle bazi nema 

pravih produkcijskih podataka kao i dovoljan broj korisnika koji paralelno rade. 

15

Često upiti koje rabe korisnici Oracle izvađa po krivim indexima, odnosno, radi full table scan nad 

velikim tablica. Zato postoje dodatne provjere Oracle aplikacija prije nego li takva promjena dođe do 

produkcijske okoline. 

Zbog toga je potrebno provesti simulaciju korištenja Oracle sustava, cijele Oracle aplikacije, sa 

realnim opterećenjem. Raditi generiranje realnog prometa nad kopijom Oracle baze, te u pozadini 

raditi razna mjerenja. Sistemaši i DBA rade mjerenja nad samom bazom i Oracle serverom, mjere 

raspoloživost procesora, memorije, broj I/O operacija i slično. S druge strane, rade se end-to-end 

mjerenja odziva same akcije nad Oracle sustavom. To su primjerice pokretanje aplikacije, prijava na 

aplikaciju, set osnovnih odnosno Sigle Point of Failure akcija. 

Na kraju je potrebno analizirati podatke, tj. usporediti ih sa prethodnom analizom. Tako se može 

predvidjeti ponašanje Oracle sustava u produkcijskom okruženje nakon primjenjenog kumulativnog 

patch-a. 

6.5. Monitoring Oracle aplikacije u produkcijskom okruženju 

Nakon što sve promjene "sjednu" u produkcijsku okolinu, nije kraj provjeravanju kvalitete Oracle 

aplikacije. Praćenje, tj. monitoriranje se mora konstantno raditi. Razlog je jednostavan. Tvrtka koja 

daje usluge na Oracle sustavu, partnerima daje na znanje da će sustav raditi u dogovorenim 

granicama. Stoga iznenadni padovi uslijed npr. zagušenja sustava daje pokaz na nepuzdanost 

sustava. Ako se pružatelj usluge i partner dogovore o određenim stvarima što očekuju od Oracle 

aplikacije, onda međusobno potpisuju Service Level Agreement - SLA ugovor. Naravno, kod 

neočekivanog ispada kao i neisporučivanje primjerice datoteka na vrijeme uslijed kašnjenja, mogu se 

plaćati i penali, koji naravno, nisu nikada korisni (pa niti za onoga koji bi dobio taj iznos). Cilj 

permanentnog monitoriranja je imati maksimalno moguće dostupnu aplikaciju, te uslijed neočekivane 

greške u najmanjem mogućem roku otkriti uzrok te isti popraviti. 

7. RAZVOJ I IMPLEMENTACIJA SKRIPTI ZA AUTOMATSKO TESTIRANJE 

Na tržištu postoje razni alati koji podržavaju automatsko testiranje. Njih je moguće podijeliti u 

dvije glavne skupine, u alate za funkcionalna testiranja i u alate za mjerenje performansi. 

Ranije u prethodnim poglavljima piše se o vrstama testiranja. Ovdje će biti naglasak samo o 

automatskim testiranjima koje se primjenjuju na Oracle (Forms) aplikaciji, odnosno, svi testovi i 

mjerenja će biti rađeni preko Oracle GUI strane odnosno Oracle Forme. 

Slika 5 Okolina za automatsko testiranje Oracle aplikacija 

Naglasak je na Oracle Forms aplikaciji. Potrebno je dobro proučiti da li odabrana platforma 

podržava testiranje nad Oracle aplikacijom. Oracle nudi rješenje za testiranje Oracle aplikacija, no 

postoji razne zamke da taj sustav ipak to ne može raditi. Treba se uvjeriti da li je aplikacija za 

16

testiranje kompatibilna sa Oracle Forms serverom. Da li podržava verziju Oracle jInitiatora, ili je za 

novijeg interpretera, Sun Native javu. Potrebno je voditi i računa o širini automatizacije. Da li interface 

koji radi prikupljanje podataka želimo testirati te da li taj alata podržava i tu tehnologiju. Analizom svih 

tih podataka dolazimo do specifičnog seta alata koji sve to što pojedinoj tvrtci treba. 

Slika 5 prikazuje arhitekturu okoline za automatsko testiranje. Postoji centralni aplikacijski server, 

Oracle repozitorij te fizičke instance virtualnih korisnika. To su obično radne stanice sa kojih se 

pokreću funkcionalna i performansna testiranja. Vidljivo je da QA team vodi brigu o setu testova koji 

će se pokrenuti na željenoj Oracle instanci, tj. aplikaciji spremne za testiranje. 

7.1. Funkcionalna testiranja 

Za funkcionalna testiranja je potrebno imati potpuno izoliranu okolinu. Potrebno je osigurati da 

nitko slučajno ne radi razvoj, jer to ima direktan negativan utjecaj na rezultat funkcionalnih testiranja. 

Poželjno je prije samog testiranja i primjene novog kumulativnog patch-a, što razvojni inženjeri 

kreiraju, napraviti osvježavanje okoline. Pod osvježavanjem se misli napraviti okolinu identičnom 

kakva će biti produkcijska nakon primjene tog istog kumulativnog patch-a. 

Orkestriranje testova rade QA inženjeri u direktnoj suradnji sa implementatorima Oracle 

aplikacije. Cilj je napraviti što veći broj različitih testova te ih imati spremne u repozitoriju automatskih 

testiranja. Ako sustav i vrijeme dozvoljavaju, poželjno je raditi takozvane noćne testove. Sve promjene 

koje razvojni inženjeri rade i imaju spremno za isporuku, dobro je što ranije testirati. 

Alati za automatsko testiranje upravo ovo gore spomenuto podržavaju. Imaju bazu testova koje je 

moguće elegantno pokrenuti nad željenom okolinom. Rezultat izvođenja testova je taj, da se za svaki 

test vidi da li je funkcionalnost ispravna ili nije. U slučaju da nije, QA inženjer istražuje pomoću loga 

testa što je uzrokovalo pad dotične testne skripte, te taj isti slučaj prijavljuje razvojnom inženjeru da 

popravi. U međuvremenu, QA inženjer ima pravo da zabrani stavljanje dotičnog lošeg programskog 

koda u produkcijsko okruženje. 

17

Slika 6 Primjer loga funkcionalnog testa 1 i detalji 

Kod dizajna i pisanja automatskih testova potrebno je voditi brigu o ponovnoj iskoristivosti testnih 

skripti. Primjerice to su skripte za pokretanje Oracle aplikacije, prijavu testnog korisnika u aplikaciju, 

odjava i gašenje aplikacije. 

Same skripte trebaju pratiti osnovna načela programiranja, ne raditi redundantnost kôda. Primjer, 

ako Oracle aplikaciju koriste više tržišta, potrebno je preko iste testne skripte moći testirati Oracle 

aplikaciju za različita tržišta. 

Slika 7 Primjer loga funkcionalnog testa 2 i detalji 

Slika 6 i Slika 7 prikazuju primjer izlaznog reporta iz različitih sustava za testiranje Oracle 

aplikacija. Vidljivo je da je došlo do greške, kao i opis greške. 

18

7.2. Performansna testiranja 

Slično kao i kod funkcionalnih testiranja, potrebno je imati potpuno izoliranu okolinu. Da bi 

mjerenja bila realističnija, potrebno je imati potpuno identičnu performansnu okolinu kao i 

produkcijsku. U to ulaze podaci u tablicama, podatak o broju istovremenih korisnika, isto hardware-sko 

okruženje – database server s isto memorije i procesorske snage te isti mrežni segmenti između 

performansne baze i sustava za performansno testiranje u odnosu na krajnjeg korisnika i 

produkcijskog Oracle okruženja. 

U sustav za generiranje virtualnih korisnika potrebno je dovesti scenarij testiranja. Ovdje već 

uveliko pomaže baza funkcionalnih testova. Sve što je potrebno napraviti je da se ti testovi 

transformiraju u određeni oblik. 

Drugi parametar koji je vrlo važan, koliko istovremenih upita nad Oracle bazom je potrebno 

simulirati. Također, prilikom dizajniranja testnih performansnih scenarija moguće je definirati redoslijed 

testova. Primjerice, deset korisnika istovremeno rade neki posao slijedno, dok u željenom koraku 

želimo istovremenu napasti najveću tablicu u bazi, tj. napraviti stres test Oracle sustava. 

Tako prikupljeni podaci služe za analizu ponašanja Oracle sustava, da li se ubrzava ili usporava, 

odnosno, testirati možemo i maksimalni broj korisnika, dok Oracle sustav ne dođe u stanje 

preopterećenosti (capacity planning). 

7.3. Monitoring produkcijskog okruženja 

Sustav za performansno mjerenje moguće je prilagoditi na način da radi provjeru produkcijskog 

okruženja. Potrebno je napraviti tzv. ping svih akcija što mora apsolutno konstantno biti funkcionalno. 

Stoga sustav za praćenje radi kontrolu i istu informaciju zapisuje u nekom definiranom obliku i Oracle 

tablicu. 

Slika 8 Zapis mjerenja odziva 

Slika 9 GUI operativna konzola 

Slika 8 prikazuje dio tablice u Oracle bazi sa zapisima o prikupljenim podacima o odzivu pojedine 

Oracle Forme. Ista informacija je proslijeđena operativnom agentu koju prati ponašanje cijele 

informatičke infrastrukture (Slika 9). Ako se nadmaši, odnosno, ako dotična akcija traje više od 

definirane prve granice, operateru se prikazuju to na grafičkoj konzoli putem žute boje na objektu koji 

definira to mjerenje. Slično je ako je došlo do ispada ili do prevelikog usporenja, operateru se na 

konzoli prikazuje informacija i aktivira alarm i to automatskim putem. 

19

8. ZAKLJUČAK 

Danas je neprihvatljivo rješenje kvalitetu Oracle aplikacije prepustiti slučajnosti. Zbog raznih 

ugleda tvrtke koja pruža uslugu na Oracle aplikaciji, ne može si priuštiti ispad Oracle aplikacije, 

prvenstveno zbog financijskih gubitaka. Ozbiljne tvrtke poput Intesa Sanpaolo Card-a sa svojim 

partnerima potpisuje Service Level Agreement ugovore u kojima se obvezuje da će dostupnost 

aplikacije i isporuka određenih podataka biti u okviru dogovorenih granica. Sve te provjere je potrebno 

imati u realnom vremenom. Stoga je potrebno puno pažnje posvetiti kontroli kvalitete Oracle aplikacija 

u dizajnu, kao i u fazi razvoja. Maksimalno svu snagu treba dati na predprodukcijskim testiranjima te u 

bilo kakvim neočekivanim produkcijskim problemima imati informaciju o ispadu u najkraćem mogućem 

roku radi što bržeg popravka. 

20

CIJENA APLIKACIJE – ZAŠTO SOFTWARE TOLIKO KOŠTA? 

APPLICATION PRICE – WHY DOES SOFTWARE COST SO MUCH? 

Dubravka Mendeš Poljak 

Grad Zagreb 

email: dmpoljak@zagreb.hr 

SAŽETAK 

Danas, više nego li prije postaje izuzetno važno bilo za onoga koji kupuje ili onoga koji 

izraĎuje aplikaciju znati konačnu cijenu kao i objasniti odnosno opravdati navedeni iznos. Rad je 

prvenstveno usmjeren na prikaz korištenih načina mjerenja razvoja aplikacija, te u konačnici 

objašnjava na koji način se utvrĎuje cijena. Biti će prikazano nekoliko metrika i alata korištenih za 

procjenu troškova i pregled njihovih osnovnih mogućnosti. Nadalje biti će prikazani i rezultati 

istraživanja provedenog na hrvatskom tržištu sofwerskih kuća i način na koji oni vrše procjenu 

troškova. Nadalje prikazat će se kako procjena utječe na uspjeh projekta i u kojoj mjeri ona utječe na 

prekid razvoja. 

Today, more than ever it becomes extremely important for anyone who buys, or makes an 

application to know the final price as well as to explain or to justify that amount. The work is primarily 

focused on the presentation of used application development metrics, and ultimately explains how to 

determine price. Several metrics and tools used to estimate costs will be shown, and their basic 

features. Furthermore the results of research conducted on the Croatian market software houses and 

the way they assess the costs will be presented. Furthermore it will be shown how cost estimation can 

have impact on project success and how they influence the result of the final software product. 

UVOD 

Do kasnih 70-ih godina, razvoj softverskih proizvoda mjerio se kroz vrijeme i materijal. Radilo se o 

naplati pruženih i dostavljenih usluga. Pod tim se podrazumijevao napor uložen u razvoj, izražen kroz 

mjesece projektnog tima, koji je radio na projektu. Taj se napor zbrajao sve do isporuke softvera i do 

prihvaćanja od strane korisnika. Na taj način, kupac je ovisio o isporučitelju i njegovom uspjehu da u 

razumnom roku završi projekt. Mjerenje se izražavalo u dostavljenim linijama koda. Takvo se mjerenje 

i danas koristi, no u manjoj mjeri. Afirmacijom i razvojem novih programskih jezika, posebice objektnih 

jezika, nove metrike ostvaruju više uspjeha na području procjene troškova razvoja softverskih 

proizvoda. 

U današnjem tržišnom društvu, borba za prevlast i pridobivanje kupaca vrlo je značajna. ProizvoĎači 

trebaju biti konkurentni i maksimalno prilagodljivi kupcu. Današnja usluga mora pružiti više 

funkcionalnosti uz što niže cijene te opstati na tržištu. No proizvoĎači softvera i njihovi kupci oduvijek 

su se nalazili u nezavidnoj poziciji, jer utvrĎivanje cijene predstavlja „crnu kutiju“, budući da se softver 

ne može mjeriti jedinstvenim i fiksnim mjerama već se utvrĎivanje njegove cijene i ostalih troškova 

temelji na procjeni. Kod ostalih proizvoda cijena se obično utvrĎuje nakon što je proizvod izraĎen, no 

kod softvera se vrlo često dogaĎa da je cijenu potrebno utvrditi prije negoli je sam softver napravljen i 

to bez poznavanja svih ključnih faktora koji su potrebni za njegovu izradu. Iz navedenog se vidi 

važnost utvrĎivanja što realnije procjene utrošenih resursa jer lošom procjenom sam razvoj projekta 

dolazi u pitanje, a gubitak resursa to samo slijedi. 

Kako bi procjena bila što pouzdanija i mogla se primjeniti na različite korištene programske jezike i 

alate razvijaju se brojne metrike i alati za procjenu koji služe kao podrška u planiranju i utvrĎivanju 

potrebnih i utrošenih resursa na razvoju jednog projekta. 

21 

1

FAKTORI UTJECAJA NA TROŠKOVE SOFTVERA 

Da bi se uopće postiglo i razumjelo odreĎivanje procjene troškova razvoja, potrebno je prikupiti i 

analizirati čitav niz faktora koji direktno utječu na odreĎivanje troškova izrade softvera. Osnovne 

faktore za bilo kakvu procjenu neizostavno čine veličina, rok, kvaliteta i uloženi napor. Bez utvrĎivanja, 

razmatranja i definiranja vrijednosti ovih faktora, procjena nije moguća, a odreĎivanje troškova razvoja 

softvera je nepouzdano i gotovo nepostojeće. Osim ovih osnovnih faktora na cjelokupnu procjenu u 

pravilu utječe voše od 50 različitih i meĎusobno povezanih faktora. 

Većina studija danas pokazuje da se softverski proizvodi prekidaju zbog loše ili preambiciozno 

definiranih ciljeva. U provedenom istraživanju utvrĎeno je da se 46% anketiranih softverskih kuća u 

Hrvatskoj našlo u situaciji da su morali prekinuti s razvojem softvera, a 66% njih, kao razlog, navode 

lošu procjenu izvodljivosti. Obzirom da na lošu procjenu utječu kritični faktori, koji su loše ili 

preambiciozno definirani, oni su razlog što dolazi do kašnjenja u realizaciji projekata, što pak rezultira i 

povećanjem troškova njegove izrade. U navedenom se očituje važnost dobre procjene svakoga od 

pojedinačnih faktora, kako bi utjecali na donošenje pouzdane procjene. 

METRIKE ZA PROCJENU TROŠKOVA RAZVOJA SOFTVERSKIH PROIZVODA 

Svaki softverski projekt ima svoj početak i kraj. Softverski projekt započinje idejom, odreĎenim 

zahtjevima korisnika za zadovoljavanje neke potrebe. Kraj je realizacija tih ideja i potreba u obliku 

odreĎenog softverskog proizvoda, prihvaćenog od strane korisnika ili pokretača projekta. Ako 

promatramo taj razvoj, kao nepoznati put kojega je potrebno prijeći od jedne do druge točke, teško da 

će se tamo stići u zadano vrijeme, ili se uopće neće stići, ako se ne koriste neki od dostupnih 

pomagala kao što su kompas ili danas popularni GPS. Analogno tome, da bismo razvili kvalitetan 

softverski proizvod u zadanom vremenu i uz planirane troškove, umjesto kompasa koristit ćemo 

dostupne metrike, kao pomoć pri postizanju toga cilja. 

Korištenje metrika pretpostavlja upotrebu različitih metoda mjerenja, čime se softverski proizvodi 

unapreĎuju u pogledu razvoja. Mjerenje, upotreba i korištenje brojeva, te praćenje napretka, 

predstavljaju neizostavan dio ovog procesa. 

Jedna od definicija prepoznaje softverske metrike kao neprekidnu primjenu tehnika za mjerenje 

razvoja softvera i njegovih produkata, radi prikupljanja značajnih i u odreĎeno vrijeme potrebnih 

informacija za unapreĎenje procesa razvoja softvera i njegovih produkata. 1 

Kao i u ostalim područjima, tako je i kod metrika jedna od osnovnih funkcija prikupljanje podataka. 

Naravno, radi se o ciljanom prikupljanju podatka, relevantnih za područje koje se procjenjuje. Cilj nije 

prikupiti ogroman broj podataka, već dovoljan broj podataka koji će dati potrebne parametre i 

obrazloženja uočenih trendova. Osnovno pitanje nakon prikupljenih podatka jest što ti podaci govore? 

Podaci sami sebi nisu svrha, potrebno ih je aplicirati na okolinu u kojoj ih prikupljamo, promatramo i 

primjenjujemo. Iz njih trebamo dobiti odgovore na pitanje zašto se nešto dogaĎa, čak i ako je dobiveni 

odgovor na prvi pogled trivijalan, poput obrazloženja da projekt kasni jer je bio kvar na središnjem 

računalnom sustavu i programeri nisu mogli raditi na svojim radnim stanicama. 

„Korištenje softverskih metrika ne osigurava preživljavanje, ali povećava vjerojatnost preživljavanja“, 

ovom izjavom Paula Goodmana najbolje se očituje vrijednost i snaga upotrebe dostupnih metrika. 

Neke od dostupnih i najčešće korištenih metrika su slijedeće: 

Metrike temeljene na linijama koda 

Funkcijske točke ( i njihove brojne inačice) 

Objektne točke 

Story points 

Use Case Points 

Neuralne mreže 

1 Goodman, Paul: Software Metrics, Rothstein Associates Inc., 2004., str. 6 

22 

2

ALATI ZA PROCJENU TROŠKOVA RAZVOJA SOFTVERSKIH PROIZVODA 

Danas na tržištu postoji oko 50-ak komercijalnih alata za procjenu razvoja softverskih proizvoda. 

Mnogi od njih predstavljaju crne kutije, jer njihove korištene tehnike i način upotrebe nisu obrazloženi. 

Alati su se razvili kako bi na automatizirani način pratili razvijene modele procjene. Njihova osnovna 

funkcija uključuje procjenu vremena potrebnog za izvršavanje pojedinih aktivnosti kroz životni ciklus 

softvera, podršku za procjenu, temeljenu korištenjem funkcijskih točaka ili linija koda te, u novije 

vrijeme, podršku za upotrebu novijih korištenih tehnologija, razvojem objektno orijentiranih tehnika te 

korištenje programskih jezika poput Jave i Visual Basica, kao i web orijentiranih aplikacija. Alati su 

prvenstveno namijenjeni unapreĎenju kvalitete i produktivnosti bilo kojeg procesa uključenog u razvoj 

softvera. Nedostatkom konzistentnih i pouzdanih podataka usporio se napredak alata za procjenu 

troškova razvijenih u 70-im godinama. No kako su vremenom podaci postajali dostupniji, takvi alati su 

se progresivno poboljšavali i kontinuirano se nastavljaju razvijati. Većina alata koristi algoritme koji se 

temelje na pouzdanim modelima, dok su oni napredniji bazirani na definiranim pravilima ili bazama 

znanja. 

Na softverske projekte u pravilu utječe preko 100 različitih faktora koji imaju utjecaj na rokove, trošak, 

kvalitetu i zadovoljstvo korisnika. Individualni projekti nisu pod utjecajem svih faktora, ali obično na 

njih utječe barem 10 do 20 osnovnih faktora. Alati poput COCOMO II, SEER-SEM-a i QSM-SLIM-a, 

koriste vlastite prilagoĎene podatke prikupljenih završenih projekata, i tu se radi o parametarskim 

alatima. Ovakvi alati u sebi imaju ugraĎene algoritme i velike baze znanja, na temelju kojih se na 

sistematičan i strukturiran način organiziraju ulazni parametri i faktori koji utječu na procjenu. Oni 

uzimaju obzir različite načine razvoja softvera i procjenjuju i one dijelove koji tijekom razvoja nisu 

vidljivi, a neizostavni su dio te time korisniku alata usmjeravaju pažnju i na pojedine dijelove koji se 

najčešće nenamjerno zaborave, odnosno izostave, a ključni su dio za uspješan razvoj i završetak 

softverskog proizvoda. 

U tablici su sažeti parametri i korištene aktivnosti pri procjeni troškova razvoja softverskog proizvoda 

koji su uključeni u pojedinim alatima. 

ATRIBUTI 

VELIČINE 

ATRIBUTI 

GRUPA FAKTOR COCOMO II SLIM SEER-SEM PRICE-S 

PROGRAMA 

ATRIBUTI 

RAČUNALA 

KADROSVSKI 

ATRIBUTI 

ATRIBUTI 

PROJEKTA 

POKRIVENE 

AKTIVNOSTI 

Check- 

point 

ESTIMACS 

Izvorne instrukcije DA DA DA DA DA NE 

Funkcijske točke DA DA DA DA DA 

OO- metrike DA DA DA DA DA - 

Vrsta/Domena NE DA DA DA DA DA 

Kompleksnost DA DA DA DA DA DA 

Jezik DA DA DA DA DA - 

Ponovno korištenje DA DA DA DA DA - 

Pouzdanost DA - DA DA - DA 

Ograničenja resursa DA DA DA DA - DA 

Promijenjivost platforme DA - DA - - - 

Sposobnost kadrova DA DA DA DA DA DA 

Kadrovska stalnost DA - - - - - 

Iskustvo kadrova DA DA DA DA DA DA 

Alati i tehnike DA DA DA DA DA DA 

Zastoji DA DA DA DA DA - 

Vremenska ograničenja DA DA DA DA DA DA 

Zrelost sustava DA DA DA - DA - 

Povezanost tima DA - DA DA DA - 

Sigurnosna pitanja NE - DA - - - 

Multisite razvoj DA - DA DA DA DA 

Početak DA DA DA DA DA DA 

Elaboracija DA DA DA DA DA DA 

Konstrukcija DA DA DA DA DA DA 

Tranzicija i održavanje DA DA DA DA DA NE 

23 

3

MANUALNA PROCJENA I JEDNOSTAVNI ALGORITMI (ISKUSTVO, POVIJESNI PODACI) 

Sve do 70-ih godina, kada se prvi put počinju razvijati automatski alati, procjena troškova obavljala se 

manualno, i to korištenjem jednostavnih pravila, pod nazivom Pravilo palca (eng. Rules of Thumb). I 

danas ovaj način predstavlja najčešće korišteni pristup procjeni troškova. Najčešće ga primjenjuju 

organizacije koje zapošljavaju manje od 100 osoba, angažiranih na području razvoja softvera, kao i 

organizacije koje su primarno orijentirane na male softverske projekte, odnosno projekte koje uključuju 

do 500 funkcijskih točaka gdje visoko precizne procjene nisu potrebne. 

Poznato je da korištenje pravila palca podliježe visokom stupnju pogrešaka. Ta pravila su objavljena 

radi zadovoljenja potrebe za brzom procjenom koje se mogu koristi manualno ili upotrebom ručnih 

kalkulatora i proračunskih tablica. Najznačajnija karakteristika ovog pravila jest jednostavnost 

korištenja i brzi set dobivenih podatka vezanih uz procjenu. Dugi niz godina manualna procjena 

temeljila se na linijama koda, prvenstveno namijenjenih proceduralnim programskim jezicima. 

Alati za procjenu troškova softvera imaju u sebi ugraĎenu široku bazu znanja, niz algoritama i pravila 

na kojim se temelje. Ekspert procjenu donosi na temelju iskustva rada s prošlim projektima te pri 

svojoj procjeni može napraviti slučajne i nenamjerne pogreške koje se mogu očitovati u izostavljanju 

nekih aktivnosti ili dodjeljivanju nerealnih vrijednosti. Nadalje, prilikom rada s proračunskim tablicama, 

osobito kada se radi o velikim projektima, vjerojatnost upisa krivih vrijednosti raste, kao i previdi nekih 

ključnih elementa. Ekspert takoĎer može podrazumijevati obavljanje odreĎenog dijela posla, no on se 

neće prikazati u ukupnoj kalkulaciji, čime će se smanjiti točnost ukupne procjene ili nekog njezinog 

pojedinog dijela. Prilikom donošenja procjene, alati ne ovise o stupnju stručnosti korisnika ili voditelja 

projekta, oni sadrže prikupljeno sumarno iskustvo stotina i tisuća softverskih projekata, stoga je pristup 

procjene eksperta sklon pogreškama, dok pristup dobiven upotrebom alata donosi pouzdanije i 

značajnije informacije. No i do danas, procjena temeljena na prosudbi eksperta vrlo je korištena 

metoda. Istraživanje Barbare Kitchenham iz 2002. pokazuje da je kod 72% projekta procjena bila 

bazirana na prosudbi eksperta. 2 MeĎusobne procjene različitih eksperata nisu jednake kao što ni 

znanje i iskustvo koje posjeduje svaki od njih nije jednako. Eksperti imaju tendenciju korištenja 

jednostavnih strategija za ostvarivanje procjene. Dobro poznavanje tehnologije ili razvoja ne implicira 

da će ta osoba biti pouzdana pri cjelokupnoj procjeni aktivnosti razvoja softvera. 

Caper Jones usporeĎivao je 50 projekta, koji su ručno procijenjeni, sa 50 projekata koji su 

procjenjivani pomoću automatskih alata za procjenu. 3 Projekti su veličine 5000 funkcijskih točaka. 

Manualna procjena temeljila se na procjeni izraĎenoj od strane voditelja projekta, uz korištenje 

tabličnog kalkulatora i proračunske tablice, dok su pri odabiru alata korišteni neki od komercijalnih 

rješenja. Komparacija je izvršena izmeĎu originalnih procjena i izmeĎu podataka dobivenih nakon što 

je aplikacija bila razvijena. Rezultati koji su dobiveni vrlo su zanimljivi. Samo četiri projekta koja su 

manualno procijenjena bila su u okvirima točnosti od 10% sa stvarnim podacima. Njih 17 bilo je 

optimistično s vrijednostima od 10-30% stvarnog iznosa, a 29 ih je bilo optimistično iznad 30%. 

Vrijednosti procjene projekata pokazivale su manje troškove i kraće rokove završetka od stvarnih 

podataka. Nasuprot tome, procjene troškova 22 projekta generirane uz pomoć automatskih alata bile 

su unutar 10% pouzdanosti. Procjena 24 projekta bila je u rasponu od 10-25% pouzdanosti, tri 

projekta imala su više od 25% pouzdanosti, a samo je jedan projekt bio optimističan s oko 15% 

pouzdanosti. Zanimljivo je to da su i kod manualne i kod procjene korištenjem automatskih alata, 

procjene u području predviĎanja programiranja i napora programiranja bile tu negdje. Manualni alati 

bili su vrlo optimistični kod rasta zahtjeva, dizajna napora, napora pri dokumentaciji i testiranja. 

Zaključak komparacije jest taj da su oba načina bila jednaka prilikom procjene stvarnog programiranja, 

dok su automatski alati bolji za predviĎanje neprogramskog dijela posla. 

Osnovna zamjerka softverskim projektima jest ta da oni vrlo često imaju tendenciju premašenja 

troškova i planiranih rokova, koja nerijetko nastaje upotrebom nesistematizirane manualne procjene. 

2 McConnell, Steve: Software Estimation, Microsoft Press, 2006., str. 105 

3 Jones, Capers: Estimating Software Costs: Bringing Realism to Estimating, The McGraw-Hill Companies, 2007., str. 48 

24 

4

POTEŠKOĆE PRILIKOM PROCJENE TROŠKOVA IZRADE SOFTVERA 

Definiranje navedenih faktora ne garantira sigurnu procjenu. Potrebno je dodati još i vještine, iskustvo, 

znanje i percepciju cijele situacije i okoline u kojoj se procjena vrši. Ali ono s čim se procjenitelji 

redovito susreću jest to da koliko god realna bila procjena troškova razvoja softvera, taj će iznos 

drugoj strani uvijek biti previsok. Visoka cijena i dugi rok izrade dvije su tvrdnje koje naručitelji softvera, 

menadžeri ili šefovi redovno izgovaraju. Godinama postoji nerazumijevanje izmeĎu onih koji rade na 

razvoju, voditelja projekta i naručitelja s druge strane. Razlog u ovome možda leži u tome što nema 

jasno identificiranih mjera kojima se može izraziti ono što se radi. TakoĎer, na početku projekta 

zahtjevi su površno definirani i nisu precizno specificirani, no od voditelja projekta očekuje se da da 

ponudu o očekivanom trošku i roku izrade. Produktivnost programera vrlo je bitan faktor, no 

produktivnost se meĎusobno razlikuje od programera do programera, i to je nešto na što se ne može 

utjecati. Potrebno je razviti svijest i poznavati produktivnosti svakog pojedinog člana i ukalkulirati je u 

procjenu, a nipošto obratno. Dobra je praksa postaviti pitanje programerima da sami donesu procjenu, 

koliko im je potrebno vremena za izvršavanje pojedinog djela. Tu treba na imati umu to da programeri 

često imaju tendenciju optimistične procjene svoga posla, jer kada se dosegnu optimistične procjene, 

a posao nije završen, tada je već kasno. 

NAČIN PROCJENE TROŠKOVA RAZVOJA SOFTVERSKOG PROIZVODA U HRVATSKOJ 

Kako bi se dobila slika o stanju i spoznaji hrvatskih softverskih poduzeća i o korištenju alata i metrika 

za procjenu razvoja softvera, provedena je anketa, kojoj je bio cilj, na osnovu anketnih pitanja, 

odgovoriti na sljedeće: 

Koliko su hrvatski proizvoĎači softvera upoznati s metrikama i alatima za procjenu 

troškova? 

Na koji način vrše procjenu troškova? 

Koliko izbor metrike i alata ovisi o vrsti softvera i korištenim tehnologijama? 

Utječe li način procjene na uspjeh projekta? 

Dolazi li do prekida razvoja softvera zbog loše procjene? 

Anketiranje je provedeno na uzorku od 30 informatičkih tvrtki koje se isključivo bave proizvodnjom 

vlastitih gotovih aplikacija ili aplikacija po narudžbi korisnika. 

Provedeno istraživanje o zastupljenosti korištenja alata i metrika za procjenu razvoja softvera 

provedeno je na uzorku od 30 poduzeća. Na upitnik je odgovorilo njih 26, što iznosi 87%, i dalo je 

sljedeće zaključke temeljene na anketnom upitniku: 

Koliko su hrvatski proizvoĎači softvera upoznati s metrikama i alatima za procjenu 

troškova? 

Istraživanje je pokazalo da su hrvatska softverska poduzeća slabo upoznata s dostupnim 

metrikama i alatima koji se nalaze na tržištu. Nijednu metriku ne koristi 46% posto 

anketiranih poduzeća, dok su rezultati o korištenju alata još slabiji i pokazuju da 77% 

anketiranih poduzeća prilikom procjene ne koristi nijedan alat. 

NIŠTA 

46% 

OSTALO 

15% 

Metrike 

LOC, UC 

8% FT 

8% 

25 

OT, UC 

15% 

UC 

8% 

5

Na koji način vrše procjenu troškova? 

Hrvatska softverska poduzeća procjenu vrše korištenjem procjene eksperta i na temelju 

iskustava iz prošlih projekta, i to je odgovorilo 54% anketiranih poduzeća. No, 

istovremeno, 62% anketiranih poduzeća ne održava i ne ažurira bazu podataka o procjeni 

završenih projekta, čime ti podaci ne mogu biti vjerodostojni i njihova uporaba za 

procjenu svih sljedećih projekata smanjuje pouzdanost procjene, što u konačnici dovodi 

do kašnjenja u isporuci softvera, povećanjem troškova ili prekidom razvoja. 

Koliko izbor metrike i alata ovisi o vrsti softvera i korištenim tehnologijama? 

Istraživanje je pokazalo da poduzeća koja razvijaju web aplikacije korištenjem objektno 

orijentiranih tehnologija, koriste neku metriku prilikom procjene, i to najčešće Use Case 

metriku 25%, dok se za ostale vrste softvera i tehnologije u pravilu ne koriste metrike i 

alati. 

Utječe li način procjene na uspjeh projekta? 

Iako hrvatska poduzeća ne uobičavaju koristiti dostupne metrike i alate pri procjeni, 

shvaćaju važnost procjene i njezin utjecaj na uspjeh projekta. Tako su skoro sva 

anketirana poduzeća važnost procjene ocijenila s jako važno i važno. 

8% 

7% 

bez odgovora 

Razlozi nekorištenja metrika 

8% 4% 4% 

23% 

Važnost procjene 

54% 

38% 

54% 

metrike nam ne bi pomogle za donošenje procjene 

nismo upoznati s metrikama za procjenu troškova 

ostalo 

nismo upoznati s metrikama za procjenu troškova, ostalo 

jako važno važno umjereno važno 

26 

6

ZAKLJUČAK 

Dolazi li do prekida razvoja softvera zbog loše procjene? 

Prema odgovorima anketiranih poduzeća, najčešći razlozi prekida razvoja softvera su: 

loša procjena izvodljivosti 32%, politička odluka 10% i loše voĎenje projekta 10%. 

Navedeni odgovori dokazuju da se prekid razvoja softvera dogaĎa zbog loše procjene. 

Informatičke organizacije pod konstantnim su pritiskom da unaprijede kvalitetu softverskih projekta i 

izlazne rezultate. UnapreĎenje procesa procjene jedan je od ključnih faktora. Voditelji projekta i 

programeri često se boje da će prezentiranje procjene koja je previsoka dovesti do toga da projekt 

bude odbijen, što je osnovni razlog donošenja i prezentiranja nerealnih rokova. Informatičke 

organizacije prilikom nabavke nekog od alata najčešće se odlučuju za nabavku popularnog alata na 

tržištu, neovisno o svojim stvarnim potrebama i uvode ga u organizaciju, ne iz razloga unapreĎenja 

procjene, već kako bi nadvladali pritisak za zahtjevima uprave. Ako se to napravi bez potrebne razine 

zrelosti u mjerenju, neadekvatnim skupljanjem metrika i nepridržavanjem procesa analize u 

organizaciji, samo uvoĎenje alata dovest će do kaosa. 

U ovome je radu prikazano da je za dobivanje što pouzdanije procjene potrebno razmotriti čitav niz 

različitih faktora i aspekata koji mogu i koji izravno utječu na konačnu procjenu. Metodom anketiranja 

pokazalo se da je loša procjena jedan od ključnih razloga koji imaju negativan utjecaj na razvoj 

softvera kao i da dovodi do kašnjenja u razvoju softvera te povećava troškove njegove izrade. 

Voditelji projekta često očekuju da će dobar alat za procjenu riješiti sve njihove probleme. No samom 

nabavkom takvog alata ne garantira se i dobra procjena. Dobra procjena zahtjeva, izmeĎu ostaloga, 

razumijevanje područja koje se procjenjuje, kao i uzimanje u obzir svih faktora koji na takvu procjenu 

utječu ili mogu utjecati u odreĎenim situacijama. U obzir se, nadalje, moraju uzeti postupci kao što su 

prikupljanje, rafiniranje i održavanje povijesnih podataka tekućih i prošlih projekta. Uloga povijesnih 

podataka jest da pruže ulazne podatke potrebne za dobivanje procjene iz korištenih alata. S 

upravljanjem i korištenjem povijesnih podataka prilikom procjene treba postupati vrlo oprezno, kako 

procjena ne bi otišla u krivom smjeru. 

Alat za procjenu bit će vrlo koristan onome tko zna na koji način treba vršiti procjenu. Ako je 

procjenitelj iskusan na području softverskog inženjerstva, poznaje promatranu domenu i tehnologiju, 

bit će u mogućnosti izvući maksimum koristi i iz alata s najskromnijim mogućnostima. Alati dopuštaju 

izvoĎenje nekoliko vrsta poslova vezanih uz procjenu, što se teško može izvršiti manualno, te 

omogućavaju izvoĎenje sofisticiranih statističkih simulacija koje pomažu pri shvaćanju obujma posla 

koji treba biti napravljen. 

Nijedna pojedinačna tehnika procjene troškova nije savršena, stoga je važno korištenje i kombiniranje 

nekoliko različitih pristupa. Primjer toga su i najsofisticiraniji komercijalni alati koji koriste barem tri 

različita pristupa procjene koji se zatim meĎusobno usporeĎuju za pregled dobivenih sličnosti ili 

razlika. Ukoliko su dobiveni približno jednaki rezultati to govori da se vjerojatno radi o dobroj procjeni, 

dok velike razlike izmeĎu njih govore da bi trebalo razmotriti faktore koji su se koristili ili izostavili za 

bolje razumijevanje dobivenih rezultata. 

POPIS LITERATURE 

1. Goodman, Paul: Software Metrics, Rothstein Associates Inc., 2004. 

2. McConnell, Steve: Software Estimation, Microsoft Press, 2006. 

3. Jones, Capers: Estimating Software Costs: Bringing Realism to Estimating, The McGraw-Hill 

Companies, 2007. 

27 

7

KONKURENTNO PROGRAMIRANJE – ORACLE BAZA, JAVA, EIFFEL 

Zlatko Sirotić 

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

e-mail: zlatko.sirotic@iii.hr 

SAŽETAK 

U radu se govori o osnovama konkurentnog programiranja. Konkurentno programiranje nije novost, 

vuče korijene još iz 60-tih godina prošlog stoljeća, kada se uglavnom primjenjivalo kod operacijskih 

sustava. Prvo se daje prikaz konkurentnosti u Oracle bazi - naime, PL/SQL i JVM u bazi izravno ne 

podržavaju konkurentno programiranje, ali konkurentnost se neminovno javlja na razini rada sa 

transakcijama. Zatim se ukratko prikazuje konkurentnost u operacijskim sustavima, hardverska podrška 

konkurentnosti, pa sinkronizacijski algoritmi i mehanizmi. Zatim se prikazuje konkurentno programiranje u 

Javi verzije 1 - 4. Posebno se navode nove mogućnosti u Java verzijama 5, 6, 7. Na kraju se daje 

drugačiji pristup konkurentnom programiranju u OOPL jeziku Eiffel - SCOOP (Simple Concurrent Object- 

Oriented Programming). 

The paper discusses the basics of concurrent programming. Concurrent programming is not new, it 

has roots in 1960s when it was mainly applied in operating systems. First, concurrency in the Oracle 

database is described - although PL/SQL and the JVM in the database do not directly support concurrent 

programming, concurrency inevitably occurs at the level of transactions. Concurrency in the operating 

system, hardware support for concurrency, and synchronization algorithms and primitives are briefly 

discussed later. Concurrent programming in Java versions 1 - 4 is described after that. Specifically new 

features of Java 5, 6, 7 versions are outlined. Finally, the different approach of concurrent programming in 

Eiffel OOPL is presented - SCOOP (Simple Concurrent Object-Oriented Programming). 

UVOD 

Gotovo sva današnja računala imaju više CPU-a, manja računala u obliku višejezgrenih (engl. multicore) 

procesora, a veća i snažnija računala obično sadrže više procesora (isto višejezgrenih). Prednost je 

takvih računala da mogu paralelno izvršavati dva ili više (u ovisnosti od broja CPU-a) nezavisnih 

programa, ali mogu paralelno izvršavati i dijelove istog programa. U potonjem slučaju, ako su dijelovi 

programa nezavisni jedan od drugoga, tada programeri i dalje mogu pisati kod kao da se on odvija u 

jednom dijelu. 

No, najčešće su dijelovi programa međusobno zavisni, jer čitaju / pišu u isto memorijsko područje ili 

koriste neki drugi dijeljeni resurs, pa je moguće da dođe do tzv. race condition, gdje rezultat izračuna ovisi 

o redoslijedu izvršenja programskih instrukcija iz različitih dijelova programa. Zbog toga je potrebna 

sinkronizacija dijelova programa. Sinkronizacija traži posebne programske tehnike, koje svoje porijeklo 

imaju još u 60-tim godinama prošlog stoljeća. Te se programske tehnike obično zovu imenom 

konkurentno programiranje. 

U radu se u 1. točki prikazuje konkurentnost u Oracle bazi. Iako to nije konkurentno programiranje 

kao u programskim jezicima npr. Java, C++, Eiffel, ipak postoje neki slični problemi konkurentnosti u 

Oracle bazi i tim jezicima, npr. problemi zaključavanja, deadlocka (potpuni zastoj; u nastavku ćemo 

koristiti engleski termin, zbog jasnoće) i sl. S druge strane, neka najnovija softverska ili/i hardverska 

rješenja konkurentnog programiranja nastala su po ugledu na baze podataka – tzv. transakcijske 

memorije. 

U 2. točki prikazuje se konkurentnost na svom izvoru, tamo gdje je prvobitno i nastala – u 

operacijskim sustavima. U 3. točki daje se prikaz hardverske podrške za konkurentnost (naročito u 

dizajnu procesora). U 4. točki prikazuju se neki sinkronizacijski algoritmi i mehanizmi. U 5. točki prikazuju 

se neke "stare" tehnike konkurentnog programiranja u Javi verzije 1 do 4, a u 6. točki neke novije tehnike, 

koje je omogućila verzija 5, a u verzijama 6 i 7 su još poboljšane. 

Nažalost, konkurentno programiranje teže je od uobičajenog, sekvencijalnog programiranja, ali sa 

razvojem višejezgrenih procesora konkurentno programiranje postaje nužnost u "svakodnevnom 

programiranju". Postoje pokušaji (vrijeme će pokazati da li su uspješni) da se konkurentno programiranje 

učini jednostavnijim. Jedan drugačiji pristup konkurentnom programiranju u odnosu na onaj u Javi (a 

slično Javi ima i C#, pa i C++), koji bi trebao olakšati konkurentno programiranje, prikazan je u 7. točki – 

Simple Concurrent Object Oriented Programming (SCOOP), model koji je realiziran u OOPL jeziku Eiffel. 

28

1. KONKURENTNO PROGRAMIRANJE U ORACLE BAZI 

Uz programiranje operacijskih sustava i programiranje superračunala, programiranje sustava za 

upravljanje bazama podataka (SUBP) je treće područje koje je i do sada značajno koristilo tehnike 

konkurentnog programiranja. No, tehnike konkurentnog programiranja prisutne su, iako u blažoj verziji (tj. 

na jednostavniji način), i kod korištenja SUBP-a, npr. kod programiranja u jeziku Oracle PL/SQL. 

Poznato je da u Oracle bazi sesija (baze) nikada ne vidi promjene (tj. efekte DML naredbi) koje je 

napravila neka druga sesija, sve dok ta druga sesija ne napravi COMMIT. U Oracle bazi to je realizirano 

pomoću UNDO tablespacea, diskovne strukture u kojoj sesije čitaju prethodno stanje podataka, a ne 

tekuće stanje koje je zapisano u tablicama podataka, ali promjene još nisu COMMIT-irane. 

No, sesija ipak ovisi o drugoj sesiji, jer su redci koje je ažurirala (unijela / mijenjala / brisala) druga 

sesija nedostupni (tj. zaključani) prvoj sesiji. Redci se uobičajeno ne mogu otključati do kraja tekuće 

transakcije u sesiji koja ih je zaključala, tj. dok ona ne daje COMMIT ili ROLLBACK. Redci se mogu 

otključati i sa ROLLBACK TO SAVEPOINT, ali treba podsjetiti da sesiji koja pokuša pristupiti zaključanim 

redcima prije nego druga sesija napravi ROLLBACK TO SAVEPOINT, ti redci i daje ostaju zaključani (do 

COMMIT ili ROLLBACK). 

Sesija koja čeka na zaključane retke u pravilu čeka neograničeno, tj. dok joj druga sesija ne otključa 

retke. Postoje dva izuzetka: 

- sesija može pokušati zaključati retke sa 

SELECT ... FOR UPDATE; 

i navesti da ne želi čekati 

SELECT ... FOR UPDATE NOWAIT; 

ili želi čekati određeni broj sekundi 

SELECT ... FOR UPDATE WAIT timeout; 

ako je druga sesija zaključala redak, onda se prvoj sesiji javlja greška 

ORA-00054: resource busy and acquire with NOWAIT specified; 

- ako sesija čeka na otključavanje redaka sa udaljene baze, onda je čekanje definirano 

parametrom DISTRIBUTED_LOCK_TIMEOUT, koji ima standardnu vrijednost 60 sekundi; 

ako druga sesija drži zaključan redak, nakon isteka tog vremena prvoj sesiji javit će se greška 

ORA-02049: timeout: distributed transaction waiting for lock; 

ovu smo činjenicu koristili za trik (koji smo prikazali na HrOUG 2003) – kako izbjeći neograničeno 

čekanje otključavanja retka kod INSERT naredbe (gdje prethodno korištenje naredbe 

SELECT .. FOR UPDATE NOWAIT nema efekta, jer redak za druge sesije ne postoji). 

Osim zaključavanja redaka (jednog ili više), ponekad želimo zaključati cijelu tablicu. Zanimljivo je da 

zaključavanje tablice možemo izvesti u djeljivom ili ekskluzivnom načinu (modu). 

Više sesija može zaključati tablicu u djeljivom načinu: 

LOCK TABLE tablica IN SHARE MODE NOWAIT; 

Samo jedna sesija može zaključati tablicu u ekskluzivnom načinu (ako ju neka druga sesija nije već 

zaključala u djeljivom ili ekskluzivnom načinu): 

LOCK TABLE tablica IN EXCLUSIVE MODE NOWAIT; 

Zaključavanje tablice u djeljivom i ekskluzivnom načinu može se iskoristiti npr. za omogućavanje da 

više sesija mijenja neku tablicu dokumenata (npr. tablicu narudžbi), a da samo jedna sesija može raditi 

obradu narudžbi. Pritom se može zaključavati izvorna tablica dokumenata (npr. narudžbi), ili neka 

pomoćna tablica, koja može imati malo redaka (može i jedan, pa i nijedan). 

Iako se zaključavanje često radi implicitno, pomoću DML naredbi (INSERT, UPDATE, DELETE), 

ponekad je potrebno koristiti eksplicitno zaključavanje pomoću SELECT ... FOR UPDATE (rijetko se 

koristi LOCK TABLE) kako bi se sačuvao integritet podataka. Npr. pretpostavimo da imamo tri bankovna 

računa, svaki sa početnim iznosom od 1000 kuna. Transakcija T1 koja skida 100 kuna sa računa broj 1 i 

stavlja ih na račun broj 2, mogla bi izgledati ovako (zanemarimo što programski kod nije optimalan): 

SELECT iznos INTO v_iznos_d FROM racuni WHERE broj = 1; 

v_iznos_d := v_iznos_d - 100; 

UPDATE racuni SET iznos = v_iznos_d WHERE broj = 1; 

SELECT iznos INTO v_iznos_p FROM racuni WHERE broj = 2; 

v_iznos_p := v_iznos_p + 100; 

UPDATE racuni SET iznos = v_iznos_p WHERE broj = 2; 

29

No, pretpostavimo da u isto vrijeme transakcija T2 skida 200 kuna sa računa broj 3 i stavlja ih isto na 

račun broj 2: 







Može se desiti npr. sljedeći redoslijed radnji: 

T1: 







T2: 




SELECT iznos INTO v_iznos_p FROM racuni WHERE broj = 2; -- čita staro stanje! 


UPDATE racuni SET iznos = v_iznos_p WHERE broj = 2; -- redak je zaključan od T1 

T1: 

COMMIT; -- sada je T2 napravila UPDATE 

T2: 

COMMIT; 

Kakvo je sada stanje računa. Stanje računa 1 i 3 (davatelji) je točno – račun 1 ima 900 kuna, račun 3 

ima 800 kuna. Račun 2 (primatelj) trebao bi imati 1300 kuna, no ima 1200, jer je druga transakcija kod 

SELECT-a na računu broj 2 vidjela stanje od 1000 kuna. 

Jedan od načina da se ovaj kod napiše ispravno, je – zaključavanje oba računa unaprijed, pomoću 

naredbi SELECT FOR UPDATE. Npr. transakcija T1 mogla bi izgledati ovako: 

SELECT iznos INTO v_iznos_d FROM racuni WHERE broj = 1 FOR UPDATE; 

SELECT iznos INTO v_iznos_p FROM racuni WHERE broj = 2 FOR UPDATE; 





No, sada se može desiti deadlock - ako dvije transakcije pokušaju zaključati dva retka, ali u 

suprotnom redoslijedu. Npr. u slučaju da transakcija T1 uspješno zaključa račun broj 1, transakcija T2 

uspješno zaključa račun 2, a obje žele zaključati i suprotni račun, desit će se deadlock: 

T1: SELECT iznos ... FROM racuni WHERE broj = 1 FOR UPDATE; -- uspješno 

T2: SELECT iznos ... FROM racuni WHERE broj = 2 FOR UPDATE; -- uspješno 

T1: SELECT iznos ... FROM racuni WHERE broj = 2 FOR UPDATE; -- čeka 

T2: SELECT iznos ... FROM racuni WHERE broj = 1 FOR UPDATE; -- čeka 

Srećom, Oracle baza otkrit će da je došlo do deadlocka, te će jedna od dvije transakcije dobiti 

grešku ORA-00060: deadlock detected while waiting for resource. Nakon što ta transakcija (koja je dobila 

grešku) napravi ROLLBACK, druga transakcija će nastaviti sa radom. 

30

Za kraj, prikažimo kako se u Oracle bazi može napraviti paralelno izvršavanje dijelova programa 

pomoću jobova. Izvorno smo ovu metodu koristili kod distribuiranih baza, gdje smo na jednoj bazi 

("centralna baza") pokretali jobove koji su pozivali udaljene procedure na drugim (udaljenim) bazama. 

Udaljene procedure paralelno obrađuju lokalne podatke, a nakon završetka svake procedure job javlja 

centralnoj bazi da je procedura završila. Kada centralna baza dobije odgovor od svih jobova, 

sekvencijalno (u jednoj transakciji) prikuplja rezultate udaljenih baza. Navedena metoda može se koristiti i 

na jednoj bazi, ali je korisna samo ako ta baza ima više raspoloživih (slobodnih) CPU-a. Poželjno bi bilo 

da je broj slobodnih CPU-a veći ili jednak broju jobova, tako da sve procedure mogu raditi paralelno. Ovo 

je osnovna logika te metode: 

...FOR cur IN (SELECT baza FROM udaljene_baze) LOOP 

DBMS_ALERT.REGISTER (cur.baza); 

naredba_l := 

'BEGIN ' || 

' udaljena_procedura@' || cur.baza || ';' || 

' DBMS_ALERT.SIGNAL (''' || cur.baza || ''', '' OK, '');' || 

'EXCEPTION' || 

' WHEN OTHERS THEN' || 

' DECLARE' || 

' l_greska VARCHAR2 (20) := SUBSTR (SQLCODE, 1, 20);' || 

' BEGIN' || 

' ROLLBACK;' || 

' DBMS_ALERT.SIGNAL (''' || cur.baza || ''', l_greska);' || 

' END;' || 

'END;'; 

DBMS_JOB.SUBMIT (pid_l, naredba_l, SYSDATE, NULL, FALSE); 

br_jobova_l := br_jobova_l + 1; 

END LOOP; 

COMMIT; -- nužan za pokretanje JOB-ova 

/* 

Čeka na završetak svih JOB-ova ili istek vremena (1800 sekundi) 

za svaki prolaz u FOR petlji. 

*/ 

FOR i IN 1..br_jobova_l LOOP 

DBMS_ALERT.WAITANY (alert_l, poruka_l, status_l, 1800); 

IF status_l = 1 THEN -- isteklo je vrijeme, a alert se nije okinuo 

RAISE jobovima_isteklo_vrijeme; 

END IF; 

IF poruka_l ' OK, ' THEN -- JOB je puknuo 

poruka_za_gresku_l := alert_l || ' - ' || poruka_l; 

RAISE puknuo_job; 

END IF; 

poruka_za_gresku_l := poruka_za_gresku_l || alert_l || poruka_l; 

END LOOP; 

DBMS_ALERT.REMOVEALL; 

/* 

INSERT sa svih udaljenih baza 

- serijski (ali radi brzo), kako bi bila jedna transakcija 

*/ 

FOR cur IN (SELECT baza FROM udaljene_baze) 

LOOP ... 

END LOOP; 

COMMIT; 

31

2. KONKURENTNO PROGRAMIRANJE I OPERACIJSKI SUSTAVI 

Ideja o konkurentnom računanju (concurrent computation) razvila se baš na području operacijskih 

sustava. Prvi operacijski sustavi, napravljeni 50-tih godina prošlog stoljeća, bili su sekvencijalni, tj. 

računalni programi izvršavali su se na njima slijedno, jedan iza drugoga. Vrlo brzo se uvidjelo da je to vrlo 

neracionalan način korištenja računala (u to vrijeme vrlo rijetkih i skupih), pa su 60-tih godina napravljeni 

brojni operacijski sustavi koji su omogućavali konkurentno korištenje računalnih resursa. 

Tadašnja velika računala, kao i donedavno uobičajena osobna računala, imala su samo jedan CPU. 

Zbog toga se programi na njima nisu zaista izvršavali paralelno (ako zanemarimo specijalne programe, 

koji su se zaista izvršavali paralelno sa glavnim programima, npr. na specijaliziranim procesorima ulaznoizlaznih 

jedinica), već kvazi-paralelno. Uobičajeno se takav kvazi-paralelan način rada naziva 

višezadaćnost (multitasking). Procesi, kako se nazivaju programi u izvršavanju (može se reći i da su 

procesi instance programa u izvršavanju) u višezadaćnom radu izvršavaju se slijedno na istom CPU, ali 

se zbog isprepletenog izvršavanja djelića različitih procesa (tj. niza instrukcija), čini kao da se procesi 

izvršavaju paralelno. Na slici 2.1 vidi se prikaz višezadaćnosti: 

Slika 2.1: Višezadaćnost (multitasking): instrukcije se međusobno isprepliću; Izvor: [14] 

Vrlo brzo su se pojavila velika računala sa dva ili više CPU-a, a danas je uobičajeno da i najjeftinija 

prijenosna računala imaju dva CPU-a, u obliku dvije jezgre smještene u isti mikroprocesor (bolje rečeno 

mikroprocesorski čip). Ovakva računala omogućavaju da se dva procesa (ili više, ovisno o broju CPU-a) 

zaista izvršavaju paralelno, što se uobičajeno naziva multiprocesorski rad ili multiprocesiranje 

(multiprocessing), kako prikazuje slika 2.2: 

Slika 2.2: Multiprocesiranje (multiprocessing): instrukcije se izvršavaju paralelno; Izvor: [14] 

I multiprocesiranje i višezadaćnost su primjeri konkurentnog izvršavanja. Postoji i distribuirano 

izvršavanje, koje je po svom ponašanju dosta slično konkurentnom izvršavanju. Razlika je u tome što se 

konkurentno izvršavanje zbiva na jednom računalu (koje može imati više CPU-a, pa i stotine i tisuće), a 

distribuirano izvršavanje zbiva se na dva ili više računala koja su spojena mrežom. 

Ne ulazeći u detalje zbivanja u operacijskim sustavima (detalje se može vidjeti npr. u [2]), može se 

reći da proces operacijskog sustava ima sljedeće najvažnije elemente [14]: 

- Identifikator procesa: jedinstveni ID procesa; 

- Stanje procesa: tekuća aktivnost procesa; 

- Kontekst procesa: vrijednost programskog brojača i vrijednost svih registara CPU-a; 

- Memorija: tekst programa, globalni podaci, stog (stack) i gomila (heap). 

32

Slika 2.3 prikazuje najvažnije elemente procesa operacijskog sustava: 

Slika 2.3: Najvažniji elementi procesa operacijskog sustava; Izvor: [13] 

Operacijski sustav koristi poseban program - raspoređivač (scheduler), koji određuje kojem procesu 

treba dodijeliti (neki) procesor. Procesi mogu biti u ova tri generalna stanja [14]: 

- Pokrenut (running): instrukcije procesa se izvršavaju na (nekom) procesoru; 

- Spreman (ready): proces je spreman za izvršavanje, ali trenutačno mu nije dodijeljen procesor; 

- Blokiran (blocked): proces čeka da se desi neki događaj (npr. da se završi čitanje podataka sa 

diska ili iz memorije, koji su potrebni za nastavak rada procesa). 

Slika 2.4 prikazuje tranziciju stanja procesa operacijskog sustava (dodana su i terminalna stanja new 

i terminated): 

Slika 2.4: Tranzicija stanja procesa operacijskog sustava; Izvor: [13] 

Zamjena (swapping) procesa koji se izvršavaju na CPU-u naziva se zamjena konteksta (context 

switch). Pretpostavimo da je proces P1 u stanju pokrenut i treba biti zamijenjen procesom P2 koji mora 

biti u stanju spreman. Program raspoređivač postavlja stanje procesa P1 na spreman i snima njegov 

kontekst u memoriju, kako bi ga poslije mogao "probuditi" i omogućiti da nastavi sa istog mjesta na kojem 

je stao. Raspoređivač dalje koristi kontekst procesa P2 kako bi postavio vrijednosti registara CPU-a i 

postavlja proces P2 u stanje pokrenut. Ta zbivanja prikazuje slika 2.3: 

Slika 2.5: Zamjena konteksta (context switch): proces P1 se odstranjuje iz procesora 

i zamjenjuje ga proces P2; Izvor: [14] 

33

U prethodnom opisu proces P1 je iz stanja pokrenut prešao u stanje spreman, a proces P2 obrnuto. 

No, moguće je da proces pređe iz stanja pokrenut u stanje blokiran, jer čeka da se desi neki događaj 

(npr. da završi čitanje podataka sa diska ili iz memorije, ili da drugi proces napravi neki niz instrukcija). 

Blokirani proces ne može direktno preći u stanje pokrenut, nego prvo mora preći u stanje spreman, a 

onda ga raspoređivač može staviti u stanje pokrenut. 

Kod paralelnog ili (kvazi-paralelnog) izvršavanja procesa možemo u načelu razlikovati dva slučaja. U 

prvom slučaju procesi su nezavisni jedan od drugoga, tj. ne komuniciraju međusobno. Inače, 

komunikacija između dva procesa radi se preko razmjene poruka (rjeđe) ili preko čitanja/pisanja u 

zajednički dio memorije (češće). Zapravo, i nezavisni procesi mogu u nekom smislu biti zavisni, tj. ovise o 

zajedničkim resursima kao što su procesori (koji ih izvršavaju), ulazno-izlazne jedinice i sl. Programiranje 

nezavisnih konkurentnih procesa zapravo se ne razlikuje od programiranja sekvencijalnih procesa. U 

drugom slučaju procesi su zavisni, tj. međusobno komuniciraju. Tada je potrebno koristiti mehanizme 

sinkronizacije kako bi se procesi izvršavali na ispravan način - to je "pravo" konkurentno programiranje. 

No, nisu samo procesi oni koji se mogu izvršavati paralelno (ili kvazi-paralelno). Ako je dobro da se 

procesi mogu izvršavati paralelno, onda to može biti dobro i za manje dijelove programa nego što su 

procesi, tj. dobro je da se paralelno (ili kvazi-paralelno) mogu izvršavati dijelovi istog programa! Dijelovi 

programa koji se mogu izvršavati paralelno zovu se dretve ili niti (threads). Može se reći: "dretve su lagani 

procesi". Procesi koji su sastavljeni od više dretvi zovu se višedretveni (multithreaded). 

Dretve jednog procesa dijele adresni prostor tog procesa, tj. jedna dretva vidi podatke druge dretve. 

Zapravo, dretve dijele globalnu memoriju (programski kod i globalne podatke) i gomilu (heap), ali imaju 

vlastiti stog (stack) i kontekst dretve, kako prikazuje slika 2.6: 

Slika 2.6: Najvažniji elementi dretvi operacijskog sustava 

(prikazane su tri dretve koje pripadaju istom procesu); Izvor: [13] 

Zamjena konteksta dretvi u pravilu se izvodi nekoliko puta brže od zamjene konteksta procesa. U [7] 

se navodi da je zamjena konteksta dretve puno efikasnija od zamjene konteksta procesa, koja tipično 

traje stotine do tisuće ciklusa procesa. Zbog toga svi današnji moderni operacijski sustavi nisu samo 

višeprocesni, nego i višedretveni. No i tu se očekuju poboljšanja, jer kako je navedeno u [3] "Postojeći 

raspoređivači nisu pripremljeni za stotine CPU-a i tisuće dretvi koje su u stanju pokrenut (running)." 

Dretve se mogu dodjeljivati procesorima na isti način na koji se mogu dodjeljivati procesi. Npr. u 

računalnom sustavu sa četiri CPU-a, sustav može u određenom trenutku paralelno izvršavati četiri 

različita procesa, ali može izvršavati i četiri dretve istog procesa, ili bilo koju kombinaciju. Istina, zbog 

optimizacije sustav može odabrati da je bolje rasporediti određene dretve na određene procesore. 

34

3. UTJECAJ RAZVOJA MIKROPROCESORA NA KONKURENTNO PROGRAMIRANJE 

Materijal [4], znakovitog naslova "Not Your Father's Von Neumann Machine: A Crash Course in 

Modern Hardware", navodi da je Von Neumannov model računala (prikazan na slici 3.1) u današnje 

vrijeme samo korisna apstrakcija, koja u mnogim detaljima odudara od stvarnih današnjih računala: 

Slika 3.1: Von Neumannov model računala; Izvor: [4] 

U knjizi [7], autori daju grafikon (slika 3.2) koji prikazuje rast performansi procesora 1978.-2005. 

godine. Vidljiva su tri razdoblja: razdoblje CISC računala do 1986., u kojem je prosječno godišnje 

povećanje performansi 25%; razdoblje velikog povećanja radnog takta procesora, gdje je povećanje 

performansi 52% godišnje; razdoblje višejezgrenih procesora, gdje se radni taktovi procesora više nisu 

povećavali: 

Slika 3.2: Rast performansi procesora od 1978. do 2005.; Izvor: [7] 

No, to ne znači da je prestao vrijediti Mooreov zakon, jer broj tranzistora po procesoru i dalje 

eksponencijalno raste, kako pokazuje slika 3.3. No, radni takt procesora praktički je prestao rasti oko 

2005. Razlog za to je prije svega veliko povećanje potrošnje struje procesora na velikim brzinama. Zbog 

toga su se proizvođači okrenuli drugačijem načinu povećanja performansi procesora. Umjesto povećanja 

brzine, povećali su broj CPU-a na jednom mikroprocesorskom čipu, tj. počeli su proizvoditi višejezgrene 

procesore. No, dok smo kod jednojezgrenih procesora povećanjem takta procesora dobili linearno 

povećanje brzine programa, kod višejezgrenih procesora program najčešće moramo pisati drugačije da 

bismo iskoristili raspoložive jezgre, tj. moramo preći na konkurentno programiranje. 

Slika 3.3: Povećanje broja tranzistora i radnog takta procesora od 1973. do 2010.; Izvor: [15] 

35

U [7] se daje zanimljiv grafikon (slika 3.4) koji pokazuje kako se širina pojasa (bandwidth) ili 

propusnost glavnih elemenata računala (procesora, memorije, diska, mreže) povećavala daleko brže od 

brzine pristupa (latency). 

Slika 3.4: Log-log dijagram kretanja odnosa propusnosti i brzine pristupa 

kod glavnih elemenata računala; Izvor: [7] 

Tablica 3.1 prikazuje razlike u veličini, brzini pristupa, propusnosti i nekim drugim karakteristikama 

različitih vrsta memorije, tj. procesorskih registara, priručne memorije (cache), glavne memorije i diskova 

(konkretni podaci vrijede za oko 2005. godinu). Vidi se da je glavna memorija 10 i više puta sporija od 

registara i priručne memorije: 

Tablica 3.1: Razlike u veličini, brzini pristupa i drugim karakteristikama 

različitih vrsta memorije; Izvor: [7] 

Slika 3.5 pokazuje kako se eksponencijalno povećava jaz između performansi CPU-a i performansi 

glavne memorije (DRAM): 

Slika 3.5: Povećanje jaza između performansi CPU-a i performansi DRAM-a; Izvor: [4] 

36

Naravno, nije nemoguće napraviti glavnu memoriju koja bi bila brza skoro kao registri procesora. 

Problem je što bi takva memorija bila puno skuplja. Naime, glavna memorija standardno koristi tzv. 

DRAM (Dynamic RAM) memoriju, koja za svaki bit memorije treba jedan tranzistor i jedan kondenzator. 

Daleko brža SRAM (Static RAM) memorija za svaki bit memorije treba šest tranzistora. Ako treba birati 

između sustava sa većom količinom sporije glavne memorije i sustava sa manjom količinom brže glavne 

memorije, u pravilu je bolje izabrati prvo, jer je magnetski disk daleko sporiji od najsporije glavne 

memorije. No, još je bolje napraviti hijerarhiju memorija, tj. koristiti bržu i manju SRAM priručnu memoriju 

(ili više razina te memorije) zajedno sa većom i sporijom DRAM glavnom memorijom. Budući da programi 

često koriste programske instrukcije koje se nalaze blizu jedna drugoj, a to često vrijedi i za podatke, 

priručne memorije značajno ublažavaju sporost pristupa glavnoj memoriji. Slika 3.6 prikazuje dva primjera 

korištenja priručne memorije, jedan jednostavniji i jedan složeniji (oba primjera prikazuju jednojezgreni 

procesor): 

Slika 3.6: Dva primjera korištenja priručne memorije; lijevo je jednostavniji sustav sa jednom 

razinom priručne memorije; desno je složeniji sustav sa tri razine priručne memorije, 

a prva razina ima odvojenu memoriju za podatke (L1d) i za instrukcije programa (L1i); 

Izvor: [5] 

Osim uvođenja priručne memorije u mikroprocesorske čipove, dizajneri su od 1985. nalazili i druga 

rješenja za rješavanje jaza između brzine registara i brzine glavne memorije, kako bi u konačnici povećali 

brzinu izvođenja programa. 

Jedan od načina koji je jako pridonosio povećanju performansi procesora sve dok je bilo moguće 

povećavati radni takt procesora (a to je postalo problematično zbog prevelikog zagrijavanja procesora) je 

tzv. paralelizam na razini instrukcija, ILP (Instruction-Level Parallelism). ILP obuhvaća više mehanizama, 

od kojih je najvažniji pipelining ("cjevovod instrukcija"), gdje se u procesor paralelno dovodi više 

instrukcija (istog programa) koje se paralelno obrađuju, ali tako da se za svaku instrukciju istovremeno 

radi različita faza obrade. Na taj način, ako se npr. jedna prosječna instrukcija obrađuje u pet faza kroz 

pet radnih taktova, paralelnom obradom pet instrukcija istovremeno moguće je teoretski svesti prosječno 

vrijeme obrade instrukcije na samo jedan takt. Problem su, međutim, npr. instrukcije grananja, tj. sve 

instrukcije koje narušavaju sekvencijalni tok programa. Na rješavanje takvih problema kod ILP-a dizajneri 

procesora su trošili sve više i više tranzistora u procesoru. 

Dosjetili su se da bi ILP mogli koristiti i na drugi način. Umjesto da paralelno obrađuju (u različitim 

fazama) instrukcije istog programa, mogli bi paralelno obrađivati instrukcije različitih programa, tj. 

instrukcije različitih dretvi (threads). Treba naglasiti da procesorske dretve (ili hardverske dretve) mogu 

odgovarati i dretvama i procesima operacijskog sustava. Takvo obrađivanje instrukcija naziva se 

multithreading (Intel koristi ime Hyper-Threading Technology), a prikazuje ga slika 3.7: 

Slika 3.7: Multithreading kod procesora; Izvor: [4] 

37

Multithreading (kao niti ILP) ne može činiti čuda. Naime, za razliku od višejezgrenih procesora, kod 

multithreadinga su duplirani samo neki elementi CPU-a. Npr. kod Intelove implementacije duplirani su 

samo procesorski registri. Dretve dijele i istu priručnu memoriju. Zbog toga procesor koji podržava dvije 

procesorske dretve nikako ne može imati 2 puta bolje performanse od istovrsnog procesora koji podržava 

samo jednu dretvu, već u praksi maksimalno do oko 1,3 puta (a i to vrlo rijetko). No, multithreading je 

ipak koristan, a koristi se i kod višejezgrenih procesora. 

Kada je postalo jasno da se više ne može povećavati radni takt procesora (zbog eksponencijalnog 

povećanja potrošnje, pa onda i zagrijavanja procesora), a broj tranzistora po procesoru se i dalje 

eksponencijalno povećava, bilo je razumno početi smještati dva ili više CPU-a (jezgri) u jedan procesorski 

čip. U računalo se onda može ugrađivati i nekoliko višejezgrenih procesora, pa se dobije arhitektura npr. 

kao na slici 3.8. Na njoj je prikazan sustav sa dva dvojezgrena procesora, a svaka jezgra ima dvije 

procesorske dretve (T1 i T2). Dretve jedne jezgre dijele priručne memorije L1i i L1d. Jezgre dijele 

priručne memorije L2 i L3. Dva procesora nemaju zajedničku priručnu memoriju, te pristupaju glavnoj 

memoriji na uobičajen način – to je tzv. centralna djeljiva memorija. Takva se arhitektura glavne memorije 

ponekad naziva UMA (Uniform Memory Access), ali se češće naziva SMP (Symmetric Multi-Processors) 

arhitektura, iako se naziv SMP ponekad koristi za UMA i NUMA arhitekturu zajedno. 

Slika 3.8: Sustav sa dva dvojezgrena procesora (svaka jezgra podržava dvije dretve); Izvor: [5] 

Osim arhitekture centralne djeljive memorije, postoji i arhitektura distribuirane djeljive memorije. Iako 

je i takva memorija djeljiva između svih procesora (pa neki kažu da je i to simetrična arhitektura, SMP), 

određeni dijelovi memorije su bliži određenim procesorima. Takva se arhitektura uobičajeno naziva 

NUMA (Non-Uniform Memory Access). Procesor ima najbrži pristup svom "lokalnom" dijelu glavne 

memorije, a brzina pristupa udaljenim dijelovima memorije ovisi o udaljenosti procesora od onoga 

procesora kojemu "pripada" taj dio memorije. U NUMA arhitekturi procesori nisu međusobno povezani 

(samo) preko memorijske sabirnice, nego su direktno povezani sa određenim brojem drugih procesora 

(tzv. Hyper Link; AMD koristi varijantu HyperTransport, tehnologiju licenciranu od nekadašnje firme 

Digital). Najčešće su povezani u obliku "hiperkocke", kao što pokazuje slika 3.9. Npr., kod desne 

hiperkocke (sa 8 procesora, C = 3), procesor 1 najbrže pristupa vlastitoj memoriji, a nakon toga 

memorijama procesora 2, 3 i 5 (sa kojima je direktno povezan, C = 1), a najudaljeniji mu je procesor 8, pa 

je pristup njegovoj memoriji najsporiji (C = 3). 

Slika 3.9: Povezivanje procesora (i pripadajućih dijelova glavne memorije) u hiperkocke ; Izvor: [5] 

Danas na tržištu postoji nekoliko procesora koji su višejezgreni, podržavaju višedretvenost i mogu se 

međusobno povezivati. Npr. Oracle (prije Sun) SPARC T3 procesor, poznat i kao Niagara 3 (prikazan na 

slici 3.10) ima 16 jezgri, svaka jezgra podržava 8 dretvi, a moguće je spojiti 4 takva procesora, čime se 

38

dobije 16 * 8 * 4 = 512 dretvi. 

Slika 3.10: Oracle SPARC T3 procesor ima 16 jezgri, a svaka podržava 8 dretvi; Izvor: [15] 

No, trenutačni lider na području standardnih (nespecijaliziranih) procesora je Vega 3 firme Azul 

Systems, koji je prvenstveno ciljan za tržište Java servera. Procesor ima 54 jezgre, a moguće je spojiti 16 

procesora (koristi se UMA arhitektura), čime se dobije sustav sa 864 jezgre. Ono što čini ovaj procesor 

zanimljivim je i podrška za tzv. hardversku transakcijsku memoriju (Hardware Transactional Memory). 

Osim Vega procesora (verzije 1, 2 i 3), Azul Systems je prilagodio Sun JVM koji podržava heap veličine i 

preko 500 GB, sa maksimalnim pauzama za GC (Garbage Collector) od samo 10-20 ms, a to zahvaljujući 

i podršci procesora Vega za GC [3]. 

Nažalost, kod višejezgrenih procesora (i višeprocesorskih sustava općenito) rast performansi 

sustava rijetko raste proporcionalno sa povećanjem broja jezgri, već je rast općenito manji. Za razliku od 

toga, povećanje radnog takta kod jednojezgrenih i jednoprocesorskih sustava u pravilu je povećavalo 

performanse skoro linearno. Zapravo, u nekim slučajevima se proporcionalno povećanje performansi 

može postići i kod višejezgrenih / višeprocesorskih sustava, npr. onda kada takvi sustavi služe za 

podršku baza podataka i aplikacijskih servera, gdje su pojedini procesi (ili dretve) međusobno nezavisni. 

No, kada pokušamo paralelizirati (razbiti u dretve) jedan program, najčešće dobijemo rezultat prikazan na 

desnoj strani slike 3.10, a ne onaj prikazan na lijevoj strani: 

Slika 3.11 Povećanje broja jezgri obično ne rezultira (skoro) linearnim povećanjem performansi 

(lijeva strana slike), već puno manjim od toga (desna strana slike); Izvor: [13] 

Razlog za to objašnjava Amdahlov zakon [13]. Ako je u nekom programu proporcija onih dijelova 

programa koji se mogu paralelno izvršavati jednaka p (što znači da je proporcija dijelova koji se ne mogu 

paralelno izvršavati jednaka 1 – p), onda se povećanjem broja CPU-a može dobiti ovo povećanje: 

Npr. ako imamo 10 procesora i ako je moguće paralelizirati 90% programa, onda je maksimalno 

povećanje brzine 5,26 puta, što je skoro dva puta manje od broja procesora. Ako je moguće paralelizirati 

99% programa, onda je povećanje 9,17 puta. 

39

4. SINKRONIZACIJSKI ALGORITMI I MEHANIZMI 

Pretpostavimo da smo napisali sljedeći programski kod [10] za računanje sekvence cijelih brojeva: 

@NotThreadSafe 

public class UnsafeSequence { 

private int value; 

/** Returns a unique value. */ 

public int getNext() { 

return value++; 

} 

} 

Prethodni kod nije dobar u konkurentnom radu. Npr., ako dvije dretve A i B izvode metodu getNext(), 

moguć je sljedeći tok izvođenja, koji će dati pogrešan rezultat – obje dretve dobile su istu sekvencu 10, 

umjesto 10 i 11. Problem je u tome što (Java) naredba value++ kod izvođenja nije atomarna, već se 

razlaže na (uobičajeno) tri interne naredbe: temp = value; temp = temp + 1; value = temp. 

Slika 4.1: Poziv metode getNext() u dretvama A i B dao je (pogrešno) istu sekvencu; 

Izvor: [10] 

Kao i kod sekvencijalnih programa, tako je i kod konkurentnih programa najvažnija osobina 

programa korektnost. Međutim, u konkurentnim programima se korektnost daleko teže postiže / 

provjerava. Prethodni program nije korektan, jer njegova točnost ovisi o međusobnom redoslijedu 

izvođenja naredbi dva (ili više) programa. Taj se problem uobičajeno naziva race conditions. 

Da bismo riješili taj problem, dretve (ili procese, ali u nastavku ćemo navoditi samo dretve, iako 

može biti oboje) moramo sinkronizirati [10]. Sinkronizacija se zasniva na ideji da dretve komuniciraju 

jedna sa drugom kako bi se "dogovorile" o sekvenci akcija. U prethodnom primjeru trebale bi se 

"dogovoriti" da u isto vrijeme samo jedna drži resurs (tj. da ima ekskluzivan pristup do njega). Dretve 

mogu komunicirati na dva načina: 

- korištenjem djeljive memorije (shared memory): dretve komuniciraju čitajući i pišući u zajednički 

dio memorije; ova tehnika je dominanta i bit će korištena u nastavku; 

- slanjem poruka (message-passing): dretve međusobno komuniciraju porukama. 

Nažalost, potreba za ekskluzivnim držanjem resursa može dovesti do različitih problema. Najveći 

problem je deadlock, kada dvije dretve (ili više njih) ostaju blokirane zato što obje trebaju (i) resurs koji je 

ekskluzivno zauzela druga dretva. Osim deadlocka, problem je i livelock, kada dretva naizgled radi, ali se 

ne dešava ništa korisno. Problem je i kada se resursi ne dodjeljuju dretvama na pravedan (fer) način, a 

najgora varijanta je kada neka dretva konstantno ostaje bez resursa - to je tzv. gladovanje (starvation). 

Međusobno isključivanje (mutual exclusion) je oblik sinkronizacije koji onemogućava istovremeno 

korištenje djeljivog resursa. S tim je povezan pojam kritične sekcije (critical section), što je naziv za dio 

programa koji pristupa djeljivom resursu. Pseudokod koji prikazuje osnovnu logiku rada sa kritičnom 

sekcijom je sljedeći: 

while true loop 

entry protocol 

critical section 

exit protocol 

non-critical section 

end 

Sinkronizacijski mehanizmi temeljeni na ideji protokola ulaz / izlaz (iz kritične sekcije) nazivaju se 

lokoti (locks). 

40

Lokoti se mogu realizirati na različite načine. Dobro su poznata [8] dva algoritma za implementaciju 

lokota - Petersonov algoritam za dvije dretve, te Lamportov Bakery (= pekara) algoritam za n dretvi: 

class Peterson implements Lock { 

// thread-local index, 0 or 1 

private volatile boolean[] flag = new boolean[2]; 

private volatile int victim; 

} 

public void lock() { 

int i = ThreadID.get(); 

int j = 1 - i; 

flag[i] = true; // I’m interested 

victim = i; // you go first 

while (flag[j] && victim == i) {}; // wait 

} 

public void unlock() { 


flag[i] = false; // I’m not interested 

} 

class Bakery implements Lock { 

boolean[] flag; 

Label[] label; 

} 

public Bakery (int n) { 

flag = new boolean[n]; 

label = new Label[n]; 

for (int i = 0; i < n; i++) { 

flag[i] = false; label[i] = 0; 

} 

} 



flag[i] = true; 

label[i] = max(label[0], ...,label[n-1]) + 1; 

while ((?k != i)(flag[k] && (label[k],k)

Kako se navodi u [8], lokote bi trebalo implementirati sa sljedećim atomarnim osnovnim operacijama 

(atomic primitives) za sinkronizaciju, koje su kompleksnije od operacija atomarnog čitanja-pisanja 

(pseudokod je pisan u Eiffelu): 

test-and-set (x, value) 

do 

temp := x 

x := value 

result := temp 

end 

compare-and-swap (x, old, new) 

do 

if x = old then 

x := new; result := true 

else 

result := false 

end 

end 

Treba napomenuti da su navedene operacije u praksi realizirane na razini procesora, tako da je 

navedeni pseudokod samo prikaz logike tih operacija. Operacija test-and-set (TAS) bila je osnovna 

operacija za sinkronizaciju u mikroprocesorima 1990-tih godina, dok praktički svaki mikroprocesor 

dizajniran poslije 2000. godine podržava jaču operaciju compare-and-swap (CAS), ili njoj ekivalentnu. No, 

CAS (i CASD, Compare-and-Swap-Double) nisu novost – bile su dio IBM 370 arhitekture od 1970! 

Jedan od najpoznatijih današnjih algoritama za implementaciju lokota je MCSLock. Njegove varijante 

osnova su za sinkronizaciju koju koriste današnji JVM-ovi (Java Virtual Machines). U nastavku su 

prikazane metode lock() i unlock() MCSLock algoritma. Vidi se (označeno crveno) da obje metode koriste 

radno čekanje (ali to je local spinning), te da lock() koristi operaciju getAndSet, a unlock() operaciju 

compareAndSet (što je uobičajeni Java naziv za hardversku operaciju compare-and-swap): 

public class MCSLock implements Lock { 

... 


QNode qnode = myNode.get(); 

QNode pred = tail.getAndSet(qnode); 

if (pred != null) { 

qnode.locked = true; 

pred.next = qnode; 

// wait until predecessor gives up the lock 

while (qnode.locked) {} 

} 

} 

} 

public void unlock() { 

QNode qnode = myNode.get(); 

if (qnode.next == null) { 

if (tail.compareAndSet(qnode, null)) 

return; 

// wait until predecessor fills in its next field 

while (qnode.next == null) {} 

} 

qnode.next.locked = false; 

qnode.next = null; 

} 

Zanimljiv je pojam konsenzus objekt (consensus object), uveden u [8]. Ne ulazeći u detalje, tj. 

matematičke definicije i dokaze navedene u [8], mogu se navesti neki zanimljivi rezultati. Konsenzus 

objekt je objekt čija klasa ima samo metodu decide(). Cilj je napraviti rješenja bez čekanja (wait-free 

solutions) za tzv. problem konsenzusa (consensus problem), kod kojeg se grupa procesa pokušava 

usaglasiti oko zajedničke vrijednosti. Broj konsenzusa (consensus number) je maksimalni broj procesa za 

koje određena primitivna operacija (konsenzus objekt) može implementirati problem konsenzusa. 

42

Zanimljivi su sljedeći rezultati (teoremi) iz [8]: 

- atomarni registri imaju broj konsenzusa 1; 

- FIFO redovi (queues) imaju broj konsenzusa 2; korolar je da je nemoguće napraviti 

implementaciju bez čekanja za redove, stogove (stacks), skupove (sets) ili liste samo od 

skupova atomarnih registara; 

- tzv. Common2 RMW (Read–Modify–Write) operacije, koje su standardno realizirane u 

procesorima, imaju broj konsenzusa 2; to su npr. operacije getAndSet(v), getAndIncrement(), 

getAndAdd(k) i slične; 

- registri koji koriste compareAndSet() i get() operacije imaju beskonačni broj konsenzusa. 

Kako se navodi u [8], strojevi (računala) koja imaju operacije kao što je compareAndSet() znače na 

području asinkronog računanja (asynchronous computation) ono što Turingovi strojevi znače na području 

sekvencijalnog računanja (sequential computation): svaki konkurentni objekt koji se može potencijalno 

implementirati, može se implementirati na način bez čekanja (wait-free manner) na takvim strojevima. Po 

riječima Mauricea Sendaka: "compareAndSet() is the king of all wild things". 

Osim navedenih nižih osnovnih operacija (primitives) za sinkronizaciju, postoje i više osnovne 

operacije, kao što su semafori i monitori. Semafore je izumio E.W. Dijkstra 1965. godine. Oni su vrlo 

važna viša osnovna operacija za sinkronizaciju, ali ne baš dovoljno visoka [13]. Opći semafor je objekt 

koji se sastoji od varijable count i dvije operacije wait i signal. Ako dretva (ili proces) zove wait dok je 

count > 0, tada se count smanjuje za 1, a inače dretva čeka da count postane pozitivan. Ako dretva zove 

signal, count se povećava za 1. Testiranje varijable count, te njeno dekrementiranje i inkrementiranje, 

mora biti izvedeno atomarnim operacijama niže razine (kao što su one prije navedene). Postoje i binarni 

semafori, koji mogu imati vrijednost 0 ili 1. Semafori nisu baš pogodni za konkurentno programiranje, jer 

pružaju preveliku fleksibilnost: teško je odrediti da li je korištenje semafora u nekom dijelu programa 

izvršeno korektno, pa često treba pregledati cijeli program; operacije wait i signal se često mogu greškom 

izostaviti, ili staviti na pogrešno mjesto; lako je uvesti deadlock u program. 

Zbog toga su Per Brinch-Hansen i Tony Hoare 1973./1974. godine izumili monitore. Treba 

napomenuti da se monitori često implementiraju na temelju semafora (iako mogu i na drugim temeljima), 

ali može se i obrnuto - implementirati semafore na temelju monitora [13], što je važno za teoretska 

razmatranja, ali u praksi nije iskoristivo. Monitori se temelje na objektno-orijentiranim principima (iako 

njegovi izumitelji u to vrijeme nisu tako zvali; napomena: prvi OOPL Simula 67 napravljen je još 1967.). U 

terminima objektno orijentirane paradigme može se reći da: 

- klasa monitor (monitor class) ima atribute koji su isključivo privatni, a njene metode (funkcije i 

procedure) se izvode sa međusobnim isključivanjem (mutual exclusion); 

- monitor je objekt (instanca) klase monitor. 

Intuitivno, atributi klase monitor odgovaraju djeljivim varijablama (shared variables), tj. dretve im 

mogu pristupati samo preko monitor metoda. Tijela rutina odgovaraju kritičnim sekcijama, jer u isto 

vrijeme može biti aktivna najviše jedna metoda monitora. 

Prednosti monitora [13] jesu: 

- strukturni pristup: programer ne mora pamtiti da iza operacije wait mora staviti signal i sl.; 

- raspodjela odgovornosti (separation of concerns): međusobno isključivanje se dobije automatski, 

a za sinkronizaciju na temelju uvjeta (condition synchronization) se koriste varijable uvjeta 

(condition variables). 

Nedostaci monitora [13] jesu: 

- performanse: lakši su za programiranje, ali ponekad sporiji od semafora; 

- pravila signalizacije (signaling disciplines): mogući su izvor konfuzije; jedno od dva pravila za 

signalizaciju, tzv. Signal and Continue, može biti problematično kod korištenja, kad se 

sinkronizacijski uvjet promijeni prije nego čekajuća dretva uđe u monitor (upravo to pravilo koristi 

Java; drugo pravilo je Signal and Wait); 

- ugnježđeni pozivi monitora (nested monitor calls): ako metoda r1 monitora M1 poziva r2 od M2, a 

r2 sadrži operaciju wait, da li se međusobno isključivanje treba odnosti na M1 i M2, ili samo M2? 

43

Kako se navodi u [10], zaključavanje, bez obzira na varijantu, ima i mana. Npr. moderni JVM-ovi 

mogu optimizirati baratanje lokotima, ali kada više dretvi istovremeno traže isti lokot, JVM najčešće treba 

"pomoć" operacijskog sustava, pri čemu dretve najčešće bivaju suspendirane (dok se lokot ne otključa). 

Zapravo, "pametni" JVM-ovi mogu koristiti statističke podatke (profiling data) za odluku da li je bolje 

suspendirati dretvu, ili koristiti spin zaključavanje (spin locking). 

Zaključavanje ima i druge mane. Ako je dretva koja drži lokot odgođena na duže vrijeme, nijedna 

dretva koja treba taj lokot ne može napredovati. Taj problem se uvećava kada lokot čeka dretva višeg 

prioriteta od one koja drži lokot – to se naziva inverzija prioriteta (priority inversion). Ako je dretva koja 

drži lokot permanentno blokirana (npr. zbog beskonačne petlje, deadlocka, livelocka i dr.), nijedna dretva 

koja čeka taj lokot neće moći napredovati. No, najveću manu zaključavanja autori u [8] vide u tome što 

"nitko stvarno ne zna kako organizirati i održavati veliki sustav temeljen na zaključavanju". 

Srećom, danas postoji već spomenuta CAS operacija za sinkronizaciju (ili njoj ekvivalentne), koja je 

po svojoj osnovi optimistička, tj. nije blokirajuća (za razliku od lokota koji su, iako se danas grade na 

temelju CAS operacije, pesimistički, tj. blokirajući). Sljedeći primjer koda [10] prikazuje brojač koji je 

realiziran pomoću CAS operacije na neblokirajući (nonblocking) način - nema lokota: 

@ThreadSafe 

public class CasCounter { 

private SimulatedCAS value; 

} 

public int getValue() { 

return value.get(); 

} 

public int increment() { 

int v; 

do { 

v = value.get(); 

} while (v != value.compareAndSwap(v, v + 1)); 

return v + 1; 

} 

Kako je već rečeno, CAS operacija je vrlo važna za sadašnjost i budućnost konkurentnog 

programiranja. Trošak korištenja CAS operacije kod današnjih procesora varira, od oko 10 do oko 150 

procesorskih ciklusa, pri čemu se stalno radi na ubrzavanju. Korištenje CAS-a je jako doprinijelo 

implementaciji neblokirajućih (bez lokota) konkurentnih algoritama i struktura podataka. Npr. U Javi 5, a 

naročito 6, implementirani su (pomoću CAS operacije) algoritmi i strukture podataka koji se u 

konkurentnom radu ponašaju dramatično brže od onih iz Java verzije 4 i ranijih verzija. 

U [8] autori navode i mane CAS operacije: algoritme koji koriste CAS (ili ekvivalentne operacije) vrlo 

je teško smisliti i često su vrlo neintuitivni. Zapravo, osnovna teškoća sa svim današnjim sinkronizacijskim 

operacijama (pa i CAS) je da one rade na samo jednoj riječi memorije, što tjera na korištenje kompleksnih 

i neprirodnih algoritama. Zapravo, postoji operacija CASD (Compare-and-Swap-Double), ali ona ažurira 

dvije susjedne riječi, a još nije realizirana operacija DCAS koja bi ažurirale dvije memorijske riječi na 

nezavisnim lokacijama. Pogotovo nije realizirana nekakva operacija multiCompareAndSet(). No, čak i da 

postoji, niti ona ne bi u potpunosti riješila problem sinkronizacije. 

Problem sa svim dosadašnjim sinkronizacijskim mehanizmima i operacijama (i onima koje postoje i 

navedenim nepostojećim operacijama), bez obzira da li rade ili ne rade zaključavanje, je da se ne mogu 

lagano komponirati, što ima veliki negativan utjecaj na modularnost konkurentnih programa. Zato je 

izmišljena transakcijska memorija (TM), a njena realizacija može biti softverska (STM), hardverska (HTM) 

ili hibridna. Transakcija [8] je sekvenca koraka koje izvršava jedna dretva. Transakcije moraju biti 

serijabilne (serializable), što znači da mora izgledati kao da se izvršavaju sekvencijalno (jedna iza druge) i 

onda kada se izvršavaju paralelno. Serijabilnost je na neki način teža varijanta linearizabilnosti 

(linearizability). Linearizabilnost definira atomarnost individualnog objekta. Serijabilnost definira 

atomarnost cijele transakcije, tj. bloka programskog koda koji može uključivati poziv metoda različitih 

objekata. Ispravno implementirane, transakcije nemaju problem deadlocka ili livelocka. 

Postoje različite softverske implementacije transakcijske memorije. Jednu implementaciju za Javu 

daju autori u [8] (inače, jedan autor je prvi dao ideju hardverske transakcijske memorije, a drugi autor je 

(su)inventor softverske transakcijske memorije). Npr. programski jezik Clojure podržava STM na razini 

jezika. Java za sada ne podržava STM niti na razini jezika, niti na razini biblioteka. 

44

U [8] je dat prikaz i hardverske transakcijske memorije (HTM). Prikazano je kako se standardna 

hardverska arhitektura može prilagoditi za podršku kratkotrajnih i malih (po veličini) transakcija. 

Napomenimo da danas postoje barem dva mikroprocesora koja podržavaju HTM - već spomenuti Vega 

procesor firme Azul Systems, a nedavno (kolovoz 2011.) mu se pridružio i BlueGene/Q firme IBM. 

Otkazan je razvoj procesora Oracle (prije Sun) Rock, koji je isto trebao podržavati HTM. Temeljna ideja 

za podršku HTM-a je u tome da današnji mikroprocesori podržavaju protokole usklađivanja priručne 

memorije (cache-coherence protocols), pa time već podržavaju većinu toga što je potrebno za realizaciju 

HTM-a. Oni već detektiraju i rješavaju sinkronizacijske konflikte između dretvi pisaca (writers), i između 

dretvi čitatelja (readers) i dretvi pisaca, te stavljaju u međuspremnik (buffer) neke probne izmjene 

(umjesto da ih direktno upisuju u glavnu memoriju). Treba dodati u hardver samo još neke detalje. 

Svaki procesor ima svoju priručnu memoriju. Priručna memorija sastoji se od grupa memorijskih 

riječi. Grupa se naziva linija (line) i ima oznaku (tag), koja pokazuje stanje linije. Koristi se tzv. MESI 

protokol, u kojem je svaka linija u jednom od sljedeća četiri stanja (MESI = početna slova tih stanja): 

- Modified: linija je modificirana i eventualno treba biti upisana natrag u (glavnu) memoriju; 

nijedan drugi procesor nema tu liniju u svom međuspremniku; 

- Exclusive: linija nije modificirana, i nijedan drugi procesor ju nema u međuspremniku; 

- Shared: linija nije modificirana, ali drugi procesori ju mogu imati u međuspremniku; 

- Invalid: linija ne sadrži suvisle podatke. 

MESI protokol detektira sinkronizacijske konflikte između individualnih čitanja i pisanja, te osigurava 

da se procesori usklade oko stanja (djeljive) memorije. Kada procesor čita ili piše u memoriju, emitira 

(broadcasts) zahtjev na sabirnicu (bus), a ostali procesori to slušaju (ponekad se to zove snooping). 

Pojednostavljeno se dešava sljedeće: 

- kada procesor daje zahtjev za učitavanje linije u ekskluzivnom modu, ostali procesori invalidiraju 

svoju kopiju; svaki procesor sa modificiranom kopijom mora upisati svoju kopiju u memoriju, prije 

nego se nastavi učitavanje; 

- kada procesor daje zahtjev za učitavanje linije u djeljivom modu, svi procesori koji imaju 

ekskluzivnu kopiju moraju joj promijeniti stanje u Shared; ostatak je kao prije; 

- ako priručna memorija postane puna, mora se izbaciti neka linija; ako je ta linija Shared ili 

Exclusive, jednostavno se zanemari; ako je Modified, mora se upisati u memoriju. 

Slika 4.2 prikazuje jedan slijed događaja. Prvo je (a) procesor A učitao (neku) liniju u ekskluzivnom 

modu. Onda je (b) procesor B isto učitao tu liniju, pa je ona sada u djeljivom modu. Zatim je (c) procesor 

B mijenjao tu liniju, pa je kod njega ona u statusu Modified, a kod procesora A je u statusu Invalid. Na 

kraju je (d) procesor B upisao tu liniju u memoriju, procesor A je osvježio svoju liniju, i oba procesora opet 

imaju status linije Shared: 

Slika 4.2: MESI protokol; Izvor: [8] 

Kako navode autori u [8], za podršku HTM-a treba zadržati MESI protokol kakav jeste, samo treba 

dodati jedan transakcijski bit za svaku oznaku linije priručne memorije (cache line’s tag). Uobičajeno je taj 

bit postavljen na 0. Kada se u priručnoj memoriji mijenja vrijednost kao posljedica transakcije, bit se 

postavlja na 1. Treba samo osigurati da se modificirane transakcijske linije ne upisuju natrag u memoriju i 

da invalidacija linije abortira transakciju. Mana ove sheme je zajednička mana skoro svih HTM shema. 

Prvo, veličina transakcije ograničena je veličinom priručne memorije (zato npr. IBM BlueGene/Q 

mikroprocesor ima čak 32 MB L2 memorije, koja se koristi za transakcije). Drugo, većina operacijskih 

sustava briše priručnu memoriju kada se dretva pasivizira, tako da trajanje transakcije može biti limitirano 

dužinom "vremenskog kvanta" operacijskog sustava. Po tome bi slijedilo da je HTM najbolji za 

kratkotrajne i male transakcije, a ostale transakcije trebale bi koristiti STM, ili kombinaciju HTM-a i STM-a. 

45

5. KONKURENTNO PROGRAMIRANJE U JAVI VERZIJE 1 - 4 

Kako navode autori u [10], iako mi sami možda nećemo kreirati dretve u našim Java programima, 

ipak ne možemo izbjeći višedretveni rad. Naime, svaka Java aplikacija koristi dretve. Kada se starta JVM, 

on kreira posebne dretve, npr. za GC (garbage collection), uz main dretvu. Kada koristimo Java AWT ili 

Swing framework, oni kreiraju posebnu dretvu za upravljanje korisničkim sučeljem. Kada koristimo 

servlete ili RMI, oni kreiraju pričuvu (pool) dretvi. Zato, kada koristimo te frameworke, moramo do neke 

mjere biti upoznati sa konkurentnošću u Javi. Naime, svaki takav framework uvodi u našu aplikaciju 

konkurentnost na implicitan način, te moramo znati napraviti da mješavina našeg koda i frameworkovog 

koda bude sigurna u višedretvenom radu. 

Svaki Java program ima barem jednu dretvu, onu koja izvršava metodu main(). Kada želimo 

napraviti svoju dretvu, imamo u Javi dva načina; jedan način je da napravimo klasu koja nasljeđuje klasu 

Thread i da nadjačamo (override) metodu run(), kao što prikazuje sljedeći primjer [14], u kojem se kreiraju 

dvije klase, Worker1 i Worker2: 

class Worker1 extends Thread { 

public void run() { 

// implement doTask1() here 

} 

} 

class Worker2 extends Thread { 


// implement doTask2() here 

} 

} 

Da bi se kreirale dretva, potrebno je kreirati objekt (instancu) klase (u ovom slučaju klase Worker1 

i/ili Worker2) i pozvati metodu start() nad tim objektom. Time će se automatski kreirati dretva i pozvati 

metoda run() u njoj. U nastavku se prikazuje implementacija metode compute() (iz neke treće klase čiji 

ostali detalji nisu prikazani), koja kreira dvije dretve, tako da dva posla (tasks) mogu biti izvedena 

paralelno (ako postoje dva slobodna procesora koja ih izvode): 

void compute() { 

Worker1 worker1 = new Thread(); 

Worker2 worker2 = new Thread(); 

worker1.start(); 


} 

Sada klase Worker1 i Worker2 proširimo sa sljedećim atributom i metodom: 

private int result; 

public void getResult() { 

return result; 

} 

Pretpostavimo da dretve snimaju rezultat izračuna u tu varijablu, a metodom getResult() ih možemo 

čitati. Sada želimo dobiti rezultat oba izračuna u metodi compute(): 

return worker1.getResult() + worker2.getResult(); 

Očito, moramo čekati da obje dretve završe prije nego dobijemo taj rezultat. To se postiže naredbom 

join() koja, kad se poziva nad dretvom-izvršiteljem, uzrokuje da dretva-pozivatelj čeka dok dretvaposlužitelj 

ne završi. U ovom slučaju programski kod dretve-pozivatelja izgleda ovako: 

int compute() { 



worker1.join(); 

worker2.join(); 

return worker1.getResult() + worker2.getResult(); 

} 

Naravno, u ovom slučaju nije važno da li prvo pozivamo join() nad worker1 ili worker2. 

46

Kako je prije navedeno, postoji i drugi način za kreiranje dretvi u Javi. Prethodno prikazani način 

(kreiranje klase koja nasljeđuje klasu Thread), iako izgleda logičan, manje se koristi jer je manje 

fleksibilan. Problem je u tome što u Javi (za sada) postoji samo jednostruko nasljeđivanje ponašanja, tj. 

klasa (a ne samo sučelja). A, "Višestruko nasljeđivanje klasa je korisno, koliko god mi šutjeli o tome :)" 

(odnosno - koliko god nas pokušavali uvjeriti u suprotno; uzgred, izgleda da se neki oblik višestrukog 

nasljeđivanja ponašanja priprema u Javi 8). Bez višestrukog nasljeđivanja klasa, ako naša klasa "potroši" 

jednostruko nasljeđivanje za klasu Thread, ne može naslijediti od neke druge klase. Zbog toga se češće 

koristi drugi način kreiranja dretve. Prvo se napiše "pomoćna" klasa koja nasljeđuje sučelje (interface) 

Runnable, pri čemu mora implementirati metodu run(). Primjer [13]: 

public class RunThread implements Runnable { 

String id; 

public RunThread(String id) { 

this.id = id; 

} 


// do something when executed 

System.out.println("This is thread " + id); 

} 

} 

Onda se objekt te "pomoćne" klase šalje konstruktoru koji kreira objekt klase Thread (tj. dretvu) u 

kodu naše "glavne" klase: 

Thread mt = new Thread(new RunThread("mt")); 

mt.start(); ... 

Do sada prikazani rad sa dretvama u Javi izgleda prilično jednostavno. No, problemi nastaju kada se 

dvije dretve (ili više njih) upliću jedna drugoj u posao, npr. tako da modificiraju isti objekt. To može stvoriti 

netočne rezultate i naziva se race condition, npr. u ovom slučaju [14]: 

class Counter { 

private volatile int value = 0; 

public int getValue() { 

return value; 

} 

public void setValue(int someValue) { 

value = someValue; 

} 

public void increment() { 

value++; -- napomena: niti sama naredba value++ nije atomarna 

} 

} 

Pretpostavimo da neka metoda u nekoj drugoj klasi kreira objekt klase Counter i sadrži sljedeći kod: 

x.setValue(0); 

x.increment(); 

int i = x.getValue(); 

Pitanje je: koju vrijednost ima varijabla i na kraju ovih naredbi? Ako je riječ o jednodretvenom 

programu, onda je vrijednost 1. No u konkurentnom radu brojač može biti modificiran od drugih dretvi, 

tako da rezultat ovisi o ispreplitanju naredbi ove dretve sa naredbama neke druge dretve. Npr. ako druga 

dretva konkurentno izvodi naredbu 


varijabla i na kraju navedenih naredbi prve dretve može imati vrijednost 1, 2 ili 3, tj. rezultat ovisi o 

slučajnom redoslijedu izvođenja naredbi dvije dretve (zapravo, dodatni problem je i u tome što sama 

naredba value++ nije atomarna, već se u stvarnosti razlaže na tri interne naredbe: temp = value; temp = 

temp + 1; value = temp). Naravno, to nije ono što se želi. Taj se problem rješava pomoću sinkronizacije 

koja se zove međusobno isključivanje (mutual exclusion), za što Java ima jednostavno rješenje još od 

verzije Java 1. Svaki objekt u Javi ima lokot (lock; nasljeđuje se automatski od superklase Object), kojega 

istovremeno može držati (zaključati) samo jedna dretva. 

47

Objekt koji će služiti kao lokot može se kreirati npr. ovako: 

Object lock = new Object(); 

Dretva koja će tražiti lokot (tj. zaključati lokot) to radi pomoću naredbe synchronized, koja označava 

početak tzv. synchronized bloka (inače synchronized i volatile su jedine Java ključne riječi vezane za 

konkurentnost; ostalo su metode klase Object ili metode klasa specijaliziranih za konkurentnost): 

synchronized(lock) { 

// critical section 

} 

Kada dretva dođe do početka tog bloka, pokuša zaključati lokot objekta koji je naveden kao 

argument naredbe synchronized. Ako je lokot zaključan od neke druge dretve, polazna dretva čeka dok 

on ne postane otključan. Nakon toga ga polazna dretva drži zaključanim sve do kraja tog bloka. Problem 

iz prethodnog primjera mogli bismo riješiti pomoću synchronized npr. ovako (u prvoj, odnosno drugoj 

dretvi; naravno, moramo biti sigurni da je varijable lock u oba koda referenciraju isti objekt): 

// prva dretva 



x.increment(); 

int i = x.getValue(); 

} 

// druga dretva 



} 

Osim bloka, i cijela metoda (funkcija / procedura) može imati synchronized na početku: 

synchronized type method(args) { 

// body 

} 

što je, zapravo, isto kao i ovo: 

type method(args) { 

synchronized(this) { 

// body 

} 

} 

Prethodno je slično konceptu monitora, koji je prikazan u 4. točki, ali dizajneri Jave su napravili 

određena odstupanja od tog koncepta. Svaki objekt u Javi ima unutarnji (intrinsic) lokot i unutarnju 

kondiciju (condition). Ako je metoda deklarirana pomoću ključne riječi synchronized, ona djeluje kao 

monitor. Kondicijskim varijablama se pristupa pomoću naredbi wait / notifyAll / notify, što će biti prikazano 

u nastavku. Međutim, Java objekt se razlikuje od monitora [9] u tri važne stvari, kompromitirajući time 

sigurnost dretve (thread safety) : 

- atributi ne moraju biti privatni; 

- metode ne moraju biti sinkronizirane; 

- unutarnji lokot je pristupačan klijentima. 

Zbog toga je jedan od inventora monitora, Per Brinch Hansen, 1999. godine izjavio: "Zaprepašćuje 

me da je ovaj nesigurni Java paralelizam shvaćen tako ozbiljno od programske zajednice, četvrt stoljeća 

nakon invencije monitora i programskog jezika Concurrent Pascal." [Java’s Insecure Parallelism, ACM 

SIGPLAN Notices 34:38–45, April 1999.] 

Kao što vrijedi za monitor, tako vrijedi i za Java klase - zaštita pristupa djeljivim varijablama nije 

jedini razlog zašto dretve moraju biti međusobno sinkronizirane. Često puta treba odgoditi izvođenje 

metode (ili dijela metode) u nekoj dretvi, dok se ne zadovolji određeni uvjet (a taj uvjet nije samo 

otključavanje određenog lokota). To se zove sinkronizacija na temelju uvjeta (condition synchronization), 

koja se u Javi implementira pomoću naredbi wait / notifyAll / notify, koje se pozivaju nad sinkroniziranim 

objektima. 

48

Jedan primjer problema koji traži sinkronizaciju na temelju uvjeta je tzv. problem proizvođač-potrošač 

(producer-consumer problem), koji je,u različitim varijantama, čest u praksi. Može se apstraktno opisati 

na ovaj način [14]: 

- Proizvođač: u svakoj iteraciji (beskonačne) petlje, proizvodi podatke koje potrošač konzumira; 

- Potrošač: u svakoj iteraciji (beskonačne) petlje, troši podatke koje je proizveo proizvođač. 

Proizvođači i potrošači komuniciraju preko djeljivog međuspremnika (buffer) koji implementira red 

(queue), za koji smatramo (u ovom primjeru) da je neograničen, pa će nam biti važno samo da li je 

prazan. U primjeru [14] se prikazuje samo dio klase, a ne kompletan programski kod. Prvo pretpostavimo 

da imamo klasu Buffer (koja implementira neograničeni red) i da imamo jedan objekt te klase: 

Buffer buffer = new Buffer(); 

Proizvođači dodaju podatke na kraj reda, koristeći metodu (reda) void put(int item), a potrošači 

skidaju podatak sa reda koristeći metodu int get(). Broj podataka koji se nalaze u redu može se dobiti 

pomoću metode int size(). Pretpostavimo sada da u klasi Consumer imamo sljedeću metodu: 

public void consume() { 

int value; 

synchronized(buffer) { 

value = buffer.get(); // incorrect: buffer could be empty 

} 

} 

Metoda nije dobra, jer ne provjerava da li je red (tj. međuspremnik) prazan, što može prouzročiti 

grešku kod izvođenja (runtime error). Dretva treba čekati dok red bude neprazan i tek tada pročitati 

podatak iz njega. Čekanje se u Javi može napraviti pomoću metode wait(), koja se može pozvati samo 

nad objektom koji je prethodno zaključan, tj. samo unutar synchronized bloka. Wait() tada blokira tekuću 

dretvu i otpušta lokot koji je dretva držala. Slijedi primjer [14]: 

public void consume() throws InterruptedException { 

int value; 


while (buffer.size() == 0) { 

buffer.wait(); 

} 

value = buffer.get(); 

} 

} 

Sada lokot može preuzeti (zaključati) neka druga dretva, koja može mijenjati stanje navedene 

kondicije. Da obavijesti prvu dretvu o promjeni kondicije, druga dretva poziva notify(), što odblokira prvu 

dretvu, koja čeka na taj lokot, ali druga dretva ne otključa lokot odmah, već tek na kraju svog 

synchronized bloka (unutar kojega je i pozvala notify()). U 4. točki smo naveli da kod monitora dva 

osnovna tzv. pravila signalizacije (signaling disciplines) mogu biti Signal and Wait ili Signal and Continue 

(Java koristi samo ovo drugo). Primjer u kojem proizvođač obavještava potrošača o promjeni kondicije; 

public void produce() { 

int value = random.produceValue(); 


buffer.put(value); 

buffer.notify(); 

} 

} 

Proizvođač je proizveo neki slučajni broj, zaključao red, spremio podatak u njega i pozvao notify(), 

čime je odblokirao jednu (bilo koju!) dretvu koja je čekala na taj lokot. Na kraju synchronized bloka (što je 

u ovom slučaju bilo odmah iza) je i otključao taj lokot. No, odblokirana dretva ne može biti sigurna da je 

taj uvjet valjan i kada ona dođe na red, jer je u međuvremenu neka treća dretva mogla potrošiti podatak i 

red je možda opet prazan. Stoga je dretva potrošač morala ispitivati uvjet u while petlji. Važno je i to da 

notify() uvijek odblokira samo jednu (bilo koju!) dretvu koja čeka na određeni lokot. Stoga je u praksi puno 

sigurnije pozivati notifyAll(), koja odblokira sve dretve koje čekaju na određeni lokot. 

49

Metode wait(), notify() / notifyAll() rade interno sa tzv. unutarnjim redovima kondicija (intrinsic 

condition queues). Vidjet ćemo da u Javi 5 postoji njihova generalizacija, koja omogućava da programeri 

eksplicitno rade sa kondicijama. 

Na slici 5.1 prikazan je dijagram promjene stanja Java dretvi. Vidi se (i) da dretva prelazi iz stanja 

Ready (češće se to stanje naziva Runnable) u stanje Waiting nakon što pozove wait(), a obrnuti prijelaz 

se zbiva kada druga dretva (što se iz slike ne vidi) pozove notify() / notifyAll(): 

Slika 5.1: Dijagram promjene stanja Java dretvi; Izvor: [13] 

Preciznije se zbivanje može pratiti kroz sljedeće dvije slike. Na slici 5.2 prikazana su tri koraka kod 

prijelaza dretve iz stanja Running (u kojem se dretva izvršava u procesoru) u stanje Waiting. Prvo dretva 

poziva metodu wait() (1), naravno, uvijek unutar synchronized bloka, čime otključa lokot i prelazi u stanje 

Waiting (2). Sada neka dretva koja je Ready može preći u stanje Running, jer se procesor oslobodio. 

Slika 5.2: Promjena stanja nakon wait() operacije; Izvor: [13] 

Slika 5.3 prikazuje nastavak zbivanja - poziva se notify() ili notifyAll(). Nakon što neka druga dretva 

pozove notify() ili notifyAll() (1) (naravno, uvijek unutar synchronized bloka), jedna dretva (ako je notify()) 

ili sve dretve (ako je notifyAll()) koje čekaju na lokot koji ima ta druga dretva, prelazi (2) iz stanja Waiting u 

Ready. Naravno, rekli smo da dretva koja poziva notify() / notifyAll() ne otključava lokot odmah, već tek 

kod izlaska iz synchronized bloka (to je signalizacijsko pravilo Signal and Continue). Mora se primijetiti da 

ova slika ne prikazuje metodu notify() u svim njenim detaljima. 

Slika 5.3: Promjena stanja nakon notify() operacije; Izvor: [13] 

50

Slika 5.4 prikazuje stanja Java dretvi na malo drugačiji način. Ovdje je stanje Waiting detaljnije 

razloženo u tri posebna stanja: Blocked, Waiting i Timed waiting (a Ready se naziva Runnable). No, niti 

ovdje zbivanja koja implicitno imaju naredbe notify() / notifyAll() nisu prikazana potpuno detaljno. 

Napomenimo da dretva prelazi u stanje Waiting ne samo nakon naredbe wait() (i join()), već i kod čekanja 

na objekte klase Lock ili Condition iz java.util.concurrent librarya, uvedenog u Java 5 verziji. 

Slika 5.4: Dijagram promjene stanja Java dretvi; Izvor: [9] 

Spomenimo da uz osnovnu varijantu metode wait() postoje i varijante wait(long millis) i wait(long 

millis, int nanos) koje uzrokuju da dretva čeka na obavijest od druge dretve ili na istek definiranog 

vremena. Java metode wait() / notify / notifyAll pripadaju klasi Object, od koje ih nasljeđuju sve druge 

klase. Inače, Java metode notify / notifyAll se u izvornoj terminologiji monitora zovu signal / signal_all. 

Na kraju, prikažimo kako može nastati deadlock, kada se dvije dretve (ili grupa dretvi) blokiraju 

zauvijek, jer jedna dretva čeka lokot koji ima druga, i obrnuto. Primjer iz [14]: 

public class C extends Thread { 

private Object a; 

private Object b; 

public C(Object x, Object y) { 

a = x; 

b = y; 

} 


synchronized(a) { 

synchronized(b) { 

... 

} 

} 

} 

} 

Pretpostavimo sada da se izvodi sljedeći kod, gdje su a1 i b1 objekti tipa Object: 

C t1 = new C(a1, b1); 

C t2 = new C(b1, a1); 

t1.start(); 

t2.start(); 

Budući da su argumenti a1 i b1 međusobno permutirani kod kreiranja dretvi t1 i t2, može doći do 

takve sekvence poziva u kojem dretva t1 zaključa objekt a1, dretva t2 zaključa objekt b1, i onda su obje 

dretve blokirane. Za razliku od sustava za upravljanje bazom podataka (što smo vidjeli u 1. točki), Java 

sustav ovdje neće detektirati (i onda riješiti) deadlock. Zato programer mora paziti da do deadlocka ne 

dođe. U Javi 5 postoji mogućnost da se program lakše napiše na način da ne dođe do deadlocka. 

51

6. KONKURENTNO PROGRAMIRANJE U JAVI VERZIJE 5, 6, 7 

Konkurentnost u Javi od verzije 1 do verzije 4 praktički se nije mijenjala, osim što su se rješavali 

bugovi i sl. Suštinu "alata" za konkurentno programiranje činili su: klasa Object, tj. njen unutarnji (intrinsic) 

lokot (atribut te klase) i njene metode wait(...) / notify / notifyAll, Java ključne riječi synchronized i volatile, 

klasa Thread i sučelje Runnable. 

U Javi verzije 5, koja se pojavila 2004. godine, uvedeno je dosta novina na drugim područjima (npr. 

generičke klase, bolje kolekcije i dr.), ali i na području konkurentnog programiranja. JSR 166, koji se 

odnosi na konkurentnost, temeljen je uglavnom na paketu edu.oswego.cs.dl.util.concurrent, kojega je 

napravio Doug Lea. Kroz novi paket java.util.concurrent uvedene su sljedeće nove mogućnosti: 

- Executors (thread pools, scheduling); 

- Futures; 

- Concurrent Collections; 

- Locks (ReentrantLock, ReadWriteLock...); 

- Conditions; 

- Synchronizers (Semaphores, Barriers...); 

- Atomic variables; 

- System enhancements. 

U Java verziji 6, koja se pojavila godinu i pol nakon verzije 5, nije se pojavilo ništa revolucionarno, ali 

su se na području konkurentnog programiranja (kao i na drugim područjima) "iznutra" poboljšale 

biblioteke, bilo da su se riješili bugovi ili poboljšale performanse. U Java verziji 7, koja je izašla u ljeto ove 

godine (2011.) u području konkurentnog programiranja novost je Fork/Join Framework. 

U ovoj točki prikazat će se (ukratko) samo neke mogućnosti uvedene u Javi 5 (sa poboljšanjima u 

Javi 6), i to ReentrantLock, ReadWriteLock, Conditions i Atomic variables. 

Do Java 5 verzije, jedini mehanizmi za koordinaciju pristupa djeljivim podacima bili su synchronized 

(koji koristi unutarnji lokot) i volatile. Java 5 donijela je i ReentrantLock, što je (klasa za) eksplicitan lokot. 

Kako navode autori u [10], on nije zamjena za implicitan, unutarnji lokot, već alternativa koju je bolje 

koristiti u nekim (ali ne svim) slučajevima. Klasa ReentrantLock implementira sučelje Lock, koje ima ove 

metode: 

public interface Lock { 

void lock(); 

void lockInterruptibly() throws InterruptedException; 

boolean tryLock(); 

boolean tryLock(long timeout, TimeUnit unit)throws InterruptedException; 

void unlock(); 

Condition newCondition(); 

} 

Zaključavanja pomoću objekata klase ReentrantLock ima istu semantiku kao i synchronized, ali ima i 

dodatne mogućnosti. Najčešći oblik korištenja je sljedeći [10]: 

Lock lock = new ReentrantLock(); 

... 

lock.lock(); 

try { 

// update object state 

// catch exceptions and restore invariants if necessary 

} finally { 

lock.unlock(); 

} 

Za razliku od implicitnog zaključavanja i otključavanja kod synchronized, ovdje se zaključavanje i 

otključavanje mora raditi eksplicitno, a vrlo je važno da se otključavanje stavi u finally blok, inače lokot 

može ostati stalno zaključan. Moglo bi se reći da je to korak nazad u odnosu na synchronized, jer je sad 

moguće (dodatno) pogriješiti. No, mogućnost da se zaključavanje i otključavanje lokota napravi u 

različitim dijelovima koda ponekad je nužna (iako je takav kod manje čitljiv), a sa synchronized se to nije 

moglo izvesti. Preporuča se korištenje dosadašnje synchronized varijante ako nam ne treba ova 

mogućnost ili dodatne mogućnosti klase ReentrantLock, koje su navedene u nastavku. 

52

ReentrantLock ima ove dodatne mogućnosti: 

- pomoću metode tryLock() moguće je vidjeti da li je lokot slobodan; ako jeste, zaključa se, a ako 

nije, metoda odmah vraća exception; ovo je slično kao SQL naredba SELECT ... FOR UPDATE 

NOWAIT; 

- pomoću metode tryLock(long timeout,TimeUnit unit) moguće je vidjeti da li je lokot slobodan; ako 

jeste, zaključa se, a ako nije, metoda vraća exception nakon isteka zadanog vremena; ovo je 

slično kao SQL naredba SELECT ... FOR UPDATE WAIT timeout; 

- pomoću metode lockInterruptibly() dretva može (pokušati) zaključati lokot na taj način da 

aktivnost koja se može prekinuti (cancellable activities) može prekinuti dretvu dok čeka na lokot; 

- metoda newCondition() omogućava definiranje kondicija (condition) uz lokot. 

Sljedeći primjer [10] prikazuje korištenje metode tryLock(long timeout,TimeUnit unit): 

public boolean trySendOnSharedLine 

(String message, long timeout, TimeUnit unit)throws InterruptedException 

{ 

long nanosToLock = unit.toNanos(timeout) 

if (!lock.tryLock(nanosToLock, NANOSECONDS)) return false; 

try { 

return sendOnSharedLine(message); 

} finally { 


} 

} 

Sljedeći primjer [10] prikazuje korištenje metode lockInterruptibly(): 

public boolean sendOnSharedLine(String message) 

throws InterruptedException 

{ 

lock.lockInterruptibly(); 

try { 

return cancellableSendOnSharedLine(message); 

} finally { 


} 

} 

Treba napomenuti da zapravo i metoda tryLock(long timeout,TimeUnit unit) ima mogućnost 

prekidanja, a ne samo mogućnost čekanja (određeno vrijeme) da se lokot otključa. Prikazane metode 

omogućavaju programiranje na način da se izbjegne deadlock. 

Slika 6.1 prikazuje kako je u Java 5 verziji ReentrantLock bio značajno bolje propusnosti (kod većeg 

broja dretvi) od synchronized varijante, ali je u verziji Java 6 to izjednačeno: 

Slika 6.1: Propusnosti ReentrantLock-a u odnosu na propusnost unutarnjeg lokota; Izvor: [10] 

53

Kod kreiranja ReentrantLock lokota mogu se definirati dvije varijante: fer i ne-fer lokot. Fer lokoti 

osiguravaju da dretve dobivaju lokote po redoslijedu prispijeća zahtjeva. Default su ne-fer lokoti, isto kao 

kod synchronized varijante. Ako nam nije nužno potreban fer lokot, bolje je koristiti ne-fer lokot, zbog 

puno veće propusnosti, što prikazuje slika 6.2: 

Slika 6.2: Propusnost fer i ne-fer ReentrantLock lokota; Izvor: [10] 

Osim dvije krivulje za fer i ne-fer lokote, vidi se i krivulja koja prikazuje korištenje 

ConcurrentHashMap kolekcije. Uglavnom je bolje koristiti konkurentne kolekcije, koje često koriste 

neblokirajuće algoritme (tj. sinkronizaciju bez lokota), nego vlastita rješenja. 

Osim ReentrantLock lokota, postoje i lokoti klase ReentrantReadWriteLock, koja implementira 

sučelje ReadWriteLock: 

public interface ReadWriteLock { 

Lock readLock(); 

Lock writeLock(); 

} 

Strategija zaključavanja koju implementiraju ovakvi lokoti je: istovremeno može raditi više čitatelja 

koji blokiraju pisce, ali može raditi samo jedan pisac, koji blokira čitatelje i (druge) pisce. Slika 6.3 

prikazuje propusnost koju ima ReentrantReadWriteLock u odnosu na ReentrantLock: 

Slika 6.3: Propusnost "običnih" i read-write reentrant lokota; Izvor: [10] 

U Java 5 verziji pojavili su se i objekti-kondicije (condition objects). Kao što su eksplicitni lokoti 

generalizacija unutarnjih lokota, tako su i objekti-kondicije generalizacija unutarnjih redova kondicija 

(intrinsic condition queues). Kondicija (condition) se povezuje sa Lock objektom na taj način da se pozove 

Lock.newCondition na već kreiranom lokotu (Lock objektu). Za razliku od unutarnjih lokota i njihovih 

redova kondicija, gdje je uz jedan unutarnji lokot vezan samo jedan red kondicija, kod eksplicitnih lokota 

može se vezati više kondicija za jedan lokot, ako postoji potreba. Kondicije imaju metode await, signal, 

signalAll, koje su ekvivalentne metodama wait, notify, notifyAll kod unutarnjih redova kondicija. 

54

Ovako izgleda sučelje Condition: 

public interface Condition { 

void await() throws InterruptedException; 

boolean await(long time, TimeUnit unit) throws InterruptedException; 

long awaitNanos(long nanosTimeout) throws InterruptedException; 

void awaitUninterruptibly(); 

boolean awaitUntil(Date deadline) throws InterruptedException; 

void signal(); 

void signalAll(); 

} 

Primjer korištenja kondicija za implementaciju ograničenog međuspremnika (vidi se da se na jedan 

lokot vežu dvije kondicije, te da se koriste nove metode await i signal): 

class BoundedBuffer { 

Lock lock = new ReentrantLock(); 

Condition notFull = lock.newCondition(); // Povezivanje jednog lokota 

Condition notEmpty = lock.newCondition(); // i dvije kondicije 

Object[] items = new Object[100]; 

int putptr, takeptr, count; 

} 

public void put(Object x)throws IE { 

lock.lock(); 

try { 

while (count == items.length) notFull.await(); 

items[putptr] = x; 

if (++putptr == items.length) putptr = 0; 

++count; 

notEmpty.signal(); 

} finally { 


} 

} 

public Object take() throws IE { 

lock.lock(); 

try { 

while (count == 0) notEmpty.await(); 

Object x = items[takeptr]; 

if (++takeptr == items.length) takeptr = 0; 

--count; 

notFull.signal(); 

return x; 

} finally { 


} 

} 

Vidjeli smo neka (a ima ih još dosta) poboljšanja u zaključavanju u Javi 5. No, kako kažu autori u 

[10], mnoge klase u paketu java.util.concurrent, kao što su Semaphore i ConcurrentLinkedQueue, pružaju 

bolje performanse i skalabilnost u odnosu na stare klase (koje su koristile synchronized), ne zato što 

koriste nove vrste lokota, već zato što uopće ne koriste lokote - koriste atomarne varijable (atomic 

variables) i neblokirajuću sinkronizaciju (sinkronizacija bez lokota). Neblokirajući algoritmi značajno su 

kompleksniji od blokirajućih, ali pružaju bolje performanse i skalabilnost, nemaju problema npr. sa 

deadlockom, pa su najčešći predmet novijih istraživanja na području konkurentnih algoritama. 

No, kako naglašava autor u [6], pisanje neblokirajućih konkurentnih algoritama je posao za eksperte. 

Navodi da onaj tko misli da zna pisati takve algoritme treba proći tzv. Goetzov test (Brian Goetz je 

dugogodišnji stručnjak za konkurentno programiranje u Javi, trenutačno Java Language Architect u firmi 

Oracle): "Ako znate pisati JVM visokih performansi za moderne mikroprocesore, tada ste kvalificirani da 

razmišljate o tome da li smijete izbjeći lokote za sinkronizaciju (tj. pisati neblokirajuće algoritme)". 

55

Atomarne varijable su na neki način generalizacija volatilnih varijabli (volatile variables) koje su 

postojale i prije Jave 5. Postoji dvanaest klasa atomarnih varijabli, podijeljenih u četiri grupe, a najvažnija 

je grupa skalarnih varijabli (scalars), koju čine klase AtomicInteger, AtomicLong, AtomicBoolean i 

AtomicReference. Atomarne varijable su, kao i lokoti u novim verzijama Jave, implementirane uglavnom 

uz pomoć CAS (compare-and-swap) operacije, koja je opisana u 4. točki. Jedino kad određeni hardver ne 

podržava tu operaciju (što je rijetkost, jer svi procesori već desetak godina podržavaju CAS ili ekvivalent), 

onda JVM umjesto CAS obično koristi spinn lock (zaključavanje pomoću radnog čekanja). JVM-ovi su, 

kao i operacijski sustavi, koristili CAS (ako je postojao na određenom hardveru) i prije Jave 5, ali tek od 

Jave 5 mogu Java klase (uključujući i one koje mi pišemo) koristiti CAS operaciju. 

U nastavku se prikazuju dvije realizacije [10] generatora pseudoslučajnih brojeva - pomoću klase 

ReentrantLock i pomoću klase AtomicInteger i operacije CAS [10]: 

public class ReentrantLockPseudoRandom extends PseudoRandom { 

private final Lock lock = new ReentrantLock(false); 

private int seed; 

ReentrantLockPseudoRandom(int seed) {this.seed = seed;} 

public int nextInt(int n) { 

lock.lock(); 

try { 

int s = seed; 

seed = calculateNext(s); 

int remainder = s % n; 

return remainder > 0 ? remainder : remainder + n; 

} finally {lock.unlock();} 

} 

} 

public class AtomicPseudoRandom extends PseudoRandom { 

private AtomicInteger seed; 

AtomicPseudoRandom(int seed) {this.seed = new AtomicInteger(seed);} 

public int nextInt(int n) { 

while (true) { 

int s = seed.get(); 

int nextSeed = calculateNext(s); 

if (seed.compareAndSet(s, nextSeed)) { 

int remainder = s % n; 

return remainder > 0 ? remainder : remainder + n; 

} 

} 

} 

} 

Na slici 6.4 prikazuje se propusnost oba rješenja. Prikazana je i krivulja za tzv. ThreadLocal varijable 

(imaju najbolje performanse), a to su varijable koje imaju svoju posebnu instancu za svaku dretvu, na 

temelju thread local storage mehanizma - to je nešto slično kao kada u bazi podataka jedna sesija ne vidi 

mijenjane, ali nekomitirane, podatke druge sesije, jer čita svoju vlastitu verziju u UNDO tablespaceu. 

Slika 6.4: Propusnost ReentrantLock i AtomicInteger kod srednjeg opterećenja; Izvor: [10] 

56

7. EIFFEL OOPL 

Eiffel je 1985. godine dizajnirao (a 1986. je napravljen prvi compiler) Bertrand Meyer, jedan od 

najvećih autoriteta na području OOPL-a. Prvo izdanje njegove knjige OOSC (1988.), značajno je djelo 

informatičke literature (aktualno je 2. izdanje iz 1997.). Ta je knjiga upoznala javnost sa OO jezikom Eiffel 

(tada verzije 2). Eiffel je od početka je podržavao višestruko nasljeđivanje, generičke klase, obradu 

iznimaka, garbage collection i metodu Design by Contract (DBC), a kasnije su mu dodani agenti 

(vjerojatno će nešto slično imati Java 8 pod imenom closures ili lambda expressions; C# ih već ima), 

nasljeđivanje implementacije (uz nasljeđivanje tipa) i metoda za konkurentno programiranje Simple 

Concurrent Object-Oriented Programming (SCOOP). U široj je javnosti daleko manje poznat nego C++ i 

Java, ali ga mnogi autoriteti smatraju danas najboljim OOPL jezikom. Eiffel je od 2005. godine ECMA 

standardiziran, a od 2006. ISO standardiziran. 

Slijedi primjer Eiffel klase. Napomenimo da konstruktor metoda u Eiffelu ne mora imati isto ime kao 

klasa u kojoj se nalazi, ali smo namjerno zadržali isto ime, kao što npr. mora biti u Javi: 

class ZIVOTINJA 

create zivotinja 

feature {ANY} 

ime : STRING 

visina_cm: DOUBLE 

zivotinja (p_ime: STRING; p_visina_cm: REAL) is 

do 

ime := p_ime 

visina_cm := p_visina_cm 

end 

prikazi_podatke is 

do 

print (" Ime: "); print (ime) 

print (", Visina (cm): "); print (visina_cm) 

print (", Visina (inch): "); print (visina_inch) 

end 

visina_inch: REAL is 

do 

Result := visina_cm / 2.54 

end 

end 

Vidimo da se u Eiffelu ne mora koristiti znak za odvajanje naredbi " ; ", ali je preporuka da se koristi 

ako imamo više naredbi u istom retku (zbog čitljivosti). Primijetimo da u funkciji ne postoji ključna riječ 

return, već Eiffel ima posebnu predefiniranu varijablu Result. Također, primijetimo da Eiffel (a to ima i 

PL/SQL) omogućava tzv. uniformni pristup (uniform access), tj. poziv atributa ne razlikuje se od poziva 

funkcije bez parametara. Npr. u proceduri prikazi_podatke funkciju pozivamo sa visina_inch, dok npr. 

Java traži da se koriste zagrade i kad metoda nema parametara, pa se mora pisati visina_inch(). 

Uniformni pristup se smatra značajnom mogućnošću OOPL jezika. 

Eiffel ima vrlo jednostavno i vrlo fleksibilno definiranje pristupa, jer za svaki atribut/metodu možemo 

definirati koja mu klasa može pristupati. Npr, ako ne želimo dati niti jednoj klasi pristup atributu visina_cm 

i funkciji visina_inch, pristup konstruktoru zivotinja želimo dozvoliti samo klasama TEST1 i TEST2, a 

pristup atributu ime i proceduri prikazi_podatke želimo dozvoliti svim klasama, napisat ćemo: 

feature {NONE} visina_cm ...; visina_inch ...; 

feature {TEST1, TEST2} zivotinja ...; 

feature {ANY} ime ...; prikazi_podatke ...; 

Važno je naglasiti da u Eiffelu dozvola pristupa atributu znači dozvolu čitanja atributa, ne i dozvolu 

pisanja. Vrijednosti atributa može mijenjati samo metoda iz klase u kojoj je atribut definiran (ili iz njene 

podklase), pomoću set procedura. Zbog toga u Eiffelu ne treba raditi get funkcije, dok Java mora imati get 

funkcije ako želimo atribute zaštiti od upisa izvan klase. Zanimljivo je da Eiffel može sakriti atribute nekog 

objekta čak i od drugih objekata (instanci) iste klase, pomoću {NONE} ili, što je isto, pomoću {}. Eiffel ne 

poznaje sakrivanje atributa/metoda od podklase (nema nešto kao Java private), jer Meyer drži da to nije 

u skladu sa OO modelom. 

57

Eiffel podržava jednostruko i višestruko nasljeđivanje (klasa). No, postoje dvije vrste nasljeđivanja - 

nasljeđivanja tipa (zove se i semantičko nasljeđivanje, ili nasljeđivanje sučelja) i nasljeđivanja 

implementacije (zove se i sintaktičko nasljeđivanje, ili nasljeđivanje programskog koda). Prva vrsta 

nasljeđivanja je "pravo" nasljeđivanje, u kojem podklasa predstavlja podtip. Druga vrsta nasljeđivanja je 

"praktično" nasljeđivanje, gdje se želi iskoristiti neki postojeći programski kod, ali se ne želi koristiti 

polimorfizam. Eiffel je dobio nasljeđivanje implementacije naknadno, po uzoru na jezik C++. 

Neki drže višestruko nasljeđivanje vrlo važnim svojstvom OOPL jezika. Npr. Meyer drži da je u 

mnogim konkretnim situacijama potrebno da klasa može naslijediti dvije ili više klasa i duhovito kaže da je 

odgovor na pitanje "Da li moja klasa C treba naslijediti klasu A ili klasu B (budući da moj jezik podržava 

samo jednostruko nasljeđivanje)?" često isto tako težak kao i odgovor na pitanje "Da li da izaberem 

mamu ili tatu?". Višestruko nasljeđivanje je naročito korisno u slučaju kada postoje dva (ili više) jednako 

važna kriterija za kreiranje hijerarhije klasa (jednostruko nasljeđivanje dopušta samo jednu hijerarhiju) i u 

slučaju kada podklasa od jedne nadklase nasljeđuje tip, a od druge nadklase nasljeđuje implementaciju, 

tzv. mix-in nasljeđivanje (primjer: klasa ARRAYED_STACK nasljeđuje od apstraktne klase STACK i klase 

ARRAY). Slijedi Eiffel (nepotpuni) primjer klase C koja nasljeđuje od klasa A i B, pri čemu klasa C 

nadjačava jedan atribut i jednu metodu iz klase A i jednu metodu iz klase B: 

class C 

inherit 

A redefine atribut_iz_a, metoda_iz_a end 

B redefine metoda_iz_b end 

feature 

... 

end 

Kod višestrukog nasljeđivanja najčešće se navode dva glavna problema. Jedan je problem kada 

roditeljske klase imaju atribute/metode istog imena, ali različitog značenja. Eiffel za to ima vrlo 

jednostavno rješenje – preimenovanje (barem jednog) atributa/metode pomoću rename. Drugi je problem 

kada imamo tzv. ponavljajuće (repeated) nasljeđivanje, npr. u primjeru gdje su klase B i C djeca klase A, 

a klasa D je dijete i od B i od C, pa izlazi da je klasa D dva puta (indirektno) dijete od klase A (to se 

naziva i dijamantnim nasljeđivanjem, zbog sličnosti crteža takvih klasa sa skicom dijamanta). Ako 

atributi/metode klase A nisu nadjačani u klasama B i C, Eiffel za to ima najjednostavnije moguće rješenje 

– ne treba ništa napraviti, jer duplih atributa/metoda niti nema. Ako su pak atributi/metode iz klase A 

redefinirani u klasi B i/ili C, tada postoje dva slučaja – da je kod nadjačavanja u klasama B/C zadržano 

isto ime atributa/metode kao u klasi A, ili da je ime promijenjeno. Prvi slučaj (ista imena) se najčešće 

svodi na drugi, preimenovanjem jednog atributa/metode (a rjeđe se koristi "eliminacija" jednog 

atributa/metode, pomoću undefine). U drugom slučaju (različita imena) Eiffel traži da se eksplicitno 

izabere (pomoću select) željeni atribut/metoda, što je potrebno da bi se razriješila dilema izbora prave 

metode kod dinamičkog pozivanja metoda (zbog polimorfičnog pridruživanja). 

Eiffel šalje parametre referentnog tipa kao reference, a expanded parametre šalje kao vrijednosti. 

Bez obzira kako se parametri šalju, Eiffel ne dozvoljava da se oni u metodi mijenjaju, niti pomoću naredbe 

pridruživanja "parametar := nesto", niti pomoću naredbe kreiranja objekta "create parametar;". Ali, iako 

Eiffel metoda ne može mijenjati objekt predstavljen parametrom, može mijenjati njegove atribute (bilo 

direktno, bilo pozivom drugih metoda). Zanimljivo je pitanje promjene signature, tj. pitanje da li parametri 

u nadjačanoj metodi mogu imati drugačiji tip od parametara u metodi iz nadklase i (ako mogu) kakav 

mora biti taj tip. Postoje tri (glavne) mogućnosti: 

1. tip parametra se ne može mijenjati - no variance; 

2. može se mijenjati tako da bude podtip u odnosu na bazni – covariance; 

3. može se mijenjati tako da bude nadtip - contravariance. 

Eiffel podržava covariance i za parametre metoda i za povratnu (return) vrijednost funkcije i za 

atribute. Npr. Java je do verzije 1.4 imala u potpunosti no variance pristup, ali od verzije 1.5 (ili 5.0) 

podržava covariance za povratne vrijednosti funkcije (i PL/SQL se ponaša kao Java 1.5). 

Eiffel je imao generičke klase od početka, dok ih Java dobila u verziji 1.5. Možemo reći da generičke 

klase zapravo nisu prave klase, nego predlošci za klase, jer imaju tzv. generičke parametre. Npr. u Eiffelu 

ovako izgleda generička klasa STACK [G] (generički parametar nazvan je G, a može se zvati i drugačije): 

class STACK [G] 

feature 

element_na_vrhu: G is 

do ... end 

... 

end 

58

Generička klasa se koristi kao klijent neke (druge) klase, u kojoj se (drugoj klasi) atribut, varijabla ili 

parametar deklarira pomoću generičke klase, tako da se generički parametar zamijeni sa nekom (trećom) 

klasom. Npr. klasa STACK_KLIJENT može sadržavati dva atributa definirana na sljedeći način (generički 

parametar G zamijenjen je klasom ZIVOTINJA, odnosno klasom REAL): 

atribut1: STACK [ZIVOTINJA] 

atribut2: STACK [REAL] 

Eiffel ima (kao i Java) i tzv. ograničenu generičnost (constrained genericity), gdje se generički 

parametar ograničava nekom određenom klasom, pomoću operatora ->. U slučaju ograničene 

generičnosti, klasa koja zamjenjuje generički parametar mora biti ili ista kao klasa koja ograničava 

generički parametar, ili podklasa te klase. Npr. ako bismo ovako definirali (ograničenu) generičku klasu 

STACK: 

class STACK [G -> ZIVOTINJA] ... end 

tada bismo imali sljedeće: 

atribut1: STACK [BAKTERIJA] -- greška, nije podklasa od ZIVOTINJA 

atribut2: STACK [ZIVOTINJA] -- OK, može biti ista klasa 

atribut3: STACK [KUCNI_LJUBIMAC] -- OK, to je podklasa od ZIVOTINJA 

Design By Contract (DBC) je metoda čiji je autor također Meyer. Stoga nije čudno da Eiffel u 

potpunosti podržava DBC. Za sada niti jedan drugi OOPL ne podržava DBC u potpunosti, barem ne na 

razini jezika. DBC je opširno opisan u [12]. Pojednostavljeno rečeno, DBC se zasniva na ideji da svaka 

metoda (procedura ili funkcija), uz "standardni" programski kod, treba imati još dva dodatna dijela - 

pretkondiciju (precondition) i postkondiciju (postcondition). Klasa treba imati još jedan dodatni dio - 

invarijantu (invariant). Ugovor (contract) se zasniva na tome da metoda "traži" od svog pozivatelja (neke 

druge metode) da zadovolji uvjete definirane u pretkondiciji (plus uvjete definirane u invarijanti), a ona 

(pozvana metoda) se tada "obvezuje" da će na kraju zadovoljiti uvjete definirane u postkondiciji (plus 

uvjete definirane u invarijanti). Ideja je na neki način upravo suprotna od tzv. defanzivnog programiranja, 

koje zagovora da se u svim mogućim trenucima pokušava što više toga provjeriti. 

Eiffel za specifikaciju DBC elemenata koristi ključne riječi require (odnosno require else u 

nadjačanoj metodi, kod nasljeđivanja) za označavanje pretkondicije, ensure (odnosno ensure then u 

nadjačanoj metodi) za postkondicije i invariant za invarijante klasa. Navedene naredbe su najvažnije za 

DBC podršku, ali Eiffel ih ima još. Naredba check služi za provjeru nekog uvjeta u bilo kom trenutku. Za 

provjeru programskih petlji postoje dvije naredbe: variant provjerava da li se cjelobrojni izraz smanjuje 

kod svakog prolaza u petlji, a invariant (opet ista riječ kao za označavanje invarijante klase, ali je u 

kontekstu petlje značenje drugačije) provjerava da li je određeni uvjet u petlji zadovoljen u svakom 

prolazu. 

U Eiffelu metoda ne može obraditi iznimku koja se desila zbog nezadovoljavanja pretkondicije – 

jednostavno, pozvana metoda nema što raditi ako se druga metoda (pozivatelj) ne drži ugovora! Dakle, 

za pojavu iznimke u vrijeme izvršavanja programskog koda pretkondicije "krivac" je metoda-pozivatelj, 

dok je za pojavu iznimke u vrijeme izvršavanja programskog koda postkondicije "krivac" metodaizvršavatelj. 

Nadjačane metode ne mogu imati bilo kakve pretkondicije ili postkondicije, već nadjačana metoda 

mora imati jednaku ili slabiju pretkondiciju (tj. može zahtijevati od metode koja ju je pozvala ili isto što i 

metoda nadklase, ili manje od toga) i mora imati jednaku ili jaču postkondiciju (tj. mora osigurati barem 

ono što je osiguravala metoda nadklase, ili više od toga). Zato se za definiranje pretkondicije u 

nadjačanoj metodi koristi oblik require else (umjesto require), a za definiranje postkondicije u 

nadjačanoj metodi koristi se ensure then. 

Može se postaviti pitanje utjecaja izvršenja pretkondicija, postkondicija i invarijanti na brzinu 

izvođenja programa. Nažalost, utjecaj postoji, a naročito je skupa provjera invarijanti. Stoga se u Eiffel-u 

može odrediti nekoliko stupnjeva provjere. Najslabija provjera (ali sa najmanjim negativnim utjecajem na 

brzinu izvođenja) je provjera samo pretkondicija (ta se provjera obično ostavlja i nakon završetka faze 

testiranja, tj. ostaje u produkcijskom kodu). Sljedeći stupanj uključuje provjeru postkondicija, slijedi 

provjera invarijanti, zatim provjera petlji i na kraju provjera pomoću check naredbi. Najveći stupanj 

provjere se obično koristi samo kod testiranja, jer se takvi programi izvršavaju i do 2-3 puta sporije u 

odnosu na programe koji nemaju nikakvih provjera. 

Treba naglasiti da su pretkondicije, postkondicije i invarijante korisne čak i kada nisu realizirane kao 

programski kod, nego samo kao komentar (najčešće zato što je nešto teško ili nemoguće izraziti – Eiffel 

nema operatore univerzalnog i egzistencijalnog kvantifikatora iz predikatnog računa), jer poboljšavaju 

dokumentiranost izvornog koda. Zbog DBC podrške, može se reći da je Eiffel i specifikacijski (a ne samo 

programski) jezik. 

59

Slijedi Eiffel programski kod za realizaciju stoga (OOSC2 str. 390.-391.). Zapravo, to nije kompletan 

programski kod, već samo tzv. kratki oblik klase, koji ne prikazuje izvršni kod metoda (zato to nije class, 

već class interface). Kratki oblik klase ne prikazuje niti skrivene implementacijske detalje, tako da ne 

vidimo da klasa ima jedan skriveni atribut tipa niz (implement: ARRAY [G]) koji služi za implementaciju 

stoga: 

class interface STACK [G] 

creation make 

feature – inicijalizacija 

-- stog od n elemenata 

make (n: INTEGER) is 

require non_negative_capacity: n >= 0 

ensure capacity_set: capacity = n 

end 

feature -- pristup 

-- maksimalni broj elemenata 

capacity: INTEGER 

-- broj elemenata stoga 

el_count: INTEGER 

-- element na vrhu stoga 

item: G is 

require not_empty: not empty 

end 

feature – statusi 

-- da li je stog prazan? 

empty: BOOLEAN is 

ensure empty_definition: Result = (el_count = 0) 

end 

-- da li je stog pun? 

full: BOOLEAN is 

ensure full_definition: Result = (el_count = capacity) 

end 

feature – promjena 

–- dodaj x na vrh stoga 

put (x: G) is 

require not_full: not full 

ensure not_empty: not empty 

added_to_top: item = x 

one_more_item: el_count = old el_count + 1 

end 

-– makni element sa vrha 

remove is 

require not_empty: not empty 

ensure not_full: not full 

one_fewer: el_count = old el_count - 1 

end 

invariant 

count_non_negative: 0

8. KONKURENTNO PROGRAMIRANJE U EIFFELU – SCOOP METODA 

Metoda SCOOP (Simple Concurrent Object-Oriented Programming) ima prilično davne korijene. 

Njen kreator, Bertrand Meyer (koji je i kreator jezika Eiffel), prikazao je osnovne ideje te metode još 1990. 

godine na TOOLS Europe, a preradio ih je 1993. Detaljan prikaz dao je 1997. u [12]. Kasnije je SCOOP 

metoda eksperimentalno realizirana i poboljšavana na ETH Zurich, te se koristi naročito za nastavne i 

znanstvene potrebe. Formalni prikaz te metode zaokružio je 2007. godine P. Nienaltowski u doktorskoj 

disertaciji kod prof. Meyera. Nedavno je (lipanj 2011.) firma Eiffel Software (www.eiffel.com) uključila 

SCOOP metodu u svoj proizvod EiffelStudio v.6.8. Moglo bi se reći da je SCOOP zaseban (mini) jezik za 

konkurentno programiranje, jer eksperimentalne implementacije postoje i izvan jezika Eiffel, npr. postoje i 

za jezik Java. SCOOP se i dalje razvija, npr. rade se istraživanja na sljedećim područjima: 

- prevencija i detekcija deadlocka; 

- uvođenje softverske transakcijske memorije; 

- distribuirani SCOOP. 

Kod SCOOP metode vrlo je važan pojam procesor, ali se pod tim pojmom ne misli na fizički 

procesor, već na apstraktni procesor, koji može biti i fizički procesor (u nastavku će se za njega koristiti 

termin CPU), proces operacijskog sustava, dretva operacijskog sustava i sl. Da se smanji zabuna, u 

nastavku će se koristiti oblik (apstraktni) procesor (a ne samo procesor, kao što se koristi u [12], [13] i 

[14]). Za razliku od CPU-a, čiji je broj ograničen, možemo držati da je broj (apstraktnih) procesora 

praktički neograničen. Kako se navodi u [12], (apstraktni) procesor je jedna od tri sile računanja kod 

OOPL programiranja: neka akcija (ili metoda, tj. funkcija ili procedura) izvodi se na određenom 

(apstraktnom) procesoru nad određenim objektom (instancom klase), kako prikazuje slika 8.1: 

Slika 8.1: Tri sile kod računanja (The three forces of computation); Izvor: [12] 

Temeljna ideja vezana za (apstraktne) procesore u SCOOP metodi je: svaki objekt je dodijeljen 

samo jednom (apstraktnom) procesoru, koji se naziva rukovatelj (handler) objektom. S druge strane, 

jedan (apstraktni) procesor može biti rukovatelj za više objekata. Kad se kreira novi objekt, runtime sistem 

(na temelju programskih uputa) odlučuje da li će mu se dodijeliti neki rukovatelj od postojećih, ili će se 

kreirati novi (apstraktni) procesor kao rukovatelj za novokreirani objekt. Ta veza ostaje do kraja - objekt je 

uvijek vezan za samo jednog rukovatelja, a to u konačnici znači da se nad istim objektom istovremeno 

može izvoditi samo jedna metoda, jer metode određenog objekta može izvoditi samo rukovatelj tog 

objekta. 

Kada se u nekoj metodi, koja se izvodi nad nekim objektom, poziva metoda nad objektom kojim 

rukuje drugi rukovatelj (tj. koji nije isti kao rukovatelj prvog objekta), taj se poziv zove asinkroni poziv ili 

odvojeni (separate) poziv. U tom slučaju rukovatelj prvog objekta može nastaviti rad, ne čekajući da 

pozvana metoda završi. Za razliku od toga, poziv metode nad drugim objektom koji ima istog rukovatelja 

kao i prvi objekt, je sinkroni poziv ili neodvojeni poziv – to je standardna situacija iz sekvencijalnog 

programiranja, gdje rukovatelj mora čekati da jedna metoda završi prije nego nastavi izvršavati drugu 

(naravno, zanemarujemo fizičke detalje CPU-a, mogućnost instrukcijskog paralelizma i sl.). 

Ostalo je otvoreno pitanje na koji način runtime sistem određuje kojeg će rukovatelja dodijeliti 

objektu. U odnosu na nekonkurentni Eiffel, SCOOP metoda uvodi samo još jednu ključnu riječ - separate. 

Uz uobičajenu deklaraciju varijable (napomena: Eiffel izvorno koristi termin entitet za atribute, lokalne 

varijable i argumente metoda) 

x : X 

koja označava da je varijabla x referenca na objekt tipa (tj. klase) X, sada se može pisati i 

x : separate X 

čime se izražava da kod izvođenja programa x može biti referenca na objekt koji ima drugog 

rukovatelja u odnosu na objekt u kojem se ta referenca nalazi. Takva se referenca zove odvojena 

referenca, a objekt na koji pokazuje zove se odvojeni objekt. 

61

Slika 8.2 prikazuje tri objekta: x, y i z. Objektu x je rukovatelj (apstraktni) procesor p, a objektima y i 

z rukovatelj je (apstraktni) procesor q. Objekt x ima atribut y, koji predstavlja udaljenu referencu, jer ta 

referenca pokazuje na objekt y, koji ima drugog rukovatelja. Za razliku od toga, objekt y ima atribut z koji 

je ne-odvojena referenca na ne-odvojeni objekt z, jer objekti y i z imaju istog rukovatelja. 

Slika 8.2: Odvojena referenca: u objektu x, atribut y referencira objekt 

na drugom (apstraktnom) procesoru; Izvor: [14] 

Primjer [12] pojasnit će do sada navedeno. Prtpostavimo da u klasi WORKER, metoda task nešto 

radi i stavlja rezultat u atribut output: 

class WORKER 

feature 

output: INTEGER 

do_task (input: INTEGER) do ... end 

end 

Klasa MANAGER ima dva atributa - reference tipa WORKER, ali jedna referenca je odvojena, a 

druga je ne-odvojena. U nekoj metodi te klase pozivaju se metode task nad odvojenim objektom worker1 

i nad ne-odvojenim objektom worker2, a onda se rezultati izvođenja zbrajaju: 

class MANAGER 

feature 

worker1 : separate WORKER 

worker2 : WORKER 

-- in some routine: 

do 

. . . 

worker1.do_task (input1) 

worker2.do_task (input2) 

result := worker1.output + worker2.output 

end 

end 

Zbivanja kod izvođenja ovog programskog koda mogu se ovako opisati: procedura task nad 

odvojenim objektom worker1 poziva se asinkrono, tj. program ne čeka da ona završi, već odmah prelazi 

na sljedeću proceduru task nad objektom worker2, koju izvodi sinkrono. Kada je ta druga procedura 

gotova, izvršava se sljedeća naredba, koja zbraja dva rezultata. Tek u ovom trenutku mora se čekati da 

procedura task nad objektom worker1 završi, jer je sada potreban rezultat te procedure. To se čekanje 

obavlja automatski od strane SCOOP mehanizma, i zove se wait-by-necessity (čekanje po potrebi). U 

ovom primjeru je rad sa odvojenim objektima bio lagan, jer je sistem sam znao da li je poziv sinkron ili 

asinkron i kada treba čekati na rezultat. 

62

U nastavku će biti prikazano kako se u SCOOP-u radi međusobno isključivanje (mutual exclusion) u 

slučajevima kada se odvojeni objekti međusobno upliću jedan drugome u rad, tj. kod tzv. race condition. 

Primjer rada sa brojačima je ekvivalentan Java primjeru iz 5. točke (oboje je iz [12]): 

class COUNTER 

feature 

value : INTEGER 

set_value (a_value: INTEGER) 

do 

value := a_value 

end 

increment 

do 

value := value + 1 

end 

end 

Pretpostavimo da postoji varijabla x deklarirana kao separate COUNTER i pratimo sljedeći niz 

naredbi: 

x.set value (0) 

x.increment 

i := x.value 

Istovremeno se u nekom odvojenom (apstraktnom) procesoru odvija naredba: 

x.set value (2) 

Kao i u ekvivalentnom Java primjeru u 5. točki, zbog mogućeg ispreplitanja ovih naredbi u 

paralelnom radu, vrijednost varijable i iz prvog koda može biti 1, 2 ili 3. U Javi se to moglo spriječiti 

sinkronizacijom pomoću (npr.) synchronized. U Eiffelu se koristi jednostavno pravilo, koje se zove pravilo 

odvojenih argumenata (separate argument rule): runtime sistem automatski zaključava (apstraktne) 

procesore koji rukuju odvojenim objektima koji su (objekti) poslani kao argumenti metode. Ako je 

(apstraktni) procesor zaključan, ne može ga se koristiti, pa se ne može pozvati niti jedna metoda nad 

objektom kojemu je rukovatelj zaključani (apstraktni) procesor. Izmijenimo prethodni kod (tri instrukcije) 

na sljedeći način, tako da ih stavimo u proceduru koja će imati odvojeni objekt kao argument: 

compute (x: separate COUNTER) 

do 

x.set_value (0) 

x.increment 

i := x.value 

end 

Pogledajmo sada poziv compute (x) i pretpostavimo da je (apstraktni) procesor p rukovatelj za x. 

Kako je prije rečeno, budući da je x odvojeni argument te procedure, procesor p mora biti zaključan. 

Tekući procesor, koji izvodi proceduru compute, automatski čeka dok runtime sistem ne zaključa 

procesor p. Kada je p zaključan, tijelo procedure compute može se izvršavati bez problema (ne postoje 

višestruki lokoti na jedan procesor), pa će varijabla i na kraju procedure uvijek ima vrijednost 1. SCOOP 

forsira takvo ponašanje, tj. svi pozivi nad odvojenim objektima moraju se uokviriti u procedure kojima se 

odvojeni objekt šalje kao argument. 

Npr. ovo je neispravno (kompajler javlja grešku): 


compute 

do x.f end 

a ovo je ispravno: 


compute (x1: separate X) 

do x1.f end 

63

Prikažimo sada u SCOOP-u sinkronizaciju na temelju uvjeta (condition synchronization), koja se u 

Javi implementirala npr. pomoću naredbi wait / notifyAll / notify, na istom primjeru proizvođača i potrošača 

kao u 5. točki. Pretpostavimo da imamo generičku klasu BUFFER[T] koja implementira neograničeni red 

(unbounded queue): 

buffer: separate BUFFER[INTEGER] 

i sljedeću proceduru u klasi potrošača: 

consume (a_buffer: separate BUFFER[INTEGER]) 

require 

not (a_buffer.count = 0) 

local 

value: INTEGER 

do 

value := a_buffer.get 

end 

Primijetimo da smo koristili pretkondiciju kako bismo osigurali da buffer nije prazan kada iz njega 

čitamo. Pitanje je što će se desiti ako je buffer prazan? U sekvencijalnom slučaju desila bi se iznimka 

(exception). Međutim, u konkurentnom radu pretkondicije na odvojene objekte imaju drugu semantiku - 

rukovatelj odvojenog objekta se otključa, čeka se dok se ne zadovolji zahtjev, a onda se rukovatelj 

odvojenog objekta opet zaključa. Pretkondicija se u konkurentnom radu pretvara u uvjet za čekanje (wait 

condition). To se ponašanje može iskazati kao pravilo čekanja (wait rule): "Poziv metode koja ima 

odvojene argumente izvršit će se onda kada su svi odgovarajući rukovatelji slobodni (nisu zaključani) i 

kada su zadovoljene sve pretkondicije. Rukovatelji su ekskluzivno zaključani za vrijeme trajanja metode." 

Kao i u Javi, tako se i u SCOOP metodi može desiti deadlock. Primjer [12]: 

class C 

creation 

make 

end 

feature 

a : separate A 

b : separate A 

make (x : separate A, y : separate A) 

do 

a := x 

b := y 

end 

f do g (a) end 

g (x : separate A) do h (b) end 

h (y : separate A) do ... end 

Pretpostavimo sada da se izvršava sljedeći kod, gdje su objekti c1 i c2 tipa separate C, objekti a i b 

su tipa separate A, objekt a ima rukovatelja p, objekt b ima rukovatelja q: 

create c1.make (a, b) 

create c2.make (b, a) 

c1.f 

c2.f 

Budući da su kod inicijalizacija objekata c1 i c2 argumenti permutirani, moguća je sekvenca poziva 

kod koje je u jednom slučaju zaključan rukovatelj p, a čeka se da se oslobodi rukovatelj q, i obrnuto. 

Nastao je deadlock. 

Deadlock se trenutačno ne može automatski detektirati u SCOOP-u, pa je programerova 

odgovornost da radi programski kod slobodan od deadlocka (deadlock-free). No, kako se navodi u [12], 

radi se na implementaciji sheme koja prevenira deadlock, a ona je temeljena na redoslijedu zaključavanja 

koji prevenira cikličko zaključavanje (cyclical locking). 

64

ZAKLJUČAK 

Iako i dalje vrijedi Mooreov zakon (naravno, to nije zakon niti u matematičkom, niti u fizikalnom 

smislu, to je statistička prognoza), koji tvrdi da se broj tranzistora na mikroprocesorskom čipu 

udvostručuje otprilike svake dvije godine, danas se kaže: "vrijeme jednostavnog povećanja brzine 

programa je prošlo". 

Radni takt procesora praktički je prestao rasti oko 2005. godine. Razlog za to je prije svega veliko 

povećanje potrošnje struje procesora na velikim brzinama. Zbog toga su se proizvođači okrenuli 

drugačijem načinu povećanja performansi procesora. Umjesto povećanja brzine, povećali su broj CPU-a 

na jednom mikroprocesorskom čipu, tj. počeli su proizvoditi višejezgrene procesore. No, dok smo kod 

jednojezgrenih procesora povećanjem takta procesora dobili linearno povećanje brzine programa, kod 

višejezgrenih procesora program najčešće moramo pisati drugačije da bismo iskoristili raspoložive jezgre, 

tj. moramo preći na konkurentno programiranje. 

Vrlo je važno postići visoku paralelnost programa, a razlog za to objašnjava tzv. Amdahlov zakon. 

Npr. ako imamo 10 procesora i ako je moguće paralelizirati 90% programa, onda je maksimalno 

povećanje brzine 5,26 puta, što je skoro dva puta manje od broja procesora. Ako je moguće paralelizirati 

99% programa, onda je povećanje 9,17 puta. 

Nažalost, konkurentne programe nije lako pisati. Kako je naglasio autor u [6] (na kraju poglavlja o 

konkurentnosti): "Nakon rada kroz ovo poglavlje, možete primijetiti da rad sa dretvama u Javi izgleda vrlo 

kompleksno i teško za korektnu upotrebu. Dodatno, izgleda malo neproduktivno - iako dretve rade 

paralelno, morate investirati veliki trud da implementirate tehnike koje ih sprečavaju da na loš način utječu 

jedna na drugu. Ako ste ikada pisali programe u zbirnom jeziku (assembleru), kad pišete programe sa 

dretvama, imate sličan osjećaj: svaki mali detalj je važan, i nemate sigurnosnu mrežu u obliku provjere od 

strane kompajlera." 

Nije lako pisati tzv. blokirajuće algoritme, koji koriste različite vrste lokota za (blokirajuću) 

sinkronizaciju. Svi se ti lokoti danas uglavnom zasnivaju na mikroprocesorskoj funkciji (operaciji) 

Compare And Swap (CAS), ili njoj ekivalentnoj. No, CAS (i CASD, Compare-and-Swap-Double) nisu 

novost - bile su dio IBM 370 arhitekture od 1970. godine, iako je tek 1991. matematički dokazano da 

"registri koji koriste compareAndSet() i get() operacije imaju beskonačni broj konsenzusa", što bi vrlo 

pojednostavljeno (do banalizacije) značilo da je CAS operacija "jako dobra za konkurentno 

programiranje". No, korištenje lokota (tj. zaključavanje), bez obzira što se za implementaciju lokota koristi 

operacija CAS, ima dosta mana. Najveću manu zaključavanja autori u [8] vide u tome što "nitko stvarno 

ne zna kako organizirati i održavati veliki sustav temeljen na zaključavanju". 

Još je teže pisati neblokirajuće konkurentne algoritme, koji ne koriste zaključavanje. I oni se interno 

temelje (uglavnom) na CAS operaciji, Dakle, CAS operacija je vrlo važna za sadašnjost i budućnost 

konkurentnog programiranja. No CAS operacija ima i mane: neblokirajuće algoritme koji koriste CAS (ili 

ekvivalentne operacije) vrlo je teško smisliti i često su vrlo neintuitivni. Zapravo, osnovna teškoća sa svim 

današnjim sinkronizacijskim operacijama (pa i CAS) je da one rade na samo jednoj riječi memorije, što 

tjera na korištenje kompleksnih i neprirodnih algoritama. Problem sa većinom dosadašnjim 

sinkronizacijskih mehanizama i operacija, bez obzira da li rade ili ne rade zaključavanje, je da se ne mogu 

lagano komponirati, što ima veliki negativan utjecaj na modularnost konkurentnih programa. 

Zato je izmišljena transakcijska memorija (TM), a njena realizacija može biti softverska (STM), 

hardverska (HTM) ili hibridna. Transakcija je sekvenca koraka koje izvršava jedna dretva. Transakcije 

moraju biti serijabilne (serializable), što znači da mora izgledati kao da se izvršavaju sekvencijalno (jedna 

iza druge) i onda kada se izvršavaju paralelno. Ispravno implementirane, transakcije nemaju problem 

deadlocka ili livelocka, ali najvažnije je da je pomoću njih lakše pisati konkurentne programe. Postoje 

različite softverske implementacije transakcijske memorije. Npr. programski jezik Clojure podržava STM 

na razini jezika, a neki jezici podržavaju STM na razini biblioteka. 

Što se tiče HTM-a, danas postoje barem dva mikroprocesora koja podržavaju HTM - Vega procesor 

firme Azul Systems (već 5-6 godina), a nedavno (kolovoz 2011.) mu se pridružio i BlueGene/Q firme IBM. 

Temeljna ideja za podršku HTM-a je u tome da današnji mikroprocesori podržavaju protokole 

usklađivanja priručne memorije (cache-coherence protocols), pa time već podržavaju većinu toga što je 

potrebno za realizaciju HTM-a. 

Postoje i neka softverska rješenja konkurentnog programiranja koja (za sada) ne koriste STM, ali 

izgledaju naprednija nego npr. rješenja u Javi. Jedno takvo rješenje je Simple Concurrent Object Oriented 

Programming (SCOOP), model koji je realiziran u OOPL jeziku Eiffel (iako postoje eksperimentalne 

realizacije i u drugim jezicima, pa i u Javi). Suština te metode je da objektima ekskluzivno rukuju njihovi 

rukovatelji - apstraktni procesi, i ne zaključavaju se objekti, već procesi. Uobičajena semantika Eiffel 

pretkondicije se u SCOOP-u mijenja – neuspjeh zadovoljenja pretkondicije ne uzrokuje exception, već 

čekanje na zadovoljavanje uvjeta. Vrijeme će pokazati da li je taj model uspješan. 

65

LITERATURA 

1. Bloch, J. (2008): Effective Java (2.izdanje), Addison-Wesley / Sun Microsystems 

2. Budin, L., Golub, M., Jakobović, D., Jelenković, L. (2010): Operacijski sustavi, Element, Zagreb 

3. Cliff C. (2010): Azul's Experiences with Hardware / Software Co-Design (prezentacija), 

Azul Systems, blogs.azulsystems.com/cliff (kolovoz 2011.) 

4. Cliff C., Göetz B. (2009): Not Your Father's Von Neumann Machine - 

A Crash Course in Modern Hardware (prezentacija), JavaOne 2009, 

http://www.azulsystems.com/events/javaone_2009/session/2009_J1_HardwareCrashCourse.pdf 

(kolovoz 2011.) 

5. Drepper U. (2007): What Every Programmer Should Know About Memory (white paper), 

Red Hat Inc., http://www.akkadia.org/drepper/cpumemory.pdf (kolovoz 2011.) 

6. Eckel B. (2006): Thinking in Java (4.izdanje), Prentice Hall 

7. Hennessy, J.L., Patterson D.A. (2007): Computer Architecture - A Quantitative Approach 

(4.izdanje), Elsevier / Morgan Kaufmann Publishers 

8. Herlihy, M., Shavit, N. (2008): The Art of Multiprocessor Programming, 

Elsevier / Morgan Kaufmann Publishers 

9. Horstmann, C.S., Cornell, G. (2008): Core Java: Volume 1 - Fundamentals (8.izdanje), 

Prentice Hall / Sun Microsystems 

10. Göetz B. i ostali (2006): Java Concurrency in Practice, Addison-Wesley 

11. Lea D. (1999): Concurrent Programming in Java - Design Principles and Patterns (2.izdanje), 

Addison-Wesley 

12. Meyer, B. (1997): Object-Oriented Software Construction, Prentice Hall 

13. Meyer, B., Nanz S. (2010): Concepts of Concurrent Computation (materijali sa kolegija), 

ETH Zuerich - Chair of Software Engineering, 

http://se.inf.ethz.ch/old/teaching/2010-S/0268/index.html#lectures_slides (kolovoz 2011.) 

14. Nanz S. i dr. (2010): A Comparative Study of the Usability of Two Object-oriented 

Concurrent Programming Languages, ETH Zuerich & University of Toronto, 

http://se.inf.ethz.ch/people/nanz/publications/nanz-et-al_arxiv1011.6047.pdf (kolovoz 2011.) 

15. Reinhold M. (2011): Divide and Conquer Parallelism with the Fork/Join Framework (prezentacija), 

Oracle Java Platform Group, 

http://www.oracle.com/us/technologies/java/fork-join-framework-428206.pdf www (kolovoz 2011.) 

Oracle priručnici za bazu 11g Release 2 (2009): 

16. Oracle Database Concepts 

17. Oracle Database PL/SQL Packages and Types Reference 

66

Alen Prodan 

Login d.o.o. 

Mihačeva draga b.b. 

51000 Rijeka 

+385 91 156 44 68 

alen.prodan@login.hr 

http://www.login.hr 

KORIŠTENJE HISTOGRAMA U OPTIMIZACIJI SQL NAREDBI 

OPTIMIZING SQL STATEMENTS WITH HISTOGRAMS 

SAŽETAK 

Histogrami nadopunjuju raspoložive statistike o tablicama omogućujući detaljniji uvid u distribuciju 

vrijednosti podataka pohranjenih u stupcima tablice. Općeniti stav i preporuka je da se histogrami 

koriste u slučajevima izrazito neravnomjerne distribucije vrijednosti unutar kolona tablice, što 

predstavlja prevladavajući, ali ne i jedini mogući scenarij praktičnog korištenja histograma. Kroz rad 

čitatelj upoznaje što su histogrami i kako se generiraju različite vrste histograma,te načine njihove 

aplikacije u rješavanju različitih tipova problema optimizacije SQL naredbi. 

ABSTRACT 

Histograms complement the available table statistics, providing detailed insight into the 

distribution of column data.The prevalent and most basic histogram use case scenario is with 

nonuniform data distributions.Histograms provide improved selectivity estimates in the presence of 

data skew, but besides that, there are more problem types histograms can solve. This paper provides 

an overview of histograms, how to build them and how Oracle use them to solve different problem 

types. 

UVOD 

U odsutnosti histograma, CBO ne raspolaže sa informacijom o raspodijeli vrijednosti unutar 

kolona pojedine tablice. U takvim okolnostima CBO pretpostavlja ravnomjernu raspodijelu, što znači 

da se svaka pojedina vrijednost (distinct value) pojavljuje jednak broj puta. Kod ravnomjerne 

raspodijele, CBO izračunava selektivnost filtera „where kolona = konstanta“ kao 1/num_distinct, a 

kardinalnost skupa se izračunava kao num_rows/num_distinct. Preciznost kod izračuna selektivnosti i 

kardinalnosti izrazito je bitna ne samo za odabir načina pristupa podacima (table/index access path), 

već i za određivanje join mehanizma i redoslijeda kojim tablice ulaze u join. 

1. VRSTE HISTOGRAMA 

Oracle koristi histograme za preciznije izračunavanje selektivnosti i kardinalnosti kod 

neravnomjernih distribucija vrijednosti unutar stupaca tablice pri čemu se koriste dva tipa histograma. 

Frequency histogram koristi se za skupove koji imaju = num_distinct, a num_distinct

stupac N1, nad kojim je generiran FH histogram. Stupac T1.N1 sadrži retke sa sljedećom 

raspodijelom vrijednosti. 

Primjer 1. Frequency histogram nad stupcem sa 3 različite (distinct) vrijednosti 

VRIJEDNOST ENDPOINT_VALUE ENDPOINT_NUMBER 

RAZLIKA 

2 2 3 (3-0) = 3 

4 4 4 (4-3) = 1 

8 8 7 (7-4) = 3 

Frequency histogram možemo grafički prikazati na sljedeći način: 

Stupci ENDPOINT_VALUE i ENDPOINT_NUMBER predstavljaju vrijednosti iz 

USER_TAB_HISTOGRAMS viewa. Stupac RAZLIKA predstavlja frekvenciju pojavnosti svake 

pojedine (distinct) vrijednosti (2,4,8) unutar stupca T1.N1. Za uočiti je da se u data dictionary ne 

pohranjuje frekvencija za pojedinu vrijednost u obliku [vrijednost, frekvencija], već kumulativni zbroj 

(running total). U našem primjeru, postoji (3-0) = 3 retka koja imaju vrijednost 2, zatim (4-3) = 1 redak 

za vijednost 4, te (7-4) = 3 retka za vrijednost 8, a kumulativno gledano, u tablici postoji 7 redaka za 

koje je T1.N1

Primjer 2. Height balanced histogram bez popularnih vrijednosti 

ENDPOINT_VALUE 1 3 6 9 

VRIJEDNOST 1 2 3 4 5 6 7 8 9 

ENDPOINT_NUMBER 0 1 2 3 

RAZLIKA (1–0) = 1 (2-1) = 1 (3-2) = 1 

Redak VRIJEDNOST sadrži vrijednosti iz tablice, odnosno vrijednosti za koje se generira 

histogram. ENDPOINT_VALUE i ENDPOINT_NUMBER prikazuju vrijednosti iz 

USER_TAB_HISTOGRAMS viewa. ENDPOINT_VALUE predstavlja vrijednost u tablici koja se nalazi 

na fizičkoj poziciji koja je uzorkovana, dok ENDPOINT_NUMBER predstavlja broj intervala (bucketa). 

HB histogramom se retci u pojedinom stupcu mapiraju u mrežu koja se sastoji od N intervala. U 

konkretnom slučaju, budući da tablica sadrži 9 redaka, te da je generiran histogram sa 3 intervala 

(N=3), svaki od intervala pokriva broj_redaka / N = 3 retka. Granice intervala označene su 

podebljanim okomitim linijama, a uzorkovane vrijednosti nalaze se u zasjenjenim stupcima. Redak 

RAZLIKA pokazuje da li se neka od vrijednosti (ENDPOINT_VALUE) pojavljuje uzastopno u više od 

jednog intervala (RAZLIKA > 1), što bi značilo da se radi o popularnoj vrijednosti. 

Na sljedećem primjeru prikazan je slučaj kada se ista vrijednost (ENDPOINT_VALUE) pojavljuje 

unutar dva uzastopna uzorkovana intervala. 

Primjer 3. Height balanced histogram sa popularnom vrijednosti 

ENDPOINT_VALUE 1 3 9 9 

VRIJEDNOST 1 2 3 4 9 9 9 9 9 

ENDPOINT_NUMBER 0 1 2 3 

RAZLIKA (1-0) = 1 (3-1) = 2 

Vrijednost 9 uzorkovana je dva puta i to na fizičkim pozicijama 6. i 9. retka. Ipak, u HB histogramu 

postoji samo jedan redak za kojega je ENDPOINT_VALUE=9, ali je pripadajući ENDPOINT_NUMBER 

povećan, te sada iznosi 2. To je rezultat kompresije koju prilikom kreiranja histograma provodi Oracle. 

Kompresija omogućuje da se sa manje fizičkih zapisa (redaka koji čine histogram) opišu vrijednosti u 

stupcu tablice. U konkretnom primjeru, jače zatamnjeni stupac na fizičkoj poziciji 6. retka iako 

uzorkovan u fazi generiranja histograma, fizički nije direktno zapisan u samu strukturu histograma 

zbog prije spomenute kompresije. Vrijednosti koje se u uzorkovanju pojavljuju više od jednom, imaju 

vrlo značajnu ulogu, a nazivamo ih popularnim vrijednostima. 

1.2.1. Popularnost i uloga New Density formule 

Kod HB histograma, popularne su vrijednosti one za koje vrijedi da je (ENDPOINT_NUMBER(n) – 

ENDPOINT_NUMBER(n-1)) > 1. Popularne vrijednosti imaju značajne statističke razlike u odnosu na 

nepopularne vrijednosti, a to su one vrijednosti za koje vrijedi da je (ENDPOINT_NUMBER(n) – 

ENDPOINT_NUMBER(n-1)) = 1. Za popularne vrijednosti frekvencija pojavnosti se prilično precizno 

može utvrditi na temelju broja intervala (buckets) u kojima je vrijednost uzorkovana, te na temelju 

podatka o broju redaka koje svaki interval sadrži. Za nepopularne vrijednosti to nije moguće. Na 

sljedećem grafikonu prikazan je skup od 9 redaka, nad kojima je kreiran HB histogram sa 3 intervala 

(bucketa). Na prikazu su zatamnjene pozicije na kojima se pojavljuje ista vrijednost, a razrađeno je 6 

mogućih scenarija koji ukazuju na problem određivanja frekvencije pojavnosti nepopularnih vrijednosti. 

Frekvencija pojavnosti nepopularnih vrijednosti se može kretati u intervalu od 1 do 2 * N -1, a bez da 

se takva vrijednost detektira kao popularna vrijednost u histogramu. 

Scenario 

1 

2 

3 

4 

5 

6 

Intervali (Buckets) za N = 3 

0 1 2 3 

69

Zbog tog razloga se za izračun frekvencije pojavnosti nepopularnih vrijednosti koristi druga 

statistička veličina pod nazivom density. Od verzije 11g baze podataka, CBO ne koristi staru density 

vrijednost koju izračunava DBMS_STATS paket i koja je pohranjena u data dictionary, već izračunava 

interno novu vrijednost koja je zabilježena u 10053 trace datoteci pod nazivom NewDensity i koja se 

koristi za izračun selektivnosti predikata iz WHERE uvjeta SQL naredbi u prisutnosti histograma. 

Izračun i korištenje nove density vrijednosti regulirano je skrivenim inicijalizacijskim parametrom 

_optimizer_enable_density_improvements. Način izračuna NewDensity vrijednosti i njezine primjene u 

izračunu selektivnosti za SQL naredbe koje referenciraju nepopularne vrijednosti prikazane su u 

sljedećem primjeru. Tablica T3 sa stupcem N1 sadrži 25 redaka i neravnomjernu raspodijelu 

vrijednosti unutar stupca N1. Vrijednosti u stupcu N1 izgledaju kao što slijedi u primjeru 4: 

Primjer 4. Izračun i primjena NewDensity vrijednosti za procjenu selektivnost nepopularnih vrijednosti 

select n1, count(*) 

from t3 

group by n1 

order by n1; 

N1 COUNT(*) 

1 4 

5 6 

6 1 

7 1 

8 11 

9 1 

10 1 

Nad stupcem N1 generiran je HB histogram sa 5 intervala (bucketa). 

ENDPOINT_VALUE ENDPOINT_NUMBER EPn – EPn-1 

1 0 0 

5 2 2 

8 4 2 

10 5 1 

Distribuciju vrijednosti, alternativno možemo prikazati i na sljedeći način: 

EV 1 5 5 8 8 10 

V 1 1 1 1 5 5 5 5 5 5 6 7 8 8 8 8 8 8 8 8 8 8 8 9 10 

EN 0 1 2 3 4 5 

EV = ENDPOINT_VALUE 

V = VRIJEDNOST 

EN = ENDPOINT_NUMBER 

R = RAZLIKA 

HB histogram je prepoznao vrijednosti 5 i 8 kao popularne vrijednosti. Vrijednost 1, iako se 

pojavljuje 4 puta nije prepoznata kao popularna vrijednost, budući da se sljedeća pozicija uzorkovanja 

nalazi na fizičkoj poziciji 5. retka (sortirano), u kojem je vrijednost N1 = 5. Zasjenjeni stupci označavaju 

uzorkovane retke. Jače zatamnjeni stupci označavaju retke koji jesu uzorkovani u fazi generiranja 

histograma, ali se ne prikazuju u histogramu zbog mehanizma kompresije. U histogramu se vrijednosti 

(ENDPOINT_VALUE) 5 i 8 pojavljuju samo jednom, ali im je pripadajuća ENDPOINT_NUMBER 

vrijednost 2, što ukazuje da je riječ o popularnim vrijednostima. Iscrtkanom linijom označen je prijelaz 

između različitih (distinct) vrijednosti unutar granica pojedinog intervala. 

U nastavku slijedi isječak iz trace datoteke generirane sa 10053 eventom za testni SQL upit. 

select n1 

from t3 

where n1 = 1; 

70

SINGLE TABLE ACCESS PATH 

Single Table Cardinality Estimation for T3[T3] 

Column (#1): 

NewDensity:0.040000, OldDensity:0.100000 BktCnt:5, PopBktCnt:4, PopValCnt:2, NDV:7 

gdje je: 

OldDensity stara density vrijednost pohranjena u data dictionary 

BktCnt broj intervala (bucketa) 

PopBktCnt broj popularnih intervala 

PopValCnt broj popularnih vrijednosti 

NDV broj različitih vrijednosti (NDV = number of distinct values) 

NewDensity se izračunava koristeći sljedeću formulu 1 : 

NewDensity = ((BktCnt – PopBktCNt) / BktCnt) / (NDV – PopValCnt) 

odnosno, ako uvrstimo gornje vrijednosti dobivamo: 

NewDensity = ((5 – 4) / 5) / ( 7 – 2) = 0.2 / 5 = 0.04 

Što predstavlja NewDensity formula ? Kada CBO ne raspolaže informacijom o raspodijeli 

vrijednosti za pojedinu kolonu, optimizer pretpostavlja da se radi o ravnomjernoj distribuciji. Ukoliko je 

nad kolonom tablice generiran HB histogram, konceptualno je moguće podijeliti tablicu u dva 

podskupa: popularni i nepopularni. SQL naredba sa filterom “where kolona = konstanta” će selektirati 

vrijednosti iz jednog od ta dva skupa. Kada SQL naredba selektira iz popularnog skupa, tada se 

density ili pak NewDensity ne koriste, jer je podatak o frekvenciji pojavnosti zapisan u samom HB 

histogramu. Međutim, ukoliko bi prethodno opisani SQL zahvaćao podatke iz nepopularnog skupa 

tada nam histogram više nije od pomoći. Za nepopularne vrijednosti u tablici distribucija je nepoznata, 

pa CBO pretpostavlja ravnomjernu distribuciju. Umnožak broj_redaka * density predstavlja 

aproksimaciju prosječne frekvencije pojavnosti svake pojedine vrijednosti koja nije prikazana u 

histogramu kao popularna vrijednost. U gornjem primjeru, ako je broj popularnih intervala PopBktCnt = 

4, broj popularnih distinct vrijednosti 2, a ukupan broj redaka u tablici iznosi 25, to znači da ukupan 

broj nepopularnih redova iznosi (5-4) / 5 = 0.2 * 25 = 5, dok je ukupan broj nepopularnih distinct 

vrijednosti 7 – 2 = 5, pa je selektivnost 0.2 / 5 = 0.04, a kardinalnost 0.2 / 5 = 0.04 * 25 = 1. 

1.2.2. Stabilnost Height Balanced histograma 

Ponekad, čak i male promjene nad tablicom, kao što je dodavanje retka, brisanje retka ili pak 

ažuriranje postojećeg retka, mogu uzrokovati nestajanje nepopularnih vrijednosti iz histograma. 

Popularne vrijednosti sa druge strane, ponašaju se puno stabilnije, odnosno rjeđe nestaju iz 

histograma, iako se može dogoditi da popularna vrijednost postane nepopularna. Npr. promjenimo li 

samo jedan redak u tablici iz Primjera 2. za koji je N1 = 9 u N1 = 10, vrijednost 9 prestaje biti 

popularna vrijednost: 

VRIJEDNOST ENDPOINT_VALUE ENDPOINT_NUMBER 

RAZLIKA 

1 1 0 

2 2 

3 3 1 (1 – 0) = 1 

4 4 

9 9 

9 9 2 (2 -1 ) = 1 

9 9 

9 9 

10 10 3 (3 – 2) = 1 

1 [Dell’Era, New Density calculation in 11g] 

71

Takav oblik nestabilnosti karakterističan je samo za HB histograme, budući da se kod FH histograma 

mapa vrijednosti gradi zbrajajući frekvencije pojavnosti za svaku pojedinu (distinct) vrijednost u stupcu 

tablice, za razliku od HB kod kojih se mapa vrijednosti gradi na temelju uzorkovanja, pa struktura 

histograma zavisi o tome na kojem će se mjestu nalaziti granice intervala (bucketa). 

2. SPECIFIČNE PRIMJENE HISTOGRAMA 

Primjena histograma nije limitirana isključivo na precizniji izračun selektivnosti i kardinalnosti kod 

neravnomjernih raspodijela vrijednosti, te posljedično na primjereniji izbor načina pristupa podacima 

(access path), join mehanizma i redoslijeda međusobnog vezivanja tablica putem join mehanizma. 

Histogrami mogu pomoći i u procjeni selektivnosti kod korištenja neprimjerenih tipova podataka ali i 

kod pojave ekstremnih vrijednosti u inače savršeno ravnomjernoj raspodijeli vrijednosti 2 . 

Pretpostavimo sljedeći slučaj, u kojem se neprimjereno koristi number tip podatka za pohranu 

datumskih vrijednosti, umjesto da se za iste koristi propisani date tip. Za potrebe testa, pripremiti ćemo 

tablicu sa podacima za interval od 01.12.2010 do 01.01.2011. (32 retka). Tablica sadrži dva stupca, a 

u oba stupca su unešene iste datumske vrijednosti u intervalu od 01.12.2010 do 01.01.2011, uz 

razliku da se u stupcu D vrijednosti pohranjuju koristeći nativni date tip, dok se u stupcu N vrijednosti 

pohranjuju koristeći number tip. Sa DBMS_STATS paketom, prikupiti će se statistike, ali bez 

histograma (SIZE 1). 

create table t 

as 

select to_date('01.12.2010', 'dd.mm.yyyy')+rownum-1 d, 

to_number(to_char(to_date('01.12.2010', 'dd.mm.yyyy')+rownum-1, 'yyyymmdd')) n 

from dual 

connect by level 'FOR ALL COLUMNS SIZE 1' ); 

SQL upitom selektirati ćemo retke iz tablice za razdoblje od 31.12.2010 do 01.01.2011, prvo za stupac 

D – nativni date tip: 

select d, n 

from t_dtype 

where d between to_date('31.12.2010', 'dd.mm.yyyy') and to_date('01.01.2011', 'dd.mm.yyyy') 

D N 

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

31.12.10 20101231 

01.01.11 20110101 

Execution Plan 

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

Plan hash value: 696206505 

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

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 

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

| 0 | SELECT STATEMENT | | 2 | 28 | 2 (0)| 00:00:01 | 

|* 1 | TABLE ACCESS FULL| T_DTYPE | 2 | 28 | 2 (0)| 00:00:01 | 

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

Očekivano, upit je vratio dva retka, a procjena optimizera bila je vrlo precizna. Ponovimo li isti upit 

postavljajući filter nad N kolonu, odnosno number tip, dobivamo sljedeći rezultat: 

2 [J. Lewis: CBO Fundamentals, Apress, 2006] 

72

select d, n 

from t_dtype 

where n between 20101231 and 20110101 

D N 

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

31.12.10 20101231 

01.01.11 20110101 


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


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


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



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

Upit je vratio ista dva retka, međutim izračunata selektivnost drastično odstupa od stvarnog 

stanja. Zašto dolazi do krive procjene ? Zbog pogrešnog korištenja number tipa za pohranu datumskih 

vrijednosti, Oracle ne razumije da su zapravo 20121231 i 20110101 u kalendarskom smislu dvije 

uzastopne vrijednosti. Numerički, traženi raspon vrijednosti iznosi 20110101 – 20101231 = 8870, dok 

ukupni rang vrijednosti (max – min) iznosi 20110101 – 20101201 = 8900. Već parcijalnim izračunom 

vidljivo je da optimizer procjenjuje selektivnost kao 8870 / 8900 = 99.6% redaka u tablici, a to u našem 

slučaju iznosi 32 retka. Generiranjem HB histograma sa 20 intervala (bucketa) nad N stupcem, 

ponavljamo isti SQL upit, ali ovoga puta je selektivnost preciznije izračunata, budući da uz pomoć 

histograma optimizer zna da svaki interval (bucket) u prosjeku ima 32 / 20 = 1.6 redaka. 

D N 

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

31.12.10 20101231 

01.01.11 20110101 


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


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


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



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

Drugi zanimljivi primjer korištenja histograma, odnosi se na slučaj u kojem histogram pomaže pri 

izračunu selektivnosti za nizove vrijednosti unutar kojih se pojavljuju ekstremi. Pretpostavimo tablicu 

koja u sebi sadrži 365 redaka, odnosno po jedan redak za svaki dan u 2010. godini. Nadalje, 

pretpostavimo da se nakon uspješnog procesiranja slogovi ne brišu iz tablice, već se u stupcu datum, 

vrijednost datuma postavlja na 01.01.1970 i na takav način diferencira procesirane od neprocesiranih 

redaka. Efekt će biti prikazan na primjeru. 

create table t_eks 

as 

select to_date('01.01.2010', 'dd.mm.yyyy')+rownum-1 d 

from dual 

connect by level 'FOR ALL COLUMNS SIZE 1' ); 

73

Nakon kreiranja tablice i prikupljanja statistika, za početak bez histograma, iz tablice će biti selektirani 

podaci za 12/2010. 

select count(*) 

from t_eks 

where d between 

to_date('01.12.2010' , 'dd.mm.yyyy') and to_date('31.12.2010' , 'dd.mm.yyyy') 

COUNT(*) 

---------- 

31 


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


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


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


| 1 | SORT AGGREGATE | | 1 | 8 | | | 

|* 2 | TABLE ACCESS FULL| T_EKS | 31 | 248 | 2 (0)| 00:00:01 | 

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

Očekivano, SQL upit je vratio 31 redak, a optimizer je također ispravno procjenio selektivnost. Sada 

ćemo jedan od redaka ažurirati na vrijednost 01.01.1970, te osvježiti statistike, ali ponovno bez 

generiranja histograma: 

update t_eks set d = to_date('01.01.1970', 'dd.mm.yyyy') where rownum = 1; 

commit; 

exec dbms_stats.gather_table_stats(user, 'T_EKS', method_opt=>'FOR COLUMNS D SIZE 1'); 

Upit je vratio očekivanih 31 redak, međutim, procjenjena selektivnost u planu izvršavanja sada 

dramatično odstupa: 

COUNT(*) 

---------- 

31 


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


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


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




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

Razlog je u tome što Oracle izračunava selektivnost “between“ ranga vrijednosti na sljedeći način: 

(željeni rang vrijednosti) / (ukupni rang vrijednost) + 2/num_distinct 

što u prvom slučaju iznosi: 

(31.12.2010 – 01.12.2010) / (31.12.2010 – 01.01.2010) + 2/365 = 30 / 364 + 2/365 = 0.0879 * 

365 = 32 

74

Nakon ažuriranja jednog od redaka, došlo je do promjene minimalne vrijednosti unutar stupca, te 

dramatičnog povećanja ukupnog raspona vrijednosti (max – min vrijednost). Ukupni raspon vrijednosti 

povećan je sa 364 na 14974, što znači da prema prije navedenoj formuli selektivnost iznosi: 

(31.12.2010 – 01.12.2010) / (31.12.2010 – 01.01.1970) + 2/365 = 30 / 14974 + 2/365 = 

0.00748 *365 = 2 

Kreiranjem histograma, traženi interval se ne aplicira više na cijeli rang vrijednosti unutar kolone 

tablice, već samo na raspon vrijednosti jednog ili više intervala koji obuhvaćaju tražene vrijednosti, u 

našem slučaju riječ je o intervalu broj 2. Rezultat je dramatično povećana preciznost izračuna 

selektivnosti. 

ENDPOINT ENDPOINT_NUMBER WIDTH HEIGHT 

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

01.01.70 0 

02.07.10 1 14792 ,0022 

31.12.10 2 182 ,1758 

Uz prisutnost histograma, selektivnost traženog ranga vrijednosti se izračunava na sljedeći način: 

(31.12.2010 – 01.12.2010) / (31.12.2010 – 02.07.2010) + 2 * density = 30 / 182 + 2 * 

0.002739726 = 0.164835 * 182 = 31. 

Ponovimo li prijašnji upit, možemo vidjeti da je uz pomoć histograma ponovno točno procjenjena 

selektivnost. 

select count(*) 

from t_eks 

where d between 

to_date('01.12.2010' , 'dd.mm.yyyy') and to_date('31.12.2010' , 'dd.mm.yyyy') 

COUNT(*) 

---------- 

31 


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


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


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




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

3. IZRADA VLASTITOG FREQUENCY HISTOGRAMA 

Za stupce koji sadržavaju više od 254 različitih (distinct) vrijednosti, nije moguće generirati 

precizan Frequency histogram. U takvim okolnostima koristi se Height balanced histogram čiji je glavni 

nedostatak smanjena preciznost kojom se opisuju podaci u tablici. Moguće je da određene retke sa 

visokom frekvencijom pojavnosti Oracle ne detektira kao popularne vrijednosti prilikom kreiranja 

histograma. Ukoliko korisnici sustava učestalo pretražuju slogove koji sadržavaju te vrijednosti važno 

je postići dobru procjenu selektivnosti, jer je to temelj za formiranje kvalitetnih planova izvršavanja. 

Izradom vlastitog Frequency histograma moguće je detaljnije opisati popularne vrijednosti i postići 

bolju procjenu selektivnosti, a samim time i kvalitetnije planove izvršavanja. Postupak će biti prikazan 

na sljedećem primjeru. Koristeći sljedeću SQL naredbu, kreirana je tablica sa 100000 redaka i sa 

100000 različitih (distinct) vrijednost u stupcu N1. 

75

create table t4 

as 

select 

rownum n1 

from dual 

connect by level

declare 

l_statrec DBMS_STATS.statrec; 

l_val_array DBMS_STATS.numarray; 

l_distcnt number; 

l_density number; 

l_nullcnt number; 

l_avgclen number; 

begin 

dbms_stats.get_column_stats( 

ownname=>user, 

tabname=>'T4', 

colname=>'N1', 

distcnt=> l_distcnt, 

density=> l_density, 

nullcnt=> l_nullcnt, 

srec => l_statrec, 

avgclen => l_avgclen 

); 

select n1, c 

bulk collect into l_val_array, l_statrec.bkvals 

from 

( 

select n1, c 

from 

( 

select n1, count(*) c 

from t4 

group by n1 

order by c desc 

) 

where rownum l_statrec, 

numvals=>l_val_array 

); 

select 1/(2*count(*)) into l_density from t4; 

dbms_stats.set_column_stats( 

ownname=>user, 

tabname=>'T4', 

colname=>'N1', 

distcnt=> l_distcnt, 

density => l_density, 

nullcnt => l_nullcnt, 

srec => l_statrec, 

avgclen => l_avgclen 

); 

END; 

77

Analizirajući generirani FH histogram, vidimo da su ovog puta popularne vrijednosti zabilježene kao 

takve i u samom histogramu, što je vidljivo iz sljedećeg isječka histograma: 

ENDPOINT_VALUE ENDPOINT_NUMBER 

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

... ... 

98 196 

99 198 

100 300 

123 301 

200 502 

300 803 

400 1204 

500 1705 

... .... 

Ponovimo li prethodni upit nad tablicom iz primjera, vidimo da sada plan izvršavanja prijavljuje da će 

sustav vratiti 104 retka, što je vrlo precizna procjena, s obzirom da u tablici postoje 102 retka, za koje 

je N1=100. 

select n1 from t4 where n1 = 100 


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


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


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


|* 1 | TABLE ACCESS FULL| T4 | 104 | 520 | 45 (3)| 00:00:01 | 

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

ZAKLJUČAK 

Histogrami predstavljaju moćan alat za rješavanje određenih tipova problema optimizacije SQL 

naredbi. Primjena histograma nije nužno vezana isključivo uz tradicionalne probleme optimizacije SQL 

naredbi kod neravnomjernih raspodijela vrijednosti unutar stupaca tablice, već je moguća za 

rješavanje određenih specifičnih situacija, kao što je pojava ekstremnih vrijednosti u normalnim 

raspodijelama vrijednosti ili neprimjerenog korištenja tipova podataka. Stupci sa manje od 255 

različitih (distinct) vrijednosti su dobri kandidati za generiranje preciznih Frequency histograma, dok je 

za stupce sa više od 255 vrijednost, potrebno izgraditi Height balanced histogram ili u ekstremnih 

slučajevima, pribjeći izradi vlastitog Frequency histograma za najpopularnije vrijednosti u tablici. 

LITERATURA 

Lewis, Jonathan: Cost Based Oracle Fundamentals, 2006. 

Dell'Era, Alberto: New Density calculation in 11g, 2007.; Join Over Histogram, 2007. 

78

KRIPTOGRAFIJA U ORACLE BAZI 

Zlatko Sirotić 

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

e-mail: zlatko.sirotic@iii.hr 

SAŽETAK 

U radu se prvo prikazuju osnove kriptografije. Prikazuje se razlika između simetričnih kriptosustava 

(koji koriste isti ključ u procesu kriptiranja i procesu dekriptiranja) i asimetričnih kriptosustava 

(kriptosustava s javnim ključem). Nešto detaljnije se prikazuje asimetrični kriptosustav RSA. Zatim se 

prikazuje upotreba kriptografije u Oracle bazi. U prilogu se prikazuje matematička osnova kriptosustava 

RSA, te njegova programska realizacija (za prezentacijske svrhe). 

The paper presents the basics of cryptography. Furthermore, it shows the difference between the 

symmetric cryptosystem (which uses the same key in the encryption and decryption process) and 

asymmetric cryptosystem (cryptosystem with public key). The asymmetric cryptosystem RSA is explained 

in detail, as it is the use of cryptography in the Oracle database. The appendix shows the mathematical 

basis of the RSA cryptosystem and the implementation of its software (for presentation purposes). 

UVOD 

Sve do kraja 60-tih godina prošlog stoljeća, kriptografija se uglavnom koristila u vojne i diplomatske 

svrhe. Tada je došlo do širokog razvoja međunarodnih financijskih transakcija, pa se pojavila potreba za 

kriptosustavima koje će moći koristiti korisnici širom svijeta. Zato su uvedeni međunarodni standardi u 

kriptografiji. Prvo su uvedeni simetrični kriptosustavi, koji koriste isti ključ i u procesu kriptiranja i u 

procesu dekriptiranja, što znači da je ključ poznat i pošiljatelju i primatelju poruke (i samo njima). Kasnije 

su razvijeni asimetrični kriptosustavi (ili kriptosustavi s javnim ključem). 

U radu se prvo prikazuju sigurnosne osobine poruka (informacija). Zatim se ukratko prikazuju 

simetrični i asimetrični kriptosustavi. Iako Oracle baza podataka za sada izravno ne koristi asimetrične 

kriptosustave, u nastavku se nešto detaljnije prikazuje najčešće korišteni asimetrični kriptosustav RSA. U 

prilozima se daju i neki matematički pojmovi vezani za RSA kriptosustav, te prezentacijska realizacija 

RSA kriptosusava u Oracle Forms alatu. 

U nastavku se prikazuje korištenje kriptografije u Oracle bazi. Kao kod svih baza, tako i kod Oracle 

baze postoje dvije glavne vrste kriptiranja podataka – kriptiranje podataka koji su u tranzitu (data in 

transit) i kriptiranje podataka koji stoje (data at rest), a kod potonjih se uglavnom radi o podacima baze 

podataka koji se nalaze na diskovima. Kriptiranje podataka koji stoje radi se u Oracle bazi isključivo 

pomoću simetrične kriptografije, a moguće je primjenjivati "ručnu" metodu, tj. programiranje pomoću 

paketa DBMS_CRYPTO, ili dvije metode koje čine tzv. transparentnu enkripciju podataka (Transparent 

Data Encription, DTE): TDE Column Encryption i TDE Tablespace Encryption. 

1. SIGURNOSNE OSOBINE PORUKA (INFORMACIJA) 

Sigurnost računalnih komunikacija ovisi o sljedećim sigurnosnim osobinama poruka (informacija) ili, 

drugačije rečeno, o sljedećim zahtjevima nad porukama (informacijama): 

- povjerljivost (tajnost, privatnost, engl. confidentiality): poruku (informaciju) koju osoba A 

šalje osobi B ne može pročitati nitko treći; 

- integritet (besprijekornost, netaknutost, engl. integrity): osoba B je sigurna da poruka 

(informacija) koju je poslala osoba A nije promijenjena (od neke treće osobe); 

- raspoloživost (engl. availability): poruke (informacije) moraju uvijek biti na raspolaganju 

ovlaštenim osobama, unatoč mogućim nepogodama / nesrećama ili zlonamjernim napadima; 

79

- autentičnost (vjerodostojnost, engl. authenticity): osoba B zna da je samo osoba A mogla 

poslati poruku koju je ona (osoba B) primila; 

- neporecivost (nepobitnost, ne-nepriznavanje, engl. non-repudiation): osoba A ne može 

zanijekati da je poslala poruku koju je osoba B primila (ako ju zaista poslala). 

Može se napomenuti sljedeće: 

- prva tri zahtjeva (povjerljivost, integritet, raspoloživost) se često smatraju osnovnim 

zahtjevima; 

- raspoloživost se ne može povećati pomoću kriptografije, čak se ponekad može i smanjiti 

(kriptiranje i dekriptiranje poruka traje neko vrijeme); 

- često se navodi i šesti zahtjev, autorizacija (engl. authorization): autentificirani korisnik može 

pristupati samo sadržajima koji su mu dopušteni, i to na način koji mu je dopušten; 

autorizacijom se dodatno osiguravaju povjerljivost i/ili integritet; autorizacija se ne rješava 

(direktno) pomoću kriptografije; 

- zahtjev autentičnosti i neporecivosti (poruke) izgledaju slično, pa se može činiti da su 

ekvivalentni; no, autentičnost ne implicira neporecivost, jer bi npr. osoba B mogla sama sebi 

poslati poruku kriptiranu simetričnim ključem i tvrditi da je poruku poslala osoba A (koja 

jedina, uz osobu B, zna taj ključ); no, ako se primjenjuje asimetrični kriptosustav, onda osoba 

B ne može sama sebi poslati kriptiranu poruku u ime osobe A (jer samo osoba A ima tajni 

ključ) i može se sigurno tvrditi da je to poruka od osobe A; s druge strane, neporecivost ne 

implicira autentičnost, jer se osoba C može lažno predstaviti kao da je osoba A i koristiti svoj 

javni i privatni ključ (C može znati javni ključ osobe A, ali ne može znati tajni ključ osobe A). 

Drži se da je zahtjev neporecivosti (poruke) jedini zahtjev koji se ne može elegantno riješiti pomoću 

simetričnih kriptosustava. No, asimetrični kriptosustavi puno su pogodniji i za rješavanje zahtjeva 

integriteta i autentičnosti. S druge strane, zahtjev povjerljivosti (naročito kod velikih poruka) najčešće se 

rješava pomoću simetričnih kriptosustava, koji su puno brži i traže ključeve manjih veličina (za istu razinu 

sigurnosti) u odnosu na asimetrične kriptosustave. Kod zahtjeva povjerljivosti, asimetrični kriptosustavi se 

najčešće koriste samo za razmjenu simetričnog ključa (kojim će se kriptirati poruka i osigurati njena 

povjerljivost). 

2. SIMETRIČNI I ASIMETRIČNI KRIPTOSUSTAVI 

Do kraja 60-tih godina prošlog stoljeća glavna primjena kriptografije bila je u vojne i diplomatske 

svrhe, pa su pojedine države (ili čak organizacije) imale svoje specifične kriptosustave. No, tada je došlo 

do širokog razvoja međunarodnih financijskih transakcija, pa se pojavila potreba za kriptosustavima koje 

će moći koristiti korisnici širom svijeta, tj. pojavila se potreba uvođenja (međunarodnih) standarda u 

kriptografiji. 

Na temelju programa i javnog natječaja za zaštitu računalnih i komunikacijskih podataka koji je 

1972./73. inicirao američki National Bureau of Standard (NBS), 1976. je prihvaćen kao standard 

kriptosustav koji je dobio ime Data Encryption Standard (DES), a koristi 56-bitne ključeve. Taj je standard 

bio u širokoj upotrebi sve do kraja 20. stoljeća (iako se koristi i danas), ali je već početkom 90-tih godina 

postalo jasno da je samo pitanje vremena kad će DES postati nesiguran, što se prvi put javno pokazalo 

1998. godine. Zato je 1997. godine National Institute of Standards and Technology (NIST), organizacija 

koja je naslijedila NBS, raspisala natječaj za kriptosustav koji će naslijediti DES. Kao privremeni standard 

određen je prošireni DES standard imena 3DES (trostruki DES), koji koristi 168-bitne ključeve. Nasljednik 

DES-a izabran je 2000. godine i dobio je ime Advanced Encryption Standard (AES), a koristi 128, 192, ili 

256-bitne ključeve. 

Navedeni kriptosustavi su simetrični kriptosustavi, tj. koriste isti ključ i u procesu kriptiranja 

(enkripcije, šifriranja) i u procesu dekriptiranja (dekripcije, dešifriranja), što znači da je ključ poznat i 

pošiljatelju i primatelju poruke (i samo njima). No, taj simetrični ključ ima manu da se mora (na siguran 

način) razmijeniti među sudionicima u komunikaciji, što nije veliki problem kod zatvorenih sustava s malim 

brojem sudionika u komunikaciji, ali je problem kod današnjih otvorenih sustava s nepoznatim i velikim 

brojem sudionika. Zato su razvijeni asimetrični kriptosustavi (ili kriptosustavi s javnim ključem). 

Glavna ideja je da se konstruiraju kriptosustavi kod kojih je na temelju poznavanja funkcije kriptiranja 

praktički nemoguće izračunati funkciju dekriptiranja. Svaki sudionik u komuniciranju ima svoj javni ključ, 

80

koji može biti poznat svima, i svoj tajni ključ, koji je poznat samo njemu. Kriptiranje se radi javnim ključem 

primatelja, a dekriptiranje tajnim ključem primatelja (kod digitalnog potpisa je drugačije!), tako da samo 

primatelj može pročitati poruku. Asimetrični kriptosustavi nisu zamjena za simetrične, već jedni druge 

nadopunjuju, čime se dobivaju hibridni kriptosustavi. 

Može se dati ovakva usporedba između simetričnih kriptosustava (SK) i asimetričnih kriptosustava 

(AK): 

- sigurnost: kod AK, samo privatni ključ mora biti tajan, a javni ključ se može slobodno 

distribuirati; kod SK, zajednički (simetrični) ključ mora biti poznat dvjema (ili više) sudionicima 

u komunikaciji; nije dokazano da su AK sigurni, ali isto vrijedi i za SK, osim u slučaju kada se 

simetrični ključ upotrebljava samo jedanput; 

- dugotrajnost ključa: kod AK, isti par ključeva se može koristiti dugo vremena, a kod SK je 

poželjno mijenjati ključ kod svake sesije; 

- upravljanje ključevima (engl. key management): ako je n broj sudionika u međusobnoj 

komunikaciji, SK traži ukupno n * (n – 1) / 2 ključeva, pri čemu svaki sudionik mora kod sebe 

pamtiti (n – 1) ključ; kod AK, treba ukupno n javnih ključeva, koji se mogu slobodno pohraniti 

na nekom pristupačnom mjestu (bazi javnih ključeva), a svaki sudionik mora pamtiti samo 

svoj tajni ključ (u pravilu pamti i svoj javni ključ, da ne mora za njega pristupati bazi); 

- razmjena ključeva: kod AK se ne moraju razmjenjivati ključevi između sudionika; razmjena 

ključeva kod SK je obavezna; budući da je to opasno, upravo se AK koristi za sigurnu 

razmjenu simetričnog ključa, čime se onda omogućava SK (zajedno je to hibridni 

kriptosustav); 

- efikasnost: AK su značajno sporiji od SK; npr. RSA kriptosustav je oko 1000 puta sporiji od 

DES kriptosustava; 

- veličina ključeva: ključevi za AK su značajno veći od ključeva za SK (za istu razinu 

sigurnosti); npr. privatni ključ u RSA mora imati barem 1024 bita, dok je kod većine SK 128 

bitova dovoljno. 

U nastavku su dati neki vrlo važni pojmovi kod primjene asimetričnih kriptosustava (primjenjuju se 

samostalno, ili zajedno sa simetričnim kriptosustavima). 

Sažetak (hash, digest): za razliku od funkcije kriptiranja, koja je matematički gledano injektivna 

funkcija, tj. funkcija koja dva različita X-a preslikava u dva različita Y-a, funkcija sažetka može preslikavati 

više X-eva u isti Y, što znači da nema inverznu funkciju. Koristi se kao pomoćno sredstvo, npr. kod 

spremanja hash-a lozinki (umjesto samih lozinki) u bazu podataka, kod digitalnog potpisa i dr. 

Digitalna omotnica: njome se postiže povjerljivost poruke. Za to bi se mogli koristiti i samo 

simetrični ključevi. No, budući da je razmjena nekriptiranih simetričnih ključeva opasna, pošiljatelj kreira 

novi simetrični ključ (samo za tu sesiju), pomoću tog ključa kriptira izvornu poruku, a onda simetrični ključ 

kriptira pomoću javnog ključa primatelja, te onda šalje oboje - poruku kriptiranu simetričnim ključem i 

kriptirani simetrični ključ. Primatelj prvo dekriptira kriptirani simetrični ključ (svojim tajnim ključem, što 

znači da samo on to može napraviti), a onda tako dobivenim simetričnim ključem dekriptira izvornu 

poruku. Navedeno je prikazano na slici 1. 

Digitalni potpis: njime se postiže integritet i neporecivost poruke. Pošiljatelj uz izvornu 

(nekriptiranu) poruku šalje i izvornu poruku kriptiranu pomoću svog tajnog ključa (suprotno od uobičajene 

sheme asimetričnog kriptiranja, npr. one kod digitalne omotnice!). Primatelj pomoću javnog ključa 

pošiljatelja dekriptira poruku i uspoređuje ju s izvornom. Budući da samo pošiljatelj zna svoj privatni ključ, 

osiguran je integritet i neporecivost poruke. Zapravo, u praksi se najčešće ne kriptira izvorna poruka, već 

sažetak (hash) izvorne poruke, a razlozi su (barem) sljedeći: sažetak je kraći od izvorne poruke, pa se 

brže kriptira/dekriptira (važno je, jer su asimetrični kriptosustavi spori), ukupna poruka je kraća, izvorna 

poruka se može isto kriptirati (što onda čini digitalni pečat). U ovoj varijanti primatelj uspoređuje dobiveni 

sažetak s onim koji sam izračunava, kako je prikazano na slici 2. 

81

Slika 1. Digitalna omotnica; Izvor [8] 

Slika 2. Digitalni potpis; Izvor [8] 

Digitalni pečat: njime se postiže povjerljivost, integritet i neporecivost poruke. Digitalni pečat je 

kombinacija digitalne omotnice i digitalnog potpisa, tj. digitalni pečat je digitalno potpisana digitalna 

omotnica. 

Digitalni certifikat: njime se postiže autentičnost poruke. Digitalni certifikat je (specijalna) poruka 

koja je (najčešće) digitalno potpisana od certifikacijskog centra (engl. Certification Authority, CA), kome 

se po definiciji vjeruje. Ta (specijalna) poruka sadrži barem par podataka - identifikator i javni ključ 

pošiljatelja. U praksi certifikat obično sadrži i podatak o roku valjanosti, primijenjenim algoritmima za 

sažimanje i kriptiranje kod potpisivanja, i dr. Pomoću digitalnog certifikata primatelj može provjeriti da li je 

dobiveni (od nekog pošiljatelja) javni ključ jednak onome koji piše u digitalnom certifikatu, tj. da li je 

pošiljatelj autentičan (onaj kojim se predstavlja). 

82

3. OPIS RSA KRIPTOSUSTAVA 

Diffie-Hellmanov postupak za razmjenu tajnog ključa 

Iako je RSA prvi kriptosustav s javnim ključem (objavljen 1977. godine), začetnicima kriptografije 

javnog ključa smatraju se Diffie i Hellman, koji su 1976. godine objavili postupak (protokol) za razmjenu 

tajnog (simetričnog) ključa. Njihov postupak, iako služi za sigurnu razmjenu simetričnog ključa (tj. kod 

njihovog postupka se ne radi o javnim i tajnim ključevima, odnosno asimetričnom kriptosustavu), dao je 

ključnu ideju za realizaciju kriptosustava s javnim ključem – ideju da se konstruiraju kriptosustavi kod 

kojih bi iz poznavanja funkcije kodiranja bilo praktički nemoguće (u nekom razumnom vremenu) izračunati 

funkciju dekodiranja. Tada bi funkcija kodiranja mogla biti javna. 

Diffie-Hellman postupak za razmjenu ključeva zasnovan je na činjenici da je u nekim grupama 

potenciranje puno jednostavnije od logaritmiranja (problem diskretnog logaritma). 

Kriptosustavi s javnim ključem i RSA kriptosustav 

U kriptosustavu s javnim ključem svaki korisnik ima dva ključa: javni E K i tajni K D (slova E i D 

označavaju glavnu namjenu tih ključeva: Enkripcija i Dekripcija). Ako Ana želi poslati Branku poruku P, 

onda je ona kodira pomoću Brankovog javnog ključa K EB i pošalje Branku šifrat C: 

C = E( 

P, 

K EB) 

. 

Branko dekodira šifrat koristeći svoj tajni ključ K DB : 

P = D( 

C, 

K DB) 

tj. 

P = D( 

E( 

P, 

K EB), 

K DB) 

. 

Napomena: u engleskoj literaturi uobičajena imena za glavne sudionike u komunikaciju su Alice i 

Bob (kod nas Ana i Branko), a ti su likovi uvedeni upravo u prvom radu o RSA kriptosustavu. 

RSA je prvi i najpoznatiji kriptosustav s javnim ključem, objavljen 1977. godine, a nazvan je po 

svojim tvorcima Ronaldu Rivestu, Adi Shamiru i Leonardu Adlemanu. Njegova sigurnost je zasnovana 

prvenstveno na teškoći faktorizacije velikih prirodnih brojeva. No, otvoreno je pitanje je li razbijanje RSA 

kriptosustava, tj. određivanje x iz poznavanja x n 

e mod ekvivalentno faktorizaciji od n. 

Postupak izgradnje RSA kriptosustava 

1. Odaberu se dva tajna velika prosta broja p i q, svaki veličine barem 512 bitova (a 

preporučljivo je i 1024). 

2. Izračunava se umnožak n = p q. 

3. Izračunava se umnožak ϕ(n) = (p – 1) (q – 1). 

4. Odabere se broj e < ϕ(n) i relativno prost u odnosu na ϕ(n), 

tj. takav da je nzd (e, ϕ(n)) = 1. 

5. Izračunava se broj d < ϕ(n) tako da bude: 

e d ≡ 1 (mod ϕ(n)), 

što se može napisati i kao: 

e d ≡ k ϕ(n) + 1 

(može se primijetiti da zato što su broj e i umnožak e d relativno prosti u odnosu na ϕ(n), 

automatski je i broj d relativno prost u odnosu na ϕ(n)). 

6. Brojevi e i n se obznanjuju i čine javni ključ. 

7. Brojevi p, q, d su tajni, pri čemu je d tajni ključ (zajedno sa n, koji je javno poznat). 

83

Kriptiranje se obavlja funkcijom kriptiranja: 

e 

C = E( 

P, 

K ) = RSA( 

P, 

K ) = P mod n, 

E 

a dekriptiranje funkcijom dekriptiranja: 

P = D( 

C, 

K 

D 

) = 

RSA 

−1 

( C, 

E 

K 

D 

) = C 

d 

e 

d 

mod n = ( P mod n) 

mod n = P 

U nastavku se pokazuje da je taj postupak korektan, tj. da je: 

P P (mod n) 

ed ≡ . 

ed 

mod n 

Zapravo, mora se primijetiti da je navedeni postupak korektan samo ako je veličina poruke P manja 

od n. Ako je poruka P ≥ n (što je u pravilu često), onda se izvorna poruka P razbija na poruke 

od kojih je svaka manja od n, te se svaka zasebno kriptira i dekriptira. 

P P ,..., P 

1, 

2 

r 

Provjera korektnosti RSA kriptosustava 

Treba pokazati da je: 

P P (modn) 

ed ≡ . 

Budući da je: 

e d ≡ k ϕ(n) + 1 = k (p – 1) (q – 1) + 1, 

može se za one P koji nisu kongruentni s 0 (mod p), što znači da nisu višekratnici od p, koristiti mali 

Fermatov teorem (prikazan u prilogu A) i dobiti: 

P 

ed 

= P 

k (p - 1) (q- 

1) + 1 

k (q - 1) 

(p - 1) 

k (q- 

1) 

= P( 

P ) ≡ P( 

1) 

≡ P (mod p) 

To je, također, trivijalno ispunjeno i kada je P višekratnik od p, jer je tada: 

P ≡ 0 (mod p) 

, 

pa općenito vrijedi: 

P ≡ P (mod p) 

ed 

. 

Analogno vrijedi i za q, pa se iz (posebnog slučaja) kineskog teorema o ostatcima (prilog A) dobiva: 

ed 

P 

ed 

≡ P (mod p) 

∧ P ≡ P (mod q) 

⇔ 

ed 

P ≡ P (mod n) 

. 

Neke praktične napomene vezane za RSA kriptosustav 

Važna praktična pitanja su: 

1. Kako dobiti dva velika prosta broja p i q? 

2. Kako odabrati javni ključ e? 

3. Kako izračunati tajni ključ d? 

Odgovori mogu biti sljedeći: 

1. Budući da je teškoća faktorizacije velikih prirodnih brojeva osnova za sigurnost RSA 

kriptosustava, ne možemo faktorizacijom naći dokazivo proste brojeve p i q. Zato se nalaze 

vjerojatno prosti brojevi, npr. pomoću heurističkog ispitivanja po Miller-Rabinu (prikazano u 

prilozima A i B). Zbog sigurnosti je preporučljivo da p i q ne budu preblizu jedan drugome, da p - 

1 i q - 1 imaju barem jedan veliki prosti faktor, ali ne zajednički, jer je poželjno da p - 1 i q - 1 

nemaju velikih zajedničkih faktora. 

2. Za javni ključ e nekad se preporučivalo uzeti broj 3, ali se pokazalo da nije dobro imati jako mali 

broj e, pa se danas preporučuje staviti 2 1 65537 

16 

e = − = , što je broj koji je i pogodan za 

računanje. No, može ga se i generirati nekim (pseudo)slučajnim postupkom. 

3. Tajni ključ d može se izračunati na temelju proširenog Euklidovog algoritma (prilog A i B). 

84 

. 

.

Neke druge metode za zasnivanje kriptosustava s javnim ključem 

RSA kriptosustav spada u asimetrične kriptosustave čija je sigurnost zasnovana prvenstveno na 

teškoći faktorizacije velikih prirodnih brojeva. Drži se da je teškoća faktorizacije velikih prirodnih brojeva 

ekivalentna teškoći nalaženja "klasičnog" diskretnog logaritma, tako da su kriptosustavi koji primjenjuju 

jednu ili drugu metodu u načelu isto sigurni (kod istih veličina ključeva). Primjer poznatog kriptosustava 

koji koristi metodu "klasičnog" diskretnog logaritma je kriptosustav ElGamal, nazvan po svom autoru 

(Taher ElGamal). 

No, asimetrični kriptosustavi koji rade na temelju teškoće nalaženja diskretnog logaritma u grupi 

eliptičkih krivulja nad konačnim poljem K za istu sigurnost traže značajno manje ključeve. Takvi se 

kriptosustavi zovu kriptosustavi temeljeni na eliptičkim krivuljama (Elliptic Curve Cryptosystem, ECC). 

Procjenjuje se da su danas (oko 2010. godine) ekvivalentno sigurni RSA ključevi duljine 1369 bita i ECC 

ključevi duljine 146 bita (ECC su skoro 10 puta manji), a da će 2040. godine (zbog procijenjenog 

povećanja snage klasičnih, ne-kvantnih računala) ekvivalentno sigurni RSA i ECC ključevi biti duljine 

3214 i 191 bita (ECC su skoro 17 puta manji). To je osobito važno kod onih primjena kod kojih je prostor 

za pohranu ključeva ograničen (npr. kod pametnih kartica). Treba napomenuti da su u Java 7 uvedene 

funkcije za kriptiranje pomoću eliptičkih krivulja. 

4. KRIPTIRANJE PODATAKA U TRANZITU 

Kriptiranje podataka koji su u tranzitu nije vezano samo za baze podataka i takvo se kriptiranje 

uglavnom koristilo i prije kriptiranja podataka koji stoje u bazi. Kada je riječ o Oracle bazi, postoje rješenja 

kriptiranja podataka u tranzitu koja su vezana uz Oracle bazu, ali postoje i rješenja nezavisna od Oracle 

baze. No, obje varijante kriptiranja podataka u tranzitu imaju isti cilj, zaštiti tri vrste paketa (podataka 

baze) koji se prenose mrežom: 

1. paketi koji služe za inicijaciju sesije između klijenta i servera baze podataka; 

2. paketi koje klijent šalje bazi, uključujući SQL naredbe; 

3. paketi koje baza, kao odgovore, šalje klijentu. 

Jasno je zašto se želi zaštiti 3.vrstu paketa, jer su to podaci, a i 2.vrstu paketa, SQL naredbe, jer se 

i u njima mogu nalaziti neki tajni podaci (npr. broj kreditne kartice u SQL upitu i sl.). 

No, važno je zaštiti i 1.vrstu paketa (podaci za inicijaciju sesije), bez obzira što Oracle baza uvijek 

tokom logon procesa prenosi lozinku u kriptiranom obliku (bez obzira da li je promet mrežom kriptiran ili 

nije). Ako promet mrežom nije kriptiran, tokom postupka identifikacije/autentikacije na Oracle bazu može 

se pojaviti jedna potencijalna ranjivost. 

Postupak identifikacije/autentikacije (kod baze 11g) pojednostavljeno ide tako da klijent prvo 

pošalje bazi korisničko ime. Baza na temelju korisničkog imena potraži u sistemskim tablicama hash 

vrijednost lozinke za tog korisnika (lozinka se nikada ne sprema u Oracle bazu, pa ni kriptirana). Baza 

generira slučajni ključ za novu sesiju, taj ključ kriptira pomoću hash vrijednosti lozinke (koristeći AES 

algoritam) i šalje klijentu tako kriptirani ključ sesije. Klijent dekriptira primljeni serverski ključ sesije, 

koristeći hash vrijednost lozinke koju je korisnik unio. Zatim klijent generira vlastiti (klijentski) ključ sesije, 

te uz pomoć oba ključa sesije (serverskog i klijentskog) kriptira lozinku (koristeći AES), te ju šalje serveru, 

zajedno s kriptiranim klijentskim ključem sesije (kojega isto kriptira pomoću hash vrijednost lozinke, 

koristeći AES). Server sada može dekriptirati klijentski ključ sesije, te uz pomoć njega i svog ključa sesije 

dekriptirati primljenu lozinku, izračunati njen hash i na kraju ga usporediti sa hash vrijednošću koja je 

spremljena u bazi. Ranjivost navedenog postupka sastoji se u tome da napadač koji na neki način sazna 

hash vrijednost lozinke iz baze može, osluškujući mrežu, dekriptirati serverski i klijentski ključ sesije, te 

onda dekriptirati i lozinku. Ako je promet mrežom kriptiran, te ranjivosti nema. Naravno, može se primijetiti 

da postoji značajna ranjivost baze ako netko nepozvan može saznati hash vrijednost lozinki iz baze. 

Sam proces kriptiranja podataka u tranzitu može se raditi pomoću dva Oracle rješenja, koja se 

dobivaju samo uz opciju Advanced Security Options (ASO). Jedno je rješenje tzv. Network Data 

Encryption (NDE), a drugo se zasniva na Secure Socket Layer (SSL). Preporuča se korištenje NDE 

rješenja, jer je jednostavnije od SSL varijante. 

Osim ta dva Oracle rješenja, moguće je koristiti i nezavisna softverska ili hardverska rješenja, npr. 

različite varijante tuneliranja (jedna od njih je Secure Shell - SSH), Internet Security Protocol (IPSec), 

ili hardverske akceleratore (koji, za razliku od softverskih rješenja, ne opterećuju procesore 

klijenta/servera), npr. mrežne kartice koje podržavaju enkripciju/dekripciju. 

85

5. KRIPTIRANJE PODATAKA NA DISKOVIMA 

Kriptiranje podataka koji nisu u tranzitu, a najčešće je riječ o podacima na diskovima, postalo je 

predmet velike pažnje zadnjih 10-tak godina. Naime, bez obzira na sve druge načine osiguravanja 

podataka u bazi, vidjelo se da su jako opasni oni slučajevi u kojima se ukradu podaci na diskovima, pa 

onda napadači imaju dovoljno vremena i mogućnosti da pristupe osjetljivim podacima i kada nemaju 

direktan pristup kroz bazu podataka. Podaci iz baze podataka mogu, ako nisu kriptirani, biti relativno lako 

dostupni i van sustava za upravljanje bazom podataka, npr. može se i sa običnim uređivačem teksta 

dobiti uvid u podatke, S druge strane, nije dovoljno da budu zaštićeni samo podaci koji se direktno nalaze 

u bazi podataka, već i podaci koji su nastali npr. backup-om tih podataka. 

Poduzeća (ali i druge organizacije) danas pristupaju kriptiranju podataka na diskovima najčešće iz 

tri razloga (ili kombinacije tih razloga): 

- da bi spriječili lošu reputaciju koju dobiju nakon što se otkrije da su napadači otuđili osjetljive 

podatke; 

- da izbjegnu ili smanje financijske troškove koje imaju zbog odšteta koje su dužne nadoknaditi 

oštećenim stranama; 

- da budu u skladu s različitim regulatornim propisima o zaštiti podataka, naročito zaštiti 

privatnih podataka. 

Kriptiranju podataka na diskovima može se pristupiti na tri različita načina: 

- "ručno" kriptiranje se radi kroz aplikaciju/aplikacije, programiranjem; dobra strana takvog 

načina kriptiranja je da je vrlo fleksibilno – programiranjem se može postići manje-više sve 

što se želi; loše strane su brojne; kriptiranje kroz aplikaciju ne može se izvesti na brzinu, jer 

su aplikacije kompleksne i treba puno toga u njima mijenjati; kriptiranje uvijek pogoršava 

performanse, a kriptiranje vlastitim programiranjem najčešće je najsporije; kod kriptiranja 

vlastitim programiranjem često se zaboravi neko područje (neka aplikacija), pa onda napadač 

može iskoristiti tu slabost i kroz nju dobiti nekriptirane podatke; na kraju, najveća mana 

kriptiranja vlastitim programiranjem je da se ne može na adekvatan način zaštiti ključeve za 

kriptiranje; 

- "automatsko" kriptiranje kroz sustav za upravljanje bazom podataka; bolje je od prethodne 

varijante; SUBP sustavi danas imaju dosta napredne mogućnosti "transparentnog" kriptiranja, 

kod kojega aplikacija niti "ne zna" da su podaci kriptirani; no, za razliku od programiranja kroz 

aplikaciju, "transparentno" kriptiranje ne pomaže kod sakrivanja podataka od onih koji imaju 

pristup bazi; 

- "automatsko" kriptiranje na razini diskovnog sustava; u ovom slučaju ne kriptiraju se samo 

podaci u bazi, već svi (željeni) podaci na diskovima, bili u bazi podataka ili ne; ovaj način 

kriptiranja podataka možda je najtransparentniji (za aplikaciju) i najjednostavniji; u nastavku 

se ovaj način kriptiranja ne prikazuje, već se prikazuju samo prva dva načina kriptiranja, koja 

su vezana za bazu podataka. 

Kod kriptiranja podataka u bazi podataka, bilo programiranjem ili "automatski" kroz SUBP, postoje 

različite varijante korištenja ključeva za kriptiranje (napomena: u načelu se uvijek radi o simetričnom 

kriptiranju): 

- postoji jedan ključ za kriptiranje podataka u cijeloj bazi podataka; 

- postoji jedan ključ za svaku tablicu baze podataka (ili neki drugi dio baze podataka, npr. 

tablespace baze podataka); 

- postoji jedan ključ za svaki stupac koji se kriptira; 

- postoji jedan ključ za svaki redak koji se kriptira; 

- različite kombinacije prethodnog. 

86

Također, vrlo je važno (ako ne i najvažnije) pitanje – gdje se sprema ključ (ključevi): 

- u bazu podataka; 

- u datoteke izvan baze podataka (na serveru baze podataka, aplikacijskom serveru ili klijentu): 

- u programski kod aplikacije; iako ovo rješenje izgleda primamljivo, ono je najlošije, jer postoje 

različiti načini dekodiranja (disasembliranja) programa i dolaska do ključa koji je sakriven u 

programu. 

6. KRIPTIRANJE PODATAKA POMOĆU PAKETA DBMS_CRYPTO 

Kako je već prije navedeno, "ručno" kriptiranje (kroz aplikaciju, programiranjem) podataka u bazi 

vrlo je zahtjevno i u načelu se ne preporučuje. Traži puno vremena za izvedbu, ima najlošije 

performanse, omogućuje ostavljanje "rupa" u kriptiranju, a najveći je problem kod njega – kako upravljati 

ključevima za kriptiranje. Bez obzira na te mane, u Oracle 11g nekada se mora koristiti "ručno" kriptiranje, 

a najvažnija dva slučaja jesu: 

- na raspolaganju je samo Standard edicija baze, koja nema mogućnosti za "transparentno" 

kriptiranje (koje je dodatna opcija u Enterprise ediciji); 

- želi se kriptirati (neke) podatke i korisnicima baze - "transparentno" kriptiranje ne može sakriti 

podatke korisnicima baze. 

Za "ručno" kriptiranje koristi se paket (na bazi) DBMS_CRYPTO. 

DBMS_CRYPTO ima sljedeće mogućnosti: 

- podržava kriptografske algoritme: DES, 3DES, 3DES_2KEY, AES, RC4; ako nema nekog 

posebnog razloga, preporučljivo je koristiti algoritam AES, koji omogućava kriptiranje sa 128, 

192 ili 256-bitnim ključevima; 

- kriptografski hash algoritmi: MD5, SHA-1, MD4; 

- MAC algoritmi (algoritmi za autentikaciju poruka) HMAC_MD5, HMAC_SH1; 

- kriptografski generatori pseudoslučajnih brojeva u formatu RAW, NUMBER, 

BINARY_INTEGER; 

- kriptiranje blokova podataka: kriptiranje ulančavanjem blokova (Cipher Block Chaining, CBC) 

gdje se prethodni kriptirani blok zbraja (XOR) sa novim blokom prije kriptiranja, dvije varijante 

koje su slične prethodnom - CFB (Cipher Feedback Chaining) i OFB (Output Feedback 

Chaining), te varijanta koju bi trebalo izbjegavati – ECB (Electronic Notebook), jer kod nje isti 

ulaz uvijek daje isti izlaz, pa se na temelju statističke analize teksta može pokušati dekriptirati 

poruka; 

- ispunjavanje (padding) podataka nulama ili pomoću metode PBCS5 (preporučljivo). 

U nastavku slijedi prikaz korištenja paketa DBMS_CRYPTO, koji uključuje i usporedbu performansi 

bez / sa kriptiranjem. Prvo se radi pomoćni paket: 

create or replace package encryption_wrapper as 

function encrypt (p_string in varchar2, p_key in varchar2) 

return raw; 

function decrypt (p_raw in raw, p_key in varchar2) 

return varchar2; 

end; 

87

create or replace package body encryption_wrapper as 

g_encrypt_typ constant PLS_INTEGER default 

DBMS_CRYPTO.ENCRYPT_AES256 

+ DBMS_CRYPTO.CHAIN_CBC 

+ DBMS_CRYPTO.PAD_PKCS5; 

function padkey (p_key in varchar2) 

return raw is 

begin 

return utl_raw.cast_to_raw(rpad(p_key,32)); 

end; 

function encrypt (p_string in varchar2, p_key in varchar2) 

return raw 

is 

begin 

return 

dbms_crypto.encrypt 

(src => UTL_I18N.STRING_TO_RAW (p_string, 'AL32UTF8'), 

typ => g_encrypt_typ, 

key => padkey (p_key)); 

end; 

function decrypt (p_raw in raw, p_key in varchar2) 

return varchar2 

is 

begin 

return utl_i18n.raw_to_char ( 

dbms_crypto.decrypt 

(src => p_raw, 

typ => g_encrypt_typ, 

key => padkey (p_key)), 

'AL32UTF8'); 

end; 

end; 

Prethodni paket koristi se za kriptiranje tablice T (koristi se i pomoćna tablica STAGE, iz koje se 

puni pomoćna tablica T): 

create table stage as 

select object_name from all_objects; 

create table t ( 

last_name varchar2(30), 

encrypted_name raw(32)); -- ovaj će se stupac kriptirati 

Ovo je primjer punjenja tablice T iz tablice STAGE bez kriptiranja, metodom redak po redak, koja 

je najsporija: 

declare 

l_start number := dbms_utility.get_cpu_time; 

begin 

for x in (select object_name from stage) loop 

insert into t (last_name) values ( x.object_name ); 

end loop; 

dbms_output.put_line 

((dbms_utility.get_cpu_time - l_start) || ' hsecs' ); 

end; 

431 hsecs (= 4,31 sekundi rada CPU-a). 

88

Slijedi primjer punjenja tablice T iz tablice STAGE sa kriptiranjem: 

truncate table t; 

declare 

l_start number := dbms_utility.get_cpu_time; 

begin 

for x in (select object_name from stage) loop 

insert into t (encrypted_name) 

values ( 

encryption_wrapper.encrypt 

(x.object_name, 'Secret Key Secret Key Secret Key')); 

end loop; 

dbms_output.put_line 

((dbms_utility.get_cpu_time - l_start) || ' hsecs' ); 

end; 

2502 hsecs 

Vidi se da je INSERT sa kriptiranjem oko 6 puta sporiji od INSERT-a bez kriptiranja. Daleko veće 

razlike, na štetu kriptiranja, dobile bi se kada bi se unos podataka radio masovnom (bulk) metodom, tj. 

više redaka odjednom. Slično kao INSERT ponašaju se i UPDATE i SELECT naredbe. Jedino DELETE 

ne ovisi o (ne)kriptiranju. 

7. PROBLEMATIKA KLJUČEVA I ORACLE WALLET 

Kako je već prije navedeno, jedan od najvećih problema kod kriptiranja podataka u bazi je – gdje 

spremiti ključ(eve) za kriptiranje. Ključ se može staviti npr. u programe, ali (kako je već navedeno) 

znalcima je relativno lako doći do ključeva skrivenih u programu. Moguće ih je staviti u bazu podataka, no 

onda onaj koji ukrade bazu podataka, ukrade i ključeve. Moguće ih je staviti u datoteke izvan baze 

podataka. No onda te datoteke moraju biti kriptirane, a slijedi pitanje gdje držati ključ za kriptiranje tih 

datoteka, itd. Također, treba napomenuti da je rješenje po kojemu prije pristupa podacima korisnik (na 

neki način) predaje ključeve, vrlo nepraktično, osim ako se koristi hardverski modul za sigurnost 

(Hardware Security Module, HSM). 

Osim pitanja gdje spremiti ključ(eve), postavljaju se i neka druga praktična pitanja. Poznato je da 

ključeve za kriptiranje treba svako toliko mijenjati. No, ako imamo backup(e) podataka koji su kriptirani 

starim ključem(ključevima), onda imamo potrebu čuvanja tog starog ključa(ključeva). 

Uglavnom, vidi se da problem upravljanja ključevima za kriptiranje nije jednostavno riješiti. Oracle u 

Enterprise ediciji, sa ASO opcijom, nudi jedno rješenje koje naziva Oracle Wallet (novčanik). Wallet je 

datoteka izvan baze (zapravo, može biti više datoteka, tj. više wallet-a) koja sadrži ključeve za kriptiranje 

(i dekriptiranje, jer je riječ o simetričnim algoritmima), a sadržaj te datoteke je kriptiran lozinkom. Lozinka 

se zadaje prilikom kreiranja wallet-a, ali se može naknadno mijenjati. Prije nego se otvori baza podataka 

(iako može i kasnije), administrator baze podataka (ili netko drugi koji zna lozinku) otvori wallet, a onda 

baza podataka može koristiti ključeve koji su pohranjeni u wallet-u za kriptiranje/dekriptiranje podataka u 

bazi. Moguće je koristiti i tzv. auto-login wallet, koji se sam pokrene kod startanja baze. Iako može 

izgledati kako takav auto-login način rada nema smisla, on ima smisla u onim slučajevima kada netko 

može ukrasti podatke ali ne i server, jer auto-login način rada funkcionira samo na istovjetnom serveru na 

kojem je instaliran. Postoji i treći način korištenja wallet-a, koji je zapravo i najsigurniji, a to je da se wallet 

nalazi na posebnom HSM modulu. HSM modul, osim sigurnosti, može povećati i performanse, jer on 

može preuzeti na sebe kriptiranje/dekriptiranje podataka i time odteretititi bazu podataka. 

No, najčešći način korištenja Oracle Wallet-a je pomoću lozinke, što se u nastavku ukratko 

prikazuje. Kao prvo, u Oracle SQLNET.ORA parametarskoj datoteci mora biti zapisano gdje se wallet 

nalazi, npr.: 

ENCRYPTION_WALLET_LOCATION= 

(SOURCE=(METHOD=FILE)(METHOD_DATA= 

(DIRECTORY=/home/ora11gr2/network/admin/) 

)) 

89

Nakon toga se kreira wallet, sa: 

ALTER SYSTEM SET ENCRYPTION KEY 

IDENTIFIED BY lozinka_za_wallet; 

Kada se starta baza, nakon otvaranja baze mora se pokrenuti otvaranje wallet-a: 

ALTER SYSTEM SET ENCRYPTION WALLET OPEN 


Ako se želi privremeno zatvoriti wallet, to se može napraviti sa: 

ALTER SYSTEM SET ENCRYPTION WALLET CLOSE 


8. KRIPTIRANJE PODATAKA POMOĆU TDE COLUMN ENCRYPTION 

Kao i Oracle Wallet, i Transparent Data Encryption (TDE) Column Security se može koristiti samo u 

Enterprise ediciji baze, pri čemu je potrebna i ASO opcija. TDE Column Security služi za zaštitu 

određenih stupaca tablica podataka na disku, u slučaju da netko neovlašteno dođe do tih podataka izvan 

baze, ali su ti stupci za korisnike baze uvijek transparentno dekriptirani. Treba napomenuti da stupci nisu 

kriptirani samo u tablicama, već i REDO, UNDO i TEMP pomoćnim strukturama podataka na disku 

(naravno, i u backup podacima). 

Može se kreirati novi kriptirani stupac postojeće tablice, ili kriptirati postojeći stupac, ili kreirati 

potpuno nova tablica sa kriptiranim stupcem, što se prikazuje u nastavku: 

CREATE TABLE t ( 

c1 varchar2(30), 

c2 varchar2(30) ENCRYPT 

); 

Ako se unese redak u tu tablicu i sa SELECT pogleda sadržaj, činit će se kao da podaci nisu 

kriptirani – zato jer ih baza sama transparentno dekriptira: 

INSERT INTO t VALUES 

( '***ovo NIJE kriptirano***', '***ovo JE kriptirano***'); 

SELECT * from t; 

C1 C2 

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

***ovo NIJE kriptirano*** ***ovo JE kriptirano*** 

Ako se privremeno zatvori wallet i onda pokuša unijeti novi redak sa oba stupca, vidjet će se da se 

tada ne može unijeti kriptirani stupac, ali može se unijeti nekriptirani stupac i poslati NULL za kriptirani 

stupac (jer je kod definicije stupaca omogućena NULL vrijednost). Također, ako je wallet zatvoren ne 

može se dati SELECT nad kriptiranim stupcima, ali može nad nekriptiranim: 

ALTER SYSTEM SET ENCRYPTION WALLET CLOSE 



( '***ovo NIJE kriptirano***', '***ovo JE kriptirano***'); 

* 

ERROR at line 1: 

ORA-28365: wallet is not open 


( '***ovo NIJE kriptirano***', NULL); 

90

SELECT c2 FROM t; 

* 

ERROR at line 1: 

ORA-28365: wallet is not open 

SELECT c1 FROM t; 

C1 

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

***ovo NIJE kriptirano*** 

***ovo NIJE kriptirano*** 

Kada se navodi ključna riječ ENCRYPT, postoje tri opcije: 

- USING 'algorithm': može se birati AES ili DES enkripcija; u pravilu nema smisla koristiti stari 

DES algoritam; default je 192-bitni AES (može se birati i 128 ili 256); 

- IDENTIFIED BY password: time se može specificirati određeni ključ za enkripciju stupca (i 

isto sprema u wallet), a inače se ključ sam generira, za svaki stupac posebno; specificirani 

ključ je potreban npr. onda kada kriptirane podatke treba seliti na drugu bazu pomoću 

eksterne tablice; 

- SALT ili NO SALT: default je SALT, tj. da baza sama doda određene slučajne (random) 

bajtove na početku kriptiranih podataka; time je enkripcija jača, jer istovjetni izvorni podaci 

nisu više istovjetni nakon kriptiranja, pa je kriptoanaliza otežana; korištenje NO SALT treba 

ograničiti samo za stupce koji se indeksiraju (indeksirani stupci moraju imati uvijek iste 

kriptirane podatke za iste izvorne podatke). 

TDE Column Security nije bez mana. 

Jedna mana su smanjene perfomanse u odnosu na bazu bez kriptiranja. To smanjenje performansi 

je zavisno od toga što se radi. No, uvijek je brže od rješenja koje se može dobiti programiranjem pomoću 

paketa DBMS_CRYPTO. Jedan od razloga za gubljenje performansi je i taj što se podaci čuvaju u 

kriptiranom obliku i u memoriji, tj. u SGA strukturi baze (no, prednost toga je da netko tko bi mogao 

pristupiti tom dijelu memorije ne bi vidio smislene podatke). 

Drugo, zbog potrebe da se kriptirani podaci zaokruže na višekratnik od 16 bajtova, a i zbog 

dodavanja SALT podataka, TDE Column Security kriptiranje troši i više prostora na disku (i u SGA dijelu 

memorije). 

TDE Column Security ima i neka ograničenja: 

- ako kriptirani stupac ima indeks, taj indeks isto mora biti kriptiran (inače kriptiranje gubi 

smisao), ali onda kriptiranje ne može koristiti SALT opciju, jer indeksirani stupci moraju imati 

uvijek iste kriptirane podatke za iste izvorne podatke; 

- kriptirani indeksi se realno mogu koristiti samo za pretragu određene vrijednosti, ali ne i za 

pretragu raspona vrijednosti, jer kriptirani podaci više nemaju smisleni raspon; 

- kriptirani stupci se ne mogu koristiti za funkcijske indekse; 

- nad kriptiranim stupcima ne mogu se raditi vanjski ključevi. 

Kako će se vidjeti u nastavku, TDE Tablespace Security nema gore navedene restrikcije, 

a i performanse su generalno puno bolje u odnosu na TDE Column Security. 

91

9. KRIPTIRANJE PODATAKA POMOĆU TDE TABLESPACE ENCRYPTION 

Kao i TDE Column Security, tako se i TDE Tablespace Security može koristiti samo u Enterprise 

ediciji baze, pri čemu je potrebna i ASO opcija. TDE Tablespace Security po prvi put je uveden u Oracle 

bazi 11.1. Kako samo ime kaže, ovdje se ne kriptira samo određeni stupac, već cijeli tablespace. 

Za razliku od TDE Column Security, kod TDE Tablespace Security nije moguće kriptirati postojeću 

tablicu ili postojeći tablespace, već je potrebno kreirati novi kriptirani tablespace i onda u njega kopirati 

postojeće tablice koje želimo kriptirati. Kreiranje kriptiranog tablespace-a radi se sa: 

CREATE TABLESPACE kriptirani_tablespace 

DATAFILE ... 

ENCRYPTION DEFAULT STORAGE (ENCRYPT); 

Kao i kod TDE Column Security, i ovdje je moguće odabrati algoritam za enkripciju, a on može biti 

3DES168, AES128, AES192 ili AES256. Default je AES128, a ne AES192 kao kod TDE Column Security, 

jer je ovdje količina podataka kojae se kriptira/dekriptira puno veća - cijeli tablespace, a ne pojedini 

stupac/stupci. 

Svaka tablica koja se kreira u kriptiranom tablespace-u bit će u cijelosti kriptirana. Kriptiranje se 

radi na razini bloka tablice, a ne retka ili stupca, pa nema potrebe za zaokruživanjem podataka na 

višekratnik od 16 bajtova, jer je blok podataka sam po sebi višekratnik od 16 bajtova. Također, budući da 

je svaki blok podataka jedinstven, nije potreban SALT podatak. Rezultat je taj da TDE Tablespace 

Security ne zauzima dodatni prostor na disku. Dalje, TDE Tablespace Security kriptira podatke prije 

slanja podataka iz SGA na disk, odnosno dekriptira ih u obrnutom smjeru. To znači da su podaci u SGA u 

nekriptiranom obliku, što predstavlja potencijalnu ranjivost u slučaju da netko neovlašten može pristupiti 

SGA području (no, ta je ranjivost samo teoretska, jer takav vjerojatno lako može pristupiti i drugim 

dijelovima baze, pa i preuzeti DBA prava), ali je prednost u tome da se čitanje/upis u SGA radi brzo. 

Za razliku od podataka u SGA, podaci u REDO, UNDO i TEMP pomoćnim strukturama na disku su 

kriptirani (isto kao i kod TDE Column Security). No, treba uzeti u obzir da nakon kopiranja nekriptirane 

tablice iz nekriptiranog tablespace-a u kriptirani tablespace, te brisanja nekriptirane tablice, nije sigurno 

da više nema nekriptiranih podataka (te tablice). Naime, ti podaci ostaju određeno vrijeme u REDO, 

UNDO i TEMP pomoćnim strukturama. Naravno, ostaju i u backup-iranim podacima. 

ZAKLJUČAK 

Kriptiranje podataka važno je zbog očuvanja privatnosti, integriteta i autentičnosti poruka 

(informacija), te zbog osiguranja neporecivosti slanja poruke. 

Za kriptiranje se koriste simetrični i asimetrični kriptosustavi. Simetrični kriptosustavi su puno brži 

(oko 1000 puta), ali asimetrični kriptosustavi omogućavaju razmjenu ključeva među velikim brojem 

sudionika. 

Važno je kriptirati podatke u tranzitu, ali i podatke koji se nalaze na medijima (najčešće diskovima). 

Podatke na medijima može se kriptirati nezavisno od baze podataka, ili ih se može kriptirati unutar baze 

podataka. 

Oracle baza direktno omogućava simetrično kriptiranje. Kriptografske mogućnosti različitih edicija 

Oracle baze 11g su sljedeće: 

- Standard edicija baze ima kriptiranje pomoću paketa DBMS_CRYPTO (programiranjem); njime 

se može postići sve, pa i sakrivanje podataka od (nekih) korisnika u bazi, ali uz lošije 

performanse i uz otvoreni problem spremanja ključeva za kriptiranje; 

- Enterprise edicija sa dodatnom opcijom Advanced Security ima transparentno kriptiranje 

podataka (TDE); TDE ne služi za sakrivanje podataka od legalnih korisnika baze, već samo za 

zaštitu podataka u slučaju krađe cijelog računala ili sustava za pohranu podataka; ASO opcija 

omogućava i dvije varijante kriptiranje podataka u tranzitu - jedno je rješenje tzv. Network Data 

Encryption (NDE), a drugo se zasniva na Secure Socket Layer (SSL). 

Nažalost, značajna je razlika u cijeni između Standard edicije i Enterprise edicije sa dodatnom 

opcijom ASO. S druge strane, činjenica je da se vlastitim programiranjem u Standard ediciji vrlo teško 

može postići sigurnost ključa (ili više ključeva) koju ima skuplja varijanta. No, uvijek postoji i mogućnost 

korištenja transparentnog kriptiranja na razini diskovnog sustava. 

92

LITERATURA 

1. Bača, M. (2004): Uvod u računalnu sigurnost, Narodne novine, Zagreb 

2. Ben-Natan, R. (2009): HOWTO Secure and Audit Oracle 10g and 11g, Auerbach Publications 

3. Budin, L., Golub, M., Jakobović, D., Jelenković, L. (2010): Operacijski sustavi, Element, Zagreb 

4. Dujella, A., Maretić, M. (2007): Kriptografija, Element, Zagreb 

5. Knox, D. C. (2004): Effective Oracle Database 10g Security by Design, McGraw-Hill 

6. Kyte, T. (2009): Expert Oracle Database Architecture, Apress 

7. Mollin, R. A. (2007): An Introduction to Cryptography, Chapman & Hall/CRC (Taylor & Francis 

Group), Boca Raton 

8. Žagar, M. (2008): Otvoreno računarstvo – Sigurnost (prezentacijski materijali), FER, Zagreb 

9. Žubrinić, D. (2002): Diskretna matematika, Element, Zagreb 

Oracle priručnici za bazu 11g Release 2 (2009.): 

10. Advanced Security Administrator's Guide 

11. Database Security Guide 

12. Enterprise User Security Administrator's Guide 

93

PRILOG A: Neki matematički pojmovi vezani za RSA kriptosustav 

Djeljivost brojeva 

Neka su a, d ∈ Z. Kaže se da d dijeli a ako je a različito od 0 i ako je d višekratnik od a. Tu činjenicu 

(da d dijeli a) može se izraziti i na ove načine: 

d⎪a (d je djelitelj od a; ako d = 1 ili a, zove se trivijalni djelitelj, inače se zove faktor) 

a = k d (a je višekratnik od d). 

Relacija dijeli je refleksivna (a⎪a, tj. svaki broj dijeli sebe samoga), antisimetrična (ako su a i b 

različiti i a⎪b, ne može biti da b⎪a) i tranzitivna (ako a⎪b i b⎪c, onda a⎪c). 

Teorem dijeljenja 

Neka su zadani a ∈ Z i b ∈ N. Onda postoje jedinstveni brojevi q ∈ Z i r ∈ {0, …, b -1} takvi da je: 

a = q b + r (q je količnik ili kvocijent, r je ostatak ili reziduum). 

Činjenica da je r ostatak dijeljenja a sa b može se napisati i ovako: 

r = a mod b. 

Najveći zajednički djelitelj, relativno prosti brojevi 

Ako su a, b, d ∈ Z i vrijedi d⎪a i d⎪b tada je d zajednički djelitelj od a i b. Ako je barem jedan od 

brojeva a, b različit od nule, tada postoji njihov najveći zajednički djelitelj (najveća zajednička mjera). Da 

je d najveći zajednički djelitelj brojeva a i b, piše se ovako: 

d = nzd (a, b) (druga varijanta: d = Nzm (a, b) ). 

Ako je nzd (a, b) = 1, kaže se da su a i b relativno prosti. 

Euklidov algoritam i prošireni Euklidov algoritam 

Euklidov algoritam opisan je u Euklidovom djelu Elementi (4. stoljeće p.n.e.). Uobičajeno se koristi za 

brzo nalaženje najvećeg zajedničkog djelitelja d brojeva a i b. 

No, Euklidov algoritam daje i opis efektivnog postupka kojim se može doći do brojeva x, y, c koji 

zadovoljavaju diofantsku jednadžbu oblika: 

a x + b y = c (a i b su zadani, x, y, c se nalaze). 

Ta jednadžba ima rješenje (koje nije jednoznačno, već postoji beskonačno mnogo rješenja) ako i 

samo ako je minimalno rješenje za c jednako nzd (a, b). Tzv. prošireni Euklidov algoritam koristi se da se, 

uz nzd (a, b), nađu i brojevi x i y koji zadovoljavaju navedenu jednadžbu. 

Prosti brojevi (prim-brojevi) i osnovni teorem aritmetike 

Prosti brojevi su prirodni brojevi veći od 1 koji su djeljivi samo sa 1 i samim sobom, tj. nemaju 

faktore. Brojevi koji nisu prosti zovu se složeni brojevi (i imaju faktore). 

Osnovni teorem aritmetike kaže da se svaki prirodni broj a > 2 može prikazati na jedinstven način 

kao umnožak potencija svojih prostih djelitelja, pri čemu su prosti djelitelji poredani po veličini (manji 

lijevo): 

a = 

p 

e1 

1 

p 

e2 

2 

... p 

ek 

k 

. 

Ako je broj a složen, to se zove rastav ili faktorizacija broja a na proste faktore. 

Prostih brojeva ima beskonačno mnogo (dokaz je dat u Euklidovim Elementima). Broj prostih brojeva 

koji su manji ili jednaki broju x uobičajeno se označava sa π(x). Vrijedi: 

π(x) ∼ x / ln x, kad x →∞. 

Iz toga proizlazi da je vjerojatnost P da neki slučajno izabrani veliki broj n bude prosti: 

P (n je prosti broj) ≈ (n / ln n) / n = 1 / ln n. 

Ekvivalentnost po modulu (kongruencija po modulu) 

Kaže se da su brojevi a, b ∈ Z ekvivalenti po modulu m (ili kongruentni po modulu m, ili kongruentni 

modulo m) ako je njihova razlika djeljiva sa m, tj. ako vrijedi: 

m⎪(a – b) (ili a – b = k m). 

Tada se piše: 

a ≡ b (mod m) (čita se: a je ekvivalentan (kongruentan) b po modulu m). 

94

Može se pokazati da su tada (i samo tada) ostatci dijeljenja a sa m, odnosno b sa m jednaki: 

a ≡ b (mod m) ⇔ a mod m = b mod m. 

Relacija kongruencija po modulu m je refleksivna, simetrična i tranzitivna. 

Eulerova (phi) funkcija 

Funkcija ϕ : N → N koja prirodnom broju n pridružuje broj prirodnih brojeva koji su < n i relativno 

prosti sa n zove se Eulerova funkcija. Definira se da je ϕ(1) = 1. 

Ako je n složeni broj, koji ima rastav na proste faktore ,..., , p p p može se pokazati da je: 

( 1 1/ 

) ( 1 1/ 

) ... ( 1 1/ 

). p 

p p − − 

( ) 

2 

n n − 

= ϕ 

1 k 

1, 2 k 

Posebno za slučaj kada je n umnožak dva prosta broja p i q (n = p q), vrijedi: 

ϕ(n) = n (1 – 1/ p) (1 – 1/ q) = p q (1 – 1/ p) (1 – 1/ q) = (p – 1) (q – 1). 

Posebno za slučaj kada je n prosti broj p, vrijedi 

ϕ(p) = p – 1. 

Eulerova kongruencija (teorem) 

Ako su a i n relativno prosti prirodni brojevi, onda je: 

( ) 

a 1 

n ϕ 

≡ 

( mod n). 

Mali Fermatov teorem 

Za poseban slučaj Eulerove kongruencije kada je n prosti broj p, pa je ϕ(p) = p – 1, vrijedi: 

− 

(za svaki a ∈ N koji nije višekratnik od p). 

a p 1 

≡ 

1 

( mod p) 

Drugi oblik Fermatova teorema vrijedi i ako je a višekratnik od p: 

a a p 

p 

≡ mod (za svaki a ∈ N). 

( ) 

Pseudoprosti brojevi 

Mali Fermatov teorem može poslužiti (i) kada se treba generirati slučajni veliki broj za koji se sa 

velikom vjerojatnošću može tvrditi da je prosti broj (ako je generirani broj mali, lako se može dokazati da li 

je prosti, postupkom rastava na proste faktore; no, rastav velikih brojeva na proste faktore je složen i na 

teškoći tog rastava se i zasniva RSA algoritam). 

Generira se slučajni veliki neparni broj n i gleda se da li taj broj zadovoljava mali Fermatov teorem za 

neki slučajno odabrani broj a (koji može biti relativno mali), tj. gleda se da li vrijedi: 

a a n 

n 

≡ mod . 

( ) 

Ako gornje ne vrijedi, n sigurno nije prosti broj. Tada se može tražiti dalje, u okolini broja n (npr. tako 

da se n poveća za 2, jer nijedan paran broj osim 2 nije prosti). 

Ako gornje vrijedi, to ne znači da je n sigurno prosti broj! Naime, postoje i pseudoprosti brojevi, za 

koje isto vrijedi mali Fermatov teorem za neke baze a. Može se pokazati da za svaku bazu a ≥ 2 postoji 

čak beskonačno mnogo pseudoprostih brojeva. Zbog toga se testiranje prostosti ne radi samo s jednom 

bazom a, nego se generira veći broj baza (što veći broj baza, to je veća vjerojatnost da je izabrani broj n 

prosti). Ako provjere sa svim bazama zadovoljavaju mali Fermatov teorem, velika je vjerojatnost da je broj 

n prosti. Nažalost, postoje i posebni pseudoprosti brojevi, zvani Charmichaelovi brojevi. 

95

Charmichaelovi brojevi i heurističko ispitivanje po Miller-Rabinu 

Charmichaelovi brojevi su brojevi koji su pseudoprosti u svakoj bazi a, tj. vrijedi: 

a a C 

C 

≡ mod za svaki a (C je ovdje oznaka za Charmichaelov broj), 

( ) 

odnosno vrijedi: 

a C 

1 - C 

≡ 1 mod za svaki a koji je relativno prost sa Charmichaelovim brojem. 

( ) 

Korseltov kriterij kaže da je n Carmichaelov ako i samo ako je n složen, kvadratno slobodan (što 

znači da je 1 najveći kvadrat koji dijeli n, odnosno eksponenti svih prostih faktora od n su jednaki 1) i za 

svaki prosti faktor p od n vrijedi da p – 1 dijeli n – 1. Može se pokazati da odavde neposredno slijedi da n 

mora biti produkt od barem tri različita prosta broja. 

Zbog toga što postoje Carmichaelovi brojevi, testiranje prostosti sa različitim bazama a ne može biti 

dovoljno sigurno. Naime, ako se slučajno naiđe na Carmichaelov broj (istina, vjerojatnost za to je mala, 

jer iako Carmichaelovih brojeva ima beskonačno mnogo, oni su puno rjeđi od prostih brojeva), onda će 

testiranje broja C (Carmichaelov broj) u svakoj bazi a pokazati da je zadovoljen Fermatov teorem. 

Zbog toga se, osim testiranja na Fermatov teorem sa različitim bazama, radi još jedno testiranje. 

Gleda se da li za generirani broj n postoji x različit od +1 i –1 koji zadovoljava jednadžbu: 

x n 

2 

≡ 1 mod 

(x je različito od +1 i –1). 

( ) 

Ako postoji takav x, tada se kaže da je x netrivijalni drugi korijen od 1 mod n i tada je n sigurno 

složen broj. U suprotnom je n možda prosti broj (nije sigurno). 

Heurističko ispitivanje po Miller-Rabinu zasniva se upravo na navedena dva testa, tj. generirani broj 

n je sigurno složen ako: 

- za neku odabranu bazu a (u više iteracija) nije zadovoljen Fermatov teorem 

- ili postoji netrivijalni drugi korijen od (1 mod n). 

U suprotnom se sa velikom vjerojatnošću može tvrditi da je generirani broj n prosti. 

Kineski teorem o ostatcima 

Kineski teorem o ostacima (engl. Chinese Remainder Theorem - CRT) govori o rješenju sustava 

linearnih kongruencija. Ime mu se vezuje uz kineskog matematičara iz prvog stoljeća Sun Tzua. 

Neka su r m m m ,..., , 1 2 u parovima relativno prosti prirodni brojevi, te neka su r a a a ,..., , 1 2 cijeli 

brojevi. Tada sustav kongruencija: 

( m ) , x ≡ a ( mod m ) , ..., x ≡ a ( m ) 

x ≡ a 

mod 

1 

ima rješenja. 

mod 1 

2 

Ako je x 0 jedno rješenje, onda su sva rješenja dana sa: 

x ≡ 

x 

( m m ... m ). 

0 mod 1 2 r 

Za poseban slučaj, kada su p i q prosti i kada su svi ai jednaki a, vrijedi: 

x ≡ a (mod p) ∧ x ≡ a (mod q) ⇔ x ≡ a (mod p q) 

što se može koristiti u dokazu korektnosti RSA algoritma. 

2 

96 

r 

r

PRILOG B: Implementacija RSA kriptosustava 

Implementacija (u Oracle Forms razvojnom alatu) koja se prikazuje ne služi za realne svrhe, već 

samo za prezentaciju RSA kriptosustava. Implementacija radi samo s porukama koje su prirodni brojevi 

manji od broja n. Također, generirani ključevi su relativno mali, iako se mogu povećavati mijenjanjem 

odgovarajućih konstanti u programu (do granica koje dopušta Forms razvojni alat). 

Korisničko sučelje programa izgleda ovako (s primjerom podataka): 

Jedino polje koje je unosivo je Izvorna poruka, a ostala polja služe samo za prikaz odgovarajućih 

podataka. Funkcije tri gumba su sljedeće: 

Kriptiraj i dekriptiraj: 

- ako je Izvorna poruka prazna, javlja odgovarajuću grešku; 

- inače gleda da li su ključevi već generirani (ako nisu, generira ih); 

- kriptira i dekriptira izvornu poruku i prikazuje rezultat na lijevoj strani; 

- Status sada može biti: 

"Kriptiranje / dekriptiranje završeno!" 

ili 

"GREŠKA u kriptiranju/dekriptiranju - izvorna poruka je >= n!" 

ili 

"NEPOZNATA GREŠKA u kriptiranju/dekriptiranju!" 

(u slučaju programske greške, ili zbog ograničenja razvojnog sustava). 

Generiraj nove ključeve: 

- briše polja Kriptirana poruka i Dekriptirana poruka (polje Izvorna poruka ne briše); 

- generira nove ključeve; 

- prikazuje podatke na desnoj strani ekrana (maske); 

- ispisuje u polje Status poruku "Generirani novi ključevi!" . 

Izađi: izlaz iz programa. 

U nastavku se prikazuje programski kod s kratkim opisom (programski kod je komentiran). 

97

Procedura generiraj_nove_kljuceve poziva se iz istoimenog gumba i radi sljedeće: 

PROCEDURE generiraj_nove_kljuceve IS 

p INTEGER; q INTEGER; n INTEGER; phi INTEGER; 

e INTEGER; d INTEGER; k INTEGER; 

BEGIN 

/* Prvo se nalazi prosti broj p, u zadanom rasponu */ 

p := prosti_broj (konstante.min_prosti_broj_k, 

konstante.max_prosti_broj_k); 

/* 

Traži se prosti broj q, takav da je 

razlika između p i q >= zadanoj minimalnoj razlici 

i da je nzd (p - 1, q - 1) konstante.max_nzd_p_minus_1_q_minus_1_k 

LOOP 

q := prosti_broj (konstante.min_prosti_broj_k, 

konstante.max_prosti_broj_k); 

END LOOP; 

/* Računaju se n i phi */ 

n := p * q; 

phi := (p - 1) * (q - 1); 

/* Računa se e, relativno prost sa phi */ 

e := vrati_e (phi); 

/* Nalaze se k i d, takvi da je e * d = k * phi + 1 */ 

izracunaj_d_k (phi, e, d, k); 

/* Prikaz podataka */ 

:p := p; 

:q := q; 

:n := n; 

:phi := phi; 

:k := k; 

:k_puta_phi_plus_1 := k * phi + 1; 

:e := e; 

:d := d; 

:e_puta_d := e * d; 

END; 

Konstante koje se koriste u programu nalaze se na jednom mjestu (specifikaciji paketa): 

PACKAGE konstante IS 

/* 

Koliko puta se heurističkom metodom provjerava 

da li je generirani broj prost 

*/ 

broj_provjera_prostosti_k CONSTANT INTEGER := 10; 

/* Granice za generiranje prostih brojeva p i q */ 

min_prosti_broj_k CONSTANT INTEGER := 10**9; 

max_prosti_broj_k CONSTANT INTEGER := 10**10; 

98

* 

Minimalna razlika između generiranih prostih brojeva p i q. 

Ako je razlika malena, lakša je kriptoanaliza RSA algoritma. 

*/ 

min_razlika_izmedu_p_q_k CONSTANT INTEGER := 1000; 

/* 

Maksimalni najveći zajednički djelitelj od (p - 1) i (q - 1). 

Ako je nzd (p - 1, q - 1) velik, 

lakša je kriptoanaliza RSA algoritma. 

*/ 

max_nzd_p_minus_1_q_minus_1_k CONSTANT INTEGER := 100; 

/* 

Granice za generiranje broja koji će biti 

početni broj za generiranje broja e. 

Napomena: e ne mora biti prosti broj, 

već mora biti relativno prost sa phi. 

*/ 

e_pocetni_min_k CONSTANT INTEGER := 1000; 

e_pocetni_max_k CONSTANT INTEGER := 10000; 

END; 

Funkcija prosti_broj vraća (vjerojatni, ne dokazani) prosti broj u zadanom rasponu: 

FUNCTION prosti_broj (min_p INTEGER, max_p INTEGER) 

RETURN INTEGER 

/* Vraća prosti broj, u zadanim granicama */ 

IS 

broj INTEGER; 

BEGIN 

/* 

Prvo se generira slučajni broj u zadanim granicama. 

Ako nije paran, povećava se za 1. 

U petlji se provjerava da li je prost. 

*/ 

broj := slucajni_broj (min_p, max_p); 

IF broj MOD 2 = 0 THEN 

broj := broj + 1; 

END IF; 

WHILE slozen_broj (broj) LOOP 

/* 

Početni broj je prost, nije 2, pa je neparan. 

Zbog toga se e može u iteraciji povećavati za 2. 

*/ 

broj := broj + 2; 

IF broj > max_p THEN 

broj := min_p; 

END IF; 

END LOOP; 

RETURN broj; 

END; 

99

Funkcija slucajni_broj vraća slučajni broj u zadanom rasponu: 

FUNCTION slucajni_broj (min_p INTEGER, max_p INTEGER) 


/* Generira slučajni cijeli broj od min do max (uključujući) */ 

IS 

broj INTEGER; 

BEGIN 

/* 

DBMS_RANDOM.VALUE (min_p, max_p) vraća decimalnu vrijednost 

između min_p, uključujući, i max_p, isključujući. 

Zato se računa DBMS_RANDOM.VALUE (min_p, max_p + 1). 

Vraća se u cijeli broj. 

*/ 

broj := DBMS_RANDOM.VALUE (min_p, max_p + 1); 

RETURN broj; 

END; 

Funkcija slozen_broj vraća TRUE ako je broj sigurno složen, a FALSE ako je vjerojatno prosti broj. Ona 

višekratno poziva funkciju slozen_jednokratna_provjera. Obje zajedno implementiraju heurističko 

ispitivanje po Miller-Rabinu: 

FUNCTION slozen_broj (broj INTEGER) RETURN BOOLEAN IS 

slozen BOOLEAN := FALSE; 

i INTEGER := konstante.broj_provjera_prostosti_k; 

pom INTEGER; 

BEGIN 

WHILE i > 0 AND NOT slozen LOOP 

/* Slučajno se generira broj između 1 i (broj - 1) */ 

pom := slucajni_broj (1, broj - 1); 

slozen := slozen_jednokratna_provjera (pom, broj); 

i := i - 1; 

END LOOP; 

/* 

Ako je slozen = TRUE, onda je sigurno složen. 

Inače je prost, vrlo vjerojatno. 

*/ 

RETURN slozen; 

END; 

100

FUNCTION slozen_jednokratna_provjera (pom INTEGER, broj INTEGER) 

RETURN BOOLEAN 

IS 

TYPE binarna_tablica_t IS TABLE OF INTEGER 

INDEX BY BINARY_INTEGER; 

slozen BOOLEAN := FALSE; 

c INTEGER; 

c_binarno binarna_tablica_t; 

i INTEGER; 

d INTEGER; 

d_s INTEGER; 

BEGIN 

c := broj - 1; 

/* 

Prvo se c pretvara u binarni oblik, 

tako da se sprema u niz (tablicu) c_binarno 

čiji je prvi element najmanja binarna znamenka, 

a zadnji element najveća. 

*/ 

i := 0; 

WHILE c > 0 LOOP 

i := i + 1; 

c_binarno(i) := c MOD 2; 

c := FLOOR (c / 2); 

END LOOP; 

d := 1; 

WHILE i > 0 AND NOT slozen LOOP 

d_s := d; 

d := (d * d) MOD broj; 

IF d = 1 AND d_s 1 AND d_s (broj – 1) THEN 

slozen := TRUE; 

END IF; 

IF c_binarno(i) = 1 THEN 

d := (d * pom) MOD broj; 

END IF; 

i := i - 1; 

END LOOP; 

IF i = 0 AND d 1 THEN 

slozen := TRUE; 

END IF; 

RETURN slozen; 

END; 

101

Funkcija vrati_e računa javni ključ e: 

FUNCTION vrati_e (phi INTEGER) RETURN INTEGER 

/* Računa e, relativno prost u odnosu na phi i manji od njega */ 

IS 

e INTEGER; 

BEGIN 

/* 

Prvo se generira slučajni broj u zadanim granicama. 

Ako nije paran, povećava se za 1. 

U petlji se provjerava se da li je relativno prost sa phi. 

*/ 

e := slucajni_broj (konstante.e_pocetni_min_k, 

konstante.e_pocetni_max_k); 

IF e MOD 2 = 0 THEN 

e := e + 1; 

END IF; 

WHILE nzd (phi, e) 1 LOOP 

/* 

phi = (p - 1) * (q - 1). 

p i q su veliki prosti brojevi, tj. neparni. 

Dakle, phi je paran, pa e ne može biti paran, 

ako će biti relativno prost u odnosu na phi. 

Početni e je neparan. 

Zbog toga se e može u iteraciji povećavati za 2. 

*/ 

e := e + 2; 

/* Ako dođemo do phi, vraćamo se na donju granicu */ 

IF e >= phi THEN 

e := konstante.e_pocetni_min_k; 

IF e MOD 2 = 0 THEN 

e := e + 1; 

END IF; 

END IF; 

END LOOP; 

RETURN e; 

END; 

102

Funkcija nzd vraća najveći zajednički djelitelj dva broja (koristeći Euklidov algoritam), a procedura 

izracunaj_d_k računa tajni ključ d i k, pozivajući proceduru za prošireni Euklidov algoritam: 

FUNCTION nzd (x INTEGER, y INTEGER)RETURN INTEGER IS 

a INTEGER := x; 

b INTEGER := y; 

t INTEGER; 

BEGIN 

WHILE b > 0 LOOP 

t := b; 

b := a MOD b; 

a := t; 

END LOOP; 

RETURN a; 

END; 

PROCEDURE izracunaj_d_k ( 

phi INTEGER, e INTEGER, 

d OUT INTEGER, k OUT INTEGER) 

IS 

nzd_pom INTEGER; 

minus_k INTEGER; 

BEGIN 

/* 

Pomoću proširenog Euklidovog algoritma nalaze se d i minus_k, 

takvi da je e * d + phi * minus_k = nzd (e, phi). 

Pritom je, specifično, nzd (e, phi) = 1 

(jer su e i phi relativno prosti). 

*/ 

prosireni_Euklidov_algoritam (e, d, phi, minus_k, nzd_pom); 

/* 

d bi mogao ispasti negativan, 

pa se d i minus_k povećavaju, dok d ne bude pozitivan 

*/ 

WHILE d

Procedura prosireni_Euklidov_algoritam općenito nalazi x i y u diofantskoj jednadžbi koja ima oblik a x 

+ b y = c, a vraća i c, koji je zapravo nzd (a, b). U konkretnom slučaju procedura izracunaj_d_k šalje ovoj 

proceduri e i phi kao parametre a i b, a u povratu od nje dobiva d i –k (dobiva i nzd (e, phi), ali je on po 

definiciji jednak 1, jer e i phi moraju biti relativno prosti): 

PROCEDURE prosireni_Euklidov_algoritam ( 

a INTEGER, x OUT INTEGER, 

b INTEGER, y OUT INTEGER, g OUT INTEGER 

) 

/* vraća x, y i g takve da a * x + b * y = nzd (a, b) */ 

IS 

u INTEGER; 

v INTEGER; 

w INTEGER; 

q INTEGER; 

xt INTEGER; 

yt INTEGER; 

gt INTEGER; 

ut INTEGER; 

vt INTEGER; 

wt INTEGER; 

BEGIN 

x := 1; 

y := 0; 

g := a; 

u := 0; 

v := 1; 

w := b; 

WHILE w > 0 LOOP 

q := FLOOR (g / w); 

/* Pamtimo stare vrijednosti */ 

xt := x; 

yt := y; 

gt := g; 

ut := u; 

vt := v; 

wt := w; 

/* Nove vrijednosti */ 

x := ut; 

y := vt; 

g := wt; 

u := xt - q * ut; 

v := yt - q * vt; 

w := gt - q * wt; 

END LOOP; 

END; 

104

Procedura kriptiraj_i_dekriptiraj se poziva iz istoimenog gumba. Ona samo poziva funkcije 

kriptirana_poruka i dekriptirana_poruka, koje pozivaju funkciju modulo_potencije. Funkcija 

modulo_potencije služi za brzo modularno potenciranje: 

PROCEDURE kriptiraj_i_dekriptiraj 

(izvorna_poruka INTEGER, n INTEGER, e INTEGER, d INTEGER) 

IS 

kp INTEGER; 

dp INTEGER; 

BEGIN 

kp := kriptirana_poruka (izvorna_poruka, e, n); 

dp := dekriptirana_poruka (kp, d, n); 

/* prikaz podataka */ 

:kriptirana_poruka := kp; 

:dekriptirana_poruka := dp; 

END; 

FUNCTION kriptirana_poruka 

(izvorna_poruka INTEGER, e INTEGER, n INTEGER) 


IS 

BEGIN 

RETURN modulo_potencije (izvorna_poruka, e, n); 

END; 

FUNCTION dekriptirana_poruka 

(kriptirana_poruka INTEGER, d INTEGER, n INTEGER) 


IS 

BEGIN 

RETURN modulo_potencije (kriptirana_poruka, d, n); 

END; 

105

FUNCTION modulo_potencije 

(baza INTEGER, potencija INTEGER, modulo INTEGER) 


IS 

TYPE binarna_tablica_t IS TABLE OF INTEGER 

INDEX BY BINARY_INTEGER; 

potencija_binarno binarna_tablica_t; 

pom INTEGER; 

i INTEGER; 

rezultat INTEGER; 

BEGIN 

/* 

Prvo se potencija pretvara u binarni oblik, 

tako da se sprema u niz (tablicu) potencija_binarno 

čiji je prvi element najmanja binarna znamenka, 

a zadnji element najveća. 

*/ 

pom := potencija; 

i := 0; 

WHILE pom > 0 LOOP 

i := i + 1; 

potencija_binarno(i) := pom MOD 2; 

pom := FLOOR (pom / 2); 

END LOOP; 

/* 

Sada se niz (tablica) potencija_binarno 

koristi za nalaženje modula potencije, 

kao da radimo (baza ** potencija) MOD modulo. 

*/ 

rezultat := 1; 

WHILE i > 0 LOOP 

rezultat := MOD (rezultat * rezultat, modulo); 

IF potencija_binarno(i) = 1 THEN 

rezultat := (rezultat * baza) MOD modulo; 

END IF; 

i := i - 1; 

END LOOP; 

RETURN rezultat; 

END; 

106

IAS ZA MNOGO KORISNIKA: SAMO JEDAN ILI VIŠE NJIH NA VIRTUALNIM 

STROJEVIMA 

IAS FOR A LARGE NUMBER OF USERS: ONE INSTALLATION OR MORE ON 

VIRTUAL MACHINES 

Dubravko Miljković 

HEP-SIT, Vukovarska 37, Zagreb 

Mob: 098 9825602 

E-mail: dubravko.miljkovic@hep.hr 

SAŽETAK 

Virtualni strojevi (VMWare i Hyper-V) omogućuju instalaciju više iAS-a na istom poslužitelju. 

Često je mišljenje da iAS može opsluživati samo oko 70-80 korisnika, a da je iznad tog broja potrebna 

zasebna nova instalacija. Uzrok leži u pogrešnom prikazu zauzeća memorije po korisniku i 

interpretaciji memorijskih parametara Task Managera, precijenjenoj procjeni potrebne memorije za 

određen broj korisnika te nekonfiguriranju memory heap size parametra na operacijskom sustavu. 

Stoga se u zadnje vrijeme instalira nekoliko iAS-a kao virtualni strojevi na istom poslužitelju na koji je 

ugrađena dodatna RAM memorija. Međutim, veliki broj korisnika i dobri rezultati mogu se postići 

pravilnom konfiguracijom samo jednog iAS-a na jednom poslužitelju. 

ABSTRACT 

Virtual machines (VMWare and Hyper-V) make it possible to install several iAS on the same 

server. It is frequent misconception that iAS can serve only 70-80 users, and after that one needs 

another installation. Reason for this comes from incorrect reading of memory consumed by user and 

interpretation of memory parameters in Task Manager, incorrect estimate of necessary memory for 

particular number of users obtained by linear extrapolation, not configuring memory heap size 

parameter on OS as well as a choice of OS. As a consequence in recent time there is growing number 

of multiple installations of iAS on several virtual machines on a server. However, good results can be 

achieved with careful configuration of just one iAS on one server. 

1. UVOD 

Ovdje rad je ograničen na korisnike Forms/Reports aplikacija (što je najčešći slučaj) na iAS 10g 

instaliranom na Windows operacijskom sustavu. Out-of-the box instalacija podržava oko 70-80 

korisnika. Kad se broj korisnika dostigne prethodni limit ne mogu se uspostaviti nove sesije, dobiva 

poruku FRM-92101 (na starom iAS 1.02 FRM-92050), [1, 2], a OS javlja poruku Out-of-Memory, [3, 4]. 

Administrator ubrzo pokrene task manager i vidi da pojedinačna Forms sesija troši oko 15 MB ili 

više, pomnoži to sa brojem korisnika, pogleda Page File Usage i vrlo brzo zaključi da postojeći stroj 

nema više dovoljno raspoložive memorije. Međutim tu se obično kombinira nekoliko grešaka: 

1. Poruka Out-of-memory se ne odnosi na raspoloživ RAM, nego samo na Windows nondesktop 

heap size 

2. Ako pojedina sesija troši 15 MB to ne znači da će N korisnika potrošiti N x 15 MB RAM-a 

3. Ono što se očita kao Page File Usage je Total Commit Charge, sustav je obično još jako 

daleko od swap-anja 

4. Maksimalan broj istovremenih konekcija (ne korisnika) od strane klijenata ka Apache HTTP 

serveru treba se konfigurirati u httpd.conf datoteci 

Sama instalacija iAS-a inicijalno podržava oko 70-80 korisnika. Pri tome nakon instalacije treba 

podesiti samo osnovne postavke kao što su formsweb.cfg, *.env, .ora datoteke, NLS Lang, 

embeded pdf fontove i iAS je praktički spreman za uporabu. Ukoliko želimo da iAS opslužuje još veći 

broj korisnika potrebno je obaviti još neke konfiguracije. Nažalost one nisu uvijek detaljno i jasno 

opisane u osnovnim Oracle priručnicima za iAS. Stoga većina instalacija ima konfiguracijske 

parametre kakvi se dobiju samom instalacijom. 

107

Slika 1 Poruka koju dobije korisnik kad je rezerviran premali nondesktop heap size 

2. VIRTUALNI STROJEVI KAO MOGUĆE RJEŠENJE 

Ne znajući ili ne želeći se opterećivati za dodatne konfiguracije, a želeći uslužiti veći broj korisnika, 

neki traže spas u virtualnim strojevima. Kad se već misli da smo ograničeni na 70-80 korisnika po iASu, 

hajdemo ih instalirati više. Ali to znači više servera, a potrošnja CPU-a je (dok se ne pokreću 

zahtjevni reporti) uglavnom zanemariva. Pa pokušajmo onda s virtualnim strojevima. Podignimo ih 

nekoliko na jednom fizičkom serveru i na svakom virtualnom stroju podignimo OS, a na njemu iAS. 

Ako na jednom fizičkom serveru podignemo na taj način četiri iAS-a, popeli smo se do oko 300 

korisnika. U svakom slučaju puno više nego 70-80 korisnika. 

Slika 2 Aplikacija na fizičkom serveru i virtualizacija 

108

Slika 3 Virtualizacija s VMWare ESX 

Slika 4 Virtualizacija s Hyper-V Server 2008 

Sama virtualizacija donosi određeni memorijski i CPU overhead. Memorijski footprint je relativno 

mali i iznosi (ovisno o varijanti) nekoliko desetaka MB. Isto važi za CPU, overhead je reda nekoliko 

posto. Međutim na svakom virtualnom stroju instaliran je OS i iAS što zauzima oko 700 MB po stroju. 

To znači da kad imamo četiri virtualna stroja na Windows OS-ove, iAS-e i VM footprint potrošili smo 

oko 3 GB. Dakle, takva instalacija mora odmah započeti s bar 6 GB (u stvarnosti 8 GB) RAM-a na 

fizičkom serveru. Isto tako na svakom iAS-u instaliranom na VM treba podignuti sve reports servere 

koje aplikacije koriste. 

Sam ESX Server je besplatan osim ako se žele koristiti napredne funkcije podrške. Međutim 

svaka odvojena instalacija operacijskog sustava Windows se posebno plaća. 

Hyper-V postoji u dvije varijante: kao samostalni besplatan proizvod zvan Microsoft Hyper-V 

Server 2008 i kao role koje se instaliraju na Windows Server 2008 i Windows Server 2008 R2. 

Tu je u boljoj poziciji Hyper-V koji kad se instalira kao rola na Windows Server 2008 omogućuje 

četiri besplatna Windows Sjever 2008 OS-a na virtualnim strojevima (premda nam treba Windows 

2003 Server, ali to se da riješiti snalažljivošću). 

Što se tiče licenciranja Oracle iAS-a tu nema bitne razlike jer se licenciranje obavlja po broju 

CPU-a. Značajno veće troškove bi imala varijanta s virtualnim strojevima ako bi se koristile napredne 

funkcije virtualizacije koje omogućavaju migraciju virtualnih strojeva na druge fizičke server jer bi 

trebalo licencirati sve CPU-e (osim u slučaju korištenja Oracle VM). 

Kod primjene virtualnih strojeva treba još riješiti raspodjelu (balansiranje) prometa između 

pojedinih strojeva, [5, 6]. Isto tako, ako želimo da takvo rješenje ima i visoku raspoloživost, a ne samo 

kapacitet, treba osigurati mehanizam provjere ispravnosti funkcija iAS-a na svakom virtualnom stroju 

(da u clusteru ne bi bio uključen neispravan iAS). Sve ovo dalje ponešto komplicira rješenje s više 

virtualnih strojeva. 

U ovom radu želi se ukazati da za velika opterećenja nije potrebno koristiti virtualne strojeve s 

odvojenim instalacijama iAS-a već jedan dobro konfiguriran iAS na klasičnom operacijskom sustavu 

na jednom fizičkom serveru. Stoga će kroz slijedeća poglavlja biti dotaknuti problemi čije 

razumijevanje omogućuje korektnu konfiguraciju navedene instalacije. 

3. UPORABA MEMORIJE iAS-a 

Opisat ćemo korištenje memorije od strane Forms aplikacija, jer se tu obično griješi u procjeni. 

Pojedinačni reports serveri također koriste otprilike 10-60 MB (ovisno o broju engine-a i opterećenju). 

3.1. Skalabilnost formi 

Ako pokrenemo neku srednje složenu aplikaciju i u task manager-u promatramo zauzeće 

memorije od strane Forms (frmweb.exe) procesa. 

Kad bi imali na raspolaganju stress tester (dosta skupa sprava) postepenim opterećivanjem iAS-a 

s korisnicima došli bi do zanimljivih rezultata (Windows heap size mora za veća opterećenja biti 

korektno konfiguriran u Windows registry key-u): 

109

Npr. ako sustav ima slobodno 1 GB RAM-a i jedna sesija koristi 15 MB lako bi pogrešno zaključili 

da iAS može podržati 68 korisnika. Kada bi sustav bio opterećen s oko 50 korisnika ako bi pogledali 

iskorišten i slobodan RAM došli bi do zaključka da jedna sesija koristi oko 6.2 MB. Ako je tako onda 

možda iAS s 1 GB RAM-a izdrži oko 165 korisnika?! Idemo dalje, opteretimo iAS s 1 GB slobodnog 

RAM-a do kraja, kada performanse (u smislu vremena odziva – response time) počinju drastično 

padati i kod oko 350 korisnika možemo zaključiti da jedna sesija koristi samo oko 2.8 MB RAM-a!!! 

3.2. Pokazivanje task manager-a i ugrađeno optimiziranje korištenja memorije Forms 

procesa 

Jednostavno mjerenja zauzeća memorije putem task managera ne daje korektan rezultat. Vrlo 

često OS nije oslobodio prethodno angažiranu memoriju od frmweb procesa ili još nije osvježio interne 

tablice. No značajnije je to što Oracle u optimiziranje korištenja memorije od strane Forms procesa 

uložio puno truda i zbog načina korištenja memorije na temelju potrošnje memorije od strane jednog ili 

dva Forms proces ne može se jednostavno ekstrapolirati potrošnja memorije za znatno veći broj 

korisnika, [7, 8, 9]. Ako task manager pokazuje da je proces koristi 15 MB, proces može stvarno 

koristiti recimo samo 5 MB, a ostatak je proces rezervirao anticipirajući buduće potrebe. 

Osim toga Oracle Forms procesi su sposobni dijeliti izvršni kod i aplikacijski image. Ako stotine 

korisnika otvore istu formu postoji puno zajedničkih objekata u memoriji. Čak ako su istovremeno 

otvorne različite forme u memoriji nalazi se još punu objekata koji dijele mogu dijeliti memorijske 

resurse.Štoviše, kad je forma završila s radom, memorija koju je zauzimala ne mora se osloboditi 

odmah. Naime alociranje memorije je relativno skup postupak koji se često ne obavlja sve dok to nije 

apsolutno potrebno osloboditi zauzetu memoriju. 

Korištenje zajedničkih resursa naglašenije je kod uporabe jedne aplikacije nego kod „portfelja“ 

aplikacija (puno različitih aplikacija na istom iAS-u), ali uštede su uvijek velike. 

Sad uviđamo da potrošnja memorije za veliki broj korisnika ne može se odrediti jednostavnom 

linearnom ekstrapolacijom očitane potrošnje memorije za jednog korisnika. Memorija sustava u biti 

nije problem. Sa oko 1 GB (samo za forms procese) možemo opslužiti 300 korisnika, sa 2 GB (opet 

samo za forms procese) još puno više. U biti memorija nije usko grlo za iole normalan broj korisnika 

(recimo ispod 500-600 – da li ih stvarno želimo još više na jednom fizičkom serveru?). 

Za ilustraciju evo i rezultata „memory bound“ testa koji je proveo Oracle na serverima Sun 450R 

sa Solaris 2.8 OS i ukupno 1 GB i 2 GB memorije, dakle ne 1 GB memorije za forms procese nego 

ukupno Solaris OS - 94 GB, iAS – 150 GB i forms procesi. Radi cjelovitosti preneseni su rezultati i 

Memory bound testa i CPU bound testa (četiri 450 MHz CPU, programski upravljan broj procesora), 

relativno moderan server za to vrijeme (2000. godina), [7, 8] 

Slika 5 „Memory bound test“ rezultati za server s ukupno 1 GB i 2 GB memorije 

110

Slika 6 „CPU bound test“ “ rezultati za server s ukupno 1 i 2 CPU-a 

Ove slike ilustriraju da velik broj korisnika na jednom fizičkom stroju nisu fantazija. 

4. KORIŠTENJE MEMORIJE KOD WINDOWS OS-a 

4.1. Uobičajena ograničenja kod 32-bitnih Windows OS-a 

Kratko ćemo opisati kako Windows OS koristi memoriju. Windows Server 2003 Standard Edition 

ima limit od 4 GB fizičkog RAM-a. Čak ni tih 4 GB RAMA-a ne može se potpuno iskoristiti zbog 

prostora rezerviranog za video memoriju i razne periferne uređaje (npr. DMA za hard disk). 

Slika 7 Default-na raspodjela memorije između privatnih procesa i kernela 

U default-noj Windows konfiguraciji 2 GB virtualnog adresnog prostora je određeno za privatno 

korištenje svakog procesa, a ostalih 2 GB se dijeli između svih procesa i operacijskog sustava, [10]. 

Pri tome najveće zauzeće memorije od pojedinog privatnog procesa može biti do 2 GB, a suma 

zauzeća memorije od svih privatnih procesa opet mora stati unutar 2 GB. 

111

4.2. Memorijski switch-evi 

• /3GB Switch 

Ako nam za privatne proces stvarno treba više od 2 GB RAM-a možemo se ispomoći uporabom 

/3GB switch-a. Sada privatni procesi mogu zauzeti pojedinačno ili sveukupno do 3 GB RAM-a, [10]. 

Naravno to ide na uštrb memorije koja je na raspolaganju operacijskom sustavu. 

Slika 8 Raspodjela memorije između privatnih procesa i kernela uz primjenu /3GB switch-a 

Primjer iz Boot.ini 

[Boot Loader] 

Timeout=30 

Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT 

[Operating Systems] 

multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows Server 2003" /fastdetect /3GB 

• /USERVA switch 

Ponekad se operacijski sustav koji ima postavljen /3GB switch ponaša nestabilno. Stoga možemo 

koristiti /USERVA switch putem kojeg možemo preciznije definirati memoriju raspoloživu za privatne 

procese na način da preciznije specificiramo granicu između 2 GB i 3 GB, [11]. Višak memorije 

iskoristiti će kernel što povećava stabilnost rada sustava. 

Primjer iz Boot.ini 

[Boot Loader] 

Timeout=30 

Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT 

[Operating Systems] 

multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows Server 2003" /fastdetect /3GB /Userva=2900 

• /PAE switch 

Moderniji Windows operacijski sustavi mogu iskoristiti još više memorije uporabom PAE 

switch-a, [12]. PAE je od strane Intela osigurano memorijsko proširenje koje omogućuje podršku više 

od 4 GB fizičke memorije za većinu 32-bitnih (IA-32) Intel Pentium Pro i kasnijih platformi. 

Nažalost da bi aplikacija iskoristila PAE podršku mora biti pisana kao PAE aware aplikacija. 

Budući da su revizije iAS-a 10g relativno stariji softverski proizvodi oni nisu PAE aware aplikacije. 

112

Sa /3GB i /USERVA switch-evima možemo dobiti dodatnih 1 GB prostora za iAS. Ako se sjetimo 

da pri velikom broju korisnika potrošnja po sesiji može pasti na samo 2.8 MB, sa dodatnih 1 GB dobili 

bi preko 300 novih korisnika. Naravno trebamo voditi računa da tako opterećen iAS može imati 

problema sa CPU kod intenzivnog reportiranja. Međutim isti CPU problemi bi se javili kod tog broja 

korisnika i pri korištenju virtualnih strojeva. 

5. SWAPANJE I PAGE FILE USAGE 

Swap file (ili swap space) je prostor na disku koji se koristi kao virtualno memorijsko proširenje 

fizičke memorije računala. Postojanje swap file omogućuje operacijskom sustavu da se ponaša kao da 

ima više fizičke memorije (RAM-a) nego što je u stvarnosti ima. Naravno, ovo ima svoju cijenu jer se 

sadržaj RAM-a privremeno seli na vanjski disk i obratno što bi znatno usporilo rad iAS-a ili ga u 

konačnici potpuno onemogućilo. U biti je vrlo teško natjerati iAS na swap-anje. Uglavnom se pogrešno 

misli da sistem swap-a kad ima puno resursa i u stvarnosti još uopće ne swap-a. 

Mnogi vjeruju da je Page File Usage koji pokazuje task manager stvarni page file usage, ali to nije 

tako. PF Usage kako ga prikazuju task manager u Windows XP I Windows Server 2003 je u stvari 

system commit total, [13]. 

Na taj način ako sustav ima 4 GB RAM-a 3,67 GB RAM-a je iskoristivo. Tijekom rada možemo 

uočiti Page File Usage u Task Manageru od recimo 3,1 GB dok PefMon pokazuje samo 2%. 

113

Slika 9 Memorija sustava nakon restarta i bez korisnika na iAS-u 

114

Slika 10 Memorija sustava opterećenog s 326 korisnika. PF Usage je 3.11 GB, ali to nije swap space 

već total commit memory – sustav još ne swap-a, pogledati Available memory 1.63 GB. CPU 

opterećenje je nisko, ali nije korišteno reportiranje, inače bi CPU opterećenje bilo značajno. Non-IO 

Desktop heap size postavljen an 2048 K (objašnjeno kasnije) 

115

Slika 11 Prikaz zauzeća memorije od Forms (formsweb.exe) procesa kod 326 korisnika (onako kako 

ga vidi Task Manager). S ovim brojem procesa i linearnom ekstrapolacijom zauzeća memorije odavno 

bismo probili (zajedno s iAS instalacijom) limit od punih 4 GB (a kamoli 2 GB rezerviranog za privatne 

procese), nije korišten nijedan opcionalni memorijski switch (/ 3GB ili /USERVA) 

116

Slika 12 Slika procesa na sustavu s pet korisnika dobivena putem Process Explorer-a, Forms procesi 

frmweb.exe su potprocesi Oracle servisa 

117

Slika 13 Slika procesa na sustavu s tridesetak korisnika dobivena putem Process Explorer-a, Forms 

procesi frmweb.exe su potprocesi Oracle servisa 

118

Slika 14 OracleFRHomeProcessManager servis kojem pripada opmn.exe proces čiji su potprocesi 

Forms procesi frmweb.exe 

6. KONFIGURACIJA INSTALACIJE 

Da bi iAS mogao podnijeti veliki broj korisnika uz uobičajene konfiguracijske datoteke potrebno je 

modificirati Windows heap size i broj istovremenih konekcija (ne user-a) u Apache-ju. 

6.1. Heap Size 

Kod podizanja Windows operacijskog sustava rezerviraju se različita područja u memoriji za 

praćenje svojih resursa. Tu spada i relativno nepoznat Windows desktop heap, [14, 15]. Na windows 

operacijskim sustavima desktop heap pohranjuje informacije o različitim procesima koji se odvijaju na 

stroju. Memorijska alokacija heap-a upravljana je brojem otvorenih aplikacija, prozora, servisa i drugih 

resursa. Kod pokretanja velikog broja procesa potrebna rezervirana memorija za heap može biti 

nedostatna. Stoga treba modificirati rezervirani heap size. Ukupni heap size je na Windows 2000 

Server-u bio limitiran na svega 48 MB (to uključuje zbirno IO desktop, Non-IO desktop i shared heap 

size). Stoga, ako se željelo povećati zzzz trebalo je istovremeno obično smanjiti broj servisa (odnosno 

ukloniti servise koji nisu esencijalni) i smanjiti ponešto yyyy. Zbog takvog ograničenja na veličinu Non- 

IO Desktop heapsize u stvarnosti je postojalo ograničenje od oko 120 istovremenih korisnika na iAS-u. 

Međutim, na Windows Server 2003 i 2008 heapsize limit je praktički neograničen (ograničen 

raspoloživom memorijom). 

Kada pokrenete veliki broj programa za sustav Windows, poruke o pogrešci "Out Of Memory" 

(Nema dovoljno memorije) pojavljuju se kada pokušate pokrenuti nove programe ili kada pokušate 

koristiti programe koji su već pokrenuti, premda je još uvijek dostupno dovoljno fizičke memorije i 

memorije stranične datoteke. 

http://support.microsoft.com/kb/126962 

119

Informacija o veličini heap-a pohranjena je u registry-ju: 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems 

Tipičan sadržaj key-ja je: 

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 

Windows=On SubSystemType=Windows ServerDll=basesrv,1 

ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 

ProfileControl=Off MaxRequestThreads=16 

Veličina heap-a je definirana u dijelu SharedSection 

Default-ne vrijednosti su 1024,3072,512 

Sve vrijednosti su u kilobajtima. (K). 

Kao što vidimo veličina heap-a je određena s tri parametra: 

SharedSection = xxxx,yyyy,zzzz 

Pri tome je 

xxxx = System-wide Heapsize. Nema potrebe za modifikacijom ove vrijednosti 

yyyy = IO Desktop Heapsize. To je the heap za memorijske objekte u IO Desktop-u 

IO Desktop heap koriste programi koji se pokreću putem ikone ili iz komandne linije, ili su pak 

potprocesi pokrenuti od prethodnih programa. 

Ni ova vrijednost se ne treba modificirati (na Windows 2000 Server-u vrijednost se mogla 

modificirati na nižu vrijednost samo iz razloga da se sačuva ograničeni memorijski prostor od 48 MB 

za treću vrijednost) 

zzzz = Non-IO Destop Heapsize. To je veličina heap-a za memorijske objekte u Non-IO Desktop-u 

Non-IO Destop heap rezerviran je za servise i potprocese pokrenute od servisa. 

Ova vrijednost je pridjeljena svakom Windows servisu (misli se na servise kojima pristupamo 

preko Administrative Tools > Services). 

Ukupna veličine memorije potrebne za heap je: 

xxxx + (broj memorijskih objekata u IO Desktopu) * yyyy + (broj Windows servisa) * zzzz (1) 

Zašto moramo konfigurirati Non-IO Desktop Heapsize? 

Forms procesi su potprocesi OracleFRHomeProcessManager servisa kojem pripada opmn.exe Svaki 

servis u Windows OS-u može imati ograničen broj potprocesa koji je određen sa Non-IO Desktop 

Heapsize. Osim frmweb.exe potprocesa svaki Windows servis ima još desetak drugih potprocesa 

(slike 12-14), svi ostali potprocesi su Forms potprocesi (frmweb.exe). Svi ti frmweb.exe potprocesi su 

potprocesi OracleFRHomeProcessManager servisa. Jedan potproces zauzima oko 6.5 K. 

Broj procesa za heap size je približno, [16]: 

gdje su: 

P – boj procesa 

H – Veličina za heap u KBytes 

H 

P = (2) 

6. 

5 

120

Stoga ako umjesto 512 K postavimo Non-IO Desktop Heapsize od 2048 K možemo uslužiti oko 

300 korisnika. Ako imamo Non-IO Desktop Heapsize od 3072 K možemo uslužiti oko 450 korisnika. U 

Oracle Note: 187455.1 navedeno je da su kod vrijednosti od 5112 postigli više od 700 istovremenih 

korisnika (doduše oni su koristili Windows 2000 pa su zbog limita na Non-IO Desktop Heapsize, a da 

bi postavili veći heap Apache pokretali iz komandne linije, a modificirali IO Desktop Heapsize na 5112, 

jer kao što je već napomenuto se u Windows 2000 zbog ukupnog 48 MB limita na ukupni heap, Non- 

IO Desktop Heapsize nije se mogao postaviti na iznad 768 K. Na Windows 2003 i 2008 praktički nema 

ovog limita pa se može mijenjati Non-IO Desktop Heapsize, a Apache pokretati uobičajeno, kako je 

predviđeno i postavljeno samom instalacijom). 

Vrijednosti za heapsize preporučljivo je postavljati da budi višekratnici od 512 K, ali nije uvjet. 

Nakon promjene vrijednosti potrebno je restartati server. 

Autor je postavio Non-IO Desktop Heapsize na 2048 (Windows Server 2003) i pokrenuo 326 

jednostavnih aplikacija (formi). Isto tako je bio u kontaktu s administratorom iAS-a jedne vanjske tvrtke 

koji je imao oko 300 korisnika na stroju, a ima informacije o preko 400 korisnika jednostavne aplikacije 

pokrenute na putem stress testera. 

U praksi treba uzeti u obzir da pojedine aplikacije mogu intenzivno koristiti Oracle reporte što 

predstavlja značajno opterećenje za CPU i ponešto memoriju, pa u praksi vrijednosti mogu biti nešto 

niže. Naravno, kod velikog CPU opterećenja varijanta s virtualnim strojevima ne bi bila u prednosti. 

6.2. Određivanje najvećeg broja istovremenih konekcija 

Druga važna odluka je određivanje maksimalnog broja istovremenih konekcija koje za potrebni 

broj korisnika HTTP server mora opslužiti, inače čekaju u redu (queue) što ne želimo da korisnik 

primijeti. Svaka aktivna sesija konzumira jednu konekciju dok ne istekne KeepAliveTimeout parametar 

u Apache httpd.conf. Kod učitavanja reporta kod korisnika kratkotrajno se aktivira još jedna konekcija 

(dok se ne npr. ne učita cijeli pdf). Pasivne sesije ne koriste ni jednu konekciju (osim kratkotrajno 

svakih 30 minuta, zbog Forms heartbeat-a). Od ukupnog broja korisnika prema Paretovom principu, 

[17], 20% korisnika će proizvesti 80% aktivnosti (i konekcija) na serveru. U slučaju jako motiviranih 

korisnika može se koristiti i odnos 70:30. Ako imamo npr. 300 korisnika, njih 20% (60) proizvesti će 

80% prometa, a ostalih 80% (240) preostalih 20% prometa. Ako pretpostavimo da pozivanje reporta 

čini 5% aktivnosti i sigurnosni parametar od 25% onda za 300 korisnika uz 80:20 odnos trebamo 

300*0,2/0,8*1.05*1.25 ≈ 98 konekcije, a uz 70:30 odnos 300*0.3/0.7*1.05*1.25 ≈ 169 konekcija. 

Tipično opterećenje HTTP servera tijekom radnog dana prikazano je na slici 15. 

Simultaneous 

connections 

| 

200 | 

| 

| ********** 

| **** *** 

150 | ***** ** 

| **** *** 

| *** *** 

| * ** 

100 | * ** 

| * * 

| * * 

| * * 

50 | * * 

| * * 

| ** * 

| *** *** 

1 |*** ** 

Time of +------------------------------------------------------------- 

day 7am 8am 9am 10am 11am 12am 1pm 2pm 3pm 4pm 5pm 

Slika 15 Broj istovremenih konekcija (ne korisnika) tijekom radnog dana 

121

Broj konekcija je ovisan o parametrima KeepAlive - da li dopušta perzistentne konekcije, 

(default-na vrijednost je On - tako treba i ostaviti) i KeepAliveTimeout – vrijeme kroz koje Apache čeka 

naredni zahtjev prije nego zatvori konekciju (default-na vrijednost 15s). Ovaj parametar je kompromis 

između brzine i broja konekcija. Broj istovremenih konekcija određen je parametrom ThreadsPerChild 

– to je maksimalni broj konekcija koje Apache server može istovremeno uslužiti, default-na vrijednost 

50. ThreadsPerChild radi kao MaxClients parameter na UNIX-u. 

Određivanje maksimalnog broja istovremenih konekcija možemo još bolje utvrditi 

eksperimentalno, a treba biti zasnovano na podacima iz dijela dana kad je opterećenje najveće. 

Najveći broj istovremenih konekcija je u korelaciji s brojem korisnika koji pristupaju aplikacijskom 

serveru. Korisnik može uspostaviti od do istovremenih konekcija. Isto tako konekcije mogu biti 

definirane u Apache httpd.conf datoteci kao trajne ili privremene, a u tom slučaju treba biti definirano 

vrijeme trajanja konekcije. Treba imati u vidu da je najveći broj korisnika redovito neaktivan (nisu za 

računalom, nisu u uredu itd.) premda imaju uspostavljenu sesiju. Uobičajen način određivanja 

najvećeg broja istovremenih konekcija je uz pomoć monitoringa mod_status reporta tijekom dana dok 

se dovoljno dobro ne shvati tipično korištenje aplikacijskog servera, [18]. 

Monitoring 

with 

mod_status 

1. Add these directives to httpd.conf, or uncomment the ones already there: 

# 

# Allow server status reports, with the URL of http://servername/server-status 

# Change the ".your_domain.com" to match your domain to enable. 

# 

 

SetHandler server-status 

Order deny,allow 

Deny from all 

Allow from localhost szg01ias10g02.data.centar szg01ias10g02 

Allow from spi-dmiljkovic.data.centar 

 

2. Request the /server-status page (http:// szg01ias10g02/server-status/) from the web 

server at busy times of the day and look for a line like the following: 

192 requests currently being processed, 287 idle workers 

3. The number of requests currently being processed is the number of simultaneous 

connections at this time. Taking this reading at different times of the day can be used to 

determine the maximum number of connections that must be handled. 

(Prema IBM HTTP Server Performance Tuning) 

Naravno, da bi uopće mogli očitati velike vrijednosti za broj istovremenih konekcija one moraju 

prije biti i konfigurirane s ThreadsPerChild. Međutim nije dobro za ThreadsPerChild postavljati 

prevelike vrijednosti (reflektira se ponešto na zauzeće memorije). Na primjer, ako imamo 300 

korisnika, možemo pokušati s vrijednosti ThreadsPerChild od 150, pa vidjeti putem monitoringa koliki 

je stvaran maksimalan broj konekcija, ako je to npr. 100 onda možemo dodati sigurnosni faktor od 

25% što je 125, pa ThreadsPerChild vratiti sa 150 na 125. Ako bi broj konekcija bio vrlo blizak 

parametru ThreadsPerChild onda ga možemo malo povećati, npr. za istih 25%. Mogli bi ići i obrnutim 

putem, od malog iznosa ka većem, ali onda bi nam test uzastopno pucao sve dok ne bi postavili 

odgovarajuću vrijednost (uvećanu za sigurnosni faktor). Još jednom treba napomenuti da je ovaj 

parametar jako ovisan o KeepAliveTimeout, što je taj parametar veći to je veći i broj potrebnih 

konekcija, dok je kod manjeg parametra i broj potrebnih konekcija manji. Međutim male vrijednosti za 

KeepAliveTimeout mogu se reflektirati na komfor rada korisnika jer će se javljati situacije gdje će se 

ista konekcija opetovano uzastopno uspostavljati. 

122

Nakon svega treba spomenuti da kod velikog broja korisnika na iAS-u nije sve u korisnicima 

Forms-a. Potrebno je osigurati procesorsku snagu za vršna opterećenja kod intenzivnih reportiranja. 

Isto tako sama baza iza aplikacijskog servera također mora biti sposobna izdržati opterećenje koje na 

nju postavlja velik broj istovremenih korisnika i transakcija. 

7. ŠTO AKO IMAMO LINUX 

Sličan problem kao kod 32-bitnih Windows operacijskih sustava javlja se i kod 32-bitnih Linux 

instalacija, [19, 20]. Linux kernel dijeli adresni prostor u omjeru 3:1 za korisnički prostor u odnosu na 

kernel. Stoga odmah, bez uporabe posebnih switch-eva imamo za iAS na raspolaganju nešto malo 

više memorije nego kod kod Windowsa. Dakle memorija ni kod opterećenja od nekoliko stotina 

korisnika ne bi smjela biti problem. 

Veća memorija za korisnike Linux-a moguća je ako se koristi PAE kernel (specifičnost Intel 

procesora), ali opet, iAS 10g je relativno stariji software i nije pisan da bude PAE aware pa od toga 

nemamo koristi. 

Ako se ne koristi PAE kernel: 

1. Maksimalan fizički RAM za kernel i sve procese je ovisan o BIOS-u I tipično je ograničen na 

3.25 GB 

2. Svaki proces je ograničen na 3 GB, a kernel na 1 GB. 

8. NOVE 64 BITNE INSTALACIJE 

Kod novih 64-bitnih proizvoda kao što je Weblogic aplikacijski server nema memorijskog 

ograničenja kao kod 32 bitnih sustava. Memorije redovito ima više nego dovoljno. Nažalost iAS 10g ne 

postoji u 64-bitnoj izvedbi. 

9. ZAKLJUČAK 

Dobro konfiguriran iAS može podnijeti 300-400 korisnika Forms-a (toliko je sigurno isprobano). 

Zbog osiguranja kapaciteta za intenzivno reportiranje i u skladu s time zahtjeva na CPU u praksi bi se 

trebalo ograničiti na 250 korisnika po jednom tipičnom fizičkom serveru (kakve imamo u datacentru) 

kako bi bile podmirene vršne potrebe. 

Virtualizaciju ima smisla primijeniti jedino kad imamo još neke druge planove (seljenje virtualnih 

strojeva između fizičkih servera ili pak želimo na virtualnom stroju unutar fizičkog servera instalirati još 

nešto drugo). Limiti za broj korisnika su zbog zahtjeva na CPU u slučaju intenzivnog reportiranja isti. 

Pri tome imamo dodatne troškove licenciranja za OS i Oracle iAS (osim ako se ne koristi Oracle VM). 

Isto tako virtualizacija bi imala smisla na vrlo velikim fizičkim serverima s puno CPU jezgara (npr. 16, 

64 i više). 

Ako ne želimo koristiti napredne funkcije virtualizacije (seljenje virtualnih servera između fizičkih 

servera) trebalo bi koristiti jedan dobro konfiguriran iAS. Čak ako smo veliki ljubitelji virtualizacije, na 

virtualnim strojevima trebali bi korektno konfigurirati iAS umjesto da virtualizacijom otklanjamo potrebu 

za detaljnijom konfiguracijom iAS-a. 

Što se tiče održavanja, općenito uzevši jedan veći server znači manje održavanja, ali manje opcija 

ako se što pokvari. Više malih iAS-a na virtualnim strojevima zahtijeva više održavanja, ali pruža više 

fleksibilnosti kod održavanja i konfiguriranja (možemo spuštati jedan po jedan VM). Ako se pojedini 

iAS sruši preostali na virtualnim strojevima i dalje rade (srećom, današnji OS-ovi i iAS su vrlo 

pouzdani i mogu raditi mjesecima bez restarta). Međutim treba na neki način riješiti load balancing, a 

ako računamo na i visoku raspoloživost, a ne samo kapacitet, to rješenje ne smije imati single point of 

failure i mora uključivati mehanizme za brzu i periodičku provjeru ispravnosti instance iAS-a na VM 

(kako cluster ne bi uključivao neispravnu instancu iAS-a). 

Ako pak nismo zadovoljni sa 250 korisnika na jednom fizičkom serveru, dobro bi bilo razmisliti o 

potencijalnim posljedicama ispada jednog takvog, danas relativno jeftinog fizičkog servera (bez obzira 

na rješenje s jednim iAS-om ili više njih i VM). Veći kapacitet i raspoloživost možemo postići 

clusteriranje odvojenih pojedinačnih instalacija iAS-a (svaka na svom fizičkom serveru bez korištenja 

virtualizacije) na uobičajen način korištenjem NLB-a ili nekog load balancera. Postići ćemo jako veliki 

kapacitet, a nećemo plaćati troškove licenciranja kao kod instalacije brojnih malih iAS-a na virtualnim 

strojevima. 

123

10. LITERATURA 

1. Oracle Metalink Note: 187455.1, After 82 Sessions / Users / Connections Errors Come up or no 

new connection possible 

2. FRM-92101: There was a failure in the forms server during startup, 

http://www.orafaq.com/forum/t/143576/2/ 

3. Microsoft podrška, Poruka o pogrešci "Out of Memory" (Nema dovoljno memorije) pojavljuje se 

kada je pokrenut veliki broj programa, ID članka: 126962, 

http://support.microsoft.com/kb/126962/hr 

4. E. Lippert, “Out Of Memory” Does Not Refer to Physical Memory, Fabulous Adventures In Coding, 

http://blogs.msdn.com/b/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physicalmemory.aspx 

5. Implementing Microsoft Network Load Balancing in a Virtualized Environment, 

http://www.vmware.com/files/pdf/implmenting_ms_network_load_balancing.pdf 

6. Creating an NLB Cluster using Hyper-V, 

http://sharepointviews.blogspot.com/2008/11/creating-nlb-cluster-using-hyper-v.html 

7. Oracle Application Server Forms Services 10g (9.0.4) Capacity Planning Guide, An Oracle White 

Paper November 2004 

8. Oracle Forms Services Release 6i Capacity Planning Guide, 2000 

9. J. Garmany i D. K. Burleson, Oracle Application Server 10g Administration Handbook; Oracle 

Press, McGraw-Hill, 2004 

10. Ask Aresh, 32-bit Memory Management Explained, http://askaresh.blogspot.com/2008/11/32-bitmemory-management-explained.html 

11. How to use the /userva switch with the /3GB switch to tune the User-mode space to a value 

between 2 GB and 3 GB, http://support.microsoft.com/kb/316739 

12. Physical Address Extension - PAE Memory and Windows, http://msdn.microsoft.com/enus/windows/hardware/gg487503 

13. Explanation of Pagefile Usage as reported in the Task Manager, 

http://blogs.technet.com/b/perfguru/archive/2008/01/08/explanation-of-pagefile-usage-as-reportedin-the-task-manager.aspx 

14. Desktop Heap Overview, Part I, 

http://blogs.msdn.com/b/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx 

15. Desktop Heap Overview, Part II, 

http://blogs.msdn.com/b/ntdebugging/archive/2007/07/05/desktop-heap-part-2.aspx 

16. E. Marechal, Windows and the ClearCase process limit: Understanding the desktop heap, 

http://www.ibm.com/developerworks/rational/library/05/1220_marechal/ 

17. Pareto principle, http://en.wikipedia.org/wiki/Pareto_principle 

18. IBM HTTP Server Performance Tuning, 

http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html 

19. Linux 32 bit OS and 4GB memory limit, http://www.linuxquestions.org/questions/linux-general- 

1/32-bit-os-and-4gb-memory-limit-707762/ 

20. LinuxRamLimits, http://www.spack.org/wiki/LinuxRamLimits 

124

METODE BALANSIRANJA OPTEREĆENJA (LOAD BALANCINGA) ZA 

APLIKACIJSKE SERVERE 

METHODS FOR LOAD BALANCING FOR APPLICATION SERVERS 

Dubravko Miljković 

HEP-SIT, Vukovarska 37, Zagreb 

Mob: 098 9825602 

E-mail: dubravko.miljkovic@hep.hr 

SAŽETAK 

Da bi se osigurala potrebna raspoloživost, kapacitet i skalabilnost web aplikacija u poslovnim 

sustavima s velikim brojem korisnika uobičajeno je korištenje nekog oblika balansiranja opterećenja 

(load-balancinga). Razmotrena su slijedeća rješenja: Round Robin DNS, Hardware Load Balancing, 

Software Load Balancing: Oracle i Load Dispatcher te Windows NLB. Odlučujući faktori za odabir 

rješenja uključuju raspoloživa svojstva, složenost implementacije, povećanje raspoloživosti i cijenu. 

Opisani su mehanizmi provjere ispravnosti noda, održavanje perzistentne sesije i mogućnost 

asimetričnih opterećenja. Prikazano je rješenje raspoređivanja opterećenja u geografski disperziranom 

sustava pogodnom za veće organizacije sa više regionalnih centara. 

ABSTRACT 

To provide necessary availability, capacity and scalability of web applications in business systems 

with large number of users it is common to use some kind of load balancing. Following solutions are 

considered: Round Robin DNS, Hardware Load Balancing, Software Load Balancing (built in Oracle 

iAS and Load Dispatcher) and Windows NLB. Decisive factors influencing choice of solution includes 

available features, complexity of implementation, increased availability and price. Mechanisms for 

node health check, maintaining persistent session and handling asymmetric loads are presented. 

Solution for load distribution in geographic distributed system suitable for larger organizations with 

more regional centers is also described. 

1. UVOD 

Za osiguranje potrebne raspoloživosti, kapaciteta i skalabilnosti web aplikacija uobičajeno je 

korištenje farmi aplikacijskih servera. Između klijenta i farme aplikacijskih servera potrebno je imati 

metodu koja će raspoređivati ulazne http zahtjeve na individualne servere unutar farme, [1, 2]. Load 

balancer kao postupak ili uređaj presreće mrežni promet i usmjerava ga prema različitim serverima. 

Sama farma aplikacijskih servera se prema van predstavlja preko jedinstvene virtualne adrese (kao 

jedinstven server). Za postizanje visoke raspoloživosti load balancing treba detektirati neispravan 

server i automatski ga izostaviti iz raspoređivanja prometa (nažalost korisnici Forms aplikacija morati 

će se ponovno konektirati, ali će im load balancer to odmah omogućiti). U slučaju potrebe za većim 

kapacitetom sustava load balancing omogućuje skalabilnost, dovoljno je dodati novi server. Load 

balancing omogućuje i fleksibilnost u radu farme jer se pojedinačni server može za potrebe 

održavanja privremeno uklonit iz farme. 

Slika 1 Load balancer i farma web servera 

125

2. METODE BALANSIRANJA PROMETA 

Slijedi kratak pregled metoda za load balancing. (postoje i drugačija podjele, zasnovana na 

mrežnom Layeru gdje se odvija balansiranje). 

2.1. Round Robin DNS 

Predstavlja najjednostavniji način distribucije opterećenja. Round-robin DNS radi na način da DNS 

server odgovara na zahtjev ne sa jednom IP adresom, već sa više IP adresa servera koji pružaju istu 

web uslugu [1, 2, 3]. Temelj ove metode predstavlja redoslijed IP adresa koje DNS server vraća 

klijentu. Sa svakim novim zahtjevom permutira se (točnije rotira) lista IP adresa koje kao odgovor šalje 

DNS server. Klijent obično koristi prvu vraćenu adresu. Na taj način različiti pozivi klijenata su usluženi 

od različitih servera čime se cjelokupno distribuira opterećenje raspodjeljuje između svih servera. Npr., 

ako su adresi web usluge dodijeljene tri IP adrese, prvi klijent će pristupiti prvoj IP adresi, drugi drugoj 

IP adresi, treći trećoj IP adresi, četvrti opet prvoj IP adresi itd. Evo jednog primjera unosa u DNS 

serveru s višestrukim A rekordima: 

; zone file fragment 

IN MX 10 hepweb 

.... 

hepweb IN A 192.168.0.4 

IN A 192.168.0.5 

IN A 192.168.0.6 

192.168.0.4, 192.168.0.5, 192.168.0.6 

192.168.0.5, 192.168.0.6 ,192.168.0.4 

192.168.0.6 ,192.168.0.4, 192.168.0.5 

Premda je sama metoda vrlo jednostavna ona pati od ozbiljnih nedostataka. Na DNS serveru i/ili 

klijentu obično je uključena subnet prioritizacija (subnet prioritization) koja u slučaju korištenja servera 

na različitim mrežama uređuje redoslijed IP adresa na način da prva adresa bude ona (po IP metrici – 

pojednostavljeno to je sličnost IP adresa klijenta i servera) iz najbliže mreže. Premda ovo može biti 

čak i zgodno kod geografski disperziranih sustava, subnet prioritizacija će istom klijentu kod 

uzastopnih upita uvijek na prvom mjestu vratiti IP adresu istog (po IP metrici najbližeg) servera. Na taj 

način ako pojedine regije imaju različiti broj klijenata, zahtjevi klijenata neće se ravnomjerno 

raspoređivati po serverima već po kriteriju subnet prioritizacije i pripadne IP metrike. Drugi problem je 

taj što DNS serveri i klijenti obično koriste cache, pa uzastopni zahtjevi ne moraju biti raspoređeni na 

različite servere. Ponešto može pomoći korištenje malih vrijednosti TTL (Time To Live), ali to 

povećano opterećuje DNS server. Treći problem je što Round Robin DNS ne vodi računa o stvarnoj 

raspoloživosti servera koji osigurava uslugu klijenta. Ukoliko server ispadne iz funkcije, Round Robin 

DNS će i dalje klijentima dostavljati IP adresu neraspoloživog servera (ne uključuje fault-tolerance). 

Četvrti problem je što round robin DNS jednako raspodjeljuje promet na servere ne vodeći računa o 

kapacitetu pojedinog servera. Ovaj nedostatak djelomično se može otkloniti varijantom Weighted 

Round-Robin DNS gdje se svakom serveru dodjeljuje određen težinski faktor: 

Resource Weight 

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

server1 4 

server2 12 

server3 1 

U gornjem primjeru od 17 zahtjeva 4 će biti raspoređena na prvi server, 12 na drugi i 1 na treći 

server. Nažalost Weighted Round-Robin DNS nije standardiziran na DNS serverima. 

Treba imati u vidu i ponašanje web browsera u slučajevima kad su mu je dostavljeno više IP 

adresa za istu web adresu. Microsoft Internet Explorer (IE) kad ne može dohvatiti prvu IP adresu 

nakon 20 sekundi pokušat će dohvatiti narednu od dostavljenih IP adresa. Pri tome treba osigurati da 

web server koji nije raspoloživ ne smije imati aktivnu web stranicu (npr. server može biti djelomično 

ispravan i imati aktivnu web stranicu čime prema vanjskom svijetu daje dojam potpune ispravnosti). 

Postoje i jednostavna programska rješenja gdje se ciklički ispituje stanje svih web servera koji pružaju 

126 

2

uslugu klijentima i u slučaju ispada pojedinog servera obavlja se automatska intervencija na DNS 

serveru tako da se privremeno ukloni record koji pripada neraspoloživom web serveru. Nakon što 

dotični server ponovo postane dostupan njegov record se ponovo automatski dodaje u DNS server. 

Primjer takvog programa je Simple Failover, [4]. Na slijedeće dvije slike ilustriran je rad tog programa. 

Slika 2 Round robin i ispad servera Slika 3 Round robin sa Simple Failover 

2.2. Hardware Load Balancing 

Hardware load balanceri (Hardware Load-balancing Device HLD) obično su integrirani unutar 

modernih router-a (layer 4-7 router). Mogu opsluživati izuzetno velike promete, ali nemaju velike 

mogućnosti konfiguriranja. Isto tako ovo rješenje je vrlo skupo za male i srednje velike poslovne 

sustave. Uobičajene su izvedbe kao programska rješenja na posebnom brzom hardware-u 

(Application-Specific Integrated Circuit - ASIC) ili pak kao zasebne kombinacije custom hardware i 

software-a na nekoj varijanti LINUX-a ili custom OS-a. Česte su redundantne izvedbe (dual core) čime 

se uklanja load balancer kao potencijalni single point of failure. Uobičajeni implementirani load 

balancing algoritmi su slijedeći: round robin, weighted round robin, least connections, weighted least 

connections, server latency i direct server measurement (uporabom server feedback-a). Posljednje 

rješenje je napredno i uzima u obzir trenutno opterećenje servera na destinaciji, [5]. Konfiguracija 

redovito spada u domenu osoblja za održavanje mrežne opreme, rijetko će to obavljati sistem 

administratori, pa treba uzeti u obzir potrebu koordinacije kadra. 

Slika 4 Hardware load balancer koji uzima u obzir opterećenje servera (agenti na serverima) 

127 

3

2.3. Software Load Balancing 

Load balancing je tradicionalno poistovjećivan sa posebnim hardware-om. Međutim load 

balancing može se realizirati i kao programsko rješenja na konvencionalnim serverima. Spomenuti 

ćemo i Oracle iAS web cache koji se može obavljati funkciju jednostavnog load balancera. 

Slika 5 Oracle web cache load balancer 

Slika 6 Oracle web cache load balancer s primjenom težinskih faktora 

128 

4

• OracleAS Web Cache arhitektura 

iAS Web cache ne omogućuje samo cache-ing statičkih web stranica, već i jednostavnu formu 

load balancinga, [6]. Pri tome se kod konfiguriranja navedu svi serveri u farmi. Sam web cache može 

biti na aktiviran na odvojenom (aplikacijskom) serveru ili pak na jednom od postojećih aplikacijskih 

servera. Omogućeno je pridjeljivanje različitih težinskih faktora ovisno o kapacitetu pojedinog servera 

(weighted availability capacity). Samo balansiranje odvija se po round robin metodi. Slično rješenje 

postoji i za instance u Weblogic clusteru (Administrator console). Postoji i mogućnost failover-a 

(ugrađena jednostavna detekcija pada instance – mogućnost dohvata stranice Apache servera). 

Međutim u oba slučaja ostaje problem jedne pristupne točke za korisnike (single-point of failure). 

Stoga su prethodna rješenja pogodna za clusteriranje instanci unutar istog hardverskog servera. 

• Programski load balancer (load dispatcher) na konvencionalnom serveru 

Load dispatcher (sinonim za load balancer, ali češće se koristi u nazivima softverskih balancera) 

je potpuno programsko rješenje raspoređivanja prometa. Realizirano je kao programski paket koji se 

vrti na posebnom serveru. Današnji hardware je vrlo brz tako da ovakvo rješenje zadovoljava gotovo 

sve potrebe (reda 10000 novih konekcija po sekundi). S druge strane programska realizacija donaša 

izrazito veliku fleksibilnost kod definiranja politike raspoređivanja prometa. Uobičajena su slijedeća 

load balancing pravila: round robin, weighted round robin, perceptive (predviđa najprikladniji nod 

kombinirajući broj konekcija i vrijeme odziva), least connections (nod s najmanje konekcija), weighted 

least connections, fastest response time (nod s najbržim vremenom odziva), random node itd. Kao i 

kod hardware load balancera ukoliko se želi postići balansiranje prometa zasnovano na opterećenjima 

pojedinih servera postoje agenti koji se instaliraju na servere – server feedback (mogu obavljati i 

provjeru ispravnosti aplikacije). Ukoliko se želi ostvariti i visoka raspoloživost potrebno je koristiti dva 

balancera (u active-standby ili active-active konfiguraciji), [1, 2] da bi se izbjegla single point of failure. 

Slika 7 Software load balancer ispred Weblogic servera 

Slika 8 Software load balancer za visoku raspoloživost (primarni balancer i backup) 

129 

5

• HTTP redirector 

Ograničen su samo na HTTP promet. HTTP zahtjev preusmjerava sa HTTP redirectd komandom 

direktno na pojedini aplikacijski server [2]. Početno se pristupa adresi redirectora, ali se u browseru 

ubrzo vidi adresa odabranog aplikacijskog servera. Ovisno o složenosti programskog rješenja moguće 

su i različite opcije preusmjeravanja. Najjednostavnija rješenja susreću se u obliku Perl skripti (random 

node, round robin, IP address based - geotargeting). Ovakve skripte dostupne su na internetu, [7], a 

mogu se jednostavno dodatno modificirati za konkretnu primjenu (npr. regionalnu redirekciju po IP 

adresi, umjesto redirekciju po državi korisnika). Primjer jednog drugog složenijeg Perl load balancera 

je freeware Perbal, [8]. 

Software load balanceri su jeftiniji i imaju veće mogućnosti konfiguriranja od hardware load 

balancera (npr. mogu usmjeriti promet na nod koji optimalno može uslužiti zahtjev, url swithing – 

prefix, pattern, sufix) Postoje i besplatne verzije kao npr. Zen Load Balancer. 

2.4. Windows NLB 

Microsoft Windows Clustering podržava slijedeće dvije cluster tehnologije: NLB (Network Load 

Balancing) cluster i Server cluster, [9]. Za nas je bitna NLB cluster tehnologija koja omogućuje 

distribuiranje opterećenja između više servera što je pogodno za web aplikacije. Pri tom je svaki 

server sposoban samostalno opsluživati aplikaciju, a NLB samo balansira promet na raspoložive 

servere. Balansiraju se mrežne konekcije. Međutim pri velikom broju korisnika, broj konekcija po 

serveru jako dobro aproksimira i stvarno opterećenje servera. Svaki server trebao bi imati (premda 

nije uvjet) po dvije mrežne kartice, jednu za NLB (balansirani) promet i jednu za običan promet ka i od 

servera. Primjena samo jedne kartice je moguća ali postavlja određena ograničenja (samo multicast 

mode i onemogućena komunikacija između servera unutar NLB clustera, moguća je komunikacija 

servera samo prema van i obratno). Serveri se spajaju na mrežu kao na zajednički bus. Ne postoji 

posebna međusobna veza između servera u clusteru (interconnect). Dizajn je fault-tolerant i nema 

single point of failure. Windows 2008 podržava do 32 noda spojena u NLB koji trebaju biti na istom 

fizičkom subnetu (i lokaciji) osima ako se ne koristi VLAN (to donosi problem jedne pristupne točke). 

Slika 9 NLB Setup - kartice su na mreži kao na paralelnom bus-u, nodovi su ravnopravni, nema 

vanjskog load balancera, eliminiran single point of failure 

Slika 10 Windows NLB Stack 

130 

6

Network Load Balancing cluster ostvaruje visoku raspoloživost na slijedeća tri načina: 

1. Periodična razmjena poruka – heartbeat message 

2. Konvergencija – promjena stanja clustera inicira postupak konvergencije. Članovi clustera se 

međusobno informiraju o svojim stanjima i određuje se nova distribucija opterećenja na preostale 

aktivne članove clustera 

3. Raspoloživost tijekom planiranih isključenja – pojedinačni serveri unutar clustera mogu se stavit 

van pogona dok cluster dalje nesmetano radi 

Na slikama je predstavljena je konfiguracija NLB-a (obavlja se s Network Load Balancing Manager-om) 

Slika 11 Dodavanje novih nodova u NLB cluster (Windows 2003 i 2008) 

Slika 12 Host parameters – default state stopped Slika 13 Cluster IP address (virtual address) 

Slika 14 Cluster parameters - unicast Slika 15 Port rules – Load Equal, Affinity Single 

131 

7

Windows NLB je u svojim počecima bio zamišljen da radi preko hub-a (ne preko switch-a). Danas se 

to redovito rješava direktnim spajanjem NLB mrežnih kartica na switch. Pri tome je potrebno na 

mrežnoj NLB kartici osposobiti IP Forwarding (windows 2008). 

netsh interface ipv4 set int "[name of the NIC]" forwarding=enabled 

Napomena: [name of the NIC]=NLB 

Na Windows 2000 i 2003 treba u registry-ju postaviti: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter 

Value Name: IPEnableRouter 

Value type: REG_DWORD 

Value Data: 1 

Windows NLB je daleko najrašireniji oblik network load balancinga, ali slično rješenje postoji i za Linux 

(lnlb), [10]. 

3. PROVJERA ISPRAVNOSTI NODA (APLIKACIJSKOG SERVERA) 

Balansiranje prometa na server ima smisla samo ako je dotični server ispravan. Utvrđivanje 

ispravnosti noda i aplikacije na njemu može biti složeniji zadatak (application health monitoring), |1, 2]. 

Naime, nije dovoljno samo da na aplikacijskom serveru bude funkcionalan, isto mora važiti za ostale 

komponente kao npr. reports serveri itd. Stoga je potrebno dobro definirati kada je nod stvarno 

ispravan. Pri tome sama indikacija da je neki servis podignut ne znači da je usluga i stvarno dostupna 

pa bi trebalo raditi funkcionalne provjere - probe (npr. učitavanje web stranice, puštanje nekog vrlo 

jednostavnog reporta, analiziranje reports log-a itd.). Poželjno je uvesti i dvorazinsku provjeru, brzu i 

sporu. Brza (osnovna), jednostavnija provjera kritičnih komponenti (npr. Apache s HTTP GET) obavlja 

se jako često, npr svakih nekoliko sekundi i u slučaju neuspjeha služi za trenutno isključivanje servera 

iz farme. Budući da se ponavlja u vrlo kratkom intervalu ne smije puno opterećivati CPU (npr. 

aplikacija Active Server Watcher). 

Slika 16 Active Server Watcher za jednostavne i brze provjere 

Detaljna (application specific, HTTP GET s content checks, reports servers, provjera 

funkcionalnost servisa – ne samo provjera da li je servis podignut), sporija, provjera obavlja se prije 

nego li se server uključi u farmu, kao i nakon toga, ali u ciklusu reda minute. Ova provjera je ponešto 

malo zahtjevna za CPU i nije stoga uputno ponavljati je u vrlo kratkom intervalu kao kod brze provjere. 

Primjer pogodne aplikacije za ovu namjenu je IPSentry. U narednoj tablici ilustrirana je veza između 

raspoloživosti i godišnjeg vremena van pogona. Primijetite da je za ostvarivanje vrlo visoke 

raspoloživosti (99,999 %) potrebno reagirati jako brzo u slučaju kvara noda. Ukoliko pretpostavimo da 

se kvar bilo kojeg noda (odnosno aplikacije na njemu) u clusteru dešava nekoliko puta u godini, 

potrebno je detektirati kvar i rekonfigurirati cluster u roku ispod minute. Inače ćemo osigurati samo 

veliki kapacitet, ali ne i raspoloživost. 

132 

8

Tablica I Raspoloživost, ukupno godišnje vrijeme van pogona i predloženo rješenje 

Raspoloživost Godišnje vrijeme van pogona Rješenje (okvirno) 

99% 87,6 sati jedan server 

99,9% 8,76 sati jedan server, vrlo dobra konfiguracija i održavanje 

99,99% 52,5 minuta cluster 

99,999% 5,25 minuta cluster, geografski disperzirani cluster 

Slika 17 IP Sentry za detaljne provjere I Slika 18 IP Sentry za detaljne provjere II 

4. PERZSTENCIJA, ASIMETRIČNA OPTEREĆENJA, 

• Perzistencija 

Za razliku od statičnih web stranica koji ma se uzastopno može pristupati s različitih servera 

(stateless aplications), Forms aplikacije moraju se od početka do kraja izvesti na istom serveru 

(statefull applications). Potrebno je svu komunikaciju tijekom sesije usmjeravati samo na jedan isti 

aplikacijski server [1, 2]. Postupak se naziva session persistence ili sticky session. Perzistencije se 

ostvaruju na slijedeće načine: 

Primjena cookija, load balancer upisuje cookie u browser korisnika (session cookie, kao 

kod iAS web cache-a) 

IP zasnovana – persistence window, korisnik s iste IP unutar prozora perzistencije 

komunicira samo s jednim serverom, kao kod Windows NLB-a, problem s korisnicima iza 

proxy-a 

• Asimetrična opterećenja 

Serveri u farmi nemaju uvijek isti kapacitet te ne bi bilo dobro ravnomjerno raspoređivati sav 

promet jednako po serverima nejednakog kapaciteta. Stoga sve opisane metode imaju neku 

mogućnost rada sa serverima različitih kapaciteta: 

weighting faktor kod round robin 

weighting faktor u hardware load balanceru 

weighting faktor u software load balanceru 

weighting faktor u Windows NLB, [9] 

• Problem IP affinity-a (i perzistencije uopće) 

IP affinity je dobro rješenja za ostvarenje perzistentnih session-a, ali postavlja se pitanje koliko 

vremenski dugo taj affinity treba vrijediti (affinity window) Očigledno ne treba dovijeka zalijepiti 

korisnika za pojedini aplikacijski server. Pri primjeni cookija load balancer bi trebao izmijeniti cookie 

na kraju sesije (load balancer trebao nekako saznati kad je sesija dovršena, npr putem posebnog jar-a 

133 

9

iz aplikacije). Kod Windows NLB-a affinity je zasnovan na IP adresi korisnika i vrijedi od uspostave 

rada aplikacijskog servera u NLB clusteru pa sve do prekida rada dotičnog servera unutar NLB 

clustera. Budući da ne želimo da isti korisnik uvijek bude raspoređen na isti server (npr. dan za 

danom) potrebno je ponekad nakratko isključiti server iz NLB-a (resetiranje affinity-a). To se kod NLBa 

može obaviti komandom wlbs stop i nakon toga (nakon oko jedne minute) s komandom wlbs start 

Sam interval prekida ne smije biti prekratak, u praksi treba ostaviti dovoljno vremena da nlb cluster 

sa sigurnošću „shvati“ da mu privremeno nedostaje jedan nod i „zaboravi“ postojeće affinity). Ovo je 

pogodno obavljati tijekom noći kada obično nema korisnika na sustavu. To treba napraviti sukcesivno 

na više servera (idealno na svim) u NLB clusteru, inače bi korisnik opet završio na istom serveru (jer bi 

ujutro drugi serveri zbog affinity opet imali stare korisnike, a dotični server bi bio najmanje opterećen). 

• Ponašanje nakon restarta noda 

Kod ispada noda obično se obavlja restart servera (kod manjeg kvara prvo se pokuša sa restartom 

komponente aplikacijskog servera, pa tek u slučaju neuspjeha restart čitavog servera). Za vrijeme 

podizanja noda korisnici će se spajati na preostale aktivne nodove. Ako podizanja noda potraje dulje 

vremena, mnogi korisnici s kojima je bila prekinuta komunikacija već će započeti nove perzistentne 

sesije (zbog brze prilagodbe clustera na novonastalu situaciju). Stoga će restartani nod biti slabo 

opterećen (funkcija vremena oporavka i pristizanja korisnika) sve dok ne stignu potpuno novi korisnici. 

Ovaj efekt se može smanjiti osiguravanjem brzog reboota servera (uklanjanje nepotrebnih servisa itd.). 

• Opterećenje preostalih nodova 

Prilikom dizajniranja load balancinga clustera treba računati da u slučaju ispada jednog noda, 

preostali nodovi imaju dovoljan ukupan kapacitet da usluže korisnike. Ako se to ne osigura, a sami 

nodovi nemaju neku vrstu zaštite od preopterećenja, ispad jednog noda može izazvati domino efekt i 

porušiti sve preostale nodove. Stoga load balancing cluster treba dimenzionirati s jednim serverom 

viška (redundancija N+1). 

5. GEOGRAFSKI DISPERZIRANI SUSTAV 

Opisan je primjer geografski disperziranog sustava koji se koristi u HEP-u, a uključuje četiri iAS 

clustera u četiri regionalna centra (Zagreb, Rijeka, Split i Osijek), [12, 13]. U svakom pojedinom 

regionalnom centru nalazi se iAS NLB cluster koji može raditi samostalno. Sustavu se pristupa preko 

zajedničke web adrese hepweb, bez obzira na lokaciju korisnika. Za usmjeravanje korisnika na 

najpogodniji NLB cluster koristi se geotargeting redirekcija. Geotargeting redirekcija je ostvarena 

kombinacijom DNS subnet prioritizacije i Perl rediretkora. Redirekcija se obavlja prema regiji korisnika, 

a lokano unutar regionalnih clustera, na nivou aplikacijskih servera, primijenjen je Windows NLB. 

Koristi se dvorazinska geotargeting redirekcija. Prva razina se obavlja uz pomoć DNS s 

uključenom subnet prioritization opcijom. Ova opcija je po defaultu je bila uključena i na računalima 

korisnika (Windows 2000, Windows XP). Za zajedničko krovno ime hepweb postoje višestruki 

(konkretno četverostruki) A rekordi u DNS-ima unutar HEP-a. Ovi rekordi ukazuju na adrese Perl 

redirektora koji se nalaze na svakom clusteru. Perl redirektorima pristupa se preko virtualne adrese 

regionalnih regionalnog clustera, npr. http://hepwebzg/apli.html). Perl skripta pri redirekciji uzima u 

obzir stanja (raspoloživost i opterećenje) koja clusteri međusobno izmjenjuju (svoje stanje opterećenja 

regionalni clusteri oglašavaju na servisnoj web stranici clustera) clustera. Na DNS serverima uključena 

je opcija subnet prioritization. Ova opcija uključena je po defaultu i na računalima korisnika (Windows 

2000, Windows XP). 

Perl redirektori na regionalnim clusterima imaju slijedeće adrese: 

hepwebos 10.193.64.116 

hepwebri 10.65.64.206 

hepwebst 10.129.64.116 

hepwebzg 10.1.200.206 

Ukoliko korisnik koristi novi adresni sustav (s lokalnim adresama 10.*.*.*) za upit nslookup hepweb 

DNS-ovi (s uključenom subnet prioritizacijom) odgovaraju sortiranim adresama Perl redirektora 

134 

10

Za korisnike iz raznih regija to izgleda ovako: 

• Regija Osijek 10.193.64.116, 10.129.64.116, 10.65.64.206, 10.1.200.206 

• Regija Rijeka 10.65.64.206, 10.1.200.206, 10.193.64.116, 10.129.64.116 

• Regija Split 10.129.64.116, 10.193.64.116, 10.1.200.206, 10.65.64.206 

• Regija Zagreb 10.1.200.206, 10.65.64.206, 10.129.64.116, 10.193.64.116 

Korisnici na prvom mjestu uvijek dobiju adresu svog regionalnog Perl redirektora. Ukoliko je prva 

adresa nedostupna, klijentov IE browser prelazi nakon 20 sekundi na slijedeću adresu vraćenu iz 

DNS-a (mehanizam ugrađen u sam IE browser) i dođe do nekog od Perl redirektora dok je ispravan 

barem jedan od clustera. U slučaju DNS-a s uključenom subnet prioritizacijom prva razina redirekcije 

usmjerava korektno sav promet osim u slučajevima ispada ili preopterećenja regionalnog clustera. 

Ako nije uključena subnet prioritizacija na DNS serverima nslookup hepweb pri vraća permutirane 

adrese regionalnih clustera (round robin DNS), a sav teret usmjeravanja korisnika na pripadni server 

ostaje na Perl skriptama. Sustav radi u oba slučaja, samo kod uključene subnet prioritizacije promet 

se korektno usmjeri već na prvoj razini, pa Perl skripta na drugoj razini samo potvrdi (propusti) 

redirekciju. Razni mogući problemi kod balansiranja prometa uz pomoć DNS servera na globalnoj 

geografskoj razini (pogotovo kad dotični DNS serveri nisu naša nadležnost) spomenuti su u [14, 15, 16]. 

Drugu razinu redirekcije obavlja Perl skripta koja provjerava kojem od regionalnih adresnih 

područja pripada IP adresa korisnika. Potom se vrši redirekcija na aplikativnu adresu pripadnog 

regionalnog, obično istog na kojem je i dotični redirektor clustera (to može biti produljena virtualna 

adresa pa u slučaju da je ciljni cluster neispravan ne obavlja redirekciju na njega već se redirekcija 

obavlja metodom slučajnog izbora između preostalih ispravnih regionalnih clustera (uključivši tu i 

cluster na kojem se donosi ta odluka). Na taj način u slučaju ispada jednog clustera po trećina 

prometa ravnomjerno se usmjerava na svaki od preostalih regionalnih clustera. 

Slika 19 Normalan geografski disperziranog sustava rad sustava 

Slika 20 Ispad clustera Rijeka, promet se preusmjerava na drugi cluster (u ovom primjeru Zagreb). 

Pri izboru drugog clustera uzimaju se u obzir svi regionalni clusteri koji imaju višak kapaciteta 

135 

11

6. ZAKLJUČAK 

U radu iznesen je kratak pregled metoda za load balancing. Većina njih zahtjeva dodatni hardware 

koji za slučaj zahtjeva visoke raspoloživosti treba biti udvojen. Vrlo često routeri imaju ugrađenu 

funkciju load-balancinga, pa se mogu koristiti i za tu funkciju. Konfiguriranje ovakvih routera izlazi iz 

domene sistem administratora i obično obavljaju specijalizirane osobe – mrežni administratori 

(najčešće vanjski partneri), stoga treba računati na vanjsku podršku. Ukoliko se želi izrazito velika 

fleksibilnost u kreiranju pravila raspoređivanja prometa (kao npr. servisiranje pojedinih aplikacije na 

određenim nodovima u clusteru kroz specifični url switching) može se koristiti software load balancer. 

Ako se želi osim velikog kapaciteta i skalabilnosti postići i visoka raspoloživost treba izbjeći single 

point of failure pa su potreban dva balancera u clusteru (ili dual-core redundantni hardware load 

balanceri). Za precizno usmjeravanje prometa po nodovima u slučaju korištenja odvojenih hardware i 

software load balancera potrebno je imati instalirane agente za procjenu opterećenja na samim 

nodovima gdje su aplikacijski serveri (server feedback). Rješenja gdje je load-balancer integriran u 

web cache samog aplikacijskog servera pogodna su za balansiranje prometa na instance aplikacijskih 

servera instalirane unutar istog hardware servera, ali nisu pogodna za postizanje visoke raspoloživosti 

ako se koristi više hardware servera (što je u clusterima skoro redovit slučaj) zbog jedne pristupne 

točke za korisnika. Od raspoloživih metoda autor preferira Microsoft NLB jer je jednostavan za 

konfiguriranje i ne zahtijeva dodatni hardware, niti intervencije na routeru, a po performansama je više 

nego dovoljan čak i za najveće sustave. Budući da su svi nodovi ravnopravni na mreži (bez front load 

balancing servera) ne postoji single point of failure. Isto tako, stanje ispravnosti aplikacije može se 

nakon provjere direktno komunicirati sa NLB postavkama noda u clusteru (komunikacija unutar istog 

servera). Tijekom sesije web aplikacije korisnika promet za dotičnog korisnika treba se redovito 

odvijati preko istog aplikacijskog servera, stoga je potrebno osigurati neki oblik perzistencije sesije 

(npr. zasnovane na IP adresi korisnika). Jednostavno i jeftino rješenje za geografski disperzirani 

cluster može se realizirati dvorazinskim usmjeravanjem prometa koji na prvoj razini uključuju 

višestruke recorde u DNS serverima (inicijalna redirekcija po IP adresi korisnika), a na drugoj razini 

(lokalni clusteri) kombinaciju Perl redirektora (HTTP redirekcija po IP adresi korisnika) i network load 

balancing-a (NLB). 

7. LITERATURA 

1. T. Bourke, Server Load Balancing, O'Reilly & Associates, 2001 

2. C. Kopparapu, Load Balancing Servers, Firewalls and Caches, John Wiley, 2002 

3. D. Hart, Load Balancing and Round Robin DNS, Adanac Software, 

http://www.adanacsoftware.com/articles/Load%20Balancing%20and%20Round%20Robin%20 

DNS.pdf 

4. SimpleFailover, User Manual, http://www.simplefailover.com/outbox/SimpleFailover.pdf 

5. A. Bivens et all., Autonomic load balancing, Part 1: Cisco Content Switching Module, 2006, 

http://www.ibm.com/developerworks/autonomic/library/ac-ewlmload1/ 

6. Oracle 9iAS Web Cache, Administration and Deployment Guide, Release 2 (9.0.2), 2002 

7. R. L. Schwartz , Poor man's load balancer, 

http://www.stonehenge.com/merlyn/WebTechniques/col55.html 

8. Perlbal, http://www.danga.com/perlbal/ 

9. R. J. Shimonski, Windows Server 2003 Clustering & Load Balancing, McGraw-Hill, Osborne, 

2003 

10. Linux Network Load Balancing, http://lnlb.sourceforge.net/ 

11. Global Server Load Balancing, Array Networks, White Paper 

12. D. Miljković, Geografski distribuiran iAS NLB cluster, 10. HROUG konferencija, Umag, 2005 

13. D. Miljković, Geografski disperzirani cluster internet aplikacijskih servera za visoku 

raspoloživost i kapacitet, CASE 18, Opatija, 2006 

14. P. Tenerillo, Why DNS Based Global Server Load Balancing (GSLB) Doesn’t Work, Tenerillo 

Inc., 2004, http://www.tenereillo.com/GSLBPageOfShame.htm 

15. P. Tenerillo, Why DNS Based Global Server Load Balancing (GSLB) Doesn’t Work, Part II, 

Tenerillo Inc., 2004, http://www.tenereillo.com/GSLBPageOfShameII.htm 

16. P. Tenerillo, Overview of DNS Caching In Browsers, Addendum to “Why DNS Based GSLB 

Doesn’t Work”, Tenerillo Inc., 2004, http://www.tenereillo.com/BrowserDNSCache.htm 

136 

12

INTEGRACIJA ORACLE APLIKACIJA I JASPERREPORTS-A 

Josip Matanović 

Infosistem d.d., Ivana Šibla 15, 10020 Zagreb 

Telefon: +385 1 6500 233 GSM: + 385 91 6500 233 

E-mail: jmatanovic@infosistem.hr Web: www.infosistem.hr 

SAŢETAK 

Pravodobno posjedovanje točnih informacija je jedna od presudnih prednosti kompanija. 

To dovodi do povećane potrebe za izvještavanjem i izradom velikog broja nerijetko sličnih 

izvještaja. Radi potrebe da se korisnicima omogući da više utječu na rezultat traženih 

informacija te ubrza, olakša i poveća kvaliteta posla poseglo se za integracijom 

JasperReports s Oracle aplikacijama. Korisniku se omogućava da na jednostavan način 

manipulira rezultatima izvještaja, kao i mogućnost biranja u kojem će se alatu izvješća 

naknado uređivati (MS word, MS excel, PDF,...). 

Timely possession of accurate information is one of the key competitive advantages a 

company can have. This leads to an increased demand for business intelligence (reporting) 

and development of a large number of frequently similar reports. In order to give users 

control of the requested information and expedite, facilitate and increase the business 

process JasperReports have been integrated with Oracle Applications. Users can handle the 

report results in a simple manner and choose the tools for subsequent report editing (MS 

Word, MS Excel, etc.) 

1. UVOD 

Poznata je izreka ''Informacija je znanje''. Izreka engleskog filozofa i znanstvenika 

Francisa Bacona glasi ''Znanje je moć''. Iz toga proizlazi da ''Informacija je moć''. U 

suvremenom poslovnom svijetu ova izreka sve više dobiva na važnosti. Brze i pravilne odluke 

oslanjaju se na informacije koje su u danom trenutku na raspolaganju. Uspješne tvrtke se od 

drugih razlikuju prvenstveno po tome što se na promjene u okruženju najbrže odazivaju, a 

neke i diktiraju promjene. Time se povećavaju potrebe za suvremenim informacijskim 

sustavom. Shodno tome od informacijskog sustava se očekuje da na adekvatan način 

odgovori potrebama tržišta. 

2. ZAŠTO 

2.1. Potrebe trţišta 

Navedena su tri primjera iz prakse zbog kojih smo se odlučili na integraciju 

JasperReportsa s Oracle aplikacijom. 

1. Kreiranje velikog broja sličnih izvještaja, grafičkih izvještaja i izvještaja raznih formata 

2. Kreiranje velikih izvještaja(> 50000 stranica) 

3. Slanje izvještaja u PDF formatu na elektroničku poštu ili dokumentacijski sustav 

Korisnik također zahtjeva da određena izvješća imaju i napredne grafičke, oku ugodne 

elemente. Zbog nedostataka ili kompliciranosti izvedbe ovih potreba pomoću Oracle Reports 

Buildera, potrebno je potražiti alternativno rješenje. U ovom trenutku na tržištu postoji također 

i veliki broj engina za izvješćivanje. 

137 

1

Za odabir alternativnog korišteni su sljedeći kriterij: 

Mogućnost uklapanja u postojeće Oracle 6i aplikacije 

Mogućnost uklapanja u OAS aplikacije 

Veličina community-a 

Cijena 

Otvorenost izvornog koda 

Frekvencija izdavanja novih inačica 

Performanse 

Dokumentacija i literatura 

Nakon završenog istraživanja te stvarnog testiranja nekoliko report engina odabralo se 

JasperReport kao report engina u kojemu će se pojedini izvještaji ubuduće kreirati. 

2.2. JasperReports općenito 

JasperReportsi su report engine za izradu izvješća, open source je i besplatan je. 

Izrađeni su Javi. Osim klasičnog prikaza izvještaja na monitor i printer, omogućuje i kreiranje 

izvještaja u raznim formatima kao što su PDF, HTML, MS Excel, RTF, ODT, CSV i XML. 

Osnovna prednost JasperReportsa je ta što je definicija reporta otvorena specifikacija. Izvorni 

kod izvješća za Jasper engine je XML datoteka nazvana JRXML. Dok je izvršna datoteka 

kompajlirane JRXML datoteke java klasa. 

select 

xmlElement("jasperReport", 

XMLAttributes( 

'http://jasperreports.sourceforge.net/jasperreports' AS "xmlns", 

'595' AS "pageWidth", 

'842' AS "pageHeight" 

) 

) 

from dual 

Rezultat: 

 

 

S obzirom da je izvorna datoteka XML datoteka postoji mogućnost da se lako kreira dinamički 

iz PL/SQL koda i to u starijim verzijama baze kao CLOB varijabla dok u novim verzijama baze 

pomoću Oracle xml funkcija kao što su xmlElement, xmlAgg, ... Tako generirana varijabla tipa 

xmlType moguće je direktno iz baze i validirati po shemi (.XSD) koja je također spremljena u 

bazi podataka. 

138 

2

Stvorenu JRXML datoteku moguće je u runtime-u i kompajlirati, napuniti podacima i pretvoriti 

u datoteku PDF, XLS, HTML,.. formata. I to iz na primjer Oracle Formsa ukoliko se uvezu 

Java klase u formu. Budući da je naš cijeli sustav napravljen u Oracle Forms tehnologiji ovo 

se pokazalo idealnim u našem slučaju, pa smo pristupili integraciji. 

... 

/* 

Nova instanca JsperReporta iz datoteke 

*/ 

jasperReport = JasperCompileManager.compileReport(jrxmlDatoteka); 

... 

/* 

Pokretanje reporta (konekcija na BD) 

*/ 

jasperPrint = JasperFillManager.fillReport(jasperReport, new HashMap(), connection); 

... 

/* 

Kreiranje datoteke u odabranoj extenziji 

*/ 

JasperExportManager.exportReportToPdfFile(jasperPrint, (putanja + imeDatotekeBezExtenzije + "." + 

ExtenzijaDatoteke)); 

... 

2.3. Općenito o integraciji 

Integracija je dolazila u obzira samo ako se zadovolje sljedeći uvjeti: 

Ne smije imati dodatne zahtjeve za hardware resursima; 

Korisnik integracijom mora dobiti najmanje onoliko koliko je i do sada imao 

postojećim izvještajima; 

Pokretanje izvješća mora biti omogućeno na jednak način kao i to sada (poziv 

direktno iz menija aplikacije, poziv iz postojećeg sustava za pokretanje izvješća); 

Integracija ne smije bitno mijenjati postojeću infrastrukturu 

Kako bi se omogućila integracija Oracle aplikacija i JasperReportsa bili su potrebni sljedeći 

koraci prema okolinama: 

6i 

10g 

Java Runtime Enviromet verzija 1.4 ili viša instalirana kod korisnika na lokalnom 

računalu; 

Konfigurirana classpath varijabla; 

Ugrađen OAS-ov JRE; 

Konfigurirane konfiguracijske datoteke; 

Za posebne slučajeve i konfiguriran Java Virtual Machine kontrole u Oracle 

Enterprise Manageru; 

2.4. Problemi pri integraciji 

Prilikom integracije naišlo se na sljedeće tehničke probleme: 

Konfiguracija JVM kontrolera u Oracle Enterprise Manageru; 

139 

3

Konfiguracija je uspješno izvršena nakon konzultacija sa Oracle supportom. 

Konfiguracija bila je potrebna kako se bi se moglo utjecati na parametre pokretanja 

JVM-a kao što su Xms i Xmx. 

Praćenje izvršavanja izvješća, te odustajanje od izvješća na zahtjev korisnika; 

Pri pokretanju Oracle Reporta korisniku na ekranu se prikazuje status izvršenja 

(ukupan broj stranica za formatiranje, trenutni broj stranice koji se formatira). 

Korisniku se omogućuje da na zahtjev i prekine proces formiranja izvještaja. 

U kompletnoj integraciji, prikazivanje statusa izvršenja korisniku na ekran u vremenu 

između pokretanja JasperReport izvještaja te prikaz izvještaja na ekran predstavljalo 

je najveći izazov. 

JasperReport Api sadrži metode za dohvat trenutne stranice u obradi i ukupnog broja 

stranica. 

Međutim bilo je potrebno pokrenuti izvještaj u posebnom thread-u da bi oracle 

procedura koja je pozvala JasperReport mogla završiti te timerom u oracle formsima 

moglo u malim vremenskim intervalima pozvati metode koje vraćaju broj stranice koji 

se formira i ukupan broj stranica, te tako te informacije prikažu korisniku na ekran u 

obliku progress bara. Uz to pozivanje izvještaja u posebnom thred-u omogućilo je da 

se na zahtjev korisnika (Pritisak na gumb) zaustavi formiranje izvješća jednako kao i 

kod Oracle Reportsa. 

Pokretanje oracle procedura prije pokretanja selecta izvještaja 

3. KAKO 

Određeni postojeći Oracle Reports izvještaju pokreću procedure koje pune ili 

pripremaju podatke koje izvještaj dohvaća. U Oracle Reportsima je to jednostavno 

riješeno pozivanje procedura u triggerima kao što su AFTER PARAMETER FORM ili 

BEFORE REPORT 

U JasperReportsima je stvar nešto složenija, što nas je natjeralo da povećamo 

mogućnosti našeg API-a za pokretanje JasperReporta na način da se omogući 

pozivanje Oracle procedura i prijenos parametra u iste prije pokretanja izvještaja u 

istom Oracle database session u kojemu će JasperReportsi izvršiti select naredbu. 

3.1. Dinamički izvještaji 

Korisnici imaju potrebu za kreiranjem više gotovo identičnih izvještaja, koji se razlikuju u 

malom broju podataka. Ukoliko se za svaki izvještaj kreira posebno, javlja se veliki broj 

gotovo identičnih izvještaja i time se njihovo održavanje komplicira te korištenje korisnicima 

otežava posao jer se moraju snalaziti u moru sličnih izvještaja. 

Ideja je napraviti jedan izvještaj koji bi pokrio veliku većinu potreba. Izrada jednog takvog 

izvještaja je komplicirana, a samim time bi se kompliciralo i njegovo održavanje. 

Druga ideja je napraviti ekran i omogućiti korisnicima da samostalno kreiraju željeni izvještaj. 

Oracle Reports Builder se pokazao krut za takvu manipulaciju samim izvještajem. 

JasperReports-i su se pokazali fleksibilniji po tom pitanju. 

JasperReportsi su zbog otvorenosti i jednostavnosti source koda idealni po tom pitanju. 

Korištenje Oracle Formsa kao alata kojim korisnicima omogućuje da ima veću slobodu 

definiranja izgleda izvještaja i podataka koje želi vidjet zajedno s integracijom s 

JasperReportsima pokazalo se kao odlična kombinacija. Takvoj fuziji Oracle Formsa i 

JasperReporta omogućili smo korisniku da definira mnogo više značajki izvještaja kao što su: 

140 

4

Kolone koje ga zanimaju – redoslijed, širinu, labelu, sortiranje, font, veličinu fonta i 

boje, grupna funkcija na koloni... 

Grupiranje – korisnik sam odabire po kojim kriterijima želi grupirati podatke 

Parametre – korisnik sam određuje koje parametre želi koristiti, a koje zanemariti 

Format – širinu i veličinu izvještaja, orijentaciju 

Ostalo – želi li logotip i koji na izvještaju, margine, redni broj ispred zapisa, kada se 

redni broj resetira, da li se na zadnjoj stranici ispisuju parametri, vrijeme pokretanja, 

korisnik broj stranica,... 

Izlazni format izvješća – PDF, DOC, XLS,HTML,... 

Slika I. Prikaz ekrana za definiciju fontova 

Slika II. Prikaz ekrana za definiciju kolona 

141 

5

3.2. Veliki izvještaji 

Slika III. Prikaz integracije 

Zbog potreba arhiviranja podataka o poslovanju, javila se potreba kreiranja izvještaja o 

poslovanju tijekom cijele godine. Budući da je izvještaj sadržavao poslovanje tijekom velikog 

vremenskog razdoblja imao je veliki broj stranica. Tu se javio problem da se pri kreiranju 

izvještaja u PDF formatu Builder zatvarao bez upozorenja o grešci na određenom broju 

stranica, dok se HTML format uspješno izvršio. Razlog tome je što kada se kreira izvještaj u 

PDF formatu sve stranice izvještaja se kreiraju u memoriji pa tek nakon što se kreiraju one se 

pokazuju na izlazu. Ovo uzrokuje potrebu za povećanjem memorije. 

Poučeni ranijim iskustva možemo reći da kreiranje velikih izvještaja u Reports Builderu ne 

predstavlja problem. Određena izvješća nakon generiranja u PDF formatu bez problema 

prelaze i 200Mb. Međutim u određeno situaciji zadani izvještaj u 6i verziji se nije mogao 

izvršiti bez obzira na učinjen tuning. U drugom konkretnom slučaju nije se išlo u analizu 

razlog „pucanja“ jer je okolina za integraciju JasperReport izvještaja već bila postavljena te je 

izvještaj prepisan u Jasper varijantu, te kao takav se bez problema izvodio i generirao PDF 

veći od 300 Mb, odnosno prema riječima JasperReports tima moguće je napraviti i izvješća 

veliko koliko ima i slobodnog mjesta na disku. 

Proces integracije dobiva se na način da se kreira jednak izvještaj koristeći JasperReport te 

komajliranu verziju jrxml (jasper) sprema na isto mjesto kao i REP datoteke. U pll-u forme su 

uvezene Java klase koje služe kao wrapper za pozivanje JasperReport API-a. Korisnik na 

lokalnom računalu u ovom slučaju mora imati instaliranu JVM. Sada se iz svih Oracle formi 

koje mogu pozivati Jasper izvještaji. 

Sada se iz svih Oracle formi koje mogu pozivati Jasper izvještaji iz postojećih Oracle 

aplikacija it to na način da korisnik će teško primijetiti razliku. 

142 

6

Slika IV. Prikaz integracije 

3.3. Slanje PDF izvještaja elektroničkom poštom ili u Dokumentacijski sustav 

Zbog novonastale potrebe da se prilikom pokretanja Oracle joba kreira PDF dokument te 

s njim dalje manipulira integrirali smo Jasper report engine s Oraclom bazom. 

Postoje dvije konkretne situacije koje je bilo potrebno riješiti: 

1. Da procedura koju poziva oracle job može kreirati PDF datoteku, te sa se kreirana 

datoteka pošalje elektroničkom poštom 

2. Da procedura koju poziva oracle job može kreirati PDF datoteku, te sa se kreirana 

datoteka spremi u dokumentacijski sustav 

Rješenje koje smo kreirali je zamišljeno da u bazi kreiramo PDF dokument, i onda tako 

kreirani PDF pošaljemo e-mailom. PL/PDF je programski paket koji omogućava kreiranje PDF 

dokumenta direktno u bazi. PL/PDF omogućava da se dinamički kreira PDF dokument s 

podacima iz baze. Pisan je u PL/SQL-u i također omogućava pohranu PDF dokumenta 

direktno u bazu. Budući da se radilo o izoliranom slučaju od PL/PDF smo odustali zbog cijene 

licence kao i zbog toga što nam se učinio kompliciranim za upotrebu. Na slici je kao primjer 

naveden kod za brojanje stranica i krajnji rezultat izvršenja tog koda. 

Slika V. Prikaz koda potrebnog za kreiranje brojanja stranica u PDF formatu preko PL/PDF paketa 

143 

7

3.4. Način integracije 

Oracle job pokreće baznu procedura koja generira JRXML datoteku. Tako kreiranu 

datoteku se pozivom web servisa iz baze šalje aplikacijskom serveru koja ima konfiguriran 

Jasper report engine. 

Jasper report engine kompajlira JRXML datoteku u izvršnu datoteku (.jasper) te pokreće i 

exportira u PDF datoteku. 

Novostvorenu PDF datoteku vraća kao response na web service. 

Procedura koja je pozvala web servis i poslala JRXML datoteku dobiva kao response PDF 

koje u jednoj situaciji šalje elektroničkom poštom, dok u drugoj situaciji pozivom web servisa 

sprema u dokumentacijski sustav. 

Slika VI. Prikaz integracije 

3.5. Izvješća s naprednim grafičkim elementima 

Određena izvješća moraju sadržavati napredne grafičke elemente i da istovremeno 

izgledaju moderno i oku ugodno. 

U tom slučaju izvješće se kreira u alatu (na primjer iReport) te se izvršna datoteke sprema na 

disk zajedno sa REP datotekama, te se integracijom takva izvješća mogu pozivati iz već 

postojećeg sustava za pokretanje Oracle izvješća uz manje preinake. 

144 

8

Slika VII. Primjer grafičkih izvještaja 

145 

9

4. ZAKLJUČAK 

Integracijom JasperReportsa s postojećim Oracle Aplikacijama smo zadržali postojeću 

funkcionalnost ekrana. Krajnji korisnik nije svjestan promjena tehnologije izrade izvještaja, 

prepoznaje minimalne promjene i kao takve ih lako prihvaća. Izgled izvještaja kao i njegovo 

pozivanje je nepromijenjeno. 

Integracija je od integratora tražila: 

Spajanje Oracle PL/SQL-a s javom; 

Konfiguriranje Client/Server i OAS okruženja; 

Nadogradnju postojećeg sustava za pozive izvješća; 

Poznavanje JRXML-a; 

Poznavanje JasperReports API-a. 

Integracijom smo omogućili korisniku: 

Izbor podataka koje žele prikazati na izvještaju ovisno o osobnim poslovnim 

potrebama; 

Manipulaciju izgledom samog izvještaja; 

Odabir formata izvještaja; 

Modernije grafičke izvještaje; 

Složenije daljnje radnje sa izvještajem kao npr. spremanje u dokumentacijski sustav. 

146 

10

SAŽETAK 

ISŽO-ADS: INTEGRACIJA TRANSAKCIJSKOG SUSTAVA 

S DOKUMENTACIJSKIM SUSTAVOM 

dr. sc. Andro Milanović 

Ami-Program d.o.o. 

+385-91-626-2450 

andro.milanovic@zg.t-com.hr 

mr. sc. Ivan Žiger 

Croatia osiguranje d.d. 

+385-91-1454-106 

ivan.ziger@crosig.hr 

Transakcijski sustav ISŽO (Informacijski Sustav za Životna Osiguranja) razvijen je kao potpora 

poslovnim procesima životnih osiguranja. Sustav je zasnovan na Oracle Forms i ostalim Oracle 

tehnologijama, koristi troslojnu arhitekturu te je u uporabi više godina. Učinkovito poslovanje 

zahtijevalo je uvođenje elektroničkog upravljanja dokumentacijom. Za implementaciju Arhivskodokumentacijskog 

sustava (ADS) odabran je sustav vanjskog partnera zasnovan na Java 

tehnologijama. Implementirani ADS potpuno je prilagođen potrebama korisnika, integriran u sustav 

ISŽO te se nalazi u produkcijskoj uporabi već 20 mjeseci. U radu se opisuju procesi razvoja, 

arhitektura sustava ISŽO-ADS i tehnološka rješenja za povezivanje raznorodnih podsustava. 

SUMMARY 

Transactional system ISŽO (Informacijski Sustav za Životna Osiguranja) comprises the 

application core for support of business processes of life insurance. The system is based on Oracle 

Forms, uses a three-tiered architecture and has been in use for years. A new business requirement 

was to implement a document management system (DMS). The implementation of the system ADS 

(Arhivsko-dokumentacijski sustav) was given to a partner company, which offered its Java-based 

DMS. The implemented system has been fully tuned to the users’ needs, integrated with ISŽO, and 

has been in production use for 20 months. This paper describes the development processes, 

architecture of ISŽO-ADS, and the technological solutions for integrating heterogeneous subsystems. 

1. UVOD 

Sustavi za upravljanje dokumentima (DMS, Document Management System) prisutni su u 

računarstvu više od 20 godina. Njihov razvoj započeo je stvaranjem prvih sustava namijenjenih 

praćenju stanja papirnatih dokumenata. Ubrzo su se pojavili i EDM (Electronic Document 

Management) sustavi koji su, za razliku od početnih sustava, omogućavali pohranu i čuvanje 

elektroničkih dokumenata. Povećanjem računalnih kapaciteta, širenjem primjena računalnih mreža i 

povećanjem međusobne suradnje djelatnika u tvrtkama, pojavila se potreba dijeljenja dokumenata te 

potreba za sve složenijim dokumentacijskim sustavima. 

Dugogodišnjim razvojem sustavi za upravljanje dokumentima postigli su brojne napredne 

mogućnosti poput suradnje i interaktivnog rada više korisnika na dokumentu, naprednih sigurnosnih 

zaštita i postavki, upravljanja radnim tijekom zasnovanim na dokumentima, nadzora životnog ciklusa 

dokumenta ili praćenja izmjena dokumenta. Nadalje, s vremenom je proširen i skup objekata kojima 

DMS sustavi upravljaju pa su tako nastali sustavi za upravljanje sadržajem (CMS, Content 

Management System). Uz dokumente, takvi sustavi upravljaju i raznim drugim sadržajima poput slika, 

Internet stranica, video i audio snimaka, kontaktnih podataka i drugih vrsta zapisa. Na osnovi CMS 

sustava, nastali su i suvremeni ECM (Electronic Content Management) sustavi, čija je namjena 

upravljanje svim vrstama nestrukturiranih informacija u srednjim i velikim tvrtkama. 

Većinu područja primjene DMS sustava čini upravljanje dokumentima i informacijama koje 

nastaju u unutarnjem poslovanju tvrtke ili u odnosima s drugim tvrtkama i tijelima državne uprave. U 

147 

1

pojedinim područjima primjene pojavljuju se velike količine dokumenata i u odnosima između 

organizacije i njenih stranaka. Primjeri takvih područja su financijske institucije i osiguravajuće kuće. 

Suvremeni sustav za upravljanje dokumentima može znatno unaprijediti poslovanje takvih 

organizacija. Kod organizacija koje razmjenjuju velike količine dokumenata sa svojim strankama, 

dokumenti su integralni dio poslovnih procesa, a često čine i osnovu cijelih procesa, pokretački signal 

ili rezultat izvođenja procesa. U navedenim je okolinama jedan od osnovnih preduvjeta uspjeha 

dokumentacijskog sustava potpuna i bešavna integracija DMS-a u poslovne procese organizacije te u 

sve poslovne aplikacije. 

Slijedeći suvremene trendove, kako općenito u IT sektoru, tako i trendove u području osiguranja, 

Croatia osiguranje d.d. odlučila je uvesti sustav za upravljanje dokumentima u svoje poslovanje. Kao 

izvođač implementacije Arhivsko-dokumentacijskog sustava (ADS), odabrano je partnerstvo agencije 

FINA i tvrtke Synerva IT d.o.o. Agencija FINA implementirala je sustav za upravljanje ulazom 

dokumenata, provela digitalizaciju postojeće arhive fizičkih dokumenata te preuzela zadaću 

arhiviranja fizičkih dokumenata. Tvrtka Synerva IT ponudila je svoj sustav za upravljanje 

dokumentima, implementirala dodatne module prema zahtjevima i potrebama Croatije osiguranja te 

integrirala sustav ADS u postojeće poslovne procese i aplikacijske sustave. 

Referat opisuje cjeloviti proces implementacije Arhivsko-dokumentacijskog sustava, od analize 

poslovnih procesa i snimanja korisničkih zahtjeva, preko tehničke implementacije sustava, do 

konačnog postavljanja sustava u produkcijski rad. Opisani su problemi koji su se pojavili tijekom 

snimanja poslovnih procesa i korisničkih zahtjeva te rješenja kojima su problemi otklonjeni. Naveden 

je pregled implementacije samog sustava koji uključuje arhitekturu i oblikovanje sustava, značajke 

programskog ostvarenja te pregled postupka uvođenja sustava u produkcijski rad. Konačno, opisani 

su rezultati projekta i njegova uspješnost. 

2. OSNOVNE ZNAČAJKE PROJEKTA 

Implementacija Arhivsko-dokumentacijskog sustava povjerena je tvrtkama FINA i Synerva IT 

koje su zajedno ponudile cjelovito rješenje za upravljanje dokumentima i arhiviranje. Tijekom definicije 

opsega projekta i ciljeva utvrđen je plan uvođenja dokumentacijskog sustava po sektorima Croatije 

osiguranja (CO). Uvođenje po sektorima odabrano je kako bi se rizici za cjelokupni projekt umanjili 

putem segmentacije složenog sustava u manje, djelomično neovisne dijelove. Nadalje, iskustva 

dobivena tijekom implementacije sustava u prvom sektoru, koristit će se u daljnjem oblikovanju 

sustava i prilagođavanju korisničkim zahtjevima. Pritom je bilo nužno osigurati da cjelovita 

programska i sklopovska arhitektura te podatkovni modeli, uzmu u obzir i buduće sektore u kojima će 

se implementirati ADS. 

Tijekom definicije projekta zadani su osnovni parametri ADS-a. Naveden je osnovni skup 

funkcionalnosti koje sustav mora ponuditi i stupanj povezanosti s postojećim informacijskim 

sustavima CO. Definirana je potreba za potporu digitalizaciji fizičkih, papirnatih dokumenata koji se 

stvaraju u poslovanju i u odnosima s klijentima. Određeno je da digitalizaciju takvih dokumenata 

provode djelatnici CO u okviru izvođenja redovnih poslovnih procesa. Nadalje, utvrđena je potreba za 

naknadnom digitalizacijom postojeće dokumentacije, odnosno dokumentacije koju CO čuva u svojim 

arhivima i koja je nastala prije uvođenja dokumentacijskog sustava. 

Za prvi sektor projekta uvođenja ADS-a odabran je Sektor životnih osiguranja. Sektor životnih 

osiguranja prosječne je veličine unutar osiguravajuće kuće. Važno obilježje sektora je da se tijekom 

obrade polica osiguranja stvara značajna količina dokumenata vezanih uz police. Dio dokumentacije 

stvara sama osiguravajuća kuća, no najveći dio dokumentacije čine vanjski dokumenti koje prilaže 

stranka, tijela državne uprave i druge institucije. Dokumentaciju životnih osiguranja potrebno je čuvati 

tijekom cijelog trajanja police te arhivirati dodatnih 10 godina nakon isteka. Iako je učestalost pristupa 

dokumentima relativno niska, tijekom čitavog trajanja police potrebno je omogućiti pristup svoj 

dokumentaciji. Konačno, jedan od presudnih motiva za odabir Sektora životnih osiguranja bio je visok 

stupanj informatiziranosti sektora kroz poslovni aplikacijski sustav ISŽO. 

Na temelju postojećih iskustava i poznatih negativnih primjera neuspjelih projekata uvođenja 

dokumentacijskih sustava, definirane su osnovne smjernice za implementaciju ADS-a i rizici za 

uspješnost projekta. Kao najveći rizici identificirani su neadekvatnost dokumentacijskog sustava za 

primjenu u poslovnim procesima te neprihvaćanje od strane krajnjih korisnika. Analizom poslovanja 

Sektora životnih osiguranja, utvrđeno je da samostojeći, odnosno izdvojeni dokumentacijski sustav 

neće odgovarati potrebama poslovnih procesa, usporavat će djelatnike Sektora te će potencijalno 

izazvati njihove negativne reakcije. Budući da je jedna od strateških smjernica dobra prihvaćenost 

sustava kod krajnjih korisnika, odlučeno je da se sustav za upravljanje dokumentima i njegovo sučelje 

u potpunosti integriraju s poslovnim procesima i aplikacijom ISŽO. Navedenim pristupom željelo se 

148 

2

osigurati uklapanje dokumentacijskog sustava u poslovne procese, ostvariti znatne vremenske uštede 

pri radu korisnika koji ne moraju koristiti dvije odvojene aplikacije i, konačno, stvoriti pozitivan stav 

krajnjih korisnika koji nove funkcionalnosti mogu koristiti unutar već poznatog im sučelja. 

Odabir integriranog pristupa implementaciji ADS-a značajno je smanjio rizike projekta, no 

istovremeno je osjetno povećao složenost procesa implementacije. Zbog očekivane velike složenosti, 

pristupilo se detaljnom definiranju projektnog plana i implementacijskog procesa. Implementacijski 

proces podijeljen je u pet ključnih faza prikazanih na slici 1. 

Slika 1: Faze implementacijskog procesa 

Tijekom planiranja projekta pažljivo su odabrani ključni sudionici projekta i voditelji pojedinih 

izvedbenih faza. S obzirom da su u implementaciji projekta sudjelovale tri neovisne tvrtke te više 

odjela unutar Croatije osiguranja, bilo je nužno ostvariti učinkovitu komunikaciju i kvalitetnu 

koordinaciju unutar projekta. Tijekom izvođenja projekta implementacije Arhivsko-dokumentacijskog 

sustava pokazalo se da su učinkovita komunikacija i koordinacija imale presudan značaj na pojedine, 

kritične točke i faze izvođenja projekta. 

3. IMPLEMENTACIJSKI PROCES 

Implementacijski proces započeo je detaljnim snimanjem postojećeg stanja poslovnih procesa, 

nakon čega su definirane izmjene u procesima uvjetovane uvođenjem dokumentacijskog sustava. 

Sljedeća faza sastojala se od detaljnog snimanja tehničkih značajki aplikacijskog sustava ISŽO i 

tehnologije Oracle Forms kako bi se integracija uspješno ostvarila i s tehničke strane. Nakon 

opsežnih pripremnih radnji, pristupilo se definiranju arhitekture, programskom ostvarenju i izgradnji 

samog sustava. 

Uz izvođenje implementacije novog sustava, u okviru projekta bilo je potrebno digitalizirati 

postojeću arhivu dokumenata i dobivene digitalne dokumente indeksirati i učitati u dokumentacijski 

sustav. Digitalizacija dokumenata odvijala se paralelno s fazama planiranja i implementacije sustava 

radi optimalnog iskorištavanja dostupnih sredstava i uštede vremena. Unatoč tome, bilo je nužno 

osigurati određene koordinacijske točke kako bi digitalizirana dokumentacija bila dostupna 

djelatnicima CO i prije uvođenja dokumentacijskog sustava u produkcijski rad. 

Konačno, sam postupak uvođenja ADS-a u produkcijski rad također je pažljivo planiran. 

Napravljeni su planovi za postupanje s dokumentacijom tijekom prijelaznog razdoblja kao i plan 

digitalizacije dokumenata iz prijelaznog razdoblja. Konačno, izrađeni su planovi testiranja sustava, 

detaljna korisnička dokumentacija i edukacijski plan. U nastavku poglavlja podrobnije su opisane 

pojedine faze procesa implementacije, osim same faze izgradnje ADS-a koja je zajedno s tehničkim 

detaljima opisana u zasebnom poglavlju. 

149 

3

3.1. Definiranje poslovnih procesa 

U početnoj fazi projekta provedeno je snimanje poslovnih procesa. Osnovni razlog snimanja bilo 

je stvaranje pretpostavki za učinkovitu integraciju dokumentacijskog sustava i usklađivanje s 

potrebama korisnika. Snimanje poslovnih procesa provela je Synerva u suradnji s djelatnicima 

Sektora životnih osiguranja Croatije osiguranja. Croatia osiguranje certificirana je prema standardu 

ISO 9001 te su stoga svi poslovni procesi dokumentirani, a tijekom snimanja su korištene i službene 

upute za djelatnike sektora. Tijekom procesa snimanja identificirano je nekoliko desetaka poslovnih 

procesa koji uključuju rukovanje dokumentacijom. Nakon pripremnih radnji, djelatnici Synerve 

analizirali su dobivene dijagrame, dokumentaciju poslovnih procesa i upute za djelatnike te prema 

dobivenim informacijama pripremili sažeti pregled poslovnih procesa. Potom su provedene detaljne 

konzultacije s djelatnicima Sektora kako bi se pouzdano utvrdilo poklapanje dokumentacije sa 

stvarnim procesima te kako bi se dodatno razjasnili detalji poslovnih procesa važni za rukovanje 

dokumentacijom. 

Nakon stvaranja pregleda postojećih procesa, pristupilo se definiciji novih poslovnih procesa koji 

uključuju rukovanje elektroničkim dokumentima primjenom ADS-a. U proces definicije novih procesa, 

uz djelatnike Synerve i Sektora životnih osiguranja, uključeni su i djelatnici Službe za informatiku. 

Definiranje novih procesa uključivalo je prilagodbu postojećih procesa novom sustavu, definiranje 

novih postupaka rukovanja dokumentacijom te definiranje više aspekata organizacije dokumenata 

prema njihovoj namjeni, životnom ciklusu police, kategoriji, podružnici, itd. Stoga su, istodobno s 

definicijom procesa, izrađeni i dokumenti koji opisuju korisničke zahtjeve. 

Definicija novih poslovnih procesa s korisnicima pokazala se iznimno zahtjevnom. Pojedini 

korisnici nisu mogli predočiti izgled budućeg sustava i način rukovanja dokumentima. Nadalje, 

probleme je predstavljala i prevelika razina detalja te deseci poslovnih procesa u Sektoru životnih 

osiguranja koji su, iako slični u svojoj strukturi, načelno različiti prema sadržaju. U otklanjanju 

nastalog zastoja znatan doprinos dali su djelatnici Službe za informatiku prijedlogom da se deseci 

detaljnih procesa zamijene znatno manjim brojem pojednostavljenih, apstraktnih procesa. Svaki 

apstraktni proces predstavlja jednu čitavu kategoriju poslovnih procesa, a izbačeni su svi detalji 

nebitni za upravljanje dokumentima. Ukupno su definirane tri osnovne aktivnosti koji se pojavljuju u 

radu s policama životnog osiguranja: prodaja police, obrada police i obrada prijavljene štete. 

Izradom pojednostavljenih apstraktnih procesa uspješno su prevladani nastali problemi te su na 

njihovoj osnovi definirani i novi procesi za rukovanje dokumentima primjenom ADS-a. Nakon toga, 

završeno je definiranje korisničkih zahtjeva te su stvoreni i prototipi korisničkog sučelja. Na osnovi 

prototipa sučelja, djelatnici poslovnog sektora mogli su lakše predočiti izgled budućeg sustava te dati 

svoje mišljenje i prijedloge. Jedan od prijedloga koje su dali korisnici jest primjena crtičnog kôda (engl. 

bar code) u cilju olakšavanja digitaliziranja i indeksiranja dokumenata. Izvođači projekta ispravno su 

uočili vrijednost prijedloga te je on prihvaćen i uvršten u skup korisničkih zahtjeva. 

Uz navedeno, izrađena je i testna dokumentacija čijim prihvaćanjem korisnici potvrđuju da sustav 

zadovoljava njihove potrebe. Kao konačni rezultat opisanog procesa dobiven je niz projektnih 

dokumenata kojima se definiraju novi poslovni procesi, korisnički zahtjevi i postupci testiranja. Prije 

pristupanja samoj implementaciji, provedena je i verifikacija izrađenih dokumenata s poslovnim 

sektorom i informatičkom službom. 

3.2. Snimanje tehničkih značajki 

Nakon definiranja novih poslovnih procesa, izvođenje projekta nastavljeno je snimanjem 

tehničkih značajki postojećih sustava Croatije osiguranja. Snimanje tehničkih značajki provela je 

Synerva u suradnji s djelatnicima sistemske i aplikacijske grupe Sektora za informatiku. S 

djelatnicima sistemske grupe utvrđena je arhitektura postojećih sklopovskih sustava, sustava baze 

podataka, aplikacijskog poslužitelja te sustava za autentikaciju i autorizaciju korisnika zasnovanog na 

Microsoftovom Active Directoryu. Nadalje, definirane su i potrebe za novim poslužiteljima za 

Arhivsko-dokumentacijski sustav te tehničke značajke poslužitelja i uvjeti nabave. Konačno, 

definirana su prava pristupa pojedinim sustavima CO i pripremljeni su odgovarajući korisnički računi 

za razvijatelje. Sistemska grupa je potom samostalno pristupila postupku nabave potrebne opreme te 

konfigurirala i postavila sve poslužitelje. 

Snimanje značajki sučelja, funkcionalnosti i podatkovnog modela aplikacije ISŽO provedeno je u 

suradnji Synerve i aplikacijske grupe. Zbog velike složenosti podatkovnog modela i brojnosti 

ugrađenih funkcionalnosti, za potrebe implementacije Arhivsko-dokumentacijskog sustava stvoren je 

pojednostavljeni model. Umjesto predaje cijelog podatkovnog modela djelatnicima Synerve, definiran 

je skup indeksnih podataka dokumenata i potom su dogovorene dodirne točke između baze podataka 

ISŽO i dokumentacijskog sustava. Nadalje, identificirane su funkcionalnosti i logičke cjeline sučelja 

150 

4

aplikacije ISŽO koje su povezane s rukovanjem dokumentacijom i koje mogu biti iskorištene za 

integraciju s ADS-om. Jedna od zanimljivosti procesa snimanja tehničkih značajki jest da su u 

suradnji s djelatnicima aplikacijske grupe pojašnjeni pojedini detalji poslovnih procesa pa čak i 

ispravljene određene pogreške i netočne pretpostavke. Navedeno je posljedica čvrste povezanosti 

između aplikacijske grupe i krajnjih korisnika sustava na terenu. 

Na temelju snimljenog stanja pristupilo se izradi tehničkog dijela projektne dokumentacije. 

Definirani su podaci koje je potrebno izmjenjivati između baze podataka ISŽO i dokumentacijskog 

sustava te je dogovorena razmjena podataka putem pozivanja pohranjenih potprograma (engl. stored 

procedures). Precizno su definirani i dokumentirani svi prototipovi pohranjenih potprograma. Nadalje, 

utvrđeno je da je za autentikaciju i autorizaciju korisnika ADS-a znatno povoljnije koristiti postojeće 

mehanizme u aplikaciji ISŽO, umjesto Active Directorya. Stoga su definirani i potprogrami za 

autorizaciju korisnika u dokumentacijskom sustavu. Konačno, specificirane su točke integracije ADSa 

u korisničko sučelje aplikacije ISŽO. Utvrđeni su način povezivanja, programska sučelja i tehnički 

parametri pozivanja. Rezultat procesa snimanja tehničkih značajki jest skup dokumenata projektne 

dokumentaciju koji definiraju sučelja i podatkovne strukture za povezivanje aplikacije ISŽO i Arhivskodokumentacijskog 

sustava. 

3.3. Digitalizacija postojeće dokumentacije 

Jedan od osnovnih zadataka projekta uvođenja Arhivsko-dokumentacijskog sustava u 

poslovanje Sektora životnih osiguranja bila je digitalizacija postojeće dokumentacije. U skladu sa 

zakonskim zahtjevima, Croatia osiguranje je i prije uvođenja ADS-a pohranjivala svu dokumentaciju 

polica životnog osiguranja u fizičkom obliku. Stoga je bilo potrebno digitalizirati svu postojeću 

dokumentaciju i učitati je u dokumentacijski sustav. Digitalizaciju dokumentacije provela je FINA, 

odnosno njezin odjel ADC (Arhivsko Dokumentacijski Centar). Prilikom digitalizacije dokumenata 

provedeno je i njihovo indeksiranje kako bi se dokumenti kasnije mogli uspješno učitati u 

dokumentacijski sustav i ispravno povezati s podatkovnim strukturama sustava ISŽO. Indeksiranje je 

provedeno ručno te je stoga u suradnji s djelatnicima CO bilo potrebno provesti podrobnu analizu 

vrsta dokumenata, njihove kategorizacije i sadržaja. Nakon analize, definirani su indeksni podaci i 

potom je osoblje ADC-a obučeno za pravilno rukovanje dokumentima i indeksiranje. 

Pored digitalizacije i indeksiranja, FINA je preuzela i arhiviranje fizičkih dokumenata te je stoga 

dokumentacija nakon digitalizacije odmah pohranjivana u arhivima FINA-e. Samo odvijanje procesa 

preuzimanja dokumentacije i njene digitalizacije bilo je pažljivo planirano. Proces je vremenski trebalo 

uskladiti s implementacijom Arhivsko-dokumentacijskog sustava tako da sva postojeća dokumentacija 

bude digitalizirana i indeksirana do trenutka kada će ADS biti pušten u produkcijski rad. Budući da je 

FINA postupno preuzimala dokumentaciju iz Croatije osiguranja bilo je potrebno pronaći i prijelazno 

rješenje putem kojeg bi djelatnici CO pristupali digitaliziranim dokumentima. Za prijelazno rješenje 

tvrtka Synerva osigurala je pojednostavljenu verziju starije inačice svog dokumentacijskog sustava u 

koji su učitani digitalizirani dokumenti zajedno s njihovim osnovnim indeksnim podacima. 

U prijelaznom razdoblju tijekom kojeg su podružnice postupno prelazile na rad s 

dokumentacijskim sustavom bilo je potrebno riješiti i problem digitalizacije postojeće dokumentacije 

koja nije stvorena u okviru novih poslovnih procesa. Iako u novim poslovnim procesima djelatnici CO 

samostalno digitaliziraju novu dokumentaciju i uvode je u dokumentacijski sustav, odlučeno je da 

postojeću fizičku dokumentaciju djelatnici CO neće morati retroaktivno digitalizirati. S obzirom na 

stečena znanja i iskustva, odlučeno je da će digitalizaciju navedenih dokumenata također provesti 

FINA i time olakšati uvođenje i prihvaćanje ADS-a. 

Tijekom cjelokupnog procesa digitalizacije i indeksiranja dokumenata, FINA-in odjel ADC 

digitalizirao je 330.000 dokumenata s ukupno 2 milijuna stranica. Dokumenti su indeksirani i 

konvertirani u PDF format te isporučeni zajedno s indeksnim datotekama. Obrada dokumenata 

provedena je u 6 segmenata, a ukupna veličina dobivenih dokumenata iznosi približno 67 GB. Prije 

učitavanja dokumenata u ADS, provedena je dodatna analiza indeksnih podataka kako bi se u što 

većoj mjeri smanjila količina ljudskih pogrešaka. Nakon ispravljanja otkrivenih pogrešaka, dokumenti 

su automaziranim alatima učitani u ADS. Kao rezultat ovog procesa, djelatnicima koji rade na 

životnim osiguranjima danas na raspolaganju stoji cjelokupna dokumentacija Sektora unazad desetak 

godina koliko se ona pohranjuje. 

3.4. Uvođenje sustava u produkcijski rad 

Uvođenje sustava u produkcijski rad započelo je testiranjem koje je provedeno u Synervi i u 

Croatia osiguranju. Za potrebe testiranja izrađeni su testni planovi prema kojima su testiranje proveli 

djelatnici obje tvrtke. Inicijalno testiranje proveli su djelatnici Synerve korištenjem vlastite razvojne 

151 

5

okoline, nakon čega je sustav postavljen i konfiguriran za rad u testnoj okolini CO. Rad s testnom 

okolinom omogućio je izvođenje integracijskih testova sa stvarnim sustavima Croatije osiguranja te sa 

stvarnim podacima iz sustava ISŽO. Nakon djelatnika Synerve, testiranje su nastavili djelatnici 

aplikacijske grupe Sektora za informatiku CO. Konačno, sustav su testirali djelatnici Sektora životnih 

osiguranja. Kako bi se dodatno povećala kvaliteta testiranja i utvrdilo da sustav odgovara stvarnim 

potrebama krajnjih korisnika, na probni rad s ADS-om pozvano je desetak djelatnika podružnica CO 

koji svakodnevno rade sa životnim osiguranjima. Njihova mišljenja i iskustva iskorištena su kako bi se 

provele dodatne prilagodbe i poboljšanja sustava. 

Nakon uspješno provedenog testiranja, Arhivsko-dokumentacijski sustav postavljen je na 

edukacijsku i produkcijsku okolinu. Dok je u produkcijskoj okolini pokrenuto učitavanje dokumenata 

digitaliziranih u FINA-i, edukacijska okolina pripremljena je za proces edukacije djelatnika podružnica. 

Edukacija se odvijala u učionici Generalne direkcije CO, a sudjelovali su djelatnici kojima su životna 

osiguranja jedno od primarnih područja. Ukupno su bile organizirane tri edukacijske grupe s po 30-ak 

polaznika iz svih podružnica Croatije osiguranja. Trajanje edukacije za jednu grupu iznosilo je dva 

radna dana. Za potrebe edukacije pripremljene su upute o izmjenama u poslovnim procesima, upute 

za rad sa sustavom za digitalizaciju i upute za rad s dokumentacijskim sustavom. Sama edukacijska 

okolina iskorištena je za demonstraciju sustava i praktični rad polaznika. 

Tijekom edukacije, polaznici su upoznati s promjenama u poslovnim procesima, digitalizacijom i 

radom s dokumentacijskim sustavom. U području poslovnih procesa, polaznicima su objašnjene 

izmjene u postojećim procesima, izmjene u rukovanju fizičkim dokumentima i načela rukovanja 

digitalnim dokumentima. Polaznici su dalje podučeni radu s aplikacijom eInput, odnosno sustavom za 

digitalizaciju fizičkih dokumenata, a također je objašnjen i demonstriran rad sa scannerom. Konačno, 

polaznicima je ukazano na promjene i dodatne funkcionalnosti aplikacije ISŽO koje se odnose na 

dokumentacijski sustav. Uz predavanja i demonstracije, od polaznika je zatraženo i da praktično 

izvedu sve postupke vezane uz dokumentacijski sustav. 

4. OSNOVNE KOMPONENTE ARHIVSKO-DOKUMENTACIJSKOG SUSTAVA 

Tri su osnovne programske cjeline koje čine cjelokupni Arhivsko-dokumentacijski sustav: sustav 

ISŽO, sustav Japaya i sustav Captiva. ISŽO (Informacijski Sustav za Životna Osiguranja) je vlastiti 

aplikacijski sustav Croatije osiguranja koji pruža potporu izvođenju poslovnih procesa životnog 

osiguranja. Sustav Japaya je središnji dio sustava za upravljanje dokumentima, a razvila ga je tvrtka 

Synerva. Konačno, sustav Captiva namijenjen je upravljanju ulazom, odnosno digitalizaciji papirnatih 

dokumenata, a razvila ga je tvrtka EMC. 

Uz navedene programske cjeline, Arhivsko-dokumentacijski sustav koristi razne pozadinske 

programske sustave. Baze podataka sustava ISŽO i Japaya zasnovane su na Oracleovoj bazi 

podataka i RAS sustavu, a aplikacijski poslužitelj sustava ISŽO je Oracleov IAS (Internet Application 

Server) postavljen na farmi poslužitelja. Uz navedeno, sustav ADS koristi i specijalizirani sklopovski 

sustav Centera koji je namijenjen pouzdanoj i sigurnoj pohrani dokumenata, a proizvodi ga EMC. U 

nastavku poglavlja opisane su osnovne programske cjeline i sustav Centera. 

4.1. Aplikacijski sustav ISŽO 

Aplikacijski sustav ISŽO vlastiti je sustav Croatije osiguranja koji daje informatičku potporu 

poslovnim procesima životnih osiguranja. Razvoj sustava bio je vlastiti, uz sudjelovanje unutarnjih i 

vanjskih izvršioca (konzorcijski razvoj). Danas vlastiti informatičari u potpunosti dalje razvijaju i 

održavaju taj sustav. Razvoj sustava otpočeo je u rujnu 2002. godine, a prva funkcionalna inačica 

puštena je u produkciju u siječnju 2004. godine. Nakon uspješnog uvođenja sustava, razvoj nije 

zaustavljen, već naprotiv, nastavljeno je širenje sustava uvođenjem novih funkcionalnosti. Sustav se 

kontinuirano proširuje novim mogućnostima prema potrebama poslovnih procesa i dorađuje se na 

osnovi povratnih informacija korisnika. Pritom se veliki značaj pridaje prilagodbi sustava zahtjevima i 

specifičnim potrebama krajnjih korisnika. 

Sustav ISŽO danas daje potporu svim procesima životnih osiguranja od planiranja, prodaje, 

obrade portfelja do šteta i svih potrebnih analitika. Osim za unutarnje potrebe, sustav je s vremenom 

proširen kako bi dao potrebnu informatičku potporu partnerskim tvrtkama, poput agencija i banaka. 

Sustav ima gotovo 4.000 korisnika, od čega je preko 650 djelatnika Croatije osiguranja, a ostatak čine 

vanjski suradnici i djelatnici partnerskih tvrtki. 

Tehnološku osnovicu sustava čini skup Oracleovih tehnologija. Baza podataka izgrađena je u 

Oracleu i izvodi se na Oracle RAS sustavu. Čini ju preko 750 tablica i preko 350.000 redaka 

pohranjenog kôda, većinom namijenjenog izvođenju složenih izračuna, a ukupna veličina baze prelazi 

152 

6

100 GB. Sama aplikacija zasnovana je na Oracle Forms tehnologiji i izgrađena primjenom alata 

Oracle Forms Developer. Iako ponešto starija, tehnologija Oracle Forms zasnovana je na Web 

tehnologijama i stoga dostupna u suvremenim preglednicima. Uporaba Web aplikacije korisnicima 

olakšava pristup i korištenje aplikacije, a informatičkim stručnjacima olakšava razvoj i održavanje 

sustava. Na slici 2 prikazan je primjer korisničkog sučelja aplikacije ISŽO. 

4.2. Sustav Japaya 

Slika 2: Primjer korisničkog sučelja aplikacije ISŽO 

Japaya je sustav za upravljanje dokumentima koji je razvila tvrtka Synerva. Synerva je njemačka 

tvrtka čije su osnovne djelatnosti razvoj programskih sustava i savjetovanje u informatici. Središnjica 

tvrtke je u Njemačkoj, a podružnice su otvorene u Švicarskoj i Hrvatskoj. Razvoju sustava Japaya 

prethodilo je dugogodišnje iskustvo u implementaciji sustava za upravljanje dokumentima te razvoj 

starije generacije DMS sustava nazvane Filero. Tvrtka Synerva uspješno je implementirala 

dokumentacijske sustave kod više klijenata, u rasponu od obrtnika do velikih organizacija i banaka. 

Sustav Japaya najnovija je generacija DMS-a zasnovana na Javi, J2EE i skupu otvorenih 

tehnologija. U potpunosti je razvijen u Synervi i ne koristi sustave drugih proizvođača. Japaya je 

objektno-orijentirani sustav, odnosno svi podaci i zapisi promatraju se kao objekti, a u rukovanju 

podatkovnim modelom i podacima primjenjuju se standardne OO tehnike poput nasljeđivanja i 

polimorfizma. Japaya pohranjuje podatke o dokumentima u relacijsku bazu podataka, no sam sustav 

je neovisan od proizvođača baze podataka. Baza podataka odvojena je od jezgre sustava zasebnim 

apstrakcijskim slojem, a trenutno su poduprta tri DBMS-a među kojima je i Oracleov. Međutim, uz 

minimalni razvojni trošak, moguće je izgraditi adapter za bilo koju bazu podataka kojoj se može 

pristupiti putem sustava JDBC (Java DataBase Connectivity). Same dokumente sustav Japaya može 

spremati u bazu podataka, u datotečni sustav ili na namjenski uređaj za pohranu dokumenata. 

Japaya trenutno sadrži potporu za samo jedan namjenski uređaj za pohranu, EMC Centera. 

Sa stajališta DMS-a, sustav Japaya nudi brojne funkcionalnosti. Objektno-orijentirani podatkovni 

model omogućuje stvaranje složenih podatkovnih modela za pohranu metapodataka o dokumentima. 

Metapodatke o dokumentima moguće je indeksirati, a sustav sadrži i puni tekstualni indeks 

dokumenata (engl. full-text indexing) za standardne datotečne formate. Pritom je uz velike svjetske 

jezike poput engleskog, njemačkog i španjolskog, uključena i potpuno funkcionalna potpora za 

hrvatski jezik, koja omogućava prepoznavanje i indeksiranje korijena riječi bez obzira na gramatički 

oblik. Sustav posjeduje i snažan jezik za postavljanje upita pomoću kojeg je moguće pretraživati sve 

metapodatke dokumenata i na taj način pronaći tražene dokumente. 

153 

7

Sustav Japaya prati sve izmjene na dokumentima i njihovim metapodacima te stare podatke i 

dokumente nastavlja čuvati i nakon njihove izmjene ili brisanja. Na taj način, gradi se povijest 

dokumenata u kojoj je moguće kasnije pronaći starije inačice dokumenata i njihovih podataka. Uz 

povijest je čvrsto vezano i praćenje izmjena, odnosno revizija (engl. audit trail) koja uz svaku izmjenu 

zapisuje kada je nastala i koji ju je korisnički račun proveo. Japaya posjeduje i složen sigurnosni 

sustav koji omogućuje detaljan opis prava pristupa pojedinim dokumentima i hijerarhijskim 

strukturama. Sigurnosni sustav povezan je sa sustavom za praćenje povijesti dokumenata i sustavom 

za praćenje izmjena. Sam sigurnosni sustav izgrađen je modularno te ostavlja mogućnost 

jednostavne konfiguracije različitih načina provođenja sigurnosnih politika i razvoj novih mehanizama. 

Autentikaciju i autorizaciju korisnika moguće je provoditi kroz ugrađeni sustav za upravljanje 

korisnicima i korisničkim grupama ili povezivanjem s vanjskim sustavima. Primjenom LDAP protokola 

omogućeno je povezivanje prema direktorijskim sustavima poput Microsoftovog Active Directorya. 

Zahvaljujući modularnoj strukturi, moguće je izgraditi i specijalizirani sustav za autentikaciju i 

autorizaciju korisnika, primjerice, za spajanje na bazu podataka s korisničkim podacima. U području 

sigurnosti, sustav još nudi i impersonaciju i delegiranje prava pristupa te automatsko potpisivanje 

dokumenata kako bi se zajamčila nepromjenjivost i neporecivost. 

U sustav Japaya ugrađena je i potpora za olakšavanje indeksiranja tijekom digitalizacije koja 

automatski izrađuje crtični kôd na temelju indeksnih podataka dostupnih iz povezane poslovne 

aplikacije. Crtični kôd potom se ispisuje i digitalizira zajedno s dokumentom. Čitanjem crtičnog kôda 

sustav može automatski ili poluautomatski indeksirati dokument. Konačno, osnovno sučelje sustava 

zasnovano je na Web aplikacijama i stoga je dostupno s različitih klijentskih platformi. 

Jedna od najznačajnijih prednosti sustava Japaya jest njegova prilagodljivost potrebama 

korisnika. Sam poslovni model tvrtke Synerava jest razvoj specijaliziranih sustava prema specifičnim 

zahtjevima i potrebama korisnika. Nadalje, budući da je cijeli sustav Japaya, uključujući i njegov 

izvorni kôd u vlasništvu Synerve, sustav je znatno fleksibilniji od komercijalnih off-the-shelf sustava. 

Navedeni sustavi velikih proizvođača, vođeni su načelom „one size fits all“, čime je konkretna 

implementacija ograničena na manje prilagodbe potrebama korisnika. Pokazalo se da se 

prilagodljivost i mogućnost integracije sustava Japaya vrlo dobro poklopila s potrebama Croatije 

osiguranja i znatno pridonijela uspjehu projekta. 

4.3. Sustav za upravljanje ulazom 

Upravljanje ulazom (engl. input management) ostvareno je primjenom gotovog, komercijalnog 

sustava EMC Captiva. S obzirom na veličinu Croatije osiguranja, potrebe za digitalizacijom 

dokumenata i broj korisnika, zaključeno je da je Japayin integrirani modul za digitalizaciju potrebno 

zamijeniti složenijim sustavom poput Captive. Unutar skupa modula sustava EMC Captiva, za 

potrebe ADS-a odabrane su komponente InputAccel i eInput. eInput je aplikacijski sustav koji se 

izvodi kao Web aplikacija i omogućuje digitalizaciju dokumenata putem preglednika MS Internet 

Explorer. Sustav sadrži komponentu za upravljanje scannerom koju je potrebno instalirati na 

klijentsko računalo i koja se povezuje na upravljačke programe scannera. Čitav proces digitalizacije i 

indeksiranja dokumenta odvija se u pregledniku. 

Modul InputAccel jest poslužiteljski sustav koji zaprima digitalizirane dokumente i potom ih dalje 

obrađuje te priprema za ulaz u dokumentacijski sustav. Sustav InputAccel zasniva se na procesima 

koje razvija implementator sustava. Unutar procesa zadaju se načini obrade dokumenta i indeksnih 

podataka te način pripreme i slanja dokumenta u dokumentacijski sustav. U pogledu obrade 

dokumenta, moguće je mijenjati razna fizička svojstva digitalizirane slike, mijenjati format zapisa te 

izvoditi prepoznavanje znakova (OCR, Optical Character Recognition). 

4.4. Sustav za pouzdanu i sigurnu pohranu 

Područje osiguranja u znatnoj je mjeri regulirano, a zakonima je propisano i čuvanje 

dokumentacije stvorene u odnosima sa strankama. Zahtijeva se dugoročno čuvanje izvorne 

dokumentacije u trajanju od 10 godina nakon datuma isteka same police. Budući da i same police 

mogu biti dugoročne, primjerice u životnom osiguranju često se ugovaraju i na 30 godina, nužno je 

osigurati pouzdanu i sigurnu pohranu dokumenata. Temeljem navedenih zahtjeva, za pohranu 

dokumenata odabran je sustav EMC Centera. 

Centera je sklopovski sustav iz kategorije CAS sustava (Content Adressable Storage). Sustav 

CAS sličan je sustavima NAS (Network Attached Storage) po tome što nudi veliku količinu prostora 

za pohranu podataka i po tome što mu se pristupa preko računalne mreže. Međutim, dok sustavi NAS 

nude prostor za pohranu u obliku mrežnih dijeljenih diskova kojima se pristupa putem standardnih 

protokola, sustav CAS nudi pohranu i dohvat pojedinačnih dokumenata putem namjenskog sučelja. 

154 

8

Gledano izvana, sustav ne nudi uobičajene paradigme datotečnih sustava, već rukuje isključivo 

pojedinačnim dokumentima koje identificira njihovom svojstvenom vrijednosti koja se izračunava 

pomoću hash funkcije. Primjena hash vrijednosti u kombinaciji s unutarnjim zaštitnim mehanizmima 

osigurava nepromjenjivost pohranjenih dokumenata tako da sustav Centera jamči da jednom 

pohranjeni dokument sigurno nije naknadno mijenjan. 

Uz zaštitu sadržaja dokumenata, Centera sadrži i višestruku unutarnju redundanciju kojom se 

osigurava pouzdanost sustava i korisnika štiti od gubitka podataka. Nadalje, postavljanjem 

sekundarnog sustava Centera moguće je osigurati izradu sigurnosnih kopija (engl. back-up) na 

udaljenom sustavu. U slučaju ispada primarnog sustava, sekundarni sustav može čak i preuzeti 

funkcije primarnog sustava (engl. fail-over) i time osigurati kontinuirani rad. Sve funkcije sustava 

Centera izgrađene su u skladu s regulatornim zahtjevima SAD-a gdje su i certificirane. Zahvaljujući 

navedenom, sustav Centera često se koristi za pohranu dokumenata u strogo reguliranim područjima 

poput farmacije, medicine i financija. 

5. IZGRADNJA ARHIVSKO-DOKUMENTACIJSKOG SUSTAVA 

Izgradnja i programsko ostvarenje Arhivsko-dokumentacijskog sustava započeli su tek nakon što 

su završile obje pripremne faze planiranja poslovnih procesa i analize tehničkih značajki produkcijske 

okoline. Rezultat pripremnih faza bio je skup dokumenata kojim se definiraju korisnički zahtjevi, 

podatkovni modeli, sučelja za povezivanje, metapodaci dokumenata itd. Temeljem pripremljenih 

dokumenata te imajući u vidu planirano širenje ADS-a na ostale sektore Croatije osiguranja, izrađena 

je arhitektura cijelog sustava. Potom su oblikovane pojedine komponente sustava, definirana su 

sučelja za njihovo međusobno povezivanje, specificirani su izgled i funkcionalnost korisničkih sučelja 

te je započelo programsko ostvarenje sustava. 

Programsko ostvarenje sustava trajalo je približno 9 mjeseci. Oko dvije trećine radova izvedeno 

je na razvojnoj okolini tvrtke Synerve, a ostatak je izveden u Croatiji osiguranju. Za potrebe 

implementacije postavljene su četiri okoline: razvojna, testna, edukacijska i produkcijska. U 

razvojnom procesu sudjelovali su razvijatelji svih tvrtki sudionica projekta. Najveći dio razvoja ostvarili 

su djelatnici Synerve primjenom Java platforme i J2EE tehnologija. Djelatnici aplikacijske grupe 

Službe za informatiku CO razvili su potprograme za dohvat podataka o dokumentima i korisničkim 

pravima primjenom Oracle platforme, jezika PL/SQL i tehnologije Oracle Forms. Konačno, djelatnici 

FINA-e razvili su procese za obradu i indeksiranje dokumenata na platformi Captiva. 

5.1. Arhitektura i oblikovanje sustava 

Arhitektura Arhivsko-dokumentacijskog sustava izrađena je na osnovi tehničkih značajki 

postojećih informatičkih sustava Croatije osiguranja, korisničkih zahtjeva i korištenih komponenti. 

Osnovna zadaća arhitekture jest povezati i integrirati brojne tehnološki raznorodne komponente 

različitih proizvođača u jedinstven i funkcionalan dokumentacijski sustav. Nadalje, s obzirom na 

planirano uvođenje dokumentacijskog sustava u ostale sektore CO, najvažnije pojedinačno svojstvo 

arhitekture jest mogućnost budućeg rasta, odnosno skalabilnost. Stoga je primijenjena modularna 

arhitektura s komunikacijski labavo povezanim komponentama. U slučaju potrebe, omogućeno je lako 

dodavanje novih i redundantnih modula te zamjena komunikacijskog podsustava novim. Sam 

komunikacijski podsustav također je zasnovan na načelu koje osigurava buduću skalabilnost. Opća 

arhitektura ADS-a prikazana je na slici 3. 

Središnja točka Arhivsko-dokumentacijskog sustava je poslužitelj sustava Japaya. Poslužitelj 

Japaye zadužen je za cjelokupno upravljanje dokumentima što uključuje rukovanje samim 

dokumentima, upravljanje metapodacima dokumenata, praćenje izmjena, određivanje prava pristupa, 

praćenje korisnika i održavanje autentičnosti dokumenata. S obzirom na svoju funkciju, poslužitelj 

Japaye je središnja integracijska točka koja povezuje sve komponente ADS-a. Metapodaci 

dokumenata te svi sistemski podaci sustava za upravljanje dokumentima pohranjuju se u zasebnoj 

bazi podataka. Sustav Japaya povezan je i s bazom podataka sustava ISŽO u kojoj su mu dodijeljena 

prava čitanja podataka potrebnih za indeksiranje dokumenata i izradu izvješća. Obje baze podataka 

zasnovane su na Oracle DBMS-u, a Japaya se spaja s njima primjenom posebnog sučelja, odnosno 

adaptera za Oracle baze podataka. Sami dokumenti, odnosno njihove datoteke, pohranjuju se na 

sustavu za pohranu dokumenata Centera. Budući da se Centeri ne pristupa preko standardnih 

protokola, već isključivo preko specijaliziranog sučelja, Synerva je za potrebe projekta razvila adapter 

za povezivanje s Centerom. 

155 

9

Autorizacija, 

e-mail 

Dokumenti 

Captiva Importer Interface 

Slika 3: Arhitektura Arhivsko-dokumentacijskog sustava 

Sljedeća ključna komponenta ADS-a jest poslužitelj sustava za upravljanje ulazom koji je 

izgrađen primjenom sustava Captiva. Osnovna zadaća sustava je upravljanje postupkom digitalizacije 

i indeksiranja fizičkih dokumenata. Putem klijentskih računala na koja su spojeni scanneri korisnici se 

spajaju na poslužitelj, digitaliziraju fizičke dokumente, upisuju indeksne podatke i šalju dokumente u 

proces daljnje obrade. Sustav za upravljanje ulazom preuzima slikovne zapise dokumenata, pretvara 

ih u željeni format, pridaje im indeksne podatke i potom predaje sustavu za upravljanje dokumentima. 

Uz sustav Japaya, sustav za upravljanje ulazom spojen je i na sustav ActiveDirectory kojeg koristi 

radi autentikacije i autorizacije korisnika te za dohvat e-mail adresa korisnika. Primjenom elektroničke 

pošte sustav obavještava korisnike i administratore sustava u slučaju pojave problema u cjelokupnom 

procesu digitalizacije dokumenata. U svrhu povezivanja sustava Captiva i sustava Japaya, Synerva je 

izgradila posebnu komponentu koja preuzima dokumente od Captive i učitava ih u dokumentacijski 

sustav. 

Farma aplikacijskih poslužitelja za aplikacije izgrađene primjenom tehnologije Oracle Forms, 

posljednja je ključna komponenta Arhivsko-dokumentacijskog sustava. Farma je zasnovana na 

sustavu Oracle IAS i čini poslužiteljsku osnovu poslovnih aplikacija Croatije osiguranja. Budući da je 

projektom predviđeno da se sučelje ADS-a integrira u sučelje aplikacije ISŽO, farma je ujedno i 

osnova za izvođenje cijelog klijenskog podsustava Japaye. Svi korisnici sustava ISŽO spajaju se na 

farmu aplikacijskih poslužitelja te preko nje komuniciraju s dokumentacijskim sustavom i rukuju 

dokumentima. Synerva je razvila dvije klijentske komponente koje se izvode u procesima 

aplikacijskog poslužitelja i u okolini korisničkog preglednika. Zadaće klijentskih komponenata su 

povezivanje klijenata sa sustavom Japaya, posredovanje u razmjeni podataka između klijenata i 

Japaye, proširenje funkcionalnosti aplikacije ISŽO, izvođenje dijela obrade dokumenata na Oracle 

Forms klijentima, čitanje indeksnih podataka iz baze podataka sustava ISŽO i njihovo povezivanje s 

dokumentima. Arhitektura predviđa i mogućnost da su klijenti sustava za upravljanje ulazom i klijenti 

farme aplikacijskih poslužitelja ista računala, odnosno digitalizacija se može obavljati na računalima 

koja korisnici koriste za rad s aplikacijom ISŽO. 

5.2. Programsko ostvarenje 

Programska arhitektura Arhivsko-dokumentacijskog sustava prikazana je na slici 4. Sustav 

Japaya i sve namjenske komponente koje je Synerva razvila za potrebe projekta, zasnovani su na 

Java platformi i načelima objektno-orijentiranih sustava. Iznimka su procesi obrade dokumenata u 

sustavu za upravljanje ulazom koje je razvila FINA primjenom namjenskog skriptnog jezika. U 

nastavku su opisane pojedine programske cjeline. 

156 

Oracle Forms Interface 

10

5.2.1. Komponenta JapayaServer 

Slika 4: Programska arhitektura Arhivsko-dokumentacijskog sustava 

Poslužiteljska komponenta JapayaServer središnji je dio sustava koji povezuje sve ostale 

komponente i upravlja cijelim sustavom. Izrađena je kao Java aplikacija koja se izvodi kao 

poslužiteljski proces. Aplikacija upravlja dokumentima, metapodacima dokumenata i podatkovnim 

modelima. Nadalje, provjerava prava pristupa, prati povijesti izmjena, prati pristup dokumentima, 

indeksira dokumente i ostvaruje mehanizme pretraživanja dokumenata. Osnovu aplikacije čine 

jezgreni moduli dokumentacijskog sustava razvijeni u Synervi. Osim dokumentacijskih modula, 

JapayaServer koristi i čitav niz otvorenih J2EE tehnologija poput Hibernatea, Springa ili Lucenea. 

Zbog usmjerenosti na otvorene tehnologije, olakšano je pristupanje sustavu, povezivost s drugim 

sustavima i održavanje sustava. 

Komponenta JapayaServer povezana je na sustav Centera putem namjenski razvijenog 

adaptera. Nadalje, JapayaServer izravno je povezan i s dvije baze podataka. Prva baza podataka 

namijenjena je dokumentacijskom sustavu koji u nju pohranjuje metapodatke dokumenata i sve 

sistemske podatke dokumentacijskog sustava poput povijesti izmjena, podataka o pristupu 

dokumentima i popisa korisnika. Druga je baza podataka sustava ISŽO iz koje JapayaServer 

dohvaća dio indeksnih podataka te podatke za autorizaciju korisnika. U tu svrhu razvijen je posebni 

adapter za sigurnosni sustav Japaye koji autorizacijske podatke dohvaća iz baze sustava ISŽO 

izvođenjem pohranjenih potprograma. Pohranjene potprograme razvili su djelatnici aplikacijske grupe 

Službe za informatiku CO. 

Konačno, JapayaServer spojen je i na komunikacijski poslužitelj od kojega dobiva zahtjeve 

klijenata. Nakon obrade zahtjeva, JapayaServer šalje rezultate klijentima, ponovo preko 

komunikacijskog poslužitelja. Navedenim je ostvareno potpuno odvajanje poslužitelja od klijenata, a 

zahvaljujući modularnoj arhitekturi moguće je komunikacijski podsustav zamijeniti drugim koji će 

koristiti druge protokole. Kanaliziranje sve komunikacije prema drugim komponentama kroz 

komunikacijski poslužitelj znatno pojednostavljuje razvoj poslužiteljskog dijela dokumentacijskog 

sustava. Nadalje, postignuto je fokusiranje isključivo na funkcije dokumentacijskog sustava, a 

pouzdanost i sigurnost komunikacije prepušteni su komunikacijskom podsustavu. 

157 

11

5.2.2. Komunikacijski poslužitelj 

Komunikacijski je poslužitelj središnja komunikacijska točka sustava. Sva komunikacija između 

klijentskih komponenti sustava i poslužiteljske komponente JapayaServer prolazi kroz njega. Korišteni 

komunikacijski protokol je JMS, a implementacija je zasnovana na otvorenom JMS Message Broker 

sustavu. Komunikacijski poslužitelj izgrađen je oko reda poruka koje klijenti razmjenjuju s 

poslužiteljem Japaye. Dok su poruke koje prenose rezultate izvođenja zahtjeva uvijek usmjerene 

prema klijentu koji je postavio zahtjev, poruke koje prenose zahtjeve klijenata prema poslužitelju 

nemaju fiksnu ciljnu adresu. Umjesto fiksne adrese koristi se poopćeno adresiranje na poslužitelj. 

Poopćeno adresiranje omogućuje da u sustavu postoji više poslužitelja koji se spajaju na isti 

komunikacijski red poruka. 

Dodavanjem novih poslužitelja povećava se kapacitet sustava i postiže svojstvo razmjernog 

rasta dok primjena reda poruka osigurava prirodno raspoređivanje zadataka na dodatne poslužitelje. 

Nadalje, postiže se i automatska redundancija sustava kod koje u slučaju ispada jednog poslužitelja, 

ostali potpuno automatski preuzimaju njegovo opterećenje. Komunikacijski se podsustav brine i za 

kriptiranje i digitalno potpisivanje poruka. Kriptiranjem sadržaja poruke štiti se povjerljivost podataka, 

no zbog visokih procesnih zahtjeva kriptiranje je moguće i isključiti. Digitalno potpisivanje poruka služi 

autentikaciji svih sudionika u komunikaciji, odnosno osigurava da sustavu neće pristupati neovlaštene 

komponente. 

5.2.3. Sustav za ulaz dokumenata 

Sustav za ulaz dokumenata ostvaren je kao Java aplikacija nazvana CaptivaFolderImporter, a 

razvila ju je Synerva. Radi se o jednostavnoj komponenti koja preuzima dokumente od sustava za 

upravljanje ulazom i potom ih šalje poslužitelju Japaye radi dodavanja u dokumentacijski sustav. 

Razmjena dokumenata između sustava InputAccel i CaptivaFolderImportera zasnovana je na 

razmjeni datoteka u dijeljenom direktoriju. CaptivaFolderImporter nadzire dijeljeni direktorij te kada 

uoči pojavu datoteke s dokumentom i pripadne indeksne datoteke pokreće postupak dodavanja 

dokumenta u sustav. Prilikom preuzimanja dokumenta, CaptivaFolderImporter čita datoteku 

dokumenta i pripremljene indeksne podatke koje preoblikuje u podatkovne objekte. Podatkovni objekti 

pohranjuju se u poruku zahtjeva, a sama datoteka dokumenta šalje kao podatkovni tok. 

5.2.4. Sustav za upravljanje ulazom 

Sustav za upravljanje ulazom sastoji se od programskih komponenti InputAccel i eInput. eInput 

je Web aplikacija koja korisnicima omogućuje upravljanje scannerom, izvođenje postupka 

digitalizacije i indeksiranja dokumenta te slanje dokumenta na poslužitelj. Poslužiteljski dio sustava 

eInput prima slikovni zapis dokumenta i indeksne podatke te ih predaje sustavu InputAccel. Zadaća 

sustava InputAccel jest obrada slikovnog zapisa, pretvorba u drugi format, obrada indeksnih podataka 

te predaja datoteke dokumenta i indeksnih podataka dokumentacijskom sustavu. U opisanoj 

implementaciji, InputAccel izvodi manja poboljšanja kvalitete slikovnog zapisa te konvertira dokument 

u PDF format. Nadalje, InputAccel očitava crtični kôd koji se nalazi na naslovnici dokumenta, iz njega 

izlučuje indeksne podatke dokumenta te ih pohranjuje u tekstualnu datoteku. PDF datoteka i 

tekstualna datoteka s indeksnim podacima potom se pohranjuju u dijeljeni direktorij koji nadzire 

komponenta CaptivaFolderImporter. Radi autentikacije i autorizacije korisnika, sustav za upravljanje 

ulazom spaja se na sustav Active Directory. Procese obrade dokumenata, konverzije u PDF te 

očitavanja i spremanja indeksnih podataka razvila je FINA primjenom namjenskog skriptnog jezika 

sustava Captiva. 

5.2.5. Klijentske komponente sustava 

S obzirom na ahitekturu Oracle IAS poslužitelja i tehnološku osnovu sustava Oracle Forms, 

klijentski dio Arhivsko-dokumentacijskog sustava podijeljen je u dvije komponente. JapayaJmsClient 

je klijentska komponenta koja se izvodi unutar Oracle Forms Run-Time procesa. Komponenta je 

pisana u Javi, a pokretanje unutar nativnog procesa omogućeno je putem JNI sučelja. Osnovna 

zadaća komponente jest povezivanje Oracle Forms klijenata s poslužiteljem dokumentacijskog 

sustava. Budući da se Oracle Forms klijenti izvode na klijentskim računalima unutar Internet 

preglednika izvan sigurne zone te s obzirom na ograničenja u izvođenju Java Appleta, nije moguća 

izravna komunikacija između njih i poslužitelja Japaye. Stoga sva komunikacija ide od klijenata do 

Oracle IAS poslužitelja te potom od njega do poslužitelja Japaye. JapayaJmsClient zadužen je za 

implementaciju JMS protokola te slanje i primanje zahtjeva i odgovora s poslužitelja Japaye. 

158 

12

Uz posredovanje u komunikaciji, komponenta JapayaJmsClient zadužena je i za razmjenu 

podataka sa samim klijentskim sučeljem koje se izvodi u pregledniku Interneta. Kako je komunikacija 

između Oracle Forms procesa i klijentskog preglednika moguća jedino putem razmjene znakovnih 

nizova, JapayaJmsClient provodi i serijalizaciju podataka. Podatkovni objekti koji dolaze od 

poslužitelja pretvaraju se u XML i potom šalju kao znakovni nizovi klijentskom pregledniku. Binarna 

datoteka dokumenta enkodira se u tekstualni zapis i potom šalje pregledniku. Složenost komunikacije 

dodatno komplicira ograničenje duljine tekstualnog zapisa na 4000 znakova. Komponenta 

JapayaJmsClient stoga mora provoditi segmentaciju zapisa i slanje pojedinačnih segmenata. 

Komponenta također izvodi i obrnuti postupak, odnosno spajanje segmenata u veću cjelinu, 

dekodiranje binarnih zapisa iz teksta te deserijalizaciju iz teksta u podatkovne objekte. 

Druga klijentska komponenta jest Java Applet sučelja ADS-a nazvan JapayaFormsUI. S obzirom 

na složenost dokumentacijskog sustava i korisničkih zahtjeva zaključeno je da primjenom standardnih 

Oracle Forms razvojnih alata neće biti moguće ostvariti sve potrebne funkcionalnosti. Stoga je 

razvijena Java komponenta JapayaFormsUI koja sadrži cijelo sučelje dokumentacijskog sustava i 

izvodi dio obrade dokumenta na klijentu. Komponenta omogućuje pregled i izmjenu metapodataka 

dokumenta, pregled sadržaja dokumenta, otvaranje dokumenta u pripadnoj aplikaciji, čitanje i pisanje 

dokumenta na lokalne jedinice pohrane, ispis naslovnice dokumenta s crtičnim kôdom, itd. 

Uz upravljanje sučeljem i rukovanje dokumentima, JapayaFormsUI ostvaruje i komunikaciju 

prema komponenti JapayaJmsClient koja se izvodi na Oracle IAS poslužitelju. Sam Java applet 

komponente JapayaFormsUI ugrađen je u posebno pripremljenu integracijsku formu koja ne sadrži 

nijedan element sučelja osim samog appleta. Osim pružanja okoline za izvođenje appleta sučelja, 

integracijska forma zadužena je i za povezivanje s ostalim formama sustava ISŽO te za dohvat 

indeksnih podataka iz baze podataka ISŽO. Forma je razvijena u alatu Oracle Forms Developer i 

jeziku PL/SQL 

5.3. Sučelje Arhivsko-dokumentacijskog sustava 

Sučelje Arhivsko-dokumentacijskog sustava izgrađeno je na osnovi korisničkih zahtjeva i uz 

nastojanje da se što više poveća učinkovitost rada korisnika. U fazi planiranja projekta Synerva je 

izradila više prototipova sučelja koji su potom prikazani djelatnicima Sektora životnih osiguranja i 

Službe za informatiku CO. Na osnovi mišljenja i primjedbi korisnika, prototipovi su iterativno 

unaprijeđivani do konačnog prihvaćanja. 

Slika 5: Primjeri integracije ADS-a u aplikaciju ISŽO 

159 

13

Sučelje je u potpunosti integrirano u aplikaciju ISŽO pri čemu su u postojeće forme koje korisnici 

koriste u svakodnevnom radu s aplikacijom nadodane dodatne tipke i izbornici kojima se pokreće 

dokumentacijski sustav. Primjeri integracije sučelja ADS-a u aplikaciju ISŽO prikazani su na slici 5. 

Nakon što korisnik odabere neku akciju dokumentacijskog sustava, aplikacija ISŽO pokreće sučelje 

dokumentacijskog sustava te mu predaje opis pokrenute akcije i potrebne podatke. Primjerice, ako 

korisnik pokrene akciju dodavanja dokumenta iz forme za obradu šteta, prilikom pokretanja 

dokumentacijskog sustava bit će automatski predani i svi potrebni indeksni podaci poput oznake 

podružnice, identifikatora štetovnog događaja i broja police. Zahvaljujući opisanom pristupu, korisnik 

ne mora ručno unositi indeksne podatke čime mu je znatno olakšan i ubrzan svakodnevni rad. Samo 

sučelje dokumentacijskog sustava izrađeno je u Javi, ali je potpuno uklopljeno u Oracle Forms 

okolinu. Nadalje, sučelje je potpuno prilagođeno potrebama poslovnih procesa životnih osiguranja i 

prirodno podupire sve specifičnosti poslovnih procesa i pripadnih metapodataka. Primjer izgleda 

sučelja dokumentacijskog sustava prikazan je na slici 6. 

6. ZAKLJUČAK 

Slika 6: Primjeri sučelja Arhivsko-dokumentacijskog sustava 

Projekt uvođenja Arhivsko-dokumentacijskog sustava pokazao se vrlo složenim. S jedne strane, 

bilo je potrebno koordinirati rad tri neovisne tvrtke te dva sektora unutar samog Croatia osiguranja. S 

druge strane, projekt je bio tehnički zahtjevan zbog potrebe integracije raznorodnih sustava i 

tehnologija koje su međusobno tek djelomično sukladne. Integracija Java komponenti s Oracle Forms 

sustavom ostvarena na ovom projektu jedan je od rijetkih takvih primjera u široj regiji. Unatoč svoj 

složenosti i problemima koji su se pojavili, projekt je uspješno završen postavljanjem 

dokumentacijskog sustava u produkcijski rad 9. veljače 2010. godine. 

Dokumentacijski sustav danas koristi oko 150 korisnika koji svakodnevno dodaju oko 200 novih 

dokumenata, a broj dokumenata u sustavu narastao je na 400.000. Sustav je dobro prihvaćen od 

strane krajnjih korisnika, a zahvaljujući snažnoj potpori Službe za informatiku i Sektora životnih 

osiguranja, već dva tjedna od početka produkcije svi djelatnici životnih osiguranja počeli su redovno 

koristiti sustav. Produkcijski rad pokazao je da je sustav dobro usklađen s potrebama poslovnih 

160 

14

procesa i zahtjevima korisnika na terenu. Nakon približno tri mjeseca praktički svi korisnici svladali su 

krivulju učenja te je naglo pao broj upita službi za pomoć korisnicima. 

Tehnička strana sustava također je uspješno ispunila očekivanja. U početnom razdoblju od 

mjesec dana pronađen je i prijavljen neznatan broj problema i nedostataka u radu sustava izazvanih 

programskim pogreškama. Navedene pogreške nisu bile ozbiljnije, nisu narušile konzistenciju sustava 

te su u kratkom roku ispravljene. Nakon početnog razdoblja, sustav je ušao u potpuno stabilno stanje. 

Tijekom 20 mjeseci rada, poslužiteljski dio sustava imao je manje od deset ispada. Pritom je približno 

polovica ispada bila uzrokovana problemima kod sistemskog održavanja poslužitelja. Drugu polovicu 

ispada uzrokovali su problemi u radu sustava za upravljanje ulazom. Problemi s navedenim sustavom 

uzrokovani su gubitkom memorije i poznati su proizvođaču, no otklanjanje problema nije promptno 

uslijedilo, već je proizvođač preporučio periodičko ponovno pokretanje poslužitelja. Konačno, tek 

jedan ispad uzrokovan je problemima u radu sustava Japaya. Svi navedeni ispadi riješeni su u roku 

od jednog radnog dana, a često i znatno brže jer se većina problema pojavila u početnoj godini rada 

sustava dok je on bio pod pojačanim nadzorom izvođača radova. 

Primjenom Arhivsko-dokumentacijskog sustava ostvarene su značajne promjene i uštede u 

izvođenju poslovnih procesa životnih osiguranja, a korisnicima sustava znatno je olakšano rukovanje 

dokumentima. Iako su korisnici dobili dodatnu zadaću digitalizacije dokumenata, istovremeno su 

rasterećeni od potrebe fizičkog rukovanja dokumentima, uključujući sve vremenske i materijalne 

troškove koje ono nosi. Nadalje, korisnicima je ukinuta obveza održavanja priručne i lokalne arhive u 

podružnici. Navedene arhive zamijenjene su jednom čija je jedina zadaća privremeno čuvanje fizičkih 

dokumenata do trenutka njihovog slanja na pohranu u FINA-u te stoga stvara znatno manje 

opterećenje djelatnika. Uštede su postignute i u poštanskim i telekomunikacijskim troškovima jer je 

uklonjena potreba za slanjem fizičke dokumentacije u Generalnu direkciju u slučajevima kada su 

potrebne dodatne analize i procjene. 

Praktična primjena pokazala je da je uvođenjem ADS-a korisnicima pojednostavljeno rukovanje 

dokumentima i ubrzan njihov svakodnevni rad. Međutim, jedna od najznačajnijih prednosti sustava 

jest povećana dostupnost dokumenata. Elektroničkom ili digitaliziranom dokumentu stvorenom u 

podružnici može pristupiti bilo koja ovlaštena osoba, bez obzira na kojoj se fizičkoj lokaciji nalazi. 

Ovime je značajno povećana mogućnost nadzora poslovanja, ali je isto tako olakšana razmjena 

informacija između djelatnika, omogućena mobilnost djelatnika te traženje specijalističke pomoći koju 

najčešće pruža Generalna direkcija. Budući potencijal sustava vrlo je velik jer otvara mogućnosti za 

daljnji napredak u poslovnim procesima, dodatnu automatizaciju sustava i nove mogućnosti suradnje i 

razmjene dokumenata kako unutar Croatije osiguranja tako i prema vanjskim partnerima. 

Razmatrajući uspješnu primjenu Arhivsko-dokumentacijskog sustava, dobru prihvaćenost 

sustava kod krajnjih korisnika te stabilnu tehničku osnovu, moguće je zaključiti da je projekt uvođenja 

ADS-a uspješno ostvaren. Jedini značajan i ozbiljan nedostatak projekta jest znatno prebacivanje 

planiranih rokova. Kašnjenje je znatnim dijelom uzrokovano proširenjem opsega te problemima u 

koordinaciji pojedinih aktivnosti i relativnim prioritetima u odnosu na druge projekte unutar Croatije 

osiguranja. Međutim, također značajan dio kašnjenja uzrokovan je i odlukom vodstva projekta da se 

pristupi podrobnom planiranju i oblikovanju sustava. Na pripremu implementacije i oblikovanje 

sustava potrošeno je oko 40% vremena, a 60% vremena potrošeno je na samu implementaciju i 

postavljanje sustava. Osnovni motiv za takvu odluku vodstva bilo je nastojanje da sustav, koji je 

poslužio kao pilot za uvođenje dokumentacijskog sustava u ostale sektore, bude uspješno 

implementiran i prihvaćen kako bi otvorio put za daljnji nastavak projekta. 

161 

15

ORACLE VPD U PRIMJENI 

Nataša Dvoršak 

ULJANIK IRI d.o.o., Pula 

e-mail: natasa.dvorsak@uljanik.hr 

SAŽETAK 

Razvoj i sve raširenija primjena informacijskih tehnologija, a posebno BI rješenja, dovode do 

situacija kada aplikacijska zaštita podataka više nije dovoljna. Bazi se pristupa iz različitih 

sustava/alata, te se otvara pitanje zaštite podataka spremljenih u bazi. 

Zašto ne primijeniti već gotovo Oracle rješenje VPD (Virtual Private Database)? 

U Oracle ver. 10gR2 uvedena su značajna poboljšanja performansi koja VPD sustav čine iskoristivim 

nad transakcijskim podacima. 

Prikazat će se dizajn i izrada sustava zaštite u kojem djeluje nekoliko različitih sigurnosnih grupa, 

tehnike koje se primjenjuju za bolje performanse, različite mogućnosti filtriranja i prikaza podataka, 

bilježenje kritičnih aktivnosti na bazi uz FGA (Fine Grained Auditing). 

Oracle VPD in the implementation 

The development of information technology, and specifically BI solutions, are leading to situations 

where the application data protection is no longer sufficient. Database can be accessed from different 

systems / tools, the solution is in data protection in the database. Why not apply the Oracle out of the 

box solution VPD? 

Oracle in 10gR2 introduced significant performance improvements that make the VPD usable over the 

transaction data. 

It will be demostrated the design and implementation of security policies in which there are several 

different policy groups, the techniques applied to enhance performance, a variety of filtering options 

and masking data, recording of critical activities on the database using the FGA. 

UVOD 

Razvojem informacijske tehnologije rastu i apetiti korisnika za novim informacijama i izvještajima 

u svim oblicima. Sve je više informatički pismenih korisnika koji znaju raditi s izvještajnim alatima 

poput Oracle BI, Oracle Discoverera, SQL developera, MS Excela i slično. Zaštita podataka u takvom 

okruženju veoma je izazovni zadatak. U našem okruženju korisnici imaju jedinstveno korisničko ime 

(user na Oracle bazi zaštićen baznim rolama) koje koriste za rad s ERP sustavom, ali također i za 

konekciju na bazu s ostalim dostupnim alatima. Tablice kojima se pristupa namijenjene su za pohranu 

podataka različitih poslovnih subjekata. Pojedini korisnici ovlašteni su za pristup podacima jednog ili 

više poduzeća u sustavu. Sigurnost ERP sustava koncipirana je prema modelu zaštite na nivou 

poduzeća, dok je pristup podacima drugim kanalima manjkav. Osim interne zaštite podataka poslovnih 

subjekata, pred informatičare se stavljaju i zahtjevi za zaštitu od neovlaštenog pristupa osjetljivim 

podacima (npr. prema Zakonu o zaštiti osobnih podataka). Jedno od rješenja koje Oracle nudi je VPD 

(Virtual Private Database). VPD dolazi u standardnom paketu Enterprise edicije Oracle baze. 

1 UVOD U VPD 

1.1 Osnovne informacije 

Oracle Virtual Private Database (VPD) je sigurnosni okvir koji je prvi puta implementiran u verziji 

baze 8i pod nazivom Fine Grained Access Control (FGAC). Osnovna značajka VPD-a je postizanje 

razine sigurnosti na nivou retka (Row Level Security – RLS). U izdanju baze 10g u VPD se dodaje i 

mogućnost zaštite na nivou stupaca. Standardno ponašanje zaštite stupaca svodi se na skrivanje 

redova s osjetljivim stupcima, a postoji i mogućnost prikazivanja svih redova sa skrivanjem osjetljivih 

stupaca (column masking). Skrivanje stupaca može se koristiti samo u SELECT naredbama. VPD 

pravila na razini stupaca ne mogu se primjenjivati nad synonymima. 

VPD mehanizam temelji se na dinamičkoj modifikaciji naredbi za čitanje (SELECT) ili ažuriranje 

162

(INSERT, UPDATE, DELETE) podataka tablica, viewa ili synonyma. Server baze podataka automatski 

modificira naredbu koju je korisnik poslao bazi tako da u WHERE klauzulu dodaje uvjete povezujući ih 

AND operatorom. Dodatne uvjete vraća funkcija koja je implementirana u okviru sigurnosnih pravila 

VPD-a. Ukoliko je nad istim objektom istovremeno aktivno više VPD sigurnosnih funkcija rezultati se 

povezuju AND operatorom u WHERE klauzuli. Dakle, postoji mogućnost da jedna sigurnosna politika 

uvjetuje isključenje druge i rezultat je tada prazan skup podataka. 

1.2 Aplikacijski kontekst 

Uz pojam VPD-a vezan je i pojam aplikacijskog konteksta (Application Context). Aplikacijski 

kontekst sastoji se od parova ključ-vrijednost koji se smještaju u sigurnu predmemoriju (cache) 

podataka. Ovisno o tome u kojem je memorijskom prostoru smješten razlikujemo globalni (System 

Global Area) i lokalni aplikacijski kontekst (User Global Area). Lokalni kontekst vidljiv je samo u okviru 

jedne bazne sesije, dok je globalni vidljiv svim sesijama baze. Kontekstne vrijednosti povezuju se i 

smještaju u grupe, tzv. namespace. Svaka sesija Oracle baze uvijek kreira zadani USERENV 

namespace sa svojim kontekstnim atributima, ali moguće je kreirati i vlastite grupe (namespace) sa 

svojim atributima. 

U kontekstu VPD-a aplikacijski kontekst zanimljiv je iz dva glavna razloga: 

− optimizacija izvođenja, 

− implementacija vlastitih grupa sigurnosti. 

Optimizacija izvođenja uz korištenje aplikacijskog konteksta moguća je zahvaljujući: 

− brzom pristupu atributima konteksta, 

− korištenju vrijednosti kontekstnih atributa u predikatima WHERE klauzule, 

− mogućnosti kreiranja uvjeta koji imaju atribute slične "bind" varijablama. 

Atributi konteksta smješteni su u posebnom memorijskom prostoru koji omogućava brzi pristup. 

Umjesto da se neprestano pristupa vrijednostima u baznim tablicama, ubrzanje se može postići 

čitanjem vrijednosti iz aplikacijskog konteksta. Dobra je praksa koristiti predikate WHERE klauzule s 

funkcijama koje vraćaju kontekstne vrijednosti, jer se na taj način uspijeva izbjeći korištenje konstanti u 

predikatima i kreiranje jednakog predikata za više korisnika sustava. 

Primjer 1:. 

select * from employees t where t.department_id = sys_context('EMP', 

'DEPARTMENT_ID') 

U verziji baze 10g uveden je i novi parametar "Policy Type" funkcije za kreiranje VPD sigurnosne 

politike DBMS_RLS.ADD_POLICY kojim se može utjecati na performanse servera baze. 

163

Tabela 1: DBMS_RLS.ADD_POLICY utjecaj Policy Type parametra [1] 

Još jedan razlog korištenja aplikacijskog konteksta u okviru VPD-a krije se u korištenju vlastitih 

grupa sigurnosne politike. Zadana (default) sigurnosna grupa je SYS_DEFAULT. Sigurnosna politika 

VPD-a definirana na grupi SYS_DEFAULT uvijek se izvodi. Vlastite VPD grupe kreiraju se kada se želi 

uvjetovati izvođenje neke VPD sigurnosne politike. Kreiranjem posebnih sigurnosnih grupa stvara se 

mogućnost istovremene aktivnosti sigurnosne politike samo jedne od ne-SYS_DEFAULT grupa. U 

jednoj korisničkoj sesiji uvijek je aktivna sigurnosna politika SYS_DEFAULT grupe i samo jedne ili svih 

vlastitih grupa. Koja je grupa aktivna definira se posebnim atributom aplikacijskog konteksta (Driving 

Context). Ukoliko Driving Context atribut nije definiran ili je vrijednost NULL tada će VPD mehanizam 

aktivirati sve sigurnosne politike. 

1.3 Administracija VPD-a 

Administracija VPD sigurnosnih pravila u potpunosti se obavlja uz pomoć paketa DBMS_RLS. 

Pomoću ovog paketa mogu se dodavati, aktivirati/deaktivirati, osvježavati i brisati sigurnosna pravila ili 

grupe VPD-a, te dodavati ili brisati aplikacijski kontekst. VPD pravila mogu se definirati nad tablicama, 

viewima ili synonymima baze. 

Osnovni postupak kreiranja VPD pravila svodi se na: 

• Kreiranje funkcije koja vraća predikat WHERE uvjeta (VARCHAR2), a prima dva parametra 

vlasnik i ime tablice. 

• Pridruživanje funkcije tablici (DBMS_RLS.ADD_POLICY). 

U radu s VPD grupama postupak je nešto složeniji: 

• potrebno je kreirati aplikacijski kontekst (lokalni ili globalni) 

• pridružiti tablici grupu (DBMS_RLS.CREATE_POLICY_GROUP) 

• pridružiti tablici funkciju (DBMS_RLS.ADD_GROUPED_POLICY) 

• pridružiti tablici atribut aplikacijskog konteksta, tzv. "driving context" tablici 

(DBMS_RLS.ADD_POLICY_CONTEXT) 

164

Tabela 2: DBMS_RLS popis funkcija i procedura [1] 

Osim ovog paketa za rad s VPD-em potreban je i DBMS_SESSION koji omogućava ažuriranje 

kontekstnih varijabli. 

Primjer 2. 

dbms_session.set_context(namespace => 'CONTEXT_VPD', 

attribute => 'POLICY_GROUP', 

value => 'FIN'); 

1.4 Informacije o VPD okruženju 

Sve informacije o postavljenom VPD okruženju na bazi smještene su u nekoliko tablica/viewa 

kataloga baze. Administrator VPD-a svakako treba konzultirati ove tablice kako bi dobio točnu sliku 

definiranog sustava zaštite, kao i za provjeru funkcioniranja sustava VPD-a (V$VPD_POLICY). U 

V$VPD_POLICY zapisani su predikati koji se dodaju WHERE klauzuli tablice/viewa/synonyma. View 

koji se u literaturi gotovo i ne spominje je USER/ALL/DBA_SEC_RELEVANT_COLS u kojem se 

nalaze podaci o stupcima tablica koje su uključene u VPD sigurnost. 

165

Tabela 3: Popis "data dictionary" view-a koji opisuju VPD postavke [2] 

Za potrebe testiranja sustava vjerojatno ćete konzultirati i zapise u viewima V$CONTEXT i 

V$GLOBALCONTEXT. 

166

2 VLASTITO RJEŠENJE 

Slika 1: Pogled na podatke u V$VPD_POLICY 

Implementacija VPD-a u našem okruženju imala je za cilj ugradnju mehanizama zaštite podataka 

na razini poduzeća koji neće zahtijevati velike zahvate u programskom rješenju. Sigurnosni zahtjevi 

trebaju biti zadovoljeni prilikom svakog pristupa podacima, dakle s bilo kojim alatom za manipuliranje 

podacima baze. 

Nakon prijelaza na bazu 10g, VPD se sporadično koristi za zaštitu podataka pojedinih tablica i 

viewa koji su kreirani za potrebe korištenja u Oracle Discoverer analizama, te u iznimnim slučajevima 

zaštite izrazito osjetljivih podataka. Novo rješenje trebalo bi pokriti sve opće zahtjeve zaštite podataka 

na razini poduzeća (retka tablice) i zaštite osjetljivih podataka u tablicama. Osim VPD-a u našem 

okruženju koristi se i Fine grained auditing (FGA) za praćenje manipulacija podacima nad izrazito 

osjetljivim tablicama (npr. plaće). 

U realizaciji rješenja vodili smo se idejom da poslovna pravila VPD sigurnosti budu što 

jednostavnija (tako savjetuju i u literaturi koju smo proučavali). Takvo razmišljanje išlo je u smjeru da 

se izrade dvije funkcije, jedna za zaštitu redaka i druga za zaštitu osjetljivih stupaca te se one pridruže 

svim tablicama/viewima koji zahtijevaju sigurnost podataka. Unutar funkcija mogu se razraditi 

mehanizmi pristupa ovisno o postavljenim ovlaštenjima korisnika. U konačnoj verziji rješenja, funkcije 

za vraćanje predikata VPD mehanizma prilično su jednostavne. U after logon triggeru baze ugrađen je 

mehanizam punjenja atributa aplikacijskog konteksta s vrijednostima predikata za svaku od tablica. 

Ovlasti korisnika za rad u VPD okruženju definirane su u posebnoj baznoj tablici. Na temelju zapisa u 

tablici kreira se predikat VPD mehanizma. 

function row_vpd(p_schema in varchar2, p_table in varchar2) 

return varchar2 is 

v_result varchar2(1000); 

begin 

v_result := nvl(sys_context('NEKI_CONTEXT', upper(p_table)), '1=0'); 

return v_result; 

end vrati_drustva_vpd; 

function col_vpd(p_schema in varchar2, p_table in varchar2) 

return varchar2 is 

v_rv varchar2(2000); 

begin 

v_rv := nvl(sys_context('NEKI_CONTEXT', upper(p_table) ||'_COL'), 

'1=0'); 

return v_rv; 

end; 

Jednostavnost je primijenjena i za odabir tablica nad kojima će se dignuti VPD zaštita. Uključili 

smo svega nekoliko ključnih tablica u kojima se može primijeniti zaštita redaka na razini poduzeća. U 

tablicama kćerima, tamo gdje je bilo potrebno, primijenili smo samo zaštitu na nivou stupaca. Zaštitom 

167

na razini tablica automatski su u VPD uključeni i svi viewi koji se vežu uz odabrane tablice. 

Testiranjem ove početne zamisli naišlo se na sljedeće probleme u radu: 

− VPD sigurnosna politika provodi se uvijek, čak i u baznim procedurama i funkcijama čiji je 

vlasnik korisnik koji ima ovlaštenja pristupa svim redcima ili stupcima 

− korištenje "data masking" opcije zaštite uzrokuje grešku (FRM 40654:Record has been 

updated by another user ...) prilikom pokušaja ažuriranja podataka u Oracle Forms aplikaciji. 

Kako bi se izbjegli dodatni problemi u radu ERP sustava, koji se bazira na Oracle Forms/Reports 

rješenju, odlučeno je da je u radu s aplikacijom najbolje izbjeći aktivaciju VPD sigurnosnih pravila. 

Razmatrana su dva moguća rješenja: 

− u VPD funkciju ugraditi logiku izbjegavanja VPD-a vraćanjem uvijek istinitog predikata, npr. 

"1=1" 

− iskoristiti mogućnosti vlastitih VPD sigurnosnih grupa (policy groups) tako da se ovisno o 

aplikacijskom kontekstu aktivira zadovoljavajuća grupa. 

Odlučeno je da se iskoristi ova druga mogućnost, jer prvi način uvijek aktivira neku sigurnosnu 

politiku nad tablicama, dok u radu s grupama postoji mogućnost izbjegavanja aktivacije VPD 

mehanizma. Identificirane su tablice čije retke i/ili stupce treba zaštititi. Implementacija s vlastitim VPD 

grupama zahtjeva nekoliko koraka. Svakoj od tablica treba se pridružiti kontekst aplikacijske grupe 

(DBMS_RLS.ADD_POLICY_CONTEXT), zatim svakoj tablici pridružiti svaku od vlastitih VPD grupa 

(SYS_DBMS_RLS.CREATE_POLICY_GROUP) i na kraju, opcionalno, pridružiti policy funkciju 

(DDMS_RLS.ADD_GROUPED_POLICY). Slijedeći te korake, svakoj od relevantnih tablica pridružen 

je kontekst aplikacijske grupe. 

Slika 2: Shematski prikaz modela VPD implementacije 

168

egin 

dbms_rls.add_policy_context(object_schema => 'VLASNIK', 

object_name => 'TABLICA', 

namespace => 'VPD_CONTEXT', 

attribute => 'VPD_POLICY_GROUP'); 

end; 

/ 

Kreirane su dvije VPD sigurnosne grupe "VPD_PL_SQL" i "VPD_NULL" za svaku od tablica: 

begin 

sys.dbms_rls.create_policy_group(object_schema => 'VLASNIK', 


policy_group => 'VPD_PL_SQL'); 

end; 

/ 

begin 

sys.dbms_rls.create_policy_group(object_schema => 'VLASNIK', 


policy_group => 'VPD_NULL'); 

end; 

/ 

Za grupu "VPD_NULL" nije kreiranja nikakva sigurnosna politika, tj. nije pridružena ni jedna 

funkcija za vraćanje predikata, dok je za grupu "VPD_PL_SQL" svakoj od tablica pridružena bar jedna 

od dviju funkcija. 

begin 

dbms_rls.add_grouped_policy(object_schema =>'VLASNIK', 

object_name =>'TABLICA', 

policy_group =>'VPD_PL_SQL', 

policy_name =>'TABLICA_col', 

function_schema =>'VLASNIK', 

policy_function =>'vpd_p.col_vpd', 

sec_relevant_cols =>'OPC,NAS,UL,KBR', 

sec_relevant_cols_opt=>dbms_rls.all_rows, 

policy_type =>dbms_rls.CONTEXT_SENSITIVE); 

end; 

/ 

169

Slika 3: Ovisno o modelu konekcije na bazu korisniku se 'podmeće' odgovarajuća VPD grupa 

Za evidenciju podataka o grupama koje će se aktivirati prilikom konekcije na bazu kreirana je 

tablica u koju se za specifične atribute konekcije (korisnik baze, program, računalo/server, korisnik 

OS-a) zapisuje koja će se VPD grupa aktivirati. Prilikom konekcije na bazu okida se after logon trigger 

baze u kojem se poziva procedura za postavljanje konteksta VPD okruženja. U kontekstne atribute 

zapisuju se predikati svake sigurnosne grupe, te grupa koja predstavlja Driving Context. Postavljeno 

rješenje zadovoljava zahtjeve koji su postavljeni, ali je administracija dijelom zahtjevna. 

Sljedeći korak poboljšanja bio bi izgradnja grafičkog sučelja za potpunu administraciju VPD 

sigurnosne politike. Treba napraviti sučelje ("dashboard") na kojem će se vidjeti statusi svih definiranih 

VPD pravila i na kojem će biti jednostavne "komande" za aktivaciju i deaktivaciju pravila, te mogućnost 

definiranja novih. 

3 MOGUĆI PROBLEMI 

3.1 Oracle Forms aplikacija 

Kada se koristi VPD zaštita stupaca maskiranjem podataka javlja se problem ažuriranja podataka 

u Oracle Forms modulu, jer je vrijednost polja na ekranu (NULL) različita od one zapisane u bazi. Ova 

greška dovodi do otkrića još jednog problema sigurnosti VPD-a. 'Column masking' opcija zaštite radi 

samo nad SELECT naredbama. Kada nad istom tablicom izvedete SELECT ... FOR UPDATE tada 

'column masking' zaštita više ne funkcionira. SELECT FOR UPDATE je upravo ono što forma radi 

kada pokuša rezervirati slog za ažuriranje u izvornom ON-LOCK triggeru i tada se uspoređuju učitane 

vrijednosti s vrijednostima na bloku forme. Kada vrijednosti nisu jednake javlja grešku FRM 40654. 

Ova greška može se zaobići samo izmjenama u Forms modulu. 

170

Slika 4: Pokušaj ažuriranja podataka na formi koja ima maskirane stupce 

U našem rješenju oslonili smo se na sigurnost implementiranu u aplikaciji, te smo kod prijave u 

aplikaciju aktivirali VPD grupu (Driving Context) koja nema implementirane VPD funkcije. 

Istraživanjem po forumima, na linku http://www.orafaq.com/forum/t/30540/2/ postoji zapis o još 

jednoj mogućnosti pojave greške FRM 40654. Problem je dokumentiran kao Oracle Bug 7344505 

(metalink ID 759252.1). Greška se javlja samo kod dinamičkih VPD predikata. Na forumu je naveden 

primjer ažuriranja tablice kćeri D na koju je podignut VPD predikat koji provjerava postojanje retka u 

roditeljskoj tablici M. VPD pravila dozvoljavaju ažuriranje tablice D, dok ažuriranje tablice M nije 

dozvoljeno VPD-em. Kada se na formi pokrene ažuriranje retka tablice D forms modul izvodi 

zaključavanje sa SELECT FOR UPDATE koji kao rezultat vraća 0 redova i navodi forms modul na 

grešku kao da je netko obrisao slog. 

Greška se može zaobići zahvatom u ON-LOCK triggeru koji bi trebao na trenutak isključiti VPD. 

3.2 PL/SQL kôd na bazi 

Naišli smo i na problem u radu baznih procedura i funkcija u kojima nam je VPD zaštita neželjena 

pojava. Npr. željeli smo kontrolirati da li se JMBG radnika pojavljuje u tablicama ostalih poslovnih 

subjekata kao "nepoželjni" radnik. I ovaj problem zaobiđen je aktivacijom posebne VPD grupe prilikom 

prijave u aplikaciju. Rješenje se moglo postići i poigravanjem s atributima aplikacijskog konteksta, ali 

to je zahtjevalo zahvate u kôdu koje smo nastojali izbjeći. 

3.3 Rad s definiranim VPD grupama 

Prilikom definiranja vlastitih VPD grupa potrebno je u svaku od grupa uključiti sve tablice koje se 

pojavljuju u bilo kojoj od grupa. Mogući scenarij je npr.: kreirali ste grupu G1 i nju pridružili tablicama 

T1 i T2, zatim grupu G2 i nju priključili tablici T1. Kada korisnik u sesiji na bazi ima pridruženu grupu 

G2 i pokuša čitati tablicu T2 javit će se greška: 

ORA-28123 Driving context 'string,string' contains invalid group 'string'. 

Uvijek provjerite podatke u tablici DBA/USER/ALL_POLICY_GROUPS, tj. da li je svakoj od tablica 

pridružena svaka od grupa. 

3.4 Greške u VPD funkcijama 

Ukoliko je funkcija koja vraća predikat VPD-a u statusu "invalid" ili ima grešku javit će se poruka 

171

greške prilikom rada s tablicom/viewom: 

ORA-28112 Failed to execute policy function. 

Kada funkcija vrati predikat s neispravnom sintaksom javit će se: 

ORA-28113: policy predicate has error 

3.5 DBMS_RLS Policy Type 

Ukoliko u predikatima VPD pravila koristite aplikacijski kontekst tada parametar policy type 

prilikom kreiranja VPD pravila (DBMS_RLS.ADD_POLICY, DBMS_RLS.ADD_GROUPED_POLICY) 

ne smije imati vrijednost STATIC ili SHARED_STATIC. Na primjerima koji su testirani predikat je bio 

oblika: 

ime_kolone = SYS_CONTEXT('NEKI_CONTEXT','ATRIBUT'). 

Rezultat VPD pravila bio je nepredvidiv, ovisio je o vrijednosti inicijalno pohranjenoj u SGA 

međumemoriju. Kada se parametar Polici Type postavlji kao DYNAMYC, CONTEXT_SENSITIVE, 

SHARED_CONTEXT_SENSITIVE pravila VPD-a s kontekstnim varijablama u predikatima rade 

ispravno. 

3.6 Rekurzija u VPD definiciji 

Potrebno je naglasiti mogućnost pojave rekurzije. Oprezno koristite tablice/viewe koji imaju 

podignutu VPD zaštitu u funkcijama za vraćanje VPD predikata. Moguć je scenarij beskonačne petlje 

kada npr. funkcija F1 poziva proceduru P2, koja zatim poziva proceduru P3 koja čita iz tablice koja ima 

implementiranu VPD zaštitu funkcijom F1. 

Za bolje performanse analizirajte predikate koje kreiraju VPD funkcije čitajući zapise u 

V$VPD_POLICY, te podignite odgovarajuće indexe. 

3.7 Web aplikacija 

U web aplikacijama praksa je da se konekcija na bazu radi s fiksnim aplikacijskim korisničkim 

imenom, npr. APPKORISNIK. U takvoj situaciji VPD sigurnost se ne može oslanjati na korisnika baze 

(APPKORISNIK), već na korisnika koji se prijavio u aplikaciju. Za takvu situaciju postoji relativno 

jednostavno rješenje. Kreirati će se novi atribut globalnog aplikacijskog konteksta REALUSER čija će 

vrijednost biti stvarni korisnik aplikacije. 

begin 

sys.dbms_session.set_context(namespace => 'VPD_GLOB_CTX', 

attribute => 'REALUSER', 

value => upper(p_user), 

username => user, 

client_id => upper(p_user)); 

dbms_session.set_identifier(p_user); 

end; 

Kreirati će se nova VPD sigurnosna grupa VPD_WEB_SEC čije funkcije će se oslanjati na 

korisnika zapisanog u globalnom aplikacijskom kontekstu. 

172

Tabela 4: Predloženi scenarij VPD-a ovisno o modelu konekcije na bazu [1] 

Budući da web rješenja u našem okruženju nemaju široku primjenu, a korisnik za konekciju na 

bazu koristi se isključivo u aplikaciji, odlučili smo u tim rješenjima za sada ostati na VPD zaštiti 

jedinstvenog korisnika koji se konektira na bazu. 

4 ZAOBILAŽENJE VPD-A 

Dobro je znati da VPD pravila ne pogađaju sve korisnike. To je učinjeno namjerno iz više razloga. 

Jedan od razloga je kako bi se osigurao potpuni i točni backup svih podataka. Također, bilo bi 

problema kada bi se dogodila neka greška u nekoj od funkcija VPD-a koja ne bi dozvoljavala 

konekciju na bazu ni jednom korisniku. 

Zadana je postavka Oracle baze da su svi korisnici koji imaju SYSDBA privilegiju isključeni iz 

VPD-a. Također, i korisnici kojima je dodijeljena sistemska privilegija "EXEMPT ACCESS POLICY" ne 

prolaze kroz VPD sigurnosni sustav. Dobro je periodično provjeriti korisnike kojima je ta privilegija 

dodijeljena: 

select * from dba_sys_privs where privilege = 'EXEMPT ACCESS POLICY'; 

Dodjeljivanje ove sistemske privilegije treba izbjegavati u praksi, a pogotovo uz opciju "with admin 

option". Na primjeru vlastitog rješenja prikazano je kako se VPD sigurnost može postaviti tako da se 

ovisno o kontekstu konekcije na bazu pojedina pravila VPD-a uključe ili isključe. 

5 SIGURNOST VPD OKRUŽENJA 

5.1 Potencijalni problemi 

VPD nije savršen i potpuno siguran mehanizam. Postoji niz slabih karika koje treba dodatno 

osigurati. Moguće slabe točke VPD-a su: 

− informacije o predikatima 

− informacija o VPD definicijama 

− zaštita VPD strukture baznim rolama 

− mogućnosti zaobilaženja VPD-a 

− SQL injekcija 

− pristup podacima izvan baze. 

173

5.2 Informacije o predikatima 

Iz viewa v$vpd_policies moguće je dobiti popis izvedenih sigurnosnih pravila VPD-a i njihovih 

predikata. Ovo je zanimljiv view, pogotovo ako se poveže s v$sqlarea ili v$sql tako da se dobije 

originalni SQL i korišteni predikat. Ovo je primjer jednog takvog upita na bazu: 

select sql_text, predicate, policy, object_name 

from v$sqlarea, v$vpd_policy 

where hash_value = sql_hash; 

Zbog sigurnosti, pristup ovim podacima baze treba dozvoliti samo administratorima sustava. 

Postoji i nekoliko načina da se "trejsanjem" dođe do podataka o predikatima VPD pravila. Jedan 

od jednostavnijih načina je uz korištenje "Event 10730": 

alter session set sql_trace=true; 

alter session set events '10730 trace name context forever'; 

select * from neka_tablica_koja_ima_vpd; 

alter session set events '10730 trace name context off'; 

alter session set sql_trace=false; 

Datoteka s rezultatima izgleda otprilike ovako: 

*** 2003-10-19 16:30:59.000 *** SESSION ID:(7.64) 2003-10-19 16:30:59.000 

------------------------------------------------------------- Logon user 

: VPD Table or View : VPD.TRANSACTIONS Policy name : VPD_TEST_POLICY 

Policy function: VPD.VPD_POLICY.VPD_PREDICATE RLS view : SELECT 

"TRNDATE","CREDIT_VAL","DEBIT_VAL","TRN_TYPE","COST_CENTER" FROM 

"VPD"."TRANSACTIONS" "TRANSACTIONS" WHERE (cost_center='ACCOUNTS') 

Iz podataka se može isčitati predikat VPD-a. Slično se može iskoristiit i "Event 10060". 

5.3 Informacije o VPD definicijama 

Iz viewa %_POLICY_GROUPS, %_POLICY_CONTEXTS, %_POLICIES, 

%_SEC_RELEVANT_COLS moguće je saznati detalje o VPD konfiguraciji. Pristup ovim podacima 

treba ograničiti isključivo na administratore sustava. Također treba zaštititi i pristup podacima o 

izvornom kodu funkcija koje se koriste za vraćanje predikata (OBJ$, SOURCE$, PROCEDURE$, 

ARGUMENT$, %_SOURCE, V$CONTEXT, v$GLOBALCONTEXT i ostalo). 

5.4 Zaštita VPD strukture baznim rolama 

U prethodnom poglavlju spomenuti su neki od viewa koje treba dodatno zaštititi. Osim toga treba 

poraditi i na zaštiti paketa DBMS_RLS i DBMS_SESSION. Potrebno je razmisliti o zaštiti lokalnog i 

globalnog konteksta. Preporuka je da se kontekst definira tako da se dozvoli ažuriranje isključivo 

preko dedicirane bazne procedure, koju treba zaštititi od neovlaštenog izvođenja. 

Vlastite tablice, procedure, triggeri u kojima se definiraju dodatni parametri VPD okruženja 

trebaju se uključiti u strogi mehanizam zaštite. Nikako se ne smiju zanemariti i sistemske privilegije 

kojima se može utjecati na navedene objekte. 

5.5 Mogućnost zaobilaženja VPD-a 

Već je spomenuto kako se VPD u potpunosti može zaobići s "EXEMPT ACCESS POLICY" 

sistemskim ovlaštenjem. Osim toga u praktičnoj implementaciji VPD-a koriste se vlastite tablice i 

kontekstne varijable. Ove podatke moguće je zlonamjerno očitati ili izmijeniti i na taj način prevariti 

VPD. Korisnici s ovlastima nad paketom DBMS_RLS imaju mogućnost rušenja (drop) ili kreiranja VPD 

pravila. 

5.6 SQL injekcija 

U knjizi "Oracle Hacker’s Handbook" [4] prikazano je kako se SQL injekcijom može npr. izvršiti 

174

ušenje (drop) VPD pravila. Ukratko, preko procedure XDB_PITRIG vlasnika XDB koji ima ovlasti za 

izvođenje DBMS_RLS napravljena je SQL injekcija naredbe DBMS_RLS.DROP_POLICY. 

SQL> CONNECT SCOTT/TIGER 

Connected. 

SQL> SELECT * FROM VPD.VPDTESTTABLE; 

CLASSIFICATION ORDER_TEXT RANK 

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

UNCLASSIFIED UPDATE DUTY ROTA CORPORAL 

UNCLASSIFIED POLISH BOOTS MAJOR 

SQL> CREATE OR REPLACE FUNCTION F RETURN NUMBER AUTHID CURRENT_USER IS 

2 PRAGMA AUTONOMOUS_TRANSACTION; 

3 BEGIN 

4 DBMS_OUTPUT.PUT_LINE('HELLO'); 

5 EXECUTE IMMEDIATE 'BEGIN 

SYS.DBMS_RLS.DROP_POLICY(''VPD'',''VPDTESTTABLE'',''SECRECY''); END;'; 

6 RETURN 1; 

7 COMMIT; 

8 END; 

9 / 

Function created. 

SQL> CREATE TABLE FOO (X NUMBER); 

SQL> EXEC XDB.XDB_PITRIG_PKG.PITRIG_DROP('SCOTT"."FOO" WHERE 

1=SCOTT.F()--','BBBB'); 

PL/SQL procedure successfully completed. 

SQL> SELECT * FROM VPD.VPDTESTTABLE; 

CLASSIFICATION ORDER_TEXT RANK 

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

SECRET CAPTURE ENEMY BASE GENERAL 

UNCLASSIFIED UPDATE DUTY ROTA CORPORAL 

SECRET INVADE ON TUESDAY COLONEL 

UNCLASSIFIED POLISH BOOTS MAJOR 

5.7 Pristup podacima izvan baze 

Direktnim pristupom "sirovim" podacima na disku mogu se očitati podaci koj su VPD-em 

zaštićeni. U "Oracle Hacker’s Handbook" [4] prikazan je jedan takav primjer Java procedure na bazi 

koja čita "sirove" podatke i ispisuje ih. Ovakvoj opasnosti podvrgnute su "backup" i "export" datoteke. 

Osjetljive podatke trebalo bi dodatno zaštititi enkripcijom. 

5.8 Column Masking slabosti 

Column Masking opcija zaštite stupaca funkcionira sam uz SELECT naredbe, i to na prvi pogled 

izgleda u redu. Međutim, jedna od grešaka koja je uočena testiranjem sustava, a nema zapisa o tome 

u literaturi je problem naredbe SELECT ... FOR UPDATE. Takvim dohvatom podataka stupci tablice 

nisu maskirani kao što bi se očekivalo. 

Propust u sugurnosti "Column Maskinga" može se uočiti i pozivom naredbe UPDATE, tako na 

primjer naredbom: 

update radnici t 

set t.neko_polje = '' 

where id = 2413 returning jmbg into :jmbg; 

može se očitati zapis stupca koji očekujemo da bude skriven VPD-om. 

Na temelju prikazanih primjera zaključuje se da je maskiranje stupaca sigurno samo u slučaju kada 

korisnik nema pridružene bazne ovlasti za ažuriranje zaštićene tablice. 

175

ZAKLJUČAK 

VPD nije svemoguć! Prikazali smo neke od mogućnosti zlouporabe. Mehanizam maskiranja 

stupaca ima iznenađujućih propusta. Za efikasnu zaštitu servere i bazu treba dodatno pratiti i zaštititi, 

te primijeniti višeslojnu zaštitu. Treba znati da je VPD samo jedan od segmenata zaštite. Primjenjiv je 

i efikasan u radu korisnika koji bazi pristupaju samo s ovlastima za čitanje podataka. VPD nikako ne 

pruža kvalitetnu zaštitu od zlonamjernih napada na podatke. Glavna prednost je u tome što se 

implementira direktno na bazi i ne zahtjeva dodatne izmjene u aplikacijama, a koristi ga svaka 

aplikacija koja pristupa bazi. 

Ukoliko se, unatoč prikazanim nedostacima, ipak odlučite koristiti Oracle VPD, nastojite primijeniti 

zlatno pravilo jednostavnosti kako se ne biste izgubili u džungli administracije VPD pravila. 

LITERATURA 

1. Oracle® Database Security Guide 10g Release 2 (10.2) 

2. Ben-Natan, R. (2009): HOWTO Secure and Audit Oracle 10g and 11g, Auerbach Publications 

3. Knox, D. C. (2004): Effective Oracle Database 10g Security by Design, McGraw-Hill 

4. David Litchfield (2007): Oracle Hacker’s Handbook, Wiley 

5. Thomas Kyte: Expert one-on-one Oracle, Apress 

LINKOVI 

6. https://forums.oracle.com/forums/ 

7. http://www.petefinnigan.com/Oracle_Security_VPD6Slides.pdf 

8. 

http://www.symantec.com/connect/articles/oracle-row-level-security-part-2 

176

ORACLE/ORACLE SPATIAL I FME ETL - RAZMJENA PODATAKA NEOVISNO O 

FORMATU 

Martin Martić 

Multisoft d.o.o., Zagreb, Ivana Broza 12/II 

Mob: 098/9000 465 

e-mail: martin.martic@multisoft.hr 

web: www.multisoft.hr 

Mario Starčević 

Multisoft d.o.o., Zagreb, Ivana Broza 12/II 

e-mail: mario.starcevic@multisoft.hr 

SAŽETAK 

Ovaj referat opisuje alate i tehnike koji osiguravaju jedinstveni način prikupljanja i izdavanja 

podataka izmeĎu Oracle/Oracle Spatial baze podataka i različitih standardnih i nestandardnih - ASCII, 

CAD, raster, data base i/ili GIS - formata s naglaskom na prostorne podatke. Isto tako prikazane su 

mogućnosti podrške procesa kontrole kvalitete, analize i reformatiranja prostornih podataka, njihove 

standardizacije, primjene za pojedinačne poslove kao i automatizacije za masovne istovrsne poslove. 

Rad se temelji na FME Desktop i FME Server softverima. 

SUMMARY 

This paper describes tools and techniques that provide a unique way of collecting and publishing 

data between Oracle/Oracle Spatial database and various standard and non-standard – ASCII, CAD, 

raster, database and/or GIS - formats with focus on spatial data. Also, the support for process of 

quality control, analysis and reformatting of spatial data, its standardization, implementation of 

individual tasks and automation of mass equivalent transactions are displayed. The paper is based on 

FME Desktop and FME Server software. 

1 UVOD 

Najjača komponenta geografskih informacijskih sustava je vizualizacija. To je razlog zašto sve 

više firmi koristi, uvodi ili planira uvesti GIS sustav u svoje poslovanje. GIS kao integrator vektorskih, 

rasterskih, prostornih i drugih vrsta podataka unutar jednog sustava, da bi imao vrijednost, mora 

omogućiti široki raspon funkcija za upravljanje i analizu podataka. Prije toga moraju se obaviti postupci 

unosa, migracije i spremanja podataka u željeni GIS sustav. Kada razmišljamo o migraciji podataka, 

problem na koji nailazimo su: količina različitih datoteka/baza u kojima su pohranjene informacije, 

vrijednosti atributa nekog objekta najčešće su spremljene u različitim formatima, prostorne 

(geometrijske) podatke želimo spojiti sa atributnim (alfa-numeričkim) podacima, prije migracije 

podataka u jedinstvenu bazu, podaci trebaju zadovoljavati neke formalne kontrole. Alat koji želite imati 

kod rješavanja ovakvih problema je FME Desktop i FME Server. Ovaj referat opisuje mogućnosti ovih 

alata kod i izdavanja podataka izmeĎu Oracle/Oracle Spatial baze podataka i različitih standardnih i 

nestandardnih - ASCII, CAD, raster, data base i/ili GIS - formata s naglaskom na prostorne podatke. 

2 STANDARDNI I NESTANDARDNI FORMATI PROSTORNIH PODATAKA 

Raširena uporaba GIS-a krajem devedesetih godina prošlog stoljeća proizvela je značajne 

količine prostornih podataka. Većina programske podrške je u to vrijeme koristila vlastite formate 

podataka za pohranjivanje geometrije i vlastiti DBMS. Takav način definiranja vlastitih formata dovela 

je do toga da danas postoji više od 250 formata i to su formati od poznatih proizvoĎača softvera. 

Često se možemo susresti sa nestandardnim zapisima prostornih podataka (geometrija), gdje su 

aplikacije koristile vlastiti način spremanja podataka koordinata u tekstualne datoteke. TakoĎer, unutar 

baza podataka koje ne podržavaju prostornu komponentu ili ju starija verzija baze nije podržavala, 

koordinate su spremane u alfa-numeričkim atributima. 

Tipovi prostornih podataka se mogu podijeliti na: 

177 

1

- vektorske 

- rasterske 

Slika 1 Stvarni svijet kroz tipove prostornih podataka 

Tip rasterskih podataka sastoji se od redova i stupaca ćelija. Svaka ćelija može imati vrijednost, a 

razlučivost rasterskog skupa podataka ovisi o površini ćelije. Tip vektorskih podataka sastoji se od 

koordinata jedne točke, početne i krajnje točke neke dužine, koordinata uzduž neke krivulje itd. 

3 ORACLE SPATIAL BAZA PODATAKA 

Oracle Spatial (eng. spatial = prostorni) je integrirani set funkcija i procedura, koje omogućavaju 

spremanje, pristupanje, te brzo i učinkovito analiziranje prostornih podataka unutar Oracle baze 

podataka. Prostorni podaci predstavljaju lokacijske karakteristike pravih ili pojmovnih (konceptualnih) 

objekata, odnosno kako su ti objekti postavljeni u odnosu na stvarni ili konceptualni prostor u kojem su 

smješteni. 

Oracle Spatial, često označavan samo Spatial, podržava standardnu SQL shemu i funkcije koje 

omogućuju pohranjivanje, pozivanje, obnavljanje i pregledavanje skupa prostornih prikaza u bazi 

podataka. Sastoji se od sljedećih komponenata: 

• Sheme (MDSYS) koja propisuje spremanje, sintaksu i semantiku podržanih geometrijskih 

tipova podataka 

• Prostornog indeksnog mehanizma 

• Skupa operatora i funkcija za izvršavanje područja-zanimanja (area-of-interest) upitnika i 

upitnik prostornog spajanja (spatial join), te ostalih operacija za prostorne analize 

• Administrativne alate 

• Funkcije i procedure za pomoćne i podesive operacije 

• Topologija modela podataka za rad s podacima o čvorovima, rubovima i licima u topologiji 

(opisano u Oracle Spatial Topology i Network Data Models). 

• Mrežni model podataka za mogućnosti zastupanja ili predmete koji su modelirani kao čvorovi 

i veze u mreži (opisano u Oracle Spatial Topology i Network Data Models). 

• GeoRaster značajku koja omogućuje pohranu, indekse, upite, analize, i dostavu GeoRaster 

podataka, koji je točkasta slika i mrežasti podatak s pridruženim metapodacima (opisano u 

Oracle Spatial GeoRaster). 

Prostorno svojstvo (atribut prostornog prikaza) jest geometrijski opis njegovog oblika u nekom 

koordinatnom sustavu. Taj pojam se naziva geometrija. 

4 FME APLIKACIJE 

FME je vodeći ETL(Extract/Transform/Load) alat u svijetu, korišten od strane tisuće GIS 

profesionalaca širom svijeta za brzo dohvaćanje, ureĎivanje i unos podataka. 

178 

2

Slika 2 Prikaz dohvaćanja, uređivanja i unosa 

Služi za dobivanje prostornih podataka u točan format i strukturu. Ima podršku za čitanje i pisanje više 

od 250 prostornih i alfanumeričkih formata. UreĎuje podatke u točno željenu strukturu. Nudi više od 

400 transformera, koji pomažu kod djelovanja na geometriju i atribute prostornih podataka na 

njihovom putu od dohvaćanja prema zapisivanju u neki od podržanih formata. FME podržava oko 

5000 koordinatnih sustava čime je moguća pretvorba podataka na temelju projekcija, elipsoida i 

datuma. 

Može se definirati i vlastiti korisnički koordinatni sustav. 

4.1 FME Desktop 

Dolazi sa nizom alata koji proučavaju prostorne podatke i njihovu obradu čine jednostavnijom. 

FME Workbench – je grafičko okruženje unutar kojeg korisnik kreira prostor za rad (workspace) i u 

kojem dohvaća podatke u željenim formatima, djeluje na njih i šalje ih u željeni format. 

FME Universal Viewer – je jako koristan alat za brzi pregled prostornih podataka. Povezan je sa 

Workbench-om čime omogućuje prikaz podataka koji se obraĎuju unutar nekog Workspace-a. 

FME Universal Translator – kreiran je za brze transakcije i jednostavnu pretvorbu izmeĎu brojnih 

formata. TakoĎer je koristan za brzo pokretanje Workspace-a. 

4.2 FME Server 

Poslužuje ažurirane podatke točno gdje, kada i kako ih trebate. Dizajniran je da rukuje sa velikom 

količinom podataka i dopušta efikasno posluživanje podataka kroz široki raspon formata. Firme koriste 

FME Server za jednostavnije skupljanje, obradu i distribuciju prostornih i alfanumeričkih podataka. 

5 PROCESI 

5.1 Proces analize podataka 

FME Workbench nudi brojne transformere koji mogu poslužiti kod analize prostornih podataka. 

Kada se podaci dostave da bi što brže i jednostavnije napravili zadane kontrole, preinake i na kraju 

pretvorili ih u novi format ili unijeli u željenu bazu prostornih podataka, treba se napraviti kvalitetna 

analiza. Za analizu podataka transformer koji želimo koristiti je StatisticsCalculator. 

179 

3

Slika 3 Primjer FME Worksapace-a za analizu layera 

Na Slici 3 je primjer analize u kojoj nad zadanim direktorijem, FME prolazi kroz sve AutoCAD DWG 

datoteke, te za zadanu datoteku radi popis svih slojeva (layera) i broj zapisa u tom sloju. 

Slika 4 Parametri StatisticCalculator transformera 

Kod analize vrijednosti nekog atributa nam StatisticCalculator daje brojne mogućnosti. Parametri na 

slici 4, prikazuju da je analizom moguće dobiti desetak statističkih vrijednosti atributa, kao što su: 

minimalna vrijednost atributa, maksimalna vrijednost atributa, srednja vrijednost, suma vrijednosti itd. 

Kod nekih podataka koji ne dolaze sa specificiranim koordinatnim sustavom, potrebno je napraviti 

analizu koordinatnog sustava u kojem su koordinate podataka. 

Neke od analize koje se najčešće provode su: 

Slika 5 Testira koordinatni sustav 

180 

4

- provjera slojeva i blokova unutar AutoCAD-a 

- vrste geometrija (linija, točka, površina itd.) koje se nalaze unutar sloja, tablice, datoteke 

- razne analize vrijednosti atributa (tipovi, numeričke vrijednosti, itd.) 

5.2 Proces kontrole podataka 

Nakon analize podataka s kojima raspolažemo, potrebno je napraviti kontrole da bi bili zadovoljeni 

uvjeti za zapis podataka u bazu/datoteku. Podaci ponekad imaju vrijednosti atributa odvojene od 

geometrije objekta. Potrebno je spojiti te dvije vrijednosti. Način na koji se te vrijednosti spajaju mogu 

biti razni. Unutar AutoCAD podataka, atributi su obično stavljeni u blokove i preko točke unosa (insert 

point-a) se spajaju sa geometrijom. Tu se zna dogoditi da zbog ljudskog faktora, točka unosa nije 

dobro unesena na geometriju ili se nalazi na mjestu gdje se više geometrija preklapa. 

Slika 6 Kontrola veze geometrije sa atributima 

Slika 6 prikazuje kombinaciju dva transformera gdje prvi kontrolira preklapanje točke unosa bloka sa 

linijom objekta, na koji se nadovezuje transformer koji testira da li se točka preklapa sa jednom linijom, 

više linija ili sa niti jednom linijom. 

Kontrola koja je prikazana na slici 7 prikazuje način provjere da li je linija prekratka, te da li linija 

presijeca samu sebe. 

Slika 7 Kontrola duljine i presjecanja 

Neke od kontrola koje se najčešće provode: 

- ispravno povezane (SNAP-irane) geometrije 

- uneseni atributi i kontrola vrijednosti 

- ispravna vrsta geometrije za zadani objekt 

181 

5

5.3 Proces promjene formata 

Svaki format u koji se podaci spremaju ima svoju strukturu koje se treba pridržavati. Pretvorbe 

podataka iz postojećeg u novi format unutar FME aplikacije, kada sve vrijednosti i izgled objekta ostaje 

isti, su jednostavni i FME Workbench kod odabira ulaznih podataka (u nekom formatu) i izlaznih 

podataka (u željenom drugom formatu) kreira radnu plohu automatski. 

Slika 8 Prozor za automatsko generiranje radne plohe 

Slika 9 Automatski generirana radna ploha 

Kod odreĎenih formata, najčešće kod baza podataka koje dopuštaju da objekt ima više prostornih 

atributa, ili formati koji ne spremaju atribute uz geometriju, potrebno je generiranu radnu plohu 

dodatno doraditi. 

6 Rad sa Oracle Spatial 

Spajanje na Oracle bazu se razlikuje od korištenja formata koji spremaju podatke u 

datoteke/direktorije. Spajanje na Oracle zahtjeva instalaciju klijenta. 

182 

6

Spojiti se može preko tnsnames.ora ili direktnom konekcijom. 

6.1 Spajanje preko tnsnames.ora 

Slika 10 Odabir Oracle formata 

Kod odabira formata Oracle Spatial Object pritisne se na Parameters… gdje se upisuju traženi 

parametri kao na slici 11. Nakon toga se kod Table List pritiskom na […] trotočje dobije popis tablica 

sa kojima se želi rukovati. 

6.2 Spajanje direktnom konekcijom 

Slika 11 Parametri za spajanje 

Kod odabira formata Oracle Spatial Object pod Dataset se upiše niz parametara potrebnih za 

spajanje, kao što je upisano na slici 12. 

Slika 12 Parametri za direktnu konekciju 

Pritiskom na Parameters… se kod Table List pritiskom na […] trotočje dobije popis tablica sa kojima 

se želi rukovati. 

183 

7

6.3 Rukovanje unosom 

Spajanje na Oracle bazu za čitanje podatak iz nje ili za pisanje u nju je jednako i vrši se preko 

parametara kao što je navedeno iznad. Kada se podaci zapisuju u Oracle bazu odreĎeni zapis unutar 

tablice možemo unijeti (insert), promijeniti (update) i obrisati (delete). Da bi odredili način na koji ćemo 

rukovati sa zapisom unutar tablice postoji atribut fme_db_operation u koji zapisujemo jednu od 

naredbi: DELETE, INSERT ili UPDATE. Kada znamo kako odrediti način na koji ćemo rukovati sa 

zapisom, biramo kojim zapisima želimo dodati odreĎeno rukovanje. Za to se koristi atribut fme_where. 

Njegova struktura je: 

Slika 13 Primjer na koji se filtriraju zapisi 

Na slici 13 je prikazano korištenje filtra kod atributa koji odreĎuje rukovanje zapisima preko vrijednosti: 

I za INSERT, U za UPDATE i D za DELETE. 

6.4 Smisleno dohvaćanje podataka 

Kod dohvaćanja podataka iz Oracle baze važno je dohvatiti željene tablice i zapise, pri tome pazeći da 

broj dohvaćenih zapisa bude što manji. Što je manje zapisa, biti će brže čitanje, manje sistemskih 

resursa će se zauzeti i brže će se obaviti posao. 

6.5 Where upit (Where Clause) 

Većina čitanja iz baze će biti preko where upita. Tu se postavlja upit, da bi se dohvatili samo podaci 

koji zadovoljavaju taj upit i vratili u FME. Ovaj parametar zapošljava alat baze, pa je zbog toga 

efikasniji od čitanja cijele tablice i filtriranja preko Tester transformera. 

6.6 Granica dohvaćanja (Search Envelope) 

Slika 14 Where Clause 

Slično where upitu, granica dohvaćanja specificira prostorni upit, na način da se u FME vraćaju samo 

podaci koji su unutar zadane granice. Ovaj parametar takoĎer zapošljava alat baze, pa je zbog toga 

efikasniji od čitanja cijele tablice i rezanja podataka sa Clipper transformerom. 

184 

8

6.7 Broj dohvaćanja zapisa u vremenu 

Slika 15 Search Envelope 

Ovaj parametar definira koliko će zapisa dohvatiti u jedinici vremena iz baze. Ovim parametrom se 

može namjestiti performansa čitanja. 

Premali broj i FME će trošiti previše vremena na zahtjevima za čitanje. 

Preveliki broj i performanse baze mogu biti smanjene za ostale korisnike. 

6.8 Zapis višestrukih geometrija 

Većina baza ima mogućnost unosa više geometrija u zapis tablice, što podržava i FME. MeĎutim, da 

bi se tablica sa višestrukom geometrijom mogla unositi, takva tablica mora postojati, FME ju ne može 

kreirati. 

Postoje dva načina zapisa višestruke geometrije: 

- čitanje i pisanje višestruke geometrije 

- čitanje jednostruke geometrije i pretvaranje tih geometrija u višestruke 

Kod prvog načina zapisivanje se radi automatski. Dok kod drugog načina je potrebno grupirati 

geometrije za isti zapis prije upisivanja. 

6.9 Transformeri nad bazom 

Slika 16 Grupiranje u višestruke geometrije 

Postoje dva načina izvršavanja SQL koda nad bazom. SQL kod može biti unesen u parametar da se 

pokreče prije i poslije pokretanja posla. Drugi način je korištenje SQL transformera unutar posla. 

SQL kod se može koristiti za kreiranje, brisanje i mijenjanje tablica baze ili za bilo koju drugu namjenu 

za koju se koristi izvoĎenje SQL koda. 

6.10 Transakcije nad bazom 

Transakcije su način na koji se radna ploha može napraviti efikasnijom. Preko intervala transakcije 

specificiramo broj zapisa koji će biti zapisan u bazu u jednoj transakciji. Zapisi se šalju u priručnu 

memoriju dok ne dosegnu zadani broj i onda se pošalju u bazu. Povećavanjem broja možemo 

povećati performanse, budući da se koristi manje transakcija za zapis. MeĎutim postoji i maksimalna 

185 

9

veličina priručne memorije, koju se ne smije potpuno popuniti da ne bi došlo do usporavanja cijelog 

sistema. 

7 IZVOĐENJE 

7.1 Izvođenje unutar FME Workbencha 

Kada je radna ploha sa ulaznim i izlaznim podacima napravljena, spremni smo za njeno izvoĎenje 

unutar Workbencha potrebno je pritisnuti (File Run Transaction), tipku F5 ili ikonu . 

Slika 17 Tri ikone za pokretanje posla 

Osim ovog osnovnog pokretanja postoje još dva načina pokretanja posla. Jedan je pokretanje sa 

odabirom objavljenih parametara . Drugi je pokretanje uz kontrolu . 

7.2 Izvođenje unutar FME Quick Translator-a 

Ova aplikacija FME-a služi za brzo pokretanje radne plohe, kada nam nije potrebno da vidimo način 

na koji se čitaju i zapisuju podaci te koji se sve transformeri koriste. 

Slika 18 FME Quick Transformer 

186 

10

Kod pokretanja plohe na ovaj način potrebno je izabrati vrijednosti za objavljene parametre i izvoĎenje 

se pokreče. Ispiše se izvještaj o uspješnosti izvoĎenja. 

7.3 Izvođenje preko automatske skripte 

Kada želimo lakše i automatizirano pokrenuti FME posao, napravimo tekstualnu datoteku u koju 

prebacimo tekst naredbe i spremimo ju sa nastavkom .bat. Naredba se može zapisivati u više redova, 

ako na kraju reda stavimo znak ^. Primjer naredbe: 

fme.exe shape2mif.fmw^ 

--SourceDataset_SHAPE E:\FME_HrOUG\Shape\pu_opcine.shp^ 

--DestDataset_MIF E:\FME_HrOUG\Mapinfo 

pause 

Naredba pause ostavlja vidljiv prozor. Objavljenim parametrima u ovom slučaju: 

--DestDataset_MIF 

--SourceDataset_ACAD_6 

možemo unositi vrijednosti. Time dobijemo dinamičko izvoĎenje preko skripte koju možemo ručno 

pokretati ili pripremiti za automatsko pokretanje u željeno vrijeme (Scheduled Tasks). 

7.4 Izvođenje na FME Serveru 

FME Server je skalabilna ETL platforma koja pruža fleksibilnu distribuciju i unos podataka. Prednost 

ovakve platforme je da ju korisnici mogu koristiti bilo kada i bilo gdje, pri čemu ne trebaju imati 

instaliranu FME aplikaciju. Serveru se pristupa preko Intraneta/Interneta i dopušta pokretanje FME 

poslova koji se nalaze na serveru. Server dopušta skidanje podataka koji su izlaz iz pokrenutog posla 

ili se ti podaci mogu slati (Streaming) na neki od popularnih web aplikacija kao što su Google 

Earth/Maps, Microsoft Bing, OpenLayers i druge. 

187 

11

PROGRAMSKA PODRŠKA SUSTAVA ZA LOCIRANJE MUNJA U HRVATSKOJ 

Ime i prezime autora: Bojan Franc 

Tvrtka autora: Fakultet elektrotehnike i računarstva, Sveučilište u Zagrebu 

Adresa: Unska 3, 10000 Zagreb 

Kontakt telefon autora: +385 1 612 95 10 

E-mail autora: bojan.franc@fer.hr 

Web: www.fer.hr 

Ime i prezime autora: Miroslav Šturlan 




E-mail autora: miroslav.sturlan@fer.hr 


Ime i prezime autora: Ivo Uglešić 




E-mail autora: ivo.uglesic@fer.hr 


Ime i prezime autora: Ivan Goran Kuliš 

Tvrtka autora: Končar-KET 

Adresa: Fallerovo šetalište 22, 10000 Zagreb 


E-mail autora: ivangoran.kulis@koncar-ket.hr 

Web: www.koncar-ket.hr 

SAŢETAK 

Praćenje grmljavine u realnom vremenu može biti učinkovito sredstvo u voĎenju prostorno 

distribuiranih sustava izloženih atmosferskim uvjetima. Danas takvi sustavi predstavljaju snažno oruĎe 

u projektiranju, zaštiti i voĎenju elektroenergetskih mreža, a njihova je primjena i u drugim sustavima i 

mrežama kao što su TK mreže, RTV odašiljači, naftovodi, plinovodi, sustavi osiguranja, meteorološki 

servisi, agencije za zaštitu od požara i dr. Podaci pristigli iz raznih izvora obraĎuju se i pohranjuju u 

Oracle 11g instanci baze podataka. GIS podaci promatranih objekata na tlu prostorno se koreliraju s 

podacima o udarima munja u realnom vremenu korištenjem Oracle Spatial funkcionalnosti te se 

prezentiraju pomoću Autodesk MapGuide webGIS rješenja. 

SUMMARY 

Real time lightning tracking can be an effective asset in management of spatially distributed 

systems which are exposed to atmospheric conditions. Such systems represent a powerful tool in 

design, protection and control of power systems. Their application also lies in numerous other 

systems, like telecommunication, radio and television networks, pipelines, insurance companies, 

meteorological services, fire fighting agencies, etc. Data acquired from multiple sources are processed 

and stored in an Oracle 11g database instance. GIS data of monitored structures on the ground are 

correlated with lightning data real-time using Oracle Spatial functionality. Correlations are displayed 

using Autodesk MapGuide webGIS solutions. 

188 

1

1. UVOD 

Praćenje i nadzor atmosferskih pražnjenja u realnom vremenu i prostoru može biti efikasno 

sredstvo i značajna pomoć u voĎenju EES-a. U svijetu se takvi sustavi rašireno koriste i neprekidno 

usavršavaju već više od dvadesetak godina. Velike razvijene zemlje su u potpunosti pokrivene s više 

različitih sustava za lociranje munja (SLM), a oni se koriste i u okolnim zemljama (Italija, Slovenija, 

MaĎarska i dr.). Danas se kao imperativ nameće uvoĎenje takvih sustava i njihova primjena u voĎenju 

elektroenergetskih sustava. Prije svega treba izbjeći da na karti Europe elektroenergetski sustavi koje 

vodimo ostanu u "sivoj zoni" u praćenju grmljavinske aktivnosti, ako se zna da se danas velika većina 

zemalja povezuje na ovom zadatku. 

2. SUSTAV ZA LOCIRANJE MUNJA - LINET 

Europski sustav za lociranje munja (Lightning location network - LINET) je razvijen u Njemačkoj, 

gdje je instalirano 30 senzora. 2006. sustav LINET je počeo s radom pokrivajući Njemačku i sve ostale 

susjedne zemlje. Izvještaji LINET sustava daju lokacije udara munja većih i manjih amplituda. Veće 

amplitude struja obično potječu od udara munja oblak–zemlja (OZ), dok su manje amplitude posljedica 

pražnjenja meĎu oblacima (oblak-oblak, OO). 

Krajem 2008. na području Hrvatske upogonjen je sustav za lociranje munja u sklopu LINET 

mreže. Na području Hrvatske instalirano je 6 senzora (Zagreb, Rijeka, Zadar, Split, Dubrovnik, Blato 

(otok Korčula)). Diljem Europe mreža senzora je proširivana, a naročito je povećana gustoća mreže 

na području Jugoistočne Europe. Početkom 2011. LINET mreža broji više od 125 senzora. 

Sustav koristi VLF/LF frekvencijski opseg i otkriva gustoću magnetskog toka pri atmosferskom 

pražnjenju pomoću dviju meĎusobno okomito postavljenih prstenastih antena. Preporučena udaljenost 

izmeĎu susjednih senzora iznosi 250 km ili manje. Slika 1 pokazuje raspored senzora u Hrvatskoj i 

susjednim državama. 

Slika 1 Mreža LINET senzora na području Hrvatske i okolice 

Svi senzori LINET sustava istoga su tipa što osigurava homogenost prikupljenih podataka te 

eliminira pojavu greške koja bi se pojavila uslijed korištenja različitih parametara, mjernih principa i 

metoda kada bi se koristili različiti tipovi senzora. 

LINET senzor jednostavne je izvedbe (PC računalo, GPS prijemnik, modul za obradu i 

digitalizaciju analognog signala, antena za mjerenje magnetske indukcije) te se može vrlo brzo i 

jednostavno instalirati na željenu lokaciju. Kako su senzori identični, olakšano je i održavanje. 

Kalibracija se može provoditi udaljeno iz LINET centra. Zbog velikog broja senzora te učinkovitog 

softverskog algoritma LINET sustav pruža točnost lociranja udara do 100 m i odličnu detekciju udara 

malih amplituda struja [4]. 

189 

2

Visoko sofisticiranu mrežu za lociranje munja LINET, s mnogo novih karakteristika, je danas 

moguće iskoristiti kako za istraživanja, tako i za pogonske primjene. Prvi projekt s ovim sustavom je 

izvršen u Brazilu (Bauru), zatim u Australiji (Darwin) i Africi (Benin). U Brazilu je sustav usporeĎivan sa 

lokalnim sustavom (Rindat) dokazujući neke prednosti koje su opažene pri testiranju u Njemačkoj [1]. 

Slika 2 Izgled LINET 

senzorske antene 

(ortogonalni prsteni) i GPS 

antene 

1.1. Princip detekcije udara munje 

ObraĎeni podaci 

Korisnici 

` ` 

Login 

Nowcast 

(LINET) server 

Internetska veza 

sa središnjim 

sustavom LINET 

NeobraĎeni 

podaci 

Antene za 

mjerenje polja 

DAQ kartica za 

prikupljanje podataka 

i prilagoĎavanje 

signala (pojačavanje, 

filtriranje i AD 

pretvorba signala, 

obrada podataka) 

Program za obradu podataka/ 

komunikaciju 

Računalo 

GPS antena 

GPS kartica za mjerenje 

vremena 

Senzorska 

stanica 

Slika 3 Shema toka podataka u sustavu za praćenje 

atmosferskih pražnjenja LINET 

Komponente magnetske indukcije detektiranog signala mjere se pomoću ortogonalne petlje 

(antene) u stvarnom vremenu. Mjerena veličina je inducirana struja, a ne napon te se kao rezultat 

dobije vremenska ovisnost magnetske indukcije u rasponu 0,1 – 130 nT [2]. Frekvencijski raspon 

antene je 1 kHz – 1 MHz. U propisanim vremenskim intervalima, podaci dobiveni od vanjskih senzora 

se prenose u glavnu upravljačku stanicu gdje se vrši kombinirana analiza svih signala. 

Sustav LINET koristi TOA (eng. Time-Of-Arrival) metodu za odreĎivanje lokacije atmosferskog 

pražnjenja potpomognutu metodom za odreĎivanje pravca (DF, eng. Direction Finding). Primarno se 

koristi TOA metoda za odreĎivanje lokacije, pri čemu su potrebne detekcije od najmanje četiri 

senzora. Kombiniranjem TOA i DF metode moguće je detektirati pražnjenja pomoću dva ili tri senzora, 

no u tom slučaju greška odreĎivanja lokacije je povećana [1]. Senzori sustava LINET detektiraju 

atmosferska pražnjenja s amplitudama manjim od 5 kA, pri čemu senzori ne bi smjeli biti meĎusobno 

udaljeni više od 250 km. [3]. 

Slika 4 TOA (Time-Of-Arrival) metoda za odreĎivanje lokacije atmosferskih pražnjenja 

U proteklih 20-ak godina postavljeni su sustavi za lociranje u mnogim zemljama. Za 

nadgledanje velikih površina prednost imaju vrlo niska (VNF) i nisko-frekvencijska (NF) tehnologija. 

Ovu tehnologiju koristi i sustav LINET. Ta tehnologija tradicionalno je korištena za detekciju pražnjenja 

OZ s amplitudama struja iznad 5 kA, dok su se OO pražnjenja detektirala posebnim metodama. 

MeĎutim, sustav LINET koristi istu VNF/NF metodu za detekciju OZ i OO pražnjenja [4]. 

190 

3

Posebno treba biti uzeto u obzir razlikovanje ova dva načina atmosferskih pražnjenja. 

Tradicionalno se za tu svrhu koristi impulsni valni oblik (valni oblik razlikovanja), iako je poznato da su 

takvim postupkom u nekim slučajevima zabilježene netočnosti. 

Slika 5 VNF/NF frekvencijski opseg za detekciju atmosferskih pražnjenja 

Iz toga je razloga za sustav LINET nedavno razraĎen trodimenzionalni (3D) geometrijski 

algoritam za VNF/NF metodu [5]. Taj se postupak oslanja na poznatu činjenicu da OZ udari emitiraju 

VNF/NF pražnjenje dominantno u ionizirajućem kanalu blizu razine zemlje, dok OO pražnjenja nastaju 

u ionizirajućem kanalu meĎu oblacima i visoko iznad razine zemlje. Odgovarajuće razlike u vremenu 

širenja elektromagnetskih valova (slika 2) uzrokovanih od visoko i nisko stacioniranih centara 

pražnjenja iskorištene su za lociranje mjesta pražnjenja. Ta metoda radi zadovoljavajuće, sve dok 

udaljenost izmeĎu mjesta udara munje i najbližeg senzora ne prelazi 100 km (odgovara udaljenosti 

meĎu senzorima oko 200 km); inače razlike u rezultatima ove metode postaju premale da bi bile 

primjetne. 

Slika 6 Princip detekcije OO pražnjenja: OO i OZ signali s iste 2D lokacije dolaze s vremenskom 

razlikom dT=TP−TH (P = centar VNF emisije; S = lokacija senzora; H = visina izvora emisije) [1] 

Posebni su napori učinjeni da bi se postigla visoka točnost lokacije mjesta udara u promatranom 

području. Danas je postignuta srednja točnost lokacije koja iznosi otprilike 100 m. 

1.2. Podaci LINET sustava 

Podaci koje prikupe LINET senzori šalju se u neobraĎenom obliku putem Internetskih veza u 

Nowcast (LINET) centar. U centru se vrši povezivanje i obrada podataka nakon čega su podaci u 

formatiranom obliku spremni za isporuku klijentima. Podaci preuzeti od LINET sustava arhiviraju se u 

bazu podataka. U sustavu su arhivirani podaci od 1. siječnja 2009.. 

191 

4

Podaci o atmosferskim pražnjenjima (tablica 1) koji se raspoloživi klijentima su: 

1. datum i vrijeme pražnjenja (UTC, 100 ns rezolucija), 

2. zemljopisna širina i dužina (GPS koordinate), 

3. amplituda struje pražnjenja (rezolucija 0.1 kA), 

4. tip pražnjenja (OO, OZ), 

5. visina za pražnjenja tipa OO, 

6. 2D statistička greška u odreĎivanju lokacije pražnjenja (m) [6]. 

Tablica 1 Podaci LINET sustava o atmosferskim pražnjenjima 

GPS VRIJEME TIP VISINA STRUJA GREŠKA 

15.8932 45.7170 29.4.2009 18:57:05.5952183 OZ - -15 kA 40 m 

15.8920 45.7036 29.4.2009 19:07:32.7712689 OZ - -5.2 kA 50 m 

15.8508 45.7407 29.4.2009 18:50:47.1437623 OZ - 72.2 kA 50 m 

15.8214 45.7566 29.4.2009 18:50:47.1127271 OO 3600 (m) -5.5 kA 50 m 

15.8647 45.7595 29.4.2009 19:07:01.6730042 OO 4100 (m) 4.7 kA 60 m 

15.8117 45.7558 29.4.2009 18:49:09.4577769 OO 5900 (m) -10.7 kA 80 m 

3. PRIMJENA U VOĐENJU ELEKTROENERGETSKOG SUSTAVA 

Primjene sustava za lociranje munja poznate su danas u različitim djelatnostima ili 

organizacijama kao što su osiguravajuća društva, sustavi za zaštitu od šumskih požara, sredstva 

civilne obrane, vojne instalacije, komercijalni avioprijevoznici, telekomunikacijske mreže, trgovci i 

distributeri eksploziva, petrokemijska industrija, mreže radijskih i televizijskih odašiljača. 

Elektroprivredne tvrtke uključile su se meĎu korisnike sustava za lociranje munja relativno kasno i to 

tek nakon što su sustavi dovoljno usavršeni. U početku su sustavi za lociranje munja imali brojne 

slabosti: nemogućnost razlučivanja udara munja u tlo od svih ostalih udara (izmeĎu oblaka); netočnost 

u detekciji svih udara; nemogućnost detekcije uzastopnih udara, i dr. Sve je to onemogućavalo 

upotrebu u svrhe projektiranja i voĎenja nadzemnih električnih mreža, no u posljednje su vrijeme 

navedene slabosti većim dijelom otklonjene. Danas, suvremeni sustavi za lociranje munja nalaze sve 

veću primjenu u elektroprivredi i to meĎu distributerima, ali i u sustavima voĎenja prijenosnih mreža. 

Primjene u elektroenergetskim mrežama i sustavima danas se susreću uglavnom na jednom ili više 

područja [7]: 

1. u korelaciji ispada i kvarova u mreži s pojavama munja, 

2. u uspostavljanju, voĎenju i nadzoru elektroenergetskog sustava, 

3. u davanju posadama upozorenja o nailasku munja, 

4. u izboru trasa nadzemnih vodova i načina njihove zaštite od munja. 

3.1. Korelacija ispada i kvarova u mreţi s pojavama munja 

Podaci sustava za lociranje munja mogu se korelirati s podacima o ispadima i kvarovima u mreži, 

što može doprinijeti kvaliteti praćenja pogona. Danas razvijene elektroprivrede obavezno prate 

podatke o kvarovima vezane za rad prekidača ili ponovnog uklopa primjenom različite opreme za 

registraciju. Takva oprema omogućuje on-line nadzor prekidača i praćenje tzv. alarmnog statusa 

transformatorskih stanica. Usporedba s podacima sustava za lociranje munja pokazuje da svi kvarovi i 

ispadi za vrijeme grmljavina nisu uzrokovani udarom munje. Najpovoljniji način odreĎivanja realnog 

broja prorada prekidača i ponovnih uklopa izazvanih udarima munja je dovoĎenje u korelaciju 

podataka u vremenu i prostoru sa sustavima za lociranje munja. 

3.2. Uspostavljanje, voĎenje i nadzor elektroenergetskog sustava 

Česta je primjena kod uspostavljanja i voĎenja elektroenergetskog sustava u vrijeme kada se 

dispečerski centri suočavaju s problemom identifikacije uzroka prorade prekidača. Važna informacija 

za donošenje dispečerske odluke je podatak da li je udar nastupio u trenutku isklopa i u neposrednoj 

blizini voda. S praćenjem munja u stvarnom vremenu moguće je iskusnom operateru utvrditi da li je 

isklop posljedica trajnog kvara ili prijelazne pojave uzrokovane udarom munje. Takav alat može biti 

vrlo korisna pomoć prilikom uspostavljanja novih pogona i mreže te minimiziranju potrebnog vremena i 

troškova. 

192 

5

3.3. Upozoravanje posada o nailasku munja 

Dispečerski i pogonski inženjeri mogu primjenom podataka sustava za lociranje munja brzo 

angažirati osoblje za održavanje u područjima kojima se približavaju jake grmljavinske fronte. Jednako 

je važna sposobnost sustava da pruži pouzdanu informaciju da je grmljavinska fronta potpuno 

napustila dano područje ili pogonsku zonu. Važan aspekt sigurnosti za pogonske posade za 

održavanje je u tome da se popravci na dugim vodovima izvode bez rizika ozljeda od udara munja. 

Veoma je poželjno točno poznavati pravac približavanja grmljavina kod voĎenja radova na vodovima 

ili kod većih ispitivanja u mreži. 

3.4. Izbor trasa nadzemnih vodova i načina njihove zaštite od udara munja 

Sustavi za lociranje munja daju mnogo kvalitetnije podatke u odnosu na dosadašnje prikaze 

gustoće udara u tlo. Nekadašnje izokerauničke karte pretvarane su različitim empirijskim faktorima u 

podatke o gustoći udara u tlo. Točnost takvog postupka je veoma ograničena i ovisna o svojstvima 

područja koje se promatra. Mnogo bolji podaci dobiveni su mrežama brojača munja kratkog dometa 

(npr. tip brojača CIGRE 10 kHz), ali se ni oni ne mogu usporediti po kvaliteti i mnoštvu parametara s 

onima što daju novi sustavi. U modernom projektiranju prijenosnih i distribucijskih vodova novi sustavi 

za lociranje munja postaju sve više nezaobilazno sredstvo. Poznavanje karata gustoće udara munja u 

tlo omogućava odreĎivanje prioriteta ugradnje odvodnika prenapona i drugih sredstava zaštite od 

prenapona. Pretpostavlja se da su vodovi u zonama najveće gustoće udara u tlo najviše izloženi 

pojavi povratnog preskoka. Sukladno tome imovina prijenosnih i drugih poduzeća najbolje se štiti 

koncentracijom odvodnika prenapona na spomenutim lokacijama. 

Izbor trase prijenosnih vodova je veoma kompleksan postupak ovisan o nizu faktora. Jedan od 

njih je rizik ispada budućeg voda uslijed grmljavinskih aktivnosti. Rizik se može računati za najmanje 

dvije ili više alternativnih trasa voda, a osnovni ulazni podaci o tome su gustoća udara munja u tlo, broj 

udara na godinu i mjesec ili dan, podaci o strujama pražnjenja, itd. Radi svega toga suvremeni sustavi 

za lociranje munja postaju sve više nezamjenjiv alat u projektiranju nadzemnih vodova. 

4. PROGRAMSKA PODRŠKA 

U planu je implementacija sustava za lociranje munja unutar sustava voĎenja elektroenergetskog 

sustava Operatora prijenosnog sustava Hrvatske elektroprivrede. Sustav omogućuje praćenje 

grmljavinske aktivnosti na području elektroenergetskog sustava Hrvatske te koreliranje s dogaĎajima 

(ispadima, kvarovima, APU-ima) na vodovima i postrojenjima u stvarnom vremenu. Korelacija u 

stvarnom vremenu ostvaruje se integracijom podataka o munjama, alarma i dogaĎaja SCADA sustava 

te geoprostornih podataka objekata elektroenergetskog sustava [7]. 

Slika 7 Prijenosna mreža hrvatskog 

elektroenergetskog sustava 

193 

Slika 8 Shema prostorno-vremenske korelacije 

izmeĎu podataka o udarima munja, 

geoprostornim podacima objekata i dogaĎaja u 

elektroenergetskoj mreži 

6

4.1. Arhitektura sustava 

Programska podrška sustava za lociranje munja oblikovana je po principima uslužno orijentirane 

arhitekture (eng. Service Oriented Architecture – SOA). Sustav je realiziran kroz četveroslojnu 

arhitekturu (slika 9): 

1. sloj klijenata – web preglednici i SOAP klijenti koji razmjenjuju podatke sa sustavom za 

lociranje munja; 

2. prezentacijski sloj – web poslužitelj i SOAP komunikacijsko sučelje realizirano kroz Windows 

Communication Foundation (WCF) servis; 

3. aplikacijski sloj – WCF servisi i GIS poslužitelj; 

4. sloj baze podataka – operacijska baza podataka i skladište podataka. 

Slika 9 Arhitektura programske podrške sustava za lociranje munja 

Sustav je dizajniran modularno, tako da se pojedine pod-komponente (web poslužitelj, WCF 

servisi, GIS poslužitelj, baza podataka) mogu neovisno distribuirati unutar jednog ili više poslužitelja i 

udaljenih lokacija, pri čemu se meĎusobna komunikacija obavlja putem TCP/IP protokola. Na taj način 

sustav postaje dovoljno fleksibilan da udovolji zahtjevima različitih klijenata kao i eventualnim 

promjenama i/ili nadogradnjama jednom nakon što je sustav implementiran. Osim navedenog, 

modularnost omogućava brz razvoj i adaptaciju sustava za primjenu u drugim granama ekonomije, 

povezivanje na druge izvore podataka te dodavanje dodatne i/ili izmjenu postojeće logike potrebne za 

specifične primjene u raznim sektorima ekonomije (energetika, graditeljstvo, osiguravajuća društva, 

zaštita od požara i sl.). 

Sustav razvijan za potrebe korištenja u elektroenergetskoj mreži je povezan na tri vanjska izvora 

podataka s kojima komunicira u stvarnom vremenu razmjenjujući poruke putem SOAP/HTTP 

protokola: 

1. LINET centralni poslužitelj podataka o udarima munja (poslužuje nove podatke o udarima 

munja u intervalima od 10 sekundi); 

2. SCADA poslužitelj podataka o dogaĎajima u elektroenergetskoj mreži (prorada zaštitne 

opreme, zastoji, kvarovi i sl.); 

3. GIS poslužitelj podataka o elektroenergetskim objektima (slika elektroenergetske mreže – 

geometrije vodova, postrojenja i sl.). 

194 

7

4.2. Interaktivne mape i vizualizacija podataka 

Za vizualizaciju podataka koristi se AutoDesk web GIS rješenje MapGuide Enterprise. MapGuide 

posjeduje FDO tehnologiju za pristup podacima pomoću kojeg se povezuje na Oracle 11gR2 bazu 

podataka i barata prostornim podacima. Web sučelje bazirano je na Fusion tehnologiji. Fusion ne 

zahtijeva dodatke svojstvene nekom web pregledniku te stvara aplikacije koje rade na svim poznatijim 

preglednicima na Windows, Mac ili Linux platformama te pruža fleksibilan način interakcije s 

MapGuide poslužiteljem. 

4.3. Klijenti sustava 

Slika 10 Hijerarhija i veze MapGuide resursa 

Za povezivanje na sustav korisniku je potreban web preglednik. Sustav posjeduje web korisničko 

sučelje realizirano pomoću HTML/Javascript tehnologije koje podržavaju svi moderni web preglednici. 

Na taj način ostvarena je široka dostupnost uz minimalne zahtjeva na strani klijenta. Osim web 

korisničkog sučelja, sustav posjeduje SOAP komunikacijska sučelja namijenjena za komunikaciju s 

drugim (vanjskim) sustavima u svrhu automatskog obavještavanja i uzbunjivanja, prosljeĎivanja 

podataka o munjama sustavima za izradu izvještaja i trajnu pohranu u skladišta podataka. 

Slika 11 Korisničko web sučelje za prikaz aktivnosti u stvarnom vremenu (lijevo) i pretragu u povijesti 

(desno) 

4.4. Arhiviranje izmjerenih podataka 

Arhiviraju se podaci o munjama, podaci o dogaĎajima u elektroenergetskoj mreži koji su povezani s 

udarima munja te statistike nad podacima o munjama i korelacijama. TakoĎer, arhiviraju se dnevne 

195 

8

karte grmljavinske aktivnosti kreirane pomoću GIS poslužitelja za potrebe kreiranja izvještaja i bržeg 

pregleda grmljavinske aktivnosti u prošlosti. 

4.5. Baza podataka 

Sustav je realiziran oko Oracle 11gR2 Enterprise instance baze podataka. Iako je relacijska 

shema baze podataka potrebne za ispunjavanje funkcijskih zahtjeva relativno jednostavna, zbog 

prirode ulaza podataka, izvršavanja operacija i skladištenja analiziranih podataka, baza se može 

podijeliti u dva segmenta: operacijsku bazu podataka i skladište podataka. 

Prvi segment čini operacijska baza podataka u koju se upisuju podaci iz vanjskih izvora. GIS 

podaci objekata elektroenergetskog sustava su u pravilu statični te se rijetko mijenjaju (topologija se 

povlači i ažurira iz vanjskog GIS poslužitelja). Podaci o udarima munja se unose u periodima od 10 

sekundi, no jednom upisani, ti podaci se ne mijenjaju. Podaci o dogaĎajima u elektroenergetskoj mreži 

po prirodi su slični podacima o udarima munja te se ne mijenjaju nakon što se jednom upišu. Zbog 

gore navedenog, neposredno nakon upisa novih podataka, operacijska baza izvršava sve potrebne 

proračune, analize i korelacije te su podaci spremni za pohranu u skladište podataka. 

Drugi segment je organiziran po principima skladišta podataka. Iako nije punokrvno skladište 

podataka i jednostavnog je dizajna, najbolje ispunjava funkcijske zahtjeve za pohranom, analizom i 

pristupom podacima. Konačno skladištenje podataka implementirano je u vanjskom skladištu 

podataka, zajedničkome za sve podsustave unutar sustava voĎenja elektroenergetske mreže. No, 

kako vanjsko skladište ne garantira dostupnost i raspoloživost, sustav se za ispunjavanje 

funkcionalnosti ne oslanja na njega već zadržava minimalan skup podataka potrebnih za rad. 

5. ORACLE SPATIAL I PROSTORNE ANALIZE 

Iako sustav raspolaže GIS alatom (AutoDesk MapGuide Enterprise) koje sadržava sve potrebne 

alate i metode za provoĎenje potrebnih prostornih analiza nad podacima, zbog prirode unosa 

podataka i zahtjeva za što manjim kašnjenjem izmeĎu stvarnog dogaĎaja udara munje i predstavljanja 

informacije korisnicima, cjelokupna prostorna obrada izvršava se korištenjem metoda i alata Oracle 

Spatial opcije unutar instance baze podataka. AutoDesk MapGuide Enterprise webGIS rješenje koristi 

se za izradu interaktivnih karata te vizualizaciju podataka na webu. 

Prostorno se analiziraju podaci o udarima munja koji su predstavljeni 2D geometrijom točke 

(Lat/Lon koordinate, WGS84 koordinatni sustav) s GIS podacima objekata elektroenergetskog sustava 

koji su predstavljeni 2D geometrijama (točke, linije i poligoni). Elektroenergetski prijenosni sustav 

sadrži 123 trafostanice i 7416 km dalekovoda za koje se definiraju alarmne zone unutar kojih se 

promatraju udari munja u stvarnom vremenu te koreliraju s dogaĎajima u elektroenergetskoj mreži. 

Sustav za lociranje munja odreĎuje lokaciju udara munje metodom vremena pristizanja 

elektromagnetskog vala i triangulacijom iz nekoliko senzorskih lokacija. Senzorske stanice su 

meĎusobno vremenski sinkronizirane pomoću GPS sustava rezolucije 100 ns. Iz toga slijedi 

minimalna statistička greška odreĎivanja lokacije od 30 m (u idealnom slučaju). Za vrijeme većih 

grmljavinskih nevremena nad našim područjima sustav bilježi i do 1500 udara munja u minuti, a 

dosada zabilježeni dan s najviše grmljavine brojao je više od 500.000 udara. Ukupno kašnjenje od 

stvarnog dogaĎaja do prikaza na web sučelju je unutar 60 sekundi. 

5.1. Grid geografskog područja 

Geografsko područje za koje se promatra grmljavinska aktivnost podijeljeno je pravokutnim 

gridom rezolucije 0.1 stupanj zemljopisne dužine i širine. Svim elektroenergetskim objektima i udarima 

munja pridjeljuje se jedan ili više gridova u kojima se objekti nalaze (dimenzija skladišta podataka). Za 

potrebe detaljnijih analiza i korelacija, pojedina područja posjeduju dodatno definirane gridove veće 

rezolucije (0,01, 0,005 i 0,001 stupanj zemljopisne dužine i širine). 

196 

9

Slika 12 Detaljni grid (0,001 stupanj zemljopisne dužine i širine) oko dalekovoda 

5.2. Alarmne zone elektroenergetskih objekata 

Zbog ugraĎene statističke i sistemske greške u odreĎivanju lokacije udara munja, oko 

promatranih objekata na zemlji definira se alarmna zona proizvoljnog polumjera (npr. 500 m) za koju 

se promatraju udari munja. Za područja unutar alarmnih zona izvode se dodatne statističke i prostorne 

analize ovisno o potrebi i primjeni. Za potrebe voĎenja elektroenergetskog sustava analizira se 

amplitudna raspodjela struja munja te se odreĎuju dionice dalekovoda i postrojenja najizloženije 

udarima munja. 

Slika 13 Alarm zone elektroenergetskih objekata 

5.3. Prostorna korelacija udara munja s elektroenergetskim objektima 

U postupku korelacije udara munje s elektroenergetskim objektom provodi se nekoliko faza, 

odnosno, razina korelacije. Prvo se provodi prostorna korelacija munje s alarmnom zonom objekta, 

čime se skup kandidata za korelaciju najviše smanjuje. Nakon prostorne korelacije izvodi se 

vremenska korelacija izmeĎu prostorno koreliranih kandidata i dogaĎaja na objektu. Veličinu izlaznog 

skupa ovdje ponajviše odreĎuje širina vremenskog perioda sustava za registraciju dogaĎaja. MeĎutim, 

razvojem tehnologije i primjenom GPS sinkronizacije izmeĎu ureĎaja, podaci koje ti sustavi daju 

precizni su i do razine 1 ms. Ukoliko i nakon vremenske korelacije nema konačne odluke moguće je 

analizirati amplitudu struje munje u ovisnosti o električnim i mehaničkim karakteristikama 

elektroenergetskog objekta. 

U prostornoj korelaciji udara munje s objektom na zemlji, značajan je podatak o udaljenosti udara 

munje od promatranog objekta (sdo_geom.sdo_distance). Taj se podatak usporeĎuje s podatkom o 

greški lociranja udara munje te se odreĎuje vjerojatnost udara munje kao kandidata za uzrok dogaĎaja 

u elektroenergetskom sustavu. 

Za dalekovode dodatno je značajan podatak o udaljenosti udara munje od početka dalekovoda, 

tzv. stacionaži udara na dalekovodu. Kako dalekovodi mogu biti dugački i nekoliko stotina kilometara, 

točan podatak o kilometraži (ili broju stupa) može znatno smanjiti vrijeme potrebno za pronalazak i 

popravak kvara. Za tu svrhu, dalekovodu se definira LRS geometrija (sdo_lrs.convert_to_lrs_geom), a 

točka udara munje projicira se na liniju dalekovoda (sdo_lrs.project_pt). Uz pomoć projicirane točke na 

liniji, odreĎuje se stacionaža, odnosno udaljenost projekcije udara od početka dalekovoda 

(sdo_lrs.find_measure). 

197 

10

5.4. Karte gustoće udara i statistike 

Slika 14 Prostorna korelacija 

Važna funkcija sustava za lociranje munja je izrada karata gustoće udara munja te prostorna 

analiza podataka o munjama (amplitudna distribucija struja munja, distribucija greške lociranja i sl.). 

Slika 15 Distribucija amplitude struje i greške lociranja munja 

Prostorno se karte dijele na karte gustoće i karte prostornih analiza niske rezolucije (0,1 stupanj 

zemljopisne širine i visine), visoke rezolucije (0,01 stupanj) i karte alarmnih područja vrlo visoke 

rezolucije (0,001 stupanj). Obrada podataka vrši se jednom godišnje kada se obraĎuju i pohranjuju 

godišnji podaci te generiraju izvještaji. Uz navedeno, podaci se sumiraju za višegodišnje razdoblje. 

Obrada se može pokrenuti na zahtjev administratora sustava. 

Slika 16 Karta gustoće udara munja niske rezolucije za 2009. i 2010. [8] 

198 

11

6. ZAKLJUČAK 

Sustavi za lociranje udara munja neprestano se unapreĎuju i razvijaju te su danas snažno oruĎe 

u projektiranju, zaštiti i voĎenju elektroenergetskih mreža te brojnih drugih tehnoloških sustava 

izloženih atmosferskim uvjetima. Primjena sustava je i u drugim granama ekonomije kao što su zračni, 

željeznički i pomorski promet, meteorologija, osiguranja imovine, graĎevinarstvo, zaštita od požara i 

dr. 

U radu je dan kratak opis europskog sustava za lociranje munja LINET, koji je implementiran i 

pokriva teritorij Hrvatske. Prikazano je programsko rješenje koje omogućuje primjenu podataka 

sustava za lociranje munja u sustavu voĎenja hrvatskog elektroenergetskog sustava. Za izvršavanje 

korelacije s dogaĎajima na objektima na tlu, programska podrška prihvaća podatke iz drugih vanjskih 

izvora kao što su GIS sustav i sustav za nadzor elektroenergetske mreže (SCADA). Poslovna logika 

realizirana je kroz WCF usluge koje povezuju pojedine komponente sustava te vrše komunikaciju s 

vanjskim sustavima. Temelj programske podrške čini Oracle 11gR2 Enterprise instanca baze 

podataka. Valja istaknuti Oracle Spatial komponentu i ugraĎenu prostornu logiku pomoću koje se 

realizira prostorna obrada podataka u stvarnom vremenu, pri čemu je informacija o udaru munje 

dostupna širokom krugu korisnika unutar 60 sekundi. 

7. LITERATURA 

[1] Betz H. D., Schmidt K., Laroche P., Blanchet P., Oettinger W. P., Defer E., Dziewit Z., Konarski 

J.: “LINET – An international lightning detection network in Europe“, 2007. 

[2] Betz H. D., Kulzer R., Gerl A., Eisert B., Oettinger W.P., Jakubassa D.: „On the Correlation 

between VLF-Atmospherics and Meteorological data”, ICLP Firence, 1996. 

[3] Betz H. D., Schmidt K.,Fuchs B., Oettinger W.P., Hoeller H.: „Cloud Lightning: Detection and 

Utilization for Total Lightning Measured in the VLF/LF Regime“, Journal of Lightning Research, 

August 2007. 

[4] Betz H. D., Oettinger W.P., Schmidt P., Wirz M.: „Modern Lightning Detection and 

Implementation of a New Network in Germany, Europe”, European Geosciences Union 2005, 

Geophysical Research Abstracts, Vol. 7, 00685,2005. 

[5] Betz H. D., Schmidt K., Laroche P., Blanchet P., Oettinger W.P., Defer E.: „LINET – A new 

lightning detection network in Europe”, 13th International Conference on Atmospheric 

Electricity, August 13-18, 2007., Beijing, China. 

[6] Uglešić, Ivo; Milardić, Viktor; Franc, Bojan; Filipović-Grčić, Božidar; Milešević, Boško: 

„Uspostava sustava za lociranje udara munja u Hrvatskoj”, 9. savjetovanje HRO CIGRÉ, Cavtat, 

Hrvatska, 8.-12.11.2009. 

[7] Uglešić, Ivo; Milardić, Viktor; Mandić, Milivoj; Filipović-Grčić, Božidar: „Praćenje atmosferskih 

pražnjenja za potrebe voĎenja EES-a“, Studija, Zagreb, Hrvatska, rujan 2007. 

[8] Uglešić, Ivo; Milardić, Viktor; Franc, Bojan; Filipović-Grčić, Božidar; Horvat, Jasna: „Prva 

iskustva sa sustavom za lociranje munja u Hrvatskoj“, 9. simpozij o sustavu voĎenja EES-a, 

Zadar, Hrvatska, studeni 2010. 

199 

12

17. KONFERENCIJA 

HRVATSKE UDRUGE ORACLE KORISNIKA 

16.-20. LISTOPADA 2012. 

Hotel Istra Crveni otok Rovinj

R E F E R A T I - Media Zona - My Paper

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?