Beginning SQL

Chapter 11
The information that follows comes with a huge caveat: Virtually everything that follows varies depending
on your specific implementation. Transaction and locking implementation is very specific to a particular
vendor’s product and the details vary, sometimes immensely. The best you can expect from this
book is to get a feeling for what is possible, and then you should read the documentation for the DBMS
you are working with for the exact details of how that product works.
Introducing Transactions
302
In SQL, a transaction is a group of SQL statements taken together as a logical unit of work. Oftentimes,
the process of entering data requires adding data into several different tables and perhaps modifying data
in a couple of tables. If any of those operations fail, then the entire set of operations must be undone. In
order to ensure that you perform all of the operations or none of the operations, you use transactions.
In order for a group of statements to be considered a transaction, it must pass the ACID test. ACID is an
acronym that stands for the following:
❑ Atomic: This property refers to the all-or-none behavior of the group of statements. If any of the
statements fail, then the entire group of statements must be undone or rolled back. Only when
all of the statements execute without error are the results of the entire group of statements saved
to the database. When a patient checks in to the hospital, a new patient record may need to be
created or an existing record updated. A check-in record needs to be created. A bed needs to
be assigned to that patient. It would not be good to get the patient all the way checked in but
not assign a bed to the patient. Losing patients is considered very bad practice.
❑ Consistent: The database must be in a consistent state at the end of the transaction. The SQL
statements must be applied without error, and all database structures must be correct and
saved. A consistent state really means that as the DBMS makes decisions on available data,
updates to data do not overwrite previous updates, and records are not added or deleted based
on data that is not a real, permanent part of the database.
❑ Isolated: Data that transactions change must not be visible to other users before or during the
changes being applied. Other database users must see the data as it would exist at the end of the
transaction so that they do not make decisions or errors based on data that is no longer valid. If
a product order is rolled back because the customer decides at the last minute to order a different
part, another order should not be back-ordered because the first order was momentarily visible
and there appeared to be insufficient stock to fill the next order.
❑ Durable: At the end of the transaction, the database must save the data correctly. Power outages,
equipment failures, or other problems should not cause partial saves or incomplete data
changes. Most DBMSs manage this requirement through the use of transaction logs kept on an
entirely different drive from the main database.
In order to use transactions in a meaningful way, you need to build some data not included in the original
database. In the next section, you build tables with inventory to implement a very simple rental
database. You examine how these tables are created and how data is inserted, and you start to think
about which pieces should use transactions. Later on, after you have learned a great deal more about
transactions, you learn how to wrap some of these operations in transactions and why you would do so.