Baze Podataka

SifK znaci sifra klijenta I ono je primarni kljuc tog entiteta - PK. Kao sto pise, ovaj entitet je nezavisan sto znaci da postoji
nezavisno od drugih entiteta. Takav entitet se takodje naziva I jak entitet.

KLIJENT(SifK, Ime) predstavlja relacioni model entiteta KLIJENT.

SifK I Ime u okviru entiteta KLIJENT se nazivaju klasifikacionim svojstvima, a u realcionom modelu se nazivaju atributi.

SifK Ime
1 Ana
2 Pera
3 Ana
… …

Primer:
Student
SifS
Indeks
Ime

Student(SifS, Indeks, Ime)

Ovde I SifS I Indeks mogu da budu PK, pa se za njih kaze da su kandidat kljucevi – KK. Kada jedan KK postane PK za njega se
kaze da je surogat kljuc – SK. To znaci da je SifS SK.
Entitet AUTOMOBIL je zavisan entitet. On zavisi od entiteta MODEL. Zavisan entitet se takodje naziva I slabim entitetom.
Takav entitet ima jos jedan pravougaonik oko sebe.
E - egzistencijalna zavisnost(entitet AUTOMOBIL ne moze postojati(egzistirati) bez entiteta MODEL)
(0, N) – Kardinalnost uslovljavanja; U ovom slucaju ne mora postojati ni jedan automobil tog modela a moze ih postojati N.
(1)(1, 1) – Kardinalnost uslovljenosti; Posto entitet AUTOMOBIL ima svoj PK to znaci da postoji samo jedan(ni manje ni
vise) automobil sa jedinstvenom SifA odredjenog modela.
U relacionom modelu AUTOMOBIL, SifM je zaokruzen jer je on strani kljuc - SK, odnosno PK entiteta od kojeg entitet
AUTOMOBIL zavisi. On mora postajati kao atribut u relacionom modelu zavisnog entiteta da bi se znalo od kog entiteta on
zavisi.

Za MODEL:
SifM Naziv
1 …
2 …
3 …

Za AUTOMOBIL:
SifA RegBr SifM
1 … 1
2 … 1
3 … 2
4 … 2

Zadatak: SifA=3 Koji je naziv tog modela?

U tabeli za AUTOMOBIL bismo nasli tu SifA I preko nje dosli do SifM I onda bismo u tabeli MODEL preko SifM nasli naziv tog
modela.
Na isprekidanoj strelici, E se podrazumeva, kao I (1) kao kardinalnost uslovljenosti.
U ovom primeri entitet NAJAM ne moze postojati bez entiteta KLIJENT I AUTOMOBIL. To znaci da je entitet NAJAM zavisan
entitet, kao I entitet AUTOMOBIL(samo sto entitet AUTOMOBIL zavisi od entiteta MODEL koji nam sada nije toliko bitan).

I – identifikaciona zavisnost(rezervaciju moze da identifikuje I klijent I model, pa zato entitetu REZERVACIJA(koji je zavisan
entitet) nije potreban PK).
SifK, SifM je kompozitni PK(PK koji je sastavljen od vise kljuceva) sto moze da se zapise I kao SifK, SifM
Datum je diskriminator I zato je podvucen isprekidanom linijom. On se u tabeli ponasa kao da je sastav PK.

U entitetu R1, A I B predstavljaju kompozitni primarni kljuc.

Entitet AUTOMOBIL je nadklasa, dok su entiteti PUTNICKI I TERETNI podklase entiteta AUTOMOBIL.
Trougao predstavlja signal za specijalizaciju(odnosno generalizaciju).
Kardinalnost specijalizacije nam pokaziju da automobil mora biti ili putnicki ili teretni. Takva kardinalnost se naziva
ekskluzivna kardinalnost((0, 1) ili (1, 1)).
Kardinalnosti kod entiteta PUTNICKI I entiteta TERETNI se podrazumevaju da su (1).
Relacioni model entiteta AUTOMOBIL je logican. Relacioni modeli entiteta PUTNICKI I entiteta TERETNI pored klasifikacionih
svojstva samih entiteta, kao atribute, sadrze I PK njihove nadklase. PK migrira iz entiteta nadklase u entitet podklasa I postaje
I PK(primarni kljuc) I SK(strani kljuc), zato je on I podvucen I zaokruzen u relacionim modelima entiteta PUTNICKI I TERETNI.

Kardinalnost specijalizacije je (0, 2), I to znaci da radnik moze biti ili nesto trece, ili jedno, ili drugo, ili oba. Takva kardinalnost
se naziva parcijalna inkluzivna specijalizacija.
Primer:
R1
A
B

R2
A
C

Posto oba entiteta imaju isti PK, onda moze da se uradi generalizacija:

B I C su specificna svojstva, dok je A zajednicko svojstvo. Da se u entitetu R1 nalazilo klasifikaciono svojstvo D, kao I u entitetu
R2, onda bi to takodje bilo zajednicko svojstvo, pa bi preslo u R3. To znaci da su sva klasifikaciona svojstva koja se nalaze u
nadklasi u stvari zajednicka svojstva podklasa.
Relacioni modeli:
DRZI je veza izmedju entiteta KLIJENT I entiteta AUTOMOBIL. Veza se oznacava tako sto se oivici sestougaonikom. SifA je PK
veze zbog kardinalnosti izmedju AUTOMOBIL-a I DRZI. Ta kardinalnost nam govori da jedan automobil moze da ne drzi ni
jedan klijent ili jedan. To znaci da je dovoljno staviti samo SifA kao PK. Ali da je kardinalnost bila (0, N) umesto (0, 1), onda bi
relacioni model veze DRZI izgledao ovako:

Tada bi i SifK i SifA bi bili PK veze DRZI. To znaci da PK veze zavisi od kardinalnosti. Veza moze da se prikaze kao tabela. U vezi
ne postoji diskriminator.

U prvom primeru nam zbog kardinalnosti nije potrebna veza, pa sve moze da se stavi u jedan relacioni model. Ovde je sve
stavljeno pod A, ali moze I da se stavi pod B, gde bi SiB bio PK, a SifA strani kljuc.
U drugom primeru sva svojstva iz veze idu u A, a posto su A I B povezani, onda PK iz B ide u A.
U trecem primeru, posto A I B ne moraju biti povezani(zbog kardinalnosti), moraju postojati sva 3 relaciona modela. Ovde u
relacionom modelu V PK moze da bude ili SifA ili SifB. Svejedno je koji jer oba mogu maksimalno po 1 da udju u vezu, ali ne
mogu oba da budu PK u isto vreme.
U cetvrtom primeru B ne moze da identifikuje vezu jer moze vise puta da udje u nju, pa je PK veze samo sifA.
U petom primeru I A I B mogu po vise puta da udju u vezu, pa je PK veze kompozitni PK SifA, SifB.
Kada hocemo da 1 veza ucestvuje u drugoj vezi, onda ona postaje entitet tako sto se sestougaonik oivici pravougaonikom. U
ovom primeru smo to uradili da bi studenti znali koji nastavnik predaje koji predmet I koji predmet oni mogu da pohadjaju.
Da je studente zanimalo samo koji predmet mogu da pohadjaju, bilo bi dovoljno da se napravi veza izmedju entiteta
STUDENT I entiteta PREDMET, a da veza PREDAJE ne mora da predje u entitet.
1. Zadatak

Resenje:
U svakom entitetu, ako nije naglaseno sta je PK, mi sami biramo. Mozemo da izaberemo neki od klasifikacionih svojstava, ali
samo ako smo sigurni da moze da bude PK. Ako nismo sigurni sta moze, a sta ne, uvek mozemo da uvedemo sifru tog entiteta
I da nju postavimo za PK.
Entitet Kaseta I Film su povezani vezom Sadrzi jer je stanje filma(filmova) na kaseti trenutno. Filmovi mogu da se brisu sa
kasete I da se dodaju novi – na istu kasetu. Kad god se pamti nesto sto je trenutno(nesto moze da se brise, dodaje, menja…),
tada treba da se koristi veza.
Na ovom dijagramu se ne mogu postavljati uslovi. Primer je taj kad bi na jednoj kaseti cije je trajanje 5 sati bila dva filma cije
je zajednicko trajanje 7 sati. To ne moze da se realizuje, a ovaj dijagram nam to “dozvoljava”. To bi se regulisalo u SQL-u.
Razlog zasto je Zanr postavljen kao entitet – ako bi zanr bio klasifikaciono svojstvo u entitetu Film, zauzelo bi se vise
memorije, jer bi se za svaki film stavljao string koji govori kojeg je taj film zanra, a ne samo sifra zanra. A I tako bi bilo sklonije
greskama.
U entitetu Film je za PK uzet SifF, ali da smo uveli pretpostavku da u video klubu ne postoje dva filma sa istim nazivom,
klasifikaciono svojstvo Naziv bi mogao da bude PK. Ako se to uradi, onda mora da se naglasi.
Na isprekidanoj liniji koja se nalazi izmedju entiteta Zanr I Film, nalaze se kardinalnosti I tip zavisnosti. Nista od toga ne mora
da se napise na toj liniji, jer se to podrazumeva. Ako su vrednosti drugacije, onda mora da se napise.
Kardinalnost (0, N) izmedju entiteta Film I veze Sadrzi nam govori da film uopste ne mora da se nadje na kaseti a moze isti
film da bude I na vise kaseta.
Kardinalnost (0, N) izmedju entiteta Kaseta I veze Sadrzi nam govori da jedna kaseta ne mora da sadrzi ni jedan film a moze I
proizvoljan broj filmova(to samo zavisi od duzine kasete, pa se opet vracamo na onaj uslov).
Isprekidana linija izmedju entiteta Film I Pozajmica bi trebalo da postoji, jer preko entiteta Kaseta mozemo da saznamo koji
film se nalazi na njoj, ali ako ima vise filmova, necemo znati zbog kog tacno filma je pozajmica izvrsena. Isto tako, npr., da se
trazila statistika koji film je koliko puta uzet, opet bi ova zavisnost morala da postoji.
U entitetu Pozajmica ne mora postojati SifP, ali bi tada on zavisio identifikaciono od ostalih entiteta I Trajanje bi bio
diskriminator.

Relacioni modeli datih entiteta:

2. Zadatak

Resenje:
U ovom zadatku, sve je trajno. Pravimo sistem za fudbalski savez u toku jedne sezone, a kaze da fudbaleri ne mogu da
menjaju ekipu u toku sezone. Onda pise I da je potrebno trajno evidentirati svaki postignuti gol… Nista nije trenutno, pa zato
u ovom dijagramu nemamo vezu/e.
Kardinalnost (2) izmedju entiteta Tim I Utakmica nam govori da uvek tacno 2 tima igraju na jednoj utakmici . To znaci da ce PK
entiteta Tim 2 puta da se nadje u jednoj koloni tabele Utakmica. E se podrazumeva, kao I kardinalnost uslovljavanja (0, N).
Klasifikaciono svojstvo Ishod, u entitetu Utakmica, moze da bude karakter (‘1’, ‘2’ I ‘x’) ili ceo broj(1, 2 I 0), mada manje
memorije zauzima karakter.
Entitet Gol zavisi od entiteta Igrao, a ne od entiteta Utakmica I entiteta Fudbaler, jer nece svaki fudbaler igrati na svakoj
utakmici.
U entitetu Gol, RBr je diskriminator, jer moze da se desi da na jednoj utkamici jedan fudbaler postigne vise golova u toku
istog minuta.
Entitet Karton je jak entitet jer moze da postoji I bez utakmice, fudbalera, itd., ali ako je dodeljen, onda mora da bude
dodeljen na utakmici. Zato postoji I entitet Dodeljen. U njemu je SifD PK jer on zavisi egzistencijalno. Da je njegova zavisnost
identifikaciona, SifD bi bio diskriminator jer je moguce da na jednoj utakmici isti fudbaler dobije 2 zuta kartona u istom
minutu.
Da je npr. u zadatku pisalo da I zuti karton ima neka klasifikaciona svojstva, kao I crveni karton, onda bismo mogli da uradimo
specijalizaciju tako sto bi entitet Karton bio nadklasa, a entiteti Zuti I Crveni bi bili podklase sa svojim klasifikacionim
svojstvima. S obzirom da u ovom zadatku to ne pise, vec samo pise da karton moze biti zuti ili crveni, dovoljno je u entitet
Karton ubaciti klasifikaciono svojstvo Tip koji se odnosi na to da li je karton zuti ili crveni. Pri specijalizaciji, etiteti Zuti I Crveni
bi bili prazni.
Kada za neki subjekat u tekstu imamo vise stvari koje treba da pamtimo, onda pravimo novi entitet, ili vezu. Zavisi sta se trazi.

Relacioni modeli:

U relacionom modelu Utakmica, postoje 2 SifT: SifT1 I SifT2. To je zbog kardinalnosti uslovljenosti. Mogli smo da napisemo I:
Domacin I Gost. Imalo bi istu funkciju, a pored toga bismo imali jos jednu informaciju vise(ko je domacin a ko gost). Oba
atributa su zaokruzena jer dolaze iz razlicitih tabela. Iz tabela I za jedan I za drugi tim. To je jedna tabela, ali posto 2 tima
moraju da igraju na utakmici, onda mora postojati 2 SK koja predstavljaju te timove. Pise iz razlicitih tabela, ali to je jedna
tabela, a dve kolone, ali su razlicite kolone, pa su onda oba kljuca podvucena.
Da je u zadatku receno da fudbaler u toku jedne utakmice moze da menja pozicije, onda bi atribut Pozicija bio diskriminator.
Diskriminator treba da se podvuce isprekidano u relacionom modelu, dok u entitetu I moze I ne mora.
Moglo je da se trazi da se zapamti I vreme koliko je koji igrac igrao na nekoj utakmici ili koliko je igraca igralo na nekoj
utakmici. Ali to nije toliko bitno, I ne bi nnista promenilo.

3. Zadatak

Resenje:

U entitetu Turnir mozemo da uvodimo neke pretpostavke sta bi moglo da bude PK, ali je najpametnije da kada imamo jak
entitet, dodamo sifru tog entiteta kao PK.
Kod entiteta Korisnik smo izvrsili specijalizaciju. Kardinalnost (1, 1) znaci da Korisnik moze biti ili Sahista ili Komentator. Nista
drugo.. Mada je moglo da se stavi I (0, 1) jer ne pise da mora da bude nesto od ta dva.
Ucestvovanje moze I da zavisi egzistencijalno(E), ali onda mora da ima svoj primarni kljuc. Ali, svaki put kad moze da se izvrsi
identifikaciona zavisnost(I), treba nju staviti.
Zavisnost izmedju entiteta Ucestvovanje I Nagrada ne moze biti I jer za jedno ucestvovanje moze postojati vise nagrada, pa
nam onda PK ucestvovanja ne bi bio dovoljan da identifikujemo nagradu. Cak ni opis ne bi mogao da se stavi kao
diskriminator, jer moze postojati vise nagrada sa istim opisom.
Kardinalnost izmedju entiteta Komentator I Analiza nam govori da jedan komentator moze dati vise analiza, ali ne mora ni
jednu.
Kardinalnost imzedju entiteta Partija I Sahista nam govori da na jednoj partiji ucestvuje tacno dvoje sahista.
Analiza ne moze postojati bez komentatora, koji je izvrsava, I poteza, za koji je izvrsena, dok potez ne moze postojati bez
partije.
Kardinalnost izmedju entiteta Potez I Analiza nam govori da na jedan potez ne mora biti izvrsena ni jedna analiza, a moze ih
biti I vise.
U entitet Komentator mozemo dodati neko klasifikaciono svojstvo, da ga opisemo I da ne bude prazan, ali ne mora.
Izmedju entiteta Potez I Analiza, lista moze biti veza, eli je bolje da bude klasifikaciono svojstvo, jer potez ne moze postojati
bez partije.
Entitet odigrana moze biti I veza, jer nigne ne pise da li se to trenutno ili trajno cuva, ali je bolje kao entitet.
Zavisnost izmedju entiteta Turnir I Odigrana ne moze biti I jer partija ne mora da se odigra na turniru(to nam govori I
kardinalnost izmedju entiteta Partija I Odigrana). To znaci da je samo Partija dovoljna da identifikuje entitet odigrana, jer ako
se partija ne odigra,entitet Odigrana nema smisla(nema nicega), a ako se odigra, onda se ili jedna partija odigra samo jednom
na jednom turniru ili se odigra van turnira. Bas to nam I govori da je za identifikaciju entiteta Odigrada dovoljan I potreban
samo PK entiteta Partija. Jedino je moglo i da se stavi da su obe zavisnosti E, ali bi onda entitet Odigrana morao da ima PK.
Ako bilo gde postoji I zavisnost, entitet koji zavisi mora imati PK(kompozitni ili ne) koji se sastoji od PK od entiteta od kojeg
zavisi I.

Relacioni modeli:

4. Zadatak

Resenje:
Za entitete Uredjaj I Deo smo izvrsili generalizaciju, jer se za njih pamte ista klasifikaciona svojstva. Kardinalnost generalizacije
– (1, 1) znaci da proizvod koji se prodaje moze biti ili Uredjaj ili Deo. Ne moze nista drugo. Posto smo sami napravili
generalizaciju, to znaci da Proizvod mora biti nesto od 2 entiteta koji su podklase. Moglo je da pise I (1, 2). Kardinalnosti
izmedju entiteta Uredjaj I znaka za generalizaciju, kao I kardinalnost izmedju entiteta Deo I znaka za generalizaciju se
podrazumeva da su (1).
Izmedju entiteta Uredjaj I Deo se nalazi veza Sadrzi. Veza stoji tu jer jedan uredjaj moze da sadrzi jedan ili vise delova(zbog
toga je I kardinalnosti izmedju entiteta Uredjaj I veze Sadrzi (1, N)), a deo moze da se zameni drugim delom, pa nam to govori
da je to nesto trenutno, a ne trajno. Kardinalnost izmedju entiteta Deo I veze Sadrzi nam govori da jedan deo ne mora biti
deo ni jednog uredjaja, a moze biti deo maksimalno jednog uredjaja. Ipak, tu je moglo I da pise (0, N) jer jedan deo moze da
se zameni drugim delom(delovima), pa to znaci da moze biti deo jednog uredjaja, pa kad se zameni, onda moze biti deo
drugog uredjaja. Bas zbog toga sto deo moze da se zameni drugim delom, postoji veza Zamena izmedju jednog istog entiteta.
Obe kardinalnosti – (0, N) nam govore da jedan deo ne mora, a moze I vise puta da se menja, I da jedan deo ne mora biti, a I
moze biti vise puta zamenjen.
Kardinalnost specijalizacije (1, 1) nam govori da Komitent moze biti ili Firma ili Osoba(nista drugo).
U entitetu Stavka ne moraju da se nalaze Naziv I Cena kao klasifikaciona svojstva jer se ona nalaze u entitetu Proizvod, a
entitet Stavka zavisi od entiteta Proizvod, pa se sve moze procitati I iz te tabele preko SK u Stavci. Entitet Stavka moze zavisiti
I identifikaciono, ali ovde treba egzistencijalno jer pise da Stavka sadrzi SifS sto je njen PK.

Relacioni modeli:

5. Zadatak
Entitet Tip je mogao da stoji I kao atribut u entitetu Oprema, ali ne mora.. Moze da se desi da se kasnije trazi da se neki
atribut doda u tip, pa je onda bolje napraviti entitet. Bio je jos neki primer slican ovom. Kada imamo atribut tip u nekom
entitetu, uglavnom mozemo da ga izvucemo I napravimo entitet, a taj entitet koji je trebalo da sadrzi Tip kao atribut postaje
zavisan od entiteta Tip(E).
Kardinalnost (2) nam govori da firma moze I da isporucuje I da proizvodi neku opremu. Da smo izmedju entiteta Firma I
Oprema napravili vezu za isporucivanje I proizvodjenje, njena kardinalnost bi bila (1, 1) jer jedna jedinstvena oprema(koja ima
svoj InvBr) moze biti isporucena ili proizvedena od strane samo 1 firme, a kada je kardinalnost u vezi (1, 1), onda veza nije
potrebna I treba koristiti egzistencijalnu zavisnost od firme ka opremi.
Kardinalnost (0, 1) kod veze “se sastoji” nam govori da jedna oprema ne mora da se nalazi ni u jednoj opremi, a moze max u
jednoj(jedna oprema sa 1 InvBr max u jednoj drugoj opremi).
Veza “rasporedjena” mora da postoji, jer izmedju opreme I sobe nema zavisnosti, a I to nije nesto trajno. Ne pise u tekstu
zadatka, ali realno gledano, opreme mogu da se premestaju iz sobe u sobu. Kardinalnost (1, N) kod ove veze nam govori da
jedna oprema mora biti rasporedjena bar u jednoj sobi, a moze I u vise.
Entitet soba zavisi od entiteta Radnik I to E. Realno gledano, soba kao takva moze sama da postoji, ali posto mi pravimo bazu
podataka za kompaniju, a pise u tekstu zadatka da svaka soba mora imati definisanu odgovornu osobu, to znaci da u toj
kompaniji soba bez definisane osobe ne postoji. I zato u ovom zadatku soba E zavisi od radnika.
Mi smo na casu umesto entieta Instalacija stavili ternarnu vezu, ali to nije najbolje. Instalacije treba da se pamte I to nije
nesto trenutno. Kad se instalacija obavi, ne moze da se vrati nazad. Moze da se instalira novi softver ili obrise stari, ali ce se
svakako svaka instalacija zabeleziti. Primer za ternarnu vezu je ispod relacionih modela.
Relacioni modeli:

Primer za ternarnu vezu:

6. Zadatak
Entitet Grad nigde nije naglasen da treba da postoji kao entitet, ali je logicno da ga napravimo. Mislim da je na nekom od
zadataka sa lab-a bio primer sa gradom I da bi uvek bilo dobro da ga izvucemo kao jak entitet. Distributer nije zavisan od
grada, pa je zato I povezan sa njim vezom “pokriva”. To je nesto trenutno jer distibuter moze da menja gradove koje pokriva,
a I jedan grad mogu da pokrivaju vise razlicitih distributera u isto ili razlicito vreme. Dok je npr. entitet Apoteka slab entitet
koji E zavisi od entiteta grad. Logicno je da apoteka ne moze bostojati bez grada(gde bi drugde postojala?).
Ostalo sve je I ok. Sve kardinalosti su (0, N) osim kod entiteta saradjuje koji je povezan sa vezom popust. To nam govori da
Distributer koji saradjuje sa jednom apotekom moze da joj da popust za samo 1 prozivod, a ne mora ni za jedan.
U ovom zadatku smo od veze saradjuje napravili entitet. Ona se izmedju entiteta Distributer I Apoteka ponasa kao veza, ali
kada se povezuje sa Proizvodom preko veze popust, tada se ponasa kao entitet. To je zato sto je nama bitno koji distributer
kojoj apoteci daje popust na koji proizvod. Pa kada vec imamo vezu koja povezuje entitet Distributer I Apoteku, najlakse, a i
najbolje je da je samo pretvorimo u entitet I onda preko veze popust povezemo sa enitetom Proizvod. Da svaki distributer
saradjuje sa svakom apotekom, onda bismo ovde mogli I da napravimo ternarnu vezu popust koja bi povezivala entitete
Distributer, Apoteka I Proizvod. Ali posto ne moze svaki distributer da saradjuje sa svakom apotekom, nema smisla praviti
takvu ternarnu vezu, jer iz nje ne bismo mogli da izvucemo koji distributer saradjuje sa kojom apotekom.
Relacioni modeli:
SQL: DML
Postoje 2 naredbe. Naredba upita I naredba azuriranja.
Naredba upita:
- Redni upit
- Skalarni upit
- Svodni upit
Naredba azuriranja:
- Ubacivanje
- Izmena
- Uklanjanje

Redni upit

Sastoji se iz 3 dela, gde je jedan opcioni(WHERE). Prvi deo – SELECT nam govori sta da selektujemo(koji kljuc/eve). Tu
mozestajati ili *(selektuju se sve kolone, ondosno sve vrste iz odredjene tabele) ili ALL(znaci da se selektuje sve iz te kolone,
pa I duplikate, I ako nista ne pise, onda se ALL podrazumeva) ili DISTINCT(selektuje se odredjena kolona bez duplikata), gde
iza ALL I DINSTINCT treba da se nalazi ime kljuca/eva. Drugi deo – FROM nam govori odakle to da selektujemo(iz koje tabele/a
ili pogleda). Treci deo je opcioni – WHERE I on predstavlja uslov od kojeg moze zavisiti sta treba da se selektuje. Uz pomoc
Klauzule mozemo da organizujemo nase podatke rastuce(DESC) ili opadajuce(ASC). Ona treba da stoji odmah posle reci
SELECT.
Primeri:

U prvom primeru treba da selektujemo celu tabelu Oblast.

U drugom primeru treba da selektujemo kljuc SifN iz tabele Knjiga. Tu se ALL podrazumeva, tako da se selektuju I duplikati.
U trecem primeru selektujemo sve SifN iz tabele Knjiga bez ponavljanja(bez duplikata).
U cetvrtom primeru treba da selektujemo 2 kljuca – SifN I Naziv iz tabele Naslov, ali samo one za koje je SifO=’PJ’.

Skalarni upit

Skalarni upiti vracaju samo 1 red zbog koriscenja agregatnih f-ja. Pod naredbom SELECT nam se nalazi sta treba da
selektujemo, gde G-Lista predstvalja 1 ili vise G-Izraza(kombinacija kolona sa agregatnim f-jama). Ostalo je isto kao I kod
Rednog upita. Nova stvar su agregatne funkcije koje nam u stvari govore sta da radimo sa kolonom/ama koje smo selektovali
I onda rezultat te obrade vracamo. Ona se nalazi odmah posle naredbe SELECT.
Primeri:

U prvom primeru vracamo broj koji predstavlja koliko se redova nalazi u svim kolonama u bazi, odnosno vraca broj svih
clanova koji postoje u bazi za tabelu Clan(broj polja te tabele).
U drugom primeru vraca se broj razlicitih SifC iz tabele Pozajmica(ne gledaju se duplikati), odnosno broj clanova koji su izvrsili
pozajmicu.
U trecem primeru se vraca suma svih polja iz kolone Dana iz tabele Pozajmica(gledaju se I duplikati).
U cetvrtom primeru se trazi minimalna I maksimalna vrednost Dana Iz tabele Pozajmica. Rezultat je jedan red koji se sastoji iz
2 kolone, gde se u prvoj koloni nalazi minimalna vrednost, a u drugoj maksimalna.
Min Max
vr. vr.
U petom primeru se vraca isto jedan red sa 2 kolone, gde se u prvom clanu nalazi suma svih dana iz kolone Dana iz tabele
Pozajmica, ali samo za one redove za koje vazi da je SifC=’JJ1’, a u drugom clanu prosecna vrednost svih dana iz kolone Dana
iz tabele pozajmica, ali samo za one redove za koje isto vazi da je SifC=’JJ1’.
Svodni upit

Svodni upit, pored naredbi SELECT, FROM I opcione naredbe WHERE, ima jos dve naredbe od kojih je jedna opciona. Naredba
koja u svodnom upitu mora postojati je naredba GROUP BY I uz pomoc nje pravimo grupu. Opciona naredba je naredba
HAVING I ona predstavlja uslov za formiranje grupe.
Primeri:

U prvom primeru u tabeli Je_Autor treba da selektujemo kolonu SifA I da grupisemo po sifri autora I na taj nacin napravimo
grupe. Broj grupa=broj razlicitih SifA. COUNT(*) u svodnom upitu vraca broj svih clanova date kolone u svakoj od grupa. Ako
je npr. br. grupa 3 dok se u prve dve grupe 2 puta nalazi ista SifA, onda bi COUNT(*) za prvu I drugu grupu vratilo broj 2, a za
trecu grupu broj 1.
SifA SifNaslova
1 2
1 3
2 4
2 8
3 5
Ovde postoje tri gupe. A rezultat ovog primera izgleda ovako:

SifA Broj
1 2
2 2
3 1
Broj redova je jednak broju grupa. Na ovaj nacin smo izvrsili grupisanje tako sto smo napravili tabelu kod koje se us vakom
redu nalazi razlicita SifA I broj koliko je naslova on napisao.
U drugom primeru iz tabele Pozajmica treba da selektujemo kolonu SifC I da izvrsimo gupisanje po toj koloni a da zapamtimo
samo grupe za koje je suma svih dana veca od 10. Rezultat ce predstavljati tabela sa samo jednom kolonom – SifC, a
vrsta(redova) ce biti onoliko koliko ima grupa koje zadovoljavaju uslov.
U trecem primeru treba da selektujemo SifC I da izvrsimo prebrojavanje I sumu dana u tabeli Pozajmica. To znaci da ce
rezultat biti tabela koja ima 3 kolone: SifC, Broj I Suma a redova onoliko koliko ima grupa. Selektuju se SifC za koje je broj
dana veci od 2 I grupisanje se vrsi po SifC. Rezultat ovog primera je u stvari tabela koja nam govori koliko je pozajmica(Broj) I
na koliko dana(Suma) izvrsio koji clan(SifC), gde se u pozajmice ubrajaju samo one za koje je Dana > 2.

Upit nad vise tabela

Naredba SELECT nam govori sta da selektujemo. Naredba FROM iz koje tabele. U upitima nad vise tabela, u naredbi FROM
moze stajati vise naziva tabela. Ostale naredbe imaju isti smisao kao u upitima nad 1 tabelom. U naredbi FROM mogu da se
napreve skracenice za nazive tabela I na taj nacin olaksa posao. Npr:
FROM Pozajmica P, Naslov N. I onda se te skracenice koriste da se oznaci koji kljuc pripada kojoj tabeli. Kljuc uvek mora da se
odredi kojoj tabeli pripada jer u vise tabela isti kljuc moze da se ponavlja.
Kada se vrse upiti nad vise tabela, mi spajamo te tabele u jednu. Broj kolona te jedne tabele jednak je zbiru broja kolona svih
koje se spajaju, dok je broj redova jednak proizvodu svih broj redova tabela koje se spajaju, jer treba da se nadju sve
kombinacije svakog reda sa svakim drugim.
Primeri

U prvom primeru iz Tabela Naslov I Oblast treba sa selektujemo sve nazive. Prvo napravimo jednu tabelu, koja je sastavljena
iz tabela Naslov I Oblast, I onda gledamo uslove. Selektujemo nazive(I N.Naziv I O.Naziv) za koje je ispunjen uslov da je
N.SifO=O.SifO. Onda napravimo rezultujucu tabelu koja ima 2 kolone(N.Naziv I O.Naziv) I onoliko vrsta(redova) koliko je
naziva ispunilo uslov pod naredbom WHERE, I tu tabelu sortiramo po kljucu N.Naziv u neopadajucem poretku.
U drugom primeru se trazi suma svih dana iz tabele Pozajmica I Naslov koji zadovoljavaju uslov da je u tom redu P.SiN=N.SifN
I da je SifO=’BP’.
U trecem primeru treba da selektujemo P.SifC, Ime I da izbrojimo koliko grupa imamo, u tabeli Pozajmica I Clan. Grupe se
prave po P.SifC I Ime. To znaci da je ukupan broj svih grupa broj grupa medju kojima P.SifC I Ime nije identicno(izmedju 2
grupe, ne unutar jedne).
Forme predikata
Ovo su sve razlicite forme predikata koje mogu da se koriste u uslovima.
Primer:

U ovom primeru treba da selektujemo SifC bez ponavljanja(bez duplikata) iz tabele Pozajmica za koje vazi da je broj dana
izmedju 5 I 10.
Podupit

Nekorelisani podupit ne zavisi od spoljasnjeg upita, dok korelisani zavisi. EXISTS vraca TRUE ili FALSE.
Primeri

U prvom primeru unutrasnji upit je skalarni jer vraca samo 1 vrednosti, a takodje I nekorelisani jer ne zavisi od spoljasnjeg.
Ovde se traze pozajmice koje su trajale duze od maksimalno duge sa SifC=’PP0’.
U drugom primeru prvi unutrasnji upit zavisi od spoljasnjeg upita I svaku put vraca vrednost u zavisnosti od autora. Ovde
treba da selektujemo(ipsisemo) ime autora koji je napisao sve naslove kod kojih je SifO=’PJ’. U prvom upitu izbrojimo koliko
puta je za jednu SifO=’PJ’ odredjeni autor napisao naslov, a u drugom izracunamo koliko naslova postoji kod kojih je SifO=’PJ’
I ako se ta dva broja poklope, ispise se ime tog autora. Drugi unutrasnji upit ne zavisi od spoljasnjeg I rezultat je uvek isti(broj
naslova gde je SifO=’PJ’). Nadimak nam je pomogao da referenciramo nesto iz spoljasnjeg u unutrasnjem upitu.
Kombinovani upit

Primer

U ovom primeru Drzi predstavlja trenutno stanje(vezu). U njoj ne moze da se napravi duplikat SifK(sifra knjige) jer se u njoj
nalaze informacije koji clan drzi koju knjigu. A u tabeli Pozajmice se nalaze sve pozajmice koje su se izvrsile(osim ovih iz veze,
jer kada se te pozajmice zavrse, one se prenesu u tabelu Pozajmica). Unija ova dva skupa nam govori za koje knjige je sve
izvrsena pozajmica(bez duplikata jer nam nije bitno koliko puta je koja knjiga pozajmljivana nego samo koja knjiga je u
pitanju).
Naredba ubacivanja

Primeri

U prvom primeru menjamo tabelu Naslov. Treba da ubacimo vrednosti ‘PJP0’, ‘Pogramski jezik PASCAL’ I ‘PJ’. Posto nije
navedeno gde treba da se ubaci, podrazumeva se da se ubacuje u svako polje u odredjenom redu. Taj red je prvi sledeci
slobodan red. Da je pisalo u okviru VALUES sledece: VALUES(‘BP’), onda bismo u prvi Slobodan red u prvo polje(prva kolona)
upisali ‘BP’, a u ostale NULL.
U drugom primeru se iz tabele Naslov selektuju SifN I Naziv za koje je SifO=’PJ’ I to se ubaci u kolone SifraNasova I
NazivNaslova u tabeli NaspovPJ.

Naredba izmene

Primer

U ovom primeru u tabeli Naslov, tamo gde je SifN=’RBP0’ menjamo SifO u ‘BP’.
Naredba ukljanjanja

Primer

U ovom primeru u tabeli Clan brisemo svaki red u kojem je SifC=’MM0’.

Zadaci
1. Zadatak
View(pogled) je logicki isti kao tabela, samo sto se cuva na operativnoj memoriji, dok se tabele cuvaju na spoljasnjim
memorijama. Poglede pravimo da bismo lakse napravili upit, odnosno da olaksamo sebi zadatak. Mozemo da ih
posmatramo kao funkcije kada pisemo neki kod, I uz pomoc fukcija problem razlazemo na vise manjih problema. Pogled
nema stanje, samo se poziva kad god se nadje negde u FROM-u. Ja sam u ovim zadacimo o pogledu pricao kao o
tabeli(sto I logicki jeste), ali to nije nesto sto postoji zauvek, vec nesto sto napravimo u odredjenom trenutku(pogled se
formira onda kada se pozove naredbom FROM u nekom upitu) da bi nam olaksalo posao, I uz pomoc njega resimo
problem. Pogled se posle gubi.
U ovakvim zadacima uz pomoc teksta I relacionih modela treba da stvorimo sliku o kakvoj se bazi radi, sta je sa cim u
nekoj vezi, sta je veza, a sta entitet, I sta od cega zavisi…
U njihovim zadacimo strani kljucevi nisu zaokruzeni, ali bi na kolokviumu trebalo da budu, pa sam ih ja zaokruzio da bi se
lakse razumelo sta od cega zavisi.
Prva stavka:

U ovoj stavci smo napravili 3 pogleda.

Prvi pogled se zove BrUtakmica I on ima 2 kolone: SifF I BrUtakmica. U njega(u te kolone) cemo upisati sifre
fudbalera(SifF) I broj koliko puta se on pojavio u tabeli IGRAO, odnosno na koliko je utakmica igrao(COUNT(*)), a to cemo
uraditi tako sto cemo izvrsiti grupisanje po SifF. Tako cemo u prvom pogledu imati podatke za svakog fudbalera na koliko
je utakmica igrao.
Drugi pogled se zove BrGolova I takodje ima 2 kolone: SifF I BrGolova. U njega cemo upisati sifre fudbalera u kolonu SifF I
broj postignutih golova u kolonu BrGolova tako sto cemo te podatke izvuci iz tabele Gol I grupisati ih po SifF. Tako smo
napravili pogled iz kojeg mozemo da vidimo koliko je golova dao koji fudbaler.
Treci pogled se zove DaliGolNakonKartona I ima samo jednu kolonu: SifF. U tu kolonu cemo ubaciti sifre onih fudbalera
koji su postigli gol na nekoj utakmici nakon sto su primili zuti karton. Tu vrsimo upit nad vise tabela(FUDBALER,
UTAKMICA, GOL I KARTON). Tako formiramo tabelu u kojoj se nalaze sifre fudbalera koji su dali gol na utakmici na kojoj
su primili karton I to nakon tog kartona, a igrali su u gostima. To se sve nalazi u WHERE odeljku. I iz te tabele selektujemo
sve SifF I ubacimo ih u nas pogled. U ovom pogledu nismo napravili uslov da li je karton zuti, jer ako je igrac dobio crveni
karton, sigurno nece dati gol posle njega jer nece igrati.
Mi sada imamo informacije koji igrac je dao koliko golova I na koliko utakmica I koji igrac je dao gol u gostujucem timu
nakon primljenog zutog kartona. Posto se nama trazi da izrazunamo prosek datih golova koje je dao igrac po utakmici ali
samo ako je taj gol dat nakon primljenog zutog kartona u gostujucem timu, onda treba ova tri pogleda da
iskombinujemo. To radimo u poslednjem upitu. Poslednji upit je resenje zadatka. On ce nam dati informaciju koja je sifra
fudbalera(F.SifF) I njegovo ime(F.Ime) I prosecan broj golova po utakmici(gde se racunaju golovi dati nakon zutog kartona
u gostujucem timu). Ovde imamo podupit(nekorelisani) I on nam vraca sve sifre fudbalera iz pogleda
DaliGolNakonKartona I onda F.SifF koja se podudara sa BG.SifF I sa BU.SifF proverimo da li se podudara sa nekom SifF iz
tog pogleda. Ako se podudara, onda tu sifru, ime tog fubalera I taj prosek selektujemo.
Druga stavka:
Pravimo pogled USLOV koji ima 2 kolone: SifF I SifU, I u njih cemo ubaciti F.SifF I U.SifU koje cemo selektovati iz upita nas
vise tabela(nova tabela koja je spoj tabela FUDBALER, UTAKMICA I GOL) koji zadovoljava uslov pod WHERE. Tu se vrsi
provera da li je fudbaler sa svojom sifrom dao gol na utakmikmici(F.SifF=G.SifF), da li je gol postignut na odredjenoj
utakmici(G.SifU=U.SifU), da li je fudbaler igrao u pobednickom timu(sledeci uslov) I da li je neko dao gol posle(poslednji
uslov I to je podupit I u njemu selektujemo razlicite SifF koji su dali gol nakon postignutog gola fudbalera koji ji odredjen
F.SifF ; ako se ne selektuje ni jedna sifra, EXISTS vraca FALSE a posto pre toga stoji NOT, onda je rezultat TRUE). U toj
novonastaloj tabeli izvrsimo grupisanje po F.SifF I U.SifU ali samo za one fudbalere za koje je COUNT(*)=2(to znaci da je
postigao poslednja 2 gola).
I sada nad tabelom FUDBALER I pogledom USLOV postavimo uslov F.SifF=U.SifF da bismo odredjene(one koji
zadovoljavaju uslov, odnosno one koji se nalaze u pogledu USLOV) sifre fudbalera I njihova imena selektovali iz tabele
FUDBALER.
2. Zadatak

Za ovaj zadatak, sve sto nam treba imamo u tabeli nabavka. Posto nama treba provera da li imamo dovljno robe
odredjene sifre, treba da uradimo upit nad vise tabela nabavka, odnosno da tu tabelu spojimo samu sa sobom I to po sifri
robe(SifR).

Pravimo pogled LIFO(last in first out) koji ima 5 kolona(kolone se nalaze u zagradi nakon imena pogleda). U njih cemo
ubaciti ono sto se nalazi posle AS SELECT I to iz tabela Nabavka R1 I Nabavka R2, pod uslovom da je datum iz R2 veci ili
jednak datumu iz R1 I da je sifra proizvoda ista. To cemo uraditi za svaku sifru proizvoda I onda cemo u tom pogledu imati
informacije za sve sifre proizvoda. Mogli smo da stavimo uslov da je SfiR=30, ali na ovaj nacin imamo informacije o svakoj
robi, a onda cemo u sledecem upitu izvrsiti tu proveru I iz ovog pogleda izvuci robu koja nam je potrebna. I izvrsicemo
grupisanje po SifR iz R1, Datumu I Ceni iz R1.
Sledeci upit nam vraca totalnu cenu, a ovaj izraz nakon naredbe SELECT sluzi da se ne bi vratila cena za vise od 40
proizvoda, jer ukljucivanje poslednje kolicine proizvoda za prodaju, broj svih proizvoda moze premasiti 40. Npr. ako smo
sakupili 30 proizvoda, a prva prethodna nabavka je nabavka od 15, ukljucivanjem te nabavke mi dobijamo 45 tih
proizvoda, pa posto smo izracunali ukupnu cenu za tih 45 proizvoda, od nje treba da izbacimo cenu za 5 poslednjih
proizvoda. U ovom upitu iz pogleda LIFO za one proizvode cija je sifra 30 I ciji je datum jednak maksimalnom datumu iz
pogleda LIFO za koji vazi da je totalna kolicina veca ili jednaka 40 I da je sifra proizvoda 30 vrsimo izracunavanje totalne
cene. To je moguce, jer smo u pogledu LIFO izvrsili grupisanje po sifri, datumu I ceni.
3. Zadatak

Resenje:

Podsetiti se mnozenja matrica! Tesko je razumljivo objasnjenje bez razumevanja mnozenja matrica.
Uzimamo za pretpostavku da je mnozenje izmedju dve matrice koje treba da mnozimo moguce. Vrsimo upit nad vise
tabela I to nad tabelama Matrica(2 tabele Matrica za 2 matrice koje se mnoze) I nad tabelama Podaci(2 tabele Podaci za
podatke za 2 matrice koje se mnoze). Iz te novonastale tabele treba da se selektuju T2.I, T4.J I
SUM(T2.Vrednost*T4.Vrednost), ali samo one koji ispunjavaju uslove. Uslovi su: da se je SifM iz tabele Matrica jednaka
SifM iz tabele Podaci I da je naziv te matrica ‘A’ I da je druga SifM iz tabele Matrica jednaka SifM iz tabele Podaci I da je
njen naziv ‘B’. To se radi jer je u zadatku receno da se vrsi mnozenje matrica A I B. Sledeci uslov je da je broj kolone prve
matrice jednak broju vrste druge matrice I taj uslov sluzi da se zna koji element matrice A se mnozi sa kojim elementom
matrice B. I onda se za te selektovane elemente izvrsi grupisanje po vrsti prve matrice I koloni druge. To je uradjeno zbog
sledeceg: U novonastaloj tabeli imamo broj vrste prve matrice I broj kolone druge matrice. To nam je potrebno jer su te 2
vrednostu u stvari lokacija elementa iz rezultujuce matrice ciju sumu racunamo. Ta suma je u stvari suma koja nastaje
kada se vrsi mnozenje matrica. Mi na ovaj nacin dobijamo tabelu u kojoj se vise puta nalazi isti broj vrste I kolone sa
odredjenom sumom. A kada izvrsimo grupisanje po vrsti I koloni, mi dobijemo tabelu u kojoj se u svakom redu nalazi
razlicit broj vrste I kolone I sumu svih suma iz te vrste I kolone u tabeli nastaloj upitom nad vise tabela. Tako se dobije
tabela koja u stvari I predstavlja resenje ovog zadatka. To resenje je prikazano ispod dela “Odgovor za dati sadrzaj:”.

4. Zadatak

Primer dobrog rasporeda:

Primer loseg rasporeda:

Dobar raspored je raspored koji nema pause izmedju neka 2 predavanja. Na drugoj slici u Sredu I u Petak postoji pauza,
pa je taj raspored los.
Ovaj zadatak nije tezak. Fora je samo da se proveri da li je raspored dobar ili los I to na taj nacin sto oduzmemo pocetak
prvog predavanja od poslednjeg I dodamo 1, Pretpostavimo da svako predavanje traje po 1h. Tada prvo predavanje
pocinje u 1, a poslednje u 6. Ako je ceo dan pun, onda je 6-1 + 1 = 6(6 predavanja), I to je uslov. Ako se ne poklope ova
dva broja, onda je raspored los.
Resenje:
Formiramo pogled LosRaspored I u njemu ce se nalaziti sifre studenata koji imaju los raspored(SifS) I informacija koji dan
je raspored los. On ima te 2 kolone. U njih se upisuju P.SifS I R.Dan iz tabele koja nastaje upitom nad vise tabela(POHADJA
I RASPORED), ali samo oni podaci za koje je ispunjen uslov da je P.SifR=R.SifR. Onda izvrsimo grupisanje po P.SifS I R.Dan
za koje vazi da onaj uslov koji sam pominjao na pocetku nije ispunjen. Tako smo dobili sifre studenata I dane kada je
njihov raspored los.
Sada sledi unija 2 upita(sto je kombinovani upit) koja formira tabelu u kojoj se nalaze indeksi svih studenata, I pored kojih
pise da li im je raspored dobar ili los. To se radi tako sto se u prvom upitu selektuju sifre studenata iz tabele STUDENT za
koje je raspored los I to se napise pored njihovog broja indeksa. Ta provera se nalazi u odeljku WHERE I tu se pita da li se
ta sifra podudara sa nekom od sifri iz pogleda LosRaspored. Ako se podudara, onda taj student ima los raspored(nije nam
bitno koji dan) I pored njega se napise ‘LOS’. U drugom upitu se radi ista stvar, samo se proverava da li se SifS ne nalazi u
pogledu LosRaspored I da li se nalazi u tabeli POHADJA. U prvom upitu ovu poslednju proveru nismo morali da radimo, jer
je ona odradjena pri kreiranju pogleda, pa se zna da student koji ima los raspored pohadja neki predmet. U drugom upitu
to treba da se odradi da ne bismo pored studenta koji ne pohadja nista napisali da mu je raspored dobar.

5. Zadatak

Resenje:

Prvo formiramo pogled IznosPoDatumu koji ima dve kolone: Datum I Total. U njemu mozemo da procitamo koliki je
ukupan iznos svih racuna za svaki dan(datum). Pogled formiramo tako sto u prvu kolonu upisemo R.Datum a u drugu
SUM(S.Iznos) iz tabele koja nastaje upitom nad vise tabela(RACUN I STAVKA_RACUNA), za one redove za koje je ispunjen
uslov da je R.SifR=S.SifR. I onda izvrsimo grupisanje po R.Datum. Pre grupisanja smo u novonastaloj tabeli za svaki datum
imali iznos koji predstavlja sumu svih stavki sa jednog racuna. Ako je jednog dana izdato vise racuna(sto je veoma
verovatno) onda u ovoj tabeli postoji onoliko redova sa istim datumom koliko postoji racuna za taj datum. Grupisanjem
po datumu se dobija tabela u kojoj za svaki datum postoji jedan red. Tako u nasem pogledu u koloni Datum se nalaze
datimi koji bi mogli biti primarni kljuc(jer se ne ponavljaju), a u koloni Total za taj datum se nalazi totalna suma iznosa
svih racuna koji su izdati tog dana.
U upitu onda selektujemo A.Datum I SUM(B.Total) iz tabele koja nastaje upitom nad pogledom IznosPoDatumu koji
kombinujemo sa samim sobom jer tako svaki datum iz prvog pogleda kombinujemo sa svakim datumom iz drugog I onda
za svaki datum iz prvog mozemo da proverimo da li je veci ili jednak datumu iz drugog pogleda. Prvi pogled je pogled A, a
drugi B. Iz te tabele se selektuju oni datumi iz prvog pogleda, koji su veci ili jednaki datumu iz drugog pogleda I izvrsi suma
totalnih polja(polja koja odgovaraju datumu iz drugog pogleda). I na kraju izvrsimo grupisanje po datumu iz prvog
pogleda I tako za svaki datum dobijemo sumu svih racuna za taj datum I sve datume pre njega.
Datum za koji nije izdat ni jedan racun nece uci u pogled, jer postoji uslov da je sifra racuna iz tabele RACUN jednaka sifri
racuna iz tabele STAVKA_RACUNA. Za onaj datum za koji nije izdat ni jedan racun, sifra racuna ne postoji, pa samim tim
ovaj uslov nije ispunjen.

SQL, DDL, DCL

Tipovi podataka:

Kolone mogu biti ovih tipova. CHARACTER[(n)] alocira n bitova u memoriji, a n je opciono, dok kod CHARACTER
VARYING(n) se alocira onoliko bitova u memoriji koliki je string, a n predtavlja maksimlanu duzinu stringa, I ovde je n
obavezno. TIMESTAMP ne unosimo mi, vec se samo unosi u polje kolone I ono predstavlja trenutak kada smo uneli red u
tabelu koju formiramo, dok TIME sami unosimo.
Kreiranje tabela:

U okviru zagrada posle VREATE TABLE Ime_tabele se nalaze dva bloka. Prvi predstavlja definicije kolona, a drugi
ogranicenja tabele I taj je opcioni. U okviru definicija kolona moze postojati vise ogranicenja kolone.
NOT NULL – u toj koloni mora nesto da se nalazi
UNIQUE – ne smeju postojati duplikati(jedinstvena vrednost)
PRIMARY KEY – kolona predstavlja primarni kljuc(to znaci da se u kolononi uvek mora nalaziti nesto I da ne smeju
postojati duplikati  PRIMARY KEY = NOT NULL + UNIQUE)
CHECH(Predikat) – provera raznih uslova; Primer: CHECK(Ime_kolone > 0) – da bi se red uneo, polje u okviru ove kolone
mora da ispuni uslov u zagradi posle CHECK-a(CHECK mora biti ispunjen).
DEFAULT – predstavlja podrazumevane vrednosti za kolonu ako se one ne unesu
REFERNCES Ime_tabele2[(Ime_kolone2)] – predstavlja referencu na strani kljuc iz tabele Ime_tabele2. Ime_kolone2 je
opciono, jer ako se ne stavi, podrazumeva se da se odnosi na PK tabele Ime_tabele2. Naziv kolone koja predstavlja strani
kljuc(tabela Ime_tabele egzistencijalno zavisi od tabele Ime_tabele2, a PK Ime_tabele2 je Ime_kolone2) ne mora biti isti
kao nzaiv PK iz tabele Ime_tabele2. Ovo sto se nalazi ispod REFERENCES predstavlja referencijalni integritet I to je opcioni
deo. Tu mozemo da izaberemo sta se desava sa kolonom u tabeli koja zavisi od druge tabele ako se PK druge tabele
promeni(ON UPDATE) ili obrise(ON DELETE). NO ACTION znaci da se nista ne desava(nista se ne menja); CASCADE znaci
da se brisu svi redovi iz Ime_tabele koji referenciraju vrednost PK iz Ime_tabele2; SET NULL znaci da se stavi NULL ako se
nesto desi; SET DEFAULT znaci da ako se nesto desi, u tu kolonu upisemo vrednost koju smo stavili za DEFAULT.

Primer definije kolone:

SifB INT NOT NULL REFERENCES B(SifB)
SifB je ime kolone; INT je tip kolone; NOT NULL I REFERENCES su ogranicenja kolone. Ovo NOT NULL nam govori da tabela
koja zavisi od tabele B(tabela koju formiramo) u koloni SifB uvek mora imati nesto. To znaci da tabela koju formiramo
egzistencijalno zavisi od tabele B, a posto je kardinalnost uslovljenosti uvek (1), onda to I znaci da mora nesto da se nalazi
u toj koloni.

Ogranicenja na nivou tabele:

To su ogranicenja koja se ticu vise kolona u okviru tabele koju formiramo.
UNIQUE – moze za vise kolona; primer: UNIQUE (SifK, Naziv) I to znaci da ne sme da se pojave SifK I Naziv u jednom redu
da su jednaki SifK I Naziv-u u drugom redu, ali moze da se desi na je Naziv u nekom redu jednak Naziv-u u drugom. Isto
vazi I za SifK.
PRIMARY KEY – kompozitni primarni kljuc
CHECK – provera koja zavisi od vise kolona
FOREIGN KEY – posto je ovo ogranicenje na nivou tabele, moramo da naznacimo koja kolona/kolone Iz tabele koju
formiramo predstavlja/predstavljaju referencu. Zato FOREIGN KEY I REFERENCES idu zajedno.
REFERENCES – isto kao I u ogranicenju na nivou kolone, samo sto moze da se nabroji vise kljuceva(ako u tabeli, od koje
zavisi tabela koju formiramo, primarni kljuc predstavlja kompozitni primarni kljuc). Opet, I ovde je opciono staviti u
zagradu ime kolona iz druge tabele jer se podrazumeva da uzimamo PK I te tabele. Referencijalni integritet(ono ispod
REFERENCES) je isti kao I kod ogranicenja na nivou kolone. Ako se nista ne stavi:
Za ON UPDATE je podrazumevano CASCADE
Za ON DELETE je podrazumevano NO ACTION
Ovo vazi I za ogranicenja na nivou kolone I za ogranicenja na nivou tabele.
Primeri:

U prvom primeru formiramo tabelu Oblast. Ona ima 2 kolone: SifO I Naziv. SifO je string duzine 2, a Naziv string duzine 20
karaktera. SifO je PK, a u koloni Naziv uvek mora nesto da se nalazi I ne smeju postojati 2 ili vise ista naziva. To znaci da I
Naziv I SifO mogu biti PK, ali je stavljeno da je to SifO.
U drugom primeru se formira table Knjiga koja ima 2 kolone. SifK je PK I to je string duzine 3 karaktera, dok je SifN string
duzine 4 karaktera, u njoj uvek mora nesto da se nalazi, I ona predstavlja reference na primarni kljuc iz tabele Naslov.
Referencijalni integritet ne mora da pise ispod, jer to sto pise se I podrazumeva.
U trecem primeru se formira tabela Rezervacija koja ima 3 kolone: SifN je string duzine 4 karaktera I predstavlja referencu
na PK iz tabele Naslov; SifC je string duzine 3 karaktera I predstavlja referencu na PK iz tabele Clan, a Vreme je kolona
koja predstavlja vreme(trenutak) kad smo uneli red u tabelu Rezervacija. Polje u koloni vreme nikad ne sme biti prazno.
Posle definicija kolona sledi ogranicenje na nivou tabele gde kaze da je PK tabele Rezervacija kompozitni PK sacinjen iz
kolona SifN I SifC.
U drugom primeru u ogranicenju kolone SifN stoji NOT NULL pre REFERENCES, dok u trecem primeru ne stoji ni kod SifN
ni kod SifC. To znaci da se NOT NULL podrazumeva zbog one kardinalnosti koju sam spominjao gore. Mislim da je bolje da
se uvek pise NOT NULL(za svaki slucaj).

Pored ogranicenja na nivou kolone I tabele, postoje I ogranicenja na nivou baze.

Ogranicenja na nivou kolone se proveravaju onda kada se menja nesto u toj koloni.
Ogranicenja na nivou tabele se proveravaju onda kada se menja nesto u toj tabeli, odnosno u bilo kojoj koloni te tabele.
Ogranicenja na nivou baze se proveravaju onda kada se menja nesto u toj bazi, odnosno u bilo kojoj tabeli te baze,
odnosno u bilo kojoj koloni bilo koje tabele te baze.
Ovo znaci da je najbolje imati sto manje ogranicenja na nivou baze I tabele. Sve sto moze da se stavi u ogranicenje
kolone, treba tu da se stavi, da bi se izbegla nepotrebna proveravanja na nivou cele tabele ili baze(manje vremena se
utrosi  bolja performansa).

Ogranicenja(pravila) mogu da se formiraju(1. stavka) I isto tako I da se uklanjaju(2. stavka). Primer(3. stavka) predstavlja
kreiranje ogranicenja(pravila) koje se zove Max3Rezervacije I to je ogranicenje na nivou baze. Tu upit vraca sifre clanova
koji imaju vise od 3 rezervacije. Posto ispred tog upita stoji NOT EXISTS to znaci da mi trazimo sifre clanova koji nisu
izvrsili preko 3 rezervacije.

Pravila mogu da se imenuju(1. stavka) I moze da se menja mod pravila(2. stavka). Ovo nisam najbolje shvatio, a nisam
nasao u zadatku, tako da se nadam da nece biti :D
Vec formirana tabela moze da se menja naredbom ALTER TABLE. Posle nje sledi ime tabele koja se menja, a posle imena
sledi izmena tabele koju hocemo da izvrsimo. Ta izmena moze biti izmena kolona ili izmena ogranicenja tabele. Pod
izmenom kolone se podrazumevaju izmene kolona ponaosob. Moze se izmeniti 1 ili vise kolona. Izmena jedne kolone
predstavlja ili dodavanje cele kolone, izmenu postojece ili uklanjanje kolone. Dodavanje kolone se vrsi naredbom ADD
[COLUMN] pa se posle pise definicija te kolone. Izmena postojece kolone se vrsi dodavanjem podrazumevanja ili
njegovim uklanjanjem. Dodavanje podrazumevanja se vrsi naredbom ALTER [COLUMN] pa ime kolone pa SET DEFAULT,
dok se uklanjanje podrazumevanja vrsi naredbom ALTER [COLUMN] pa ime kolone pa DROP DEFAULT. To znaci da izmena
kolone predstavlja samo izmenu podrazumevane vrednosti te kolone I nista vise. To je zato sto ako se postavi neko
ogranicenje na nivou te kolone, I tako formira tabela, nema smisla uvoditi promenu neke osobine kolone jer tako moze
doci do toga da ta kolona ne ispunjava ogranicenje koje je na pocetku postavljeno. Podrazumevana vrednost kolone
nikako ne remeti ogranicenje(osim ako je ogranicenje, npr. da broj u koloni mora biti veci od 5 a mi dodamo
podrazumevanu vrednost kolone na 0. Ovo ipak nema smisla raditi, a I da se uradi, negde bi program pukao, pa je
dozvoljeno menjati podrazumevanu vrednost). I uklanjanje kolone se vrsi naredbom DROP [COLUMN] pa ime kolone.
Pod izmenom ogranicenja tabele se podrazumeva izmena jednog ogranicenja tabele ili vise njih. Izmena jednog
ogranicenja tabele se vrsi ili dodavanjem ogranicenja ili njegovim uklanjanjem. Dodavanje ogranicenja se vrsi naredbom
ADD CONSTRAINT I posle toga se napise to ogranicenje, dok se uklanjanje ogranicenja vrsi naredbom DROP CONSTRAINT
pa onda ime ogranicenja(iako ne pise ovde u primeru, treba da se stavi ime ogranicenja).
Pored svega toga, tabela moze I da se ukloni:

To se vrsi naredbom DROP TABLE pa ime tabele.

Indeksi nece biti na kolokvijumu. Indeksi sluze da se ubrza pretraga unutar tabele. Oni u pozadini stvaraju B+ stablo koje
omogucava laksu pretragu, ali se velicina baze povecava, nekad I za duplo.

Nesto jos malo o pogledima, iako je sve do sad predjeno. Uglavno kao podsecanje.

Primeri:
1. Primer

Resenje:
U ovom zadatku se formira tabela STAVKA_RAVUCUNA. Kolone te tabele se citaju iz relacionog modela u postavci
zadatka. Ako bude dat model entiteta I odnosa onda se cita sa te seme(onda treba obratiti paznju na strane kljuceve).
Upit koji se nalazi u CHECK delu broji koliko je do tog trenutka uneto racuna jer redni broj treba biti sukcesivan, a to se
ispunjava tako sto se on izjednaci sa brojem unetih sifri racuna. Ipak, moze se desiti da se neki racun obrise, I da je pre
brisanja, npr. poslednji redni broj bio 5, a kad se neki racun obrise iz baze(pa samim tim I njegova sifra), onda sledecim
ubacivanjem racuna dobijamo opet da je redni broj 5. To se moze spreciti tako sto se umesto COUNT(*) stavi
MAX(RedniBr) + 1. Sto se tice ostalih kolona, njihovo definisanje je jednostavno. SifS je ceo broj I primarni kljuc; SifR je
ceo broj I strani kljuc I ne sme biti NULL. Isto vazi I za SifPr. Posle REFERENCES pa ime tabele ne mora da pise nista vise jer
se sve to ostalo podrazumeva. Kolicina je ceo broj, uvek mora postojati I stavljen je uslov da mora biti veca od 0. Ne pise
u zadatku da treba, ali nema poente da se u stavci racuna nalazi neki proizvod ako je njegova kolicina 0 ili manja. Tako da
treba obratiti paznju I na takve stvari(kad je nesto logicno). RedniBr je isto ceo broj, uvek mora postojati I mora biti
sukcesivan. Zato I postoji onaj upit pod CHECK-om. Iznos je realan broj I uvek mora postojati. Tu bi npr. bilo lepo da se
stavi CHECK (Iznos >=0) iako ne stoji. Ovo jednako sam stavio ako neko npr. ima neki kupon ili popust :D
Posle definicija kolona sledi ogranicenje na nivou tabele. Posto u zadatku pise da se jedan proizvod ne sme pojavljivati na
racunu u vise stavki, taj uslov je ispunjen prvim UNIQUE-om. Drugi UNIQUE postoji jer pise da se stavke jednog racuna
moraju unositi redom, pa on omogucava da SifR I RedniBr zajedno budu jedinstveni. Ipak, on uopste nije morao da se
napise jer samo ogranicenje na nivou kolone RedniBr koje omogucava sukcesivan unos rednog broja za odredjeni racun,
omogucava I to.
Poslednje ogranicenje ProverIznosa je ogranicenje na nivou baze. Ogranicenje na nivou baze se formira onda kada nam
treba informacija iz vise tabela. Tu se vrsi provera za iznos sa stavke racuna. Ipak, ovo ogranicenja nam onemogucava da
nekad promenimo cenu nekog proizvoda.

2. Primer
Resenje:

Opet, kolone citamo iz relacionog modela. U ovakvim zadacima, jedino treba obratiti paznju na uslove, a ostalo je dosta
jednostavno. Uslovi se postizu ogranicenjima(da li na nivou kolone, tabele ili baze, svejedno, ali ako je moguce na nivou
kolone, onda tu). U koloni Termin se u CHECKU stavlja uslov da termin moze biti u opsegu od 1 do 7. Za kolonu Dan isto,
samo sa drugim predikatom.
Posle ovoga slede ogranicenja na nivou tabele. Prvim ogranicenjem se postize da se nikad ne desi da na isti dan, u istom
terminu neki profesor drzi predavanje. Drugim ogranicenjem se postize da se nikad ne desi da je na isti dan, u istom
terminu zauzeta ista ucionica.
Posle kreiranja tabele sledi ogranicenje na nivou baze. Ovim ogranicenjem proveravamo broj prijavljenih studenata. Ovo
ogranicenje nije moglo da se napravi na nivou tabele jer se u njemu koriste 2 tabele. Ovim ogranicenjem
onemogucavamo da se u neku ucionicu za koji pravimo raspored(U.SifU = R.SifU) prijavi vise studenata nego sto u njoj
ima mesta(R.BrPrijavljenih > U.BrMesta).

3. Primer

Resenje:
Ovaj zadatak je jednostavan. Uslovi su svi ok, jedino treba obratiti paznju na ogranicenja na nivou tabele. Prvo
ogranicenje(CHECK) nam onemogucava pojavu utakmice na kojoj ce isti tim biti I domacin I gost, odnosno pojavu
utkamice sa jednim timom. Iako to ne pise u zadatku, to je jedna od onih stvari na koje treba obratiti paznju. Drugo
ogranicenje nam omogucava da svaki par timova odigra 2 utakmice, pri cemu je jedna na domacem, a druga na
gostujucem terenu.

4. Primer

Resenje:

I u ovom zadatku je sve jednostavno, do ogranicenja na nivou tabele. Prvo ogranicenje ispunjava poslednji uslov u
zadatku, dok je drugo ogranicenje malcice komplikovanije. Ovim podupitima se u stvari postize da se nadje cena za
poslednji datum nabavke neke robe(poslednji datum je MAX(N3.DATUM), a cena je N.Cena) I onda se to pomnozi sa 1.1,
sto je 110% I stavi uslov da cena te robe koja se posmatra ne sme biti veca od toga. Ovde bi trebalo da stoji znak > a ne <=
jer mi trazimo redove koji imaju cenu koja je skuplja za vise od 10% od cene pri prethodnoj nabavci te robe. Jer ako taj
red postoji, onda NOT EXISTS (SELECT …) vraca FALSE I uslov u zadatku nije ispunjen. Ove provere se vrse kad god se
pokusa neka izmena nad podacima u bazi. Ako uslov nije ispunjen, odbija se izmena I baza zadrzava staro stanje.

5. Primer

Zadatak koji je dat na slajdovima ne treba jos da se radi jer tu treba da se koriste transakcije, da bi se on ispravno uradio,
a to jo nismo radili. Pa treba samo da se napravi tabela PODACI(to smo radili sa Hadzicem).
Resenje:

CREATE TABLE PODACI (

SifP INTEGER PRIMARY KEY
I INTEGER NOT NULL CHECK(I > 0)
J INTEGER NOT NULL CHECK (J > 0)
Vrednost INTEGER NOT NULL
SifM INTEGER NOT NULL REFERENCES MATRICA
UNIQUE(SifM, I, J)
);

CREATE ASSERTION PROVERA

CHECK(NOT EXISTS(SELECT *
FROM PODACI P, MATRICA M
WHERE M.SifM = P.SifM AND (P.I > M.BrVrsta OR P.J > M.BrKolona)
)
);

U ovom zadatku postoji jedno ogranicenje na nivou tabele I ono omogucava da SifM, I, J budu jednistveni, odnosno
onemogucava da se za jednu matricu vise puta definise vrednost istog polja. I postoji jedno ogranicenje na nivou baze. U
njemu se vrsi provera da li I prelazi broj vrsta I da li J prelazi broj kolona.
Mogli smo kao primer(sto smo uradili na casu), da u ovom zadatku napisemo posle REFERENCES MATRICA ON UPDATE
SET DEFAULT, a pre toga da napisemo DEFAULT = -1. To bi podrazumevalo da postoji matrica u tabeli MATRICA sa SifM = -
1 jer se mi referenciramo na nju.

Jos ponesto:
- Sve sto moze da bude primarni kljuc u tabeli(npr. u tabeli STUDENT BrIndeksa I SifS), a nije, treba da bude UNIQUE I
NOT NULL.
- Count ne broji NULL vrednosti.
- AVG za NULL vrednosti racuna 0. To znaci da on dodaje 0 za svako NULL polje, a sumu deli sa velicinom kolone. To
nije prava prosecna vrednost, jer prosecna vrednost treba da se racuna samo za polja koja nisu NULL. To bi se dobilo
tako sto bismo sumu svih polja podelili sa brojem polja koja nisu NULL: SUM(Ime_kolone) / COUNT (Ime_kolone).
- COUNT moze da prebrojava I duplicate(to se podrazumeva), a moze I samo one razlicite – COUNT(DISTINCT
Ime_kolone).
- BETWEEN 1 AND 31 ukljucuje donju(1) I gornju(31) granicu.
- Kada pravimo svodni upit(upit sa grupisanjem), ono sto se nalazi posle SELECT-a mora da se nalazi I u GROUP BY-u
ako u SELECT-u postoji bar jedna agragatna funkcija. Tada se u GROUP BY-u nalazi sve iz SELECT-a, a mogu jos I neke
kolone. SELECT je tada podskup GROUP BY-a.
- Odeljak WHERE u okviru upita se izvrsava pre formiranja rezultata.
- Odeljak HAVING u okviru upita se izvrsava nakon formiranja grupe, I onda se formira rezultat.
Normalizacija
Normalizacija predstavlja postupak “sredjivanja” baze tako da ona bude sto optimalnija I sto se tice zauzeca memorije, I
njene obrade(vremenski) I sto se tice njenog razumevanja I logike na koji su odredjeni entiteti povezani, … Odnosno,
normalizacija predstavlja set pravila koja bi trebalo da baza zadovoljava da bi radila sto bolje. Sto je tih pravila koja baza
zadovoljave vise, to baza bolje radi.

Relacija je sinonim za tabelu.

Unikatnost se odnosi na uvek isti broj kolona, Identifikacioni integritet za primarni kljuc znaci postojanje samo 1 PK(sto je I
logicno), … Ovo su osobine, odnosno ciljevi normalizacije.
Poslednje tri stavke predstavljaju moguce nepravilnosti odnosno stvari na koje treba da se obrati paznja.
Primer:

U tabeli AUTOR SifA je sifra autora, SifN je sifra naslova, a Koji predstavlja ime naslova knjige koju je odredjeni autor napisao.
PK je kompozitni PK, jer da je npr. samo SifA PK, onda ne bismo mogli u tabelu da unesemo vise dela jednog autora. Kada
bismo popunjavali tu tabelu, doslo bi do nagomilavanja nepotrebnih, odnosno poznatih informacija. Npr. ako bi se unelo vise
redova za jednog istog autora(ista SifA I Ime), mi bismo na osnovu njegove sifre znali njegovo ime I nema potrebe da se ono
svaki put unosi. Takodje, ako bismo hteli da promenimo ime za odredjenu SifA, onda bismo menjali vise polja. Generalno, ova
tabela I nema bas smisla da postoji kao ovakva bas I zbog ovakvog kompozitnog PK I zbog nepotrebnog zauzeca
memorije(unosenje svaki put imena) I menjanja odredjenih kolona. Taj problem moze da se resi dekompozicijom, odnosno da
se naprave 2 tabele koje ce imati neke od ovih kolona, a morace da imaju jednu istu kolonu, koja ce da ih povezuje(SK). Npr.
bilo bi dobro da jedna tabela ima kolone SifA(PK) I Ime, a druga tabela SifN(PK), Koji I SifA(SK). Tako bismo uvek mogli da
vidimo koji autor je napisao koji naslov I koje je njegovo ime. Ne bi bilo nepotrebnog zauzeca memorije a I problem menjanja
neke vrednosti bi nestao.
Postoji I suprotan proces – prirodno spajanje – spajanje 2 tabele u jednu preko iste kolone. To se pise ovako: Tabela1 x*
Tabela2(valjda se tako pise, mada nije ni bitno).
Jos jedan primer:
Trebalo bi da je SifN sifra naslova, SifC sifra clana, SifK sifra knjige. Onda uopste nema smisla imati ovkavku tabelu. SifC, SifK I
Datum mogu da identifikuju pozajmicu. Ako se zna koja je knjiga(SifK) onda nema potrebe pamtiti I SifN u tabeli koja nam
govori o pozajmicama. Takodje, moze da se desi da se za istu SifN I Datum, a razlicitu SifC stavi ista SifK(to bi znacilo da su 2
razlicita clana uzeli istu knjigu na isti datum) sto je, naravno, nemoguce. Opet nema smisla da postoji ovakva tabela u bazi.
Prvi primer dekompozicije(gde tabela POZ2 ima samo kolonu SifN) nije zadovoljavajuc jer tabele POZ1 I POZ2 nemaju kolonu
preko koje ce biti povezane, a I tabela POZ2 nam ne daju nikakvu informaciju.
Drugi primer dekompozicije(gde tabela POZ2 ima 2 kolone – SifK(PK) I SifN) je zadovoljavajuc. Preko tabele POZ2 za svaku
knjigu mozemo da vidimo sifru naslova te knjige I ako nas zanima, naslov procitamo iz neke tabele koja npr. ima SifN(PK) I
Naslov kao kolone(pretpostavlja se da takva tabela postoji u bazi). Tabele POZ1 I POZ2 su povezane preko kolone SifK, I iz
tabele POZ1 sada mozemo procitati sve informacije o pozajmici I ne postoji mogucnost greske.
I, ova recenica da je dekompozicija bez gubitaka akko je reverzibilna znaci da ako smo dobro izvrsili dekompoziciju(nije doslo
do gubitaka), sto je I cilj, onda se prirodnim spajanjem moze rekonstruisati pocetna tabela.

Sada na slajdovima se nalazi sledeci slajd. To je vise teorijski, pa I nije toliko bitno.. Bice objasnjeno kroz zadtke, ali neka stoji
ovde:
Npr. za neku tabelu koja ima kolone A, B, C, D, E i F funkcijske zavisnosti mogu da se prikazu na sledeci nacin: F={A->B, B->C,
DE->F, C->D}. To znaci da ako poznajemo ono sto se nalazi u koloni A, onda znamo I sta ce se nalaziti u koloni B(u istom redu).
Isto, ako znamo sta se nalazi u koloni B, znamo I sta se nalazi u istom redu kolone C. Ako znamo sta se nalazi u kolonama D i E
onda znamo sta se nalazi u koloni G i ako znamo sta se nalazi u koloni C, znacemo sta se nalazi u koloni D. To smo procitali iz
funkcijske zavisnosti. Ali, sada mozemo da vidimo da ako znamo A, tada znamo I B, a ako znamo B, onda znamo I C, pa samim
tim iz A znamo I C. Ako znamo C, onda znamo I D,sto znaci da iz A znamo I D, kao I da iz B znamo D. To sve se zapisuje preko
zatvaraca skupa funkcijskih zavisnosti.
A+->B, C, D
B+->C, D
C+->D
D+->/
E+->/
F+->/
Sada kada imamo zatvarace skupa za svaku kolonu ponaosob, treba da pravimo zatvarace za sve kombinacije 2 kolone, pa 3,
pa dokle god je potrebno. Posto je to dugacko, necu da pisem za sve. Kada neki kljuc/evi jeste/su deo KK, oni ne treba da
ucestvuju u ostalim pretragama.
AB+->C, D
DE+->F
…
Naravno, za svaki zatvarac skupa, ono sto se nalazi sa leve strane, nalazi se I sa desne(podrazumeva se, pa ne mora da se
pise). Logicno je da iz A znamo sta se nalazi u A :D to bi se pisalo ovako: A+->A, B, C, D ali to A nije obavezno.
Primer:
Moze da se pise I SifN+= i SifN+->. Svejedno je. Ne mora da se radi ovako po koracima.

Kada hocemo da izvrsimo dekompoziciju, to treba da se uradi tako da se ne izgube neke funkcijske zavisnosti. Sve funkcijske
zavisnosti koje vaze za pocetnu tabelu treba da vaze I za novonastale tabele. Skup F je skup funkcijskih zavisnosti.

Treba znati sta koja funkcijska zavisnost predstavlja jer ce to biti potrebno kod odredjivanja normalnih formi.
Superkljucna funkcijska zavisnost je zavisnost gde je ono sto se nalazi sa leve strane deo PK.
Trivijalna funkcijska zavisnost je zavisnost kada je Y pravi podskup od X. Pravi podskup je skup svih podskupova datog skupa
osim tog celog skupa. Primer: ABC->BC jeste pravi podskup, dok ABC->ABC nije.

Primeri:
1. a)
Ovde je uradjen zatvarac skupa funkcijskih zavisnosti za sve kombinacije. Na taj nacin se dolazi do KK(kandidat kljucava). Sada
bilo koji od KK moze biti PK. KK je onaj kljuc iz kojeg mozemo da saznamo sve ostale kljuceve I on predstavlja UNIQUE
vrednosti. Ovde je npr. i KK AB ali nema potrebe da se pise, jer je I sam A KK. KK AB se naziva superkljuc.
Inace, kada pise A->BC, to moze I da se napise kao A->B, C a moze I kao A->B, A->C.

b)

Nakon izvrsene dekompozicije dobili smo dve tabele – R1 I R2. Sada treba da proverimo da li smo izgubili neku funkcijsku
zavisnost u odnosu na funkcijske zavisnosti pocetne tabele – R.
Prvo pravimo sve zatvarace skupova zavisnosti za jednu tabelu I tako dolazimo do skupa funkcijski zavisnosti F1. To je skup
funkcijskih zavisnosti za tabelu R1. Onda isto to uradimo I za tabelu R2 I dobijemo F2. Posto nije uradjeno korak po korak na
slajdu, to izgleda ovako:
R1(A, B, C)
A+->B, C
B+->/
C+->/
BC+->A
To znaci da su KK={A, BC}. Za odredjivanje zatvaraca skupa funkcijskih zavisnosti, koriste se funkcijske zavisnosti pocetne table
R, a to su funkcijske zavisnosti iz skupa F. To sto smo izvrsili dekompoziciju ne znaci da ne treba da ih koristimo. Bas naprotiv,
nama je cilj da nakon dekompozicije sve funkcijske zavisnosti iz skupa F postoje u uniji skupova F1 I F2. Naravno, iz A znamo I
D i E, ali ne treba da ih pisemo, jer se oni ne nalaze u tabeli R1.
Znaci: F1={A->BC, BC->A}

R2(A, D, E)
A+->D, E
D+->/
E+->A, D
Znaci KK={A, E}
F2={A->DE, E-AD}

F1 U F2={A->BC, BC->A, A->DE, E->AD}={A->BCDE, BC->A, E->AD}

Sada ovo treba da proverimo sa F I da vidimo da li sve funkcijske zavisnosti iz F postoje I u F1 U F2. Funkcijske zavisnosti CD->E
i B->D ne postoje u skupu F1 U F2, ali postoje u skupu F, sto znaci da je doslo do gubitka funkcijskih zavisnosti. To znaci da
ovakva dekompozicija ne treba da se radi. Nama ovde nije trazeno da odradimo dobru dekompoziciju vec samo da proverimo
da li je doslo do gubitka funkcijskih zavisnosti, a jeste.
c)

Ovo je jos jedan primer dekompozicije, ali ni ovo ne valja jer dolazi do gubitka pri spajanju.
d)

I ovo je jos jedan primer koji zadovoljava sve uslove. Nema gubitaka I dekompozicija je izvrsena na dobar nacin.
Spajanje tabela R1 i R4 se prikazuje kao R1, R4.
Kada se spajaju 2 tabele koje imaju isti KK onda nema gubitaka pri spajanju.

Algoritam za brze pronalazenje KK je sledeci:

Treba da zabelezimo 4 stvari:
- n – elementi koji se nalaze u tabeli, ali ne I u funkcijskim zavisnostima
- l – elementi koji se nalaze sa leve strane funkcijskih zavisnosti
- d – elementi koji se nalaze sa desne strane funkcijskih zavisnosti
- o – elementi koji se nalaze sa obe strane funkcijskih zavisnosti
Nakon toga se izvrsi unija n i l(n U l) i izvrsi zatvarac skupa rezultata unije. Ako se tako ne dobije KK, onda se taj rezultat
kombinuje sa kljucevima iz o I ivrsavaju se zatvaraci skupova tih kombinacija I trazi se KK. Primer upotrebe ovog algoritma je
dat u 4. zadatku. Nije neophodno koristiti ovaj algoritam, ali je on dobar kada pocetna tabela ima veliki broj kljuceva I
funkcijskih zavisnosti.

Normalne forme(NF)
Postoje razlicite normalne forme. Za neku bazu se kaze da se nalazi u odgovarajucoj NF ako zadovoljava uslove te NF. One su:
1NF, 2NF, 3NF, BCNF i 4NF. Potrebno je da znamo sta je 2NF, 3NF i BCNF. Da bi baza bila u nekoj NF, tada svaka zavisnost
treba da zadovoljava uslove te NF.
- Baza je u 1NF ako je svako njeno polje(kolona) nedeljivo. Primer koji je dao Tubic je: Ako umesto kolone Adresa
imamo kolone Grad, ImeUlice i Broj. Mada ovo I nije bas dobar primer, jer smo mi pravili tabele sa kolonama Adresa..
Ali mi cemo uvek dobijati bazu koja je sigurno u 1NF pa o tome ne treba da vodimo racuna. Zato je za nas I bitno 2NF,
3NF I BCNF
- Baza je u 2NF ako u svakoj zavisnosti ono sto se nalazi desno od -> ne zavisi parcijalno od KK. To znaci da ono sto se
nalazi sa leve strane -> ne sme biti deo KK(sme ceo KK ali ne deo).
- Baza je u 3NF ako je svaka zavisnost ili trivijalna ili superkljucna(desna strana je superkljuc) ili je desna strana deo KK.
Ovde se pod superkljucem smatra I sam KK.
- Baza je u BCNF ako je svaka zavisnost ili trivijalna ili superkljucna(desna strana je superkljuc). Ovde se pod
superkljucem smatra I sam KK.
Ako je baza u 3NF, onda je I u 2NF I u 1NF. Isto tako, ako baza nije u 2NF, onda nije ni u 3NF ni u BCNF.
Ako baza ne zadovoljava odredjenu NF, vrsi se dekompozicija. Algoritam za dekompoziciju je sledeci:
U zavisnoti od NF koju baza treba da zadovolji, zaokruzimo u skupu funkcijskih zavisnosti sve one koje ne zadovoljavaju uslov
odredjene NF. Sada se prave nove tabele. Za svaku zavisnost koja je zaokruzena se napravi po 1 tabela sa imenima onih
kolona koje se nalaze u toj zavisnosti. Sada slede 3 koraka koja su ista za bilo koju NF.
1. Korak – Provera sadrzajnosti
Proverava se da li se jedna tabela sadrzi u drugoj. Odnosno da li je jedna tabela podskup druge. Ako takva tabela postoji,
nju uklanjamo.
2. Korak – Proverava se da li se KK nalazi u nekoj od tabela
Ako se KK ne nalazi ni u jednoj od tabela, onda se pravi nova tabela sa KK.
3. Korak – Proverava se da li se sve kolone iz pocetne tabele nalaze u nekoj od tabela. Ako postoji kolona koja se ne
nalazi ni u jednoj od novonastalih tabela, ona se ubacuje u bilo koju od tabela.
Kada se zavrse ova 3 koraka, doveli smo bazu u oddredjenu NF.
Primer za 2NF:

KK={SifA SifN}; to je kompozitni PK. Cim jedna zavisnost nije u 2NF, onda se radi dekompozicija. Tako smo ovde napravili 2
nove tabele kod kojih imamo 2 skupa funkcijskih zavisnosti. Sada svaka zavisnost, u odnosu na svoju tabelu, jestu u 2NF.
Primer za 3NF:

KK={SifN SifA}. Posto ne zadovoljavaju sve zavisnosti 2NF, samim time ne zadovoljavju ni 3NF. Opet se vrsi dekompozicija. I
ovde I u prethodnom primeru je izvrsen algoritam za dekompoziciju. Nakon dekompozicije smo bazu doveli u 3NF. Ali, da smo
npr. hteli da je dovedemo u 2NF, onda bismo zaokruzili samo one zavisnosti koje ne zadovoljavaju 2NF(SifN->Naziv, SifO I
SifA->Ime) I onda odradili ona 3 koraka. Tako bismo bazu doveli u 2NF, ali ona I dalje ne bi bila u 3NF.
Primer za BCNF:
KK={SifK SifC Datum}. Odradjen je onaj algoritam I tako je dobijeno ovo resenje sa 3 nove tabele.
Jedina stvar je u tome sto taj algoritam za 2NF I 3NF garantuje negubljenje funkcijskih zavisnosti dok za BCNF ne garantuje.
2. Zadatak

Ovaj zadatak je generalno jednostavan, a I ove stvari ce se raditi I u narednim zadacima, pa ga necu raditi. Poenta je samo da
se izvrsi dekomponovanje poo nom algoritmu do BCNF-a. Prvo se nadju KK, a to je ovde AC. Zavisnost B->C ne zadovoljava
uslov za BCNF, dok zavisnost AC->B zadovoljava. Onda se izvrsi taj algoritam, pa se ispitaju sve funkcijske zavisnosti novih
skupova funkcijskih zavisnosti I proveri se koja je izgubljena. Treba da proverimo da li smo izgubili neku funkcijsku zavisnost u
odnosu na funkcijske zavisnosti pocetne tabele. Prvo pravimo sve zatvarace skupova zavisnosti za jednu tabelu I tako
dolazimo do skupa funkcijski zavisnosti F1. To je skup funkcijskih zavisnosti za prvu tabelu. Onda isto to uradimo I za
ostale/ostalu tabele I dobijemo ostale skupove funkcijskih zavisnosti. Onda uradimo uniju svih funkcijskih zavisnosti I vidimo
koja je izgubljena u odnosu na pocetne zavisnosti(zavisnosti iz skupa F).
3. Zadatak

Za proveru da li skup F logicki implicira funkcijsku zavisnost C->DE treba da napravimo zatvarac skupa za C.
C+-> D, E
Posto iz C-a znamo D, a iz D-a znam E, onda I iz C-a znamo E, pa samim tim skup F logicki implicira funkcijsku zavisnost C->DE.
Sada treba da proverimo da li dekompozicija na R1 I R2 zadovoljava BCNF.
Uvek je dobro na pocetku odrediti KK.
A+->/
B+->/
C+->D, E
D+->E
E+->/
AB+->C, D, E
…
Ovde je samo AB KK. Nisam nastavio dalje provere jer se vidi da nista ostalo nece biti.  KK={AB} To znaci da je AB
kompozitni PK za tabelu R.
Sada treba da odredimo sve funkcijske zavisnosti za tabelu R1 I R2 I napravimo njihovu uniju I proverimo da li se tu nalaze sve
zavisnosti kao I u skupu F.
R1(C, D, E)
C+->D, E
D+->E
E+->/
DE+->/
To znaci da vazi: KK={C} i F1={C->DE}; zavisnost C->DE je superkjlucna I onda ona zadovoljava BCNF

R2(A, B, C)
A+->/
B+->/
C+->/
AB+->C
AC+->/
BC+->/
Vazi: KK={AB} i F2={AB->C}; zavisnost AB->C je superkjlucna I onda ona zadovoljava BCNF

F1 U F2={C->DE, AB->C}={C->D, C->E, AB-> C}

Sada treba da proverimo ovaj skup sa skupom F.
F={ AB-> C, C->D, D->E}
AB->C se nalazi u oba skupa
C->D se nalazi u oba skupa
D->E se nalazi samo u skupu F
Posto su obe tabele u BCNF-u onda ova dekompozicija zadovoljava BCNF, ali je doslo do gubitka funkcijske zavisnosti.

4. Zadatak

U ovom zadatku je dat KK, ali ako ne bude dat, uvek se prvo on nadje. Ja cu da odradim njegovo nalazenje preko algoritma za
pronalazak KK.
n:/
l: C D
d: E F
o: A B

n U l = CD  CD+->F A B E  CD jeste KK  KK={CD}

Da CD nije KK, onda bi se rezultat ove unije(CD) kombinovao sa elementima iz o I proveravalo bi se CDA+->, CDB+-> i CDAB+->.

a)
A->B D->FA B->E C->A
BCNF X X X X
3NF X X X X
2NF √ X √ X

Ako je u nekom redu svako polje stiklirano, onda tabela zadovoljava tu NF. Ako makar jedno polje tog reda nije stiklirano,
onda tabela ne zadovoljava tu NF. Ovde tabela ne zadovoljava ni jednu od ove 3 NF.

b)
Sada samo pratimo korake algoritma.
R1(A, B) R2(D, F, A) R3(B, E) R4(C, A)
1. Korak – sve je ok, nema promena
2. Korak – KK nije ni u jednoj od tabela pravi se nova tabela sa KK
R1(A, B) R2(D, F, A) R3(B, E) R4(C, A) R5(C, D)
3. Korak- svi elementi su sadrzani u tabelama  sve je ok
Sada smo zavrsili algoritam I doveli bazu/tabelu u 3NF.

c)
Semu treba da dovedemo u BCNF izdvajajuci zavisnosti redosledom s leva na desno. To se radi na sledeci nacin:
Prvo se iz tabele R(A, B, C, D, E, F) naprave 2 tabele:
R1(A, B) – ovo je tabela za prvom zavisnosti(posto se ide sa leva na desno)
A+->B
B+->/
Vazi: KK={A} i F1={A->B} I ova zavisnost je superkljucna, pa onda zadovoljava BCNF

R1’(A, C, D, E, F) – ovo je druga tabela koja je nastala iz R a ona nastaje tako sto se iz tabele R izbace oni elementi koji se
nalaze sa desne strane -> odgovarajuce funkcijske zavisnosti.
Sada od tabele R1’ pravimo nove 2 tabele na isti nacin. Sada gledamo zavisnost D->FA:
R2(D, F, A)
D+->F, A
F+->/
A+->/
Vazi: KK={D} i F2={D->FA} I ova zavisnost je superkljucna, pa onda zadovoljava BCNF

R1’’(C, D, E)
Sada iz tabele R1’’ treba da se naprave 2 nove tabele. Zavisnost koju gledamo je B->E. Ali posto u tabeli R1’’ nemamo B, onda
ne mozemo to da uradimo. Takodje, ne moze ni da se nastavi dekomponovanje po zavisnosti C->A. Dekomponovanje ne
moze da se nastavi za onu zavisnost za koju fali bilo koji element sa leve strane ili svi elementi sa desne strane. Sada gledamo
da li tabela R1’’ zadovoljava BCNF.
C+->E
D+->E
E+->/
Vazi: KK={CDE} i F1’’={C->E, D->E} i ova zavisnost ne zadovoljava BCNF pa treba da nastavimo da vrsimo dekompoziciju. Da su
obe ove zavisnosti zadovoljavale uslov za BCNF, zavrsili bismo sa dekomponovanjem.
Sada vrsimo dekompoziciju tabele R1’’ na isti nacin kao sto smo krenuli da radimo dekompoziciju tabele R. Imamo 2
zavisnosti: C->E i D->E koje obe ne zadovoljavaju uslov za BCNF. To znaci da mozemo da vrsimo dekompoziciju po bilo kojoj
od te zavisnosti(posto za ovo ne pise da se radi sa leva u desno) sto znaci da moze postojati vise resenja. Ako nastavimo sa
dekompozicijom po C->E, onda dobijamo sledece 2 nove tabele:
R3(C, E)
C+->E
E+->/
Vazi: KK={C} i F3={C->E} I ova zavisnost je superkljucna, pa onda zadovoljava BCNF

R1’’’(C, D)
Opet, od tabele R1’’’ ne mogu da se naprave 2 tabele ako se dekompozicija vrsi po D->E. To znaci da sada treba da proverimo
da li sama tabela R1’’’ zadovoljava BCNF.
C+->/
D+->/
CD+->CD
Vazi: KK={CD} i F1’’’={CD->CD}={ } I ova zavisnost je trivijalna, pa onda zadovoljava BCNF

Sada smo sproveli normalizaciju date seme u BCNF izdvajajuci zavisnosti redosledom s leva u desno. Dobijene tabele su:
R1(A, B) R2(D, F, A) R3(C, E) R1’’’(C, D)

d)
F1 U F2 U F3 U F1’’’={A->B, D->FA, C->E}
F={A->B, D->FA, B->E, C->A}
Kada uporedimo ova dva skupa, vidi se da su se izgubile zavisnosti B->E i C->A.

5. Zadatak

U ovom zadatku je dat KK, pa ne mora da se trazi. Ono sto se trazi je da se skup F dovede do skupa Fc I da se onda izvrsi
normalizacija seme do 3NF.
Fc je kanonicni pokrivac skupa funkcijskih zavisnosti I to je skup koji predstavlja minimalni broj funkcijskih zavisnosti sa
minimalnim brojem elemenata tako da sve funkcijske zavisnosti iz skupa F I dalje vaze. Nekada I skup F predstavlja skup Fc.
Npr. ako bi bilo F={A->B, B->C, A->C}, tada nam zavisnost A->C nije neophodna jer se do nje moze doci preko A->B i B->C, pa je
onda Fc={A->B, B->C}. Naravno, algoritam za to nije bas toliko jednostavan. Algoritam ima 3 koraka I to su:
1. Korak – izostavljanje jednog po jednog elementa sa leve strane ->, pa se ovaj korak radi samo za one zavisnosti koje
sa leve strane -> imaju 2 ili vise elementa. Ovaj korak se zavrsava kada se to odradi za sve funkcijske zavisnosti.
2. Korak – unija svih funkcijskih zavisnosti cija je leva strana ista
3. Korak – izostavljanje elemenata sa desne strane ->, pa se I ovaj korak radi samo za one funkcijske zavisnosti koje sa
desne strane -> imaju 2 ili vise elementa

Kako to izgleda u ovom zadatku:

1. Korak:
- ABH->C
Izostavimo A(proveravamo da li iz BH mozemo doci do C ili do A, jer na taj nacin izostavljanjem A onda nista necemo
promeniti): BH+->E F A D. Mozemo da dodjemo do A I to znaci da umesto ABH->C mozemo da pisemo BH->C.
Izostavimo B: H+->/ I to znaci da B ne smemo da izostavimo
Izostavimo H: B+->/ I to znaci da H ne smemo da izostavimo
Nakon svega ovoga umesto ABH->C mozemo da pisemo BH->C.

- BGH->F
Izostavimo B: GH+->/
Izostavimo G: BH+->C E F. Posto smo dosli do F, to znaci da mozemo G da izostavimo, I umesto BGH->F pisemo BH->F.
Izostavimo H: B+->/
Nakon svega ovoga umesto BGH->F mozemo da pisemo BH->F.

- BH->E
Izostavimo B: H+->/
Izostavimo H: B+->/
Nakon svega ovoga zavisnost BH->E ne mozemo da skratimo.

2. Korak:
Nakon prvog koraka mozemo da napisemo da je F={BH->C, A->D, C->E, BH->F, F->AD, E->F, BH->E} I sada treba da
izvrsimo 2. korak tako sto cemo spojiti sve funkcijske zavisnosti koje imaju iste elemente sa leve strane ->:
F’={BH->CFE, A->D, C->E, F->AD, E->F}.
 3. Korak:
- BH->CFE
Izostavlja se C: BH+->F E. C ne moze da se izostavi
Izostavlja se F: BH+->C E F, pa F moze da se izostavi I sada umesto BH->CFE moze da se pise BH->CE
Izostavlja se E: BH+->C E, pa I E moze da se izostavi I sada umesto BH->CE moze da se pise BH->C
Nakon svega ovoga umesto BH->CFE mozemo da pisemo BH->C.

- F->AD
Izostavlja se A: F+->D. A ne moze da se izostavi
Izostavlja se D: F+->A D, pa D moze da se izostavi.
Nakon svega ovoga umesto F->AD mozemo da pisemo F->A.

To znaci da je F’={BH->C, A->D, C->E, F->A, E->F}=Fc

Sada smo odredili Fc I treba da dovedemo semu u 3NF. To se samo odradi poo nom algoritmu za dekompoziciju(kao 4.
zadatak pod b))

6. Zadatak je za odredjivanje 4NF sto nismo radili.

7. Zadatak

Ovde treba da se odradi samo pod a) a to je samo koriscenje algoritma za dekompoziciju(kao 4. zadatak pod b)).

Transakcije

Primer jedne transakcije:

BEGIN TRANSACT ION
UPDATE ACCOUNTS
SET Money=Money-100
WHERE Id=10

UPDATE ACCOUNTS
SET Money=Money+100
WHERE Id=20
COMMIT

Ovo smo mogli da odradimo I bez BEGIN TRANSACTION i COMMIT, samo sto tada ovo ne bi bilo 100% dobro, jer nakon
izvrsenja prve naredbe moze doci do nekog kvara, gubitka struje, isl. pa se druga naredba ne bi ni izvrsila, a onda se onih 100
din. koji su skinuti sa Id=10 jednostavno izgubilo. Sto ne sme da se desi. Resenje toga je upotreba transakcije koja omogucava
da se ove 2 naredbe izvrse istovremeno.
Operacije koje postoje u okviru transakcija su: Rd/Read(cita podatak), Wr/Write(upisuje vrednost u podatak), COMMIT(kraj
transakcije, potvrdjuje da je sve u redu), RollBack, Abort, Lock(zakljucava podatak tako da ga ostale transakcije ne mogu
koristiti sve dok ga ta transakcija ne otkljuca), Unlock(otkljucava podatak).
Uloga skedzulara(scheduler) je da te operacije poredja onako kako one treba da se izvrsavaju.
Primer jedne operacije:
(Rd, X4, T6)
Ovde se vrsi citanje podatka x4 od strane transakcije T6.

Konfliktne situacije – Primer:

T1 T2
Rd(A) Ovde je svejedno koja ce transakcija prva da se odradi = Rd(A)
Rd(A) Rd(A)

Rd(A) Ovde je bitno koja ce transakcija prva da se odradi ≠ Wr(A)

Wr(A) Rd(A)

Wr(A) Ovde je bitno koja ce transakcija prva da se odradi ≠ Wr(A)

Wr(A) Wr(A)

To znaci da operacija Rd-Rd ne predstavlja konfliktnu situaciju, dok operacije Rd-Wr i Wr-Wr predstavljaju konfliktne situacije.
Naravno, konfliktne situacije postoje samo za iste podatke. A ako se radi o istoj transakciji, onda to nije konfliktna situacija jer
redosled izvrsavanja zavisi od te transakcije. To znaci da se posmatraju operacije Rd-Wr i Wr-Wr nad istim podacima razlicitih
transakcija.
Primer:
Ovde treba svaku operaciju da posmatramo I da je uporedjujemo sa svakom drugom posle nje I da vidimo da li moze doci do
nekog konflikta.
Prvi konflikt nastaje izmedju operacija (Read, X2, T3) i (Write, X2, T4). Po redosledu na primeru, prvo treba da se odradi
transakcija T3, pa tek onda transakcija T4. Zato je iz grafa strelica povucena od T3 ka T4.
Konflikt koji nam govori da strelica treba da ide od T3 ka T6 je (Read, X2, T3) i (Write, X2, T6).
Konflikt koji nam govori da strelica treba da ide od T4 ka T6 je (Read, X2, T4) i (Write, X2, T6).
Konflikt koji nam govori da strelica treba da ide od T3 ka T5 je (Read, X3, T3) i (Write, X3, T5).
Naravno, ovde postoje jos neke konfliktne situacije, ali one ne uticu na formiranje novih veza u grafu.
Da bismo dobili ekvivalentni serijski redosled, na ovaj graf treba da se primeni topolosko sortiranje(prvo se brisu cvorovi ciji je
ulazni stepen 0). Tako se ovde prvo brise T3. Nakon toga, ulazni stepen je jedank 0 za T4 I T5. To znaci da ce biti min 2 resenje.
Ako obrisemo onda T4, ulazni stepen 0 imaju T5 I T6, sto daje jos jedno resenje. Onda moze da se obrise prvo T5 pa T6 ili
obrnuto. A da smo umesto T4 obrisali prvo T5, onda bismo posle toga obrisalo T4 pa T6. To su I resenja koja su data na slici.
Redosled brisanja cvorova predstavlja ekvivalentni serijski redosled(osnosno serijalizovanost).
Sto se tice zadataka kod provere serijalizovanosti, uvek cemo imati transakcije koje prvo vrse citanje nekog podtka, pa onda
upis u njega.
Provera da li je redosled serijalozovan – proverevamo da li se zadovoljeni svi uslovi koji treba da budu zadovoljeni da ne bi
doslo do greske I onda se napise Ti -> Ty -> … Tx -> Tz, a ako nisu zadovoljeni svi uslovi onda nije serijalizovano.

Zakljucavanje I protokoli:
Zakljucavanje moze biti:
- Binarno zakljucavanje – Lock I Unlock
- Kompleksno zakljucavanja – Lock se deli na 2 dela(LockS i LockX) I Unlock
- Zakljucavanje za striktni dvofazni protokol – neka kombinacija ova dva prethodna
Primeri:
T1 T2
Lock(E)
Rd(E)
Wr(e)
Unlock(E)
Lock(E)
Rd(E)
Wr(E)
Unlcok(E)

Operacije u ove dve transakcije ce se izvrsavati ovim redosledom koji se nalazi u tabeli. Tacnije, I ako napisemo da se prvo
izvrsavaju 2 operacije od T1, pa onda Lock(E) od T2, vrsenje instrukcija ce se vratiti na T1, jer je E vec zakljucano u transakciji
T1. Tek kad se izvrsi Unlock(E) u T1, onda se skace na Lock(E) u T2 I izvrsavaju instrukcije u T2.
Sledeci primer je primer kada dolazi do deadlock-a:
T1 T2
Lock(A) Lock(B)
Rd(A) Rd(B)
Lock(B) Lock(A)
Rd(B) Rd(A)
Unlock(A) Unlock(B)
Unlock(B) Unlock(A)
Kada bismo namestili da se operacije izvrsavaju tako sto se prvo odrade 2 iz T1, pa 2 iz T2, to ce biti ok, jer se radi o razlicitim
podacima. Ako posle skocimo na Lock(B) iz T1, to nece moci da se izvrsi jer je B zakljucano u T2, I onda se vraca na operacije iz
T2 I dolazi se do Lock(A) iz T2, a A je zakljucano u T1, pa se vraca na Lock(B) iz T1, pa se onda opet vraca na Lock(A) iz T2, itd.
Tada se ulazi u beskonacno skakanje od T1 do T2 I dolazi se do deadlock-a I tako se zabaguje sistem. To znaci da kada se jedna
stvar zakljuca u jednoj transakciji, da bi ona bila zakljucana I u drugoj transakciji, prvo treba da se otkljuca u prvoj transakciji.
To je sve dvofazni protokol. Faze dvofaznog protokola su:
- Zakljucavanje podataka
- Otkljucavanje podataka
U ovom protokolu, svaki podatak koji se koristi prvo treba da se zakljuca, pa onda da se otkljuca. U jednoj transakciji, nakon
sto se izvrsi makar jedno otkljucavanje, ne moze da se ivrsi ni jedno zakljucavanje, pa onda prvo treba da se odrade
zakljucavanja podataka koji se koriste, pa onda otkljucavanje istih. Ipak, ne treba na samom pocetku zakljucavati sve podatke,
a na kraju ih otkljucati jer je cilj da svaki podatak bude sto krace zakljucan.

1. Zadatak
Prvo se trazi da se izvrsi binarno zakljucavanje. Ovo sto pise u zagradi je ono sto sam napisao gore. Konkurentnost treba da
bude sto veca, pa se zato zakljucavanja rade sto kasnije, a otkljucavanje sto ranije.
Resenje:

Prva tabela predstavlja “spojene” instrukcije, odnosno, ne vidi se redosled izvrsavanja instrukcija. Mi tu tabelu treba da
modifikujemo koristeci binarno zakljucavanje. Druga tabela predstavlja resenje. Iskoriscene su osobine binarnog
zakljucavanja koje su ranije opisane. Ali objasnicu samo za T1. Nama nisu bitne operacije D:=D/5, C:=D*2, … Nas zanima samo
kada se koji podatak kada koristi. Da bismo mogli da izvrsimo Read ili Write(te operacije su nam bitne), pre toga treba
podatak da se zakljuca, a nakon zakljucavanja svih podataka, krece otkljucavanje. Tako je prvo izvrsen Lock(D) pa Read(D). Ne
zanima nas D:=D/5, pa se onda vrsi Lock(C) jer je sledeca operacija Read(C). Onda slede Write(C) I Write(D). Pa posto imamo
Read(I) pre toga mora da se zakljuca, pa se pise Lock(I) prvo. Posto vise nema novih podataka sa kojima se radi, sada se vrse
otkljucavanja podataka koji se vise nece koristiti(bas da bi sto krace bili zakljucani, da bi konkurentnost bila veca). Zato se pre
Read(I) urade Unlock(D) I Unlock(C), pa tek onda Read(I). Onda sledi Write(I), pa Unlock(I) I na samom kraju Commit, za
zavrsavanje transakcije T1. Ista pravila se koriste za ostale transakcije.

Onda se trazi da se izvrsi kompleksno zakljucavanje.

Pracila kompleksnog zakljucavanja:
Postoji isto zakljucavanje I otkljucavanje, ali se zakljucavanje deli na 2 razlicita:
- LockS=LockShare(serovan kljuc) I kada se neki podatak zakljuca uz LockS u jednoj transakciji, on moze isto da se
zakljuca uz LockS u drugoj transakciji, ali to ima smisla stavljati ispred kljuceva koji se samo citaju.
- LockX=LockExclusive I ovo zakljucavanje se koristi pre nego sto se u podatak izvrsi upis.
Znaci, pred Rd se koristi LockS, a pred Wr se koristi LockX. Ako se u jednoj transakciji podatak zakljuca uz pomoc LockS, u
drugoj moze da se zakljuca samo uz LockS. Ako se napise LockX, izvrsavanje instrukcija se vraca na transakciju 1(Naravno, ako
taj podatak nije otkljucan u prvoj transakciji). I u ovom zakljucavanju se kao I u binarnom prvo izvrsavaju zakljucavanja, pa
onda otkljucavanja.
Resenje za kompleksno zakljucavanje:

U trecoj tacki se pita da li operacije u transakcijama dobijene u prvoj tacki mogu da se poredjaju u redosled kao u njihovom
primeru. A ako ne moze, onda treba sami da modifikujemo neke stvari I na taj nacin napravimo dobar redosled izvrsavanja
instrukcija.
Resenje je:

U ovom primeru mogu da se poredjaju onako kako treba. Ali da se npr. podatak A koristio u jos nekoj transakciji(ne samo u
transakciji T2), onda bi posle operacije Read(G) u T2 trebalo otkljucati A, pa ga pre operacije Write(A) opet zakljucati.
Pored ovih zakljucavanja postoji I striktni dvofazni protokol. Jednostavan je dosta. Zakljucavanja se vrse po redu po kojem
treba, prateci pravila binarnog zakljucavanja, dok se sva otkljucavanja vrse nakon Commit-a.

Pod podatkom se smatra polje u tabeli ili kolona ili cela tabela.

2. Zadatak

Resenje:
Redosled izvrsavanja operacija po striktnom dvofaznom protokolu ne moze izgledati kao na slici bas zato sto otkljucavanja
treba da se izvrsavaju posle Commit-a. Zato Lock(A) ne moze da se izvrsi u T2 posle Read(B)) zato sto je A zakljucan u T4, a
moze da se otkljuca tek nakon Commit-a u T4. Tek tada, A moze da se zakljuca u nekoj drugoj transakciji, sto je I odradjeno –
A je zakljucano pre operacije Read(A) uT2. Isto vazi za operaciju Lock(C) u T1. Posto je C zakljucano u T3, da bi se zakljucalo u
bilo kojoj drugoj transakciji, prvo mora da se otkljuca u T3, a to moze tek nakon Commit-a u T3. Zato je Lock(C) u T1 izvrseno
pre Read(C) u T1.

Postoji I protokol u obliku stabla. Za njega postoje 4 pravila:

1. Prvo se zakljucava neki podatak koji mi izaberemo, moze bilo koji
2. Sledeca zakljucavanja se mogu vrsiti samo na direktnim potomcima zakljucanih elemenata
3. Mozemo da otkljucamo kad god hocemo I sta god hocemo
4. Pre Commit-a sve mora biti otkljucano

3. Zadatak

Resenje:
Ovo moze da se odradi na ovaj nacin. Samo se prate pravila ovog protokola. Prvo se zakljucalo E, pa onda njegov potomak D,
pa onda moze C, itd. Ipak, bolje bi bilo da posle Lock(D) stoji Unlock(E), pa Lock(C), pa Unlock(D), itd. Jer se tako prate pravila
protokola, a podaci su krace zakljucani.