Acid Properties in DBMS
- The single logical units of work known as transactions are those that access and (potentially) alter the data contained in a specific database. With read-and-write operations, we have access to the transactions.
- Certain features, known as the ACID (Atomicity, Consistency, Isolation, Durability) attributes, must be adhered to in transactions if database consistency is to be maintained. Let’s go through them in more depth.
Atomicity
Atomicity describes a situation in which the full transaction either happens all at once or not at all. There is therefore no halfway point. There can never be a partial transaction. Every transaction may be thought of as a separate unit that either executes completely or not at all. Here, we have these two operations:
Commit: If a transaction commits, we are aware of the modifications that were done. Thus, the “All or nothing rule” is another name for atomicity.
Abort: If a transaction fails, we won’t be able to see any database modifications that were done.
Example: Suppose Remo wants to transfer $10 to Sheero’s account, B, from account A, which has $30 in it. A hundred dollar amount is already available in account B. $10 will become $110 when it is transferred to account B. Two surgeries are going to happen right now. One is that the $10 Remo intends to send will be deducted from account A and credited to account B, or Sheero’s account, in the identical amount. What occurs next is that the initial debit operation completes correctly, but the subsequent credit operation does not. As a result, the value decreases to $20 in Remo’s account A while remaining at $100 in Sheero’s account.
As seen in the accompanying figure, $100 is still in account B after $10 has been credited. The transaction is not atomic, thus.
The graphic below demonstrates that successful debit and credit operations have been carried out. The transaction is therefore atomic.
Therefore, atomicity is the key emphasis in the bank systems since when the amount loses atomicity, this causes a big problem.
Consistency
Consistency indicates that the value should always be maintained. In DBMS, the integrity of the data must be upheld, which calls for any changes to the database to always be retained. Data integrity is crucial in transactions because it ensures that the database is consistent both before and after the transaction. The information should always be accurate. For any particular database to be consistent before and after a transaction, we must uphold the integrity requirements.
Example:
Three accounts—A, B, and C—are shown in the above image, and account A is making transactions T to both B and C one at a time. Debit and Credit are the two actions that happen. Account A initially debits Account B with $50, and before the transaction, account B reads $300 in Account A. The available money in B increases to $150 following the completion of transaction T. Now, A debits $20 to account C, and C reads $250 at that point (which is accurate because A correctly debited $50 from B). The debit and credit transaction from account A to account C was completed successfully. We can see that the transaction was successful.
Isolation
Multiple transactions can occur simultaneously with isolation in place, preventing inconsistent database states. An autonomous, or uninvolved, transaction takes place. Until and unless this specific modification in this transaction has been committed or put to memory, any changes that take place in that transaction will never be visible to the other transactions.
The virtue of isolation guarantees that when we run the transactions simultaneously, the produced state will be identical to the state that was run serially and in a certain sequence.
Example:
The value of both accounts shouldn’t change if two activities are being executed simultaneously on two distinct accounts. The value ought to continue to exist. As seen in the picture below, account A is making T1 and T2 transactions to accounts B and C, but each is carrying them out separately and without interfering with one another. It is referred to as isolation.
Durability
The database changes and alterations are written to and saved in the disc after a transaction’s execution is complete, according to the durability feature. These continue even after a system breakdown has occurred. Such modifications are saved in non-volatile memory and become permanent. The results of this transaction are never lost as a result.
Example:
The outcomes of a transaction or the database’s contents cannot be lost in the event of a system crash or any other failure. Separate transaction logs that can “re-create” all transactions from a selected point in time (like a backup) are frequently used to ensure durability.
Uses of ACID Properties
All things considered, the ACID features of transactions offer a DBMS method to guarantee the consistency and accuracy of any database. Every transaction functions as a series of activities operating as single units, creates consistent outcomes, operates apart from all other operations, and makes durably stored modifications. This assures consistency. These guarantee the accuracy of the data in a certain database.
Advantages of ACID properties in DBMS
Data consistency and corruption are prevented by the ACID characteristics, which also protect data integrity.
Reliability: Transactions are consistently and trustworthily executed thanks to the ACID features.
Concurrency Control: The ACID qualities allow for conflict-free simultaneous access to data.
Fault Tolerance: ACID characteristics make a guarantee that data is durable and can withstand system failures.
Transaction management: Structured transaction handling is provided by ACID properties.
Compliance and Auditability: The characteristics of ACID make compliance and auditing with regulations easier.
Disadvantages of ACID properties in DBMS
speed Overhead: Due to increased processing and resource usage, ACID features might affect system speed and throughput.
Complexity: Adding ACID features to database systems makes them more complicated, which makes design and maintenance more difficult.
Scalability Challenges: In highly distributed or scalable systems, ACID features may provide challenges that restrict scalability.
Deadlock risk: ACID transactions that use locking methods run the risk of causing deadlocks and system halts.
Limited Concurrency: ACID characteristics may limit concurrency, which might affect system throughput as a whole.
Recovery Complexity: The ACID qualities add complexity to backup and recovery plans.
compromise with System availability may be impacted in some circumstances by strict adherence to ACID characteristics.
Conclusion
The DBMS’s ACID features guarantee dependable and strong data management.
Atomicity: Changes are either committed in whole or not at all since transactions are viewed as indivisible components.
Consistency: Transactions enforce preset rules and restrictions by keeping the database in a valid state both before and after. Data consistency is avoided through isolation, where concurrent transactions don’t interact with one another.
Durability: Committed changes are permanently preserved and remain accessible even in the event of a system crash, assuring data dependability. In a database system, adherence to these qualities assures data integrity, consistency, isolation, and longevity.
