Overview
In this part, we shift from using an existing schema to designing one. Up to this point, most of the database questions have started with tables that already exist. Now the course turns to the earlier design questions that shape those tables in the first place.
As in earlier parts, the course still uses two recurring contexts. Some chapters work on the familiar course-platform example so that the design concepts stay stable. The study tracker project is present at the project checkpoint as the long-running project track. This part also introduces a handful of smaller case descriptions to give you more practice on varied domains.
Design is a judgment skill, not a vocabulary one. Reading about entities and relationships is useful, but much of the learning happens when you try to read a short prose description, decide what the important subjects of the domain are, and then check whether your design can actually answer the questions the system should support. That is why this part contains more case descriptions and partial-task exercises than the earlier parts.
The structure of this part is as follows:
- The Database Design Process explains why design starts from domain questions and expected use rather than from table syntax.
- Reading a Case Description introduces subject analysis as a reading skill and walks through one worked example in detail.
- Practicing Subject Analysis asks you to do the same work on two fresh cases before moving on.
- Entities and Attributes asks which ideas deserve their own identity and which ideas simply describe something else.
- Relationships, Cardinality, and Optionality connects conceptual modeling to the relationship paths that earlier SQL chapters already used.
- Entity-Relationship Diagrams teaches a small diagram notation and revisits diagrams as a design tool rather than only a reading aid.
- Testing a Design Against Its Questions walks a draft model through its expected questions to see whether the structure actually supports them.
- Keys, Identifiers, and Stability discusses what lets the model refer to entities stably over time.
- Design Patterns and Anti-Patterns looks at a few strong early design habits and a few warning signs worth noticing before formal normalization.
- Documenting a Design shows what a finished design package looks like and how its parts fit together.
- Project Checkpoint asks you to create a design package for the study tracker project, including a subject-analysis note, an ER diagram, and a design rationale.
This part is a little longer than the previous ones because it adds more practice room. A useful way to read it is to treat each case description as a small exercise in its own right, even when the chapter does not formally ask you to submit anything.
If terminology starts to feel dense, keep the glossary nearby. Most of the core words come back in the next part when the design becomes a concrete schema.
Recommended Order of Work
A useful rhythm for this part is:
- read the regular chapters in order,
- complete the chapter-level exercises as you go,
- complete the part’s project checkpoint,
- and finish with the recap quiz and feedback form.
Finally, at the end of the part, there is a recap and feedback chapter that briefly summarizes the part and asks for feedback.