Database transactions are a fundamental concept in database management systems that ensure data integrity and consistency. A transaction is a sequence of database operations that are treated as a single, indivisible unit of work. These operations can include inserting, updating, or deleting data from a database. The purpose of transactions is to ensure that the database remains in a consistent state even in the event of hardware or software failures, or concurrent access by multiple users.

Here is a detailed explanation of database transactions, along with some examples:

ACID properties

A transaction must satisfy the ACID properties to ensure data consistency and integrity. ACID stands for Atomicity, Consistency, Isolation, and Durability.

1. Atomicity: A transaction must be treated as an atomic unit of work, which means that all the operations in the transaction must either succeed or fail as a whole. If any operation fails, the entire transaction must be rolled back.

2. Consistency: A transaction must leave the database in a consistent state. This means that the database must satisfy all the integrity constraints and business rules defined for it.

3. Isolation: A transaction must be isolated from other concurrent transactions. This means that the changes made by a transaction should not be visible to other transactions until the transaction is committed.

4. Durability: Once a transaction is committed, its effects must be permanent and survive system failures.

Transaction states

A transaction can be in one of the following states:

1. Active: The transaction is currently executing and has not yet been committed or rolled back.

2. Partially Committed: The transaction has executed all its operations, but has not yet been committed.

3. Committed: The transaction has completed successfully and all its changes have been made permanent in the database.

4. Failed: One or more operations in the transaction have failed, and the transaction has been rolled back.

5. Aborted: The transaction has been rolled back due to an external failure, such as a system crash or network failure.

Transaction control statements

Transactions can be controlled using the following statements:

1. BEGIN TRANSACTION: This statement marks the beginning of a transaction.

2. COMMIT: This statement marks the end of a transaction and makes all its changes permanent in the database.

3. ROLLBACK: This statement cancels all the changes made by a transaction and rolls it back to its original state.

4. SAVEPOINT: This statement creates a named point in a transaction, allowing it to be partially rolled back to a specific point in the transaction.

5. ROLLBACK TO SAVEPOINT: This statement rolls back a transaction to a named savepoint.

Example

Let's say that a user wants to transfer $100 from account A to account B. The transaction to complete this transfer would involve updating the balances of both accounts. Here's an example of how this transaction might be implemented:

1. Begin the transaction by starting a new database transaction.

2. Retrieve the current balance of account A and subtract $100.

3. Update the balance of account A in the database.

4. Retrieve the current balance of account B and add $100.

5. Update the balance of account B in the database.

6. Commit the transaction by making all changes permanent in the database.

If any of the steps above fail, for example, if the balance of account A is insufficient to complete the transfer, the transaction will be rolled back. This means that all changes made during the transaction will be undone, and the database will be left in the same state it was in before the transaction started.