Serializability in DBMS Theory - Time & Space Complexity
When we study serializability in databases, we want to understand how the order of transactions affects the system's work.
We ask: How does the number of operations grow as more transactions run together?
Analyze the time complexity of checking if a schedule of transactions is serializable.
-- Assume we have a schedule with n transactions
-- and m operations total
-- Pseudocode for conflict graph creation:
CREATE GRAPH conflictGraph;
FOR each pair of conflicting operations (op1, op2) IN schedule DO
ADD EDGE from transaction(op1) TO transaction(op2) IN conflictGraph;
END FOR;
-- Check if conflictGraph has cycles to decide serializability
This code builds a graph of conflicts between transactions and checks for cycles to decide if the schedule is serializable.
Look for repeated steps that take most time.
- Primary operation: Comparing pairs of operations to find conflicts.
- How many times: For m operations, pairs can be up to about m squared (m x m).
As the number of operations grows, the number of pairs to check grows much faster.
| Input Size (m) | Approx. Operations |
|---|---|
| 10 | About 100 checks |
| 100 | About 10,000 checks |
| 1000 | About 1,000,000 checks |
Pattern observation: The work grows roughly by the square of the number of operations.
Time Complexity: O(m2)
This means if you double the number of operations, the work to check serializability roughly quadruples.
[X] Wrong: "Checking serializability grows linearly with the number of transactions or operations."
[OK] Correct: Because we must compare pairs of operations to find conflicts, the work grows much faster than just counting operations once.
Understanding how serializability checking scales helps you explain database behavior clearly and shows you can think about system performance in real situations.
"What if we only checked conflicts between transactions that access the same data item? How would the time complexity change?"