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
© Copyright 2024 Paperzz
