1.1The role and architecture of a DBMS

DB's exam A-2 does not test rote definitions like "a DBMS is software that manages data"; it tests what a DBMS actually guarantees when a business system experiences a failure or heavy load, and what the designer must choose as a result. Compared to handling data directly with a file system, a DBMS provides mechanisms that keep data consistent in the face of real-world threats such as simultaneous access by multiple users, sudden power loss, and application bugs. This section breaks the DBMS's roles down by function and clarifies exactly what each one prevents, and what it does not.

1.1.1The five roles of a DBMS

• A DBMS (Database Management System) is the software foundation that centrally handles data definition, storage, manipulation, and protection. It provides concurrency control, failure recovery, and access control—features difficult to implement in a hand-rolled program that manipulates a file system directly—as standard capabilities.
• The five main roles: (1) data definition (DDL)—defining schema such as tables, constraints, and indexes; (2) data manipulation (DML)—querying and updating via SQL; (3) concurrency control—arbitrating so that concurrently executing transactions do not produce contradictions; (4) failure recovery—restoring data to a consistent state after a system or media failure; and (5) data independence—ensuring changes to physical storage or to applications do not affect one another.

1.1.2What the ACID guarantee actually covers

• The properties a DBMS guarantees for a transaction are called the ACID properties: Atomicity—a transaction either executes fully or is fully rolled back; Consistency—the database only transitions between states that satisfy its constraints; Isolation—concurrently executing transactions do not interfere with each other; and Durability—the results of a committed transaction are not lost even after a failure.
• ACID is a guarantee scoped to the transaction; it does not guarantee that an update committed due to flawed application business logic is "correct." For example, an update that drives an account balance negative will still commit successfully as long as it does not violate the DBMS's own integrity constraints, even without an application-side check.

Suppose you are the DBA responsible for an e-commerce site's inventory management system, and you receive a report that a momentary power outage occurred during a late-night batch job, forcing the server to restart. The first thing to check is whether Durability held—that is, whether the results of order-confirmation processing that had already committed just before the outage are still present on disk. A DBMS typically persists the log at commit time via WAL (write-ahead logging) before returning a response, so the results of committed transactions are not lost. The next question is how to handle transactions that were in progress but not yet committed at the moment of the outage. It would be a mistake to think "it would make better use of the data to let the in-progress work finish as much as possible before restarting." Following the principle of Atomicity, the DBMS instead rolls back any uncommitted transaction, completely undoing every trace of its updates to preserve consistency after restart (leaving a partial set of updates in place is never acceptable). One more thing to avoid is conflating this failure with a case where "multiple concurrent inventory-update transactions were competing." Concurrency control (isolation) is strictly about preventing interference between multiple transactions; recovering from a power outage mid-transaction falls under failure recovery (atomicity and durability). Separating the scope each role guarantees is the key to avoiding a mistaken recovery procedure, such as manually trying to patch up in-flight data.

1.1.3Section summary

• A DBMS integrates five roles: data definition, data manipulation, concurrency control, failure recovery, and data independence
• The ACID properties (atomicity/consistency/isolation/durability) guarantee transaction-scoped technical consistency; they do not guarantee the correctness of application-side business logic
• Recovery from a failure such as a power outage is the responsibility of atomicity (rolling back the uncommitted) and durability (preserving the committed), a distinct role from concurrency control (isolation)