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 the database is left in the state it was in before the transaction began.
The canonical transaction is transferring money at an ATM. If I transfer $50 from checking to savings, the bank will first reduce my checking account by $50 and then increase my savings account by $50. If it does the first step but not the second, I 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, i.e., it cannot be partially implemented. Every transaction must be atomic. For instance, in the previous banking example, it must be impossible to decrement my checking account but fail to increment my savings account. If the transaction fails, it must return the database to the state it would have been in without the transaction. ...