T1 2 Modeli UvodBP PDF

Miroslav Mihaljišin
PRIRUČNIK SAMO ZA INTERNU UPOTREBU
kompilacija sadržaja sa sajta razno.sveznadar.info i knjige Računarstvo i informatika 2.

Modeli i baze podataka
Sadržaj
Modeliranje i simulacija ................................................................................................................................. 1
1.1 Terminolgija: Šta je ustvari model .......................................................................................................... 1
1.1.1 Pojam sistema i realnog sistema ........................................................................................................... 1
1.1.2 Odnos modela, realnog sistema i teorije ............................................................................................... 2
1.1.3 Cilj modeliranja .................................................................................................................................... 3
1.1.4 Procedure modeliranja .......................................................................................................................... 4
1.2 Metodologija i klasifikacija modela ........................................................................................................ 4
1.3 Podjela modela na osnovu formalizma i detaljnosti ................................................................................ 5
1.1.1 Neformalni opis modela ................................................................................................................... 5
1.1.2 Formalni opis modela ....................................................................................................................... 5
1.1.3 Savršeni i referentni modeli .............................................................................................................. 5
1.4 Formalna podjela modela ........................................................................................................................ 6
1.4.1 Fizički modeli ................................................................................................................................... 6
1.4.2 Apstraktni modeli ............................................................................................................................. 7
1.4.2.1 Opisni (verbalni) modeli................................................................................................................ 8
1.4.2.2 Analogni modeli ............................................................................................................................ 8
1.4.2.3 Matematčki modeli ....................................................................................................................... 9
1.4.2.4 Konceptualni modeli...................................................................................................................... 9
1.4.2.5 Računarski i simulacioni modeli ..................................................................................................10
1.5 Simulacija ...................................................................................................................................................11
1.5.1 Šta je simulacija ...................................................................................................................................11
1.5.2 Modeliranje i simulacija ......................................................................................................................11
1.5.3 Životni ciklus simulacije: Koraci simulacionih procesa ......................................................................12
1.5.4 Objedinjeni jezik modeliranja – UML......................................................................................13
1.6 Simulacija dinamičkih sistema ...............................................................................................................14
1.6.1 Statički i dinamički sistemi..............................................................................................................14
1.6.2 Deterministički i stohastički sistemi ................................................................................................15
1.7 Vrste analize modela ..............................................................................................................................15
1.8 Razvoj modeliranja i simulacije .............................................................................................................16
1.9 Kratki pregled razvoja modela baza podataka ........................................................................................18
1.9.1 Davna istorija...................................................................................................................................18
1.9.2 Istorija: Vrijeme dokazivanja ..........................................................................................................18
1.9.3 Vrijeme stvaranja standarda ............................................................................................................18
1.9.4 Moderna vremena ............................................................................................................................19

2. Sistem za upravljanje bazom podataka – Uvod- .....................................................................................20
2.1 Šta su to baze podataka ..........................................................................................................................20
2.1.1 Sistem za upravljanje bazom podataka ...........................................................................................20
2.1.2 Podatak i informacija ......................................................................................................................21
2.1.3 Entiteti i atributi ..............................................................................................................................21
2.1.4 Domen atributa ...............................................................................................................................22
2.2 Arhitektura baze podataka i njeno predstavljanje šemama ....................................................................22
2.3 Jezici za upravljanje bazama podataka...................................................................................................23
2.3.1 Softverski paketi za rad s bazama podataka ...................................................................................24
2.3.2 Životni ciklus baze podataka ..........................................................................................................24
2.3.2.1 Analiza potreba ............................................................................................................................25
2.3.2.2 Modeliranje podataka ..................................................................................................................25
2.3.2.3 Implementacija.............................................................................................................................25
2.3.2.4 Testiranje .....................................................................................................................................25
2.3.2.5 Održavanje ...................................................................................................................................25
2.4 Apstrakcija i šeme za modeliranje baze podataka ..................................................................................26
2.5. Relacioni model ................................................................................................................................27
2.5.1 Modeli baze podataka .....................................................................................................................27
2.5.2 Vrste modela baza podataka ...........................................................................................................27
2.5.2.1 Ravni (tabelarni) model ...............................................................................................................28
2.5.2.2 Hijerarhijski model podataka .......................................................................................................28
2.5.2.3 Mrežni model podataka ...............................................................................................................28
2.6 Pojam relacije i relacione baze ...............................................................................................................29
2.6.1 Šema relacije: Relaciona tabela i Šema relacione baze ..................................................................30
2.6.2 Predstavljanje relacija i šema relacija .............................................................................................30
2.6.3 Osnovne osobine koje treba da ima relacioni model .....................................................................31
2.6.3.1 Zadatak: uvod u kreiranje relacionog modela ..............................................................................31
2.7 Kandidati za ključ i primarni ključ .........................................................................................................32
2.8 Veze kod relacionog modela baze ..........................................................................................................33
2.9 Kardinalnost entiteta ............................................................................................................................34
2.10 Dvanaest pravila koji određuju relacioni sistem (Je li Kod sujevjeran?) .............................................35
2.10.1 Sistemski tretman „NULL“ vrijednosti ........................................................................................36
2.10.2 Neprekidan pristup dinamičkom katalogu relacionog modela .....................................................36
2.10.3 Fizička nezavisnost .......................................................................................................................37
2.10.4 Logička nezavisnost ......................................................................................................................37
2.10.5 Integritetska nezavisnost ...............................................................................................................37
2.11 Tabelarna terminologija .......................................................................................................................38
Modeliranje i simulacija

1.1 Terminolgija: Šta je ustvari model

Model je približni prikaz sistema ili procesa koji služi za razumijevanje sistema, te njegovo mijenjanje ili
upravljanje njime.
Model je francuska riječ (modéle), koja se pojavljuje u sličnom obliku u većini evropskih jezika: njemački
modell, italijanski modello, španski modelo, ruski модель.
Originalno, riječ vuče korjene od latinskih riječi modellus tj. modulus (mjera, standard) i modus (način,
mjera).
Prema Rječniku Oxford 2012 model je: „Osoba ili predmet koja se smatra za izuzetan primjer nečega1“.
“Umanjena slika planiranog ili postojećeg objekta”
Webster New World Dictionary
“Matematički ili fizički sistem koji podleže specifičnim pravilima, a koristi se za razumijevanje fizičkih,
bioloških i društvenih sistema sa kojima je u određenoj analogiji”
McGraw-Hill Dictionary of Scientific and Technical Terms
U govornom jeziku ima više značenja, pa ćemo navesti neka:

1. Uzor, uzorak, obrazac.
2. Kalup po kojem se izrađuje neki predmet.
1. Osoba koja pozira umjetniku.
4. Predmet (najčešće odjevni ili ukrasni) načinjen samo u jednom primjerku; unikat.
Modeliranje (ili modelovanje) je proces korišćenja modela umjesto realnog sistema.
1.1.1 Pojam sistema i realnog sistema
Čak ni opšta teorija sistema (General systems theory) kojoj je pojam sistem polazni i bazični element, nema
jedinstvenu definiciju pojma sistema već nudi više definicija. Za našu analizu ćemo uzeti najjednostavniju
koja kaže:
Sistem je uređeni skup elemenata.
Kako postoje (često) i neuređeni sistemi možemo naglasiti da su neki objekti ili pojave sređeni: Sistem je
skup objekata (realnih ili apstraktnih) koji čine cjelinu, gdje je svaki element koji čini objekt, zavisan i ima
vezu sa najmanje jednim od preostalih elemenata, a svi zajedno grade i čine cjelinu koja postoji radi
određenog cilja ili zajedničke svrhe2.
Ako prihvatimo ovu definiciju sistem možemo simbolički predstaviti u obliku:
S= {E, V, F}
S - sistem;
E - skup elemenata sistema;
V - skup veza;
F- funkcija cilja sistema.
Realan svijet je izvor podataka za formiranje modela što je predstavljeno na Slici 1.1. Shodno ranijoj
definiciji sistema:
1
Originalno: a person or thing that is considered an excellent example of something
2
Zajednički cilj i svrha ne znači da mu svi elementi doprinose.
1
Realan sistem je uređen i međuzavisan skup objekata koji formiraju cjelinu.
Slika 1.1 odnos realnog svijeta, sistema i modela
1.1.2 Odnos modela, realnog sistema i teorije
Na osnovu iskustva i znanja, čovjek pomoću apstrakcije razvija model koji odgovara realnom sistemu. Nivo
apstrakcije (koji najčešće znači uprošćavanje) utiče na validnost modela, tj. na valjanost i uspješnost
predstavljanja realnog sistema preko modela.
Model treba da što vjernije predstavi stvarnost, ali istovremeno da ima izabrane samo elemente i
karakteristike sistema koje su značajne za realizaciju cilja modela (za projektovano istraživanje).
Slika 1.2 Teorija kao poveznica realnog sistema i modela
Model se ne može uspješno realizovati ako nema odgovarajuću teoriju koja ga opisuje. Teorija je
neophodan element koji povezuje model i sistem. Prije nastanka modela neophodno je formulisati teoriju.
Model je uprošćena i idealizovana apstrakcija realnosti (realnog sistema) koja ne obuhvata sve aspekte
realnog sistema, a realizuje se u određenoj okolini na osnovu teorije. Model3 je, dakle, praktično
predstavljena teorija, koji služi za razumijevanje nekog realnog sistema, te njegovo mijenjanje ili
upravljanje njime.
U ovom slučaju pod teorijom smatramo uopštene principe i iskaze koji su dobijeni posmatranjem sistema.
Znači u konkretnim podacima realnog sistema pronašli smo univerzalne principe: teoriju koja važi za model.
3
Ovdje smo na dvije uvodne stranice dali tri definicije modela. Ako vam se čini mnogo, postoji onoliko definicija
modela koliko i autora koji se bave modeliranjem. Jedna knjiga o ovoj temi počinje sa 25 definicija modela koje se
potom analiziraju i pravi sinteza od 5 predočenih definicija, koja objašnjava ovaj nesumnjivo interesantan i kompleksan
pojam. Mi se nadamo da vam je pojam modela intuitivno jasan, a da ćete pravu predstavu o modelu i modeliranju imati
na kraju ovog poglavlja.
2
Navedimo glavne elemente i osobine sistema koje ga određuju:

 elementi (komponente) sistema
 Granice sistema
 Struktura sistema
 Okolina sistema
 Veze sistema
 Cilj sistema
 Funkcije sistema
 Procesi
Projektovanje i analiza sistema znači definisanje svih ovih elemenata.

Vremenski slijed promjena stanja sistema naziva se proces. Procesi predstavljaju mehanizam pomoću kojeg
sistem izvršava svoje funkcije i ostvaruje ciljeve, te su glavna osobina sistema.
Na procese koji se dešavaju u sistemu i na stanja sistema utiču mnogobrojni faktori (od kojih smo glavne
nabrojali), pa je postavka univerzalne teorije koja bi dovela do nekog univerzalnog modela bespredmetna.
Takav pokušaj je dovođenje samog principa modela koji uprošćava stvarnost, do apsurda; zahtjevom za
kompleksnim i univerzalnim ali da bude jednostavno.
Pažnja treba da se fokusira na konkretnu prirodu problema i, zavisno od mogućih sredstava za njegovo
rješavanje, definiše logika i teorijska postavka sistema.
1.1.3 Cilj modeliranja
Modeliranje treba da omogući stvaranje jasne i realne predstave - vizuelizaciju sistema, tako da možemo da
ga „vidimo“ onakvog kakav jeste, odnosno onakvog kakavog želimo da ga realizujemo. Model treba da
omogući razumijevanje sistema, a time i bolju specifikaciju strukture i ponašanja sistema. Na osnovu
modela trebalo bi biti moguće definisati šablon-obrazac koji pomaže prilikom konstruisanja ili upravljanja
sistema.
Očigledno je da su mnogobrojni ciljevi korištenja modela, a mogli bismo reći da su 4 glavna:
1) korišćenje modela umjesto realnog sistema radi sticanja ili provjere određenog saznanja
2) mogućnost analize dobijenih rezultata koja treba da obezbijedi efikasnije uprav-ljanje realnim
sistemom
3) smanjenje troškova projektovanja i izrade realnog sistema
4) izbjegavanje opasnosti eksperimenta nad realnim sistemom
Različiti su zadaci na kojima se ostvaruju ovi ciljevi. Već i samo nabrajanje zadataka bi značilo nabrajanje
gotovo svih ljudskih, proizvodnih, strateških, marketinških (itd, itd...) problema.
Često se modeliranje pogrešno veže samo za izradu velikih sistema, jer i mali sistemi mogu imati koristi od
njega. Ipak, što je sistem kompleksniji to je veća važnost mode-liranja.
3
1.1.4 Procedure modeliranja
Elementarna procedura modeliranja realizuje se kroz 3 koraka:

1. definisati i obrazložiti svrhu modeliranja.
2. odrediti strukturu modela (projektovati dizajn modela).
3. kreirati model (obično pomoću matematičkog izraza).
U poglavlju 1.5.3 Životni ciklus simulacije ćemo se nešto detaljnije pozabaviti procedurama i koracima koji
omogućavaju implementaciju modela u procesu simulacije.
1.2 Metodologija i klasifikacija modela

Postoje različite metodologije modeliranja pa je moguća klasifikacija u odnosu na:
1. formalnu podjela modela prema formalnom opisu modela
2. metode modeliranja
3. formalizam i detaljnost
4. vrste promjenljive (analogni, digitalni, hibridni)
5. prirodu opsega vrijednosti promjenljivih modela
6. prirodu zavisnosti i opsega vrijednosti promjenljive ‘vrijeme’
7. način definisanja kauzalnosti ulaza i izlaza: determinizam
8. metode predviđanje budućnosti (statističke i metode teorije vjerovatnoće)
9. linearnosti (jednostavne i višestruke regresije)
10. itd...
Analiza svake od ovih klasifikacija zavisi od njene konkretne primjene (namjene modela i simulacije).
Klasifikacije omogućavaju da izaberemo pravi model za određen problem, ali često zbunjuju svojom
kompleksnošću. Pokušaćemo to izbjeći dajući samo dvije:
 podjelu modela na osnovu formalizma i detaljnosti
 formalnu klasifikaciju modela u odnosu na nivo apstrakcije i metode
Iste metode pojavljuju se u različitim klasifikacijama.

Bez obzira na klasifikaciju kojoj pripadaju, mi ćemo posebnu pažnju obratiti na matematičke, konceptualne i
računarske modele. Savremeno modeliranje je ustvari sin-teza više metoda, pa ćemo pokazati da se
računarski model realizuje konceptualno, tako da mu je podloga matematički model.
4
1.3 Podjela modela na osnovu formalizma i detaljnosti

1.1.1 Neformalni opis modela
Neformalni (ili slobodni) opis modela opisuje sistem tako da definiše:

 objekte – to su dijelovi iz kojih se sastoji model;
 opisne promjenljive – opisuju stanje u kome se objekat nalazi u nekom vremenskom trenutku;
 pravila interakcije objekata – definišu kako objekti modela utiču jedni na druge i na opisne
promjenljive u cilju promjena njihovog stanja.
On daje samo osnovne pojmove o modelu, zanemarujući (apstrahujući) sve ostale bez korištenja unaprijed
propisanih procedura i strukture.
To ima za posljedicu da neformalni model može biti:

1. nekompletan (ne sadrži sve situacije koje mogu da nastupe),
2. nekonzistentan (predviđanje dva ili više pravila za istu situaciju, što može dovesti do zabune i
kontradiktorne akcije), i
3. nejasan (kad nije precizno definisan redoslijed akcija).
Ovi problemi (1-3) se rješavaju pravilima i konvencijama u komuniciranju koji se nazivaju formalizmi pa se
i model koji se pridržava tih pravila naziva model sa formalnim opisom.
1.1.2 Formalni opis modela
Formalni opis modela opisuje sistem na nedvosmislen način tako da se obezbijedi preciznost i potpunost
koristeći se unaprijed definisanom strukturom i procedurama.
Omogućava i formalizovanje nekompletnosti, nekonzistentnosti i nejasnosti definišući stepene pouzdanosti.
Kod formalnog opisa modela, model se može procjenjivati i u odnosu na detaljnost, što znači s obzirom na
broj objekata i veza koje u sebe uključuje. Detaljnost se odnosi na odnos broja komponenti realnog sistema i
broja komponenti modela koji opisuju realni sistem (nivo apstrahovanja -opažajnost).
1.1.3 Savršeni i referentni modeli

Savršeni model je onaj model koji uključuje sve promjenljive i veze među njima kao u realnom sistemu pa
je samim tim apsolutno pouzdan i valjan: Za iste ulaze daje iste izlaze kao i realan sistem. Ovakvi modeli se
ne mogu praktično realizovati izuzev za ekstremno jednostavne i proste sisteme (za koje modeli nisu ni
potrebni).
Savršeni modeli su idealizacija stvarnih modela. Obično služe kao referentni modeli na osnovu kojih se
razvijaju praktični modeli.
Referentni model je skup smjernica i preporuka na osnovu kojeg se razvija (projektuje) neki sistem.
Najčešće je propisan od neke nadležne organizacije koja propisuje standarde kako treba da izgleda uređaj-
sistem. Ako proizvođač želi da proizvodi neki uređaj on treba da se pridržava propisanih pravila. Njegov
uređaj treba da zadovolji propisane procedure definisane referentnim modelom.
Jedan od primjera je OSI referentni mrežni model. OSI referentni model (Open Systems Interconnection) je
konceptualni model koji se koristi kao smjernica za razvoj uređaja i programa pri mrežnim
komunikacijama. To je opisni model koji je stvorila međunarodna organizacija za standardizaciju ISO
(International Organization for Standardization). Proizvođačima se propisuje skup standarda i tako
osigurava kompatibilnost i povezivanje među različitim mrežnim tehnologijama.
TCP/IP (Transmission Control Protocol/ Internet Protocol) su protokoli pomoću kojih se vrši praktična
implementacija OSI modela. Odnos OSI i TCP/IP predstavljen je na Slici 1.3. TCP/IP je model razvijen na
osnovu OSI referentnog modela.
5
Slika 1.3 Ilustracija koja pokazuje odnos OSI modela i

TCP/IP
gdje je OSI referentni model
preuzeto sa:
http://www.protocols.com/pbook/tcpip1/
1.4 Formalna podjela modela

Standardna klasifikacija metoda izrade modela, zasnovana na podjeli prema nivou apstrakcije i vrsti
modeliranja, predstavljena je na Slici 1.4.
Slika 1.4 Standardna klasifikacija modela
Pod terminom fizički misli se na materijalne (hemijska struktura molekula, model aviona), a klasa
apstraktnih modela predstavlja simboličke mentalne modele (koji mogu imati različitu reprezentaciju u
zavisnosti od metode predstavljanja: od verbalnog opisa preko analogije i matematičke analitike do
konceptualne predstave računarskim modelima i simulacijama).
1.4.1 Fizički modeli
Fizički model često se naziva i samo model, ali ako želimo da napravimo razliku u odnosu na druge vrste
(naročito konceptualni) naglasićemo da je riječ o fizičkom modelu.
Fizički modeli sistema predstavljaju srazmjerno umanjenu kopiju realnog sistema iz koga su izdvojene
bitne fizičke i funkcionalne karakteristike.
Objekt modeliranja može biti ekstremno mali (na primjer, atom) pa u tom slučaju fizički model predstavlja
uvećanje.
6
Slika 1.5 Odnos i interakcija fizičkog i apstraktnog modela
Mada je jasno (vidi 1.1.2 Odnos modela, realnog sistema i teorije i Sliku 1.5) naglasimo: I kod izrade
fizičkog modela se polazi od logičkog modela (apstrakcije), a rezultat je izrađeni fizički model.
Kada je definisan fizički model nekog fizičkog (realnog) sistema, idući korak bi bio stvaranje matematičkog
modela, koji predstavlja matematičku interpretaciju fizičkog modela, pomoću odgovarajućih fizičkih
zakonitosti, koje su predstavljene analitički.
Statički modeli zadržavaju uvijek iste karakteristike, dok se dinamički mijenjaju u zavisnosti od promjene
ulaza. Dinamički aspekti modela se fokusiraju na njegovo ponašanje, kreirajući model procesa u
vremenskom domenu.
Napomenimo da je korištenje fizičkih modela ograničeno troškovima i vremenom izrade.
1.4.2 Apstraktni modeli
Osnov apstrakcija je promišljanje i analiza (odnosno način izdvajanja nekih osobina i svojstava predmeta od
samog predmeta), pa se metode modeliranja mogu podijeliti prema načinu apstrakcije pri obavljanju i
prezentovanju analize.
Mentalni (misaoni) modeli su modeli nastali apstrakcijom. Predstavljaju apstrakciju koju stvara ljudski um.
Omogućavaju komunikaciju među ljudima, planiranje aktivnosti itd.
Na Slici 1.6 možete vidjeti strukturnu šemu ovog modela kao i osnovne elemente koji određuju mentalni
model i njegov odnos prema sistemu i realnom (stvarnom) svijetu. Ovaj model omogućuje donošenje odluke,
na osnovu unaprijed propisanih pravila i strategije i strukture koje model sadrži.
Slika 1.6 Strukturna šema mentalnog modela
7
1.4.2.1 Opisni (verbalni) modeli

Kod opisnog metoda, analiza sistema ili njegovih dijelova se vrši opisno, opisivanjem u vidu teksta.
Verbalni model je način predstavljanja mentalnih modela govornim jezikom. Uobiča-jeno se predstavlja u
pisanom obliku i spada u klasu neformalnih (vidi 1.4) modela.
Opisni modeli su široko primijenjeni i koriste se u svakidašnjim aktivnostima.

Osnovne mane ovog modela su ograničenost pri rješavanju složenih problema zbog mogućnosti različite
interpretacije i dvosmislenosti pri shvatanju opisa, kao i proiz-voljnost pri ocjeni značaja pojedinih faktora.
1.4.2.2 Analogni modeli

Analogni modeli su zasnovani na fizičkoj sličnosti i ekvivalenciji sa nekom od karakteristika fizičkog–
realnog sistema, gdje se putem analogije dolazi do rješenja problema.
Kao primjer koji ilustruje ovaj metod navešćemo metod elektronsko-hidrauličke analogije prikazan na Slici
1.7. Pošto je električna struja nevidljiva i procesi u elektronici se teško demonstriraju, različite elektronske
komponente su prikazane hidrauličkim ekvivalentima.
Slika 1.7 Analogija između hidrauličkog kola i elektronskog kola
Nadamo se da je vaše znanje iz mehanike i elektronike dovoljno da možete sami shvatiti i proanalizirati obje
šeme. Razmotrite analogiju hidrauličkog i elektronskog kola, tako da se uspostavi korelacija između
jednačina koje opisuju mehaničke (hidrauličke) i elektronske procese.
Više detalja o analogiji na: https://sr.wikipedia.org/wiki/Metod_hidrauli%C4%8Dke_analogije.
8
1.4.2.3 Matematčki modeli

Matematičkim modelom se pomoću matematičkih postupaka i operacija, na osnovu određenih podataka,
opisuje ponašanje sistema. Matematički modeli pripadaju klasi apstraktnih modela, a primjenjuju se u
naučnim i inženjerskim disciplinama.
Metodologija i struktura matematičkog modela je različita i određena prirodom realnog sistema i cilja
matematičkog modeliranja.
Matematičko modeliranje počinje definisanjem procesnog prostora P u kojem se odvija neki proces.
Posmatrani procesi mogu biti složene prirode i osnova pristupa matematičkog modeliranja je sažimanje i
apstrakcija istraživanih procesa. Na određenom nivou modela u istraživanom procesnom prostoru se definišu
dva osnovna skupa veličina modela, skup ulaznih veličina X i izlaznih veličina Y.
Osnov matematičkog modela M je određivanje matematičko-statističkih relacija koje povezuju skup
izlaznih veličina Y (koje su zavisne veličine), sa skupom nezavisnih ulaznih veličina X.
Slika 1.8 Razdvajanje skupova ulaznih i izlaznih veličina kod matematičkog modela
Na Slici 1.8 dat je prikaz matematičkog modela M u kome se procesni prostor P razdvaja u skupove ulaznih
veličina X i izlaznih veličina Y.
Definisanje ovih skupova se realizuje na osnovu analize realnog sistema koji se želi modelirati i kauzalnosti
između veličina X koje su uzrok promjena i zavisnih veličina Y koje su posljedica ovih promjena.
Definisanje skupova {X,Y} zahtijeva (bar) dva ekspertna nivoa
a) poznavanje procesa obuhvaćenih procesnim prostorom u realnom svijetu (eksperta za realan
problem)
b) poznavanje teorije (eksperta koji može da matematički opiše odgovarajućim jednačinama realan
problem)
Razmislite o dvije naoko kontradiktorne činjenice:
Isti procesni prostor može se predstaviti različitim modelima.
Isti model može se koristiti za predstavljanje različitih procesa.
1.4.2.4 Konceptualni modeli

Konceptualni modeli nastaju na osnovu strukture logike rada sistema. Zovu se još i strukturni modeli
pošto u grafičkom obliku prikazuju strukturu i pomoću nje omogućuju modeliranje. Predstavljaju osnovu
za izradu računarskih modela.
Struktura modela se uobičajeno predstavlja grafički dijagramom entiteta i veza ili UML4 dijagramom klasa,
kao što je prikazano na Slici 1.9., a što ćemo nešto detaljnije komentarisati u 1.5.4.1.
Konceptualni model sadrži:

1. Strukturu podataka – statički opis stanja realnog svijeta
2. Operacije – izražavaju dinamiku iz realnog svijeta
3. Ograničenja (constraints) – Ograničenja u modelu koja su posljedica ograničenja iz realnog svijeta
4
UML (Unified Modeling Language) standardizovani jezik za modeliranje, služi za vizue-lizaciju, specifikaciju,
konstruisanje i dokumentovanje softverskih sistema. vidi više 4.8.4.1.
9
Slika 1.9 Primjer konceptualnog modela koji koristi XML5 i UML

izvor: https://www.researchgate.net/figure/229424210_fig2_Figure-2-modeling-level-3-in-Eduweaver-left-activity-description-in-
IMSLD-right
Jedna od namjena konceptualnog modela je automatsko generisanje programa i pomoć u razvoju programa.
1.4.2.5 Računarski i simulacioni modeli

Simulacioni modeli su svi oni modeli gdje se „nešto“ predstavlja pomoću „nečeg drugog“. Pojam simulator
označava uređaj u kome se vještački stvaraju takve prilike kakve postoje u realnom svijetu. Ako se
simulacija obavlja na računaru, simulacioni modeli predstavljaju računarske modele.
Računarski modeli su prikaz konceptualnih modela u obliku računarskih programa6 korišćenjem
programskih jezika. Računarski model je program koji generiše ponašanje simuliranog sistema. Objekti
računarskog modela su opisani promjenljivim (ulazno/izlaznim varijablama) i njihovim osobinama
(atributima).
Kod kompleksnijih sistema moguće je primijeniti modularni princip, koji olakšava projektovanje sistema
na način da se prvo projektuju moduli a potom vrši njihovo povezivanje. Modularnost pojednostavljuje i
ubrzava proces modeliranja, jer omogućava timski rad i parcijalno rješavanje problema, ali krije i
mnogobrojne zamke, sa čuvenim pitanjem: Svi moduli rade, a sistem ne radi. Zašto?
Zasad ćemo ukazati na osnovni uzrok kako je to moguće. Odgovor je u definiciji sistema: Sistem ne postoji
bez uticaja okoline (vidi Sliku 1.1).
Simulacioni modeli se dijele prema dva kriterija: prema vrsti promjenljivih u modelu i prema načinu na koji
se mijenja stanje modela u vremenu.
Podjela prema vrsti promjenljivih u modelu:

 Deterministički modeli su modeli čije se stanje može predvidjeti, tj. novo stanje je potpuno
određeno prethodnim.
Primjer: stanje sistema Sn se mijenja pod uticajem aktivnosti A, determinističkog trajanja od n sekundi, u
stanje Sn+1.
Primjer simulacije bilijara: za poznatu brzinu i ugao može se predvidjeti putanja kugle.
 Stohastički modeli čije se ponašanje ne može predvidjeti, ali se mogu predvi-djeti vjerovatnoće
promjena stanja.
Primjer: stanje Sn se pod uticajem aktivnosti A može promijeniti u stanja S’n+1, S’’n+1 ili S’’’n+1 ( es prim, es
drugo, es treće) prema uniformnoj raspodjeli vjerovatnoća stanja.
Ovakav model se može koristiti za simulaciju igara na sreću, ili sportskih simulacija kao što je tenis.
5
XML EXtensible Markup Language - jezik za označavanje podataka. Nastao je na osnovu ideje da se stvori jedan
jezik koji će biti čitljiv i ljudima i računarskim programima.
6
možda bi preciznije bilo reći softvera i softverskih paketa
10
Podjela prema načinu na koji se stanje modela mijenja u vremenu:

1. Diskretni modeli u kojima se stanje sistema mijenja samo u pojedinim tačkama u vremenu, nema
kontinualne promjene stanja. Te promjene se nazivaju događaji.
2. Kontinualni modeli u kojima se promjenljive stanja mijenjaju kontinualno u vremenu. Na
digitalnim računarima se ne mogu izvoditi kontinualne promjene veličina već se moraju
aproksimirati skupom diskretnih vrijednosti.
3. Kontinualno - diskretni modeli sadrže i kontinualne i diskretne promjenljive.
1.5 Simulacija
1.5.1 Šta je simulacija
Simulacija je prema Šenonu (Shanon, 1975) „proces dizajniranja modela realnog sistema i provođenje
eksperimenata sa tim modelom radi razumijevanja ponašanja sistema ili evaluiranja različitih strategija (u
okviru granica zadatih kriterijumima ili setom kriterijuma)“.
Slika 1.10 Osnovni elementi koji čine simulaciju

Da pojasnimo i naglasimo:
Simulacija je proces koji uspostavlja vezu između modela i računara. Simulacija je eksperimentalna metoda
koja omogućuje proučavanje stvarnog procesa pomoću njegovog modela.
Model prikazuje statičko stanje sistema, odnosno stanje u jednom momentu. Simulacija pretpostavlja
praćenje stanja sistema u vremenu. To znači da je za izvođenje simulacije potrebno definisati vremenski
slijed: vremenski hodogram koji određuje hronologiju stanja sistema.
Modeliranjem izrađujemo model, a simulacijom pratimo ponašanje modela.
1.5.2 Modeliranje i simulacija
U literaturi i praksi često se koristi termin modeliranje i simulacija (engl. Modeling and simulation
(M&S)), koji objedinjuje ova dva pojma što je dijelom opravdano jer:
 Realni sistem opisuje se modelom.
 Stanje sistema predstavljeno je stanjem modela koje je određeno varijablama stanja.
 Model se definiše simulacijskim jezikom.
 Nakon izrade modela pristupa se simulaciji koja se odvija izvođenjem posebnog programa -
simulatora7 - na računaru.
 Rad simulatora je upravljan modelom.
Modeliranje i simulacija predstavljaju složenu aktivnost koja sadrži tri elementa:

1. Realni sistem
2. Model
3. Računar
7
Ovdje pod simulatorom podrazumijevamo program u izvršenju, pa bi mogli napraviti analogiju između programa i
procesa (kao programa koji se izvršava) i modela (statički) i simulacije (dinamički)
11
Podsjećamo:
Realni sistem koji je izvor podataka, može se predstaviti u obliku jednačine y=f(x), kojom se definiše
model.
Modeliranje je proces kojim se uspostavlja veza između realnog sistema i modela.
U računarstvu, model predstavlja skup instrukcija (program) koje služe da se generiše ponašanje
simuliranog sistema. Model ima svoje objekte koji su opisani promjenljivim i njihovim atributima.
Povezivanje modela predstavlja pripremnu fazu simulacije u kojoj se vrši priprema i obezbjeđuju potrebni
resursi za proces simulacije (kao što je obezbjeđivanje memorije, definisanje redoslijeda budućih koraka u
smislu prioriteta, provjera eventualno loše unesenih ulaznih podataka i slično).
Nakon povezivanja pristupa se stvarnoj simulaciji.
U fazi stvarne simulacije vrši se sukcesivno izračunavanje prelaznih stanja i izlaza iz sistema. Obično se
proračun provodi i prikazuje u diskretnim vremenskim intervalima koji mogu, ali i ne moraju biti jednoliki.
Izbor intervala se definiše posebnim „rješavačem jednačina“ (solver).
1.5.3 Životni ciklus simulacije: Koraci simulacionih procesa
Životni ciklus simulacije ćemo predstaviti nizom koraka koji

opisuju pojedine faze rješavanja problema. Osnovni koraci
simulacionog procesa prikazani na Slici 1.11 su sljedeći:
1. Definicija cilja istraživanja-simulacione studije;
2. Identifikacija sistema (opis komponenata, način rada, veza sa
okolinom, formalni prikaz sistema);
1. Prikupljanje podataka o sistemu i njihova analiza;
4. Izgradnja simulacionog modela (stvaranje konceptualnog
modela koji adekvatno opisuje sistem);
5. Izgradnja simulacionog programa (izbor softverskog paketa,
ili programskog jezika i stvaranje simulacionog programa);
6. Verifikacija simulacionog programa (da li program vjerno
predstavlja model);
7. Validacija (vrednovanje) simulacionog modela Vrlo značajna
karika koja najčešće dovodi do ponovnog projektovanja modela.
Validacija je provjera sličnosti ili preklapanja izlaznih
vrijednosti iz modela i eksperimentalnih podataka.
8. Planiranje simulacionih eksperimenata i njihovo izvođenje;
9. Analiza rezultata eksperimenata (najčešće statistička analiza);
10. Zaključci i preporuke.
Ove korake su definisali formulisali Law i Kelton 1982. godine,

Law AM, Kelton WD. Simulation modeling and analysis. New
York: McGraw-Hill, 1982 izvor INTRODUCTION TO MODELING
AND SIMULATION, Anu Maria,State University of New York at
Binghamton, Department of Systems Science and Industrial Engineering
Binghamton, NY 13902-6000, U.S.A.
Slika 1.11 Koraci simulacionog procesa
12
1.5.4 Objedinjeni jezik modeliranja – UML

Kod konceptualnog modeliranja smo na Slici 1.9 dali primjer UML šeme objektno-orijentisanog sistema.
Daćemo nekoliko razjašnjenja koje će vas uvesti u svijet modela baziranih na klasama i objektno-
orijentisanom pristupu.
Objektno-orijentisani (OO) razvoj predstavlja proces, ideju (apstrakciju) i problemsku specifikaciju
(formalni opis modela) u formi objektno-orijentisanog programa koji se sastoji od niza objekata koji
komuniciraju jedni sa drugima. Objekti se kreiraju kao klase koje su definisane u izvornom kodu programa.
UML je pogodna notacija za OO analizu i dizajn. Realizovan je kao korisnički grafički jezik pogodan za
vizuelizaciju, specifikaciju, konstruisanje i dokumentovanje modela.
Postoje tri osnovna elementa UML modela, a to su:
1. Gradivni blokovi
2. Pravila za povezivanje gradivnih blokova
3. Opšti mehanizmi koji se primjenjuju u UML-u
Gradivni blokovi UML-a su: objekti-stvari (osnovni entiteti predstavljeni kao apstraktni objekti), veze-
relacije koje povezuju objekte i dijagrami koji grupišu interesantne skupove povezanih objekata.
UML omogućava konstruisanje preglednih šema (vidi Sliku 1.9) koje modeliraju sistem opisujući njegov
koncept, npr. proces poslovanja i funkcije sistema i konkretne stvari koje definišu i opisuju sistem, npr.
klasne tipove, domene, šeme baza podataka, softverske komponente.
Slika 1.12 Osnovne kategorije korisnika UML-a

Postoje različite kategorizacije korisnika UML-a i one su obično domenski grupisane prema pravima
pristupa određenim blokovima i mehanizmima.
Osnovne kategorije korisnika koji koriste UML-a su: sistem-projektanti i krajnji korisnici. U zavisnosti od
kompleksnosti sistema mogući korisnici su razvojni inženjeri (koji mogu da vrše izmjene programa),
kontrolori kvaliteta (provjeravaju strukturu i ponašanje sistema), tzv. bibliotekari (zaduženi za kreiranje i
katalogizaciju objekata i tipova sistema), itd. kao što je predstavljeno na Slici 1.12.
13
1.6 Simulacija dinamičkih sistema

Za simulaciju dinamičkih sistema koriste se matematički modeli koji analitički vrše optimizaciju procesa.
Matematički modeli koriste nekoliko vrsta optimizacije procesa koje ih opisuju, od kojih su najznačajniji:
 Nelinearno optimizovanje - Koristi se u kontinuiranom optimizovanju, a primjenjuje se za traženje
optimalne raspodjele, odnosno pri traženju najpovoljnijih rješenja
 Račun vjerovatnoće
 Prognoziranje optimuma
 Matematička statistika
Navešćemo osnovne strukture koje određuju matematičke modele:

- jednačine regresijskog pravca (najjednostavnije aplikativno primjenjive u Excel-u),
- regresijski polinomi i regresijski modeli,
- obične diferencijalne jednačine,
- parcijalne diferencijalne jednačine,
- multivarijantni linearni regresijski modeli (MIMO)
- autoregresijski linearni modeli (MISO)
- neuronske mreže,
- modeli neizrazite logike,
- stohastički modeli, itd.
Pošto je očigledno da su ovo vrlo zahtjevna znanja, mi ćemo praktičan rad nastaviti na dosta provizornim i
neformalnim temeljima, koji su dovoljni tek za početne korake u modeliranju i simulaciji.
1.6.1 Statički i dinamički sistemi
Statički modeli opisuju sisteme kod kojih vrijeme ne utiče na ponašanje sistema. Dinamički modeli opisuju
ponašanje sistema u vremenu prateći stanja sistema preko vrijednosti različitih veličina koje se odnose na
pojedine elemente modela.
Pojednostavljeno, dinamički sistemi prate fenomene koji se privremeno mijenjaju u realnom sistemu.
Promjena vrijednosti neke osobine objekta se povezuje sa vremenom. Npr. veličine (kao što su brzina, težina,
brojnost i slično) zavise od vremena. U tom slučaju je model koji povezuje veličinu i vrijeme dinamički.
U slučaju nekih društvenih ili prirodnih fenomena (kao što su npr. porast populacije ili industrijske
proizvodnje) moguće je planirati i predvidjeti budućnost kreiranjem i praćenjem dinamičkih modela.
14
1.6.2 Deterministički i stohastički sistemi
Deterministički simulacioni modeli su oni kod kojih su sve promjenljive stanja determinističke veličine, a
stohastički su oni kod kojih je bar jedna promjenljiva slučajna veličina i u tom slučaju govorimo o
modelu vjerovatnoće.
1.7 Vrste analize modela

Analiza modela može se obaviti korišćenjem mnogobrojnih metoda, a mi ćemo predstaviti 4 glavne:
1. Šta-ako (What-if) analiza

Na realizovanom modelu korisnik mijenja jednu ili više nezavisnih (ulaznih) varijabli, i posmatra kako se
mijenja zavisna (izlazna) varijabla.
Primjer: analiza rizika, najbolje je ako se obavlja simulacijom na način da se nezavisne varijable mijenjaju na
slučajan način koristeći neku od distribucija (recimo Monte-Karlo). Ova metoda je direktno dostupna iz
Excel-a, vidi Sliku 1.11.
Slika 1.13 Poziv Scenario menadžera iz Excela
Scenario menadžer (Scenario Manager) omogućava da se analiziraju sve moguće vrijednosti jedne funkcije
kada se promijeni jedan parametar.
2. Traženje cilja (Goal seeking ili How can)

Kod ove analize kao polazište se koriste algoritmi sa pretraživanjem unazad (Backtracking algoritmi).
Korisnik zadaje ciljnu vrijednost zavisne varijable, i traži da se mijenjaju vrijednosti nezavisnih varijabli sve
dok se ne dostigne ciljna vrijednost zavisne varijable.
Primjer: Želimo postići profit od 10.000 KM, i zadamo da se mijenja cijena, dok se ne pronađe cijena koja
daje toliki profit.
Ovo takođe pripada standardnom Excel arsenalu (vidi Sliku 1.13)
3. Analiza osjetljivosti
Ispituje se kako promjena jednog parametra (nezavisne/ulazne varijable) utiče na funkciju cilja (zavisnu
varijablu). Obično se izražava procentualno.
Primjer: ako se mijenja cijena, posmatra se kako ona utiče na promjenu profita.
4. Optimizacija
Optimizacija je metod određivanje ekstrema (minimuma ili maksimuma) realne funkcije cilja promjenama i
izborom jedne ili više nezavisnih varijabli uz zadana ograničenja.
Primjer: Treba optimizovati (pronaći maksimalni) profit, ako su zadane cijene proizvoda, količine, troškovi,
a ograničenja su raspoloživi kapacitet mašina i ljudi, te potražnja.
Kreiranje optimizacionih modela obično se rješava metodama linearnog programiranja, gdje se definiše:
Funkcija cilja (šta se želi optimizovati), te da li se želi pronaći minimum ili maksimum
Koje su varijable odlučivanja – koje su ulazne varijable koje će se mijenjati u modelu
Ograničenja – funkcije i konstante.
15
1.8 Razvoj modeliranja i simulacije

Osobina koja određuje ljude kao vrstu: mišljenje, je osnov za kreiranje misaonog mo-dela; pa se može reći
da izrada „nekakvih“ modela postoji oduvijek: Crteži pećinskih ljudi su način na koji su oni predstavljali
svijet.
Hermann Schichl, u svom radu Models and History of

modeling, kao prvu apstrakciju koju možemo nazvati
modelom navodi broj i veže ga za 30000 godina prije
Hrista. U istom radu kao prve modele upotrebljive u
praksi navodi Astronomske modele kalendara nastale 3-
4000 godina prije Hrista, paralelno na područjima današnje
Indije, Vavilona i Egipta. Ovi modeli su se koristili u
planiranju sjetve.
Dalji razvoj modeliranje doživljava sa razvojem
matematike u staroj Grčkoj, gdje se Euklidovi Elementi
mogu smatrati prvom matematičkom teorijom koja se
primjenjivala u praksi.
Primjer modela koji je promijenio shvatanje svijeta je
Keplerov (Johannes Kepler 1571. -1630.) model Sunčevog
sistema iz 1596. godine (vidi Sliku 1.26), koji je, kad se na Slika 1.26 Keplerov model preuzet iz knjige Istorija
njega primijene Njutnova i Ajnštajnova mehanika i kosmosa
(Mysterium Cosmographicum) izvor Wikipedia
principi, važeći i danas.
Promjena principa izrade modela se umnogome može vezati za razvoj matematike i njene primjene u
elektronici i računarstvu, pa bi razrada ove teme podrazumijevala razradu misli značajnih matematičara od
Lajbnica (Gottfried Wilhelm Leibniz 1646.- 1716.), preko Bula (George Boole, 1815.- 1864.) Kantora
(Georg Ferdinand Ludwig Filip Kantor 1845.-1918.) i Rasela (Bertrand Arthur William Russell 1872. -
1970.), do Nojmana (John von Neumann 1901. - 1957.) i Tjuringa (Alan Mathison Turing 1912.-1954.), da
nabrojimo samo najznačajnije.
Svakako je interesantan primjer Teslinog modela daljinski upravljanog čamca koga je demonstrirao 1898.
godine. Ovim modelom se pomoću električnih signala bežično upravljalo na daljinu, a originalnu prijavu
Teslinog patenta ovog modela možete vidjeti na Slici 1.27. Ovaj model je bio daleko ispred svog vremena i
sa pravom se može smatrati pretečom modernih sistema automatske regulacije.
Sredinom XX vijeka sa pojavom elektronskih računara modeliranje doživljava procvat i počinje njegova
prava primjena u modernom smislu.
Slika 1.27 Teslin model daljinski upravljanog čamca

(kopija dijela originalne šeme iz Tesline prijave Patentnom birou izvor http://iqnova.com/)
16
Prvo značajno modeliranje na računaru obavljeno je u sklopu projekta Menhetn (projekt razvoja atomske
bombe). Napravljen je model kretanja neutrona pri lančanoj reakciji kojeg su razradili Ulam (Stanisław
Marcin Ulam 1909. -1984.) i Nojman. Zbog tajnosti projekta detalji nisu bili šire dostupni javnosti.
Tek naknadno, kad su 1949. Ulam i Metropolis (Nicholas Constantine Metropolis 1915.- 1999.) objavili
zajednički rad The Monte Carlo method, ovaj metod počinje da se značajnije primjenjuje i njegova
popularnost raste. Ovaj metod je odranije bio poznat, a Ulam ga je unaprijedio i dao mu ime Monte Karlo (pa
smo ga i mi kao takvog dijelom obradili, (1.6.3).
Pedesetih godina su razvijeni mnogobrojni modeli, posebno u vojnoj i avio industiji.
Šezdesete godine dovode do popularizacije računarskih modela i simulacija koji se koriste u „trci u
svemiru“, a u javnosti su popularisane kroz Apolo program. Projektant modela je morao da poznaje
arhitekturu računara i procese koje želi simulirati.
Sedamdesetih godina računari postepeno iz domena vojne industrije lagano prelaze u područje velikih
industrijskih sistema, pa se počinje sa simulacijom ne samo kompleksnih proizvodnih sistema i uređaja, već
se simuliraju i ekonomski, društveni ali i biološki i ekološki sistemi.
Napredovanje tehnologije osamdesetih godina dovodi do moćnog i jeftinog hardvera, jeftinih PC
konfiguracija i jeftinih CNC (programski upravljanih) mašina. U fabrikama se masovno koriste proizvodi čiji
modeli su prethodno testirani i simulirani na računarima.
Devedesetih godina se u praksi primjenjuju metode modeliranja koje u sebe uključuju i integrišu
kompleksne sisteme računarskih mreža i vještačke inteligencije.
Pad cijena računara omogućio je stvaranja alata za kućnu primjenu (tačnije za primjenu na PC računarima),
kakvi su Matlab, Mathematica, AutoCAD, OrCAD, Space, ArchiCad,… koji u sebi integrišu kompletno
crtanje/modeliranje te produkciju i proizvodnju 2D i 3D modela. 3D printeri su omogućili revoluciju u izradi
modela i prototipova integracijom CAD dizajna (Computer-aided Design).
Danas je obavezno da proizvodni proces započne izradom 3D CAD modela, tj. virtualnog prototipa
proizvoda.
Slika 1.28 Integracija 3D printera i softvera za modeliranje
Moderna ekonomija tvrdi da je proizvod sve ono što se može ponuditi na tržištu, pa shodno tome
modeliranje obuhvata i ekonomske odnose. Naše primjere Excel-a shvatite kao početne korake u tom
domenu.
Današni trendovi modeliranja su zasnovani na agentima (Agent-Based Modelling; ABM modeliranje) i
konceptu vještačke inteligencije.
17
1.9 Kratki pregled razvoja modela baza podataka
1.9.1 Davna istorija
Prva masovna automatska obrada podataka desila se davne 1882. godine u SAD-u. Te godine je
obavljen popis stanovništva. Herman Holerit (vidi Sliku 2.27) je napravio i prodao statističkom
birou SAD-a (gdje je bio zaposlen) mašinu koja je mogla da automatski obrađuje bušene kartice.
Koncept i ideja su bili jednostavni, svaki stanovnik SAD-a je predstavljen nizom od 80 karaktera
(ime, godište, itd) koji je bio „poravnat“ praznim prostorom (svi podaci su uniformno bili iste
dužine).
Hiljade kutija punih bušenih kartica činile su prvu
bazu podataka.
Podatke je obrađivala elektromehanička mašina sa
senzorima. Ova mašina je mogla da obradi oko 100
kartica u minuti (a svaka kartica je imala 12 redova sa 80
karaktera). To je dovelo do nevjerovatnog skraćenja
Slika 2.27 Herman Hollerith (1860 – 1929) i obrade rezultata popisa. Rezultati su bili poznati već
njegova mašina za obradu bušenih kartica poslije mjesec dana od završetka popisa, umjesto nakon
desetak godina što je bila ranija praksa.
1.9.2 Istorija: Vrijeme dokazivanja
U narednih pola vijeka se od tehnologije elektromehaničkih uređaja i releja, preko elektronskih

cijevi i tranzistora stiglo do integrisanih kola i relativno jeftinih računara. Tehnologija izrade
računara je napredovala, ali od prvobitnog koncepta zasnovanog na tabelarnom modelu i bušenoj
kartici dugo vremena se nije odustajalo.
Tek 1951. (opet za potrebe popisa stanovništva) firma Remington Rand napravila je prema dizajnu
Mauchly-a i Eckert-a UNIVAC I (Universal Automatic Computer), prvi komercijalni računar koji
je koristio magnetne trake. UNIVAC je prvi serijski proizvođen računar.
Ne samo kao zanimljivost, spomenućemo Grace Hopper (1906-1992) ženu sa činom
kontraadmirala, koja je učestvovala u razvoju UNIVAC-a, a bila je glavni tvorac pomalo
zaboravljenog Cobol-a. Smatra se da je još uvijek više od pola poslovnog svjetskog softvera
realizovano u Cobol-u.
Sistemi zasnovani na datotekama su imali dominantnu ulogu i nisu mogli da se koriste van
strogo definisanog okruženja. Za razliku od modernih sistema ovi sistemi su bili direktno
povezani na bazu. Korišćeni su uglavnom u vojne svrhe ili kod velikih projekata, od kojih je
sigurno najpoznatiji Apollo. Ovaj period može se smatrati periodom u kome je dokazana
sposobnost računarskih sistema da upravlja-ju ogromnim količinama podataka smještenih u
namjenski strukturisane datoteke. Umjesto termina baze podataka koristio se termin banke
podataka.
1.9.3 Vrijeme stvaranja standarda

Krajem šezdesetih godina XX vijeka dolazi do koncepcijskih promjena u dizajniranju i obradi
podataka. Iz tog perioda potiče i termin baza podataka: 1963. je pod pokrovi-teljstvom Društva za
razvoj sistema (System Development Corporation) održan simpozijum sa naslovom Razvoj i
upravljanje računarsko-centralizovanom bazom podataka - Development and Management of a
Computer-centered Data Base.
Iz tog vremena su i prvi sistemi upravljanja bazama podataka razvijeni na principima
hijerahijskog modela kojeg je prihvatio IBM.
18
Radna grupa DBTG (Data Base Task Group) američke organizacije CODASYL (Conference On
Data Systems Languages) 1959. prezentuje i standardizuje mrežni model za obradu podataka.
Autor mrežnog modela je bio Čarls Bakman

(Slika 2.28). Bakman se na-stavio baviti
bazama podataka i smatra se da je on razvio
prvi navigacioni sistem za upravljanje bazama
(Integrated Data Store, IDS). Bakman je
kreirao i prvu višeprogramsku aplikaciju koja
je omogućavala online pristup bazi podataka
Edgar Frank "Ted" Codd (1923 – Charles Bachman (rođen još 1965. Dobitnik je Tjuringove nagrade za
2003) Engleski matematičar i 11.12.1924) američki
računarski naučnik računarski naučnik 1973. godinu, a 2015. dobio je prestižno
Slika 2.28 Kod i Bakman: Dvojica ljudi koji se smatraju priznaje za neprocjenjiv doprinos u oblasti
tvorcima modernih baza podataka sistema baza podataka od Muzeja istorije
računarstva (Computer History Museum).
IBM je tih godina bio apsolutno dominantan, pa nije ni čudo što je velik broj ideja osmišljen i
realizovan u ovoj kompaniji. Kao velik i gotovo monopolski sistem IBM je bio dosta konzervativan
i sporo je prihvatao nove ideje.
Edgar Frank Kod (Edgar Frank Codd), direktor IBM-ovog razvojnoj centra iz San Hozea,
1970. predlaže novi koncept koji je nazvan relacioni model podataka. U to vrijeme njegove ideje
su smatrane čisto akademskim i praktično neprimjenjivim jer nije bilo jasno kako bi računar
mogao uspješno i efikasno da obrađuje tabele i relacije, umjesto u praksi provjerenog sistema
datoteka i mrežnog modela.
U početku je IBM odbio da implementira relacioni model, ali Kod je nastavio da uporno promoviše
svoje ideje što je dovelo do razvoja najuspješnijeg modela baza podataka: relacionog modela.
Dobio je Tjuringovu nagradu 1981. i od tada ustvari počinje dominacija relacionog modela.
Kod nije samo izmislio termin OLAP (Online Analytical Processing) već je i tvorac
višedimenzionih upita koji su osnov ove tehnike obrade podataka.
Tvorac SQL-a je Čemberlin (Donald D. Chamberlin američki naučnik rođen 1944). SQL je
promovisan 1972. a nastao je u istoj IBM-ovoj istraživačkoj laboratoriji gdje je Kod definisao
relacioni model. Kasnije se Čemberlin aktivno uključio u rad W3C konzorcija i smatra se jednim od
ljudi koji su definisali XML.
1.9.4 Moderna vremena

Pred kraj prošlog vijeka se programiranje u svim domenima, pa i kod baza podataka, okreće prema
objektu. Objektno-orijentisano programiranje postaje dominantno.
Značajne novine donosi XML koncept koji pokušava da prevaziđe tradicionalnu podjelu između
dokumenta i podatka. XML baze su naročito pogodne za korišćenje na internetu (HTML i XML se
izuzetno dopunjuju) i za rad sa polustrukturiranim podacima.
Razvoj interneta dovodi do popularizacije multimedijalnih sadržaja, pa nastaju i multimedijalne
baze i sistemi za upravljanje njima: MMDBMS -Multimedia Database Management System. Pošto u
svojoj osnovi multimedija ima nestrukturirane podatke,
objektno-orijentisan stil je omogućio sredstva za definisanje novih tipova podataka i operatora za
nove vrste medija, kao što su video, grafika i audio.
Relacioni model pokazuje snagu i vitalnost. Prihvata nove ideje i neprestano se dograđuje. Zadržan
je osnovni koncept, a relacijama su pridružene osobine objekta. Tako je nastao objektno-relacioni
sistem (ORDBMS) predstavljen 1999. god. sa SQL-3 standardom.
Kao jedan od mogućih pravaca razvoja je mapiranje objektnog u relaciono, gdje se stvaraju
virtuelne objektne baze korišćenjem okvira (framework).
19
2. Sistem za upravljanje bazom podataka – Uvod‐

2.1 Šta su to baze podataka
Naziv baza podataka se strogo1 govoreći odnosi na zbirku zapisa (bilo kakvu, pa i neelektronsku). Ako se za
pristup koristi softver, onda bi se za taj softver trebao koristiti naziv sistem upravljanja bazom podataka.
Pošto nam primarni predmet interesovanja nije pravo, daćemo definiciju iz knjige Uvod u baze podataka2:
„Baza podataka je skup podataka koji su organizovani prema potrebama korisnika, koji se održavaju i koriste
za dobijanje informacija.“
Uobičajeno se baze podataka čuvaju na računaru i na nekom trajnom mediju-disku (što nije bitno za samu
definiciju).
Za bazu je bitno da je to organizovani skup logički povezanih podataka, gdje se pod organizovan i logički
smatra da je to skup podataka pripremljen tako da se mogu jednostavno koristiti, tj. pregledavati, pretraživati,
sortirati, porediti i mijenjati.
Baza podataka različitim korisnicima i programima pruža mogućnost da iste podatke različito koriste.
Osim podataka namijenjenih korisnicima, baza podataka sadrži i metapodatke. Metapodaci su podaci o
strukturi baze podataka (imena tabela-relacija, imena i domene atributa-kolona koji čine relacije), veze
među podacima, pomoćne strukture za pristup podacima (ključevi i indeksi), podaci o korisnicima
(prava i privilegije) i sve ostale sistemske komponente (izgled ekrana, izvještaja i slično).
2.1.1 Sistem za upravljanje bazom podataka
Sistem za upravljanje bazom podataka SUBP (Database Management System – DBMS) je softver koji je
spona i veza (interfejs) između korisnika (aplikativnih-korisničkih programa) i zapisa baze podataka na
disku.
Slika 2.1 Sistem baza podataka
Sistem baza podataka predstavlja jedinstvo baze podataka i neophodnih hardverskih, softverskih i ljudskih
resursa i predstavljen je na Slici 2.1. Sistem sadrži 4 osnovne komponente:
1. korisnici,
2. aplikacija nad bazom podataka,
3. sistem za upravljanje bazama podataka i
4. baza podataka.
1
Ovo strogo, znači pravno gledano, a autori vam mogu ponuditi adresu direktive Evropske unije (Directive 96/9EC)
gdje se na 576 stranica propisuje način korištenja podataka iz različitih baza podataka. Adresa je:
http://ec.europa.eu/internal_market/copyright/docs/databases/etd2001b53001e72_en.pdf
2
Mladen Veinović, Goran Šimić, Uvod u baze podataka, Univerzitet Singidunum, Beograd 2010
20
Sistem za upravljanje bazom podataka – Uvod-
2.1.2 Podatak i informacija
Sjećate li se pojma sistema? (iz poglavlja Modeliranje i simulacija). Za potrebe analize modela sistema baze
podataka daćemo proširenje ranije definicije: Sistem predstavlja skup elemenata i njihovih međusobnih veza.
U „realnom svijetu“ podatak je pojam koji opisuje i kvantifikuje stanje nekog procesa. Podatak je činjenica
koja predstavlja reprezentaciju nekog predmeta ili događaja. Oblici podataka su zvučni, slikovni, brojčani i
tekstualni. Podaci mogu biti strukturirani (npr. slovni, brojevi, datumi), i nestrukturirani (slika, zvuk).
Informacija3 je novi podatak koji posjeduje neku relevantnu novinu. Podatak sam po sebi nema značenje,
tek kad se obradi i interpretira postaje informacija.
U sklopu sistema za upravljanje podacima vrši se obrada podataka iz baze podataka, tako da oni postanu
korisne informacije.
2.1.3 Entiteti i atributi
Entitet predstavlja pojam nečega što posebno i samosvojno postoji, a kod baza podataka entitet je osnovni
element koji smještamo u bazu.
Entitet je realan ili imaginaran objekat (odnosno biće, događaj ili pojava) koji se može jednoznačno
identifikovati, razlikovati i opisati. Entitet je nešto o čemu želimo sačuvati podatke.
Entitet se opisuje atributima, a konkretne vrijednosti entiteta određuju se vrijednostima atributa.
Atributi predstavljaju opis entiteta, odnosno atributima se definišu opšte osobine koje određuju entitet.
Konkretna vrijednost entiteta dobije se kada se atributima daju konkretne vrijednosti.
Npr.: entitet Imenik ima atribute Ime, Prezime, Adresa, Grad, Br_Tel, a vrijednost tog entiteta može biti:
Petar, Petrović, Banja Luka, Fruškogorska, 051/123-122.
Atribut je definisan izrazom:
<ime atributa> <tip atributa> <dodatna svojstva atributa>
Atribut ima svoje ime po kome se razlikuje od ostalih atributa entiteta kojem pripada. Ne mogu postojati
dva atributa sa istim imenom u sklopu jednog entiteta; normalno ista imena se mogu koristiti za atribute
različitih entiteta.
Tip podatka4 pridružen konkretnom atributu bliže opisuje atribut i određuje način njegovog memorisanja.
Najčešći tipovi atributa su:
 Tekstualni / strings (CHAR(n) – tekst dužine n slova, VARCHAR(n) – tekst dužine najviše n slova,
TEXT – tekst proizvoljne dužine),
 Numerički (INT – cijeli broj prikazan s 4 bajta, BIGINT – cijeli broj prikazan s 8 bajta, SMALLINT
– cijeli broj prikazan s 2 bajta, REAL – realni broj prikazan s 4 bajta, DOUBLE PRECISION - realni
broj prikazan s 8 bajta, NUMERIC [(p,s)] - realni broj zadane preciznosti,
 MONEY - novac,
 Logički podaci,
 Datum i vrijeme (DATE, TIME, TIMESTAMP – datum+vrijeme).
Atributi mogu imati i neka dodatna svojstva koja mogu da ograniče domen atributa (vidi iduću lekciju).
Dodatna svojstva atributa:
 DEFAULT (zadavanje predefinisane vrijednosti),
 NOT NULL (vrijednost ne smije biti nepoznata),
 CHECK (provjera da li je vrijednost atributa u zadanim granicama),
 UNIQUE (jedinstvenost među n-torkama unutar relacije),
 PRIMARY KEY (primarni ključ),
 REFERENCES (vrijednost odgovara vrijednostima atributa iz druge relacije (najčešće ključ te
relacije)),
 UNSIGNED (Ako ne trebamo negativne brojeve),
 FLOATING POINT (decimalni brojevi),
 DOUBLE F.P. (pozitivne i negativne vrijednosti).
3
Šenon je informaciju definisao kao podatak koji smanjuje neizvjesnost.
4
većinu tipova i dodatnih svojstava ćemo provježbati kroz primjere u Access-u
21
2.1.4 Domen atributa
Domen (domain) je skup svih prihvatljivih vrijednosti koje atribut može imati.
Domen atributa se definiše: tipom podataka, dužinom podataka i opsegom vrijednosti.
Definicija domena zahtijeva potpun opis važećih podataka.

To može biti lista sa svim prihvatljivim vrijednostima (npr. domen atributa Ocjena: {1,2,3,4,5} ili
StručnaSprema, {niža, srednja, viša, visoka, master, doktorat}.
U praksi se ne mogu svi domeni definisati pojedinačnim navođenjem prihvatljivih vrijednosti. Ponekad je
lakše definisati domen u obliku pravila koja utvrđuju da li određena vrijednost pripada skupu prihvatljivih
vrijednosti.
Ako se atributu ne definiše domen onda on uzima sve vrijednosti tipa koji ga određuje, što ponekad dovodi
do zabune. Domen i tip nisu jedno te isto, izuzev u slučajevima kad zadržimo predefinisanu sistemsku
vrijednost domena (INTEGER, CHAR...).
Domen je skup vrijednosti istog tipa, npr. skup imena rijeka nekog sliva, skup imena igrača nekog tima,
skup imena mjesnih zajednica nekog grada, skup naslova knjiga neke biblioteke, itd.
2.2 Arhitektura baze podataka i njeno predstavljanje šemama

Arhitektura baze podataka sastoji se od tri nivoa-sloja i veza-interfejsa među slojevima. Struktura baze
podataka je na ovakav način prvi put predstavljena sedamdesetih godina i poznata je kao ANSI/X3/SPARC
model5. Riječ je o tri nivoa apstrakcije predstavljena na Slici 2.3.
Slika 2.3 Troslojna arhitektura baze podataka

Svaki nivo ima specifičan način definisanja i predstavljanja objekata, odnosa i operacija među njima.
Hijerarhijska organizacija omogućava modularan pristup i, što je još važnije, logičku i fizičku nezavisnost
programa od podataka.
Korisnički (vanjski) eksterni logički nivo čine aplikacioni programi kojima mogu pristupiti korisnici. Oni
se služe samo dijelom podataka koji postoje u bazi podataka i taj dio se zove pogled (view) i opisuje se
eksternim šemama.
Za kreiranje baze podataka na lokalnom nivou dovoljno je zadati samo šemu i poglede. DBMS automatski
generiše potrebni raspored arhiviranja i fizičku bazu.
Globalni logički nivo opisuje se konceptualnom šemom i sadrži opis svih entiteta i veza, atributa, domena i
integritetska ograničenja.
Konceptualna šema se može opisati korištenjem modela podataka, npr. relacionog i često se naziva i
logička šema. To je tekst ili dijagram kojim se imenuju i definišu svi podaci, veze među podacima, te pravila
kojima se čuva integritet baze podataka. Logičku šemu definiše, vidi i uređuje administrator, ili projektant
baze.
5
preliminarno predstavljen od strane ANSI (American National Standards Institute) 1972., kao potpun standard
definisan je 1975. kao “ANSI/X3/SPARC Study Group on Data Base Management Systems; Interim Report), a zadnja
verzija je iz 1996
22
Fizički nivo - To je fizički prikaz i raspored podataka na diskovima, tj. vanjskoj memoriji gdje se podaci
smještaju. Raspored smještanja i pamćenja podataka na fizičkom nivou opisuje kako se logičke definicije
preslikavaju na fizičke uređaje.
Fizičkom nivou pristupaju programeri koji kreiraju DBMS. DBMS „prevodi“ korisničke zahtjeve za
podacima s lokalnog nivoa na globalni logički nivo, a potom ih realizuje kao ekvivalentne na fizičkom nivou
(vidi Sliku 2.3)
Jedna baza podataka ima jednu konceptualnu, jednu fizičku i (najčešće) više eksternih šema.
2.3 Jezici za upravljanje bazama podataka

Komunikacija korisnika, tačnije aplikacionog programa i DBMS -a (na lokalnom nivou, vidi Sliku 2.3) se
tradicionalno obavljala preko:
1. Jezika za opis podataka (Data Description Language - DDL) koji definiše podatke i veze među
podacima na logičkom nivou. Koristi se za definisanje nove ili promjenu postojeće šeme podataka.
2. Jezika za manipulisanje podacima (Data Manipulation Language - DML) koji definiše i
uspostavlja vezu između aplikacionog programa i baze.
3. Jezika za postavljanje upita (Query Language - QL). Služi neposrednom korisniku za
interaktivno pretraživanje baze. Obično je to jezik koji podsjeća na govorni (engleski) jezik i osim
pretraživanja omogućuje operacije unosa, izmjene i brisanja podataka.
Ovakva podjela je prilično zastarjela. Naime, kod relacionih baza postoji tendencija da se sva tri jezika
integrišu. Primjer takvog jezika je SQL (Structured Query Language). SQL je strukturni upitni jezik koji u
sebi objedinjuje mogućnosti kreiranja, manipulacije i zaštite objekata baze. Na Slici 2.4 može se vidjeti blok
šema koja pokazuje odnos SQL-a prema DDL-u i DML-u, kao i osnovni tipovi i komande koje ovaj jezik
podržava.
Slika 2.4 Tipovi i komande SQL-a
Moderne aplikacije se razvijaju u standardnim objektno orijentisanim programskim jezicima (Java, C++, . . .
). Za interakcije s bazom koriste se unaprijed pripremljene klase objekata. Ali, to je tema nekog drugog
udžbenika.

23
2.3.1 Softverski paketi za rad s bazama podataka
Baze podataka se u pravilu realizuju korišćenjem nekog od provjerenih (i skupih) softverskih paketa. U
Tabeli 2.1 dat je pregled nekih od najznačajnijih softverskih proizvoda i paketa za rad sa bazama podataka.
Proizvod Proizvođač Operativni sistem Jezici

ADABAS Unix, Linux i Microsoft Windows
Software AG SQL COBOL
serveri
Adaptive Server MS Windows , OS/2, Mac, UNIX
Sybase Inc. SQL, COBOL, ...
Enterprise (razni), UNIXWare
Advantage Database MS Windows , OS/2, Mac, UNIX
Sybase Inc. SQL, COBOL, ...
Server (razni), UNIXWare
Allbase/SQL Hewlett Packard Co. UNIX (HP-UX) SQL. 4GL, C, ...
Linux. UNIX (razni),
DB2 IBM Corporation MS Windows, VMS, MVS, VM, SQL, COBOL, Java, ...
OS/400
FileMaker Pro Go 14 FileMaker Inc Linux, MS Windows (razni), Mac OS SQL i ODBC
IBM Corporation (prije: UNIX (razni), Linux,
Informix SQL. Java i drugi
Informix) MS Windows
MS Access Microsoft MS Windows (razni) Access, Basic, SQL
MS SQL Server Microsoft MS Windows NT/7/8/10 SQL, C+ + . ...
Linux, UNIX (razni), SQL,
MySQL MySQL AB
MS Windows (razni), Mac OS C, PHP. ...
MS Windows (razni), Mac OS, UNIX
Oracle Oracle Corporation SQL, Java i drugi
(razni), Linux i drugi
Supra Cincom Systems Inc. UNIX, Linux, OpenVMS SQL, COBOL, ...
Windows Server 2003, Linux
Teradata Database Teradata Corporation SQL
Enterprise Server 10
Tabela 2.1: Softverski paketi za rad sa bazama
Vašoj pažnji preporučujemo pregled 2000 najboljih softverskih proizvoda

(Top Database Management Software Products) na adresi:
http://www.capterra.com/database-management-software/
Posebno preporučujemo MySQL. Možda nije najbolji, ali je jedan od najpopularnijih jer je besplatan (open
source) sistem za upravljanje bazom podataka.
2.3.2 Životni ciklus baze podataka

Svaka baza podatak ima svoj životni vijek, početak kada je projektirana, pa do njene implementacije i
održavanja. Uvodenje baze podataka u neko poduzeće ili ustanovu predstavlja složeni zadatak koji zahtijeva
timski rad stručnjaka raznih profila.
Grubo se to može podjeliti na 5 faza:
1. Analiza potreba
2. Modeliranje podataka
3. Implementacija
4. Testiranje
5. Održavanje
Alternativni dijagram koji pokazuje interakciju pojedinih

faza razvoja i životnog ciklusa baze podataka
24
2.3.2.1 Analiza potreba

Porebno je ustanoviti način poslovanja , koji se podaci koriste, i na koje načine, i gdje. Proučavaju se tokovi
informacija u firmi.
Uočavaju se podaci koje treba pohranjivati i veze među njima. Analiza potreba takođe treba
obuhvatiti analizu transakcija (operacija) koje će se obavljati nad bazom podataka, budući da to može
isto imati uticaja na sadržaj i konačni oblik baze. Važno je procijeniti frekvenciju i opseg pojedinih
transakcija, te zahtjeve na performanse. Rezultat analize je dokument koji se zove specifikacija potreba.
 Treba pronaći veze među podacima.
 Sve te informacije o podacima treba objediniti i uskladiti, stvoriti konzistentnu sliku o njima.
 Zatim je ustanoviti kako će se ti podaci koristiti, koliko često, i koje su vrste operacija potrebne nad
podacima.
2.3.2.2 Modeliranje podataka
Ovaj dio pripada onome sto se zove globalna šema. Za bazu podataka tipično postoji strukturni opis vrste
činjenica sadržanih u toj bazi podataka: taj opis naziva se šema. Šema opisuje predmete koji su prikazani u
bazi podataka, te odnose među njima. Ovom tematikom ćemo se kasnije detaljno pozabaviti.
2.3.2.3 Implementacija
Prethodni koraci su bili vrsta planiranja - sve na papiru (ili računaru),ali ovaj korak je realizacija
zamišljenog.
Na osnovu šeme i pod-šema, te uz pomoć dostupnog DBMS-a (SUBP-a), fizički se realizuje baza podataka
na računaru. U DBMS-u (SUBP-u) obično postoje parametri kojima se može uticati na fizičku organizaciju
baze. Parametri se podešavaju tako da se osigura efikasan rad najvažnijih transakcija. Razvija se skup
programa koji realizuju pojedine transakcije te pokrivaju potrebe raznih aplikacija. Baza se inicijalno puni
podacima.
Obuhvata:
 Implementacija šeme.
 Razvoj potrebnih aplikacija za rad.
 Inicijalno punjenje baze podataka s podacima potrebnim za početak rada.
2.3.2.4 Testiranje
Korisnici rade s bazom i provjeravaju da li ona zadovoljava sve zahtjeve. Nastoje se otkriti greške.U novije
vrijeme, prije prave implementacije, razvijaju i približni prototipovi baze podataka, te se oni pokazuju
korisnicima. Jeftinu izradu prototipova omogućuju jezici 4. generacije i objektno-orijentisani jezici.
2.3.2.5 Održavanje
Odvija se u vrijeme kad je baza već ušla u redovnu upotrebu. Sastoji se od sljedećeg: popravak grešaka koje
nisu bile otkrivene u fazi testiranja; uvođenje promjena zbog novih zahtjeva korisnika; podešavanje
parametara u DBMS (-SUBP-) u svrhu poboljšavanja performansi. Održavanje zahtijeva da se stalno prati
rad s bazom, i to tako da to praćenje ne ometa korisnike.
25
2.4 Apstrakcija i šeme za modeliranje baze podataka
Ovaj dio pripada onome sto se zove izrada globalne šeme i definisanje baze podataka:
 definisanje vrste podataka i veza među njima a prema informacijama dobivenim analizom potreba.
 normalizacija (regrupiranje) podataka u cilju budućceg efikasnijeg rada baze podataka.
 definisanje podšema za pojednine aplikacije.
Pošto baza podataka ne postoji u relnom svijetu primjenjujemo koncept apstrakcije:
Apstrakcija podrazumjeva tri procedure

 Klasifikaciju
gdje se obavlja klasificiranje,opis i grupisanje
entiteta u klase, razrede, odnosno tipove prema
zajedničkim obilježjima. Opisuje se vezom
(odnosom) “jest pojava” (engl. instance of).
 Generalizaciju
gdje se tipovi entiteta niže razine uopštavaju se
tipom entiteta. Opisuje se vezom “jest” (engl.
is a)
 Agregacija
vrši formiranje novog pojma na osnovu odnosa
postojećih pojmova.
26
2.5. Relacioni model

Model je reprezentacija skupa entiteta (objekata) i njihovih međusobnih veza. Izbor i definisanje entiteta i
veza između njih je suština procesa modeliranja.
Za sada možemo reći da postupak definisanja relacija-tabela i veza među njima znači kreiranje modela
relacione baze podataka. Prije nego što definišemo relacioni model, upoznaćemo se sa modelima baza
podataka uopšte, potom sa elementima i uslovima kreiranja relacionog modela.

2.5.1 Modeli baze podataka
Prilikom objašnjenja arhitekture baze objasnili smo da se na konceptualnom nivou definiše konceptualni
model sa odgovarajućom logičkom šemom koja sadrži opis svih entiteta i veza, atributa, domena i
integritetska ograničenja. Hijerarhijsko mjesto konceptualnog modela vidi se na Slici 2.5 (između korisnika i
fizičkog nivoa).
Slika 2.5 Hijerarhija modela

Eksterni modeli (1-3) nastaju na osnovu konceptualnog modela i predstavljaju samo pogled (view) koji je
nastao prema potrebama korisnika.
Na Slici 2.5 može se primijetiti da fizički model omogućava predstavljanje konceptualnog modela u formi
zapisa podataka na neki fizički medij (najčešće je to disk, a „posrednik“ između medija i fizičkog modela je
operativni sistem-OS).
Kad se govori o modelima baze podataka najčešće se misli na konceptualni model, pa ćemo mi ubuduće
kad kažemo model smatrati da je to konceptualni model (a kad to ne bude slučaj to ćemo posebno
naglasiti).
Definisanje logičke šeme, odnosno pravljenje konceptualnog modela (uopšte, pa i kod baza podataka)
podrazumijeva tri koraka:
1. detekciju i selekciju objekata (entiteta) i veza između objekata
2. imenovanje objekata, njihovih atributa i veza
3. klasifikaciju, gdje se objekti svrstavaju u klase i tipove

2.5.2 Vrste modela baza podataka
Model baze podataka je formalni sistem koji se sastoji od:

 skupa objekata - osnovnih elemenata (koncepata) baze podataka
 skupa operacija koje se provode nad objektima
 skupa integritetskih ograničenja (integrity constraints) kojima se definiše skup važećih pravila
Razlikujemo nekoliko vrsta modela. Mi ćemo se baviti relacionim modelom (što je i naslov ove (2.4)
sekcije), a ostale modele, koji su uglavnom istorijski ćemo samo informativo obraditi.
27
2.5.2.1 Ravni (tabelarni) model

Ravni model poznat i kao model ravnih datoteka (flat files) je model gdje se svi podaci čuvaju u samo jednoj
tabeli. Glavni nedostatak je velika redundansa, a primjer koji bi odgovarao ovom modelu bila bi Excel
tabela.
Može se smatrati pretečom relacionog modela samo zbog forme tabele kao načina organizacije podataka.
2.5.2.2 Hijerarhijski model podataka

Hijerarhijski model je najstariji model. Zasnovan je na hijerarhijskoj strukturi koje ima oblik stabla prikazan
na Slici 2.6. Kod hijerarhjskog modela podaci su organizovani kao čvorovi.
Slika 2.6 Hijerarhijski model predstavljen mrežnim stablom

Hijerarhijska struktura odgovara stablu i postoje različiti matematički opisi i procedure pretrage mrežnog
stabla6. Element na jednoj strani relacije “jedan-prema-više” naziva se element višeg nivoa ili roditelj, koji je
povezan sa elementima nižeg nivoa ili djecom. Hijerarhijska baza podataka se predstavlja kao stablo
aplikacionih elemenata, gdje relacija “jedan-prema-više” povezuje svakog roditelja i dijete. Pretraga se
obavlja od osnovnog sloga (root) i kreće prema naniže (ako se ne pronađe, vraća se unazad i ide na iduće
dijete...)
2.5.2.3 Mrežni model podataka

Mrežni model nastao je kao paralela hijerarhijskom modelu, ali kod njega je dopušteno da svaki slog ima
više od jednog roditelja. Moglo bi se reći da je hijerarhijski model specijalni slučaj mrežnog modela.
I mrežni model se može predstaviti mrežnim grafom (kako ovdje ne postoji obavezan odnos roditelj-dijete,
ne govori se o stablu, već o mrežnom grafu). Kod mrežnih struktura moguće je da se svaki element povezuje
sa svakim. Podaci u mrežnom modelu se prikazuju skupovima slogova, a njihovi odnosi pomoću veza. Na
Slici 2.7 data je ilustracija mrežnog modela predstavljena mrežnim grafom i modelom jedne konkretne baze.
Slika 2.7 Mrežni graf kojim se može predstaviti mrežna struktura podataka
Relacioni model podataka

Ovaj model je trenutno najrasprostranjeniji i on je predmet našeg interesovanja.
6
Teorija grafova je grana matematike koja se bavi proučavanjem grafova. Graf je vrsta strukture podataka koji se
sastoji od skupa čvorova i skupa grana, koje predstavljaju odnose (veze) između čvorova. Mrežno stablo je
najjednostavnija klasa grafa. U računarstvu se grafovi često koriste za opis modela ili struktura podataka.
28
2.6 Pojam relacije i relacione baze

Osnivač relacionog modela Kod7 je osnovne pojmove relacionog modela preuzeo iz matematičke teorije.
Relacija, kao osnovni koncept relacionog modela je matematička relacija8.
Relacija je imenovani podskup Dekartovog (Kartezijevog) proizvoda dva ili više domena. Kombinacije
vrijednosti domena nazivaju se n-torke.
Pojednostavljeno objašnjenje Dekartovog proizvoda daćemo u sekciji o relacionoj algebri (sekcija 2.5), a za
više detelja o ovoj problematici preporučujemo knjigu Gordane Pavlović-Lažetić, Uvod u relacione baze
podataka, iz koje ćemo dati nešto precizniju definiciju relacije:
„Neka su D1,D2,...,Dn (n  N) domeni (ne obavezno različiti). Dekartov proizvod tih domena, u oznaci D1 ×
D2 × ... × Dn, jeste skup n-torki (v1, v2, ... ,vn) takvih da je viDi za sve i=1,2, ...,n. Relacija R stepena n,
definisana na domenima D1,D2,...Dn, je proizvoljni konačni podskup navedenog Dekartovog
proizvoda.“
Prema tome, relacija je skup n-torki.

Relaciji bi u standardnoj računarskoj trminologiji odgovarala jedna datoteka, a n-torci jedan slog te
datoteke.
Relacija ima jednostavnu reprezentaciju u obliku dvodimenzionalne tabele sa podacima, prikazanu na Slici
2.8.
Slika 2.8 Tabela kao reprezentacija relacije

Napokon možemo da definišemo relacionu bazu: Relaciona baza podataka je skup vremenski
promjenljivih relacija (n-torki u relacijama).
Sistemi relacionih baza podataka imaju sljedeće odlike:
 Svi podaci se predstavljaju preko relacija (relation) u obliku dvodimenzionalne tabele sa podacima.
Osim atributa svakog entiteta, model podataka mora da definiše i veze ili odnose koje postoje
između entiteta. Veza ili odnos (relationship) je udruživanje-asocijacija između entiteta.
 Sve vrijednosti su skalarne. (vidi 2.6.5 1NF).
 Sve operacije obavljaju se nad cijelom relacijom, a rezultat je takođe cijela relacija. Taj koncept je
poznat kao cjelovitost (closure).
Skup operacija koje se provode na relacijama, odnosno tabelama naziva se relacionom algebrom. Kasnije
ćemo se upoznati sa osnovnim pojmovima iz relacione algebre i računa.
7
Edgar Kod, engleski matematičar i naučnik, više detalja vidi u 2.9
8
često se može sresti pogrešna tvrdnja da se relacioni model tako zove zbog veza (engl. relationships), relacioni model
je dobio ime po relacijama na kojima se model zasniva.
29
2.6.1 Šema relacije: Relaciona tabela i Šema relacione baze
Šema relacije predstavlja opis strukture tabele. Relaciona šema se još naziva i relaciona tabela, a nju
karakterišu sljedeća svojstva:
 U relacionoj šemi može postojati samo jedan tip slogova, odnosno n-torki;
 Svaki red, odnosno slog ili n-torka (tuple) uključuje tačno određen broj polja podataka, tj. atributa i
svaki od njih je eksplicitno imenovan;
 Relaciona šema ne sadrži dva jednaka naziva atributa, odnosno relacija ne sadrži dvije jednake
kolone;
 Redoslijed kolona, odnosno atributa je nebitan;
 Redoslijed n-torki je nebitan;
relacija nije uređena. Relaciju možete zamisliti kao košaru u kojoj su torke nagomilane bez
ikakvog posebnog redoslijeda. Redni brojevi zapisa, uobičajen mehanizam za pristupanje zapisima
u nerelacionim bazama podataka, ne postoje u relacijama.
 Nove se tabele mogu stvarati povezivanjem preko vrijednosti polja podataka iz istog domena iz dvije
postojeće tabele.
Naglasimo: relacija i tabela nisu isto. Kod tabela je bitan redoslijed redova i kolona, dok kod relacija nije
bitan redoslijed atributa i n-torki.
Šemu relacije možemo shvatiti dvojako: kao definiciju strukture neke datoteke (kako smo naveli u definiciji),
ali i kao predstavu svojstava klase objekata i veza unutar nekog sistema.
Šema relacione baze podataka je skup šema njenih relacija.
2.6.2 Predstavljanje relacija i šema relacija
Relaciju možemo predstaviti tako da navedemo njeno ime i skup atributa koji je čine:
R(A1:D1, A2:D2,..., An:Dn), ako domeni nisu bitni dovoljno je navesti samo atribute:
R(A1, A2,..., An).
Primjer: Ucenik(Razred, BrojDnevnik, Ime, Prezime)
Uobičajena konvencija za predstavljanje relacione šeme je dijagram relacije. Relaciju predstavljamo

pravougaonom tabelom koja ima onoliko ćelija koliko je atributa u relaciji.
Ime relacije se ispisuje iznad tabele, a imena atributa u ćelijama9.
Kao primjer, na Slici 2.9 daćemo dijagram relacione šeme baze podataka Generacija2016.
L_Podaci
JMBG Odjeljenje Br_dnevnik Prezime Ime Dat_rodj Pol Adresa Grad

Odjeljenja

Odjeljenje Smjer
Slika 2.9 Primjer dijagrama relacija
9
pri čemu se atribut koji je primarni ključ podvlači, a spoljni ključevi pišu italikom, a šta to znači vidi 2.2.5
30
2.6.3 Osnovne osobine koje treba da ima relacioni model
SUBP (DBMS) se naziva relacionim ako podržava relacione operacije (kanije ćemo objasniti relacione
operacije). Osim što podržava relacione operacije, da bi neki model mogao da se nazove relacionim on treba
da ima osnovne osobine kao što su:
 Sistemski tretman „NULL“ vrijednosti
NULL je univerzalna vrijednost "nepoznato". Koristi se kad iz bilo kog razloga u momentu unosa
podataka nije poznata vrijednost nekog ulaznog podatka. NULL može biti vrijednost svake kolone
bez obzira na njen tip, osim primarnog ključa i u slučaju kad se izričito zahtijeva da vrijednosti u
nekoj koloni ne smiju biti nedefinisane (dodatno ograničenje NOTNULL).
 Neprekidan pristup dinamičkom katalogu relacionog modela
Katalog relacionog modela predstavlja zapis o strukturi baze podataka. Spada u tzv. metapodatke,
koje smo spomenuli u uvodu. Zapisan je u istoj formi (relacije-tabele) kao i sami podaci. Pravo
pristupa ovom katalogu imaju samo ovlašteni korisnici-administratori. Naziva se dinamički, jer
definicije podataka koje se mogu vidjeti odgovaraju upravo tekućem stanju u bazi podataka.
 Fizička nezavisnost
znači da korisničke aplikacije ostaju neizmijenjene kada se promijeni fizička organizacija baze ili
fizički metod pristupa podacima (vidi Arhitektura baze podataka). Praktično, fizička organizacija
podataka ima uticaj samo na performanse (brzinu pristupa podacima, odziv sistema).
 Logička nezavisnost
Ekvivalentno prethodnom uslovu, samo u obrnutom smjeru;
 Integritetska nezavisnost
o Integritet entiteta definiše da je primarni ključ jedinstven na nivou cijele relacije.
o Integritet domena određuje skup dozvoljenih vrijednosti kolone
o Relacioni integritet
Svaki atribut u relaciji vezuje se za određeni domen, pa povezivanjem atributa ne smije da se
naruši (analiziraj kasnije kardinalnost).
o Referencijalni integritet odražava definisane odnose (relacije) među tabelama kada se u njih
dodaju ili se iz njih brišu zapisi (analiziraj kasnije anomalije), naglašava da izmjena bilo kog
podatka ne smije da mijenja karakter drugog.
2.6.3.1 Zadatak: uvod u kreiranje relacionog modela
Želimo kreirati bazu podataka Generacija2016 koja predstavlja generaciju učenika (npr. neke gimnazije,
koju ćemo analizirati kao sistem iz realnog svijeta koga želimo modelirati i dizajnirati bazu koja ga
predstavlja).
Izbor relacija i definisanje atributa
Prvo analiziramo problem, odredimo podatke koje želimo pamtiti (poželjno je da to uradimo u pisanoj
formi), na osnovu toga definišemo objekte i podatke, prepoznamo entitete i njihova svojstva, koje želimo
predstaviti relacijama; odnosno definišemo tabele i kolone.
Krenućemo od skupa učenika škole koga želimo predstaviti relacijom-tabelom Ucenik u kojoj ćemo
smještati i čuvati podatke o razredu, odjeljenju, smjeru, broju u dnevniku, imenu, prezimenu, datumu
rođenja, polu i adresi stanovanja.
Nedostaju predmeti i ocjene, njihovo uvođenje ostavljamo za napredne učenike kad se upoznaju ne samo sa
preostalim temama modeliranja baza već i Access-om.
Moguće rješenje je definisanje baze Generacija 2016 sa dvije tabele-relacije: L_Podaci i Odjeljenja i
njihovih atributa (kolona).
L_Podaci
Odje Br_
JMBG Prezime Ime Dat_rodj Pol Adresa Grad
ljenje dnevnik
0123456 I-1 18 Marković Marko 10-01-01 M Beogradska 7 Zvornik
0123456 I-1 3 Žarić Ana 05-03-00 Ž Lj. Bogdana 3 Višegrad
2345678 I-2 22 Petrović Milan 02-01-01 M Karađorđa 7 Teslić
3466677 I-2 23 Rodić Ana 05-12-99 Ž Savska 34 Kotor Varoš
4565553 I-3 22 Petrović Petar 09-12-00 M Čairska 3 Laktaši
3219871 I-3 1 Adžić Zlatko 07.07-00 M S. Đaka 19 Banja Luka

31
Odjeljenja
Odjeljenje Smjer
I-1 opšti
I-2 opšti
I-3 društveno-jezički
I-4 matematički

I-5 računarski
Nastavak zadatka: Definisati domene atributa relacije L_podaci.

Rješenje:
Atribut Domen Značenje Definicija domena
JMBG Jedinstveni broj Skup mogućih matičnih Niz karaktera, dužine 1210
građanina brojeva radnika
Odjeljenje Oznaka i broj Skup mogućih imena osoba Niz karaktera, dužine do 5.
odjeljenja
Br_dnevnik Broj u dnevniku Skup mogućih brojeva u Cijeli brojevi, opseg 1-32
dnevniku
Prezime Prezime učenika Skup mogućih prezimena Niz karaktera, dužine do 15.
Ime Ime učenika Skup mogućih imena Niz karaktera, dužine do 15.
Dat_Rodj Datum Rodjenja Moguće vrijednosti za datume Datum, opseg, od 01-JAN-99 nadalje
rođenja učenika prvog razreda
Pol Pol Pol učenika Karakter (1), vrijednost M i Ž
Adresa Adresa učenika Moguće adrese učenika Niz karaktera (25)
Mjesto Mjesto stanovanja Moguće mjesto stanovanja Niz karaktera (15)

2.7 Kandidati za ključ i primarni ključ

Kandidat za ključ (candidate key) je atribut, ili skup atributa, čije vrijednosti jednoznačno određuju n-torku
unutar relacije.
Na primjer kandidat za ključ relacije Auto mogao bi biti atribut RegistarskiBroj.
Svaka relacija mora da ima barem jednog kandidata za ključ: to je skup svih atributa koji čine torku.
Kandidat za ključ mora da ispuni još jedan dodatan uslov, a to je da se ne može razbiti na prostije dijelove;
zbog toga skup svih atributa relacije ne mora obavezno biti kandidat za ključ.
Kandidat za ključ može se sastojati od samo jednog atributa - prost ključ (simple key), ili od više njih -
složen ključ (composite key).
Neki autori smatraju da složeni ključevi nisu dobro rješenje i zato dodaju svojim tabelama vještačke
identifikatore – npr. polja tipa autonumber; da bi izbjegli složene ključeve.
Ukoliko relacija ima više kandidata za ključ, tada biramo jednog od njih i proglašavamo ga primarnim
ključem.
Sada, kad smo se upoznali sa primarnim ključem, relaciji možemo pridružiti i osobinu adresabilnosti:
Svaka n-torka relacije određena je vrijednošću primarnog ključa.
Svaki podatak je određen nazivom relacije, nazivom atributa i vrijednošću primarnog ključa.
Atributi koji čine primarni ključ zovu se primarni atributi, svi ostali zovu se sporedni atributi.
Primarni ključ ima dvostruku ulogu: jednoznačno definiše n-torke (red u tabeli) i omogućava da se preko
njega ostvari veza sa drugim relacijama (tabelama).
Nastavak zadatka 2.2.2.1: Prepoznaj - definiši primarne ključeve relacija L-Podaci i Odjeljenja.
10
Zašto nije ispravno (mada je moguće) da se JMBG definiše kao broj?
32
2.8 Veze kod relacionog modela baze

Ako ste pažljivo čitali odjeljak o konceptualnom modelu, mogli ste zaključiti da izbor objekata, njihovo
imenovanje i klasifikacija znači potpuno definisanje modela, jer izbor objekata znači i izbor veza.
Pod relacijom-vezom smatramo uspostavljanje nekog odnosa između dva objekta. Događaj opisuje vezu
između dva objekta.
Primjer: rečenica “Učenici pišu zadaću” pokazuje da događaj „pišu“ uspostavlja vezu između dva objekta -
učenika i zadaće.
Objekti između kojih postoji veza ili odnos zovu se učesnici veze (participants).
Kod relacionih modela veze se uspostavljaju između atributa relacija.

Pojednostavljeno: Terminom veza, tj. „odnos“ (Relationships) ukazuje se na međusobne odnose
između primarnih i stranih ključeva tabela.
Strani ključ (Foreign key) tabele je atribut (skup atributa) koji ukazuje na zavisnost od neke druge tabele.
Polazna tabela se obično zove tabela-dijete, a tabela od koje ona zavisi roditeljska tabela.
Strani ključ mora zadovoljiti uslov da je skup njegovih atributa primarni ključ roditeljske tabele. Primjer sa
Slike 2.10 pokazuje kako to izgleda u bazi Regionalno poslovanje, koja ima dvije tabele/relacije
PoslovanjeSektora i Regije.
Slika 2.10 Odnos primarnog i stranog ključa
U relacionom modelu veza nije materijalizovana, već se dinamički uspostavlja pri radu s podacima,
poređenjem vrijednosti atributa u n-torkama raznih relacija.
Primarni i sekundarni ključ povezuje jednakost značenja, pa jednakost naziva može, ali i ne mora biti
zadovoljena.
33
2.9 Kardinalnost entiteta

Kardinalnost (cardinality) predstavlja odnos broja objekata koji se povezuju.
Kardinalnost entiteta je uređeni par (a:b), koji pokazuje koliki je broj veza pojedinog elementa tog entiteta
sa elementima entiteta s kojim je relacijski povezan.
Slika 2.13 Tipovi kardinalnosti entiteta

Postoje tri tipa kardinalnosti entiteta prema broju veza:
1. Jedan-ka-jedan (1 : 1),
Jedan primjerak prvog tipa entiteta može biti u vezi s najviše jednim primjerkom drugog tipa
entiteta, te takođe jedan primjerak drugog tipa može biti u vezi s najviše jednim primjerkom prvog
tipa.
2. Jedan-ka-mnogo (1 : n)
Jedan primjerak prvog tipa entiteta može biti u vezi s 0, 1 ili više primjeraka drugog tipa entiteta, no
jedan primjerak drugog tipa može biti u vezi s najviše jednim primjerkog prvog tipa.
3. Mnogo-ka-mnogo (M : N)
Veza m:n znači da jedan primjerak prvog tipa entiteta može biti u vezi s 0, 1 ili više primjeraka
drugog tipa entiteta, te takođe jedan primjerak drugog tipa može biti u vezi s 0, 1 ili više primjeraka
prvog tipa.
Na Slici 2.13 dato je nekoliko ilustracija koje pokazuju različite tipove kardinalnosti i različite načine
njihovog predstavljanja.
Veza m:n je veza (više prema više) koja se u modelima vrlo često javlja, a ne može da se direktno
implementira u relacionom modelu baze podataka.
Problem veze m:n između dva entiteta se prevazilazi "razbijanjem" ove veze na dvije veze tipa l:n. Ova
veza ne može da se direktno realizuje u relacionim bazama podataka, već mora posredno preko još jedne
tabele, kao što je prikazano na Slici 2.13.
Kardinalnost je pojam koji označava brojnost, pa se govori i o kardinalnosti relacije (entiteta), atributa i
veze, što može dovesti do zabune.
34
2.10 Dvanaest pravila koji određuju relacioni sistem (Je li Kod sujevjeran?)
12 Kodovih pravila čini skup od trinaest pravila koja je predložio Edgar F.

Kod11, sa ciljem da definiše šta je potrebno da poseduje jedan sistem za
manipulaciju bazom podataka da bi ga mogli smatrati relacionim (RDBMS).
Kod je sročio ova pravila kao deo lične potrebe da spreči razbijanje svoje vizije
relacione baze podataka, s obzirom da su prodavci baza podataka nastojali
početkom osamdesetih godina dvadesetog vijeka da zapakuju postojeće proizvode
u relacionu oblandu. Pravilo broj 12 je posebno bilo navedeno da se suprotstavi
takvim nastojanjima.
Edgar Frank Codd
(Engleska, 1923. – 2003.)
dok je radio za IBM, stvorio je relacioni model za upravljanje bazom podataka
0. Sistem se mora kvalifikovati kao relacioni, kao baza podataka, i kao sistem za manipulaciju.
Da bi sistem nazvali relacionim sistemom za manipulaciju bazom podataka (RDBMS), on isključivo
mora koristiti svoje relacione mogućnosti da upravlja bazom podataka.
1. Pravilo informacije:
Sve informacije u bazi podataka moraju biti predstavljene na jedinstven način, svojim vrijednostima
u kolonama u okviru redova tabela.
2. Pravilo garantovanog pristupa:
Svi podaci moraju biti dostupni bez dvosmislenosti. Ovo pravilo je u suštini reformulacija osnovnog
zahtjeva za postojanjem primarnih ključeva. Ono traži da je svaka pojedinačna vrijednost u bazi
logički adresibilna navođenjem naziva tabele koja je sadrži, naziva kolone u kojoj se nalazi i
vrijednosti primarnog ključa reda koji je sadrži.
3. Sistematično tretiranje null vrijednosti:
Sistem mora dozvoljavati da svako polje može, po potrebi, ostati prazno (ili imati vrijednost null).
Posebno, mora podržavati predstavljanje "informacija koje fale ili se ne mogu primjenti" koje je
sistematično, različito od svih regularnih vrijednosti (na primer, "različito od nule i bilo kog drugog
broja," u slučaju brojevnih vrijednosti), i nezavisno od tipa podataka. Takođe se naglašava da takve
reprezentacije sistem mora tretirati dosljedno.
4. Aktivni, uvijek dostupan katalog zasnovan na relacionom modelu:
Sistem sadrži opis baze podataka na logičkom nivou u vidu tabela, tj. relacioni katalog dostupan
autorizovanim korisnicima kroz upotrebu njihovog standardnog jezika za upite. To znači da korisnici
moraju biti u mogućnosti da pristupe strukturi baze podataka (katalogu) koristeći isti jezik za upite
kojim se služe da bi pristupili samim podacima.
5. Pravilo razumljivog podjezika:
Sistem mora da podržava bar jedan relacioni jezik koji
(a) Ima linearnu sintaksu,
(b) može da se koristi i interaktivno i u okviru aplikativnih programa,
(c) podržava operacije definisanja podataka (uključujući definisanje pogleda), operacije
manipulisanja podacima (ažuriranje podjednako kao i izdvajanje), pravila integriteta i autorizaciju,
kao i operacije manipulisanja transakcijama (begin, commit, i rollback).
6. Pravilo ažuriranja pogleda:
Sve poglede koje je teorijski moguće ažurirati, ažurira sistem.
7. Unošenje, ažuriranje i uklanjanje podataka na nivou skupova:
Sistem mora da podržava skupovne insert, update, i delete operatore. To znači da se informacije iz
relacione baze mogu izdvajati u skupovima koje čine podaci iz više redova i više tabela. Ovo pravilo
traži da operacije dodavanja, ažuriranja i brisanja budu primjenjive na bilo koji skup podataka koji se
može izdvojiti iz baze, a ne samo na pojedinačni red u jednoj tabeli.
8. Fizička nezavisnost podataka:
Promjene na fizičkom nivou (način na koji se čuvaju podaci, da li su u pitanju nizovi ili povezane
liste itd.) ne smiju zahtjevati promjene aplikacija zasnovanih na datoj strukturi.
11
izvor wikipedija prema Codd, Edgar Frank (14 October 1985), "Is Your DBMS Really Relational?", ComputerWorld.
35
9. Logička nezavisnost podataka:

Promjene na logičkom nivou (tabela, kolona, redova, i tako dalje) ne smiju zahtjevati promjene
aplikacija koje su zasnovane na toj strukturi. Mnogo je teže postići logičku nego fizičku nezavisnost
podataka.
10. Nezavisnost od pravila integriteta:
Pravila integriteta moraju biti definisana nezavisno od aplikativnih programa i sačuvana u katalogu.
Mora biti predviđena mogućnost njihove izmjene u bilo kom trenutku bez nepotrebnog uticanja na
postojeće aplikacije.
11. Nezavisnost od distribucije:
Distribucija dijelova baze na različite lokacije mora biti nevidljiva za korisnike baze. Postojeće
aplikacije moraju nastaviti da rade:
(a) kada se prvi put uvodi distribucija baze; i
(b) pri bilo kojoj sledećoj distribuciji podataka u sistemu.
12. Pravilo zaštite podataka:
Ako sistem podržava upotrebu jezika koji rade na niskom nivou (manipulacija jednim slogom u
datom trenutku), onda oni ne mogu biti korišćeni za napad na sistem, u smislu zaobilaženja pravila
integriteta ili relacione sigurnosti.
2.10.1 Sistemski tretman „NULL“ vrijednosti
Potpuno relacioni sistem za upravljanje bazom podataka obavezno sistemski podržava predstavljanje
informacija koje nedostaju u bazi, upotrebom tzv. Null vrijednosti, nezavisno od tipa podataka.
Null vrijednost je specifičan indikator različit od praznog niza karaktera ili niza “blankova” i različit
od nule ili bilo kog drugog broja.
RDBMS obezbjeđuje jedinstvenu prezentaciju Null vrijednosti, a na taj način i jednostavno rukovanje tim
vrijednostima. Vrijednost Null može biti potencijalna vrijednost svake kolone bez obzira na njen tip, osim u
slučaju kad se izričito zahtjeva da vrijednosti u nekoj koloni ne smiju biti nedefinisane (dodatno ograničenje
NONULL). Izuzetak predstavljaju kolone primarnog ključa koje, kao identifikatori zapisa u tabeli, ne
smiju uzeti Null vrijednost.
2.10.2 Neprekidan pristup dinamičkom katalogu relacionog modela
Relacioni sistem posjeduje katalog (riječnik) podataka koji se na logičkom nivou predstavlja na isti način
kao i sami podaci, tako da ovlašćeni korisnici mogu primjenjivati jedinstveni relacioni jezik za pretragu
ovih meta-podataka.
Pod pojmom "katalog" podrazumjeva se direktorij u kojem se nalaze sistemske definicije podataka. Uvidom
u katalog podataka može se saznati koje kolone posjeduju određene tabele, koja su ograničenja definisana,
kao i druge informacije koje se odnose na sistemske tabele. U slučaju distribuiranih baza podataka, katalog
treba da sadrži podatke o lokaciji svakog dijela baze.
Katalog nazivamo “dinamičkim” zbog činjenice da definicije podataka koje se mogu vidjeti odgovaraju
upravo tekućem stanju u bazi podataka. Bez obzira na to koji korisnik, na kojoj lokaciji, ili u kom dijelu
opisa baze napravi neku izmjenu, novo stanje će biti dostupno za čitanje svim ovlašćenim korisnicima.
“On line” pristup katalogu praktično znači da je trenutnom stanju opisa baze obezbeđen neprekidan pristup.
Međutim, sve dok se stanje u opisu baze konačno ne promjeni, ovlašćenim korisnicima je vidljivo stanje
prije promjena. Naime, u relacionoj bazi sve operacije koje mjenjaju opis podataka započinju i završavaju se
određenim naredbama kojima se sistem obaveštava da je ažuriranje kompletno. “On line” uvidom ne vidi se
ni jedna izmjena koja nije konačna.
Važna je činjenica da pravo pristupa opisu baze imaju samo za to ovlašćeni (autorizovani) korisnici.
36
2.10.3 Fizička nezavisnost
Relacioni sistemi u obavezi su da zadovolje pravilo fizičke nezavisnosti čija je suština u sljedećem:
aplikacioni program i aktivnosti na terminalima ostaju neizmjenjeni kada se promjeni fizička organizacija
baze ili fizički metod pristupa podacima.
Aplikacije i programi rukuju podacima isključivo na semantičkom i logičkom nivou. Sama fizička
organizacija podataka predstavlja internu stvar sistema i ima uticaja jedino na performanse (brzinu pristupa
podacima, odziv sistema). Neophodno je da u sistemu postoji oštra granica između logičkog modela
podataka i fizičkog razmještaja podataka na mediju.
Kreiranje i brisanje indeksa nad nekom tabelom iz baze, ne smije imati uticaja na logičku strukturu programa
i naredbi. Kod nerelacionih sistema za upravljanje bazom podataka sami programi bi morali pretrpjeti
izmjene u zavisnosti od postojanja indeksa nad određenim tabelama.
Navedeno pravilo omogućava da se uoče dvije osnovne grupe korisnika u sistemu:

 projektanti i programeri,
 administratori baze podataka.
Uloga projektanata i programera je da se bave logičkim dizajniranjem i programiranjem, dok se
administratori baze, između ostalog, bave i održavanjem interne organizacije podataka u sistemu. Osnovna
komponenta koja u aktuelnim relacionim sistemima obezbeđuje fizičku nezavisnost je tzv. optimizator SQL
naredbi.
Optimizator za svaku SQL naredbu određuje optimalan plan izvršenja u smislu vremena odziva i ukupnog
utroška resursa sistema. Sam proces optimizacije odvija se u trenutku izvršenja naredbe, a sastoji se od
analize dostupnih indeksa i načina pristupa podacima. Plan izvršavanja naredbe za koji se predviđaju
najbolje performanse u obradi bira se na osnovu heurističkih pravila ili statističkih podataka o bazi.
2.10.4 Logička nezavisnost
Kada se na tabelama baze izvrše izmjene koje ne izazivaju gubljenje podataka ili logička oštećenja,
aplikacioni programi i aktivnosti na terminalima ostaju logički neoštećeni. Ukoliko RDBMS ispunjava uslov
ažuriranja pogleda onda će bez problema moći da zadovolji i pravilo logičke nezavisnosti.
Kada spajamo dvije tabele mogućnost ažuriranja pogleda nad novom tabelom uslov je za očuvanje logičke
nezavisnosti.
Logička, kao i fizička nezavisnost, za posljedicu imaju jednu veoma važnu prednost koju relacioni sistemi
pokazuju u odnosu na nerelacione. Prednost se sastoji u tome što greške u početnom dizajnu modela
podataka nemaju teške posljedice i dozvoljavaju naknadne korekcije. Projektanti u tom smislu mogu da
bez prevelikog opterećnja kreiraju inicijalne modele podataka, a da ih kasnije, čak i u poodmakloj fazi
implementacije aplikacije, ponovo dorađuju i prilagođavaju novim zahtjevima.
2.10.5 Integritetska nezavisnost
Sva pravila integriteta definišu se u okviru definicije baze podataka i čuvaju se u katalogu podataka, a ne u
aplikacionim programima.
Integritet podataka djeli se na 4 kategorije:
- integritet entiteta,
- integritet domena,
- referencijalni integritet, i
- korisnički definisan integritet.
Integritet entiteta podrazumeva da svaka vrijednost primarnog ključa mora biti jedinstvena na nivou cijele
relacije. Osim toga, mora biti ispunjen uslov da ni jedna stavka u koloni primarnog ključa ne smije imati
NULL vrijednost.
37
Integritet domena određuje skup dozvoljenih vrijednosti kolone. Održavanje integriteta domena postiže se
navođenjem dozvoljenog tipa podataka, dozvoljenog formata za unos podataka, ili zadavanjem skupa
mogućih vrijednosti.
Referencijalni integritet odražava definisane odnose (relacije) među tabelama kada se u njih dodaju ili se iz
njih brišu zapisi.
Korisnički integritet omogućava definisanje specifičnih poslovnih pravila. Naime, za bazu podataka mogu
postojati dodatna ograničenja, formirana na osnovu određenih pravila poslovanja, koja definišu važeće
podatke u bazi.
RDBMS treba da obezbjedi definisanje svih navedenih kategorija integriteta podjezikom relacionih
podataka. Kada se pravila integriteta jednom definišu ona sprečavaju upis podataka koji ne zadovoljavaju te
definicije (nekonzistentni podaci).
U slučaju promjene pravila integriteta dolazi do izmjene jednog ili više iskaza ograničenja u katalogu
podataka, ali logička struktura programa i aktivnosti na terminalima ostaju neizmjenjeni.
Jedino moguće sredstvo za čuvanje integriteta baze podataka, kod postojećih relacionih sistema, je korišćenje
tzv. okidača (Triggers). Okidač je pokretač procedure koja se automatski poziva kad god dođe do
dodavanja, ažuriranja ili brisanja podataka u tabeli.
Okidač je objekat baze koji se čuva u katalogu podataka i svaki je pojedinačno pridružen jednoj tabeli, pri
čemu se navodi koje od operacija dodavanja, ažuriranja ili brisanja izazivaju njegovo izvršenje.
Tako se, na primer, za bazu podataka tekućih računa građana u nekoj banci može definisati okidač koji se
izvršava prilikom brisanja slogova iz tabele, a ima ulogu da onemogući brisanje računa čije stanje nije ravno
nuli.

2.11 Tabelarna terminologija
Za kraj ovog poglavlja u Tabeli 2.3 dajemo jednostavan pregled termina koji se koriste u relacionoj algebri i
onih koji su uobičajeni u tabelarnoj terminologiji kod većine programskih jezika koji podržavaju relacione
baze (npr. Access), a koji često izazivaju zabunu.
Terminologija relacione baze Tabelarna terminologija

podataka
relaciona baza podataka skup tabela
relacija jedna tabela
atribut (svojstvo) zaglavlje kolone u tabeli
slog red od podataka u tabeli
mjera veličine skupa određenih objekata broj redova u tabeli
stepen broj kolona u tabeli
domen postavka važećih vrijednosti za podatke u koloni
MOV (Model objekti veze) ili ER model objekti-veze ili Entity-Relationship Model
Tabela 2.3 Tabelarna i standardna terminologija relacionih baza
38

T1 2 Modeli UvodBP PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T1 2 Modeli UvodBP PDF

Uploaded by

Copyright:

Available Formats

Miroslav Mihaljišin

PRIRUČNIK SAMO ZA INTERNU UPOTREBU

kompilacija sadržaja sa sajta razno.sveznadar.info i knjige Računarstvo i informatika 2.

1.1 Terminolgija: Šta je ustvari model

U govornom jeziku ima više značenja, pa ćemo navesti neka:

Modeliranje (ili modelovanje) je proces korišćenja modela umjesto realnog sistema.

1.1.1 Pojam sistema i realnog sistema

Realan sistem je uređen i međuzavisan skup objekata koji formiraju cjelinu.

Slika 1.1 odnos realnog svijeta, sistema i modela

1.1.2 Odnos modela, realnog sistema i teorije

Slika 1.2 Teorija kao poveznica realnog sistema i modela

Navedimo glavne elemente i osobine sistema koje ga određuju:

Projektovanje i analiza sistema znači definisanje svih ovih elemenata.

1.1.3 Cilj modeliranja

1.1.4 Procedure modeliranja

Elementarna procedura modeliranja realizuje se kroz 3 koraka:

1.2 Metodologija i klasifikacija modela

Iste metode pojavljuju se u različitim klasifikacijama.

1.3 Podjela modela na osnovu formalizma i detaljnosti

Neformalni (ili slobodni) opis modela opisuje sistem tako da definiše:

To ima za posljedicu da neformalni model može biti:

1.1.2 Formalni opis modela

1.1.3 Savršeni i referentni modeli

Slika 1.3 Ilustracija koja pokazuje odnos OSI modela i

1.4 Formalna podjela modela

Slika 1.4 Standardna klasifikacija modela

1.4.1 Fizički modeli

Slika 1.5 Odnos i interakcija fizičkog i apstraktnog modela

Napomenimo da je korištenje fizičkih modela ograničeno troškovima i vremenom izrade.

1.4.2 Apstraktni modeli

Slika 1.6 Strukturna šema mentalnog modela

1.4.2.1 Opisni (verbalni) modeli

Opisni modeli su široko primijenjeni i koriste se u svakidašnjim aktivnostima.

1.4.2.2 Analogni modeli

Slika 1.7 Analogija između hidrauličkog kola i elektronskog kola

1.4.2.3 Matematčki modeli

1.4.2.4 Konceptualni modeli

Konceptualni model sadrži:

Slika 1.9 Primjer konceptualnog modela koji koristi XML5 i UML

1.4.2.5 Računarski i simulacioni modeli

Podjela prema vrsti promjenljivih u modelu:

Podjela prema načinu na koji se stanje modela mijenja u vremenu:

Slika 1.10 Osnovni elementi koji čine simulaciju

1.5.2 Modeliranje i simulacija

Modeliranje i simulacija predstavljaju složenu aktivnost koja sadrži tri elementa:

1.5.3 Životni ciklus simulacije: Koraci simulacionih procesa

Životni ciklus simulacije ćemo predstaviti nizom koraka koji

Ove korake su definisali formulisali Law i Kelton 1982. godine,

Slika 1.11 Koraci simulacionog procesa

1.5.4 Objedinjeni jezik modeliranja – UML

Slika 1.12 Osnovne kategorije korisnika UML-a

1.6 Simulacija dinamičkih sistema

Navešćemo osnovne strukture koje određuju matematičke modele:

1.6.1 Statički i dinamički sistemi

1.6.2 Deterministički i stohastički sistemi

1.7 Vrste analize modela

1. Šta-ako (What-if) analiza

Slika 1.13 Poziv Scenario menadžera iz Excela

2. Traženje cilja (Goal seeking ili How can)

1.8 Razvoj modeliranja i simulacije

Hermann Schichl, u svom radu Models and History of

Slika 1.27 Teslin model daljinski upravljanog čamca

Slika 1.28 Integracija 3D printera i softvera za modeliranje