Professional Documents
Culture Documents
Zagreb, 2018
MODELIRANJE, IMPLEMENTACIJA I ADMINISTRACIJA BAZA PODATAKA
Ž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.
SADRŽAJ
1. Uvod u baze podataka................................................................................................... 9
1.1. Što je baza podataka? ........................................................................................ 9
1.2. SQL (Structured Query Language) ................................................................... 11
1.3. ACID svojstva ................................................................................................... 13
1.4. Instalacija i konfiguracija SQL Servera ............................................................. 20
1.5. Kreiranje SQL Server baze podataka ............................................................... 27
2. Dizajn baze podataka .................................................................................................. 33
2.1. Konceptualni podatkovni model ........................................................................ 33
2.2. Logički podatkovni model .................................................................................. 36
2.3. Fizički podatkovni model ................................................................................... 38
2.4. Ostali podatkovni modeli ................................................................................... 43
2.5. Normalizacija baze podataka ............................................................................ 46
2.6. Analiza podataka SQL upitima .......................................................................... 51
3. Objekti baze podataka ................................................................................................. 55
3.1. Tablice .............................................................................................................. 55
3.2. Pogledi .............................................................................................................. 60
3.3. Grupirajući i negrupirajući indeksi ..................................................................... 64
3.4. Uskladištene procedure i funkcije ..................................................................... 71
3.5. DML i DDL okidači ............................................................................................ 77
3.6. Sekvence .......................................................................................................... 82
3.7. Sinonimi ............................................................................................................ 84
4. Organizacija i sigurnost ............................................................................................... 85
4.1. Sheme .............................................................................................................. 85
4.2. Prijavni nalozi .................................................................................................... 88
4.3. Korisnički računi ................................................................................................ 92
4.4. Uloge ................................................................................................................ 95
4.5. Kriptografija u SQL Serveru ............................................................................ 101
4.6. Transparentno šifriranje podataka .................................................................. 106
4.7. Uvijek šifrirani podaci ...................................................................................... 109
4.8. Dinamičko maskiranje podataka ..................................................................... 114
5. Održavanje i nadzor .................................................................................................. 117
5.1. Izrada rezervnih kopija .................................................................................... 117
Uvodna riječ
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.
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.
Informacija
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.
Naziv Opis
Korijene vuče još iz DOS operacijskog sustava, dok postoji i
Paradox posebna Paradox inačica za Windows OS. Paradox se aktivno
koristio u Borland razvojnim alatima Delphi i C++ Builder.
Besplatna baza podataka. Jedna od najraširenijih u svijetu koja radi
SQLite na velikom broju uređaja i platformi, počevši od Android, iOS i
iPhone uređaja, MAC, PC, televizora, automobila itd. [2]
Isključivo za Windows OS. Podržava paralelni (konkurentni) rad do
maksimalno 255 korisnika, te omogućuje razvoj aplikacija i izvještaja
Microsoft Access
koji se spremaju u samoj bazi podataka. Microsoft Access aplikacija
se plaća, dok je sama baza podataka (datoteka) besplatna.
Desktop baza podataka primarno namijenjena za iPad, iPhone i Mac
FileMaker Pro okruženja. Podržava i Windows okruženje te omogućuje integraciju
s Microsoft SQL Server, Oracle i MySQL bazom podataka. [3]
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
Microsoftova relacijska baza podataka (RDBMS) namijenjena
korporativnim okruženjima. Podržava Transact-SQL, ekstenziju
Microsoft SQL Server
SQL-a. Baza je dostupna u velikom broju izdanja od kojih je
Express izdanje potpuno besplatno.
Vlasništvo korporacije Oracle. RDBMS namijenjen krajnje
Oracle zahtjevnim korisnicima te podržava PL/SQL proceduralni jezik.
Također je dostupan u besplatnom Express izdanju. [4]
Vlasništvo korporacije IBM. Uz standardni SQL jezik DB2
DB2 podržava PL/SQL te je također dostupan u besplatnoj Express-
C inačici. [5]
Besplatna (open source) objektno relacijska baza podataka
Postgre SQL (ORDBMS). [6] Postgre SQL koristi PL/pgSQL jezik te u
potpunosti podržava ACID svojstva.
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.
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.
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.
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.
TCL upiti koriste se za upravljanje transakcijama. Njima je moguće uspješno potvrditi kraj
transakcije (COMMIT) ili napraviti njen opoziv (ROLLBACK).
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.
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).
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.
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.
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; --!
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.
Transakcija 1 Transakcija 2
SELECT odjel_id FROM zaposlenik WHERE ID=1
-- ispisuje 1
UPDATE zaposlenik SET odjel_id=2 WHERE ID=1;
COMMIT;
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).
Transakcija 1 Transakcija 2
SELECT * FROM Zaposlenik WHERE odjel_id = 2
COMMIT;
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]
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).
U prvoj operaciji (Slika 1.3.1) 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.
Transakcija 1 Transakcija 2
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
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.
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.
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 poslužitelj 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 poslužitelju 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.
Željko Kovačević, struč.spec.ing.techn.inf. | Tehničko veleučilište u Zagrebu 20
MODELIRANJE, IMPLEMENTACIJA I ADMINISTRACIJA BAZA PODATAKA
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".
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".
Prilikom instalacije nove instance SQL Servera obavezno je potrebno odabrati stavku
"Database Engine Services" (Slika 1.4.4). 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 narednom koraku instalacije potrebno je konfigurirati novu instancu (Slika 1.4.5). 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.
Servis SQL Server Agent koristi se za izvršavanje unaprijed zakazanih poslova (eng. jobs)
u SQL Serveru. Primjerice, ukoliko želite svaki petak u 23:00 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 (Slika 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.
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.
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).
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 (Slika 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.
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
Željko Kovačević, struč.spec.ing.techn.inf. | Tehničko veleučilište u Zagrebu 26
MODELIRANJE, IMPLEMENTACIJA I ADMINISTRACIJA BAZA 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 generiraju odgovarajući SQL upiti čijim
izvršavanjem se kreira specificirana baza podataka.
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 kojeg prikazuje Slika 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
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).
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.
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 to prikazuje Slika 1.5.2.
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.
Pri kreiranju baze podataka moguće je definirati i mnoge druge postavke (automatsko
sažimanje veličine datoteka, omogućavanje šifriranja 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).
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.
Model
Značajka
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
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.
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 prikazane slike (Slika 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.
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 kod nekog drugog
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 prikazani model.
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.
Osim entiteta sada su vidljivi i njihovi atributi, s time da su ključni atributi podcrtani (Slika
2.2.1). Ukoliko entiteti imaju veći broj atributa onda ih je praktičnije predstaviti u obliku
dijagrama klasa ili na sljedeći način:
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 prikazanom primjeru (Slika 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.
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.
Primarni ključ može biti definiran i kao kombinacija dvaju ili više atributa (stupaca), a tada
je riječ o složenom 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.
Također, 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.
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.
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 (Slika 2.3.1) u tablicu Student mogu se prebaciti stupci
Mentor, NazivTeme i DatumPredaje, čime nestaje potreba za tablicom ZavrsniRad.
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.
Slika 2.3.2 prikazuje vezu "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.
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" (Slika 2.3.3). [19]
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 što prikazuje Primjer 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.
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 (Slika 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.
Veza "jedan prema više" koristiti se i prilikom realizacije rekurzivne veze, pri čemu se
primarni i strani ključ nalaze se u istoj tablici. U prikazanom primjeru veze (Slika 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
Ukoliko pretpostavimo da se u tablici Odjel (Slika 2.3.5) nalaze zapisi kao što to prikazuje
Primjer 2.3.2, tada odnose među pojedinim odjelima možemo prikazati sljedećom slikom.
Rekurzivna veza koristi se u mnogo situacija. Primjerice, vrlo često se koristi za opis
strukture internetskog foruma (svaki forum može imati više podforuma, a ujedno može i
sam biti podforum) itd.
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.
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.
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.
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 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 IspitniRok (Primjer 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.
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
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.
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 (Primjer 2.5.3),
pa je potrebno samo provjeriti tablicu Ispit (Primjer 2.5.4).
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 (Primjer 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.
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 (Primjer 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.
Općenito se smatra da nije potrebno normalizirati dalje od 3NF jer su sada uklonjene sve
anomalije pri dodavanju, izmjeni i brisanju podataka.
Konačni rezultat normalizacije nakon provođenja 3NF prikazan je slikom (Slika 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.
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 kojeg prikazuje Slika 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.
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.
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).
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).
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.
Da bismo došli do traženog rezultata potrebno je izvršiti pregled svih računa (FROM
Racun). Pregledom modela (Slika 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.
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 (Slika 2.3.7) vidimo da je u tu svrhu
potrebno spajanje (INNER JOIN) tablica Racun->Stavka->Artikl->TipArtikla po njihovim
primarnim i stranim ključevima.
3.1. Tablice
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.
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 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.
Kreiranje navedenog primarnog ključa u SSMS alatu prikazano je na slici (Slika 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
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]
ili
U SSMS alatu oba ograničenja moguće je pronaći u popisima ključeva i indeksa 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.
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]
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.
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.
Ovakvi tipovi tablica (Primjer 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.
U primjeru sa slike 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 (Slika 3.2.1, 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).
Ukoliko bismo pogled sa slike kreirali izravno izvršavanjem SQL upita, taj upit izgledao bi
kao u prethodnom primjeru (Primjer 3.2.1). Općenito, pogled se kreira na sljedeći način:
Iako je to u praksi rijetko, pri kreiranju pogleda moguće je navesti aliase rezultantnih
stupaca. Tako bismo prethodni pogled mogli napraviti i na sljedeći način:
Razlika između Primjer 3.2.1 i Primjer 3.2.2 je u tome š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 prvom primjeru nisu unaprijed
definirani aliasi rezultantnih stupaca pa se unutar SELECT upita "ručno" dodijelio alias
stupcu Kolegij.Naziv.
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]
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.
Izvršavanjem prvog SELECT upita (Primjer 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.
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.
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 šifriranje definicije pogleda, procedure i funkcije.
Za razliku od inicijalnog pogleda (Primjer 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 šifrirani 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.
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.
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 prikazanog primjera (Primjer 3.3.1) najbolje pokazuje
njegov izvedbeni plan (eng. execution plan) (Slika 3.3.2).
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 prethodnog primjera (Primjer 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 (Slika 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.
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:
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 vrijednosti u stupcu IznosPlace jer više zaposlenika može imati isti iznos plaće.
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]
Izvedbeni plan kao na slici (Slika 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.
Željko Kovačević, struč.spec.ing.techn.inf. | Tehničko veleučilište u Zagrebu 67
MODELIRANJE, IMPLEMENTACIJA I ADMINISTRACIJA BAZA PODATAKA
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
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
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.
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.
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.
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).
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.
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š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).
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 usp_ProsjecnaPlacaZaposlenika (Primjer
3.4.3) moguće pozvati na sljedeći način:
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,
Argumenti se predaju unutar zagrada nakon imena funkcije, dok sama skalarna funkcija
može imati i podrazumijevane vrijednosti parametara.
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.
Funkcija Place_Zaposlenika (Primjer 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:
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).
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]
Nakon kreiranja funkcije Place_Zaposlenika2 (Primjer 3.4.8) sljedeće naredbe neće biti
moguće uspješno izvršiti:
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:
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.
ili
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.
UPDATE Zaposlenik
SET Ime = 'aNTON'
WHERE OIB = '111222'
U konačnici, okidač tr_ImeVrijeme (Primjer 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.
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 sljedeći
način (Primjer 3.5.2).
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).
-- IF @Zaposlen = 0
-- DELETE FROM Zaposlenik WHERE OIB = @OIB
-- ELSE
-- PRINT 'Nije moguće izbrisati aktivnog zaposlenika!'
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.
Postoje dva područja djelovanja DDL okidača – na razini baze podataka (ON DATABASE)
ili na razini servera (ON ALL SERVER). U okidaču tr_ZabranaTablice (Primjer 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 (Primjer 3.5.5).
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.
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
-- 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:
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())
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:
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.
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.
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).
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.
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.
Tako u primjeru (Slika 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(Primjer
4.1.1).
Naziv odredišne sheme objekta definira se prilikom njegovog kreiranja, dok naredbom
TRANSFER možemo prebaciti objekt iz jedne sheme u drugu. Primjerice,
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.
U primjeru (Slika 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.
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.
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]
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.
Pri kreiranju prijavnog naloga moguće je kreiranje i povezivanje novih korisničkih računa
baza podataka. Tako Slika 4.2.3 prikazuje 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 prikazanim na slici 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.
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.
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 Slika 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.
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
(Primjer 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.
USE [TestDB]
CREATE USER [User1] FOR LOGIN [Login1] -- User1 povezan s prijavnim nalogom
CREATE USER [User2] WITHOUT LOGIN -- User2 bez prijavnog naloga!
Kada se korisnik (aplikacija) prijavi na server korištenjem prijavnog naloga Login1 (Primjer
4.3.2) 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.
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 (Slika 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.
Bilo pri kreiranju nove ili uređivanju postojeće serverske uloge, moguće joj je dodijeliti nove
članove odabirom stavke "Members" (Slika 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".
Za kreiranje serverske uloge "IT_Podrska", SSMS alat generirat će i izvršiti T-SQL upit iz
prikazanog primjera.
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 Slika 4.4.3 prikazuje i ostale.
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.
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.
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.
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:
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 (Primjer 4.3.2).
Funkcije sažimanja koriste se kao jednosmjerni kriptografski algoritmi bez ključa. Kada se
neki sadržaj (tekst, datoteka ili sl.) sažme funkcijom sažimanja više nije moguće u realnom
vremenu iz sažetog 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]
Izvršavanjem prikazanog T-SQL koda (Primjer 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,
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.
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 sažme odabranom 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 šifriran, sadržaj se može
dešifrirati 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 sifriran javnim ključem
može biti dešifriran samo odgovarajućim privatnim ključem kojeg posjeduje samo osoba
kojoj je poruka namijenjena.
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 dešifrirati simetrične i asimetrične ključeve unutar baza podataka, pa
time i dešifrirati 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.
tablice "Kupac" (Primjer 4.5.6). Simetrični ključ prvo je potrebno otvoriti, a nakon toga za
šifriranje i dešifriranje sadržaja koristiti funkcije ENCRYPTBYKEY i DECRYPTBYKEY.
Odgovarajuće inačice ovih funkcija postoje i u slučajevima kada se za šifriranje i
dešifriranje koriste certifikati i asimetrični kriptografski algoritmi.
Za šifriranje sadržaja baze podataka i njenih datoteka koristi se simetrični algoritam čiji se
ključ (Database Encryption Key, DEK) šifrira 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 dešifrirati
DEK pa time niti sadržaj baze podataka.
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 šifrirati bazu podataka.
Nakon kreiranja certifikata uvijek je poželjno izraditi njegovu rezervnu kopiju jer se u slučaju
gubitka certifikata neće moći dešifrirati 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
kojeg prikazuje Slika 4.6.2.
Šifriranje 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 (Slika 4.6.2), gdje se prilikom klika na gumb "OK"
generira i izvršava sljedeći T-SQL kod.
Izvršavanjem upita iz prikazanog primjera kreira se DEK ključ zaštićen server certifikatom
te se njime u konačnici šifrira TestDB baza podataka. Ukoliko bi uljez ukrao TestDB bazu
podataka (TestDB.mdf, TestDB.ldf itd.) te ju pokušao pripojiti svojoj instanci dobio bi
sljedeću poruku (Slika 4.6.3).
U master bazi podataka uljeza neće postojati odgovarajući certifikat za dešifriranje DEK
ključa ukradene baze podataka pa ju uljez neće moći dešifrirati i pripojiti svojoj instanci
SQL Servera. Greška kao na prikazanoj slici dogodit će se i ukoliko uljez pokuša doći do
podataka obnovom ukradene rezervne kopije.
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 šifriranog sadržaja u čitljivom, dešifriranom obliku, dok se prilikom
spremanja izmjena ti podaci šifriraju prije slanja nazad u bazu podataka.
Upotrebom ove značajke, baza podataka u svakom trenutku sadrži šifrirane podatke koje
ne mogu dešifrirati 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]
Sadržaj pojedinog stupca šifrira se ključem stupca (eng. column encryption key, CEK), a
ključevi stupaca šifriraju 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 Primjer 4.7.1.
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).
SQL Server ima uvid u šifriranu vrijednost CEK ključa te algoritam kojim je ključ šifriran
(Primjer 4.7.2). Međutim, za njegovo dešifriranje bit će potreban CMK ključ, odnosno
certifikat u kojem je spremljen.
Nakon što postoji CMK i barem jedan CEK ključ može se pristupiti šifriranju sadržaja
stupaca (Slika 4.7.3). Jednim CEK ključem moguće je šifrirati sve stupce tablice, a svaki
od stupaca može biti šifriran determinističkim ili slučajnim tipom ključa. Ključevi
determinističkog tipa uvijek će generirati istu šifriranu vrijednost za jedan podatak, dok će
se korištenjem slučajnog tipa ključa uvijek generirati različita šifrirana 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.
ID OIB BrojKreditneKartice
1 111111 1111-2222-3333-4444
2 222222 2222-3333-4444-5555
Ukoliko sada pokušamo dohvatiti sadržaj tablice "Kupac" naredbom SELECT kao rezultat
dobit ćemo šifrirane podatke u stupcu "BrojKreditneKartice".
ID OIB BrojKreditneKartice
1 111111 0x011A51BB80E9EFE9DE45952ED5C1E3….
2 222222 0x012C1EE64B88B4C886150AF7F91C20D….
Da bi klijent aplikacije mogle vidjeti dešifrirani 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
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".
Šifriranje stupaca potrebno je omogućiti dodavanjem izraza "Column Encryption
Setting=enabled" (Slika 4.7.4).
Ukoliko u nekom trenutku više ne želite šifrirati stupce korištenjem "Always Encrypted"
značajke potrebno je ponovno pokrenuti čarobnjak te za tip šifriranja odabrati "Plaintext".
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.
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).
Izvršavanjem prikazanog T-SQL koda 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:
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
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").
Slika 5.1.1 prikazuje kako je odredište rezervne kopije samo jedna 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.
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").
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.
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.
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 (Primjer 5.1.2).
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).
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". Alternativno, isti rezultat nije moguće dobiti samo izradom
potpune ili diferencijalne rezervne kopije jer one ne podrazumijevaju i izradu rezervne
kopije dnevnika transakcija.
Prilikom povrata baze podataka treba vratiti kompletan lanac rezervnih kopija koji
vodi do željenog datuma i vremena. Primjerice, za povrat baze podataka 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.
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 Slika
5.2.1 prikazuje 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 sljedeći dijalog.
Na grafički način prikazane su sve već postojeće rezervne kopije, a klikom na gumb "OK"
lanac rezervnih kopija 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.
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.
ž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.
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" (Slika 5.2.3) ili naredbom SET SINGLE USER WITH
ROLLBACK IMMEDIATE (Primjer 5.2.1).
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.
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.
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 odgovarajući T-SQL kod
(Primjer 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" (Slika 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).
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.
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…".
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.
Svaki plan održavanja ima jedan ili više podplanova. Tako se u primjeru (Slika 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 Slika 5.4.2 prikazuje kako 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 biti kreirana tri zasebna SQL Server
Agent posla (Slika 5.4.3).
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".
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).
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.
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).
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.
-- 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 Primjer 5.5.1 prikazuje kako je na taj način
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.
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.
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 prikazuje Slika 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]
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…".
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]
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.
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).
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]
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" (Slika 1.4.4).
Tada će se instalirati i alat Database Engine Tuning Advisor.
Nakon pokretanja SQL Server Profilera moguće je napraviti novo nadgledanje (eng. trace)
odabirom stavke "File / New Trace…". U konačnici, pojavljuje se dijalog (Slika 5.7.2) koji
sadrži dvije kartice – "General" i "Event Selection".
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.
Nakon što se pokrene nadgledanje pojavljuje se dijalog (Slika 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 Slika 5.7.3 prikazuje 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".
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
Željko Kovačević, struč.spec.ing.techn.inf. | Tehničko veleučilište u Zagrebu 141
MODELIRANJE, IMPLEMENTACIJA I ADMINISTRACIJA BAZA PODATAKA
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.
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".
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 (Slika 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]
Za pregled svih zabilježenih događaja potrebno je desnim klikom na audit objekt odabrati
stavku "View Audit Logs". Tada se pojavljuje dijalog (Slika 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.
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 (Slika 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 sljedećoj slici.
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.
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.
Kao što je prikazano (Tablica 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
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.
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.
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).
Č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.
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.
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.
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
(Slika 6.1.4, gumb "Article Properties").
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.
(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.
U primjerima na slici (Slika 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 slike 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.
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).
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.
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.
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.
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.
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.
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".
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 (Slika 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.
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.
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).
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.
Popis tablica
Tablica 1.1.1. Informacija i podaci ..................................................................................... 9
Tablica 1.1.2. Primjeri desktop baza podataka ................................................................ 10
Tablica 1.1.3. Primjeri klijent-server baza podataka ........................................................ 11
Tablica 1.3.1. Razine izolacije u SQL Serveru [9] ............................................................ 15
Tablica 1.3.2. Sadržaj tablice Zaposlenik ........................................................................ 16
Tablica 2.1.1. Značajke podatkovnih modela [17] ............................................................ 33
Tablica 3.2.1. Rezultat prvog izvršavanja pogleda vPolaznici ......................................... 63
Tablica 3.2.2. Rezultat drugog izvršavanja pogleda vPolaznici ....................................... 63
Tablica 3.5.1. Sadržaji tablica Inserted i Deleted ............................................................. 79
Tablica 4.8.1. Funkcije maskiranja u SQL Serveru [41] ................................................. 114
Tablica 6.1.1. Ključni pojmovi u replikaciji ...................................................................... 146
Popis slika
Slika 1.3.1. Potpuni zastoj ............................................................................................... 18
Slika 1.4.1. Instance i baze podataka .............................................................................. 20
Slika 1.4.2. SQL Server instalacijski centar ..................................................................... 21
Slika 1.4.3. Provjera preduvjeta instalacije ...................................................................... 21
Slika 1.4.4. Odabir značajki instance ............................................................................... 22
Slika 1.4.5. Konfiguracija instance ................................................................................... 23
Slika 1.4.6. Konfiguracija servisa ..................................................................................... 23
Slika 1.4.7. Autentifikacija korisnika ................................................................................. 24
Slika 1.4.8. Svojstva TCP/IP protokola kreirane instance ................................................ 25
Slika 1.4.9. Spajanje na SQL Server instancu ................................................................. 26
Slika 1.5.1. Kreiranje baze podataka – opće informacije ................................................. 27
Slika 1.5.2. Datoteke, datotečne grupe i razmještaj po diskovima ................................... 28
Slika 1.5.3. Neke od ostalih postavki baze podataka ....................................................... 29
Slika 2.1.1. Primjeri entiteta i veza u konceptualnom podatkovnom modelu ................... 34
Slika 2.1.2. Konceptualni podatkovni model za Zadatak 2.1.1 ......................................... 35
Slika 2.2.1. Logički podatkovni model za Zadatak 2.1.1 .................................................. 36
Slika 2.2.2. Primjer logičkog podatkovnog modela [18] ................................................... 37
Slika 2.3.1. Primjer veze "jedan prema jedan" ................................................................. 38
Slika 2.3.2. Primjer veze "jedan prema više" ................................................................... 39
Slika 2.3.3. Referencijalni integritet veze ......................................................................... 39
Slika 2.3.4. Primjer veze "više prema više" ...................................................................... 41
Slika 2.3.5. Primjer rekurzivne veze................................................................................. 42
Slika 2.3.6. Odnosi među pojedinim odjelima .................................................................. 42
Slika 2.3.7. Implementacija fizičkog podatkovnog modela u SQL Serveru ...................... 43
Slika 2.4.1. Primjer hijerarhijskog modela ........................................................................ 44
Slika 2.4.2. Primjer mrežnog modela ............................................................................... 44
Slika 2.4.3. Primjer relacijskog modela [20] ..................................................................... 45
Slika 2.5.1. Tablice i veze nakon provođenja 3NF ........................................................... 50
Slika 3.1.1. Kreiranje tablice korištenjem SSMS alata ..................................................... 55
Slika 3.1.2. Primarni ključ sa svojstvom identiteta ........................................................... 56
Slika 3.2.1. Kreiranje i izvršavanje pogleda korištenjem SSMS alata .............................. 60
Slika 3.3.1. Struktura tablica Zaposlenik .......................................................................... 65
Popis primjera
Primjer 1.2.1. DML upiti ................................................................................................... 12
Primjer 1.2.2. DDL upiti.................................................................................................... 12
Primjer 1.2.3. DCL upiti.................................................................................................... 12
Primjer 1.2.4. TCL upiti .................................................................................................... 13
Primjer 1.3.1. Demonstracija prljavog čitanja ................................................................... 16
Primjer 1.3.2. Demonstracija neponavljajućeg čitanja ..................................................... 17
Primjer 1.3.3. Demonstracija fantomskih zapisa .............................................................. 17
Primjer 1.3.4. Demonstracija potpunog zastoja ............................................................... 19
Primjer 1.5.1. SQL upiti generirati SSMS alatom ............................................................. 30
Primjer 2.3.1. Sadržaji tablica Ducan i Racun .................................................................. 40
Primjer 2.3.2. Sadržaj tablice Odjel.................................................................................. 42
Primjer 2.5.1. Nenormalizirani oblik tablice IspitniRok ..................................................... 46
Primjer 2.5.2. Ponavljajuće skupine podataka tablice IspitniRok ..................................... 47
Primjer 2.5.3. 1NF – tablica Student ................................................................................ 48
Primjer 2.5.4. 1NF – tablica Ispit ...................................................................................... 48
Primjer 2.5.5. 2NF - tablice Ispit i Kolegij ......................................................................... 49
Primjer 2.5.6. 3NF - tablice Student i Grad ...................................................................... 49
Primjer 2.5.7. 3NF - tablice Ispit i Profesor ...................................................................... 50
Primjer 3.1.1. Generirani SQL upit za kreiranje tablice 'Osoba' ....................................... 55
Primjer 3.1.2. CHECK ograničenja .................................................................................. 58
Primjer 3.1.3. Kreiranje lokalne privremene tablice ......................................................... 58
Primjer 3.1.4. Kreiranje globalne privremene tablice ....................................................... 59
Primjer 3.1.5. Kreiranje tablice kao varijable .................................................................... 59
Primjer 3.2.1. Kreiranje pogleda izvršavanjem SQL upita................................................ 61
Primjer 3.2.2. Kreiranje pogleda sa unaprijed definiranim aliasima stupaca .................... 61
Primjer 3.2.3. Korištenje pogleda u SQL upitu ................................................................. 62
Primjer 3.2.4. Ažuriranje pogleda..................................................................................... 62
Primjer 3.2.5. Kreiranje šifriranog pogleda....................................................................... 64
Primjer 3.3.1. Pretraga svih zaposlenika čija plaća iznosi više od 5000 kn ..................... 65
Primjer 3.3.2. Kreiranje grupirajućeg indeksa .................................................................. 66
Primjer 3.3.3. Kreiranje negrupirajućeg indeksa .............................................................. 70
Primjer 3.3.4. Kreiranje filtriranog negrupirajućeg indeksa .............................................. 70
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].
[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].
[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].
[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.
[Pokušaj pristupa 19 5 2017].
[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].
[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].
[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.
[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.
[Pokušaj pristupa 18 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].
[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].
[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].
[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].
[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].
[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].
[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.
[Pokušaj pristupa 12 11 2017].
[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].
[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].
[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
DDL · 12
A DDL okidači · 81
DECRYPTBYKEY · 106
Agent distribucije · 150 Desktop baze podataka · 9
Agent snimke · 150 Detach · 136
Agent spajanja · 153 Diferencijalne rezervne kopije · 120
Always Encrypted · 109 Distributer · 146, 148
AlwaysOn · 161 DMK · 105
Aplikacijske uloge · 100 DML · 12
Asimetrični kriptografski algoritmi · 103 DML okidači · 77
Atomicy · 14 Dnevnik transakcija · 28
Audit specifikacija · 143 Druga normalna forma · 48
Availability Groups · 162 Durability · 20
Ažurirajući pogledi · 63
E
B
EKM · 107
Baza podataka · 9 ENCRYPTBYKEY · 106
Bulk-logged · 30 Enforce Foreign Key Constraint · 40
e-pošta · 132
ER model · 33
C
Extended properties · 87
Cascade · 40
Collation · 29 F
Column encryption key · 110
Column master key · 110 Failover · 159
Consistency · 14 Fantomski zapisi · 17
Filegroups · 28
FileMaker · 10
Č
Filtrirani negrupirajući indeks · 70
Fizički podatkovni model · 38
Članak · 146
FK · 37
Full · 30
D Funkcije sažimanja · 101
Impersonacija · 95
Informacija · 9
N
Informix · 11
NDF · 28
Inline Table-Valued Functions · 75
Negrupirajući indeks · 70
Instanca · 20
Ne-ključni atributi · 34
Isolation · 14
Neponavljajuće čitanje · 16
Izdavač · 146
No Action · 40
Izvedbeni plan · 65
J O
Obnova indeksa · 71
Jedan prema jedan · 39
Ograničenja · 57
Jedan prema više · 39
Optimistično zaključavanje · 15
Oracle · 11
K
M Poslovi · 126
Postgre SQL · 11
Maskiranje podataka · 114 Potpuna rezervna kopija · 117
MDF · 28 Potpuni zastoj · 18
Merge replication · 153 Pretplata · 155
Query Optimizer · 66 Š
Šifrirani pogled · 64
R
S U