高等資料庫
高等資料庫
主動式資料庫
ACTIVE DATABASE
指導老師：陳彥良教授
學生：曾弘彰修訂
目錄
壹‧概論 2
貳‧定義 5
參‧架構 7
3.1信息庫(Depository) 7
架構(Architecture)9
肆‧條例語言的模式 11
事件(Event) 12
情境(Condition) 14
處理(Action) 15
參數繫結(Event-Condition-Action Binding) 16
條例的次序(Rule Ordering) 18
條例執行語意 19
5.1 Ariel 20
Postgres 22
Starburst 23
SQL2 and SQL3 24
HiPAC25
錯誤復原(Error Recovery)28
一些問題的討論 29
結論 33
參考文獻 35
壹.概論
以資料為中心，將應用程式所需的資料，以最佳的形式組織在一起，在資料庫管理系統(Data Base Management)控制下，達到減少資料複雜性、達成資料的一致性、獨立性、資料共享及統一管理的特性，這就是我們傳統的資料庫。傳統式資料庫，如下圖一所示：它是被動式的(passive)，也就是說:除非在使用者下達命令或是應用程式明確的提出要求時，才依指令執行查詢或是交易處理，否則它不會主動幫我們做任何事的。以資料庫觀點而言，使用者、應用程式、作業系統軟體等都是外部的事物，這些處理的程序或邏輯都是儲存在應用程式子系統(application subsystem)中。
ap program
DML
DBMS OS 人事資料庫
DDL 會計資料庫
tools & utility
圖一. 傳統式資料庫的使用
在某些情況下，例如存貨控制系統資料庫必須監視存貨量是否低於安全庫存量，若是低於安全庫存量，則必須做適時的自動執行定貨處理。而傳統資料庫要做到上述的功能時，有兩種作法：
將檢查與更新資料庫的動作放在一個程式內，每當更新的動作執行時，同時檢查庫存量等情況，以便決定是否需要進行其他的處理。
每隔一段固定時間，對資料庫的狀態作檢查與處理。
這兩種方法都是利用外部程式的做法。然而，這兩種情況都可能產生在前後兩次檢查間有一些狀況沒有檢查到，而沒有進行到該處理的訂貨程序：第一種的情況下，可能有另外一個外部程式進行更新而使資料庫已經呈現需適時需要處理的狀態，但是當這個更新程式尚未執行前，這個狀態不會被檢查是否成立，必須等到它執行時才會進行檢查與處理。而第二種情況下，除了兩個檢查間有未檢查到的問題外，如果進行檢查的的間隔期間太短亦會有效率的問題，太長則又容易使沒檢查到的狀況機會增多。
主動式資料庫（Active Database System），經由使用者的設定後，會隨時監視資料庫的狀態，一但有預期的狀況發生時，會提出警告以防止意外情況發生，或系統適時的作出反應。其處理方式如圖二所示:
ap program
DML 伴隨
DBMS OS 人事資料庫active
DB
DDL 會計資料庫component
tools & utility
圖二. 主動式資料庫的使用
它與傳統式料庫主要的差別在於：
1. 將處理程序與邏輯儲存在資料庫裡，而不是儲存在應用程式子系統中，它是伴隨著表格或物件（object）存在的，或者是伴隨著整個資料庫環境的。（所謂的伴隨，是指宣告於或者作用於哪些物件或表格上）
2. 這些處理程序的啟動是由資料庫管理系統內部的監控機制(DBMS-based)來啟動、控制與管理，而不是由外部程式來進行。
3. 這些處理程序的啟動，根據事先指定事件的發生而啟動。
在主動式資料庫中，這些處理程序以及檢查的動作通常以事件處理條例(production rule 或稱為event-condition-action rule 簡稱ECA-rule）來表示，這些規則儲存在資料庫系統中，而且可以由不同的應用程式共同使用。
這些事件處理條例經由「資料庫操作」的事件、「資料庫狀態」的發生或「狀態間的轉變」三種型態的事件（event）來激發，然後檢查條例中的情境（condition）是否發生，若是符合情境者則執行處理（action）。事件處理條例的定義儲存在資料庫中，並且由資料庫系統來執行，執行的過程也都受到資料庫系統的所有權控制（authorization control）、並行控制（concurrency control）與復原處理（recovery）。系統隨時偵測發生的事件，對於發生的事件會通知對應的事件處理條例進行處理，我們稱這個動作為『發信』signaling 。發信之後，這些對應的事件處理條例就被『激發』triggered (or fired)，接著會被『執行』executed。事件處理條例的執行包含兩個動作，情境的衡量以及對應的處理。事件處理條例被激發之後，先衡量情境是否符合，若是符合者則進行對應處理。
這種處理的觀念來自於人工智慧系統（Artificial Intelligence），與人工智慧系統不同的是它不是利用循環式固定週期inference engine來檢查事件或情境，而是根據事件的發生而進行檢查。而主動式資料庫的事件處理條例使得資料庫系統有一個強有力的機制來執行一些有用的工作：如完整性限制（integrity constraints）、存取限制（access constraints）、版本控制（version control）、提供資料庫重整（database reorganization）或查詢最佳化（query optimization）所需要的統計資訊、執行激發與警示機制（triggers and alters）等等。
另一方面，由於事件處理條例的推論能力，主動式資料庫系統非常適合建立大型的、有效率的知識資料庫（knowledge-base）及專家系統(expert system)；因此，Active database有時亦稱為Expert Database(專家資料庫)。
主動式資料庫的應用有：網路管理(network management)、電腦整合製造(computer integrated manufacturing)、工程設計(engineer design)及監督資料庫狀態等。
貳.定義
對於主動式資料庫,可以用最完整的語意來充分表達,使其具有明確的定義。
一.基本上它是個完整的資料庫
因為具備了有傳統式資料庫的建立檔案，資料插入，資料擷取，查詢語言等功能。
二.具備有ECA-Rule的模式
由於它擴充了傳統式資料庫的反應行為,而這些行為即能依使用者的命令去執行,使資料庫能主動的行為出現,而這些方法,謂之ECA-Rule模式。
ECA-Rule模式,有下列的描述予以組成:
.事件(event)
事件的形態描述，有基本型(primitive)與複合型(composite)的型態，如資料項目異動、資料的擷取、資料的結合(conjunction)等，但不論是何者，皆有
before和after對事件發生時的指定。
當事件發生時，對於該事件有兩個重要的屬性，即：
.事件型態(event type)：記錄該事件屬於哪一個型態。
.事件時間(timestamp)：記錄該事件發生的正確時間。
情境(condition)
當事件發生後，則情境必須去檢查其是否合乎於條件，若資料庫的狀態符合情境的定義，則進行處理。再者，情境也可以是一個查詢的指令，依查詢結果決定是否符合情境的預測。
處理(action)
合乎情境的檢查後，即進行各種指令的執行，如資料的異動、資料的檢索、程序的呼叫等。
三.條例必須有信息庫(depository)的管理
將所有的條例集合起來，即成為一個條例庫(rule base)。對於條例庫，我們可以將其視為信息庫(Depository)的一部份(對於信息庫，在3.1有介紹)。即是主動式資料庫的子集合。
四.要能解釋為什麼(why)
在主動式資料庫而言，這是協助使用者，為了瞭解與追蹤系統的執行運作行為，以避免在主動式環境中發生一些無法預期的行為。因此，面對此情形，我們必須要能解釋其發生的行為。
因此，綜上所述，我們可以用下面的語句來定義主動式資料庫。『主動式資料庫是具備有事件-情境-處理的條例模式。並經由條例的激發，至信息庫尋找適當的工具，配合其執行結果是能預測且解釋的資料庫』。
我們可以用下面圖三，說明主動式的執行過程。
EVENT CONDITION ACTION
更新顯示狀態
庫存報表Active Database 重新整理
event ：更新庫存
condition ：目前庫存—提貨數量< 安全存量
action ：重新整理且訂貨
圖三主動式資料庫執行範例
參.架構
3.1信息庫(Depository)
在早期電腦輔助軟體工程中，文件的管理大多使用檔案予以管理及貯存；而如今，演變至今對所有資料文件而言，是由一個邏輯一致性和非多餘性且集中式的方式所貯存，這即所謂信息庫(Depository)。這種的步驟，我們可以稱之為文件整合(Document Integrated)。對CASE(Computer Aided Software Engineering)而言，信息庫是它的核心所在，它能貯存並組織所有軟體開發過程中所需的資訊。這些資訊包括企業經營的結構、系統開發程序、資料結構、處理邏輯、專案管理資料等。一個理想的信息庫，可以連結資料庫應用軟體裡面的資料辭典。
這些架構集合資料定義和處理語言，都是以標準介面存在，因此我們必須考慮CASE工具的整合使用。對所有的文件而言，貯存在信息庫都是以簡單、可擴充的架構方式存在。
現在，我們將主動式(或稱之為自動式)的方法，加入信息庫中，使其能成為主動式信息庫(Active Depository)如圖四。因而，主動式信息庫能夠偵測各種事件激發的情境，並且自動地為事件描述並選擇合適的處理模式。為了讓主動式信息庫能夠自動配合事件的激發，情境的控制及行動的處理執行，在主動式信息庫，配合有下面數點：
.有共同的軟體處理模式，
.每個專案均有其適當的軟體模式，
.在可行的主動式中，各種狀態需建立在信息庫，
.配合CASE工具能執行處理，或必要的行動。
user signal system others
Depository
主動式(CASE tool)
信息庫
激發
ECA-rule
Database
圖四主動式信息庫示意圖
因此，一個主動式信息庫中，有兩個重要性：
一個信息庫，在傳統來說是個軟體企劃、專案的所有文件資料貯存的地方。
當一個事件狀態發生時，配合情境的控制和適當的處理及激發適當的CASE工具，作最合宜的處理。
3.2.架構
前一節談到了信息庫，它在主動式資料庫佔了非常重要的角色。
我們在傳統式的資料庫裡，增加也增強了對事件的偵查、情境的監督及執行交易的處理。另外，我們可藉由某些介面、工具，經適當的條例去access資料庫，當資料庫的條件合乎我們在條例中設定時，即激發出適當的訊號提醒我們。遂因此，我們將上一節談到的主動信息庫予以擴充，提出一個主動式資料庫的架構，如圖五所示。
USER
Depository (CASE tool)
Storage 、Analysis
Extended Transaction Management
ECA-rule Management
Inter Application Management
Database
圖五主動式資料庫架構圖
在此架構中，主動式資料庫是由三部份組成：
第一部份是信息庫：是個軟體企劃、專案的所有文件資料貯存、CASE工具使用及分析資料及之處，產生下個階段的執行碼，或參考文件和建立一個品質保證的報表，該層可將其視為應用層。
第二部份因它有著自動支援，為符合這些規劃去主動執行，因此，它應有支援事件執行交易管理、ECA條例管理及內部通訊支援管理的所在，該層可將其視為執行層。
第三部份則為傳統式的資料庫，可視為資料庫層。
綜合而論，即是將主動式信息庫，加上資料的分析、事件執行交易管理、內部通訊支援管理，和傳統式資料庫即成為主動式資料庫。所以此資料庫有三層，因此，該資料庫可以說它是個階層式整合的資料庫。
肆.條例語言的模式
在不同的資料庫系統中，有不同的資料模式，也就有不同的條例語言。如關連式資料庫中，條例語言定義在Schema中，並伴隨著table、view及integrity constraints；此外，對資料及操作有add、drop或modify的條例。又如物件導向資料庫中，是以條例形式物件定義在schema中，條件的組成結構有events、conditions及actions，和其它物件一樣，能被created、deleted或modified，及fire、enable、disable的特別操作。
對於主動式資料庫，必須有條例語言去定義才可執行。廣義的說，只要符合“將處理程序與邏輯儲存在資料庫本身”的定義，皆可稱之，如constraints、assertions、procedures等；狹義的說，“必須是使用於主動式資料庫中”的定義，皆可稱之，如event、condition、action等。我們現在可以將ECA-rule事件處理條例定義如下：
on event
if condition
do actions
舉例如：
on start
if task_done( )
do update_worklist( )
是說「開始某個操作，當此操作結束的時候，就更新工作清單。」
本篇是介紹主動式資料庫，因此只對event、condition、action的模式說明。
4.1事件（EVENT）
所有的主動式資料庫系統的條例，都是藉由資料庫的定義，明確或不明確地被激發執行。在關連式資料庫中，激發“insert 一筆資料到employee 表格中”的事件表示法，如下例一:
define rule MonitorNewEmps
on insert to employee
if ...
then ...
例一關連式資料庫中的表示法
在物件式資料庫中，當啟動employee類別的salary-raise物件時，即產生激發事件(salary-raise物件是定義在employ類中)，如下例二
define rule CheckRaises
on employee.salary-raise()
if ...
then ...
例二物件導向資料庫中的表示法
有一些條例語言也允許激發事件是對資料的取用，如下例三：
define rule MonitorSalAcess
on retrieve salary
from employee
if ...
then ...
例三對資料取用的激發事件
其他語言還提供的激發事件有commit, abort, prepare-to-commit 等。此外，尚有一些時間性事件(temporal event)，它有三種激發形式：
絕對時間(absolute):在某個時刻激發；
2.相對時間(relative):在處理發生後的某個時刻激發；及
週期時間(periodic):固定一段時間激發。
有些語言還可以將這些激發事件混合在同一個條例宣告裡，或是在事件、情境與處理間可以有參數的傳遞（大部份是物件導向資料庫）。
一般而言，物件導向式資料庫在激發事件定義上提供較強的功能，這是因為它將事件處理條件當成物件來處理的關係。因為主動式資料庫目前有許多標準還沒有定義出來，而且條例語言受到資料庫型態（關連式或階層式或物件導向式）的影響而有所不同，特別是激發事件的定義，因此各家語言都提供許多不同的特性。
4.2情境(condition)
情境定義可以是對資料庫狀態的一個預測，或是一個對資料庫的查詢；當預測的狀態成立或是查詢結果不是空值時，情境就會成真而啟動處理程序。感覺上，事件與情境很相似，但事實不然。情境通常是一個需要評估的資料庫狀態或查詢，需要藉由評估來決定真偽。
有時某一些情形下，激發事件的發生幾乎使得情境必然成立，此時情境的判斷可以忽略而直接啟動處理。
有許多的條例語言允許情境的判定是去比較某一個處理前後資料庫狀態的差別，通常這一類的情境我們稱之為transition conditions。例如以下的例子：
define rule MonitorRaise
on update to employee.salary
if employee.salary > 1.1 ＊old employee.salary
then ...
例四、transition conditions
if 子句部份就是情境的定義，是一個邏輯子句。因為資料庫的狀態的改變通常是伴隨著某些資料庫的操作，因此有些語言如Ariel ，對於觸動事件的宣告可以忽略而直接由情境條件來判定是否啟動處理程序。
4.3處理(action)
處理程序是當激發事件發生且情境成立時，所要執行的一些操作。不同的語言所提供的處理程序有所不同，如SQL2 裡處理程序只能針對目前的交易作處理，而SQL3 則可以是對資料庫裡任何資料作處理或查詢。
以下是一個是範例：
define rule FavorNewEmps
on insert to employee
then delete employee e where e.employee = employee.name
例五
當新增一筆employee 記錄時，要將目前記錄中所有跟新增的記錄之姓名相同者刪除。在Postgres中，它的條例的處理可能會用上的是「instead」關鍵字，去代替激發。
4.4參數繫結(event-condition-action binding)
在人工智慧系統的條例語言中，符合條例情境的資料與條例處理之間有連結的存在。如OPS5 ，每當條例執行的時候，在情境內的變數會繫結到那些工作暫存區中符合情境的資料上，然後這些變數會傳遞到處理中。
因為資料庫系統的條例語言可以明確的指定事件，而且也比OPS5 有更多的不同的情境與處理，因此繫結的概念更為複雜。在HiPAC 物件資料庫中，激發條例的事件可以給予參數，這些參數可以被條例中的情境與處理參用。例如，有一條例被Salary-raise(e:employee , oldsal:integer , newsal:integer)所激發，在情境與處理中，e 是代表其方法被啟動的物件employee，而oldsal 與newsal 則是用來代表事件發生的整數數字。對於混合事件，這些參數將會被累積，再pass到情境和處理。例如，對Salary-raise(e:employee , oldsal:integer , newsal:integer) 重複啟動時，每一次的啟動都會有三元一組（e , oldsal , newsal）的值來代表不同的啟動。再HiPAC 的條例情境部份可以宣告成一個查詢動作，而這個查詢的結果是可以透過繫結讓處理來參用的。
在SQL2/SQL3 ，Ariel ，Postgres ，Starburst 等系統中，條例的激發是由insertion ，deletion ，或update 某一個表格而來的。因此，這些系統都會有一種方法讓情境與處理可以參用這些被inserted，deleted，updated 的值組。
在SQL2/SQL3 ，Ariel 中，當一個條例被某表格的異動而激發時，在情境與處理部份對表格值組的參用只能是那些將要更動的值組。如例六中SQL3 的例子：
create trigger DeptDel
before delete on department
when edepartment.budget < 100,000
delete employee when employee.dno = department.dno
例六
這一個條例是被表格department 的刪除動作所啟動的，而情境與處理部份所參用的department 是指將要被刪除的那個值組。更動前與更動後的值組也可以被參用，如同例四。SQL2 使用關鍵字old 與new 來區別更動前與更動後的值組，SQL3 則允許在條例宣告中定義特別的名詞代表新、舊值組來讓情境與處理參用。
在Ariel 裡，舊值是由關鍵字previous 來代表。而要被更動的整個表格也都可以被情境與處理參用，不限於只是那些被更動的值組。它是利用值組變數或是同義字的方式來達到的，如例五。
在Postgres 中，事件與情境的參用是更動的值組，而在處理中變數所參用的是指整個表格。為了能夠參用值組的新、舊值，Postgres 以特別的值組變數new 與old 來代表，如例五的內容改用Postgres 的語法則為下面的例七：
define rule FavorNewEmps
on append to department
then delete employee where employee.name = new.name
例七
在Starburst 中，一個條例的激發可能牽涉到表格中的一群inserted , deleted 與updated 值組（將在條例執行語意中提到），它則利用中間表格(transition tables)的方式來參用。中間表格是一個邏輯的表格，與實際的表格一樣可以拿來參用。在條例的執行期間，中間表格inserted 是表示那些因新增後而激發條例的值組集合，deleted 是表示那些刪除掉後會激發條例的值組集合；new-updated 與old-updated 則是代表那些因修改而激發條例的值組集合之新值與舊值。如下列的例子，當修改的職員薪水平均超過100 時就取消整個交易。
define rule AvgTooBig
on update to employee.salary
if (select avg(salary) from new-updated) > 100
then rollback
例八
4.5條例的次序(rule ordering)
在SQL2 與SQL3 中不允許有兩個以上的條例有相同的的激發事件宣告，因此不需要有衝突的解決問題。然而大部分的主動式資料庫在處理同時有兩個以上條例被激發的情況時，並不像SQL2 與SQL3 一樣有如此嚴謹的作法，在選擇要執行哪一個被激發條例時多少是有一點隨意的。
Postgres 曾考慮過許多方法，如數值權重（numeric priorities）與互斥架構（exception hierarchies），但是到今天為止這些方法都還沒有被Postgres 使用。
Starburst 使用的是部份排序（partially ordered）；當兩個條例有並行的衝突時，只須決定兩兩之間的優先順序，而不必考慮所有條例的順序排列。
Ariel 中，則利用數值權重的方式。每一個條例會被賦予一個介於－1000 到1000 間的浮點數值，如果一個條例沒有被賦予此值時，系統將會自動賦予初始值0。
HiPAC 與前述的系統都不一樣，它將同時被激發的條例以並行的方式處理。即使如此，HiPAC 也有一套相對次序的處理原則，來決定並行處理時的連續順序（serialization order）。
伍.條例執行語意
一個資料庫條例語言的語意，是用來決定條例在資料庫執行期間如何運作，同時也決定了條例與任意的資料庫操作、交易之間相互作用；即使是只有一群很少的條例，條例的執行也是相當複雜且難以預料的，因此一個嚴謹的語意執行模式(rule execution model)是相當重要的。主動式資料庫的條例處理必須與傳統的資料庫活動整合，這些活動如查詢(query)、更改(modification)與交易(transaction)，而這些活動正是造成條例被激發的動力。
對於一個條例語言本身來說，許多條例執行方式有不同的選擇，而現行的系統中，各系統的語意也有相當多的差異。有以下的考慮：
粒子性(granularity)：因為大部分的資料庫語言的工作單位都是以值組群的方式，因此就必須決定要在單筆值組更動完成或是在整個值組群更動後，甚至是在整個交易完成之後才激發。
衝突解決：是否有兩個以上的條例被同一個事件激發？一些語言不允許此種情形，但另一些則可以。如果允許的話，在同時間內，是用某種解決衝突的演算法去安排條例順序執行的次序，或者條例皆能併行執行。
範圍限制：條例的執行與使用者的交易之間的交互作用也是一個問題，一些條例的執行範圍是在引起激發的交易裡面，也就是激發事件發生的交易內；而有一些系統則允許更有彈性的範圍限制。
在這一章裡，我們以Ariel , Postgres 、Starburst、SQL2 與SQL3及HiPAC ；來看看這些資料庫如何在粒子性、衝突解決、範圍限制等方面處理條例的執行。另外也簡略的提及在條例執行時的錯誤復原的問題。
5.1 Ariel
在Ariel 中，條例是被狀態轉變(transition)所激發的，狀態的轉變是由一個單一的資料庫命令或是命令集對資料庫的更動所造成。因為在一般關連式系統中，如Ariel，一個單一的的資料庫命令(insert ,delete , update)是所謂的值組群導向(set-oriented)，因此其條例處理的粒子性最小的單位是值組群；而一群指令集可以構成一個交易，但是同一個指令不可以身跨兩個交易以上，因此其最大的粒子性單位為整個交易。條例的執行是在狀態轉變完成之後啟動，並且被當成是交易的一部份來執行。當條例執行開始時，Ariel 使用一個類似人工智慧系統條例語言的循環式inference engine 來進行。
Ariel 的條例處理部份可以參用那些因更動而激發條例的資料，而Ariel 的條例是被一群changes 而激發的，因此這些資料參用的繫結應該是以值組群為單位的，而不是以單一值組的方式。如例九：
define rule MonitorNewBobs
on insert to employee
if employee.name = "Bob"
then retrieve employee
例九
在上例中，如果employee 表格被新增一群值組，這個條例的處理會取回這些新增值組的名字為Bob 者；employee.name 的繫結就是針對所有新增的值組。
範圍模式方面，在Ariel 中是允許巢狀激發的，一個條例處理所引發的轉變可以造成對自己或是其他條例的激發；也就是說每一個條例所造成的轉變，對往後的條例而言都是看的見的。如果條例中執行到了rollback ，那整個巢狀激發的連鎖會被中止，並且結束整個交易。
Ariel 的條例是在狀態完成後才開始處理的，因此它只考慮狀態轉變的最終的影響，而不是中間過程的所有轉變。大部分的情況下，淨改變值的影響會如同一個單一的更改。在一個狀態轉變中，如果一個值組被更新過好幾次，最後的淨影響(net effect)是一次的更新；如果值組被更新而後刪除，其淨影響只是一次的刪除。若一個值組被新增然後更新，它的淨改變值只是新增一筆值組（內容為更新後的資料）；如果一筆值組被新增然後刪除，則等於沒有淨影響。這些淨影響將會是條例事件與情境在判斷是否符合的依據。
衝突解決問題，Ariel 對於每一個條例都指派一個數值權重，這個數值可以是相同的。因此，當有數個條例同時被激發時，Ariel會以下列的演算法來解決衝突：
1. 先找權重值最高者。
2. 如果相同，選擇前一次激發的時間最接近目前時間者。
3. 如果還相同，選擇情境是更細、更具體者。
4. 如果再相同，則採用隨機的方式。
5.2 Postgres
在Postgres的粒子性中，條例的執行是在任何的單一值組被更動過而激發且滿足情境時就進行。這種方式叫做值組導向條例執行（tuple-oriented），與Ariel 的set-oriected 的方式剛好相反。
在Postgres 中條例的範圍處理可以是任何的資料庫操作，因此當一個條例被執行時，它可能也因而更動了其他多筆的值組，每一筆值組也都可能因此激發了其他的條例。所以Postgres 的條例處理天生就是遞迴性與即時性（立刻執行）的，而不像Ariel 是根據狀態轉變的淨影響。
Postgres 對條例執行的演算法如下：
1. 有些值組因使用者或條例而異動。
2. 這些異動激發了條例且滿足了條例的情境。
（假設有R1, R2,....,Rn）
3. 對於每一個Ri，執行Ri 的處理。
如前面所提，處理的部份可能引起其他值組的異動而造成連鎖反應。在Postgres 裡是沒有衝突解決的機制的，被啟動的條例是以隨機的次序來執行的。如果一個條例的處理執行了rollback 時，條例的執行與整個交易都會被取消。
5.3 Starburst
在Startburst 裡，條例的執行是在每一個交易完成後啟動的；此外，使用者可以在交易中指定一個特別的指令來引發條例的執行。因此，如同Ariel 一樣其最小的粒子性是單一的關連式命令（值組群為單位），最大的粒子性單位為一個單一交易。
Starburst 的條例可以因為insert , delete , 或者update 而激發，當一個條例在交易中第一次被激發時，它所評估的狀態是從交易開始以來的所有異動，包括由使用者或是其他條例所造成的異動結果；如果條例在交易中是第二次以上被觸動時，它所考慮的異動則是從它前一次被激發後到目前的異動狀況。Starburst 也像Ariel 一樣，考慮的是淨影響，而不是異動過程的轉變。
Starburst 也和Ariel 一樣使用類似的人工智慧系統的inference engine，在每一次的循環中，只找出被激發的條例而暫時未去評估其情境是否符合。情境的評估要到所有考慮的條例都挑出時才去決定。
對於衝突解決，Starburt 將每一個條例都分配一個相對的權重，這個權重是在當inference engine 在循環中挑出條例時就配予，而且將不會有其他後來再挑出的條例的權重高過於這個條例。
範圍模式部份，除了在交易結束時自動啟動的條例執行外，使用者還可以使用下列三種命令在交易之中要求執行條例，這三個指令分別是：process rules，process ruleset S，process rules R。
process rules 就造成如同在交易結束時執行一樣，就是把執行時點當成是交易結束的時點一樣；process ruleset S 則只去處理由使用者定義的條例群S ；process rule R 只是處理條例R 是否被激發。不論條例是由上面三種或在交易結束時才執行，如果是第一次被激發，所考慮的異動都是從交易開始到激發之間；若是第二以上被激發，則只考慮前一次執行到這一次之間的異動。而rollback 的處理也和一般系統一樣，同時將條例執行與交易都取消。
5.4 SQL2 and SQL3
SQL2 與SQL3在粒子性部份，可以同時使用tuple-level 與set-level 的方法來處理triggers（SQL裡兩種形式的條例語言，SQL2 只有assertion，SQL3 則都有），而選擇的方法則是在定義條例時直接指定以“for each row”的選項就可以使用tuple-level，若不加則以set-level 來處理。triggers 的處理可以是任意的資料庫操作，是被資料庫的修改所觸動的。
不論是哪一種level 的方式，其情境的評估都是根據資料庫目前的狀態，這包括從交易開始以來的異動；而且可以參用到這些被修改的表格之新值與舊值。
SQL2 與SQL3 的條例執行是採取絕對循序的，任何的兩個條例不能擁有相同的激發事件，因此沒有衝突解決的必要。
範圍模式部份，其附加的嚴格條例定義語法限制，限制在一連串的條例啟動中同一個表格不可以被重複的更動，因此可保証連鎖的條例可以被終結。這在其他系統中是沒有的特性。
5.5 HiPAC
要解釋HiPAC 對執行中條例的處理方法，先要介紹Coupling modes。Coupling Mode 最早起源於HiPAC 專案中，後來成為其他主動式資料庫討論的內容，這也是HiPAC 獨特的範圍模式。
Coupling modes 決定條例的事件、情境、處理與資料庫交易間相對的時間與關係。在Ariel , Postgres , Starburst 以及其他許多的主動式資料庫中，情境的評估與處理的執行都發生在與激發事件同一個交易的範圍裡；而在HiPAC 裡，條例的定義可以彈性的指定是否要讓情境與處理的執行在引發激發的同一交易內進行。
我們分別用E , C , A 來代表事件,情境,與處理。每一個HiPAC 的條例都有E-C Coupling mode 與C-A Coupling mode，E-C Coupling mode 決定條例的情境評估什麼時候可以進行（相對於激發事件而言），C-A Coupling mode 則決定條例的處理什麼時候被執行（相對於處理而言）。
每一個Coupling mode 有三種模式：immediate（立即執行），deferred（在交易的最後執行），decoupled（產生另一個交易）。並不是三種模式的所有組合都有意義的，表一列出7種允許的組合與了種不允許的組合。利用這些組合，可以讓使用者設計出更適用的主動式資料庫應用。
因為decoupled mode 的緣故，有一個Causality 的限制可以選擇性的來使用，如果這個條件指定的話，由條例產生的另一個交易只有在原始交易commit 之後才可以commit。在順序關係（serialization order）內，這條例產生的交易必須跟隨著原來的交易之後處理。
HiPAC 中可以由一個事件啟動一個或兩個以上的條例，而且可以同時處理重複啟動的條例，它不是利用衝突解決的的機制來選擇要執行哪一個條例，而是將所有的條例以並行的方式處理。如果在執行期間有其他的條例被啟動，他們可以跟著一起被並行的處理。為了達到如此的作法，HiPAC 擴充了nested transaction model 來執行，其演算法如下：
1. 一些由使用者或是條例引起的事件激發了條例R1 , R2 , ..... , Rn。
2. 對於每一個Ri 安排一個交易用來
評估Ri 的情境
假如情境的評估成立，安排一個交易來執行Ri 的處理
在第二步中的交易排程是根據Ri 的E-C Coupling mode 來決定，而2b 中的交易排程是根據Ri 的C-A Coupling mode。如果是immediate 模式，則產生一個巢狀的子交易立即執行；若是deferred 模式，則產生另一個巢狀的子交易，在目前交易commit 後執行；而decoupling mode 則產生另一個與目前交易同等級的交易。值得注意的是，在情境評估與處理執行時都可能引起一些事件而造成遞迴的條例執行；而HiPAC 的條例有次序關係，這些次序關係可以在巢狀子交易並行處理時決定順序關係（serialization order）。
表一
C-A Mode
E-C Mode
Immediate
deferred
decoupled
immediate
Condition checked
and action executed
after event
condition checked
after event, action
executed at end of
transaction
condition checked
after event, action
executed in separate
transaction
deferred
Not allowd
condition checked
and action executed
at end of transaction
condition checked at
end of transaction,
action executed in
separate transaction
decoupled
Condition checked
and action executed
in separate transaction
not allowed
conition checked in
one separate transac-tion, action executed
in a different separate
transaction
以上所述，我們可以將各語言分別對粒子性、解決衝突及範圍限制、做一個綜合表二如下：
表二
粒子性 | 解決衝突 | 範圍限制 | |
Ariel | SET-ORIENTED | 權重最高者 | 允許巢狀 |
Postgres | TUPLE-ORIENTED | 隨機 | 遞迴性 即時性 |
Starburst | SET-ORIENTED | 權重最高者 | 交易結束自動起動 |
SQL2 SQL3 | SET-ORIENTED TUPLE-ORIENTED | 絕對順序 | 嚴格限制 |
HiPAC | ? | 並行處理 | Immediately Deffered Decoupled |
5.6錯誤復原
條例執行時的錯誤復原問題，在目前主動式資料庫中並沒有被完全的討論。一個條例在執行的時候，可能會產生某些錯誤，例如要讀取的資料已經被刪除、資料的使用權限被收回而無法使用、並行處理產生了死結、因為系統產生的一些錯誤或是條例處理本身就是因為錯誤的情境所引起等等。資料的遺失，或使用權遺失的情形可以利用加強dependency-tracking facility 功能來解決；在這樣的功能下，如果條例所依存的資料不存在時，條例就失去它的作用。大部分的條例語言在處理錯誤情況的時候都是都是直接將這一個交易終結，這也是傳統資料庫在交易處理時錯誤的處理方法。另一種解決的方法是結束目前的執行，回到之前的狀態重新啟動條例的執行。
在HiPAC 中的巢狀交易處理模式，允許了這些方法的可能性。當一個條例在執行一個子交易失敗時，發生錯誤的事件會傳回來訊息，由此條例決定是否要產生另一個子交易來修復它（這裡常常是由於發生錯誤的事件所引發的另一個條例執行）。另一種方法則是這個錯誤的狀況會整個傳回到最原始的交易，讓整個交易終結。
另一個探討的問題是如何在系統當機之後修復事件。對於傳統的資料庫操作，這是很容易解決的，只要利用一般的交易復原的處理即可；而對於時間性（temporal event）的或外部的事件（external event），事件必須事先宣告是否要可以復原，對於可復原的事件而言，他們的事件發生與參數繫結都要可靠的記錄下來。在進行復原處理時，尚未commit 的交易（decoupled 的情境或處理產生的交易）收到復原事件的訊號時必須重新啟動。
陸.一些問題的討論
事件的偵查(Event and their detection)
事件的觀念是主動式資料庫的核心部份，因此事件的支援是用來作為他們在功能、結構關係的偵查，不但如此，而且還能以系統作即時的反應。理想上，主動式資料庫應該可以自動偵測到所有的事件發生，但有時有些事件是無法由系統偵測到，而必須由使用者或應用程式發信。如果這一個系統的發信都必須由使用者或資料庫應用程式設計者來判定發信的正確性，而系統無法判定發信的正確與否時，這只不過是被動式資料庫的變形，不能算是真的主動式資料庫。
忙碌性等待(Busy waiting)
此情形主要是單獨使用者或者是在單CPU的系統下使用，而並非是在多元程式(multiprogramming)或多工(multitask)的情形。這個技術大多用在custom-crafted過程，以控制應用程式，如用來執行控制“資料搜集迴圈(loop)”。
情境監督碼的設置(condition monitoring code in application)
在這方法上，程式開發者必須在程式的適當之處，加上情境監督碼(condition monitoring code)。它的優點最主要為：系統上不需要做任何改變，情境監督碼成為程式的一部份；其次要的優點為：不同的與耦合模式(coupling modes)都能容易的執行。話雖如此，但仍有問題的存在，如：什麼樣的情境要被監督及監督碼是什麼？系統對於情境監督碼並沒有維護或是管理，因此，無法分享給其它程式開發者應用在程式上；再者，若是監督碼不是模組化(modular)或再利用(reusability)的話，則在應用程式在開發與維護上將是顯得困難的。雖然，情境監督它是非常重要的，但在目前在一般主機(host)上的語言是較難達到的。但資料庫程式語言(Data Base Programming Language DBPL)的環境裡，將較會容易達成的，且易分辨出主機語言及資料處理語言(data manipulation language)。
輪詢（Polling）
在這技術裡，每一個情境都要事先決定polling的次數，和評估情境的可行性以便執行處理。不論如何，每一個條例及條例類別的polling次數，都必須事先決定；此外，情境在polling的間隔，亦需考慮情境中值組的關係的大小，及評估情境的複雜度與修改的次數是否頻繁。polling它不會增強自己的耦合模式(coupling mode)，亦不會造成迴圈的執行。同樣的，在檢查的同時，它會依靠在polling的interval內，就因為有如此的時間的壓迫，因此並不適合做為監督條例。
不定期狀態查核(Aperiodic checking of situation)
這是可以替代polling的另一種技術，不定期評估查核一個系統或系統之構件(component)的情境是否確為真？激發這事件，必須要指定清楚，或由系統決定。這個方法將允許情境詳細指定說明，但這個必須倚靠詳細查核。再者，不定期查核同時，是不能保證正確，因此該技術和polling同樣有時間的壓迫，遂不適合做為監督條例。
非同步監督(Asynchronous monitoring)
這是一個類似於interrupt-driven的處理，此方法較為重要，因需處理對於事件的偵查、情境的評估及處理的執行三件事。這個方法潛在性對事件有即時性偵查及處理的執行；不但如此，就樂觀的情境和處理的機會來說，它們將系統很詳細的陳述。不論如何，這個技術需要擴展到DBMS的核心，和DBMS的架構再檢查以適應主動式的可能性。
巢狀的條例(Nested rules)
當條例處理時，能夠激發其它條例，那麼可能會有潛在性的巢狀迴圈條例在執行，像排程策略(如在圖形追蹤的Depth-first、Breadth-first)的執行，都必須使用此巢狀的方法。
條例的管理（Rule Management）
如果有一些條例，在不同的應用程式被執行時，那麼條例就會有被修改的可能性。這意味著條例會有同時受到控制機制的可能性大增。因此，條例的插入、修改及刪除都必須要有嚴謹的系統予以管理。條例庫是由當時存在的條例集合而成，由主動式資料庫管理系統來集中管理。換句話說，ECA-rules是資料庫的一部份，也是DBMS meta information的一部份。一個主動式資料庫管理系統應該正確的記錄有關條例存在的事實，以及他們是如何的被定義。這些資訊應該可以被使用者以及應用程式來使用。最好的情況是，主動式資料庫管理系統可以利用它基層的資料模式來表示這些條例。此時使用者與應用程式便可以像是在使用傳統被動式資料庫一樣的，以綱要的方式來使用這些資訊。
提供條例應用設計的環境
一個主動式資料庫系統應該要提供rule browser等的下列工具。這些工具在主動式資料庫的程式環境中可以分開使用，也可能是由已存在的傳統式被動式資料庫或CASE工具擴展出來的。更進一步的說，要強調的只是這些工具達到的功能。
Rule browser：幫助我們瀏覽目前現有的條例，這些條例可以是使用者自定，也可以是原本在被動式資料庫下一些基本的完整性限制。
Rule designer：幫助使用者定義新的條例，可以是一種全新的定義語言，或是擴充式的SQL語言。
Rulebase analyzer：用來檢測目前條例庫的一些性質，一般而言這些性質是不能自動產生，需要由analyzer的分析結果，以幫助資料庫管理師來管理條例庫的正確性與安全性。
Debugger：可以讓處理在監控的情況下執行，可以用來當作測試的環境，並確保處理是正確的進行。,
Maintenance tool：用一致的界面幫助使用者管理條例庫，包括檢索、修改等工作，並且可以注意是否這些修改動作會影響條例庫的行為狀態，以及如何影響。
Trace facility tool：記錄事件發生與處理進行的相關資訊，幫助資料庫管理師了解整個資料庫的條例進行狀況，以便進行管理。
Performance tuning tools：主動式資料庫系統必須在它的應用領域中很實用，特別是其執行效率不能比傳統被動式資料庫系統顯著的降低。因此對於不同的應用領域，主動式資料庫系統應該要提供可以調整資料庫內層結構的方式，以調整執行效率，包括如coupling mode與條例庫儲存結構等。
此外，依據Jennifer Widom談到：在目前的許多學者中，對於主動式資料庫談論了許多，大致上可分為兩種：
.一為“寬而淺(broad and shallow)”，他們描述這些應用的許多條例，但這些條例相互之間並沒有交戶作用。感覺到這些是非常容易管理的。
.另一為“深(deep)”，他們的條例間有非常大的交互影響，但是對於開發上是非常不容易的。
學者自己感覺到，他們對於“深”的應用上，沒有太多的經驗；亦有不同的學者，他們知道或是參與實際應用。大多數的這些應用看起來像是在“廣而淺”的部份，並不是在真正的資料庫上的應用，或者是說兩者都不是。
柒.結論
主動式資料庫朝向在資訊系統中完整表達與管理的運作規則，並且希望在資料的維護上提供相當好的資訊系統平臺。此外，主動式資料庫在資料庫上的應用上更有下面的優點：
1. 增加應用程式發展上的效率
傳統的資料庫系統裡，規則的定義是程序性的，條例的相關部份與控制邏輯必須在外部程式中定義。在主動式資料庫系統，這些規則的定義是宣告性（declarative）的，只要宣告其條例的類型，一些已存在資料庫中的控制邏輯便會去執行。例如在SQL 利用CREATE TRIGGER 或CREATE ASSERTION 指令來定義規則，一些儲存程序（stored procedures）就可以根據前面指令指定的資料庫元件進行操作。
這種宣告性的方法使得規則在應用上更有效率，因為這些控制邏輯（如復原、監控機制等）都已經存在資料庫系統的環境中，不需要由使用者自行發展應用程式來處理；同時由於這些控制邏輯可以再使用，因此可以增加應用程式發展的效率。
2.提昇執行運作上的效率
在Client/Server 架構中的資料庫系統應用，如果以傳統資料庫的運作方法將條例及控制邏輯定義在外部程式中，一但有條例遞迴啟動的情況發生時，傳統資料庫會以下面的方法來運作：
(1). Client 端的應用程式向Server 端發出資料庫操作的需求，如SQL 的UPDATE 指令。
(2). Server 端執行這一個指令，並且傳遞給Client 端成功的訊息以及執行狀況。
. Client 端的應用程式根據執行狀況的結果分析，產生另一個需要的操作指令，如評估情境所需要的SELECT 指令，或是根據企業規則所需進行的處理，這些指令再傳遞給Server 端進行處理。
這種主從式架構的資料庫應用，中間的傳遞過程必須依賴網路媒介的溝通。很明顯的，這樣的方法會產生很多的網路傳遞，特別是在第三步驟(3)中規則的處理時。主動式資料庫可以將第三步驟完全由資料庫系統來進行，節省許多不必要的網路傳遞。
3.人工智慧與資料庫的整合
主動式資料庫的條例語言（事件處理條例）在概念上與人工智慧系統的production rule 是非常相近。近幾年來，在資料庫的領域中出現了知識庫（knowledge bases）與知識庫管理系統（knowledge-base management system KBMS）的研究方向。在早期對於人工智慧與資料庫的研究卻一直沒有能互相交流，兩方面的研究者對於對方的研究領域都不暸解。一直到1988 年Michael Brodie 才開始進行兩種領域的整合，整合後具知識的共享、與系統獨立的優點。
綜合上述討論，對於主動式資料庫，若是要能應用在商業的領域，下面幾點是我們必須加強研究發展的方向：
提供對應用程式發展的支援並增加應用程式與條例系統間的溝通。
增加條例更強的表示性，以便能執行更複雜的工作，並要兼顧其效率性。
改進演算法，使其更具有效率；並且對於分散式資料庫與平行的環境都必須考慮，以適應資訊科技快速變動的時代。
應朝向階層式架構與整合式的主動式物件導向資料庫(Active Object-Oriented Database)的發展。
參考文獻
1. W.KIM, Modern Database System:ch.21 Active Database Systems，1995.
2. ACM-NET Consortium, The Active Database Management System Manifesto, ACM SIGMOD Record, Vol. 25, No. 3, September 1996, 40-49.
3 Jennifer Widom , Research Issues in Active Database System: Report from the Closing Panel at RIDE-ADS ’94, ACM SIGMOD Record, Vol. 23, No. 3, September 1994, 41-43.
4. Heinrich Jasper Active Database for Active Repository, IEEE 1994
5 Sharma Chaluation , Architecture and monitoring techniques for active database: An evaluation, Data & Knowledge Engineering 1994
6 陳鴻嘉陳彥良, 主動式資料庫中央大學資訊管理研究所1996
主動式資料庫