Sveučilište u Rijeci, Odjel za informatiku Jednopredmetna informatika, 2.godina Kolegij: Baze podataka

POBOLJŠAN MODEL PODATAKA ZA NAPREDNE APLIKACIJE Seminarski rad

Autori: Elena Frančin, Sabina Šišović i Katerina Černjeka Mentor: dr. sc. Patrizia Poščić
Rijeka, svibanj 2011.

SADRŽAJ
1. 2. UVOD ........................................................................................................................................................... 1 KONCEPTI AKTIVNIH BAZA PODATAKA I OKIDAČI ................................................................... 2 2.1. GENERALIZIRANI MODEL ZA AKTIVNE BAZE PODATAKA I ORACLE-OV AUTOMATSKI POSTUPAK POVEZIVANJA PROCEDURA .................................................................................................. 2 2.2. DIZAJN I PITANJE IMPLEMENTACIJA ZA AKTIVNE BAZE PODATAKA ............................... 6 2.3. PRIMJERI STATEMENT-LEVEL POZIVAJUĆIH PROCEDURAU STARBUST-U ...................... 7 2.4. POTENCIJALNE APLIKACIJE ZA AKTIVNE BAZE PODATAKA ............................................. 10 3. VREMENSKA BAZA PODATAKA ....................................................................................................... 11 3.1. SADRŽANO VRIJEME U RELACIJSKIM BAZAMA PODATAKA KORISTEĆI N-TORKE ..... 13 3.1.1. Relacije valjanog vremena ............................................................................................................ 13 3.1.2. Relacije transakcijskog vremena ................................................................................................... 14 3.1.3. Dvovremenske relacije .................................................................................................................. 14 3.2. UKLJUČIVANJE VREMENA U OBJEKTNO-ORIJENTIRANOJ BAZI PODATAKA PRAVEĆI VERZIJE ATRIBUTA ..................................................................................................................................................... 16 3.3. KONSTRUKCIJE VREMENSKOG UPITA .................................................................................................. 16 4. MULTIMEDIJSKE BAZE PODATAKA ............................................................................................... 17 4.1. 4.2. 5. KONCEPT PROSTORNIH BAZA PODATAKA ............................................................................. 17 UVOD U KONCEPTE MULTIMEDIJSKIH BAZA PODATAKA .................................................. 18

UVOD U DEDUKTIVNE BAZE PODATAKA ..................................................................................... 19 5.1. PREGLED DEDUKTIVNIH BAZA PODATAKA .......................................................................................... 19 5.2. PROLOG/DATALOG NOTACIJA ............................................................................................................. 19 5.3. DATALOG NOTACIJA ........................................................................................................................... 21 5.4. KLAUZULNE FORME I „HORN“ CLAUSES ............................................................................................. 22 5.4.1. Pretvaranje formuli ....................................................................................................................... 22 5.5. INTERPRETACIJA PRAVILA .................................................................................................................. 23 5.6. DATALOGOVI PROGRAMI TE NJIHOVA SIGURNOST .............................................................................. 25 5.7. UPOTREBA RELACIJSKIH OPERACIJA ................................................................................................... 26 5.8. EVALUACIJA NEREKURZIVNIH UPITA U DATALOGU ............................................................................ 26

1. UVOD
Zbog povećane upotrebe baze podataka, korisnici su zahtijevali dodatne funkcionalnosti njihovih softverskih paketa s ciljem olakšavanja implementacije više naprednih i složenih korisničkih aplikacija. Objektno – orijentirane baze podataka osiguravaju svojstva koja omogućuju korisnicima proširivanje sustava pomoću apstraktnih tipova podataka za svaku aplikaciju. Korisno je ustanoviti zajedničke značajke za neke od naprednih aplikacija i napraviti model koji će predstavljati te zajedničke značajke. Specijalizirane pohranjene strukture i indeksirane metode mogu biti implementirane radi poboljšanja djelovanja zajedničkih značajki. Značajke mogu biti implementirane kao apstraktna vrsta podataka ili klasna biblioteka i može se odvojeno kupiti uz softverski paket DBMS-a. Upoznat ćemo baze podataka nekih zajedničkih značajki koje koriste napredne aplikacije.

1

2. KONCEPTI AKTIVNIH BAZA PODATAKA I OKIDAČI
Okidač zapravo predstavlja tehniku za specifikaciju određenih tipova pravila. Taj je postupak postojao već u ranim verzijama SQL –a a sad je i dio SQL-99 standarda. Komercijalni SUBP (Sustavi za upravljanje bazom podataka) kao npr. Oracle, DB2 i SYBASE imali su više verzija tzv. Triggersa1, odnosno okidača. Okidač zapravo predstavlja objekt koji postoji samo unutar radnog okruženja neke tablice. Oni se automatski izvršavaju kada se određene stvari dese u tablici, kao npr. ubacivanje redova, ažuriranje ili brisanje. Okidači se mogu koristiti za različite stvari ali se uglavnom koriste za kopiranje podataka prilikom unošenja ili za provjeru pri ažuriranju podataka koko bi se osiguralo da podaci ispunjavaju određene kriterije. Koristiti ćemo sintaksu Oracle-ovog SUBP-a kako bi ilustrirali taj koncept jer je Oracle-ov postupak povezivanja procedura vrlo sličan SQL standardu.

2.1.

GENERALIZIRANI MODEL ZA AKTIVNE BAZE PODATAKA I ORACLE-OV AUTOMATSKI POSTUPAK POVEZIVANJA PROCEDURA

Model koji se koristi nazvan je ECA (Event-Condition-Action) model. Pravila ECA modela sastoje se od 3 komponente: 1. Event (Događaj) – ti događaji su obično operacije ažuriranja baze podataka koje su eksplicitno primijenjene na bazu podataka. U generalnom modelu oni mogu biti i privremeni događaji ili neki vanjski događaji. 2. Condition – predstavlja uvjet dali bi se određeno akcija trebala izvršiti. Jednom kad se okidač pozvao, opcionalno uvjet može biti procijenjen. Ako nema uvjeta onda će se akcija izvršiti samo jednom, kad se desi Event. Ako je uvjet definiran, znači da je najprije procijenjen, ali samo ako je procijenjen na true akcija će se izvršiti. 3. Action – akcije koje se izvršavaju. Akcija je obično niz SQL naredbi ali može biti i transakcija baze podataka ili neki vanjski program koji će se automatski izvršavati.

Pokušat ćemo ilustrirati ovaj model na primjeru. Primjer se temelji na pojednostavljenoj varijanti aplikacije baze podataka koju smo nazvali TVRTKA.

1

Triggers je engleska riječ za automatski postupak povezivanja procedure.

2

BP se sastoji od sljedećih tablica: ZAPOSLENIK (IME, OIB, PLACA, BRODJEL, NADZORNI_OIB) ; - Za BrOdjel je dozvoljena Null vrijednost koja nam govori da zaposlenik trenutno ne pripada niti jednom odjelu. - NadzorniOIB je valjski ključ sa tablicom ODJEL ODJEL (OIME, BRODJEL, UKUPNA_PLACA, MENADZER_OIB); - Atribut Ukupna_placa predstavlja ukupnu placu svih zaposlenika zaposlenih u pojedinom odjelu. - MenadžerOIB predstavlja vanjski ključ sa tablicom ZAPOSLENIK Prvo moramo definirati DOGAĐAJE (Evente) koji mogu prouzročiti promjene atributa Placa: 1. Umetanje (jednog ili više) zaposlenika u tablicu ZAPOSLENIK. 2. Promjena plaće (jednog ili više) postojećih zaposlenika. 3. Promjena odjela postojećih zaposlenika. 4. Brisanje (jednog ili više) zaposlenika iz tablice ZAPOSLENIK. U slučaju Eventa 1 moramo samo preračunati Ukupna_placa u slučaju da je novi zaposlenik odmah dodijeljen određenom odjelu, to znači da taj zaposlenik nema postavljeno BrOdjel na Null vrijednost. To bi mogao biti UVJET (Conditon) koji će se provjeravati. Sličan bi uvjet trebali provjeravati kod Eventa 2 (i Eventa 4) ako je zaposlenikova placa promijenjena (ili je zaposlenik izbrisan) a zaposlen je u određenom odjelu. Za Event 4 uvijek ćemo izvršavati akciju da bi održavali vrijednost Ukupna_placa točnom, tako da nam tu ne trebaju uvjeti jer je akcija uvijek izvršena. AKCIJA (Action) za Evente 1,2 i 4 je da se automatski ažurira vrijednost Ukupna_placa za odjel zaposlenika u slučaju unosa, brisanja ili ažuriranja zaposlenikove plaće. U slučaju Eventa 3 potrebna je dvostruka akcija; jedna da se ažurira Ukupna_placa odjela u kojem je zaposlenih bio zaposlen i jedna da se ažurira Ukupna_placa novog odjela u kojem je zaposlen. Četiri okidača R1, R2, R3 i R4 odgovaraju gore navedenoj situaciji. Pogledajmo okidač R1 kako bi ilustrirali sintaksu kreiranja okidača u Oracle-u.

3

a) Okidači koji automatski održavaju konzistenciju UKUPNA_PLACA tablice ODJEL: R1: CREATE TRIGGER TOTALSAL1 AFTER INSERT ON ZAPOSLENIK FOR EACH ROW WHEN (NEW.BRODJE IS NOT NULL) UPDATE ODJEL SET UKUPNA_PLACA = UKUPNA_PLACA + NEW.PLACA WHERE BRODJEL = NEW.BRODJEL R2: CREATE TRIGGER TOTALSAL2 AFTER UPDATE OF PLACA ON ZAPOSLENIK FOR EACH ROW WHEN (NEW.BRODJEL IS NOT NULL) UPDATE ODJEL SET UKUPNA_PLACA = UKUPNA_PLACA + NEW.PLACA – OLD.PLACA WHERE BRODJEL = NEW.BRODJEL; R3: CREATE TRIGGER TOTALSAL3 AFTER UPDATE OF BRODJEL ON ZAPOSLENIK FOR EACH ROW BEGIN UPDATE ODJEL SET UKUPNA_PLACA = UKUPNA_PLACA + NEW.PLACA WHERE BRODJEL = NEW.BRODJEL UPDATE ODJEL SET UKUPNA_PLACA = UKUPNA_PLACA – OLD.PLACA WHERE BRODJEL = OLD.BRODJEL END; R4: CREATE TRIGGER TOTALSAL4 AFTER DELETE ON ZAPOSLENIK FOR EACH ROW WHEN (OLD.BRODJEL IS NOT NULL) UPDATE ODJEL SET UKUPNA_PLACA = UKUPNA_PLACA – OLD.PLACA WHERE BRODJEL = OLD.BRODJEL;

4

b) Okidači za usporedbu plaće zaposlenika sa plaćom njegovog nadređenog: R5: CREATE TRIGGER INFORM_SUPERVISOR1 BEFORE INSERT OR UPDATE OF PLACA, NADZORNI_OIB ON ZAPOSLENIK FOR EACH ROW WHEN (NEW.PLACA > (SELECT PLACA FROM ZAPOSLENIK WHERE OIB = NEW.NADZORNI_OIB)) INFORM_SUPERVISOR(NEW.NADZORNI_OIB, NEW.OIB); Naredbom CREATE TRIGGER zapravo stvarno okidač i zatim navodimo njegovo ime, u primjeru R1 je to TOTALSAL1. Klauzula AFTER definira da se procedura pozove nakon određenog događaja (Eventa) koji će prouzročiti da se okidač izvrši (ili pozove). Npr. u primjeru R1 okidač se poziva nakon unosa (AFTER INSERT) novog zaposlenika u tablicu ZAPOSLENIK (ON ZAPOSLENIK). Opcionalno navodimo i FOR EACH ROW što znači da će se procedura pozvati jednom za svaki red na koji djeluje događaj (Event). Zatim slijedi klauzula WHEN koja se koristi za navesti uvjete koji trebaju biti provjereni nakon što je procedura pozvana a prije izvršavanja ikakve akcije. I napokon, akcije koje trebaju biti izvedene definirane su kao PL/SQL blok koji sadrži jednu ili više izjava kojima se izvršavaju vanjske procedure. Navedena 4 okidača R1, R2, R3 I R4 ilustriraju broj mogućnosti pozivanja procedure. Prvo, osnovni događaji koji mogu biti specificirani za pozivanje procedura su standardne SQL naredbe ažuriranja: UNOS, BRISANJE i AŽURIRANJE. One su definirane istoimenim naredbama INSERT, DELETE I UPDATE. Naredba UPDATE navodi atribute koji će biti ažurirani, npr. UPDATE OF PLACA BRODJEL... Upotrjebljeni izrazi NEW i OLD koriste se u Oracle notaciji; NEW se odnosi na novouneseni ili ažurirani podatak dok se OLD odnosi na podatak koji je izbrisan ili onaj podatak na kojem se izvršilo ažuriranje. Procedura R1 je automatski pozvana nakon INSERT operacije koja je primijenjena na tablicu ZAPOSLENIK. U R1 se provjerava uvjet (NEW.BRODJEL IS NOT NULL) i ako je on istinit znači da novo uneseni zaposlenik pripada jednom od odijela, a to znači da se izvodi jedna od akcija. Akcija ažurira podatke tablice ODJEL koji su povezani sa novo unesenim zaposlenikom tako da dodaje njegovu plaću (NEW.SALARY) atributu UKUPNA_PLACA odjela kojem taj zaposlenik pripada. Procedura R2 je vrlo slična R1 ali je ona automatski pozvana nakon izvršavanja operacije UPDATE koja ažurira plaću. Procedura R3 je automatski pozvana nakon ažuriranja atributa BRODJEL tablice ZAPOSLENIK, koja predstavlja prelazak radnika iz jednog odjela u drugi. U ovoj proceduri nemamo uvjeta tako da je ona pozvana svaki put kad se taj događaj (Event) dogodi. Ta akcija ažurira podatke o odjelu iz kojeg je dotični radnik otišao i odjela u koji

5

je prešao tako da se njegova plaća oduzima od ukupne plaće odjela kojem je pripadao a dodaje se novom odjelu. Važno je spomenuti utjecaj klauzule FOR EACH ROW jer se time poziva procedura za svaki redak (a znamo da jedan redak tablice sadrži podatke o jednom zaposleniku) posebno. Da nema te klauzule taj bi se okidač zvao statement-level okidač a s obzirom da se on definira za svaki redak posebno zove se row-level okidač. Izrazi NEW i OLD mogu se koristiti samo uz row-level okidače.

2.2.

DIZAJN I PITANJE IMPLEMENTACIJA ZA AKTIVNE BAZE PODATAKA

Prvo pitanje implementacije odnosi se na aktivaciju, deaktivaciju i grupiranje pravila ili kako smo ih prethodno znali nazvati – procedura. Sintaksa okidača u Oracle-u: ::= CREATETRIGGER (AFTER/ BEFORE) ON [ FOR EACH ROW1 [ WHEN ] ; ::= {OR } ::=INSERT/ DELETE/UPDATE [OF {, Q1 OR Q2 OR … OR Qm

(3) se može transformirati u:
P1 AND P2 AND ... AND Pn => Q ,

koja je zapisana u Datalogu slijedeći pravilo: Q :- P1, P2, … , Pn. (4) se može transformirati u:
P1 AND P2 AND ... AND Pn , koja je zapisana u Datalogu: P1, P2, … , Pn.

(5) (6) (7) (8)

22

Pravilo Dataloga, kao u (6) je ustvari „Horn clause“ i njezino značenje, bazirano na formuli (5) jest: ako su predikati Pi (i=1,2,…,n) svi istiniti za sve pojedinačne veze sa svojim argumentima, tada je Q također istinit. Datalogov izraz (8) traži da svi predikati budu istiniti da bi upit bio zadovoljen. Općenito, upit se u Datalogu sastoji od dvije komponente: 1. Datalogov program, koji je skup pravila 2. Znak P(X1, X2, … , Xn) gdje je svaki Xi varijabla ili konstanta Prologov ili Datalogov sustav ima unutarnji stroj za zaključivanje koji se može koristiti za rješavanje takvih upita. Kod Prologa oni vraćaju jedan rezultat po upitu, a kod Dataloga se svi rezultato vraćaju zajedno.

5.5.

INTERPRETACIJA PRAVILA

Dvije su opcije interpretiranja teoretskog značenja pravila: dokazno-teoretska i modelno-teoretska. U dokazno teoretskoj interpretaciji, smatramo činjenice i pravila istinitim tvrdnjama ili aksiomima. Temeljni aksiomi ne sadrže varijable. Činjenice su temeljni aksiomi koji su predviđeni da budu istiniti. Pravila su nazvana deduktivnim aksiomima jer mogu biti korištena u dedukciji novih činjenica. Deduktivni aksiomi mogu se koristiti za stvaranje dokaza koji donose nove činjenice iz postojećih činjenica. Primjer 6.
1. superior(X,Y):-supervise(X,Y). 2. superior(X,Y):-supervise(X,Z), superior(Z,Y). 3. supervise(jennifer.ahmad). 4. supervise(james.jennifer). 5. superior(jennifer.ahmad). 6. superior(james.ahmad). (rule 1) (rule 2) (ground axiom, given) (ground axiom, given) (apply rule 1 on 3) (apply rule 2 on 4 and 5)

Iz ovog primjera vidimo kako se dolazi do dokaza činjenice superior(james,ahmad) iz danih pravila (1., 2., 3. i 4. Su zadani). Dokazno-teoretska interpretacija preceduralno računa odgovor na upit. Proces dokazivanja se naziva „dokazivanje teorema“. Drugi vid interpretacije, modelno-teoretska za zadanu konačnu ili beskonačnu domenu konstantnih vrijednosti povezujemo s predikatom svaku moguću kombinaciju vrijednosti argumenta. Tada moramo odrediti je li predikat istinit ili lažan. Općenito, dovoljno je odrediti one kombinacije koje čine predikat istinitim i utvrditi da su ostale kombinacije lažne. Kad je to utvrđeno za sve predikate, to se naziva interpretacijom skupa predikata.

23

Primjer 7. U ovoj interpretaciji istinita vrijednost je dodijeljena svim mogućim kombinacijama vrijednosti argumenata, za dva predikata:
Pravila: superior(X,Y) :- supervise(X,Y). superior(X,Y) :- supervise(X,Z), superior(Z,Y). Poznate činjenice:: supervise(franklin,john) is true. supervise(james,franklin) is true. supervise(john,jennifer) is true supervise(X,Y) je false za sve ostale (X,Y) kombinacije Izvedene činjenice: superior(franklin,john) is true. superior(james.franklin) is true. superior(john.jennifer) is true. superior(james,john) is true. superior(franklin,jennifer) is true. superior(james,jennifer) is true superior(X,Y) je false za sve ostale (X,Y) kombinacije

Bitno je još naglasiti da kad su svi predikati u tijelu pravila istiniti u interpretaciji, predikat u glavi pravila mora također biti istinit. U modelno-teoretskom pristupu, značenje pravila dolazi iz stvaranja modela za ta pravila. Taj model se naziva minimalnim modelom za skup pravila, ako se nijedna činjenica ne može promjeniti iz istinite u lažnu te i dalje imati model za ta pravila. Model prikazan u prethodnom primjeru je minimalni model za skup činjenica danih u supervise predikatu. Ustvari, minimalni model koji odgovara danom skupu činjenica u modelno-teoretskoj interpretaciji trebao bi biti jednak činjenicama interpretiranim dokazno-teoretski (za istu bazu deduktivnih aksioma). Međutim, ako naiđemo na negaciju u pravilima, mnogo više je minimalnih modela mogućih za dani skup činjenica. Treći pristup uključuje definiranje mehanizma za zaključivanje koji se koristi za deduciranje činjenica iz pravila. Kod Prologa, nisu svi programi u skladu s dokaznoteorijskom ili modelno-teorijskom interpretacijom, to ovisi o pravilima u programu. Za mnoge jednostavne Prologove programe, stroj za zaključivanje donosi činjenice koje odgovaraju prvim dvijema interpretacijama.

24

5.6.

DATALOGOVI PROGRAMI TE NJIHOVA SIGURNOST

Dvije su glavne metode definiranja istinitih vrijednosti u Datalogovim programima. Prva metoda, činjenično-definirani predikati su definirani nabrajanjem svih kombinacija vrijednosti koje čine predikat istinitim. Ta metoda sliči relacijama u bazi čije su sastavnice pohranjene u bazi podataka. Primjer 8. employee(john). employee(franklin). employee(alicia). employee(jennifer). salary(john,30000). salary(franklin,40000). salary(alicia,25000). Salary(jennifer,43000). department(john,research). department(franklin,research). department(alicia,administration). department(jennifer,administration). supervise(franklin,john). supervise(jennifer,alicia). supervise(john,alicia). male(john). male(franklin). female(alicia). female(jennifer). workson(john,productx,32). workson(john,producty,8). workson(franklin,producty, 10). workson(franklin,productz, 10). workson(franklin,computerization,10) . workson(franklin,reorganization,10). workson(alicia,newbenefits,30). workson(alicia,computerization, 10). workson(jennifer,newbenefits,20). workson(jennifer,reorganization,15). project(productx). project{producty). project(productz). project(computerization). project(reorganization). project(newbenefits).

Prikazani su predikati employee, salary, department, supervise, male, female, workson, project.

Druga su metoda pravilno-definirani predikati koji su ustvari glava jednog ili više Datalogovih pravila. Oni sliče virtualnim relacijama. Primjer 9. superior(X,Y) :- supervise(X,Y). superior(X,Y) :- supervise(X,Z), superior(Z,Y). subordinate(X,Y) :- superior(Y,X). supervisor(X) :- employee(X), supervise(X,Y). over_40K_emp(X) :- employee(X), salary(X,Y), Y>=40000. under_40K_supervisor(X) :- supervisor(X), not(over_40_K_emp(X)).

25

Program ili pravilo se smatraju sigurnima ako imaju konačan broj činjenica. Pravila u prethodnom primjeru jesu sigurna. Situacija u kojoj nailazimo na nesigurno pravilo koje generira beskonačan broj činjenica kad jedna od varijabli može obuhvatiti i vrijednosti iznad domene vrijednosti. Primjer 10. big_salary(Y) :- Y>60000

5.7.

UPOTREBA RELACIJSKIH OPERACIJA

U pravilima u Datalogu se specificiraju mnoge operacije relacijske algebre. To znači da se u Datalogu relacijski upiti mogu jednostavno odrediti. Rastuća moć Dataloga omogućena je kroz rekurzivne upite. U Datalogu nisu potrebna imena atributa nego je bitan stupanj svakog predikata, te tip podatka svakog atributa. To je od velike važnosti za operacije unije, presjeka i spajanja. Ako se Datalogov model bazira na relacijskom modelu predikat predstavlja skup n-torki, a postojanje jednakih n-torki unutar istog predikata se u pravilu ne pojavljuje, iako je moguće, dok je kod Prologa sasvim nemoguće. Primjer 11. rel_one(A, B,C). rel_two(D,E,F). rel_three(G,H,I,J). select_one_B_less_5(X,Y,Z) :- rel_one(X,Y,Z), Y