Aktywne reguły w systemach obiektowych (i nie tylko)

K.Subieta. Aktywne reguły, Folia 1

Aktywne reguły w systemach obiektowych(i nie tylko)

Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa


Co to są reguły?Generalnie, są to dowolne informacje zapisane w bazie danych, których semantyka jest znana nie tylko dla ludzi, a również dla systemu. Takie informacje mogą być automatycznie interpretowane lub uwzględniane przez system.

Najczęściej spotykane typy reguł:

• Perspektywy (views): wyrażenia umożliwiające inny pogląd użytkownika na bazę danych• Zapamiętane procedury: procedury zapamiętane w bazie danych• Wirtualne atrybuty: atrybuty obiektów, których wartość jest wyliczana w momencie dostępu• Aktywne reguły: fragmenty kodu uruchamiane w momencie wystąpienia pewnego zdarzenia• Ograniczenia statyczne, asercje: warunki nakładane na pewne wartości lub ich kombinację• Ograniczenia dynamiczne: warunki nakładane na zmianę danych, okres ważności danych,...• Ograniczenia dostępu: reguły ustalające prawa dostępu uzytkowników do danych• ...


Reguły a reguły logiczne

Pojęcie reguły ma swój prawzór w regułach występujących w dedukcyjnych bazach danych lub w programowaniu w logice (reguły Horna). Jednakże tego rodzaju reguły mają jak dotąd zerowe zastosowanie w rzeczywistych (nie urojonych) bazach danych.

Podstawowa różnica z regułami logicznymi:- Reguły w bazach danych są zwykle obywatelami pierwszej kategorii, mają nazwę, granice, mogą być dynamicznie wstawiane lub usuwane ze środowiska bazy danych- Reguły w bazie danych są kodowane w dostęnym dla niej języku, np. w SQL

Dość przypadkowa w gruncie rzeczy koincydencja terminu “reguła” spowodowała wyzwolenie lawiny pseudo-teorii próbujących łaczyć “deductive and active” bazy danych.

Całość zamieniła się w całkowicie niestrawny najeżony formułami klajster, z którego jak dotąd dokładnie nic nie wynika (poza oczywiście kolejną publikacją na kolejną konferencję).Moją antypatią w tym zakresie cieszy się tandem S.Ceri + J.Widom. Wyjątkowe bzdury.

Ostatnio ta aktywność pseudo-teoretyków w tej działce jakby przygasła.Czyżby nie mieli nic do powiedzenia?Wierzyć się nie chce...


Po co są reguły?Podniesienie “inteligencji” systemu, uwzględnienie reguł biznesu

Dzięki regułom programista może być zwolniony z obowiązku kodowania explicite mnóstwa informacji wewnątrz swojego programu. Ta informacja jest zakodowana raz i może być użyta przez wielu programistów, lub tez może być użyta wielokrotnie automatycznie, bez świadomości programistów.

Podniesienie bezpieczeństwa i niezawodnościReguły umożliwiają znaczne podwyższenie niezawodności działania i bezpieczeństwa danych. Programista jest zwolniony z obowiązku pamiętania o wielu elementach, które bez reguł musiałby wkomponować w swój program. Ma więc mniejsze szanse zrobienia błędu. Programista lub użytkownik jest również zabezpieczony przed popełnieniem błędu lub zaniedbania, który naruszy spójność lub bezpieczeństwo bazy danych. System jest bardziej zabezpieczony przed nieodpowiedzialnym działaniem lub sabotażem.

Podniesienie poziomu abstrakcji przy programowaniu aplikacjiProgramista lub uzytkownik ma większą możliwość skoncentrowania się na logice aplikacji, a nie na myśleniu o tym, aby nie przeoczyć żadnego szczegółu, który może zaważyć na logice funkcjonowania, bezpieczeństwie lub spójności systemu.


DOSTAWCA

Pasywna relacyjna baza danych

CZĘŚĆ

DNR

D1D2D3D4D5

NAZW

AbackiBoberCzernyDąbekErbel

STATUS

2010302030

MIASTO

LublinPoznańPoznańLublinRadom

CNR

C1C2C3C4C5C6

MIASTO

LublinPoznańRzeszówLublinPoznańLublin

DC

DNR

D1D1D1D1D1D1D2D2D3D4D4D4

CNR

C1C2C3C4C5C6C1C2C2C2C4C5

ILOŚĆ

300200400200100100300400200200300400

KOLOR

CzarwonyZielonyNiebieskiCzerwonyNiebieskiCzerwony

NAZWAC

NakrętkaWkrętPodkładkaNitNitTulejka

WAGA

121717141219 Baza danych zawiera wyłącznie

wartości. Interpretacja tych wartości jest poza bazą danych


Pasywna baza danych

Programy aplikacyjne......................

........................

Narzędzia i udogodnienia administratora bazy danych

Zapytania użytkowników ad hocGeneratory raportów

Baza danychDostawcy

Części

DC


Aktywna baza danych

Programy aplikacyjne..............................................

Narzędzia i udogodnienia administratora bazy danych

Zapytania użytkowników ad hocGeneratory raportów

Baza danych

Dostawcy

Części

DC

Elementy aktywne, uruchamiane automatycznie bez woli programisty.


Więzy integralności, asercje

SQL-92:CREATE TABLE table_name

row_1 ....,row_2 ....,....row_n,CONSTRAINT constraint_nameconstraint_definition ....

CREATE ASSERTION assertion_nameassertion_definition

CREATE ASSERTION maks_ilosc_czerwonychCHECK ( ( SELECT SUM (DC.ILOSC)

FROM DC, CZESC WHERE DC.CNR = CZESC.CNR AND CZESC.KOLOR = “czerwony”) < 5000 )

Asercja: maksymalna liczba czerwonych części nie powinna przekraczać 5000:

Problem: kiedy

sprawdzać zdarzenia i

asercje?


Reguły Event-Condition-Action (ECA)

Aktywne reguły (active rules) Byty programistyczne (zbudowane z sekwencji instrukcji) umieszczane w bazie danych, których uruchomienie jest powodowane spontanicznie (niezależnie od normalnego przebiegu sterowania programu aplikacyjnego) przez określone zdarzenia zachodzące w bazie danych, np. aktualizację pewnej danej, upłynięcie pewnego czasu, itp.

Aktywne reguły często przyjmują postać tzw. reguł ECA (Event-Condition-Action): akcja (action) jest podejmowana przez regułę wtedy, gdy zajdzie określone zdarzenie (event) oraz spełniony będzie określony warunek (condition). Aktywne reguły są często nazywane trygerami (triggers) lub regułami biznesu (business rules). Aktywne reguły są cechą wielu SZBD, w tym relacyjnych, obiektowo-relacyjnych i obiektowych. Istnieją również specjalne systemy zorientowane na tego typu reguły.

Filozofia aktywnych reguł wydaje się bardzo prosta, niemniej generują one dużą liczbę problemów, których rozwiązanie nie jest trywialne.

Manifest baz danych “trzeciej generacji” (Stonebraker et al) uważa aktywne reguły za pierwszorzędną cechę przyszłych systemów.


Przykładowe zastosowania aktywnych regułWymuszenie więzów integralnościowychNp. ktokolwiek może zmienic zarobek pracownika, ale aktywna reguła czuwa, aby nie był przekroczony budżet. W przypadku przekroczenia wyświetla komunikat i zrywa transakcję.

Wymuszanie aktualizacji redundantnych danych (Np. replik, materializowanych perspektyw, dwustronnych powiązań) Po aktualizacji pewnej danej następuje automatycznie aktualizacja jej kopii lub danej pochodnej. Po aktualizacji kopii następuje aktualizacja oryginału.

Monitorowanie operacjiCelem sporządzania raportów i przeciwdziałaniu nadużyciom informacje o niektórych ważnych operacjach są gromadzone w odpowiednich zbiorach. Np. dostęp do informacji o zarobu powodu zapis: kto, kiedy, co z tym zrobił.

Wymuszanie reguł prywatnościDostęp do pewnych danych powoduje uruchomienie akcji spradzającej, czy osoba ma do tego uprawnienia. Np. każdy może obejrzeć swoją wypłatę, ale nie może objrzeć cudzej.

Deaktualizacja informacjiWiele informacji traci ważność po pewnym czasie, np. prognoza pogody, notowania giełdowe, prawa użytkowania systemu, itd. Aktywna reguła może nie tylko deaktualizaować te dane, ale również je niszczyć celem nie doprowadzenia do przypadkowej dezinformacji.


Reguły w systemie Ingres• Są one zdefiniowane przy pomocy standardowych cech SQL oraz 4GL• Są zapamiętane w bazie danych• Dla kadej zapamiętanej tablicy można wprowadzić dowolną ilość reguł• Reguły są wykonywane automatycznie na podstawie warunków zachodzą- cych w bd, programista piszący program aplikacyjny nie musi ich uwzględniaæ w programie.• Wykonanie reguły może uruchomić inne reguły (tzw. forward-chaining); reguły mogą być wywołane rekurencyjnie.

Rodzaje reguł w systemie Ingres:

• Reguły “biznesu”, integralność wskaźników: np. jeżeli zapas części C3 jest mniejszy od 100, wyślij zamówienie• Kontrolowanie zużycia zasobów np. realizacja zapytania nie może trwaæ dłużej niż 5 minut; czas ten jest oszacowany przed przystąpieniem do wykonania zapytania• Kontrola dostępu do danych np. Kowalski należy do grupy dostępu G3, która ma dostęp tylko do tablicy DC.


Ingres: aktywne reguły

Zwiększają wydajność programisty oraz podwyższają niezawodnośćoprogramowania.

Programista przy programowaniu/modyfikowaniu aplikacji nie musipamiętać o konieczności uwzględnienia dodatkowych akcji.

Np. jeżeli stan zapasu części jest mniejszy od krytycznego, wyślij zamówienie:

ON UPDATE poz_zamowienia

IF poz_zamowienia.ilosc < :min_ilosc

THEN zamow( poz_zamowienia)

Stan lub zdarzenie:

Warunek:

Akcja:

Akcja jest procedurą zapisaną w SQL.Jest to kawałek programu (lub wołanie procedury), który każdy programistakażdej aplikacji musiałby powtórzyć, jeżeli tylko aktualizowałby zamówienie.


Ingres: zdarzenia wyzwalające aktywne reguły• akcje na wierszach tablic: insert (wstawianie), update (aktualizacja) lub delete (usuwanie)

• zmiana wartości w wyspecyfikowanej kolumnie tablicy - (update)

• jakakolwiek zmiana, która spełnia warunek nałożony na jedną lub więcej kolumn jakiejś tablicy

Do czego może się to przydać:

• Do wymuszenia integralności wskaźników: np. jeżeli dana pracownika zawiera numer działu, to taki dział musi istnieć w bazie danych• Do wymuszenia generalnej integralności: np. jeżeli dodamy nowego pracownika, to automatycznie jest dodawane 1 do danej zawierającej liczbę pracowników• Do wymuszenia reguł biznesu: np. jak w wyżej podanym przykładzie

Reguła jest nazwaną daną w bazie danych: może byæ utworzona, zmieniona i usunięta.


Reguły systemu PostgresZałóżmy, że ograniczenie mówi, że Nowak ma zarabiać tyle co Starszak:

on new PRACOWNIK.zarobekwhere PRACOWNIK.nazwisko = “Starszak”then do

replace P (zarobek = new.zarobek)from P in PRACOWNIKwhere P.nazwisko = “Nowak”

Dość niefortunna składnia, rezultat radosnej twórczosci inżynierów

Jeżeli aktualizowany jest zarobek (dowolny w ramach klasy) to: - zapamiętaj jego wartość pod zmienną new.- sprawdź, czy aktualizowany był zarobek pracownika o nazwisku Starszak

- jeżeli nie, to nic nie rób- jeżeli tak, to pod zarobek Nowaka podstaw zmienną new.

Wbrew pozorom, konsekwentne, logiczne i generalne ustawienie składni i semantyki tego rodzaju konstrukcji oraz pełne zintegrowanie ich z językiem zapytań nie jest sprawą prostą.


Reguły systemu Postgres -pozorowanie

on retrieve to PRACOWNIK.zarobekwhere PRACOWNIK.nazwisko = “Plaka”then do instead

retrieve (PRACOWNIK.zarobek)where PRACOWNIK.nazwisko = “Draka”

Jeżeli ktoś próbuje dostać się do zarobku Plaki,to zamiast zarobku Plaki dostaje na wyjściu zarobek Draki.

Metodę tę można także zastosować dla obliczania atrybutów wirtualnych:

on retrieve to PRACOWNIK.wiek....then do instead

retrieve ( BieżącyRok - PRACOWNIK.Rok_ur)

Tego rodzaju sztuczka może byc stosowana dla zmylenia hackerów.

Znowu, głównym problemem jest ustawienie modelu od strony syntaktycznej i semantycznej tak, aby model był prosty, ogólny i konsekwentny.

Dla języków zapytań jest to pewien problem: samo wyszukanie nie generuje zdarzenia. Jak i kiedy go generować?


Zdarzeniaevents

Zdarzeniem jest coś, co następuje w jednym punkcie czasowym (z punktuwidzenia naszej percepcji czasu) i warte jest analizowania z punktu widzenia celów projektowanego systemu informacyjnego. Samo zdarzenie nie trwa w czasie, ale fakt zaistnienia zdarzenia jest zarejestrowany i trwa aż do momentu, gdy jakiś podmiot go “skonsumuje”.

Np. zdarzeniem jest naciśnięcie przez użytkownika lewego klawisza myszy, lubodlot samolotu w dniu 20 stycznia 1997 o godz. 19:00 z Warszawy do Paryża.

Zdarzenia mogą być uporządkowane w czasie, ale możemy także rozpatrywać zdarzenia jak współbieżne. Zdarzenia mogą być grupowane w klasy i mogą im być przypisane atrybuty.

Zdarzenia warto rozpatrywać w okreslonym kontekście, np. czym innym będzie naciśnięcie klucza Esc jeżeli użytkownik ogląda Pomoc, a czym innym będzie w głównym menu.

Zwykle wystąpienie zdarzenia wywołuje pewną przyporzadkowaną mu akcję systemu,która najcześciej zmienia stan (obiektu lub sterowania).


Przykłady klas zdarzeń

samolot odlatuje( linia lotnicza, nr lotu, miasto )naciśnięty klawisz myszy ( klawisz, lokacja kursora ) wprowadzono ciąg znaków ( tekst )podniesiono słuchawkę telefonuwybrano cyfrę numeru telefonu (cyfra)obroty silnika wkroczyły w niebezpieczną strefę

Zdarzenia włączają błedy jako szczególny przypadek.Np.

silnik się zatarł, transakcja została zerwana, czas upłynął

są normalnymi wystąpieniami zdarzeń.


Generalizacja zdarzeńZdarzenia mogą być traktowane jak obiekty, ewentualnie z atrybutami.

zdarzenieczasZdarzenia

związane zakcjami użytkownika: info_wejściowe

urządzenie

klik_klawisza_myszylokalizacja

naciśnięcie_klawisza_klawiaturykod_znaku

naciśnięcie_klawisza_myszy

puszczenie_klawisza_myszy

sterujący znakowy

spacja alfanumeryczny interpunkcyjny


Zdarzenia jako byt systemowyCzęść zdarzeń w systemie należy “wszyć” w system jako zdarzenia elementarne:

- nastąpił pewien moment czasowy (zadzwonił budzik)- naciśnięcie klawisza myszy- wprowadzenie nowego obiektu- początek/koniec transakcji- aktualizacja danej....

Zdarzenia złożone można komponować ze zdarzeń elementarnych (algebra zdarzeń?):- po naciśnięciu klawisza myszy w ciągu 0.2 sek nastąpiło drugie naciśnięcie - po tym jak zadzwonił budzik nastąpiło wczytanie danej- akcje firmy spadły 3 razy w ciągu tygodnia na łączną sumę ponad 100$

Programista ma mozliwość generowania zdarzeń przy pomocy specjalnych instrukcji.Jeżeli do tego ma możliwość testowania wystąpienia zdarzeń (elementarnych i złożonych), wówczas ma możliwość dowolnego ustawiania zdarzeń złożonych przy pomocy klasycznych instrukcji języka programowania.

Zdarzenie ma określoną nazwę poprzez którą jest identyfikowane w systemie.Zdarzenie może mieć parametry, a raczej może być obiektem o dowolnej budowie.

Zdarzenia są rejestrowane w specjalnym rejestrze zdarzeń (kontenerze).


Klasa jako miejsce przechowywania reguł

Wśród tych cech najważniejszymi są:

Typ, czyli statyczna budowa obiektu (atrybuty)Metody, czyli operacje, które można wykonać na obiekcie

Klasa jest miejscem przechowywania takich cech obiektów, które są dla nich niezmienne lub wspólne, czyli ich inwariantów.

Inwarianty dotyczące jednego obiektu mogą być przechowywane w wielu klasach.

Obiekt, który jest podłączony do danej klasy przechowującej jego inwarianty, jest nazywany wystąpieniem lub członkiem tej klasy.

Ale oczywiście, możliwe jest bardzo wiele innych inwariantów....


Inne inwarianty klasyNazwa, czyli językowy identyfikator obiektuPowiązania, asocjacje obiektów danej klasy z obiektami tej lub innej klasyWartości wspólne dla wszystkich obiektów danej klasy (stałe)Informacja o wartościach zerowych (niekiedy jest składnikiem typu)Wartości domyślne używane w momencie tworzenia nowego obiektuZdarzenia lub wyjątki, które mogą zajść w operacjach na obiekcieObsługa zdarzeń lub wyjątkówLista eksportowa, określająca, które atrybuty dostępne są z zewnątrzLista importowa określająca obiekty innych klas któe są dostępneOgraniczenia, więzy integralności, którym musi podlegać każdy obiektAtrybuty wyliczalne wraz z ich algorytmamiIkony do reprezentacji graficznejReguły bezpieczeństwa i prywatności Informacje katalogowe, pomoceFizyczne własności obiektów: reprezentacja metody dostępu,...

Wśród tych inwariantów są również różnorodne reguły.Zasada: chociaż te inwarianty są przechowywane w ramach klasy, są one właściwe dla obiektów danej klasy (tak, jakby siedziały w ich środku).


Sformułowanie problemu

Środowisko

zdarzenie

zdarzenie

zdarzenie

zdarzenie

zdarzenie

zdarzenie

zdarzenie

zdarzenie

Konsument

Konsument

Zdarzenie “wlatuje” do pewnego środowiska i trwa w nim dopóki jakiś “konsument” go nie skonsumuje. Po konsumpcji, konsument podejmuje akcję.


Klasyfikacja zdarzeń i reakcji na zdarzeniaZdarzenie zachodzi w ramach:

klasy obiektu środowiska bd

Reakcja na zdarzenie

znajduje się w ramach:

klasy

obiektu

środowiskabd

Skopiować reakcję z klasy do obiektu

i uruchomić

Uruchomić

Skopiować reakcję z klasy do obiektu

i uruchomić???

??? Uruchomić

Uruchomić Uruchomić Uruchomić


Migracja zdarzeńJeżeli zdarzenie pojawiło się w danym środowisku, to:

Może być w tym środowisku przechwycone przez obsługę i zjedzone

Może być w tym środowisku przechwycone przez obsługę, ale nie zjedzone.W takiej sytuacji jest przekazywane do bardziej szerokiego środowiska.

W danym srodowisku może nie być obsługi danego zdarzenie; w takiej sytuacji zdarzenie ginie

W danym srodowisku może nie być obsługi danego zdarzenie; w takiej sytuacji zdarzenie przelatuje dalej, do bardziej ogólnego środowiska

Programista może zadecydować co ma zrobić z danym zdarzeniem: zjeść, nie zjeść, prekazać do innego.

Np. zdarzeniem jest aktualizacja zarobku pracownika Kowalskiego.Jeżeli obiekt Kowalskiego lub klasa PRACOWNIK zawiera obsługę tego zdarzenia,to wchodzimy w tę obsługę; zdarzenie jest zjadaneJeżeli takiej obsługi nie ma, to zdarzenie wlatuje do środowiska bazy danych, gdzie również może znajdować się obsługa tego zdarzenia.


Aktywne reguły a transakcjeProblem: jeżeli programista okreslił granice jakiejś transakcji, to jak należy traktować operacje wyzwalana przez aktywne reguły w ramach tej transakcji?

Zwrócimy uwagę, że programista może nic nie wiedzieć o wyzwalanych regułach. Ponadto, może nam zależeć na tym, aby w przypadku zerwania transakcji nie cofać akcji wykonanych przez aktywne reguły (np. w celu monitorowania prób zmiany danych).Wykonanie może więc być:

Natychmiastowe: w momencie wyzwolenia reguły następuje zawieszenie transakcji aż do zakończenia działania reguły.Opóźnione: reguła jest wyzwalana wtedy, jeżeli transakcja dochodzi do potwierdzenia, jako pod-transakcja. Ostateczne potwierdzenie następuje po zakończeniu działania reguły/reguł.Rozdzielone: reguła startuje nową transakcję, rozdzieloną w stosunku do poprzedniejPrzyczynowo-skutkowe: reguła jest wykonywana jako nowa transakcja wyzwalana w momencie zakończenia właściwej. W przypadku zerwania tej nowej transakcji, zrywana jest także właściwa transakcja.

Podstawowy problem: gdzie i jak zawrzeć informację o tym w jakim stosunku do transakcji pozostają wyzwalane reguły? Przy transakcji? Przy regule? Oddzielnie?


Trwałe wątkiEwolucja w myśleniu o danych i obiektach:

1 generacja: dane pasywne wewnątrz danej złożonej (Kowalski, Jan, 1944, 2500)

2 generacja: dana złożona może także składać się z kodów procedur (metod)

3 generacja: dana złożona może także zawierać wątki, czyli kawałki programu, które nie tylko siedzą wewnątrz danej złożonej, ale także bez przerwy się wykonują.

persistent threads

Trwałe wątki szczególnie trudno sobie wyobrazić, jeżeli obiekt w którym znajduje się taki wątek siedzi na dysku (jak może taki watek działać, jeżeli jest po prostu na trwale zapamiętany). Okazuje się jednak, sprawa jest implementowalna: obiekt jest ściągany do bufora w RAM jeżeli cokolwiek z nim się dzieje (np. aktualizuje). Natychmiast po ściągnięciu uruchamia się wątek od stanu, w którym on był w momencie zapamietywania na dysk. Z punktu widzenia programisty taki wątek działa cały czas.

Trwałe wątki pozwalają na uzyskanie znacznie więcej mozliwości, niż dają reguły ECA. Mogą one na bieżąco monitorować stan obiektu, np. unieważniać informację po pewnym czasie (np. o notowaniach giełdowych), reagować na zmiany, przywracać stan,...

Zaimplementowane w systemie TYCOON. W tej chwili trwają prace w tym zakresie w ramach Persistent Java (Pjama).


Trzy podejścia do obsługi zdarzeń1. Wyjątki: ADA, OMG CORBA, ODMG,....

Specjalne byty programistyczne umożliwiające przekazanie sterowania do zdefiniowanego fragmentu programu po wystąpieniu błędu. Jest to “goto”, które ma zdolność przekraczania reguł zakresu. Zwija stos i nie umożliwia powrotu do stanu sprzed wystąpienia wyjątku.

2. Programowanie zdarzenioweProgram jest zorganizowany w formie bloków reakcji na pojawiające się zdarzenia. Niezwykle użyteczne dla programowania wizyjnego.

3. Aktywne możliwości w bazach danych (tryggery)

Baza danych zawiera trwałe bloki, które reagują na zdarzenia.

We wszystkich wymienionych przypadkach jest ta sama sytuacja:- pojawiają się zdarzenia/wyjątki- sterowanie jest przekazywane do bloku programu, który ma obsłużyć to zdarzenie

Wyjątki nie zakładają asynchroniczności, jest to prawie czyste gotoW pozostałych przypadkach można założyc współbieżność, chociaż jest to problem


Ingres 4GL - programowanie zdarzenioweInicjalizacja ramki: initialize( i = integer;) =

begin i = 1; end;

Czytanie tablicy dostawcy po kliknięciu myszą guzika “Czytaj”;ten kawałek progrmu może być podwiązany bezpośrednio do tego guzika:

on click =begin i = 1; select wynik[i].dnr = DOSTAWCA.DNR, wynik[i].nazw = DOSTAWCA.NAZW from DOSTAWCA where MIASTO = :miasto; begin i = i+1; end;end;


ZZ

Z

Zdarzenia, reakcje na zdarzenia, i inne elementy środowiska

Trwałe środowiska: aktywne reguły, trwałe wątkiUlotne środowiska: wyjątki, programowanie zdarzeniowe

Dana

Dane(obiekty)

Dana

DanaAkt.reguła

Typ ProceduraProcedura

Procedura

Środowisko

Akt.reguła


Podsumowanie

Reguły, szczególnie aktywne są bardzo ważnym dodatkiem do obiektowych baz danychProblem jest jednak w dużym stopniu ortogonalny w stosunku do obiektowości

Aktywne reguły mają dość istotne asocjacje z programowaniem zdarzeniowym

Pewnym problemem badawczym (moim zdaniem nierozwiązanym) jest ustawienie zarówno programowania zdarzeniowaego jak i aktywnych reguł w ramach spójnego systemu opartego o zintegrowny język zapytań i programowania

Powiązanie aktywnych reguł z przetwarzaniem transakcji jest problemem

Powiązanie aktywnych reguł z asynchronicznym przetwarzaniem jest problemem

Migracja, rejestracja i reguły zakresu dla zdarzeń tworzą pewien problem

Trwałe wątki są bardzo ciekawą koncepcją, która daje nadzieje na opanowanie problemu w sposób generalny.

Aktywne reguły w systemach obiektowych (i nie tylko)

Documents

Transcript of Aktywne reguły w systemach obiektowych (i nie tylko)