Lastic Rule Based System

 Overview :::

 Key Features

 Benefits

 Licensing / Prices

   
 
You are here: Home > Products > Lastic Rule Based System > Overview


Overview

The Rule Based System consists of:
  • A rule definition facility and run-time processor
  • A fact base definition (data dictionary) facility
Rules are constructed within a domain - the 'area of interest' for that set of rules. In addition, rule domains can be shared (library domains). A rule consists of one or more clauses and each clause consists of one or more conditions. Rules are defined and processed as syllogisms.

Fact bases (that part of your database defined within a data dictionary) are available to the various domains. More than one rule domain can utilise the same fact base.

Rules can interact with the environment via both supplied functions and facilities for developers to construct their own functions to perform whatever actions are required.

Design-Time
The fact base automatically determines inheritance capabilities (including multiple inheritance) via the subscript definitions of the database records.

Rule definitions are compiled to tokenised data for the domain.

Both the fact bases and the rule domains are held within your databases.



Run-Time
An application invokes the Rule Processor by passing the domain and start rule to be processed.



Functions within the rules can interact with both the database and directly with the user.

Upon completion, the rule processor will return with a boolean response indicating whether the rule process has completed successfully or not.

Rule functions also enable data to be written to the database - thus, the processing of a domain could increase the fact base. Such newly written information could be used for further rule processing or may be retrieved by the initiating application.

How Do Rules Work? 
  • Rule Structure 
    A rule consists of one or more clauses with each clause containing one or more conditions.
     
  • Conditions 
    A condition may be described, at it’s simplest, as (if) A=B. However, either A or B (or both) may be functions or rules themselves. For example, if both A and B were rules then, when encountering the above condition, the rule processor would evaluate both rules before performing the comparison. Now since a rule may invoke further rules we can see that complex structures can be developed. 
     
  • Clauses 
    A clause is a set of conditions which, if all are true, causes the rule to be true. If any condition within a clause is false then the clause is false. If a clause fails then the rule processor will action any further clauses ('or' clauses) to see if they are true. Again, the rule will be true if any clause is true. If all clauses are false within a rule then the rule will fail.
     
  • Variables 
    Variables may be either database items or 'work variables'. A database item is denoted by it’s entity name and item name - for example 'patient.date_of_birth'. A work variable is denoted purely as it’s name - for example 'total'. 

    For database items, if we have already established, say, the patient database reference (such as the patient 'number') then a condition such as:

                'if patient.year_of_birth before 1900'

    will cause the rule processor to locate the physical global field containing the date of birth, extract the year of birth and perform the comparison. The comparator ‘before’ would have been defined as equivalent to ‘<’.
     
  • Assigning Values 
    Value assignment occurs if the comparator is 'equals' (or an equivalent) and the variable to the left of the 'equals' has no locatable value. When this occurs, the value to the right is given to this variable. Both then have the same value and the comparison will be true.
     
  • Rule Evaluation 
    Since rules may invoke other rules the rule processor maintains it’s own stack mechanism. Rule stacking does not affect the Caché / M stacks. Rules are invoked within conditions and will return values of 1 (true) or 0 (false). It is this value which is compared within conditions.
     
  • Certainty
    Certainty is not a function of the rule condition but of values determined during that rule’s operation. A rule may determine, for example, a statistical rate of 0.15. Another rule condition may compare this value to a statistical norm. The rule performing the comparison may succeed or fail within this comparison - returning a true or false status.
 
 
 
© 2007 Lastic Limited. All rights reserved.                     Legal / Privacy