Before we can talk about atomicity, redo logs, or isolation levels, we must earn every word the parent note used. This page is a dictionary you build, bottom to top — no term appears until the ones beneath it are solid.
Picture a spreadsheet with two columns, id and bal (short for balance), and two rows: Alice and Bob. That single picture is enough to carry the whole ACID story.
Why we need it: every ACID example ("move ₹100 from Alice to Bob") is just changing the value inside cells of this grid. If you can see the grid, its rows, columns, and cells, you can see every anomaly later.
Why we need it: ACID never argues about single operations — those are trivially safe. The drama begins when we group several operations. So "operation" is the atom; "transaction" is the molecule.
The parent writes these as SQL:
UPDATE acct SET bal = bal - 100 WHERE id = 'Alice';
Read that as: "in the acct table, in the row where id equals 'Alice', replace the bal cell with its old value minus 100." The := symbol the parent uses in examples (Alice.bal := 400) just means "gets assigned the value" — the arrow that overwrites a cell. It is not the = of "is equal to"; it is "becomes".
Picture a real cardboard box you place around a few operations. Nothing inside is "real" until you seal it (COMMIT). At any moment before sealing you may burn the box (ROLLBACK).
Why we need it: the entire promise of ACID starts with "the box is indivisible." Without a beginning and an end, there is no "unit of work" to protect. COMMIT is the exact instant durability starts to apply; before it, nothing is guaranteed.
Picture states as dots on a map, and edges as legal transactions hopping between them. Some dots are painted green (valid); the red ones (a negative balance) are forbidden — no transaction is allowed to land there.
Why we need it: Consistency is defined entirely in this language. Without the word invariant you cannot say what "valid" means.
CHECK (bal >= 0) — the cell rule "balance must be at least zero". The symbol >= means "greater than or equal to".
PRIMARY KEY — "this column uniquely names each row; no two rows share an id."
FOREIGN KEY — "a value here must point to a real row in another table" (see Database Constraints).
Why we need it: the parent's Consistency example ("subtract → bal := -50 violates the CHECK → rollback") only makes sense once you know a CHECK is a machine-enforced invariant. Constraints are how the DB keeps you on green dots.
Picture two shelves. The top shelf (RAM) is a whiteboard: instant to write, wiped when the lights go out. The bottom shelf (disk) is stone tablets: slow to carve, but permanent.
Why we need it: Durability is entirely about the RAM-vs-disk gap. Databases keep recent changes on the fast whiteboard for speed; the danger is a crash erasing the whiteboard before it was copied to stone. Every trick — WAL, fsync — is about closing that gap safely.
Undo log stores the old value before a change ("Alice.bal was 500"). It answers: "how do I go backwards?" → used by Undo and Redo Logs for ROLLBACK and to erase crashed, uncommitted work (this powers Atomicity).
Redo log stores the new value of a committed change ("Bob.bal becomes 300"). It answers: "how do I re-do work that was committed but hadn't reached the data file?" → this powers Durability via Write-Ahead Logging (WAL).
Why we need it: the parent literally says "Atomicity uses the undo log, Durability uses the redo log." You cannot understand either property without knowing a log is an append-only diary and which direction (backward = undo, forward = redo) each reads.
Picture two hands reaching into the same grid at once. If they grab the same cell in a bad order, one hand sees a half-finished number.
Why we need it: the three anomalies (dirty / non-repeatable / phantom read) and the isolation-level table are meaningless until "concurrent", "serial", and "anomaly" are defined. See Concurrency Control, Isolation Levels, Locking and 2PL, and MVCC for the machinery.
The diagram below is a prerequisite map. Read it like this: each box is a concept from this page; an arrow A --> B means "A must be understood before B" — A feeds into B. Follow the arrows upward and you arrive at the four ACID promises, which all flow into the single "ACID promise" box at the bottom.
