Normalizacija baza podataka

Podgorica, maj 2019. godina

Sadržaj

1.Uvod..................................................................................................................................................1
2. Istorija baze podataka.......................................................................................................................2
3.Normalizacija baze podataka...........................................................................................................3
3.1. Normalizacija kroz primjer.......................................................................................................4
4. Metode normalizacije...................................................................................................................6
5. Normalne forme...........................................................................................................................8
6. Primarni ključ...............................................................................................................................9
6.2. Odabir primarnog ključa........................................................................................................9
7. Praktičan primjer normalizacije.................................................................................................11
7. 1.Svođenje modela na prvu normalnu formu..........................................................................12
7.2. Svođenje modela na drugu normalnu formu........................................................................13
 7.3. Svođenje modela na treću normalnu formu.........................................................................14
8. Razlozi zbog kojih se može odustati od normalizacije........................................................16
9. Zaključak....................................................................................................................................17
12. Literatura......................................................................................................................................18
 1.Uvod

Baza podataka je skup informacija (podataka) koje su prikupljene u određenom, obično

dužem, vremenskom periodu. Totalno integrisani informacioni sistem je nedostižan ili nepotreban.
Ono sto je potrebno je:
 dovoljno slobode kako bi korisnici mogli da razvijaju svoju inicijativu u kreiranju sistema
koji im je potreban.
 postovanje pravila koja će omogućiti da razmjenjuju podatke sto podrazumjeva zajedničku
mrežu za prenos, zajednički model podataka i njihov standardni oblik.
Model podataka je jednostavan način predstavljanja skupa podataka njegove interpretacije
preko strukture podataka, skupa ograničenja i skupa operatora, o čemu je vođeno računa o daljem
izlaganju.
Bazom podataka upravlja poseban softver, tako zvani sistem za upravljanje BP. To je skup
programskih proizvoda, koji ima zadatak da omogući realizaciju, održavanje i korišćenje BP.Sadrži
u sebi sredstva za opisivanje šeme BP i skup operatora za prevodjenje BP iz jednog stanja u drugo.
U oblasti projektovanja relacionih baza podataka, normalizacija predstavlja sistematski metod
za osiguravanje da je struktura baze podataka pogodna za upite opšteg tipa, i da ne ispoljava izvesne
neželjene karakteristike - anomalije unošenja, ažuriranja i brisanja - koje bi mogle da dovedu do
gubitka integriteta podataka. E. F. Kod, izumitelj, relacionog modela, je uveo koncept normalizacije
kao i pojam koji je danas poznat kao prva normalna forma 1970. godine.
 2. Istorija baze podataka

slika1.unos podataka
slika 2. skadištenje i pretraživanje

slika 3. obrada zahtjeva slika 4. sortiranje

Nastanak baza podataka se vezuje za Herman-a Holerith-a. On je 1884. god prijavio patent – sistem
za automatsku obradu podataka (AOP).
AOP je sluzio za popis stanovništva u SAD. Podaci su bili na bušenim karticama koji su se ručno
ubacivali u uredjaj za očitavanje, a obrada podataka vršila se prebrojavanjem. Dotadašnja obrada
podataka popisa trajala je 10-ak godina, a sa ovim izumom vreme obrade smanjilo se na šest
nedelja.
Ideja AOP-a je bila da se svaki stanovnik SAD prestavnja sa nizom od 80 karaktera – ime, godište
itd.
 3.Normalizacija baze podataka

Normalizacija baze podataka je proces efikasnog organizovanja podataka u bazi podataka.

Normalizacija je tehnika dizajna baze podataka kojom se na osnovu izvjesnih kriterijuma određuje
sadržaj tabela (tj.koje kolone treba da obuhvataju tabele i njihova struktura ključa).
Normalizacija baze podataka je postupak kojim se iz danog modela bez podataka nastoji
otkloniti potreba za višestrukim ponavljanjem istih podataka (redudansa podataka). Naime, osim
što (nekorisno) troši prostor, višestruko zapisivanje istog podatka otežava (i/ili onemogućava)
mijenjanje sadržaja baze podataka.
Osnovna ideja je da se eliminiše nepotrebno dupliranje ne-ključnih podataka u tabelama te
da se tako smanji veličina prostora koju baza zauzima na disku i da su podaci logično uskladišteni.
Cilj normalizacije možemo izraziti riječima: Baza podataka treba biti oblikovana tako da se
svaki podatak upisuje samo jednom (ili: samo na jednom mjestu). Dva osnovna cilja procesa
normalizacije su:
1. Eliminisanje redudantnih podataka (skladištenje istih podataka na više mjesta u bazi podataka)
2. Osiguravanje da su zavisnosti podataka logične (u jednoj tabeli se nalaze samo povezani podaci)
Odnosno, osnovni cilj relacionog modela podataka je da odgovarajuća baza podataka koja:
1. ne sadrži redundansu,
2. se može jednostavno koristiti i mjenjati.

Pod redundansom podrazumjevamo višestruko memorisanje iste informacije u bazi podataka.

Potpuno eliminisanje redundanse podataka u bazi podataka je skoro nemoguće ostvariti. Realni cilj
pri projektovanju baze podataka je kontrolisana redundansa podataka.
Bitna osobina koja se očekuje od normalizacije je reverzibilnost tj. da ne smije doći do gubitka
informacija sadržanih u polaznoj relaciji.
Polazeći od skupa normalizovanih relacija, mora biti moguća rekonstrukcija polazne
nenormalizovane relacije.
Jedan od ključnih ciljeva relacione baze podataka je da se spriječi nepotrebno dupliranje podataka.
U stvari, ovo je jedan od glavnih razloga zašto se koriste relacione baze podataka, a ne fajlovi, koji
podatke skladište u jednoj tabeli.
Ponekad se klasa ili objekat dizajnira korektno (zavisi koji model podataka se koristi), a u
relacionoj šemi se tek uoči problem
 3.1. Normalizacija kroz primjer

slika 5. normalizacija kroz primjer

Jednostavno korišćenje i mijenjanje podataka podrazumijeva prije svega sprečavanje anomalija

održavanja podataka. Pod anomalijama održavanja podataka podrazumijevamo:
• anomaliju dodavanja,
• anomaliju brisanja,
• anomaliju promjene.

Svaka od ovih anomalija manifestruje se na specifičan način, a njihov zajednički uzrok je

povezivanje opisa svojstava različitih objekata u jedan zapis u bazi podataka.

Anomalija dodavanja (unošenja) javlja se u onim slučajevima kada su informacije o svojstvima

jednog objekta memorisane u bazi podataka kao dio opisa nekog drugog objekta. Na primjer,
vidimo da su ID, ime i adresa kupca uključeni u račun.
Ako bismo željeli da napravimo relaciju iz ovog pogleda kakav jeste, a nakon toga i tabelu iz
relacije, otkrili bismo da se novi kupac ne može insertovati u bazu ukoliko nešto nije kupio. Ovo
je stoga što svi podaci vezani za kupca uključeni u sam račun.

Anomalija brisanja je inverzija anomalije dodavanja. Odnosi se na situaciju gdje brisanje podataka
vezanih za određeni entitet uzrokuje neplanirani gubitak podataka koji karakteriše drugi entitet.
U slučaju našeg računa, ako odlučimo da obrišemo posljednji (jedini preostali) račun koji pripada
određenom kupcu, izgubićemo sve podatke vezane za tog kupca.

Anomalija ažuriranja se odnosi na situaciju gdje ažuriranje jednog podatka zahtijeva ažuriranje
više n-torki (vrsta) podataka.
U primjeru našeg računa, ako bismo htjeli da promijenimo adresu kupca, morali bismo je
promijeniti na svakom računu tog kupca. Ovo je zbog toga što bi adresa kupca bez primjene
normalizacije bila redundantno smještena na svakom računu kupca.

4. Metode normalizacije
 U najopštijem smislu, normalizacija je postupak kojim se prozivoljna, nenormalizovanja
relacija transformiše u skup manjih normalizovanih relacija. Normalizacija se izvodi na osnovu
zavisnosti koje iskazuju zakonitosti koje vrijede u svijetu čiji model podataka gradimo.
Bitna osobina koja se očekuje od normalizacije je reverzibilnost, tj. da ne smije doći do
gubitaka informacija sadržanih u polaznoj relaciji. Polazeći od skupa normalizovanih relacija, mora
biti moguća rekonstruckija polazne nenormalizovane relacije.

Postoje sljedeće dvije tehnike normalizacije:

 Vertikalna normalizacija,
 Horizontalna normalizacija.

Vertikalna normalizacija je postupak kojim se proizvoljna nenormalizovana šema relacije

transformiše u skup manjih i normalizovanih šema relacija. Iz relacione šeme se izdvajaju obilježja
koja stoje u nedozvoljenim odnosima sa ostalim obilježjima u šemi.
Od izdvojenih obilježja formira se nova šema relacije. Transformacija relacije zadate na relacionoj
šemi neposredna je posljedica normalizacije relacione šeme.
Vertikalna normalizacija zasniva se na operacijama projekcije i prirodnog spajanja. Pomoću
operacije projekcije relaciju vertikalno razbijamo na dvije ili više manjih relacija.
Pri tome, dolazi do cijepanja svake pojedine n-torke u relaciji. Opearciju prirodnog spajanja
koristimo da bi dokazali reverzibilnost, tj. da bi rekonstruisali polaznu, nenormalizovanu relaciju.

Horizontalnom normalizacijom relacija se rastavlja na podskupove n-torki fragmente

relacije koji zadovoljavaju određene uslove.
Horizontalna normalizacija zasniva se na operacijama sekcije i unije. Sama tehnika je još uvijek u
razvoju a značajnu ulogu mogla bi odigrati kod distribuiranih baza podataka.
Kod distribuiranih baza podataka relacija ne mora u potpunosti biti memorisana na jednoj lokaciji.
Fragmenti relacije memorišu se na pojedinim lokacijama, što bi se moglo koristiti za samu
normalizaciju.

U daljim razmatranjima normalizacije ograničićemo se samo na vertikalnu normalizaciju. Postoje

sljedeće dvije varijante vertikalne normalizacije:
 normalizacija dekompozicijom,
  normalizacija sintezom

Normalizacija dekompozicijom započinje od proizvoljne nenormalizovane relacije šeme i izvodi

se u koracima. Svakim korakom normalizacije relaciona šema prevodi se u višu normalnu formu,
tako da se polazni skup obilježja dijeli u dva skupa i od svakog formira posebna relaciona šema.
Svaki korak normalizacije mora biti reverzibilan.

Normalizacija sintezom polazi od skupa obilježja i od skupa zavisnosti zadatih na tom

skupu obilježja. Postupak se ne izvodi u koracima već se direktno formiraju relacione šeme koje
ispunavaju uslove zahtjevane normalne forme.

5. Normalne forme
 Pri dizajniranju baze podataka potrebno je donijeti odluke o tome koje tablice načiniti, koja
će polja te tablice sadržavati, te kakve veze između tablica treba uspostaviti.

Normalizacija je postupak primjene niza pravila kojima se osigurava optimalna struktura

baze podataka. Normalne forme su niz primjene tih pravila.

Svakom slijedećom normalnom formom dobiva se bolja strukutra podataka nego u prethodoj
normalnoj formi. Za nas su najznačajnije prve tri normalne forme:

Prva normalna forma zahtjeva atomičnost polja tablice i da svi zapisi moraju imati isti broj
polja. To znači da se u istom polju ne mogu zapisivati ime i prezime.
Razlog postojanja ovog pravila je to što je nemoguće pretraživati ili sortirati podatke prema imenu
ili prezimenu ukoliko se obje vrijednosti nalaze u istom polju.
Slijedeći zahtjev koji tablica mora zadovoljiti da bi bila u 1NF je ne sadržavati vrijednosti koje se
ponavljaju.

Druga normalna forma zahtjeva da je zadovoljena 1NF i sva polja moraju biti jednoznačna
i u potpunosti zavisiti o glavnom ključu(engl. primary key).
Drugim riječima, u svakoj tablici moraju se zapisivati podaci o samo jednom subjektu. Primjer
nepoštovanja 2NF je tablica u kojoj se zapisuju podaci o narudžbi zajedno sa podacima o osobi koja
je obavila narudžbu.
Kako bi tablicu prebacili u 2NF potrebno je takvu tablicu razdvojiti u dvije tablice. Postupak
razdvajanja u dvije tablice zove se dekompozicija.

Treća normalna forma zahtjeva da je zadovoljena 2NF i sva polja koja nisu dio glavnog
ključa ne smiju međusobno zavisiti jedno o drugom.
Treba izbaciti sva izračunavanja u tablici, npr. kada uz polja [Cijena] i [Količina] želimo pomnožiti
te podatke i postaviti u polje [Ukupno].
Problem se javlja kada ažuriramo polje [Cijena] ili polje [Količina], jer se polje [Ukuono]
([Cijena]* [Količina]) ne ažurira automatski. Zato ga treba izbaciti po 3NF.

6. Primarni ključ

Primarni ključ (PRIMARY KEY) je ključno polje tabele kojim se kontroliše način na koji se
informacije povezuju sa drugim tabelama.Primarni ključ na jedinstven način definiše zapis. Matični
broj je ključno polje za povezivanje tabela; ključna polja moraju biti istog tipa.

Primarni ključevi su najčešće ID,tipa AutoNumber. Primarni ključ se postavlja na jedno ili
više polja u tabeli. Njihova uloga je da onemogućavaju ponavljanje podataka u tim poljima. Njima
osiguravamo jedinstvenost svih podataka u poljima na koja smo ih postavili (jedan ključ = nema
duplikata u zaključanom polju). Dakle polja poput JMBG, ID, Člasnki broj,Šifra robe, itd. su polja
na koja svakako treba postaviti ključ jer ti se podaci ne smiju ponavljati.

Ako u jednoj tabeli na više polja postavimo ključeve tada kreiramo složeni ključ. Sada svako
polje unutar složenog ključa može i ne mora imati duplikate, ali ne mogu postojati dva zapisa u
jednoj tabeli s istom kombinacijom podataka tj. da imaju sve podatke identične u sva tri zaključana
polja

6.2. Odabir primarnog ključa

Prvi korak u normalizaciji je odabir primarnog ključa između svih jedinstvenih

identifikatora koje pronađemo u relaciji.
Podsjetimo se da jedinstveni identifikator predstavlja jedan ili kolekciju više atributa koji
jedinstveno identifikuju svaku pojavu (n-torku) u relaciji.
Vrlo često je to samo jedan atribut.
Ukoliko jedinstveni identifikator ne može biti u vidu jednog atributa, možemo nadovezati nekoliko
atributa da formiramo identifikator.

Važno je razumjeti da kada je jedinstveni identifikator sastavljen od više atributa, sami atributi se ne
kombinuju, tj. oni i dalje postoje kao nezavisni atributi i postaće pojedinačne kolone u tabeli, ili
tabelama, kreiranoj iz naših normalizovanih relacija.

Ponekad, ali rijetko, dešava se da ne postoji smislen skup atributa u relaciji koji može poslužiti kao
jedinstveni identifikator. Ipak, kada se ovo desi, moramo izmisliti jedinstveni identifikator, često sa
vrijednostima dodijeljenim sekvencijalno ili slučajno, tokom dodavanja instance entiteta bazi
podataka.

Ova tehnika predstavlja izvor jednistvenih identifikatora kao što su ID zaposlenih, broj tablica
vozila, broj motora vozila, itd.
Jedinstvene identifikatore koji imaju stvarno – smisleno značenje nazivamo prirodnim
identifikatorima, dok ove druge (uključujući one koje moramo izmisliti) nazivamo surogatnim ili
vještačkim identifikatorima.

Moramo imati na umu da izabrani identifikator mora uvijek biti jedinstven, tj. ako postoji bar jedan
slučaj gdje on nije jednistven, ne možemo ga koristiti.
Primjer loše odabranog primarnog ključa je kombinacija: imena i prezimena; očevog i majčinog
imena i datuma rođenja...

Ponekad relacija ima više od jednog mogućeg jedinstvenog identifikatora. Kada se ovo desi, svaku
mogućnost nazivamo kandidatom. Kada smo identifikovali sve moguće kandidate za relaciju,
moramo izabrati jednog kandidata koji će biti primarni ključ relacije.
Odabir primarnog ključa je suštinski za proces normalizacije, jer sva pravila normalizacije koriste
primarni ključ
Kriterijumi za odabir primarnog ključa među kandidatima su (prvo ide najvažniji):
 Ako postoji samo jedan kandidat, izaberi ga.
 Odaberi onog kandidata za kojeg je najmanje vjerovatno da će promijentiti svoju
vrijednost.
 Odaberi najjednostavnijeg kandidata. Onaj kandidat koji je sastavljen od najmanjeg
broja atributa se smatra najjednostavnijim.
 Odaberi najkraćeg kandidata. Ovo je čisto radi efikasnosti. Ako se primarni ključ može
pojaviti u mnogim tabelama kao spoljašnji ključ, često je dobro da se sačuva malo
prostora na ovaj način.

7. Praktičan primjer normalizacije

Daćemo primjer kako da od neuređene (nenormalizovane) baze dobijemo model u 3NF

formi. Krenućemo od jednostavne strukture; imamo spisak članova foruma koji imaju nekakvo
znanje o raznim materijama. Neki članovi znaju o muzici, neki o hardware-u dok se neki bolje
snalaze sa linux-om; naravno, postoje i oni koji vrlo dobro poznaju i hardware i muziku. Primjer
jednostavne tabele bi izgledao ovako:

slika 6. Tabela o podacima znanja članova

 Ovo je tipičan primjer loše dizajnirane baze sa samo jednom tabelom u kojoj se nalaze svi
podaci.
Ako želimo da saznamo koji korisnik zna “video” moramo proći kroz sve korsnike, provjeriti
sadržaj polja “znanje” i pregledati prilično nepregledno polje “znanje” te otkriti da li dotični
korisnik zna “video” ili ne.
Mane ovakve organizacije su očigledne (brzina, preglednost…) te je ovo vrlo nepraktičan način za
čuvanje informacija.

7. 1.Svođenje modela na prvu normalnu formu

Razdvajanje repetitivnih podataka u zasebne tabele našu strukturu dovodi u prvu normalnu
formu.
Iz našeg primjera (gdje je sve bilo nagurano u istu tabelu), dobijamo 2 odvojene tabele:

slika 7.Svođenje na prvu normalnu formu

 7.2. Svođenje modela na drugu normalnu formu

Ako pogledamo tabelu “ZNANJE” iz prethodnog primjera gdje smo sveli model na prvu
normalnu formu, primjetićemo da nam se podaci dupliciraju.

Za razliku od tabele “KORISNIK” gdje atribut KORISNIK_ID definiše slog tabele, u tabeli
KORISNIK slog definišu KORISNIK_ID i ZNANJE_ID atributi zajedno. Ovo u nekim slučajevima
može da ima smisla, ali u našem slučaju, gdje ime “znanja” realno nije ni u kakvoj relaciji sa
korisnikom i bezrazložno se multiplicira u tabeli, možemo zaključiti da nam se podaci “dupliraju
što se odražava na prostor potreban za čuvanje istih, otežava i usporava operacije sa bazom.

Ako na primjer želite da promjenite ime jednog “znanje” (na primjer želite da “Audio”
postane “Rad sa zvukom”) morate to ime promjeniti na više mjesta, umjesto samo na jednom
(anomalija pri
promjeni). Dalje, pretpostavite da “mali perica” ode sa foruma; u tom slučaju treba obrisati sve
slogove vezane za njega; u tom slučaju, potpuno će nestati referenca da je znanje “Linux” postojalo
na forumu (anomalija pri brisanju).

Da bi ste zaobišli ove anomalije, potrebna vam je druga normalna forma.

Da bi “razvili” našu bazu u drugu normalnu formu, potrebno je da razdvojimo atribute koji zavise
od oba ključa koji definišu tabelu “ZNANJE”. Rezultat će biti dvije tabele:
 slika 8.Svođenje na drugu normalnu formu

7.3. Svođenje modela na treću normalnu formu

Ako pogledamo malo bolje tabelu “KORISNIK” iz primjera za drugu normalnu formu,
vidjećemo da iako ispunjava i prvu i drugu normalnu formu, atribut “ŽIVI” nije direktno zavistan
od ID-a korisnika (primarnog ključa). Da bi postigli treću normalnu formu, taj podatak mora da se
odvoji u zasebnu tabelu. Zašto?
 Ako uzmemo na primjer da “mali žikica” napusti forum, te se slogovi koji njega definišu
obrišu, nestaće trag o “BIH” (anomalija pri brisanju) ili ako “Srbija” ponovo promjeni ime u “Uža
Srbija sa okolinom”, to ime moramo promjeniti na više od jednog mjesta (anomalija pri promjeni).
Razlaganje na treću normalnu formu zahjteva da podatak o “ŽIVI” prebacimo u zaseban entitet.

slika 9.Svođenje na treću normalnu formu

 8. Razlozi zbog kojih se može odustati od normalizacije

Za većinu praktičnih primjera dovoljno je relacije normalizovati do 3NF. Ponekad je potrebno neku
relaciju i dalje normalizovati do BCNF ili 4NF. Peta normalna forma, koja se takođe navodi u
literaturi, nije od praktičnog značaja.

Postoje razlozi zbog kojih ponekad možemo odustati od pune normalizacije.

Pogledajmo dva takva razloga.

1.Složeni atribut

Dešava se da nekoliko atributa u relaciji čine cjelinu koja se u aplikacijama nikad ne rastavlja na
sastavne djelove.
Na primjer, posmatrajmo relaciju KUPAC ( PREZIME IME, POŠTANSKI_BROJ, GRAD, ULICA
) . Strogo govoreći, GRAD je funkcionalno zavisan o POŠTANSKI_BROJ, pa relacija nije u 3NF.
No mi znamo da POŠTANSKI BROJ, GRAD i ULICA čine cjelinu koja se zove adresa.
Budući da se podaci iz adrese koriste i ažuriraju "u paketu", ne može doći do prije pominjanih
anomalija. Nije preporučljivo razbijati ovu relaciju na dvije.

2.Efikasno čitanje podataka

Normalizacijom se velike relacije razbijaju na mnogo manjih. Kod čitanja je često potrebno podatke
iz malih relacija ponovo sastaviti u veće n-torke. Uspostavljanje veza medu podacima u manjim
relacijama traje znatno duže nego čitanje podataka koji su već povezani i upisani u jednu veliku
relaciju.
Projektant baze podataka treba da procjeni kada treba provesti normalizaciju do kraja a
kada ne. Za tu procjenu je važno razumjevanje značenja podataka i načina kako će se oni
koristiti.
 9. Zaključak

Normalizacija baze podataka je proces efikasnog organizovanja podataka u bazi podataka.

Normalizacija je tehnika dizajna baze podataka kojom se na osnovu izvjesnih kriterijuma određuje
sadržaj tabela (tj.koje kolone treba da obuhvataju tabele i njihova struktura ključa). Normalizacija
baze podataka je postupak kojim se iz danog modela bez podataka nastoji otkloniti potreba za
višestrukim ponavljanjem istih podataka (redudansa podataka). Naime, osim što (nekorisno) troši
prostor, višestruko zapisivanje istog podatka otežava (i/ili onemogućava) mijenjanje sadržaja baze
podataka. Osnovna ideja je da se eliminiše nepotrebno dupliranje ne-ključnih podataka u tabelama
te da se tako smanji veličina prostora koju baza zauzima na disku i da su podaci logično
uskladišteni.
Cilj normalizacije možemo izraziti riječima: Baza podataka treba biti oblikovana tako da se
svaki podatak upisuje samo jednom (ili: samo na jednom mjestu). Dva osnovna cilja procesa
normalizacije su:
1. Eliminisanje redudantnih podataka (skladištenje istih podataka na više mjesta u bazi podataka) 2.
Osiguravanje da su zavisnosti podataka logične (u jednoj tabeli se nalaze samo povezani podaci)
Odnosno, osnovni cilj relacionog modela podataka je da odgovarajuća baza podataka koja:
1. ne sadrži redundansu,
2. se može jednostavno koristiti i mjenjati
12. Literatura

[1] https://razno.sveznadar.info/10-doc-PDF/Normalizacija.pdf
[2] http://www.vps.ns.ac.rs/Materijal/mat517.pdf
[3]https://www.ucg.ac.me/skladiste/blog_13294/objava_12986/fajlovi/Normalizacija
%20baza%20podataka.pdf
[4]https://www.mojwebdizajn.net/edukacija/uvod-u-baze-
podataka/prezentacije/normalizacija-baze-podataka.aspx
 Komentar_________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________

Pitanja na usmenom dijelu ispita:

1. ____________________________________________________________________________________
____________________________________________________________________________________
2. ____________________________________________________________________________________
____________________________________________________________________________________
3. ____________________________________________________________________________________
____________________________________________________________________________________

Ocjena rada: ______________________

Usmena odbrana rada: ______________________
Opšta ocjena: ______________________

Članovi komisije:
1. Mentor (ispitivač) ___________________
2. Stalni član ___________________
3. Predsjednik komisije ___________________

Datum:_________ 2019. god. Podgorica