...
A transaction in a database is a single logical unit of work that encompasses multiple operations. It's essentially a sequence of operations performed as a single logical unit of work.
A good example of a transaction is a bank transfer from one account to another. This transfer consists of two separate operations: withdrawing the money from one account and depositing it into another. These two operations together make up a single transaction.
In the context of databases, these operations typically involve reading from and writing to a database. If all the operations succeed, the transaction is considered successful and the changes are committed (permanently saved) to the database.
However, if any operation within the transaction fails, the entire transaction is considered to have failed, and none of the changes are committed. Instead, the changes are rolled back and the database is left in its original state. This is known as maintaining atomicity of the transaction - either all the operations in a transaction are performed, or none are.
ACID
Transactions in databases are managed to ensure ACID properties:
Atomicity: A transaction is atomic -- it is one indivisible unit, and it is either performed in its entirety or not at all.
Consistency: A transaction brings the database from one consistent state to another. Consistency in this context refers to ensuring that a transaction brings the database from one valid state to another, adhering to all data validation rules and constraints.
Isolation: Each transaction is executed independently of other transactions. Effects of a transaction are not visible to others until the transaction is committed.
Durability: Once a transaction is committed, its effects are permanent and survive future system and media failures.
In summary, a transaction in the database is a logical unit of work that may consist of multiple operations. Each transaction in a database has to maintain the ACID properties to ensure accuracy, completeness, and data integrity.