ACID Properties
ACID is a concept (and an acronym) that refers to the four properties of a transaction in a database system, which are: Atomicity, Consistency, Isolation and Durability. These properties ensure the accuracy and integrity of the data in the database, ensuring that the data does not become corrupt as a result of some failure, guaranteeing the validity of the data even when errors or failures occur.
The ACID properties allow us to write applications without considering the complexity of the environment where the application is executed. This is essential for processing transactions in databases. Because of the ACID properties, we can focus on the application logic instead of failures, recovery and sync of the data.
Transaction
Before explaining the four ACID properties, we need to understand what is a transaction. A transaction is a sequence of operations that are executed as a single unit of work, and a transaction may consist of one or many steps. A transaction access data using read and write operations.
Each transaction is a group of operations that acts a single unit, produces consistent results, acts in isolation from other operations and updates that it makes are durably stored.
The goal of a transaction is to preserve the integrity and consistency of the data. If a transaction succeeds, the data that were modified during the transaction will be saved in the database. If some error occurs and needs to be cancelled or reverted, the changes that were made in the data will not be applied.
When we work with a database, we execute SQL declarations, and those operations are generally executed in blocks, and those blocks are the transactions. They allow to insert, update, delete, search data, and so on.
For example, transferring money between bank accounts is a transaction, what will occur in this case is that the value must be debited from one account and credit in another account.
Atomicity
A transaction must be an atomic unit of work, which means that all the modified data are performed or none of them will be. The transaction should be completely executed or fails completely, if one part of the transaction fails, all the transaction will fail. This provides reliability because if there is a failure in the middle of a transaction, none of the changes in that transaction will be committed.
For example, in a financial transaction, the money goes out from account A and goes to account B, both operations should be executed together, and if one of them fails, the other will not be executed. So the transaction is treated as a single entity, as a single command. A transaction can have more than two operations, but it will always be executed all of them or none. On this example, when the money is being transferred from account A to account B, if something fails, the entire transaction will be aborted and will rollback.
Consistency
This property ensures that the transaction maintains data integrity constraints, leaving the data consistent. The transaction creates a new valid state of the data and if some failure happens, return all the data with the state before the transaction being executed.
The goal is to ensure that the database before and after the transaction be consistent. If a transaction leaves data in an invalid state, the transaction is aborted and an error is reported.
The data that is saved in the database must always be valid (the data will be valid according to defined rules, including any constraints, cascades, and triggers that have been applied on the database), this way the corruption of the database that can be caused by an illegal transaction is avoided. For example, if we try to add a record in a sale table with the code of a product that does not exist in the product table, the transaction will fail. Another example, if you have a column that does not allow negative numbers, and try to add or modify a record, using a value lower than zero on this column, the transaction will fail.
Isolation
This property ensures the isolation of each transaction, ensuring that the transaction will not be changed by any other concurrent transaction. It means that each transaction in progress will not be interfered by any other transaction until it is completed.
For example, if two clients are trying to buy at the same time the last available product on the web site, when the first user finishes the shopping, it will make the transaction of the other user be interrupted.
Durability
Once a transaction is completed and committed, its changes are persisted permanently in the database. This property ensures that the information that is saved in the database is immutable until another update or deletion transaction affects it.
Once the transaction is committed, it will remain in this state even if a serious problem occurs, such as a crash or a power outage. For this purpose, the completed transactions are recorded on permanent memory devices (non-volatile) such as hard drives, so the data will be always available, even if the DB instance is restarted.
Conclusion
The ACID properties ensure the integrity and the consistency of the data in the database, ensuring that the data does not become corrupt as a result of some failure. The databases that apply the ACID properties will ensure that only transactions that were completely successful will be processed, and if some failure happens before a transaction be completed, the data will not be changed.
References
Software Architect’s Handbook — Joseph Ingeno
What does ACID mean in Database Systems?
GeeksForGeeks — ACID Properties in DBMS
