Table of Contents
Active Databases ...................................................................................................................................... 1
What are Active Databases? ................................................................................................................ 1
Common Databases versus Active Databases ..................................................................................... 1
Active Rules ........................................................................................................................................ 2
Events .................................................................................................................................................. 2
Primitive events .............................................................................................................................. 2
Composite Events ........................................................................................................................... 3
Rule Execution..................................................................................................................................... 4
Coupling Modes .............................................................................................................................. 5
Deferred Coupling. ......................................................................................................................... 5
Active Database Applications .............................................................................................................. 6
Development & Implementation.......................................................................................................... 6
Example SQL....................................................................................................................................... 7
Transaction Execution ......................................................................................................................... 7
Types of Active Databases .................................................................................................................. 8
STARBURST ................................................................................................................................. 8
POSTGRES .................................................................................................................................... 8
ACOOD .......................................................................................................................................... 8
ACOOD .......................................................................................................................................... 9
Active and Deductive combined ........................................................................................................ 10
Active Example ................................................................................................................................. 10
Military Intelligence ...................................................................................................................... 10
Active Faults ...................................................................................................................................... 11
Deductive Databases .............................................................................................................................. 12
Introduction ....................................................................................................................................... 12
Specifications ..................................................................................................................................... 12
What are they used in? ....................................................................................................................... 12
Inference engine (or deductive mechanism) ...................................................................................... 13
Bottom - Up (forward chaining) ........................................................................................................ 13
Top - Down (backward Chaining) ..................................................................................................... 14
Clausal Form & Horn Clauses ........................................................................................................... 15
Interpretation of Rules. ...................................................................................................................... 13
Logic programming ........................................................................................................................... 15
Prolog/Datalog notation ..................................................................................................................... 16
Stratified Negation. ............................................................................................................................ 16
LDL - Logic Data Language .............................................................................................................. 16
NAIL! - Not Another Implementation of Logic ................................................................................ 17
CORAL .............................................................................................................................................. 19
Deductive Object Oriented Databases (DOOD) ................................................................................ 19
VALIDITY ........................................................................................................................................ 20
Commercial uses of Deductive Databases. ........................................................................................ 20
LDL............................................................................................................................................... 20
VALIDITY ................................................................................................................................... 21
Summary ............................................................................................................................................ 21
The future of deductive databases? .................................................................................................... 21
References ......................................................................................................................................... 22
Module No. CO42009
OODB
Active Databases
What are Active Databases?
The database system is an important part of the information system of any
organization. Each new achievement in information technology reflects in the
database systems. As information technology evolves, so do DBMSs (e.g. OOPL
evolved database systems into OODBs). DBMSs are big monolithic systems and
when database technology evolves, they become even bigger. The Solution is to break
up the functionality of DBMSs into many autonomous/semi-autonomous loosely
coupled components
An event is raised from the environment where the system must then respond to the
event. The event-response paradigm is needed in all software systems, not just
databases. Systems that respond to environment stimuli are known as active.
Common Databases versus Active Databases
An Active Database System (ADB) is a conventional database system extended with
the capability of reactive behaviour.
 Conventional Databases are passive: they only do what they are told to.
 The ADB system can perform operations automatically, in response to
situations that have occurred inside or outside the databases.
The databases is frequently queried to check if a situation to react upon has occurred
(How often?)
- High frequency: the databases will perform bad (clutter)
- Low frequency: an interesting situation may be missed
 Embedding detection of situations and reaction inside applications:
Maintenance problems
 An ADB is more powerful than a passive database:
- Performs functions that in passive Databases must be encoded in applications
(or polling)
- Facilitate applications beyond the scope of passive Databases
- Perform tasks that require special-purpose subsystems in passive Databases
Active & Deductive Databases
Page 1 of 23
13/02/16
Module No. CO42009
OODB
Active Rules
Now a common feature among commercial DBMS vendors such as Oracle, DB2, &
SYBASE active rules, as mentioned, are an added functionality of common databases
where active rules trigger a sequence of events in the database. These rules can be
activated through temporal changes, external (application) driven changes, or user
intervention.
Active databases rely the ECA model (Event, Condition, Action).
 Event: - This is the event or events that trigger the Active rule. Events are
usually database operations such as Update, Delete, Add, or Create. They can
be as mentioned temporal events where a change in time would specify a
trigger or they can be external i.e. from user intervention or application
intervention.
 Condition: - Here the rule deciphers whether the action should be executed as
specified the action will automatically trigger.
 Action: - the action can either be a sequence of SQL statements but it could
basically be any action taken by the database or even the execution from the
database, of an external application.
Events
Events describe situations to which a reaction must be shown
 Events are objects, therefore they belong to event classes
 Event classes can be organized in hierarchies (inheritance)
 Events can be primitive or composite
Primitive events
 Method invocation
- Modification and/or retrieval of object values
- General-purpose methods
- Database methods (e.g. transaction operations)
 Time events
- Absolute (e.g. 1 Jan 2000 at 12:00)
- Relative (e.g. 10 min after stock market closing time)
- Periodic intervals (e.g. every 10 minutes)
 Application-specific or user-defined events; they must be explicitly raised by
the application or the user
 An event can be raised before or after method invocation E.g. before accessing
an object a security rule is checked
 After updating the salary attribute of an employee object the average salary of
all employees is re-calculated
 ECA rules are implemented as a "detour" from normal method execution
Active & Deductive Databases
Page of 23
13/02/162
Module No. CO42009
OODB
Detection of Events
Before event
Event
detector
Message
Method
execution
Object
Signalling
Result
Figure 1 Event detection model
E1 & E2
E1
After event
Rule
E2
Signalling
Subscription
Figure 2 Subscription of Events
Composite Events
Composite events are combinations of other Primitive or Composite events where
they define more complex situations that must be reacted upon.
Composite event constructors:
 Logical combinations (conjunction, disjunction, implication, negation)
- E.g. If both the general stock index and share volume have increased rapidly,
then BUY
 Event Sequence
- E.g. If IBM stock decreases after Intel increases, then Microsoft stock will
increase next day
 Temporal composition
- E.g. 5 seconds after event E1
- Every hour after the first time event E2 occurred
 Events may have parameters:
 OID of the object that the event has occurred
 Parameters of the method invocation
 Transaction that the event has occurred

Composite events may check on parameters E.g. both E1 and E2
events must happen during the same transaction or for the same object

Composite events and rules subscribe to primitive events
Active & Deductive Databases
Page of 23
13/02/163
Module No. CO42009
OODB
Rule Execution
The event manager collects all raised events and triggers the corresponding rules
 Condition is checked and if true action is executed
 Events pass parameters to conditions and actions
 Rule conditions are:
-Check on event parameters
-Queries on database objects
-Condition can be null, i.e. it is always true
-Condition must be able to refer to old and new object values
 Rule actions are:
-Database object modifications
-Application specific procedures (e.g. announcements)
-Transaction operations
-Rule actions may raise more events (termination problems)
 Multiple rules may be eligible for firing at a given time
-The ADB must perform conflict resolution
-Rules can be executed in a serialized order or concurrently
-Order of rule execution is usually defined using priorities
 Rules are objects (rule classes, hierarchies, inheritance, etc.)
 Rule management includes:
o Creation, modification and deletion of rule objects
o Enabling and disabling of rules.
Active & Deductive Databases
Page of 23
13/02/164
Module No. CO42009
OODB
Coupling Modes
An important question in ECA rule execution is: When (exactly) to check the
condition, after the event has been detected? And when (exactly) to execute the action
after the condition has been checked and satisfied?
The exact time to perform the above is determined relative to the triggering operation
and the end of the transaction

There can be various delays in executing the parts of the rule

These possibilities are called rule coupling modes

The delay between event detection and condition checking is called EC
coupling

The delay between condition checking and action execution is called CA
coupling

Immediate Coupling. There is no delay between EC and / or CA

The condition is immediately checked after the event has been detected

The action is executed immediately after the condition is satisfied

The action can trigger another rule, and so on so forth
- Special care must be taken in order to terminate rule processing

This mode can be used for authorization, security, etc.
Deferred Coupling.
The next part of the ECA rule is executed at the end of the current transaction.
The condition of the rule is not checked after its event has been signalled, but at the
end of the transaction. The action of the rule is not executed after the condition has
been satisfied, but at the end of the transaction. This coupling mode is used for
checking integrity constraints. Many single updates violate the constraint, but the
overall effect is valid. If the condition is checked immediately after the first "illegal"
update, then a constraint violation is detected. The constraint violation is repaired by
following update:
Detached Coupling. The next part of the ECA rule is executed in a separate
transaction
The new transaction may or may not depend on the old transaction this mode is useful
when many rules are executed at one time. It is preferable to split rule execution into
many small transactions as long transactions lock objects for a long period, so the rest
of the users and applications cannot use them!
Active & Deductive Databases
Page of 23
13/02/165
Module No. CO42009
OODB
Active Database Applications
Active rules implement simple database tasks such as:
-Integrity constraint checking and enforcement (deferred coupling mode)
-Authorization (immediate coupling mode)
-Maintenance of derived data or materialized views
-Composite events and detached coupling may not be needed
Active rules implement application programs
-Business rules (e.g. stock trading information systems)
-All event types and coupling modes are needed
Active rules integrate loosely coupled, heterogeneous, may be distributed, and
autonomous information systems by:
- Advanced workflow management systems
- Reactive behaviour in heterogeneous distributed OODBs
- Real-time plant control systems
- Process-centred software development environments
- Event detection from external systems or devices is needed
- Real-time features are needed (timing of rule execution)
There are no active OODB commercial systems available as yet. However
experimental prototypes have been developed such as:
- ODE, HIPAC, SENTINEL, EXACT, SAMOS, NAOS
Instead of ADB systems the commercial market uses relational DB systems with
triggers like the Oracle system, which has both triggers and object-relational features
Development & Implementation
The design of the Active database extends beyond the capabilities, mentioned earlier,
to a set of more detailed administrative tasks, which govern the implementation of
active rules.
Active rules can be:
Activated: - the event is enabled & can be triggered.
Deactivated: - the event will be disabled & cannot be activated.
Dropped: - Removed altogether after implementation.
Grouped: - A given set of rules that are common can be grouped together
known as rule sets for easier administration.
Process rules: - user can command a set of rules to activate for trial purposes.
Before / After / Concurrently: - here as mentioned in the example the actions
can be applied at certain times with consequence to the condition and event.
Separate Transaction: - here the administrator can determine whether or not
the rule should be activated with the same transaction as rules or whether it
should have its own.
<trigger> ::=CREATE TRIGGER <trigger name>
(AFTER | BEFORE ) <triggering events> ON <table name>
[FOR EACH ROW]
[WHEN <condition> ]
<trigger actions>;
<triggering event > ::=<trigger event> {OR <trigger name> }
<trigger event> ::= INSERT | DELETE UPDATE [OF <column name> {,<column name>}]
<trigger action> ::= <PL/SQL block>
Note. Syntax for declaring trigger in an ORACLE system
Active & Deductive Databases
Page of 23
13/02/166
Module No. CO42009
OODB
Example SQL
The following example implies a new member has joined their local Slimming Club.
The members is inserted into the clubs database field where the new member’s weight
is then added to the total weight of all the members within that particular club in the
chain. This will give the administrators of the company nationwide an idea of which
ones are proving to be the most successful. The updates to the table are carried out
with statement level updates.
CREATE RULE T_WEIGHT ON SLIM-CLUB
WHEN INSERTED
Event
IF EXISTS (SELECT*FROM INSERTED WHERE CNO IS NOT NULL)
Condition
Action
THEN UPDATE CLUBNUMBER AS C
SET M.TOTAL_WEIGHT=M.TOTAL_WEIGHT +
(SELECT SUM(I.WEIGHT) FROM INSERTED AS I WHERE C.CNO = I.CNO)
WHERE C.CNO IN SELECT CNO FROM INSERTED);
Note. Syntax for an ORACLE implemementation
Transaction Execution
When an event is triggered we have to satisfy one or any number of conditions before
allowing the action to take place. This is known as the condition evaluation.
Rule consideration: - as its also known decide will evaluate the criteria of the
condition and assess as to whether or not the conditions specifications have been met.
If the criterion has been matched the rule will move onto the action but not before the
different time options have been assessed. Below are the different scenarios, which
are quite self-explanatory.
Immediate Consideration: - The condition executes as part of the same
transaction that updates the event. The immediate consideration option has
three other options also implemented
Evaluate the condition before executing the triggering event
Evaluate the condition instead of executing the triggering event.
Evaluate the condition after the triggering event.
Deferred Consideration: - The condition is read after the transaction has
called the event.
Detached Consideration: - once the triggering transaction has begun the
condition is read separately where it will receive the event information and
send a message to the action.
Rules can be implemented on the whole database or on selected rows of the database
governed by the SQL statement used.
Statement Level rules update the whole database where as
Row-Level rules update selected rows (or tuples).
Oracle allows for both case scenarios where as STARBURST (as described below)
will only cater for Statement-Level rules.
Active & Deductive Databases
Page of 23
13/02/167
Module No. CO42009
OODB
Types of Active Databases
STARBURST
STARBURST is an experimental database management system designed to exploit
Active functionality on a Relational DBMS. The database uses Statement Level
Active Rules but not Row Level, meaning updates can only be applied to the database
as a whole. It uses standard SQL statements to update the database. STARBURST
uses the differed consideration execution method, which means the condition is only
considered after the transaction ends.
POSTGRES
Is a rule system with object-orientated functionality, with 2 implementations of rules
and acts at a row-level statement.
Rule
Definition
Module
Traffic Cop
Parser
Set of
Parse Tree
Query Rewrite
Rule system
Plan
Parse Tree
Planner
Executer
Tuple
Tuple
Rule
Manager
Figure 3 POSTGRES event system model
Access
Methods








Traffic Cop: calls the execution of all modules.
Rule definition module: define new rule.
Parser: syntax checking, create parser tree.
Query rewrite rule system: combine query and rule
Planner: create a plan for next module.
Executor: execution for the plans.
Rule manager: responsible for TLS rules
Access methods: for all I/O operation, insert
Active & Deductive Databases
Page of 23
13/02/168
Module No. CO42009
OODB
ACOOD
ACOOD or ‘Active Object-Orientated Database’ is an extensive research prototype of
an active DBMS built on top of ONTOS DB, which is a commercial object-oriented
DBMS.
Application
4
6
3
ACOOD
5
1
ONTOS Client
2
EG
Flow
Reply
EG – Event Generator
Figure 4 ACOOD event system model
 ACOOD uses ONTOS DB as its storage manager. All events and rules are stored in
ONTOS DB.
 All response to ONTOS DB submitted tasks pass through this channel. Dynamic creation
and deletion of Event Generators (EG) in ACOOD is supported through the ONTOS DB
programmatic type interface. ONTOS DB is responsible for event generation.
 When a rule is fired, the action invokes a method in the application.
 The application configures the active parts of the DBMS by creating and removing events
and rules.
 Standard passive OODBMS functionality is provided by ONTOS DB. The application can
submit its request directly to the ONTOS DB client.
 ONTOS DB replies to application submitted queries. Since ONTOS DB cannot interact
with the application on its own initiative, this arrow is dotted.
Active & Deductive Databases
Page of 23
13/02/169
Module No. CO42009
OODB
Active and Deductive combined
The reason why we relate the two technologies is because they complement each
other to the degree that they can emphasis an artificial intelligence type data system.
The active part of the database is responsible for the events and actions being
executed but the deductive part of the database can record the condition and determine
facts and rules based on the specifications already set. From there the database can
decipher conditions based on a knowledge base that it has evolved from these facts
and rules. Our example in the presentation can give and idea of how the two can work
together to the effect that an implementation can be created and left to determine rules
for its self. A problem with this is the fact that active rules are complex and can
become contradictory to the extent that they can become involved in an ever-existing
loop. Constant human interaction will have to be over seen in order to ensure the
database doesn’t stall, somewhat contradicting the point of having an Active and
Deductive database.
Active Example
Military Intelligence
Un known to many of us many of the missile launchers in the military use database
applications that hold a certain amount of programmed intelligence. The launchers are
programmed to detect different warning signals based on varying events.
For example a missile launcher could detect a plane travelling through air space that is
being monitored. Should the plane take a common route through for instance, a
commercial route, it will be ignored. If the plane where to cross over a no fly zone
then the database will add ‘1’ to the condition. If the plane where to travel at a lower
altitude than normal this would trigger the event to add another ‘1’ to the condition.
At this point the rule consideration can evaluate the condition and return an action to
the missile launcher that will move it to point at the object.
If the plane were to make a sudden change in direction, then again the database would
update the condition field this would happen for each ‘suspicious’ eventually until the
condition field was satisfied. Once the condition has been met the next condition
evaluation will trigger another action, which would prompt the missile launcher to fire
at the plane or perhaps close to it as a warning.
Active & Deductive Databases
Page of 23
10
13/02/16
Module No. CO42009
OODB
Active Faults
Active databases won’t be able to establish themselves fully in the commercial market
until a number of faults are ironed out before hand. These faults are quite significant
and can lead to inconsistency within databases easily. Tools, perhaps within a DBMS,
will need to be devised to design the Active objects and test them. Another tool will
need to be developed in order to monitor the Active objects once implemented. The
reason for this is that there can be multiple Active objects triggering concurrently
acting on the same data. Termination of actions is not guaranteed either, for instance:
If a rule where to be triggered when an INSERT event was executed on an employee
table and its action includes an UPDATE on an attribute1 within the departments
table. But rule 2’s trigger is an UPDATE event on attribute1 of the department’s table
and its action is an INSERT on the employee table. We can see here that these rules
can trigger each other indefinitely leading to non-termination. If lots of rules were
written this way it would be very difficult to determine the cause of the fault with out
some sort of monitoring device.
Active rules can considerably simplify database and software development but active
rules have no easy to use technique for designing, writing, and verifying rules. As
mentioned it is difficult to measure how consistent an active rule is compared to the
other ones as rules can also contradict each other.
Active & Deductive Databases
Page of 23
11
13/02/16
Module No. CO42009
OODB
Deductive Databases
In this section we will describe Deductive Databases systems and how they are
implemented with real world scenarios. We will also describe how active and
deductive database can be integrated.
Introduction
A deductive database is a database system that includes facilities to define deductive
rules. These rules can then be used to infer or deduce additional information from the
facts stored in the database. In a deductive database system, rules are typically
specified through a declarative language i.e. a language that provides a mechanism to
specify what we want to achieve rather than how we want to achieve it. The model
used for deductive databases is based on the field of logic programming and the
Prolog language (explained in greater detail later in this document)
Specifications
A deductive database uses two types of specification facts and rules.

Facts are specified in a manner similar to the way relations are specified; the
main difference is that they may not necessarily include the attribute names.
The meaning of an attribute is determined solely by its position within the
tuple.

Rules are similar to relational views. Rules specify virtual relations that are
not actually stored, but can be formed from the facts by applying inference
mechanisms based on the rule specifications.
What are they used in?
As mentioned above, a deductive database provides an intelligent database system
capable of generating new rules from existing rules and facts. This type of
functionality has many, possible, applications specifically:





Artificial Intelligence
Semantic networks
Frames
Production systems
Rules for capturing domain-specific knowledge
Active & Deductive Databases
Page of 23
12
13/02/16
Module No. CO42009
OODB
Interpretation of Rules.
A deductive database systems the inference engine uses a computational mechanism
to interpret the rules, which is an exact computational interpretation of the rules.
However, there are 2 theoretical interpretations. These interpretations may not deliver
the same outcome as the inference mechanism.
 Proof-theoretic.
o It considers facts and rules to be true statements also known as axioms.
o Facts are axioms that contain no variables also known as ground
axioms.
o Rules are known as deductive axioms. They are used to deduce new
facts.
 Model-theoretic.
o Typically uses a finite domain known as the Herbrand Universe or an
infinite domain, both of which contain constant values.
o Every possible combination of values is assigned a predicate.
o After discovering whether the predicate is true or false, they are
grouped with all the other predicates that will make the argument true.
Therefore we can state that all the other combinations make the
predicate false.
o Once this is completed for every predicate it is known as the
“interpretation of a set of predicates”.
o An interpretation is known as model for a specific set of rules. If those
rules are always true.
In the model–theoretic approach, the meaning of rules is established by providing a
model for these rules. One such model is the minim model. In general the minimal
model that corresponds to a given set of facts in the model theoretic system is, should
be the same as the facts generated in the proof theoretic interpretation.
Usually the facts that are generated by the model-theoretic and the proof-theoretic
should be the same if given the same set of ground and deductive axioms.
Inference engine (or deductive mechanism)
There are two main approaches to computational inference mechanisms based on the
proof-theoretic interpretation of rules. These are, the bottom-up and top-down
inference. These are outlined below.
Bottom - Up (forward chaining)
In bottom-up inference, the inference engine creates new facts by applying the rules to
the original facts. Once these new facts are created the forward chaining inference
engine will check the new facts against the query predicate goal for a match. This is in
line with the aim of forward chaining, which is to move forward towards the predicate
goal and away from the facts. In this approach facts should only be generated that are
Active & Deductive Databases
Page of 23
13
13/02/16
Module No. CO42009
OODB
relevant to the query else if all other possible facts are created it becomes inefficient
for systems that have a large set of rules and facts.
Top - Down (backward Chaining)
Backwards chaining is primarily used in Prolog interpreters. The top down approach
is also known as backward chaining or top-down resolution. As the name suggests,
this inference engines works in the opposite way to the bottom-up inference
mechanism by the way the system starts with the query predicate goal and attempts to
find a match to the variables that lead to valid facts in the database. In this
mechanism, facts are not explicitly generated, as they are in bottom-up.
Variables are bound to values; the follow example from “The Fundamentals of
Database Systems 3rd Edition, will explain how this happens.
Figure 5Top-down evaluation of a query
In processing the query supsuperior(James,Y)?, the system first searches for any facts
with the superior predicate whose first argument matches “james”. If any such facts
exist, the system generates the results in the same order in which the facts were
specified. Since there are no such facts in our example, the system then locates the
first rule whose head (LHS) has the same predicate name as the query, leading to the
(nonrecursive) rule:
superior(X,Y) :- supervise(james,Y)
The inference mechanism then matches X to james, leading to the rule:
Active & Deductive Databases
Page of 23
14
13/02/16
Module No. CO42009
OODB
superior(james,Y) :-supervise(james,Y)
The variable is now said to be bound to the value “james”. The system proceeds to
substitute superior(james,Y) with supervise(james,Y), and it searches for facts that
match supervise(james,Y) to find a answer for Y. the facts are searched in the order in
which they are listed in the program leading to the first match Y=franklin, followed
by the match Y=Jennifer. At this point, the search using the first rule is exhausted, so
the system searches for the next rule whose head (LHS) has the predicate name
superior which leads to the recursive rule. The inference mechanism then binds X to
“james”, resulting in the modified rule:
superior(james,Y):- supervise(james,Z), superior(Z,Y)
Two searches that are used within the top-down mechanism are depth-first and
breadth-first. The most standard approach is the depth-first search. This is where
the program searches for a binding that makes the first predicate true. It then searches
for an equivalent match for the subsequent predicate. If the original predicate binding
does not return any matches that makes the second predicate true, the mechanism then
backtracks and looks for the next binding that makes the first predicate true.
The most recent search technique is the more efficient breadth-first this search is
designed to match together the multiple sub-goals then it can proceed in parallel. It
has optimisation techniques, which direct the search to the most promising rules first.
Clausal Form & Horn Clauses
Formulas contain conditions, which include predicates called atoms; formulas also
contain quantifiers such as the universal quantifier and existential quantifier. In
clausal form a formula must be transformed into another formula with the following
characteristics:



Universal quantifiers do not have to be explicitly included since all
the variables in the formula are universally quantified
automatically.
Formulas are made up of clauses and each clause is made up of
literals which are connected by logical OR connectors. This means
a clause is a disjunction of literals.
A formula is made up of clauses which are connected by logical
AND connectors. Making formulas a conjunction of clauses.
In Datalog rules are expressed as horn clauses. A clause can contain a maximum of
one positive literal
Logic programming
Deductive database systems are closely related to the field of logic programming and
the Prolog language. Research into deductive database logic systems has used Prolog
Active & Deductive Databases
Page of 23
15
13/02/16
Module No. CO42009
OODB
as a starting point. A variation on Prolog is Datalog, which is a used to define rule
declaratively in conjunction with an existing set of relations.
Prolog/Datalog notation
These query languages uses a notation in which predicates given with unique names,
this name should suggest the implicit meaning of the predicate, the predicate also has
a fixed number of arguments. The predicate states the fact is true if all the arguments
are constant, but if the predicate uses variables as arguments then it is used as a query
or as part of a rule.
Prolog has numerous "built-in" predicates that the system interprets directly, and are
generally used with comparison operators such as =, >, <, =>, <=, these are treated as
binary functions. Whereas arithmetic operators such as +,-,*, / are used as arguments
in predicates. However one of the major differences between Datalog and Prolog is
that arithmetic operators can be used in predicate arguments.
A Datalog program is made up of atomic formulas which are literals that are made
up in the following way p(a1,a2,a3,….,an). p is the name of the predicate, and n is the
number of arguments or the arity for the predicate. The arguments are either constant
values which are numeric or start with a lowercase letter, or they are variable names
that always begin with an uppercase letter.
Literals can be either a positive or a negative literal.
Stratified Negation.
A program that makes use of negation will typically get its meaning from an
“intended” model. The problem is developing algorithms that pick a suitable model
that makes sense if the rules and allows the database administrator to answer queries
about the model as efficiently as possible.
An extensively studied negation class is the Stratified negation. Programs use
stratification if it does not use recursion through negation and instead has intuitive
semantics.
.
LDL - Logic Data Language
Microelectronics and Computer Technology Corporation developed the LDL project
in 1984. The primary objectives of this project were:


“To develop a system that extends the relational model yet exploits some of the
desirable features of an RDBMS.”
“To enhance the functionality of a DBMS so that it works as a deductive
DBMS and also supports the development of general-purpose applications.”
These goals were achieved and the resulting system is a deductive DBMS. The LDL
system can be viewed as a rule based extension to the domain calculus based
languages. LDL is a combination of the expressive capability of Prolog and the
Active & Deductive Databases
Page of 23
16
13/02/16
Module No. CO42009
OODB
functionality of a general purpose DBMS. At the time that LDL was developed, there
were many systems, which had tried to achieve this, however the main drawback of
these systems was the fact that Prolog is navigational i.e. one tuple at a time whereas
RDBMS relies on user the user to formulate queries and leaves the optimisation of the
query execution to the system.
The developers of LDL decided to modify the Prolog programming environment into
a general-purpose declarative logic language. This resulted in a programming
language different from the original Prolog language. The main differences are:
 The rules are compiled in the LDL environment.
 At compile time, there is a notation if a “schema” of the fact base. The fact
table is freely updated at compile time. This differs from Prolog, as Prolog
treats facts and rules are identically. When there is a change, it subjects those
facts to interpretation.
 LDL does not follow the resolution and unification technique that is used in
Prolog systems.
 The LDL execution model is simpler than its Prolog equivalent. It is based on
the operation of matching and the computation of “least fixed points”
The first implementation of LDL was developed in 1987 and was based on a language
called FAD. This was followed by another implementation in1988 that used a
language called SALAD. It has since been through several revisions/optimisations.
The current implementation is a portable system for the UNIX environment.
NAIL! - Not Another Implementation of Logic
The purpose of NAIL! Was to support the optimal execution of Datalog goals. The
assumptions made were one strategy was inappropriate for all logic programs in
general, architecture was developed which could be improved through progressive
additions. NAIL! Is responsible for magic sets and regular recursions. It also made
important contributions on respect to aggregation and negation of logical rules.
Negation and set operators are isolated when the pre-processor is rewriting the NAIL!
Code by replacing disjunction with several conjunctive constraints. After this the
NAIL! code is represented through predicates. The strategy selection module uses the
user’s goal to produce the best execution strategies to achieve it and any related goals.
Nail is a purely declarative query language; Glue is a procedural language used for
non-query activities. The two languages combined are sufficient to write a complete
application. Nail and Glue code are both compiled into the target language I-CODE.
The Nail compiler uses variants of the magic sets algorithm and supports wellfounded models. The Glue compiler's static optimiser uses peephole techniques and
data flow analysis to improve code. The I-CODE interpreter features a run-time
adaptive optimiser that re - optimises queries and automatically selects indexes.
Active & Deductive Databases
Page of 23
17
13/02/16
Module No. CO42009
OODB
Figure 6 NAIL! system architecture
Active & Deductive Databases
Page of 23
18
13/02/16
Module No. CO42009
OODB
CORAL
The CORAL project was developed at the University of Wisconsin in 1988; the idea
was to develop a robust deductive database system.
The CORAL system uses a declarative language and has a c++ front-end, allowing the
user to program declaratively and imperatively.
It is similar to LDL as the declarative language is based on Horn clauses, but CORAL
is considered a programming language that combines the most important features of
SQL and Prolog.
Due to CORAL supporting a variety of semantics and evaluation methods, the
declarative program can be broken down into modules that interact with each other.
Each module has to contain one or more rules which define an export predicate and
may contain local predicates, this is why a module is also known as the definition of a
predicate
Users can guide the query optimisation of each module, by selecting control choices
at each level.
The run-time system will interpret the shallow compiled plan, which allows for very
quick compilation of large program.
Deductive Object Oriented Databases (DOOD)
Object oriented databases have only recently come into mainstream use and the
specifications are continually being updated. An oblivious enhancement of objectoriented database is deductive object oriented database systems. These systems
provide the functionality of deductive databases with the flexibility of object oriented
database systems. Generally speaking, deductive databases and object-oriented
databases have complementary strengths and weaknesses, which is one of the main
reasons for the integration of these to paradigms.
In the development of and design of DOODs, the following approaches have been
taken:
 Language extension – this is the extension of an existing deductive database
language model with object-oriented features. For example, Datalog can be
extended to support identity, inheritance, and other object oriented features.
 Language Integration – this is the integration of a deductive programming
language with an imperative programming language in the context of an object
model or a type system.
 Language Reconstruction – this approach involves reconstructing the object
model and creating a new logic language that includes new object oriented
features. The goal of this strategy is to develop an object logic that captures
the essentials of the object-oriented paradigm and that can also be used as a
deductive programming language in DOODs.
Active & Deductive Databases
Page of 23
19
13/02/16
Module No. CO42009
OODB
VALIDITY
VALIDITY was the first industrial implementation of a deductive object oriented
databases (DOOD). In the development of VALIDITY, the deductive databases
systems; LDL and CORAL were reviewed and were found to offer some object
oriented features that could be considered as DOODs.
VALIDITY combines the deductive capabilities of DDB with the ability to
manipulate complex objects. This implementation provides a mechanism to
declaratively specify knowledge. This mechanism also provides it to integrate rules,
which allow knowledge independence. VALIDITY provides the following
functionality:
 A DOOD data model and language, called DEL (Datalog Extended
Language).
 An engine working along with a client server model.
 A set of tools for schema and rule editing, validation, and querying.
Similar to the ODMG model, DEL offers object oriented features and includes both
declarative and imperative features. The engine of VALIDITY integrates the
traditional features of database systems i.e. persistence, concurrency control,
recovery, backup etc. with the advanced deductive features of deductive database
systems.
Commercial uses of Deductive Databases.
We have discussed two commercial systems, LDL and VALIDITY and we will
describe their applications.
LDL
This system has been applied to these three application domains.



Enterprise modelling - allows data to be structured and processed within the
constraints of the domain. This allows a number of applications to be designed
and managed on the created “metadatabase”.
Hypothesis testing (data dredging) – this domain involves devising a
hypothesis and then changing it into a LDL rule set and query. The query is
then executed against data to test the hypothesis; this is repeated by
reformulating the rules. This is used in the field of microbiology for dredging
data of DNA sequences.
Software reuse – software code for applications is usually coded procedurally
but contains a small portion of rule based LDL. These rules created a
knowledge base that contains information on the definition of each C module
used in a system. A set of rules that define the way a code module behaves
when importing functions and constraints etc.
Active & Deductive Databases
Page of 23
20
13/02/16
Module No. CO42009
OODB
VALIDITY
VALIDITY is used for applying the principles of software engineering when
developing applications. It allows formal specifications to be directly compiled in
DEL. This eliminates mistakes that can occur on any methodologies based on ER
conceptual designs.



E-commerce – VALIDITY is used in the need for complex customer profiles,
which have to match against target descriptions. These profiles are built for
various sources. These profiles contain information on demographic data
viewing history etc. When a customer is matched to a target object,
VALIDITY describes this using these rules.
Rules Governed Process – well defined rules govern the actions to be carried
out by the system. For example a missile system, all known aircraft are
modelled in DEL classes. The locations of aircraft are governed by the rules,
which reflect the regulations. If an enemy aircraft should enter the designated
area the deduction rules identifies the danger.
Knowledge Discovery – aids in the discovery of new data relationships by
analysing the existing data.
Summary
We have described how active and deductive databases work and their internal
architectures. We have also described how these systems can, and have, been
implemented to solve real world problems.
As we have described in the document, deductive database systems can be a great tool
in information systems. We have also shown how deductive databases can be
integrated with object oriented databases systems to give the best of both worlds.
The future of deductive databases?
As have alluded to the in the document, a deductive object oriented database could be
used in e-commerce. A future implementation of this type of system could be on the
Amazon website, where by customer information would be stored in a deductive
database. This would easily allow the database administer to keep detailed
information about customers.
Currently (from our research) we have found no evidence of a deductive database
installation.
Active & Deductive Databases
Page of 23
21
13/02/16
Module No. CO42009
OODB
References
Web based Referrals:
Active @ 21/05/02
http://www.cs.ou.edu/~database/scalable.htm
Active @ 21/05/02
http://www.cs.sunysb.edu/~warren/xsbbook/node12.html
Active @ 21/05/02
http://www.dcs.qmul.ac.uk/SEL-HPC/Articles/GeneratedHtml/db.deduct.html
Active @ 21/05/02
http://www.ida.his.se/ida/adc/intro.html
Active @ 21/05/02
http://www.ida.his.se/ida/research/groups/dbtg/dbtg_adbms.chtml
Active @ 21/05/02
http://www.cs.wisc.edu/coral/
Literature Referrals:
Author
Elmasri Navathe:
Dr. Nick Bassiliades
Subrata Kumar Das
Norman. W. Paton
Title
Fundamentals of Database Systems
Active Object Orientated Databases
Deductive Databases & Logic Programming
Active Database Systems
Active & Deductive Databases
Page of 23
22
13/02/16