deductive databases - web viewe-commerce – validity is used in the need for complex customer...

Table of Contents

Active Databases........................................................................................................................................1What are Active Databases?..................................................................................................................1Common Databases versus Active Databases.......................................................................................1Active Rules..........................................................................................................................................2Events....................................................................................................................................................2

Primitive events................................................................................................................................2Composite Events.............................................................................................................................3

Rule Execution......................................................................................................................................4Coupling Modes...............................................................................................................................5Deferred Coupling............................................................................................................................5

Active Database Applications...............................................................................................................6Development & Implementation...........................................................................................................6Example SQL........................................................................................................................................7Transaction Execution...........................................................................................................................7Types of Active Databases....................................................................................................................8

STARBURST...................................................................................................................................8POSTGRES......................................................................................................................................8ACOOD............................................................................................................................................8ACOOD............................................................................................................................................9

Active and Deductive combined.........................................................................................................10Active Example...................................................................................................................................10

Military Intelligence.......................................................................................................................10

Active Faults.......................................................................................................................................11

Deductive Databases................................................................................................................................12Introduction.........................................................................................................................................12Specifications......................................................................................................................................12What are they used in?........................................................................................................................12Inference engine (or deductive mechanism).......................................................................................13Bottom - Up (forward chaining).........................................................................................................13Top - Down (backward Chaining)......................................................................................................13Clausal Form & Horn Clauses............................................................................................................15Interpretation of Rules.........................................................................................................................15Logic programming.............................................................................................................................15Prolog/Datalog notation......................................................................................................................16Stratified Negation..............................................................................................................................16LDL - Logic Data Language...............................................................................................................16NAIL! - Not Another Implementation of Logic.................................................................................17CORAL...............................................................................................................................................19Deductive Object Oriented Databases (DOOD).................................................................................19VALIDITY..........................................................................................................................................20Commercial uses of Deductive Databases..........................................................................................20

LDL................................................................................................................................................20VALIDITY.....................................................................................................................................21

Summary.............................................................................................................................................21The future of deductive databases?.....................................................................................................21References...........................................................................................................................................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 componentsAn 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 24 05/05/23


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 24 05/05/232

Object

Message

Result

Method execution

Event detector Signalling

Before event

After event

E1 & E2

E1 E2

Rule

Signalling Subscription


Detection 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


Figure 1 Event detection model

Figure 2 Subscription of Events

3


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 objectso Enabling and disabling of rules.



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 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, NAOSInstead 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



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 EventWHEN INSERTED

IF EXISTS (SELECT*FROM INSERTED WHERE CNO IS NOT NULL) ConditionTHEN UPDATE CLUBNUMBER AS C Action

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 implementedEvaluate 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 asRow-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.


Parser

Traffic CopRule Definition Module

Executer

Rule Manager

PlannerQuery Re-writeRule system

Parse TreeParse Tree

Set of Plan

Tuple

Tuple

Access Methods


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.


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

Figure 3 POSTGRES event system model

8

Application

ACOOD3

4

ONTOS Client EG

21

56

Flow

Reply

EG – Event Generator


ACOODACOOD 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.


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.

Figure 4 ACOOD event system model

9


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 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.



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



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



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:



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



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



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 well-founded 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.



Figure 6 NAIL! system architecture



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 predicateUsers 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 object-oriented 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.



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.

LDLThis 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.



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.



References Web based Referrals:Active @ 21/05/02http://www.cs.ou.edu/~database/scalable.htm Active @ 21/05/02http://www.cs.sunysb.edu/~warren/xsbbook/node12.htmlActive @ 21/05/02http://www.dcs.qmul.ac.uk/SEL-HPC/Articles/GeneratedHtml/db.deduct.htmlActive @ 21/05/02http://www.ida.his.se/ida/adc/intro.htmlActive @ 21/05/02http://www.ida.his.se/ida/research/groups/dbtg/dbtg_adbms.chtmlActive @ 21/05/02http://www.cs.wisc.edu/coral/

Literature Referrals:

Author TitleElmasri Navathe: Fundamentals of Database SystemsDr. Nick Bassiliades Active Object Orientated DatabasesSubrata Kumar Das Deductive Databases & Logic ProgrammingNorman. W. Paton Active Database Systems


http://www.cs.wisc.edu/coral/

http://www.ida.his.se/ida/research/groups/dbtg/dbtg_adbms.chtml

http://www.ida.his.se/ida/adc/intro.html

http://www.dcs.qmul.ac.uk/SEL-HPC/Articles/GeneratedHtml/db.deduct.html

http://www.dcs.qmul.ac.uk/SEL-HPC/Articles/GeneratedHtml/db.deduct.html

http://www.cs.sunysb.edu/~warren/xsbbook/node12.html

http://www.cs.ou.edu/~database/scalable.htm

deductive databases - web viewe-commerce – validity is used in the need for complex customer...

Documents