MODELIRANJE, IMPLEMENTAIJA I ADMINISTRAIJA AZA … · MODELIRANJE, IMPLEMENTAIJA I ADMINISTRAIJA AZA PODATAKA Priručnik na kolegiju ‘Modeliranje i administracija baza podataka

MODELIRANJE, IMPLEMENTACIJA I ADMINISTRACIJA BAZA PODATAKA

Željko Kovačević, struč.spec.ing.techn.inf.

Zagreb, 2018


Željko Kovačević, struč.spec.ing.techn.inf. | Tehničko veleučilište u Zagrebu 2

PRIRUČNICI TEHNIČKOG VELEUČILIŠTA U ZAGREBU

MANUALIA POLYTECHNICI STUDIORUM ZAGRABIENSIS

Željko Kovačević

MODELIRANJE, IMPLEMENTACIJA I ADMINISTRACIJA BAZA PODATAKA Priručnik na kolegiju ‘Modeliranje i administracija baza podataka' koji se održava u sklopu nastave

na diplomskom stručnom studiju informatike Tehničkog veleučilišta u Zagrebu

Zagreb, 2018.



izdavač Tehničko veleučilište u Zagrebu

Vrbik 8, Zagreb

za izdavača mr. sc. Goran Malčić

autor Željko Kovačević, struč.spec.ing.techn.inf.

recenzenti Prof. dr. sc. Kornelije Rabuzin, FOI, Varaždin

Prof. dr. sc. Mladen Varga, EFZG, Zagreb

vrsta djela priručnik

Objavljivanje je odobrilo Stručno vijeće

Tehničkog veleučilišta u Zagrebu

odlukom broj: 2833-1/18 od 23. listopada 2018.

ISBN 978-953-7048-78-5





SADRŽAJ

1. Uvod u baze podataka ................................................................................................... 8

1.1. Što je baza podataka? ........................................................................................ 8

1.2. SQL (Structured Query Language) ................................................................... 10

1.3. ACID svojstva ................................................................................................... 12

1.4. Instalacija i konfiguracija SQL Servera ............................................................. 19

1.5. Kreiranje SQL Server baze podataka ............................................................... 26

2. Dizajn baze podataka .................................................................................................. 31

2.1. Konceptualni podatkovni model ........................................................................ 31

2.2. Logički podatkovni model .................................................................................. 34

2.3. Fizički podatkovni model ................................................................................... 36

2.4. Ostali podatkovni modeli ................................................................................... 41

2.5. Normalizacija baze podataka ............................................................................ 44

2.6. Analiza podataka SQL upitima .......................................................................... 48

3. Objekti baze podataka ................................................................................................. 52

3.1. Tablice .............................................................................................................. 52

3.2. Pogledi .............................................................................................................. 57

3.3. Grupirajući i negrupirajući indeksi ..................................................................... 61

3.4. Uskladištene procedure i funkcije ..................................................................... 68

3.5. DML i DDL okidači ............................................................................................ 74

3.6. Sekvence .......................................................................................................... 79

3.7. Sinonimi ............................................................................................................ 80

4. Organizacija i sigurnost ............................................................................................... 82

4.1. Sheme............................................................................................................... 82

4.2. Prijavni nalozi .................................................................................................... 85

4.3. Korisnički računi ................................................................................................ 89

4.4. Uloge ................................................................................................................ 92

4.5. Kriptografija u SQL Serveru .............................................................................. 98

4.6. Transparentna enkripcija podataka ................................................................. 103

4.7. Uvijek kriptirani podaci .................................................................................... 106

4.8. Dinamičko maskiranje podataka ..................................................................... 111

5. Održavanje i nadzor ................................................................................................... 114

5.1. Izrada rezervnih kopija .................................................................................... 114



5.2. Povrat rezervnih kopija ................................................................................... 119

5.3. SQL Server Agent ........................................................................................... 123

5.4. Izrada plana održavanja .................................................................................. 126

5.5. Elektronička pošta baze podataka .................................................................. 128

5.6. Kopiranje baze podataka ................................................................................ 131

5.7. SQL Server Profiler ......................................................................................... 135

5.8. SQL Server Audit ............................................................................................ 138

6. Tehnologije visoke dostupnosti .................................................................................. 143

6.1. Uvod u replikaciju ............................................................................................ 143

6.2. Replikacija snimke stanja ................................................................................ 147

6.3. Transakcijska replikacija ................................................................................. 148

6.4. Replikacija spajanjem ..................................................................................... 150

6.5. Replikacijski pretplatnici .................................................................................. 151

6.6. Otpremanje dnevnika transakcija .................................................................... 154

6.7. Zrcaljenje baze podataka ................................................................................ 156

6.8. AlwaysOn rješenja .......................................................................................... 158

Reference ...................................................................................................................... 161

Ključne riječi .................................................................................................................. 166



Uvodna riječ Pred vama je priručnik pisan za potrebe studenata specijalističkog diplomskog

stručnog studija informatike na Tehničkom veleučilištu u Zagrebu. Sadržaj priručnika

obuhvaća sadržaj kolegija "Modeliranje i administracija baza podataka", a namijenjen je

svima koji žele usvojiti dodatna znanja iz područja dizajna, modeliranja, implementacije te

administriranja relacijskih baza podataka i sustava.

Iako priručnik obuhvaća i najvažnije uvodne teme iz područja relacijskih baza podataka o

kojima su studenti već slušali tijekom dodiplomskog studija, ubrzo zatim usredotočuje se

na naprednije koncepte. Zbog toga je poželjno da čitatelj već ima neka osnovna znanja o

relacijskim bazama podataka i SQL jeziku kako bi se mogao čim prije i lakše usredotočiti

na daljnji sadržaj.

Za demonstraciju koncepata primarno se koristi Microsoft SQL Server RDBMS. Iako

postoji besplatna Express inačica SQL Servera, ona zbog svojih ograničenja neće biti

dovoljna za rad uz ovaj priručnik. Preporučuje se korištenje minimalno Standard inačice

SQL Servera, a za realizaciju najnaprednijih koncepata bit će vam potrebna Enterprise

inačica. Studenti mogu besplatno preuzeti svaku od inačica pristupom Imagine (MSDNAA)

programu.

Ovim putem također želim zahvaliti svima koji su svojim savjetima i primjedbama doprinijeli

kvaliteti ovog priručnika, a tu su bili mnogobrojni kolege iz struke, recenzenti te studenti

Tehničkog veleučilišta u Zagrebu.

Željko Kovačević, struč.spec.ing.techn.inf.

Tehničko veleučilište u Zagrebu, 2018.g.



1. Uvod u baze podataka

1.1. Što je baza podataka?

Baza podataka organizirana je te međusobno povezana skupina podataka. Zbog

toga vrlo često moguće je pronaći definiciju baze podataka i kao organiziranu skupinu

informacija. Općenito, podatak je neobrađena činjenica koja može postojati u bilo kojem

obliku (tekst, slika, zvuk itd.), a sama za sebe nema nikakvo značenje [1]. Primjerice,

podatak je broj 400. Ipak, niz povezanih podataka tvori informaciju. Tako, primjerice,

informacija je "Cipele koštaju 400 kn".

Informacija

Podatak 1 Podatak 2 Podatak 3 Podatak 4

Cipele koštaju 400 kn

Tablica 1.1.1. Informacija i podaci

Baza podataka sadrži tablice u kojima se nalaze zapisi čije su vrijednosti raspoređene po

stupcima. Također, u terminologiji nije neobično pronaći da baza podataka sadrži entitete

i atribute. Naime, na konceptualnoj razini postoje entiteti i atributi koji se kasnije na fizičkoj

razini pretvaraju u tablice i stupce.

Ovisno o bazi podataka, one još mogu sadržavati poglede (eng. views), okidače (eng.

triggers), uskladištene procedure (eng. stored procedures), funkcije itd. Neke od baza

podataka poput MS Accessa mogu sadržavati i izvještaje (eng. reports), obrasce (eng.

forms), module (eng. modules) itd. Mogućnosti pojedinih baza podataka definirane su

njihovom namjenom te predviđenim tipom korisnika, pa zato ne čudi što Microsoft Access

ima određene specifičnosti koje su predviđene za male i samostalne baze podataka i

aplikacije.

Po namjeni, baze podataka možemo podijeliti na desktop te klijent-server baze podataka.

Desktop baze podataka namijenjene su manje zahtjevnim korisnicima. Najčešće je riječ o

jednom ili nekoliko korisnika koji bazu koriste u osobne svrhe ili za manje projekte. Takve



baze podataka najčešće su besplatne pa su i iz tih razloga primamljive većem broju

korisnika. Međutim, tehnički su najčešće dosta ograničene i neprikladne za ozbiljniji posao.

Naziv Opis

Paradox

Korijene vuče još iz DOS operacijskog sustava, dok postoji i

posebna Paradox inačica za Windows OS. Paradox se aktivno

koristio u Borland razvojnim alatima Delphi i C++ Builder.

SQLite

Besplatna baza podataka. Jedna od najraširenijih u svijetu koja radi

na velikom broju uređaja i platformi, počevši od Android, iOS i

iPhone uređaja, MAC, PC, televizora, automobila itd. [2]

Microsoft Access

Isključivo za Windows OS. Podržava paralelni (konkurentni) rad do

maksimalno 255 korisnika, te omogućuje razvoj aplikacija i izvještaja

koji se spremaju u samoj bazi podataka. Microsoft Access aplikacija

se plaća, dok je sama baza podataka (datoteka) besplatna.

FileMaker Pro

Desktop baza podataka primarno namijenjena za iPad, iPhone i Mac

okruženja. Podržava i Windows okruženje te omogućuje integraciju

s Microsoft SQL Server, Oracle i MySQL bazom podataka. [3]

Tablica 1.1.2. Primjeri desktop baza podataka

Desktop baze podataka u su pravilu tek datoteke. Zbog toga su podložne nekim

ograničenjima operacijskog sustava poput ograničenog broja istovremenih konekcija, pa

time i ograničenom broju konkurentnih korisnika. Tako Microsoft Access baza podataka

dopušta maksimalno 5 konkurentnih konekcija ukoliko se nalazi na Window 7 Home OS-

u, 10 na Windows 7 Professional te maksimalnih 255 konkurentnih konekcija na Windows

Server OS-u.

Unatoč ovakvim i sličnim ograničenjima, desktop baze podataka i dalje su jako popularne

jer zadovoljavaju većinu potreba manje zahtjevnih korisnika. Međutim, u zahtjevnijim

okruženjima gdje je najčešće riječ o velikom broju korisnika, postoje i neki dodatni

čimbenici koje treba uzeti u obzir. Performanse, skalabilnost, dostupnost te sigurnost

podataka odjednom postaju izrazito bitni. Ove osobine nisu previše zastupljene u desktop

bazama podataka te ih se najčešće osigurava pomoću klijent-server baza podataka.



Naziv Opis

Microsoft SQL Server

Microsoftova relacijska baza podataka (RDBMS) namijenjena

korporativnim okruženjima. Podržava Transact-SQL, ekstenziju

SQL-a. Baza je dostupna u velikom broju izdanja od kojih je

Express izdanje potpuno besplatno.

Oracle

Vlasništvo korporacije Oracle. RDBMS namijenjen krajnje

zahtjevnim korisnicima te podržava PL/SQL proceduralni jezik.

Također je dostupan u besplatnom Express izdanju. [4]

DB2

Vlasništvo korporacije IBM. Uz standardni SQL jezik DB2

podržava PL/SQL te je također dostupan u besplatnoj Express-

C inačici. [5]

Postgre SQL

Besplatna (open source) objektno relacijska baza podataka

(ORDBMS). [6] Postgre SQL koristi PL/pgSQL jezik te u

potpunosti podržava ACID svojstva.

Tablica 1.1.3. Primjeri klijent-server baza podataka

U ovu skupinu baza podataka spadaju i mnoge druge poput MySQL, Sybase, Informix itd.

Ove baze podataka najčešće funkcioniraju kao mrežni servisi pomoću kojih se odvija

klijent-server komunikacija. Obično se jedan takav servis naziva instanca, a jedno server

računalo (poslužitelj) može odjednom imati više aktivnih instanci.

1.2. SQL (Structured Query Language)

SQL je jezik koji se koristi za komuniciranje s bazom podataka. Po Američkom

nacionalnom institutu za standarde (ANSI) ovaj jezik smatra se standardom za relacijske

baze podataka. Iako većina RDBMS sustava podrazumijevano koristi SQL, većina njih je

razvila i vlastite ekstenzije tom jeziku (T-SQL u SQL Serveru, PL/SQL u Oracleu itd.).

Unatoč tome, neke standardne naredbe poput SELECT, INSERT, UPDATE, DELETE,

CREATE i DROP prisutne su u svim RDBMS sustavima te omogućuju one najvažnije

operacije nad bazom podataka. [7]



U SQL serveru postoje četiri tipa SQL upita: DML (Data Manipulation Language), DDL

(Data Definition Language), DCL (Data Control Language) i TCL (Transaction Control

Language). Svakom od ovih tipova upita je svojstven različit set SQL naredbi.

DML upiti koriste se za dohvat, umetanje, izmjenu te brisanje podataka korištenjem SQL

naredbi SELECT, INSERT, UPDATE i DELETE.

Primjer 1.2.1 – DML upiti

-- dodaj odjel br. 2 insert into Odjel(naziv, id) values ('Novi odjel', 2) -- svi zaposlenici odjela br. 1 se prebacuju u odjel br. 2 update Zaposlenik set Odjel_id = 2 where Odjel_id = 1 -- dohvati odjel svakog od zaposlenik select Odjel_id from Zaposlenik -- izbriši odjel br. 1 delete from Odjel where id = 1

DDL upitima kreira se i mijenja struktura objekata (tablica, pogleda, funkcija itd.) u bazi

podataka, za što je potrebno koristiti SQL naredbe CREATE, ALTER i DROP.

Primjer 1.2.2 – DDL upiti

-- kreiraj tablicu Zaposlenik CREATE TABLE [dbo].[Zaposlenik]( [ID] [int] IDENTITY(1,1) NOT NULL, [Ime] [nvarchar](50) NULL, [Prezime] [nvarchar](50) NULL, [Odjel_id] [int] NULL, [Jmbg] [nvarchar](50) NULL, [Grad] [nvarchar](50) NULL ) -- Promjeni svojstva stupca Prezime ALTER TABLE Zaposlenik ALTER COLUMN Prezime NVARCHAR(75) NOT NULL; -- Izbriši stupac Jmbg ALTER TABLE Zaposlenik DROP COLUMN Jmbg;

DCL upitima definiraju se uloge i dozvole u bazi podataka što ih čini ključnim upitima za

kontrolu pristupa. U tu svrhu koriste se SQL naredbe GRANT i REVOKE.

Primjer 1.2.3 – DCL upiti

-- korisniku 1 dozvoli dohvat, dodavanje i izmjenu podataka u tablici Zaposlenik



GRANT SELECT, INSERT, UPDATE ON Zaposlenik TO korisnik1 -- korisniku 2 opozovi dozvolu brisanja podataka u tablici Zaposlenik REVOKE DELETE ON Zaposlenik FROM korisnik2

TCL upiti koriste se za upravljanje transakcijama. Njima je moguće uspješno potvrditi kraj

transakcije (COMMIT) ili napraviti njen opoziv (ROLLBACK).

Primjer 1.2.4 – TCL upiti

DECLARE @kodGreske INT BEGIN TRAN UPDATE Zaposlenik SET Grad = 'Zagreb' -- postavi grad Zagreb WHERE id = 1 -- ..prvi zaposlenik 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

Vrlo često tipovi SQL upita međusobno se kombiniraju. Primjerice, u jednoj transakciji koja

se kontrolira TCL upitima moguće je kreirati objekte poput tablica DDL upitima. Podatke u

tim tablicama možemo obraditi DML upitima te ovlasti i dozvole nad tim tablicama definirati

DCL upitima.

1.3. ACID svojstva

Da bi se neka baza podataka mogla smatrati profesionalnom, tj. "ozbiljnom" ona

mora imati ACID svojstva. Štoviše, korištenje baze podataka bez ovih svojstava krajnje je

rizično i nepreporučljivo u ozbiljnim (korporativnim) okruženjima zbog cijelog niza mogućih

poteškoća. ACID (Atomicy, Consistency, Isolation, Durability) svojstva jamče sigurno i

pouzdano izvršavanje transakcija, prilikom čega se čak i u slučaju greški baza podataka

neće dovesti u problematično stanje.



Svaka transakcija može se sastojati od nekoliko dijelova. Svojstvo atomarnosti (eng.

atomicy) osigurava da će se transakcija izvršiti u potpunosti (svi njeni dijelovi) ili da se neće

izvršiti uopće (niti jedan njen dio). Pri tome treba uzeti u obzir nestanke struje, moguće

kvarove na sklopovlju i druge nepredviđene situacije koje su također obuhvaćeni ovim

svojstvom.

Za primjer uzmimo plaćanje goriva kreditnom karticom na benzinskoj postaji. Transakcija

bi se u tom slučaju sastojala od minimalno dvaju dijelova: skidanje novca s računa klijenta

te uplate tog novca na račun benzinske postaje. Nezamislivo bi bilo da se izvršio samo

jedan dio te transakcije, odnosno da se, primjerice, samo skinuo novac s računa klijenta,

a da isti nije uplaćen na račun benzinske postaje.

Da bi se svojstvo atomarnosti realiziralo, baza podataka prati sva stanja unutar transakcije

i zapisuje ih u dnevnik. U slučaju da jedan dio transakcije nije moguće izvršiti, svi prethodno

uspješno izvršeni dijelovi transakcije će se također poništiti. [8] Baza podataka se u tom

slučaju vraća u izvorno stanje prije transakcije.

Niti jedna transakcija ne smije narušiti konzistentnost (eng. consistency) baze podataka.

Ovo svojstvo brine se o tome da svaki podatak koji se treba spremiti u bazu podataka

prethodno zadovoljava sva postojeća pravila i ograničena. U protivnom, transakcija se

odbacuje i baza se vraća u prethodno konzistentno stanje.

Za primjer možemo uzeti cjelobrojni stupac neke tablice koji je definiran kao primarni ključ.

Zbog svojstva konzistentnosti baza podataka vodi brigu o tome da se u taj stupac može

unijeti samo cijeli broj te da je on jedinstven u tom stupcu. Pravila konzistentnosti dodatno

se mogu proširiti i referencijalnim integritetom (eng. referential integrity) te pomoću okidača

(eng. triggers).

Jedno od najvažnijih ACID svojstava u više-klijentskom (konkurentnom) okruženju svojstvo

je izolacije (eng. isolation). Njime se definira da događaji i stanja u jednoj transakciji nisu

vidljivi u drugim transakcijama. Svaka transakcija izvršava se neovisno o drugim

transakcijama, a da bi se to realiziralo koriste se mehanizmi zaključavanja.



Za primjer možemo zamisliti situaciju gdje dvije osobe u isto vrijeme žele podići novac sa

zajedničkog bankovnog računa. Prva osoba vrši transakciju pomoću bankomata, a druga

je u poslovnici banke. Ona osoba koja prva podigne neki iznos automatski mora zaključati

transakciju drugoj osobi dok ona ponovno ne pročita zadnje stanje računa. U protivnom bi

se moglo dogoditi da se s računa podignulo više novaca nego što je bilo dostupno.

Zaključavanje se može realizirati kao optimistično i pesimistično. Optimistično se najčešće

koristi u situacijama kada klijent radi s kopijom podataka iz izvorne baze. Nakon obrade tih

podataka potrebno ih je nazad spremiti u izvornu bazu pa se u tom trenutku treba provjeriti

jesu li ti podaci u međuvremenu već mijenjani od strane nekog drugog klijenta.

Upravo to demonstrira prethodni primjer s bankom. Bankovne aplikacije u poslovnici i na

bankomatu učitale su kopije izvornih podataka, a nakon njihove izmjene pokušava ih se

spremiti nazad u izvornu bazu. Ukoliko je u međuvremenu došlo do izmjene izvornih

podataka od strane nekog drugog klijenta aktivira se zaključavanje.

Je li došlo do izmjene izvornih podataka u trenutku spremanja izmjena može se provjeriti

na nekoliko načina. Primjerice, provjeravanjem inačice izvornog zapisa prije i u trenutku

spremanja izmjena, uspoređivanjem vremenskih oznaka zapisa (eng. timestamp) itd.

Pesimistično zaključavanje puno je rigoroznije. Klijent cijelo vrijeme transakcije ima

isključivo pravo nad zapisom, a u tom periodu nitko ne može pristupiti zapisu. Ovakav

pristup zna biti problematičan zbog moguće nepažnje samih korisnika. Ukoliko korisnik

otvori zapis za uređivanje, a zatim ode na ručak cijelo to vrijeme zapis će biti nedostupan

ostalim korisnicima.

Razine izolacije Prljavo čitanje Neponavljajuće čitanje Fantomi

Nepotvrđeno čitanje Da Da Da

Potvrđeno čitanje - Da Da

Ponavljajuće čitanje - - Da

Serijalizacija - - -

Snimak - - -

Tablica 1.3.1. Razine izolacije u SQL Serveru [9]



Pri radu s transakcijama, SQL Server baza podataka podržava nekoliko različitih razina

izolacije (Tablica 1.3.1), a ovisno o odabranoj razini mogu se pojaviti određeni fenomeni

čitanja. Da bismo ih demonstrirali pretpostavimo da u bazi podataka postoji tablica

"Zaposlenik" sa sljedećim sadržajem.

ID Ime Prezime Odjel_id

1 Ante Antić 1

2 Pero Perić 1

3 Ivica Ivić 2

Tablica 1.3.2. Sadržaj tablice Zaposlenik

Prljavo čitanje (eng. dirty read) fenomen je koji se pojavljuje kada jedna transakcija može

pročitati nepotvrđena međustanja iz neke druge transakcije. Ukoliko je druga transakcija u

konačnici odbacila ta međustanja (eng. rollback) onda je prva transakcija dohvatila netočne

podatke.

Transakcija 1 Transakcija 2

select odjel_id from zaposlenik where ID=1 -- ispisuje 1

UPDATE zaposlenik SET odjel_id=2 WHERE ID=1; -- transakcija još uvijek nije završena!

select odjel_id from zaposlenik where ID=1 -- ispisuje 2!

ROLLBACK; --!

Primjer 1.3.1. Demonstracija prljavog čitanja

Prljavo čitanje događa se ukoliko izolacije uopće nema, tj. ukoliko se koristi razina izolacije

"nepotvrđeno čitanje" (eng. uncommitted read). U višeklijentskom okruženju ovaj fenomen

čitanja krajnje je nepoželjan i treba ga izbjeći korištenjem više razine izolacije.

Ukoliko se tijekom transakcije isti podaci čitaju dva ili više puta, a rezultat pri svakom od

čitanja nije isti, riječ je o "neponavljajućem čitanju" (eng. non-repeatable reads). Ovaj

fenomen čitanja može podsjećati na prethodni, no u ovom slučaju riječ je o čitanju već

potvrđenih podataka.




SELECT odjel_id FROM zaposlenik WHERE ID=1 -- ispisuje 1

UPDATE zaposlenik SET odjel_id=2 WHERE ID=1; COMMIT;

SELECT odjel_id FROM zaposlenik WHERE ID=1 -- podrazumijevano ispisuje 2 COMMIT;

Primjer 1.3.2. Demonstracija neponavljajućeg čitanja

Rezultat zadnjeg čitanja podataka u prvoj transakciji ovisi o korištenoj razini izolacije. SQL

Server podrazumijevano koristi razinu izolacije "potvrđeno čitanje" (eng. committed read).

[10] To znači da će se sada prilikom prvog čitanja dohvatiti vrijednost 1, a u drugom čitanju

vrijednost 2. Ukoliko se koristi viša razina izolacije poput ponavljajućeg čitanja (eng.

repeteable read), u oba čitanja pročitat će se vrijednost 1 jer će druga transakcija biti na

čekanju sve dok se u potpunosti ne završi prva transakcija.

Ako se tijekom transakcije izvrše dva ili više istih upita koji za rezultat imaju različitu skupinu

podataka, riječ je o pojavi fenomena "fantoma", tj. fantomskih zapisa (eng. phantom reads).


SELECT * FROM Zaposlenik WHERE odjel_id = 2

INSERT INTO Zaposlenik VALUES('Marko', 'Marić', 2) COMMIT;

SELECT * FROM Zaposlenik WHERE odjel_id = 2 -- podrazumijevano se vide "fantomski zapisi" COMMIT;

Primjer 1.3.3. Demonstracija fantomskih zapisa

I ovaj fenomen moguće je spriječiti korištenjem većih razina izolacije poput serijalizacije

(eng. serializable) te snimka (eng. snapshot). Ove dvije najveće razine izolacije daju isti

rezultat, ali na različite načine.

Serijalizacija kao metodu rada koristi zaključavanje korištenih resursa. Čim jedna

transakcija počne s radom, automatski zaključa korištene resurse ostalim transakcijama



koje su tada u stanju čekanja. Alternativno, snimak ne koristi zaključavanje već

verzioniranje pri čemu se koristi sistemska baza podataka tempdb. U nju se spremaju

inačice svih izmijenjenih podataka tijekom transakcija. Svaka transakcija zabilježena je

svojim jedinstvenim brojem koji je dodijeljen svakoj od inačica izmijenjenih podataka. [11]

Korištenjem snimka kao razine izolacije, konkurentne transakcije izvršavaju se odmah

korištenjem onih inačica podataka (snimke) koja je postojala na početku transakcije.

Upravo zato nije potrebno vršiti zaključavanje drugih transakcija kao u slučaju serijalizacije.

Da bi se snimak mogao koristiti kao razina izolacije prethodno je to potrebno omogućiti na

sljedeći način.

ALTER DATABASE ImeBazePodataka SET ALLOW_SNAPSHOT_ISOLATION ON

Pri odabiru razine izolacije treba paziti na moguće komplikacije pri međusobnom

zaključavanju transakcija, a jedna od takvih situacija potpuni je zastoj (eng. deadlock).

Slika 1.3.1. Potpuni zastoj

U prvoj operaciji 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 tada je na čekanju dok proces 2 ne završi.

Međutim, proces 2 nikada neće završiti jer ne može pristupiti resursu 1 kojeg je zauzeo

proces 1. Rezultat je potpuni zastoj jer su oba procesa stalno u stanju čekanja.



Situaciju sa slike također možemo demonstrirati sljedećim primjerom.


UPDATE Zaposlenik SET Odjel_id=5 WHERE ID=1 -- zauzet je resurs (tablica) 'zaposlenik'

UPDATE odjel SET sef_id=1 WHERE ID=1 -- zauzet je resurs (tablica) 'odjel'

UPDATE odjel SET sef_id = 2 WHERE ID = 1 -- Resurs 'odjel' je već zauzet! COMMIT

UPDATE Zaposlenik SET odjel_id=1 WHERE ID=1 -- Resurs 'zaposlenik' već je zauzet! COMMIT

Primjer 1.3.4. Demonstracija potpunog zastoja

SQL Server je u mogućnosti detektirati ovakve situacije pomoću dretve monitora potpunog

zastoja (eng. deadlock monitor thread) koja svakih 5 sekundi provjerava je li došlo do

potpunog zastoja. Kada se potpuni zastoj dogodi, intervali provjere smanjuju se čak do 100

ms sve dok se više ne budu detektirali potpuni zastoji. Nakon toga intervali provjere

ponovno se povećavaju na vrijeme do 5 sekundi. [12]

Kada se detektira potpuni zastoj SQL Server će odabrati žrtvu potpunog zastoja (eng.

deadlock victim) čiju transakciju će otkazati te time omogućiti drugom procesu da završi sa

svojom transakcijom.

Podrazumijevano, SQL Server odabire žrtvu po principu "najjeftinije" transakcije.

Primjerice, ukoliko transakcija prvog procesa obrađuje 2 zapisa, a transakcija drugog

procesa 5 zapisa, žrtva će biti prvi proces jer je izmjene njegove transakcije brže moguće

poništiti.

Korisnici također mogu utjecati na odabir žrtve korištenjem naredbe SET

DEADLOCK_PRIORITY gdje mogu za sesiju definirati prioritete LOW, NORMAL ili HIGH.

Također, prioritete je moguće definirati kao cjelobrojne vrijednosti od -10 do 10, a SQL

Server podrazumijevano koristi prioritet NORMAL. Ukoliko dvije sesije imaju isti prioritet i

njihove transakcije su jednako "skupe" žrtva se bira slučajnim odabirom.



Zadnje je ACID svojstvo trajnost (eng. durability). Njime se osigurava trajnu pospremljenost

podataka u bazu podataka nakon uspješnog završetka transakcije čak i u slučaju nestanka

struje, nepredviđenog rušenja sustava, kvara na sklopovlju ili nekih drugih greški.

1.4. Instalacija i konfiguracija SQL Servera

Postojeća instalacija SQL Servera preduvjet je za kreiranje baze podataka. SQL

Server donedavno je bilo moguće instalirati samo na Windows operacijskim sustavima,

dok je od inačice 2017 dostupan i na nekim Linux operacijskim sustavima poput Red Hat,

Ubuntu te SUSE [13]. Dostupan je u velikom broju izdanja, od čega je "Express" izdanje

potpuno besplatno.

Slika 1.4.1. Instance i baze podataka na serveru

Instalacija SQL Servera predstavlja instalaciju jedne njegove instance. Svaka instanca

može sadržavati više baza podataka, dok na jedno server računalno (poslužitelj) možemo

instalirati više instanci (Slika 1.4.1). Ukoliko se na jedno server računalo instalira više

instanci one se tada moraju razlikovati po imenu. U protivnom, moguće je izvršiti i

instalaciju samo jedne, podrazumijevane (eng. default) instance.

Svaka instanca na server računalu izvršava se kao servis koji može dopustiti mrežnu

klijent-server komunikaciju s bazom podataka. U tom slučaju svaka instanca ima zaseban

mrežni priključak (eng. port) pomoću kojeg klijenti mogu identificirati pojedinu instancu.



Slika 1.4.2. SQL Server instalacijski centar

Pokretanjem instalacije SQL Servera prikazuje se SQL Server instalacijski centar (Slika

1.4.2). U njemu je moguće pronaći mnogo dokumentacije o samom planiranju instalacije,

alate za pripremu te održavanje instalacije, dodatne mrežne resurse te napredne postavke

instalacije. Da bismo započeli s instalacijom nove SQL Server instance potrebno je

odabrati stavku "New SQL Server stand-alone installation or add features to an existing

installation".

Slika 1.4.3. Provjera preduvjeta instalacije

U prvom koraku provjeravaju se svi potrebni preduvjeti za uspješnu instalaciju SQL

Servera. Primjerice, korisnički račun pod kojim je pokrenuta instalacija mora imati

administratorske ovlasti i sva potrebna prava, računalo nije potrebno resetirati te ima



unaprijed instalirane sve potrebne servise i biblioteke. Ovisno o stanju provjere, instalaciju

neće nužno biti moguće nastaviti sve dok se ne zadovolje svi potrebni preduvjeti.

U drugom koraku instalacije potrebno je odabrati izdanje SQL Servera koje želite instalirati,

unijeti registracijski ključ te složiti se s uvjetima licence. Nakon toga nudi se mogućnost

izravnog preuzimanja i instaliranja zakrpi za SQL Server te instalacija instance može

započeti odabirom stavke "SQL Server Feature Installation".

Slika 1.4.4. Odabir svojstava instance

Prilikom instalacije nove instance SQL Servera obavezno je potrebno odabrati stavku

"Database Engine Services". Servisi poput SQL Server Database Engine, SQL Server

Agent, SQL Server Browser i drugih sastavni su dio svake instance te ih je uvijek nužno

instalirati.

U slučaju potrebe za replikacijom potrebno je označiti i stavku "SQL Server Replication".

Također, uvijek je poželjno instalirati i dokumentaciju te Management Studio, SQL Server

Profiler i ostale alate koje su sastavni dio stavke "Management Tools - Complete".



Slika 1.4.5. Konfiguracija instance

U narednom koraku instalacije potrebno je konfigurirati novu instancu. U ovom slučaju

možemo odabrati je li riječ o podrazumijevanoj neimenovanoj instanci (eng. default

instance) ili kreiramo imenovanu instancu. Za potrebe ovog primjera kreirat će se

imenovana instanca s imenom MOJAINSTANCA.

Slika 1.4.6. Konfiguracija servisa

Nakon provjere potrebnog slobodnog prostora na disku potrebno je konfigurirati i servise

koji će raditi s instancom. Za svakog od njih je poželjno automatsko pokretanje s

podizanjem operacijskog sustava kako ih ne bi trebalo naknadno "ručno" pokretati.

Servis SQL Server Agent koristi se za izvršavanje unaprijed zakazanih poslova (eng. jobs)

u SQL Serveru. Primjerice, ukoliko želite svaki petak u 23:00h automatski stvoriti



sigurnosnu kopiju baze podataka (eng. backup) to je moguće realizirati pomoću ovog

servisa. On podrazumijevano nije konfiguriran za automatsko pokretanje pa je na to

potrebno paziti prilikom konfiguracije servisa na Slici 1.4.6.

Servis SQL Server Database Engine predstavlja servis instance te bi se uvijek trebao

automatski pokretati ukoliko je potrebno da je ta instanca SQL Servera dostupna odmah

pri podizanju operacijskog sustava.

Servis SQL Server Browser služi kao posrednik između klijenta i instance. Da bi se klijent

mogao spojiti na instancu obično mora znati IP adresu server računala, naziv instance i

njen mrežni priključak (eng. port). Ukoliko se koristi ovaj servis klijent ne mora znati mrežni

priključak već samo IP adresu server računala i naziv instance, dok će broj mrežnog

priključka instance klijentu biti poslan od strane servisa.

Slika 1.4.7. Autentifikacija korisnika

Posljednje postavke prije instalacije odnose se na dopuštenu vrstu autentifikacije korisnika.

Moguće je izabrati između "Windows authentication mode" i "Mixed Mode". Prvi izbor

najčešće se koristi kada se želi dopustiti autentifikacija samo onih korisnika koji pripadaju

istoj domeni neke interne mreže. Ovaj je pristup sigurniji, ali stvara poteškoće pri pokušaju

autentifikacije korisnika iz drugih domena, mreža i operacijskih sustava.



Način autentifikacije "Mixed Mode" koristi se kada se želi omogućiti autentifikacija šireg

kruga korisnika koji nisu nužno u istoj domeni ili mreži (primjerice, internet). U instanci SQL

Servera za svakog takvog korisnika moguće je stvoriti korisnički račun i lozinku koje će taj

korisnik moći koristiti prilikom svoje autentifikacije. Ovaj način i dalje dozvoljava mogućnost

korištenja "Windows authentication mode" autentifikacije.

Ukoliko je odabran "Mixed Mode" potrebno je definirati lozinku za glavni administratorski

račun instance SQL Servera (sa), te navesti barem jedan administratorski korisnički račun

Windows korisnika koji će se moći koristiti prilikom autentifikacije (Slika 1.4.7).

Slika 1.4.8. Svojstva TCP/IP protokola instance

Nakon završetka instalacije SQL Server instance najčešće je potrebno provjeriti mogu li joj

klijenti pristupiti preko mreže te na taj način komunicirati s bazama podataka. Da bi to bilo

moguće potrebno je pokrenuti SQL Server Configuration Manager aplikaciju te u njoj

provjeriti je li omogućen TCP/IP protokol za željenu instancu (Slika 1.4.8).

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 dodijeljen različit mrežni priključak prilikom svakog njenog pokretanja (ovisno o

tome koji mrežni priključak je trenutno dostupan). Da bi klijent znao koji je trenutni mrežni

priključak dodijeljen instanci mora biti instaliran i pokrenut SQL Server Browser servis.



Ukoliko se uvijek želi koristiti isti mrežni priključak tada nema potrebe za SQL Server

Browser servisom te se koristi statički mrežni priključak kao u primjeru na Slici 1.4.8. Tada

ujedno nema potrebe niti za propuštanjem UDP mrežnog priključka 1434 kroz vatrozid

(eng. firewall) kako bi ovaj servis mogao komunicirati s klijentima, što dodatno doprinosi

sigurnosnoj komponenti servera.

Statički mrežni priključak često je korišten upravo zbog definiranja pravila u vatrozidu.

Uvijek je u vatrozidu lakše definirati pravilo za jedan mrežni priključak nego koristiti

dinamičke mrežne priključke gdje se prilikom svakog pokretanja SQL Server instance

može dodijeliti različiti mrežni priključak za kojeg opet treba definirati pravilo u vatrozidu.

Također treba napomenuti da se prilikom instalacije podrazumijevane instance SQL

Servera za njenu mrežnu komunikaciju podrazumijevano 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.

Slika 1.4.9. Spajanje na SQL Server instancu

Nakon uspješne konfiguracije SQL Server instance moguće joj je pristupiti prethodno

instaliranim SQL Server Management Studio (SSMS) alatom (Slika 1.4.9). Pomoću njega

može se jednostavno spajati na više različitih instanci odjednom, kreirati i upravljati

bazama podataka, administrirati korisnike itd., a sam alat u potpunosti je besplatan.



Isti princip spajanja kao na Slici 1.4.9 koristi se i u drugim klijent aplikacijama gdje se za

autentifikaciju i autorizaciju korisnika također mora znati IP adresa server računala,

korisničko ime i lozinka, naziv instance te broj mrežnog priključka ukoliko se ne koristi SQL

Server Browser servis.

1.5. Kreiranje SQL Server baze podataka

SQL Server baza podataka smještena je unutar instance SQL Servera, a nastaje

na osnovu predloška sistemske "model" baze podataka. Moguće ju je kreirati izvršavanjem

SQL (DDL) upita ili pomoću SQL Server Management Studio (SSMS) alata. Čak i u slučaju

korištenja SSMS alata, u konačnici opet se kreiraju odgovarajući SQL upiti čijim

izvršavanjem se kreira specificirana baza podataka.

Slika 1.5.1. Kreiranje baze podataka – opće informacije

Upotrebom SSMS alata, baza podataka kreira se na način da se desnim klikom na stavku

"Databases" u prikazanom izborniku odabere stavka "New database…". Tada se pojavljuje

dijalog kao na Slici 1.5.1.

U dijelu s općim informacijama potrebno je definirati ime baze podataka. Na osnovu imena

za svaku bazu podataka kreiraju se minimalno dvije datoteke. Prva datoteka

<ime_baze_podataka>.MDF sadrži podatke i objekte (tablice, pogledi, uskladištene

procedure, indeksi itd.) a druga <ime_baze_podataka>.LDF predstavlja dnevnik

transakcija. [14]



MDF datoteka je primarna datoteka koja podrazumijevano sadrži sistemske tablice te sve

ostale objekte koji nisu dodijeljeni nekoj drugoj datotečnoj grupi. Naime, kada je riječ o

velikim i zahtjevnim sustavima, za podatke i objekte nije pogodno koristiti samo jednu

(primarnu) datoteku na disku. Da bi se poboljšalo performanse pri čitanju i pisanju bolje je

uz primarnu datoteku koristiti i više sekundarnih (.NDF) datoteka. Pojedini objekti iz

primarne datoteke tako bi se mogli podijeliti kroz više sekundarnih datoteka, a te datoteke

ili njihove grupe razmjestiti kroz više različitih diskova (Slika 1.5.2).

Slika 1.5.2. Datoteke, datotečne grupe i razmještaj po diskovima

Svim datotekama možemo definirati inicijalnu veličinu, način rasta te maksimalnu veličinu,

a svaka baza podataka uvijek sadrži barem jednu (podrazumijevanu) datotečnu grupu

naziva "PRIMARY". U njoj se nalazi primarna MDF datoteka, a mogu se nalaziti i druge

sekundarne datoteke. Svaki objekt baze podataka može biti dodijeljen jednoj datotečnoj

skupini, a ovisno o raspoloživom mjestu može se nalaziti u samo jednoj datoteci ili biti

rasprostranjen kroz više datoteka te datotečne skupine.

Datoteke i datotečne skupine korisne su i u administraciji baza podataka jer omogućuju

kreiranje ili povrat rezervne kopije samo odabranih datoteka i/ili datotečnih skupina.

Datotečne skupine moguće je kreirati odabirom stavke "Filegroups" na Slici 1.5.1.

Dnevnik transakcija bilježi podatke o izvršavanju svake transakcije te se koristi za potrebe

oporavka baze podataka u slučaju greški koje bi mogle uzrokovati njeno nekonzistentno

stanje (nestanak struje, kvar na sklopovlju itd.). Jedna baza podataka može imati više

datoteka dnevnika transakcija, a one nikada nisu dio neke specifične datotečne skupine.

Podrazumijevano, datoteke dnevnika transakcija uvijek se nalaze na istoj lokaciji kao i

podatkovne datoteke, no to ne mora uvijek biti slučaj, kao što je prikazano slikom 1.5.2.



Koncept vlasništva (eng. ownership) najčešće se koristio u prijašnjim inačicama SQL

Servera kada još uvijek nisu postojale sheme u bazama podataka. Vlasnik (eng. owner)

korisnik je koji ima nepovratne ovlasti nad pojedinim objektom ili bazom podataka, a takvog

korisnika nije moguće izbrisati sve dok sva svoja vlasništva ne prebaci na drugog korisnika.

Danas se umjesto takvog pristupa objekti najčešće grupiraju po shemama što olakšava

administraciju korisnika i dozvola. Zbog toga nije potrebno definirati vlasnika baze

podataka te polje Owner sa Slike 1.5.1 može imati vrijednost "<default>".

Slika 1.5.3. Neke od ostalih postavki baze podataka

Od ostalih postavki pri kreiranju baze podataka (Slika 1.5.3) možemo spomenuti

"Collation", kojom se definiraju pravila pri sortiranju podataka s različitim tipovima znakova.

Podrazumijevanu vrijednost "<default>" nije potrebno mijenjati jer SQL Server podržava

Unicode tipove znakova, a time i nelatinične znakove. [15]

Postavka "Recovery model" izravno utječe na rad dnevnika transakcija te način izrade i

povrata rezervnih kopija. Podržani modeli oporavka baze podataka su "full"

(podrazumijevano), "bulk-logged" i "simple".



Kao preporuka i najčešće korišteni model oporavka koristi se potpuni (eng. full) model. U

dnevniku transakcija spremaju se podaci o svakoj izvršenoj transakciji, pa ga je moguće

koristiti pri povratu baze podataka u slučaju greške te u slučaju povrata u neku prijašnju

točku u vremenu. Nedostatak su korištenja ovog modela velike datoteke dnevnika

transakcija u zahtjevnim sustavima s velikim brojem transakcija.

Model oporavka "bulk-logged" najčešće se koristi tek privremeno u slučajevima izvršavanja

velikog broja transakcija odjednom. Kako bismo izbjegli spremanje svake od tih transakcija

u dnevnik transakcija (potpuni model oporavka) te time jako povećali njegovu veličinu i

ugrozili performanse privremeno je moguće koristiti "bulk-logged" model. Nakon

izvršavanja, te transakcije su u dnevniku transakcija zabilježene u minimalnom obliku (eng.

minimal logging) [16] nakon čega se opet vraćamo na potpuni model oporavka.

Upotrebom jednostavnog (eng. simple) modela oporavka iz datoteka dnevnika transakcija

automatski se brišu sve završene transakcije. Zbog toga dnevnik transakcija ne može više

biti korišten za povrat baze podataka. Ovakav model oporavka rijetko je u upotrebi i

najčešće se koristi u testnim okruženjima gdje nije nužno potrebno zabilježiti svaku

transakciju.

Pri kreiranju baze podataka moguće je definirati i mnoge druge postavke (automatsko

sažimanje veličine datoteka, omogućavanje enkripcije baze podataka itd.) a SSMS alat će

u konačnici generirati odgovarajuće SQL upite (naredbe) kojim će se kreirati takva baza

podataka (primjer 1.5.1).

Primjer 1.5.1 – SQL upiti generirati SSMS alatom

CREATE DATABASE [Testna] CONTAINMENT = NONE ON PRIMARY ( NAME = N'Testna', FILENAME = N'C:\Microsoft SQL Server\MSSQL11.MOJAINSTANCA\MSSQL\DATA\Testna.mdf' , SIZE = 5120KB , FILEGROWTH = 1024KB ) LOG ON ( NAME = N'Testna_log', FILENAME = N'C:\Microsoft SQL Server\MSSQL11.MOJAINSTANCA\MSSQL\DATA\Testna_log.ldf' , SIZE = 2048KB , FILEGROWTH = 10%) GO ALTER DATABASE [Testna] SET COMPATIBILITY_LEVEL = 110 ALTER DATABASE [Testna] SET ANSI_NULL_DEFAULT OFF ALTER DATABASE [Testna] SET ANSI_NULLS OFF ALTER DATABASE [Testna] SET ANSI_PADDING OFF ALTER DATABASE [Testna] SET ANSI_WARNINGS OFF



ALTER DATABASE [Testna] SET ARITHABORT OFF ALTER DATABASE [Testna] SET AUTO_CLOSE OFF ALTER DATABASE [Testna] SET AUTO_CREATE_STATISTICS ON ALTER DATABASE [Testna] SET AUTO_SHRINK OFF ALTER DATABASE [Testna] SET AUTO_UPDATE_STATISTICS ON ALTER DATABASE [Testna] SET CURSOR_CLOSE_ON_COMMIT OFF ALTER DATABASE [Testna] SET CURSOR_DEFAULT GLOBAL ALTER DATABASE [Testna] SET CONCAT_NULL_YIELDS_NULL OFF ALTER DATABASE [Testna] SET NUMERIC_ROUNDABORT OFF ALTER DATABASE [Testna] SET QUOTED_IDENTIFIER OFF ALTER DATABASE [Testna] SET RECURSIVE_TRIGGERS OFF ALTER DATABASE [Testna] SET DISABLE_BROKER ALTER DATABASE [Testna] SET AUTO_UPDATE_STATISTICS_ASYNC OFF ALTER DATABASE [Testna] SET DATE_CORRELATION_OPTIMIZATION OFF ALTER DATABASE [Testna] SET PARAMETERIZATION SIMPLE ALTER DATABASE [Testna] SET READ_COMMITTED_SNAPSHOT OFF ALTER DATABASE [Testna] SET READ_WRITE ALTER DATABASE [Testna] SET RECOVERY FULL ALTER DATABASE [Testna] SET MULTI_USER ALTER DATABASE [Testna] SET PAGE_VERIFY CHECKSUM ALTER DATABASE [Testna] SET TARGET_RECOVERY_TIME = 0 SECONDS USE [Testna] GO IF NOT EXISTS (SELECT name FROM sys.filegroups WHERE is_default=1 AND name = N'PRIMARY') ALTER DATABASE [Testna] MODIFY FILEGROUP [PRIMARY] DEFAULT GO

Osim zbog automatskog generiranja potrebnih SQL naredbi, korištenje SSMS alata pri

kreiranju baze podataka prikladno je i zbog cijelog niza postavki koje bi se inače morale

pamtiti i ručno podešavati. Sve njih je sada na jednostavan način moguće naknadno

pročitati i izmijeniti.



2. Dizajn baze podataka

2.1. Konceptualni podatkovni model

Da bi se uspješno oblikovala baza podataka potrebno je u što boljoj mjeri razumjeti

potrebe korisnika. U tu svrhu najčešće se odmah pristupa analizi poslovnih procesa gdje

se pokušavaju identificirati svi akteri, njihove međusobne veze te podaci koji se u tim

procesima razmjenjuju. U konačnici kreira se konceptualni ER (eng. entity relationship)

podatkovni model koji na najvišem nivou opisuje buduću bazu podataka.

Konceptualni podatkovni model razvija se u suradnji s poslovnim analitičarom ili samim

korisnikom te za njegov razvoj i razumijevanje nije potrebno nikakvo tehničko predznanje.

Preciznost ovog modela od ključne je važnosti za razvoj baze podataka jer se na osnovu

njega razvijaju logički i fizički podatkovni modeli.

Značajka Model

Konceptualni Logički Fizički

Imena entiteta X X

Veze među entitetima X X

Atributi X

Primarni ključevi X X

Strani ključevi X X

Imena tablica X

Imena stupaca X

Tipovi podataka X

Tablica 2.1.1. Značajke podatkovnih modela [17]

Svaki od podatkovnih modela ima određene značajke (Tablica 2.1.1), a u konceptualnom

podatkovnom modelu koriste se entiteti i njihove međusobne veze. Entitet je osnovni

element za prikupljanje informacija. Njime se opisuju ljudi, događaji, mjesta itd., a svaki

entitet opisuje se atributima. Primjerice, entitet je Student, a njegovi atributi mogu biti ime,

prezime i JMBAG.



Atributi mogu biti ključni (eng. key) i neključni (eng. non-key). Ključnim atributima

jednoznačno se opisuju entiteti dok se neključni atributi mogu ponavljati unutar više

različitih entiteta. U prethodnom primjeru ključni atribut bio bi JMBAG jer to je jedinstven

podatak za svakog studenta, dok bi ime i prezime bili neključni atributi jer više studenata

može imati isto ime i/ili prezime.

Slika 2.1.1. Primjeri entiteta i veza u konceptualnom podatkovnom modelu

Kada se definira veza između dva entiteta njihov se odnos promatra iz oba smjera. Gleda

se odnos prvog entiteta prema drugom, a zatim drugog entiteta prema prvom, pri čemu se

polazišni entitet uvijek gleda u jedini.

Primjerice, iz Slike 2.1.1 možemo pročitati da jedan student piše samo jedan završni rad.

Isto vrijedi i u drugom smjeru, tj. jedan završni rad piše samo jedan student. Također, jedan

profesor predaje nula ili više (0…*) kolegija, te jedan kolegij predaje samo jedan profesor.

I na kraju, jedan student pohađa nula ili više kolegija, dok jedan kolegij pohađa nula ili više

studenata.

Modeli u ovakvom obliku lako su čitljivi i razumljivi. Štoviše, konceptualni podatkovni model

vrlo često se smatra "zajedničkim jezikom" korisnika (klijenata) i arhitekata baza podataka.

To demonstrira i sljedeći primjer.



Zadatak 2.1.1

Bračni par Ivica i Ana žele pratiti svoje kupovne navike. S obzirom na različite cijene u

pojedinim dućanima, žele znati koje artikle najčešće kupuju u kojem dućanu te na koje

tipove artikala troše najviše novaca. Također, žele znati u kojem dućanu najčešće kupuju

te koliko novaca potroše u pojedinom dućanu u nekom vremenskom razdoblju. Sukladno

ovim zahtjevima potrebno je dizajnirati i kreirati odgovarajuću bazu podataka.

U prvom koraku potrebno je identificirati sve ključne entitete, a to su:

▪ Kupac (ime i prezime)

▪ Dućan (naziv i adresa)

▪ Račun (datum i vrijeme, ukupni iznos)

▪ Artikl (naziv i cijena)

▪ Stavka (artikl, količina i njegova ukupna cijena)

▪ Tip artikla (naziv)

Tek sada razvija se konceptualni podatkovni model na način da se identificiraju i povežu

entiteti koji su u izravnoj vezi. Primjerice, entiteti kupac i račun u izravnoj su vezi jer jedan

kupac može posjedovati više računa. Također, entitet račun u izravnoj je vezi i s entitetima

dućan i stavka jer svaki račun izdan je u nekom dućanu te može imati jednu ili više stavki.

Na sličan način treba identificirati i sve ostale entitete koji su u izravnoj vezi.

Slika 2.1.2. Konceptualni podatkovni model za Zadatak 2.1.1

Ispravnost konceptualnog podatkovnog modela provjerava se na način da se provjeravaju

odnosi između pojedinih entiteta u oba smjera. Primjerice, iz modela na Slici 2.1.2 može

se pročitati da jedan artikl (primjerice, Milka čokolada) može pripadati samo jednom tipu

artikala (primjerice, slatkiši), dok tom tipu artikla može pripadati nula ili više artikala (Milka



čokolada, Moto keksi, Kiki bomboni itd.). Međutim, možda baš kod vašeg trenutnog

korisnika treba vrijediti drukčije, odnosno da jedan artikl (Milka čokolada) može pripadati

većem broju tipova artikala (slatkiši, čokolade, slastice itd.) te bi u tom slučaju trebalo

korigirati model na Slici 2.1.2.

Iz ovog primjera može se zaključiti da veze među entitetima i njihovi odnosi ovise isključivo

o poslovnom procesu i željama korisnika. Zbog toga se isti konceptualni podatkovni model

ne može izravno replicirati za potrebe drugih korisnika bez prethodne provjere i korekcije

ovakvih detalja.

2.2. Logički podatkovni model

Nakon završenog razvoja konceptualnog podatkovnog modela pristupa se logičkom

podatkovnom modeliranju. Njime se u potpunosti, pomoću atributa, opisuju svi postojeći

entiteti te potrebe za podacima. Logički podatkovni model tek je proširenje konceptualnog

podatkovnog modela, a koriste ga administratori i arhitekti baza podataka pri razvoju

fizičkog podatkovnog modela.

Slika 2.2.1. Logički podatkovni model za Zadatak 2.1.1

Osim entiteta sada su vidljivi i njihovi atributi, s time da su ključni atributi podcrtani. Ukoliko

entiteti imaju veći broj atributa onda ih je praktičnije predstaviti u obliku dijagrama klasa ili

na sljedeći način:



Slika 2.2.2. Primjer logičkog podatkovnog modela [18]

Logički podatkovni model također se razvija na način da nije ovisan o nikakvoj specifičnoj

platformi ili RDBMS sustavu, a njegovi atributi mogu biti opisani i generičkim (općim)

tipovima podataka, ograničenjima i ključevima.

U primjeru na Slici 2.2.2 ključni atributi imaju oznaku PK (eng. primary key), dok strani

imaju oznaku FK (eng. foreign key). Oznaka PF koristi se za atribute koji su ujedno primarni

i strani, kao primjerice u entitetima Parts_by_Vehicles i Vehicles_by_Customer.

U narednoj fazi fizičkog podatkovnog modeliranja ključni atributi postat će primarni ključevi,

tj. stupci pomoću kojih se jednoznačno određuje svaki zapis (redak) u tablici. Korištenjem

primarnog ključa nameće se ograničenje (eng. constraint) da ne mogu postojati dva ili više

zapisa s istom vrijednošću u tom stupcu. Također, vrijednost unutar takvog stupca je

obavezna, dakle stupac ne može biti prazan ili imati NULL vrijednost.

Na Slici 2.2.2 ključni atribut entiteta Vehicles je atribut Vehicle_Serial_Number. Time je

definirano da unutar buduće tablice Vehicles svaki zapis mora imati vrijednost u tom stupcu



(serijski broj) te da je ta vrijednost različita za svaki zapis u toj tablici (ne postoje dva ili više

vozila sa istim serijskim brojem).

Primarni ključ može biti definiran i kao kombinacija dvaju ili više atributa (stupaca), a tada

je riječ o složenom (kompozitnom) primarnom ključu. Svaki od stupaca složenog primarnog

ključa mora imati vrijednost, a u tablici se ne može pojaviti ista kombinacija vrijednosti u

tim stupcima.

Na Slici 2.2.2 ne može se dogoditi da se u tablici Vehicles_by_Customer dva ili više puta

nalazi jedno vozilo s istim vlasnikom. Međutim, moguće su kombinacije da jedan vlasnik

ima više različitih vozila te da je jedno vozilo imalo više različitih vlasnika.

2.3. Fizički podatkovni model

Zadnja faza podatkovnog modeliranja predstavlja kreiranje fizičkog podatkovnog

modela. Njega se može implementirati u relacijskoj ili NoSQL bazi podataka, XML datoteci

itd. Entiteti iz logičkog podatkovnog modela zamjenjuju se tablicama, a njihovi atributi

stupcima koji su sada, ovisno o odabranom načinu implementacije i sustavu, opisani

konkretnim, a ne generičkim tipovima podataka.

Veze među tablicama u fizičkom podatkovnom modelu određuju se na osnovi veza među

entitetima u konceptualnom i logičkom podatkovnom modelu. Veze mogu biti "jedan prema

jedan", "jedan prema više", "više prema više" te rekurzivna veza.

Slika 2.3.1. Primjer veze "jedan prema jedan"

Tip veze "jedan prema jedan" realizira se pomoću dviju tablica s istim primarnim

ključevima. Najčešće se koristi pri radu s tablicama koje imaju veliki broj stupaca pa se



ovim tipom veze, radi preglednosti, pojedine grupe stupaca jedne tablice izdvajaju u više

zasebnih tablica.

Ukoliko je riječ o tablicama s manjim brojem stupaca, veza "jedan prema jedan" najčešće

se izbjegava te se umjesto njenog korištenja stupci tih tablica spajaju u jednu tablicu.

Primjerice, umjesto veze na Slici 2.3.1 u tablicu Student mogu se prebaciti stupci Mentor,

NazivTeme i DatumPredaje, čime nestaje potreba za tablicom ZavrsniRad.

Slika 2.3.2. Primjer veze "jedan prema više"

Tip veze "jedan prema više" realizira se korištenjem primarnog ključa tablice roditelja (eng.

parent, master) te stranog ključa tablice djeteta (eng. child, detail). Ovom vezom definira

se da za jedan zapis iz tablice roditelja može postojati više zapisa u tablici djeteta.

Upotrebom stranog ključa zapisi iz tablice djeteta referenciraju se na odgovarajuće zapise

u tablici roditelja.

U primjeru na Slici 2.3.2 može se vidjeti veza "jedan prema više" između tablica Ducan i

Racun, a iz te veze možemo zaključiti da u jednom dućanu može biti izdano više računa.

Svaki zapis u tablici Racun sadrži stupac sa stranim ključem SifraDucana pomoću kojega

se jednoznačno može identificirati dućan u kojemu je izdan pojedini račun.

Slika 2.3.3. Referencijalni integritet veze



Općenito, tip veze "jedan prema više" uvijek treba biti sinkroniziran na način da za svaku

vrijednost stranog ključa u tablici djeteta postoji ista takva vrijednost primarnog ključa u

tablici roditelja. To pravilo ujedno definira pojam referencijalnog integriteta, a ono se

osigurava svojstvom veze "Enforce Foreign Key Constraint" kao na Slici 2.3.3. [19]

Za očuvanje referencijalnog integriteta u SQL Serveru mogu se definirati i pravila pri

izmjeni i brisanju već postojećih podataka (Slika 2.3.3). Njima se definira što se događa sa

zapisima i vrijednostima stranih ključeva u tablici djeteta ukoliko se promijeni ili izbriše

pojedina vrijednost primarnog ključa u tablici roditelja. U SQL Serveru možemo koristiti

pravila "No Action", "Cascade", "Set NULL" i "Set Default".

Ducan Racun

Sifra (PK) Naziv Broj (PK) SifraDucana (FK)

1 Walmart 1 1

2 Starbucks 2 2

3 Subway 3 2

Primjer 2.3.1. Sadržaji tablica Ducan i Racun

Pravilo "No Action" definira da se neće dogoditi nikakva sinkronizacija (izmjena) u tablici

djeteta nakon promjene ili brisanja vrijednosti primarnog ključa u tablici roditelja. Upravo

zbog toga upotreba ovog pravila pri radu s podacima najčešće rezultira greškama zbog

pokušaja kršenja referencijalnog integriteta.

Ukoliko bi tablice Ducan i Racun imale sadržaj kao u Primjeru 2.3.1 pokušaj brisanja

dućana sa šifrom 1 ili 2 iz tablice Ducan ne bi uspio. To bi bilo kršenje referencijalnog

integriteta jer bi onda u tablici Racun imali reference na dućane koji više ne postoje. Isto bi

se dogodilo i u slučaju pokušaja izmjene šifre tih dućana jer bi i u tom slučaju u tablici

Racun postojale reference na nepostojeće dućane.

Da je korišteno pravilo "Cascade" prilikom brisanja nekog dućana iz tablice Ducan izbrisali

bi se i svi računi iz tablice Racun koji su bili referencirani na taj dućan. Također, ukoliko

bismo promijenili šifru dućana Walmart u broj 100 automatski bi se u tablici Racun

promijenile vrijednosti svih stranih ključeva u vrijednost 100.



Da bismo koristili pravilo "Set Default" prethodno bismo trebali dodijeliti podrazumijevanu

(eng. default) vrijednost stupcu koji predstavlja strani ključ tablice djeteta. U slučaju

brisanja zapisa iz tablice roditelja, prethodno referencirane vrijednosti stranog ključa tablice

djeteta promijenile bi se u podrazumijevanu vrijednost. Ta podrazumijevana vrijednost

mora postojati u primarnom ključu tablice roditelja jer će se inače dogoditi greška zbog

pokušaja kršenja referencijalnog integriteta. Zbog toga je u slučaju brisanja umjesto pravila

"Set Default" bolje koristiti pravilo "Set NULL" koje će vrijednost stranog ključa postaviti na

NULL vrijednost, čime se neće narušiti referencijalni integritet.

Slično vrijedi i prilikom izmjene vrijednosti primarnog ključa u tablici roditelja. Tada bi sve

referencirane vrijednosti stranog ključa tablice djeteta, ovisno o korištenom pravilu ("Set

Default" ili "Set NULL") bile promijenjene u podrazumijevanu ili NULL vrijednost.

Slika 2.3.4. Primjer veze "više prema više"

Sljedeći je tip veze "više prema više", a njom definiramo da za jedan zapis iz prve tablice

može postojati više zapisa iz druge tablice. Međutim, i za jedan zapis iz druge tablice može

postojati više zapisa iz prve tablice. Da bi se ovakva veza mogla realizirati potrebno je

koristiti međutablicu sa složenim primarnim ključem.

Primarni ključ međutablice kreira se kao kombinacija primarnih ključeva onih dviju tablica

koje su u vezi "više prema više". Zatim, kreiraju se dvije veze "jedan prema više", tj. između

prve tablice i međutablice te druge tablice i međutablice. U tim vezama dijelovi složenog

primarnog ključa međutablice imaju ulogu stranih ključeva.

U primjeru na Slici 2.3.4 prikazana je veza "više prema više" između tablica Student i

Kolegij. Korištenjem međutablice Polaznik ta veza realizirana je kao kombinacija dviju veza

"jedan prema više", odnosno jedan student može iti pohađati više kolegija te jedan kolegij

može pohađati više studenata.



Slika 2.3.5. Primjer rekurzivne veze

Veza "jedan prema više" koristiti se i prilikom realizacije rekurzivne veze, a u takvoj vezi

primarni i strani ključ nalaze se u istoj tablici. U primjeru rekurzivne veze na Slici 2.3.5

jedan odjel može imati jedan nadređeni odjel, a istovremeno i više podređenih odjela.

ID IDNadredeniOdjel Naziv

1 NULL IT odjel

2 1 Odjel programiranja

3 1 Odjel dizajna

4 2 Odjel web aplikacija

5 2 Odjel desktop aplikacija

Primjer 2.3.2. Sadržaj tablice Odjel

Ukoliko pretpostavimo da se u tablici Odjel sa Slike 2.3.5 nalaze zapisi kao u Primjeru

2.3.2, tada odnose među pojedinim odjelima možemo prikazati sljedećom slikom.

Slika 2.3.6. Odnosi među pojedinim odjelima iz Primjera 2.3.2



Rekurzivna veza koristi se u mnogo situacija. Primjerice, njom je jednostavno opisati

strukturu internetskog foruma (svaki forum može imati više podforuma, a ujedno može i

sam biti podforum). Također, ukoliko bismo vodili evidenciju o zaposlenicima, jedan

zaposlenik može biti šef drugim zaposlenicima, a opet on sam također imati svog šefa itd.

Slika 2.3.7. Implementacija fizičkog podatkovnog modela u SQL Serveru

Sukladno svim prethodno opisanim značajkama fizičkog podatkovnog modela te na osnovi

već postojećeg logičkog podatkovnog modela iz Slike 2.2.1, napokon možemo prikazati

njegovu implementaciju u SQL Serveru (Slika 2.3.7). Tek nakon ove faze modeliranja i

izrade tablica možemo pristupiti unosu i izmjeni podataka razvojem zasebne desktop ili

web klijent aplikacije ili korištenjem SSMS alata.

2.4. Ostali podatkovni modeli

Osim prethodno opisanih, postoje i mnogi drugi podatkovni modeli. Tijekom 60-ih i

70-ih godina učestalo su korišteni hijerarhijski i mrežni modeli, a jedan od najpopularnijih

relacijski je model baze podataka kojeg je početkom 70-ih osmislio Edgar F. Codd.



Slika 2.4.1. Primjer hijerarhijskog modela

Hijerarhijski model razvijen je i korišten u IBM-u početkom 60-ih godina. Zbog strukture u

obliku stabla (Slika 2.4.1) omogućen je brz rad s podacima, pa se ovakve baze i dalje

koriste u aplikacijama koje zahtijevaju velike performanse.

Model počinje od korijenskog čvora, a on kao i svaki čvor roditelja može imati više djece.

Svaki čvor dijete može imati samo jednog roditelja, pa se tom strukturom realizira odnos

"jedan prema više". Glavni nedostatak hijerarhijskog modela nemogućnost je realizacije

odnosa "više prema više" pa se u tom slučaju koristio mrežni podatkovni model.

Slika 2.4.2. Primjer mrežnog modela



Mrežni model baze podataka proširenje je hijerarhijskog modela gdje jedan čvor djeteta

može imati više roditelja (Slika 2.4.2). Osim što omogućava realizaciju odnosa "više prema

više" te kompleksniju i fleksibilniju strukturu i dalje nudi vrlo brzu obradu podataka. Ipak,

pojavom relacijskog modela koji uskoro postaje standardom, oba prethodna modela gube

na popularnosti te se danas puno rjeđe koriste.

Slika 2.4.3. Primjer relacijskog modela [20]

Relacijski model zasniva se na relacijama (tablicama) koje se sastoje od redaka i stupaca.

Svaki stupac predstavlja atribut entiteta, a jedan ili kombinacija više atributa može tvoriti

primarni, tj. strani ključ. Svaki redak predstavlja n-torku koja sadrži konkretne podatke o

instanci entiteta (Slika 2.4.3), a sadržaj svake pojedine n-torke (primjerka) mora se

razlikovati. Tvrtka Oracle među prvima je implementirala relacijski model, a danas je on

prisutan i u sustavima poput SQL Server, MySQL, PostgreSQL itd.

Osim spomenutih, postoje i sljedeći modeli:

▪ Objektno-orijentirani model

▪ Objektno-relacijski model

▪ Ravni (eng. flat) model



▪ Višedimenzionalni model

▪ Polustrukturirani model

▪ Asocijativni model

▪ Graf model (NoSQL)

▪ Dokument model (NoSQL)

▪ Itd.

Ovisno o potrebama korisnika, vrši se odabir najprikladnijeg podatkovnog modela, a na

osnovu njega i odabir konačne baze podataka.

2.5. Normalizacija baze podataka

Edgar Frank Codd prvi je predstavio koncept normalizacije kao proces organizacije

stupaca (atributa) i tablica (relacija) relacijske baze podataka s ciljem pojednostavljenja

dizajna, smanjenja redundantnosti i poboljšanja integriteta podataka. [21]

JMBAG Student UlicaBr Grad BrPoste Spol KolegijSf KolegijIme Profesor IspitDatum Ocjena 112233 Ante Antić Vrbik 2 Zagreb 10000 M 12345 Automatika Nikola Antić 12.2.2014 3 112233 Ante Antić Vrbik 2 Zagreb 10000 M 23456 Fizika Pero Perić 13.2.2014 1 112233 Ante Antić Vrbik 2 Zagreb 10000 M 23456 Fizika Pero Perić 14.7.2014 2 223344 Ivana Marić Brig 8 Zadar 23000 Ž 12345 Automatika Nikola Antić 12.2.2014 2 223344 Ivana Marić Brig 8 Zadar 23000 Ž 23456 Fizika Pero Perić 14.7.2014 2

Primjer 2.5.1. Nenormalizirani oblik tablice IspitniRok

Nenormalizirani oblik podataka najčešće se dobije kao rezultat upita koji spaja više tablica.

Takav oblik podataka, kao u Primjeru 2.5.1, nije prikladan u standardnoj obradi zbog

učestalih ponavljanja podataka, bespotrebnog rasipanja diskovnog prostora, anomalija pri

operacijama dodavanja, izmjene i brisanja podataka itd.

Primjerice, dodavanje novog zapisa u tablicu iz Primjera 2.5.1 može biti problematično

ukoliko nemamo vrijednosti za sve stupce, a pogotovo one koji su primarni ključevi. Ukoliko

bi stupci JMBAG, KolegijSf i IspitDatum tvorili složeni primarni ključ (student može na

odabrani datum samo jednom pristupiti ispitu iz istog kolegija) onda bi pokušaj unošenja

samo novog grada i njegovog poštanskog broja bio neuspješan jer bismo time narušili

integritet baze podataka.



Izmjena već postojećih zapisa također je problematična. Ukoliko bismo htjeli izmijeniti

adresu studenta Ante Antića, tu izmjenu bismo morali napraviti u svim zapisima te tablice

gdje god se spominje taj student. To pak negativno utječe na performanse. S druge strane,

izmjenom adrese samo u jednom zapisu narušili bismo konzistentnost baze podataka.

Slično bi se dogodilo i prilikom brisanja podataka. Ukoliko bi profesor Pero Perić dao otkaz

to bi moglo uzrokovati potpuni nestanak svih zapisa u kojima se spominje taj profesor.

Time bismo izgubili i pojedine vrijednosti još dvaju stupaca – KolegijSf i KolegijIme jer bi

se brisanjem tog profesora izbrisali i svi podaci o kolegijima koje je on predavao.

S obzirom da navedene anomalije mogu narušiti integritet i konzistentnost baze podataka,

ugroziti performanse te uzrokovati neželjeni gubitak podataka svakako je preporučljivo

provesti proces normalizacije.

Normalizacija se provodi slijedeći pravila definirana normalnim formama. Postoji šest

normalnih formi, a smatra se dovoljnim provesti prve tri normalne forme kako bi se tablica

smatrala normaliziranom.

Prva normalna forma (1NF) zadovoljena je ukoliko su ispunjeni sljedeći kriteriji:

▪ Ponavljajuće skupine podataka razdvojene su u zasebnim tablicama.

▪ Složeni stupci podijeljeni su u više jednostavnih stupaca.

▪ Svaka tablica ima primarni ključ.

JMBAG Student UlicaBr Grad BrPoste Spol KolegijSf KolegijIme Profesor IspitDatum Ocjena 112233 Ante Antić Vrbik 2 Zagreb 10000 M 12345 Automatika Nikola Antić 12.2.2014 3 112233 Ante Antić Vrbik 2 Zagreb 10000 M 23456 Fizika Pero Perić 13.2.2014 1 112233 Ante Antić Vrbik 2 Zagreb 10000 M 23456 Fizika Pero Perić 14.7.2014 2 223344 Ivana Marić Brig 8 Zadar 23000 Ž 12345 Automatika Nikola Antić 12.2.2014 2 223344 Ivana Marić Brig 8 Zadar 23000 Ž 23456 Fizika Pero Perić 14.7.2014 2

Primjer 2.5.2. Ponavljajuće skupine podataka tablice IspitniRok

Iz nenormaliziranog oblika tablice mogu se prepoznati dvije skupine ponavljajućih

podataka. Prva opisuje studenta, a druga održani ispit. Stoga ćemo umjesto početne

tablice sada imati dvije nove tablice: Student i Ispit.



JMBAG Ime Prezime Ulica KucniBroj Grad PostanskiBroj Spol 112233 Ante Antić Vrbik 42 Zagreb 10000 M 223344 Ivana Marić Brig 12 Zadar 23000 Ž

Primjer 2.5.3. 1NF – tablica Student

Tablica Student sadržavala je složene stupce Student i UlicaBr. Prvi stupac podijeljen je u

dva stupca Ime i Prezime, a drugi u stupce Ulica i KucniBroj, čime smo izbjegli prisunost

više od jednog podatka u stupcu. I konačno, primarni je ključ ove tablice stupac JMBAG

jer pomoću njega moguće je o jednoznačno odrediti svaki zapis u tablici.

JMBAG KolegijSf KolegijIme ProfesorIme ProfesorPrezime IspitDatum Ocjena 112233 12345 Automatika Nikola Antić 12.2.2014 3 112233 23456 Fizika Pero Perić 13.2.2014 1 112233 23456 Fizika Pero Perić 14.7.2014 2 223344 12345 Automatika Nikola Antić 12.2.2014 2 223344 23456 Fizika Pero Perić 14.7.2014 2

Primjer 2.5.4. 1NF – tablica Ispit

Slično se dogodilo i u tablici Ispit koja umjesto složenog stupca Profesor sada sadrži stupce

ProfesorIme i ProfesorPrezime. Primarni ključ sastoji se od triju stupca JMBAG, KolegijSf

i IspitDatum jer jedino kombinacijom tih triju stupaca jednoznačno možemo odrediti svaki

zapis u toj tablici.

Tablicama Student i Ispit zadovoljena je prva normalna forma (1NF). Da bismo zadovoljiti

drugu normalnu formu (2FN) potrebno je ispuniti sljedeće kriterije:

▪ Tablica već zadovoljava 1NF.

▪ Svi stupci koji nisu primarni ključevi ovise o svim dijelovima primarnog ključa.

Također, postoji pravilo da je tablica u 2NF ukoliko je već u 1NF te je njen primarni ključ

definiran samo jednim stupcem. [22] Upravo je to slučaj s tablicom Student iz Primjera

2.5.3, pa je potrebno samo provjeriti tablicu Ispit iz Primjera 2.5.4.

U tablici Ispit potrebno je provjeriti stupce KolegijIme, ProfesorIme, ProfesorPrezime i

Ocjena te utvrditi koji od njih nisu u potpunosti ovisni o svim dijelovima primarnog ključa.



Stupac KolegijIme jedini je takav stupac jer je ovisan samo o stupcu KolegijSf, a ne i o

ostalim dijelovima primarnog ključa. Štoviše, stupac KolegijIme suvišan je upravo zbog

stupca KolegijSf pa ga je potrebno izbaciti iz tablice Ispit te smjestiti u novu tablicu.

JMBAG KolegijSf ProfesorIme ProfesorPrezime IspitDatum Ocjena

112233 12345 Nikola Antić 12.2.2014 3

112233 23456 Pero Perić 13.2.2014 1

112233 23456 Pero Perić 14.7.2014 2 Sifra Ime

223344 12345 Nikola Antić 12.2.2014 2 12345 Automatika

223344 23456 Pero Perić 14.7.2014 2 23456 Fizika

Primjer 2.5.5. 2NF - tablice Ispit i Kolegij

Konačno, da bismo provjerili zadovoljava li tablica treću normalnu formu (3NF) potrebno je

ispuniti sljedeće kriterije:

▪ Tablica već zadovoljava 2NF.

▪ Svi stupci koji nisu primarni ključevi ne smiju ovisiti o bilo kojim drugim stupcima

koji nisu primarni ključevi.

U tablici Student iz primjera 2.5.3, koja ujedno zadovoljava i 2NF, može se primijetiti

međusobnu ovisnost neključnih stupaca Grad i PostanskiBroj. Ukoliko se promijeni naziv

grada, to će utjecati i na promjenu poštanskog broja i obrnuto. Zbog toga je suvišne stupce

potrebno izbaciti iz tablice Student i prebaciti u novu tablicu.

JMBAG Ime Prezime Ulica KucniBroj PostanskiBroj Spol PostanskiBroj Naziv

112233 Ante Antić Vrbik 42 10000 M 10000 Zagreb

223344 Ivana Marić Brig 12 23000 Ž 23000 Zadar

Primjer 2.5.6. 3NF - tablice Student i Grad

Tablica Student sada sadrži samo stupac PostanskiBroj koji ima ulogu stranog ključa u

vezi "jedan prema više" s tablicom Grad.

Tablica Ispit iz Primjera 2.5.5 također ima dva neključna stupca koji su međusobno ovisni,

a to su stupci ProfesorIme i ProfesorPrezime. Ukoliko se promijeni ime profesora koji

održava ispit, to vjerojatno znači i promjenu prezimena (i obrnuto) jer je riječ o sasvim



drugom profesoru. Zbog toga je ta dva stupca potrebno izbaciti iz tablice Ispit i smjestiti ih

u novu tablicu, po uzoru na Primjer 2.5.6.

JMBAG KolegijSf ProfesorID IspitDatum Ocjena

112233 12345 1 12.2.2014 3

112233 23456 2 13.2.2014 1

112233 23456 2 14.7.2014 2 ID Ime Prezime

223344 12345 1 12.2.2014 2 1 Nikola Antić

223344 23456 2 14.7.2014 2 2 Pero Perić

Primjer 2.5.7. 3NF - tablice Ispit i Profesor

Općenito se smatra da nije potrebno normalizirati dalje od 3NF jer su sada uklonjene sve

anomalije pri dodavanju, izmjeni i brisanju podataka.

Slika 2.5.1. Tablice i veze nakon provođenja 3NF

Konačni rezultat normalizacije nakon provođenja 3NF prikazan je slikom 2.5.1. Baza

podataka u ovom obliku osigurava bolji integritet podataka uz minimalnu redundanciju.

Ipak, veći broj tablica u konačnici uzrokuje slabije performanse baze podataka zbog

potrebe spajanja tablica pri izvršavanju SQL upita.

2.6. Analiza podataka SQL upitima

Dizajn baze podataka izrazito je bitan prilikom analize podataka jer izravno utječe

na način na koji se dohvaćaju podaci. Štoviše, loš dizajn najčešće će uzrokovati sporo

izvršavanje upita zbog nepotrebnog spajanja jedne ili više tablica kako bi se došlo do



željenog rezultata. Za primjer analize podataka u nastavku ćemo koristiti fizički model

podataka sa Slike 2.3.7.

Zadatak 2.6.1

Koliko računa ima koji kupac? Za svakog kupca potrebno je u zasebnom retku vratiti ime

kupca i ukupan broj njegovih računa.

SELECT Kupac.ime, COUNT(*) FROM Racun INNER JOIN Kupac ON Kupac.id = Racun.idkupac GROUP BY Kupac.ime

Popis svih računa nalazi se u tablici Racun. Zato se prilikom analize računa podaci čitaju

upravo iz te tablice (izraz "FROM Racun"). Međutim, u toj tablici ne postoji ime kupca već

tek strani ključ pomoću kojeg se ime kupca može doznati. Upravo zbog toga bilo je

potrebno spojiti (INNER JOIN) tablice Racun i Kupac pomoću primarnog ključa tablice

Kupac (Kupac.id) i stranog ključa u tablici Racun (Racun.idkupac).

Funkcija COUNT jedna je od agregatnih funkcija, a njima se vrše upiti nad skupinama

zapisa. Konkretno, COUNT (*) vraća ukupan broj svih zapisa u tablici. Budući da se uz tu

agregatnu funkciju ispisuje i ime kupca (Kupac.ime) onda je krajnji rezultat potrebno

grupirati (GROUP BY) po imenu kupca kako bi agregatna funkcija COUNT za svakog od

njih mogla vratiti njegov broj zapisa (računa).

Zadatak 2.6.2

Koliko novaca potroši svaki od kupaca pri svakom posjetu dućanu? Za svakog kupca

potrebno je u zasebnom retku vratiti ime kupca i prosječno potrošenu količinu novca.

SELECT Kupac.ime, AVG(Racun.ukupnitrosak) from Racun INNER JOIN Kupac on Kupac.id = Racun.idkupac GROUP BY Kupac.ime

Alternativa Zadatku 2.6.1: umjesto brojanja svih računa iz tablice Racun (COUNT *) koristi

se agregatna funkcija AVG kako bi se vratila prosječna vrijednost ukupnog troška računa

po pojedinom kupcu. U SQL Serveru moguće je koristiti i neke druge agregatne funkcije

poput MIN, MAX, SUM itd.



Zadatak 2.6.3

Vratite prvih 5 najčešće posjećenih dućana. Za svaki dućan potrebno je vratiti njegov naziv

i ukupan broj posjeta, a rezultat sortirati po učestalosti posjeta (od dućana s najviše posjeta

prema dućanima s manje posjeta).

SELECT TOP 5 Ducan.naziv, COUNT(*) AS BrojPosjeta FROM Racun INNER JOIN Ducan on Ducan.sifra = Racun.sifraducana GROUP BY Ducan.naziv ORDER BY BrojPosjeta DESC

Da bismo vratili samo prvih 5 zapisa koristi se izraz "TOP 5", a da bismo odredili kojih točno

5 zapisa rezultat upita potrebno je sortirati (ORDER BY) po broju posjeta. Izrazom ORDER

BY sortiraju se stupci, pa je stoga potrebno imenovati stupac koji se dobije kao rezultat

agregatne funkcije COUNT izrazom "AS BrojPosjeta". Također, dodatkom ključne riječi

DESC podaci se sortiraju od najveće vrijednosti prema manjoj.

Zadatak 2.6.4

Za svakog kupca potrebno je vratiti broj posjeta po pojedinom dućanu. U rezultatu se treba

nalaziti ime kupca, naziv dućana te broj posjeta. Također, rezultat je potrebno sortirati po

učestalosti posjeta (od dućana s najviše posjeta prema dućanima s manje posjeta).

SELECT Kupac.ime, Ducan.naziv AS Ducan, count(*) AS BrojPosjeta FROM Racun INNER JOIN Ducan on Ducan.sifra = Racun.sifraducana INNER JOIN Kupac on Kupac.id = Racun.idkupac GROUP BY Kupac.ime, Ducan.naziv ORDER BY BrojPosjeta DESC

Prikazani zadatak blago je proširenje Zadatka 2.6.3. Razlika je tek u tome što se rezultat

grupira po dva podatka (Kupac.ime i Ducan.naziv), zbog čega je potrebno napraviti dva

spajanja (INNER JOIN) kako bi se dohvatili potrebni podaci.

Zadatak 2.6.5

Koji artikl je najviše puta kupljen u 2015. godini? Potrebno je vratiti naziv artikla i količinu.

SELECT TOP 1 Artikl.naziv AS Artikl, COUNT(Artikl.sifra) AS Kolicina FROM Racun INNER JOIN Stavka ON Stavka.sifraracuna = Racun.sifra INNER JOIN Artikl ON Artikl.sifra = Stavka.sifraartikla WHERE Racun.datum BETWEEN '1.1.2015' AND '12.31.2015' GROUP BY Artikl.naziv ORDER BY Kolicina DESC



Da bismo došli do traženog rezultata potrebno je izvršiti pregled svih računa (FROM

Racun). Pregledom modela sa Slike 2.3.7 može se primijetiti da svaki račun sadrži stavke,

a svaka stavka pojedini artikl pa je istim tim redoslijedom potrebno povezati (INNER JOIN)

tablice Racun, Stavka i Artikl. Konačni rezultat filtrira se izrazom WHERE te se sortira po

učestalosti kupljenog artikla. Konačno, izrazom "TOP 1" vraćaju se podaci samo za

najčešće kupljeni artikl.

Zadatak 2.6.6

Potrebno je vratiti prvih 5 tipova artikala koji su se najrjeđe kupovali u 2015. godini. U

rezultatu je za svaki od tipova artikala potrebno vratiti naziv i kupljenu količinu.

SELECT TOP 5 Tipartikla.naziv, COUNT(Tipartikla.id) AS Kolicina FROM Racun INNER JOIN Stavka ON Stavka.sifraRacuna = Racun.sifra INNER JOIN Artikl ON Artikl.sifra = Stavka.sifraArtikla INNER JOIN Tipartikla ON TipArtikla.id = Artikl.idtip WHERE Racun.datum BETWEEN '1.1.2015' AND '12.31.2015' GROUP BY Tipartikla.naziv ORDER BY Kolicina

Vrlo slično kao i u Zadatku 2.6.5, analizom podataka iz tablice Racun potrebno je doći do

podataka u tablici TipArtikla. Pregledom modela sa Slike 2.3.7 može se primijetiti da je u

tu svrhu potrebno spajanje (INNER JOIN) tablica Racun->Stavka->Artikl->TipArtikla po

njihovim primarnim i stranim ključevima.



3. Objekti baze podataka

3.1. Tablice

Komponente baze podataka koje se koriste za spremanje i manipulaciju podacima

nazivamo objektima baze podataka. Većina baza podataka sadrži nekoliko zajedničkih

tipova objekata poput tablica, pogleda (eng. views), indeksa itd. Međutim, neke baze

podataka mogu sadržavati i sebi svojstvene tipove objekata poput izvještaja (eng. reports),

obrazaca (eng. forms) i makroa, kao što je slučaj u Microsoft Access bazi podataka.

Tablice su tipovi objekata koji služe za spremanje podataka. Sastoje se od redaka i

stupaca, gdje jedan redak sadrži jedan zapis. Dijelovi pojedinog zapisa identificirani su

stupcima koji imaju svoje ime i tip, a dodatno mogu biti opisani ograničenjima (eng.

constraints) i svojstvima poput maksimalne duljine, podrazumijevane vrijednosti itd.

Tablice se kreiraju izvršavanjem DDL SQL upita, kao u Primjeru 1.2.2.

Slika 3.1.1. Kreiranje tablice korištenjem SSMS alata

SQL Server Management Studio (SSMS) također nudi mogućnost jednostavnog kreiranja

i uređivanja tablica bilo korištenjem interaktivnog grafičkog sučelja (Slika 3.1.1) ili izravnim

izvršavanjem SQL upita. U konačnici, i pristup preko interaktivnog grafičkog sučelja

rezultirat će pozadinskim generiranjem i izvršavanjem odgovarajućih SQL upita, kao u

sljedećem primjeru.

Primjer 3.1.1 – Generirani SQL upit za kreiranje tablice 'Osoba'

CREATE TABLE [dbo].[Osoba]( [OIB] [nvarchar](50) NOT NULL, [Ime] [nvarchar](50) NULL, [Prezime] [nvarchar](50) NULL,



[Starost] [int] NULL, CONSTRAINT [PK_Osoba] PRIMARY KEY CLUSTERED ( [OIB] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

U generiranom SQL upitu može se vidjeti struktura tablice Osoba. Osim popisa stupaca s

pripadajućim tipovima, svojstvima i ograničenjima, također se vide ključevi i indeksi te svi

drugi dodatni objekti i svojstva tablice Osoba. SQL upit iz Primjera 3.1.1 može se generirati

za svaku postojeću tablicu na način da se u SSMS alatu desnim klikom na tablicu odabere

stavka "Script Table as / CREATE To".

Pri kreiranju tablice uvijek treba paziti na postojanost primarnog ključa. Iako nije nužno da

tablica mora imati primarni ključ njegovo nepostojanje može narušiti konzistentnost baze

podataka (pojava duplikata) te vrlo često može ukazivati na pogrešan dizajn i biti uzrokom

loših performansi pri pretraživanju i spajanju s drugim tablicama.

Ukoliko u tablici nema stupca ili kombinacije stupaca koji bi mogli biti primarni ključevi,

najčešće se dodaje novi cjelobrojni stupac (ID) sa svojstvom identiteta. Njegova vrijednost

automatski se određuje (povećava) svaki puta kada se dodaje novi zapis. Upravo zato on

je idealan kandidat za primarni ključ u takvim tablicama.

Slika 3.1.2. Primarni ključ sa svojstvom identiteta

Kreiranje navedenog primarnog ključa u SSMS alatu prikazano je Slikom 3.1.2. Cjelobrojni

stupac ID ima svojstvo identiteta ("Identity Specification = Yes"). Vrijednost ovog stupca za

prvi zapis u tablici definirana je izrazom „Identity Seed", a za svaki sljedeći zapis njegova

vrijednost uvećava se za broj definiran izrazom "Identity Increment". Tako će u ovom

slučaju vrijednost stupca ID započeti od 1, te će se za svaki sljedeći zapis uvećavati za 1.

Jednako tako mogli smo izvršiti i sljedeći SQL upit.



ALTER TABLE NazivTablice ADD ID INT IDENTITY(1,1) PRIMARY KEY

Ako bismo htjeli da vrijednost stupca ID započinje od 2, a uvećava se za 5 izvršili bismo

sljedeći SQL upit.

ALTER TABLE NazivTablice ADD ID INT IDENTITY(2, 5) PRIMARY KEY

Svaka tablica može imati samo jedan stupac sa svojstvom identiteta. Čak i kada umetanje

novog zapisa u tablicu ne uspije ili se poništi (eng. rollback), dodijeljena vrijednost tom

stupcu smatra se iskorištenom te se za sljedeći zapis generira i dodjeljuje nova vrijednost.

Takav tijek događaja može uzrokovati "rupe" u nizu dodijeljenih vrijednosti, a one se mogu

dogoditi i zbog rušenja baze podataka ili resetiranja servera ukoliko je on u predmemoriju

(eng. cache) unaprijed već generirao i spremio neke vrijednosti za taj stupac. [23]

U svrhu očuvanja konzistentnosti i integriteta baze podataka u svakoj tablici moguće je

definirati pravila za podatke. Ona se implementiraju kao ograničenja (eng. constraints) nad

pojedinim stupcima tablice. Ograničenja su objekti baze podataka koji mogu biti tipa

PRIMARY KEY, FOREIGN KEY, NOT NULL, UNIQUE, DEFAULT, INDEX i CHECK.

Neka od ovih ograničenja međusobno se podrazumijevaju. Primjerice, ograničenje

PRIMARY KEY kombinacija je ograničenja NOT NULL i UNIQUE. Međutim, i stupac koji

nije primarni ključ može imati ta ograničenja. Ukoliko pak želimo napraviti UNIQUE

ograničenje nad kombinacijom dvaju ili više stupaca, to je moguće na više načina;

ALTER TABLE Osoba ADD CONSTRAINT UQ_JedinstvenoImePrezime UNIQUE(Ime, Prezime);

ili

CREATE UNIQUE INDEX IX_JedinstvenoImePrezime ON Osoba(Ime, Prezime);

U SSMS alatu oba ograničenja moguće je pronaći u popisima ključeva i indeksa tablice.

Ako je potrebno provjeravati intervale vrijednosti i karakteristike podataka (primjerice,

minimalna i maksimalna duljina) u pojedinim stupcima koristi se ograničenje tipa CHECK.



Primjer 3.1.2 – CHECK ograničenja

-- Starost mora biti u intervalu [0, 100] ALTER TABLE [dbo].[Osoba] WITH CHECK ADD CONSTRAINT [CK_OsobaGodine] CHECK (([Starost]>=(0) AND [STAROST]<=(100))) -- Ime mora imati više od 0 i manje od 50 znakova ALTER TABLE [dbo].[Osoba] WITH CHECK ADD CONSTRAINT [CK_OsobaIme] CHECK ((len([Ime])>(0) AND len([Ime])<(50)))

Ograničenja tipa CHECK vidljiva su u SSMS alatu u popisu ograničenja tablice.

SQL Server može sadržavati i privremene tablice, a one se dijele na lokalne i globalne.

Privremene tablice smještene su u sistemskoj Tempdb bazi podataka i automatski se

uništavaju nakon što više nisu potrebne.

Primjer 3.1.3 – Kreiranje lokalne privremene tablice

CREATE TABLE #Privremena( ID INT IDENTITY(1,1) PRIMARY KEY, Zapis NVARCHAR(100) )

Naziv lokalne privremene tablice započinje znakom "#", a u Tempdb bazi podataka bit će

spremljena u sljedećem (skraćenom) obliku:

[dbo].[#Privremena_______________________________________________________000000000007]

Obično objekti unutar baze podataka mogu imati naziv do maksimalno 128 znakova.

Međutim, lokalne privremene tablice mogu imati naziv do 116 znakova, dok zadnjih 12

znakova dodjeljuje server. Naime, svaka lokalna privremena tablica dostupna je samo

jednoj konekciji, i to onoj u kojoj je napravljena. I druge konekcije također mogu kreirati

svoju lokalnu privremenu tablicu istog imena (#Privremena), a da bi server znao koja od

njih pripada kojoj konekciji koristi zadnjih 12 znakova kao identifikator konekcije.

Primjerice,

[dbo].[#Privremena_______________________________________________________000000000007]

[dbo].[#Privremena_______________________________________________________000000000008]

Sada izvršavanje upita



SELECT * FROM #Privremena

neće nužno dati isti rezultat. Jedna će se konekcija referencirati na privremenu tablicu sa

završnom oznakom 7, a druga konekcija na drugu tablicu.

Lokalna privremena tablica automatski se uništava iz Tempdb baze podataka nakon

završetka konekcije. Ukoliko je takva tablica kreirana unutar uskladištene procedure (eng.

stored procedure) automatski će biti uništena nakon njenog izvršavanja. Također ju je

moguće uništiti i "ručno" korištenjem naredbe DROP. [24]

Primjer 3.1.4 – Kreiranje globalne privremene tablice

IF NOT EXISTS(SELECT * FROM tempdb.sys.objects WHERE name = '##Privremena') CREATE TABLE ##Privremena( ID INT IDENTITY(1,1) PRIMARY KEY, Zapis NVARCHAR(100) )

Naziv globalne privremene tablice započinje znakovima "##". Za razliku od lokalne, ova

tablica vidljiva je i dostupna svim konekcijama. Njen vijek trajanja ograničen je trajanjem

konekcije u kojoj je kreirana ili se može ručno uništiti korištenjem naredbe DROP. Globalna

privremena tablica neće automatski biti uništena nakon završetka uskladištene procedure

u kojoj je kreirana, kao što je to slučaj s lokalnom privremenom tablicom.

Tablice mogu biti kreirane i korištene kao varijable. Tada su kao i sve druge varijable

vidljive samo unutar bloka naredbi, funkcije ili procedure u kojoj su kreirane.

Primjer 3.1.5 – Kreiranje tablice kao varijable

DECLARE @Privremena TABLE( ID INT IDENTITY(1,1) PRIMARY KEY, Zapis NVARCHAR(100) )

Ovakvi tipovi tablica kao u Primjeru 3.1.5 ne mogu sadržavati strane ključeve niti se za njih

mogu kreirati objekti poput okidača (eng. triggers). Također, tablice kao varijable mogu se

koristiti kao parametri uskladištenih procedura, a u tom slučaju njihov sadržaj dostupan je

samo za čitanje.



3.2. Pogledi

Pogled (eng. view) objekt je baze podataka koji sadrži tekst spremljenog SELECT

upita. Najčešće se koristi kako bismo SELECT upitom mogli povezati podatke iz više

različitih tablica te ih na pojednostavljen način prikazati i koristiti kao da su smješteni samo

u jednoj (virtualnoj) tablici. Pogled (njegov SELECT upit) ne može se izvršiti sam od sebe,

već se pri njegovom referenciranju unutar nekog drugog SQL upita ili pogleda stvara

rezultantna virtualna tablica.

Kao i u slučaju tablica, poglede je moguće kreirati interaktivno korištenjem SSMS alata ili

izravnim izvršavanjem SQL upita.

Slika 3.2.1. Kreiranje i izvršavanje pogleda korištenjem SSMS alata

U primjeru sa Slike 3.2.1 prikazan je način izrade pogleda koji ispisuje sve studente i

njihove upisane kolegije. Podaci se čitaju iz međutablice Polaznik, a u njoj su samo strani

ključevi tablica Student i Kolegij. Stoga su u pogledu te tri tablice povezane na način kako

je prikazano prvim dijelom slike (oznaka 1).



Nakon odabira tablica potrebno je odrediti stupce koji će biti vidljivi kao rezultat izvršavanja

pogleda (oznaka 2). Već pri odabiru stupaca automatski se generira i nadopunjuje

odgovarajući SQL upit pogleda (oznaka 3). U konačnici, izvršavanjem pogleda, tj. njegovog

SQL upita, stvara se virtualna tablica s rezultatima (oznaka 4).

Primjer 3.2.1 – Kreiranje pogleda izvršavanjem SQL upita

CREATE VIEW [dbo].[vPolaznici] AS SELECT TOP (100) PERCENT dbo.Polaznik.JMBAG, dbo.Student.Ime, dbo.Student.Prezime, dbo.Polaznik.SifraKolegija, dbo.Kolegij.Naziv AS NazivKolegija FROM dbo.Polaznik

INNER JOIN dbo.Student ON dbo.Student.JMBAG = dbo.Polaznik.JMBAG INNER JOIN dbo.Kolegij ON dbo.Polaznik.SifraKolegija = dbo.Kolegij.Sifra

Ukoliko bismo pogled sa Slike 3.2.1 kreirali izravno izvršavanjem SQL upita, taj upit

izgledao bi kao u Primjeru 3.2.1. Općenito, pogled se kreira na sljedeći način:

CREATE VIEW Naziv_sheme.Naziv_pogleda ([Aliasi stupaca)] AS SELECT upit;

Iako je to u praksi rijetko, pri kreiranju pogleda moguće je navesti aliase rezultantnih

stupaca. Tako bismo kreiranje pogleda iz Primjera 3.2.1 mogli napraviti i na sljedeći način:

Primjer 3.2.2 – Kreiranje pogleda sa unaprijed definiranim aliasima stupaca

CREATE VIEW [dbo].[vPolaznici] (JMBAG, Ime, Prezime, SifraKolegija, NazivKolegija) AS SELECT TOP (100) PERCENT dbo.Polaznik.JMBAG, dbo.Student.Ime, dbo.Student.Prezime, dbo.Polaznik.SifraKolegija, dbo.Kolegij.Naziv FROM dbo.Polaznik


Razlika između primjera 3.2.1 i 3.2.2 u tome je što zadnji primjer u SELECT upitu ne navodi

alias za stupac Kolegij.Naziv budući da su aliasi svih rezultantnih stupaca već unaprijed

definirani pri kreiranju pogleda. S druge strane, u Primjeru 3.2.1 nisu unaprijed definirani

aliasi rezultantnih stupaca pa se unutar SELECT upita "ručno" dodijelio alias stupcu

Kolegij.Naziv.

Nakon kreiranja pogleda, moguće ga je koristiti u SQL upitima. Primjerice,



Primjer 3.2.3 – Korištenje pogleda u SQL upitu

SELECT * FROM [dbo].[vPolaznici] WHERE JMBAG <= 2 ORDER BY JMBAG

Pogledi imaju više ograničenja, a jedno od njih je i nepouzdano korištenje izraza ORDER

BY. Ukoliko je potrebno sortirati zapise koji se dobiju kao rezultat izvršavanja pogleda to

se radi korištenjem izraza ORDER BY pri referenciranju pogleda iz nekog drugog SQL

upita (Primjer 3.2.3), a ne korištenjem tog izraza u samoj definiciji pogleda. [25]

Od ostalih ograničenja i nedostataka pogleda mogu se spomenuti i sljedeći:

▪ Nemogućnost kreiranja pogleda s parametrima.

▪ Nemogućnost korištenja varijabli i privremenih tablica unutar pogleda.

▪ Pogled je samo jedan SELECT upit.

▪ Unutar pogleda ne mogu se stvarati nove tablice (SELECT INTO).

Iako je rezultat pogleda virtualna tablica, nju je također vrlo često moguće ažurirati. Takvi

ažurirajući pogledi (eng. updatable views) zapravo ažuriraju tablice na osnovu kojih je

nastao rezultat pogleda.

Primjer 3.2.4 – Ažuriranje pogleda

SELECT * FROM vPolaznici UPDATE vPolaznici SET Ime = 'Anita' WHERE JMBAG = 1 and SifraKolegija = 1 SELECT * FROM vPolaznici

Izvršavanjem prvog SELECT upita u Primjeru 3.2.4 prvi se puta izvršava pogled vPolaznici.

Kao njegov rezultat dobit ćemo set podataka, tj. virtualnu tablicu sa sljedećim sadržajem.

JMBAG Ime Prezime SifraKolegija NazivKolegija

1 Ante Antić 1 Matematika

1 Ante Antić 2 Fizika

2 Ivica Ivić 2 Fizika

Tablica 3.2.1. Rezultat prvog izvršavanja pogleda vPolaznici



U narednoj UPDATE naredbi pogled je ažuriran na način da je stupcu Ime dodijeljena

vrijednost "Anita". Dodatno, uvjetom u UPDATE naredbi definirali smo da se ažuriranje

ograničava samo na prvi zapis pogleda (JMBAG vrijednost = 1, SifraKolegija = 1).

JMBAG Ime Prezime SifraKolegija NazivKolegija

1 Anita Antić 1 Matematika

1 Anita Antić 2 Fizika

2 Ivica Ivić 2 Fizika

Tablica 3.2.2. Rezultat drugog izvršavanja pogleda vPolaznici

Sada rezultat drugog izvršavanja pogleda vPolaznici može djelovati zbunjujuće (Tablica

3.2.2). Iako je možda očekivano da će biti ažuriran samo prvi zapis pogleda, zapravo su

ažurirani svi njegovi zapisi u kojima je JMBAG vrijednost jednaka 1 (prijašnje ime "Ante").

Razlog je upravo u tome što ažuriranje pogleda zapravo znači ažuriranje tablica na osnovu

kojih je nastao rezultat tog pogleda.

U pogledu vPolaznici (Primjer 3.2.1) definirano je da se vrijednost stupca Ime čita iz tablice

Student. Stoga, ažuriranje pogleda, odnosno vrijednosti stupca Ime, znači ažuriranje

referentnog zapisa u tablici Student, nakon čega se ponovnim izvršavanjem pogleda

svugdje vidi nova vrijednost tog stupca ("Anita"). Rezultat pogleda tek referira na podatke

u drugim tablicama. Zato ažuriranje jedne vrijednosti pogleda najčešće kao posljedicu ima

izmjenu rezultata pogleda na više mjesta.

I ažurirajući pogledi imaju neka ograničenja i nedostatke. Primjerice, naredba UPDATE

može ažurirati samo jednu referentnu tablicu pogleda. Probleme pri ažuriranju mogu

uzrokovati i agregatne funkcije te podupiti unutar pogleda koji sadrže derivirane tablice.

Također, iz pogleda moguće je brisati podatke naredbom DELETE samo ukoliko je pogled

baziran na jednoj tablici.

Unatoč svim nedostatcima, pogledi ipak nude neke sigurnosne prednosti. Unutar pogleda

moguće je sakriti informacije o svim shemama, referentnim tablicama i drugim korištenim

pogledima, a korisniku dati dozvolu samo za čitanje podataka dobivenih pogledom.

Također, SQL Server dopušta i enkripciju definicije pogleda, procedure i funkcije.



Primjer 3.2.5 – Kreiranje kriptiranog pogleda

CREATE VIEW [dbo].[vPolaznici] WITH ENCRYPTION AS SELECT TOP (100) PERCENT dbo.Polaznik.JMBAG, dbo.Student.Ime, dbo.Student.Prezime, dbo.Polaznik.SifraKolegija, dbo.Kolegij.Naziv AS NazivKolegija FROM dbo.Polaznik


Za razliku od inicijalnog pogleda iz Primjera 3.2.1, ovom pogledu više nije moguće dohvatiti

definiciju. Međutim, on je i dalje funkcionalan te se može koristiti u drugim SQL upitima i

pogledima. Za kriptirani pogled, SSMS alat podrazumijevano neće omogućiti generiranje

skripte za ažuriranje jer ne može dohvatiti njegovu trenutnu definiciju, ali je zato moguće

takvu skriptu "ručno" napisati u slučaju potrebe izmjene definicije pogleda.

3.3. Grupirajući i negrupirajući indeksi

Veće količine podataka u tablicama i pogledima usporavaju izvršavanje SQL upita

zbog sporije pretrage i dohvata tih podataka. Primjerice, pretraga nekog podatka u skupu

od par milijuna 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 (eng.

table scan) te najčešće predstavlja "najskuplji" način pretrage u smislu potrošnje

procesorskog vremena. Da bismo ga izbjegli koristimo indekse, a najčešći su tipovi indeksa

grupirajući (eng. clustered) i negrupirajući (eng. non-clustered) indeksi.

Grupirajući indeks možemo zamisliti kao telefonski imenik u kojem su svi telefonski brojevi

poredani po prezimenu. Kada bismo željeli pronaći telefonski broj neke osobe na osnovi

njenog prezimena, do rezultata bismo vrlo brzo došli binarnom pretragom. Međutim, kada

bismo telefonski imenik htjeli pretraživati po imenu osobe, morali bismo sekvencijalno

pregledavati svaki pojedini zapis.

Grupirajućim indeksom definira se fizički razmještaj zapisa u tablici, a može biti samo jedan

u zadano vrijeme. Primjerice, ne možemo u isto vrijeme zapise u tablici (telefonskom

imeniku) imati sortirane po imenu i po prezimenu jer bi za to trebalo imati dvije različite



tablice (telefonska imenika). Zbog toga u tablici može postojati samo jedan grupirajući

indeks, a ukoliko je potrebno stvoriti drugi prvi se prethodno mora izbrisati.

Slika 3.3.1. Struktura tablica Zaposlenik

Da bismo uvidjeli prednosti grupirajućeg indeksa možemo se poslužiti tablicom Zaposlenik

sa Slike 3.3.1. Ta tablica nema primarni ključ! Naime, pri dodavanju primarnog ključa

automatski se stvara i grupirajući indeks nad stupcem primarnog ključa, a to sada želimo

izbjeći kako bismo mogli testirati performanse prije i poslije dodavanja indeksa.

Za potrebe testiranja u tablici Zaposlenik nalazi se popis od 10000 zaposlenika sa slučajno

dodijeljenim iznosima plaće i mjesecima radnog staža.

Primjer 3.3.1 – Pretraga svih zaposlenika čija plaća iznosi više od 5000 kn

SELECT * FROM Zaposlenik WHERE IznosPlace > 5000

Na koji način se izvršava upit iz Primjera 3.3.1 najbolje pokazuje njegov izvedbeni plan

(eng. execution plan).

Slika 3.3.2. Izvedbeni plan – skeniranje tablice



SQL Server koristi Query Optimizer kako bi pronašao najbolji izvedbeni plan za izvršavanje

nekog SQL upita. Ovisno o količini podataka, njihovom fizičkom razmještaju, postojećim

indeksima, vezama među tablicama, statistikama itd. Query Optimizer stvara mnogo

kandidata za najbolji izvedbeni plan te se u konačnici odlučuje na jednog od njih.

U upitu iz Primjera 3.3.1 Query Optimizer odlučio se na jedini mogući izvedbeni plan, tj.

skeniranje tablice. Kako ne postoji indeks nad stupcem IznosPlace jedini način za

pronalazak svih plaća većih od 5000 kn jest da se pregleda svaki zapis u tablici. Upravo to

je i prikazano Slikom 3.3.2 gdje se vidi da je za potrebe izvršavanja tog upita pročitano

(provjereno) svih 10000 zapisa, a da ih tek 4914 zadovoljava traženi kriterij. Kako bismo

izbjegli skeniranje tablice, odnosno pregled svih 10000 zapisa, možemo kreirati grupirajući

indeks nad stupcem IznosPlace.

Primjer 3.3.2 – Kreiranje grupirajućeg indeksa

CREATE CLUSTERED INDEX IX_IznosPlace on Zaposlenik(IznosPlace ASC)

Nakon kreiranja indeksa IX_IznosPlace svi zapisi u tablici Zaposlenik fizički su sortirani po

vrijednosti stupca IznosPlace, što se jednostavno može provjeriti sljedećim upitom:

SELECT * FROM Zaposlenik

Kreirani indeks IX_IznosPlace nema ograničenje tipa UNIQUE. Međutim, ako je grupirajući

indeks kreiran automatski kao posljedica dodavanja primarnog ključa tada

podrazumijevano uvijek ima takvo ograničenje. Zbog toga sada je moguća prisutnost

dvostrukih vrijeednosti u stupcu IznosPlace jer više zaposlenika može imati isti iznos plaće.

Slika 3.3.3. Indeks i statistika indeksa



SQL Server će za svaki indeks stvoriti i statistički objekt (Slika 3.3.3). Njega koristi Query

Optimizer pri kreiranju i odabiru izvedbenih planova jer se u statističkom objektu nalaze

informacije o distribuciji podataka unutar tablice. Na osnovi tih informacija može se

procijeniti kardinalnost, tj. 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. [26]

I konačno, nakon kreiranja grupirajućeg indeksa IX_IznosPlace, ponovno izvršavanje upita

iz Primjera 3.3.1 sada će rezultirati puno bržim izvedbenim planom.

Slika 3.3.4. Izvedbeni plan – pretraga po grupirajućem indeksu

Izvedbeni plan kao na Slici 3.3.4 smatra se optimalnim jer nije utrošeno nimalo

procesorskog vremena na nepotrebna čitanja. Umjesto čitanja svih 10000 zapisa

(skeniranja tablice) pročitani su samo oni zapisi koji trebaju biti vraćeni kao rezultat upita.

Rezultat je to postojanja grupirajućeg indeksa koji omogućava pretragu podataka

pretraživanjem indeksa (eng. index seek).

Zbog činjenice da se zapisi u tablici fizički sortiraju po grupirajućem indeksu (sama tablica

predstavlja indeks), Query Optimizer se u određenim situacijama može odlučiti na

skeniranje grupirajućeg indeksa (eng. clustered index scan). Primjerice, u upitu

SELECT * FROM Zaposlenik

ne postoji uvjet (klauzula WHERE) pa se pristupa metodi skeniranja grupirajućeg indeksa.

I metoda skeniranje tablice bi u konačnici pročitala sve zapise, ali skeniranje grupirajućeg



indeksa je brže budući da su zapisi sada organizirani po strukturi balansiranog B-stabla

(eng. B-tree), kao na Slici 3.3.5.

Slika 3.3.5. Struktura grupirajućeg indeksa (B-stablo) [27]

Pri pretraživanju podataka pomoću grupirajućeg indeksa prvo se provjerava korijenski čvor

(eng. root node), odnosno svi zapisi u njegovoj indeksnoj stranici (eng. index rows). Svaki

zapis u indeksnoj stranici sadrži ključnu vrijednost i pokazivač na jedan od međučvorova

na srednjoj razini (eng. intermediate level) ili pokazivač na odgovarajući list (eng. leaf

node/data page) ukoliko je traženi podatak pronađen. Također, stranice na pojedinim

razinama međusobno su povezane dvostruko povezanim listama, što doprinosi boljim

performansama pri operaciji skeniranja grupirajućeg indeksa.

Zbog ovakve strukture, metoda skeniranja grupirajućeg indeksa brža je od metode

skeniranja tablice. Ukoliko nema grupirajućeg indeksa, podaci su spremljeni kao

neorganizirana gomila (eng. heap). Dohvat podataka tada je sporiji jer ne postoje

pokazivači iz jedne stranice na drugu, već se za dohvat svake sljedeće stranice mora

koristiti IAM (Index Allocation Map).



Zbog ograničenja tablice na tek jedan grupirajući indeks vrlo se često moraju koristiti i

negrupirajući (eng. non-clustered) indeksi. Počevši od SQL Servera 2008 u svakoj tablici

može postojati čak i do 999 negrupirajućih indeksa.

Iako indeksi ubrzavaju pretragu podataka, sa svakim novim indeksom padaju performanse

pri operacijama dodavanja, izmjene i brisanja podataka. Nakon svake od tih operacija

najčešće će trebati ažurirati i sve postojeće indekse, što može oduzeti mnogo

procesorskog vremena. Zbog toga indekse treba pažljivo odabrati kako upravo oni ne bi

bili uzrokom loših performansi baze podataka.

Slika 3.3.6. Struktura negrupirajućeg indeksa [28]

Negrupirajući indeks kreira se na vrlo sličan način kao i grupirajući indeks.

Primjer 3.3.3 – Kreiranje negrupirajućeg indeksa

CREATE /* NONCLUSTERED */ INDEX IX_RadniStaz on Zaposlenik (MjeseciRadnogStaza)

Za razliku od grupirajućeg indeksa, podaci u tablici Zaposlenik ovaj puta nisu fizički

sortirani po indeksu (indeksiranom stupcu) već se stvara nova podatkovna struktura B-



stabla za svaki negrupirajući indeks (Slika 3.3.6). Ta struktura vrlo je slična strukturi B-

stabla grupirajućeg indeksa, s razlikom da listovi B-stabla negrupirajućeg indeksa sadrže

tek pokazivače na podatke umjesto stvarnih podataka.

SQL Server omogućava i kreiranje filtriranih negrupirajućih indeksa. Njih se koristi u

slučajevima kada se učestalo rade pretrage određenog podskupa podataka.

Primjer 3.3.4 – Kreiranje filtriranog negrupirajućeg indeksa

CREATE INDEX IX_PostojeciRadniStaz on Zaposlenik (MjeseciRadnogStaza) WHERE MjeseciRadnogStaza IS NOT NULL

Pretpostavimo da učestalo radimo upite bazirane na radnom stažu zaposlenika. Korištenje

klasičnog negrupirajućeg indeksa uzrokovalo bi indeksiranje svih zapisa u tablici

Zaposlenik. Međutim, ukoliko nemamo koristi od nepostojećih podataka (NULL vrijednosti

u stupcu MjeseciRadnogStaza) onda nema niti potrebe da indeksiramo takve zapise.

Stoga, filtriranim negrupirajućim indeksom iz Primjera 3.3.4 indeksiramo samo one zapise

o zaposlenicima koji imaju podatak o radnom stažu.

Filtrirani negrupirajući indeks omogućuje bržu pretragu jer je njegovo B-stablo manje

veličine. Također, ažuriranje podataka ne mora svaki puta uzrokovati i ažuriranje

filtrirajućeg negrupirajućeg indeksa, pa su i performanse pri radu sa podacima bolje.

Učestale promjene nad podacima (dodavanje, izmjena i brisanje) mogu uzrokovati

fragmentaciju indeksa. Indeksne stranice najčešće postanu razbacane po disku ili nisu

dobro popunjene (koristi se više stranica nego što je potrebno), što u konačnici loše utječe

na performanse. SQL Server tada nudi mogućnost reorganizacije ili obnove indeksa.

Primjer 3.3.5 – Reorganizacija i obnova indeksa

ALTER INDEX IX_RadniStaz ON ZAPOSLENIK REORGANIZE -- Fragmentacija do 30% ALTER INDEX IX_RadniStaz ON ZAPOSLENIK REBUILD -- Fragmentacija > 30%

Reorganizacija indeksa podrazumijeva reorganizaciju indeksnih stranica, a preporučuje se

kada fragmentacija indeksa iznosi do maksimalnih 30%. U protivnom, preporuka je

napraviti obnovu indeksa (njegovo brisanje i ponovno kreiranje). Ovisno o količini podataka

u tablici, obnova indeksa može dugo trajati pa ju je poželjno raditi tek kada je broj upita

prema bazi najmanji (primjerice, po noći).



3.4. Uskladištene procedure i funkcije

Korisnički definiranim procedurama i funkcijama moguće je centralizirati i nametnuti

istu poslovnu logiku svim klijentima baze podataka. Na taj način možemo osigurati da svi

klijenti koriste iste rutine (postupke) pri obradi podataka te da niti jedan od klijenata ne

može od njih odstupati. Ovakvim pristupom postiže se konzistentnost u radu svih klijenata

te se olakšava i eventualna izmjena same poslovne logike.

Izmjena centralizirane poslovne logike najčešće znači tek izmjenu procedura i funkcija u

bazi podataka. Dodatnih izmjena na klijent strani nema ili su minimalne (eventualne

promjene povratnih vrijednosti ili listi argumenata procedura i funkcija). Klijent aplikacije

tada je lakše pisati i održavati jer umjesto kompleksne poslovne logike moraju

implementirati tek sučelja za unos i prikaz podataka.

SQL Server nudi mogućnost pisanja vlastitih uskladištenih procedura, skalarnih funkcija i

funkcija s tabličnim vrijednostima (eng. table-valued functions). Za pisanje vlastitih

agregatnih funkcija potrebno je koristiti CLR (Microsoft .NET Framework Common

Language Runtime).

Uskladištene procedure omogućuju spremanje T-SQL upita u bazi podataka. Umjesto

slanja kompleksnih upita mrežom dovoljno je tek pozvati uskladištenu proceduru koja

sadrži taj upit. Uskladištene procedure izvršavaju se na serveru, što značajno doprinosi

performansama. Među ostalim, omogućuju i dodatne razine sigurnosti. Korisnik ne mora

imati ovlasti za rad s objektima (tablicama, pogledima itd.) niti ovlasti za izvršavanje upita

koji se nalaze u uskladištenoj proceduri, ali može biti ovlašten izvršiti uskladištenu

proceduru koja sve te objekte i upite sadrži.

Primjer 3.4.1 – Uskladištena procedura usp_SviZaposlenici

CREATE PROCEDURE usp_SviZaposlenici AS BEGIN SELECT * FROM Zaposlenik END



Kao i svi drugi tipovi objekata i uskladištene procedure kreiraju se naredbom CREATE

(Primjer 3.4.1). Prilikom njihova imenovanja preporuka je ne koristiti prefiks "sp_" jer on je

rezerviran za sistemske uskladištene procedure. Umjesto njega poželjno je koristiti neki

drugi prefiks poput "usp_" (eng. user stored procedure) ili sl. [29]

Tijelo uskladištene procedure može sadržavati više naredbi pa je uvijek omeđeno ključnim

riječima BEGIN i END, a za njeno izvršavanje koristi se naredba EXECUTE (skraćeno

EXEC):

EXEC usp_SviZaposlenici

Uskladištene procedure mogu imati i parametre, a oni mogu sadržavati i podrazumijevane

vrijednosti.

Primjer 3.4.2 – Uskladištena procedura usp_UvecajPlacu

CREATE PROCEDURE usp_UvecajPlacu (@Od float = 0, @Do float, @Iznos float) AS BEGIN UPDATE Zaposlenik SET IznosPlace = IznosPlace + @Iznos WHERE IznosPlace BETWEEN @Od and @Do END

Jedna od najvažnijih mogućnosti uskladištenih procedura jest da mogu mijenjati sadržaj

baze podataka. Tako procedura u Primjeru 3.4.2 uvećava plaću svim zaposlenicima čiji je

trenutni iznos plaće između vrijednosti @Od i @Do. Parametar @Od ima podrazumijevanu

vrijednost 0, što omogućuje poziv uskladištene procedure na sljedeće načine:

-- najčešći oblik predaje vrijednosti proceduri EXEC usp_UvecajPlacu 0, 3500, 500 -- drugačiji raspored ulaznih vrijednosti EXEC usp_UvecajPlacu @Do = 3500, @Od = 0, @IznosUvecanja = 500 -- korištenje podrazumijevane vrijednosti parametra @Od = 0 EXEC usp_UvecajPlacu @Do = 3500, @IznosUvecanja = 500

Kada redoslijed predanih vrijednosti odgovara redoslijedu parametara najbrže je koristiti

prvi oblik predaje vrijednosti. U protivnom, za svaku predanu vrijednost treba naglasiti

kojem parametru pripada. Ukoliko vrijednost nekog parametra nije navedena, u proceduri



se koristi njegova podrazumijevana vrijednost ili se javlja greška ukoliko podrazumijevana

vrijednost ne postoji.

Uskladištena procedura može vratiti set podataka (Primjer 3.4.1), cjelobrojnu vrijednost

korištenjem naredbe RETURN ili vrijednosti drugih tipova korištenjem izlaznih (eng. output)

tipova parametara (Primjer 3.4.3).

Primjer 3.4.3 – Uskladištena procedura usp_SrednjaStarostZaposlenika

CREATE PROCEDURE [dbo].[usp_SrednjaStarostZaposlenika] (@srednjaStarost float output) AS BEGIN DECLARE @sumaPlaca float = (SELECT SUM(IznosPlace) FROM Zaposlenik) DECLARE @brojZaposlenika int = (SELECT COUNT(*) FROM Zaposlenik) IF @brojZaposlenika > 0 BEGIN SET @srednjaStarost = @sumaPlaca / @brojZaposlenika RETURN 0 -- uspješno izvršena procedura END ELSE RETURN 1 -- dijeljenje s nulom (prazan popis zaposlenika) END

Povratna vrijednost koja se definira naredbom RETURN zamišljena je tek da vrati status

izvršavanja procedure (0 – uspješno izvršena, ili neki drugi cijeli broj u slučaju greške). Za

sve ostale povratne vrijednosti koriste se izlazni tipovi parametara kojih može biti više i koji

mogu biti proizvoljnih tipova. Tako je proceduru iz Primjera 3.4.3 moguće pozvati na

sljedeći način:

DECLARE @sredina float DECLARE @status int -- poziv uskladištene procedure i vraćanje vrijednosti EXEC @status = usp_SrednjaStarostZaposlenika @sredina OUTPUT IF @status = 0 SELECT @sredina ELSE PRINT 'Ne postoji niti jedan zaposlenik!'

Prije ispisa srednje starosti zaposlenika provjerava se status izvršavanja uskladištene

procedure (varijabla @status). Naime, ukoliko u tablici Zaposlenik nema zapisa onda nije

niti moguće izračunati prosječnu starost pa će uskladištena procedura za taj slučaj

naredbom RETURN vratiti vrijednost 1. Za dohvat srednje starosti (realan broj) putem

izlaznih parametara predana je varijabla @sredina sa ključnom riječi OUTPUT.



Za razliku od uskladištenih procedura, skalarne funkcije uvijek vraćaju samo jednu

vrijednost. Također, moraju biti determinističke, tj. za iste vrijednosti ulaznih parametara

uvijek moraju dati istu povratnu vrijednost. Zbog toga se unutar skalarne funkcije ne mogu

pozivati nedeterminističke funkcije poput RAND, GETDATE itd.

Primjer 3.4.4 – Skalarana funkcija 'fn_Kvadrat'

CREATE FUNCTION dbo.fn_Kvadrat (@broj float) RETURNS FLOAT AS BEGIN RETURN @broj * @broj END

Svaka skalarna funkcija treba imati povratnu vrijednost koja se definira naredbom

RETURN (Primjer 3.4.4), a pri njenom pozivu uvijek treba koristiti obje komponente imena,

tj. naziv vlasnika ili sheme te naziv skalarne funkcije. Primjerice,

SELECT dbo.fn_Kvadrat(10) -- 100

Argumenti se predaju unutar zagrada nakon imena funkcije, dok sama skalarna funkcija

može imati i podrazumijevane vrijednosti parametara.

Primjer 3.4.5 – Skalarana funkcija 'fn_IzracunPlace'

CREATE FUNCTION dbo.fn_IzracunPlace (@broj_sati int, @bolovanje bit = 0) RETURNS FLOAT AS BEGIN DECLARE @satnica int = 25 IF @bolovanje = 1 -- ako je zaposlenik bio na bolovanju… RETURN @broj_sati * @satnica * 0.7 -- 70% plaće RETURN @broj_sati * @satnica END

Ipak, parametri funkcija s podrazumijevanim vrijednostima nisu neobavezni. Ukoliko se pri

pozivu funkcije ne navede konkretna vrijednost takvog parametra već se želi koristiti

njegova podrazumijevana vrijednost potrebno je koristiti ključnu riječ DEFAULT. To

omogućuje poziv funkcije fn_IzracunPlace (primjer 3.4.5) na sljedeći način:

SELECT dbo.fn_IzracunPlace(10, DEFAULT) – 250 (nije na bolovanju)



Za razliku od skalarnih funkcija koje isključivo vraćaju jednu vrijednost, možemo kreirati i

dva tipa funkcija koje vraćaju setove podataka, odnosno tablične vrijednosti. To su:

▪ Inline Table-Valued Functions

▪ Multistatement Table-Valued Functions

Prvi tip predstavlja jednostavni oblik funkcije s tabličnom vrijednošću. Njeno tijelo sadrži

samo jednu SELECT naredbu kojom se definira povratna vrijednost funkcije, tj. rezultantna

virtualna tablica. To ju čini vrlo sličnom pogledu (eng. view) koji također rezultira virtualnom

tablicom. Ipak, kao i svaka druga funkcija može imati parametre dok ih pogled nema. Zbog

toga se vrlo često taj tip funkcije koristi kao zamjena za pogled.

Primjer 3.4.6 – Jednostavni oblik funkcije sa tabličnom vrijednošću

CREATE FUNCTION Place_Zaposlenika (@Od float, @Do float) RETURNS TABLE AS RETURN -- povratna je vrijednost novi set podataka ( SELECT Ime, Prezime, IznosPlace from Zaposlenik WHERE IznosPlace between @Od and @Do )

Funkcija iz Primjera 3.4.6 kao rezultat vraća virtualnu tablicu s popisom svih zaposlenika

čija plaća iznosi između vrijednosti definiranih parametrima @Od i @Do. Njen poziv

možemo napraviti na sljedeći način:

SELECT Ime, Prezime, IznosPlace FROM dbo.Place_Zaposlenika(5000, 10000)

Ukoliko je potrebno da funkcija s tabličnom vrijednošću može sadržavati više naredbi, tj.

imati kompleksnost skalarnih funkcija, mora koristiti njen složeni oblik (eng. multistatement

table-valued function).

Primjer 3.4.7 – Složeni oblik funkcije sa tabličnom vrijednošću

CREATE FUNCTION IznadprosjecnePlace() RETURNS @RezultatTablica TABLE (-- struktura rezultantne tablice Ime nvarchar(50), Prezime nvarchar(50), IznosPlace float ) AS BEGIN -- izračun prosjeka plaće DECLARE @ProsjekPlace float



SET @ProsjekPlace = (SELECT AVG(IznosPlace) FROM Zaposlenik) -- popuni rezultantnu tablicu... INSERT INTO @RezultatTablica SELECT Ime, Prezime, IznosPlace FROM Zaposlenik WHERE IznosPlace > @ProsjekPlace RETURN -- vrati sadržaj tablice @RezultatTablica END

Kod složenog oblika funkcije s tabličnom vrijednošću eksplicitno je potrebno definirati

strukturu rezultante tablice (Primjer 3.4.7). Također, blok naredbi (tijelo) takve funkcije

mora biti omeđeno ključnim riječima BEGIN i END jer može sadržavati više od jedne

naredbe. Unutar tijela funkcije popunjava se rezultantna tablica, a njen sadržaj vraća se

naredbom RETURN.

Bilo da je riječ o funkcijama ili pogledima možemo ih kreirati i korištenjem dodatne izjave

"WITH SCHEMABINDING". Tom izjavom zabranjujemo svaku modifikaciju referentnih

objekata koja bi utjecala na izvršavanje te funkcije ili pogleda. [30]

Primjer 3.4.8 – Korištenje izjave "WITH SCHEMABINDING"

CREATE FUNCTION Place_Zaposlenika2 (@Od float, @Do float) RETURNS TABLE WITH SCHEMABINDING AS RETURN ( SELECT Ime, Prezime, IznosPlace from dbo.Zaposlenik WHERE IznosPlace between @Od and @Do )

Nakon kreiranja funkcije Place_Zaposlenika2 (Primjer 3.4.8) sljedeće naredbe neće biti

moguće uspješno izvršiti:

DROP TABLE dbo.Zaposlenik -- Cannot DROP TABLE 'dbo.Zaposlenik' because it is being referenced by object -- 'Place_Zaposlenika2'. ALTER TABLE dbo.Zaposlenik ALTER COLUMN IME nvarchar(100) -- The object 'Place_Zaposlenika2' is dependent on column 'IME'.

Izjavom "WITH SCHEMABINDING" neće se zabraniti brisanje (DROP) i izmjena (ALTER)

nereferenciranih dijelova objekata. Primjerice, bez zabrane mogli bismo brisati i mijenjati

sve stupce tablice Zaposlenik koji nisu referencirani unutar funkcije Place_Zaposlenika2.



Korištenje ove izjave nameće dva dodatna pravila:

▪ Unutar funkcije ili pogleda zabranjeno je korištenje izraza SELECT *.

▪ Svi referentni objekti moraju sadržavati i naziv sheme prije svog imena.

Funkcije u SQL Serveru ograničene su na način da ne mogu mijenjati sadržaj baze

podataka. Unutar njih nije dopušteno koristiti naredbe INSERT, UPDATE i DELETE osim

ako se njima ne djeluje na tablične varijable (Primjer 3.4.7). Također, nije moguće pozivati

uskladištene procedure, koristiti i vraćati kursore i BLOB (eng. binary large object) objekte,

obrađivati greške (TRY-CATCH, RAISERROR) itd. Da bi se nadišla sva ova ograničenja

najčešće se umjesto funkcija koriste uskladištene procedure.

3.5. DML i DDL okidači

Okidač (eng. trigger) posebna je vrsta uskladištene procedure koja se izvršava

automatski umjesto (eng. instead of) ili nakon (eng. after) nekog događaja. Ovisno o

tipovima 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, očuvati integritet te kontrolirali strukturu baza podataka.

DML okidači koriste se kada je nad tablicom potrebno kontrolirati operacije dodavanja

(INSERT), ažuriranja (UPDATE) i brisanja (DELETE) podataka. Primjerice, pretpostavimo

da u tablici Zaposlenik želimo nametnuti sljedeća poslovna pravila pri radu sa podacima:

1. Ime zaposlenika mora započeti velikim slovom, a ostala slova moraju biti mala.

2. Spremiti datum i vrijeme svake izmjene podataka u stupac ZadnjaIzmjena.

3. Nije moguće izbrisati osobu (zaposlenika) koja je još uvijek zaposlena.

Navedena pravila možemo primijeniti kreiranjem odgovarajućih okidača, pri čemu se koristi

sljedeća sintaksa:

CREATE [ ili ALTER ] TRIGGER [naziv_sheme.]ime_okidaca ON { TABLE | VIEW } { AFTER | INSTEAD OF } { [INSERT] [,] [UPDATE] [,] [DELETE] } AS { tijelo_okidaca }



DML okidače moguće je kreirati nad tablicama i pogledima, a unatoč velikoj fleksibilnosti

imaju i nekoliko ograničenja. Unutar tijela okidača nije moguće kreiranje (CREATE),

mijenjanje (ALTER) i brisanje (DROP) baze podataka, a ista ograničenja vrijede i za

indekse tablice i samu tablicu nad kojom se okidač izvršava. [31] Također, nad istom

tablicom dopušteno je kreiranje većeg broja AFTER, ali samo jednog INSTEAD OF

okidača.

Primjer 3.5.1 – Okidač nakon (AFTER) operacija INSERT i UPDATE

CREATE TRIGGER tr_ImeVrijeme ON ZAPOSLENIK AFTER INSERT, UPDATE AS BEGIN -- Dohvati OIB (identifikator) DECLARE @OIB NVARCHAR(50) = (SELECT OIB from Inserted) -- Dohvati ime zaposlenika DECLARE @ime NVARCHAR(50) = (SELECT Ime from Inserted) UPDATE Zaposlenik SET -- Prvi znak imena pretvori u veliko slovo, a ostale znakove u mala slova Ime = UPPER(LEFT(@ime, 1)) + LOWER(SUBSTRING(@ime, 2, LEN(@ime))), -- Spremi datum i vrijeme zadnje izmjene zapisa ZadnjaIzmjena = SYSDATETIME() WHERE OIB = @OIB END

Okidačem iz Primjera 3.5.1 implementirana su prva dva poslovna pravila. Prilikom svakog

dodavanja novog ili ažuriranja postojećeg zapisa, ime zaposlenika prepravlja se tako da

počinje velikim slovom (ostala slova su mala) te se u stupac ZadnjaIzmjena sprema datum

i vrijeme izvršene operacije. Taj okidač možemo testirati na sljedeći način:

-- Dodaj novog zaposlenika (OIB, Ime, Prezime, IznosPlace, Zaposlen?) INSERT INTO Zaposlenik VALUES ('111222', 'ante', 'Antic', 4500, 1) SELECT Ime, ZadnjaIzmjena FROM Zaposlenik WHERE OIB = '111222' -- Ante 2017-07-13 18:36:11.957

ili

-- Ažuriraj ime postojećeg zaposlenika UPDATE Zaposlenik SET Ime = 'aNTON' WHERE OIB = '111222' SELECT Ime, ZadnjaIzmjena FROM Zaposlenik WHERE OIB = '111222' -- Anton 2017-07-13 18:36:11.970



U tijelu okidača moguće je koristiti specijalne tablice Inserted i Deleted (Primjer 3.5.1). To

su privremene tablice koje se nalaze u memoriji te služe kao međuspremnici za sve zapise

koji su zahvaćeni operacijama INSERT, UPDATE i DELETE.

Operacija Tablica Inserted Tablica Deleted

INSERT Sadrži nove zapise -

DELETE - Sadrži zapise koji se brišu

UPDATE Sadrži nove inačice zapisa Sadrži stare inačice zapisa

Tablica 3.5.1. Sadržaji tablica Inserted i Deleted

Tako bi se nakon operacije

UPDATE Zaposlenik SET Ime = 'aNTON' WHERE OIB = '111222'

u tablici Inserted nalazio zapis

OIB Ime Prezime IznosPlace Zaposlen ZadnjaIzmjena

111222 aNTON Antic 4500 1 2017-08-14 12:22:13.553

a u tablici Deleted prethodna inačica tog zapisa

OIB Ime Prezime IznosPlace Zaposlen ZadnjaIzmjena

111222 Ante Antic 4500 1 2017-08-14 12:22:13.553

U konačnici, okidač iz Primjera 3.5.1 koristi vrijednost stupca Ime iz tablice Inserted

(aNTON) kako bi nad tom vrijednošću primijenio poslovno pravilo 1 te zajedno s datumom

i vremenom izmjene sve spremio u tablicu Zaposlenik.

Okidač se izvršava jednom po operaciji, a ne jednom po svakom zahvaćenom zapisu

(retku). Zbog toga je potreban veliki oprez pri operacijama u kojima se zahvaća više zapisa

odjednom. Tako će izvršavanje sljedećeg upita rezultirati greškom unutar okidača:



UPDATE Zaposlenik SET Ime = 'aNTON' -- Nema WHERE – mijenja se ime svih zaposlenika!

Postojeći okidač (Primjer 3.5.1) nije u mogućnosti primijeniti poslovna pravila 1 i 2 nad više

zahvaćenih zapisa odjednom, već tek nad INSERT i UPDATE operacijama u kojima se

zahvaća jedan po jedan zapis. U takvim slučajevima potrebno je kreirati okidače na način

kao u Primjeru 3.5.2.

Primjer 3.5.2 – Okidač nad više zahvaćenih zapisa

CREATE TRIGGER tr_ImeVrijeme2 ON ZAPOSLENIK AFTER INSERT, UPDATE AS BEGIN UPDATE Zaposlenik SET Ime = UPPER(LEFT(i.ime, 1)) + LOWER(SUBSTRING(i.ime, 2, LEN(i.ime))), ZadnjaIzmjena = SYSDATETIME() FROM Zaposlenik INNER JOIN Inserted i ON Zaposlenik.OIB = i.OIB END

Spajanjem (INNER JOIN) tablica Zaposlenik i Inserted dobit ćemo sve zapise koji su

zahvaćeni izvršenom INSERT ili UPDATE operacijom, nakon čega nad svima njima

odjednom možemo primijeniti poslovna pravila 1 i 2. Za implementaciju pravila broj 3

idealno je koristiti INSTEAD OF DELETE okidač (Primjer 3.5.3).

Primjer 3.5.3 – Okidač INSTEAD OF DELETE

CREATE TRIGGER tr_ZabranaBrisanja ON ZAPOSLENIK INSTEAD OF DELETE AS BEGIN /* ...na razini jednog zahvaćenog zapisa */ -- DECLARE @OIB NVARCHAR(50) = (SELECT OIB from Deleted) -- DECLARE @Zaposlen bit = (SELECT Zaposlen from Deleted) -- IF @Zaposlen = 0 -- DELETE FROM Zaposlenik WHERE OIB = @OIB -- ELSE -- PRINT 'Nije moguće izbrisati aktivnog zaposlenika!' /* ...brisanje višestruko zahvaćenih zapisa */ DELETE Zaposlenik FROM Zaposlenik Z INNER JOIN Deleted D ON Z.OIB = D.OIB and Z.Zaposlen = 0 END

Unutar tijela okidača moguće je detektirati promjenu vrijednosti pojedinih stupaca, za što

se koristi funkcija UPDATE. Primjerice,



IF UPDATE(Ime) PRINT 'Promijenili ste ime!'

Detekcija promjene vrijednosti unutar stupca može pomoći pri optimizaciji jer se umjesto

izvršavanja cijelog koda unutar okidača može izvršiti samo onaj dio koji je bitan pri

promijeni nekog konkretnog stupca.

DML okidačima kontroliramo sadržaj, a za kontrolu strukture objekata koristimo DDL

okidače. Operacije poput CREATE, ALTER i DROP moguće je spriječiti, uvjetovati ili uz

njih definirati i neke druge operacije. DDL okidači izvršavaju se isključivo nakon operacije,

odnosno ne postoji INSTEAD OF tip DDL okidača.

Primjer 3.5.4 – DDL okidač na razini baze podataka

CREATE TRIGGER tr_ZabranaTablice ON DATABASE AFTER DROP_TABLE, ALTER_TABLE AS BEGIN PRINT 'Ne možete mijenjati ili brisati tablicu!' ROLLBACK END

Postoje dva područja djelovanja DDL okidača – na razini baze podataka (ON DATABASE)

ili na razini servera (ON ALL SERVER). U Primjeru 3.5.4 zabranjeno je brisanje i mijenjanje

strukture bilo koje tablice u bazi podataka nad kojom je kreiran okidač. Kako se DDL okidač

uvijek izvršava nakon operacije, zadnjom naredbom (ROLLBACK) poništavamo prethodno

obavljenu DROP TABLE ili ALTER TABLE operaciju.

Ukoliko bismo htjeli definirati DDL okidač koji se izvršava nad bilo kojom bazom podataka

na serveru (instanci), koristili bismo ON ALL SERVER specifikaciju, kao u Primjeru 3.5.5.

Primjer 3.5.5 – DDL okidač na razini servera (instance)

CREATE TRIGGER tr_ZabranaSvugdje ON ALL SERVER AFTER CREATE_TABLE AS BEGIN PRINT 'Ne možete kreirati tablicu!' ROLLBACK END



Pokušaj kreiranja nove tablice u bilo kojoj bazi podataka na serveru sada više nije moguć.

Zbog ovakvih i sličnih situacija DML i DDL okidače privremeno je moguće onemogućiti,

izvršiti potrebne operacije, a zatim ponovno omogućiti.

DISABLE TRIGGER tr_ZabranaSvugdje ON ALL SERVER -- CREATE TABLE ... ENABLE TRIGGER tr_ZabranaSvugdje ON ALL SERVER

U SSMS alatu DML okidače moguće je pronaći unutar svake tablice pod stavkom

"Triggers". DDL okidači na razini baze podataka su pod stavkom "Database Triggers", a

okidači na razini servera u stavci "Server Objects/Triggers".

3.6. Sekvence

Počevši od SQL Servera 2012 moguće je kreirati i koristiti sekvence. To su objekti

koji generiraju uzlazno ili silazno sortirane nizove cjelobrojnih vrijednosti. Sekvence mogu

podsjećati na stupce sa svojstvom IDENTITY, ali takvi stupci vezani su isključivo za tablicu

u kojoj postoje, dok se jedna sekvenca može koristiti u svim tablicama baze podataka.

Također, sekvence se mogu resetirati automatski ili proizvoljno, te im je moguće definirati

minimalnu i maksimalnu vrijednost.

Primjer 3.6.1 – Kreiranje sekvence 'Rb'

CREATE SEQUENCE Rb START WITH 1 -- INCREMENT BY 1 -- MINVALUE ... -- MAXVALUE ... -- CYCLE ?

Pri kreiranju sekvence poželjno je definirati početnu vrijednost niza (START WITH).

Ukoliko nije drugačije definirano, podrazumijevana vrijednost prirasta (INCREMENT BY)

je broj 1, dok minimalna i maksimalna vrijednost te svojstvo CYCLE nisu definirani. Kada

želimo generirati i dohvatiti novi broj u nizu (sekvenci) možemo izvršiti sljedeći upit:

SELECT NEXT VALUE FOR Rb



Prvo izvršavanje ovog upita ispisat će vrijednost 1, a zatim vrijednost 2, pa 3 itd. Svaka

generirana vrijednost može se iskoristiti za, primjerice, numeriranje zapisa u tablicama,

numeriranje izvršenih operacija u log tablicama itd. naredbama poput

INSERT INTO LogTablica VALUES (NEXT VALUE FOR Rb, 'Login korisnika', SYSDATETIME())

Sekvence mogu biti generirane i silazno, kao u Primjeru 3.6.2.

Primjer 3.6.2 – Kreiranje silazne sekvence

CREATE SEQUENCE Silazna START WITH 10 INCREMENT BY -1 MINVALUE 1 MAXVALUE 10 CYCLE

Početna i maksimalna vrijednost sekvence Silazna je broj 10, a svaka sljedeća vrijednost

umanjena je za 1. Kada se dođe do minimalne vrijednosti (1), sljedeća generirana

vrijednost opet je broj 10, što je osigurano svojstvom CYCLE. Ukoliko je potrebno resetirati

sekvencu prije nego što je došla do svoje granične vrijednosti, možemo izvršiti sljedeći

upit:

ALTER SEQUENCE Silazna RESTART WITH 10

Gdje god se javlja potreba za numeriranjem uvijek je poželjno koristiti sekvence umjesto

stupaca sa svojstvom identiteta. Sekvence imaju šire djelovanje, lakše ih je kontrolirati te

uvijek generiraju predviđene vrijednosti. Vrijednosti generirane stupcem sa svojstvom

identiteta ne moraju nužno uvijek biti u istom razmaku te ih je moguće generirati samo

prilikom kreiranja novog zapisa.

3.7. Sinonimi

Sinonimi su pomoćni objekti koji se koriste kako bismo kreirali alternativna imena

za objekte u bazi podataka. Njihovim korištenjem pojednostavljuje se pristup objektima s



dugačkim nazivima, uz manje posljedica moguće je izmijeniti postojeću strukturu baze

podataka te se doprinosi i sigurnosnim aspektima administracije.

Primjer 3.7.1 – Kreiranje i korištenje sinonima 'LjudskiResursi'

CREATE SYNONYM LjudskiResursi FOR TestDB.dbo.Zaposlenik SELECT * FROM LjudskiResursi -- SELECT * FROM TestDB.dbo.Zaposlenik

Sinonime je moguće kreirati za uskladištene procedure, funkcije, tablice i poglede (Primjer

3.7.1). Štoviše, u trenutku kreiranja sinonima, stvarni objekt ne mora niti postojati već se

on provjerava tek prilikom referenciranja sinonima.

Upotrebom sinonima, aplikacije uvijek mogu koristiti iste upite prema bazi podataka.

Umjesto da se referenciraju na stvarne objekte, referenciranjem na sinonime uklanja se

potreba za modifikacijom aplikacije u slučaju promjene naziva stvarnih objekata. Tada je u

bazi podataka tek potrebno nanovo kreirati iste sinonime tako da ovaj puta referenciraju

na nova imena objekata.

U području sigurnosti i administracije sinonimi također imaju svoju ulogu. Potencijalni

napadač puno će teže doznati ime stvarnog objekta na osnovi imena sinonima, a pri

administraciji prava i dozvola korisniku se može omogućiti korištenje sinonima ne znajući

o kojem stvarnom objektu zaista riječ.



4. Organizacija i sigurnost

4.1. Sheme

U starijim inačicama SQL Servera svaki objekt morao je imati svog vlasnika (eng.

owner). Vlasnik objekta najčešće bi bio korisnik koji je kreirao objekt i imao je trajne

(nepovratne) ovlasti nad tim objektom. Problemi bi nastali kada bismo htjeli izbrisati

korisnika iz baze podataka jer tada bismo sve objekte u njegovom vlasništvu prethodno

trebali prebaciti u vlasništvo nekog drugog korisnika. Također, pojavio bi se i problem s

referenciranjem tih objekata (NoviVlasnik.Objekt) što dodatno zahtjeva i promjenu koda

unutar uskladištenih procedura, funkcija i aplikacija. [32]

Izlaskom SQL Servera 2005 uvode se sheme koje uvelike pojednostavljuju organizaciju,

administraciju i pristup objektima baze podataka. Shemu možemo zamisliti kao imenovani

prostor (eng. namespace) u kojemu se nalazi jedan ili više objekata. Svaki objekt baze

podataka može pripadati samo jednoj shemi (podrazumijevano dbo), a referencira ga se

upravo preko imena sheme kojoj pripada (Server.BazaPodataka.Shema.Objekt).

Slika 4.1.1. Primjer organizacije tablica po shemama

Sheme omogućuju organizaciju (grupiranje) objekata baze podataka bilo po namjeni,

sadržaju ili nekom drugom kriteriju. Tako u primjeru na Slici 4.1.1 postoje tri sheme:

HumanResources, Person i Production, a svaka od njih sadrži odgovarajuće tablice. Osim

tablica, sheme mogu sadržavati i poglede, uskladištene procedure, funkcije itd. Baza

podataka može sadržavati i više objekata s istim imenom, a u tom slučaju svaki od tih

objekata mora biti smješten u različitoj shemi.



Korištenjem SSMS alata, sve sheme u bazi podataka moguće je pronaći pregledom stavke

"Security / Schemas", a desnim klikom na tu stavku moguće je kreirati novu shemu.

Slika 4.1.2. Kreiranje sheme – naziv i vlasnik

Objekti pripadaju shemi, a svaka shema ima vlasnika (Slika 4.1.2). Ukoliko ne definiramo

vlasnika sheme, tada korisnik dbo podrazumijevano postaje njen vlasnik. Korisnik dbo

podrazumijevano uvijek postoji u bazi podataka i upravo zato ovakav pristup je najčešći. U

protivnom, za sve ostale korisnike vlasnike treba voditi računa o prijenosu vlasništva pri

pokušaju njihovog brisanja iz baze podataka.

Slika 4.1.3. Kreiranje sheme – ovlasti



Jedna od prednosti shema je i jednostavnija administracija. Umjesto da korisniku

definiramo ovlasti nad svakim objektom pojedinačno, možemo mu definirati ovlasti nad

shemom. Tada te ovlasti automatski ima i za sve objekte unutar te sheme.

Tako u primjeru na Slici 4.1.3 korisnik test_user ima ovlasti za izvršavanje uskladištenih

procedura te dodavanje, mijenjanje i dohvaćanje podataka iz svih objekata unutar sheme.

Korisnik test_user automatski dobiva navedene ovlasti i za svaki novi objekt unutar sheme,

dok se iste ovlasti mogu definirati i za skupine korisnika (eng. database role) te aplikacije

(eng. application role). Korisnicima je moguće odobriti (GRANT) ili zabraniti (DENY) neku

operaciju, a opcijom WITH GRANT omogućiti da tu operaciju odobre i drugim korisnicima.

Prilikom kreiranja sheme (i mnogih drugih tipova objekata) moguće je definirati i korisnički

definirana svojstava (eng. extended properties). To su tekstualno-opisna svojstva koja

imaju naziv i vrijednost, a koriste se kako bismo na dodatni način opisali kreirani objekt.

Primjerice, naziv svojstva može biti "Autor", a njegova vrijednost "Ante Antić".

Klikom na gumb "Script" (Slika 4.1.3) moguće je generirati T-SQL upit čijim će se

izvršavanjem kreirati shema s prethodno definiranim svojstvima i postavkama, kao u

Primjeru 4.1.1.

Primjer 4.1.1 – Kreiranje sheme izvršavanjem T-SQL upita

CREATE SCHEMA [MojaShema] GO GRANT EXECUTE ON SCHEMA::[MojaShema] TO [test_user] GRANT INSERT ON SCHEMA::[MojaShema] TO [test_user] GRANT SELECT ON SCHEMA::[MojaShema] TO [test_user] GRANT UPDATE ON SCHEMA::[MojaShema] TO [test_user]

Naziv odredišne sheme objekta definira se prilikom njegovog kreiranja, dok naredbom

TRANSFER možemo prebaciti objekt iz jedne sheme u drugu. Primjerice,

ALTER SCHEMA MojaShema TRANSFER dbo.Zaposlenik; -- MojaShema.Zaposlenik

Ukoliko se prilikom referenciranja objekta ne navede naziv sheme, SQL Server će prvo

potražiti taj objekt u korisnikovoj podrazumijevanoj shemi, a zatim u dbo shemi. Ukoliko

objekt i tada nije pronađen vraća se greška.



4.2. Prijavni nalozi

Prijavni nalog (eng. login) koristi se u svrhu autentifikacije i spajanja korisnika na

SQL Server. Svaki prijavni nalog može biti povezan s više korisničkih računa baza

podataka (jednim korisničkim računom po bazi), a oni se koriste za autorizaciju, odnosno

pristup bazama podataka.

Slika 4.2.1. Prijavni nalozi i korisnički računi baza podataka

U primjeru na Slici 4.2.1 prijavni nalog "Login 1" povezan je s tri korisnička računa baza

podataka. Nakon uspješne autentifikacije, korisnik je automatski autoriziran koristiti sve te

baze podataka sukladno pravima i dozvolama koje su definirane povezanim korisničkim

računima.

Odvajanje autentifikacije od autorizacije ima svoje prednosti prilikom, primjerice,

prebacivanja baze podataka s jedne instance SQL Servera na drugu. U tom slučaju

prebacit će se i svi korisnički računi baze podataka pa je u drugoj instanci potrebno tek

povezati prijavne naloge s tim prenesenim korisničkim računima.

Prijavni nalog kreira se na razini instance, a moguće ga je kreirati korištenjem SSMS alata

odabirom stavke "Security / Logins / New login…" ili izravno upotrebom T-SQLa.



Slika 4.2.2. Kreiranje prijavnog naloga upotrebom SSMS alata

Ime prijavnog naloga može biti ime postojećeg Windows korisnika ili skupine (Slika 4.2.2).

U tom slučaju koristi se Windows autentifikacija pa za takve korisnike nije potrebno

definirati lozinku. Ovakav tip autentifikacije najčešće se koristi u intranetskim mrežama,

dok nije pogodan za korisnike koji se nalaze u drugim domenama ili pristupaju SQL

Serveru preko interneta.

Za podršku najšireg spektra korisnika koristi se SQL Server autentifikacija. Korisničko ime

i lozinka spremaju se u SQL Serveru, a takvi korisnici mogu se autentificirati i spojiti na

SQL Server iz drugih domena, mreža ili preko interneta. Takvim korisnicima moguće je

nametnuti i pravila o lozinkama, poput da lozinka traje samo određeno vrijeme ili da ju

korisnik mora promijeniti pri sljedećoj prijavi. Pravila o lozinkama ne definiraju se u SQL

Serveru već u operacijskom sustavu server računala ("Start / Control Panel / Administrative

Tools / Local Security Policy"). [33]



Neovisno o načinu autentifikacije, svakom prijavnom nalogu moguće je definirati

podrazumijevanu bazu podataka i jezik. Loša je praksa za podrazumijevanu bazu

podataka ostaviti ponuđenu sistemsku master bazu jer bi korisnici u njoj najčešće

nepažnjom mogli izvršiti neželjene SQL upite.

Ukoliko odabrana podrazumijevana baza podataka nije dostupna (izbrisana je ili sl.)

autentifikacija neće biti moguća. Zato je u praksi čest slučaj da se za podrazumijevanu

bazu podataka odabire sistemska tempdb baza podataka jer ona uvijek postoji. Čak i da

korisnici izvršavaju neželjene upite u tempdb bazi podataka, potencijalna šteta je puno

manja nego da se ti upiti izvršavaju u master bazi podataka.

Prijavni nalog može pripadati jednoj ili više server uloga (eng. server roles). Njih možemo

zamisliti kao skupine korisnika koji imaju određene ovlasti na razini SQL Servera. Tako,

primjerice, članovi sysadmin uloge (skupine) nemaju nikakvih ograničenja i mogu raditi bilo

što u SQL Serveru. Uloga dbcreator omogućava korisnicima kreiranje novih baza

podataka, dok se securityadmin ulogom može kontrolirati sigurnost na SQL Serveru.

Postoje i druge unaprijed definirane (stalne) server uloge poput processadmin, diskadmin,

bulkadmin itd., a po potrebi se mogu kreirati i vlastite.

Slika 4.2.3. Kreiranje i povezivanje korisničkih računa baza podataka



Pri kreiranju prijavnog naloga moguće je kreiranje i povezivanje novih korisničkih računa

baza podataka. Tako je na Slici 4.2.3 prikazano povezivanje prijavnog naloga TestLogin s

bazama podataka TestDB i Posudba na način da se unutar njih kreiraju korisnički računi

koji imaju isto ime kao i prijavni nalog.

Svaki od ovih korisničkih računa može imati različito ime te može pripadati različitim

ulogama baza podataka (eng. database roles). Slično kao i server uloge koje služe za

kreiranje skupine korisnika na razini instance, tako postoje i uloge baza podataka, odnosno

skupine korisnika na razini pojedine baze podataka. I u ovom slučaju postoje unaprijed

definirane (stalne) uloge poput db_datareader, db_datawritter, db_owner itd. (Slika 4.2.3),

a mogu se kreirati i nove. Tako će se primjerom na Slici 4.2.3 u bazi podataka TestDB

kreirati novi korisnički račun TestLogin koji će pripadati db_datareader ulozi, tj. automatski

će imati ovlasti čitati podatke iz te baze podataka.

Potrebno je primijetiti da se korisnički račun može istovremeno dodijeliti ulogama

db_datareader i db_denydatareader te ulogama db_datawritter i db_denydatawritter.

Primjerice, skupini korisničkih računa (ulozi) Profesori omogućeno je čitanje svih podataka

(db_datareader), ali jednom dijelu te skupine (npr. podgrupi VanjskiSuradnici) čitanje

podataka je zabranjeno (db_denydatareader). Ukoliko je profesor Ante član podgrupe

VanjskiSuradnici, prevladat će zabrana (DENY) iako je ta podgrupa član grupe Profesori.

Prijavnom nalogu moguće je dodijeliti ovlasti na razini servera (stavke "Securables" i

"Status"). Primjerice, to mogu biti ovlasti za spajanje i gašenje servera, pregled, kreiranje i

izmjenu baza podataka, izmjenu prijavnih naloga itd.

SSMS aplikacija u konačnici će kreirati odgovarajući prijavni nalog sa svim novim

povezanim korisničkim računima baza podataka i odabranim postavkama. Alternativno,

mogli smo i samostalno napisati odgovarajući T-SQL upit za kreiranje tog prijavnog naloga,


Primjer 4.2.1 – Kreiranje prijavnog naloga izvršavanjem T-SQL upita

USE [master] CREATE LOGIN [TestLogin] WITH PASSWORD=N'12345', DEFAULT_DATABASE=[TestDB], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF



GO USE [Posudba] GO CREATE USER [TestLogin] FOR LOGIN [TestLogin] GO USE [TestDB] GO CREATE USER [TestLogin] FOR LOGIN [TestLogin]

U slučaju potrebe brisanja ili izmjene prijavnog naloga ili korisničkih računa, opet se koriste

naredbe DROP i ALTER. Međutim, brisanjem prijavnog naloga ne brišu se i povezani

korisnički računi. Oni postaju siročad (eng. orphaned users), te ih je tada moguće povezati

s drugim prijavnim nalozima.

4.3. Korisnički računi

Korisničkim računima vrši se autorizacija, odnosno dodjeljivanje prava i dozvola za

rad u bazi podataka. Najčešće se koriste u kombinaciji s prijavnim nalozima gdje se nakon

uspješne autentifikacije, ovisno o povezanim korisničkim računima, korisniku dodjeljuju

prava i dozvole nad jednom ili više baza podataka. Korisnički računi smješteni su unutar

baze podataka, a može ih biti čak 11 tipova. [34]

SSMS alat podrazumijevano će ponuditi izradu korisničkog računa baze podataka za

sljedeće tipove korisnika:

▪ Windows korisnik

▪ SQL korisnik s prijavnim nalogom

▪ SQL korisnik bez prijavnog naloga

▪ Korisnik povezan s certifikatom

▪ Korisnik povezan s asimetričnim ključem

Prva dva standardni su tipovi korisnika, dok su ostali tipovi korisnika posebne namjene.

Također, izlaskom SQL Servera 2012, baze podataka moguće je pretvoriti u djelomično

neovisne baze podataka (eng. partially contained databases). One su minimalno ovisne o

instanci SQL Servera te zato sadrže i korisničke račune s lozinkama (eng. SQL user with

password). Pomoću takvih korisničkih računa može se vršiti i autentifikacija korisnika bez

potrebe korištenja prijavnog naloga koji se nalazi na serveru.



Slika 4.3.1. Kreiranje korisničkog računa baze podataka upotrebom SSMS alata

Ukoliko korisnički račun baze podataka nije kreiran prilikom kreiranja prijavnog naloga

(Slika 4.2.3), moguće ga je kreirati naknadno upotrebom T-SQLa ili u SSMS alatu odabirom

stavke "<BAZA_PODATAKA> / Security / Users / New user…". Tada se pojavljuje dijalog

kao na Slici 4.3.1 u kojemu je prvo potrebno odabrati odgovarajući tip korisnika.

Najčešće će korisnički račun baze podataka biti kreiran na osnovu postojećeg Windows

korisnika ili skupine, ili će biti riječ o SQL korisniku s prijavnim nalogom (Slika 4.3.1). Oba

tipa korisničkih računa povezuju se s prijavnim nalogom, a mogu biti vlasnici jedne ili više

shema te članovi jedne ili više uloga baze podataka.

Slika 4.3.2. Dodjela dozvola korisničkom računu baze podataka



Autorizacija, odnosno prava i dozvole u bazi podataka, dodjeljuju se unutar stavke

"Securables". Tako u primjeru na Slici 4.3.2 novom korisniku Ante bit će dodijeljena

dozvola izvršavanja SELECT upita nad tablicom Student. Štoviše, budući da je riječ o

tablici možemo tu dozvolu dodijeliti na razini pojedinog stupca tablice klikom na gumb

"Column Permissions…". Tada se pojavljuje dijalog kao na Slici 4.3.3.

Slika 4.3.3. Dodjela SELECT dozvole na razini stupca

Iako će korisnik Ante imati dozvolu izvršavanja SELECT upita nad tablicom Student, ta

dozvola se u ovom slučaju neće odnositi na stupac Ime (Slika 4.3.3). Zbog toga neće biti

moguće izvršiti upit SELECT * FROM Student, već će se u SELECT naredbi moći navesti

samo oni stupci nad kojima korisnika Ante ima dozvolu.

Primjer 4.3.1 – Kreiranje korisničkog računa baze podataka izvršavanjem T-SQL upita

USE [TestDB] CREATE USER [Ante] FOR LOGIN [Login1] DENY SELECT ON [dbo].[Student] ([Ime]) TO [Ante] -- Zabrana za stupac 'Ime'! GRANT SELECT ON [dbo].[Student] ([izmjena_DatumVrijeme]) TO [Ante] GRANT SELECT ON [dbo].[Student] ([izmjena_Korisnik]) TO [Ante] GRANT SELECT ON [dbo].[Student] ([JMBAG]) TO [Ante] GRANT SELECT ON [dbo].[Student] ([Prezime]) TO [Ante]

U konačnici, SSMS alat generirat će i izvršiti skriptu za kreiranje korisničkog računa Ante

koja izgleda kao u Primjeru 4.3.1.



Od korisnika posebne namjene vrlo često se upotrebljava SQL korisnik bez prijavnog

naloga (eng. SQL user without login). Koristi se kao alternativa aplikacijskoj ulozi (eng.

application role) tj. najčešće kada je riječ o autorizaciji klijent aplikacija. Ovakav tip

korisničkog računa nema lozinku već se pomoću impersonacije prelazi u sigurnosni

kontekst nekog drugog korisničkog računa koji ima sva potrebna prava i dozvole.

Primjer 4.3.1 – Kreiranje i korištenje korisničkog računa bez prijavnog naloga

USE [master] CREATE LOGIN [Login1] WITH PASSWORD=N'12345', DEFAULT_DATABASE=[tempdb] DENY VIEW ANY DATABASE TO [Login1] GO USE [TestDB] CREATE USER [User1] FOR LOGIN [Login1] -- User1 povezan s prijavnim nalogom CREATE USER [User2] WITHOUT LOGIN -- User2 bez prijavnog naloga! -- User2 ima ovlasti za čitanje podataka iz tablice! GRANT SELECT ON [dbo].[Student] TO [User2] -- User1 može impersonirati korisnika User2 GRANT IMPERSONATE ON USER::User2 to User1

Kada se korisnik (aplikacija) prijavi na server korištenjem prijavnog naloga Login1

kreiranog u Primjeru 4.3.1 moći će pročitati sve zapise iz tablice Student na sljedeći način:

USE TestDB EXECUTE AS USER = 'User2' -- Izvrši upite u sigurnosnom kontekstu korisnika User2 SELECT * FROM Student -- Uspješno izvršen upit!

Prijavni nalog Login1 povezan je s korisničkim računom User1 koji nema nikakve ovlasti u

TestDB bazi podataka. Unatoč tome, korisnik će uspjeti pristupiti željenim podacima

(popisu studenata) tako što će upit biti izvršen u sigurnosnom kontekstu korisnika User2

koji ima dozvolu dohvata podataka (SELECT) u tablici Student.

4.4. Uloge

Slično kao i sheme u bazi podataka koje se koriste za grupiranje objekata, uloge

(eng. roles) najčešće se koriste za grupiranje korisnika. Pomoću uloga (skupina)

jednostavnije je organizirati i administrirati korisnike jer im se prava i dozvole mogu

automatski dodijeliti na osnovi članstva u nekoj ulozi.



U SQL Serveru moguće je kreirati tri tipa uloga:

▪ Serverske uloge (eng. server roles)

▪ Uloge baze podataka (eng. database roles)

▪ Aplikacijske uloge (eng. application roles)

Primjerice, umjesto da svakom zaposleniku odjela informatičke podrške na razini prijavnog

naloga ili korisničkog računa dodjeljujemo ista prava i dozvole kao i ostalim zaposlenicima

tog odjela, možemo ga dodijeliti ulozi "IT_Podrska". Samim članstvom u toj ulozi zaposlenik

može imati ista prava i dozvole na serveru (ili u bazi podataka) kao i ostali članovi te uloge.

Slika 4.4.1. Kreiranje server uloge "IT_Podrska"

Serverskom ulogom definira se skupina članova koja ima prava i dozvole na razini SQL

Server instance, a članovi serverske uloge mogu biti prijavni nalozi i druge serverske uloge.

U primjeru na Slici 4.4.1 svi zaposlenici (prijavni nalozi) odjela informatičke podrške imat

će prava i dozvole za zaustavljanje rada instance SQL Servera (Shutdown), za pregled

popisa svih baza podataka (View any database) i definicije objekata (View any definition)



te za uvid u stanje označene instance (View server state). Među ostalim, server ulogom

moguće je dodijeliti prava i dozvole za upravljanje pristupnim točkama (eng. endpoints),

prijavnim nalozima itd.

Slika 4.4.2. Članovi server uloge "IT_Podrska"

Bilo pri kreiranju nove ili uređivanju postojeće serverske uloge, moguće joj je dodijeliti nove

članove odabirom stavke "Members", kao na Slici 4.4.2. Također, ukoliko je potrebno da

navedena serverska uloga bude član neke druge serverske uloge (njena poduloga) to se

može definirati u stavci "Membership".

Primjer 4.4.1 – Kreiranje server uloge "IT_Podrska" izvršavanjem T-SQL upita

USE [master] CREATE SERVER ROLE [IT_Podrska] ALTER SERVER ROLE [IT_Podrska] ADD MEMBER [Login1] GRANT SHUTDOWN TO [IT_Podrska] GRANT VIEW ANY DATABASE TO [IT_Podrska] GRANT VIEW ANY DEFINITION TO [IT_Podrska] GRANT VIEW SERVER STATE TO [IT_Podrska]

Za kreiranje serverske uloge "IT_Podrska", SSMS alat generirat će i izvršiti T-SQL upit kao

u Primjeru 4.4.1.

Svaka SQL Server instanca ima već unaprijed definiran niz stalnih serverskih uloga koje

se mogu iskoristiti pri dodjeljivanju najčešćih administrativnih prava i dozvola. Stalne

serverske uloge ne mogu se mijenjati već im je tek moguće kontrolirati članstvo. Neke od

njih već su opisane u poglavlju 4.2, a Slikom 4.4.3 prikazane su i ostale.



Slika 4.4.3. Stalne serverske uloge i njihove dozvole [35]

Jednako tako, za grupiranje i lakšu administraciju korisničkih računa baze podataka koriste

se uloge baze podataka (eng. database roles). Osim korisničkih računa, članovi te uloge

mogu biti i druge (pod)uloge baze podataka.

Slika 4.4.4. Dodjela prava i dozvola ulozi baze podataka



Kao i obični korisnik, uloga baze podataka može biti vlasnik sheme. Mogu joj se dodijeliti

prava i dozvole nad bazom podataka općenito, nad skupinama objekata (shemama) ili

zasebno nad svakim pojedinim objektom baze podataka (Slika 4.4.4).

Sva prava i dozvole dodijeljene ulozi baze podataka automatski se dodjeljuju i njenim

članovima. Izuzetak su situacije u kojima pojedini član uloge ima eksplicitnu zabranu

(DENY) za korištenje i pristup nekom resursu. U tom slučaju uvijek će prevladati zabrana,

bez obzira na eventualnu dozvolu (GRANT) dodijeljenu ulogom.

Slika 4.4.5. Stalne uloge baze podataka i njihove dozvole [36]

Kada god je to moguće korisnička prava i dozvole poželjno je dodjeljivati članstvom u ulozi

jer se tako pojednostavljuje i ubrzava administracija. Zbog toga, kao i u slučaju serverskih

uloga, svaka baza podataka sadrži niz stalnih uloga (Slika 4.4.5). Ukoliko korisnik nije



prikladan za članstvo niti u jednoj od tih uloga, može se kreirati nova ili se prava i dozvole

tom korisniku mogu dodijeliti eksplicitno, izvan uloge.

Baza podataka može sadržavati i aplikacijske uloge (eng. application roles). Za razliku od

serverskih uloga i uloga baze podataka, one ne služe za grupiranje određenog tipa

korisnika već za autorizaciju klijent aplikacija. Svaka aplikacija trebala bi se autorizirati

preko jedne aplikacijske uloge, pri čemu aplikacija mora znati naziv uloge i njenu lozinku.

Slika 4.4.6. Kreiranje aplikacijske uloge "Blagajna"

Ukoliko pretpostavimo da klijent aplikacija "Blagajna" želi imati određena prava i dozvole u

bazi podataka, za nju možemo kreirati aplikacijsku ulogu (Slika 4.4.6). Sva prava i dozvole

za aplikaciju definirale bi se korištenjem stavke "Securables", a proces autorizacije

izgledao bi ovako:

1) Aplikacija se spaja na bazu podataka pomoću prijavnog naloga koji je povezan s

korisničkim računom željene baze podataka. Iz sigurnosnih razloga tom korisničkom

računu baze podataka ne dodjeljuju se nikakva prava i dozvole!

2) Da bi aplikacija dobila potrebna prava i dozvole treba se autorizirati postojećom

aplikacijskom ulogom. U tu svrhu iz aplikacije poziva se i izvršava sistemska



uskladištena procedura sp_setapprole. Njoj se kao argumenti predaju naziv

aplikacijske uloge, njena lozinka i enkripcija (none), nakon čega aplikacija dobiva

sva prava i dozvole definirane tom aplikacijskom ulogom.

Ukoliko bi uljez i uspio doći do pristupnih podataka sadržanih u izrazu "Connection string",

od njih ne bi imao koristi jer mu ne pružaju nikakve dozvole u bazi podataka. Uz te podatke

trebao bi mu dodatno i naziv aplikacijske uloge te njena lozinka koji su poznati samo

aplikaciji te nisu dio izraza "Connection string".

Ipak, ukoliko na razvoju aplikacije radi više programera, lozinku aplikacijske uloge najčešće

će trebati mijenjati kada jedan od tih programera napusti projekt. U tom slučaju mora se

mijenjati i aplikacija, pa se zbog toga umjesto aplikacijskih uloga danas češće koriste

korisnički računi baza podataka bez prijavnog naloga i lozinke, kao u Primjeru 4.3.1.

4.5. Kriptografija u SQL Serveru

Dodjeljivanjem odgovarajućih prava i dozvola moguće je ograničiti pristup

podacima. Ipak, uljezi dosta često korištenjem socijalnog inženjeringa i drugih metoda

uspijevaju doći do korisničkih podataka, pa u tom trenutku imaju pristup i potencijalno

osjetljivim podacima koji se nalaze u bazi podataka (osobni podaci kupaca, lozinke, brojevi

kreditnih kartica itd.). Da bi se izbjegla takva šteta, osjetljive podatke uvijek je poželjno

dodatno zaštiti. U tu svrhu SQL Server omogućuje korištenje funkcija sažimanja (eng.

hash) te simetričnih i asimetričnih kriptografskih algoritama.

Funkcije sažimanja koriste se kao jednosmjerni kriptografski algoritmi bez ključa. Kada se

neki sadržaj (tekst, datoteka ili sl.) kriptira funkcijom sažimanja više nije moguće u realnom

vremenu iz kriptiranog sadržaja dobiti nazad izvorni sadržaj. Zbog toga se funkcije

sažimanja često koriste za zaštitu lozinki.

Rezultat funkcije sažimanja mora biti jedinstven te uvijek isti za pojedinu ulaznu vrijednost,

a bez obzira na veličinu ulaznog podatka funkcija sažimanja kao rezultat uvijek mora vratiti

binarni zapis iste veličine.



Pri odabiru funkcije sažimanja treba uzeti u obzir da se zbog već otkrivenih slabosti i

nedostataka mnoge od njih danas više ne koriste. Tako se primjerice funkcije MD4, MD5 i

SHA-1 zbog otkrivenih kolizija i uspješnih metoda napada danas više ne smatraju dovoljno

sigurnima, već se umjesto njih preporučuju SHA-2 i SHA-3 funkcije.

SQL Server 2016 omogućuje korištenje funkcija MD2, MD4, MD5, SHA-0, SHA-1, SHA-2

(256) i SHA-2 (512). Sve osim SHA-2 funkcija smatraju se zastarjelima te će se pri

njihovom korištenju javiti upozorenje. [37]

Primjer 4.5.1 – Zaštita lozinki korištenjem SHA2 – 256 funkcije

-- Kreiranje tablice 'Korisnik' CREATE TABLE [dbo].[Korisnik]( [ID] [int] IDENTITY(1,1) NOT NULL, [Ime] [nvarchar](50) NULL, [Lozinka] [varbinary](256) NULL, PRIMARY KEY (ID) ) GO -- Kreiranje uskladištene procedure za dodavanje novog korisnika CREATE PROCEDURE DodajKorisnika (@Ime varchar(50), @Lozinka varchar(256)) AS BEGIN INSERT INTO Korisnik (Ime, Lozinka) VALUES (@Ime, HASHBYTES('SHA2_256', @Lozinka)) END

Izvršavanjem T-SQL koda iz Primjera 4.5.1 stvorit će se tablica "Korisnik" s tri stupca. Iako

je svaka lozinka zapravo niz znakova otvorenog teksta, stupac "Lozinka" definiran je kao

VARBINARY (binarni) tip jer se u njemu neće spremati otvoreni tekst već rezultat funkcije

sažimanja odnosno binarni zapis. Primjerice,

EXEC DodajKorisnika 'User1', 'TajnaLozinka' SELECT Lozinka FROM Korisnik WHERE Ime = 'User1' -- 0x9453CAAD51A1C84C917B9C57BAB7C7401405179F1509E925AD13803DBC5E5471

Pri provjeri lozinke klijent aplikacija računa rezultat sažimanja unesene lozinke te ga

uspoređuje s rezultatom sažimanja koji je spremljen u bazi podataka. Ukoliko su oba

rezultata identična lozinka je ispravna. U protivnom korisnik će najčešće ponovno morati

unijeti lozinku. Kako je rezultat sažimanja (lozinka) spremljen kao binarni zapis najčešće

ga se predstavlja u heksadecimalnom obliku, u kojem je prikladan i za uspoređivanje.



Da bi se spriječilo lako otkrivanje rezultata funkcije sažimanja često se koristi i metoda

"soljenja" otvorenog teksta (Primjer 4.5.2).

Primjer 4.5.2 – "Soljenje" otvorenog teksta

DECLARE @Lozinka varchar(256) = 'Lozinka' DECLARE @Sol varchar(256) = 'DodatakNaKrajLozinkeOtvorenogTeksta' SELECT HASHBYTES('SHA2_256', @Lozinka + @Sol)

Fiksni niz znakova veće duljine (sol) može se dodati prije, poslije ili negdje u sredini

otvorenog teksta (lozinke), nakon čega se sve spojeno kriptira funkcijom sažimanja. Na

identičan način "sol" se treba koristi i pri provjeri unesene lozinke.

Funkcije sažimanja korisne su u ovakvim situacijama gdje podatke nije potrebno vraćati u

izvorni oblik. U protivnom, umjesto funkcija sažimanja potrebno je koristiti simetrične i

asimetrične kriptografske algoritme.

Simetrični kriptografski algoritmi koriste jedan tajni ključ. Jednom kriptiran, sadržaj se može

dekriptirati 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č svima je dostupan, a sadržaj kriptiran javnim ključem

može biti dekriptiran samo odgovarajućim privatnim ključem kojeg posjeduje samo osoba

kojoj je poruka namijenjena.

Slika 4.5.1. Hijerarhija ključeva u SQL Serveru [38]



Za korištenje kriptografskih algoritama u SQL Serveru potrebno je slijediti hijerarhiju

ključeva (Slika 4.5.1). Primjerice, pretpostavimo da tablica "Kupac" sadrži stupac

"BrojKreditneKartice". Kako je taj podatak osjetljiv potrebno ga je zaštiti kriptiranjem, i to

na način da je po potrebi moguće pročitati izvorni sadržaj, tj. broj kreditne kartice. Zbog

toga u ovom slučaju nije moguće koristiti funkcije sažimanja već možemo upotrijebiti

simetrični kriptografski algoritam AES-256.

Primjer 4.5.3 – Implementacija hijerarhije ključeva

USE TestDB -- 0) Kreiranje tablice 'Kupac' CREATE TABLE [dbo].[Kupac]( [ID] [int] IDENTITY(1,1) NOT NULL, [OIB] [nvarchar](50) NULL, [BrojKreditneKartice] [varbinary](4000) NULL, PRIMARY KEY (ID) ) GO -- 1) Kreiranje glavnog ključa baze podataka CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MasterKeyPass' GO -- 2) Kreiranje asimetričnog ključa kriptiranog glavnim ključem baze podataka CREATE ASYMMETRIC KEY MojAsimetricniKljuc WITH ALGORITHM = RSA_2048 GO -- 3) Kreiranje simetričnog ključa kriptiranog asimetričnim ključem CREATE SYMMETRIC KEY MojSimetricniKljuc WITH ALGORITHM = AES_256 ENCRYPTION BY ASYMMETRIC KEY MojAsimetricniKljuc GO

Stupac "BrojKreditneKartice" sadržavat će kriptiranu vrijednost, pa je stoga VARBINARY

tipa (Primjer 4.5.3). Za kriptiranje tog stupca koristit će se AES-256 algoritam pomoću

simetričnog ključa "MojSimetricniKljuc". Da bi se zaštitio taj simetrični ključ kreiran je

asimetrični ključ "MojAsimetricniKljuc" s algoritmom RSA (2048) čiji je privatni ključ također

potrebno zaštiti. Podrazumijevano, štiti ga se pomoću glavnog enkripcijskog ključa baze

podataka (eng. database master key, DMK) kao u Primjeru 4.5.3 ili proizvoljno definiranom

lozinkom.

Primjer 4.5.4 – Asimetrični ključ kriptiran proizvoljno definiranom 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 definiranom lozinkom

nije nužno potrebno kreirati i koristiti DMK ključ. Ipak, iz sigurnosnih razloga to nije

preporučljivo jer korištenjem DMK ključa dodaju se nove razine enkripcije budući da je i

sam DMK ključ dodatno zaštićen ključem instance SQL Servera (eng. service master key,

SMK) i lozinkom.

Primjer 4.5.5 – Izrada rezervnih kopija SMK i DMK ključeva

-- Rezervna kopija servisnog ključa BACKUP SERVICE MASTER KEY TO FILE = 'C:\SQLServer_Backup\SMK_backup.bak' ENCRYPTION BY PASSWORD = 'ServiceBackupPass' -- Rezervna kopija glavnog ključa baze podataka BACKUP MASTER KEY TO FILE = 'C:\SQLServer_Backup\DMK_backup.bak' ENCRYPTION BY PASSWORD = 'DatabaseBackupPass'

Na disku je uvijek poželjno imati rezervne kopije SMK i DMK ključeva (Primjer 4.5.5) te

korištenih certifikata. U slučaju gubitka tih ključeva ili certifikata, bez njihovih rezervnih

kopija nije moguće dekriptirati simetrične i asimetrične ključeve unutar baza podataka, pa

time i dekriptirati podatke.

DMK ključ nalazi se u dvije baze podataka – u sistemskoj bazi podataka master gdje je

zaštićen SMK ključem te u lokalnoj bazi podataka gdje je zaštićen lozinkom koja je

definirana pri kreiranju tog ključa.

Primjer 4.5.6 – Korištenje simetričnog kriptografskog algoritma

-- Otvaranje simetričnog ključa USE TestDB OPEN SYMMETRIC KEY MojSimetricniKljuc DECRYPTION BY ASYMMETRIC KEY MojAsimetricniKljuc GO -- Umetanje kriptiranog sadržaja INSERT INTO Kupac(OIB, BrojKreditneKartice) VALUES ('111111', ENCRYPTBYKEY(KEY_GUID('MojSimetricniKljuc'), '1234-5678-9012')) GO -- Sadržaj kriptiranog stupca SELECT BrojKreditneKartice FROM Kupac WHERE OIB = '111111' -- 0x00FE30C185C69B42BF5D0D0432F8F518010000004B926B64E5... GO -- Dekriptiranje podataka SELECT CONVERT(VARCHAR(50), DECRYPTBYKEY(BrojKreditneKartice)) FROM Kupac WHERE OIB = '111111' -- 1234-5678-9012

Nakon implementacije željene hijerarhije ključeva iz Primjera 4.5.3 moguće je koristiti

simetrični ključ "MojSimetricniKljuc" za kriptiranje i dekriptiranje brojeva kreditnih kartica iz



tablice "Kupac" (Primjer 4.5.6). Simetrični ključ prvo je potrebno otvoriti, a nakon toga za

kriptiranje i dekriptiranje sadržaja koristiti funkcije ENCRYPTBYKEY i DECRYPTBYKEY.

Odgovarajuće inačice ovih funkcija postoje i u slučajevima kada se za kriptiranje i

dekriptiranje koriste certifikati i asimetrični kriptografski algoritmi.

Moglo se odabrati i neki drugi plan. Primjerice, stupac "BrojKreditneKartice" mogao je

izravno biti kriptiran asimetričnim ključem, ali zbog brzine i performansi baze podataka to

nije preporuka. Također, za zaštitu simetričnog ključa mogli smo umjesto asimetričnog

ključa kreirati certifikat itd.

4.6. Transparentna enkripcija podataka

Osim pojedinih stupaca, moguće je kriptirati i kompletnu bazu podataka korištenjem

transparentne enkripcije podataka (eng. transparent data encryption, TDE). Cilj je ove

enkripcije zaštiti podatke u slučaju krađe pa se u tu svrhu kriptiraju sve datoteke baze

podataka, uključujući dnevnik transakcija i datoteke rezervnih kopija.

Slika 4.6.1. Arhitektura transparentne enkripcije podataka [39]



Za kriptiranje sadržaja baze podataka i njenih datoteka koristi se simetrični algoritam čiji

se ključ (Database Encryption Key, DEK) kriptira certifikatom smještenim u master bazi

podataka ili asimetričnim ključem smještenim u EKM (eng. extensible key management)

modulu (Slika 4.6.1). Bez tog certifikata (ili asimetričnog ključa) uljez neće moći dekriptirati

DEK pa time niti sadržaj baze podataka.

Primjer 4.6.1 – 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

Prije korištenja TDE-a potrebno je pobrinuti se da u master bazi podataka postoji DMK

ključ i certifikat koji će biti zaštićen tim ključem (Primjer 4.6.1). Tek nakon toga moguće je

generirati DEK ključ i kriptirati bazu podataka.

Slika 4.6.2. Kriptiranje baze podataka (TDE) SSMS alatom

Nakon kreiranja certifikata uvijek je poželjno izraditi njegovu rezervnu kopiju jer se u slučaju

gubitka certifikata neće moći dekriptirati DEK ključevi zaštićeni tim certifikatom. Ukoliko



prije uključivanja TDE-a rezervna kopija certifikata ne postoji javit će se upozorenje poput

onoga na Slici 4.6.2.

Kriptiranje baze podataka korištenjem TDE-a može se inicirati SSMS alatom tako da se

desnim klikom na željenu bazu podataka odabere stavka "Tasks / Manage Database

Encryption". Tada se pojavljuje dijalog kao na Slici 4.6.2, gdje se prilikom klika na gumb

"OK" generira i izvršava sljedeći T-SQL kod.

Primjer 4.6.2 – Kreiranje DEK ključa i kriptiranje baze podataka

-- Kreiranje DEK ključa TestDB baze podataka kriptiranog certifikatom USE TestDB; GO CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE TDE_Certifikat; GO -- Uključi kriptiranje baze podataka DEK ključem ALTER DATABASE TestDB SET ENCRYPTION ON; GO

Izvršavanjem upita iz Primjera 4.6.2 kreira se DEK ključ zaštićen server certifikatom te se

njime u konačnici kriptira TestDB baza podataka. Ukoliko bi uljez ukrao TestDB bazu

podataka (TestDB.mdf, TestDB.ldf itd.) te ju pokušao pripojiti svojoj instanci dobio bi

poruku kao na Slici 4.6.3.

Slika 4.6.3. Greška: nije pronađen odgovarajući certifikat

U master bazi podataka uljeza neće postojati odgovarajući certifikat za dekriptiranje DEK

ključa ukradene baze podataka pa ju uljez neće moći dekriptirati i pripojiti svojoj instanci

SQL Servera. Greška kao na Slici 4.6.3 dogodit će se i ukoliko uljez pokuša doći do

podataka obnovom ukradene rezervne kopije.



4.7. Uvijek kriptirani podaci

Izlaskom SQL Servera 2016 sadržaj pojedinih stupaca tablice moguće je zaštiti

korištenjem značajke "Always Encrypted". Ova značajka omogućuje klijent aplikacijama

čitanje i obradu kriptiranog sadržaja u čitljivom, dekriptiranom obliku, dok se prilikom

spremanja izmjena ti podaci kriptiraju prije slanja nazad u bazu podataka.

Upotrebom ove značajke, baza podataka u svakom trenutku sadrži kriptirane podatke koje

ne mogu dekriptirati niti korisnici s najvećim ovlastima 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 trebaju imati uvid u njih (korisnici). [40]

Osim korištenjem T-SQL izjava, značajku "Always Encrypted" moguće je konfigurirati i

pomoću ugrađenog čarobnjaka u SSMS alatu minimalne inačice 17.0. Pokreće se desnim

klikom na ime tablice ili stupca tablice te odabirom stavke "Encrypt Columns…".

Slika 4.7.1. Generiranje certifikata i glavnog ključa stupaca (CMK)

Sadržaj pojedinog stupca kriptira se ključem stupca (eng. column encryption key, CEK), a

ključevi stupaca kriptiraju se glavnim ključem stupaca (eng. column master key, CMK).



Ključevi stupaca spremljeni su unutar instance SQL Servera, a glavni ključ stupaca sprema

se u nekom vanjskom resursu kao što je osobni certifikat. Nakon odabira destinacijskog

certifikata (ili kreiranja novog) moguće je kreirati i spremiti CMK ključ (Slika 4.7.1).

Da bismo kreirali CMK ključ, možemo koristiti SSMS alat koji će se generirati i izvršiti T-

SQL kod na uzoru iz Primjera 4.7.1.

Primjer 4.7.1 – Kreiranje CMK ključa

USE [TestDB] /****** Object: ColumnMasterKey [CMK] CREATE COLUMN MASTER KEY [CMK] WITH ( KEY_STORE_PROVIDER_NAME = N'MSSQL_CERTIFICATE_STORE', KEY_PATH = N'CurrentUser/My/63FEFDE48A2F7099DAAD246B6ADDCAA9692CF093' ) GO

SQL Server sadrži tek metapodatke koji ukazuju na lokaciju CMK ključa (Primjer 4.7.1), a

nakon njegovog kreiranja potrebno je kreirati i barem jedan ključ stupca (CEK).

Slika 4.7.2. Generiranje ključa stupca

Za potrebe primjera pretpostavimo da želimo kriptirati stupac "BrojKreditneKartice" tipa

varchar(50). U tu svrhu kreirat ćemo CEK ključ "CEK_KreditnaKartica" koji će biti kriptiran

prethodno generiranim CMK ključem (Slika 4.7.2).

Primjer 4.7.2 – Kreiranje CEK ključa

USE [TestDB] CREATE COLUMN ENCRYPTION KEY [CEK_KreditnaKartica] WITH VALUES



( COLUMN_MASTER_KEY = [CMK], ALGORITHM = 'RSA_OAEP', ENCRYPTED_VALUE = 0x016E000001630075007200720065006E00740075007300650072002F006D0079002F003600330066006500660064006500340038006100320066003700300039003900640061006100640032003400360062003600610064006400630061006100390036003900320063006600300039003300A17E2E6CC56BF1D80604098F7AB06EA39892D6A9CFF108E41D9CE1942846887037D9D25311EF3467297C34B31E1F0421256467E9B37D87BDBA427B8306DB1C4EA1E2FFBE3F9D97268490D99547ADA0C607D2A8529E7E4AAF5E328079FA845DF04F454B4BC150F2E75B90B6B9258A50243D7A7EB9616D069F98F9AB156A5AFEE841384CC51B8824B402A2D2654594E9734DE1C509EEFA0A9E0E585BADD1B506A126CD5AEF42E5D1464052A2F6933A1D83A07AC1DD5556515A821C90FF145AB362269D9AC595AC87770D23AF43D983D5530B63B3649149934B984C7DE1D8EB593A3CFF93FCF8D9D96F4CC358A5A7FF2463AED4ED0BC506C2FDD06BE1EC1311B13669F0619FA5A93BC7BA83AEDB4CBB2BE015E0D51CE057885106262AF074397E047AECA7A2D5B5CFD4BAE026B36E9AA939A63EC5B47D10CBBB5B4D93053E013FB59C0ABE168CB974EB0D7D3AE643D5F8ABEE1FE9F3F754C87BE6CC0E74049FFDA6A718C7469401D06C5A294C7B75A6220B004D6A7877B2055CDD95B29F2EEA46F90C1F1E6EAE31A384DE0D7526F9289227BEA06767332033DD7E831482F6BCD1EFDF4CFF07A16DD08476DA4FC7F0E79504476BBB4C484D8AD523A61E7177B2B2CF55BB475FD8B6802FB70DCB1F3A6C85E8B0B553FF6589533A680391D5CA548FEF582F486857759A503B83063B0954C87B2429086B23D3E0EE0242C88B98009D0D )

SQL Server ima uvid u kriptiranu vrijednost CEK ključa te algoritam kojim je ključ kriptiran

(Primjer 4.7.2). Međutim, za njegovo dekriptiranje bit će potreban CMK ključ, odnosno

certifikat u kojem je spremljen.

Slika 4.7.3. Odabir stupca za kriptiranje

Nakon što postoji CMK i barem jedan CEK ključ može se pristupiti kriptiranju sadržaja

stupaca (Slika 4.7.3). Jednim CEK ključem moguće je kriptirati sve stupce tablice, a svaki



od stupaca može biti kriptiran determinističkim ili slučajnim tipom ključa. Ključevi

determinističkog tipa uvijek će generirati istu kriptiranu vrijednost za jedan podatak, dok će

se korištenjem slučajnog tipa ključa uvijek generirati različita kriptirana vrijednost za isti

podatak. Deterministički ključ dozvoljava operacije poput grupiranja, filtriranja i spajanja

tablica, ali manje je siguran od slučajnog tipa ključa. Primjerice, u situacijama kada stupac

sadrži podatke poput spola osobe (M/Z) ili vrijednosti tipa True/False svakako je preporuka

koristiti slučajni tip ključa.

Za primjer uzmemo sljedeći sadržaj tablice "Kupac":

ID OIB BrojKreditneKartice

1 111111 1111-2222-3333-4444

2 222222 2222-3333-4444-5555

Nakon korištenja čarobnjaka "Always Encrypted" s postavkama kao na Slici 4.7.3 definicija

stupca "BrojKreditneKartice" bit će izmijenjena (Primjer 4.7.3).

Primjer 4.7.3 – Definicija kriptiranog stupca "BrojKreditneKartice"

[BrojKreditneKartice] [varchar](50) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = [CEK_KreditnaKartica], ENCRYPTION_TYPE = Deterministic, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL

Ukoliko sada pokušamo dohvatiti sadržaj tablice "Kupac" naredbom SELECT kao rezultat

dobit ćemo kriptirane podatke u stupcu "BrojKreditneKartice".

ID OIB BrojKreditneKartice

1 111111 0x011A51BB80E9EFE9DE45952ED5C1E3….

2 222222 0x012C1EE64B88B4C886150AF7F91C20D….

Da bi klijent aplikacije mogle vidjeti dekriptirani oblik tih podataka, moraju koristiti jedan od

upravljačkih programa (eng. driver) koji podržava značajku "Always Encrypted". Trenutno

postoje tri takva upravljačka programa:

▪ .NET Framework Data Provider for SQL Server

▪ JDBC

▪ Windows ODBC



Primjerice, u slučaju korištenja prvog upravljačkog programa, .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 vidjeti

kriptirani sadržaj stupaca u čitljivom obliku.

Za primjer može se iskoristiti i SSMS kao klijent aplikacija baze podataka. Prilikom prijave

potrebno je kliknuti na gumb "Options >>", a zatim na "Additional Connection Parameters".

Enkripciju stupaca potrebno je omogućiti dodavanjem izraza "Column Encryption

Setting=enabled" (Slika 4.7.4).

Slika 4.7.4. Omogućavanje enkripcije stupaca u SSMS alatu

Nakon prijave naredbom SELECT moguće je dohvatiti sadržaj kriptiranog stupca

"BrojKreditneKartice" u čitljivom (dekriptiranom) obliku. SSMS alat ponudit će i mogućnost

automatske parametrizacije T-SQL varijabli za potrebe kriptiranja i spremanja podataka

nazad u bazu podataka. Parametrizacija se može uključiti i ručno korištenjem stavke

"Query / Query Options… / Execution / Advanced / Enable Parametrization for Always

Encrypted".

Primjer 4.7.4 – Dodavanje novog zapisa i vrijednosti u kriptirani stupac

DECLARE @Kartica varchar(50) = '3333-4444-5555-6666' INSERT INTO Kupac(OIB, BrojKreditneKartice) VALUES (333333, @Kartica)



Zbog uključene parametrizacije, upit iz Primjera 4.7.4 bit će uspješno izvršen, a u tablicu

"Kupac" bit će spremljen novi zapis s kriptiranim brojem kreditne kartice.

Ukoliko u nekom trenutku više ne želite kriptirati stupce korištenjem "Always Encrypted"

značajke potrebno je ponovno pokrenuti čarobnjak sa Slike 4.7.3 te za tip enkripcije

odabrati "Plaintext".

4.8. Dinamičko maskiranje podataka

Značajka dinamičkog maskiranja podataka (eng. dynamic data masking, DDM)

predstavljena je izlaskom SQL Servera 2016. Njom je omogućeno skrivanje osjetljivih

podataka od neovlaštenih korisnika korištenjem funkcija maskiranja. DDM značajkom

podaci se ne kriptiraju već se tek prikazuju u teško razumljivom ili nepotpunom obliku.

Funkcija Opis

Default Za skrivanje tekstualnih tipova podataka koriste se XXXX

znakovi, a za numeričke tipove podataka 0 (nula). Datum i

vrijeme skrivaju se vrijednošću 01.01.1900 00:00:00.0000000.

Email Prikazuje se samo prvi znak adrese e-pošte s konstantnim

".com" sufiksom. Npr. aXXX.XXXX.com.

Random Koristi se za skrivanje numeričkih tipova podataka nekom

slučajnom vrijednošću unutar definiranog intervala.

Partial Prikazuje određen broj početnih i krajnjih znakova, a središnji

dio teksta skriven je proizvoljnim znakovima.

Tablica 4.8.1. Funkcije maskiranja u SQL Serveru [41]

Za demonstraciju DDM značajke pretpostavimo da postoji tablica "Kupac" sa sljedećim

sadržajem:

OIB Naziv email DatumUclanjenja BrojKreditneKartice

111111 ABC d.o.o. [email protected] 2017-07-17 1111-2222-3333-4444

222222 DEF j.d.o.o. [email protected] 2015-05-16 2222-3333-4444-5555



Ukoliko zadnja tri stupca proglasimo osjetljivim podacima te ih želimo zaštiti DDM

značajkom, to bismo napravili na sljedeći način (Primjer 4.8.1).

Primjer 4.8.1 – Upotreba funkcija maskiranja

ALTER TABLE KUPAC ALTER COLUMN email ADD MASKED WITH(FUNCTION = 'email()') ALTER TABLE KUPAC ALTER COLUMN DatumUclanjenja ADD MASKED WITH(FUNCTION = 'default()') ALTER TABLE KUPAC ALTER COLUMN BrojKreditneKartice ADD MASKED WITH(FUNCTION = 'partial(0,"XXXX-XXXX-",4)')

Naredbom ALTER potrebno je tek promijeniti definicije stupaca s osjetljivim podacima.

Tada se podaci u tim stupcima podrazumijevano maskiraju svakom korisniku koji nema

administratorske ovlasti i nije vlasnik (eng. owner) baze podataka (Primjer 4.8.2).

Primjer 4.8.2 – Demonstracija DDM značajke

-- Kreiranje korisnika koji ima ovlasti za dohvat podataka USE TestDB CREATE USER [Korisnik1] WITHOUT LOGIN GRANT SELECT ON [dbo].[Kupac] TO [Korisnik1] GO -- Izvrši upit u sigurnosnom kontekstu kreiranog korisnika EXECUTE AS USER = 'Korisnik1' SELECT * FROM Kupac REVERT

Izvršavanjem T-SQL koda iz Primjera 4.8.2 kreirat će se korisnik bez prijavnog naloga koji

ima ovlasti za dohvat podataka naredbom SELECT. Prelaskom u njegov sigurnosni

kontekst te izvršavanjem SELECT naredbe kao rezultat dobije se sljedeće:

OIB Naziv email DatumUclanjenja BrojKreditneKartice

111111 ABC d.o.o. [email protected] 1900-01-01 XXXX-XXXX-XXXX-4444

222222 DEF j.d.o.o. [email protected] 1900-01-01 XXXX-XXXX-XXXX-5555

Naredbom GRANT moguće je dodijeliti UNMASK dozvolu i nekom drugom korisniku baze

podataka, a naredbom ALTER COLUMN može se ukinuti korištenje maske za odabrani

stupac (npr. ALTER COLUMN email DROP MASKED).



Unatoč nedostatku UNMASK dozvole korisnik i dalje može umetati nove i mijenjati

postojeće zapise u tablici. Također, u slučaju pokušaja umetanja maskiranih podataka u

drugu tablicu (SELECTI INTO, INSERT INTO) rezultat će biti maskirani podaci u odredišnoj

tablici.



5. Održavanje i nadzor

5.1. Izrada rezervnih kopija

Da bi se minimalizirao rizik od gubitka podataka uslijed neočekivanih kvarova

sklopovlja, pogrešnog rukovanja podacima ili u slučaju katastrofe poželjno je periodički

izrađivati rezervne kopije baza podataka. Odabir odgovarajuće strategije za izradu i povrat

rezervnih kopija jedna je od ključnih stavki kvalitetnog održavanja, a o tome svjedoče i

mnogobrojne knjige napisane na tu temu.

SQL Server podržava tri osnovna tipa rezervnih kopija, a to su:

▪ Potpuna rezervna kopija (eng. full backup)

▪ Diferencijalna rezervna kopija (eng. differential backup)

▪ Rezervna kopija dnevnika transakcija (eng. transaction log backup)

Potpuna rezervna kopija najsigurniji je oblik rezervne kopije, a njeno je postojanje i

preduvjet za izradu diferencijalne kopije i kopije dnevnika transakcija.

Slika 5.1.1. Izrada potpune rezervne kopije u SSMS alatu



Periodičke potpune rezervne kopije najčešće su dovoljne kada je riječ o malim bazama

podataka. S obzirom da tada ne zauzimaju puno diskovnog prostora lako ih je spremati, a

i povrat baze podataka iz takve rezervne kopije traje jako kratko vrijeme. Potpuna rezervna

kopija može se kreirati u bilo kojem trenutku upotrebom SSMS alata, odnosno desnim

klikom na željenu bazu podataka i korištenjem stavke "Tasks / Backup…" (Slika 5.1.1).

Alternativno, rezervna kopija može se kreirati i izvršavanjem odgovarajućeg T-SQL koda.

Nakon odabira željene baze podataka i tipa rezervne kopije (Full) moguće je odabrati i

stavku "Copy-only Backup" (Slika 5.1.1). Ova stavka koristi se samo u slučajevima kada

se izrađuje rezervna kopija kojom se ne želi prekinuti već postojeći lanac (ciklus) rezervnih

kopija. Primjerice, za potrebe prebacivanja baze podataka u testno okruženje izradom

ovakvog tipa rezervne kopije ne utječe se na kasnije diferencijalne i rezervne kopije

dnevnika transakcija. One neće kao polaznu točku koristiti kreiranu "Copy-only Backup"

rezervnu kopiju već tek zadnju potpunu rezervnu kopiju baze podataka. [42]

Izrada rezervne kopije može se odnositi na kompletnu bazu podataka ili na samo neke

njene dijelove (odabrane datoteke ili datotečne grupe). Tada je riječ o parcijalnoj rezervnoj

kopiji. Također, rezervna kopija može imati i vijek trajanja, a u tom razdoblju (definiranom

brojem dana ili krajnjim datumom) datoteka rezervne kopije ne može biti prepisana drugom

rezervnom kopijom.

Odredište rezervne kopije najčešće je datoteka na disku, a može biti i traka (eng. tape) te

URL. Svaki od ovih odredišta može biti zasebno kreiran i korišten kao uređaj rezervne

kopije (eng. backup device) koji postoji na razini SQL Server instance (stavka "Server

objects / Backup devices").

Na Slici 5.1.1 odredište rezervne kopije jedna je datoteka na disku. U najčešćim

slučajevima ovo će biti zadovoljavajući pristup jer će kompletan sadržaj rezervne kopije biti

smješten samo na jednom mjestu. Međutim, kada je riječ o velikim bazama podataka

izrada rezervnih kopija i njihov povrat može iziskivati puno vremena. Da bi se ti procesi

ubrzali, kao odredište može se definirati više datoteka rezervne kopije. Tada će se prilikom

njene izrade paralelno upotrebom više dretvi pisati sadržaj tih datoteka, kao što će se

paralelno i čitati sadržaj iz tih datoteka prilikom vraćanja rezervne kopije.



Za maksimalnu učinkovitost preporuka je da se sve takve datoteke nalaze rasprostranjene

kroz više diskova. Ipak, tada je veći rizik od gubitka podataka budući da su za povrat takve

rezervne kopije potrebne sve odredišne datoteke.

Slika 5.1.2. Postavke rezervne kopije

U stavci "Options" (Slika 5.1.2) definiramo želimo li novu rezervnu kopiju dodati na kraj

datoteke (medija) rezervne kopije ili tu datoteku želimo prepisati novom rezervnom

kopijom. Tako bi se u prvom slučaju unutar jedne datoteke mogle nalaziti višestruke

rezervne kopije (bilo kojeg tipa), a u drugom slučaju tek zadnja rezervna kopija.

Rezervnu je kopiju uvijek poželjno provjeriti nakon kreiranja kako bi se sa sigurnošću znalo

je li čitljiva i može li se koristiti za povrat baze podataka (stavke "Verify backup when

finished" i "Perform checksum before writting to media"). Iz istog razloga najčešće nije

poželjno nastaviti s izradom rezervne kopije u slučaju greške (stavka "Continue on error").



Konačno, moguće je koristiti i kompresiju datoteka rezervne kopije kako bi se smanjila

njihova veličina, a klikom na gumb "OK" generira se i izvršava odgovarajući T-SQL kod za

izradu rezervne kopije (Primjer 5.1.1).

Primjer 5.1.1 – Izrada potpune rezervne kopije korištenjem T-SQL koda

BACKUP DATABASE [TestDB] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL12.MAIN\MSSQL\Backup\TestDB.bak' WITH NOFORMAT, NOINIT, NAME = N'TestDB-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10

Zbog svoje veličine, česte potpune rezervne kopije nisu najbolje rješenje kada je riječ o

velikim bazama podataka. Da bi se uštedio prostor na disku preporuka je češća izrada

diferencijalnih rezervnih kopija, a one sadrže tek izmjene koje su nastale nakon zadnje

potpune rezervne kopije.

Slika 5.1.3. Potpune i diferencijalne rezervne kopije [43]

Diferencijalne rezervne kopije nisu inkrementalne već kumulativne. Tako će svaka

diferencijalna rezervna kopija u sebi sadržavati i sadržaj svake prethodne diferencijalne

rezervne kopije, i tako sve dok se ne napravi sljedeća potpuna rezervna kopija (Slika 5.1.3).

Bez obzira na postojanost diferencijalne rezervne kopije za povrat baze podataka (eng.

restore) i dalje je potrebna potpuna rezervna kopija. Prvo se vraća potpuna rezervna kopija,

a nakon nje odgovarajuća diferencijalna rezervna kopija.

Primjer 5.1.2 – Izrada diferencijalne rezervne kopije korištenjem T-SQL koda

BACKUP DATABASE [TestDB] TO DISK = N'Diferencijalna.bak' WITH DIFFERENTIAL



Diferencijalnu rezervnu kopiju moguće je izraditi korištenjem SSMS alata na sličan način

kao i potpunu rezervnu kopiju ili izvršavanjem T-SQL koda kao u Primjeru 5.1.2.

U kombinaciji s potpunim i diferencijalnim rezervnim kopijama najčešće se koriste i

rezervne kopije dnevnika transakcija (eng. transaction log backups). Za razliku od

diferencijalnih, rezervne kopije dnevnika transakcija inkrementalne su, tj. svaka od njih

sadrži samo izmjene napravljene od posljednje rezervne kopije dnevnika transakcija.

Moguće ih je izrađivati samo ukoliko baza podataka prethodno ima izrađenu potpunu

rezervnu kopiju te ukoliko koristi potpuni model oporavka. Također, jedino ovaj tip rezervne

kopije omogućuju povrat baze podataka u željenu točku u vremenu (eng. point in time

recovery, PITR).

Slika 5.1.4. Potpuna, diferencijalne i rezervne kopije dnevnika transakcija

Ovisno o veličini baze podataka, broju transakcija u zadanom vremenu, osjetljivosti

podataka i sigurnosnoj politici tvrtke može postojati veliki broj različitih strategija izrade

rezervnih kopija. Jedna od njih prikazana je Slikom 5.1.4 gdje se potpune rezervne kopije

izrađuju jednom dnevno. Svakih 6 sati izrađuju se diferencijalne rezervne kopije, a između

pojedinih diferencijalnih izrađuju se rezervne kopije dnevnika transakcija, svaka u razmaku

od sat vremena.

U slučaju neželjenog gubitka podataka moguće je napraviti povrat baze podataka do

najnovije rezervne kopije dnevnika transakcija. Sve transakcije koje su se dogodile nakon

toga mogu se vratiti samo ukoliko postoji rezervna kopija repa dnevnika transakcija (eng.



tail of the transaction log), a nju je moguće kreirati upotrebom stavke "Back up the tail of

the log…" sa Slike 5.1.2 ili u nekim slučajevima prilikom povrata baze podataka.

Ukoliko su datoteke dnevnika transakcija u potpunosti popunjene korisnici više neće moći

koristiti bazu podataka. Da bismo spriječili rast tih datoteka i oslobodili njihov sadržaj

potrebno je periodički izrađivati rezervne kopije dnevnika transakcija korištenjem stavke

"Truncate the transaction log" (Slika 5.1.2). Alternativno, isti rezultat nije moguće dobiti

samo izradom potpune ili diferencijalne rezervne kopije jer one ne podrazumijevaju i izradu

rezervne kopije dnevnika transakcija.

5.2. Povrat rezervnih kopija

Prilikom povrata baze podataka treba vratiti kompletan lanac rezervnih kopija koji

vodi do željenog datuma i vremena. Primjerice, za povrat baze podataka sa Slike 5.1.4 u

najnovije vrijeme prvo je potrebno vratiti zadnju potpunu rezervnu kopiju, a nakon nje i

zadnju diferencijalnu rezervnu kopiju. Tek nakon toga vrši se povrat svih rezervnih kopija

dnevnika transakcija koje su iz vremena nakon zadnje diferencijalne rezervne kopije.

Slika 5.2.1. Primjer lanca rezervnih kopija

Za svaku rezervnu kopiju moguće je vidjeti odakle počinje i završava, odnosno informacije

o početnim i završnim log sekvencama (eng. log sequence numbers, LSN). Tako je na Slici



5.2.1 vidljivo da zadnja rezervna kopija dnevnika transakcija počinje točno ondje gdje

završava prethodna, a to je upravo iz razloga što su rezervne kopije tog tipa inkrementalne,

tj. nadovezuju se jedna na drugu. Također je moguće vidjeti i vezu između potpune i

diferencijalnih rezervnih kopija uspoređujući potpune LSN brojeve (eng. full LSN) i LSN

brojeve kontrolnih točki (eng. checkpoint LSN).

Za povrat baze podataka u točno određenu točku u vremenu (datum i vrijeme) potrebno je

imati odgovarajuće rezervne kopije dnevnika transakcija. Zatim, klikom na gumb "Timeline"

(Slika 5.2.1) pojavljuje dijalog kao na Slici 5.2.2.

Slika 5.2.2. Povrat baze podataka u određenu točku u vremenu

Na grafički način prikazane su sve već postojeće rezervne kopije, a klikom na gumb "OK"

lanac rezervnih kopija sa Slike 5.2.1 automatski će se reorganizirati tako da se omogući

povrat baze podataka u odabranu točku u vremenu. To uključuje automatski odabir

odgovarajuće potpune, diferencijalne i svih potrebnih rezervnih kopija dnevnika

transakcija.

Da bismo testirali povrat baze podataka možemo ju prvo pokušati vratiti pod novim

imenom, a ono se može definirati u polju "Destination / Database" (Slika 5.2.1). Sukladno



novom imenu, potrebno je promijeniti i imena odredišnih datoteka u stavci "Files" kako ne

bismo pokušali prepisati već postojeću bazu podataka u produkciji.

Slika 5.2.3. Postavke povrata baze podataka

Povrat baze podataka najčešće znači prijepis već postojeće baze podataka, pa je stavku

"Overwrite the existing database" (Slika 5.2.3) potrebno označiti ukoliko odredišna baza

podataka već postoji. U protivnom neće biti moguće napraviti njen povrat u prijašnje stanje.

Jedna od najvažnijih stavki povrata baze podataka status je oporavka, a on može biti:

▪ RESTORE WITH RECOVERY – Baza podataka dostupna je korisnicima odmah

nakon završenog povrata rezervne kopije. Ukoliko se vrši povrat više rezervnih

kopija odjednom tek nakon povrata zadnje od njih baza podataka treba biti u

oporavljenom stanju.

▪ RESTORE WITH NORECOVERY – Koristi se prilikom vraćanja višestrukih

rezervnih kopija. Korisnici nemaju pristup bazi podataka sve dok se ne povrate sve

željene rezervne kopije. Tek nakon povrata zadnje od njih bazu podataka potrebno



je postaviti u oporavljeno stanje naredbom RESTORE. Primjerice, RESTORE

DATABASE TestDB WITH RECOVERY.

▪ RESTORE WITH STANDBY – Baza podataka dostupna je samo za čitanje. Sve

nedovršene transakcije neće biti će izvršene, ali će biti spremljene u zasebnu

datoteku za slučaj da se predomislimo, odnosno želimo se vratiti u vrijeme prije

zadnjeg povrata baze podataka. [44]

Kada se baza podataka vraća u vrijeme zadnje rezervne kopije, može biti nepoželjno

izgubiti sve one transakcije koje su se dogodile nakon tog vremena. Zato se

podrazumijevano prilikom ovakvog tipa povrata izrađuje i rezervna kopija repa dnevnika

transakcija. Upravo u ovom slučaju bazu podataka potrebno je ostaviti u statusu WITH

NORECOVERY kako bi se nakon povrata potrebnog lanca rezervnih kopija kao zadnja

mogla uredno vratiti i rezervna kopija repa dnevnika transakcija.

Povrat baze podataka moguć je samo ukoliko ne postoje druge aktivne konekcije prema

bazi podataka. Njih je moguće i nasilno prekinuti odabirom stavke "Close existing

connections to destination database" sa Slike 5.2.3 ili naredbom SET SINGLE USER WITH

ROLLBACK IMMEDIATE (Primjer 5.2.1).

Primjer 5.2.1 – Povrat lanca rezervnih kopija korištenjem T-SQL koda

USE [master] ALTER DATABASE [TestDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE RESTORE DATABASE [TestDB] FROM DISK = N'C:\Program Files (x86)\Microsoft SQL Server\MSSQL11.FULLSERVER\MSSQL\Backup\testdb.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 5 RESTORE DATABASE [TestDB] FROM DISK = N'C:\Program Files (x86)\Microsoft SQL Server\MSSQL11.FULLSERVER\MSSQL\Backup\testdb.bak' WITH FILE = 3, NORECOVERY, NOUNLOAD, STATS = 5 RESTORE LOG [TestDB] FROM DISK = N'C:\Program Files (x86)\Microsoft SQL Server\MSSQL11.FULLSERVER\MSSQL\Backup\testdb.bak' WITH FILE = 4, NORECOVERY, NOUNLOAD, STATS = 5 RESTORE LOG [TestDB] FROM DISK = N'C:\Program Files (x86)\Microsoft SQL Server\MSSQL11.FULLSERVER\MSSQL\Backup\testdb.bak' WITH FILE = 5, NOUNLOAD, STATS = 5 ALTER DATABASE [TestDB] SET MULTI_USER GO

Za povrat kompletnog lanca rezervnih kopija sa Slike 5.2.1 generirat će se i izvršiti T-SQL

kod iz Primjera 5.2.1. Iako je na Slici 5.2.3 odabran status oporavka RESTORE WITH

RECOVERY on se odnosi samo na zadnju rezervnu kopiju u postojećem lancu.



5.3. SQL Server Agent

Uz odgovarajuću strategiju izrade rezervnih kopija održavanje baze podataka

podrazumijeva i periodičku provjeru integriteta, održavanje indeksa, čišćenje nepotrebnih

datoteka itd. Da bi se proces redovnog održavanja baza podataka automatizirao u SQL

Serveru moguće je koristiti komponente SQL Server Agent servisa te ih kombinirati s

planovima održavanja (eng. maintenance plans).

SQL Server Agent je Windows servis zadužen za automatizaciju administrativnih poslova

u SQL Serveru. [45] Postoji kao sastavni dio svake instance te se podrazumijevano ne

pokreće automatski podizanjem operacijskog sustava. Međutim, te postavke moguće je

definirati prilikom instalacije instance (Slika 1.4.6), naknadno izmijeniti upotrebom SQL

Server Configuration Manager aplikacije ili u popisu svih Windows servisa na računalu.

SQL Server Agent sastoji se od četiri komponente:

▪ Poslovi (eng. jobs)

▪ Rasporedi (eng. schedules)

▪ Upozorenja (eng. alerts)

▪ Operateri (eng. operators)

Najvažnija su komponenta SQL Server Agenta poslovi jer se pomoću njih definiraju

administrativne zadaće. Svaki posao izvršava se na osnovu rasporeda, generiranog

upozorenja ili na zahtjev (izvršavanjem uskladištene procedure sp_start_job). Također,

posao može biti i jednokratan, pri čemu se automatski briše nakon uspješnog završetka.

Slika 5.3.1. Kreiranje posla u SQL Server Agentu



Prilikom kreiranja pojedinog posla moguće je definirati njegovo ime, vlasnika, kategoriju i

opis (Slika 5.3.1). S obzirom da su za upravljanje i izvršavanje poslova potrebne neke od

najviših ovlasti u SQL Serveru vrlo često se kao vlasnik posla koristi prijavni nalog "sa" ili

jedan od drugih prijavnih naloga koji je član sysadmin uloge.

Slika 5.3.2. Kreiranje koraka posla

Svaki posao sastoji se od barem jednog koraka. Ukoliko pretpostavimo da je cilj našeg

posla napraviti potpunu rezervnu kopiju TestDB baze podataka, potrebno je napraviti korak

tipa "Transact-SQL script (T-SQL)" te u polje "Command" kopirati T-SQL kod iz Primjera

5.1.1. Da bismo testirali ispravnost T-SQL koda moguće je kliknuti gumb "Parse" (Slika

5.3.2), nakon čega se dobije odgovarajuća povratna informacija.

Rezultat izvršavanja pojedinog koraka posla ne mora nužno biti uspješan. Ovisno o

njegovoj kritičnosti moguće je u slučaju neuspješnog završetka koraka zaustaviti ostatak

posla (naredne korake) ili definirati neku drugu akciju. Sve akcije nakon uspješnog ili

neuspješnog završetka koraka moguće je definirati u kartici "Advanced" sa Slike 5.3.2.

Ukoliko je riječ o poslu izrade rezervnih kopija, taj posao poželjno je izvršavati periodički,

odnosno unaprijed definiranim rasporedom (Slika 5.3.3).



Slika 5.3.3. Raspored izvršavanja posla

Tipom rasporeda definira se trenutak i učestalost izvršavanja posla. To može biti posao

koji se ponavlja, izvršava samo jedanput ili se izvršava u posebnim situacijama (prilikom

pokretanja SQL Server Agenta ili kada je procesor u stanju mirovanja). Učestalost posla

može biti na dnevnoj, tjednoj ili mjesečnoj bazi, sa ili bez krajnjeg datuma izvršavanja.

Također, svaki posao može se izvršavati sukladno jednom ili više rasporeda.

Posao može biti izvršen i kao rezultat generiranog upozorenja (eng. alert). Upozorenje je

automatski odgovor na određeni događaj, pri čemu može biti riječ o SQL Server događaju,

problematičnim performansama izvedbe ili WMI (Windows Management Instrumentation)

događajima. [45] Primjerice, upozorenje se može generirati prilikom neuspješno

obavljenog posla, nedovoljnih prava i dozvola, nedostatka resursa, kvara na sklopovlju itd.

U tom trenutku može biti kontaktiran i operater, odnosno jedna od osoba zadužena za

administriranje i održavanje SQL Servera.



Komponente SQL Server Agenta imaju jednu od ključnih uloga u procesu automatiziranog

održavanja. Također, vrlo se često koriste i za potrebe automatizirane replikacije baza

podataka.

5.4. Izrada plana održavanja

Plan održavanja (eng. maintenance plan) na vizualan način omogućuje

implementaciju, pregled i izmjenu strategije održavanja. Možemo ga zamisliti kao SQL

Server Agent posao, s time da su koraci unutar plana održavanja vizualno prikazani tokom

(eng. workflow) iz kojeg su jasno vidljivi strategija i scenariji održavanja.

Plan održavanja kreira se na razini instance SQL Servera, a korištenjem SSMS alata

moguće ga je kreirati upotrebom stavke "Management / Maintenance Plans / New

Maintenance Plan…".

Slika 5.4.1. Zadaci plana održavanja

Prilikom njegove izrade moguće je koristiti 11 unaprijed definiranih tipova zadataka (Slika

5.4.1). Ovisno o željenoj strategiji održavanja, zadatke je moguće proizvoljno kombinirati,

a pomoću toka definirati njihov redoslijed izvršavanja. Štoviše, redoslijed izvršavanja

zadataka može biti i uvjetno definiran, uzimajući u obzir i da se neki od zadataka možda

neće uspješno izvršiti.



Slika 5.4.2. Plan održavanja Test DB baze podataka

Svaki plan održavanja ima jedan ili više podplanova. Tako se u primjeru na Slici 5.4.2 plan

održavanja TestDB baze podataka sastoji od 3 podplana, svakog za pojedini tip rezervne

kopije. Primjerice, podplan za izradu potpune rezervne kopije počinje provjerom integriteta

baze podataka. U slučaju uspjeha tog zadatka nastavlja se s obnovom indeksa (zelena

linija) te dalje tim tokom, dok se u slučaju neuspjeha kontaktira operater (crvena linija).

Pojedini zadaci poput provjere integriteta, obnove indeksa ili izrade rezervnih kopija mogu

se odnositi i na više baza podataka odjednom.

Ukoliko postavke pojedinog zadatka nisu dobro definirane, na njegovom mjestu pojavit će

se oznaka "X". Tako na Slici 5.4.2 zadatak kontaktiranja operatera treba dodatno definirati

jer nije navedeno ime operatera.

Za svaki podplan kreira se SSIS (SQL Server Integration Services) paket koji se izvršava

SQL Server Agent poslom, bilo automatski (definiranim rasporedom) ili na zahtjev. [46]



Tako će zbog plana održavanja definiranog Slikom 5.4.2 biti kreirana tri zasebna SQL

Server Agent posla (Slika 5.4.3).

Slika 5.4.3. SQL Server Agent poslovi održavanja

Rezultat generiran izvršavanjem plana održavanja može biti spremljen u tekstualnoj (log)

datoteci ili u sistemskoj msdb bazi podataka. Također, povijest izvršavanja pojedinih

planova i podplanova moguće je pregledati u SSMS alatu odabirom stavke "Management

/ Maintenance Plans / View History".

5.5. Elektronička pošta baze podataka

Pri pojavi nekog problema u radu SQL Servera dobra je praksa automatski o tome

obavijestiti odgovarajuće operatere. U tu svrhu SQL Server nudi mogućnost slanja

elektroničke pošte. Ona se najčešće šalje zbog neuspješnog izvršavanja kritičnih zadataka

u planu održavanja ili kao odgovor na upozorenje (eng. alert).

Slika 5.5.1. Konfiguracija elektroničke pošte baze podataka



Za konfiguraciju e-pošte u SSMS alatu potrebno je odabrati stavku "Management /

Database Mail / Configure Database Mail", nakon čega se pojavljuje čarobnjak kao na Slici

5.5.1. Pomoću njega moguće je kreirati i uređivati profile i korisničke račune e-pošte te

konfigurirati sigurnosne postavke korištenja.

Slika 5.5.2. Izrada profila i korisničkog računa e-pošte

Da bi SQL Server mogao poslati e-poštu, prethodno je potrebno kreirati barem jedan profil

i korisnički račun e-pošte u SQL Serveru (Slika 5.5.2). Profil e-pošte služi kao zbirka

korisničkih računa e-pošte, pri čemu svaki od korisničkih računa ima svoj prioritet u listi. U

slučaju da se e-pošta nije uspješno poslala pomoću prvog korisničkog računa, ista će se

pokušati poslati sljedećim korisničkim računom itd.



Slika 5.5.3. Podrazumijevani profil e-pošte

Pri slanju e-pošte najčešće se koriste korisnički računi iz podrazumijevanog profila (Slika

5.5.3). Ipak, SQL Server Agent može biti konfiguriran tako da koristi neki drugi profil, a

njega se može definirati u postavkama tog servisa (Slika 5.5.4).

Slika 5.5.4. Profil e-pošte SQL Server Agenta

Slanje e-pošte može se inicirati kontaktiranjem operatera ili izravnim izvršavanjem T-SQL

koda pozivajući uskladištenu proceduru sp_send_dbmail (Primjer 5.5.1). Navedenoj

proceduri potrebno je predati ime profila e-pošte, nakon čega će ona biti poslana s jednog

od korisničkih računa u tom profilu, ovisno o njihovom prioritetu.

Primjer 5.5.1 – Slanje e-pošte izvršavanjem T-SQL koda

USE msdb GO EXEC sp_send_dbmail @profile_name='Administratori', @recipients='[email protected]', @subject='Popis svi zaposlenika', @body='U prilogu se nalazi popis svih zaposlenika tvrtke!' -- prilog e-pošti! @query= 'SELECT * from TestDB.dbo.Zaposlenik', @attach_query_result_as_file=1, @query_attachment_filename = 'SviZaposlenici.txt'



Sadržaj e-pošte može uključivati i priloge, a na taj način je u Primjeru 5.5.1 direktoru tvrtke

poslan popis svih zaposlenika. Na identičan način e-poštu moguće je poslati i iz

uskladištenih procedura, okidača itd.

5.6. Kopiranje baze podataka

Potreba za kopiranjem baze podataka javlja se u velikom broju situacija. Primjerice,

prilikom razvoja aplikacija, nadogradnje baze podataka ili njenog testiranja često ju je

potrebno kopirati iz produkcijskog u testno okruženje. Također, baza podataka inicijalno

se kopira i za potrebe zrcaljenja (eng. mirroring) ili jednostavno zbog kreiranja dodatne

rezervne kopije.

SQL Server i SSMS alat nude nekoliko metoda kopiranja baze podataka:

1. Metoda "odspoji-kopiraj-spoji"

2. Skriptiranje baze podataka

3. Čarobnjak za kopiranje baze podataka

4. Izrada i povrat rezervne kopije

Odabir odgovarajuće metode ovisi o nekoliko čimbenika poput veličine baze podataka,

potrebe za dostupnošću tijekom kopiranja, sadržaju i strukturi te brzini samog kopiranja.

Slika 5.6.1. Odspajanje i spajanje baze podataka

Prva metoda ("odspoji-kopiraj-spoji") koristi se kada se datoteke baze podataka fizički

kopira s jedne lokacije na drugu. Da bismo na takav način mogli kopirati bazu podataka

prethodno ju je potrebno odspojiti od instance SQL Servera (desni klik na bazu podataka,



stavka "Tasks / Detach…"), a nakon kopiranja ponovno pripojiti instanci (desni klik na popis

baza podataka, stavka "Attach…"), kao što je prikazano Slikom 5.6.1.

Ipak, nedostatak je ove metode nedostupnost baza podataka tijekom kopiranja, odnosno

sve dok ju se opet ne pripoji instanci SQL Servera. Zato je ovu metodu preporučljivo koristiti

tek kada je broj upita prema bazi podataka minimalan ili ih uopće nema (npr. tijekom noći).

Ponekad je u testno okruženje potrebno kopirati praznu inačicu baze podataka, odnosno

samo njenu strukturu (definicije tablica, pogleda, uskladištenih procedura, uloga itd.).

SSMS alat tada nudi mogućnost generiranja odgovarajuće SQL skripte desnim klikom na

bazu podataka i upotrebom stavke "Tasks / Generate Scripts…". Izvršavanjem generirane

skripte u drugom (testnom) okruženju kreirat će se navedena baza podataka i svi njeni

odabrani objekti. [47]

Slika 5.6.2. Izrada skripte za kompletnu baze podataka

SQL skriptu moguće je generirati za kompletnu bazu podataka ili samo za neke od njenih

objekata (Slika 5.6.2). Generiranu SQL skriptu moguće je iz SSMS alata objaviti na web

servisu, spremiti u jednu ili više datoteka (jedna datoteka za sve objekte ili zasebna

datoteka za svaki objekt), spremiti u međuspremnik (eng. clipboard) ili prikazati u novom

uređivačkom prozoru.

Prilikom odabira odredišta skripte moguće je kliknuti i na gumb "Advanced" kojim se mogu

urediti neke od naprednih postavki za generiranja skripte. Primjerice, postavkom "Types of

data to script" moguće je odabrati jednu od ponuđenih vrijednosti:

▪ Schema only

▪ Schema and data

▪ Data only



Ovisno o potrebama možemo generirati SQL skriptu samo za strukturu baze podataka

(eng. schema only), samo za podatke sadržane u objektima (eng. data only) ili za oboje.

U skriptu je moguće uključiti i definicije prijavnih naloga, okidača, statistika itd.

Generiranje SQL skripte ne zahtjeva odspajanje (eng. detach) baze podataka te je uvijek

prikladno za kopiranje njene strukture. Međutim, generiranje SQL skripte u svrhu kopiranja

podataka ipak nije preporučljivo jer traje iznimno duže nego bilo koja druga metoda

kopiranja sadržaja baze podataka.

SSMS alat nudi i ugrađen čarobnjak za kopiranje baze podataka, a pokreće ga se desnim

klikom na bazu podataka te odabirom stavke "Tasks / Copy Database…".

Slika 5.6.3. Metoda prijenosa podataka

Nakon odabira izvorišne i odredišne instance SQL Servera potrebno je odabrati metodu

prijenosa podataka (Slika 5.6.3). Prvom metodom ("Use the detach and attach method")

zapravo radimo identični postupak kao i prethodno opisanom metodom "odspoji-kopiraj-

spoji". Baza podataka odspoji se od instance SQL Servera, nakon čega se njene datoteke

fizički kopiraju na lokaciju druge instance. Obje baze podataka zatim se automatski pripoje

svojim instancama.



Metoda "Use the SQL Management Object method" podsjeća na kreiranje SQL skripte.

Čita se definicija svakog objekta iz izvorišne baze podataka, a zatim se na osnovu definicije

takav objekt kreira u odredišnoj bazi podataka. Nakon kreiranja objekata kopiraju se

podaci, ponovno se kreiraju indeksi, metapodaci itd. [48]

Slika 5.6.4. Odabir baza podataka

U sljedećem koraku moguće je odabrati jednu ili više baza podataka iz izvorišne instance,

a za svaku od njih odabrati operaciju kopiranja (eng. copy) ili prijenosa (eng. move) u

odredišnu instancu (Slika 5.6.4). Ukoliko odredišna baza podataka već postoji u drugoj

instanci, čarobnjak će ponuditi mogućnost promjene imena nove odredišne baze podataka.

Unatoč mnogim automatiziranim značajkama ovog čarobnjaka, vrlo često postupak

kopiranja nije uspješno izvršen. Da bi se to izbjeglo potrebno je osigurati da je SQL Server

Agent pokrenut u odredišnoj instanci, da su podatkovne datoteke i datoteke dnevnika

transakcija izvorišne baze podataka dostupne iz instance odredišne baze podataka itd.

[48] U protivnom, uvijek je moguće kopirati bazu podataka "ručno" korištenjem metode

"odspoji-kopiraj-spoji" ili skriptiranjem baze podataka.

Kao jedna od vrlo čestih metoda kopiranja baze podataka koristi se izrada i povrat

rezervnih kopija. Takva (potpuna) rezervna kopija najčešće se kreira na način da ne utječe



na već postojeći lanac rezervnih kopija izvorišne baze podataka (Copy-only Backup), a u

drugoj instanci njen povrat moguće je napraviti pod istim ili drukčijim imenom (Slika 5.2.1).

5.7. SQL Server Profiler

Kontinuirano nadgledanje rada SQL Servera i pripadnih baza podataka poželjno je

zbog pravovremenog otkrivanja grešaka i sigurnosnih propusta, analize u svrhu

poboljšanja performansi te vođenja dnevnika aktivnosti (eng. log). Za nadgledanje i

optimizaciju rada moguće je koristiti mnogo značajki i alata, a ovisno o instaliranoj inačici

SQL Servera, neki od njih dostupni su izravno iz SSMS-a. Primjerice,

▪ SQL Server Profiler

▪ SQL Server Database Engine Tuning Advisor

▪ SQL Server Audit

▪ SQL Server Logs

▪ SQL Server Activity Monitor

Također, na tržištu postoje i mnoga druga komercijalna i besplatna rješenja poput SQL

Server Monitoring Software (Spiceworks), SQL Check, SQL Query Store Optimizer (Idera),

ApexSQL, AppDynamics itd. [49]

SQL Server stalno nadgleda 34 različita događaja (default trace), a po potrebi moguće je

napraviti i prilagođeno nadgledanje specifičnih baza podataka i upita. Nadgledanje je

moguće kreirati T-SQL kodom ili alatom poput SQL Server Profilera koji nudi grafičko

sučelje za izradu te prikaz rezultata nadgledanja. [50]

Slika 5.7.1. Pokretanje SQL Server Profilera



SQL Server Profiler moguće je pokrenuti izravno iz SSMS-a klikom na stavku "Tools / SQL

Server Profiler" (Slika 5.7.1). Ukoliko tamo nije prisutan potrebno je nadopuniti instalaciju

instance SQL Servera odabirom stavke "Management Tools – Complete", kao na Slici

1.4.4. Tada će se instalirati i alat Database Engine Tuning Advisor.

Slika 5.7.2. Odabir događaja i povratnih podataka

Nakon pokretanja SQL Server Profilera moguće je napraviti novo nadgledanje (eng. trace)

odabirom stavke "File / New Trace…". U konačnici, pojavljuje se dijalog kao na Slici 5.7.2

koji sadrži dvije kartice – "General" i "Event Selection".

U kartici "General" moguće je odabrati jedan od već postojećih predložaka kojim se

definiraju promatrane klase događaja i povratni podaci. Osim standardnog

(podrazumijevanog) predloška koji služi za općenito nadgledanje rada SQL Servera

moguće je koristiti i sljedeće predloške:

▪ SP_Counts – podaci o izvršavanju uskladištenih procedura

▪ TSQL – nadgledanje upita iz klijent aplikacija za potrebe otkrivanja grešaka

▪ TSQL_Duration – prikladno za identifikaciju sporih upita klijent aplikacija

▪ TSQL_Grouped – grupiranje izvršenih upita po klijentima ili korisnicima

▪ TSQL_Locks – prikladno za analizu događaja poput potpunog zastoja itd.



▪ TSQL_Replay – prikladno za nadgledanje događaja koji se ponavljaju

▪ Tuning – prilagođeno za potrebe analize u Database Engine Tuning Advisor alatu

U kartici "Event Selection" (Slika 5.7.2) moguće je detaljno definirati događaje koji se

nadgledaju, a klikom na gumbe "Column Filters..." i "Organize Columns…" dodatno filtrirati

i organizirati povratne podatke. Primjerice, filterima je moguće suziti područje nadgledanja

na točno određenu bazu podataka, prijavni nalog itd.

Slika 5.7.3. Nadgledanje događaja SQL Server Profiler alatom

Nakon što se pokrene nadgledanje pojavljuje se dijalog kao na Slici 5.7.3. Sukladno

definiranim filterima i stupcima nakon svakog događaja (primjerice, poziv uskladištene

procedure, izvršavanje nekog SQL upita, prijava na SQL Server itd.) pojavit će se dodatni

redak s opisom tog događaja.

Tako je na Slici 5.7.3 označen redak kojim je zabilježen SELECT upit napravljen unutar

SSMS aplikacije. Osim što je zabilježen kompletan upit vidljivo je tko ga je izvršio (korisnik

'sa') te iz konteksta koje baze podataka (master). Također je moguće prikazati datum i

vrijeme početka i kraja izvršavanja upita (na razini milisekunde) ukoliko provjeravamo

performanse izvršavanja.

Rezultat nadgledanja moguće je spremiti u datoteku ili tablicu, a oboje je moguće priložiti

alatu Database Engine Tuning Advisor koji će analizom tog sadržaja eventualno predložiti



kreiranje novih indeksa ili neka druga rješenja za poboljšanje performansi. Ovaj alat

moguće je pronaći i pokrenuti na sličan način kao i SQL Server Profiler (Slika 5.7.1) ili

izravno desnim klikom na označeni upit u SSMS-u te odabirom stavke "Analyze Query in

Database Engine Tuning Advisor".

5.8. SQL Server Audit

Izlaskom SQL Servera 2008 predstavljen je SQL Server Audit. On također

omogućuje nadgledanje rada SQL Servera i baza podataka, ali nudi bolje performanse i

granulaciju. Događaj (skupinu događaja) moguće je promatrati na razini instance, baze

podataka, sheme ili objekta te u kontekstu skupine (uloge) ili specifičnog korisnika.

Slika 5.8.1. Kreiranje SQL Server Audit objekta

Bilo da je riječ o nadgledanju rada instance ili njenih baza podataka, najprije je potrebno

kreirati audit objekt (Slika 5.8.1). On se kreira u instanci SQL Servera (stavka "Security /

Audits / New Audit…"), a njime se definira maksimalno vrijeme procesiranja događaja

(podrazumijevano 1000 ms), akcija u slučaju neuspjeha spremanja događaja (nastavi



dalje, ugasi server, otkaži operaciju) te odredište (datoteka, sigurnosni dnevnik, aplikacijski

dnevnik). SQL Server audit objekt moguće je kreirati i izravnim izvršavanjem T-SQL koda,


Primjer 5.8.1 – Kreiranje audit objekta izvršavanjem T-SQL koda

USE [master] CREATE SERVER AUDIT [Moje_nadgledanje] TO FILE( FILEPATH = N'C:\SQLServer_Audit\' ,MAXSIZE = 0 MB ,MAX_ROLLOVER_FILES = 2147483647 ,RESERVE_DISK_SPACE = OFF ) WITH( QUEUE_DELAY = 1000 ,ON_FAILURE = CONTINUE ) ALTER SERVER AUDIT [Moje_nadgledanje] WITH (STATE = OFF)

Tek nakon kreiranja audit objekta moguće je započeti nadgledanje instance ili pojedine

baze podataka kreiranjem zasebnih audit specifikacija. Tako se SQL Server audit

specifikacija koristi za nadgledanje rada instance, dok audit specifikacija baze podataka

kada se prate događaji unutar neke baze podataka. Svaka audit specifikacija može pratiti

jedan ili više događaja odabirom odgovarajućih akcija koje mogu biti specifične ili skupne.

Slika 5.8.2. Kreiranje SQL Server audit specifikacije



Primjerice, ukoliko iz sigurnosnih razloga želimo pratiti sve neuspješne prijave u SQL

Serveru, potrebno je kreirati SQL Server audit specifikaciju korištenjem SSMS alata (Slika

5.8.2) ili izravno izvršavanjem T-SQL koda (Primjer 5.8.2). Sve SQL Server audit

specifikacije moguće je pronaći pod stavkom "Security / SQL Server Audit Specifications".

Primjer 5.8.2 – Kreiranje SQL Server audit specifikacije izvršavanjem T-SQL koda

USE MASTER CREATE SERVER AUDIT SPECIFICATION [Neuspjesni_login] FOR SERVER AUDIT [Moje_nadgledanje] ADD (FAILED_LOGIN_GROUP) WITH (STATE = OFF)

Svaka audit specifikacija sadrži ime audit objekta čije postavke koristi pri nadgledanju rada

te jedan ili više događaja (akcija) koji se nadgledaju. Tako u primjeru sa Slike 5.8.2

nadgleda se akcija FAILED_LOGIN_GROUP kojom se bilježe sve neuspješne prijave.

Također, moguće je pratiti i sve uspješne prijave, akcije vezane za općenite operacije nad

bazama podataka (kreiranje, brisanje, izmjena), promjene lozinke korisnika itd. [51]

Slika 5.8.3. Pregled neuspješnih prijava

Audit objekti i specifikacije nakon kreiranja podrazumijevano su onemogućeni, odnosno

deaktivirani. Da bismo ih aktivirali te time pokrenuli nadgledanje rada SQL Servera i baza

podataka potrebno je desnim klikom na njih odabrati stavku "Enable…" ili izvršiti

odgovarajući T-SQL kod, kao u Primjeru 5.8.3.



Primjer 5.8.3 – Aktiviranje SQL Server audit objekta i specifikacije izvršavanjem T-SQL koda

USE MASTER -- aktiviranje server audit objekta ALTER SERVER AUDIT [Moje_nadgledanje] WITH (STATE=ON) -- aktiviranje server audit specifikacije ALTER SERVER AUDIT SPECIFICATION [Neuspjesni_login] WITH (STATE=ON)

Za pregled svih zabilježenih događaja potrebno je desnim klikom na audit objekt odabrati

stavku "View Audit Logs". Tada se pojavljuje dijalog kao na Slici 5.8.3 koji prikazuje sve

zabilježene događaje i njihove detalje. Tako je u navedenoj slici moguće primijetiti

neuspješni pokušaj prijave korisnika "Login1" zbog netočne lozinke.

Nadgledanje rada važno je i zbog sigurnosne strategije u kojoj pojedinac ili skupina ima

ovlasti pristupa i vršenja operacija nad osjetljivim podacima, ali te ovlasti smije koristiti

samo u opravdanim situacijama (primjerice, uz sudski nalog). Tada je moguće kreirati audit

specifikaciju baze podataka (stavka "<ime_baze_podataka> / Security / Database Audit

Specifications / New…") pomoću koje je moguće nadgledati sve takve akcije.

Slika 5.8.4. Kreiranje audit specifikacije baze podataka

I ovaj tip specifikacije može sadržavati jednu ili više akcija, a ovisno o tipu akcije, tj. njenom

području djelovanja (baza podataka, shema ili objekt), potrebno je navesti shemu i ime

nadgledanog objekta te korisnika ili ulogu nad kojom se vrši nadgledanje (Slika 5.8.4). Ako

je riječ o nadgledanju rada svih korisnika, najčešće se odabire uloga "public" budući da su

svi korisnici inicijalno članovi te uloge.

U primjeru na Slici 5.8.4 kreira se audit specifikacija baze podataka kojom se nadgledaju

svi SELECT upiti nad tablicom (objektom) "Kupac" od strane bilo kojeg korisnika (uloga

"public"). Pregledom dnevnika nadgledanja (eng. audit log) moguće je vidjeti zapise kao

na Slici 5.8.5.



Slika 5.8.5. Pregled izvršenih SELECT upita nad tablicom "Kupac"

Za svaki SELECT upit sada je moguće vidjeti datum i vrijeme njegovog izvršavanja, kako

je točno izgledao sadržaj upita te koji korisnik ga je izvršio. Na sličan način moguće je

pregledati i ostale akcije poput brisanja, umetanja ili izmjene podataka te izvršene

administrativne zadaće poput izrade i povrata rezervnih kopija, promjene lozinke korisnika

u bazi podataka itd. [51]

SQL Server Audit danas je preferirana metoda za nadgledanje rada jer među ostalim,

administratori ne moraju koristiti dodatne alate poput SQL Server Profilera kako bi

pojednostavili ovakve zadaće.



6. Tehnologije visoke dostupnosti

6.1. Uvod u replikaciju

Replikacija je postupak kopiranja i distribucije baze podataka na jednu ili više

različitih instanci. Potreba za replikacijom najčešće se javlja kada se želi osigurati bolja

dostupnost i performanse, ali i kada je potrebna raspodjela opterećenja te smanjenje

podatkovnog prometa između udaljenih lokacija.

Vrlo se često pojmovi poput replikacije i sinkronizacije miješaju. Naime, u postupku

replikacije kopiraju se svi objekti i podaci, dok sinkronizacija podrazumijeva tek ažuriranje

naknadno izmijenjenog sadržaja među pojedinim instancama. Sinkronizacija ne mora biti

automatska pa se može dogoditi da izmjene u bazi podataka jedne instance nisu još uvijek

ažurirane u kopijama (replikama) te baze podataka unutar drugih instanci.

U SQL Serveru postoji nekoliko tipova replikacije, a prije njihove implementacije potrebno

je poznavati neke od ključnih pojmova.

Pojam Opis

Izdavač SQL Server instanca koja objavljuje podatke prema drugim instancama.

Pretplatnik SQL Server instanca koja prima podatke.

Distributer

SQL Server instanca koja dostavlja sadržaj od izdavača prema

pretplatniku. Izdavač također može biti i distributer (lokalni distributer), a

u protivnom je riječ o udaljenom distributeru.

Članak Objekt baze podataka koji se objavljuje.

Publikacija Skupina članaka koja se objavljuje.

Tablica 6.1.1. Ključni pojmovi u replikaciji

Kao što je prikazano Tablicom 6.1.1, replikaciju možemo zamisliti kao proces izdavanja i

distribucije časopisa. Moguće ju je implementirati korištenjem više različitih topologija, a

najčešće je riječ o gospodar-gospodar (eng. master-master) te gospodar-podređeni (eng.



master-subordinate) pristupima. Pristupom gospodar-gospodar omogućuje se uređivanje

podataka u svakoj od replika, nakon čega se one međusobno sinkroniziraju. Drugi pristup

namijenjen je situacijama kada se podaci uređuju samo u instanci gospodara, dok su

replicirani podaci u podređenim instancama namijenjeni samo za čitanje. [52]

Slika 6.1.1. Pregled replikacijskog modela [53]

U postupku replikacije sudjeluju i replikacijski agenti. To su pomoćni programi koji prate

promjene nad podacima te sudjeluju u njihovoj distribuciji (Slika 6.1.1). Postoji nekoliko

vrsta replikacijskih agenata:

▪ Agent snimke (eng. snapshot agent)

▪ Agent distribucije (eng. distribution agent)

▪ Agent pregleda dnevnika (eng. log reader agent)

▪ Agent pregleda reda (eng. queue reader agent)

Ovisno o odabranom tipu replikacije koristi se jedan ili više replikacijskih agenata, a njihove

zadaće podrazumijevano se izvršavaju kao SQL Server Agent poslovi. Moguće ih je

pokrenuti i preko komandne linije, a administrirati i pomoću SSMS alata. Štoviše, kao jedan

od pripremnih koraka replikacije poželjno je za svaki od replikacijskih agenata kreirati

Windows korisnički račun na računalu poslužitelja sa odgovarajućim pravima i dozvolama.

Implementacija replikacije tipično započinje kreiranjem publikacije. Korištenjem SSMS

alata potrebno je desnim klikom na stavku "Replication / Local Publication" odabrati "New

Publication…". Tada se pojavljuje dijalog kao na Slici 6.1.2.



Slika 6.1.2. Odabir distributera

Distributer je instanca koja sadrži distribucijsku bazu podataka, a unutar nje spremaju se

podaci o aktivnostima te izvršene transakcije koje je potrebno sinkronizirati. Instanca

izdavača može ujedno biti i distributer ili je za to moguće odabrati neku drugu instancu.

Slika 6.1.3. Odabir mape snimki

Snimka publikacije sprema se u mapi snimki (eng. snapshot folder, Slika 6.1.3). Ovoj mapi

pristup moraju imati svi zainteresirani replikacijski agenti, što je potrebno osigurati

dodjeljivanjem odgovarajućih prava i dozvola Windows korisničkim računima tih agenata.



U ovom koraku također je potrebno paziti na tip budućih pretplata. Replicirane podatke

moguće je slati po principu guranja od strane distributera prema pretplatniku (eng. push)

ili ih na zahtjev pretplatnika povući od izdavača (eng. pull). Podrazumijevano je podržana

metoda guranja, a za podršku metode povlačenja mapa snimki mora biti definirana kao

dijeljena mrežna mapa.

Klikom na gumb "Next" pojavljuje se dijalog u kojemu je potrebno odabrati bazu podataka

koju se želi replicirati te tip replikacije. Neovisno o odabranom tipu replikacije u konačnici

potrebno je odabrati članke (objekte baze podataka) koje se želi replicirati (Slika 6.1.4).

Slika 6.1.4. Odabir članaka

Članci su grupirani po tipu, a prikazuju se samo oni tipovi članaka koji postoje u odabranoj

bazi podataka. Svakom članku ili skupini članaka također je moguće definirati neka od

svojstava (gumb "Article Properties", Slika 6.1.4) poput akcije u slučaju kada članak već

postoji kod pretplatnika, odabir tipova indeksa za kopiranje itd. Štoviše, sadržaj članaka u

idućem koraku moguće je filtrirati te time definirati koji se točno sadržaj želi replicirati.

Nakon kreiranja publikacije najčešće će odmah biti potrebno kreirati njenu trenutnu snimku

(eng. snapshot) za potrebe inicijalnog kopiranja publikacije svakom od pretplatnika, a prije

toga unijeti i podatke o korisničkim računima svih potrebnih replikacijskih agenata.



6.2. Replikacija snimke stanja

Snimka stanja (eng. snapshot) predstavlja sadržaj publikacije u određenom trenutku

u vremenu. Takvu snimku (stanje) moguće je replicirati kod jednog ili više pretplatnika te

time osigurati da svaki od njih ima istu publikaciju, odnosno objekte i sadržaj iz istog

datuma i vremena.

Primjerice, pretpostavimo da svaka benzinska postaja koristi lokalnu bazu podataka iz koje

čita cijene pojedinih goriva. Ukoliko se cijena goriva mijenja jednom tjedno to znači da bi

se u to zadano datum i vrijeme nove cijene mogle učitati kopiranjem i primjenom

(replikacijom) najnovije snimke stanja.

Replikacija snimke stanja (eng. snapshot replication) koristi gospodar-podređeni pristup

gdje su podaci kod pretplatnika namijenjeni samo za čitanje. Zbog veličine snimke ovaj tip

replikacije pogodan je tek u slučajevima kada se repliciraju manje količine podataka te

kada se izmjene nad publikacijom događaju rijetko. Ipak, vrlo često koristi se i pri

implementaciji ostalih tipova replikacije da bi se svakom od pretplatnika kopirala inicijalna

publikacija, odnosno njena aktualna snimka.

Slika 6.2.1. Replikacija snimka [54]

U procesu replikacije ovog tipa sudjeluju dva replikacijska agenta. Agent snimke (eng.

snapshot agent) čita publikaciju te kreira i sprema njen snimak u mapu snimaka (Slika

6.1.3). Zatim, agent distribucije (eng. distribution agent) dohvaća tu snimku te ju kopira i

primjenjuje kod pretplatnika (Slika 6.2.1). Prethodno je potrebno osigurati da svaki od

replikacijskih agenata ima odgovarajuća prava i dozvole nad mapom snimaka.



Slika 6.2.2. Akcije za već postojeće članke

Pretplatnici ovog tipa replikacije ne prate naknadne izmjene publikacije kod izdavača a

mogu ih dobiti tek nakon izrade i dohvaćanja sljedeće snimke. Replikacijom snimka tada

će se podrazumijevano prepisati svi postojeći članci kod pretplatnika i to na način da će ih

se prvo izbrisati (DROP) a zatim ponovno kreirati na osnovu sadržaja snimka. Također je

moguće odabrati i neku drugu akciju (Slika 6.2.2) prilikom definiranja svojstava članaka na

Slici 6.1.4 (gumb "Article Properties").

6.3. Transakcijska replikacija

Kada replikacija snimke stanja zbog svoje veličine postane "preskupa" ili kada je

riječ o manjim ali češćim izmjenama publikacije, pribjegava se korištenju transakcijske

replikacije. Ovaj tip replikacije također radi po principu "gospodar-podređeni" gdje su

podaci u pretplatnicima namijenjeni samo za čitanje.

Slika 6.3.1. Transakcijska replikacija [55]

Transakcijska replikacija započinje replikacijom zadnje snimke stanja kako bi svi

pretplatnici imali istu početnu publikaciju. Sve naknadne izmjene publikacije izdavača



(obavljene transakcije) prate se pomoću agenta pregleda dnevnika (eng. log reader agent)

koji te izmjene sprema u distribucijsku bazu podataka. Tada agent distribucije automatski

prenosi te izmjene postojećim pretplatnicima i to točno onim redoslijedom kojim su se

dogodili u publikaciji izdavača.

Izmijenjeni zapisi u publikacijama pretplatnika bit će prepisani prilikom sljedeće

sinkronizacije. Međutim, ukoliko su ti zapisi u međuvremenu bili izbrisan, replikacija će

završiti neuspjehom. [55]

Za primjer, transakcijsku replikaciju možemo upotrijebiti u situaciji kada je u realnom

vremenu potrebno sinkronizirati cijene proizvoda u dućanima. Ukoliko svaki dućan koristi

lokalnu bazu podataka, svaka promjena cijene proizvoda u središnjoj bazi podataka

automatski će tada biti sinkronizirana u lokalnim bazama podataka pojedinih dućana. U

ovakvoj situaciji neprikladno bi bilo koristiti replikaciju snimke stanja jer bi se tada prenosila

cijela publikacija, i to samo njeno stanje u vrijeme izrade te snimke.

Također postoji i poseban oblik transakcijske replikacije koji se koristi za sinkronizaciju

istorazinskih instanci (eng. peer-to-peer replication). Svaka instanca ujedno je izdavač i

pretplatnik, a najčešće se koristi u svrhu raspodjele opterećenja te za omogućavanje bolje

dostupnosti podataka u slučaju prestanka rada jedne od instanci. Ovaj tip replikacije

dostupan je samo u Enterprise inačici SQL Servera.

Slika 6.3.2. Raspodjela opterećenja sinkronizacijom istorazinskih instanci [56]



U primjerima na Slici 6.3.2 mogu se primijetiti dva moguća slučaja. U lijevom dijelu slike

riječ je o dvije instance gdje prva (A) može biti zadužena za obrađivanje zahtjeva za

proizvode od A-M, a druga instanca (B) zahtjeva za proizvode N-Z. Na taj način dobiva se

raspodjela opterećenja, a bilo koja izmjena bilo na instanci A ili B rezultirat će automatskom

sinkronizacijom izmjena između te dvije instance.

U desnom dijelu Sike 6.3.2 može se primijetiti vrlo slična situacija. Instanca A zadužena je

za obradu zahtjeva za čitanje i dohvat podataka, dok instanca B obrađuje sve zahtjeve za

unos novih i izmjenu postojećih podataka.

6.4. Replikacija spajanjem

Replikacija spajanjem (eng. merge replication) vrlo često se koristi u slučajevima

kada pojedini pretplatnici nisu u mogućnosti stalno biti povezani sa središnjom bazom

podataka. Oni tada autonomno mogu uređivati podatke koje imaju u svojoj lokalnoj bazi, a

sve se napravljene izmjene zajedno s izmjenama svih ostalih pretplatnika spajaju i

međusobno sinkroniziraju.

Slika 6.4.1. Replikacija spajanjem [57]

Replikacija spajanjem također započinje inicijalnom replikacijom snimke stanja, a sve

daljnje promjene nad publikacijom kod izdavača i pretplatnika prate se zasebnim

(automatski kreiranim) okidačima nad repliciranim tablicama. Oni će u sistemskim



tablicama bilježiti informacije o izmijenjenim zapisima, nakon čega će agent spajanja (eng.

merge agent) sinkronizirati te izmjene s izdavačem i ostalim pretplatnicima.

Da bi se promjene nad zapisima mogle pratiti, replikacija spajanjem zahtjeva da svaka

replicirana tablica sadrži stupac UNIQUEIDENTIFIER tipa. Upravo taj podatak koristi se u

okidačima kako bi se jednoznačno mogli identificirati izmijenjeni zapisi. Štoviše, osim ovog

podataka, bilježi se i informacija o izmijenjenom stupcu ukoliko se promijene nad zapisima

prate na nivou stupaca (Slika 6.4.2). Podrazumijevano, izmjene se prate na razini zapisa.

Slika 6.4.2. Načini praćenja izmjena u replikaciji spajanjem

S obzirom da mnogo pretplatnika može mijenjati iste podatke, moguće je da prilikom

sinkronizacije dođe do konflikta među različitim inačicama istih zapisa. U tom slučaju SQL

Server koristi rješavač konflikata (eng. conflict resolver) koji odlučuje o prihvaćenom

zapisu. Postoji podrazumijevani rješavač konflikata, a moguće je napisati i vlastiti. [57]

6.5. Replikacijski pretplatnici

Izradi pretplate može se pristupiti tek nakon izrade publikacije, a moguće ju je izraditi

izravno iz instance izdavača ili iz instance budućeg pretplatnika. Primjerice, pretpostavimo

da u instanci izdavača već postoji publikacija "TransakcijskaReplikacija-TestDB". Desnim

klikom na publikaciju te odabirom stavke "New Subscriptions…" kreće se u postupak izrade

pretplate (Slika 6.5.1).

Slika 6.5.1. Novi pretplatnik



Ukoliko se pretplata kreira iz instance pretplatnika, prvo će biti potrebno prijaviti se u

instancu izdavača te odabrati željenu publikaciju. U protivnom (pretplata se kreira iz

instance izdavača) popis publikacija tog izdavača automatski će biti vidljiv (Slika 6.5.2).

Slika 6.5.2. Odabir publikacije u instanci izdavača

U narednom dijalogu potrebno je odabrati način distribucije, tj. hoće li biti riječ o

automatiziranom guranju (eng. push) repliciranih podataka od strane distributera prema

svim pretplatnicima ili će pretplatnik povlačiti replicirane podatke na vlastiti zahtjev (eng.

pull). Prvim načinom, distribucija se odvija centralizirano i s više kontrole, dok se drugim

načinom smanjuje opterećenje i posao distributera. Za početak je preporuka koristiti

metodu guranja jer ju je brže omogućiti zbog manje količine administrativnih poslova.

Slika 6.5.3. Odabir instanci pretplatnika i odredišnih baza podataka

Najčešća je praksa u instanci pretplatnika napraviti novu bazu podataka koja ima isto ime

kao i baza podataka izdavača (Slika 6.5.3). Međutim, u instanci pretplatnika za potrebe

replikacije moguće je iskoristiti i već postojeću bazu podataka. Također, instanca

pretplatnika može biti ista kao i instanca izdavača, ali u tom slučaju odredišna baza

podataka mora biti drugačijeg imena.



U završim koracima potrebno je unijeti korisničke podatke agenta distribucije te definirati

njegov način rada (konstantni rad, na zahtjev ili prema definiranom rasporedu). Preporuka

je da agent distribucije radi konstantno kako bi se baze podataka svaki puta sinkronizirale

u najbržem mogućem roku.

Slika 6.5.4. Inicijalizacija pretplate replikacijom snimke stanja

Nakon kreiranja, svaku pretplatu potrebno je inicijalizirati replikacijom snimke stanja (Slika

6.5.4). Također, i inicijalizaciju pretplate poželjno je izvršiti čim prije (podrazumijevano

odmah nakon kreiranja pretplate) kako bi baza podataka pretplatnika u što kraćem roku

bila spremna za daljnju sinkronizaciju. Alternativno, pretplatu je moguće inicijalizirati i

prilikom sljedeće predviđene sinkronizacije.

Slika 6.5.5. Publikacija i njeni pretplatnici

Kreirana pretplata vidljiva je kako u instanci pretplatnika tako i u instanci izdavača (Slika

6.5.5). Nakon njenog kreiranja, ovisno o odabranom načinu inicijalizacije, prvo će se

dogoditi replikacija snimke stanja, dok daljnja sinkronizacija ovisi o odabranom tipu

replikacije i definiranim rasporedima agent poslova te replikacijskih agenata.



Slika 6.5.6. Replikacijski monitor

Status i tijek replikacije moguće je pratiti korištenjem replikacijskog monitora (eng.

replication monitor), a pristup njemu imaju svi članovi sysadmin i replmonitor uloga. Kao

što je prikazano Slikom 6.5.6, pomoću replikacijskog monitora moguće je vidjeti povijest

sinkronizacije iz smjera distributera prema pretplatnicima (i obrnuto), broj prenesenih

transakcija te sve eventualne greške.

Replikacijski monitor može se pokrenuti izravno iz SSMS alata desnim klikom na

publikaciju ili jednog od pretplatnika te odabirom stavke "Launch Replication Monitor". U

istom izborniku moguće je pregledati i status agenta snimke (eng. snapshot agent) te

agenta pregleda dnevnika (eng. log reader agent).

6.6. Otpremanje dnevnika transakcija

Osim replikacije postoje i druge metode za osiguravanje bolje dostupnosti podataka

u slučaju katastrofe. Jedna od njih je i metoda otpremanja dnevnika transakcija (eng. Log

shipping) koja se vrlo često koristi zbog jednostavnosti te malih zahtjeva za resursima.

Metoda radi na principu periodičke izrade i otpremanja rezervne kopije dnevnika

transakcija primarne baze podataka iz primarne instance prema jednoj ili više sekundarnih

baza podataka u različitim sekundarnim instancama.



Slika 6.6.1. Otpremanje dnevnika transakcija [58]

Svaka rezervna kopija dnevnika transakcija primarne baze podataka kopira se na dijeljenu

mrežnu lokaciju kojoj mogu pristupiti sve sekundarne instance (Slika 6.6.1). Zatim, svaka

od sekundarnih instanci kopira rezervnu kopiju iz dijeljene mrežne lokacije u svoj lokalni

prostor te izvrši njen povrat (eng. Restore) u svojoj (sekundarnoj) bazi podataka. Tada je

u slučaju nedostupnosti primarne baze podataka moguće ručno preusmjeriti se (eng.

Failover) na jednu od sekundarnih instanci te koristiti sekundarnu bazu podataka.

Ova metoda može koristiti i neobaveznu instancu monitora koja nadgleda operacije izrade

i povrata rezervnih kopija te po potrebi generira upozorenja ukoliko se neka od operacija

nije izvršila po predviđenom planu.

Slika 6.6.2. Konfiguracija otpremanja dnevnika transakcija

Korištenjem SSMS alata na jednostavan način moguće je konfigurirati ovu metodu.

Desnim klikom na bazu podataka te odabirom stavke "Properties" pojavljuje se dijalog kao



na Slici 6.6.2. U njemu je moguće definirati primarnu bazu podataka, odabrati mrežnu

lokaciju za spremanje rezervnih kopija dnevnika transakcija te odabrati sekundarne

instance SQL Servera.

Osim u SQL Serveru, metodu otpremanja dnevnika transakcija moguće je se koristiti i u

RDBMS sustavima poput MySQL, PostgreSQL, Oracle itd.

6.7. Zrcaljenje baze podataka

Bolja dostupnost baze podataka može se osigurati i korištenjem metode zrcaljenja

(eng. Database mirroring). Ova metoda zapravo predstavlja metodu otpremanja dnevnika

transakcija u realnom vremenu s podrškom za automatsko preusmjeravanje (eng.

Failover). U njoj sudjeluju primarna (eng. Principal), zrcalna (eng. Mirror) te neobavezna

svjedok (eng. Witness) instanca, kao što je prikazano slikom 6.7.1.

Slika 6.7.1. Zrcaljenje baze podataka

Nakon svake izvršene transakcije unutar baze podataka u glavnoj instanci njen zapis

dnevnika transakcija automatski se šalje bazi podataka zrcalne instance kako bi se te

transakcije i tamo čim prije replicirale. Svjedok instanca provjerava obje instance te u

slučaju nedostupnosti glavne automatski preusmjerava (eng. Failover) na zrcalnu instancu.

Svjedok instanca nije obavezna, no u tom slučaju preusmjeravanje neće moći biti

automatsko već ručno.



Zrcaliti je moguće jednu po jednu bazu podataka, a prethodno svaka od njih mora koristiti

potpuni model oporavka (eng. Full recovery mode). Štoviše, prije iniciranja procesa

zrcaljenja potrebno je napraviti potpunu rezervnu kopiju baze podataka glavne instance te

izvršiti njen povrat u zrcalnoj instanci korištenjem stavke "WITH NORECOVERY".

Slika 6.7.2. Konfiguracija zrcaljenja baze podataka

Zrcaljenje je moguće inicirati i konfigurirati pomoću SSMS alata desnim klikom na bazu

podataka te odabirom stavke "Properties", nakon čega se pojavljuje dijalog kao na Slici

6.7.2. U njemu je moguće odabrati glavnu, zrcalnu te svjedok instancu, kao i odrediti način

rada (eng. Operating mode).

Moguće je koristiti tri načina rada. Rad prilagođen visokim performansama (eng. High

performance) podrazumijeva korištenje samo glavne i zrcalne instance bez mogućnosti

automatskog preusmjeravanja. Podaci se prvo spremaju u glavnoj instanci, a zatim ih se

prenosi na zrcalnu instancu. Tada se koristi asinkrona komunikacija te je u slučaju

katastrofe jedino moguće ručno preusmjerenje na zrcalnu instancu prilikom čega može

doći i do neželjenog gubitka podataka. Druga dva načina rada koriste sinkronu

komunikaciju prilikom koje se podaci garantirano spremaju na obje instance, a mogućnost

automatskog preusmjeravanja ovisi o postojanosti svjedok instance.



Da bi klijent aplikaciju pripremili za automatsko preusmjeravanje u slučaju nedostupnosti

glavne instance u izrazu "Connection string" moguće je definirati izraz "Failover Partner".

Data Source = AdresaGlavneInstance; Failover Partner = AdresaZrcalneInstance;

Initial Catalog = MojaBazaPodataka; Integrated Security = True;

U usporedbi sa metodom otpremanja dnevnika transakcija zrcaljenje baze podataka nudi

automatsko preusmjeravanje u slučaju nedostupnosti. Ipak, omogućuje korištenje samo

jedne zrcalne instance čija baza podataka nije dostupna za čitanje i pisanje sve do trenutka

preusmjeravanja.

6.8. AlwaysOn rješenja

Izlaskom SQL Servera 2012 predstavljena su AlwaysOn rješenja koja na još većem

nivou osiguravaju bolju dostupnost baza podataka. Štoviše, Microsoft je najavio ukidanje

podrške za metodu zrcaljenja u narednim inačicama SQL Servera upravo kako bi se u

budućnosti koristila AlwaysOn rješenja. Razlikujemo dva osnovna oblika:

▪ AlwaysOn Failover Clustering Instances (FCI)

▪ AlwaysOn Availability Groups (AG)

Prvo rješenje (FCI) dostupno je i u standardnoj inačici SQL Servera, a osnovni cilj mu je

omogućiti dostupnost baza podataka čak i u slučaju katastrofe tj. potpune nedostupnosti

poslužitelja na kojemu se nalazi instanca SQL Servera.

Slika 6.8.1. Windows Server Failover Cluster (WSFC)



Rješenje radi na način da se jedna instanca SQL Servera propagira kroz više čvorova po

principu WSFC-a (Slika 6.8.1). Pojedini čvor ne sadrži lokalnu kopiju datoteka baza

podataka već se sve one nalaze na dijeljenoj mrežnoj lokaciji koju koristi aktivni čvor. Sve

dok je jedan čvor aktivan ostali čvorovi su u stanju čekanja, a kada aktivni čvor više nije

dostupan onda jedan od preostalih čvorova postaje aktivan. Novi aktivni čvor također

ukazuje na iste datoteke koje se nalaze na dijeljenoj mrežnoj lokaciji, te se time osigurava

dostupnost svih baza podataka te instance. Upravo ovo je jedna od prednosti u usporedbi

sa metodom zrcaljenja koja radi na principu poboljšanja dostupnosti samo jedne baze

podataka.

Za razliku od ovog rješenja AlwaysOn nudi i "Availability Groups" (AG) rješenje koje je

dostupno samo u Enterprise inačici SQL Servera. Ono predstavlja unaprijeđenu inačicu

metode zrcaljenja koja nudi mogućnost korištenja više zrcalnih replika. U SQL Serveru

2016 AG rješenje podržava do 9 replika (jedna primarna i osam sekundarnih), a

sekundarne replike mogu biti omogućene ili onemogućene za čitanje (u metodi zrcaljenja

sekundarna replika uvijek je onemogućena za čitanje).

Slika 6.8.2. AlwaysOn Availability Group (AG) [59]

AG rješenje koristi slušač (eng. Listener) koji zapravo predstavlja DNS ime virtualne mreže.

On sadrži popis IP adresa svih replika te se brine da se klijent uvijek spoji na primarnu



(aktivnu) repliku. Zbog korištenja DNS imena klijent ne može znati koje sve replike postoje,

a ukoliko se aktivna replika promijeni klijent neće biti niti svjestan te promjene. Za

usporedbu, u metodi zrcaljenja postojale su samo dvije replike a klijent je znao IP adresu

svake od njih.

Iako mnoge usporedbe pokazuju da AlwaysOn rješenja omogućavaju puno bolju

dostupnost SQL Server baza podataka zbog svojih dodatnih zahtjeva za resursima

najčešće se upotrebljavaju samo kod Enterprise korisnika. Korisnici srednje i niže razine

zahtjeva najčešće koriste metodu otpremanja dnevnika transakcija.



Reference

[1] gorila.jutarnji.hr, »Koja je razlika između podatka i informacije, što je podatak, a što informacija,«

[Mrežno]. Available: http://gorila.jutarnji.hr/profile/digitalac/2011/06/03/koja-je-razlika-izmeu-podatka-i-

informacije-to-je-podatak-a-to-informacija/. [Pokušaj pristupa 2 4 2017].

[2] SQLite, »Most Widely Deployed and Used Database Engine,« [Mrežno]. Available:

https://www.sqlite.org/mostdeployed.html. [Pokušaj pristupa 2 4 2017].

[3] FileMaker, »FileMaker Pro,« [Mrežno]. Available: http://www.filemaker.com/products/filemaker-pro/.

[Pokušaj pristupa 2 4 2017].

[4] Oracle Corporation, »PL/SQL,« [Mrežno]. Available:

http://www.oracle.com/technetwork/database/features/plsql/index.html. [Pokušaj pristupa 2 4 2017].

[5] IBM, »IBM DB2 Express-C: Available at no charge,« [Mrežno]. Available:

https://www.ibm.com/developerworks/downloads/im/db2express/. [Pokušaj pristupa 2 4 2017].

[6] PostgreSQL, »What is PostgreSQL?,« [Mrežno]. Available:

https://www.postgresql.org/docs/9.6/static/intro-whatis.html. [Pokušaj pristupa 2 4 2017].

[7] QuinStreet Enterprise, »What is SQL?,« [Mrežno]. Available: http://www.sqlcourse.com/intro.html.


[8] N. Kabra, »How do RDBMS provide ACID properties (atomicity, consistency, isolation, durability)?,«

[Mrežno]. Available: https://www.quora.com/How-do-RDBMS-provide-ACID-properties-atomicity-

consistency-isolation-durability. [Pokušaj pristupa 4 4 2017].

[9] Microsoft Corporation, »Understanding Isolation Levels,« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/connect/jdbc/understanding-isolation-levels. [Pokušaj pristupa 5 4

2017].

[10] Microsoft Corporation, »Customizing Transaction Isolation Level,« [Mrežno]. Available:

https://msdn.microsoft.com/en-us/library/ms175909.aspx. [Pokušaj pristupa 6 4 2017].

[11] Microsoft Corporation, »Snapshot Isolation in SQL Server,« [Mrežno]. Available:

https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx. [Pokušaj pristupa 7 4 2017].

[12] M. Gupta, »How To Monitor Deadlocks in SQL Server,« [Mrežno]. Available:

https://blogs.technet.microsoft.com/mspfe/2012/06/28/how-to-monitor-deadlocks-in-sql-server/.


[13] Microsoft Corporation, »Get ready for SQL Server 2017,« [Mrežno]. Available:

https://www.microsoft.com/en-us/sql-server/sql-server-2017. [Pokušaj pristupa 19 4 2017].



[14] Microsoft Corporation, »Database Files and Filegroups,« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-files-and-filegroups.


[15] GoDaddy, »What is collation and can I change it on my MS SQL database?,« [Mrežno]. Available:

https://uk.godaddy.com/help/what-is-collation-and-can-i-change-it-on-my-ms-sql-database-4203.


[16] Microsoft Corporation, »Prerequisites for Minimal Logging in Bulk Import,« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/relational-databases/import-export/prerequisites-for-minimal-

logging-in-bulk-import. [Pokušaj pristupa 19 5 2017].

[17] S. Pandey, »Data warehouse Concepts,« [Mrežno]. Available: http://www.techturtle.net/data-

warehouse-concepts/. [Pokušaj pristupa 28 4 2017].

[18] B. Williams, »Data Models for an Automotive Industry Platform,« Database Answers Ltd., [Mrežno].

Available: http://www.databaseanswers.org/data_models/automotive_industry_platform/. [Pokušaj

pristupa 4 5 2017].

[19] Microsoft Corporation, »Referential Integrity,« [Mrežno]. Available: https://msdn.microsoft.com/en-

us/library/aa292166(v=vs.71).aspx. [Pokušaj pristupa 13 5 2017].

[20] Lucid Software Inc., »What is a Database Model,« [Mrežno]. Available:

https://www.lucidchart.com/pages/database-diagram/database-models. [Pokušaj pristupa 16 8 2017].

[21] E. F. Codd, »A Relational Model of Data for Large Shared Data Banks,« Communications of the ACM,

svez. 13, br. 6, p. 377–387, 1970.

[22] 1Keydata, »Second Normal Form (2NF),« [Mrežno]. Available: http://www.1keydata.com/database-

normalization/second-normal-form-2nf.php. [Pokušaj pristupa 23 5 2017].

[23] Microsoft Corporation, »Create table (Transact-SQL) Identity (Property),« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql-identity-property.


[24] A. Jorgensen, P. LeBlanc, J. Chinchilla, J. Segarra i A. Nelson, »Local Temporary Tables,« u

Microsoft® SQL Server® 2012 BIBLE, Indianapolis, John Wiley & Sons, Inc., 2012, p. 406.

[25] Microsoft Corporation, »SELECT - ORDER BY Clause (Transact-SQL),« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/t-sql/queries/select-order-by-clause-transact-sql. [Pokušaj

pristupa 30 6 2017].

[26] A. Ali, »Importance of Statistics and How It Works in SQL Server – Part 1,« Database Journal, 22 12

2014. [Mrežno]. Available: http://www.databasejournal.com/features/mssql/importance-of-statistics-

and-how-it-works-in-sql-server-part-1.html. [Pokušaj pristupa 23 7 2017].



[27] Mircosoft Corporation, »Clustered Index Structures,« [Mrežno]. Available:

https://technet.microsoft.com/en-us/library/ms177443(v=sql.105).aspx. [Pokušaj pristupa 26 7 2017].

[28] Microsoft Corporation, »Nonclustered Index Structures,« [Mrežno]. Available:


[29] Microsoft Corporation, »SR0016: Avoid using sp_ as a prefix for stored procedures,« [Mrežno].

Available: https://msdn.microsoft.com/en-us/library/dd172115(v=vs.100).aspx. [Pokušaj pristupa 8 8

2017].

[30] A. Bertrand, »Benefits of SCHEMABINDING in SQL Server,« [Mrežno]. Available:

https://www.mssqltips.com/sqlservertip/4673/benefits-of-schemabinding-in-sql-server/. [Pokušaj

pristupa 6 8 2017].

[31] Microsoft Corporation, »CREATE TRIGGER (Transact-SQL),« [Mrežno]. Available:

https://technet.microsoft.com/en-us/library/ms189799%28v=sql.105%29.aspx?f=255&MSPPError=-

2147217396. [Pokušaj pristupa 13 8 2017].

[32] K. Kellenberger, »Understanding the Difference between Owners and Schemas in SQL Server,«

SQLTeam Publishing, LLC , [Mrežno]. Available: http://www.sqlteam.com/article/understanding-the-

difference-between-owners-and-schemas-in-sql-server. [Pokušaj pristupa 20 8 2017].

[33] K. B. Kelley, »How to configure password enforcement options for standard SQL Server logins,«

Edgewood Solutions, LLC, [Mrežno]. Available: https://www.mssqltips.com/sqlservertip/1909/how-to-

configure-password-enforcement-options-for-standard-sql-server-logins/. [Pokušaj pristupa 13 9 2017].

[34] Microsoft Corporation, »Create a Database User,« [Mrežno]. Available: https://docs.microsoft.com/en-

us/sql/relational-databases/security/authentication-access/create-a-database-user. [Pokušaj pristupa

16 9 2017].

[35] Microsoft Corporation, »Server-Level Roles,« [Mrežno]. Available: https://docs.microsoft.com/en-

us/sql/relational-databases/security/authentication-access/server-level-roles. [Pokušaj pristupa 26 9

2017].

[36] Microsoft Corporation, »Database-Level Roles,« [Mrežno]. Available: https://docs.microsoft.com/en-

us/sql/relational-databases/security/authentication-access/database-level-roles. [Pokušaj pristupa 28 9

2017].

[37] Microsoft Corporation, »HASHBYTES (Transact-SQL),« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/t-sql/functions/hashbytes-transact-sql. [Pokušaj pristupa 30 9

2017].

[38] B. A. Masood-al-farooq, »SQL Server Encryption,« [Mrežno]. Available: http://sqlmag.com/database-

security/sql-server-encryption. [Pokušaj pristupa 30 9 2017].



[39] Microsoft Corporation, »Transparent Data Encryption (TDE),« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-

encryption. [Pokušaj pristupa 3 10 2017].

[40] R. Sheldon, »SQL Server Encryption: Always Encrypted,« Red Gate Software Ltd, [Mrežno]. Available:

https://www.red-gate.com/simple-talk/sql/database-administration/sql-server-encryption-always-

encrypted/. [Pokušaj pristupa 7 10 2017].

[41] Microsoft Corporation, »Dynamic Data Masking,« [Mrežno]. Available: https://docs.microsoft.com/en-

us/sql/relational-databases/security/dynamic-data-masking. [Pokušaj pristupa 9 10 2017].

[42] A. Shehzad, »Copy Only Backup for SQL Server,« Edgewood Solutions, LLC , [Mrežno]. Available:

https://www.mssqltips.com/sqlservertip/1772/copy-only-backup-for-sql-server/. [Pokušaj pristupa 15 10

2017].

[43] A. Omelchenko, »Differential Backup,« [Mrežno]. Available: https://sqlbak.com/academy/differential-

backup/. [Pokušaj pristupa 19 10 2017].

[44] AskMeSql, »Log shipping - NORECOVRY vs. STANDBY mode,« 10 1 2011. [Mrežno]. Available:

http://askmesql.blogspot.hr/2011/01/log-shipping-norecovery-vs-standby-mode.html. [Pokušaj pristupa

21 10 2017].

[45] Microsoft Corporation, »SQL Server Agent,« [Mrežno]. Available: https://docs.microsoft.com/en-

us/sql/ssms/agent/sql-server-agent#Components. [Pokušaj pristupa 26 10 2017].

[46] Microsoft Corporation, »Maintenance Plans,« [Mrežno]. Available: https://docs.microsoft.com/en-

us/sql/relational-databases/maintenance-plans/maintenance-plans. [Pokušaj pristupa 1 11 2017].

[47] Microsoft Corporation, »Documenting and Scripting Databases,« [Mrežno]. Available:


[48] Microsoft Corporation, »Use the Copy Database Wizard,« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/relational-databases/databases/use-the-copy-database-wizard.


[49] Shais, »20 Best SQL Server Monitoring Tools for all SQL Servers,« Technig, [Mrežno]. Available:

https://www.technig.com/20-best-sql-server-monitoring-tools/. [Pokušaj pristupa 15 11 2017].

[50] P. Reyes, »Using the SQL Server Default Trace to Audit Events,« Edgewood Solutions LLC, [Mrežno].

Available: https://www.mssqltips.com/sqlservertip/3445/using-the-sql-server-default-trace-to-audit-

events/. [Pokušaj pristupa 18 11 2017].

[51] Microsoft Corporation, »SQL Server Audit Action Groups and Actions,« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-

groups-and-actions. [Pokušaj pristupa 23 11 2017].



[52] Microsoft Corporation, »Data Replication and Synchronization Guidance,« [Mrežno]. Available:

https://msdn.microsoft.com/en-us/library/dn589787.aspx. [Pokušaj pristupa 1 12 2017].

[53] Microsoft Corporation, »Replication Publishing Model Overview,« [Mrežno]. Available:

https://docs.microsoft.com/en-us/sql/relational-databases/replication/publish/replication-publishing-

model-overview. [Pokušaj pristupa 3 12 2017].

[54] Microsoft Corporation, »Implementing Master-Subordinate Snapshot Replication Using SQL Server,«

[Mrežno]. Available: https://msdn.microsoft.com/en-us/library/ff648057.aspx. [Pokušaj pristupa 4 12

2017].

[55] Microsoft Corporation, »Implementing Master-Subordinate Transactional Incremental Replication

Using SQL Server,« [Mrežno]. Available: https://msdn.microsoft.com/en-us/library/ff648240.aspx.


[56] Microsoft Corporation, »Peer-to-Peer Transactional Replication,« [Mrežno]. Available:


[57] Microsoft Corporation, »Implementing Master-Master Row-Level Synchronization Using SQL Server,«

[Mrežno]. Available: https://msdn.microsoft.com/en-us/library/ff649591.aspx. [Pokušaj pristupa 7 12

2017].

[58] H. Mohamed, »Log Shipping SQL Server 2012,« 9 3 2014. [Mrežno]. Available:

https://helmymo7amed.wordpress.com/2014/03/09/log-shipping-sql-server-2012/. [Pokušaj pristupa 4

6 2018].

[59] S. Bawany, »SQL Server AlwaysOn – SharePoint 2013 High Availability and Disaster Recovery,« 6 7

2014. [Mrežno]. Available: https://blogs.technet.microsoft.com/salbawany/2014/07/06/sql-server-

alwayson-sharepoint-2013-high-availability-and-disaster-recovery/. [Pokušaj pristupa 2018 7 19].



Ključne riječi

A

Agent distribucije · 144

Agent snimke · 144

Agent spajanja · 148

Always Encrypted · 103

AlwaysOn · 155

Aplikacijske uloge · 94

Asimetrični kriptografski algoritmi · 97

Atomicy · 10

Audit specifikacija · 137

Availability Groups · 156

Ažurirajući pogledi · 57

B

Baza podataka · 5

Bulk-logged · 25

C

Cascade · 35

Collation · 25

Column encryption key · 103

Column master key · 103

Consistency · 10

Č

Članak · 140

D

Database Engine Tuning Advisor · 133

Database mirroring · 153

Datotečne grupe · 24

DB2 · 7

DCL · 8

DDL · 8

DDL okidači · 75

DECRYPTBYKEY · 100

Deleted · 73

Desktop baze podataka · 5

Detach · 130

Diferencijalne rezervne kopije · 114

Distributer · 140, 142

DMK · 99

DML · 8

DML okidači · 71

Dnevnik transakcija · 24

Druga normalna forma · 43

Durability · 16

E

EKM · 101

ENCRYPTBYKEY · 100

Enforce Foreign Key Constraint · 35

e-pošta · 126

ER model · 28

Extended properties · 81

F

Failover · 153

Failover Cluster · 155

Fantomski zapisi · 13

Filegroups · 24

FileMaker · 6

Filtrirani negrupirajući indeks · 64

Fizički podatkovni model · 33

FK · 32

Full · 25

Funkcije sažimanja · 95



G

Globalne privremene tablice · 53

Grupirajući indeks · 58

H

Hijerarhijski model · 39

I

Impersonacija · 89

Informacija · 5

Informix · 7

Inline Table-Valued Functions · 69

Inserted · 73

Instanca · 16

Isolation · 10

Izdavač · 140

Izvedbeni plan · 59

J

Jedan prema jedan · 33

Jedan prema više · 34

K

Klijent-server baza podataka · 6

Ključni atributi · 29

Korisnički računi · 86

Kriptirani pogled · 58

L

Listener · 156

Log sequence numbers · 116

Log shipping · 151

Logički podatkovni model · 31

LSN · 117

M

Maskiranje podataka · 108

MDF · 24

Merge replication · 147

Microsoft Access · 5, 6

Microsoft SQL Server · 7

Mirror · 153

Mixed Mode · 21

Monitor potpunog zastoja · 15

Mrežni model · 40

Multistatement Table-Valued Function · 69

MySQL · 7

N

NDF · 24

Negrupirajući indeks · 63

Ne-ključni atributi · 29

Neponavljajuće čitanje · 12

No Action · 35

O

Obnova indeksa · 64

Ograničenja · 51

Optimistično zaključavanje · 11

Oracle · 7

P

Paradox · 6

Partially contained databases · 86

Peer-to-peer replication · 146

Pesimistično zaključavanje · 11

PF · 32

PK · 32

Plan održavanja · 123

Podrazumijevana instanca · 16

Pogled · 54

Point in time recovery · 115

Ponavljajuće čitanje · 13



Poslovi · 120

Postgre SQL · 7

Potpuna rezervna kopija · 111

Potpuni zastoj · 14

Pretplata · 149

Pretplatnik · 140

Prijavni nalog · 82

Primarni ključ · 50

Privremene tablice · 52

Prljavo čitanje · 12

Prva normalna forma · 42

Publikacija · 140

Q

Query Optimizer · 60

R

Raspored poslova · 122

Recovery model · 25

Referencijalni integritet · 35

Rekurzivna veza · 37

Relacijski model · 40

Reorganizacija indeksa · 64

Replikacija · 140

Replikacijski monitor · 151

S

Schemabingind · 70

Sekvence · 76

Serijalizacija · 13

Server uloge · 84

Set Default · 36

Set NULL · 36

Sheme · 79

Simetrični kriptografski algoritmi · 97

Simple · 25

Sinonimi · 77

Skalarna funkcija · 68

Snimak · 14

SQL · 7

SQL Server Agent · 19, 120

SQL Server Audit · 135

SQL Server Browser · 20, 21

SQL Server Database Engine · 20

SQL Server Profiler · 132

SQL user without login · 89

SQLite · 6

Stalne server uloge · 91

Stalne uloge baze podataka · 93

Sybase · 7

T

Tablice · 49

TCL · 9

TDE · 101

Transakcijska replikacija · 145

Treća normalna forma · 44

T-SQL · 7

U

Uloge baza podataka · 85

Uskladištene procedure · 65

V

Virtualna tablica · 56

Više prema više · 36

Vlasnik · 25, 79

W

Windows authentication mode · 21

Witness · 153

Documents

MODELIRANJE, IMPLEMENTAIJA I ADMINISTRAIJA AZA … · MODELIRANJE, IMPLEMENTAIJA I ADMINISTRAIJA AZA PODATAKA Priručnik na kolegiju ‘Modeliranje i administracija baza podataka