Understanding ACID Properties with SQL Queries: A Step-by-Step Guide

In the last blog, we learnt about ACID Properties theoretically. We know that the main part of ACID properties is Transactions. So let me demonstrate the ACID Properties to you using SQL Queries.

There are 4 types of properties to ensure database transactions are processed reliably in a database system.
1. Atomicity
2. Consistency
3. Isolation
4. Durability

Varadha, a self-proclaimed 'gold digger' with a history of asking Deva for loans to buy ridiculous items, needed help again. This time, he wanted to buy a new mobile phone and was 500 rupees short. Deva, his trusty friend and ATM received a message: 'Dude, I'm in dire need of funds... can you please send me some cash? This is the context and let us learn ACID Properties based on this context.
So first using MYSQL let’s create table “Accounts”.

CREATE TABLE Accounts (
    AccountID INT PRIMARY KEY,
    AccountHolder VARCHAR(100),
    Balance DECIMAL(10, 2)
);


INSERT INTO Accounts (AccountID, AccountHolder, Balance)
VALUES
(1, 'Deva', 1000.00),
(2, 'Varadha', 1500.00);

This is the Accounts table which we are using to demonstrate these properties.

Atomicity

We know that atomicity means a transaction should either be completed or not at all complete if it is in between state then it will come back to normal state.
Here is the query to demonstrate Atomicity.

START TRANSACTION;

-- So Deva is sending(Debiting) money to Varadha
UPDATE Accounts
SET Balance = Balance - 500
WHERE AccountID = 1;

-- Varadha is getting(crediting) money from Deva
UPDATE Accounts
SET Balance = Balance + 500
WHERE AccountID = 2;

-- Commit the transaction if everything goes well
COMMIT;

-- If anything fails then we can ROLLBACK.
ROLLBACK;

Above is the output for this query we can see 500 is removed from deva and added to varadha account.

So in the above query, we are doing a transaction that is credited from an account and debited from another account, either both of the transactions go well or it will roll back to the starting state using the KeyWord “ROLLBACK“.
This is what is ensured by Atomicity.
Atomicity prevents bank errors, but not Varadha's borrowing habits.

Consistency

Consistency is about whether the database is consistent(following some constraints) at the start of the transaction as well as during, it will be the same at the end of the transaction. Transactions ensure the database remains consistent throughout and after execution.
Here is the query used for it -:

-- consistency
-- We will add a constraint so that the balance wont go below 0(-ve).
ALTER TABLE Accounts
ADD CONSTRAINT chk_balance CHECK (Balance >= 0);

-- Attempt to withdraw too much (causing a failure)
START TRANSACTION;

-- Debit more than the balance (this will fail)
UPDATE Accounts
SET Balance = Balance - 2000
WHERE AccountID = 1;

-- Commit or rollback the transaction based on the result
COMMIT;
ROLLBACK;

You will get these outputs if you remove more than the account balance. If the chk_balance constraint is not present then we can get negative values in the balance column.
- The above is the output of the query if the constraint is not there and you start the transaction which can't happen because of consistency constraint which helps the table to be reliable state.
- Consistency property: where Deva's wallet goes '0' but never '-You're broke, buddy!
  
  Isolation
- It is about any multiple transactions which will be occurring simultaneously on the same data that can’t be executed at the same time.
- So, here is the SQL query to demonstrate the topic -:

    -- Isolation
    START TRANSACTION;

    -- Debit(100) Deva account
    UPDATE Accounts
    SET Balance = Balance - 100
    WHERE AccountID = 1;

    -- Keep the transaction open (do not commit)
    -- Try to debit(200) the same account
    UPDATE Accounts
    SET Balance = Balance - 200
    WHERE AccountID = 1;

    -- This will be blocked until Session 1 completes

This is the output for the above query, here you can see that Deva’s account has around 200 Rs which is achieved by these two transactions that got executed one by one instead of simultaneously.
Thanks to isolation, Deva's account wasn't drained simultaneously by Varadha's multiple 'requests’. Now, Deva's wallet can breathe a sigh of relief... until Varadha figures out a way to batch his borrowings.

Durability

Once a transaction is executed the data will be saved forever even if any system error(System failure) occurs.
It can be challenging to illustrate this directly with a query, but essentially, when you execute a COMMIT, the transaction is permanently saved in the database.
Here is the SQL Query -:

-- Durability

START TRANSACTION;

-- Credit Varadha's account with $300
UPDATE Accounts
SET Balance = Balance + 300
WHERE AccountID = 2;

-- Commit the transaction
COMMIT;

Above is the output for the query.2

Once a transaction is committed, Durability guarantees that the balance update will be retained even if the database server crashes, ensuring it remains intact when the system is restored.

Durability: where Varadha’s account balance survives even a system crash".
Example:
Before Commit: 2000
After Commit, crash, restart: 2300
Varadha’s balance withstood the 'crash test'.

Demonstration Of ACID Properties

Atomicity

Consistency

Isolation

Durability