Automatic verification of database transaction safety

Reviewer: Antony Peter Stevens

This paper gives details of the design and use of a software system, written in LISP, which the authors claim improves the working life of a systems designer concerned with the safety of a transaction to be applied to a database. The system is used to verify, prior to run-time, whether the proposed transaction is safe, meaning that it does not violate integrity constraints. The verification requires the mechanical proof of a theorem which uses details of databases in general, the specific database schema under study, and the proposed transaction. A number of different types of constraints can be expressed for the specific schema, including functional dependencies, inclusion dependencies, and intersection dependencies. The inference techniques are based on Boyer-Moore computational logic. The authors use an example database of a job matching agency to illustrate many of the features of the system, including those referring to constraints not expressible in an entity-relationship diagram. Although I found the paper hard going, the fault is not entirely mine—the editors of the journal could have insisted on a more precise use of language. Sentences like “currently the system reasons about the natural numbers” could only mean something to people already intimate with the project. Much progress was apparently achieved by optimizing the proofs obtainable for six generic types of transaction (two of them being simple insert and delete). The addition of new types of transaction to the proof system, however, requires considerable skill and knowledge. This paper is lengthy and difficult to review—one can always judge a book on LISP, for example, by comparing it with other books on the same subject. When the description is of a research system it is difficult to judge which aspects merit most attention, since we cannot predict what will be important in the future. As someone who has been responsible for a database group, I look forward to the incorporation of many of these ideas as tools in commercially available database systems. This incorporation should, if nothing else, stimulate the database designer to acquire more respect for the logical ramifications of what she or he does. A different emphasis that could be given to this kind of project might result in a more permanent contribution. Consider the difference between “We have a system that will attempt to verify what you propose” and “We suggest that you only attempt the following because we can then guarantee that it will be safe.” In other words, it may be preferable to restrict data models to certain “standard” types that are safe instead of constructing engines that attempt to verify the safety of what are sometimes arbitrary decisions made by systems designers.