Transactions

Transaction theory is a large topic in its own right. As mentioned in Chapter 4, however, it doesn't have much to do with the relational model as such (at least, not directly), and for that reason I don't want to discuss it in detail here. In any case, you're a database professional, and I'm sure you're familiar with basic transaction concepts. The standard reference highly recommended, by the way is Transaction Processing: Concepts and Techniques, by Jim Gray and Andreas Reuter (Morgan Kaufmann, 1993). All I want to do here is briefly review the so-called ACID properties of transactions.

ACID is an acronym; it stands for atomicity - consistency-isolationdurability. Here are brief explanations:

Atomicity

Transactions are "all or nothing."

Consistency

Any given transaction transforms a consistent state of the database into another consistent state, without necessarily preserving consistency at all intermediate points.^[*]

^[*] A database state is consistent if and only if it satisfies all defined constraints (consistency is just another word for integrity in this context).

Isolation

Any given transaction's updates are concealed from all other transactions, until such time as the given transaction commits.

Durability

Once a given transaction commits, its updates survive in the database, even if there's a subsequent system crash.

Now, one argument in favor of transactions has always been that they're supposed to act as "a unit of integrity" (that's what the consistency property is all about). But I don't believe that argument; as I've more or less said already, I believe that statements have to be that unit, and that database constraints must therefore be satisfied at statement boundaries. The section immediately following gives my justification for this position.