Incremental Update Process and Apparatus for an Inference System

The present invention relates to computerized inference systems as applied to database systems.

Inference or rule-based systems include a knowledge base (or database) which consists of a set of facts, a set of rules applicable to the facts, and an inference procedure for producing new facts by applying rules to existing facts. Thus, the database changes as a result of inference activity carried out by a rule interpreter that evaluates rules. Typically, moreover, such systems assume a static environment in the sense that changes to the database take place only as a result of rule-program evaluation, so that any change in the initial database requires restarting the system. These systems are not capable of efficiently incorporating modifications to the database of facts resulting from sources other than the actions of the rules themselves.

In the interest of enhanced efficiency of a computerized inference system, the invention provides for updating a current database without restarting the system. Rather, changes are made directly in a current database to reflect a change in the original database from which the current database was produced.

FIG. 1 is a schematic representation of a communication network whose operation may involve use of a preferred method and system in accordance with the invention;

FIG. 2 is a block diagram of a method in accordance with a preferred embodiment of the invention;

FIG. 3 is a block diagram of updating in accordance with a preferred embodiment of the invention;

FIG. 4 is a schematic representation of a status record as may be used in a preferred embodiment of the invention; and

FIG. 5 is a schematic diagram of a system in accordance with a preferred embodiment of the invention.

In real time applications, e.g., communication network management, the database may change independently of the inference process, since usually one cannot afford the luxury of collecting all the relevant facts before starting the inference procedure. Relevant information may arrive after inferencing has already begun. Consider, for example, an expert analyzer for automatically detecting a fault in a communication network that is in operation, and which is continuously producing information relevant to the detection process. In this environment, messages may arrive from time to time that nullify previous assumptions. For example, suppose the expert analyzer has assumed that some link LINK A.sub.-- B is up when the diagnosis of some problem was started, and at some later point, say at iteration n of the standard match-select-act cycle, a message arrives indicating that LINK A.sub.-- B is down. The naive approach for incorporating this late arriving information would be to restart the expert analysis from the beginning. However, considering that network management data is being produced continuously, this strategy may result in an infinite regression and the inference process may never terminate.

In prior art truth maintenance systems designed for incremental evaluation, such as Jon Doyle's "A Truth Maintenance System; Readings in Artificial Intelligence", Morgan Kaufmann 1981, pp. 496-516; A. Barr and E. Feigenbaum, eds., "The Handbook of Artificial Intelligence", Vol 2; Raymond Reiter and Johan de Kleer, "Foundations of Assumption-Based Truth Maintenance Systems", Preliminary Report, Proceedings of AAAI-87, pp. 183-188; and K. R. Apt and J. Pugin: "Maintenance of Stratified Databases Viewed as a Belief Revision System", Proc. 6th ACM Symp. on PODS pp. 136-145 (1987), the systems employed a truth maintenance system which built a dependency graph having nodes that correspond to base and derived facts. A problem with these systems is that in data intensive applications, space requirements for maintaining such dependency graphs become prohibitively expensive. This problem is further exaggerated by the fact that the dependency graph in such systems requires the representation of negative facts in the database in order to support the graph.

Closely tied to the question of incremental updates to a database is the semantics of the underlying rule language. For DATALOG programs, where negation is not allowed in either the head or body of a rule, incremental processing is simple. Consider for example the semi-naive evaluation of the linear DATALOG program that computes the transitive closure of a graph as described in J. D. Ullman's "Principles of Database and Knowledge Base Systems", Computer Science Press, 1989. Incorporation of a newly arrived arc of the graph is easy. The arc is simply added to the differential, and the evaluation proceeds as usual, until a fixpoint is reached. This can be done regardless of whether the new arc arrived before or after the transitive closure evaluation has completed. Since DATALOG is strictly monotonic, incremental update involves only recomputing the consequences of the newly arrived arc.

On the other hand, retraction of an arc from the graph, even in the simple transitive closure example, is a more subtle non-monotonic process. Consider languages that allow negation in the body and head of rules (negation in the head means deletion). Suppose that the fact f is retracted from a database after some inferences that depend on f have occurred. The high level view of subsequent processing that must take place is the following: the facts that were derived from f (and recursively, their derivatives) must be backed out or undone, and then the facts that can be derived from .sup.- f (and their derivatives) must be redone. For DATALOG programs (that do not have negative atoms in the rules), no actions are derived from negative facts. Therefore, for a retracted fact we only need an undo phase, and for an asserted fact we only need a redo phase. However, for more powerful rule languages, we need both an undo and a redo phase to incrementally update the database.

These two phases are not always straightforward. Rule languages such as OPS5 and DATALOG .sup.* usually operate in match-select-act cycles, and at each cycle (or iteration), some conflict resolution strategy is applied (note: in DATALOG, the symbol indicates that negations are allowed in bodies and the symbol * indicates that negations are allowed in the heads. A more detailed explanation of the DATALOG .sup.* language is described infra.) Now, consider redoing the consequences of f for the above example, This involves matching all the rules (or some sub-set of them in a language such as STRATIFIED DATALOG) and considering the instantiations that have f in the body. Suppose that the head of such an instantiation is add.sub.-- e. This does not mean that we can simply add e to the database during the redo phase for the following reason. The incremental procedure must produce the same result as if f were in the initial database. If f were in the initial database, it is possible that the add.sub.-- e operation would have been eliminated by a conflict resolution strategy within the language procedure. In the language DATALOG, add.sub. -- e would have been cancelled out by a delete.sub.-- e operation in the same cycle; moreover, the delete.sub.-- e operation may not be a consequence of f. Similarly, in OPS5 add.sub.-- e would not have been executed had there been a more recent instantiation in the cycle. Therefore, the incremental procedure must have enough information to determine for each redo instantiation whether or not it would have been eliminated by the conflict resolution strategy. Furthermore, this information obviously depends on the conflict resolution strategy, which in turn depends on the rule language.

Now consider the data reduction paradigm for distributed and parallel rule processing, as described in S. J. Stolfo, D. P. Miranker and R. Mills, "A Simple Processing Scheme to Extract and Load Balance Implicit Parallelism in the Concurrent Match of Production Rules", Proceedings of the A.F.I.P.S. Symp. on Fifth Generation Computing, AFIPS, 1985. It stipulates that each processor evaluates the original rule program, but with less data. The operations of each processor that result from the evaluation (e.g. add-a-fact or delete-a-fact) are transmitted to other processors that may use these to derive other operations. Now, if the processors are synchronized at each cycle, meaning that they all complete their evaluation and transmission in a certain cycle before any processor proceeds to the next one, then incremental evaluation is not necessary. However, this implies that the evaluation proceeds at the speed of the slowest processor at each iteration, which is not acceptable in a distributed setting. Suppose therefore that the evaluation proceeds asynchronously. Then it is possible that a processor p.sub.1 that is evaluating at cycle 5 receives an add.sub.-- e from a processor p.sub.2 that is evaluating at cycle 3. This means that p.sub.1 has to incorporate e into its local database of cycle 3. Then the problem it faces is exactly the problem of incremental rule processing: it has to undo the consequences of -e at cycle 3, and redo the consequences of e at cycle 3, but without backing its whole rule evaluation to cycle 3. In other words, individual processors need to have the ability to incorporate changes from other processors in arbitrary previous iterations. In contrast, for real time rule processing the update is always to the input database, namely to cycle 0.

The present invention provides a method and apparatus for performing only those actions in an inference mechanism that are necessary to incrementally bring the database to a consistent state.

The present invention also provides a method and apparatus where incremental updating may be performed in a recursive manner in which it can operate for an arbitrary cycle update such that it may be applied to asynchronous parallel-and-distributed rule processing by data reduction.

The technique herein described for incrementally updating a database can be summarized as follows. In the context of the previous example, wherein it was initially assumed that link LINK A.sub.-- B was up and, subsequent to commencing inferential processing, a message arrived indicating link LINK A.sub.-- B was down, a system employing the present technique would only undo the consequences of the initial assumption that LINK A.sub.-- B was up, and redo the consequences of the newly received fact that LINK A.sub.-- B is down. In other words, only the consequences associated with the newly arrived information would be revised.

This simplified example is functionally illustrated in FIGS. 1-3. In FIG. 1, LINK A.sub.-- B represents the connection between two communication nodes, node A and node B in a communication system. In this example, the goal is to establish a communication line from our point of origin, namely node W, to our destination, node E. The nodes are connected by a series of links which can either be up, useable for connection from an initial node to a destination node, or they can be down, wherein no connection can be made between the nodes. A connection can only be made by connecting enough continuous links to directly connect the point of origin to the point of destination under constraints developed in the inference program. In real life applications, constraints may include the selection of links which have less traffic; however, in this example we will simply choose the selection of the minimum number of links to connect any two points. If we commence with the assumption that LINK A.sub.-- B is up and the system's inferential process causes a connection through LINK A.sub.-- B, the consequences of having LINK A.sub.-- B go down would be catastrophic to the system's goal. Simply stated, the system will have established a faulty connection. Thus, if a processing system received a message adding the new fact that link LINK A.sub.-- B was down to the initial database, as illustrated in FIG. 2, the system would need to address the new fact. In the system of the present invention, rather than restart the inference process from the beginning, the system would only undo the consequences of LINK A.sub.-- B being up, then these LINKS would be disengaged, and the system would redo the consequences of LINK A.sub.-- B being down, as asserted in FIG. 3. In other words, the system would find another route for connecting nodes W and E under the prescribed constraints of the program without starting over. For instance, the system would disengage LINK A.sub.-- B, LINK T.sub.-- A and LINK B.sub.-- C; engage LINK T.sub.-- X, LINK X.sub.-- Z and LINK Z.sub.-- C; and maintain the other previous links, namely LINK W.sub.-- V, LINK V.sub.-- U, LINK U.sub.-- R, LINK R.sub.-- T, LINK C.sub.-- D, and LINK D.sub.-- E.

In another example using FIG. 1, if the inference system had previously established that a connection could be made from nodes W to E by passing through nodes T and C, and that nodes T and C could be connected by either routes T.sub.-- A.sub.-- B.sub.-- C or T.sub.-- X.sub.-- Z.sub.-- C, then a subsequent update message indicating LINK A.sub.-- B to be down would require the system to backtrack only up to the point where it was inferenced that nodes T and C could be connected through one of two paths. Because it had been previously inferenced that nodes T and C would be connected via path T.sub.-- X.sub.-- Z.sub.-- C, the system would trace only need to undo the inference that LINK A.sub.-- B was up and that path T.sub.-- A.sub.-- B.sub.-- C could be used as a path between nodes T and C. Thus by starting the undo consequences at the inference iteration using the fact LINK A.sub.-- B to be up and by simply undoing those consequences, the system would trace back to the inference finding another alternative node path, namely, LINK T.sub.-- X, LINK X.sub.-- Z and LINK Z.sub.-- C, to exist. The redo step would simply reassert the consequence of eliminating the alternate path from nodes T to C using LINK A.sub.-- B is a useable path. Thus by concentrating the analysis on the immediate consequences of LINK A.sub.-- B being down and using previously asserted consequences that are not affected by LINK A.sub.-- B being down, namely that nodes T.sub.-- C could be connected through an alternative path, the system can be more efficiently operated than if the system would have to be started anew or if some complex tree structure had to be retraced or recalculated.

A more detailed explanation of the present invention will be provided in the context of the language DATALOG .sup.*, wherein an application of the present invention is provided. The reason for choosing this language is that it has several attractive characteristics. First, it is set-oriented, a typical feature of database rule languages. Second, it is sufficiently rich, allowing negation in the body and in the head of rules. Third, it is abstract enough to enable identifying principal concepts that relate to incremental evaluation of rules, independently of the idiosyncrasies of commercial languages.

The Language DATALOG .sup.*

In this section, the basic terminology for DATALOG .sup.* is introduced. Intuitively, rules in DATALOG .sup.* have the general form:

A positive head implies the corresponding fact should be added to the database on rule firing, whereas a negative head implies the corresponding fact should be removed from the database, if it exists.

Formally, DATALOG .sup.* programs are built from atoms, which are predicate symbols followed by a list of arguments. The arguments may be either variables or constants. For simplicity, constants are natural numbers. A literal is either an atom, also called a positive literal, or a negated atom, also called a negative literal. If all arguments are constants, we call the literal a fact. A rule consists of a literal, the head of the rule, and possibly a conjunction of positive and negative literals which form the body of the rule. Variables are denoted by capital letters, and predicate names are strings built from lower case letters. An example of a rule is

where the head of the rule is always to the left of :-, and the body to the right. If Q is a set of facts, then Q denotes the set having the same literals as Q, but with their sign reversed.

A program is a set of rules. A program is called safe if each rule fulfills the following conditions:

(1) Each variable in the head of the rule also occurs in the body of the rule, and (2) Each variable in a negative literal in the body also occurs in a positive literal of the body. We require that programs be safe.

The instantiation of a rule r is defined with respect to a database, i.e. a finite set of positive facts; it is an assignment of constants to the variables in r such that all the positive facts in the body are in the database, and the negative ones are not.

The operational semantics of the evaluation are as follows. The input to a program is a database. The output of a program P for an input I, denoted O(P,I), is the database obtained at the end of the following iterative procedure.

Incremental Evaluation Update Procedure

Basically, the inference procedure of the present invention consists of two phases: DO and INCR.sub.-- UPDATE. The DO phase consists of the procedure DATALOG .sup.*.sub.-- SEMANTICS of the previous section. After the Act step, there is a check to determine whether an interrupt message has been received. If so, the INCR.sub.-- UPDATE procedure is invoked. The incremental evaluation update stage consists of an UNDO phase and a REDO phase. The interrupt message consists of a set Q, of positive and negative facts, denoting additions and deletions, respectively, to be applied to the input database.

Consider the DO phase. With each fact f that was in the database at some iteration, we associate a fact chain that enables us to determine the status (in or out of the database) of f at each iteration. The structure of the fact chains will be described infra.

Suppose that the positive fact f is in Q, and f was not in the input database. Then we first execute the match step of the inference procedure, considering only instantiations with respect to the input database in which f appears in the body of the instantiated rule. This is the UNDO phase. Let U be the set of operations in the heads of these instantiations. Each operation in U will have to be undone. Second, we execute the match step of the inference procedure, considering only instantiations with respect to the input database, in which f appears in the body of the instantiated rule. This is the REDO phase. Let R be the set of operations in the heads of these instantiations. Each operation in R will have to be redone.

Now suppose that +e (or simply, e) is in R, indicating that the fact e would have been added to the database in the first cycle, had f been in the input database. This does not necessarily mean that the incremental procedure should repeat the redo phase with e. It is possible that in the first cycle e was added to the database not only as a result of the instantiation that has f in the body, but also as a result of another instantiation. Then e is not new in the second iteration, and it should be eliminated from the incremental evaluation of the subsequent cycles. In other words, based on the sets U and R we should determine which facts are new. Only they should be carried forward, to the next cycle in the incremental evaluation.

Generally speaking, given UNDO and REDO sets, the incremental procedure, call INCR.sub.-- UPDATE, determines which facts must be viewed as having changed their status as a result of the incremental procedure at the specified iteration. The set of facts that are determined to have changed their status is called the NEW set. This set is the focus of interest of procedure INCR.sub.-- UPDATE. The procedure recursively redoes all the inferences that descend from the NEW set, and it also recursively undoes the inferences that stem from NEW. In other words, UNDO and REDO sets are generated for successive iterations, given the initial ones. Formally, procedure INCR.sub.-- UPDATE is as follows.

recursive procedure INCR.sub.-- UPDATE (U,R,i)

Comment: This procedure is invoked by the inference system, as an exception handler on receiving incremental modifications to past assumptions made on the database. The procedure modifies the database, given two sets of operations, U and R, that have to be incorporated at some past evaluation iteration i. Each set contains positive and negative facts. The set U represents a collection of facts whose addition or deletion (depending on the sign) has to be undone at iteration i. It is called the undo set. The set R represents a collection of facts whose addition or deletion has to be incorporated at iteration i. It is called the redo set.

The initial invocation is INCR.sub.-- UPDATE(.phi.,Q,0), where Q is the set of facts in the interrupt message.

The computations in steps (7) and (8) of the above recursive procedure is clearly less expensive, in general, than computing all instantiations of rules at iteration i.

In order to demonstrate the correctness of the INCR.sub.-- UPDATE procedure, we need to show that if an incremental update message to incorporate a positive or negative fact f in the input database is received while the processor is at iteration t>0, then the final database produced would be the same as in the case where f is in the input database.

FACT CHAINS

As mentioned earlier, for each fact f there is a chain C(f) that enables the system to determine the status of f at each iteration. For each iteration in which f was added or deleted (either in the DO or the REDO phases) we keep a count of the number of times it was added, and the number of times it was deleted. In other words, for each iteration we keep a state record in C(f), which has the structure illustrated in FIG. 4.

Fact chains are different fundamentally than timestamps, typically used in concurrent data base update applications. Fact chains determine the status of facts in or out of the database for each iteration of an iterative inferential process. Timestamps, see Ullman, are used to label individual transactions with a unique time that a transaction was initiated. Timestamps are thus used to ensure concurrency control of multiple concurrent updates to a database. It is assured that no two transactions have the same timestamp thus ensuring that multiple transactions are performed in a serial order. Fact chains, on the other hand, are associated with the data records in the database, not the transactions performed against the data, and indicate the status of a fact at some inference iteration cycle.

In FIG. 4, the Iter field indicates which iteration a particular state record corresponds to, and the Status field holds the status of the fact (In or Out of the database) at that iteration. The Added and Deleted fields are necessary to count the number of occurrences of additions and deletions (even though the operational semantics do not require so), since one does not know how many of these operations will be undone in the future.

INITIALIZATION AND MAINTENANCE OF THE FACT CHAINS

Each fact present in the initial input database is called an initial fact. We set up fact chains for the initial facts at startup time. All such facts have fact chains initialized with a single state record s, with s.Iter set to 0, and s.Status set to In. Additional chains are established for those facts which are added or deleted during inference, and for which no chain was established initially. Chains established during inference consist of a state record at iteration 0 with a status of Out, and a state record for iteration t, where t is the iteration when f was added or deleted during the inference process.

Maintenance operations on chains occur in all phases of incremental evaluation. DO and REDO phases increment the count in the Added or Deleted fields of the state record, depending on whether the fact in question is added or deleted as a result of rule firing (note that facts are never physically deleted, only their delete count is incremented). In contrast, UNDO decrements the appropriate field. The procedure that manipulates the chains during DO and REDO phases is REDO.sub.-- MAINTAIN.sub.-- CHAIN. Procedure UNDO.sub.-- MAINTAIN.sub.-- CHAIN manipulates chains during the UNDO phase. REDO.sub.-- MAINTAIN.sub.-- CHAIN receives a set of facts and an iteration number, and increments the counts of the appropriate fields of the state record indicated by the iteration number, whereas UNDO.sub.-- MAINTAIN.sub.-- CHAIN decrements the counts. As an example, consider the effect of the procedure call

COMPUTING THE NEW SET

The status of a fact f for any iteration is determined by examining the Added and Deleted fields in the state record for that iteration. This applies to the DO phase and to the incremental update phase as well. In procedure INCR.sub.-- UPDATE, the final value of the status of a fact f and the set of new facts at an iteration is computed with the COMPUTE.sub.-- NEW function.

COMPUTE.sub.-- NEW takes an evaluation iteration number i as argument, and scans the chains for the facts that were changed during the UNDO or REDO phases. If both the Added and Deleted fields are zero in the state record for i, or if both are non-zero, then we revert to the status at iteration i--1. Otherwise, if the Deleted field is 0, we interpret that as indicating that the fact was only added, and the status is set to In, whereas if the Added field is 0, the status is set to Out. A fact is flagged new if its newly computed status is the inverse of its former status. The outline of procedures INITIALIZE.sub.-- CHAINS, UNDO.sub.-- MAINTAIN.sub.-- CHAIN, REDO.sub.-- MAINTAIN .sub.-- CHAIN, and COMPUTE.sub.-- NEW are shown below.

APPLICABILITY OF INCR.sub.-- UPDATE TO STRATIFIED DATALOG

For stratified DATALOG, the rule program interpreter evaluates the rules one stratum at a time. (For a general discussion relating to stratified DATALOG See Ullman, supra). Iteration numbers are then replaced by the pair (Stratum.sub.-- Number, Iter.sub.-- Number), which may be regarded as our new iteration counter. This adaptation of this implementation calls for the adoption of a modified numbering scheme for chain maintenance operations, and for matching rules in steps (7) and (8) of procedure INCR.sub.-- UPDATE. First, instead of ordering the fact chains by iteration number, we now use the order imposed by lexicographic ordering of the (Stratum.sub.-- Number, Iter.sub.-- Number) pairs. Therefore, in the incremental update phase, instead of referring to iteration i--1, we refer to the previous iteration in the lexicographic order. Second, in steps (7) and (8) of procedure INCR.sub.-- UPDATE, we restrict the matches to rules in the particular stratum being considered. With these simple modifications, INCR.sub.-- UPDATE is applicable to stratified DATALOG.

DISTRIBUTED SYNCHRONOUS EVALUATION OF DATALOG .sup.* PROGRAMS

In a data reduction paradigm for DATALOG (without negation), instantiations of the rules in a given program are partitioned among a set of processors. The original program is evaluated on each processor, but with less data. The partition of the instantiations is achieved by restricted versions of the original program, such that each restricted version is evaluated at one processor. In general, it is necessary for the processors to communicate intermediate results to each other by message passing. This paradigm is extended to DATALOG .sup.*. In particular, we discuss a synchronous variation of this extension, whereas in the next section, we discuss an asynchronous one.

Formally, let P={r.sub.1, . . . r.sub.m } be a program with m rules and {P.sub.0, . . . , P.sub.k-1 } be a set of k>1 processors. For each rule r.sub.i, we designate k restricting predicates, h.sub.ij (X.sub.1, . . . X.sub.qi), for 0.ltoreq.j.ltoreq.k-1. The arguments X.sub.1 . . . , X.sub.qi are the same for all the k predicates, and by definition, all the arguments are variables of r.sub.i. We require that for each instantiation of the variables X.sub.1, . . . , X.sub.qi, the predicate h.sub.ij is true for exactly one j. Denote by r.sub.ij the restricted version of the rule r.sub.i having the restricting predicate h.sub.ij (X.sub.1, . . . , X.sub.qi) appended to its body. Denote by p.sub.j the restricted version of P consisting of the set of rules {r.sub.ij .vertline.1.ltoreq.i.ltoreq.m}. The set {P.sub.0 , . . . , P.sub.k-1 } is called a data reduction parallelization strategy for P.

The set of processors {P.sub.0, . . . , P.sub.k-1 } cooperate in evaluating P in parallel as follows. The database is partitioned among the processors such that each tuple has a unique Data Handler processor (DH) at which it resides. The DH processor for each tuple is computed by a hash function associated with the relation. For example, the tuple a(X,Y) such that h(X)=i resides at processor i.

In the course of the evaluation, a tuple may be added and deleted by multiple processors. In databases, concurrency control is concerned with guaranteeing that the result of all transactions is equivalent to some serial execution of those transactions. In our case, we can view the p.sub.i 's as executing separate transactions, where a transaction consists of the actions executed by P.sub.i at a given iteration. However, it is not enough to provide standard concurrency control on accesses to the distributed database, as some serial executions may not be acceptable according to the semantics. It becomes necessary to provide some means to act as an arbiter over database adds and deletes. This is realized by the Data Handler for each tuple. One can think of a data handler as a monitor program that runs on each processor that stores tuples and sequentially services requests for tuples by other processors. The data handlers are responsible for realizing the correct semantics with respect to database updates, as will be demonstrated below. For this variation, fact chains are not necessary.

Restricted versions of the rules are distributed to the processors, as described earlier. These are called the Rule Handlers (RH) for program P. When a rule handler requires a fact for matching, it requests it from the appropriate data handler. Determining the appropriate data handler involves a trivial evaluation of the associated hash function.

Each processor P.sub.i performs the instantiations of P.sub.i as in the normal evaluation procedure. Any newly inferred facts are transmitted to the appropriate data handlers for storage. All processors execute in step with respect to the evaluation iteration number, i.e., all processors have the same iteration number, which is used for synchronization. The following procedure is executed by Rule Handler i at iteration j, in the synchronous variation of the data reduction paradigm.

Increased efficiency is implied by the fact that p.sub.i evaluates a restricted version, meaning it does fewer instantiations compared to the case where the original program P is evaluated.

DISTRIBUTED ASYNCHRONOUS EVALUATION OF DATALOG .sup.* PROGRAMS

A major problem with the procedure described above is that no processor can proceed faster than the slowest one at each iteration. Obviously, we desire asynchronous operation of each P.sub.i, but this gives rise to other problems which motivate the use of the INCR.sub.-- UPDATE procedure.

Suppose some processor P.sub.i deletes a fact f at iteration t.sub.1, which was used earlier by processor p.sub.j. Suppose also that p.sub.j is now at iteration t.sub.2, and t.sub.2 >t.sub.1. Unless handled properly, this situation may cause the operational semantics of DATALOG .sup.* to be violated.

Recall that INCR.sub.-- UPDATE allows the incremental incorporation at iteration t.sub.2, database changes occurring at iteration t.sub.1 <t.sub.2. The message indicating deletion of f by P.sub.i in the example above can be viewed as an interrupt message. Thus, by using the procedure INCR.sub.-- UPDATE, p.sub.j can update its database to a consistent state.

We outline below the asynchronous variation of the data reduction paradigm (henceforth called ASYNC.sub.-- DATA.sub.-- REDUCTION) for parallel and distributed evaluation of DATALOG .sup.* programs. As before, we have rule handlers that own restricted versions of the rules of the original program. Furthermore, when the database is partitioned among the processors, each data handler maintains a chain for each fact. The processors operate asynchronously and each rule handler keeps its own iteration count.

More precisely, in ASYNC.sub.-- DATA.sub.-- REDUCTION each rule handler, RH.sub.i, executes steps (1) and (2) as in SYNC.sub.-- DATA.sub.-- REDUCTION, at each iteration j. At step (3), instead of synchronizing, RH.sub.i checks whether or not it received an interrupt message from a data handler; such a message contains a set of NEW (positive and negative) facts at an iteration number. If this is not the case, RH.sub.i simply proceeds to the next iteration. If the message pertains to an iteration number higher than j, it is ignored and RH.sub.i proceeds to the next iteration.

Otherwise, RH.sub.i executes steps (7) and (8) of INCR.sub.-- UPDATE for each interrupt message, in increasing iteration number order (meaning that it will not process a NEW set for iteration 500 if a NEW set for iteration 400 is in the queue). RH.sub.i sends the resulting UNDO and REDO sets to the data handlers (note that each set will be partitioned, with each partition being sent to a different data handler). After processing all interrupt messages RH.sub.i proceeds to iteration j+1.

Each DH.sub.i continuously receives REDO and UNDO sets, each associated with an iteration number. DH.sub.i processes these in increasing iteration number order. For each UNDO (REDO) set associated with an iteration, say k, DH.sub.i performs UNDO.sub.-- MAINTAIN.sub.-- CHAIN (REDO.sub.-- MAINTAIN.sub.-- CHAIN), and COMPUTE.sub.-- NEW. The resulting NEW set and the iteration number k are broadcast to the RH's. If both an undo and a redo set exist for k, the UNDO.sub.-- MAINTAIN.sub.-- CHAIN and REDO.sub.-- MAINTAIN.sub.-- CHAIN will both be performed before COMPUTE.sub.-- NEW. A possible implementation for the above system is shown in FIG. 5.

It should be clear that many optimizations of the transmission sets are possible, as discussed in O. Wolfson and A. Ozeri; "A New Paradigm for Parallel and Distributed Rule-Processing"; Proceedings of the ACM-SIGMOD 1990. International Conference on Management of Data, Atlantic City, N.J., May 1990.

The procedures described herein can be used for two seemingly unrelated purposes: first, to maintain the inference database in an incremental fashion in a dynamic environment where the input may be updated after inferencing is under way, and second, for the asynchronous version of the data reduction paradigm.

The INCR.sub.-- UPDATE procedure can be implemented in a communication network management system and other systems in which incremental update capabilities are necessary in a real time environment.

USE OF CONFLICT RESOLUTION META REDACTION RULES

The incremental update processing procedure herein described may also be effectively used in combination with meta-level conflict resolution rules, referred to as Meta Redaction Rules. These rules regard the set of instantiations at each cycle as working memory, and remove from the set of instantiations those members that are considered to be conflicting instantiations according to these rules. After redaction of the conflicting instantiations, all the remaining instantiations in the conflict set can be fired in parallel. The meta-redaction rules seek to prevent conflicts which may subsequently develop and enhance the operation of any system by avoiding future conflicts in the instructions resulting in subsequent rule firings. Thus, the meta redaction rule may be defined to provide a means to check for conflicts between multiple instantiations of the same rule in a parallel application.

An example of the syntax defining a meta redaction rule is as follows:

In the above example, the LHS of a redaction rule consists of the symbol m, followed by the meta-rule name, followed by specifications of rule instances in the conflict set and an arbitrary arithmetic predicate applied to variables bound in the specification of the instances. The conflicting rule instances are chosen such that if all those instances are present in the conflict set and the arithmetic predicate holds, one or more of the instances must be redacted. The RHS of a redaction rule consists of the specification of those instances that must be redacted from the conflict set.

Although the procedures and components listed above represent an embodiment of the present invention, it will be appreciated by those skilled in the art that many modifications could be made to the procedures and components without modifying from the spirit of the present invention For instance, the procedures could be modified for implementation in other rule-based languages. In addition, the state record could be modified and maintained in a number of different ways to provide the same basic function of producing a fact chain without the need for a dependency graph.