We consider the problem of repeatedly evaluating the same (computationally expensive) query to a database that is being updated between successive query requests. In this situation, it should be possible to use the difference between successive database states and the answer to the query in one state to reduce the cost of evaluating the query in the next state. We use first-order queries to compute the differences, and call this process "first-order incremental query evaluation." After formalizing the notion of first-order incremental query evaluation, we give an algorithm that constructs, for each regular chain query (including transitive closure as a special case), a nonrecursive program to compute the difference between the answer after an update and the answer before the update. We then extend this result to weakly regular queries, which are regular chain programs augmented with conjunctive queries having the so-called cartesian-closed increment property, and to the case of unbound...

Traditionally, computational complexity has considered only static problems. Classical Complexity Classes such as NC, P, and NP are defined in terms of the complexity of checking -- upon presentation of an entire input -- whether the input satisfies a certain property. For many applications of computers it is more appropriate to model the process as a dynamic one. There is a fairly large object being worked on over a period of time. The object is repeatedly modified by users and computations are performed. We develop a theory of Dynamic Complexity. We study the new complexity class, Dynamic First-Order Logic (Dyn-FO). This is the set of properties that can be maintained and queried in first-order logic, i.e. relational calculus, on a relational database. We show that many interesting properties are in Dyn-FO including multiplication, graph connectivity, bipartiteness, and the computation of minimum spanning trees. Note that none of these problems is in static FO, and this f...

We consider the problem of repeatedly evaluating the same (computationally expensive) query to a database that is being updated between successive query requests. In this situation, it should be possible to use the difference between successive database states and the answer to the query in one state to reduce the cost of evaluating the query in the next state. We use nonrecursive Datalog (which are unions of conjunctive queries) to compute the differences, and call this process "incremental query evaluation using conjunctive queries." After formalizing the notion of incremental query evaluation using conjunctive queries, we give an algorithm that constructs, for each regular chain query (including transitive closure as a special case), a nonrecursive Datalog program to compute the difference between the answer after an update and the answer before the update. We then extend this result to weakly regular queries, which are regular chain programs augmented with conjunctive queries havin...

Views are a central component of both traditional database systems and new applications such as data warehouses. Very often the desired views (e.g. the transitive closure) cannot be defined in the standard language of the underlying database system. Fortu-nately, it is often possible to incrementally maintain these views using the standard language. For exam-ple, transitive closure of acyclic graphs, and of undi-rected graphs, can be maintained in relational cal-culus after both single edge insertions and deletions. Many such results have been published in the theoret-ical database community. The purpose of this survey is to make these useful results known to the wider database research and development community. There are many interesting issues involved in the maintenance of recursive views. A maintenance al-gorithm may be applicable to just one view, or to a class of views specified by a view definition language such as Datalog. The maintenance algorithm can be specified in a maintenance language of different ex-pressiveness, such as the conjunctive queries, the re-lational calculus or SQL. Ideally, this maintenance language should be less expensive than the view def-inition language. The maintenance algorithm may allow updates of different kinds, such as just single tu-ple insertions, just single tuple deletions, special set-based insertions and/or deletions, or combinations thereof. The view maintenance algorithms may also need to maintain auxiliary relations to help maintain the views of interest. It is of interest to know the minimal arity necessary for these auxiliary relations