Business analysts who work on system solutions should have a basic understanding of database concepts.  Many databases are part of a class of systems called OLTP (OnLine Transaction Processing) systems.  So what is a database transaction within this context?

A database transaction is a series of operations performed within a database management system against a database such that, once completed, the data is left in a reliable and consistent state.  If any step of the transaction fails then all steps are reversed (rolled back), so that data integrity can be maintained.

Database transactions serve two main purposes.  First, to conduct and bundle units of work that allow for accurate recovery of data in the case of system failures.  Second, to provide isolation between different programs which may attempt to access the data simultaneously.

A database transaction should conform to the principles described by the acronym ACID (Atomic, Consistent, Isolated and Durable).

Atomic means that a series of database operations either all occur, or nothing occurs. Atomicity avoids partial database updates which can cause issues with data integrity.  Atomic transaction can be described as indivisible and irreducible.  Transactions, while atomic, can make updates to multiple database stores operating on multiple systems.

Consistent refers to the idea that a transaction will bring the database from one valid state to another and that the data written to the database will conform to defined rules. The rules can consist of constraints, triggers, and cascades.  However, understanding these additional concepts go beyond what is necessary for this definition.

Isolated describes keeping changes made by one transaction hidden from other concurrently running transactions and operations until such time as they should be made visible based on defined rules.

Durable means that any transactions that have been committed to the database will survive permanently.  This level of guarantee is often achieved by copying all transactions into a transaction log on a secondary storage medium.  A transaction is considered committed only after it has be copied to the transaction log.