preuzimanje - ITS-u

IS – Protivgradna odbrana - Izveštaj i Analiza Munir Husain Sarkar 104/06 

VISOKA ŠKOLA STRUKOVNIH STUDIJA ZA INFORMACIONE TEHNOLOGIJE 

Završni rad 

Razvoj informacionog sistema protivgradne odbrane 

– Izveštaj i analiza 

Mentor: 

Dr. Aleksandar Kostić 

Beograd, Septembar 2008. 

1/51 

Student: 

Munir Husain Sarkar 

104/06


SADRŽAJ: 

SADRŽAJ: ........................................................................................................ 2 

SPISAK KLJUČNIH REČI: .................................................................................... 4 

1. UVOD ........................................................................................................... 5 

1.1. Istorija odbrane od grada ......................................................................... 6 

1.2. Jezgra kristalizacije .................................................................................. 7 

1.3. Protivgradna odbrana ............................................................................... 8 

2. INFORMACIONI SISTEM – Odbrane od grada .................................................... 9 

2.1. Opis sistema ........................................................................................... 9 

2.2 Model objekti-veze ................................................................................. 10 

2.3. Ograničenja, operacije i dinamička pravila integriteta ................................. 12 

2.4. Strukturna dinami;ka pravila integriteta i fizički mov .................................. 13 

2.5. Konceptualno modelovanje ..................................................................... 14 

2.6 Normalizacija relacija ............................................................................. 15 

2.7. Funkcionalne zavisnosti .......................................................................... 17 

2.8. Dekompozicija relacija bez gubljenja informacija ....................................... 18 

2.9. Druga i treća normalna forma ................................................................. 19 

2.10. EER podmodeli .................................................................................... 21 

2.11. Potpuni EER model: .............................................................................. 24 

3. OBRANA OD GRADA – APLIKACIJA ................................................................. 25 

3.1. Glavna aplikacija i njeni delovi................................................................. 26 

3.1.1 Radna površina: .................................................................................. 28 

3.1.2. Sinoptička situacija. ............................................................................ 28 

3.1.3. Evidencija strelaca .............................................................................. 29 

3.1.4. Podaci o strelcima. .............................................................................. 30 

3.1.5. Podaci o stanicama: ............................................................................ 31 

3.1.6. Upozorenja i najave. ........................................................................... 32 

3.1.7. Prognoza Vremena .............................................................................. 33 

3.1.8. Beleške (Notes) .................................................................................. 34 

3.1.9. Kalendar ............................................................................................ 35 

3.1.10. Dnevni i godišnji izveštaji. .................................................................. 36 

3.1.11. Korisnici, satnica i logout................................................................... 38 

3.1.12. Pomoćni toolbar sa najčešće korišćenim funkcijama sistema. .................. 39 

4. IZVEŠTAJ I ANALIZA .................................................................................... 40 

5. IZRADA APLIKACIJE – KORIŠĆENI PROGRAMI. ................................................ 41 

5.1. SQL Server 2005 ................................................................................... 41 

5.2. SQL Management Studio......................................................................... 43 

5.3. Microsoft Visual Studio 2008 ................................................................... 44 

5.4. Microsoft.NET Framework ....................................................................... 46 

5.5. C# ....................................................................................................... 47 

ZAKLJUČAK .................................................................................................... 49 

LITERATURA ................................................................................................... 51 

2/51


SADRŽAJ SLIKA: 

Slika 1: Kumulonimbus (Cb) ........................................................................................... 7 

Slika 2: EER podmodel 1 .............................................................................................. 21 

Slika 3:EER podmodel - Lansiranje ................................................................................ 22 

Slika 4:EER podmodel - Evidencija ................................................................................. 23 

Slika 5: Login forma. ................................................................................................... 25 

Slika 6:Glavna aplikacija i njeni delovi. ........................................................................... 26 

Slika 7:Mapa pokrivenosti. ............................................................................................ 28 

Slika 8:Evidencija strelaca. ........................................................................................... 29 

Slika 9:Podaci o strelcima ............................................................................................. 30 

Slika 10:Podaci o stanicama ......................................................................................... 31 

Slika 11:Upozorenja i najave ........................................................................................ 32 

Slika 12:Prognoza vremena .......................................................................................... 33 

Slika 13:Beleške .......................................................................................................... 34 

Slika 14:Kalendar dejstava. .......................................................................................... 35 

Slika 15:Korisnici, satnica i logout. ............................................................................... 38 

Slika 16:Pomoćni toolbar .............................................................................................. 39 

Slika 17:SQL Server konekcija. ..................................................................................... 41 

Slika 18:SQL Management Studio Express ...................................................................... 43 

Slika 19: Visual Studio 2008 ......................................................................................... 44 

SADRŽAJ TABELA: 

Tabela 1: Dinamička pravila integriteta za atribute ......................................................... 303 

Tabela 2: Primer tabele u prvoj normalnoj formi ............................................................. 305 

Tabela 3: Relacija raketa ............................................................................................. 309 

3/51


A 

B 

C 

E 

K 

M 

P 

R 

S 

V 

SPISAK KLJUČNIH REČI 

Aplikacija 26,27,31,43,45,46,47,48,49,50,51,52 

Bukulja 7,8 

Cb – kumulonimbus 5,6,7 

EER model 

Konceptualni model 15,16 

MOV – Model objekti-veze 11,12,13,14 

PGS, Protivgradna stanica 9,22,23,41 

Radarski Centar 5,9,29,33,34,41,50,51 

Relacioni model 11,16,47 

Radna površina 28,29 

SQL 42,43,44,47,48,50 

Strelac 9,23,24,28,30,31,32 

Stanica 5,6,9,22,23,28,29,32 

Strukturna ograničenja 13,14 

Vrednosna ograničenja 13,14 

4/51


1. UVOD 

Po zahtevu Hidrometeorološkog zavoda, potrebno je razviti novi infromacioni sistem 

odbrane od grada. Potrebno je postojeći informacioni sistem modernizovati i prilagoditi 

savremenim tehnologijama. Takodje je potrebno ispuniti zahteve zaposlenih u Radarskom 

centru i u potpunosti olakšati njihov rad, kako bi informacioni sistem u potpunosti 

zadovoljavao njihove potrebe. 

Postojeći sistem Odbrane od grada postoji od 1996. godine. Baza podataka je 

osmišljena i implementirana pomoću alata Microsoft Access. U toj godini razvoja ovog sistema 

Microsoft Access je bio najbolje rešenje i bio jedan od modernijih načina za realizovanje jednog 

ovakvog projekta. 

U ovom završnom radu biće objašnjen jedan od načina na koji se može razviti ovaj 

informacioni sistem. Takodje će biti prikazane prednosti i mane novog sistema u odnosu na 

postojeći. 

Sektor odbrane od grada Republičkog hidrometeorološkog zavoda odbranu od grada 

sprovodi od 1967. godine. Osnovni zadatak ovog sektora je operativno sprovoñenje odbrane 

od grada, permanentno radarsko osmatranje oblačnosti nad teritorijom Srbije i razvoj 

metodologije svih vidova veštačkog uticaja na vreme – rasturanja prehlañenih magli i 

povećanja količine padavina. 

Operativno odeljenje stara se o neosmetanom sprovoñenju odbrane od grada, 

ispravnosti tehničke opreme i mreže protivgradnih stanica na Radarskim centrima, 

snabdevenosti Radarskih centara protivgradnim raketama. 

U toku sezone odbrane od grada u Odseku za kontrolu leta pribavlja se odobrenje za 

dejstvo na gradonosne oblake od strane Oblasne kontrole leta i prikupljaju izveštaji sa 

Radarskih centara. 

U Odseku za analizu i kontrolu dejstva vrši se analiza, kontrola i arhiviranje svih 

podataka prikupljenih u sistemu odbrane od grada, sastavljanje i dostava izveštaja korisnicima 

o sprovedenim dejstvima na gradonosne oblake. 

Odsek za metodologiju dejstva bavi se kako daljim razvojem metodologije odbrane od 

grada, tako i razvojem drugih vidova veštačkog uticaja na vreme, kao što su povećanje 

količine padavina i rasturanje magle. 

Metodologije su zasnovane na svetskim naučnim saznanjima iz te oblasti. U ovom 

Odseku vrši se redovna kontrola aktivnosti reagensa koji se koristi u sistemu odbrane od 

grada. 

Zadatak Odseka za razvoj radarske mreže i produkata je unapreñenje metodologije 

radarskih merenja i osmatranja, radarskih kriterijuma za dejstvo, korošćenja produkata 

Doplerovih i dvojno-polarizacionih radara. 

5/51


1.1. ISTORIJA ODBRANE OD GRADA 

Godišnji prosek padavina u Beogradu je 670 mm, od čega 1/3 daju kumulonimbusi 

(Cb) u periodu jun-avgust. Koliko su za opstanak živog sveta važne pojave koje prate Cb, još 

uvek nije sasvim istraženo. Zna se da broj dana sa grmljavinama raste od polarnica ka 

polutaru. 

Grmljavina nema bez munja, munja bez grada, a grada bez jezgara kristalizacije. 

Kako zastrašujuće sevanje munja ide uz ubitačan grad, ilustruje nevreme koje je 25. jula 

1987. najpre gradom zasulo Austriju, zatim Sloveniju, Hrvatsku, Mañarsku i, po dijagonali, 

Vojvodinu gde je tučeno 250 000 ha, od ušća Drave do Bele Crkve. Tu nije bio kraj - i 

Rumuniju je zasuo grad. Usred vedrog dana, sa brda kod Užica video se blesak svetlosti munja 

iz Cb-a, nebeske grdosije, koji je to učinio. U toku života mnogo manjeg Cb-a, protok vode je 

3,5 miliona tona. Vodu usisavaju i drže uzlazne struje brzine do 35 m/s. 

Cb je moguće prognozirati i pratiti radarom: njegovo kretanje, faze razvoja, promene 

strukture, elektične aktivnosti u njemu... 

O nastanku Cb-a i grada zna se više nego o nastanku munja, u čijim je kanalima 

temperatura 28.0000 C i gde se odvijaju procesi za koje nigde više nema uslova na Zemlji. 

Osnivača Opservatorije astronoma Milana Nedeljkovića tajna Cb-a privlačila je koliko i 

zvezde. Preporuku da meteorolozi u svetu naročitu pažnju 1895. poklone proučavanju Cb 

oblaka iskoristio je da dobije državni novac za posao koji je već o svom trošku otpočeo. 

Napisao je uputstva za Posmatranje nepogodskih pojava i Posmatranje grada (1901). 

Do tada je lično obučavao osmatrače kako se to radi i upisuje u nepogodske kartice, koje je 

uveo da bi prikupio podatke i o pojavama van meteo-stanica. Osmatranja je tako dobro 

organizovao da je na osnovu prikupljenih podataka postao stručnjak za tu pojavu. 

6/51


1.2. JEZGRA KRISTALIZACIJE 

U raznim mestima Srbije 1900. počela je borba protiv ove stihije. U julu 1902. pozvan 

je u Grac da stručnjacima za tu oblast iznese svoje mišljenje. Njegovo izlaganje je prihvaćeno i 

u celosti objavljeno u Beču. 

Nedeljković je smatrao da je pitanje odbrane preuranjeno. Nije bio proučen 

mehanizam formiranja zrna grada koji ima forme tako proste i tako komplikovane; koji pada u 

sitnim i vrlo krupnim zrnima; pada u malim količinama i ogromnim, a isto tako, pitanje visine 

na kojoj se formira nije utvrñeno, a nije se znalo ni šta u atmosferi čine viorni prstenovi koje 

su izbacivali gradni topovi. 

Slika 1: Kumulonimbus (Cb) 

Verovao je da od odbrane na maloj površini nema koristi. Zanemario je mehaničke i 

zvučne efekte, usmeravajući pažnju na čestice nastale eksplozijom nošene viornim prstenom 

ka oblaku. 

Razorna moć Cb-a usmerila mu je misli ka mogućnosti uticanja na mikroprocese u 

oblaku, kojima bi se sprečilo stvaranje grada i narušila dinamička stabilnost. Intuicija ga nije 

obmanula. U vijornom prstenu nalazila su se jezgra kristalizacije kojima se može sprečiti grad 

kada dospeju u oblak na pravo mesto, u pravo vreme i u dovoljnoj količini. 

U hladnom delu oblaka, kapi vode ostaju tečne kao prehlañene do -400C, kada se 

smrzavaju i postaju embrioni grada. U avgustu tako niska temperatura je na visini 7-8 km. 

Pri višim temperaturama, kristali leda nastaju na jezgrima kristalizacije kojih ima malo 

u atmosferi. To su mikročestice raznih supstanci, aktivne u različitim opsezima temperatura. 

Porekla su zemaljskog i kosmičkog. Mogu nastati sagorevanjem meteora. 

U oblaku, samo se neke uvećaju, dostižući dimenzije 0,3-0,5 mm i postajući zameci 

grada. Zameci zahvaćeni turbulencijom rastu na račun vode dok ne otežaju toliko da ih uzlazne 

struje ne mogu držati. Posle izlučivanja padavina, Cb može da se raspadne ili obnovi. Nisu svi 

Cb isti. Neki istovremeno obnavljaju vlagu i daju padavine, dok se kod drugih ti procesi 

smenjuju. 

7/51


Kada, gde i kakav Cb će nastati, koliko će trajati i gde će kakve padavine izlučiti, 

zavisi od dinamike atmosfere, orografije, vlage itd. U junu 1970. krupan grad je padao od 

Drine do bugarske granice. Kod Valjeva je izmereno zrno od 900 gr. Da bi poraslo do te 

veličine, uzlazne struje su morale biti preko 40 m/s. 

Rast grada do veličine koja oštećuje kulture može se sprečiti ubacivanjem u oblak 

veštačkih jezgara kristalizacije (VJK) konkurentnih prirodnim pri raspodeli vode. Kao mogući, 

ispitivani su kristali slični kristalima leda i pokazao se superioran srebrojodid (AgJ) dimenzija 

0,05-0,5µm. 

1.3. PROTIVGRADNA ODBRANA 

Na osnovu literature, u saradnji sa pet opština Šumadije, Aleksandar Opra je 1967. 

organizovao odbranu od grada. On je rasporedio 253 lansirna mesta, stvarajući sedam linija 

odbrane izmeñu Bukulje i Kosmaja, pet od Bukulje do Rudnika, a na ostaloj teritoriji su 

rasporeñena na rastojanju 4-8 km. 

Strelci su prošli obuku, dobili napisana uputstva za dejstvo zasnovana na fazama 

razvoja Cb-a. Na osnovu prognoze i grmljavina registrovanih na Bukulji i u Smederevskoj 

Palanci, signalnim raketama obaveštavani su o nailasku Cb-a. 

U Izveštaj protivgradne stanice beležili su pojave pre, za vreme i posle dejstva. Seljaci 

su 10. juna primetili da je uspostavljen red u odbrani. 

Na Bukulji su pri sasvim vedrom nebu lansirane signalne rakete na osnovu 

registrovane udaljene grmljavine koja se nije mogla čuti. Poštujući uputstva strelci su čekali 

nevreme. Delovanje linija odbrane bilo je usklañeno sa nailaskom kumulonimbusa. 

Tokom cele sezone dejstvovano je 37 dana i branjeno 155 187 ha poljoprivredne 

površine. Usevi su oštećeni gradom na 2642 ha. 

U SSSR-u je 1967. odbrana prešla u operativnu fazu, a 1968. u Srbiji je, na zahtev 

seljaka, proširena na više opština. Organizovani su centri sa kupljenim vojnim radarima da bi 

meteorolozi mogli da prate faze razvoja Cb. 

Uspostavljena je saradnja sa Laboratorijom čvrstog stanja u Vinči, koja je razvila 

vlastitu pirotehničku smešu ranga najboljih u svetu. U istoj laboratoriji je proizvedena i hladna 

komora za kontrolu smeše svake serije raketa. 

Akademik Fedor Mesinger je Svetsku meteorološku organizaciju obavestio da je 

protivgradnom zaštitom u Srbiji čestina grada smanjena 15-20%, a verovatnoća da 

zasejavanje nema efekta je 2%. U maju 2007. u radarskom centru na Bukulji je 40. sezona 

obeležena sastankom sadašnjih vodećih ljudi odbrane sa predsednicima pet opština, prvim 

radnicima odbrane, Aleksandrom Oprom i profesorom dr ðurom Radinovićem koji je 1968. bio 

direktor RHMZ i dugogodišnji aktivni učesnik razvoja odbrane. 

8/51


2. Informacioni sistem – Odbrane od grada 

2.1. OPIS SISTEMA 

Radarski centar (RC) konstantno nadgleda oblake na odreñenom području. Na osnovu 

toga, moguće je blagovremeno prepoznati potencijalno gradonosne oblake i pratiti eventualno 

formiranje grada unutar njih. Već iz ovih skeniranja mogu se po potrebi odrediti i parametri za 

dejstvo. 

Na svakoj protivgradnoj stanici (PGS) angažovana su dva strelca – glavni i pomoćni. 

Oni su u radio-vezi sa RC-ima, i prozivaju se dva puta dnevno. Pri ovim prozivkama oni ne 

moraju nužno biti na stanici, bitno je da li su dostupni za slučaj potrebe za dejstvom. Kada se 

pojave gradonosni oblaci šalje se obaveštenje strelcima na nivou opština da zauzmu svoje 

stanice. 

Stanice se izgrañuju tako da strelac do njih može doći u roku od dvadeset minuta. 

Kada stignu na njih, strelci se moraju ponovo javiti, da se zna da su spremni za dejstvo. Nije 

neophodno da oba strelca budu prisutni – pomoćni je tu za slučaj da glavni iz nekog razloga 

nije u mogućnosti da deluje tog dana. Na svakoj PGS se nalaze lanser i odreñeni broj raketa. 

Na osnovu kretanja oblaka, RC je u mogućnosti da prognozira verovatno kretanje 

oblaka u bliskoj budućnosti, na osnovu čega se u slučaju delovanja strelcima javljaju parametri 

za podešavanje lansera. Ti parametri su azimut, elevacija (za sada formalni parametar, 

odreñuje se na dnevnom nivou za čitavu državu) i tempiranje (takoñe formalni parametar – 

rakete koje se koriste nemaju podešavanje tempiranja). 

Svaka PGS može imati jednu ili više zona zabrane, tj prostor ograničen azimutima u 

kome ne sme delovati, zbog naselja i sl. Takoñe, dejstvo se vrši u skladu sa kontrolom leta – 

ukoliko je avion u blizini, stanica ne sme delovati u njegovoj oblasti kretanja. 

Premda su oblaci relativno veliki po površini, ciljevi unutar njih (odnosno gradonosne 

ćelije) – nisu. Na osnovu refleksivnosti, radar pronalazi ove ćelije i beleže se njihove 

koordinate kao i stadijum razvijenosti grada. Grad se formira oko sitnih čestica u oblaku, koje 

vremenom, pošto se led akumulira oko njih, rastu sve dok silom gravitacije ne počnu da 

padaju. Protivgradne rakete deluju tako što raspršavaju veliku količinu sitnih čestica u 

gradonosne ćelije, zahvaljujući čemu se formira veći broj manjih zrna grada, koja se pri padu 

tope i padaju na tlo kao kiša. 

Jedan od ključnih problema u organizaciji dejstva je identifikacija PGS koje mogu 

izvršiti dejstvo nad odreñenim ciljem (odnosno gradonosnim oblakom). Pored očiglednog 

zahteva da strelac bude prisutan, značajno je i da li je cilj u dometu PGS, karakteristike rakete 

i lansera, vetrovi i mnogi drugi faktori. 

Na kraju dejstva beleži se evidencija utrošenih raketa (radi slanja novih, što se vrši 

sutradan), kao i statusa lansera (za slučaj da je neophodna opravka). 

Rakete mogu biti različitih tipova i od različitih proizvoñača. Značajna je godina 

proizvodnje i rok trajanja, tj. raketa nije permanentno upotrebljiva. Takoñe su značajne 

varijable maksimalna visina rakete, brzina rakete i količina reagensa. 

9/51


2.2 MODEL OBJEKTI-VEZE 

Model objekti-veze (MOV) je najpopularniji i u praksi najviše korišćeni model za 

projektovanje baza podataka, prvenstveno relacionih. Postoji više različitih verzija ovog 

modela, sa gotovo istim konceptima i različitim grafičkim oznakama. Za potrebe ovog rada 

koristićemo originalnu notaciju P.Chen-a. 

Ključni aspekt MOV je njegova struktura, koja se predstavlja pomoću dijagrama 

objekti-veze (DOV). Simbole na ovim dijagramima uvodićemo postepeno sa uvoñenjem 

pojedinih koncepata modela. Pre svega, u MOV se sistem opisuje kao skup objekata i njihovih 

veza. 

Objekat u modelu može da predstavlja bilo neki fizički objekat ili koncept realnog 

sistema (konkretan proizvod, konkretnog radnika, vremenski trenutak ili period, smer studija i 

slično). Imajući u vidu da čak i jednostavni sistemi sadrže mnoštvo objekata i njihovih veza, 

neophodno je, u njihovom predstavljanju preko modela podataka, koristiti apstrakcije 

podataka. 

Koristeći apstrakciju tipizacije (klasifikacije), pojedinačni objekti u sistemu se 

predstavljaju tipovima, odnosno klasama objekata. U MOV slični objekti, odnosno objekti koji 

imaju isti skup stanja (tj. isti skup atributa i veza) mogu se predstaviti jedinstvenim tipom 

objekta. 

Tip objekta predstavlja opštu specifikaciju skupa sličnih objekata, a klasa predstavlja 

specifikaciju jedne implementacije tipa. Jednom tipu objekta može da odgovara više klasa, 

odnosno jedna specifikaicja skupa sličnih objekata može se implementirati na različite načine. 

Konkretan objekat koji je predstavljen nekim tipom, odnosno koji je implementiran 

nekom klasom, naziva se pojavljivanje tipa ili pojavljivanje klase objekta. 

U MOV, kao i u Relacionom modelu, podrazumeva se da se tip implementira preko 

skupa njegovih pojavljivanja. Zbog toga se može reći da je klasa objekata, u ovim modelima 

skup pojavljivanja objekta datog tipa. 

Na DOV klase objekata se prikazuju pravougaonicima. Svaka klasa u svojoj definiciji 

sadrži i tip objekta. 

Veze u modelu opisuju način povezivanja (uzajamna dejstva) objekata. 

Apstrakcija klasifikacije može se primeniti i na veze i definisati pojmovi tipa, klase i 

pojavljivanja veze. Tako, na primer, par može biti jedno pojavljivanje tipa 

odnosno klase veza Zapošljavanje. Klase veze se na DOV predstavljaju rombovima. 

U MOV se direktno predstavljaju samo binarne veze, odnosno veze izmeñu dva 

objekta. Višestruke veze se predstavljaju posredno. 

Svaki tip binarne veze definiše dva tipa preslikavanja (jednog objekta ka drugom, i 

obrnuto). 

10/51


Preslikavanja definišu uloge objekata u vezi. U tipu veze Zapošljavanje, tip Radnik 

ima „ulogu“ Radi, a tip Odeljenje ima ulogu „zapošljava“. 

Veze se mogu uspostavljati i izmeñu pojavljivanja objekta istog tipa (odnosno nad 

istom klasom objekta). Na primer, jedan proizvod može biti sastavni deo drugog proizvoda, pri 

čemu objekat Proizvod u vezi igra dvostruku ulogu – jednom se tretira kao nadreñen 

(sastavljen) a drugi put kao podreñen (ugrañen) proizvod u odgovarajućoj strukturi proizvoda. 

Isto tako je moguće uspostaviti više različitih klasa veza izmeñu dve iste klase objekata. 

Jedna od ključnih karakteristika veza je kardinalnost njenih preslikavanja. 

Kardinalnost preslikavanja E1-->E2 definiše se parom (DG, GG), gde DG (donja granica) daje 

najmanji mogući, a GG (gornja granica) daje najveći mogući broj pojavljivanja tipa objekata 

E2 za jedno pojavljivanje objekta E1. Očigledno, DG ne sme biti veća od GG. 

Njihove vrednosti mogu biti 1, ili neki prirodan broj. DG takoñe može imati vrednost 0, 

dok GG može imati vrednost M što označava nepoznat ceo broj veći od 1. 

Objekti se opisuju preko svojih svojstava, odnosno atributa. Svaki atribut u jednom 

trenutku vremena ima neku vrednost. Atributi uzimaju vrednost iz skupa mogućih vrednosti, 

koji se nazivaju domenima. 

U DOV oni se prikazuju elipsama. Domeni mogu biti predefinisani, odnosno standardni 

programsko-jezički domeni (npr. Integer, Character itd) i semantički, kada se posebno 

iskazuju, pomoću svog imena, predefinisanog domena, i ograničenja na mogući skup vrednosti 

predefinisanog domena. U MOV se skoro isključivo koriste predefinisani domeni. 

Ukoliko je moguće da atribut ima veći broj vrednosti za jednu instancu objekata u isto 

vreme (npr. poznavanje engleskog, ali i francuskog jezika) atribut se naziva višeznačnim. 

Zbog jednostavnije transformacije MOV u implementacioni model, kao i jednostavnijeg 

defiisanja ograničenja i operacija u MOV, ne koriste se višeznačni atributi, već se predstavljaju 

na jedan od sledeća dva načina: 

Ako domen višeznačnog atributa ima unapred zadat, semantički značajan skup 

atributa, tada se on modelira kao klasa objekata, a višeznačni atribut se predstavlja kao 

preslikavanje u novodefinisanoj vezi posmatrane klase sa ovom novom klasom. 

Ako domen višeznačnog atributa nema unapred zadat semantički značajan skup 

vrednosti, tada ga je pogodno predstaviti preko novog koncepta – koncepta identifikaciono 

zavisnog (slabog) objekta. Pojavljivanja slabog tipa objekta nemaju sama za sebe nikakvo 

značenje, već ga dobijaju tek kroz vezu sa drugim, nadreñenim, objektom u posmatranom 

sistemu. Shodno tome, slabi objekat u modelu ne može da postoji ni da se identifikuje bez 

veze sa njemu nadreñenim objektom. U skladu s time, kardinalnost slabi-->nadreñeni je 

trivijalna (uvek je DG=GG=1), pa se ne navodi, dok se u drugom smeru kardinalnost mora 

specifikovati. 

Pored DOV neophodno je dati i definiciju atributa, odnosno njihovih domena. 

Najpogodnije je to učiniti preko tabele u kojoj se daju naziv atributa, predefinisani domen nad 

kojim je on definisan i ograničenja na vrednosti iz domena. 

11/51


2.3. OGRANIČENJA, OPERACIJE, I DINAMIČKA PRAVILA INTEGRITETA 

Kao što je rečeno, najznačajnija komponenta MOV je njegova struktura. Ostali 

elementi su ograničenja, operacije i dinamička pravila integriteta. Pogodno je klasifikovati 

ograničenja u sledeće klase: 

Strukturna ograničenja, koja su u osnovi jezički iskaz grafičke predstave Modela 

objekti-veze. Jezički iskaz strukture je bitan samo u onim delovima modela u kojima je 

moguće da operacije ažuriranja baze naruše strukturu modela. 

Očigledno je da se to prvenstveno odnosi na kardinalnosti preslikavanja, pa se kod 

iskaza dinamičkih pravila integriteta o svim kardinalnostima preslikavanja, uključujući i 

neoznačene kardinalnosti za trivijalna preslikavanja, mora voditi računa. 

Vrednosna ograničenja definišu dozvoljene vrednosti atributa i dozvoljene promene 

ovih vrednosti. U vrednosna ograničenja spadaju ranije navedena ograničenja na pojedinačne 

vrednosti atributa, koja se nazivaju prosta vrednosna ograničenja. 

Meñutim, postoje i složena ograničenja, koja vezuju vrednosti različitih atributa u 

specifičnim pojavljivanjima objekata različitih klasa. Na primer, „student petog semestra mora 

imati položen predmet Matematika I“. ovaj primer oslikava „ograničenje stanja“, što 

podrazumeva dozvoljena stanja u jednom MOV. Meñutim, mogu se definisati i „ograničenja 

prelaza stanja“ koja definišu moguće promene datog stanja sistema, odnosno datih vrednosti 

atributa. Na primer: „Ocena pri ponavljanju ispita ne može opadati“. 

Osnovne operacije u MOV su ubacivanje (insert) novog pojavljivanja objekta u klasu, 

, izbacivanje (delete) pojavljivanja objekta iz klase, ažuriranje (Update), odnosno izmena 

vrednosti nekog atributa datog pojavljivanja objekta neke klase, zatim povezivanje (Connect) 

pojavljivanja O1 klase A sa pojavljivanjem O2 klase B, razvezivanje (Disconnect) pojavljivanja 

objekta O1 klase A i pojavljivanja objekta O2 klase B i prevezivanje (Reconnect) koja je u 

suštini uzastopna primena operacija razvezivanja i povezivanja. 

Kardinalnosti preslikavanja definišu da li se odgovarajuće operacije mogu izvesti, 

odnosno koje se sve operacije moraju zajedno izvesti u jednoj transakciji, da bi se očuvao 

integritet baze podataka. Tu su, naravno, i operacije pretraživanja – navigacione operacije, i 

upitni jezik MOV. 

Dinamičko pravilo integriteta čini trojka , preko 

koje se iskazuje koja se akcija preduzima kada neka operacija naruši definisano ograničenje. 

Kada se ista akcija preduzima bez obzira na to koja je operacija narušila ograničenje, 

dovoljno je definisati samo ograničenje i akciju. Ponekad se dinamičko pravilo integriteta 

definiše i kao četvorka. Četvrti član je tada trenutak ispitivanja ograničenja koji može da bude: 

(1) neposredno pri izvršenju operacije ažuriranja ili (2) na kraju transakcije. 

Prosta ograničenja, odnosno ograničenja na pojedinačne vrednosti atributa mogu 

narušiti operacije ubacivanja novog pojavljivanja u klasu i ažuriranje vrednosti atributa nekog 

pojavljivanja. Očigledno je da će se, bez obzira na to koja je od ovih operacija narušila 

ograničenje, preduzeti ista akcija. Zbog toga u definisanju din. pravila integriteta ove vrste nije 

potrebno navoditi operaciju. Ranije je pokazano, da je najpraktičnije ograničenje na atribute 

na atribute prikazati preko tabele sa kolonama atribut, domen, ograničenje. 

12/51


Za iskazivanje dinamičkog pravila integriteta za atribute, dovoljno je proširiti ovu 

tabelu kolonom akcija i formirati na primeru tabele 1: 

Atribut Domen Ograničenje Akcija 

Mbr long NotNull and Substring(1,2) Between 1,31 and... Poruka: “Nekorektan Mlb” 

Naziv string In(Srpski,Ruski,Engleski,Nemački) Poruka: “Jezik ne postoji” 

Adresa string 

Datum date 

rakete short Between 1,55 

13/51 

Poruka: “Broj raketa van 

opsega” 

ŠifOd short Moduo_11 

Poruka: Nije zadovoljen 

Moduo 11 

Tabela 1: Dinamička pravila integriteta za atribute 

Kako je u ovoj vrsti dinamičkog pravila integriteta akcija, gotovo uvek, odbijanje 

(poništavanje) operacije uz poruku sa odgovarajućim tekstom, ovu vrstu pravila obično nije 

neophodno ni navoditi, već je dovoljno zadati samo ograničenja na atribute, podrazumevajući 

da su ona ovako specifirana. I za složena vrednosna pravila integriteta uobičajeno je da je 

akcija koja se definiše jedinstvena za sva moguća narušavanja posmatranog ograničenja. 

2.4. STRUKTURNA DINAMIČKA PRAVILA INTEGRITETA I FIZIČKI MOV 

Strukturna ograničenja u MOV definisana su samom strukturom modela, odnosno 

načinom meñusobnog povezivanja različitih klasa objekata. Operacije održavanja baza 

podataka mogu ili ne mogu biti izvršene, narušavaju ili ne narušavaju strukturna ograničenja, 

zavisno od kardinalnosti preslikavanja veza izmeñu klasa. 

Tako, na primer, operacija Connect se ne može izvršiti za dato projavljivanje i 

preslikavanje sa donjom granicom različitom od nule, jer ako dato pojavljivanje postoji, ono 

mora biti već povezano preko datog preslikavanja sa nekim pojavljivanjem klase kodomena. Iz 

istog razloga na preslikavanju takve vrste se ne može izvršiti ni operacija Disconnect. Ili, 

operacija Insert poziva automatsko pozivanje operacije Connect za sva obavezna preslikavanja 

(DG>0) koja poseduje posmatrana klasa, imajući u vidu i druge moguće odnose operacija 

održavanja baze i kardinalnosti preslikavanja, očigledno je da je definisanje Strukturnih 

dinamičkih pravila integriteta, nad prikazanom strukturom MOV, veoma složeno. 

Zbog toga je pogodno da se dati MOV transformiše u tzv. Fizički model objekti-veze. U 

FMOV ne postoje veze u kojima oba preslikavanja imaju gornju granicu kardinalnosti M - ove 

veze treba predstaviti kao agregacije. Isto tako u FMOV ne postoje veze u kojima oba 

preslikavanja imaju donju granicu kardinalnosti jednaku 0 – ove veze se takoñe transformišu 

kao agregacije.


2.5. KONCEPTUALNO MODELOVANJE 

Konceptualni model predstavlja suštinske karakteristike sistema za koji se projektuje 

baza podataka, opisane na visokom nivou apstrakcije, preko modela podataka. On predstavlja 

celokupan mogući informacioni sadržaj baze podataka, nezavisno od toga koji je deo tog 

sadržaja i kako implementiran. 

Premda su modeli podataka manje-više formalno zasnovani, sam postupak 

modelovanja je veština, i veoma zavisi od sposobnosti, znanja i iskustva analitičara. Neki od 

ključnih metoda modelovanja su integracija podmodela, normalizacija relacija i transformacija 

modela. 

Metoda integracije podmodela podrazumeva izgradnju poslovnog modela sistema i 

specifikaciju primitivnih procesa (metodama kao što su SSA ili Use-Case dijagrami u okviru 

UML-a), potom izgradnju podmodela podataka za svaki od tih procesa (koristeći model objektiveze 

iliti EER, ili neki odgovarajući model), i na kraju – integraciju tih podmodela u jedan, 

jedinstveni model sistema. 

Dakle, strukture tokova i skladišta podataka u SSA koriste se kao osnova za 

formiranje EER modela baze podataka. Tokovi i skladišta podataka se sastoje od jednog ili više 

poslovnih dokumenata, koji, opet, prikazuju neki skup meñusobno povezanih objekata. Upravo 

te objekte, njihove atribute, i veze meñu njima je od ključnog značaja identifikovati. 

Ukoliko u okviru dokumenta postoje stavke, tj. skup polja koja se višestruko 

ponavljaju (tabele), pogodno je te stavke tretirati kao zasebne, „slabe“ objekte u modelu. 

Prva normalna forma takoñe sugeriše upravo ovakav pristup. Dokumenta koja dolaze 

iz „okoline“ sistema je takoñe najpogodnije predstavljati kao slabe objekte svojih pošiljalaca. 

14/51


2.6 NORMALIZACIJA RELACIJA 

Normalizacija relacija je postupak razvoja relacionog konceptualnog modela u kome se 

svaka relacija nekog relacionog modela svodi na odgovarajuću “normalnu formu”. Meñutim, 

definicije normalnih formi, imaju i opštiji značaj i mogu se eksplicitno ili implicitno koristiti i za 

primenu drugih modela u konceptualnom modelovanju. 

Uobičajeno je da se postupak normalizacije tretira i kao postupak logičkog 

projektovanja baza podataka. Ovde se logički model baze podataka, nezavisan od konkretnog 

SUBP-a, tretira kao konceptualni model, pa se normalizacija, koja takoñe ne zavisi od 

konkretnog SUBP-a, tretira kao postupak konceptualnog modelovanja. 

Relacioni model zahteva da se sve relacije u modelu nalaze u Prvoj normalnoj formi. 

Prva normalna forma se definiše na sledeći način: Relacija R je u prvoj normalnoj formi 

(1NF) ako su sve vrednosti njenih atributa atomske. 

Termin “normalizovana relacija” se koristi za relacije u Prvoj normalnoj formi. Ostale 

normalne forme relacija nisu zahtev samog Relacionog modela, već predstavljaju način da se 

iskažu kriterijumi za dobru praksu konceptualnog modelovanja, odnosno logičkog 

projektovanja relacione baze podataka. 

Uobičajeno je da se normalizacija tretira kao postupak kojim se odstranjuju tzv. 

“anomalije u održavanju (ažuriranju)” relacija, do kojih dolazi zbog redundanse podataka u 

bazi podataka. Osnovne operacije održavanja (ažuriranja) baze podataka u relacionom modelu 

su dodavanje nove n-torke u relaciju, izbacivanje neke n-torke iz relacije i izmena vrednosti 

nekog atributa u relaciji. Anomalije u ažuriranju će biti objašnjene na primeru sledeće relacije 

koja se nalazi u 1NF: 

Strelac(mbr, Ime, prezime, adr, opstina, vreme, raspol., id_radS, tip, frek, snaga) 

mbr ime preze adr opstina vreme raspol. id_radS tip frekvencija snaga 

2323 Mika Mikic Adresa1 Nbgd 9:35 Da 121 Ruf 500 200 

2321 Zoran Zoranic Adresa2 Nbgd 9:20 Da 122 Ruf 500 200 

3344 Zoran Zoranic Adresa3 Nbgd 9:15 Da 123 Ruf 500 200 

Tabela 2:Primer tabele u prvoj normalnoj formi 

15/51


Anomalije u dodavanju su naziv za situaciju u kojoj u bazu podataka nije moguće 

ubaciti neki logički skup podatka, a da se pri tome, zbog strukture relacija ne zahteva i 

ubacivanje nekih drugih podataka. Na primer, novi strelac se ne može ubaciti u evidenciju dok 

ne bude makar jednom prozvan. 

Anomalije u izbacivanju su naziv za situaciju u kojoj izbacivanje nekog logičkog 

skupa podataka iz baze, prouzrukuje i neželjeno izbacivanje nekih drugih podataka. 

Anomalije u promeni sadržaja su situacija u kojoj promena jednog podatka 

zahteva i promenu nekih drugih podataka u bazi. Na primer, ako strelac promeni radio-stanicu, 

mora se menjati onoliko podataka koliko puta je taj strelac prozvan. 

Već je rečeno da je redundansa podataka uzrok prikazanih anomalija. Meñutim, isto 

tako se može reći da su redundansa, odnosno anomalije u ažuriranju, prouzrokovane 

činjenicom da relacija Strelac predstavlja spoj (agregaciju) više različitih objekata sistema. 

Ona istovremeno predstavlja objekte Strelac, Radio-Stanica, Stand-By (odnosno regularna 

prozivka) i njihove meñusobne veze. Ako bi se relacija Strelac dekomponovala na relacije koje 

bi pojedinačno predstavljale ove pojedinačne objekte, 

Strelac1 (mbr, ime, prezime, adresa, telefon, opstina, cizme) 

Stand_by(vreme_prozivke, raspolozivost) 

Radio_stanica (id, tip, frekvencija, snaga, napajanje) 

redundansa podataka bi se minimizovala i izbegle sve anomalije. Postavlja se pitanje 

kako se, od bilo kog skupa relacija, može doći do skupa koji zadovoljavajuće modeluje realni 

sistem, pa samim tim ima i minimalnu redundansu. 

Normalizacija je opšti postupak dovoñenja relacija u normalne forme koje 

predstavljaju fundamentalne objekte sistema i njihove veze. Normalne forme, samim tim, 

garantuju minimum redundanse podataka u bazi i održavanje baze bez anomalija. 

16/51


2.7. FUNKCIONALNE ZAVISNOSTI 

Definicije druge, treće i Boyce-Codd-ove normalne forme zasnivaju se na konceptu 

funkcionalne zavisnosti atributa relacije, koja se definiše na sledeći način: Data je relacija R 

sa atributima X i Y, moguće složenim. Atribut Y je funkcionalno zavisan od atributa X 

(odnosno X funkcionalno odreñuje Y), R.X→R.Y, ako i samo ako svakoj vrednosti X 

odgovara jedna i samo jedna vrednost Y. 

Na primer, u relaciji Strelac datoj na početku postoje sledeće funkcionalne zavisnosti: 

mbr → ime, prezime, adresa, telefon, opstina, cizme, vreme_prozivke, raspolozivost, 

id_stanice, tip_stanice, frekvencija, snaga, napajanje 

vreme_prozivke → raspolozivost 

id_stanice →, tip_stanice, frekvencija, snaga, napajanje 

Definicija funkcionalne zavisnosti se može dati i na sledeći način: Atribut Y relacije R je 

funkcionalno zavisan od atributa X relacije R ako i samo ako, kad god dve n-torke relacije R 

imaju istu x-vrednost one moraju imati i istu y-vrednost. 

Iz definicije funkcionalne zavisnosti proističe i jedna od definicija ključa i nadključa 

relacije: Atribut X, moguće složeni, je nadključ relacije R ako i samo ako funkcionalno odreñuje 

sve ostale atribute relacije R. Atribut X, moguće složeni, je ključ relacije R ako je nadključ 

relacije R, a nijedan njegovi pravi podskup nema tu osobinu. 

Koncept potpune funkcionalne zavisnosti se definiše na sledeći način: Atribut Y relacije 

R je potpuno funkcionalno zavisan od atributa X relacije R ako je funkcionalno zavisan od 

atributa X, a nije funkcionalno zavisan ni od jednog pravog podskupa atributa X. 

Na kraju, ukoliko je atribut C funkcionalno zavisan od atributa A i od atributa B, a 

atribut B je i sam funkcionalno zavisan od A, tada je atribut C tranzitivno funkcionalno zavisan 

od A. 

17/51


2.8. DEKOMPOZICIJA RELACIJA BEZ GUBLJENJA INFORMACIJA 

Kao što je na primeru relacije Strelac pokazano, svoñenje relacija na normalne forme 

zahteva dekompoziciju polazne relacije na njene projekcije. Postavlja se pitanje da li se pri 

takvoj dekompoziciji gubi neka informacija iz polazne relacije, odnosno postavlja se zahtev da 

se ovakva dekompozicija vrši bez gubljenja informacija. 

Relacija R se dekomponuje u svoje projekcije bez gubljenja informacija ako prirodno 

spajanje tako dobijenih relacija dovodi do polazne relacije. 

Relacija R(A,B,C) gde su A, B i C podskupovi atributa, u kojoj važi R.A-->R.B može se 

uvek dekomponovati u svoje projekcije R1(A,B) i R2(A,C) bez gubljenja informacija. 

18/51

id_ra 

keta 


2.9. DRUGA I TREĆA NORMALNA FORMA 

Posmatrajmo relaciju raketa. 

id_pgs tip proizvoñ 

ač 

god_proi 

zvodnje 

rok_traj 

anja 

19/51 

brzina max_visi 

na 

Kol_reag 

ensa 

kolicina 

2 34 KK07 Ruma 2006 5 200 8 100 5 

4 22 KK45 Ruma 2006 6 300 6 100 5 

5 11 JS34 Ruma 2006 5 200 8 100 2 

Tabela 3:Relacija raketa 

Očigledna je redundansa podataka u ovoj relaciji: svi neključni atributi sem količine 

raketa na stanici se pojavljuju uz svaku vrstu raketa dostavljenu na odreñenu stanicu. Postoje 

sve anomalije u održavanju BP. Uzrok redundansi i anomalijama u održavanju je što jedino 

količina raketa potpuno funkcionalno zavisi od složenog ključa id_pgs, id_rakete, odnosno: 

id_pgs, id_rakete → kolicina, tip, proizvodjac, godina_proizvodnje, rok_trajanja, 

max_visina, kol_reagensa, brzina 

id_rakete → tip, proizvodjac, godina_proizvodnje, rok_trajanja, max_visina, 

kol_reagensa, brzina 

Definicija druge normalne forme zabranjuje ovakve zavisnosti, i glasi: Relacija R je u 

Drugoj normalnoj formi (2NF) ako i samo ako je u 1NF i svi njeni neključni atributi potpuno 

funkcionalno zavise od primarnog ključa. 

Neključni atributi su atributi koji nisu kandidati za ključ, niti deo kandidata za ključ. U 

relaciji prijava to su svi atributi sem primarnog ključa, tj. Složenog atributa id_pgs, id_rakete. 

Atribut kolicina je potpuno funkcionalno zavisan od primarnog ključa, dok ostali nisu. 

Zbog toga relacija Prijava nije u 2NF. Svoñenje na 2NF vrši se dekompozicijom, na taj način 

što se u jednoj projekciji ostavlja primarni ključ i svi aztibuti koji su potpuno funkcionalno 

zavisni od njega, dok se u drugim projekcijama realiuju one funkcionalne zavisnosti koje su 

prouzrokovale nepotpune funkcionalne zavisnosti. 

Za navedeni primer relacije Prijava dekompozicija je: 

raketa_pgs(id_pgs, id_rakete, kolicina) 

Raketa(id_rakete, tip, proizvodjac, godina_proizvodnje, rok_trajanja, max_visina, 

kol_reagensa, brzina) 

Iz definicije 2NF i definicije potpune funkcionalne zavisnosti očigledno je da je svaka 

relacija sa prostim primarnim ključem u 2NF jer prosti ključ nema semantički moguć pravi 

podskup. 

Pogledajmo sada relaciju Strelac:


Strelac (mbr, ime, prezime, adresa, telefon, opstina, cizme, vreme_prozivke, 

raspolozivost) 

U relaciji postoji tranzitivna funkcionalna zavisnost (zbog zavisnosti vreme_prozivke -- 

> raspolozivost), a možemo primetiti da ovo izaziva i redundansu podataka, pa shodno tome i 

anomalije u održavanju. Postojanje ovakvih zavisnosti zabranjuje Treća normalna forma, čija 

je definicija: Relacija R je u Trećoj normalnoj formi (3NF) ako i samo ako je u 2NF i 

ako svi njeni neključni atributi netranzitivno zavise od primarnog ključa. 

Svoñenje na 3NF vrši se dekompozicijom relacije u njene projekcije na taj način što se 

u jednoj relaciji ostavljaju primarni ključ i svi netranzitivno zavisni atributi, a u ostalim 

projekcijama se realizuju funkcionalne zavisnosti koje su dovele do tranzitivnih zavisnosti. 

Tako će se u našem primeru relacija Strelac dekomponovati na: 

Strelac1 (mbr, ime, prezime, adresa, telefon, opstina, cizme) 

Stand_by(vreme_prozivke, raspolozivost) 

20/51


2.10. EER PODMODELI 

Protivgradno delovanje vrši se sa protivgradnih stanica (PGS) koje se nalaze u 

relativnoj blizini naselja. PGS su odreñene identifikacionim brojem, nazivom, adresom, 

telefonom, opštinom kojoj pripadaju, geografskim koordinatama, nadmorskom visinom, i 

brojem raketa koje se trenutno nalaze na njoj. Sa njih deluju Strelci koji žive u blizini. 

Delovanje PGS je ograničeno zonama zabrane koje natkriljuju naseljena mesta i 

uopšte položaje u čijem se smeru iz odreñenog razloga ne sme delovati. Zone zabrane 

odreñene su početnim i krajnjim azimutom. 

Jedna PGS može imati i nekoliko Zona zabrane ali one ne smeju zauzimati više od ??? 

stepeni azimuta, jer inače PGS nije praktična. Na PGS se mogu naći i različiti tipovi raketa, koji 

su opisani u tabeli Raketa, i karakterišu ih identifikacioni broj, naziv tipa rakete, proizvoñač, 

zatim godina proizvodnje, rok trajanja, maksimalna visina, količina reagensa i brzina rakete. 

Lanser raketa je opisan identifikacionim brojem, proizvoñačem, brojem raketa koji 

može nositi, a beleži se i da li je ispravan. Na svakoj PGS nalazi se po jedan lanser. 

Slika 2: EER podmodel 1 

21/51


Svako lansiranje rakete vrši se, očigledno, sa jedne od PGS i ka odreñenom cilju. 

Lansiranje ima svoj identifikacioni broj, za potrebe izveštaja, zatim vreme lansiranja i status, 

odnosno ishod lansiranja (da li je uspešno, ili je došlo do komplikacija - zaglavljene rakete, 

neispravne rakete i sl.). 

Na jedan cilj se po pravilu ispaljuje veći broj raketa, jer formiranje grada je 

kontinualni proces i delovanje se mora vršiti relativno dugotrajno. Cilj karakterišu 

identifikacioni broj, trenutne koordinate, nadmorska visina, pogodan tip rakete i tempiranje 

rakete. 

Lansiranje se u skladu sa karakteristikama cilja može vršiti nekim od dostupnih tipova 

raketa. Još jednom naglašavamo da se u tabeli Raketa zapravo nalaze podaci o TIPOVIMA 

raketa a ne pojedinačnim raketama, tako da se za svako pojedinačno lansiranje koristi jedan 

tip rakete, dok isti tip rakete može biti korišćen za više lansiranja. 

Slika 3:EER podmodel - Lansiranje 

Strelac od atributa poseduje matični broj, ime, prezime, adresu, telefon, opštinu i broj 

čizama. Takoñe sa sobom nosi radio-stanicu, o kojoj se informacije vode u zasebnoj tabeli, u 

kojoj se nalaze identifikacioni broj stanice, njen tip, frekvencija, snaga i napajanje. 

Svaki strelac nosi jednu stanicu i svaka stanica odgovara jednom strelcu. Strelac 

deluje na jednoj odreñenoj PGS u svojoj opštini, i može biti glavni ili pomoćni strelac. Svaka 

PGS ima jednog glavnog i jednog pomoćnog strelca. 

22/51


Evidencija o dostupnosti strelaca vodi se u dve tabele - prva je "Stand-by" tabela u 

kojoj se evidentira regularno prozivanje strelaca, koje se vrši dvaput dnevno, i utvrñuje samo 

njihovu eventualnu dostupnost za slučaj da je delovanje neophodno. 

Ukoliko doñe do potrebe za delovanjem, strelcima se odašilje poziv da na njih i odu, i 

kada stignu oni se javljaju pri čemu se upisuju u drugu tabelu - "Evidencija". U obe tabele se 

beleži vreme prozivke. 

U stand by tabeli se beleži i raspoloživost strelca, dok su ostale informacijeu tabeli 

Evidencija broj raketa, stanje lansera i stanje radio-veze. 

Slika 4:EER podmodel - Evidencija 

23/51


2.11. POTPUNI EER MODEL 

24/51


Login forma: 

3. OBRANA OD GRADA – APLIKACIJA 

Slika 5: Login forma. 

Aplikacija je zaštićena od neovlašćenog korišćenja tako sto su uvedeni korisnici 

sistema. Oni upisuju svoje korisničko ime, šifru i nakon provere,mogu pristupiti glavnoj 

aplikaciji. 

Prilikom logovanja proverava se korisnik i na osnovu privilegija otvara mu se aplikacija 

sa dozvoljenim radnjama koje može izvršiti. 

Postoje dve vrste korisnika, obicni i administratorski. 

Obicni korisnik je i standardni korisnik koji može u potpunosti koristiti aplikaciju. 

Korisnik koji ima administratorske privilegije može da dodaje nove korisnike i da 

dodaje nove Radarske Centre, protivgradne stanice i vrši izmenu pomoćnog toolbar-a. 

25/51


3.1. GLAVNA APLIKACIJA I NJENI DELOVI 

Aplikacija se deli u 6 sekcija: 

Slika 6:Glavna aplikacija i njeni delovi. 

1. Logo aplikacije, naziv radarskog centra. 

2. Informacije o ulogovanom korisniku i dugme za Logout. 

3. Menubar, koji pruža mogućnosti da se pronadju odredjene sekcije unutar 

aplikacije i direktno pozove svaka od njih. 

26/51


4. Radna površina koja je izdeljena u tabove. 

U okviru radne površine postoje sledeći tabovi: 

- Sinoptička situacija. 

- Evidencija strelaca 

- Podaci o strelcima 

- Podaci o stanicama 

- Upozorenja i Najave 

- Prognoza Vremena 

- Beleske 

- Kalendar Dejstva 

- Dnevni Izvestaj 

- Godišnji izveštaj 

- Ostali Izveštaj. 

5. Pomoćni toolbar sa najčešće korišćenim funkcijama (Moguce menjati ukoliko 

je ulogovan Administratorski korisnik). 

6. Status bar, koji obaveštava korisnika o uspešnosti izvršenja funkcija aplikacije. 

27/51


3.1.1 Radna površina 

Izdeljena je u tabove kako bi korisnik lako mogao da prelazi sa jedne na drugu 

opciju i da paralelno radi vise zadataka bez gubitka podataka. 

3.1.2. Sinoptička situacija 

U ovom delu postoji interaktivna mapa na kojoj su prikazane pozicije Radarskih 

centara. 

Predvidjeno je za buduće ciljeve koji će se locirati na mapi i automatski odrediti 

dejstva samo odredjenih protivgradnih stanica na kojima su se evidentirali strelci. 

Slika 7: Mapa pokrivenosti. 

Takodje, postoji mogućnost Praćenja dejstva odreñene stanice u odredjenom 

periodu ili trenutku u zavisnosti od zahteva korisnika. 

Postoji lista proteklih dejstva koja se arhiviraju i iz njih se kasnije prave dnevni, 

godišnji i ostali izveštaji koji su potrebni radi dalje analize. 

28/51


3.1.3. Evidencija strelaca 

Prikaz strelaca je takodje ostvaren preko interaktivne mape na kojoj su prikazane 

lokacije svih strelaca upisanih u bazu. 

U ovom delu je potrebno evidentirati strelce i njihova redovna javljanja u toku dana. 

Strelac se prvo evidentiran kao dostupan tj. da se javio na redovno prozivanje u 

odredjenom vremenskom periodu (9h i 17h). 

Zatim se strelac evidentira kao prisutan (stand by), kako bi se znalo i upisalo u bazu 

da je spreman za dejstvo. 

Svako azuriranje se automatski prikazuje na mapi i u zavisnosti od statusa strelca 

menja se njegov izgled na mapi.Korisnik takodje na mapi može da se informiše o strelcu 

(ime,prezime,broj telefona,adresa i broj raketa u datoj protivgradnoj stanici). 

Predviñeno je da se u okviru administratorskog naloga omogući korisniku da ubacuje 

novog strelca i locira ga na mapi kako bi bio evidentiran i takodje, dostupne sve informacije o 

njemu. 

Slika 8:Evidencija strelaca. 

29/51


3.1.4. Podaci o strelcima 

U ovom odeljku postoje 3 dela: Lista, podaci i pretraga strelaca.Aplikacija treba da 

omogući podatke o svim strelcima koji su uneti u bazu podataka. 

Lista strelaca je predvidjena za prikaz strelaca,njihovih podataka i njihov trenutni 

status. Podaci o strelcu se ispisuju u zavisnoti od označenog sterlca u listi koja je prikazana se 

leve strene radne površine. 

Slika 9:Podaci o strelcima 

Kada se prikažu adekvatni podaci o selektovanom strelcu ,moguće je izmeniti njegove 

podatke i ažurirati u realnom vremenu bez opterećivanja aplikacije i baze podataka. 

Svaki podatak o strelcu se kontrolise posebnom klasom u aplikaciji, koja ce 

proveravati unos koji korisnik preko tastature ispisuje u polja za unos. 

Kontrola podrazumeva stavljanje velikih slova na početak unosa, izbacivanje 

odredjenih znakova i ograničenje na brojčane vrednosti. 

Pretraga je omogućena po imenu, prezimenu i opštini. Korisniku se pritiskom na 

dugme “Traži“, u polju lista strelaca prikazuje rezultat pretrage. 

30/51


3.1.5. Podaci o protivgradnim stanicama 

Slika 10:Podaci o stanicama 

Kao i u prethodnom odeljku, postoje 3 dela: Lista,Podaci i pretraga protivgradnih 

stanica. 

Lista stanica sadrži spisak postojećih stanica koje su u sistemu odbrane od grada. 

Liste se sama ažurira posle odreñenog perioda,tako da je korisniku u svakom trenutku 

omogućena realna lista strelaca. 

Pretraga se vrši po nazivu, adresi i opštini. Nakom pritusnutog dugmeta, proveravaju 

se reči koje je korisnik uneo preko tastature i onda se vrši pretraga. Ukoliko ima rezultata 

,ispisuju se u desnom delu radne površine umesto postojeće liste stanica. 

Korisniku je omogućeno da vrši unos novih stanica. Kao i kod strelaca, vrši se provera 

podataka i ukoliko su podaci prosli proveru upisuje se u bazu. 

Takoñe, odabirom odreñene stanice iz Prikaza stanica, mogu se videti detaljne 

informacije. Kada su one prikazane moguće su izmene podataka. 

31/51


3.1.6. Upozorenja i najave 

Na sajtu Republičkog hidrometeorološkog zavoda Srbije se objavljuju zvanična 

upozorenja i najave na celoj teritoriji Srbije. Ti podaci se paralelno prikazuju u ovoj aplikaciji. 

Tada svi radarski centri imaju iste podatke i mogu medjusobno razmenjivati. Time se postiže 

veća efikasnost i skraćuje vreme dostupnosti informacijama od značaja. 

Slika 11:Upozorenja i najave 

Administratorskom korisniku je omogućeno da se upišu najave i upozorenja za svaki 

radarski centar. 

Predviñeno je da se na mapi Srbije prikazuju lokacije na koje se odnose odreñena 

upozorenja. 

32/51


3.1.7. Prognoza vremena 

Radarski centar je povezan sa Republičkim Hidrometeorološkim zavodom, i potrebne 

su svakom trenutku nove informacije o vremenskoj prognozi za odreñeni period. 

Ovde se prikazuje prognoza vremena za selektovani grad u narednih 5 dana. Takodje 

se prikazuje trenutna temperatura, vlañnost vazduha i brzina vetra. 

Može se prikazati prognoza vremena za 5 i 30 dana, kao i sezonsku prognozu. 

Predviñeno je da se ažuriraju i prikazuju Prognostičke karte i turbulencije. 

Slika 12:Prognoza vremena 

Prognostičke karte nam mogu prikazati površinski pritisak i padatavine,Temperature 

(2m),Vetar, geopotencijal i temperaturu. 

33/51


3.1.8. Beleške 

Svaki korisnik koji se uloguje moguće je da upisuje neke trenutke beleške koje će 

posle moći da pogledaju ostali korisnici i administatori. 

Namenjeno je za komunikaciju meñu korisnicima kako bi imali uvida u stanje sistema i 

odreñenih zapažanja. 

Takoñe može služiti kao podsetnik za svakog korisnika, kao i upozorenja na koje treba 

obratiti pažnju. 

Slika 13:Beleške 

U sredini radne površine postoji kalendar za laksu navigaciju i sortiranje beleski. 

Moguće je za svaki dan videti beleške koje se ispituju u listi beleški. 

34/51


3.1.9. Kalendar 

Predviñeno je da se kalendarski sortiraju i ispituju najvažniji podaci vezani za dejstva 

u odreñenom periodu. 

Svi podaci se arhiviraju i prikazuju u kalendaru. 

Moguće je pregledati dnevno, nedeljno i mesečno. 

Za svaki dan se ispituje broj ispaljenih raketa za odrešeni cilj i odreñenih protivgradnih 

stanica. 

Na osnovu toga je moguće vršiti statistiku svih podataka i praviti dijagrame na 

dnevnoj,mesečnoj i godišnjoj bazi. 

Sa leve strane radne površine nalazi se i forma za unos novog podatka koji se biti 

prikazan za odreñeni dan. 

nedelji. 

U donjem levom uglu se nalazi spisak broj nedelje kao i broj ispaljenih raketa u toj 

Slika 14:Kalendar dejstava. 

35/51


3.1.10. Dnevni i godišnji izveštaj. 

U ovom delu aplikacije se prave forme izveštaja koji se štampaju i objaljuju javno. 

Na osnovu unetih podataka u bazi prave se sledeći izveštaji: 

Pregled veličine branjene teritorije. 

Pregled vremenske situacije. 

Pregled dejstava. 

Pregled karakterističnih dejstava. 

Pregled šteta od grada. 

Zaključci 

Tabela 1 (Ukupna i poljoprivredna površina sa brojem planiranih i aktiviranih stanica 

i razlozima neaktiviranja) 

Tabela 2 (Kalendar dejstava na teritoriji Radarskog centra za odredjeni period) 

36/51


Tebela 3 (Pregled dejstava po opštinama na teritoriji Radarskog centra za odreñeni 

period). 

Tabela 4 (Pregled šteta od grada na teritoriji Radarskog Centra). 

37/51


3.1.11. Korisnici, satnica i logout 

Svaki zaposleni u radarskom centru koji je ovlašćen da koristi Informacioni sistem je 

jedan korisnik. 

Slika 15:Korisnici, satnica i logout. 

Prilikom logovanja u sistem, pocinje da mu se racunaju i sati provedeni u radu. 

Moguće je napraviti listing sata provedenih u tom radarskom centru, kao i vreme provedeno na 

svakom dejstvu posebno, čime se može izvući prosek provedenih sati na nekom dejstvu, 

brzina delovanja i ažurnost u praćenju ciljeva i pojava. 

Pomoć u korišćenju aplikacije. 

Takozvani HELP, je osmešljen kao potpuno objašnjenje aplikacije, kao i način 

upotrebe. Svaka stavka Informacionog sistema je objašnjena u ovom delu. 

Potrebno je svakoj vrsti korisnika objasniti principe rada aplikacije,kao i najefikaciniji 

način da se doñe do odredjenih stavki sistema. Za svaki deo aplikacije osmišljeno je više 

načina rada u njoj, kako bi se postigla veća efektivnost i laksa snalažljivost korisnika sistema. 

38/51


3.1.12. Pomoćni toolbar sa najčešće korišćenim funkcijama sistema. 

Slika 16:Pomoćni toolbar 

Potpuno korisnički toolbar namenjen je bržoj dostupnosti najčešće korišćenih 

funkcija u aplikaciji. 

Korisnici mogu vršiti komunikaciju sa administratorom i nagovestiti mu o 

mogućim izmenama ovog toolbar-a. 

Izmenu može vršiti samo administrativni korisnik.Promene su vidljive već nakog 

logovanja običnog korisnika. 

39/51


bazi. 

4. IZVEŠTAJ I ANALIZA 

Pravljenje izveštaja u ovoj aplikaciji je moguće na osnovu podataka koji se čuvaju u 

Na osnovu vremenskog perioda mogu biti konstruisani dnevni, mesečni i godišnji 

izveštaji. Takoñe se rade izveštaji svaki Radarski Centar i svaku protiv gradnu stanicu 

posebno. Na osnovu tih podataka mogu se izvući i statistički podaci, na osnovu kojih se vrši 

analiza. 

Analiza je potrebna radi samog ocenjenjivanja rada Radarskog centra i protivgradnih 

stanica. U tom slučaju se i ocenjuje rad informacionog sistema koji sakuplja i prikazuje 

rezultate u najkraćem mogućem periodu. 

Nakon dejstava u izveštajima o pripremljenosti sistema odbrane od grada moguće je 

ukazati na problem malih magacinskih zailha protivgradnih raketa. Za jednu sezonu odbrane 

od grada obično se izdvaja oko 10 000 raketa. 

Ukoliko ima manje raketa, to se jos nakon lansiranja odmah evidentira preko 

aplikacije u jedinstvenoj bazi podataka. Na osnovu ovih izveštaja moguće je u najkraćem 

mogućem roku ugovoriti proizvodnju novih raketa kako bi sve protivgradne stanice bile 

snadbevene dovoljnom količinom raketa. 

Jedan primer dnevnog izveštavanja o dejstvu i utrošenim protivgradnim raketama na 

jednom dejstvu. 

Red. 

broj 

Datum Opština 

40/51 

Broj PGS 

u dejstvu 

Ukupno utrošenih raketa 

ispravnih Neispravnih 

1. 25.04. Zemun 1 2 - 

Inñija 3 9 - 

Pećinci 3 9 - 

Ruma 7 21 1 

Sremska Mitrovica 2 8 - 

Stara Pazova 2 10 - 

Titel 2 4 - 

Dnevni zbir: 20 63 1 

Na osnovu ovog dnevnog izveštaja moguće je vršiti analizu i praviti planove za buće 

ciljeve i adekvatno vršiti dejstva sa lansiranjem pravim brojem raketa u odnosu na planiran 

čime se smanjuju troškovi finansiranja.


5. IZRADA APLIKACIJE – KORIŠĆENI PROGRAMI 

5.1. SQL Server 2005 

Baza podataka na koja čini ovaj Informacioni sistem je izrañena i implementirana u 

Microsoft SQL Serveru verzija 2005. Manipulacija podacima unutar baze je ostvarena pomoću 

programa MS SQL Menagment Studio Express. 

Microsoft SQL Server je relacijska baza podataka kojoj je primarni jezik za upite 

Transact SQL (T-SQL), što znači da osim osnovnih i klasičnih (SELECT tipa) SQL upita 

dozvoljava i složenije stvari poput mijenjanja programskog toka (IF naredba) i slično. 

Slika 17:SQL Server konekcija. 

Transact SQL nastao je kao plod saradnje izmeñu Microsofta i Sybasea. SQL server je 

baza podataka koja se smestila na prag izmeñu manjih i srednjih baza. 

Prva verzija SQL Servera koji ima veze sa Microsoftom (ranije je sybase proizvodio 

SQL server pod imenom „Sybase SQL server“) izašla je na svjetlo dana 1989. godine pod 

imenom „SQL Server for OS/2 1.0“. Ta verzija bila je identična Sybase-ovom SQL serveru 3.0 

koji je radio pod Unix sistemom. Microsoft SQL Server pod tim imenom se počeo prodavati 

1992. godine, a puno ime mu je glasilo Microsoft SQL Server 4.2 koji se još uvek vrteo na 

OS/2 platformi. 

Prvi SQL Server za Windows NT izašao je isto kada i sami Windows-i. U tom trenutku 

Sybase i Microsoft su se razišli, te je Sybase počeo razvijati svoju bazu podataka pod imenom 

Adaptive Server Enterprise da bi se izbjeglo zbunjivanje korisnika oko imena. Do 1994. 

Microsoft je svejedno morao na sada svojem sustavu nositi Sybaseovu oznaku zbog 

autorskih prava. 

41/51


Od trenutka raskida sa Sybaseom, Microsoft je napravio značajne pomake u razvoju 

svoje baze podataka. 

SQL Server je prva baza podataka na svetu koja je posedovala korisnički interfejs. Sve 

baze su u tadašnje vrijeme radili pomoću „command-line“ sistema koji zna biti izrazito 

nezgodan i nezgrapan. Takoñe, SQL Server je prva komercijalna baza podataka koja je 

podržala Intelovu 64-bitnu arhitekturu procesora. 

Trenutno najnovija verzija SQL Servera je SQL Server 2005 koja je izdana u zimu 

2005. godine. 

Od SQL Servera 2000 do SQL Servera 2005 napravljeni su veliki pomaci u poboljšanju 

same baze podataka. 

Najbitniji od njih su: Klijentski dio IDE alata, SQL Server Integration Services, 

Reporting Server, OLAP server, podrška za data mining, Notification Services itd. 

SQL Server koristi Transact SQL kao implementaciju SQL-92 (ISO standard za SQL, 

prihvaćen 1992. godine) sa mnogim ekstenzijama. T-SQL uglavnom dodaje dodatnu sintaksu 

prilikom pisanja procedura, te utječe na podršku za transakcije. 

Microsoft SQL server i Sybase/ASE obje komuniciraju preko aplikacijski niveliranog 

protokola imenom „Tabular Data Stream“ ili kraće TDS. TDS je takoñer implementiran od 

strane FreeTDS-a da bi se omogućilo da što više aplikacija može komunicirati s Microsoft SQL 

Server i Sybase bazama podataka. 

Microsoft SQL takoñer podržava „Open Database Connectivity“, odnosno skraćeno 

ODBC tehnologiju. SQL Server 2005 posjeduje i podršku za Web servise, tj. za Simple Object 

Access Protocol, Service Oriented Architecture Protocol odnosno skraćeno SOAP W3C standard. 

To je izvanredna stvar zato što omogućuje ne Windows klijentima da komuniciraju preko te 

platforme sa SQL Serverom. 

U verziji 2005 takoñer je izdan i certificiran JDBC API za komunikaciju sa Java 

aplikacijama. SQL Server takoñer poseduje i mogućnosti poput mirroringa, clusteringa i 

snapshots-ova. 

Microsoft se ovde zbilja potrudio, te nam omogućio brojne aplikacije koje spremaju 

podatke na SQL Server. SQL Server 2005 uključuje i Common Language Runtime odnosno 

ranije spominjani CLR. Aplikacije pisane u .NET-u bez obzira koji programski jezik koristili, 

sada mogu implementirati procedure i funkcije. Starije verzije programa za razvoj su za to 

koristile API-je. 

42/51


5.2. SQL Management Studio 

SQL Management Studio je sastavni deo SQL Servera i preko njega je omogućena 

konfiguracija i administriranje svim komponentama unutar SQL Servera. Ovaj program 

uključuje konzolni i grafički pristup podacima unutar baze podataka. 

Slika 18:SQL Management Studio Express 

43/51


5.3. Microsoft Visual Studio 2008 

Aplikacija je dizajnirana i izradjena pomoću programa Visual Studio 2008 u jeziku C# 

sa ADO.NET načinom za rad sa podacima u bazi podataka. 

Visual Studio 2008 je zasnovan na Microsoftovoj viziji koja omogućava programerima i 

razvojnim timovima da veoma brzo kreiraju povezane aplikacije zajedno sa efektnim 

korisničkim iskustvom u radu sa operativnim sistemom Windows Vista,Windows XP, sistemom 

Microsoft Office 2007, mobilnim ureñajima i Webom. 

Visual Studio nije neophodan za razvoj C# aplikacija, ali nam znatno olakšava stvari. 

Možemo (ako to poželimo) napisati naš kod u najobičnijem programu za ureñivanje teksta, kao 

što je Notepad, i kompajlirati kod u sklopove koristeći kompajler iz komandne linije koji je u 

sastavu .NET okruženja. 

Meñutim, zašto bismo to radili, kada možemo iskoristiti snagu VS-a da nam pomogne. 

Slika 19: Visual Studio 2008 

44/51


Evo nekih od razloga zbog kojih VS pravi izbor za razvoj u .NET okruženju: 

� Visual Studio automatizuje korake neophodne pri kompajliranju prirodnog 

koda, ali u isto vreme dozvoljava i kompletnu kontrolu nad opcijama ukoliko 

želimo da ih primenimo. 

� Visual Studio za ureñivanje teksta je povezan sa jezicima koje podržava 

VS(uključujući jezik C#) i to tako da omogućuje pametnu detekciju grešaka i 

sugeriše odgovarajući kod na pravom mestu dok ga unosimo. 

� Visual Studio sadrži i dizajnerske alate za aplikacije koje uključuju Windows 

formulare kao i Web formulare, koji vam omogućuju jednostavna tehnika 

povlačenja i puštanja (eng drag-and-drop) dizajn elemenata korisničkog 

interfejsa. 

� Mnogi tipovi projekata koji su mogući u C# mogu se napraviti sa 

”opštenamenskim” kodom koji se već nalazi na pravom mestu. Umesto da 

počinjemo od nule, često ćemo naći različite datoteke koje sadrže kod koji je za 

nas započet, smanjujući nam vreme provedeno u spremanju projekta. 

� VS sadrži nekoliko čarobnjaka koji vam automatizuju zadatke opšte namene i 

koji mogu dodati odgovarajućim datotekama, ada mi o tome ne vodimo brigu 

(ili da u nekim slučajevima čak i nea pamtimo tačnu sintaksu). 

� VS sadrži moćne alatke za prikazivanje i navigaciju elemenata našeg projekta, 

bez obzira da li se radi o prirodnom kodu jezika C# ili nekoj slici, ili mozda 

zvučnoj datoteci. 

� Pored toga što olakšava pisanje aplikacija , VS omogućuje i jednostavniju 

distribuciju i prilagoñavanje projekata klijentima, kako bi ih oni lakše koristili ili 

instalirali. 

� VS omogućuje i napredne tehnike otklanjanja grešaka pri razvoju projekata, i 

to tako da možemo u isto vreme vreme ući u kod jedne instrukcije dok pazimo 

u kakvom je stanju aplikacija. 

Kada koristimo VS za razvoj aplikacija, to radimo kreiranjem rešenja. Rešenje, po VS 

terminologiji, predstavlja nešto više id aplikacije. Rešenja sadrže projekte koji mogu biti 

zasnovani na Windows formularima, Web formularima i tako dalje. Rešenja mogu sadržati i 

više projekata, tako da možemo grupisati srodan kod na jedno mesto, iako će se oni 

kompajlirati u različite sklopove na različitim mestima na disku. 

Ovo može biti od velika koristi, kada se radi o deljenom kodu (koji može biti smešten 

u globalni keš sklopova) u isto vreme dok aplikacije koriste taj kod. Otklanjanje grešaka u 

kodu je mnogo lakše ako se koristi jedinstveno razvojno okruženje, jer možemo pratiti 

instrukcije u višestrukim modulima koda. 

45/51


5.4. Microsoft.NET Framework 

Microsoft.NET Framework je integrisano i upravljivo okruženje za razvijanje i 

izvršavanje aplikacija bezbedno u odnosu na tipove. 

.NET upravlja Framework upravlja svima aspektima vašeg programa: ono alocira 

memoriju za smeštanje podataka i instrukcija, odobrava ili ne odobrava odgovarajuće dozvole 

vašoj aplikaciji, pokreće i upravlja izvršavanjem aplikacije i upravlja realokacijom memorije za 

resurse koji više nisu potrebni. 

.NET Framework se sastoji od dve glavne komponente: zajedničkog vremena 

izvršavanja za jezike i biblioteke klasa .NET Frameworka. 

.NET Framework je dizajniran za meñujezičku kompatibilnost. Jednostavno rečeno, 

ovo znači da komponente .NET-a mogu meñusobno da deluju bez obzira uz kom podržanom 

jeziku su napisani izvorno. 

Aplikacija napisana u Microsoft Visual Basic .NET-u može da poziva biblioteku sa 

dinamičkim povezivanjem (DLL) napisanu u Microsoft Visual C#-u, koja zauzvrat može da 

pristupi resursu napisanom u upravljivom Microsoft Visual C++-u ili u svakom drugom jeziku 

.NET-a. 

Ova jezička meñusobna operativnost se proteže sve do puno objektno – orijentisanog 

nasleñivanja. Na primer, klasa Visual Basin.NET može da se izvede iz klase C#-a i obrnuto. 

Nezavisno od jezika ili okruženja u kome je napisan, svaki program se bavi radom sa 

podacima. U najjednostavnijem obliku, on može imati samo promenljive čije su početne 

vrednosti direktno dodeljene unutar aplikacije. 

Meñutim, kod složenijih programa, pod radom sa podacima se podrazumeva uzimanje 

podataka iz spoljašnjih izvora podataka, prikazivanje podataka korisniku, kao i mogućnost da 

korisnik dodaje, briše i menja neke od tih podataka, i da te izmene čuva i u originalnom izvoru 

podataka. Ovde objašnjavamo na koji način se mogu obaviti ti opšti zadaci pomoću 

Microsoftovog jezika C#. 

Kada je potrebno da se brzo pristupi velikoj količini podataka, jedino dobro rešenje je 

skladištenje tih podataka u relacionoj bazi podataka. Sistem za upravljanje relacionim bazama 

podataka (Relational Database Management System, RDBMS) je aplikacija koja nam 

omogućuje skladištenje podataka u tabelarnom formatu – relaciona baza podataka se sastoji 

od proizvoljnog broja tabela, koje su povezane tako da omogućuju skladištenje različitih ali 

povezanih podataka. Ove aplikacije mogu biti veoma snažne i veoma skupe, ali ja ću ovde 

koristiti Microsoft SQL Data Management Studio, koji se može instalirati besplatno uz Microsoft 

Visual Studio 2008. 

46/51


Glavni deo ove aplikacije cini pristupanje bazi podataka pomoću C#-a. Veći deo 

funkcionalnosti C#-a zavisi od klasa definisanih u .NET okruženju, a pristup podacima i rad sa 

podacima ne predstavljaju izuzetak. Zato je obezbeñen skup posebnih klasa koje su poznate 

kao ADO.NET. 

ADO.NET obezbeñuje jednostavnije i intuitivne klase i metode za uspostavljanje veze 

sa bazom podataka,uzimanje podataka (izvršavanjem SQL-ovih komandi ili uskladištenih 

procedura) i ažuriranje baze podataka. 

5.5. C# - programski jezik 

Kako je gore pomenuto ,C# je jedan od jezika koji služi za izradu aplikacija koje mogu 

raditi pod .NET CLR-om. On predstavlja evoluciju jezika C i C++ koju je kreirao Microsoft da bi 

se radilo sa .NET okruženje. 

U razvoju C#-a korišćene su mnoge prednosti drugih jezika, naravno uz otklanjanje 

njihovih mana. 

Razvoj aplikacija u jeziku C# je jednostavniji nego u C++, jer je sintaksa prostija. Pa 

ipak, C# je moćan jezik i postoji veoma mali broj stvari koje bi smo uradili u C++ pre nego u 

C#-u. 

Paralelne mogućnosti jezika C# onima naprednijim u C++-u, kao što je direktno 

pristupanje i manipulisanje sistemskom memorijom, može biti izvedeno jedino kroz kod koji je 

obeležen kao nesiguran. Ove napredne tehnike programiranja su potencijalna opasnost (odakle 

im i ime) zato što je moguće pristupiti memorijskim blokovima koji su kritični za sistem, a sve 

to potencijalno vodi ka katastrofi. 

S vremena na vreme kod u jeziku C# je malo razumljiviji od C++ koda. Jer je C# 

jezik sigurniji po pitanju dodele tipa promenljivim (za razliku od C++).To znači da ukoliko 

nekoj promenljivoj ili nekom podatku dodelimo odreñeni tip, on ne može biti zamenjen nekim 

drugim nevezanim tipom. 

Postoje stroga pravila kojih se moramo pridržavati prilikom konverzije tipova, što u 

suštini znači da ćemo često morati da napišemo više koda u jeziku C# nego u C++ da bismo 

izvršili iste zadatke. Ali iz toga možemo izvući i neku korist. Kod je robusniji i jednostavnije je 

otkloniti greške, odnosno .NET u svakom trenutku može odrediti kojem tipu pripada traženi 

podatak. 

C# je samo jedan od jezika koji omogućuju rad sa .NET razvojnim okruženjem, ali 

možda je i najbolji. Njegova prednost je u tome što je jedini napravljen od početka baš za .NET 

okruženje, pa samim tim i može biti vodeći jezik korišćen za verzije .NET-a namenjene drugim 

operativnim sistemima. 

Visual Basic.NET je, recimo napravljen tako da bude što sličniji svojim prethodnicima i 

stoga ne može se iskoristiti .NET biblioteku koda u potpunosti. Suprotno njemu, jezik C# je 

napravljen tako da može iskoristiti svaki deo biblioteke koda .NET okruženja koju ova može da 

ponudi. 

47/51


Kako je gore navedeno, jezik C# nema ograničenja u pogledu toga kakve sve 

aplikacije možemo napraviti. C# koristi okruženje i samim tim nema ograničenja u vezi sa 

mogućim aplikacijama. Pa ipak, pogledajmo koji su tipovi najčešće pravljenih aplikacija. 

� Windows aplikacije – To su recimo, aplikacije tipa Microsoft Office koje imaju 

izgled Windowsa i odlično se slažu sa njim, Ovo je uprošćeno korišćenjem 

modula Windows formulara unutar .NET okruženja, koji u stvari čini biblioteka 

kontrola (kao što su dugmad, palete alatki, meniji i tako dalje) koje nam 

koriste pri izradi Windows korisničkog interfejsa (UI- user interface). 

� Web aplikacije – Web strane koje možemo videti kroz bilo koji čitač .NET 

okruženje pruža veoma moćan sistem generisanja Web sadržaja i to dinamički, 

dozvoljavajući personalizaciju, sigurnost i još mnogo toga. Ovaj sistem se 

naziva Active Server Pages.NET (ASP.NET), a jezik C# možemo koristiti za 

izradu ASP.NET aplikacija uz pomoć Web formulara. 

� Web servisi – Predstavljaju nov i uzbudljiv način izrade raznovrstnih 

distribuiranih aplikacija. Koristeći Web servise preko Interneta možemo 

razmenjivati bilo koju vrstu podataka, koristeći prostu sintaksu, ne vodeći 

računa o tome u kom jeziku je napisana aplikacija niti na kom sistemu je 

postavljena. 

Bilo kom od ovih tipova može zatrebati pristup bazama podataka, što se postiže 

korišćenjem Active Data Objects .NET (ADO.NET) odeljka .NET okruženja. Mnogi od ovih 

resursa mogu biti iskorišćeni, kao što su alati za izradu komponenata na mreži, iscrtavanje, 

izvoñenje komplikovanih matematičkih zadataka i tako dalje. 

48/51


ZAKLJUČAK 

Ovaj mali Infromacioni sistem – Odbrane od grada je osmišljen i napravljen nakon 

zahteva Hidrometeorološkog zavoda, odseka za Odbranu od grada, kako bi se osavremenio i 

modernizovao postojeći sistem. 

Aplikacija je namenjena Radarskim centrima širom zemlje, i u potpunosti podržava sve 

postojeće načine na koje funkioniše Radarski Centar. Takoñe je i osmišljena jedinstvena baza 

podataka na teritoriji cele Srbije, koja će u mnogome pomoći prikazu aktuelnog stanja i jako 

brzom pristupu informacija. 

Prednosti ove aplikacije su pre svega savremen pristup i moderno dizajniran interfejs 

koji je prilagoñen u potpunosti korisnicima sistema. 

Korisnici ovog sistema su ovlašćeni zaposleni u Radarskom centru i samo oni mogu 

koristiti aplikaciju. Sistem je zaštićen šifrom i nije moguće pokretanje aplikacije izvan 

radarskog centra pa je time onemogućen neovlašćen pristup ovom informacionom sistemu. 

Prednosti ovog Informacionog sistema u odnosu na stariji je sama tehnologija koja se 

koristi i potpuno prilagodjen interfejs korisnicima sistema koji i sami mogu praviti izmene 

ukoliko su potrebne. 

Takoñe u starijem sistemu su se mnogi podaci razlikovali i morali su ručno da se 

unose, a nekima i nije bio omogućen pristup, pa se njima pristupalo preko nekog drugog 

izvora. 

U ovom sistemu je sve na istom mestu, što u mnogome olakšava pristup podacima i 

uvid u stanje u realnom vremenu. 

Za razvoj ovog Informacionog sistema korišćeni su sledeći softverski alati: 

� Microsoft Server 2005 – je jedan od najmodernijih baza podataka i svojim 

performansama omogućuje konstantan rad ovog sistema kao i sigurnosti 

podataka. 

� Microsoft SQL Management Studio – koji se koristi za prikaz, izmenu i 

evidentiranje delova baze podataka na najbolji mogući način kao deo Microsoft 

paketa. 

� Microsoft Visual Studio 2008 – kao jedan od najmodernijih razvojnih alata na 

tržištu i proizvod je jedne od najvećih kompanija Microsoft. Ima svoju široku 

primenu i pre svega veliku podršku prilikom grešaka i kvarova koji mogu biti 

prouzrokovani ovim Microsoft proizvodom. 

Informacioni sistem koji je napravljen i prezentovan je jedno od mogućih rešenja koje 

može biti implementirano u Radarski Centar. Aplikacija je samo jedan deo ovog sistema, i 

moguće je u potpunosti prilagoditi postojećem stanju u Hidrometeorološkom Zavodu Srbije. 

49/51


Cilj ovog završnog rada je da predstavi budućim vlasnicima i korisnicima sistema o 

mogućem načinu funkcionisanja jednog ovakvog sistema za Odbranu od grada radi što lakšeg 

prilagoñavanja novim tehnologijama i mogućnostima njegove povezanosti sa ostalim 

sistemima koje koristi Hidrometeorološki zavod Srbije. 

50/51


LITERATURA 

• Branislav Lazarevic, Zoran Marijanovic, Nenad Anicic, Sladjan Babarogic, “Baze 

podataka”, 2003. 

• Karli Watson, “C#, Od početka“, Beograd: CET Computer Equipment and Trade, 2002. 

• Alen Skot, “C#, Baze podataka“,Beograd: CET Computer Equipment and Trade, 

2003. 

• Metju A . Stoker, “Razvoj Windows Aplikacija alatima Microsoft Visual Basic.Net 

i Microsoft Visual C# . NET“, Beograd: CET Computer Equipment and Trade, 2003. 

Web stranica: 

1. „RHMZ, Republički hidrometeorološki zavod Srbije, Republika Srbija. “ 

http://www.hidmet.sr.gov.yu: 

2. „METEOROLOGIJA, Peta decenija protivgradne zaštite u Srbiji. “ 

http://www.planeta.org.yu/28/8%20meteorologija.htm 

51/51

preuzimanje - ITS-u

Create successful ePaper yourself

Delete template?

Save as template?