Transaction and its Properties in DBMS

What is Transactions in DBMS?

When user’s data is kept in a database, it must be accessed and adjusted periodically. To ensure the accuracy and reliability of data in a database, this activity should be carried out in accordance with a set of standards and in a methodical manner. In DBMS, this is referred to as a transaction. It is analogous to a financial transaction in which the user requests a withdrawal from his account. Several activities are then performed, including retrieving the user's balance form the database, deducting the necessary amount, and updating the user's account balance. This set of activities is referred to as a transaction. Transactions are quite prevalent in DBMS.

Operations of Transaction

A user can make multiple attempts to access and alter the data of a database. So there are several sorts of procedures associated with a transaction. They are addressed as follows.

Read (X)

A read command is used to retrieve the value of X in a database & save it in the buffer in main memory for later use, such as displaying it. This procedure is used when a user only wants to view the database's content and not alter it. For instance, when a user wishes to see his or her account equilibrium, a read operation is done from the database.

Write(X)

A write operation serves to transfer data from the buffer located in main memory to the database. To perform a write operation, first a reading operation is carried out to load its value into the buffer, and then a few adjustments are made to it, such as performing some arithmetic operations on it in response to the user's request, followed by a write operation to store the altered appreciate back in the database. As an example, if a user wishes to withdraw a certain sum from the account, the account's balance is received from a database using an operation known as read, then the quantity that needs to be withdrawn from the account's balance is deducted with this value, and finally the resultant value is saved back in

Commit

This transaction procedure maintains database integrity. A transaction may be halted before all of its actions are finished due to a loss of authority, hardware, or software, among other reasons. This may produce confusion in the database, resulting in inconsistency prior to and following the transaction. To guarantee that subsequent actions of any additional transaction are executed only after the current transaction's work is completed, a commit operation is conducted to permanently save the changes generated by a transaction to the database.

Rollback

This process restores the database to its last stored state when a transaction is stopped due to a power, equipment, or software failure. In layman's terms, a rollback operation undoes the activities of transactions that occurred before to its interruption in order to restore the database to a safe state and avoid any ambiguity or inconsistency.

Serializability

When the operating system conducts numerous transactions in a multitasking environment, there is always the chance that instructions from one transaction will interleave with those from another.

Schedule

A schedule is a chronological processing sequence of a particular transaction. Any schedule may include many transactions, each of which consists of an assortment of tasks or instructions.

Serial Schedule

It refers to a schedule in which all transactions are synchronized so that only one is completed initially. When the first transaction's cycle completes, the second transaction is executed as well. As a result, the transactions are shown below in chronological sequence. This form of schedule is referred to as a sequential schedule since the transactions are executed serially.

Serial schedules are used as a benchmark for multi-transaction setups. We cannot vary the execution order of instruction in a single transaction, but we may execute the instructions from two transactions at random. Such an execution is harmless if the two transactions were independent (mutually) and operate on distinct data segments. However, if each of these transactions use identical data segment, the outcomes may differ. These constantly changing findings may cause the database to become inconsistent.

To address this issue, we allow parallel execution of a transaction schedule where the actions are serializable or have an equivalence relation.

Equivalence Schedules

Similarity schedules may consist of the following types:

Result Equivalence

When two schedules provide the same results, they are deemed equal. This form of equivalency is not seen to be very relevant in general since it may provide identical results for some values but distinct results for others.

View Equivalence

Two provided schedules are regarded to be exactly view equivalence if the transactions in both schedules conduct the same type of activity in the same manner.

So, for instance,

• If T reads data from S1 first, it will additionally read data from S2.
• If T reads the number entered by J in S1, it additionally reads the value J wrote in S2.
• If T performs the final post on a value of data in S1, it will also do the same for an information value in S2.

Conflict Equivalence

If the two supplied schedules have the following qualities, they will clash.

• They both have access to a comparable data item.
• They both pertain to separate transactions.
• Certainly one of them is a "write" operation.
• Two schedules with numerous transactions and conflicting activities are conflict comparable if:
• Both of these calendars have a comparable set of transactions.
• We keep the order of clashing operation pairings in both schedules.

States of Transactions

In a database, a transaction may exist in one of the following states:

• Active: The active status indicates that a transaction is currently being performed. Thus, it is analogous to the beginning state of each particular transaction.
• Partially Committed: A transaction is partially committed when it completes the last activity.
• Failed: If a database restoration system fails to perform a check, the transaction is marked as unsuccessful. Remember that a transaction that fails cannot be processed further.
• Aborted: If a check fails and the transaction fails, the recovery manager reverts all write operations to restore the database to its original state. Transactions in this condition tend to be aborted. A database recovery module can really pick one of these two procedures following the termination of a transaction: To restart, kill the transaction.
• Committed: A transaction is considered committed if it successfully completes all operations. In this instance, all of its impacts are permanently recorded on the database system.

Properties in DBMS

Atomicity

Atomicity refers to a transaction that either occurs entirely at once or not at all. There is no intermediate step, which means that transactions do not take place in stages. Each transaction is treated as a single item, and it is either completed or not done. It consists of the subsequent two operations.

• Abort: If the transaction is aborted, any changes to the database's structure are not visible.
• Commit: When a transaction commits, the modifications made become apparent.

Atomicity is often known as the 'all or nothing rule'.

Consider the subsequent transaction T, which consists of T1 and T2. Transfer 100 form account X to the account Y.

If a transaction fails after T1, but before T2.(For example, after write(X), but before write(Y), the amount is removed from X yet not added to Y. It ends up in an irregular database state. To verify that the database state is valid, the transaction has to be performed in its entirety.

Consistency

This transaction characteristic ensures that the database remains consistent both before and after the transaction is executed. Any transaction must be executed so that the relational database remains either in its previous stable state or in a new stable state. In other words, a transaction should result in a database being transformed from a single consistent state to another. Consistency indicates that the modifications made to the system are the result of solely the logical processes that the user requested to execute, with no ambiguity.

In the case above, the entire amount prior to and following the transaction should be kept:

• Total before T: 500 + 200 = 700.
• Total after T: 400 + 300 = 700.

Therefore, the information in the database remains consistent. Inconsistency happens when T1 finishes but T2 fails. As a consequence, T becomes incomplete.

Isolation

This feature indicates that two transactions are prohibited from interfering with one other. For example, if a transaction uses certain data for its execution, no other transaction can access that data till the first transaction is completed. It guarantees the database's integrity and that no confusing values are returned. As a result, any two transactions are completely separated from one another. The database management system's concurrency control subsystem enforces this property.

Let X=500 and Y=500.

Consider two transactions: T and T".

Assume T has been run until Read (Y), and then T'' begins. Interleaving of operations causes T'' to read the right value of X but the wrong value of Y. The sum computed by T'' (X+Y = 50, 000+500=50, 500) does not match the amount at the conclusion of the transaction: T (X+Y = 50, 000 + 450 = 50, 450).

This causes database discrepancy owing to a deletion of 50 units. As a result, transactions must occur in isolation, with modifications apparent only after they are made to main memory.

Durability

This attribute guarantees that modifications made to a database once a transaction is fully processed remain permanent. The successful completion of a transaction causes lasting changes. In the case of a system failure or crash, the consistent state established after completing a transaction is preserved. This attribute is enforced by the database management system's recovery subsystem.

The properties of ACID, in their entirety, provide a mechanism for ensuring the correctness and uniformity of a database in such a way that each transactions is a group of activities that acts as one entity, produces predictable outcomes, acts independently from any additional operations, as well as updates the database makes are permanently stored.

Uses for Properties

Overall, the ACID features of transactions offer a method in DBMS that ensures the consistency and accuracy of any database. It provides consistency by treating each transaction as a collection of actions working as a single unit, producing consistent outcomes, operating in isolation from all other operations, and storing changes indefinitely. These assure data integrity in any database.

Application of Properties

The ACID features of transactions serve as a technique in DBMS to assure the integrity and correctness of any database. They guarantee that every transaction is a separate unit of activities that generates consistent results, runs independently of all other activities, and conducts long-term changes. These qualities are critical for ensuring the confidentiality of information in a database system.

Advantages of Properties in Database Management Systems

• Data Consistency: ACID qualities guarantee that data is consistent and correct following transaction execution.
• Data Integrity: ACID qualities ensure that modifications to a database are persistent and are not lost.
• Concurrency Control: ACID features assist to handle numerous transactions that are occurring at the same time by avoiding interference.
• Recovery: ACID qualities ensure that in the event of a failure or collapse the system may recover data up to that point.

Disadvantages of Properties in Database Management Systems

• Performance: The ACID qualities might incur an operating overhead for the system since they need more processing to maintain the consistency of data and integrity.
• Scalability: The ACID features may present scalability concerns in big distributed systems when numerous transactions are occurring at the same time.
• Complexity: Applying the ACID features might make the system more difficult and demand substantial skill and resources.

Overall, the benefits of ACID features in DBMS exceed the negatives. They ensure data integrity, correctness, and dependability through standardized data management practices. However, in some circumstances, applying ACID features might result in performance and scalability difficulties. As a result, it is critical to balance the advantages of ACID features against the unique demands and limitations of the system.

Conclusion

In conclusion, a transaction may be defined as a collection of actions used to complete a logical set of tasks. A transaction is a process that is used to update data in a database. This can be done by entering new data, updating current data, or removing existing data. A transaction's lifetime contains numerous stages; these situations update the system on the transaction's present status and inform the user on how to plan future processing. ACID qualities of a transaction give a technique of assuring the consistency of a database in such a way that each transaction is a collection of operations that works in isolation in contrast to other transactions, produces consistent results, and ensures durability.