The Rule-Engine provides basic concepts for a rule-based processing for other compoents. For instance, it is used during rewriting and transformation of queries.

Components and semantics

The Rule-Engine has several components

Working Memory

The working memory exists of all objects that have to be processed by rules. For the transformation, for example, the working memory consists of all logical operators that should be transformed by rules into their physical counterpart.

To interact with the working memory in a rule, there are the following methods:

Important is the retract method. If an object is never removed from the working memory by using retract, although there are rules, it may be possible to get into an infinity loop!

 

Inventory

The inventory consits of all necessary objects for the current rule engine instance. This is, normally, the set of all rules and the RuleFlowGroups (see below).

Each time when the rule engine is invoked, the rule engine creates a copy of the inventory. This is needed so that rules can not be changed if they are in use. Furthermore, it allows nested runs of the rule engine, e.g. to run a transformation within another transformation without influecing each other.

The rule engine consists of a two-stage hierarchy: First, there is a list of RuleFlowGroups and, secondly, each RuleFlowGroup has a set of Rules.

RuleFlowGroup

The rule enginge allows to create groups of rules, which are named RuleFlowGroups. Each Rule has to be assigned to such a group. The rule engine runs one group after another group. Therefore, each instance of the rule engine (e.g. the one for the transformation) has a fixed ordered list for this groups . However, a rule group may occur more than one in this ordered list.

If the rule engine is executed, it runs each group in succession. For each rule flow group, each rule of this group is tested if it is executable. Therefore, there are two possibilities:

Rules

Each rules belongs to a RuleFlowGroup. Furthermore, each rule is responsible for a dedicated type, which is defined by a generic within the rule (this might be, for example, a certain operator).

For each run of a RuleFlowGroup, the following steps are performed for each rule of the group: