BAZE PODATAKA 2 1

Doc.dr.sc. GORAN KRALJEVIĆ

BAZE PODATAKA 2

FAKULTET PRIRODOSLOVNO-MATEMATIČKIH I ODGOJNIH ZNANOSTI

SVEUČILIŠTE U MOSTARU

BAZE PODATAKA 2 2

Web:

http://www.fpmoz.ba/gkraljevic

Pitanja, primjedbe, dogovor za konzultacije ...

o E-mail: goran.kraljevic@hteronet.ba

goran.kraljevic@sve-mo.ba

Baze podataka 2

BAZE PODATAKA 2 3

Arhitektura softverskog sustava

BAZE PODATAKA 2 4

Arhitektura aplikacija

Arhitektura aplikacija – jednostavna apstrakcija na četiri dijela:

• Pohrana podataka (Data Storage)

– pohrana podataka najčešće u nekoj od relacijskih baza podataka

(podaci su definirani u podatkovnom modelu).

• Pristup podacima (Data Access Logic)

– dio aplikacije kojom se podaci upisuju, ažuriraju, dohvaćaju, itd. (najčešće su to SQL upiti nad relacijskim bazama podataka).

• Aplikacijska logika (Application Logic)

– dio aplikacije koji izvodi funkcionalnosti definirane u procesnom modelu, slučajevima korištenja i funkcionalnim zahtjevima.

• Prezentacijska logika (Presentation Logic)

– dio aplikacije koji pruža podatke korisniku i od korisnika prihvaća ulazne

informacije i naredbe.

BAZE PODATAKA 2 5

Arhitektura aplikacija

Ovisno o rasporedu funkcija aplikacije (pohrana podataka, pristup podacima, aplikacijska logika, prezentacijska logika) na strani servera ili na strani klijenta razlikuju se različite arhitekture:

• Arhitektura zasnovana na serveru

(Server-Based Architecture)

• Arhitektura zasnovana na klijentu

(Client-Based Architecture)

• Klijent-server arhitektura

(Client-Server Architecture)

BAZE PODATAKA 2 6

Arhitektura aplikacija

• Arhitektura zasnovana na serveru (Server-Based Architecture)

Sve funkcije aplikacije se odvijaju na serveru od pohrane podataka, pristupa podacima, aplikacijske logike i prezentacijske logike (ipak barem dio prezentacijske logike treba biti na klijentu u bilo kojem obliku !?).

Server je veliko i izrazito snažno računalo (mainframe).

Klijent je obično samo terminal koji omogućava korisniku da šalje i prima poruke bez obrade podataka.

BAZE PODATAKA 2 7

Arhitektura aplikacija

• Arhitektura zasnovana na klijentu (Client-Based Architecture)

Kod arhitekture zasnovane na klijentu logika prezentacije, aplikacije i pristupa podacima se prebacuje na stranu klijenta.

Server služi samo za pohranu podataka.

Problem kod upgradea jer trebate raditi upgrade na svim klijentskim računalima.

BAZE PODATAKA 2 8

Arhitektura aplikacija

• Klijent-server arhitektura (Client-Server Architecture)

BAZE PODATAKA 2 9

Arhitektura aplikacija

• Klijent-server arhitektura (Client-Server Architecture)

o Smještaj aplikacijske logike određuje da li se radi o “thin” ili “fat” klijent arhitekturi.

”Tanki” (“thin”) klijent je klijent na kojem se nalazi samo prezentacijska logika, dok je “debeli” (“fat”) klijent na kojem se osim prezentacijske nalazi i veliki dio aplikacijske (poslovne) logike.

BAZE PODATAKA 2 10

Debeli (fat) klijento Podatkovna logika integrirana u klijentao Nema obrade podataka na serveru ili je obrada minimalnao Minimalna ili nikakva elastičnost na promjene poslovne politike

Klijent-server arhitektura

Prednosti:o veća samostalnost klijentao rasterećenje glavnog računala (servera)o može imati lokalnu bazu podatakao mogu se nabaviti jeftina računala sa snažnim procesorimao brzi početni razvoj aplikacije

Nedostaci:o promjena poslovne logike znači instaliranje nove verzije aplikacije na svim

klijentima (poslovna logika integrirana na klijenta)o velika mogućnost rada sa zastarjelim podacimao ako s vremenom aplikacija postane spora (zbog količine podataka), treba

promijeniti sve klijenteo razvoj velike aplikacije s vremenom postaje vrlo kompleksan (sav kod je

na klijentu)

BAZE PODATAKA 2 11

Tanki (thin) klijento Podatkovna logika se nalazi na serveruo Osnovna namjena klijenta je prikaz podatakao Većinom se koriste u poslovnim sustavimao Tipičan primjer tankog klijenta je web preglednik

Klijent-server arhitektura

Prednosti:o promjena poslovne logike može se obaviti centraliziranoo promjena poslovne logike ne znači nužno i promjenu u klijentskom dijelu o računala ne moraju imati veliku procesorsku snaguo ukoliko s vremenom obrada postane spora (zbog količine podataka),

možemo jednostavno povećati snagu središnjeg računalao kao tanki klijent može se koristiti npr. web preglednik (dobro definirano i

svima dostupno)o smanjena mogućnost rada sa zastarjelim podacima (gotovo za svaku

promjenu ide se na server)o manja kompleksnost razvoje velikih aplikacija (kod je podijeljen na

serverski dio i klijentski dio)

Nedostaci:o veliko opterećenje glavnog računala, a to znači skupo glavno računaloo ukoliko se kao klijent koristi web preglednik moraju se poštivati njegova

ograničenja

BAZE PODATAKA 2 12

Klijent-server arhitektura

• 2-slojna arhitektura

BAZE PODATAKA 2 13

Klijent-server arhitektura

• 3-slojna arhitektura

BAZE PODATAKA 2 14

Klijent-server arhitektura

• 4-slojna arhitektura

BAZE PODATAKA 2 15

Višeslojna arhitektura

• Programski kod se može podijeliti u više razina, npr.

kod na formi (GUI - Graphic User Interface)

kod u sloju poslovne logike (BLL - Business Logic Layer)

kod u sloju pristupa podacima (DAL - Data Access Layer)

kod na bazi podataka (Stored procedure)

• Često se radi podjela u 3 razine:

Klijent - GUI (npr. u web aplikaciji je to web preglednik)

Aplikacijski server - BLL (npr. web servis)

Baza podataka (npr. SQL Server)

BAZE PODATAKA 2 16

Primjer (arhitektura klijent-server)

Npr. napraviti aplikaciju koja će prikazivati zadnjih 20 narudžbi:

o Kupce, prodavače i datume narudžbi;

o Nazive artikala, jediničnu cijenu i količinu za pojedinu narudžbu;

o Ukupnu količinu i ukupnu vrijednost narudžbe;

• Rješenje – debeli (fat) klijent

Na klijentu napraviti SQL upit kojim se dohvaćaju podaci o zadnjih 20 narudžbi.

Na klijentu napraviti SQL upit kojim se dohvaćaju detalji za zadnjih 20 narudžbi.

Kad se promjeni narudžba proći kroz sve detalje i ispisati one koje pripadajutrenutnoj narudžbi. Usput računati zbirne vrijednosti.

• Rješenje – tanki (thin) klijent

Na klijentu pozvati pohranjenu proceduru (stored procedure) koja vraća podatke o zadnjih 20 narudžbi.

Kad se promjeni trenutna narudžba pozvati pohranjenu proceduru koja vraća detalje trenutne narudžbe i zbirne vrijednosti.

BAZE PODATAKA 2 17

Primjer (arhitektura klijent-server)

Promjena zahtjeva korisnika:

o Korisnik se nakon mjesec dana rada aplikacije, naravno, predomislio i želi da

se prikazuje zadnjih 50 narudžbi.

• Rješenje – debeli (fat) klijent

Na debelom klijentu treba promijeniti SQL upite u izvornom kodu, prevesti ga u novu izvršnu inačicu te dostaviti aplikaciju korisnicima - sporo i skupo.

• Rješenje – tanki (thin) klijent

Na tankom klijentu treba na serveru promijeniti samo pohranjenu proceduru za dohvat narudžbi - brzo (manje od 5 minuta) i jeftino.

BAZE PODATAKA 2 18

Pohranjene procedure(Stored procedures)

BAZE PODATAKA 2 19

Pohranjena procedura

• Pohranjena procedura ili pohranjena funkcija je potprogram koji je pohranjen u rječniku podataka i koji se izvršava u kontekstu sustava za upravljanje bazama podataka.

Može se promatrati kao procedura ili funkcija kojom se proširuje skup SQL funkcija ugrađenih u SUBP.

o Pohranjena procedura je potprogram koji u pozivajući program ne vraća rezultat.

o Funkcija je potprogram koji u pozivajući program vraća rezultat.

BAZE PODATAKA 2 20

Pohranjena procedura

• Proizvođači SUBP koriste vlastite inačice jezika za definiranjepohranjenih procedura (standard postoji, ali je rijetko gdje implementiran)

o Oracle: PL/SQL

PL/SQL (Procedural Language / Structured Query Language)

o Microsoft SQL Server: T-SQL

T-SQL (Transact-SQL)

• Navedeni jezici proširuju mogućnosti SQL jezika proceduralnim elementima koji se koriste u strukturiranim jezicima (C, Java, ...).

Osim SQL naredbi, pohranjene procedure omogućuju korištenje:

o varijabli

o naredbi za kontrolu toka programa (if, for, while, ...)

o naredbi za rukovanje iznimkama (exception handling)

BAZE PODATAKA 2 21

Pohranjena procedura

• Upotrebom pohranjenih procedura omogućena je zaštita podataka na razini funkcije (a ne samo objekta).

• Osnovna sintaksa za dodjeljivanje dozvole za izvršavanje procedure:

GRANT EXECUTE

ON { ime_procedure | ime_funkcije }TO { korisnici | uloge | PUBLIC }[ WITH GRANT OPTION ]

• Osnovna sintaksa za ukidanje dozvole za izvršavanje procedure:

REVOKE EXECUTE

ON { ime_procedure | ime_funkcije }FROM { korisnici | uloge | PUBLIC }[ CASCADE | RESTRICT ]

BAZE PODATAKA 2 22

Pohranjena procedura

• Upotrebom pohranjenih procedura omogućena je upotreba klijent-server arhitekture oslonjene na server.

o postiže se veća učinkovitost (efikasnost) SUBP;

(SUBP ne mora ponavljati prevođenje i optimiranje SQL upita)

o postiže se veća produktivnost programera i smanjuje se mogućnost pogreške;

(Programski kôd potreban za obavljanje nekog postupka koji čini logičku cjelinu implementira se i testira na samo jednom mjestu)

BAZE PODATAKA 2 23

Primjer (klijent-server arhitektura oslonjena na klijenta)

1) SELECT COUNT (*) FROM racun

WHERE id_racuna=1;

2) SELECT COUNT (*) FROM racun

WHERE id_racuna=2;

3) UPDATE racun SET saldo=saldo-500

WHERE id_racuna=1;

4) UPDATE racun SET saldo=saldo+500

WHERE id_racuna=2;

Primjer: Prebacivanje iznosa s jednog računa na drugiPrvo se provjerava postoje li zadani brojevi računa i ako postoje, prebacuje se iznos (od 500 KM) s jednog računa na drugi.

BAZE PODATAKA 2 24

Primjer (klijent-server arhitektura oslonjena na server)

EXECUTE PROCEDURE

prebaci (1, 2, 500);

CREATE PROCEDURE prebaci (...)

DEFINE ...

SELECT ...

SELECT ...

UPDATE ...

UPDATE ...

END PROCEDURE;

Primjer: Prebacivanje iznosa s jednog računa na drugiPrvo se provjerava postoje li zadani brojevi računa i ako postoje, prebacuje se iznos (od 500 KM) s jednog računa na drugi (rješenje s korištenjem pohranjene procedure).

BAZE PODATAKA 2 25

Primjer (klijent-server arhitektura oslonjena na klijent / server)

BAZE PODATAKA 2 26

Okidači (triggers)

BAZE PODATAKA 2 27

Okidači

“Pasivni” SUBP

• konvencionalni SUBP je pasivan

• operacije nad podacima se izvršavaju isključivo na temelju eksplicitnog zahtjeva korisnika / aplikacije

“Aktivni” SUBP i “aktivne” baze podataka

• aktivni SUBP autonomno reagira na određene događaje (events)

• u aktivnim bazama podataka neke operacije nad podacima se izvršavaju automatski, reakcijom na određeni događaj ili stanje

BAZE PODATAKA 2 28

Okidači

• SUBP – definiranje aktivnih pravila (active rules)

• Događaj-Uvjet-Akcija (ECA: Event-Condition-Action)

→ Okidači (triggers)

o događaj (event): ako se dogodi, izračunava se uvjet(npr. unos - INSERT, izmjena - UPDATE ili brisanje - DELETE podataka)

o uvjet (condition): ako je rezultat izračunavanja uvjeta istina, obavljaju se akcije

o akcije (action): niz operacija, najčešće operacije nad podacima

ON event IF condition THEN action

BAZE PODATAKA 2 29

Okidači

• Okidači (trigeri) se izvršavaju automatski kod izvršavanja akcijskih SQL upita (INSERT, UPDATE, DELETE) nad pojedinim tablicama u bazi podataka.

BAZE PODATAKA 2 30

Okidači

• Pri definiciji okidača moguće je specificirati koje akcije (operacije) aktiviraju okidač (triger):

INSERT, UPDATE, DELETE

• Također, pri definiciji okidača moguće je specificirati da li se akcijenavedene u samom okidaču obavljaju:

o nakon što se obavi operacija koja je aktivirala okidač

AFTER INSERT, AFTER UPDATE, AFTER DELETE

o prije nego se obavi operacija koja je aktivirala okidač

BEFORE INSERT, BEFORE UPDATE, BEFORE DELETE

o te da li se akcije u okidaču obavljaju jednom za svaku n-torku na koju je djelovala operacija koja je aktivirala okidač

FOR EACH ROW

BAZE PODATAKA 2 31

Okidači

• Okidači (trigeri) su vezani uz tablice, pri čemu jedna tablica može imati više okidača.

• Moguće je definirati posebne okidače za svaki tip promjene koja se vrši u tablici (unos, promjena ili brisanje podataka) ili zajedničke okidače za različite promjene.

• Okidači omogućavaju uvođenje strožih i složenijih ograničenja od onih koja se npr. definiraju preko CHECK ograničenja.

Za razliku od CHECK ograničenja koje djeluje samo na nivou definirane tablice, okidač može pristupiti drugim tablicama, te provjeravati složenije uvjete integriteta.

• Pomoću okidača moguće je ustanoviti razliku između stanja tablice prije promjena i nakon promjena i poduzeti odgovarajuće akcije u vezi tih promjena.

BAZE PODATAKA 2 32

Okidači

• Primjeri primjene okidača (trigera):

o evidentiranje (logiranje) promjena nad podacima,

o implementacija integritetskih ograničenja,

o ažuriranje izvedenih atributa (npr. saldo računa),

o praćenje rada korisnika (logiranje pristupa bazi ...),

o sustavi obavještavanja,

o itd.

BAZE PODATAKA 2 33

Web:

http://www.fpmoz.ba/gkraljevic

Pitanja, primjedbe, dogovor za konzultacije ...

o E-mail: goran.kraljevic@hteronet.ba

goran.kraljevic@sve-mo.ba

Baze podataka 2