5 SBP Procedure Okidaci

Ak.god. 2014/2015. SUSTAVI BAZA PODATAKA 1

Doc.dr.sc. GORAN KRALJEVIĆ

SUSTAVI BAZA PODATAKA

FAKULTET STROJARSTVA I RAĈUNARSTVA

SVEUĈILIŠTE U MOSTARU


Web:

http://www.fsr.ba/~goran

Pitanja, primjedbe, dogovor za konzultacije ...

o E-mail: [email protected]

[email protected]

Sustavi baza podataka


Arhitektura softverskog sustava


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.



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)



• 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.



• 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.



• Klijent-server arhitektura (Client-Server Architecture)



• 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.


Debeli (fat) klijent o Podatkovna logika integrirana u klijenta o Nema obrade podataka na serveru ili je obrada minimalna o Minimalna ili nikakva elastičnost na promjene poslovne politike

Klijent-server arhitektura

Prednosti: o veća samostalnost klijenta o rasterećenje glavnog računala (servera) o može imati lokalnu bazu podataka o mogu se nabaviti jeftina računala sa snažnim procesorima o 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 podacima o ako s vremenom aplikacija postane spora (zbog količine podataka), treba

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

na klijentu)


Tanki (thin) klijent o Podatkovna logika se nalazi na serveru o Osnovna namjena klijenta je prikaz podataka o Većinom se koriste u poslovnim sustavima o Tipičan primjer tankog klijenta je web preglednik


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

možemo jednostavno povećati snagu središnjeg računala o 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čunalo o ukoliko se kao klijent koristi web preglednik moraju se poštivati njegova

ograničenja



• 2-slojna arhitektura








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)


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 pripadaju trenutnoj 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.


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.


Pohranjene procedure (Stored procedures)


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.



• Proizvođači SUBP koriste vlastite inačice jezika za definiranje pohranjenih 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)



• 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 ]



• 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)


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 drugi Prvo se provjerava postoje li zadani brojevi računa i ako postoje, prebacuje se iznos (od 500 KM) s jednog računa na drugi.


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 drugi Prvo 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).


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


Okidaĉi (triggers)


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


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


Okidaĉi

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


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 akcije navedene 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


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.


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.


Web:

http://www.fsr.ba/~goran

Pitanja, primjedbe, dogovor za konzultacije ...

o E-mail: [email protected]

[email protected]

Sustavi baza podataka

Documents

5 SBP Procedure Okidaci