Prof. Dr Milorad K. Banjanin

1. Univerzitet u Istočnom Sarajevu Tehnološki fakultet Zvornik AKTIVNE BAZE PODATAKA Prof. Dr Milorad K. Banjanin

2. kontrolu integriteta baze podataka, jedna od najznačajnijih i najdinamičnijih oblasti istraživanja i razvoja baza podataka krajem 1980-tih i početkom 1990-tih godina kontrolu prava pristupa, održavanja pogleda, generisanja izvedenih podataka, sve više se uključuju u komercijalne sisteme za upravljanje bazama podataka i postaju predmet standardizacije prikupljanja statističkih podataka, praćenje funkcionisanja baze i vođenje žurnala, kao i mnoge druge karakteristike baza podataka. aktivni sistemi baza podataka proširuju funkcionalnost tradicionalnih baza podataka uvođenjem sistema pravila koji se koristi kao opšti, unificirani mehanizam za:

3. konvencionalni sistemi aktivni sistemi PASIVNI podaci se kreiraju (ubacuju), menjaju, brišu i prikazuju kao odgovor na operacije koje direktno pokreću korisnici ili se pozivaju u toku izvršavanja aplikativnih programa Primer skladišnog poslovanja imaju mogućnost da automatski izvršavaju određene operacije kao odgovor na pojavu određenih događaja i/ili za zadovoljenje određenih uslova

4. Na skladištu se nalazi određeni broj časopisa. Na osnovu informacija o broju prodatih primeraka časopisa smanjuje se broj primeraka na skladištu. konvencionalni sistemi Pokreće se “spolja”, na zahtev korisnika Kada broj primeraka na skladištu postane manji od 5 naručuje se novih 100 primeraka. PROBLEMI: Semantiku predstavljenu programima je teško razumeti; Promene je teško sprovesti na svim potrebnim mestima; Problem frekvencije izvršavanja programa za ispitivanje stanja na skladištu. U bazi podataka se čuvaju samo podaci o trenutnom broju primeraka kojima se raspolaže. Sva ostala semantika se nalazi u programima. Neki od njih služe za ažuriranje stanja na skladištu. Poseban program periodično ispituje stanje i generiše narudžbenicu ako je broj primeraka časopisa manji od 5. Često izvršavanje programa je skupo. Da bi se prevazišao taj problem može se pribeći ređem izvršavanju programa. U tom slučaju može se promašiti pravi trenutak za ispitivanje stanja što za posledicu može imati da u nekom periodu ostanemo bez ijednog primerka časopisa.

5. U ovom slučaju prestaje potreba za programom za periodično ispitivanje stanja na skladištu. aktivni sistemi To pravilo se automatski pokreće i omogućuje generisanje narudžbenice svaki put kada broj primeraka na skladištu postane manji od 5.

6. ‚ Prepoznati predhodno opisane situacije (događaje i uslove) u bazi podataka, aplikacijama i okruženju; Pokrenuti definisane reakcije (operacije nad bazom podataka ili programe) po nastanku situacija Pasivni sistemi su u stanju da “zapamte” logički šemu i podatke, tj. činjenice u skladu sa šemom. Složeniji uslovi integriteta i pravila poslovanja realizuje se aplikativnim programima. Unutar programa su operacije nad bazom podataka koje omogućavaju pristup podacima i generisanje rezultata. logičku šemu i činjenice obuhvatanje i dodatne dinamike sistema iskazane kroz složena pravila integriteta Pasivni sistemi Aktivni sistemi Opšta ideja imaju manje mogućnosti za predstavljanje dinamike realnog sistema u odnosu na aktivne sisteme Aktivni sistemi imaju mehanizme za prepoznavanje SITUACIJA i za automatsko pokretanje odgovarajućih procedura kao REAKCIJA na nastale situacije. Aktivni sistemi omogućavaju: Svako pravilo definiše situaciju i akcije koje se preduzimaju sa nastankom situacije. Pravila u aktivnim bazama podataka su poznata pod imenomECA (Event-Condition-Auction) produkciona pravila

7. Aktivni sistemi softver za upravljanje bazom podataka detektor događaja mehanizam za izvršavanje pravila ON događaj uslov IF DO akcija Sva specificirana pravila čine MODEL ZNANJA ECA (Event-Condition-Action) produkciona pravila specifikuju se na sledeći način: Prikazano tipično produkciono pravilo ima sledeću semanatiku: “Kada se događaj pojavi, ukoliko je uslov zadovoljen (događaj i uslov određuju situaciju), izvrši ti akciju”. “situacija” se specificira u terminima predhodno moraju biti definisani “(re)akcija” Događaj može biti prepoznat u bazi podataka, u aplikaciji ili biti određen vremenskim trenutkom. Nakon prepoznavanja događaja aktivira se mehanizam za izvršavanje pravila. U bazi pravila pronalaze se pravila koja se odnose na identifikovani događaj i proverava uslov. Ukoliko je uslov zadovoljen izvršava se specificirana situacija.

8. Modeli znanja: semantika ECA pravila odnosi se na određeni događaj vrši proveru uslova po nastanku događaja u retkim slučajevima pravilo koje se izvršava bezuslovno svako PRAVILO izvršava definisanu akciju ako je uslov zadovoljen izvršava definisanu akciju odmah nakon nestanka događaja bez predhodnog proveravanja bilo kakvog uslova

9. DOGAĐAJI AKCIJA koji se proverava sa nastankom događaja USLOV Elementi potrebni za formiranje pravila: Primitivni događaji Složeni događaji 1. Predikat nad stanjem baze podataka Uslov je zadovoljen ako upit, odnosno aplikativna procedura vreća neke podatke (ili obrnuto, ako ih ne vraća) 2. Upit nad bazom podataka 3. Izvršavanje određene aplikatine procedure Akcija je bilo koji program. Takav program može da uključuje operacije nad bazom podataka i implicitno ili eksplicitno generiše nove događaje.

10. Model izvršavanja: obrada ECA-pravila povezivanje transakcije, odnosno događaja koji pokreće pravilo i izvršavanje ECA-pravila Osnovni načinpovezivanja obrade transakcije i pravila Složeniji načinpovezivanja obrade transakcije i pravila Trenutan (engl. Immediate) način Odložen (engl. Deferred) način Razdvojen (engl. Decouped) način

11. Model izvršavanja: obrada ECA-pravila tr T P izv tr T P izv tr T P izv Osnovni način povezivanja obrade transakcije i pravila Prouzrokuje prekid izvršavanja transakcije odmah po identifikovanju događaja za koji postoji definisano ECA-pravilo. Nakon toga izvršava se pravilo, da bi se sa izvršavanjem polazne transakcije nastavilo tek po završetku obrade pravila. a) TRENUTAN način b) ODLOŽEN način Ne prekida transakciju nakon identifikovanja događaja za koji postoji definisano pravilo. Umesto toga nastavlja se normalno izvršavanje transakcije, a obrada, tj. izvršavanje pravila “odlaže” se do završetka polazne transakcije. C) RAZDVOJEN način Izvršavnje pravila predstavlja potpuno novu transakciju, nezavisnu od polazne.

12. Model izvršavanja: obrada ECA-pravila Zasnivaju se na činjenici da pravilo nije atomske strukture, već se sastoji od događaja, uslova i akcije. tr T Izvrš. akcije Eval. uslova tr T Eval. uslova Izvr. akcije Složeniji način povezivanja obrade transakcije i pravila pravilo ne mora izvršavati kao neprekidna aktivnost, tj. evaluacija uslova ne mora započeti odmah nakon identifkovanja događaja, niti izvršavanje akcije odmah nakon utvrđivanja da je uslov zadovoljen Evaluacija uslova se vrši odmah po nastanku događaja, tj. ‚događaj i uslov čine neprekidnu aktivnost, dok je izvršavanje akcije odloženo. Evaluacija uslova i izvršavanje akcije sa polaznom transakcijom čine jednu celinu (jednu transakciju). a) TRENUTAN/ODLOŽEN način Evaluacija uslova se ne vrši odmah po nastaku događaja, niti se akcija izvršava odmah po utvrđivanju da je uslov zadovoljen. Identifikovanje događaja, tj. utvrđivanje da je uslov zadovoljen, ne prouzrokuju prekid polazne transakcije tako da evaluacija uslova i izvršavanje akcije predstavljaju dve nove transakcije potpuno nezavisne od polazne. b) RAZDVOJEN/RAZDVOJEN način

13. Izboru i specifikaciji načina povezivanja obrade transakcije i pravila Izboru redosleda izvršavanja pravila (sekvencijalni ili konkurentni) u slučaju da je za isti događaj definisano više pravila Izborumehanizma oporavka Izboru najboljeg načina izvršavanja pravila čije akcije pokreću nova pravila (moguće rekurzivno pokretanje samog sebe) x x x x Prilikom definisanja modela izvršavanja potrebno je voditi računa o:

14. Pregled pristupa razvoju aktivnih baza podataka Označava bilo koju proceduru napisanu u DBTG jeziku u koji je, sa punom funkcionalnošću, uključen neki konvencionalni programski jezik (najčešće COBOL) DBTG jezik Za DBTG tip zapisa T lista operacija specificira jednu ili više sledećih operacija: INSERT, REMOVE, FIND, STORE, DELETE, MODIFY i GET. Za DBTG set S lista operacija specificira jednu uli više sledećih operacija: INSERT, REMOVE i FIND. Poseduje mehanizam za automatsko pozivanje procedura kao odgovor na specificirane operacije nad bazom podataka 1980-tih Istraživanja u oblasti aktivnih baza podataka postaju široko prihvaćena 1990-tih Pun zamah i zrelost u oblasti aktivnih baza podataka 1970-tih Prvi pristupi uključivanja aktivnih komponenti jedan od prvih pristupa Deklaracija DBTG seta ili tipa zapisa (rekorda) može da uključi jednu ili više ON klauzula sintakse: CODASYL jezik za manipulisanje podacima ON lista_operacija CALL naziv_procedure DBTG jezik (jer ga je definisala Data Base Task Group) Specificirana procedurase poziva automatski neposredno nakon izvršavanja jedne od specificiranih operacija nad setom S. Specificirana procedura se poziva automatski neporedno nakon izvršavanja jedne od specificiranih oparacija nad zapisom T.

15. Pregled pristupa razvoju aktivnih baza podataka omogućavao referenciranje starih i novih vrednosti ažuriranih n-torki razvijen sredinom 1970-tih Query-by-Example (QBE) relacioni upitni jezik Uključivao je i mehanizamtrigera za proveru uslova integriteta Omogućavao je definisanje uslova povezanih sa operacijama ažuriranja INSERT, DELETE i UPDATE nad određenim tabelama i n-torkama. Kada se takva operacija ažuriranja izvršava, vrši se provra odgovarajućeg uslova; ako uslov nije zadovoljen operacija se poništava

16. Pregled pristupa razvoju aktivnih baza podataka Aktivni sistemi se razvijaju kao: nadogradnja objektno orijentisanih sistema HiPAC - najpoznatiji OO sistem za upravljanje bazom podataka, koji podržava EAC pravila ETM: događaj-akcija trigeri za kontrolu integriteta u CAD OODBMS O2: dodata pravila u OODBMS SAMOS: ECA pravila integrisana u OODBMS CPLEX: pravila dodata u OO programski jezik ODE: ograničenja i trigeri dodati C++ nadogradnja relacionih sistema Postgres Starburst

17. HiPAC (High Performance Active Database System) mogu biti kreirana, prikazana, izmenjena ili izbrisana slično drugim objektima mogu biti grupisana i organizovana slično drugim objektima HiPAC mogu pripadati podklasama, imati atribute i biti povezana sa drugim objektima da obezbedi neophodnu infrastrukturu, odnosno okruženje, za aplikacije rukovođene događajima kod kojih je vremenski kritičan odziv na nastanak situacije koja se prati najpoznatiji aktivni sistem, zasnovan na objektno-orijentisanom modelu podataka Inicijalni cilj projekta Pravila i komponente pravila su objekti baze podataka, što znači da: poseduje veoma generalizovan jezik pravila

18. Svako pravilo ima definisan događaj(Event), uslov(Condition), akciju(Action) i način povezivanja(Coupling Mod) Atributi Operacije Create Delete Modify Enable Disable Fire Event Condition Action ostali atributi DOGAĐAJ AKCIJA USLOV Jedna od klasa u HiPAC-u je Rule koja je podklasa klase Entity Atributi i operacije klase Rule bilo koja parametrizovana operacija nad bazom podataka, vremenska karakteristika (apsolutna, relativna iili periodična), signal iz aplikativnog programa ili kombinacija predhodnog. skup upita nad bazom podataka sekvenca proizvoljnih operacija nad bazom podataka ili eksternih operacija

19. Konkurentno izvršavanje pravila DOGAĐAJ USLOV AKCIJA Jedan događaj može da pokrene više pravila i u tom slučaju ne dolazi do rešavanja konflikta izborom jednog iz skupa mogućih pravila Rekurzivno izvršavanje pravila Kao rezultat izvršavanja jednog pravila može da bude pokrenuto drugo ili ponovo isto pravilo Parametri iz događajaprenose se u uslov povezani su parametrima Parametri iz događaja i uslova prenose se u akciju Fleksibilnost se ostvaruje izborom načina povezivanja, tj. specificiranjem mesta izvršavanja uslova i akcije pravila relativno u odnosu na transakciju koja pokreće izvršavanje pravila. Specificiraju se transakcione veze između: događaja i uslova (E-C Coupling) uslova i akcije (C-A Coupling) HiPAC podržava trenutan, odložen i razdvojen način povezivanja, pri čemu razdvojen način povezivanja može biti uzročno-povezan razdvojen ili nepovezan razdvojen.

20. Starburst Prototipski sistem koji se, od 1985 godine, razvijao u IBM-ovom istraživačkom centru jedan od najznačajnijih ciljeva Sintaksa pravilanjegovog sistema pravila je zasnovana na SQL-u izrada aktivnog relacionog sistema čija je osnovna karakteristika MOGUĆNOST PROŠIRENJA, odnosno uključivanje nove tehnologije za svaku komponentu arhitekture sistema i davanje efikasne podrške za aplikacije bilo kog tipa Kako su relacioni upitni jezici skupovno orijentisani, i pravila su skupovno orijentisana – pokreću ih skupovi promena nad bazom podataka, a akcije pravila mogu takođe da proizvedu skupove promena nad bazom

21. Starburst Ukoliko je n-torka ažuirana (menjana) više puta, neto efekat je samo jedno ažuriranje n-torke sa kombinovanim vrednostima pojedinačnih izmena Ukoliko je n-torka izmenjena, pa nakon toga izbačena, razmatra se samo izbacivanje Ukoliko je n-torka ubačena, pa izmenjena, neto efekat je ubacivanje n-torke sa izmenjenim vrednostima Ukoliko je n-torka ubačena, pa nakon toga izbačena, smatra se da nije ni došlo do promene stanja baze podataka Pravila su zasnovana na pojmu PRELAZA STANJA (engl. state transition) promena stanja baze podataka nastala kao rezultat izvršavanja nedeljive sekvence operacija za ažuriranje baze(insert, update, delete). U razmatranje se uzimajuNETO EFEKTIprelaza stanja:

22. create rule <naziv_pravila> on <tabela> when <predikat_prelaza> [if <uslov>] then <lista akcija> [precedes <lista_pravila>] [follows <lista_pravila>] Sintaksa naredbe za kreiranje pravila: Određuje operacije koje pokreću izvršavanje pravila On je neprazan podskup skupa: (inserted, deleted, updated, updated(k1, ...., kn)) kolone tabele <tabela> Nakon pokretanja pravila proverava se specificirani uslov. USLOV je proizvoljan SQL predikat nad bazom podataka. Neobavezne klauzule koje definišu redosled primene, odnosno redosled prioriteta pravila. Prelaz stanja će pokrenuti određeno pravilo, ukoliko se,kao neto efekat prelaza, nad tabelom za koju je definisano pravilo pojavila bar jedna od operacija specificiranih predikatom prelaza za posmatrano pravilo. • AKCIJAje bilo koja Starburst operacija nad bazom podataka: • Operacija za manipulisanje podacima (insert, delete, update, select); • Operacija za kontrolne funkcije (npr. rollback) • Operacija za definisanje podataka (npr. create table). One omogućuju rešavanje konflikta do koga dolazi kada je istim skupom promena pokrenuto više pravila. Ako pravilo P1 ima u procedes listi pravilo P2, tada će se u slučaju da su oba pravila pokrenuta, pravilo P1 uvek razmatrati pre pravila P2 Ako je uslov zadovoljen tj. ako se izrčunava u true, izvršavaju se akcije specificirne LISTOM AKCIJA za posmatrano pravilo. Uslov nije obavezan, ukoliko je izostavljen smatra se da se uvek izračunava u true, odnosno akcije pravila izvršavaju se pezuslovno, uvek kada je pravilo pokrenuto.

23. INSERTED se odnosi na one n-torke sadašnjeg stanja tabele T, koje su ubačene tokom prelaza. logičke tabele koje odražavaju promene nastale u toku prelaza stanja DELETED se odnosi na one n-torke stanja pre prelaza tabele T, koje su izbačene tokom prelaza. NEW-UPDATED se odnosi na one n-torke sadašnjeg stanja tabele T, za koje je izmenjena bar jedna kolona referencirana pravilom. OLD-UPDATED se odnosi na one n-torke stanja pre prelaza tabele T, za koje je izmenjena bar jedna kolona referencirana pravilom. mogu da referenciraju tekuće stanje baze podataka, posredstvom SQL operacija Uslov i akcija pravila Uslov i akcija mogu da referenciraju TABELE PRELAZA inserted, deleted, new-updated old-updated Posmatramo pravilo P definisano nad tabelom T. Na kraju prelaza koji pokreće pravilo P:

24. Pravilo koje kontroliše srednja primanja radnika. Pokreće se uvek kada se ubacuju podaci o novim radnicima ili menjaju plate postojećih. Ukoliko srednja primanja radnika pređu iznos od 100000 transakcija se poništava: create rule kontrola-plata on radnik when inserted, updated (plata) if (select avg (plata) from radnik) > 100000 then (select * from inserted) union (select * from new-updated) ; rollback Tabele prelaza mogu se referencirati u from klauzuli select upitnog bloka. Primer pravila

25. {ALWAYS REFUSE ONE-TIME} Postquel-naredba PRS I pravila rekord (tuple) orijentisana Starbus pravila skupovno orijentisana Prototipski sistem koji se razvijao na Univerzitetu Berkli, kao naslednik INGRES projekta Postgres PRS I sistem pravila zanivao se na ideji da se bilo koja Postquel naredba može transformisati u pravilo promenom semantike naredbe, tako da se naredba logički izvršava ili uvek (ALWAYS) ili nikad (REFUSE) ili tačno jedanput (ONE-TIME) zatim je zamenjen najpre je imao Sintaksa PRS I pravila je sledćeg izgleda: PRS I sistem pravila PRS II sistem pravila Sintaksa pravila zasnovana na Događaji u PRS I sistemu pravila su IMPLICITNI Postquel-u pokreće ih promena nad pojedinačnom n-torkom relacije. PRS I pravila nemaju mogućnost referenciranja “starih” i “novih” vrednosti

26. define [tuple rewrite] rule <naziv> on <događaj> to <objekat> [where <uslov>] do [instead]<lista akcija> Nastanak događaja pokreće izvršavanje pravila PRS II sistem pravila U PRS II sistemu događaji su EKSPLICITNI Nastao je kao rezultat sagledanih nedostataka PRS I sistema Predstavlja povratak na konvencionalni način predstavljanja znanja u vidu produkcionih pravila. Događaj može biti jedna od standardnih Postquel naredbi za manipulisanje podacima: retrieve Sintaksa PRS II pravila je sledćeg izgleda: append delete replece new old sa značenjem append ili replece značenjem delete ili replece

27. define [tuple rewrite] rule <naziv> on <događaj> to <objekat> [where <uslov>] do [instead]<lista akcija> PRS II sistem pravila Objekat je naziv relacije ili lista naziva atributa relacija. Where klauzula je standardna Postquel klauzula. Akcija je bilo koja operacija nad bazom podataka sa izmenom koja omogućuje korišćenje new ili current ključne reči umesto promenljive tipa red, na bilo kom mestu u Postquel naredbi na kome se promenljiva tipa red može koristiti.

28. define [tuple rewrite] rule <naziv> on <događaj> to <objekat> [where <uslov>] do [instead]<lista akcija> PRS II sistem pravila Ako je nakon događaja, za tekuću n-torku zadovoljen uslov iz where klauzule, pokreće se izvršavanje akcije pravila. Semantika PRS II pravila određuje da je u trenutku pristupa, ubacivanja, izmene ili izbacivanja n-torke poznata current (tekuća) n-torka (za prikaz, izmenu i izbacivanje) i new (nova) n-torka (za izmenu i ubacivanje) To predstavlja dopunu osnovne semantike po kojoj se akcije uvek izvršavaju kao dodatak na izvršavanje operacije koja je inicirala pokretanje pravila. Pored mogućnosti referenciranja tekuće i nove n-torke, akcioni deo PRS II pravila ima i dve karakteristike koje omogućavaju da se promena (tj. operacija), koja je inicirala pokretanje pravila, uopšte ne izvrši: Neposredno pre izvršavanja akcija, atributi referencirani sa current.<naziv_atributa> i new.<naziv_atributa> dobijaju vrednosti odgovarajućih polja tekuće, odnosno nove n-torke Akcija refuse- promena, koja je inicirala pokretanje pravila, se odbija; Klauzula instead – umesto promene izvršava se skup operacija definisanih instead klauzulom

29. Akcije pravila izvršavaju specificirani skup promena OBEZBEĐUJE REKURZIVNU SEMANTIKU OBRADE PRAVILA PRS II pravila rekord orijentisana pokreće ih pojedinačne promene nad n-torkama relacije Sva pravila se obrađuju untar transakcije koja je inicirana POLAZNOM OPERACIJOM. može inicirati pokretanje više pravila Pokrenuta pravila izvršavaju se u proizvoljnom redosledu Redosled i izvršavanje konflikta može se obzbediti dodelom fiksnih numeričkih prioriteta pojedinim pravilima

30. PRS II sistem podržava dva načina implementacije pravila: triger (tuple-level) implementacija query rewrite implementacija Kombinuje upite sa odgovarajućim skupom pravila i generiše modifikovane upite koji se potom izvršavaju. Obrađuje definisane trigere za svaku pojedinačnu n-torku relacije Efikasna je u situaciji kada je definisano puno pravila nad nekoliko n-torki relacije Efikasna je kada je definisano nekoliko pravila nad velikim brojem n-torki Koristi se za efikasniju obradu podskupa PRS II pravila Poziva se izvršavanjem operacija (prikaz, dodavanje, izmena, izbacivanje) nad pojedinačnim n-torkama relacije. Način implementacije svakog konkretnog pravila odrđuje samo korisnik pri definisanju pravila izborom ključne reči TUPLE ili REWRITE

31. Hvala na pažnji

32. primitivni događaji Ažuriranje podataka. Prikaz podataka. Vremenskiodređen. Aplikativno definisan događaj. U aktivnim sistemima koji su nadogradnja relacionih sistema SELECT operacija nad određenom tabelom INSERT, UPDATE ili DELETE operacija. U aktivnim sistemima koji su nadogradnja objetno orijentisanih sistema Poziv određene metode za prikaz objekta Kreiranje, brisanje ili izmena određenog objekta ili bilo kog objekta određene klase, kao i poziv određene metode koja modifikuje objekte. Vremenski događaj može biti apsolutan, tj. može predstavljati dostizanje određene vremenske tačke (npr. 01. Januar 2009. u 12:00) ili periodičan (npr. svakih 30 minuta ili svakog dana u 12:00) Ovakav događaj određuje sama aplikacija tako što joj je dozvoljeno da deklariše događaj D (npr. visoka temperatura, logovanje korisnika, itd.). Takođe se definišu i odgovarajuća pravila koja će kao događaj koji ih pokreće imati D.

33. složeni događaji Logički operatori. Sekvenca. Vremenska kompozicija. formiraju se kombinovanjem primitivnih i predhodno definisanih dloženih događaja. Korisni operatori za kobinovanje događaja: Događaji mogu biti kombinovani korišćenjem logičkih operatora AND, OR, NOT itd. Pravilo može biti pokrenuto kada se dva ili više događaja pojave u određenom, definisanom redosledu. Pravilo može biti pokrenuto kombinovanjem vremenskih i događaja koji nisu vremenski, npr. “5 sekundi nakon događaja D1”ili “svaki sat nakon prvog pojavljavanja događaja D2”.