BOSNA I HERCEGOVINA

FEDERACIJA BOSNE I HERCEGOVINE

TUZLANSKI KANTON
JAVNA USTANOVA MJEŠOVITA SREDNJA
ELEKTROTEHNIČKA ŠKOLA TUZLA

Projektovanje baze podataka

Advokatska kancelarija SHL

Prezime i ime: Asmir Zulić Razred: IVT1

Datum izrade: Ocjena:

Tuzla,decembar 2015 god.

Sadržaj:
1. ANALIZA POTREBA........................................................................................................................2

2. MODEL OBJEKTI-VEZE....................................................................................................................3

2.1 MODELIRANJE PODATAKA MODEL OBJEKTI – VEZE (TEORETSKE OSNOVE)................................3

2.2 DIJAGRAM OBJEKTI-VEZE.........................................................................................................6
2.3 OPIS OBJEKATA I VEZA.............................................................................................................6

3. RELACIONI MODEL........................................................................................................................8

3.1 UVOD........................................................................................................................................8
3.2 PREVOĐENJE MODELA OBJEKTI-VEZE U RELACIONI MODEL.......................................................9
3.2.1 PRVI KORAK..................................................................................................................................9
3.2.2 DRUGI KORAK.............................................................................................................................10

4. Relaciona šema................................................................................................................................. 12

1
2
1. Analiza potreba
Advokatska kancelarija Snobić, Hapić i Lafinaš (SHL) zabilježila je nagli porast u
poslovanju tokom zadnje decenije i razmatra potrebu za automatizovanim sistemom
naplate, tj. pravljenjem računa za učinjene usluge kako bi ih naplatili od svojih
klijenata. Za svaki slučaj koji advokatska kancelarija zastupa pred sudom žele
evidentirati podatke čiji opis slijedi.

Za svakog advokata koji radi u firmi evidentira se 5-cifreni jedinstven broj radnika i
cijena koja mu se plača za jedan sat rada. Postoji mnogo slučajeva (u advokaturi se
bave „slučajevima“, npr. ako želimo tužiti prodavnicu koja nam je isporučila pokvaren
dvd uređaj, za advokatsku kancelariju to je „slučaj“). Na jednom slučaju mogu raditi i
drugi advokati iz kancelarije, npr na nekim privremenim poslovima za koje je stručan
radi određen broj sati, ili u slučaju da je odgovorni advokat spriječen.

Svaki slučaj povezan je za jednog klijenta, a jedan klijent može imati više
slučajeva. Svaki slučaj može ima samo jednog odgovornog advokata, jedan advokat
može biti odgovorni advokat za više slučajeva.

Za većinu klijenata, SHL čuva slijedeće podatke: prezime, ime, adresu, telefon.
Za neke klijente SHL radi besplatno „pro bono“.

Neki od advokata zaposlenih u SHL imaju status „partnera“. Ostali advokati imaju
supervizora koji nadzire njihov rad. Supervizor za te advokata je također jedan od
advokata iz iste kancelarije u statusu partnera. Baza podataka treba da evidentira i
ove releacije, kako bi se mogli praviti izvještaji kao npr: ispisati sve slučajeve u
kojima je odgovorni advokat nadziran od strane supervizora Advokat Nr1.

Ovako bi izgledali podaci o jednom slučaju:

Broj slučaja: 001782

Klijent: Ime: Metro Real Estate Holding
Adresa: Armije RBiH 18, 75000 Tuzla
Telefon: 070 700 700
Osoba za kontakt: Lihvar Najmodavac
Datum otvaranja slučaja: 15.05.2011.
Datum zatvaranja slučaja: (u toku)
Opis: Klijent tuži najmoprimatelja zbog štete načinjene na iznajmljenoj nekretnini
Advokat: Jaza Jazavac (broj zaposlenog #00131)
Sati za naplatu: Jaza Jazavac (#00131) 30.05.2011 2.3 sata
Krempita Lisnat (#00132) 05.07.2011 3.0 sati
Maslanica Sasirom (#00139) 11.09.2011 0.8 sati

3
2. Model objekti-veze
2.1 Modeliranje podataka model objekti – veze (teoretske osnove)

Jedan od najvećih problema u procesu razvoja baze podataka je činjenica da

projektanti,programeri I krajnji korisnici na potpuno različite načine shvataju
podatke I načine njihove upotrebe, kao I procese iz posmatranog okruženja koje
treba model objekti veze modelirati. Da bi se obezbjedio precizan opis prirode
podataka I načina na koji se oni koriste, potrebno je proizvesti jasan model koji nije
striktno tehničke prirode. Najčešće korišteni model u praksi je model objekti veze
(MOV).

Glavna komponenta MOV pristupa je koncept entiteta (objekata I veza).

Entiteti obuhvataju objekte koji se nalaze u jednoj organizaciji, kao I veze među
objektima jedne organizacije.Ograničenja integriteta eniteta I veza čine važan dio
MOV opisa odnosno specifikacije.
– Na primjer profesor može da predaje jedno predavanje u određenom
vremenu u jednoj sali na fakuletu.

MOV modeliranje obuhvata:

– Skup entiteta (objekti I veze)
– Uočavanje ograničenja
– Definisanje ključeva MOV
– Grafička predstava (DOV diagram)
– Definisanje atributa
– Dizajn globalne šeme
– Svođenje globalne šeme na tabele (relacije)

Dijagram objekti-veze (DOV) je grafička prezentacija povezanih entiteta i

ograničenja koja čine dati dizajn odnosno projekat. Kao i kod ostalih vizuelno
orijentisanih dizajn metodologija, on pruža grafički sažetak strukture DOV baze
podataka koji je veoma koristan dizajneru:
– u procjenjivanju tačnosti, odnosno pravilnosti dizajna
– za savjetovanje sa kolegama i za objašnjavanje programerima koji će je
koristiti.

ER modeliranje je logičko modeliranje (logical data modeling). Razlikuje se

od fizičke realizacije baze podataka (physical data base design). U logičkom
modeliranju ne moraju se poznavati atributi, primarni niti spoljašnji ključevi.
Jednostavno se linijama spajaju entiteti. ER modeliranje ima sljedeći koncept: Od
generalnog ka pojedinačnom.
– Npr. ZAPOSLENI su u vezi sa ODJELJENJEM, a još uvjek ne znamo
atribute ova dva entiteta

Objekti mogu predstavljati entitete iz realnog svijeta, interfejse iz DTP,

strukture iz riječnika podataka, ali mogu biti i čisti fabrikati, koji samo treba da istaknu
povezanost različitih podataka pri procesiranju u sistemu. Objekat se identifikuje
nazivom i listom svojstava, a grafički se predstavlja kao pravougaonik u kome se
ispisuje naziv entiteta, koji je najčešće imenica. U DOV se razlikuju takozvani jaki i

4
slabi objekti. Između jakog i slabog objekta postoji i dentifikaciona i egzistencijalna
zavisnost.

Atributi su osobine (svojstva) entiteta. Atribut podrazumjeva ime i vrijednost

svojstva (npr. atribut “boja” i njegova vrijednost “plavo”).Entitet se opisuje pomoću
jednog ili vise svojstava (atributa). Atributi su podaci osnovnog tipa, ili preddefinisani
domeni. Označavaju se elipsoidima i povezani su pravolinijskim konektorma sa
objektima.

Veze (Eng. Relationshipss) u najvažniji dio DOV, jer definišu načine na kojima
su objekti uzajamno povezani. Veze se imenuju i njihovi nazivi odslikavaju sematniku
povezanosti između objekata. Predstavljaju asocijacije između entiteta klasa. Broj
objekata u vezi definiše stepen (degree) veze.

Postoje brojne mogućnosti za funkcionalnost ternarne veze, na primjer – (N :

M : P), (1 : N : M), (1 : 1 : N) ili čak (1 : 1 : 1). Ternarnu vezu uvodimo samo onda kad
se ona ne može rastaviti na dvije binarne.

5
 Kardinalnost predstavlja odnos broja objekata koji se povezuju. Određivanje
kardinalnosti se uglavnom vrši proučavanjem veza i odnosa između posmatranih
objekata.

Tipovi kardinalnosti:
• Jedan prema jedan (1:1) – na primjer jedna uplata dobavljaču se vrši po
tačno jednoj fakturi dobavljača
• Jedan prema više (1:N) – na primjer jedna narudžbenica sadrži više stavki
narudžbenice
• Više prema više (N:M) – više dobavljača ima ugovore sa više špeditera.

Verzije ER modela:
– Information Engineering (IE) (James Martin, 1990)
– Integrated Definition for Information Modeling (IDEF1X)
– Unified Modeling Language (UML)

Softveri za modeliranje:
– Microsoft Visio
– ERwin
– DB Designer 4
– MySQL Workbench

Veza u kojoj jedan entitet učestvuje više puta u različitim ulogama naziva se
rekurzivna ili unarna veza. Pored osnovnog, postoji i prošireni model objekti veze,
koji omogućava detaljnije definisanje veza između objekata. Pored asocijativnih veza
koje oslikaju semantiku udruživanja objekata u sistemu, postoje i specifične veze
kojima se izražava hijerarhija i komponovanje objekata. Postoje dvije reprezentativne
vrste ovakvih veza:
– Specijalizacija/generalizacija
– Agregacija

Generalizacija je apstrakcija u kojoj se skup sličnih tipova objekata

predstavlja opštim generičkim tipom ili nad tipom. Slični tipovi objekata su oni koji
imaju zajedničke osobine i ponašanje. Npr: klasa Nastavniki AdmOsoblje se može
generalizovati u klasu Radnik.
Specijalizacija je obrnuti postupak od generalizacije. Specijalizacija –
izbegavaju se NULL vrijednosti.

Agregacija je klasa veza koja se ponaša kao klasa objekata i može da

učestvuje u drugim vezama.Na primjer klase objekata Nastavnik I Predmet povezane
su klasom veza Predaje.

6
2.2 Dijagram objekti-veze

ER Dijagram

Na ER dijagramu možemo vidjeti četri objekta sa njihovim vezama. Između objekata

Kancelarija – Advokat nalazi se veza 1:N, tj u jednoj kancelariji može biti više advokata, a
jedan advokat radi za jednu kancelariju. Između objekata Advokat-Slučaj nalazi se veza N:M,
tj. jedan advokat može raditi istovremeno na više slučajeva, a na jednom slučaju može raditi
više advokata. Između objekata Slučaj-Klijent imamo vezu 1:N, tj. jedan klijent može se
teretiti za više slučaja, a jedan slučaj je vezan samo za jednog klijenta. I imamo još jednu
karakterističnu vezu objekta Advokat, gdje je veza 1:N, odnosno jedan advokat može biti šef
za više advokata.

2.3 Opis objekata i veza

Objekat KANCELARIJA

Naziv atributa Tip podataka Obavezno Primarni ključ Opis

polje
Id INTEGER Da Da Primarni ključ
objekta
Ime VARCHAR(40) Da Ne
Broj slučaja INTEGER Da Ne
Broj advokata INTEGER Da Ne

7
Objekat ADVOKAT

Naziv atributa Tip podataka Obavezno Primarni ključ Opis

polje
Id INTEGER Da Da Primarni ključ
objekta
Ime VARCHAR(20) Da Ne
Prezime VARCHAR(30) Da Ne
Jedinstveni VARCHAR(5) Da Ne
broj radnika
Plata po satu INTEGER Da Ne
Telefon VARCHAR(10) Ne Ne

Objekat SLUČAJ

Naziv atributa Tip podataka Obavezno Primarni Opis

polje ključ
Id INTEGER Da Da Primarni ključ
Broj slučaja VARCHAR(6) Da Ne
Ime klijenta VARCHAR(40) Da Ne
Adresa VARCHAR(50) Da Ne
Telefon VARCHAR(10) Da Ne
Osoba za kontakt VARCHAR(50) Da Ne
Datum otvaranja DATE Da Ne
slučaja
Datum zatvaranja DATE Da Ne
slučaja
Opis VARCHAR(200) Da Ne
Advokat VARCHAR(50) Da Ne
Sati za naplatu FLOAT(5,2) Da Ne

Objekat KLIJENT

Naziv atributa Tip podataka Obavezno Primarni Opis

polje ključ
Id INTEGER Da Da Primarni ključ
Ime VARCHAR(40) Da Ne
Prezime VARCHAR(30) Ne Ne
Advokat VARCHAR(50) Da Ne
Slučaj VARCHAR(6) Da Ne
Telefon VARCHAR(10) Da Ne
Adresa VARCHAR(50) Da Ne

8
3. Relacioni model
3.1 Uvod

Relacioni model podataka teorijski je razradio britanski matematičar Codd E.F.Ovaj

model ispisuje isključivo logičke aspekte podataka,odnosno relacije koje postoje među
različitim podacima i ne bavi se problemom fizičkog smještaja podataka u memoriju
računara.

Osnovni pojmovi relacionog modela koje je Codd preuzeo iz matematičke teorije skupova su:
 Domen;
 Relacija i
 Atribut. 

Domen se definiše nabrajajući vrijednosti koje ulaze u sastav domena.

Npr. Naziv dana u sedmici={ponedjeljak,utorak,srijeda,četvrtak,petak,subota,nedelja}
Relacija je imenovani podskup Kartezijevog proizvoda dva ili više domena.
Neka su definisana dva domena.
1. Ime_prezime_studenta={Petar Petrović,Dragana Draganović}
2. Naziv predmeta={Matematika,Fizika,Biologija}

Kombinacije vrijednosti domena nazivaju se n-torke.Prema tome,relacija je skup n-

torki.
IME_PREZIME_UČENIK NAZIV_PREDMET
A A
Petar Petrović Matematika
Petar Petrović Fizika
Petar Petrović Biologija
Dragana Draganović Matematika
Dragana Draganović Fizika 
Dragana Draganović Biologija
Tabela 1.  Relacija  UČENIK_PREDMET 

Relaciona tabela se još naziva i relaciona šema,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 uključuje tačno određen broj pola 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;
 Redosljed kolkona,odnosno atributa je nebitan;
 Redosljed n-torki je nebitan i
 Nove se tabele mogu stvarati povezivanjem preko vrijednosti polja podataka iz
istog domena iz dvije postojeće tabele.

Skup operacija koje se provode na relacijama, odnosno tabelama naziva se relacionom

algebrom. Najčešće koristene operacije relacione algebre nad podacima su sljedeći:
 Operacija selekcije (Selection); 
 Operacija projekcije (Projection) i 
 Operacija spajanja (Join) 

9
3.2 Prevođenje modela objekti-veze u relacioni model

3.2.1 Prvi korak

U prvom koraku kopiramo sve tabele iz modela objekti-veze.

Objekat KANCELARIJA

Naziv atributa Tip podataka Obavezno Primarni ključ Opis

polje
Id INTEGER Da Da Primarni ključ
objekta
Ime VARCHAR(40) Da Ne
Broj slučaja INTEGER Da Ne
Broj advokata INTEGER Da Ne

Objekat ADVOKAT

Naziv atributa Tip podataka Obavezno Primarni ključ Opis

polje
Id INTEGER Da Da Primarni ključ
objekta
Ime VARCHAR(20) Da Ne
Prezime VARCHAR(30) Da Ne
Jedinstveni VARCHAR(5) Da Ne
broj radnika
Plata po satu INTEGER Da Ne
Telefon VARCHAR(10) Ne Ne

Objekat SLUČAJ

Naziv atributa Tip podataka Obavezno Primarni Opis

polje ključ
Id INTEGER Da Da Primarni ključ
Broj slučaja VARCHAR(6) Da Ne
Ime klijenta VARCHAR(40) Da Ne
Adresa VARCHAR(50) Da Ne
Telefon VARCHAR(10) Da Ne
Osoba za kontakt VARCHAR(50) Da Ne
Datum otvaranja DATE Da Ne
slučaja
Datum zatvaranja DATE Da Ne
slučaja
Opis VARCHAR(200) Da Ne
Advokat VARCHAR(50) Da Ne
Sati za naplatu FLOAT(5,2) Da Ne

10
Objekat KLIJENT

Naziv atributa Tip podataka Obavezno Primarni Opis

polje ključ
Id INTEGER Da Da Primarni ključ
Ime VARCHAR(40) Da Ne
Prezime VARCHAR(30) Ne Ne
Advokat VARCHAR(50) Da Ne
Slučaj VARCHAR(6) Da Ne
Telefon VARCHAR(10) Da Ne
Adresa VARCHAR(50) Da Ne

3.2.2 Drugi korak

U drugom dijelu treba prevesti veze.

Veze koje smo uočili u relacionom modelu su:

 Kancelarija-Advokat (1:N)
 Advokat-Slučaj (M:N)
 Slučaj-Klijent (1:N)
 Advokat-Advokat (1:N)

Veze 1:N prevodimo tako što primarni ključ iz tabele objekta na strani jedan dodajemo kao
atribut i strani ključ u tabelu objekta na strani N.

Veze M:N prevodimo tako što pravimo novu tabelu koja će imati strane ključeve iz obje
tabele i iz tabele objekta na strani M i iz tabele objekta na strani N. Takođe sama ova veza
može sadržavati svoje atribute.

Veza Kancelarija-Advokat je 1:N pa će tabela izgledati ovako:

Naziv atributa Tip podataka Obavezno Primarni ključ Opis

polje
id INTEGER Da Da Primarni ključ
objekta
Ime VARCHAR(20) Da Ne
Prezime VARCHAR(30) Da Ne
Jedinstveni VARCHAR(5) Da Ne
broj radnika
Plata po satu INTEGER Da Ne
Telefon VARCHAR(10) Ne Ne
Kancelarija_id INTEGER Da Ne Strani ključ
objekta

11
Veza Advokat – Slučaj je M:N pa tabela izgleda ovako:

Naziv atributa Tip podataka Obavezno Primarni Opis

polje ključ
Advokat_id INTEGER Da Ne Strani ključ
Slučaj_id INTEGER Da Ne Strani ključ
Datum_otvaranja_slučaja DATE Da Ne
Datum_zatvaranja_slučaja DATE Da Ne

Ova tabela ima i dva nova atributa koja obilježavaju datume otvaranja i zatvaranja slučaja.

Veza Slučaj-Klijent je takođe 1:N pa tabela izgleda ovako:

Naziv atributa Tip podataka Obavezno Primarni Opis

polje ključ
Id INTEGER Da Da Primarni ključ
Broj slučaja VARCHAR(6) Da Ne
Ime klijenta VARCHAR(40) Da Ne
Adresa VARCHAR(50) Da Ne
Telefon VARCHAR(10) Da Ne
Osoba za kontakt VARCHAR(50) Da Ne
Datum otvaranja DATE Da Ne
slučaja
Datum zatvaranja DATE Da Ne
slučaja
Opis VARCHAR(200) Da Ne
Advokat VARCHAR(50) Da Ne
Sati za naplatu FLOAT(5,2) Da Ne
Klijent_id INTEGER Da Ne Strani ključ

Veza Advokat-Advokat je 1:N i tabela izgleda ovako:

Naziv atributa Tip podataka Obavezno Primarni ključ Opis

polje
id INTEGER Da Da Primarni ključ
objekta
Ime VARCHAR(20) Da Ne
Prezime VARCHAR(30) Da Ne
Jedinstveni VARCHAR(5) Da Ne
broj radnika
Plata po satu INTEGER Da Ne
Telefon VARCHAR(10) Ne Ne
Kancelarija_id INTEGER Da Ne Strani ključ
objekta
Šef_id INTEGER Da Ne Id advokata
koji predstavlja
šefa

Dodajemo atribut šef koji ustvari predstavlja samog advokata koji može biti šef za više
advokata u kancelariji.

12
4. Relaciona šema
Objekat KANCELARIJA

Naziv atributa Tip podataka Obavezno Primarni ključ Opis

polje
Id INTEGER Da Da Primarni ključ
objekta
Ime VARCHAR(40) Da Ne
Broj slučaja INTEGER Da Ne
Broj advokata INTEGER Da Ne

Objekat ADVOKAT

Naziv atributa Tip podataka Obavezno Primarni ključ Opis

polje
id INTEGER Da Da Primarni ključ
objekta
Ime VARCHAR(20) Da Ne
Prezime VARCHAR(30) Da Ne
Jedinstveni VARCHAR(5) Da Ne
broj radnika
Plata po satu INTEGER Da Ne
Telefon VARCHAR(10) Ne Ne
Kancelarija_id INTEGER Da Ne Strani ključ
objekta
Šef_id INTEGER Da Ne Id advokata
koji predstavlja
šefa
(strani ključ)

Objekat SLUČAJ
Naziv atributa Tip podataka Obavezno Primarni Opis
polje ključ
Id INTEGER Da Da Primarni ključ
Broj slučaja VARCHAR(6) Da Ne
Ime klijenta VARCHAR(40) Da Ne
Adresa VARCHAR(50) Da Ne
Telefon VARCHAR(10) Da Ne
Osoba za kontakt VARCHAR(50) Da Ne
Datum otvaranja DATE Da Ne
slučaja
Datum zatvaranja DATE Da Ne
slučaja
Opis VARCHAR(200) Da Ne
Advokat VARCHAR(50) Da Ne
Sati za naplatu FLOAT(5,2) Da Ne
Klijent_id INTEGER Da Ne Strani ključ

13
Objekat KLIJENT

Naziv atributa Tip podataka Obavezno Primarni Opis

polje ključ
Id INTEGER Da Da Primarni ključ
Ime VARCHAR(40) Da Ne
Prezime VARCHAR(30) Ne Ne
Advokat VARCHAR(50) Da Ne
Slučaj VARCHAR(6) Da Ne
Telefon VARCHAR(10) Da Ne
Adresa VARCHAR(50) Da Ne

Veza ADVOKAT-SLUČAJ

Naziv atributa Tip podataka Obavezno Primarni Opis

polje ključ
Advokat_id INTEGER Da Ne Strani ključ
Slučaj_id INTEGER Da Ne Strani ključ
Datum_otvaranja_slučaja DATE Da Ne
Datum_zatvaranja_slučaja DATE Da Ne

14