An important feature of most industrial-strength databases is support for transactions. A transaction is a set of database operations that must all complete or fail together. That is, either all the operations must complete successfully (commit the transaction), or all must be undone (roll back the transaction) so that the database is left in the state it was in before the transaction began.
A good example of a transaction is transferring money at an ATM. If you transfer $50 from checking to savings, the bank will first reduce your checking account by $50 and then increase your savings account by $50. If it does the first step but not the second, you will be annoyed.
The bank system treats the entire set of reducing one account and increasing the other as a single transaction. The entire transaction occurs or none of it occurs; it is not valid for it to occur “partially.”
Database designers define the requirements of a transaction with the so-called “ACID” test. ACID is an acronym for Atomic, Consistent, Isolated, and Durable. Here’s a brief summary of what each of these terms means:
An atomic interaction is indivisible, that is, it cannot be partially implemented. Every transaction must be atomic. For instance, in the previous banking example, it must be impossible to decrement your checking account but fail to increment your savings account. If the transaction fails, it must return the database to the state it would have been in without ...