Relational algebra, functional dependencies, normal forms, and concurrency-control theory.
5 questions in CS Fundamentals.
In a transfer, atomicity means the debit and credit commit together or not at all, consistency means declared constraints such as a non-negative balance still hold, isolation stops concurrent transactions seeing or overwriting each other's half-done work, and durability means a confirmed commit survives a crash.
Normalise by naming each functional dependency and splitting on it: atomic values for 1NF, no column depending on part of a composite key for 2NF, no non-key column depending on another for 3NF. Undo it only for a measured read path, and say who keeps the copies in step.
Normalisation removes redundancy so a fact is stored once; 3NF is reached when every non-key column depends on the key and nothing but the key. You denormalise knowingly, to buy read performance with write complexity. ACID guarantees far less than candidates assume, particularly its C.
This is write skew. Both transactions read the same snapshot, decide independently, and write disjoint rows, so there is no write-write conflict for the engine to catch. The invariant spanned rows it never saw as related, so either make the conflict physical or use true serialisability.
A schedule is serialisable when its effect matches running the same transactions one after another in some order, which is the criterion isolation is defined against. Two-phase locking achieves it by forbidding a transaction from acquiring any lock after releasing one, and the price is deadlock.