Why transactions ensure data consistency in DBMS Theory - Performance Analysis
We want to understand how the time taken by transactions changes as the amount of data or operations grows.
Specifically, how transactions keep data consistent while running multiple steps.
Analyze the time complexity of this transaction example.
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
This transaction moves money from one account to another, ensuring both updates happen together.
Look for repeated actions that affect time.
- Primary operation: Two update statements inside one transaction.
- How many times: Each update runs once per transaction.
As the number of accounts or transactions grows, the time grows roughly in proportion to the number of updates.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 transactions | 20 updates |
| 100 transactions | 200 updates |
| 1000 transactions | 2000 updates |
Pattern observation: Time grows linearly with the number of transactions because each transaction has a fixed number of steps.
Time Complexity: O(n)
This means the time to complete all transactions grows directly with how many transactions you run.
[X] Wrong: "Transactions always take the same time no matter how many operations they include."
[OK] Correct: More operations inside a transaction mean more work, so time grows with the number of steps.
Understanding how transaction time grows helps you explain database behavior clearly and shows you grasp how data consistency is maintained efficiently.
"What if the transaction included a loop updating 100 accounts instead of just two? How would the time complexity change?"
Practice
Solution
Step 1: Understand the role of transactions
Transactions group multiple operations into one unit that either fully succeeds or fully fails.Step 2: Connect to data consistency
This all-or-nothing approach prevents partial updates that could corrupt data.Final Answer:
They make sure all parts of a task complete successfully or none do. -> Option CQuick Check:
All-or-nothing = Data consistency [OK]
- Thinking transactions speed up queries
- Believing transactions allow uncontrolled edits
- Confusing data formats with consistency
Solution
Step 1: Identify the standard SQL command
The standard command to begin a transaction isBEGIN TRANSACTION;.Step 2: Eliminate incorrect options
Other options likeSTART QUERY;orOPEN DATABASE;are not valid SQL commands for transactions.Final Answer:
BEGIN TRANSACTION; -> Option DQuick Check:
Start transaction = BEGIN TRANSACTION [OK]
- Using START QUERY instead of BEGIN TRANSACTION
- Confusing transaction start with database open
- Using RUN TRANSACTION which is invalid
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;What is the main result of this transaction?
Solution
Step 1: Analyze the transaction commands
The commands start a transaction, perform two updates, then commit the changes.Step 2: Understand commit effect on data consistency
Commit saves all changes together. If any error occurs before commit, none are saved, ensuring consistency.Final Answer:
Both updates are saved together or none if error occurs. -> Option AQuick Check:
Commit = all-or-nothing save [OK]
- Thinking only first update saves
- Assuming automatic rollback without error
- Believing updates cause inconsistency
BEGIN TRANSACTION;
UPDATE inventory SET quantity = quantity - 5 WHERE product_id = 10;
-- Missing COMMIT here
UPDATE sales SET total = total + 100 WHERE sale_id = 20;What is the main problem with this transaction?
Solution
Step 1: Identify missing transaction command
The code starts a transaction but does not include a COMMIT command to save changes.Step 2: Understand effect of missing COMMIT
Without COMMIT, changes remain uncommitted and may be lost if connection closes or rollback occurs.Final Answer:
The changes may not be saved due to missing COMMIT. -> Option BQuick Check:
Missing COMMIT = no save [OK]
- Assuming transaction never starts
- Expecting syntax errors from missing COMMIT
- Believing auto-commit happens without command
Solution
Step 1: Understand partial failure risk in money transfer
If money is deducted but not added, data becomes inconsistent and incorrect.Step 2: Explain transaction rollback mechanism
Transactions ensure either all steps succeed or all fail. On crash, rollback undoes partial changes.Step 3: Connect rollback to data consistency
Rollback prevents partial updates, keeping data accurate and consistent after failure.Final Answer:
They roll back all changes so no partial update remains. -> Option AQuick Check:
Rollback = no partial updates [OK]
- Thinking partial updates are allowed
- Believing system retries endlessly automatically
- Assuming partial data is saved anyway
Ready to prove it?
Pass the test and this pattern moves unknown
