Tim Sheard

Automatic verification of database transaction safety

Maintaining the integrity of databases is one of the promises of database management systems. This includes assuring that integrity constraints are invariants of database transactions. This is very difficult to accomplish efficiently in the presence of complex constraints and large amounts of data. One way to minimize the amount of processing required to maintain database integrity over transaction processing is to prove at compile-time that transactions cannot, if run atomically, disobey integrity constraints. We report on a system that performs such verification for a robust set of constraint and transaction classes. The system accepts database schemas written in a more or less traditional style and accepts programs in a high-level programming language. Automatic verification fast enough to be effective on current workstation hardware is performed.

Exceeding the limits of polymorphism in database programming languages

Database programming languages represent an attempt to merge the technologies of programming languages and database management in order to improve the development of data-intensive applications. One aspect of the research on database programming languages is an attempt to exploit polymorphism and higher order functions to integrate query algebra capabilities into programming languages. This has proved to be difficult especially in strongly and statically typed languages, due to the high level of polymorphism and reflection in database query languages. For example, the natural join operation of relational algebra requires examination of the types of the input relations to determine the match predicate and output type, neither of which are easily expressed in current polymorphic programming languages. These aspects of natural join require quite sophisticated polymorphism and some kind of reflection. The reflection must be powerful enough to allow the examination of the input types to determine the match function and to synthesize the output type. It is the difficulty in achieving such power parsimoniously that we examine in this paper.

On the modes and meaning of feedback to transaction designers

An analysis of database transactions in the presence of database integrity constraints can lead to several modes of feedback to transaction designers. The different kinds of feedback include tests and updates that could be added to the transaction to make it obey the integrity constraints, as well as predicates representing post-conditions guaranteed by a transactions execution. We discuss the various modes, meanings, and uses of feedback. We also discuss methods of generating feedback from integrity constraints, transaction details and theorems constituting both generic knowledge of database systems and specific knowledge about a particular database. Our methods are based on a running system that generates tailored theories about database systems from their schemas and uses these theories to prove that transactions obey integrity constraints.

Resolving the tension between integrity and security using a theorem prover

Some information in databases and knowledge bases often needs to be protected from disclosure to certain users. Traditional solutions involving multi-level mechanisms are threatened by the users ability to infer higher level information from the semantics of the application. We concentrate on the revelation of secrets through a user running transactions in the presence of database integrity constraints. We develop a method of specifying secrets formally that not only exposes a useful structure and equivalence among secrets but also allows a theorem prover to detect certain security lapses during transaction compilation time.

Specification and verification of abstract database types

A database system, comprising a schema, integrity constraints, transactions, and queries, constitutes a single abstract data type. This type, which we call an abstract database type, has as its object the database itself. Thus, the value set of such a type is the set of all legal database states, legal in the sense of obeying all the structural specifications of the schema and the semantic prescriptions of the integrity constraints. The database transactions are the operations of the abstract database type and must be functions on the value set of the type. A transaction specification is safe if it defines a function which is closed on the database state set, i. e., any execution of the transaction on a legal database yields a legal database.We propose an approach to the definition of abstract database types which is both usable by typical database designers and which facilitates the mechanical verification of transaction safety. The Boyer and Moore theorem proving technique is used to prove transaction safety theorems using abstract data type axioms and recursive functions generated from the database schema and transaction programs.

Abstract data types in databases: Specification, manipulation and access

The basic data types from which records can be constructed in most database management systems are limited to a few simple types such as integers, reals, and character strings. There are many applications, exemplified by office automation, computer-aided design and geographic information systems, that could benefit from management of databases containing the complex objects typically used in programming these systems. We call databases that contain user defined abstract data types object-extended databases. In this paper we examine three aspects of providing support for object-extended databases: their specification, their manipulation by transactions, and access to them via queries. We show that a database specification scheme grounded formally in three abstract data types, finite sets, tuples and lists, accommodates the integration of databases and arbitrary abstract data types from the points of view of database designers, transaction programmers, and query writers and implemented.1

Formalizing objects for databases using ADABTPL

Object-oriented concepts appear to facilitate the specification of certain kinds of systems, such as design, control and distributed applications. Addition of object-oriented concepts to a database specification system would therefore add to the modelling power and convenience of the system. In order to accomplish a seamless integration of a formal database specification system with object-oriented constructs, we need to supply formal semantics for the object-oriented constructs. In this paper, we use the existing formalism of a database specification type system to formalize the object-oriented concepts of object identity, class, and shared objects.

A recursive base for database programming primitives

High level languages of limited expressiveness have been shown to be very effective in reducing the difficulty of specifying computations, both queries and updates, over databases. The most notable of these are relational algebra and SQL (including its update language). The main problem of these languages is not their limited computational power, but rather that their formality (or lack of it) makes it hard to uniformly integrate them with more powerful relational operations, e. g., transitive closure or least fixpoint operators, and with the operations of other algebras, such as arithmetic and abstract data type algebras. Such problems not only make it difficult to extend the languages felicitously, but reasoning about the properties of integrity constraints and transactions in these languages is much more difficult than is necessary. In this paper, we present a single high level set traversal construct that provides the formal and computational base for relational algebra, associative updates, aggregate functions, nested relations, transitive closure, and complex objects. This construct is not a new construct, but is formalized in a novel manner, and has not been shown previously to support the range of functions to which it is applied here. We also explore a means of using a generalization of this operator to capture formal properties of some computations on complex objects with identifiers and recursively typed data that might be appropriate for database languages.

Incorporating theory into database system development

Abstract Database systems, like all models, must be constrained to represent just those states and transitions which are possible in the world they model. Database integrity constraints, transition constraints and transaction definitions specify the conformity of a database system to the real world. The enforcement of database system constraints is a difficult problem to solve efficiently; this follows from the large amounts of data involved and the complexity of determining minimum required checks. We present a database system development method in which considerable theoretical support in the form of automated theorem proving is brought to bear on the integrity enforcement problem.