The simulation of business rules in active databases using expert system approach
Ivan Brůha, František Franěk, Vladimir L. Rosicky · European Simulation Multiconference on Simulation · 2000
A very active field of research of Database Management Systems (DBMS) is concerned with an augmentation of DBMS by rules. Passive rules (constraints) were the first to be investigated and are now widely accepted. Active rules (triggers) are in the transformation from research to mainstream applications. A more complex form of active rules, business rules, are now the topic of many research efforts. In our paper we present a framework for enhancement of SQL-based DBMS by business rules in mostly declarative form (as opposed to the more usual, but less manageable, procedural form). The techniques used utilize rule-based expert system methodology. INTRODUCTION OF THE FRAMEWORK The augmentation of database systems by rules is a very active area of database research (Patton 1999, Ceri and Fraternalli 1997). In general, there are two main categories of rules used with database systems. The first, so-called deductive rules, often also referred to as constraints, are usually described in a declarative fashion and are a part of the data definition and/or data manipulation language of the database system. Their activity is simple when a violation of a constraint is detected, the action that caused the violation is terminated and that is why the emphasis is on the description of the constraint. This kind of deductive rules has been wildly accepted by commercial providers of database systems. Besides the test for consistency (integrity), deductive rules can provide the ability to derive new information from the existing information, e.g. socalled security views can be defined using deductive rules. In any case, these rules do not alter the content of the database, therefore they are also referred to as passive rules (Ceri and Fraternalli 1997). The other kind of rules, active rules, often also called triggers, provide computational actions triggered by an occurrence of a specific event, typically a database operation. The action is a reaction to a given stimulus. Such rules are called active, since their actions may cause a change of the database content, in fact, we can talk of their desirable side effects. It is quite obvious that active rules are usually of the form event -> action and that the action part has a procedural character. Active rules themselves can be categorised into two major application groups: the first can be characterised as repair of violations of integrity rules (constraint violation repair) and the second as business rules (Patton 1999). The purpose of business rules is to keep the business (application-specific) integrity of the database intact. Many current commercial database systems support triggers in a very simple format: • a simple language is provided to describe the event (trigger) and when the corresponding action should be activated (before or after the event) • the action itself is a so-called stored procedure (some systems, e.g. INFORMIX, provide a special language for stored procedures, while others, e.g. DB2, allow any language like C/C++ to be used for stored procedures). This approach is quite suitable for the constraint violation repair, but much less suitable for explicit design of business rules, the reason being that the procedure triggered by the event may be quite complex. The goal of the research described in this paper is to provide a formalism and a methodology for design of active rules that would be more conducive to business rules and their intended applications. Since for practical reasons we can neither modify nor augment the functional kernel of a commercial database system directly, we had to come up with an approach how to extend an existing commercial database by a layered architecture that would “sit” on the top of the commercial system and thus simulate business rules and their execution in it. Since the extension is not a part of the database system, it actually simulates the active rules, even though from the user’s point of view they seem to be an integral part of the database system. Of course, this framework is not intended as a production system, but as a test bed for our ideas and methods regarding the business rules. DESCRIPTION OF THE DATABASE SYSTEM EXTENSION We simulate business rules of a given database system by the means of an expert system augmented with a direct database access through embedded SQL queries. We have a long experience with a rule-based McESE (McMaster Expert System Environment) project (Jaffer 1990,Franek and Bruha 1989a, Franek and Bruha 1989b, Franek and Bruha 1990), and a similar system TESS (Terren Expert System Shell) (Franek at al. 1999) that provide a database access. Thus we opted for a similar SQL-augmentation of McESE (see the following section for details) for the task. We leave it to the commercial system (triggers) to detect events of our interest, but we simulate the actions by a set of McESE rules. This approach offers to us three very important features: 1. McESE rules provide a high-level declarative description of the action and the procedural aspects are deferred to well-localized atomic predicates, i.e. to a very low-level of description. This contrasts with the purely procedural ways of commercially available active rule formalisms. 2. McESE has two built-in rule resolution strategies based on its approach to uncertainty, the optimistic strategy (use the best evaluation) and the pessimistic strategy (use the worst evaluation), and together with the stratification requirements and checking, confluence and termination (Ceri and Fraternalli 1997, Aiken at al. 1992) are automatically assured. 3. If a database contains attributes with fuzzy or granulated values, then such values could be easily processed by the augmented McESE system as it is in McESE’s nature to allow processing of fuzzy and/or granulated values (Jaffer 1990, Franek and Bruha 1990). This is another enhancement our approach provides, since current commercial systems are not capable of processing of such attributes. The fuzzy approach to constraint repair is not needed, while it is more than desirable for business rules.