Simplifying assumptions for this lecture

  • The database is an abstract collection of objects named A, B, C, … — no tuples, no tables. The algorithms work regardless of object granularity; finer granularity means more parallelism but more tracking overhead (13:22, 13:48).
  • The database has a fixed size: only reads and updates, no inserts or deletes (those introduce phantoms, covered next class) (13:48).

Definition of a transaction

  • A transaction is a sequence of read and write operations on database objects (14:22).
  • It starts with an explicit BEGIN; single statements outside one are wrapped implicitly — autocommit (14:32).
  • It ends with COMMIT or ROLLBACK. Asking to commit is not the same as committing — the DBMS may refuse and kill the transaction, and only the acknowledgement counts (15:02, 15:16).

ACID

Acronym coined in the early 1980s (15:44):

LetterMeaningCovered in
AtomicityAll operations in a transaction happen, or none do (15:44)04
ConsistencyA consistent database plus a consistent transaction yields a consistent database (16:07)05
IsolationTransactions run under the illusion of exclusive access; no intermediate updates from others are visible (17:07, 17:22)06–09
DurabilityOnce committed and acknowledged, changes survive a crash (17:22)10
  • Aside: the instructor notes the "C" was shoehorned in to make the acronym work, and repeats the book's story that the author wanted it there because his wife disliked sugar — "an acid woman" (16:46, 17:07).
  • This lecture stays at the concept level; concrete algorithms start the following Monday (17:44).