Serveri BP

1.
UVOD
Baze podataka se koriste za prikupljanje, čuvanje i manipulaciju podacima na osnovu kojih se dobijaju nove
informacije u različitim organizacijama, kao što su poslovni sistemi, zdravstvo, školstvo, vladine institucije itd.
Svakodnevno ih koriste pojedinci putem ličnih računara, radne grupe putem mrežnih servera i svi zaposleni putem
aplikacija koje se nalaze u poslovnim sistemima. Bazama podataka takođe pristupaju kupci i drugi udaljeni korisnici
korišćenjem različitih tehnologija kao što su govorni automati, web pretraživači.
Serveri mogu da uključe u svoje baze podataka procedure koje se zovu okidači - trigeri koji upozoravaju o mogućim
vanrednim događajima. Baze podataka predstavljaju viši nivo rada s podacima u odnosu na klasične programske
jezike.
Reč je o tehnologiji koja je nastala s namerom da se uklone slabosti tradicionalne “automatske obrade podataka” iz
60-tih i 70-tih godina 20. veka. Ta tehnologija je osigurala veću produktivnost, kvalitet i pouzdanost u razvoju
aplikacija koje se svode na čuvanje i pretraživanje podataka u računaru.
Proučavanje baza podataka može se sagledavati na dva različita, međusobno povezana aspekta:
 sistemi za upravljanje bazom podataka (SUBP – DBMS, Data Base Management Systems), specifični
softverski sistem koji obezbeđuje osnovne funkcije obrade velike količine podataka: jednostavno
pretraživanje i održavanje podataka, višestruko paralelno (simultano) korišćenje istog skupa podataka,
pouzdanost i sigurnost,
 modeli podataka, odnosno specifične teorije pomoću kojih se definiše i projektuje konkretna baza podataka.
Baze podataka, zajedno sa SUBP, čine sistem baza podataka. U širem smislu, u sistem baza podataka spada i
odgovarajući hardver, svi programski alati koji se nadgrađuju na SUBP i olakšavaju rad sa bazama, kao i raznorodni
korisnici baza podataka (od krajnjih korisnika, preko aplikativnih programera do administratora baza podataka).
U razvoju sistema baza podataka može se uočiti nekoliko generacija SUBP, koje su ili koegzistirale na tržištu ili
smenjivale jedna drugu. Fundamentalna razlika između sistema ovih generacija je razlika u modelu podataka, koja
se u implementaciji odgovarajućih SUBP reflektuje na efikasnost pristupa podacima i obrade podataka, produktivnost
korisnika, funkcionalnost sistema i podršku raznovrsnim aplikacijama. Tako se u prve dve generacije svrstavaju tzv.
mrežni (CODASYL) sistemi i hijerarhijski sistemi, koji su gotovo u potpunosti prevaziđeni, osamdesetih godina
prošlog veka, relacionom tehnologijom kao trećom generacijom SUBP (Relacioni SUBP – RSUBP). Sve tri
generacije namenjene su pre svega poslovnoorijentisanim aplikacijama.
Konkretni sistem za upravljanje bazom podataka se obično zasniva na nekom teorijskom modelu podataka. Istorijski,
SUBP predstavljali su revoluciju u tehnologiji obrade podataka, a modeli podataka revoluciju u metodološkom
pristupu razvoju informacionih sistema.
1/63
2. O BAZAMA PODATAKA
Opšte poznata činjenica je da baza podataka predstavlja organizovan i međusobno povezan skup podataka. Iz ovog
razloga je moguće i pronači definiciju baze podataka koja kaže da su one organizovani skup informacija 1. Kao što
ste već upoznati, podatak predstavlja neobrađenu činjenicu koja postoji u bilo kom obliku (tekst, slika, zvuk, vido
zapis i slično), a sama za sebe nema nikakvo značenje. Na primer, neki podatak predstavlja broj 7. Sam po sebi on
ne predstavlja ništa. osim što je po svojoj prirodi prirodni celi broj, ali ako se napiše "Student broj indeksa:1/2020 iz
predmeta: Računarstvo, dobio je ocenu 7", već govorimo o informaciji, da je student sa brojem indeksa 1/2020 iz
predmeta Računarstvo dobio ocenu 7. Drugim rečima niz povezanih podataka (broj indeksa, predmet, dobio, ocena)
čini informaciju, slika 1.
Informacija
Podatak 1 Podatak 2 Podatak 3
1/2020 Računarstvo 7
Slika 1. Podaci i informacija
Baza podataka sadrži tabele u kojima se nalaze zapisi čije su vrednosti raspoređene po kolonama. U literaturi se nalazi
da baza podataka sadrži entitete i atribute. Recimo, entitet je student, a atributi, koji ga opisuju, su broj indeksa, ime,
prezime, smer studija, godina studija, .... Kada se govori o entitetima i atributima misli se pre svega na konceptualni
nivo, i oni se, kasnije, na fizičkom nivou (realizacija) transformišu u tabele (entitet) i kolone (atributi).
U zavisnosti od baze podataka, pored tabela, one mogu da sadrže: poglede (views), okidače (triggers), uskladištene
procedure (stored procedures), funkcije i tako dalje. Neke od baza podataka, poput MS Accessa, ili recimo Visual
FoxPro  a, sadrže: izveštaje (reports), obrasce (forms), module (modules), makore (macros) i/ili programe
(programs). Mogućnosti baza podataka definisane su njihovom namenom i tipom koirsnika koji će ih koristiti. Tako
recimo, MS Access, koji je predviđen za male baze podataka i samostalne (standalone) aplikacije, ima za to
određene specifičnosti.
Po nameni, baze podataka se mogu podeliti na desktop (jedan ili nekoliko korisnika), odnosno klijent-server baze
podataka.
Desktop baze podataka, tabela T1., namenjene su manje zahtevnim korisnicima. Pod time se misli na jednog ili
nekoliko korisnika koji bazu podataka (i aplikaciju koja je prati) koriste za lične potrebe ili za manje projekte. Takve
baze podataka najčešće su besplatne i zbog toga dostupne većem broju korisnika. Međutim, zbog tehničkih
ograničenja dosta su ograničene i neprikladne za profesionalne i ozbiljne projekte.
Tabela 1. Neke desktop baze podataka

Naziv Opis
Potiče iz DOS operativnog sistema (mada postoji i verzuje za Windows OS). Paradox
Paradox
se aktivno koristio u Borland razvojnim alatima Delphi i C++ Builder.
Besplatna baza podatakai jedna od najrasprostranjenijih. Radi na velikom broju uređaja
SQLite
i platformi (Android, iOS i iPhone uređaja, MAC, PC, TV, automobila ...[2])
Radi samo na Windows OS. Podržava paralelni (konkurentni) rad do maksimalno 255
Microsoft Access korisnika. Formiranje aplikacije i izveštaja u samoj bazi podataka. Microsoft Access
aplikacija se plaća.
Primarno namena za iPad, iPhone i Mac okruženja. Podržava i Windows okruženje kao
FileMaker Pro
i integraciju sa Microsoft SQL Server, Oracle i MySQL bazom podataka. [3]
Desktop baze podataka, u stvari, predstavljaju skup međusobno povezanih, ili ne povezanih, samostalnih datoteka
(tabela). Iz ovog razloga postoji niz ograničenja koja potiču, pre svega, od operativnog sistema, kao što je broj
istovremenih konekcija, pa sa time i ograničeni broj korisnika koji mogu simultano (paralelno, istovremeno) da je
koriste. Na primer, Microsoft Access baza podataka dopušta maksimalno 5 istovremenih konekcija ukoliko se nalazi
na Window 7 Home OSu, 10 na Windows 7 Professional, odnosno maksimalnih 255 istovremenih konekcija na
Windows Server OSu.
2/63
Uprkos ovakvim i sličnim ograničenjima, desktop baze podataka i dalje su jako popularne jer zadovoljavaju većinu
potreba manje zahtevnih korisnika. Međutim, u zahtevnijim okruženjima gde je najčešće reč o velikom broju
korisnika, postoje i neki dodatni faktori koje treba uzeti u obzir. Pre svega misli se na performanse, skalabilnost,
dostupnost i sigurnost podatak. Kako ove osobine nisu najzastupljenije u desktop bazama podataka, da bi se one bile
primarne koriste klijent-server baze podataka, tabela T2.
Tabela 2. Primeri klijent-server baza podataka

Naziv Opis
Microsoftova relaciona baza podataka (RDBMS) namenjena korporativnim
Microsoft SQL Server okruženjima. Podržava Transact-SQL, ekstenziju SQL-a. Baza je dostupna u velikom
broju izdanja od kojih je Express izdanje potpuno besplatno.
Vlasništvo korporacije Oracle. RDBMS namenjen najzahtevnijim korisnicima.
Oracle
Podržava PL/SQL proceduralni jezik. Dostupan u besplatnom Express izdanju [4].
Vlasništvo korporacije IBM. Uz standardni SQL jezik DB2 podržava PL/SQL:
DB2
Dostupna je besplatna verzija ExpressC 5].
Open source (besplatna) objektna relaciona baza podataka (ORDBMS). Postgre SQL
Postgre SQL
koristi PL/pgSQL jezik. U potpunosti podržava ACID svojstva [6].
U ovu grupu baza podataka spadaju i mnoge druge poput MySQL, Sybase, Informix i tako dalje. Ove baze
podataka funkcionišu kao mrežni servisi pomoću kojih se odvija klijent-server komunikacija. Obično se
jedan takav servis naziva instanca, a jedan server može odjednom imati više aktivnih instanci.
3/63
3. STANDARDNI UPITNI JEZIK – SQL
SQL (Structured Query Language) je standardni relacioni upitni jezik (ANSI i ISO standard). Njegov tvorac je
Čemberlin (Chamberlin), a nastao je u IBM-ovoj istraživačkoj laboratoriji (IBM Research Laboratory) u San
Hoseu, Kalifornija 1974. godine, dakle na istom mestu gde je Kod 1970. definisao osnovne koncepte relacionog
modela podataka. Jezik se u početku zvao SEQUEL (Structured English Query Language) i predstavljao je
programski interfejs (API) za System R, prototipski sistem za upravljanje bazom podataka (SUBP) koji se razvijao
kao deo istražvačkog projekta pod istim nazivom. Krajem sedamdesetih i početkom osamdesetih godina prošlog veka
javljaju se i prve komercijalne verzije relacionih sistema, sa SQL-om kao upitnim jezikom. Među njima su
najznačajniji Oracle i dva IBM-ova proizvoda: SQL/DS i DB2.
Pojava komercijalnih relacionih sistema uvećala je značaj i ubrzala proces standardizacije relacionog upitnog jezika.
Prva etapa tog procesa završila se 1986. godine usvajanjem SQL-a kao standardnog relacionog upitnog jezika.
Ta prva verzija SQL standarda poznata je pod nazivom SQL-86. Njom su standardizovane osnovne karakteristike
SQL-a kao deklarativnog relacionog upitnog jezika. Međutim, mnoge bitne karakteristike jezika ostale su
nestandardizovane. To je dovelo do revizije standarda koja je usvojena 1989. godine i kojom su standardizovane
karakteristike koje se odnose na očuvanje integriteta baze podataka i povezivanje sa klasičnim programskim
jezicima. Ta verzija SQL standarda poznata je pod nazivom SQL-89. 1992. godine usvojena je sledeća bitna
revizija standarda, poznata pod nazivom SQL-92 ili SQL2, kojom je SQL zaokružen kao programski jezik, a
obim standarda uvećan šest puta u odnosu na polaznu verziju. Pretposlednja revizija SQL standarda usvojena je
1999. godine. Ta verzija SQL standarda poznata je pod nazivom SQL: 1999. U nju su uključeni koncepti objektne
tehnologije, mehanizam trigera, rekurzija i proceduralna proširenja. Poslednja revizija SQL standarda usvojena 2003,
pod nazivom SQL3. U ovoj reviziji otklonjeni su neki propusti, i napravljena su određena unapređenja u odnosu
na prethodnu reviziju. Dodato je i jedno novo poglavlje SQL/XML.
SQL je u stalnom razvoju. Na početku je bio prilično jednostavan, blizak korisniku i u velikoj meri deklarativan
(neproceduralan). Danas se za SQL može reći da je kompleksan, proceduralno/deklarativan jezik. SQL radi sa
tabelama. Tabela se kreira jednom izvršnom naredbom. Odmah po kreiranju tabela je raspoložva za korišćenje. Svi
podaci memorisani su u tabelama i rezultat bilo koje operacije se logički prikazuje u obliku tabele. Neproceduralnost
SQL-a se ogledala u činjenici da se njime definisalo ŠTA se želi, a ne KAKO se dobija: koji podaci se žele, koje
tabele se referenciraju i koji uslovi treba da budu ispunjeni, bez specifikacije procedure za dobijanje željenih
podataka. Da bi se povećala funkcionalnost jezika, u SQL: 1999 standardu, uvedena je proceduralna nadgradnja
SQLa, koju uglavnom čine upravljačke strukture slične upavljačkim strukturama klasičnih programskih jezika.
SQL naredbe su svrstavane u četiri kategorije:

1. naredbe za definisanje (DDL  Data Definition Language),
2. naredbe za manipulisanje (rukovanje) podacima (DML  Data Manipulation Language)
3. naredbe kontrolne (upravljačke) funkcije (DCL  Data Control Statements).
4. naredbe transakcije (TCL  Transaction Control Language)
Naredbe za definisanje, DDL, omogućuju definisanje objekata baze. Primeri naredbi ove kategorije su:
 CREATE TABLE (kreiranje tabele baze podataka)
 CREATE VIEW (kreiranje virtuelne tabele - "pogleda")
 CREATE INDEX (kreiranje indeksa nad kombinacijom kolona tabele)
 ALTER TABLE (izmena definicije tabele)
 DROP TABLE (izbacivanje tabele iz baze podataka)
SQL 1. Primer DDL upita SSMS alatom SQL server 2018 EXPRESS
--Kreiranje tabele Studenti
CREATE TABLE [dbo].[Studenti](
[BrojIndeksa] [nvarchar](15) NOT NULL,
[Ime] [nvarchar](15) NULL,
[Prezime] [nvarchar](25) NULL,
[Smer] [int] NOT NULL,
[JMBG] [nvarchar](13) NULL,
4/63
[Opstina] [nvarchar](25) NULL,
[Mesto] [nvarchar](25) NULL
) ON [PRIMARY]
GO
--promena kolone(polja) BrojIndeksa

Alter table Studenti
alter column BrojIndeksa nvarchar(8);
--kreiranje indeksa po kolonama Opstina, Mesto

CREATE INDEX OpstinaMesto
ON Studenti(Opstina,Mesto);
Naredbe za manipulisanje (rukovanje) podacima, DML, omogućuju ažuriranje i prikaz podataka iz tabela baze
podataka:
 SELECT (prikaz sadržaja relacione baze podataka)
 UPDATE (izmena vrednosti kolona tabele)
 DELETE (izbacivanje redova tabele)
 INSERT (dodavanje redova postojećoj tabeli)
SQL 2. Primer DML upita SSMS alatom SQL server 2018 EXPRESS
-- Unos smerova Informacione tehnologije (kolona naziv) sa IDSmer = 1
-- Drumski saobracaj IDSmer = 2
-- Masinsko inzenjerstvo IDSmer = 3
insert into Smer(IDSMer, Naziv)
VALUES (1, 'Informacione tehnologije');
VALUES (2, 'Drumski saobracaj');
VALUES (3, 'Masinsko inzenjerstvo');
--Unos studenata
insert into Studenti(BrojIndeksa, Ime, Prezime, Opstina, Mesto)
VALUES ('001/2019', 'Marko', 'Markovic', 'Krusevac', 'Krusevac');
insert into Studenti(BrojIndeksa, Ime, Prezime,Opstina, Mesto)
VALUES ('021/2019', 'Jana', 'Janic', 'Obrenovac', 'Obrenovac');
insert into Studenti(BrojIndeksa, Ime, Prezime,Opstina, Mesto)
VALUES ('003/2020', 'Janko', 'Jankovic', 'Trstenik', 'Trstenik');
--Ažuriranje kolone smer sa vrednošću 1 gde ne postoje unete vrednosti (IS
NULL)
update Studenti set Smer = 1 where Smer IS NULL;
--Prikaz sadržaja navedenih kolona (BrojIndeksa,Ime,Prezime,Opstina,Mesto)
--iz tabele Studenti
select BrojIndeksa,Ime,Prezime,Opstina,Mesto From Studenti;
--Brisanje redova tabele koje ispunjavaju uslov Smer=3;
delete from Studenti where Smer=3;
Naredbe za kontrolne (upravljačke) funkcije, DCL, omogućuju oporavak, konkurentnost, sigurnost i

integritet relacione baze podataka:
 GRANT (dodela prava korišcenja sopstvene tabele drugim korisnicima)
 REVOKE (oduzimanje prava korišćenja sopstvene tabele od drugih korisnika)
 COMMIT (prenos dejstava transakcije na bazu podataka)
 ROLLBACK (poništavanje dejstava transakcije)
SQL 3. Primer DCL upita SSMS alatom SQL server 2018 EXPRESS
-- korisniku, Korisnik1, dozvoljeno pristupanje, dodavanje i izmena podataka u
tabeli Studenti
5/63
GRANT SELECT, INSERT, UPDATE
ON Studenti
TO Korisnik1
-- korisniku, Korisnik2, opozvana dozvola brisanja podataka u tabeli Studenti
REVOKE DELETE
ON Studenti
FROM Korisnik2
Upiti transakcije, TCL, se koriste za upravljanje transakcijama. Njima je moguće uspešno potvrditi kraj transakcije
(COMMIT) ili je opozvati (ROLLBACK).
SQL 4. Primer TCL upita SSMS alatom SQL server 2018 EXPRESS
DECLARE @kodGreske INT
BEGIN TRAN
UPDATE Studenti
SET Mesto = 'Bagdala' -- postavi mesto Bagdala
WHERE BrojIndeksa = '001/2019' -- ..gde je broj indeksa 001/2019
SELECT @kodGreske = @@ERROR
IF (@kodGreske <> 0) -- ukoliko se dogodila greška
GOTO PROBLEM
COMMIT TRAN -- spremi sve promjene napravljene transakcijom
PROBLEM:
IF (@kodGreske <> 0) BEGIN
PRINT 'Dogodila se nepredviđena greška!'
ROLLBACK TRAN -- poništi sve izmjene napravljene transakcijom
END
SQL:1999 standard razvrstava SQL naredbe u 7 kategorija. Osnovni razlog za drugačije razvrstavanje naredbi je
uvođenje novih koncepata u SQL u skladu sa razvojem informatičke tehnologije i potreba da se postojeće naredbe
preciznije grupišu. Definisane su sledeće kategorije SQL naredbi:
I. naredbe za šemu baze podataka (SQL-Schema Statements), koje se koriste za kreiranje, izmenu i izbacivanje
šema i objekata šema (CREATE, ALTER, DROP),
II. naredbe za podatke (SQL-Data Statements) koje se koriste za prikaz i ažuriranje podataka baze (SELECT,
INSERT, UPDATE, DELETE),
III. naredbe za transakcije (SQL-Transaction Statements) koje se koriste za startovanje, završavanje i
postavljanje parametara za transakcije (COMMIT, ROLLBACK),
IV. naredbe za kontrolu (SQL-Control Statements) koje se koriste za kontrolu izvršavanja sekvence SQL
naredbi (CALL, RETURN),
V. naredbe za konekcije (SQL-Connection Statements) koje se koriste za uspostavljanje i prekidanje SQL
konekcije (CONNECT, DISCONNECT),
VI. naredbe za sesije (SQL-Session Statements) koje se koriste za postavljanje Default vrednosti i drugih
parametara SQL sesije (SET),
VII. naredbe za dijagnostiku (SQL-Diagnostic Statements) koje koriste dijagnostičke podatke i signaliziraju
izuzetke u SQL rutinama (GET DIAGNOSTICS).
SQL:1999 i SQL:2003 standardi definišu više načina korišćenja SQL-a. Dva osnovna načina su direktno
(interaktivno) korišćenje SQL-a i povezivanje SQL-a sa klasičnim programskim jezicima ("ugrađeni" SQL).
3.1. Nedeljivost , doslednost, izolovanost, trajnost  ACID
Svaka baza podataka mora da ima sledeća svojstva:
 Nedeljivost  Atomic;
 Doslednost  Consistency;
 Izlolovanost  Isolation;
 Trajnost  Durability.
6/63
U literaturi ova svojstva se pod jednim imenom nazivaju ACID  svojstva, od početnog slova naziva osobina na
engleskom jeziku, i svojstva jamče sigurno i ona obezbeđuju pouzdano izvršavanje transakcija, prilikom čega se čak
i u slučaju grešaka, baza podataka ne dovodi u nefunkcionalno i neispravno stanje.
Svaka transakcija može se sastojati od jednog ili nekoliko delova. Svojstvo nedeljivosti (Atomicy) osigurava da će se
transakcija izvršiti u potpunosti (svi njeni delovi) ili da se neće izvršiti uopšte (ni jedan njen deo). Pri tome treba uzeti
u obzir nešeljene prekide rada servera usled nestanke struje, kvarove na hardveru i druge nepredviđene situacije koje
su takođe obuhvaćene ovim svojstvo.
Dobar primer, za ovo svojstvo, je plaćanje računa platnim karticama. Ova transakcija se sastoji od najmanje dva dela:
I deo  skidanje novca sa računa klijenta i II deo  uplata na račun trgovine gde je kupljena roba. Neprihvatljivo je
da se izvrši samo jedan deo transakcije, recimo samo I deo, a da nije izvršen i II deo transakcije.
Da bi se svojstvo nedeljivosti ostvarilo, baza podataka prati sva stanja unutar transakcije i zapisuje ih u dnevnik. U
slučaju da se jedan deo transakcije nije izvršio ili da ga je nemoguće, iz bilo kog razloga, nemoguće izvršiti, svi
prethodno uspešno izvršeni delovi transakcije se poništavaju [7]. Baza podataka se u tom slučaju vraća u izvorno
stanje pre transakcije.
Dalje, ni jedna transakcija ne sme narušiti svojstvo doslednosti (Consistency). Ovo svojstvo se brine da svaki podatak
koji se treba sačuvati u bazi podataka prethodno zadovoljava sva postojeća pravila i ograničenja. U protivnom,
transakcija se odbacuje i baza podataka se vraća u prethodno, ispravno, stanje.
Odličan primer za ovo je polje (kolona) koja ujedno predstavlja primarni ključ tabele. Po definiciji u koloni koja
predstavlja primarni ključ može biti samo jedna vrednost, od nredova tabele - svojstvo neponovljivosti primarnog
ključa. Drugim rečima svojstvo doslednosti proverava da li podatak, koji se unosi u to polje (kolonu) postoji i da li
po tipu i dužini polja odgovara tipu i dužini klone u koju se unosi.
Pravila doslednosti dodatno se mogu proširiti i referencijalnim integritetom (referential integrity), kao i pomoću
okidača (triggers).
Osobina koja omogućuje da događaji i stanja u jednoj transakciji nisu vidljivi u drugima je izolovanost (Isolation).
Ova osobina je pogotovu važna u više korisničkom okruženju. Naime, ona omogućava da se svaka transakcija
izvršava nezavisno od drugih transakcija i da bi se to uspešno ostvarilo koristi se mehanizam zaključavanja.
Na primer, ukoliko neko preduzeće, u službi finansija, ima bar dve osobe zadužene za plaćanje računa, prilikom
istovremenog plaćanja računa, prvi koji vrši plaćanje, zaključava sve transakcije drugima, sve dok se ponovo ne
pročita stanje računa, kako sa računa ne bi bilo "skinuto" više novca nego što se raspolaže.
Zaključavanje može biti optimističko i pesimističko. Optimističko je u slučaju, kada korisnik radi sa kopijom
podataka. Prilikom vraćanja, snimanja, podataka u bazu, proverava se da ti podaci već nisu promenjeni od strane
nekog drugog korisnika.
Baš ovaj način ilustruje prethodni primer sa plaćanjem računa. Provera, da li je došlo do izmene originalnih podataka,
može se izvršiti na nekoliko naćina. Proveravanjem stavke originalnog zapisa pre i u trenutku čuvanja izmena,
upoređivanjem vremenskih oznaka zapisa (timestamp) i slično.
Mnogo rigoroznije je pesimistično zaključavanje. Klijent sve vreme transakcije ima isključivo pravo nad zapisom, a
u tom periodu niko ne može da pristupi zapisu. Ovakav pristup može biti problematičan zbog moguće nepažnje
korisnika. Ukoliko korisnik otvori zapis za uređivanje i iz bilo kog razloga ga ne zatvori, dok se ne zatvori, on će sve
to vreme biti nedostupan ostalim korisnicima.
Pri radu s transakcijama, SQL Server baza podataka podržava nekoliko različitih nivoa izolacije, tabela T  3., u
zavisnosti od odabranog nivoa moguća je pojava određenih fenomena čitanja podataka iz baze. Za demonstraciju
ovih fenomena, pretpostaviće se da u bazi podataka postoji tabela Studenti sa sadržajem datim u tabeli T  4.
7/63
Tabela 3. Nivo izolacije u SQL Serveru [8]
Nivo izolacije "Prljavo" čitanje Neponavljajuće čitanje Fantomi
Nepotvrđeno čitanje DA DA DA
Potvrđeno čitanje  DA DA
Ponavljajuće čitanje   DA
Serijalizacija   
Snimak   
Tabela 4. Deo sadržaja tabele Studenti

BrojIndeksa Ime Prezime Smer
001/2019 Marko Markovic 1
021/2019 Jana Janic 1
003/2020 Janko Jankovic 1
003/2019 Zora Zoric 2
050/2019 Dana Danic 2
Takozvano "prljavo" (dirty) čitanje je fenomen koji se pojavljuje kada jedna transakcija može pročitati nepotvrđena
međustanja iz neke druge transakcije. Ukoliko je druga transakcija u konačno odbacila ta međustanja (rollback) onda
je prva transakcija preuzela neispravne podatke, tabela T  5.
Tabela 5. Prikaz "prljavog" čitanja

Transakcija 1 Transakcija 2
select Smer from Studenti
where BrojIndeksa='001/2019'
-- ispisuje 1
UPDATE Studenti SET Smer=2 WHERE
BrojIndeksa='001/2019';
-- transakcija još uvijek nije završena!
-- ispisuje 2
ROLLBACK;
"Prljavo" čitanje događa se ukoliko izolacije uopšte nema, odnosno ukoliko se koristi takozvano nepotvrđeno čitanje
(uncommitted read). U višekorisničkom okruženju ovaj fenomen čitanja krajnje je nepoželjan i treba ga obavezno
izbegnuti korišćenjem višeg nivoa izolacije.
Ukoliko se desi da se, tokom transakcije, isti podaci čitaju dva ili više puta, a rezultat pri svakom od čitanja nije isti,
reč je o "neponavljajućem čitanju" (non – repeatable reads). Ovaj fenomen čitanja donekle podseća na prethodni, ali
u ovom slučaju reč je o čitanju već potvrđenih podataka, tabela 6.
Tabela 6. Prikaz neponavljajućeg čitanja

-- ispisuje 1
UPDATE Studenti SET Smer=2 WHERE
-- transakcija još uvijek nije završena!
-- podrazumevano ispisuje 2
COMMIT
Rezultat čitanja podataka, tabela 6., u prvoj transakciji zavisi od nivoa korišćenog nivoa izolacije. SQL Server,
podrazumevano, koristi nivo izolacije "potvrđeno čitanje" (committed read) [9]. To znači da će se prilikom prvog
8/63
čitanja učitati vrednost 1, a u drugom čitanju vrednost 2. Ukoliko se koristi viši nivo izolacije poput ponavljajućeg
čitanja (repeteable read), u oba čitanja preuzeće se vrednost 1 jer će druga transakcija biti na čekanju sve dok se u
potpunosti ne završi prva transakcija.
Ako se tokom transakcije izvrše dva ili više istih upita koji za rezultat imaju različit skup podataka, reč je o pojavi
fenomena "fantoma", odnosno fantomskih zapisa (phantom reads), tabela 7.
Tabela 7. Prikaz fantomskih zapisa

select * from Studenti
where Smer=2;
UPDATE Studenti VALUES (017,Pera,Peric,2)
Smer=2 WHERE BrojIndeksa='001/2019';
COMMIT
select * from Studenti
where Smer=2;
-- podrazumevano se vide fantomski zapisi
COMMIT
Ovaj fenomen se može izbeći primenom većeg nivoa izolacije, poput serijalizacije (serializable) ili snimaka
(snapshot). Ovi nivoi, maksimalne, izolacije daju isti rezultat, ali na različite načine.
Serijalizacija kao metodu rada koristi zaključavanje korišćenih resursa. Čim jedna transakcija počne s radom,
automatski zaključa korišćenje resursa ostalim transakcijama koje su tada u stanju čekanja. Nasuprotoj ovoj metodi,
snimak ne koristi zaključavanje već formira vezije postojećih podataka, pri čemu se koristi sistemska baza podataka
tempdb. U nju se smeštaju stavke svih svih ažuriranih podataka tokom transakcija. Svaka transakcija se upisuje, tako
što joj server dodeljuje jedinstveni broj koji je dodeljen svakoj od stavki ažuriranih podataka [10].
Korištenjem snimka, istovremene transakcije se izvršavaju odmah korišćenjem onih stavki podataka (snimci) koje su
postojale na početku transakcije. Iz tog razloga, nije potrebno zaključavati druge transakcija kao u slučaju
serijalizacije. Da bi se snimak mogao koristiti, kao nivo izolacije, to je potrebno omogućiti, na način kako je prikazano
u SQL–5 .
SQL 5. Primer TCL upita SSMS alatom SQL server 2018 EXPRESS
ALTER DATABASE NazivBazePodataka
SET ALLOW_SNAPSHOT_ISOLATION ON
Pri izboru nivoa izolacije treba obratiti pažnju na moguće komplikacije pri međusobnom zaključavanju transakcija,
a jedna od takvih situacija potpuni je zastoj (deadlock), slika 2.
Resurs 1
1 4
Proces 1 Proces 2
3 2
Resurs 2
Slika 2. Potpuni zastoj
U prvoj operaciji, slika 2., Proces 1 zauzeo je Resurs 1, a u drugoj operaciji Proces 2 zauzeo je Resurs 2. Problem
nastaje u trećoj operaciji budući da Proces 1 ne može pristupiti Resursu 2 jer je on već zauzet od strane Procesa 2.
Proces 1 je tada na čekanju, dok se Proces 2 ne završi. Međutim, Proces 2 nikada neće završiti jer ne može pristupiti
9/63
Resursu 1 kojeg je zauzeo Proces 1. Rezultat je potpuni zastoj jer su oba procesa stalno u stanju čekanja.
Za ilustraciju sa slike 2, dat je primer u tabeli 8.
Tabela 8. Demonstracija potpunog zastoja

UPDATE Studenti SET Smer = 3 WHERE
-- zauzet je resurs (tabela) Studenti
UPDATE Smer SET naziv=MAŠINSTVO WHERE idsmer = 3;
-- zauzet je resurs (tabela) 'smer'
UPDATE Smer SET naziv=HIP WHERE

idsmer = 3;
-- Resurs (tabela) 'smer' je već zauzet!
COMMIT
UPDATE Studenti SET Smer = 1 WHERE
-- Resurs 'Studenti' vec je zauzet!
COMMIT
SQL Server ima tu mogućnost da prepozna (otkrije) ovakve situacije pomoću takozvanog monitora potpunog zastoja
(deadlock monitor thread) koji svakih 5 sekundi proverava je li došlo do potpunog zastoja. Kada dođe do potpunog
zastoja, intervali provere se smanjuju čak do 100ms sve dok se više ne budu detektovali potpuni zastoji. Nakon toga,
intervali se ponovno povećavaju na vreme do 5 sekundi [11].
SQL Server ima mehanizam da izabere, po principu "najbezbolnije" ("najjeftinije"), koju transakciju poništava. Na
primer, ukoliko transakcija, prvog procesa, obrađuje 3 zapisa, a transakcija drugog procesa obrađuje 15 zapisa, server
gasi prvi proces, jer je izmene njegove transakcije moguće brže poništiti.
Naravno, sam korisnik može da utiče na izbor procesa čije se transakcije poništavaju. U ovu svrhu koristi se naredba
SET DEADLOCK_PRIORITY [11], gde se za svaku sesiju mogu definisati prioriteti LOW, NORMAL ili HIGH.
Takođe, prioritete je moguće definisati kao celobrojne vriednosti od -10 do 10, a SQL Server podrazumevano
(default) koristi prioritet NORMAL. Ukoliko dve sesije imaju isti prioritet i njihove transakcije su jednako značajne
("skupe") žrtva se bira po slučajnom principu.
Poslednje svojstvo ACID – a je svojstvo trajnost (durability). Njime se osigurava trajno snimanje podataka u bazu
podataka nakon uspešno obavljenih (završetak) transakcija čak i u slučaju nepredvidivih okolnosti: nestanak struje,
nepredviđeno rušenje sistema ili nekih drugih greški.
10/63
4. INSTALACIJA I KONFIGURACIJA SQL SERVERA
Uslov za formiranje baze podataka je instaliran SQL Server. SQL Server, donedavno je bilo moguće instalirati samo
na Windows operativnim sistemima, dok je od verzije 2017 dostupan i na nekim Linux operativnim sistemima (Red
Hat, Ubuntu, SUSE)[12]. Ovaj server je dostupan je u velikom broju izdanja, pri čemu verzija "Express" [13], je
potpuno besplatna.
Instalacija SQL Servera predstavlja instalaciju jedne njegove instance. Svaka instanca može imati više baza podataka,
dok se na jednom serveru mogu instalirati više instanci. Ukoliko se na serveru instalira više instanci, tada se one se
moraju razlikovati po imenu, slika 3. U protivnom, moguće je izvršiti i instalaciju samo jedne, podrazumevane
(default) instance.
Instanca 1
DB11 DB12 DB13
Instanca 2
server DB21 DB22 DB23
Slika 3. Serever: Instance i baze podataka
Svaka instanca na serveru se izvršava, kao servis, koji dopušta mrežnu klijent  server komunikaciju sa
bazom podataka. U tom slučaju svaka instanca ima zaseban port pomoću koga klijenti mogu identifikovati
pojedinu instancu.
Kada se pokrene instalacija SQL Servera, prvi ekran koji se prikazuje je, takozvani, instalacioni centar,
slika 4. Sam instalacioni centar, slika 4., koji se sastoji 6 delova:
 Planning, dokumentacija o planiranju instalacije, slika 5.;
 Installation, nova instalacija  New SQL Server stand  alone ... ili ažuriranje starijih verzija SQL
servera, slika 4.;
 Maintenance, programi za održavanje: prelaz sa varijante za razvoj na varijantu za preduzeće (from
Developer to Enterprise)  Edition Upgrade, poravka  Repair, potrebna ažuriranja  Launch
Windows Update, slika 6.;
 Tools: alatke kojim se proverava konfiguracija sistema  System Configuration Checker, izveštaj o
instaliranim opcijama - Installed SQL Server features discovery report, ..., slika 7.;
 Resources: povezivanje sa sajtovima sa literaturom, blogovima i slično, slika 8.;
 Options: izbor varijante operativnog sistema (x86 ili x64), slika 9.
Slika 4. SQL Server instalacioni server
Da bi počeli instalaciju, potrebno je kliknuti na New SQL Server stand-alone installation or add features
to an existing installation, slika 4.
11/63
Slika 5. Instalacioni centar  Planning Slika 7. Instalacioni centar  Planning
Slika 6. Instalacioni centar  Maintenance Slika 8. Instalacioni centar  Resources
Slika 9. Instalacioni centar  Opcije Slika 10. Priprema instalacionih fajlova
Po pokretanju instalacije, pojaviće se prozor License Terms, gde treba potvrditi I accept the License terms
i kliknuti na Next. Sledeći prozor koji se pojavljuje je Product Updates. Ovde treba sve ostaviti kako jeste
i kliknuti na Next. Instalacioni program pokreće prozor Install Setup Files, u okviru koga se proveravaju
ažuriranja, preuzimaju se instalacioni fajlovi i pripremaju se za instalaciju, slika 10. Kada se završi priprema
pokreće se program za izbor instanci Features Selection, gde treba samo kliknuti na Next. U sledećem
prozoru treba definisati ime instance, na primer SBP, slika 11. i kliknuti na Next, kao i u narednom prozoru
Server Configuration. U prozoru Database Engine Configuration, takođe, kliknuti na Next, kao i u
narednom prozoru, Error Reporting, ako nema grešaka.
Ukoliko je sve u redu, instalacioni menadžer daje poruku, slika 12, da je instalacija uspešno završena i
potrebno je kliknuti na Close.
Da bi mogli da testirate server, odnosno da formirate bazu podataka, potrebno je instalirati SQL Server
Management studio (https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-
ssms?view=sql-server-ver15) i instalirati ga.
12/63
Slika 11. Konfigurisanje instace SQL servera Slika 12. Završetak instalacije
Nakon završetka instalacije SQL Server instance najčešće je potrebno proveriti mogu li klijenti pristupiti
preko mreže i na taj način komunicirati s bazama podataka. Da bi to bilo moguće potrebno je pokrenuti
SQL Server Configuration Manager aplikaciju i u njoj proveriti da li omogućen TCP/IP protokol za
željenu instancu, slika 13. Ukoliko u rubrici IPAPP/TCP Port nema podataka uneti 12345 i pritisnuti OK.
Slika 13. Svojstva TCP/IP protokola kreirane instance
U postavkama TCP/IP protokola moguće je za sve IP adrese koristiti dinamičke i statičke mrežne
priključke. Ukoliko se koriste dinamički mrežni priključci, tada SQL Server instanci može biti dodeljen
različit mrežni priključak prilikom svakog njenog pokretanja (zavisno od toga koji je mrežni priključak
trenutno dostupan). Da bi klijent znao koji je trenutni mrežni priključak dodeljen instanci mora biti
instaliran i pokrenut SQL Server Browser servis.
Ukoliko se uvek želi koristiti isti mrežni priključak tada nema potrebe za SQL Server Browser servisom,
pa se može koristi statički mrežni priključak kao što je prikazano na slici 13. Tada ujedno nema potrebe niti
za propuštanjem UDP mrežnog priključka 12345 kroz firewall, kako bi ovaj servis mogao komunicirati sa
klijentima, što dodatno doprinosi sigurnosnoj komponenti servera.
Statički mrežni priključak često je korišćen upravo zbog definisanja pravila u firewall  u. U firewall  u,
uvek je laše, definisati pravilo za jedan mrežni priključak nego koristiti dinamičke mrežne priključke gde
se prilikom svakog pokretanja SQL Server instance može dodeliti različiti mrežni priključak, za koji opet
treba definisati pravilo u firewall  u.
Ovde treba napomenuti da se prilikom instalacije podrazumevane instance SQL Servera za njenu mrežnu
komunikaciju podrazumevano koristi statički TCP mrežni priključak 1433. Iz sigurnosnih razloga poželjno
je promijeniti broj ovog mrežnog priključka jer će potencijalni napadači najčešće ciljati upravo na njega.
Pošto je uspešno konfigurisana SQL Server instanca moguće joj je pristupiti preko, prethodno instaliranog
13/63
SQL Server Management Studio (SSMS) alata (Slika 14). Pomoću njega može se jednostavno spajati na
više različitih instanci odjednom, kreirati i upravljati bazama podataka, administrirati korisnike .., a sam
alat je u potpunosti besplatan.
Slika 14. Spajanje na SQL Server instancu
Isti princip spajanja koristi se i u drugim klijent aplikacijama gde se za autentifikaciju i autorizaciju
korisnika mora znati IP adresa servera, korisničko ime i lozinka, naziv instance, kao i broj mrežnog
priključka ukoliko se ne koristi SQL Server Browser servis.
14/63
5. PROJEKTOVANJE BAZE PODATAKA
Uspešnost u projektovanju baza podataka isključivo zavisi od toga kako se razumeju projektni zahtevi, postavljeni
od strane krajnjih korisnika  naručioca baze podataka. Iz tog razloga, pre nego što se pristupi projektovanju baze
podataka, prvo se izvodi analiza procesa, za koji se projektuje baza podataka. Svrha te analize je da se identifikuju
svi entiteti, njihove međusobne veze, kao podaci koji se razmenjuju između entiteta.
5.1. Konceptualni model podataka
Formiranje konceptualnog modela podataka izvodi se, timski, sa analitičarom poslovnog procesa, ili sa korisnikom
koji naručuje bazu podataka. Ovde treba napomenuti da korisnik, pa i analitičar ne trebaju da imaju nikakvo
predznanje vezano za projektovanje baza podataka. Međutim, ovo je veoma značajna faza, jer od nje zavise dalje
faze za razvoj baze podataka, jer se na osnovu konceptualnog modela formiraju logočki i dalje fizički model podataka.
Svaki od modela podataka (konceptualni, logički i fizički) ima određene karakteristike, tabela 9. 14, a u
konceptualnom modelu koriste se entiteti i njihove međusobne veze. Entitet je osnovni element za prikupljanje
informacija. Njime se opisuju ljudi, događaji, mesta, procesi i slično, a svaki entitet opisuje se atributima. Na primer,
entitet je Student, a njegovi atributi mogu biti broj indeksa, ime, prezime, JMBG, smer koji su upisali.
Tabela 9. Karakteristike modela podataka

Model
Karakteristika
Konceptualni Logički Fizički
Naziv entiteta + +
Veze između entiteta + +
Atributi +
Primarni ključ + +
Strani ključ + +
Naziv tabele +
Naziv kolone (atributa) +
Tip podatka +
Atributi opisuju entitete i među njima može biti jeda ili više koji predstavlaju ključni atribut, odnosno predstavljaju
primarni ključ (primary key). Kao što znamo, primarni ključ jednoznačno opisuje neki entitet, odnosno jednu
ntorku, i on se ne može ponoviti u tom entitetu. Na primer, kandidati za primarni ključ, entiteta studenta, je broj
indeksa ili JMBG.
Nakon definisanja entiteta i njegovih atributa pristupa se uspostavljanju veza između entiteta. Pri tome se veze između
entiteta posmatraju u oba smera. Posmatra se odnos prvog entiteta prema drugom, a zatim drugog prema prvom. Pri
ovoj analizi, prvi, polazni, entitet se posmatra u jednini (1), slika 15.
Student piše Master rad

1 1
Profesor predaje Predmet

1 0,..,N
Student sluša Predmet

0,..,N 0,..,N
Slika 15. Primeri entiteta i veza u konceptualnom modelu podataka
Tako recimo, jedan student može da piše samo jedan master rad i obrnuto, jedan završni rad može da piše samo jedan
student, slika 15. Sa druge strane, jedan profesor može da predaje ili nijedan (0) ili više predmeta (N), odnosno jedan
15/63
predmet može da da predaje samo jedan profesor. I na kraju, slika 15., jedna student ne sluša ni jedan predmet (0) ili
da ih sluša više njih (N), dok jedan predmet sluša niko (0) ili više studenata (N).
Modeli u ovakvom obliku se lako čitlaju i razumeju. Šta više, konceptualni model podataka se smatra "univerzalnim
jezikom" koje koriste korisnici  naručioci baze podataka i projektanti naze podataka.
To će se pokazati na jednostavnom primeru datom u SQL  6.
SQL 6. Ilustracija formiranja konceptualnog modela.

Za potrebe praćenja kupovine kupaca u lancu prodavnica, potrebno je projetovati bazu podataka. Ta baza
treba da onogući praćenje koji artikli se najčešće kupuju u kojim prodavnicama i koji su tipovi artikala se
najviše prodaju. Takođe, potrebno je utvrditi u kojoj prodavnici se najčešće kupuje u nekom vremenskom
periodu.
Na osnovu zahteva, prvo se utvrđuju entiteti i njihovi atributi (dati u zagradama), a to su:
 Kupac (nazivk, adresa, pib, ... )
 Prodavnica (nazivp, adresa)
 Račun (datum, vreme, brojracuna, iznos)
 Artikal (naziva, cena)
 Stavka računa (artikal, kolicina, cena, pdv)
 Tip artikla (naziv, jedinica mere - jm)
Kada se utvrdi spisak entiteta i njegovih atributa, počeinje se sa definisanjem konceptualnog modela, tako
što se utvrđuje koji entitet sa kojim je u vezi. Na primer, kupac može imati 0 ili više računa. Dalje je
očigledno, da jedna prodavnica može imati 0 ili više računa, kao da račun sadrži 1 ili više stavki. Na sličan
način treba identifikovati i ostale veze između entiteta, slika 16.
Ispravnost konceptualnog modela se proverava, tako što se proveravaju odnosi u oba smera. Na primer, jedan
artikal može pripadati samo jednom tipu artikla, dok jedan tip artikla može imati 0 ili više artikala.
Kupac ima Račun sadrži Stavke

1 0,..N 1 0,..N
0,..N 0,..N
1 Artikal
izdat sadrži
0,..N
1
Prodavnica Tip pripada

1
Slika 16. Konceptualni model podataka za primer SQL  6.
Iz gornjeg primera se može uočiti da veze između entiteta i njihovi odnosi zavise isključivo od poslovnog procesa i
zahteva korisnika. Zbog toga se isti konceptualni model ne može direktno primeniti za potrebe drugih korisnika bez
prethodne provere i korekcije. Drugim rečima ne može se napraviti univezalni konceptualni model podataka, pa čak
ni najopštiji, jer je pretpostavka da svaki korisnik će imati neke svoje specifične zahteve.
5.2. Logički model podataka
Nakon završetka faze projektovanja konceptualnog modela podataka, pristupa se modeliranju logičkog modela
podataka. Njime se u potpunosti, pomoću atributa, opisuju svi postojeći entiteti, kao i podaci sa kojima ti entiteti
operišu. Logički model je proširenje konceptualnog, a koriste ga administratori i projektanti baza podataka pri razvoju
fizičkog modela podataka.
U ovoj fazi, osim entiteta, vide se i atributi koji ih opisuju, slika 17. Primer iz SQL 6., je relativno male složenosti,
16/63
tako da ga je moguće prikazati kao što je to urađeno na slici 17., međutim, ukoliko ima dosta entiteta, i svaki od
entiteta ima veliki broj atributa, bolji način je prikazati logički model u obliku dijagrama klasa ili kao što je to urađeno
na slici 18.
nazivK broj pdv

idKupac adresaK IdRacun datum iznos kolicina cena
nazivA
Kupac ima Račun sadrži Stavke idArtikal cena
1 0,..N 1 0,..N
0,..N 0,..N
pib 1
izdat sadrži Artikal
0,..N
1
Prodavnica Tip pripada
1
idProdavnica adresaP nazivT jm

nazivP idTip
Slika 17. Logički model podataka za primer SQL  6.
Kupac Racun Prodavnica
PK idKupac PK idRacun PK idProdavnica

nazivK FK idKupac nazivP
adresaK FK idProdavnica adresaP
pib broj
datum
Artikal
iznos
PK idArtikal
FK idTip
nazivA
cena
Stavke
FK idRacun
FK idArtikal Tip
kolicina PK idTip
pdv
nativT
cena
jm
Slika 18. Drugi način predstavljanja logičkog modela podataka za primer SQL  6.
Formiranje logičkog modela podataka je apsolutno nezavisno od bilo koje platforme ili servera baze podataka, to jest
RDBMS sistema. U okviru ovog modela atributi entiteta mogu se opisati i opštim tipovima podataka (na primer: broj,
tesktualni podatak, datum, logički tip i slično), ograničenjima i ključevima (kandidatima za primarne ključeve,
primarni ili strani ključ).
U primeru sa slike 18, sa PK (skraćenica od primary key) je označen primarni ključ, a sa FK (skraćenica od foreigm
key) strani ključ.
Sledeća faza je fizičko modeliranje baze podataka, odnosno transformacija entiteta u tabele, a atributa u polja (fields),
odnosno kolone tabela.
17/63
5.3. Fizički model podataka
Poslednja faza modeliranja podataka predstavlja kreiranje fizičkog modela podataka. Ovaj model se može
implementirati bilo u recionoj ili NoSQL bazi podataka, XML, txt datoteci i tome slično. Entiteti iz logičkog modela
podataka zamjenjuju se tabelama, a njihovi atributi kolonama (poljima  fields) koji su sada, u zavisnosti od
odabranog načina implementacije i sistema na kome se realizuje baza podataka, opisani, konkretnim, a ne generičkim
tipovima podataka.
Veze između tabela u fizičkom modelu određuju se na osnovu veza između entiteta u konceptualnom i logičkom
modelu podataka. Veze mogu biti "1:1" (jedan prema jedan), "1:N" (jedan prema više), "N:M" (više prema više), kao
i rekurzivna veza.
Veza "1:1" se realizuje pomoću dve tabele sa istim primarnim ključevima, slika 19. Najčešće se koristi pri radu sa
tabelama koje imaju veliki broj kolona, pa se ovim tipom veze, radi preglednosti, pojedine grupe kolona (iz jedne
tabele) izdvajaju u više posebnih tabela.
Slika 19. Primer veze "1:1"
Ukoliko je reč o tabelama, sa relativno manjim brojem kolona, ovu vezu bi trebalo izbegavati (ne i pod obavezno),
već se umesto njenog korišćenja, kolone tih tabela se spajaju u jednu tabelu. Recimo, za vezu sa slike 19., umesto
tabele zavrsnirad, mogu se kolone predmet, nazivteme i profesor prebaciti u tabelu student. U ovom slučaju to baš i
nije preporučljivo, zato što bi ove kolone, od evidentiranja studenta (prilikom upisa) bile prazne sve dok student ne
prijavi završni rad.
Tip veze "1:N", se realizuje korišćenjem primarnog ključa tabele roditelja (parent, master) i stranog ključa tabele
dete (child, detail), slika 20. Ovom vezom se definiše da za jedan red (zapis  record), iz tabele roditelja, može
postojati više redova u tebeli deteta. Upotrebom stranog ključa redovi iz tabele deteta referenciraju se na odgovarajuće
redove u tabeli roditelja.
Slika 20. Primer veze "1:N" Slika 21. Referencijalni integritet veze
Na slici 20., je prikazana veza "1:N", između tabela profesor i zavrsnirad. Iz ove veze se zaključuje da jedan profesor
može biti mentor na više završnih radova. Svaki red u tabeli profesor, sadrži red sa stranim ključem profesor, pomoću
koga se jednoznačno može odrediti profesor koji je mentor završnog rada.
Ovaj tip veze je potrebno sinhronizovati na način tako da za svaku vrednost stranog ključa, u tabeli dete, postoji
vrednost primarnog ključa u tabeli roditelj. Ova sinhronizacija se ostvaruje definisanjem pravila referencijalnog
integriteta, a ono se osigurava svojstvom veze "Enforce Foreign Key Constraint", slika 21., [15].
Za očuvanje referencijalnog integriteta u SQL Serveru mogu se definisati i pravila pri izmeni i brisanju već postojećih
podataka, slika 21. Njima se definiše, šta će se desiti sa redovima zapisiam i vrednostima stranih ključeva, u tabeli
dete, ukoliko se promeni ili izbriše određena vrednost primarnog ključa u tabeli roditelja. U SQL Serveru mogu se
koristiti pravila; No Action, Cascade, Set NULL i Set Default.
18/63
Pravilo definiše No Action da se neće desiti nikava izmena u tabeli deteta nakon brisanja ili promene primarnog
ključa u tabeli roditelj. Upotrebom ovog pravila treba biti vrlo oprezan, jer su moguće greške zbog pokušaja kršenja
referencijalnog integriteta.
Recimo, ako bi se pokušalo da se, iz tabele profesor, izbriše profesor sa idprofesor: 101 ili 102, tabela 10., to ne bi
uspelo, jer bi se desilo kršenje referencijalnog integriteta  jer bi u tabeli zavrsnirad postojale reference koje više ne
postoje (ne može postojati strani ključ, ako ne postoji primarni!!!). Isto bi se desilo ako bi bila pokušana izmena
vrednosti profesor u tabeli zavrsnirad. U tom slučaju u tabeli zavrsnirad bi postojale reference na nepostojeće
profesore.
Tabela 10. Sadržaj tabele profesor i zavrsnirad
profesor zavrsnirad
idprofesor (pk) ime prezime student (pk) predmet nazivteme profesor
101 Pera Perić 001/2016 001 Tema cccccc 101
102 Marko Marković 015/2016 002 Tema vvvvvv 103
103 Jana Janić 001/2015 001 Tema nnnnnn 101
104 Dragi Dragić 031/2015 005 Tema gggggg 104
105 Mila Milić 002/2015 010 Tema aaaaaa 105
Sa druge strane, ukoliko se koristi pravilo Cascade, prilikom brisanja profesora iz tabele profesor, izbrisali bi se i
svi završni radovi, iz tabele zavrsnirad, koji su bili referencirani na tog profesora(na primer, ako se izbriše profesor
sa idprofesor: 101, iz tabele zavrsnirad se brišu prvi i treći zapis, tabela 10.). Takođe, ukoliko be se promenila
vrednost idprofesor, u tabeli profesor, koja je bila 101 u 100, automatski bi se promenila i vrednost stranog ključa,
kolona profesor, u tabeli zavrsnirad u prvom i trećem redu.
Za pravilo Set Default potrebno je, prethodno, dodeliti podrazumevanu (default) vrednost koloni koji predstavlja
strani ključ tabele dete. U slučaju brisanja zapisa iz tabele roditelj, prethodno referencirane vrednosti stranog ključa
tabele dete promenile bi se u podrazumevanu vrednost. Ta podrazumevana vrednost mora postojati u primarnom
ključu tabele roditelj, inače će se desiti greška zbog pokušaja kršenja referencijalnog integriteta. Zbog ovoga je
elegantnije da se umesto pravila Set Default koristiti pravilo Set NULL, koje će vrednost stranog ključa postaviti na
NULL vrednost (isprazniće polje stranog ključa), čime se neće narušiti referencijalni integritet.
Slično važi i prilikom izmene vrednosti primarnog ključa u tabeli roditelj. Tada bi se sve referencirane vrednosti
stranog ključa, tabele, dete, u zavisnosti od primenjenog pravila: Set Default ili Set NULL, bile pizmenjene u
podrazumevanu ili NULL vrednost.
Veza "M:N" (više prema više), slika 22., znači da primarni ključ iz jedne tabele se može više puta pojaviti u zapisima
druge tabele. Isto važi i za drugu tabelu. Za realizaciju, ovakve veze potrebno je uvesti još jednu tabelu, tabela veze,
kod koje je primarni ključ složen, odnosno sastoji se iz dva ili više polja.
Slika 22. Primer veze "M:N"
Tabela veze ima primarni ključ kao kombinaciju primarnih ključeva tabela koje se spajaju, odnosno koje su u relaciji
"M:N". Zatim, kreiraju se dve veze "1:N", između prve tabele i tabele veze i druge tabele i tabele veze. U tim vezama
delovi složenog primarnog ključa, u tabeli veze, imaju ulogu stranih ključeva.
Na slici 22., prikazana je veza "M:N" između tabela predmet i profesor. Uvođenjem tabele veze, profesorpredaje,
ostvaruje se, pomenuta, veza kao kombinacija dve veze "1:N". Drugim rečima, jedan predmet može da predaje više
profesora, a jedan profesor predaje više predmeta.
Za realizaciju rekurzivne veze koristi se veza "1:N", slika 23. Kao što se, sa slike, može uočiti i primarni i strani ključ
19/63
se nalaze u jednoj tabeli. Objašnjenje ove veze je sledeće: jedan odsek može imati jedan nadređeni odsek, a
istovremeno i više podređenih odseka.
Slika 23. Primer rekurzivne veze
Tabela 11. Sadržaj tabele odsek

idodsek idnadredjeni naziv
1 NULL IT
2 1 Programiranje
3 1 Dizajn
4 2 Desktop
5 2 Web
6 3 Baze podataka
Za ilustraciju primera sa slike 23, dati su podaci tabele odsek u tabeli 11., a ova veza se može predstaviti i u obliku
dijagrama, slika 24.
IT
Programiranje Dizajn
Desktop Web Baze podataka
Slika 24. Nadređeni  podređeni odsek
Primena rekurzivne veze se koristi u mnogim situacijama. Na primer, vrlo često se koristi za opis strukture internet
foruma. Svaki forum može imati više podforuma, a ujedno može i sama biti podforum.
Na kraju, na slici 25. dat je fizički model podataka za logički model prikazan na slici 17. Tek nakon ove faze
projektovanja i izrade tabela baze podataka prelazi se na korišćenje odnosno obradu podataka.
Slika 25. Fizički model podataka za primer dat u SQL 6.
20/63
5.4. Analiza podataka SQL upitima
Dizajn baze podataka je veoma značajan prilikom analize podataka, jer direktno utiče na načina na koji se preuzimaju
podaci iz tabela baze podataka . Treba imati u vidu da će loše projektovana baza podataka prouzrokovati sporo
izvršavanje upita, recimo zbog nepotrebnog ili suvišnog spajanja jedne ili više tabela kako bi se došlo do željenog
rezultata. Za primer analize podataka poslužiće fizički model podataka prikazan na slici 25., a dat kroz primere od
SQL  7. do SQL  13. Takože u tabelama od 12. do 18. dati su uneti podaci u tabele projektovane baze podataka.
Tabela 12. Sadržaj tabele Kupac

idKupac nazivK adresaK pib
1 Kupac 1 Ulica lipa bb 923654023
2 Kupac 2 Ulica Marvelovih heroja 12 874236510
3 Kupac 3 Ulica Janka Jankovica 23 035410243
Tabela 13. Sadržaj tabele Prodavnica
idProdavnica nazivP adresaP
1 Prodavnica 1 Ulica negde tu blizu
2 Prodavnica 2 Ulica negde još bliže
3 Prodavnica 3 U komšiluku
4 Prodavnica 4 Bulevar cveca
5 Prodavnica 5 Trg Republike
Tabela 14. Sadržaj tabele Tip
idTip nazivT jm
1 Mleko i mlecni proizvodi l
2 Sirevi kg
3 Cokolade gr
4 Bombone gr
5 Hleb i peciva gr
6 Povrce kg
Tabela 15. Sadržaj tabele Artikal
idArtikal idTip nazivA cena
1 1 Mleko kesa 25.00
2 1 Mleko dugotrajno 115.00
3 1 Jogurt 1l 98.00
4 1 Jogurt casa 35.00
5 1 Jogurt 1.5l 115.00
6 2 Stari sir 356.00
7 2 Mladi sir 98.00
8 2 Kackavalj 658.00
9 3 Najlepse zelje 75g 113.00
10 3 Najlepse zelje 150g 135.00
11 3 Milka 75g 125.00
12 3 Milka 350g 435.00
13 4 Kiki 250g 107.00
14 4 Negro 99.00
15 5 Bronhi 125.00
16 5 Hleb T400 45.00
17 5 Hleb T350 35.00
18 5 Pogaca Ruza 55.00
19 5 Somun 73.00
20 5 Kifla 35.00
21 6 Krompir 60.00
22 6 Luk crni 125.00
21/63
Tabela 16. Sadržaj tabele Racun
idRacun idKupac idProdavnica broj datum iznos
2 1 1 10235 2020-05-02 0.00
3 1 1 10238 2020-02-01 0.00
4 1 2 1111 2020-03-15 0.00
5 2 3 1212321 2020-01-15 0.00
6 2 1 321322 2020-03-12 0.00
10 3 4 566565 2020-02-07 0.00
11 3 1 5657787 2020-03-15 0.00
12 2 5 7898798 2020-02-28 0.00
13 2 3 2113212 2020-03-31 0.00
14 1 2 5456457 2020-03-08 0.00
15 3 5 78789987 2020-02-20 0.00
Tabela 17. Sadržaj tabele Stavke
idRacun idArtikal kolicina pdv cena
2 1 2.00000 20.00 25.00
2 6 5.50000 20.00 356.00
2 8 5.00000 20.00 658.00
2 12 7.50000 20.00 435.00
3 6 10.00000 20.00 356.00
3 11 15.00000 20.00 125.00
3 15 8.00000 20.00 125.00
3 21 10.00000 20.00 60.00
4 4 6.00000 20.00 35.00
4 2 10.00000 20.00 115.00
5 8 7.00000 20.00 658.00
5 16 5.00000 20.00 45.00
5 17 12.00000 20.00 35.00
6 10 13.00000 20.00 135.00
6 9 7.00000 20.00 113.00
6 3 8.00000 20.00 98.00
10 21 21.00000 20.00 60.00
10 22 15.00000 20.00 125.00
12 9 5.00000 20.00 98.00
12 13 10.00000 20.00 107.00
13 14 9.00000 20.00 99.00
13 16 10.00000 20.00 45.00
14 9 10.00000 20.00 113.00
14 10 9.00000 20.00 135.00
15 5 10.00000 20.00 115.00
15 16 7.00000 20.00 45.00
15 19 10.00000 20.00 73.00
SQL 7. Prikazati koliko svaki od kupaca ima računa. Za svakog kupca, u posebnom redu prikazati id broj kupca,
njegovo ime i ukupan broj računa.
SELECT Kupac.idKupac, Kupac.nazivK, count(*) AS [Broj racuna] FROM Racun
INNER JOIN Kupac ON Racun.idKupac=Kupac.idKupac
GROUP BY Kupac.idKupac, Kupac.nazivK;
Analiza:
Svi računi se nalaze u tabeli Racun, tabela 16., što znači da se prilikom prikupljanja podataka, podaci iz
tabele Racun (FROM Racun). Međutim, u ovoj tabeli se ne nalazi podatak o nazivu kupca, već se u njoj nalazi
strani ključ (Racun.idKupac) pomoću koga se može dobiti naziv kupca. Da bi se dobio naziv kupca, potrebno
je povezati tabele Kupac (tabela 12.) i Racun (INNER JOIN Kupac ON Racun.idKupac=Kupac.idKupac),
pomoću primarnog ključa u tabeli Kupac (Kupac.idKupac) i stranog ključa u tabeli Racun (Racun.idKupac).
22/63
Funkcija COUNT je agregatna funkcija. Da se podsetimo, agregatnim funkcijama se izvršava upit nad skupom
zapisa. Konkretno, COUNT (*) (koloni rezultata je dato ime Broj racuna, count(*) AS [Broj racuna]),
vraća ukupan broj svih zapisa u tabeli. Budući da se uz tu agregatnu funkciju ispisuje id kupca (Kupac.idKupac)
i naziv kupca (Kupac.nazivK) onda je za krajnji rezultat potrebno grupisati (GROUP BY) po id kupca i nazivu
kupca kako bi agregatna funkcija COUNT za svakog od njih mogla izračunati njegov broj zapisa (računa),
odnosno broj pojavljivanja polja idKupac u tabeli Racun.Rezultat ovog upita dat je u tabeli 18.
Tabela 18. Rezultat upita SQL  7.
idKupac nazivK Broj racuna
1 Kupac 1 4
2 Kupac 2 4
4 Kupac 3 3
SQL 8. Ažurirati kolonu iznos u tabeli Racun, proizvodom cena * kolicina, uvećanom za iznos pdv (pdv je u %) iz
tabele Stavke.
Rešenje:
SUM(Racun.iznos = Stavke.kolicina*Stavke.cena*(1+Stavke.pdv/100)),
pri Racun.idRacun = Stavke.idRacun
UPDATE Racun
SET Racun.iznos = s.zbir
FROM (SELECT Stavke.idRacun AS id,
SUM(Stavke.cena*Stavke.kolicina*(1+Stavke.pdv/100)) AS zbir FROM Stavke GROUP
BY Stavke.idRacun) AS s
WHERE s.id=Racun.idRacun;
Analiza:
SQL komanda UPDATE pokreće postupak ažuriranja tabele, odnosno navedenih kolona. U ovom slučaju
ažurira se kolona iznos (SET Racun.iznos = s.zbir). Da bi se to uradilo na tačan i efikasan način, u
gornjem upitu, formiran je podupit, rezultat podupita je dat u tabeli 19., koji za svaki id broj računa zbir
proizvoda količine i cene, uvećanom za iznos pdv  a u tabeli Stavke (GROUP BY Stavke.idRacun). Taj
zbir je nazvan zbir izrazom AS zbir i dobija se agregatnom funkcijom SUM
(SUM(Stavke.cena*Stavke.kolicina*(1+Stavke.pdv/100)) AS zbir), dok je rezultat podupita
nazvan s (AS s). Na kraju upita se uspostavlja uslov pod kojim će se ažurirati kolona iznos (WHERE
s.id=Racun.idRacun ). Pokretanjem napisanog upita ažurira se kolona iznos, tabela 20.
Tabela 19. Rezultat Tabela 20. Rezultat

podupita iz SQL  8. upita iz SQL  8
id zbir
idRacun idKupac idProdavnica broj datum iznos
2 10272.600000
2 1 1 10235 2020-05-02 10272.60
3 8442.0000000
3 1 1 10238 2020-02-01 8442.00
4 1632.0000000
4 1 2 1111 2020-03-15 1632.00
5 6301.2000000
5 2 3 1212321 2020-01-15 6301.20
6 3996.0000000
6 2 1 321322 2020-03-12 3996.00
10 3762.0000000
10 4 4 566565 2020-02-07 3762.00
12 1872.0000000
11 4 1 5657787 2020-03-15 0.00
13 1609.2000000
14 2814.0000000 12 2 5 7898798 2020-02-28 1872.00
15 2634.0000000 13 2 3 2113212 2020-03-31 1609.20
14 1 2 5456457 2020-03-08 2814.00
15 4 5 78789987 2020-02-20 2634.00
SQL 9. Koliko novaca potroši svaki od kupaca pri svakoj kupovini u svim prodavnicama? Za svakog kupca potrebno
je u posebnom redu prikazati id broj kupca, naziv kupca i prosečno potrošenu količinu novca.
SELECT Kupac.idKupac, Kupac.nazivK, AVG(Racun.iznos) AS prosek FROM Racun
INNER JOIN Kupac on Kupac.idKupac = Racun.idKupac
GROUP BY Kupac.idKupac, Kupac.nazivK;
23/63
U gornjem primeru, primenjena je još jedna agregatna funkcija AVG (AVG(Racun.iznos)) za računanje
prosečne vrednosti. Rezultat ovog upita je dat u tabeli 21. U SQL Serveru moguće je koristiti i neke druge
agregatne funkcije, kao što su MIN, MAX i slično.
Tabela 21. Rezultat upita SQL  9

idKupac nazivK prosek
1 Kupac 1 5790.150000
2 Kupac 2 3444.600000
4 Kupac 3 2132.000000
SQL 10. Prikazati prve 3 najčešće posećene prodavnice. Za svaku prodavnicu potrebno je prikazati id broj
prodavnice, naziv i ukupan broj poseta, a rezultat sortirati po učestalosti poseta (od najviše ka najmanje
posećenim prodavnicama).
SELECT TOP 3 Prodavnica.idProdavnica, Prodavnica.nazivP, COUNT(*) AS
BrojPoseta FROM Racun
INNER JOIN Prodavnica on Prodavnica.idProdavnica = Racun.idProdavnica
GROUP BY Prodavnica.idProdavnica, Prodavnica.nazivP
ORDER BY BrojPoseta DESC
Da bi se dobile prva 3 zapisa koristi se izraz TOP 3, a da bi se odredilo koja tačno 3 zapisa, u
redosledu od najbrojnije do manje brojne posete, rezultat upita potrebno je sortirati komandom
ORDER BY, po broju poseta. Izrazom ORDER BY sortiraju se kolone, pa je zato potrebno imenovati
kolonu koja se dobije kao rezultat agregatne funkcije COUNT(*) izrazom AS BrojPoseta.
Takođe, dodatkom ključne reči DESC podaci se sortiraju od najveće vrednosti prema manjoj.
Rezultat ovog upita je dat u tabeli 22.
idProdavnica nazivP BrojPoseta
1 Prodavnica 1 4
3 Prodavnica 3 2
2 Prodavnica 2 2
SQL 11. Za svakog kupca potrebno je prikazati broj poseta po svakoj prodavnici. U rezultatu treba prikazati id broj
kupca , naziv kupca, naziv prodavnice i broj poseta. Rezultat sortirati po učestalosti poseta od najveće ka
najmanjoj.
SELECT Kupac.idKupac, Kupac.nazivK, Prodavnica.nazivP AS Prodavnica, count(*)
AS BrojPoseta FROM Racun
INNER JOIN Prodavnica on Prodavnica.idProdavnica = Racun.idProdavnica
INNER JOIN Kupac on Kupac.idKupac = Racun.idKupac
GROUP BY Kupac.idKupac, Kupac.nazivK, Prodavnica.nazivP
ORDER BY BrojPoseta DESC
Ovaj primer je proširenje primera SQL  11. Razlika je tek u tome što je rezultat grupisan po tri kolone
(Kupac.idKupac, Kupac.nazivK, Prodavnica.nazivP), zbog čega je potrebno napraviti dva
spajanja (INNER JOIN) kako bi se preuzeli potrebni podaci. Rezultat ovog upita je dat u tabeli 23.
idKupac nazivK Prodavnica BrojPoseta
1 Kupac 1 Prodavnica 2 2
24/63
SQL 12. Koji artikl je najčešće prodavan u 2020. godini u drugom mesecu? Potrebno je prikazati naziv artikla i broj
prodaja.
SELECT TOP 1 Artikal.nazivA AS Roba, COUNT(Artikal.idArtikal) AS Broj
FROM Racun
INNER JOIN Stavke ON Stavke.idRacun = Racun.idRacun
INNER JOIN Artikal ON Artikal.idArtikal = Stavke.idArtikal
WHERE Racun.datum BETWEEN '2020-02-01' AND '2020-02-29'
GROUP BY Artikal.nazivA
ORDER BY Broj DESC
Da se dobio traženi rezultat potrebno je izvršiti pregled svih računa (FROM Racun). Sa slike fizičkog modela
podataka, slika 25., kao i na osnovu podataka iz tabele 17., može se uočiti da svaki račun sadrži stavke, a da
svaka stavka predstavlja artikal pa je istim tim redosledom potrebno povezati (INNER JOIN) tabele Racun,
Stavke i Artikal. Konačni rezultat se filtrira se izrazom WHERE i na kraju se sortira po učestalosti kupljenog
artikla. Na kraju, izrazom, TOP 1, prikazuju se podaci samo za najčešće kupljeni artikal, tabela 24.
Roba Broj
Krompir 2
SQL 13. Potrebno je prikazati prvih 5 tipova artikala koji su se najrjeđe kupovali u 2020. godini u prvom tromesečju.
U rezultatu je za svaki od tipa artikala potrebno prikazati naziv i kupljenu količinu.
SELECT TOP 5 Tip.nazivT AS [Tip artikla], COUNT(Tip.idTip) AS Kolicina
FROM Racun
INNER JOIN Stavke ON Stavke.idRacun = Racun.idRacun
INNER JOIN Artikal ON Artikal.idArtikal = Stavke.idArtikal
INNER JOIN Tip ON Tip.idTip = Artikal.idTip
WHERE Racun.datum BETWEEN '2020-01-01' AND '2020-03-31'
GROUP BY Tip.nazivT
ORDER BY Kolicina
Slično kao i prethodnom primeru, analizom podataka iz tabele Racun potrebno je doći do podataka
u tabeli Tip (artikla). Analizom modela, slika 25, uočava se da je potrebno spajanje (INNER JOIN)
tabela Racun → Stavke → Artikal → Tip po njihovim primarnim i stranim ključevima. Rezultat
upita je prikazan u tabeli 25.
Tip artikla Kolicina
Bombone 3
Sirevi 3
Povrce 3
Mleko i mlecni proizvodi 4
Hleb i peciva 5
25/63
6. Objekti baze podataka
U ovom poglavlju, na kratko ćemo da se podsetimo osnovnih objekata baze podataka, kao što je tabela, a
ono što nije bio predmet izučavanja, u kursevima na osnovnim studijama, biće detaljnije objašnjeno.
6.1. Tabele baze podataka, ključevi i indeksi
Tabele su osnovni objekti baze podataka i služe za čuvanje i manipulaciju podataka. Pored tabela, većina
sistema, odnosno servera, baza podataka sadrže poglede (views), indeksa i slično. Neki sistemi
omogućavaju formiranje izveštaja (reports), formi  obrazaca (forms), procedura ili makro, kao što je to u
MS Access bazi podataka, Oracle SQL serveru ili u Visual Fox Pro.
Tabele i ključevi, koji odreduju odnos između tabela, svojstvene su relacionim bazama podataka.
Razumevanje ovih tabela i ključeva je od izuzetnog značaja za upoznavanje relacionih baza podataka.
Sledećom listom definisani su različiti relacioni ključevi i tabele:
- Osnovna tabela (base table).
U relacionoj bazi podataka, osnovna tabela sadrži jednu ili više kolona svojstava objekata, kao i
primarni ključ koji jednoobrazno identifikuje objekte kao entitete podataka. Osnovna tabela mora
imati primarni ključ. Osnovne tabele se često nazivaju primarnim tabelama, zbog toga što to zahteva
primarnii ključ.
- Relaciona tabela (relation table).
Tabela koja obezbeđuje vezu između ostalih tabela, a nije osnovna tabela (zato što ne sadrži svojstva
objekta ili zato što nema polje primamog ključa) naziva se relaciona tabela. Ključna polja u
relacionim tabelama moraju da budu strani ključevi, povezani sa primarnim ključcm u osnovnoj
tabeli. Tehnički, prava relaciona tabela se sastoji u potpunosti iz stranih ključeva i ne sadrži
nezavisne entitete podataka.
- Primarni ključ (primary key).
Primarni ključ sastoji se iz skupa vrednosti koje jednoobrazno preciziraju red osnovne tabele. Svakoj
vrednosti primarnog ključa, odgovara vrednost samo jednog reda tabele. Primarni ključ možete
zasnovati na samo jednom polju, ukoliko je svaka vrednost ćelije jedinstvena u svim slučajevima.
- Ključevi kandidata (candidate keys).
Svaka kolona ili grupa kolona koja ispunjava zahteve primarnog ključa je kandidat za mesto
primarnog ključa tabele. Id_broj_alata i tip_alata su ključevi kandidati za identifikaciju alata u
magacinu. Međutim, id_broj_alata je bolji izbor zbog toga što dva alata mogu biti istog tipa, ali ne
i isti id_broj_alata.
- Složeni ključevi (composite key).
Ako su vam za ispunjenje jednoobraznih zahteva primarnog ključa potrebni podaci iz više od jedne
kolone tabele, kaže se da je taj ključ složeni ključ ili lančani ključ.
- Strani ključevi (foreign keys).
Strani ključ je kolona čije vrednosti odgovaraju vrednostima koje su sadržane u primarnom ključu,
ili krajnjem levom delu složenog ključa, u nekoj drugoj relacionoj tabeli. Strani ključ sadrži jednu
kolonu ili grupu kolona (složeni strani ključ). Ako je dužina stranog ključa manja od odgovarajućeg
primarnog ključa, ključ se naziva delimični ili skraćeni strani ključ.
Tabele u SQL serverima se kreiraju izvršavanjem DDL SQL upita, SQL  1., mada svi noviji sistemi imaju
i interaktivno grafičko okruženje, kao što je to , već pomenuti, SQL Server Management Studio  SSMS,
slika 26. Kada se kreira tabela baze podataka, u interaktivnom grafičkom okruženju u okviru SSMS, jedan
od rezultata je i paralelno kreiranje DDL upita za izvršavanje SQL upita za kreiranje tabele, kao što je to
prikazano u SQL − 14.
26/63
Slika 26. Grafičko okruženje u SSMS alatu.
SQL 14. SQL upit, generisan, prilikom formiranja tabele student u grafičkom korisničkom okruženju.
CREATE TABLE [dbo].[student](

[indeks] [varchar](8) NOT NULL,
[ime] [varchar](15) NULL,
[prezime] [varchar](25) NULL,
[smer] [int] NOT NULL,
CONSTRAINT [PK_student] PRIMARY KEY CLUSTERED
(
[indeks] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
Kao što se vidi iz datog upita, prikazana je kompletna struktura tabele student, sa nazivima kolona i
pripadajućim tipovima podataka, svojstvima i ograničenjima. Takođe, se vide i definisani ključevi, u ovom
slučaju primarni ključ kao i indeksi, ukoliko su i oni generisani. Da bi se video prikazani kod, potrebno je
da se, u SSMS alatu, klikne desnim tasterom na željenu tabelu i izabere stavka "Script Table as / CREATE
To".
Pri kreiranju tabele poželjno je da jedna od kolona bude proglašena za primarni ključ. Naravno, ako tabela
nema primarni ključ, to ne znači da je napravljena greška, već samo opasnost da će se narušiti konzistentnost
baze podataka, odnosno pojava duplih redova. Dalje, izostanak primarnog ključa ukazuje na pogrešan
dizajn baze podataka, kao i na pojavu loših performansi pri pretraživanju i spajanju sa drugim tabelama.
Ukoliko u tabeli nema adekvatnog kandidata: kolone ili kombinacije kolona za primarni ključ, najlakše je
dodati celobrojnu (int) kolonu (koju projektanti najčešće nazivaju id, idbroj, sifra) sa svojstvom identiteta
(identity) , slika 27. Ova osobina omogućava automatsko dodeljivanje vrednosti u takvu kolonu, to jest
vrednost se povećava svaki put kada se dodaje novi zapis. Upravo zato je on idealan kandidat za primarni
ključ u takvim tabelama.
Slika 27. Primarni ključ sa svojstvom identiteta.
Celobrojna kolona idpredmet ima svojstvo identiteta ("Identity Specification = Yes"). Kada se prvi put
upišu podaci, u ovu tabelu, vrednost ove kolone (polja) definisana je izrazom "Identity Seed", a za svaki
sledeći zapis njegova vrednost se povećava za broj definisan izrazom "Identity Increment". Kao šte se vidi
sa slike 27., vrednost kolone prilikom prvog upisa biće 1, Identity Seed = 1, a svaka sledeća vrednost uveća
će se za 1, Identity Increment = 1.
27/63
Naravno, formiranje kolone sa svojstvom identiteta može se ostvariti i SQL upitima, tako da je u SQL 15
prikazan upit kojim se formira kolona sa nazivom idbroj tipa int, sa svojstvom identiteta koji počinje sa 1,
a svaki sledeći se uvećava takođe za jedan. Naravno, broj kojim se počinje može biti proizvoljan, kao i
inkrement koji se dodaje za zvaki sledeći upis i to je prikazano u SQL 16., broj koji se dodeljuje prilikom
prvog upisa je 2, a svaki sledeći se dobija dodavanjem broja 3.
SQL 15. SQL upit za dodavanje kolone pod nazivom idbroj sa svojstvom identitet.
ALTER TABLE NazivTabele ADD idbroj INT IDENTITY(1,1) PRIMARY KEY
SQL 16. SQL upit za dodavanje kolone pod nazivom idbroj sa svojstvom identitet koji počinje od 2, a inkrement je
3.
ALTER TABLE NazivTablice ADD ID INT IDENTITY(2, 5) PRIMARY KEY
Svaka tabela može imati samo jednu kolonu sa svojstvom identiteta, [16] . Karakteristika ove kolone je ta
da kada formiranje novog zapisa, u tabelu, ne uspe ili se poništi (rollback), dodeljena vrednost toj koloni
smatra se iskorišćenom, tako da se za sledeći zapis generiše i dodeljuje nova vrednost. Posledica ovoga je
da se dobije "preskok" u nizu dodeljenih vrednosti. Događaji koji mogu prouzrukovati ovakvo stanje je
rušenje baze podataka ili restarovanje servera, a on je već u kešu (cache) − predmemoriji, generisao novu
vrednost za tu kolonu.
U svrhu očuvanja konzistentnosti i integriteta baze podataka u tabelama, baze podataka, mogu se definisati
pravila koja moraju da ispune podaci koji se unose. Ona se implementiraju kao ograničenja (constraints)
nad izabranim kolonama tabele. I ta ograničenja predstavljaju objekte baze podataka i mogu biti:
PRIMARY KEY (primarni ključ), FOREIGN KEY (strani ključ), NOT NULL (zahteva se unos), UNIQUE
(neponovljiva vrednost), DEFAULT (uobilajena vrednost), INDEX (indeks) i CHECK (proveriti).
Neka od navedenih ograničenja podrazumevaju jedno drugu. tako recimo ograničenje podrazumeva NOT
NULL i UNIQUE. Naravno i bilo koja druga kolona, koja nema svojstvo primarnog ključa, može da ima
ograničenja tipa NOT NULL i/ili UNIQUE. Dodeljivanje svojstva UNIQUE, može se ostvariti na više
načina, a u SQL 17., su prikazana dva načina.
SQL 17. SQL upit za dodeljivane svojstva koloni rednibroj.

ALTER TABLE ispit ADD CONSTRAINT rednibroj UNIQUE(rednibroj);
ili
CREATE UNIQUE INDEX rednibroj ON studentslusa(rednibroj);
Sva ograničenja, koja su dodata ili tabeli ili pripadajućim kolonama, nalaze se u listi ključeva i indeksa,
slika 28.
Slika 28. Lista ključeva, indeksa i ograničenja.

28/63
Ne retko se zahteva da određene vrednost koje se unose u kolone budu unapred ograničene, na primer
minimalni i maksimalni broj bodova koji se može osvojiti na ispitu. Naravno može se i ograničiti broj
karaktera koji se unose u odgovarajuću kolonu. Za ova ograničenja služi ograničenje CHECK. U primeru
SQL 18., prikazan je način kako se uvodi ograničenja tipa CHECK.
SQL 18. SQL upit za uključivanje ograničenja tipa CHECK.

ALTER TABLE predmet WITH CHECK
ADD CONSTRAINT [provera brojbodova]
CHECK (([brojbodova]>=(51) AND [brojbodova]<=(100)));
ALTER TABLE predmet WITH CHECK

ADD CONSTRAINT [broj karaktera]
CHECK (len([naziv])>(0) AND len([naziv])<=(35));
Kreirana CHECK ograničenja se takođe nalaze u listi ograničenja tabele, pod stavkom CONSTRAINTS,
slika 29.
Slika 29. Ograničenja tipa CHECK iz primera SQL 18.
6.2. Privremene tabele
SQL Server može da podržava i privreme tabele. Privremene tabele mogu biti lokalne i globalne.
Privremene tabele se čuvaju u sistemskoj Tempdb bazi podataka i automatski se uništavaju nakon što više
nisu potrebne. U SQL 19., prikazan je način kreiranja privreme tabele, a na slici 30, lokacija gde je ona
sačuvana.
SQL 19. SQL upit za formiranje privremene tabele.

CREATE TABLE #TmpTabela(
idbroj INT IDENTITY(1,1) PRIMARY KEY,
tekst VARCHAR(100));
Slika 30. Lokacija kreirane privremene tabele #TmpTabela.

29/63
Iz gornjeg upita, a i sa slike 30., vidi se da privremene tabele počinju sa znakom #.
Nazivi objekata u okviru baze podataka mogu imati naziv do maksimalno 128 karaktera (znakova).
Međutim, lokalne privremene tabele, u okviru naziva, mogu imati maksimalno do 116 karaktera, dok
zadnjih 12 karaktera dodjeljuje server (000000000003), slika 30. Svrha ovih 12 znakova se ogleda u tome
da je svaka lokalna privremena tabela dostupna samo jednoj konekciji, i to onoj u kojoj je napravljena.
Kako i druge konekcije mogu formirati svoju lokalnu privremenu tabelu istog imena (#PTmpTabela),
potrebno je da ih server na neki način razlikuje. To po čemu ih server razlikuje je, baš, tih zadnjih 12
karaktera, kao identifikator konekcije.
Lokalna privremena tabela se automatski uništava iz Tempdb baze podataka po završetku konekcije.
Ukoliko je takva tabela kreirana unutar uskladištene procedure (stored procedure) automatski će biti
uništena nakon njenog izvršavanja. Naravno, ovu tabelu, je moguće uništiti i "ručno" SQL naredbom DROP
[17].
Za razliku od lokalnih privremenih tabela, naziv globalne privremene tabele počinje sa dva znaka #, "##",
SQL 20. Ovo nije jedina razlika između ove dve privremene tabele, jer dok je lokalna vidljiva samo u
konekciji za koju je kreirana, globalna je dostupna svim konekcijama. I ona, kao i lokalna, traje dok traje
konekcija u kojoj je kreirana, a može se uništiti i pozivanjem naredbe DROP, ali neće se uništiti nakon
završetka uskladištene procedure u kojoj je kreirana.
SQL 20. SQL upit za uključivanje formiranje globalne tabele.

IF NOT EXISTS(SELECT * FROM tempdb.sys.objects WHERE name = '##TmpTabela')
CREATE TABLE ##TmpTabela(
idbroj INT IDENTITY(1,1) PRIMARY KEY,
tekst NVARCHAR(100));
Tabele mogu biti kreirane kao promenljive i kao takve mogu se dalje koristiti. Tada su kao i sve druge
promenljive vidljive samo unutar bloka naredbi, funkcije ili procedure u kojoj su kreirane, SQL 21.
Karakteristika ovako kreiranih tabela je da ne mogu imati strane ključeve i za njih se ne mogu vezati
(formirati) objekti poput okidača (triggers). Takođe, ovako kreirane tabele mogu se koristiti kao parametri
uskladištenih procedura, a u tom slučaju njihov sadržaj je dostupan samo za čitanje.
6.3. Pogledi
U većini SQL servera mogu da se formiraju pogledi (view). Za razliku, od izvršenja običnog SQL upita,
ono što pogled omogućava je da se rezultat SQL upita dodeli novoj, tabeli, koja se dalje, možete koristiti u
drugim upitima, pri čemu se u klauzuli FROM, pored izvorne tabele (tabela) navodi ime pogleda. U opštem
slučaju, prilikom pristupa pogledu, izvršava se upit koji je definisan u naredbi formiranja pogleda, a rezultati
tog upita izgledaju potpuno isto, kao i svaka druga tabela u upitu koji poziva pogled.
Drugim rečima, pogled je objekat koji se ponaša kao i svaka druga tabela, s tom razlikom, što on ne sadrži
podatke. On predstavlja sačuvani upit koji mora,uvek, da se pokrene da bi se prikazali podaci. Pogledi se
koriste kada se želi da se:
 prikaže određeni skup n−torki (redova) ,
 prikažu željenje kolone neke tabele,
 prikažu povezani redovi (preko veze PK  SK) iz više tabeli.
30/63
Kreiranje pogleda se može izvršiti pisanjem SQL upita ili pomoću interaktivnog grafičkog okruženja kakav
je SSMS alat u SQL serveru.
Standardna intaksa za formiranje pogleda data je u SQL 21, 18 .
SQL 21. SQL sintaksa za formiranje pogleda.

CREATE VIEW ime_pogleda AS
SELECT kolona_1, kolona 2, ...
FROM tabela
WHERE uslov;
U upitu SQL 21., prikazano je formiranje pogleda izborom kolona (SELECT kolona_1, kolona 2,
... ) iz jedne tabele (FROM tabela WHERE uslov). Naravno, kao što je prethodno rečeno, kolone koje
se prikazuju mogu biti iz više povezanih tabela, slika 31.
Procedura kreiranja pogleda otpočinje klikom desnim tasterom miša na Views, u Object Explorer  u i
izborom New View, slika 31.a). Pojaviće se prozor za izbor, tabele/tabela, slika 31.b). Tabele se biraju tako
što se dva puta klikne na tabelu ili se izabere tabela i klikne se na dugme Add, slika 31.b) i ona se prikazuje
u delu prozora (1). Takođe, iz ovog prozora, mogu se birati i pogledi (Views), funkcije (Functions),
odnosno sinonimi (Synonyms). Kolone, iz tabela, se biraju selekcijom kolona iz tabele ili se izaberu kolone
pomoću padajuće liste, deo prozora (2). Kako se biraju tabele i kolone automatski se formira SQL upit,
deo prozora (3), slika 31.c). Izvršavanjem pogleda, odnosno, upita koji ga formira, generiše se virtuelna
tabela sa rezultatima, odnosno ntorkama, deo prozora (4), slika 31.c).
Pogled koji je kreiran pomoću SSMS alata, slika 31, moće se formirati pomoću SQL upita datog u SQL
22.
SQL 22. SQL sintaksa za formiranje pogleda sa slike 31.

CREATE VIEW [dbo].[Pogled_1]
AS
SELECT dbo.Kupac.idKupac, dbo.Kupac.nazivK, dbo.Racun.idRacun,
dbo.Racun.broj, dbo.Racun.datum, dbo.Stavke.kolicina, dbo.Stavke.cena,
dbo.Stavke.pdv, dbo.Artikal.nazivA, dbo.Tip.jm, dbo.Prodavnica.nazivP,
dbo.Prodavnica.idProdavnica
FROM dbo.Kupac INNER JOIN
dbo.Racun ON dbo.Kupac.idKupac = dbo.Racun.idKupac
INNER JOIN
dbo.Prodavnica ON dbo.Racun.idProdavnica =
dbo.Prodavnica.idProdavnica INNER JOIN
dbo.Stavke ON dbo.Racun.idRacun = dbo.Stavke.idRacun
INNER JOIN
dbo.Artikal ON dbo.Stavke.idArtikal =
dbo.Artikal.idArtikal INNER JOIN
dbo.Tip ON dbo.Artikal.idTip = dbo.Tip.idTip;
Jednom kada se formira, pogled se može koristiti u drugim SQL upitima. Recimo, ukoliko se želi da se
prikažu svi računi iz prodavnice sa šifrom prodavnice 1, (idProdavnica=1), upit bi se formirao na način
kako je prikazano u SQL 23.
SQL 23. Korišćenje pogleda u upitu.

SELECT * FROM Pogled_1
WHERE idProdavnica=1;
31/63
a) b)
c)
Slika 31. Kreiranje i izvršavanje pogleda pomoću interaktivnog grafičkog okruženja  SSMS alata.
Ovde treba napomenuti da pogledi imaju ograničenja što se tiče primene. Jedan od ograničenja se odnosi
na primenu klauzule za sortiranje, ORDER BY. Ukoliko je potrebno sortirati zapise koji se dobiju kao
rezultat izvršavanja pogleda, to treba uraditi upotrebom ORDER BY pri referenciranju pogleda iz nekog
drugog SQL upita, SQL 23., a ne upotrebom tog izraza u samoj definiciji pogleda.
Od ostalih ograničenja i nedostataka pogleda ovde se navode:
 nemogućnost kreiranja pogleda sa parametrima,
 nemogućnost upotrebe promenljivih i privremenih tabela unutar pogleda,
 pogled je samo SELECT upit i
 unutar pogleda ne mogu se stvarati nove tabele (SELECT INTO).
Iako je rezultat pogleda virtuelna tabela i pored toga ona se može ažurirati. Takvi pogledi za ažuriranje
(updatable views), u stvari ažuriraju tabele na osnovu kojih je nastao rezultat pogled, SQL 24. U ovom
upitu se ažurira naziv prodavnice "Zelenis za svakog" za vrednost kupca sa nazivom "Kupac 1"
(nazivK='Kupac 1'). Na slici 32., u prvom delu je prikazan rezultat izvršenja prvog SELECT upita, a u
drugom delu rezultat izvršenja drugog SELECT upita, nakon ažuriranja pogleda, dodeljivanjem nove
vrednosti koloni nazivP.
SQL 24. Pogled za ažuriranje.

SELECT * FROM Pogled_2
UPDATE Pogled_2 SET nazivP='Zelenis za svakog'
WHERE nazivK='Kupac 1'
SELECT * FROM Pogled_2 ORDER BY idProdavnica
32/63
Ako se pogleda slika 32., rezultat upita može da zbuni. Naime u upitu SQL 24., je napisano da se naziv
prodavnice zameni, sa novom vrednošću, samo za kupca: Kupac 1. Međutim, sa slike se vidi da je naziv
prodavnice promenjen i u redu kod kupca Kupac 2. Ovo je iz razloga što ažuriranje pogleda, u stvari, znači
ažuriranje tabele, na osnovu kojih je nastao pogled,. U pogledu Pogled_2, SQL 24., definisano je da naziv
prodavnice se uzima iz tabele Prodavnica, slika 33. i zato se ažuriranje pogleda, odnosno vrednosti kolone
nazivP, znači ažuriranje referentnog zapisa u tabeli Prodavnica, nakon čega se, ponovnim izvršavanjem
pogleda, svuda vidi nova vrednost te kolone ("Zelenis za svakog"). Rezultat pogleda se referencira na
podatke u drugim tabelama. Zato ažuriranje jedne vrednosti pogleda najčešće, kao posledicu ,ima izmenu
rezultata pogleda na više mesta, slika 32.
Slika 32. Rezultat upita SQL 24.
Slika 33. Ažurirana tabela Prodavnica, nakon pogleda ažuriranja SQL 24.
Osnovni nedostatak pogleda je taj da naredbom UPDATE može se ažurirati samo jedna referentna tabela
pogleda. Probleme pri ažuriranju mogu izazvati i agregatne funkcije (SUM, AVERAGE, MIN, MAX,
COUNT) kao i podupiti koji sadrže izvedene tabele. Nedostatak se ogleda i u upotrebi naredbe DELETE.
Naime ona se može upotrebiti samo ako se pogled bazira na jednoj tabeli.
Pored ovih nedostatak, pogledi imaju i neke sigurnosne prednosti. Pogledom je moguće sakriti informacije
(WITH ENCRYPTION) o svim shemama, referentnim tabelama i drugim pogledima, tako da korisnik može
da vidi samo podatke dobijene pokretanjem pogleda, SQL 25.

CREATE VIEW [dbo].[Pogled_4]
WITH ENCRYPTION
AS
SELECT dbo.Kupac.nazivK, dbo.Racun.broj, dbo.Racun.datum, dbo.Racun.iznos,
dbo.Prodavnica.nazivP, dbo.Prodavnica.idProdavnica
FROM dbo.Kupac INNER JOIN dbo.Racun ON dbo.Kupac.idKupac = dbo.Racun.idKupac
INNER JOIN dbo.Prodavnica ON dbo.Racun.idProdavnica = dbo.Prodavnica.idProdavnica
INNER JOIN dbo.Stavke ON dbo.Racun.idRacun = dbo.Stavke.idRacun
INNER JOIN dbo.Artikal ON dbo.Stavke.idArtikal = dbo.Artikal.idArtikal
33/63
INNER JOIN dbo.Tip ON dbo.Artikal.idTip = dbo.Tip.idTip;
Za razliku od osnovnog pogleda SQL 22., u poslednjem upitu, ovom pogledu više nije moguće preuzeti
definiciju tabele, slika 34. Međutim, on je i dalje funkcionalan i može koristiti u drugim SQL upitima i
pogledima. Za šifrirani pogled, SSMS alat neće dopustiti generisanje skripte za ažuriranje, jer ne može da
preuzme njegovu trenutnu definiciju, ali je zato moguće takvu skriptu "ručno" napisati u slučaju potrebe
izmene definicije pogleda.
Slika 34. Poruka koja se generiše prilikom pokušaja generisanja skripte za formiranje pogleda iz SQL 25.
6.4. Grupišući i negrupišući indeksi
Veće količine podataka u tabelama i pogledima usporavaju izvršavanje SQL upita zbog sporije pretrage i
prikupljanja tih podataka. Na primer, pretraga nekog podatka u skupu od par stotina hiljada ili miliona
zapisa, u najgorem slučaju, može značiti sekvencijalni pregled svih zapisa sve dok se ne pronađe traženi
podatak. Takav način pretrage naziva se skeniranje (table scan) i predstavlja ne optimalni (često se kaže i
"najskuplji") način pretrage u smislu potrošnje vremena obrade  procesorskog vremena. Da bi se ovo
izbeglo koriste se indeksi: grupišući (clustered) i negrupišući (non-clustered) indeksi.
Grupišući indeks se može najlakše objasniti kao adresar u kojem su svi podaci poređani po prezimenu
kontakta. Ukoliko se traže podaci nekog određenog kontakta, na osnovu prezimena, do rezultata se veoma
brzo dolazi binarnim pretraživanjem. Ali ako bi se pretraživalo po imenu osobe, pretraga bi morala biti
sekvencijalna.
Grupišućim indeksom definiše se fizički razmeštaj podataka u tabeli i u tabeli može postojati samo jedan u
određenom trenutku. Na primer ne mogu se istovremeno imati grupišući indeksi i po prezimenu i po imenu,
jer bi u tom slučaju trebale dve tabele adresara. Ako je potrebno imati više od jednog grupišućeg indeksa,
prvo se obriše postojeći, pa se formira novi. Važno je znati da nije moguće napraviti grupišući indeks u
tabeli sa primarnim ključem, jer je on po default upravo grupišuči indeks.
U SQL 26., dat je upit za kreiranje grupišućeg indeksa tabele Radnici, po koloni IznosPlate, pri čemu tabela
Radnici nema primarni ključ!.
SQL 26. Formraje grupišućih indeksa.

CREATE CLUSTERED INDEX IND_PLATA
On Radnici(IznosPlate ASC)
Nakon kreiranja indeksa IND_PLATA svi zapisi u tabeli Radnici fizički su sortirani, u rastućem poretku -
ASC, po vrednosti kolone IznosPlate. Na slici 35., može se uočiti razlika u rasporedu redova pre (a) i posle
(b) formiranja indeksa.
SQL Server će za svaki indeks stvoriti i statistički objekat, slika 36. Njega koristi Query Optimizer pri
kreiranju i izboru planova izvršenja, jer se u statističkom objektu nalaze informacije o distribuciji podataka
unutar tabele. Na osnovi tih informacija može se proceniti kardinalnost, odnosno očekivani broj vraćenih
zapisa nakon izvršenja upita, što Query Optimizer može iskoristiti pri odlučivanju o optimalnom načinu
pretrage tih podataka 19.
34/63
a) b)
Slika 35. Sadržaj tabele Radnici pre a) i posle kreiranja grupišućeg indeksa b).
Slika 36. Indeks i statistika indeksa
Plan izvršenja upita SELECT * FROM Radnici WHERE IznosPlate>=50000 AND

IznosPlate<=80000;, slika 37., može se smatrati optimalnim jer je utrošeno minimalno vreme
procesora, potrebnim za njegovo izvršenje. Umesto čitanja svih 1500 zapisa (metodom slučajnog
generisanja simulirani su podaci u tabeli Radnici) (skeniranja tabele) pročitani su samo oni zapisi koji treba
da se dobiju kao rezultat upita.
Slika 37. Plan izvršenja - pretraživanje po grupišućem indeksu
Negrupišući indeks se kreira na sličan način kao i grupišući indeks, SQL 27. Za razliku od grupišućeg
indeksa, podaci u tabeli Radnici, ovog puta nisu fizički sortirani po indeksu (indeksiranoj koloni) već se
stvara nova struktura podataka za svaki negrupišući indeks koja u sebi sadrže pokazivače na podatke,
umesto na stvarne podatke (Bstabla).
35/63
CREATE INDEX PrezimeIme
On Radnici(prezime, ime);
Za razliku od grupišućih indeksa, negrupišućih indeksa u jednoj tabeli može biti više od jednog, slika 38.
Slika 38. Prikaz grupišućih i negrupišućih indeksa
Česte promene nad podacima (ažuriranje: dodavanje, izmene i brisanje) mogu prouzrokovati fragmentaciju
indeksa. Indeksne strane najčešće su razbacane po disku ili nisu dobro popunjene (koristi se više strana
nego što je potrebno), što loše utiče na performanse baze podataka. SQL Server tada nudi mogućnost
reorganizacije ili obnove indeksa, SQL 28.
SQL 28. Reorganizacija i obnova indeksa.

ALTER INDEX PrezimeIme ON Radnici REORGANIZE;
ALTER INDEX PrezimeIme ON Radnici REBUILD;
Reorganizacija (REORGANIZE) indeksa podrazumeva reorganizaciju indeksnih stranica, a preporučuje se

kada fragmentacija indeksa iznosi do maksimalnih 30%. U protivnom, preporuka je napraviti obnovu
indeksa (REBUILD  njegovo brisanje i ponovno kreiranje). U zavisnosti od veličine podataka, koji se
čuvaju u tabelama, ove akcije mogu da traju dosta dugo. Zato je preporučljivo da se one izvode u prigodno
vreme i to onda kada najmanje korisnika šalje zahteve za podacima iz baze podataka (recimo noću, za
vreme praznika ili vikendom).
6.5. Uskladištene procedure i funkcije
U okviru SQL Server  a, postoji mogućnost pisanja sopstvenih uskladištenih procedura, skalarnih funkcija
i funkcija sa tabličnim vrednostima (table-valued functions). Za pisanje sopstvenih agregatnih funkcija
potrebno je koristiti CLR (Microsoft .NET Framework Common Language Runtime). Uskladištene
procedure omogućuju čuvanje T-SQL upita u bazi podataka. Umesto da se, kroz mrežu, šalju složeni upiti,
dovoljno je pozvati uskladištenu proceduru koja sadrži taj upit.
Uskladištene procedure izvršavaju se na serveru, što značajno doprinosi performansama. Između ostalog,
nude i drugr nivoe sigurnost. Korisnik ne mora imati dozvolu za rad sa objektima (tabelama, pogledima i
slično) niti dozvolu za izvršavanje upita koji se nalaze u uskladištenoj proceduri, ali može imati dozvolu za
izvršavanje uskladištene procedure koja sve te objekte i upite sadrži.
Drugim rečima, za uskladištene procedure se može reći da predstavljaju imenovane blokove naredbi sa
nizom ulaznih i izlaznih parametara, ako ima potrebe za njima. Imenovani skup procedura, kursora i
promenljivih nazivaju se paket (PACKAGE). Procedure i funkcije se izvršavaju eksplicitnim pozivanjem.
Zapamćene procedure se mogu pozvati iz neke aplikacije (napisane u nekom programskom jeziku: C,
Visual Basic, i slično) ili ih mogu pozivati pravila ili okidači koji obezbeđuju integritet podataka.
Uskladištene procedure mogu da sadrže sve upite iz DDL i DDM skupa upita, koji se komplajliraju i čuvaju
u trenutku kreiranja procedure.
36/63
Sintaksa za kreiranje uskladištene procedure data je u SQL 29.
SQL 29. Sintaksa za kreiranje uskladištene procedure.20

CREATE PROCEDURE nazivProcedure (lista parametara)
AS
BEGIN
......
...... /*prostor za pisanje naredbi*/
......
END
U upitu SQL 29., vidi se početak formiranja procedure počinje komandom CREATE PROCEDURE, u čijem
nastavku se daje naziv procedure, a zatim, ukoliko se šalju parametri u tu proceduru, navode se parametri
sa imenom promenljive, kojoj prethodi znak '@'. Naredbe se pišu u bloku koji počinje sa ključnom rečju
BEGIN, a zavšava se sa END. Između ove dve ključne reči se upisuju komande koje dozvoljava SQL
sintaksa: SQL naredbe iz DDL i DDM skupa naredbi, razgranate strukture (IF - ELSE - ENDIF), mogu
da se definišu promenljive (DECLARE promenljiva1 CHAR(10);), postavljanje vrednosti definisanoj
promenljivoj (SET promenljiva1 = 'vrednost';) i slično. Formirana procedura se poziva naredbom:
EXECUTE nazivProcedure; ili EXEC nazivProcedure;
U narednom upitu, SQL 30., prikazuje se kod jednostavne procedure, koja sadrži naredbu za prikazivanje
sadržaja tabele Prodavnica. Kao što se vidi, ovaj upit nema parametre.
SQL 30. Uskladištena procedura SveProdavnice.

CREATE PROCEDURE SveProdavnice
AS
BEGIN
SELECT * FROM Prodavnica;
END;
Pozivanjem ove procedure naredbom EXEC SveProdavnice;, izvršava se upit SELECT * FROM
Prodavnica;, i prikazuje se sadržaj tabele Prodavnica, slika 39. Kada se upamti procedura, smešta se u
deo Programmability  Stored Procedures, slika 40.
Slika 39. Rezultat izvršenja procedure date u SQL 30.
Slika 40. Lokacija gde se čuva napravljena procedura.
37/63
Svaka procedura može imati svoje parametre. Parametri procedure se navode nakon naziva procedure na
sledeći način: (@naziv_parametra TIP_PODATAKA). Ukoliko ima više parametara oni su razdvojeni
zarezom. Prilikom definisanja parametara mogu im se zadati podrazumevane vrednosti.
Jedna od korisnijih osobina uskladištenih procedura jeste da mogu da menjaju sadržaj tabela baze podataka.
U upitu, SQL 31., procedura UvecajCene povećava cenu artikla koji pripadaju tipu određenom tipu artikla
i za željeni tip artikla. Tip artikla, u proceduru, se prenosi pomoću promenljive @Tip, a period se definiše
promenljivama @OdMeseca i @DoMeseca, dok se procentualno uvećanje definiše promenljivom
@Procenat.
SQL 31. Uskladištena procedura UvecajCene.

CREATE PROCEDURE UvecajCene (@OdMeseca int = 1, @DoMeseca int, @Procenat float,
@Tip varchar)
AS
BEGIN
UPDATE Stavke
SET Cena = Cena*(1+@Procenat/100)
WHERE (MONTH(datum)>=@OdMeseca AND MONTH(datum)<=@DoMeseca);
UPDATE Racun
SET Racun.Iznos = s.zbir
FROM (SELECT Stavke.idRacun AS id,
SUM(Stavke.cena*Stavke.kolicina*(1+Stavke.pdv/100)) AS zbir
FROM Stavke GROUP BY Stavke.idRacun) AS s
WHERE s.id=Racun.idRacun;
END
SQL 32. Pozivanje uskladištene procedure UvecajCene.
EXEC UvecajCene 2, 3, 15, "Mleko i mlecni proizvodi" --prvi nacin
EXEC UvecajCene @DoMeseca=3, @OdMeseca=1, @Procenat=-15.00, @Tip="Mleko i
mlecni proizvodi" --drugi nacin
EXEC UvecajCene @DoMeseca=3, @Procenat=10.00, @Tip="Mleko i mlecni proizvodi"
--treci nacin
Kada redosled vrednosti (koje se prenose u proceduru) odgovara redosledu parametara u proceduri, najbolje
je koristiti prvi oblik prenosa vrednosti, SQL 31. U protivnom, za svaku vrednost, koja se prenosi, treba
napomenuti kojem parametru pripada, drugi način, SQL 32. Ukoliko vrednost nekog parametra nije
navedena, u proceduri se koristi njegova podrazumevana vrednost ili se javlja greška ukoliko
podrazumevana vrednost ne postoji, treći način, SQL 32.
Uskladištene procedure, u SQL serveru, mogu vratiti grupu podataka, SQL 30, celobrojnu vrednost
korišćenjem naredbe RETURN ili vrednosti drugih tipova primenom izlaznih (output) tipova parametara.
U SQL 33., izračunava se ukupan iznos računa i naplaćeni pdv. Procedura vraća ukupan iznos, promenljiva
@UkIznos, iznos pdv  a, promenljiva @UkPdv.
SQL 33. Uskladištena procedure Ukupno.

CREATE PROCEDURE Ukupno1 (@UkIznos float output, @UkPdv float output)
AS
BEGIN
DECLARE @UkI float = (SELECT SUM(Kolicina*Cena) FROM Stavke)
DECLARE @UkPd float = (SELECT SUM(Kolicina*Cena*pdv/100) FROM Stavke)
IF @UkI > 0
BEGIN
SET @UkIznos=@UkI
SET @UkPdv=@UkPd
RETURN 0 -- uspešno izvršena procedura
END
ELSE
RETURN -1 -- u tabeli STAVKE nema podataka
END
38/63
Da bi se procedura, napisana kao u gornjem upitu, uspešno pokrenula, potrebno je napisati poseban SQL
upit, kao što je dato u SQL 34.
SQL 34. Uskladištena procedure Ukupno.

DECLARE @uk float; -- definisanje promenljive koja prihvata izlazni parametar
UkIznos
DECLARE @upd float; -- definisanje promenljive koja prihvata izlazni
parametar UkPdv
EXEC Ukupno @uk out, @upd out; -- Izvršenje uskladištene procedure Ukupno
SELECT @uk As UkupniIznos, @upd AS UkupniPDV; -- Prikazivanje rezultata
Kada se pokrene upit, SQL 34., dobija se rezultat kako je prikazano na slici 41.
Slika 41. Rezultat izvršenja upita SQL 34.
U prethodnim primerima, pokazalo se da uskladištene preocedure vraćaju tabele/liste (vektore). Za razliku

od od njih, skalarne funkcije vraćaju samo jednu vrednost  skalar. Ove funkcije su uvek određene
(determinističke). Drugim rečima, za iste vrednosti ulaznih parametara uvek vraćaju istu vrednost. Zbog
ove činjenice, ove funkcije ne mogu izvršavati nedeteminističke funkcija kao što su RAND, GETDATE i
slično.
Sklarna funkcija treba da ima vrednost koju vraća naredbom RETURN, SQL 35., pri čemu, kada se ova
funkcija poziva moraju se navesti obe komponente imena, SQL 36., to jest naziv vlasnika ili sheme, kao i
naziv same funkcije. I u ovom slučaju parametri, koji se prenose u funkciju, se navode iza naziva funkcije
između zagrada.
SQL 35. Skalarna funkcija IzracunatiPorez.

CREATE FUNCTION IzracunatiPorez(@cena float, @pdv float = 20)
RETURNS FLOAT
AS
BEGIN
DECLARE @porez float = @cena*@pdv/100
RETURN @porez
END
SQL 36. Pozivanje skalarne funkcije IzracunatiPorez.

SELECT dbo.IzracunatiPorez(1234.25, DEFAULT)
Parametri funkcija sa podrazumevanim vrednostima nisu neobavezni. Ukoliko se pri pozivu funkcije ne
navede konkretna vrednost takvog parametra već se želi koristiti njegova podrazumevana vrednost potrebno
je koristiti ključnu reč DEFAULT, SQL 36. (izračunata vrednost funkcije je 246.85).
Za razliku od skalarnih funkcija, koje isključivo vraćaju jednu vrednost, mogu se kreirati i funkcije koje
vraćaju skupove podataka, odnosno tabelarne vrednosti:
 Inline Table  Valued Functions
 Multistatement Table Valued Functions
Tip Inline Table  Valued Functions predstavlja jednostavni oblik funkcije koja vraća tabličnu vrednost.
Ona sadrži samo jednu SELECT naredbu kojom se definiše vrednost funkcije (tabelarna vrednost) koja
39/63
se vraća i ona uvek predstavlja virtuelnu tabelu, koja postoji samo kao rezultat pokrenute funkcije. Na
osnovu poslednjeg iznešenog, vidi se da ovaj tip funkcije veoma podseća na pogled. Za razliku od pogleda,
ovde je moguće uvoditi ulazne parametre, kao i kod svake druge funkcije, tako da se ovaj tip, ne retko,
koristi kao zamena za pogled.
Funkcija, data u SQL 37., kao rezultat vraća virtualnu tabelu sa spiskom naziva prodavnica, brojem,
datumom i iznosom računa za određeni period, definisan datumskim promenljivima @od DATE, @do
DATE.
SQL 37. Funkcija PregledRacuna koja vraća virtuelnu tabelu.

CREATE FUNCTION PregledRacuna (@Od DATE, @Do DATE)
RETURNS TABLE AS
RETURN -- vrednost koja se vraca je novi set podataka
(
SELECT Prodavnica.idProdavnica AS IDp, Prodavnica.nazivP AS nazivP,
Racun.broj AS BrojR, Racun.datum AS DatumR, Racun.iznos AS iznosR
FROM Prodavnica INNER JOIN Racun ON
Prodavnica.idProdavnica=Racun.idProdavnica
WHERE Racun.datum between @Od and @Do
)
Da bi se lakše pozivala ova funkcija, u upitu su kolone, koje se pozivaju iz tabele Prodavnica i Racun,
imenovane pozivom ključne rečce AS (IDp, nazivP, BrojR, DatumR, iznosR). Ova funkcija se poziva
sledećim upitom:
SELECT IDp, nazivP, BrojR, DatumR, iznosR

FROM PregledRacuna('2020-01-01', '2020-02-28'),
a rezultat je na slici 42.
Ukoliko je potrebno da funkcija, koja vraća tablične vrednosti, sadrži više naredbi, odnosno ima
kompleksnost skalarnih funkcija, nože se koristiti njen složeni oblik (multistatement table  valued
function).
Kod složenog oblika funkcije, tipa multistatement table  valued function, neophodno je, eksplicitno,
definisati strukturu rezultatnte tabele, SQL 38. U ovakvoj funkciji blok naredbi morad da bude ograničen
ključnim rečima BEGIN i END. Ovo je iz tog razloga jer ovaj blok može da sadrži više od jedne naredbe.
Unutar funkcije rezultat naredbi se popunjava u virtuelnu tabelu, a vraća se naredbom RETURN.
SQL 38. Složeni oblik funkcije koja vraća tabelu kao rezultat.
CREATE FUNCTION NadProsecniRacuni()
RETURNS @TabelaRez TABLE
(--struktura tabele koja je rezultat funkcije
Naziv_prodavnice VARCHAR(30),
Broj_racuna VARCHAR(9),
40/63
Iznos_racuna FLOAT,
Datum_racuna DATE
)
AS
BEGIN
--Racuna se prosecni iznos racuna
DECLARE @prosek FLOAT
SET @prosek = (SELECT AVG(Iznos) FROM Racun)
INSERT INTO @TabelaRez SELECT Prodavnica.nazivP, Racun.broj,
Racun.iznos, Racun.datum
FROM Prodavnica INNER JOIN Racun ON
Prodavnica.idProdavnica=Racun.idProdavnica
WHERE Racun.iznos>@prosek
RETURN --vraca tabelu - rezultat
END
U SQL 38., se prikazuju sve prodavnice kod kojih je ukupan iznos izdatih računa veći od prosečnog iznosa.
Da bi se ovaj upit izvršio, potrebno je prvo izračunati prosek računa (@prosek), a zatim se formira upit
kojim se ažurira rezultujuća tabela (@TabelaRez). Ova funkcija se poziva upitom: SELECT * FROM
NadProsecniRacuni(), a rezultat je prikazan na slici 43.
Na ovom mestu pomenuće se mogućnost zabrane modifikovanja referentnih objekata koja bi uticala na
izvršavanje bilo funkcije, bilo pogleda. To se postiže korišćenjem sintakse "WITH SCHEMABINDING"
[21].
Ako se posmatra upit SQL 39., sledeće naredbe neće bit moguće izvršiti:
 DROP TABLE Prodavnica
Server vraća poruku kojom nas upozorava da je tabela Prodavnica referentni objekat u funkciji
ListaProdavnica:
"Cannot DROP TABLE 'dbo.Prodavnica' because it is being referenced by object
'ListaProdavnica'"
 ALTER TABLE Prodavnica
ALTER COLUMN nazivP nvarchar(150)
Server vraća poruku kojom nas upozorava da je kolona nazivP, u tabeli Prodavnica, referentni
objekat u funkciji ListaProdavnica:
"The object ' ListaProdavnica' is dependent on column nazivP."
SQL 39. Korišćenje izjave "WITH SCHEMABINDING" u funkciji.

CREATE FUNCTION ListaProdavnica(@odId int, @doId int)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
(
SELECT idbrojP, nazivP, adresaP FROM Prodavnica
WHERE idbrojP BETWEEN @odID AND @doID
)
41/63
Upotreba, pomenute sintakse, nameće dva dodatna pravila:
 Unutar funkcije ili pogleda zabranjena je upotreba izraza SELECT *.
 Svi referentni objekti moraju da pored naziva sadržavaju i naziv sheme (baze podataka) pre svog
imena.
Funkcije definisane u SQL Serveru ograničene su tako da ne mogu menjati sadržaj baze podataka. Unutar
njih nije dozvoljena upotreba naredbi INSERT, UPDATE i DELETE osim kada se sa njima ne deluje na
tablične promenljive. Pored toga, nije moguće pozivati uskladištene procedure, koristiti i vraćati kursore i
BLOB objekte (binary large object), obrađivati greške (TRY-CATCH, RAISERROR) i tome slično. Ova
ograničenja se prevazilaze na taj način da se umesto funkcija koriste uskladištene procedure.
6.6. DML i DDL okidači
Okidači (trigger) predstavljaju posebnu vrstu uskladištene procedure koja se izvršava automatski umesto
(instead of) ili posle (after) nekog događaja. Zavisno od tipa događaja u SQL Serveru moguće je kreirati
DML, DDL, CLR i Logon okidače. Najčešće se koriste DML i DDL okidači pomoću kojih je moguće uvesti
dodatna pravila konzistentnosti, sačuvati integritet kao i kontrolisati strukturu baza podataka.
DML okidači koriste se kada je potrebno kontrolisati operacije dodavanja (INSERT), ažuriranja
(UPDATE) i brisanja (DELETE) podataka nad izabranim tabelama. Tako recimo da ako se želi da se u
tabeli Artikal postavljaju sledeća pravila pri radu sa podacima:
1. Naziv artikla mora započeti velikim slovom, a ostala slova moraju biti mala.
2. Ukoliko se cena artikla ili je vrednost  0, dodeljuje se vrednost 1.
3. Nije moguće izbrisati artikal ako se on nalazi u tabeli Stavke.
Gornja pravila se primenuju kreiranjem odgovarajućih okidača, pri čemu se koristi sledeća sintaksa:
CREATE [ ili ALTER ] TRIGGER [naziv_sheme.]ime_okidaca
ON { TABLE | VIEW }
{ AFTER | INSTEAD OF }
{ [INSERT] [,] [UPDATE] [,] [DELETE] }
AS { telo_okidaca }
DML okidači se kreiraju na tabele i poglede. Uprkos velikoj fleksibilnosti okidači imaju i nekoliko
ograničenja. Unutar tela okidača nije moguće kreiranje (CREATE), izmene (ALTER) i brisanje (DROP)
baze podataka, a ista ograničenja važe i za indekse tabele i samu tabelu nad kojom se okidač izvršava [22].
Treba imati na umu, da je prilikom kreiranja okidača dopušteno kreiranje većeg broja AFTER, ali samo
jednog INSTEAD OF okidača.
U SQL 40., primenjena su prva dva navedena pravila. Prilikom dodavanja novog artikla, naziv artikla se
prepravlja tako da počinje velikim početnim slovom, dok su ostala slova mala, a ako nije naveden tip artikla
dodeljuje mu se vrednost 7.
SQL 40. Okidač nakon (AFTER) operacija INSERT i UPDATE.

CREATE TRIGGER Okidac_Naziv ON Artikal
AFTER INSERT, UPDATE
AS
BEGIN
-- Preuzima se idArtikal
DECLARE @idA int = (SELECT idArtikal from Inserted)
-- Preuzima se naziv artikla
DECLARE @nA NVARCHAR(50) = (SELECT nazivA from Inserted)
42/63
-- Preuzima se tip Artikla
DECLARE @cena float = (SELECT cena from Inserted)
IF (@cena IS NULL OR @cena=0)
SET @cena = 1
UPDATE Artikal SET
-- Prvi slovo naziva se transformiše u veliko slovo, a ostala u mala
slova
nazivA = UPPER(LEFT(@nA, 1)) + LOWER(SUBSTRING(@nA, 2, LEN(@nA))),
-- Azurira se tip artikla
cena = @cena
WHERE idArtikal = @idA
END
Napisani okidač se može testirati upitima datim u SQL 41. i 42. , a rezultat rada trigera je dat u tabeli 26.
SQL 41. Upit za proveru okidača Okidac_Naziv unos nove n-torke (reda)
INSERT INTO Artikal (nazivA, idTip) VALUES ('piRiNac', 6)
SQL 42. Upit za proveru okidača Okidac_Naziv ažuriranje naziva artikla (reda)
UPDATE Artikal
set nazivA='joGurt CASA'
WHERE idArtikal = 4;
Tabela 26. Rezultati trigera posle upita SQL  41 do
idArtikal nazivA Cena idTip Rezultat trigera posle upita
29 Pirinac 1.00 6 SQL 41
SQL 42
4 Jogurt Casa 37.63 1 pre upita
4 Jogurt casa 37.63 1 posle upita
Okidač se izvršava jednom po operaciji, a ne jednom po svakj obuhvaćenoj n-torki (zapisu - record). Zbog
toga treba biti veoma oprezan pri operacijama u kojima se vrši ažuriranje više n-torki odjednom. Na primer,
upit SQL 43., prouzrukuje grešku unutar okidača datog u SQL 40.
SQL 43. Ažuriranje naziva artikla u svim n-torkama (redovima)

UPDATE Artikal
SET nazivA = 'pIriNaC'
-- Nema WHERE – menja se naziv artikla u svim zapisima!
Postojeći okidač, SQL 40., ne može da primeni poslovna pravila 1 i 2 nad više obuhvaćenih zapisa
odjednom, već tek nad INSERT i UPDATE operacijama u kojima se pristupa jednom po jednom zapisu. U
takvim slučajevima treba kreirati okidače kao što je dato u SQL 44.
SQL 44. Okidač nad više n-torki (zapisa)

CREATE TRIGGER Okidac_Naziv_2 ON Artikal
AFTER INSERT, UPDATE
AS
BEGIN
DECLARE @cena float
UPDATE Artikal SET
IF (i.cena IS NULL OR i.Cena=0)
SET i.cena = 1
nazivA = UPPER(LEFT(i.nazivA, 1)) + LOWER(SUBSTRING(i.nazivA, 2,
LEN(i.nazivA))),
FROM Artikal INNER JOIN Inserted i
43/63
ON Artikal.idArtikal = i.idArtikal
END
Spajanjem (INNER JOIN) tabela Artikal i Inserted dobijaju se sve n-torke (zapisi) koji su zahvaćeni
izvršenom INSERT ili UPDATE operacijom, nakon čega se nad svima njima, odjednom, mogu primeniti
poslovna pravila 1 i 2.
Za primenu pravila broj 3 idealno je koristiti INSTEAD OF DELETE okidač, SQL 45.
SQL 45. Okidač INSTEAD OF DELETE

CREATE TRIGGER Okidac_ZabranaBrisanja ON Artikal
INSTEAD OF DELETE AS
BEGIN
DELETE Artikal FROM Artikal A
INNER JOIN Obrisano O ON A.idArtikal = O.idArtikal and A.Artikal NOT IN
(SELECT idArtikal FROM Stavke)
END
Priklikom pokušaja brisanje artikla koji se već nalazi utabeli Stavke (znači da je artikal prodat: SELECT
idArtikal FROM Stavke) server vraća poruku:
(0 rows affected) -- nije obrisano!
(1 row affected)
DML okidačima se kontroliše sadržaj, a za kontrolu strukture objekata se koriste DDL okidači. Operacije
poput CREATE, ALTER i DROP mogu se sprečiti, usloviti ili uz njih definisati i neke druge operacije.
DDL okidači izvršavaju se isključivo nakon operacije, odnosno ne postoji INSTEAD OF tip DDL okidača.
SQL 46. DDL okidač na nivou baze podataka

CREATE TRIGGER Okidac_Zabrana
ON DATABASE
AFTER DROP_TABLE, ALTER_TABLE
AS
BEGIN
PRINT 'NEMATE DOZVOLU ZA MENJANE STRUKTURE i/ili BRISANJE TABELE!'
ROLLBACK
END
Prilikom pokušaja menjanja stukture ili brisanja bilo koje tabele iz aktivne baze podataka, server šalje
sledeću poruku, a na osnovu napisanog okidača u SQL 46.:
NEMATE DOZVOLU ZA MENJANE STRUKTURE i/ili BRISANJE TABELE!
Msg 3609, Level 16, State 2, Line 1
The transaction ended in the trigger. The batch has been aborted.
Postoje dva područja delovanja DDL okidača:

na nivou baze podataka (ON DATABASE) ili
na nivou servera (ON ALL SERVER).
U okidaču Okidac_Zabrana, SQL 46., zabranjeno je brisanje zabranjeno je brisanje i menjanje strukture
bilo koje tabele u bazi podataka nad kojom je kreiran okidač. Kako se DDL okidač uvek izvršava posle
izvedene operacije ili upita, naredbom ROLLBACK poništava seo prethodno obavljena akcija DROP
TABLE ili ALTER TABLE.
44/63
Modifikacijom okidača Okidac_Zabrana datom u SQL 46., na taj način što se umesto ON DATABASE
upiše ON ALL SERVER, taj okidač bi se sada izvršavao nad bilo kojom bazom podataka na serveru.
U SSMS alatu DML okidače moguće je pronaći unutar svake tabele pod stavkom "Triggers", dok se DDL
okidači na nivo baze podataka nalaze pod stavkom "Database Triggers", a okidači na nivou servera u stavci
"Server Objects/Triggers", slika 44.
Slika 44. Lokacija okidača u SSMS alatu
6.7. Sekvence
Počevši od SQL Servera 2012 moguće je kreirati i koristiti sekvence. To su objekti koji generišu rastuće ili
opadajuće sortirane nizove celobrojnih vrednosti. Sekvence podsećaju na kolone sa svojstvom IDENTITY,
ali takve kolone vezane su isključivo za tabelu u kojoj postoje, dok se jedna sekvenca može koristiti u svim
tabelama baze podataka. Takođe, sekvence se mogu automatski ili proizvoljno resetovati, odnosno moguće
im je definisati minimalnu i maksimalnu vrednost.
Pri kreiranju sekvence poželjno je definisati početnu vrednost niza (START WITH), SQL 47. Ukoliko nije
drugačije definisano, podrazumevana (default) vrednost inkrementa (INCREMENT BY) je broj 1, dok
minimalna i maksimalna vrednost, kao i svojstvo CYCLE nisu definisani.
SQL 47. Kreiranje sekvence 'RedBroj'

CREATE SEQUENCE RedBroj
START WITH 1
Kada se generiše novi broj u sekvenci (nizu) potrebno je izvršiti upit, SQL 48.
SQL 48. Pozivanje upita za generisanje novog broja u sekvenci

SELECT NEXT VALUE FOR RedBroj
Svaka generisana vrednost sekvence može se iskoristiti za numerisanje n-torki (zapis) u tabelama,
numerisanju izvršenih operacija u tabelama logovanja itd., naredbama poput upita datog u SQL 49.
SQL 499. Upotreba sledeće vrednosti iz sekvence u tabeli logovanja
45/63
INSERT INTO LogTabela
VALUES (NEXT VALUE FOR RedBroj, 'Login korisnika', SYSDATETIME())
Sekvence se mogu generisati i u opadajućem poretku, SQL 50. Početna i maksimalna vrednost sekvence
Opadajuca je broj 100, a svaka sledeća vrednost je umanjena za 1. Kada se dođe do minimalne vrednosti
(1), sljedeća vrednost, koja se generiše, je opet broj 100, što je obezbeđeno uključivanjem svojstva CYCLE.
SQL 50. Kreiranje opadajuće sekvence

CREATE SEQUENCE Opadajuca
START WITH 100
INCREMENT BY -1
MINVALUE 1
MAXVALUE 100
CYCLE
Ukoliko je potrebno da se resetuje sekvenca, pre nego što je dostigla svoju graničnu vrednost, potrebno je
izvršiti upit:
ALTER SEQUENCE Opadajuca RESTART WITH 100
Preporučljivo je da se uvek pre koriste sekvence, tamo gde ima potrebe za brojanjem , umesto kolona sa
svojstvom identiteta. Sekvence imaju i šire delovanje, lakše ih je kontrolisatii zato one uvek generišu
predviđene vrednosti. Vrednosti generisane kolonom sa svojstvom identiteta ne moraju uvek biti u istom
razmaku i njih je moguće generisati samo prilikom formiranja novog zapisa.
6.8. Sinonimi
Sinonimi su pomoćni objekti koji se koriste kako bi se kreirala alternativna imena za objekte u bazi
podataka. Njihovim korišćenjem pojednostavljuje se pristup objektima sa dugačkim nazivima, uz manje
posledica moguće je izmeniti postojeću strukturu baze podataka i povećavaju se sigurnosni aspekti
administracije.
Sinonime je moguće kreirati za uskladištene procedure, funkcije, tabele i poglede , SQL 51., pri čemu u
trenutku kreiranja sinonima, stvarni objekat ne mora da postoji već se on proverava tek prilikom
referenciranja sinonima.

CREATE SYNONYM Prod FOR Prodaja.dbo.Prodavnica
SELECT * FROM Prod -- SELECT * FROM Prodaja.dbo.Prodavnica
Upotrebom sinonima, aplikacije uvek mogu koristiti iste upite prema bazi podataka. Umesto da se
referenciraju na stvarne objekte, referenciranjem na sinonime uklanja se potreba za modifikacijom
aplikacije u slučaju promene naziva stvarnih objekata. Tada je u bazi podataka samo potrebno ponovo
kreirati iste sinonime tako da ovaj puta referenciraju na nova imena objekata.
U području sigurnosti i administracije sinonimi takođe imaju svoju ulogu. Potencijalni napadač puno će
teže doznati ime stvarnog objekta na osnovu imena sinonima, a pri administraciji prava i dozvola korisniku
se može omogućiti korišćenje sinonima ne znajući o kom stvarnom objektu je zaista reč.
46/63
7. Organizacija i bezbednost na serveru baza podataka
7.1. Sheme
U starijim verzijama SQL Servera svaki objekat je imao svog vlasnika (owner). Vlasnik objekta je,
najčešće, korisnik koji je kreirao objekat i imao je trajno vlasniztvo nad njim. Međutim, ukoliko se iz nekog
razloga obriše korisnik, to jest vlasnik, nastali bi određeni problemi. Pre nego što se obriše takav korisnik
iz baze podataka, potrebno je sve objekte, čiji je on vlasnik, prebaciti u vlasništvo nekog drugog korisnika.
Dalje, pojavio bi se i problem sa referenciranjem tih objekata (KorisnikNoviVlasnik.Objekat) što dovodi
do posledice izmene prograsmskog koda u uskladištenim procedurama, funkcija i aplikacijama, [23].
Od pojave servera SQL Server 2015 uvode se sheme koje značajno pojednostavljuju ogranizaciju,
administraciju i pristup objektima baze podataka. Shema se može uprediti sa imenovanim prostorom
(namespace) u kome se nalaze jedan ili više objekata, pri čemu svaki objekat baze podataka može pripadati
samo jednoj shemi, a pristupa mu se preko imena sheme kojoj propada: Server.
BazaPodataka.Shema.Objekat, slika 45., [23].
Slika 45. Organizacija tabele po shemama
Na primeru sa slike 45., uočava se postojanje tri sheme: HumanResources, Person i Production. Svaka od
ovih shema, pored tabela, može da poseduje i poglede uskladištene procedure funkcije, odnosno svaki
objekat koji se može kreirati na serveru baze podataka.
Sheme u bazi podataka, korišćenjem SSMS alata, mogu se pronaći pregledom stavke Security  Schemas,
slika 46.
Slika 46. Pregled shema u bazi podataka Prodaja

47/63
Kreiranje sheme počinje tako što se klikne desnim tasterom miša na Shemas i izabere se New Shema, čime
se pokreće procedura za njeno kreiranje, slika 47.
Slika 47. Kreranje sheme: dodeljivanje naziva (Schema name) i vlasnika (Schema owner)
Ukoliko se izostavi vlasnik, server automatski dodeljuje vlasnika pod imenom dbo. Ovaj vlasnik se može
uočiti u upitu SQL 1, u kome se kreirala tabela baze podataka, [dbo], drugim rečima, na serveru bazu
podataka, po default - u, vlasnik objekata je dbo. Ukoliko se dodeljuje vlasnik sheme, slika 48., treba voditi
računa o prenosu vlasništva, ukoliko se vlasnik briše iz baze podataka.
Slika 48. Kreranje sheme: dodeljivanje ovlašćenja
Glavna prednost rada sa shemama je administriranje. Naime, umesto dodeljivanja vlasništva nad
pojedinačnim objektima i operacijama nad njim, dovoljno je dehinisati ovlašćenja nad shemom. Na slici
48., definisani vlasnik ima dopuštenje za izvršavanje uskladištenih procedura (Execute), dodavanje
(Insert), menjanje (Update) i preuzimanje (Select) podataka iz svih objekata unutar sheme. Korisnik:
korisnik1, automatski dobija navedena ovlašćenja i za svaki novi objekat unutar sheme. Ova ovlašćenja
mogu se definisati i za grupe korisnika (database role) odnosno za aplikacije (application role).
Korisnicima je moguće odobriti (GRANT) ili zabraniti (DENY) neku operaciju, a opcijom WITH GRANT
omogućiti da se te operacije odobre i drugim korisnicima.
7.1. Nalozi za prijavljivanje
Nalog za prijavljivanje (login), nalog, koristi se u svrhu verifikacije i povezivanja korisnika na SQL Server.
Svaki nalog može biti povezan s više korisnika baza podataka (jednim korisničkim nalogom po bazi), a oni
se koriste za verifikaciju, odnosno pristup bazama podataka.
48/63
Nalog za prijavljivanje se kreira desnim klikom na opciju Login u okviru stavke Security, slika 49. Ime
naloga za prijavljivanje može biti ime postojećeg Windows korisnika ili grupe. U tom slučaju koristi se
Windows verifikaciju pa za takve korisnike nije potrebno definisati lozinku. Ovakav tip verifikacije
najčešće se koristi u intranetskim mrežama, dok nije pogodan za korisnike koji se nalaze u drugim
domenima ili pristupaju SQL Serveru preko interneta.
Slika 49. Prijavljeni nalozi za prijavljivanje na server baze podataka
Za podršku najšireg spektra korisnika koristi se SQL Server autentifikacija. Korisničko ime i lozinka čuvaju
se u SQL Serveru, a takvi korisnici mogu se verifikovati i povezati na SQL Server iz drugih domena, mreža
ili preko interneta. Takvim korisnicima moguće je nametnuti i pravila o lozinkama, poput pravila da lozinka
traje samo određeno vreme ili da je korisnik mora promeniti pri sledećoj prijavi. Pravila o lozinkama se ne
definišu u SQL Serveru već u operativnom sistemu servera ("Start / Control Panel / Administrative Tools
/ Local Security Policy"), [24].
Pri kreiranju naloza za prijavu na server baze podataka moguće je kreiranje i povezivanje novih korisničkih
naloga baza podataka, slika 50. Na slici 50., prikazano je povezivanje prijavnog naloga ProbaKorisnik sa
bazama podataka Prodaja i tempdb na način da se unutar njih kreiraju korisnički nalozi koji imaju isto ime
kao i prijavni nalog.
Slika 50. Kreiranje i povezivanje korisničkih naloga baza podataka
Svaki od ovih korisničkih naloga može imati različito ime i može pripadati različitim ulogama baza
podataka (database roles). Slično kao i server uloge koje služe za kreiranje grupe korisnika na nivou
instance, tako postoje i uloge baza podataka, odnosno grupa korisnika na nivo pojedinačne baze podataka.
I u ovom slučaju postoje unapred definisane (stalne) uloge poput db_datareader, db_datawritter, db_owner,
slika 50., a mogu se kreirati i nove.
49/63
Korisnički nalog može se istovremeno dodeliti ulogama db_datareader i db_denydatareader kao i ulogama
db_datawritter i db_denydatawritter. Na primer, nekoj grupi korisničkih računa (ulozi) omogućeno je
čitanje svih podataka (db_datareader), ali jednom delu te grupe (podgrupi) čitanje podataka je zabranjeno
(db_denydatareader).
7.2. Korisnički nalozi
Korisničkim naloz vrši se autorizacija, odnosno dodeljivanje prava i dozvola za rad u bazi podataka.
Najčešće se koriste u kombinaciji s nalozima za prijavu na server, gde se nakon verifikacije (naravno
uspešne), u zavisnosti od povezanih korisničkih naloga, korisniku dodeljuju prava i dozvole nad jednom
ili više baza podataka. Korisnički nalozi su smešteni u okviru baze podataka, a može ih biti 11 tipova, [25].
U SSMS alatu servera baze podataka, po defaultu, kada se kreiraju novi korisnički nalozi, ponudiće se
sledeći tipovi naloga (korisnika):
 Windows korisnik
 SQL korisnik sa nalogom za prijavu na server
 SQL korisnik bez nalogoma za prijavu na server
 Korisnik povezan sa certifikatom
 Korisnik povezan sa asimetričnim ključem
Ovde treba imati na umu, da su u pitanju nalozi, odnosno korisnici koji mogu da administriraju baz
podataka, odnosno da koriste resurse servera. Drugim rečima, ne treba mešati korisnika koji ima pravo da
radi u aplikaciji koja koristi bazu podataka na serveru i administratora baze podataka, sa definisanim
administratorskim pravima.
Prva dva, navedena, tipa naloga su standardni tipovi, dok su ostali tipovi za posebne namene. Novijim SQL
serverima (od verzije 2012 do danas) , baze podataka mogu se pretvoriti u delimično nezavisne baze
podataka (partially contained databases). One su minimalno zavisne od stavki SQL Servera i zato sadrže
i korsničke naloge sa definisanim lozinkama (SQL user with password). Pomoću takvih korisničkih naloga
može se vršiti i verifikacija korisnika, bez potrebe primene naloga za prijavu koji se nalazi na serveru.
Procedura za kreiranje korisničkog naloga, korisnika, u SSMS alatu, otpočinje izborom baze podataka
(Prodaja), zatim se u stavci Security, pronadje Users, i desnim klikom miša izabere se New Users, slika 51.
Naklon ove akcije, otvoriće se prozor za dodavanje novog korisnika, slika 52.
Slika 51. Otpočinjanje procedure za kreiranje novog korisnika
50/63
Slika 52. Kreiranje korisničkog naloga baze podataka
Slika 53. Dodeljivanje dozvola korisničkom nalogu baze podataka
Autorizacija, odnosno prava i dozvole u bazi podataka, dodeljuju se unutar opcije "Securables". Na slici,
53., novom korisniku Profesor, dodeljena je dozvola izvršavanja SELECT upita nad svim tabelama baze
podataka Prodaja. Naravno, dozvole se mogu postaviti i na pojedinačne tabele iz baze podataka, pa čak i
na pojedine kolone iz izabrane tabele (Column Permissions).
7.3. Uloge
Kao što se sheme baze podataka koristi za grupisanje objekata, tako je moguće koristiti grupisanje korisnika
u uloge (roles). Pomoću uloga (grupa) jednostavnije se organizuju i administriraju korisnici, jer prava i
dozvole se dodeljuju na osnovu pripadnosti nekoj grupi.
SQL server dopušta formiranje sledeća tri tipa uloga:

 Serverske uloge (server roles)
 Uloge baze podataka (database roles)
 Aplikacijske uloge (application roles)
Na primer, ako se u IT firmi, svakom od informatičara, koji rade na nekom projektu, dodele ista prava i
dozvole tako što im se dodeli uloga "Projekat_1". Prava i dozvole se, umesto pojedinačno, dodeljuju celoj
grupi.
Serverskom ulogom formira se grupa članova koja ima prava i dozvole na nivou SQL Server instance, a
51/63
članovi serverske uloge mogu biti prijavni nalozi i druge serverske uloge. Na primer, grupi se može dodeliti
pravo i dozvola da zaustave rad SQL Servera (Shutdown), da se napravi pregled svih baza podataka (View
any database) na serveru, kao i definicije svih objekata (View any definition), kao i za uvid u stanje
izabrane stavke (View server state). Između ostalog, server ulogom, može se dodeliti prava i dozvole za
upravljanje pristupnim tačkama (endpoints), nalozima za prijavu i slično.
Bilo pri kreiranju nove ili uređivanju postojeće serverske uloge, moguće je dodeliti nove članove izborom
stavke Members. Takođe, ukoliko je potrebno da navedena serverska uloga bude član neke druge serverske
uloge (njena poduloga) to se definiše u stavci Membership.
Svaka SQL Server instanca ima već unapred definisane serverske uloge koje se mogu iskoristiti pri
dodeljivanju najčešćih administrativnih prava i dozvola. Stalne serverske uloge se ne mogu se menjati već
im je moguće kontrolisati članstvo.
7.4. Kriptografija i SQL Server
Dodjeljivanjem odgovarajućih prava i dozvola moguće je ograničiti pristup podacima. Bez obzira na to
svedoci smo da postoje nedozvoljeni upadi na servere baza podataka, odnosno nedozvoljeni pristup
osetljivim podacima (lični podaci kupaca, lozinke, brojevi kreditnih kartica i slično). Iz potrebe da se
preduprede nedozvoljeni upadi potrebno je da se izvrši dodatna zaštita. U tu svrhu SQL server nudi funkciju
kompresije (hash) kao i simetrične i asimetične kriptografske algoritme.
Funkcije kompresije koriste se kao jednosmerni kriptografski algoritmi bez ključa. Kada se neki sadržaj
(tekst, datoteka, ...) komprimuje funkcijom kompresije više nije moguće u realnom vremenu iz
komprimovanog sadržaja dobiti izvorni sadržaj. Zbog toga se funkcije kompresije često koriste za zaštitu
lozinki.
Rezultat funkcije kompresije mora biti jedinstven i uvek isti za pojedinu ulaznu vrednost, a bez obzira na
veličinu ulaznog podatka, funkcija kompresije kao rezultat mora uvek da vrati binarni zapis iste veličine.
Pri izboru funkcije kompresije treba uzeti u obzir da se zbog otkrivenih slabosti i nedostataka mnoge od
njih danas ne koriste. Tako na primer, funkcije MD4, MD5 i SHA-1 zbog otkrivenih kolizija i uspešnih
metoda napada ne smatraju se dovoljno sigurnim, pa se danas i ne koriste, već se umesto njih primenjuju
SHA-2 i SHA-3 funkcije. U današnjim verzijama servera, primenjene su funkcije MD2, MD4, MD5, SHA-
0, SHA-1, SHA-2 (256) i SHA-2 (512). Sve, osim SHA-2, funkcije se smatraju zastarelim, pa ukoliko se
one koriste, server će upozoriti na to, [26].
Primer za zaštitu lozinke, u tabeli Korisnici, dat je u SQL 52. Izvršavanjem ovog upita kreira se tabela
Korisnici, sa tri kolone: idbroj  PK, KorIme, Lozinka. Iako lozinka predstavlja niz znakova, kolona
lozinka kao tip podatka ima VARBINARY (binarni) tip. Ovo je iz razloga što se u njenu ne čuva sekvenca
znakova koji predstavljaju neki tekst, već rezultat funkcije kompresije , odnosno binarni zapis.
Ukoliko se pokrene uskladištena procedura DodajKorisnika sa unosom "Korisnik1" za kolonu KorIme,

odnosno "Kor1234567" za kolonu Lozinka ( ), sadržaj tabele Korisnici biće kao što je prikazano na slici
54.
Pri proveri lozinke, klijent aplikacija računa rezultat kompresije unesene lozinke, a onda ga upoređuje sa
rezultatom kompresije koji je sačuvan u koloni lozinka tabele Korisnici. Ukoliko su oba rezultata identična
lozinka je ispravna. U protivnom korisnik će morati ponovno da se prijavljuje, odnosno da unese lozinku.
Kao što je rečeno, rezultat kompresije (lozinka) je sačuvan kao binarni zapis i kao takav se najčešće
predstavlja u heksadecimalnom obliku, u kojem je pogodan i za upoređivanje.
52/63
CREATE TABLE Korisnici
(idbroj INT IDENTITY(1,1) NOT NULL,
KorIme NVARCHAR(50) NULL,
Lozinka VARBINARY(256) NOT NULL,
PRIMARY KEY(idbroj));
GO
-- Kreiranje uskladištene procedure za dodavanje novog korisnika
CREATE PROCEDURE DodajKorisnika (@KorIme varchar(50), @Lozinka varchar(256))
AS
BEGIN
INSERT INTO Korisnici (KorIme, Lozinka)
VALUES (@KorIme, HASHBYTES('SHA2_256', @Lozinka))
END
Slika 54. Tabela Korisnici sa kolonom Lozinka na koju je primenjena funkcija kompresije
Da bi se sprečilo lako otkrivanje rezultata funkcije kompresije, često se koristi i metoda dodavanja niza
karaktera na početak, u sredinu ili na kraj unete lozinke, takozvano "soljenje", SQL 53. Nakon ove akcije,
sve zajedno se komprimuje odabranom funkcijom kompresije. Na identičan način se vrši i provera unete
lozinke.

DECLARE @Lozinka varchar(256) = 'Lozinka'
DECLARE @Sol varchar(256) = 'DodatakNaKrajLozinke'
SELECT HASHBYTES('SHA2_256', @Lozinka + @Sol)
Funkcije kormpresije su korisne u situacijama gde podatke nije potrebno vraćati u izvorni oblik. U
protivnom, umesto funkcija kormpresije potrebno je koristiti simetrične i asimetrične kriptografske
algoritme.
Simetrični kriptografski algoritmi koriste jedan tajni ključ. Jednom šifriran, sadržaj se može dešifrovati
samo pomoću istog ključa. Ipak, da bi se tajni ključ na siguran način mogao dostaviti drugoj strani potrebno
je koristiti asimetrične kriptografske algoritme koji koriste dva ključa (javni i privatni). Javni ključ je svima
dostupan, a sadržaj šifriran javnim ključem može biti dešifrovan samo odgovarajućim privatnim ključem
koji posjeduje samo lice kojoj je poruka namenjena.
Za korišćenje kriptografskih algoritama, u SQL Serveru, moguće je pratiti hijerarhiju ključeva , slika 55.
Na primer, neka tabela Kupac sadrži kolonu BrojPlatneKartice. Ovaj podatak je osjetljiv i potrebno ga je
zaštiti šifriranjem, tako da je po potrebi moguće pročitati izvorni sadržaj , to jest broj platne kartice. Zbog
toga, za ovaj primer, nije moguće koristiti funkcije kompresije već će se upotrebiti simetrični kriptografski
algoritam AES-256, SQL 54.
SQL 54. Implementacija hijerarhije ključeva

CREATE TABLE KUPAC
(idKupac INT IDENTITY(1,1) NOT NULL,
nazivK VARCHAR(35) NOT NULL,
adresaK VARCHAR(50) NULL,
pib VARCHAR(9) NOT NULL,
BrojPlatneKartice VARBINARY(4000) NULL,
PRIMARY KEY (idKupac));
53/63
GO
-- 1) Kreiranje glavnog ključa baze podataka
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MasterKeyPass'
GO
-- 2) Kreiranje asimetričnog ključa šifriranog glavnim ključem baze podataka
CREATE ASYMMETRIC KEY MojAsimetricniKljuc
WITH ALGORITHM = RSA_2048
GO
-- 3) Kreiranje simetričnog ključa šifriranog asimetričnim ključem
CREATE SYMMETRIC KEY MojSimetricniKljuc
WITH ALGORITHM = AES_256
ENCRYPTION BY ASYMMETRIC KEY MojAsimetricniKljuc
GO
Slika 55. Hijerarhija ključeva u SQL Serveru, 27
Kolona, BrojPlatneKartice imaće šifriranu vrednost, pa zato njet tip podataka VARBINARY, SQL 54.. Za
šifriranje te kolone, upotrebljen je AES-256 algoritam pomoću simetričnog ključa MojSimetricniKljuc,
SQL 55. Da bi se zaštitio taj simetrični ključ kreiran je i asimetrični ključ MojAsimetricniKljuc, pomoću
algoritma RSA (2048), čiji je privatni ključ isto potrebno zaštiti. Podrazumeva se da je ova zaštiita izvedena
pomoću glavnog ključa baze podataka (database master key, DMK), SQL 54 ili proizvoljno definisanom
lozinkom.
SQL 55. Asimetrični ključ šifriran proizvoljno definisanom lozinkom

CREATE ASYMMETRIC KEY MojAsimetricniKljuc
WITH ALGORITHM = RSA_2048
ENCRYPTION BY PASSWORD = 'AsymmetricKeyPass'
GO
Ukoliko je privatni ključ asimetričnog algoritma zaštićen proizvoljno definisanom lozinkom, SQL 55., nije
neophodno kreirati i koristiti DMK ključ. Ipak, iz sigurnosnih razloga to nije preporučljivo jer upotrebom
DMK ključa dodaju se novi nivoi šifriranja budući da je i sam DMK ključ dodatno zaštićen ključem instance
SQL Servera (service master key, SMK) i lozinkom.
Na disku je poželjno formirati rezervne kopije SMK i DMK ključevam, SQL 56., kao i upotrebljenih
certifikata. U slučaju gubitka tih ključeva ili certifikata, bez njihovih rezervnih kopija nije moguće
dešifrovati simetrične i asimetrične ključeve unutar baza podataka, pa time i dešifrovati podatke.
DMK ključ nalazi se u dve baze podataka – u sistemskoj bazi podataka: master, gde je zaštićen SMK
ključem i u lokalnoj bazi podataka, gde je zaštićen lozinkom koja je definisana pri kreiranju tog ključa.
54/63
Nakon implementacije željene hijerarhije ključeva, SQL 54., moguće je koristiti simetrični ključ
MojSimetricniKljuc za šifriranje i dešifriranje brojeva kreditnih kartica iz tabele Kupac, SQL 56.
Simetrični ključ potrebno je prvo otvoriti, a posle toga upotrebiti funkciju ENCRYPTBYKEY i
DECRYPTBYKEY za šifriranje i dešifriranje sadržaja. Odgovarajuće stavke ovih funkcija postoje i u
slučajevima kada se za šifriranje i dešifriranje koriste certifikati i asimetrični kriptografski algoritmi.
SQL 56. Korištenje simetričnog kriptografskog algoritma

-- Otvaranje simetričnog ključa
USE Prodaja
OPEN SYMMETRIC KEY MojSimetricniKljuc
DECRYPTION BY ASYMMETRIC KEY MojAsimetricniKljuc
GO
-- Umetanje šifriranog sadržaja
INSERT INTO Kupac(idKupac, BrojPlatneKartice)
VALUES ('111111', ENCRYPTBYKEY(KEY_GUID('MojSimetricniKljuc'), '9876-5432-1037'))
GO
-- Sadržaj šifrirane kolone
SELECT BrojPlatneKartice FROM Kupac
WHERE idKupac = '111111' -- 0x00FE30C185C69B42BF5D0D0432F8F518010000004B926B64E5...
GO
-- Dešifriranje podataka
SELECT CONVERT(VARCHAR(50), DECRYPTBYKEY(BrojPlatneKartice)) FROM Kupac
WHERE idKupac = '111111' -- 9876-5432-1037
Za šifriranje, mogao se odabrati i neki drugi algoritam. Na primer, kolona BrojPlatneKartice, mogao se
direktno šifrirati asimetričnim ključem, ali zbog brzine i performansi baze podataka to se ne preporučuje.
Naravno moguće je za zaštitu simetričnog ključa, umesto asimetričnog ključa , formirati certifikat i slično.
7.5. Transparentno šifriranje podataka
Osim pojedinih kolona, moguće je šifrirati i kompletnu bazu podataka korišćenjem transparentnog šifriranja
podataka (transparent data encryption, TDE). Cilj ovog postupka je da zaštiti podatke u slučaju krađe, pa
se u tu svrhu šifriraju sve datoteke baze podataka, uključujući dnevnik transakcija i datoteke rezervnih
kopija.
Za šifriranje sadržaja baze podataka i njenih datoteka koristi se simetrični algoritam čiji se ključ (Database
Encryption Key, DEK) šifrira certifikatom smeštenim u master bazi podataka ili asimetričnim ključem
smeštenim u EKM (extensible key management) modulu, Slika 56. Bez tog certifikata (ili asimetričnog
ključa) uljez neće moći dešifrirati DEK pa samim time ni sadržaj baze podataka.
55/63
Slika 56. Arhitektura transparentnog šifriranja podataka, 28
Pre korišćenja TDE-a potrebno je obezbediti da u master bazi podataka postoji DMK ključ i certifikat koji
će biti zaštićen tim ključem, SQL 57. Tek nakon toga moguće je generisati DEK ključ i šifrirati bazu
podataka.
Nakon kreiranja certifikata poželjno je kreirati rezervnu kopiju jer, u slučaju gubitka certifikata neće moći
da se dešifriraju DEK ključevi zaštićeni tim certifikatom. Ukoliko, pre uključivanja TDE-a, rezervna kopija
certifikata ne postoji SQL će poslati upozorenje o tome.
SQL 57. Kreiranje DMK ključa i server certifikata
USE master
GO
-- Kreiranje DMK ključa master baze podataka
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MasterKeyPass'
GO
-- Kreiranje server certifikata
USE master
CREATE CERTIFICATE TDE_Certifikat WITH SUBJECT = 'TDE certifikat'
GO
7.6. Uvek šifrirani podaci
Od SQL Server 2016, sadržaj pojedinih kolona tabele moguće je zaštiti korištenjem opcije Always
Encrypted. Ova opcija omogućava klijent aplikacijama čitanje i obradu šifriranog sadržaja u čitljivom,
dešifriranom obliku, dok se prilikom ažuriranja izmena ili dodavanja novih podataka, ti podaci šifriraju pre
slanja nazad u bazu podataka.
Na ovaj način omogućuje se da baza podataka u svakom trenutku sadrži šifrirane podatke koje ne mogu
dešifrirati, čak ni, korisnici sa najvećim ovlašćenima u SQL Serveru. Time se ujedno postiže i separacija
onih koji održavaju podatke (administratori baza podataka) i onih koji su vlasnici podataka i koji imaju
samo uvid u njih (korisnici), [29].
Konfigurisanje ove opcije, u SSMS alatu (od SQL Servera 17), se izvršava tako što se klikne desnim
tasterom miča na ime tabele ili kolone u tabeli i izabere se Encrypt Columns…. Na ovaj način dobiće se
prozor New Column Master Key, slika 57.
56/63
Slika 57. Generisanje certifikata i glavnog ključa kolone (CMK)
Sadržaj izabrane kolone šifrira se ključem kolone (column encryption key, CEK), a ključevi kolone šifriraju
se glavnim ključem kolone (column master key, CMK). Ključevi kolona sačuvani su unutar stavke SQL
Servera, a glavni ključ kolone čuva se u nekom spoljnom resursu kao što je personalni (lični) certifikat.
Nakon izbora odredišnog certifikata (ili kreiranja novog) moguće je kreirati i sačuvati CMK ključ , slika
57.
Recimo da se želi da se šifrira kolona BrojPlatneKartice, tipa podatka VARCHAR(50). Za ovu namenu,
kreira se CEK ključ, CEK_PlatnaKartica, koja je, prethodno, generisana CMK ključem, slika 58.
Slika 58. Generisanje ključa kolone
SQL Server ima pristup u šifriranu vrednost CEK ključa, odnosno u algoritam kojim je ključ šifriran, SQL
58. Međutim, za njegovo dešifrovanje potreban je CMK ključ, odnosno certifikat u kojem je sačuvan.
SQL 58. Kreiranje CEK ključa

USE [Prodaja]
/****** Object: ColumnEncryptionKey [CEK_PlatnaKartica] Script Date:
5/13/2020 17:46:18 PM ******/
CREATE COLUMN ENCRYPTION KEY [CEK_PlatnaKartica]
WITH VALUES
(
57/63
COLUMN_MASTER_KEY = [CMK],
ALGORITHM = 'RSA_OAEP',
ENCRYPTED_VALUE =
0x016E000001630075007200720065006E00740075007300650072002F006D0079002F0063006
60037003900320064003500640039006500610039003100320032006100370030003800380038
00300064003400620036003000340066003500640034006400360030006100360063006200330
0A3AC89F9500A1341C12DE88A0970BA7E89AAE48CEE6C9FE4378BB7B35EC92E9A78CED7D69F06
B75BF30351C5E5FD77F95A662628AFF273ED698F8ED4B29899DEC3C9FC394F0BD43DD3B1F6899
89BC2239EBD094E1815D6CD44A18065F17F79ECF5F87C8E9BD7739BF0D7C366A03855561E4C43
68955028A0453D0DE9A51DA321606D9AAE9FDA6EB64AB40EA0CADBC70AC20944E9DC938576EAD
7371826D7DA91C3BEB9FDEB0AE7D4FF9896E80E6808C62596BF005058652E52901E061D51528D
B7E4F56D9C59C335DC93E8F7519DB561B2B9A317E4A87A9A8493ACE48D501A0035936E3EF1A04
84CAA63CF3ABDE726B77B5781EF08B0288790ED51FB352835A955928391538E0CD3810185B04D
024F745062B95539F6D3394EE8A984430B18298ABC32BEE3CC7B9A8F4E44150EB1DD3C4C5C17C
4126DD58E44062AFE70825BC144796BC027E6F1D098090881A0DD6370BDB5A6FC654323FD7393
98C1E649350210151C59C98A6842F9F73FEFDD7EB1DB1F9415CBADC7BC85C8059630B4B6AD037
563F3A92F01FDBF0BABA48E39C6172125C178329BA97F6E1676BD9088A099F2812A426C8BA122
559ACAA40BAAA3020A1A3B9C965FE95AF359079BB83BC14379992115CBE3474BBAC7A6A0E6BFC
7BF9B80923AECCE6A19E4F2B9C524026D43AC79928793D82E26273A1B43F50A6967AC9DBD34B8
E278F840D7B0B7ED13AB6B3D
)
Nakon što postoji CMK i barem jedan CEK ključ može se pristupiti šifriranju sadržaja kolone, Slika 59.
Jednim CEK ključem moguće je šifrirati sve kolone tablice, a svaku od kolona može biti šifriran
determinističkim ili slučajnim tipom ključa. Ključevi determinističkog tipa uvek će generirati istu šifriranu
vrednost za jedan podatak, dok će se korišćenjem slučajnog tipa ključa, uvek generisati različite šifrirane
vrednosti za isti podatak. Deterministički ključ dozvoljava operacije poput grupisanja, filtriranja i spajanja
tabela, ali manje je siguran od slučajnog tipa ključa. Na primer, ako u nekoj koloni mogu da se unesu jedna
od dve moguće vrednosti (pol: M/Ž; ili recimo True ili False), svakako je bolje koristiti slučajni tip ključa.
Slika 59. Izbor kolone za šifriranje
Da bi klijent aplikacije mogao videti dešifrovani oblik tih podataka, moraju da koriste jedan drajvera
(upravljački program - driver) koji podržava instancu Always Encrypted. Trenutno su u opticaju tri drajvera
koja se koriste:
 .NET Framework Data Provider for SQL Server
 JDBC
 Windows ODBC
58/63
Na primer, u slučaju korišćenja prvog drajvera, .NET aplikacije moraju koristiti minimalno .NET
Framework 4.6. U izrazu "Connection string" potrebno je dodati "Column Encryption Setting=enabled",
nakon čega će ta aplikacija biti u mogućnosti videti šifrirani sadržaj kolone u čitljivom obliku.
Za ovo se moće koristiti i SSMS kao klijent aplikacija baze podataka. Prilikom prijave potrebno je kliknuti
na dugme "Options >>", a zatim na "Additional Connection Parameters". Šifriranje kolona potrebno je
omogućiti dodavanjem izraza "Column Encryption Setting=enabled", Slika 60.
Slika 60. Omogućavanje šifriranja kolona u SSMS alatu
Nakon prijave naredbom SELECT moguće je preuzeti sadržaj šifrirane kolone BrojPlatneKartice u
čitljivom (dešifriranom) obliku. SSMS alat nudi i mogućnost automatske parametrizacije T-SQL
promenljivih za potrebe šifriranja i čuvanja podataka nazad u bazu podataka. Parametrizacija se može
uključiti i ručno korišćenjem stavke Query / Query Options… / Execution / Advanced / Enable
Parametrization for Always Encrypted.
Ukoliko se u nekom trenutku više ne želi šifriranje kolone korišćenjem Always Encrypted instance potrebno
je ponovno pokrenuti čarobnjak i za tip šifriranja odabrati Plaintext.
7.7. Dinamičko maskiranje podataka
Instaca dinamičkog maskiranja podataka (dynamic data masking, DDM) predstavljena je izlaskom SQL
Servera 2016. Njom je omogućeno skrivanje osetljivih podataka od neovlašćenog korisnika upotrebom
funkcija maskiranja. DDM instancom podaci se ne šifriraju već se prikazuju u teško razumljivom ili
nepotpunom obliku.
U tabeli 27., date su funkcije maskiranja u SQL Serveru.
Tabela 27. Funkcije maskiranja u SQL Serveru

Funkcija Opis
Za skrivanje tekstualnih tipova podataka koriste se XXXX znakovi, a za numeričke
Default tipove podataka 0 (nula). Datum i vreme skrivaju se vrednošću 01.01.1900
00:00:00.0000000.
Prikazuje se samo prvi znak adrese e-pošte s konstantnim ".com" sufiksom. Na
Email
primer, aXXX.XXXX.com.
Koristi se za skrivanje numeričkih tipova podataka nekom slučajnom vrednošću
Random
unutar definisanog intervala.
59/63
Prikazuje određen broj početnih i krajnjih znakova, a središnji deo teksta skriven je
Partial
proizvoljnim znakovima.
U upitu SQL 59., dat je primer primene funkcija maskiranja.
SQL 59. Primena funkcija maskiranja

ALTER TABLE KUPAC
ALTER COLUMN email ADD MASKED WITH(FUNCTION = 'email()')
ALTER TABLE KUPAC

ALTER COLUMN Datum ADD MASKED WITH(FUNCTION = 'default()')
ALTER TABLE KUPAC

ALTER COLUMN BrojPlatneKartice ADD MASKED WITH(FUNCTION = 'partial(0,"XXXX-
XXXX-",4)')
Naredbom ALTER potrebno je samo promeniti definicije kolone sa osetljivim podacima. Tada se podaci u
tim kolonama, podrazumevano (default) se maskiraju svakom korisniku koji nema administratorska
ovlašćenja i nije vlasnik (owner) baze podataka, SQL 60. Podatke koji takav korisnik vidi su dati u tabeli
28.
Tabela 28. Prikaz podataka koje "vidi" korisnik koji nema administratorska ovlašćenja
IdKupac nazivK email Datum BrojPlatneKartica
11111 Kupac 1 eXXX@XXXX.com 1900-01-01 XXXX-XXXX-XXXX-4444
22222 Kupac 2 eXXX@XXXX.com 1900-01-01 XXXX-XXXX-XXXX-5555
LITERATURA
1. Lazarević B.,i drugi: Baze podataka, Peto izdanje, FON, Beograd, 2010.
2. Most Widely Deployed and Used Database Engine , https://www.sqlite.org/mostdeployed.html,
[Pristup 01/2020].
3. FileMaker Pro Advanced , https://www.filemaker.com/products/filemaker-pro-advanced/, [Pristup
12/2019].
4. http://www.oracle.com/technetwork/database/features/plsql/index.html, [Pristup 02/2020].
5. https://www.ibm.com/products/db2-database/developers, [Pristup 03/2020].
6. What is PostgreSQL? , https://www.postgresql.org/docs/9.6/static/intro-whatis.html, [Pristup
03/2020].
7. Database Files and Filegroups, https://docs.microsoft.com/en-us/sql/relational-
databases/databases/database-files-and-filegroups?view=sql-server-ver15, [Pristup 02/2020].
8. What guarantees do Relational Databases (RDBMS) provide with respect to safe data storage? ,
https://www.quora.com/What-guarantees-do-Relational-Databases-RDBMS-provide-with-respect-
to-safe-data-storage, [Pristup 01/2020]
9. Customizing Transaction Isolation Level, https://docs.microsoft.com/en-us/previous-
versions/sql/sql-server-2008-r2/ms175909(v=sql.105)?redirectedfrom=MSDN, [Pristup 01/2020]
10. Snapshot Isolation in SQL Server, https://docs.microsoft.com/en-
us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server?redirectedfrom=MSDN
[Pristup 02/2020]
11. SET DEADLOCK_PRIORITY (Transact-SQL), https://docs.microsoft.com/en-us/sql/t-
sql/statements/set-deadlock-priority-transact-sql?view=sql-server-ver15 [Pristup 01/2020].
12. https://www.microsoft.com/en-us/sql-server/sql-server-2019, [Pristup 01/2020].
13. Microsoft® SQL Server® 2017 Express, https://www.microsoft.com/en-
us/download/details.aspx?id=55994, [Pristup 03/2020].
60/63
14. What is Data Modelling? Conceptual, Logical, & Physical Data Models,
https://www.guru99.com/data-modelling-conceptual-logical.html, [Pristup 02/2020].
15. Primary and Foreign Key Constraints, https://docs.microsoft.com/en-us/sql/relational-
databases/tables/primary-and-foreign-key-constraints?view=sql-server-ver15, [Pristup 01/2020].
16. CREATE TABLE (Transact-SQL) IDENTITY (Property), https://docs.microsoft.com/en-us/sql/t-
sql/statements/create-table-transact-sql-identity-property?view=sql-server-ver15 , [Pristup
12/2019].
17. A. Jorgensen, P. LeBlanc, J. Chinchilla, J. Segarra i A. Nelson, Local Temporary Tables,
Microsoft® SQL Server® 2012 BIBLE, Indianapolis, John Wiley & Sons, Inc., 2012, p. 406.
18. SQL Views, https://www.w3schools.com/sql/sql_view.asp, [Pristup 01/2019].
19. Importance of Statistics and How It Works in SQL Server – Part 1, By Arshad Ali,
https://www.databasejournal.com/features/mssql/importance-of-statistics-and-how-it-works-in-
sql-server-part-1.html, [Pristup 02/2019].
20. A Basic Guide to SQL Server Stored Procedures, https://www.sqlservertutorial.net/sql-server-
stored-procedures/basic-sql-server-stored-procedures/, [Pristup 03/2020].
21. Benefits of SCHEMABINDING in SQL Server,
https://www.mssqltips.com/sqlservertip/4673/benefits-of-schemabinding-in-sql-server/,[Pristup
03/2020].
22. CREATE TRIGGER (Transact-SQL), https://docs.microsoft.com/en-us/previous-versions/sql/sql-
server-2008-r2/ms189799(v=sql.105)?redirectedfrom=MSDN, [Pristup 03/2020].
23. Understanding the Difference between Owners and Schemas in SQL Server,
https://www.sqlteam.com/articles/understanding-the-difference-between-owners-and-schemas-in-
sql-server, [Pristup 03/2020].
24. How to configure password enforcement options for standard SQL Server logins,
https://www.mssqltips.com/sqlservertip/1909/how-to-configure-password-enforcement-options-
for-standard-sql-server-logins/, [Pristup 03/2020].
25. Create a Database User, https://docs.microsoft.com/en-us/sql/relational-
databases/security/authentication-access/create-a-database-user?view=sql-server-ver15, [Pristup
03/2020].
26. HASHBYTES (Transact-SQL), https://docs.microsoft.com/en-us/sql/t-sql/functions/hashbytes-
transact-sql?view=sql-server-ver15, [Pristup 04/2020].
27. SQL Server Encryption Implementation, https://www.dbamantra.com/sql-server-encryption-to-
secure-data/, [Pristup 04/2020].
28. Transparent Data Encryption (TDE), https://docs.microsoft.com/en-us/sql/relational-
databases/security/encryption/transparent-data-encryption?view=sql-server-ver15, [Pristup
04/2020].
29. Robert Sheldon, SQL Server Encryption: Always Encrypted, https://www.red-gate.com/simple-
talk/sql/database-administration/sql-server-encryption-always-encrypted/, [Pristup 04/2020].
30. "PROŠIRENI MODEL OBJEKTI-VEZE", Laboratorija za informacione sisteme, FON, 2000.
31. ANSI/X3/SPARC Study Group on Database Management Systems. “Interim report”, ACM
SIGMOD bulletin, 7(2), 1975.
32. M. Majstorović , Upitni jezik za izvođenje i pretraživanje složenih objekata nad proširenim
modelom objekti – veze, SYMOPIS ‘94, Kotor, 1994.
33. Marjanović Zoran, ORACLE relacioni SUBP, Beograd, 1990.
34. Alagić,S. Relacione baze podataka, Svjetlost, Sarajevo, 1984.
35. Fagin,R. ,A normal form for relational databases that is based on domains and keys, ACM ToDS,
6(3), 1981.
36. Garcia-Molina, H., J.Ullman, J.Widom: Database Systems – The Complete Book, PrenticeHall,
2002.
37. Kim,W. Introduction to Object-Oriented Databases, MIT Press, 1990.
38. Mastering SQL Server 2008, M. Lee, G. Bieker, Kompjuter biblioteka, Beograd, 2009.
39. Ullman,J.D. Principles of Database Systems, Computer Science Press, 1980.
61/63
40. Ullman,J.D. Database and Knowledge-Base Systems, vol. I, Computer Science Press, 1988.
41. Ullman,J.D. Database and Knowledge-Base Systems, vol. II, Computer Science Press, 1989.
42. Melton, J., SQL:1999 A Tutorial, 2000.
43. Krishna K., Overview of SQL:2003, 2003.
44. ANSI/ISO/IEC International Standard (IS), Database Language SQL – Part 2: Foundation
(SQL/Foundation), September 1999.
45. Eisenberg A., Melton J., SQL:1999, formerly known as SQL3, 1999.
46. https://web.math.pmf.unizg.hr/~mdoko/nastava/Baze/vjezbe-zadaci.html [Pristup 02/2020]
62/63
63/63

Serveri BP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Serveri BP

Uploaded by

Copyright:

Available Formats

1.

Tabela 1. Neke desktop baze podataka

Tabela 2. Primeri klijent-server baza podataka

SQL naredbe su svrstavane u četiri kategorije:

--promena kolone(polja) BrojIndeksa

--kreiranje indeksa po kolonama Opstina, Mesto

Naredbe za kontrolne (upravljačke) funkcije, DCL, omogućuju oporavak, konkurentnost, sigurnost i

3.1. Nedeljivost , doslednost, izolovanost, trajnost  ACID

Svaka baza podataka mora da ima sledeća svojstva:

Tabela 4. Deo sadržaja tabele Studenti

Tabela 5. Prikaz "prljavog" čitanja

Tabela 6. Prikaz neponavljajućeg čitanja

Tabela 7. Prikaz fantomskih zapisa

Slika 2. Potpuni zastoj

Za ilustraciju sa slike 2, dat je primer u tabeli 8.

Tabela 8. Demonstracija potpunog zastoja

UPDATE Smer SET naziv=HIP WHERE

DB11 DB12 DB13

server DB21 DB22 DB23

Slika 3. Serever: Instance i baze podataka

Slika 4. SQL Server instalacioni server

Slika 6. Instalacioni centar  Maintenance Slika 8. Instalacioni centar  Resources

Slika 9. Instalacioni centar  Opcije Slika 10. Priprema instalacionih fajlova

Slika 13. Svojstva TCP/IP protokola kreirane instance

Slika 14. Spajanje na SQL Server instancu

5.1. Konceptualni model podataka

Tabela 9. Karakteristike modela podataka

Student piše Master rad

Profesor predaje Predmet

Student sluša Predmet

Slika 15. Primeri entiteta i veza u konceptualnom modelu podataka

To će se pokazati na jednostavnom primeru datom u SQL  6.

SQL 6. Ilustracija formiranja konceptualnog modela.

Kupac ima Račun sadrži Stavke

Prodavnica Tip pripada

5.2. Logički model podataka

nazivK broj pdv

idProdavnica adresaP nazivT jm

Slika 17. Logički model podataka za primer SQL  6.

Kupac Racun Prodavnica

PK idKupac PK idRacun PK idProdavnica

Slika 19. Primer veze "1:1"

Slika 22. Primer veze "M:N"

Slika 23. Primer rekurzivne veze

Tabela 11. Sadržaj tabele odsek

Desktop Web Baze podataka

Slika 24. Nadređeni  podređeni odsek

Slika 25. Fizički model podataka za primer dat u SQL 6.

Tabela 12. Sadržaj tabele Kupac

Tabela 19. Rezultat Tabela 20. Rezultat

Tabela 21. Rezultat upita SQL  9

Tabela 24. Rezultat upita SQL  12

6.1. Tabele baze podataka, ključevi i indeksi

CREATE TABLE [dbo].[student](

Slika 27. Primarni ključ sa svojstvom identiteta.

SQL 17. SQL upit za dodeljivane svojstva koloni rednibroj.

Slika 28. Lista ključeva, indeksa i ograničenja.

SQL 18. SQL upit za uključivanje ograničenja tipa CHECK.

ALTER TABLE predmet WITH CHECK

Slika 29. Ograničenja tipa CHECK iz primera SQL 18.

6.2. Privremene tabele

SQL 19. SQL upit za formiranje privremene tabele.

Slika 30. Lokacija kreirane privremene tabele #TmpTabela.