Database systems are easier to learn when you connect their ideas rather than memorise them separately. A query is shaped by a data model, constrained by integrity rules, and carried out using storage and execution choices. Your study should make those connections visible, then test whether you can use them on unfamiliar examples.
There is no single database-systems exam structure that applies to every course. Start with your course outline and assessment guidance: they determine which topics matter, how much time to spend on them, and whether you need to practise SQL, design, calculations, written explanations or a mix. The method below works through the main subject areas and can be adjusted to your syllabus.
1. Turn your course outline into a revision board
Gather your lecture slides, textbook notes, lab exercises and any photographed handwritten notes. Sort them under the headings used by your course, rather than making one long set of notes. Keep examples with the concept they demonstrate: a normalisation example belongs with functional dependencies, and a query plan belongs with indexes and execution.
A useful board has sections for the relational model and algebra, SQL, schema design, transactions, and storage and query processing. If your course covers distributed databases, add that as a separate section. Each section should contain concise rules, worked examples and the mistakes you need to watch for. Avoid copying whole lectures: extract the definitions and steps you would need to solve a problem.
A MySummaries revision board on this topic might group the candidate’s notes like this:
- A relation is a set of tuples; tuple order is not significant.
- A candidate key is a minimal superkey; a primary key is the chosen candidate key.
- A foreign key references a key in another relation, or in the same relation.
- Atomicity, consistency, isolation and durability describe transaction guarantees.
- A lost update occurs when one transaction overwrites another transaction’s write.
- Serializability asks whether concurrent execution is equivalent to some serial order.
WHERE filters rows before grouping; HAVING filters groups. Comparisons with NULL evaluate to UNKNOWN, so use IS NULL rather than = NULL.
A B+ tree supports ordered traversal and range searches; a hash index is suited to equality lookup. The optimiser estimates the cost of alternative plans using data and index statistics.
- X → Y means each X value determines one Y value.
- A lossless decomposition can reconstruct the original relation without spurious tuples.
- Dependency preservation lets constraints be checked without joining decomposed relations.
Use the board to expose what you do not yet understand. A section with a definition but no example is not finished. Add one small example that forces you to apply the rule, such as tracing a join or testing whether a decomposition is lossless.
2. Build a short “must not miss” checklist
Before drilling details, make a compact checklist of ideas that recur across the subject. Keep it to a few statements, and use it to check your explanations and worked solutions. These are not substitutes for your course materials: the syllabus may include additional topics or use particular conventions.
For database systems, a useful checklist might be:
Use this checklist as a diagnostic. If you cannot explain why each statement is true or give a counterexample to a tempting wrong version, return to the relevant board section. For example, “all indexes make every query faster” is not a safe rule: indexes take space and add work to inserts, updates and deletes, and the optimiser may prefer a scan.
3. Study actively with one-fact flashcards
Make flashcards for facts that can be recalled in a short answer. Good prompts have one target: a definition, a SQL behaviour, an algorithm step or a distinction. Avoid cards that ask you to explain an entire topic. For a multi-step skill, make a separate problem to solve on paper or in your SQL environment.
When you review, read the question, retrieve an answer without looking, then turn the card and compare your answer with the expected one. Grade honestly: choose “Again” if you could not retrieve it, not “Good” because the answer looks familiar. Revisit the card when it is due, and use repeated mistakes to improve the source notes. Here is a short deck to work through:
What makes a superkey a candidate key?
It is minimal: it determines all attributes, and no proper subset of it does.
All 8 cards
That is a MySummaries deck, filled with database systems material. Yours is written from your own notes. Start free
A card review is not enough for procedural knowledge. If the prompt asks you to find a candidate key, test functional dependencies or write a query, solve a fresh example without seeing a worked answer. Flashcards help you retrieve the rules needed for that work; they do not replace doing it.
4. Practise the subject as a chain of decisions
For each topic, use a repeatable problem-solving routine. In schema design, write down the relation and its functional dependencies, identify candidate keys, then check the normal-form requirements your course teaches. When decomposing, check both losslessness and dependency preservation; do not assume that satisfying one guarantees the other.
For SQL, state the intended output in plain language before writing the query. Identify the tables and join conditions, decide whether filtering happens before or after grouping, and then check for duplicate rows and NULL behaviour. Test the query against a tiny hand-made dataset that includes a missing value or a row with no match. This often reveals errors that a query which merely looks plausible will hide.
For transactions, draw the read and write operations in order. Mark conflicting operations on the same data item, build the precedence graph, and check for a cycle when testing conflict serializability. Then explain the anomaly or guarantee in words. For query processing, trace how a plan changes the work: compare a full scan with an index lookup, or consider whether a selection can be applied before a join. Follow the cost model and assumptions taught in your course rather than memorising a universal rule about which plan is fastest.
After solving a problem, record the point where your reasoning first went wrong. “Got the answer wrong” is not useful feedback; “treated HAVING like a row filter” or “forgot the join condition can multiply rows” gives you something specific to fix. Turn repeated errors into a board note or a short retrieval prompt.
5. Use a short audio explanation to connect ideas
Audio revision can help when you need to revisit a topic away from your desk, but listen with a task. Before playing a lecture, choose one question you want it to answer. Pause afterwards and explain the idea aloud from memory. If you cannot, return to the relevant board section and check the exact wording or example.
A MySummaries lecture generated from the board can give one connected explanation rather than reading out disconnected terms. For example, it can follow how a query moves from SQL to an execution plan:
Transcript · tap any word to jump there
Start with what the query asks for, not with an index you happen to know about. A SELECT statement describes a result; the database system still has to choose an execution strategy. The WHERE clause identifies row conditions, while GROUP BY and HAVING determine how groups are formed and filtered.
Now consider a join. One possible plan scans both inputs and compares rows; another uses an index to find matching rows. Which is cheaper depends on the number of rows, the available indexes, and the estimates the optimiser has from statistics. An index can help, but it is not automatically the best choice, and maintaining it has a cost.
When you study a plan, trace the operations and ask what each one consumes and produces. Check whether filtering can reduce the input before a join, and make sure the plan still returns the rows the SQL requests. The useful habit is to justify a choice from the query and its data assumptions, rather than claiming that one operator is always faster.
6. Run a weekly feedback loop
Set a regular cycle that combines retrieval, problem-solving and repair. For example, use three or four sessions of 45–60 minutes each week, adjusting the number to your available time and course workload:
- Session 1 — Retrieve: Review due cards, then close your notes and explain one board section from memory. Check gaps against your notes.
- Session 2 — Solve: Work through a new SQL, normalisation or transaction problem. Pick the topic according to your course schedule, and show the intermediate steps.
- Session 3 — Repair: Revisit errors from the previous session. Redo the problem without the solution, then write a concise note about the cause of the error.
- Optional session 4 — Connect: Listen to a short board-based lecture or explain a topic aloud, then answer a fresh question that combines it with another topic.
At the end of the week, look at evidence rather than hours alone: which problems could you now solve without notes, which errors recurred, and which syllabus section has not yet had a proper practice task? Plan the next week around the weakest important area. If a topic is not in your course, do not let a general guide displace time from your own assessed material.
How MySummaries helps
Build a board from your database-systems notes, then use it to generate spaced-repetition flashcards and an audio lecture from the material you need to review. Start at portal.mysummaries.app.