The previous lesson closed by saying that what lies ahead is not more syllabus but judgment, and that judgment is built with projects and with your own mistakes. That is true, but incomplete: judgment is also built by reading people who have spent thirty years making those mistakes and have had the patience to write them down in order. This lesson is the list of those people.

It is not a catalog. A bibliography catalog — forty titles with no hierarchy — helps nobody: it paralyzes. What you will find here are seven thematic blocks, each with a table saying which lesson of this course each book follows on from and who it is not for, plus detailed profiles of the titles that genuinely deserve your time. At the end there is a three-stage reading path — three months, twelve months, twenty-four months — depending on the professional profile you are heading toward.

Use it like this: do not read it end to end looking for "the good book". Go to the block matching whatever stuck in your throat during the course, read the profile, and buy or borrow from the library one book. One. When you have worked through it — worked through, not skimmed — come back here.

Important warning about availability. Editions, prices, translations and availability in bookshops and libraries change constantly. The edition details given here are indicative and may already be out of date by the time you read this. Before buying anything, check the publisher's or the author's website to see which edition is current. This lesson deliberately quotes no prices: prices change, promotions change, and what has a paperback edition today is out of print tomorrow.

1. Why keep reading books when the official documentation exists
2. How a technical book is read (not cover to cover)
3. Block A — Foundations and theory
4. Block B — Practical SQL
5. Block C — Design and modeling
6. Block D — Performance and engine internals
7. Block E — NoSQL and distributed systems
8. Block F — PostgreSQL specifically
9. Block G — Classics and foundational papers
10. A three-stage reading path
11. Editions, translations and how to get hold of the books
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

It is a reasonable objection. The PostgreSQL manual is exhaustive, it is up to date with the exact version you have installed, it is free and you can search it in two seconds. Why bother with a 900-page book from 2019?

Because they do different jobs. The documentation answers "how do I write this?". The book answers "why does this exist and when should I use it?". Those are different questions and neither replaces the other.

The example you have already lived through: the PostgreSQL documentation describes the four isolation levels with an impeccable table of which anomaly each one allows. That is exactly what you need in order to configure a transaction. But what you did in 06-02 — opening two terminals, seeing the lost update with your own eyes and understanding why READ COMMITTED is the default despite allowing non-repeatable reads — that is not in the manual, and it is not there because the manual is not the place for it.

There is a third reason, less technical and more honest: a book forces a pace on you. Documentation gets consulted in two-minute bursts between tasks, and that teaches you to solve today's problem and nothing else. A chapter read in full, with the database open beside you, leaves a different residue. Almost everyone who knows databases has read books; almost nobody who only consults documentation ends up knowing.

This matters more than the list. A good book badly read is worthless, and the usual way of reading it badly is treating it like a novel: starting on page 1 intending to reach page 900, getting bored on page 60 and abandoning it.

A technical book is not read: it is worked. This is the method.

First, reconnaissance (30-45 minutes). Before reading a single line of content, read the full table of contents twice. Then flip through the whole book quickly: look at the section titles, the tables, the diagrams, the code blocks. Do not understand anything, just look. When you are done you have to be able to say "the index material is here", "this part is about failure recovery", "I won't need this last bit for years". That mental map is what will let you find things later.

Second, choose chapters, not the book. Decide which three or four chapters you are going to work through now, and why. The rest exist for when you need them. A reference book like Silberschatz is not written to be read cover to cover outside a university course; it is written so you have the right chapter when you need it.

Third, with the database open beside you. This is the non-negotiable rule. If the book shows a query, you type it, you run it and you break it on purpose: take out the GROUP BY, change the INNER for a LEFT, put a NULL where it is not expected. What you learn is not the book's example, it is the difference between the example and your broken version. Keep a schema of your own for this — BiblioRed works perfectly — and translate the book's examples into your tables. The translation is half the learning.

Fourth, take notes on decisions, not on definitions. Do not copy out "a candidate key is a minimal set of attributes that...". That is in the book and you can reread it. Write down "if I have a loans table with a null return date, Karwin says the problem is not the NULL but that I am modeling two facts in one row". The useful notes are the ones that argue with a design.

Fifth, allow yourself to abandon it. If after three sessions you have got nothing out of it, close it. Maybe it is not your moment, or maybe that book was written for someone else. Coming back to a book two years later and understanding all of it is a common and pleasant experience; forcing it today only produces guilt.

Sixth, rereading is normal. The books in category D of this lesson get reread. A first reading of "Designing Data-Intensive Applications" when you have never suffered a replication problem is useful but superficial; the second, after having suffered one, is another thing entirely.

These are the university textbooks. Big, expensive, dense and for reference: they are not read whole, they are consulted. Their value is that they treat the subject with rigor and with proofs, something a tutorial never does. If you have ever wondered "where exactly does this BCNF business come from?", the answer is here.

What it is. The reference textbook for the database course in half the world, since the eighties and through many editions. It covers absolutely all of the classic syllabus: relational model, SQL, design, normalization, storage, indexing, query processing and optimization, transactions, concurrency, recovery, distribution and a final part on modern topics.

What it covers from this course. Practically everything in modules 1, 2, 4, 5 and 6, but with the proof behind it. Chapter numbers vary from one edition to another, so search by title in the table of contents:

Level. Undergraduate. It assumes you are comfortable with light mathematical notation (sets, functions) but demands no more than that.

How to work through it. Do not buy it to read it: buy it (or get it from a library) to have it. When "I think there's an update anomaly here" comes up at work, you go to the relational design chapter, read twenty pages and come back with the rigorous answer. The concurrency control chapter is the best possible complement to what you did in 06-02: there you saw the phenomenon, here you see the two-phase locking protocol that prevents it and why.

What to skip. The formal relational algebra part, unless it interests you; you do not need it for work. The final "advanced topics" chapters age fast in every edition. And the SQL chapter, frankly, is better learned from block B.

What it is. The other great textbook. It competes head to head with Silberschatz and the choice between them is largely a matter of taste. Its distinguishing feature is that it devotes far more space and far better treatment to conceptual modeling.

What it covers from this course. Its natural territory is modules 4 and 5. The part on the ER and extended ER model, and on transforming diagrams into relational schemas, is the most complete of the three books in this block and is the direct continuation of 04-02 and 04-03. It also covers functional dependencies and the lossless decomposition algorithm in depth, which in 05-03 you applied in practice without proving.

Level. Undergraduate, slightly drier than Silberschatz.

How to work through it. If you are going to model schemas professionally, read the whole conceptual design part, redoing the BiblioRed diagram in its notation. You will see that Elmasri-Navathe's notation differs from the crow's-foot notation you used with Mermaid; being able to read both is useful because in companies' older documentation you will run into both.

What to skip. Everything else, honestly, if you already have Silberschatz. Having both is redundant for 95% of people.

What it is. A book from a different tradition. Date was a colleague of E. F. Codd and has devoted his career to defending the relational model in its pure version, which leads him to criticize SQL harshly and persistently: duplicates, NULLs, column order, everything SQL does that relational theory does not allow.

What it covers from this course. It provides the theoretical grounding for 02-01. After reading it you will understand why that lesson insisted that a relation is a set of tuples and that the SQL table is not quite that.

Level. High in conceptual demand, though not in mathematics. It is a book of ideas.

How to work through it. As argumentative reading, not as reference. Read the chapters on relations, on NULL and on integrity, and contrast them with what you do day to day. The chapter on null values is going to make you uncomfortable, and that discomfort is productive: the next time you add a NULL column in BiblioRed you will ask yourself whether you are representing "I don't know", "not applicable" or "not yet", which are three different things that SQL rolls into one.

What to skip. It is a book you can read in parts with no problem at all. And it is perfectly legitimate never to read it: it is the only one in this lesson that is a recommendation for a minority.

This is where most people should start. These are books that translate directly into better work the following week.

What it is. The book closest in spirit to lesson 04-01 of this course. Each chapter presents a real anti-pattern — with the colloquial name it has in the trade — explains why people fall into it, when it is legitimate (there is always a case where it is) and what the correct alternative is.

What it covers. Logical design anti-patterns (comma-separated lists inside a column, badly represented hierarchies, poorly chosen primary keys, misuse of NULL, entity-attribute-value), physical design, query and application development anti-patterns, SQL injection included.

Level. Medium. You need to know SQL, but nothing advanced is required.

How to work through it. This one is read whole and in order, because it is a cumulative argument. And it is read with the BiblioRed schema in front of you: for each chapter, ask yourself whether your schema commits that sin. You will find one, and that exercise is worth more than any summary. The chapter on representing hierarchies connects directly with what you solved in module 4 with the material categories.

What to skip. Nothing, it is short. If you are in a hurry, prioritize the logical design chapters over the application development ones, which are the most tied to specific technologies and therefore the ones that age worst.

What it is. A cookbook in the literal sense: two hundred-odd concrete problems ("how to find gaps in a sequence of dates", "how to compute a moving average", "how to pivot rows into columns") with their SQL solution, explained step by step and — this is the valuable part — with the variant for each engine where they differ.

What it covers. The territory of module 7, especially 07-04. Window functions, hierarchical queries, date manipulation, pivoting, deduplication, calculations between consecutive rows.

Level. Medium-high. It is not for learning SQL, it is for stopping writing bad SQL.

How to work through it. By lookup, when you have the problem. But there is one exception: read the window functions chapter in full, even if you do not need it right now. It is the biggest productivity jump available to someone who already knows GROUP BY, and it is exactly the frontier this course has left you at. If in 07-04 the "the same member's previous loan" queries gave you trouble, this chapter is your answer.

What to skip. The sections for engines you do not use. If you work with PostgreSQL, the Oracle and SQL Server variants are noise on a first reading.

What it is. A well-built introductory manual, progressive and with exercises. It is the book you would recommend to someone arriving without having taken this course.

What it covers. The whole of module 2, with more exercises and at a slower pace. It adds transactions, views, indexes and constraints at an introductory level.

Level. Beginner.

How to work through it. If module 2 felt comfortable, skip it: it will not add anything. If in 02-04 the JOINs and correlated subqueries gave you trouble — and that is the most common case — work through it whole, with its exercises, over three or four weeks. It is the best possible use of that time. Use MySQL or whichever engine the book ships with to follow its examples, or better still, translate its examples to PostgreSQL and to the BiblioRed tables.

What to skip. The final chapters on advanced topics, which are better handled in other books in this lesson.

What it is. A complete method for designing relational databases explained without a single formula. Where Elmasri proves, Hernandez gives you a list of steps and of questions to ask the client.

What it covers. The whole of module 4, with an approach based more on process than on notation: how to interview users, how to identify entities from what they say, how to clean up field lists, how to establish and validate relationships, how to write the business rules the constraints will have to implement. It also reaches normalization, but by the informal route.

Level. Accessible. It is the design book for people who did not come from computer science.

How to work through it. By applying its method to a domain other than the book's. Exercise 1 of this lesson is exactly about that.

What to skip. Its treatment of normalization is correct but weak compared with what you already know after module 5. If you have just finished that module, that part is surplus for you.

What it is. The founding book of dimensional modeling, that is, of designing databases meant for analyzing rather than for operating. Kimball is the one who popularized the star schema presented to you at the end of 05-04 as the canonical example of deliberate denormalization.

What it covers. Fact tables and dimension tables, granularity, slowly changing dimensions (the famous "the member has moved house, what happens to the loans they made before?" problem), and a very long collection of industry cases.

Level. Medium-high, but conceptually accessible; the hard part is not understanding it, it is applying it well.

How to work through it. Read the first part — the dimensional fundamentals chapters — and just one of the industry cases, the one closest to your work. Then design the star schema for BiblioRed's loans: fact table loans, dimensions member, material, branch, time. That is exercise 2 of this lesson.

What to skip. The fifteen industry-case chapters that do not concern you. The book is meant to be consulted by sector, not read cover to cover.

This is by far the most important block of the lesson for someone who has already taken this course. It contains the book to recommend if only one is going to be read.

What it is. A short, surgical book about one single thing: how indexes work and why your queries do not use them. Its content is also available on the author's website, https://use-the-index-luke.com/, which is one of the most useful and free references in existence on the subject.

What it covers. B-tree structure, column order in a composite index (and why it is the number one source of useless indexes), predicates that prevent index use, LIKE with a leading wildcard, functions over indexed columns, indexes that cover the query, sorting and grouping that take advantage of the index, and efficient pagination.

Level. Medium, and surprisingly easy for what it teaches.

How to work through it. It is the exact continuation of 06-03. There you learned to read an EXPLAIN and to tell a sequential scan from an index scan; here you learn to predict which one you are going to get before running anything. Work through it with the database in front of you and with enough volume: if your tables have 50 rows, the planner will do a sequential scan every time and you will learn nothing. Generate half a million fictitious loans in BiblioRed (in 09-03 you will see how) and repeat every example from the book.

What to skip. Nothing. It is short on purpose. If you have to choose, the chapter on column order in composite indexes and the one on pagination are the ones that return the most performance per page read.

What it is. The book to read after this course if only one is going to be read. It is not a database book: it is a book about systems that handle data, which includes databases as one piece. And it is the best existing synthesis of academic theory and industrial practice.

What it covers. Data models (relational, document, graph) and why each one won where it won; storage and retrieval engines, with B-trees versus LSM-trees; encoding and schema evolution; replication; partitioning; transactions and isolation levels, with the best popular treatment in existence of snapshot isolation and of the write skew anomaly; the problems of distributed systems — clocks, partial failures, the network's lies; consistency and consensus; and a final part on batch and stream processing.

Level. Medium-high, but very well written. This course leaves you in a position to read it.

How to work through it. Whole and in order; it is an argument, not a reference. A reasonable pace: one chapter a week, taking notes. Its transactions and replication chapters are the natural continuation of 06-01 and 06-02, and the whole final part is what grounds what you did by feel in 08-03: when the book talks about change data capture it will be describing, by its proper name and with its failure modes studied, exactly the outbox table pattern you used to synchronize PostgreSQL with MongoDB and Elasticsearch. Each chapter ends with a vast annotated bibliography that is, in practice, a map of the entire literature of the field.

What to skip. Nothing on a first reading, although the consensus chapters are the toughest and it is legitimate to leave them for a second pass. The book's website is https://dataintensive.net/.

What it is. The book that opens up the engine that 01-04 only described from the outside. It divides into two clearly distinct halves: storage (how data is really kept on disk) and distributed systems (how several machines come to agree).

What it covers. Page and file formats, B-trees in detail and their real-world variants, LSM-trees and compaction, buffer management, write-ahead logging (the WAL that appeared in 06-01 as the durability guarantee), and then failure dissemination, failure detectors, leaders, replication and consensus.

Level. High. It is the most demanding in the lesson, along with Date.

How to work through it. Only if curiosity bites. It will not make you better at your job next week, but it explains why PostgreSQL and Cassandra behave so differently under heavy writes: one uses B-trees and the other LSM-trees, and everything else follows from that. Read the first half; the second overlaps with Kleppmann and Kleppmann is more readable.

What it is. A deliberately brief book that does what its title says: distill. It is the origin of the term polyglot persistence that structured the whole of lesson 08-03.

What it covers. Aggregate models, the four families (key-value, document, column family, graph), distribution, consistency, the CAP theorem explained without mysticism, and engine selection.

Level. Accessible.

How to work through it. It is the companion reading for module 3. It reads in two evenings.

What to skip. Its map-reduce chapter and some specific product examples have aged — the NoSQL engine landscape changed a great deal after it was published — but the conceptual framework is still the right one. Read it for the ideas, not for the products.

The MongoDB Manual deserves a place in a lesson about books because it works like one. It has a deliberate progression, chapters on concepts and not just on reference, and a data modeling section that is required reading after 03-03. It is free, it is always up to date and it does not age. When in 08-02 you decided to embed the incidents inside the bicycle document rather than reference them, you were applying what that section explains formally. Root link: https://www.mongodb.com/docs/.

PostgreSQL has been the main engine throughout this course, so these two books are the ones with the most immediate application.

What it is. A book with a clear thesis: most developers use the database as a dumb store and write in their application language things SQL solves better. Each chapter demonstrates the thesis with a case: a query that takes two hundred lines in the application and twenty in SQL, and is faster on top of that.

What it covers. Advanced SQL with PostgreSQL's specific tools: window functions, common table expressions, LATERAL, rich data types (ranges, jsonb, arrays, geometric types), extensions, and a notable section on modeling.

Level. Medium-high. You need module 2 settled.

How to work through it. It is the perfect complement to 07-04. Take it chapter by chapter and, for each new technique, look for where it would fit in BiblioRed. The range types chapter, for instance, solves in one stroke the overlapping room reservations problem that in module 7 you had to attack with constraints and manual checks: PostgreSQL has an exclusion constraint that does it declaratively.

What to skip. Nothing relevant, but it is a book to be consumed slowly.

Do not treat it as a mere lookup manual. Its Tutorial, The SQL Language and Server Administration parts are book chapters in every respect. In 09-02 you will find a recommended reading order for the full manual; here it is enough to say that if you had to keep a single text about PostgreSQL, it would be this one, and it is free.

There is an idea here worth defending: reading original papers is easier than it looks and more useful than people assume. The reputation for inaccessibility that academic papers have comes from the wrong field; in databases, the foundational papers were written by engineers who wanted to be understood.

What it is. The paper that invented the relational model, published in Communications of the ACM, volume 13, issue 6, in June 1970. It was cited in 01-03 when telling the history; here the recommendation is that you read it in full.

Why it is worth it. It is about twelve pages. And in those twelve pages sits, already formulated, almost everything you have studied in modules 2, 4 and 5: the independence of data from its physical representation, relations as sets of tuples, keys, redundancy and anomalies, and even a first sketch of normalization. Reading it produces a useful effect: discovering that the ideas taught to you as "this is how it's done" were a contested proposal by one specific person, against the consensus of the time, which was the hierarchical and network models.

How to get it. It is available in the ACM digital library (https://dl.acm.org/) and reproduced in many university repositories. Search for its exact title; no subscription is needed to find a legitimate copy.

How to read it. Two passes. The first, whole and without stopping, accepting that 1970 notation differs from today's. The second, translating its vocabulary into yours: where it says relation think table, where it says domain think data type, where it talks about nonsimple domains it is anticipating the debate that fifty years later reappeared as jsonb and nested documents.

A note on why to read originals. When you read a summary of the CAP theorem on a blog, you are reading the interpretation of someone who read someone who read Brewer. Every link simplifies and distorts. CAP is the canonical example: the blog version ("pick two out of three") is flatly false, and Brewer himself wrote the 2012 paper to correct it. The originals cost you an evening and inoculate you against a decade of repeated simplifications.

No reading path works for everyone. These three are built from where this course leaves you, toward three different professional destinations.

In table form, with the detail of why each choice:

Three warnings about the path. One: that is about eight books in two years, and that is already an ambitious pace for someone who also has a job. If you do half, you are doing fine. Two: the order matters more than the quantity; reading Kleppmann before having suffered a real data problem is reading it by halves. Three: if you are only going to do one thing from this whole lesson, let it be reading "Designing Data-Intensive Applications" over the coming year, whatever your profile.

Editions. The block A textbooks are on very advanced editions and each new edition reorders chapters and adds modern topics. For the use you are going to make of them, an earlier edition works perfectly and is far easier to get hold of: relational theory and the normal forms have not changed. Where a recent edition does matter is in the books tied to a product — PostgreSQL, MongoDB — because engine versions move on and the examples stop working.

Translations. The situation is uneven and changes over time. The classic textbooks have had translations at some point, sometimes of old editions; more recent books and those from small technical publishers are usually only in English. Check before buying and do not assume a translated version of a specific title exists. Put bluntly: being able to read technical English is, at this point, part of the job, and it is far easier than it looks because the vocabulary is the one you already know.

Where to get them. University libraries (the block A books are in every computer science school library), public libraries with interlibrary loan, electronic editions from the publishers themselves, and the technical reading subscriptions that many companies already pay for without their employees knowing — ask at work before buying anything. Several of the resources cited are free and legal: the PostgreSQL manual, the MongoDB Manual, the content of use-the-index-luke.com and Codd's paper.

And once again, the warning that opens the lesson: availability, current editions, formats and prices change. Always check at the official source — the publisher's or the author's website — before buying.

Mistake 1: buying five books at once. It is the most effective way of reading none of them. The pile of unread books generates guilt, and guilt generates avoidance. One at a time.

Mistake 2: starting with the fattest one. Silberschatz has nine hundred pages and looks like "the complete one", so a lot of people start there and give up in chapter 3. Start with "SQL Antipatterns" or with "SQL Performance Explained", which are short, get finished and produce visible results. Finishing a technical book generates the momentum for the next one.

Mistake 3: reading without a keyboard. It has been said already and is repeated because it is the dominant mistake. A technical book read on the subway is entertainment; read with the database open it is training.

Mistake 4: believing the old edition is worthless. For theory, the edition from fifteen years ago is identical in everything that matters to you. Do not skip a classic because the only edition you can find is an old one.

Mistake 5: confusing "well known" with "right for me now". "Database Internals" is an excellent book and it is a waste of time for someone still hesitating over LEFT JOINs. The best book is the one one step above where you are, not five.

Mistake 6: not rereading. The three or four central books of your career get reread every few years and each time they say something different, because the one who has changed is you.

Tip 1: keep a list of "concepts I didn't understand". Every time a book mentions something you do not know — write-ahead log, LSM-tree, slowly changing dimension — write it down instead of stopping. When you finish the chapter, resolve the three most repeated ones. Stopping at each one means you never finish.

Tip 2: always use the same practice schema. Translate every example from every book to BiblioRed or to VallBici. Having a domain of your own that you know inside out turns every new example into a comparison, and comparisons are what stick.

Tip 3: a good book's bibliography is a map. Kleppmann ends every chapter with dozens of annotated references. When a topic hooks you, that bibliography is a better guide than any internet search.

Tip 4: distrust lists without judgment, including this one if you do not cross-check it. A book being here means it has served a lot of people, not that it will serve you. Skim before committing thirty hours.

These exercises are not about memory: they are about planning and real practice. They have no single correct answer, and the solutions that follow are reasoned model answers, not the answer. Your path will differ from the one shown here and it will be fine if the reasoning holds up.

Design your own reading plan for the next twelve months. It must include, without exception:

1. An honest self-assessment: of the 33 previous lessons of this course, which three do you have the weakest grip on? Be specific (not "module 6", but "I wouldn't know how to choose between READ COMMITTED and REPEATABLE READ for closing a loan").
2. A target profile among the three in section 10, or a justified mixture.
3. Three books at most, with the order you will read them in and why in that order.
4. For each book: which specific chapters you will work through first and which you will postpone.
5. A deliverable per book: something built on BiblioRed or VallBici that proves you have worked through it.
6. A realistic estimate of weekly hours and the date on which you will review the plan.

Choose one of these two assignments and develop it to the point where you could defend it in writing on one page:

Option A (Kimball). Design the star schema for analyzing BiblioRed's loans: identify the fact table, its exact granularity, its measures, and the dimensions required. Explicitly solve the slowly changing dimension problem: a member moves to another district; should the loans they made last year be attributed to the old district or the new one? Justify the decision and explain how you would implement it.

Option B (Karwin). Audit BiblioRed's relational schema from modules 4 and 5 looking for anti-patterns: multivalued columns, primary keys chosen without criteria, badly represented hierarchies, ambiguous uses of NULL, disguised entity-attribute-value. List the ones you find — or the ones you were on the verge of introducing — and, for each, say what the alternative would be and in which case the anti-pattern would have been acceptable.

Find and read in full E. F. Codd's 1970 paper, "A Relational Model of Data for Large Shared Data Banks". Then answer in writing, in no more than one page:

1. Which specific problem of the systems of his time does Codd say he is setting out to solve?
2. Point out two ideas from the paper that you have studied in this course and say in which lesson they appeared.
3. Point out one idea from the paper that this course has not covered, or has covered differently.
4. Is there anything in the paper that today we would consider superseded or wrong?

Remember: these are model answers, not the only correct ones. What is being assessed is the quality of the reasoning, not agreement with what follows.

Solution 1 (model answer)

A well-built plan, for a back-end application development profile:

Self-assessment. (a) I cannot predict whether the planner will use an index; in 06-03 I understood the EXPLAIN after the fact but I do not anticipate the plan. (b) In 05-03 I normalized by following the procedure, but faced with someone else's schema I would not know how to spot the transitive dependency unless it were pointed out to me. (c) In 08-03 I understood the synchronization with an outbox table but I would not know how to reason about what happens if the process reading it dies halfway through.

Profile. Application development, with one foot in administration because my team has no specialist.

Books and order.

Deliverables.

1. A document with five slow BiblioRed queries over 500,000 fictitious loans, their plan before and after, the index created in each case and the justification for its column order.
2. A written audit of the BiblioRed schema with the anti-patterns detected and the proposed correction for each one.
3. A working implementation of the outbox pattern from 08-03 between PostgreSQL and MongoDB, with a deliberate test: kill the reader process mid-batch and document what happens and why no event is lost.

Pace. Four hours a week, in two two-hour sessions. Plan review at three months: if by then I have not finished the first book, the problem is the pace, not the book, and I cut the plan down to two books.

Solution 2 (model answer, option A)

Fact table: loan_facts.

Granularity: one row per individual loan of a copy. It is the most important decision in the design and it has to be declared before choosing any column. The finest available granularity is chosen because from it you can aggregate to any level (month, branch, category), whereas from an already aggregated table you cannot go back down.

Measures: loan_days, days_overdue, fine_amount, and an implicit counter (each row is one loan).

Dimensions: dim_member, dim_material, dim_copy, dim_branch, dim_loan_date, dim_return_date. The two date dimensions point to the same calendar table in two different roles.

The slowly changing dimension. The member moves to another district. There are three classic treatments and the choice depends on the business question:

Decision for BiblioRed: new versioned row. Reason: the main analytical use is measuring reading activity by district over time in order to decide where to reinforce the collection. If a member moving rewrote their history, last year's report would change every time somebody moves, and a report that changes backwards is no use for making decisions or for accountability. The fact table stores the surrogate key of the version in force at the moment of the loan, not the member's natural identifier.

An honest nuance: if the business question were "where do our most active members live today?", the overwrite treatment would be the correct one and versioning would be overkill. The answer depends on the question, which is why dimensional design always starts from the questions and not from the tables.

Solution 3 (model answer)

1. The problem. Codd points out that in the systems of his time — hierarchical and network — application programs depended on how the data was physically stored and ordered: changing an index, an order or a pointer structure forced programs to be rewritten. His proposal seeks the independence of the data from its internal representation.

2. Two ideas already seen. (a) Relations as sets of tuples over domains, with row order irrelevant: it is the foundation of 02-01. (b) The elimination of redundancy and the anomalies it produces, with the seed of normalization: 05-01 and 05-02.

3. One idea covered differently. Codd develops a relational calculus and algebra as a query language; this course has used SQL directly, which is a partial and not entirely faithful commercial implementation of those ideas (SQL admits duplicates and order, things the pure relation does not have). That mismatch is exactly what C. J. Date has been pointing out for decades.

4. What has been left behind. The concern with storage cost and with the efficiency of representations, very present in the paper, is on another scale today; and its treatment of nonsimple domains — relations inside relations — was left out of the practical relational model, though it reappeared decades later through another door with the jsonb types and the nested documents you used in module 3. Nothing in the core of the paper is superseded, which is exactly what is remarkable about a text more than fifty years old.

A resources module always runs the risk of being a list, and a list without judgment is worth nothing. That is why this lesson has insisted more on how to read and in what order than on how many titles exist.

Three things to take away.

The first: the book and the documentation do different jobs. The PostgreSQL documentation will always tell you the exact syntax of CREATE INDEX and will never tell you whether that index makes sense. For the second you need someone who has seen a thousand useless indexes and has sat down to write why they were useless. Keep using the manual daily — it is excellent — and read books separately.

The second: a technical book is worked, not read. With the keyboard in front of you, translating every example to a schema you know, breaking the queries on purpose and noting decisions instead of definitions. One chapter worked that way is worth ten read on the sofa.

And the third: fewer books, more times. If you take a single title from this whole lesson, let it be "Designing Data-Intensive Applications" by Martin Kleppmann for the next twelve months; and if you want a visible result in three weeks instead of in a year, start with "SQL Performance Explained" by Markus Winand, which is the exact continuation of 06-03 and is finished in a few evenings. And bear in mind what has been repeated: editions, translations, availability and prices change; always check at the official source before buying.

Books give order and judgment, but they are a slow, solitary format. Lesson 09-02 covers the other side of self-directed learning: the official documentation studied seriously, the platforms where SQL is practiced with automatic grading, the university courses published openly, and how to build from all of it a twelve-week study plan that starts exactly where this course has left you.