A strategy for semantic integrity checking in distributed databases

Integrity constraints represent knowledge about data with which a database must be consistent. The process of checking constraints to ensure that the update operations or transactions which alter the database will preserve its consistency has proved to be extremely difficult to implement efficiently, particularly in a distributed environment. In the literature, most of the approaches/methods proposed for finding/deriving a good set of integrity constraints concentrate on deriving simplified forms of the constraints by analyzing both the syntax of the constraints and their appropriate update operations. These methods are based on syntactic criteria and are limited to simple types of integrity constraints. Also, these methods are only able to produce one integrity test for each integrity constraint. In Ibrahim, Gray, and Fiddian (1997), we introduced an integrity constraint subsystem for a relational distributed database. The subsystem consists of several techniques necessary for efficient constraint checking, particularly in a distributed environment where data distribution is transparent to application domain. However, the technique proposed for generating integrity tests is limited to several types of integrity constraints, namely: domain, key, referential and simple general semantic constraint and only produced two integrity tests (global and local) for a given integrity constraint. In this paper, we present a technique for deriving several integrity tests for a given integrity constraint where the following types of integrity constraints are considered: static and transition constraints

The necessity for check-on-commit in the protection of the integrity of a database

The value of the data in a database can be increased by specifying and enforcing integrity constraints on the data. There are several methods for the implementation of integrity constraints. The used method in a particular situation depends on the features offered by the used Database Management System (DBMS) However, not all these methods offer the same certainty that the constraints are really enforced. There are also important differences in the methods regarding programming effort and maintainability. In this article integrity constraints and their implementation will have our attention. It will be explained why it is necessary for the protection of the integrity of the data in the database to be able to check integrity on the commit time of a transaction. The report is partially based on an article of the author on transactions [van der Made-Potuijt 1989] and the contribution of the author to an article on constraints [de Brock, Gersteling, Krijger & van der Made-Potuijt 1989]. The different methods used by the vendors of DBMS's for implementing constraints have been investigated by a group of independent dutch database experts (IDT-Holland, which stands for Independent Database Team Holland) The author is the chairman of IDT-Holland. This article offers the theoretical framework for the understanding of the results of the investigation. Certain parts of this report are of tutorial nature

Deriving global and local integrity rules for a distributed database

An important aim of a database system is to guarantee database consistency, which means that the data contained in a database is both accurate and valid. Integrity constraints represent knowledge about data with which a database must be consistent. The process of checking constraints to ensure that update operations or transactions which alter the database will preserve its consistency has proved to be extremely difficult to implement, particularly in a distributed database. In this paper, we describe an enforcement algorithm based on the rule mechanisms for a distributed database which aims at minimising the amount of data that has to be accessed or transferred across the underlying network by maintaining the consistency of the database at a single site, i.e. at the site where the update is to be performed. Our technique referred to as the integrity test generation, derives global and local integrity rules has effectively reduced the cost of constraint checking in a distributed environment

Effect preservation in transaction processing in rule triggering systems

Rules provide an expressive means for implementing database behavior: They cope with changes and their ramifications. Rules are commonly used for integrity enforcement, i.e., for repairing database actions in a way that integrity constraints are kept. Yet, Rule Triggering Systems fall short in enforcing effect preservation, i.e., guaranteeing that repairing events do not undo each other, and in particular, do not undo the original triggering event. A method for enforcement of effect preservation on updates in general rule triggering systems is suggested. The method derives transactions from rules, and then splits the work between compile time and run time. At compile time, a data structure is constructed, that analyzes the execution sequences of a transaction and computes minimal conditions for effect preservation. The transaction code is augmented with instructions that navigate along the data structure and test the computed minimal conditions. This method produces minimal effect preserving transactions, and under certain conditions, provides meaningful improvement over the quadratic overhead of pure run time procedures. For transactions without loops, the run time overhead is linear in the size of the transaction, and for general transactions, the run time overhead depends linearly on the length of the execution sequence and the number of loop repetitions. The method is currently being implemented within a traditional database system

On specifying database updates

AbstractWe address the problem of formalizing the evolution of a database under the effect of an arbitrary sequence of update transactions. We do so by appealing to a first-order representation language called the situation calculus, which is a standard approach in artificial intelligence to the formalization of planning problems. We formalize database transactions in exactly the same way as actions in the artificial intelligence planning domain. This leads to a database version of the frame problem in artificial intelligence. We provide a solution to the frame problem for a special, but substantial, class of update transactions. Using the axioms corresponding to this solution, we provide procedures for determining whether a given sequence of update transactions is legal, and for query evaluation in an updated database. These procedures have the desirable property that they appeal to theorem-proving only with respect to the initial database state.We next address the problem of proving properties true in all states of the database. It turns out that mathematical induction is required for this task, and we formulate a number of suitable induction principles. Among those properties of database states that we wish to prove are the standard database notions of static and dynamic integrity constraints. In our setting, these emerge as inductive entailments of the database.Finally, we discuss various possible extensions of the approach of this paper, including transaction logs and historical queries, the complexity of query evaluation, actualized transactions, logic programming approaches to updates, database views, and state constraints

Checking integrity constraints - how it differs in centralized, distributed and parallel databases

An important aim of a database system is to guarantee database consistency, which means that the data contained in a database is both accurate and valid. Integrity constraints represent knowledge about data with which a database must be consistent. The process of checking constraints to ensure that update operations or transactions which alter the database will preserve its consistency has proved to be extremely difficult to implement, particularly in distributed and parallel databases. In distributed databases the aim of the constraint checking is to reduce the amount of data needing to be accessed, the number of sites involved and the amount of data transferred across the network. In parallel databases the focus is on the total execution time taken in checking the constraints. This paper highlights the differences between centralized, distributed and parallel databases with respect to constraint checking