This is the first lesson from a new book on the reading list: Silberschatz, Korth, and Sudarshan's Database System Concepts — the standard university text on how databases are actually built, as opposed to Kleppmann's Designing Data-Intensive Applications, which is the practitioner's view of how to compose them. Where DDIA (your Lesson 1 onward) gives you the interview vocabulary, this book gives you the internals: what a DBMS is responsible for, how it hides complexity, and how it keeps your data safe. Chapter 1 is the orientation chapter — the map before the territory.
The single idea that organizes everything in this chapter: a database-management system is a program that stores interrelated data and gives you an abstract way to read and write it, taking on responsibilities that would otherwise be your job — crash recovery, concurrency, access control, and efficient storage. Keep that sentence in mind; every section below is just one facet of it.
A DBMS is a contract of guarantees, not just a place to put bytes. You hand it data; it promises to keep it safe across crashes, correct under concurrent users, and retrievable without you knowing where the bytes physically live. The whole book is the engineering that makes those promises hold.
Before databases, organizations kept data in ordinary operating-system files, with custom application programs written to read and write them. That sounds fine until the organization grows. The book walks through what goes wrong, and these are worth internalizing because each one maps directly to a system you'll be asked to design in an interview.
| Problem with file-processing | What actually breaks | DDIA tie-in |
|---|---|---|
| Data redundancy & inconsistency | The same fact (a student's address) is copied across several files with no single owner, so an update lands in one place and not another. | Deriving views from one source of truth — your Lesson 12 "unbundling" idea. |
| Difficulty in accessing data | An unanticipated question ("all students in this postal code") needs a brand-new program, because queries aren't first-class — they're hardcoded. | Declarative query languages let you ask what, not how (your Lesson 3). |
| Data isolation | Data scattered in differently-formatted files makes even writing that new program hard. | Uniform storage engine underneath (your Lesson 3). |
| Integrity problems | Rules like "a department balance may never go negative" get baked into scattered application code and silently drift out of sync. | Constraints enforced by the system, not the app. |
| Atomicity problems | A crash mid-transfer debits account A but never credits B — the data is now wrong forever. | Lesson 7: a transaction must happen in full or not at all. |
| Concurrent-access anomalies | Two clerks read $10,000, each subtract their amount, both write back — one update is lost. | Lesson 7 + Lesson 9: isolation and consensus. |
| Security problems | Ad-hoc programs can't easily restrict payroll staff to financial data only. | Authorization as a first-class system feature (see DDL below). |
Notice that the last three — integrity, atomicity, concurrency — are exactly the problems your transactions lesson exists to solve. The book's framing is the why; DDIA's chapters 7–9 are the how. Reading them in this order is deliberate, and it's the spine of your FAANG prep: you now see both the requirement and the mechanism.
The book's definition of the data a DBMS is for is almost poetic in its simplicity: data that is highly valuable, relatively large, and accessed by many users at once. If any one of those fails, you probably don't need a database — a file will do. The "many users at once" clause is the one that forces all the hard engineering (concurrency, transactions, recovery).
The book then separates two fundamentally different ways databases get used, and this distinction shows up constantly in real architectures:
| Online Transaction Processing (OLTP) | Data Analytics | |
|---|---|---|
| Shape of work | Many users, each touching small amounts of data — a balance check, one post. | Processing large swaths of data to find patterns and drive decisions. |
| Goal | Accurate, fast, concurrent record-keeping. | Discover rules and build predictive models (e.g. loan approval, ad targeting). |
| Examples | ATM withdrawal, posting to social media, registering for a course. | Bank deciding a loan; retailer forecasting demand from past sales. |
This is the same split DDIA makes between a system of record (the OLTP database) and a derived dataset (analytics, batch, streams). The book adds the term data mining for the field that fuses AI/statistical discovery with efficient implementation on huge databases. The reason organizations pay so much for this is the asymmetry the book names outright: the cost of a wrong decision (a bad loan, a mis-forecast inventory) is high, so gathering and mining data is worth real money.
The central purpose of a database system is to give users an abstract view of the data — to hide how it's stored. The book's analogy is the car: you drive it through a simple control abstraction without knowing how the motor works. The database does the same with three explicit levels of abstraction, and this three-tier mental model is one of the most reused ideas in the field.
| Level | Answers the question | Who lives here |
|---|---|---|
| Physical | How are bytes actually laid out on disk? (B-trees, heap files, indices.) | Storage-engine implementers; DBAs know a little. |
| Logical | What data is stored, and what are the relationships? (tables, columns, keys.) | DBAs and application developers — this is the schema. |
| View | What subset does this user see? | End users; also a security boundary. |
The view level does double duty. It simplifies life for users who only need part of the data, and it's a security mechanism: a registrar's clerk sees the student-view but cannot reach instructor salaries. Abstraction here isn't just convenience — it's access control.
The programming-language parallel the book draws is exact: a
struct instructor { char name[20]; numeric salary; } is the
logical description, while "a block of consecutive bytes" is the
physical one, and the compiler hides the physical from you. The database system plays
the same role for data that the compiler plays for types — it translates a clean
abstraction into messy physical reality.
Two words the book is careful to separate, because interviews love to conflate them:
So a schema is stable; an instance changes constantly as rows are inserted and deleted. There are schemas at every level: the physical schema (how stored), the logical schema (the tables), and subschemas (the views). The logical schema matters most because applications are built against it.
Physical data independence is the property that applications don't break when you change the physical schema (reorganize files, add an index). Because the logical schema sits on top and hides the physical, you can swap storage layout underneath without rewriting queries. This is the concrete payoff of the three-level model — it's why adding an index speeds up your queries without you changing a line of application code.
The book also flags a schema-design trap that becomes central in Chapter 7: storing the department budget inside each instructor row means a budget change must be propagated to every instructor — duplicated data waiting to become inconsistent. Good vs bad schema design is the entire subject of normalization.
A data model is the collection of concepts for describing data, relationships, semantics, and constraints. The book surveys four families, and your job is to know which problem each solves — because interview system-design questions often hinge on picking the right one.
| Model | Core idea | Best when |
|---|---|---|
| Relational | Data and relationships both expressed as tables of fixed-format records. | The dominant model; the book spends most of its pages here. Your DDIA storage lesson is the engine under it. |
| Entity-Relationship (E-R) | Entities (things) plus relationships among them; a graphical design notation. | The design phase — sketching what the database should contain before writing tables. |
| Semi-structured | Items of the same type may have different sets of attributes (JSON, XML). | Variable-shape data — posts, profiles, documents. This is the NoSQL side of your consistency lesson. |
| Object-based | Objects with identity, encapsulation, methods — now mostly folded into relational systems. | When behavior travels with the data; largely absorbed via stored procedures and ORMs today. |
The book is unambiguous that the relational model is the foundation almost everyone builds on — Codd's 1970 paper, the System R project at IBM, and the birth of SQL/DB2, Ingres, and Oracle are the historical arc. The takeaway for you: relational is the default assumption in any interview unless the data shape forces otherwise.
The system gives you two complementary languages (which in practice are folded into one, SQL):
DDL declares the schema and the rules the data must obey. The book emphasizes three kinds of integrity constraints the DDL can express — these are the system-enforced promises that replace all that scattered application code:
dept_name on a course must be a real department). Violations are rejected
outright.
The output of DDL is stored in the data dictionary, a special internal table holding metadata — "data about data." The DBMS consults it before every read or write, which is why you can't bypass a constraint by going around SQL.
The DML retrieves, inserts, deletes, and modifies data. The split that matters for interviews is procedural vs declarative:
| Style | You specify | Trade-off |
|---|---|---|
| Procedural | What you want and how to get it (the algorithm). | You keep control of performance, but you must think about storage. |
| Declarative (nonprocedural) | Only what you want; the system figures out how. | Far easier to write; the optimizer must now find an efficient plan (your storage lesson's query layer). |
SQL is a declarative DML. When you write
SELECT ... WHERE, you describe the result; the
query processor decides whether to use an index, what order to join in, and how to
scan — exactly the machinery from your storage lesson. Application programs talk to the
DBMS through APIs (ODBC for C, JDBC for Java), sending DML/DDL strings and reading results
back.
The book decomposes the system into three responsibilities, and this is the architecture diagram you should be able to sketch from memory:
The bridge between low-level disk data and the queries above it. It talks to the OS file system and is responsible for storing, retrieving, and updating data. Its sub-components:
On the physical side it maintains data files (the data), the data dictionary (the metadata), and indices (pointers to rows by value, like the index of a book).
Turns your declarative request into an efficient physical plan:
This is the promised land that fixes the atomicity and concurrency problems from Section 1.2. A transaction is a logical unit of work — like the funds transfer where A is debited and B is credited. It must hold four properties.
ACID is the contract a transaction makes with you:
Atomicity and durability are the system's job (the recovery manager); consistency and isolation are partly yours (correct transaction design) and partly the system's (concurrency control). This is the precise split your Lesson 7 drilled into.
The engine can run on one machine or many, and applications can be shaped a few ways. The book's taxonomy:
| Axis | Options | Meaning |
|---|---|---|
| Engine placement | Centralized / Parallel / Distributed | One shared-memory server → a cluster of machines → machines spread across geographic sites. This is the distributed-systems territory your whole workspace is built around. |
| App shape | Two-tier / Three-tier | Client talks directly to the DB → client talks to an application server which talks to the DB. |
The three-tier architecture is what essentially all modern web and mobile apps use: the browser/phone is a thin front end, an application server holds the business logic, and the database sits behind it. It wins on security and performance because the business rules live in one place instead of being scattered across every client. Note the echo of your Lesson 1: a thin, well-defined boundary is what keeps a system maintainable.
Four user archetypes, by how they interact:
The DBA exists precisely because a DBMS gives you central control over both the data and the programs that touch it — which is the whole point of escaping the ad-hoc file-processing mess from Section 1.2.
When an interviewer asks "Why use a database instead of files?" or "Walk me through what a DBMS guarantees," this chapter is your outline:
1. Schema vs Instance
Structure vs data-at-a-moment Instance is stable, schema changes Schema is DDL, instance is DML2. Physical data independence means:
Users see different subsets of data Apps survive physical-schema changes Apps survive logical-schema changes3. Which problem does a transaction's atomicity directly fix?
Concurrent updates overwriting each other A crash leaving a half-done transfer Users seeing data they shouldn't4. Three-tier architecture's main advantage over two-tier:
Uses fewer servers Centralizes business logic, better security Client connects straight to the DB5. Declarative DML (SQL) shifts the burden of:
Deciding what data to return Deciding how to fetch it efficiently Enforcing integrity constraintsProgram storing interrelated data + abstract read/write ? takes on crash recovery, concurrency, access, storage
File-processing breaks: redundancy+inconsistency, hard access, isolation, integrity, atomicity, concurrency, security
? last 3 = exactly transactions lesson (ch 7)
a) OLTP ? many users, small touches (ATM, post)
b) Analytics ? mine patterns, build models (loan, demand)
a) Physical ? bytes on disk (engines, DBAs)
b) Logical ? tables/relationships = schema (DBAs, devs)
c) View ? per-user subset ; also a security boundary
Schema ? design / declarations (stable)
Instance
? data at a moment (changes constantly)
? change storage (add index, reorganize) ? rewrite apps
a) Relational ? tables of fixed records ; dominant (Codd 1970, System R, SQL)
b) E-R ? entities + relationships ; design sketch
c) Semi-structured ? varying attributes (JSON/XML) ; NoSQL side
d) Object-based ? identity + methods ; folded into relational
a) Domain ? type per attribute
b) Referential integrity ? FK must exist ; violation rejected
c) Authorization ? read/insert/update/delete per user
? output = data dictionary (metadata) ; consulted before every op
a) Procedural ? what + how (you control perf)
b) Declarative (SQL) ? what only ; optimizer finds how
a) Storage mgr ? disk<->app bridge ; auth, txn, file, buffer mgr ; data files + dictionary + indices
b) Query proc ? DDL interp + DML compiler (optimizes plan) + eval engine
c) Txn mgr ? keeps DB consistent under crash + concurrency
A) Atomicity ? all-or-nothing (recovery mgr undoes partial)
C) Consistency ? valid state to valid state
I) Isolation ? no dirty intermediate state (concurrency ctrl)
D) Durability ? committed survives crash (recovery mgr)
A,D = system ; C,I = system + your design
a) Engine: Centralized ? Parallel ? Distributed (geo)
b) App: Two-tier (client<->DB) ? Three-tier (client<->app server<->DB) ; 3-tier = better security/perf
Naive (forms) / App programmers / Sophisticated (own queries) / DBA (central control: schema, auth, backups)
Primary source: Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020).
Database System Concepts, 7th ed., Chapter 1: “Introduction.”
McGraw-Hill.
Recommended supplement: Codd, E. F. (1970). “A Relational Model of Data
for Large Shared Data Banks.” Communications of the ACM, 13(6) — the
paper that started it all.
Questions? Ask your agent — you can follow up on any concept, quiz answer, or how this maps onto a specific FAANG system-design or transactions question.