ABSTRACT. This paper explores the integration of rule systems into data base management systems. One major theme is a survey of the research activities in this area over the past decade. The focus is on prototype systems that have been completely specified and the implementation issues encountered. The second thrust is to present a research agenda which should be addressed by the research community over the next few years.
http://db.cs.berkeley.edu/papers/ERL-M93-25.pdf
Historically rule management has been the domain of expert systems, and is included in such expert system shells as OPS5 [FORG81], Prolog [CLOC81], and KEE [INTE85]. As a result, rule systems were contained in stand-alone programs with no interaction with DBMS systems.
…
To help with these problems, there has been considerable effort expended to couple expert system shells to data base systems.
Rule systems have fundamentally complex semantics
Consider the rule:
on retrieve to EMP.salary then do append to AUDIT
(name = current.name, salary = current.salary, user = user())The above rule can be awakened in the same transaction as the user command or it can be activated in a different transaction. If it is activated in the same transaction, then a user can retrieve a salary, and then abort his transaction. If so, the auditing action will be undone by the abort, and the user’s retrieve will not appear in the audit trail. To get the desired action, the rule must be activated in a different transaction.
In general, different results will be observed depending on which transaction context is chosen.
One way to alleviate the semantic morass of the previous section is to view the rule specification language discussed in the previous sections as “data base assembly language”, i.e. it is a complex low-level notation that only a few compiler writers have to understand. These guru programmers will implement higher level languages, which have much simpler semantics.
The challenge for DBMS researchers is to invent a multitude of higher level notations.
… we discuss the implementation of POSTGRES views and versions. In both cases, required functionality is supported by compiling user level syntax into one or more rules for subsequent activation inside POSTGRES.
Views (or
define view TOY-EMP (EMP.all) where EMP.dept = "toy"This view is compiled into the following POSTGRES rule:
on retrieve to TOY-EMP
then do instead retrieve (EMP.all) where EMP.dept = "toy"Any query ranging over TOY-EMP will be processes correctly by the POSTGRES rules system.
… Therefore, default views are available using compilation of view syntax into a collection of rules. Other update semantics can be readily specified by user-written update rules.
In this section we more briefly sketch several other possible rule compilers. Referential integrity is often stated as a requirement for current relational DBMSs. In most commercial systems, it is hard-wired as special purpose code. However, it is straightforward to build a compiler for referential integrity syntax.
In a matter of a few years, integrated rule systems have moved from conceptualization, to research prototypes, and finally to commercial systems.