close

Enter

Log in using OpenID

- FSR web : www.fsr.ba

embedDownload
SVEUĈILIŠTE U MOSTARU
FAKULTET STROJARSTVA I RAĈUNARSTVA
BAZE PODATAKA 2
Doc.dr.sc. GORAN KRALJEVIĆ
Ak.god. 2012/2013
BAZE PODATAKA
1
Baze podataka 2
Web:
http://www2.fsr.ba/nastava/baze
Pitanja, primjedbe, dogovor za konzultacije ...
 E-mail: [email protected]
Ak.god. 2012/2013
BAZE PODATAKA
2
Arhitektura softverskog sustava
Ak.god. 2012/2013
BAZE PODATAKA
3
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.
Ak.god. 2012/2013
BAZE PODATAKA
4
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)
Ak.god. 2012/2013
BAZE PODATAKA
5
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.
Ak.god. 2012/2013
BAZE PODATAKA
6
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.
Ak.god. 2012/2013
BAZE PODATAKA
7
Arhitektura aplikacija
• Klijent-server arhitektura (Client-Server Architecture)
Ak.god. 2012/2013
BAZE PODATAKA
8
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.
Ak.god. 2012/2013
BAZE PODATAKA
9
Klijent-server arhitektura
Debeli (fat) klijent
o
o
o
Podatkovna logika integrirana u klijenta
Nema obrade podataka na serveru ili je obrada minimalna
Minimalna ili nikakva elastičnost na promjene poslovne politike
Prednosti:
o
o
o
o
o
veća samostalnost klijenta
rasterećenje glavnog računala (servera)
može imati lokalnu bazu podataka
mogu se nabaviti jeftina računala sa snažnim procesorima
brzi početni razvoj aplikacije
Nedostaci:
o
o
o
o
promjena poslovne logike znači instaliranje nove verzije aplikacije na svim
klijentima (poslovna logika integrirana na klijenta)
velika mogućnost rada sa zastarjelim podacima
ako s vremenom aplikacija postane spora (zbog količine podataka), treba
promijeniti sve klijente
razvoj velike aplikacije s vremenom postaje vrlo kompleksan (sav kod je
na klijentu)
Ak.god. 2012/2013
BAZE PODATAKA
10
Klijent-server arhitektura
Tanki (thin) klijent
o
o
o
o
Podatkovna logika se nalazi na serveru
Osnovna namjena klijenta je prikaz podataka
Većinom se koriste u poslovnim sustavima
Tipičan primjer tankog klijenta je web preglednik
Prednosti:
o
o
o
o
o
o
o
promjena poslovne logike može se obaviti centralizirano
promjena poslovne logike ne znači nužno i promjenu u klijentskom dijelu
računala ne moraju imati veliku procesorsku snagu
ukoliko s vremenom obrada postane spora (zbog količine podataka),
možemo jednostavno povećati snagu središnjeg računala
kao tanki klijent može se koristiti npr. web preglednik (dobro definirano i
svima dostupno)
smanjena mogućnost rada sa zastarjelim podacima (gotovo za svaku
promjenu ide se na server)
manja kompleksnost razvoje velikih aplikacija (kod je podijeljen na
serverski dio i klijentski dio)
Nedostaci:
o
o
veliko opterećenje glavnog računala, a to znači skupo glavno računalo
ukoliko se kao klijent koristi web preglednik moraju se poštivati njegova
ograničenja
Ak.god. 2012/2013
BAZE PODATAKA
11
Klijent-server arhitektura
• 2-slojna arhitektura
Ak.god. 2012/2013
BAZE PODATAKA
12
Klijent-server arhitektura
• 3-slojna arhitektura
Ak.god. 2012/2013
BAZE PODATAKA
13
Klijent-server arhitektura
• 4-slojna arhitektura
Ak.god. 2012/2013
BAZE PODATAKA
14
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)
Ak.god. 2012/2013
BAZE PODATAKA
15
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.
Ak.god. 2012/2013
BAZE PODATAKA
16
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.
Ak.god. 2012/2013
BAZE PODATAKA
17
Pohranjene procedure
(Stored procedures)
Ak.god. 2012/2013
BAZE PODATAKA
18
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.
Ak.god. 2012/2013
BAZE PODATAKA
19
Pohranjena procedura
• 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)
Ak.god. 2012/2013
BAZE PODATAKA
20
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 ]
Ak.god. 2012/2013
BAZE PODATAKA
21
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)
Ak.god. 2012/2013
BAZE PODATAKA
22
Primjer (klijent-server arhitektura oslonjena na klijenta)
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.
Ak.god. 2012/2013
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;
BAZE PODATAKA
23
Primjer (klijent-server arhitektura oslonjena na server)
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).
EXECUTE PROCEDURE
prebaci (1, 2, 500);
CREATE PROCEDURE prebaci (...)
DEFINE ...
SELECT ...
SELECT ...
UPDATE ...
UPDATE ...
END PROCEDURE;
Ak.god. 2012/2013
BAZE PODATAKA
24
Primjer (klijent-server arhitektura oslonjena na klijent / server)
Ak.god. 2012/2013
BAZE PODATAKA
25
Okidaĉi
(triggers)
Ak.god. 2012/2013
BAZE PODATAKA
26
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
Ak.god. 2012/2013
BAZE PODATAKA
27
Okidaĉi
• SUBP – definiranje aktivnih pravila (active rules)
• DogaĊaj-Uvjet-Akcija (ECA: Event-Condition-Action)
→ Okidaĉi (triggers)
ON event IF condition THEN action
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
Ak.god. 2012/2013
BAZE PODATAKA
28
Okidaĉi
• Okidaĉi (trigeri) se izvršavaju automatski kod izvršavanja akcijskih
SQL upita (INSERT, UPDATE, DELETE) nad pojedinim tablicama u
bazi podataka.
Ak.god. 2012/2013
BAZE PODATAKA
29
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
Ak.god. 2012/2013
BAZE PODATAKA
30
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.
Ak.god. 2012/2013
BAZE PODATAKA
31
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.
Ak.god. 2012/2013
BAZE PODATAKA
32
Baze podataka 2
Web:
http://www2.fsr.ba/nastava/baze
Pitanja, primjedbe, dogovor za konzultacije ...
 E-mail: [email protected]
Ak.god. 2012/2013
BAZE PODATAKA
33
Author
Document
Category
Uncategorized
Views
5
File Size
734 KB
Tags
1/--pages
Report inappropriate content