Raymond A. Lorie

The notions of consistency and predicate locks in a database system

In database systems, users access shared data under the assumption that the data satisfies certain consistency constraints. This paper defines the concepts of transaction, consistency and schedule and shows that consistency requires that a transaction cannot request new locks after releasing a lock. Then it is argued that a transaction needs to lock a logical rather than a physical subset of the database. These subsets may be specified by predicates. An implementation of predicate locks which satisfies the consistency condition is suggested.

System R: relational approach to database management

System R is a database management system which provides a high level relational data interface. The systems provides a high level of data independence by isolating the end user as much as possible from underlying storage structures. The system permits definition of a variety of relational views on common underlying data. Data control features are provided, including authorization, integrity assertions, triggered transactions, a logging and recovery subsystem, and facilities for maintaining data consistency in a shared-update environment. This paper contains a description of the overall architecture and design of the system. At the present time the system is being implemented and the design evaluated. We emphasize that System R is a vehicle for research in database architecture, and is not planned as a product.

The Recovery Manager of the System R Database Manager

The recovery subsystem of an experimental data management system is described and evaluated. The transactmn concept allows application programs to commit, abort, or partially undo their effects. The DO-UNDO-REDO protocol allows new recoverable types and operations to be added to the recovery system Apphcation programs can record data m the transaction log to facilitate application-specific recovery. Transaction undo and redo are based on records kept in a transaction log. The checkpoint mechanism is based on differential fries (shadows). The recovery log is recorded on disk rather than tape.

SEQUEL 2: a unified approach to data definition, manipulation, and control

SEQUEL 2 is a relational data language that provides a consistent, English keyword-oriented set of facilities for query, data definition, data manipulation, and datac ontrol. SEQUEL 2 may be used either as a stand-alone interface for nonspecialists in data processing or as a data sublanguage embedded in a host programming language for use by application programmers and data base administrators. This paper describes SEQUEL 2 and the means by which it is coupled to a host language.

Physical integrity in a large segmented database

A database system can generally be divided into three major components. One component supports the logical database as seen by the user. Another component maps the information into physical records. The third component, called the storage component, is responsible for mapping these records onto auxiliary storage (generally disks) and controlling their transfer to and from main storage. This paper is primarily concerned with the implementation of a storage component. It considers a simple and classical interface to the storage component: Seen at this level the database is a collection of segments. Each segment is a linear address space. A recovery scheme is first proposed for system failure (hardware or software error which causes the contents of main storage to be lost). It is based on maintaining a dual mapping between pages and their location on disk. One mapping represents the current state of a segment being modified; the other represents a previous backup state. At any time the backup state can be replaced by the current state without any data merging. Procedures for segment modification, save, and restore are analyzed. Another section proposes a facility for protection against damage to the auxiliary storage itself. It is shown how such protection can be obtained by copying on a tape (checkpoint) only those pages that have been modified since the last checkpoint.

On extending the functions of a relational database system

Relational database systems are attracting great interest from potential users outside the traditional areas in which such systems have been employed. Features of modern relational systems such as powerful query facilities, data and device independence, concurrency control, and recovery are useful in applications such as engineering design, office automation, and graphics. However, such applications place demands on the system that it must be extended to handle. This paper identifies three of these demands: storing non-coded information of arbitrary length within the database, dealing with aggregate objects as a unit, and improving support for interactive access. Additions to System R, a prototypical relational system, are introduced to satisfy these demands: long fields, for storing non-coded data, and complex objects, which declare the semantic relationships among data items and provide a means for adequately supporting interactive access.

A history and evaluation of System R

System R, an experimental database system, was constructed to demonstrate that the usability advantages of the relational data model can be realized in a system with the complete function and high performance required for everyday production use. This paper describes the three principal phases of the System R project and discusses some of the lessons learned from System R about the design of relational systems and database systems in general.

Efficient and flexible methods for transient versioning of records to avoid locking by read-only transactions

We present efficient and flexible methods which permit read-only transactions that do not mind reading a possibly slightly old, but still consistent, version of the data base to execute without acquiring locks. This approach avoids the undesirable interferences between such queries and the typically shorter update transactions that cause unnecessary and costly delays. Indexed access by such queries is also supported, unlike by the earlier methods. Old versions of records are maintained only in a transient fashion. Our methods are characterized by their flexibility (number of versions maintained and the timing of version switches, supporting partial rollbacks, and different recovery and buffering methods) and their efficiency (logging, garbage collection, version selection, and incremental, record-level versioning). Distributed data base environments are also supported, including commit protocols with the read-only optimization. We also describe efficient methods for garbage collecting unneeded older versions.

Version support for engineering database systems

In engineering applications, multiple copies of object descriptions have to coexist in a single database. A scheme is proposed that enables users to explicitly deal with these object versions. After introducing a basic version model, the problem of rerouting interobject references on the creation of new versions is solved by providing generic references and user-specific environments. Logical version clusters are introduced that allow for the meaningful grouping of versions. Some remarks on implementation and a comparison with other approaches are also included. >

Granularity of locks in a shared data base

This paper proposes a locking protocol which associates locks with sets of resources. This protocol allows simultaneous locking at various granularities by different transactions. It is based on the introduction of additional lock modes besides the conventional share mode and exclusive mode. The protocol is generalized from simple hierarchies of locks to directed acyclic graphs of locks and to dynamic graphs of locks. The issues of scheduling and granting conflicting requests for the same resource are then discussed. Lastly, these ideas are compared with the lock mechanisms provided by existing data management systems.