A 4-week DBMS exam study plan

Length:
4 weeks
Time needed:
8 hrs/week (32 hrs total)
Written for:
Undergrads revising for a semester-end DBMS paper

Most DBMS papers reward two things: being able to normalise a messy relation on paper, and being able to reason about what a transaction does when something goes wrong. Everything else — the history of the relational model, the diagrams of storage hierarchies — carries fewer marks than the time students spend on it.

This plan front-loads the two topics that take longest to click (normalisation and concurrency control) and leaves the last week entirely for past papers, because that is where most of the marks are actually won. It assumes roughly 8 hours a week, which is two evenings plus a weekend morning.

If you have less than four weeks, cut Week 3 rather than Week 1. Indexing questions are usually worth fewer marks than normalisation and are easier to bluff from first principles.

Week by week

  1. Week 1The relational model and normalisation

    • Relations, keys, and the difference between a candidate key and a super key — get this precise, it underpins everything after it.
    • Functional dependencies: how to read them, how to find the closure of an attribute set.
    • 1NF through BCNF, working forwards on at least six different relations by hand.
    • Lossless-join and dependency-preserving decomposition — examiners love asking whether a given decomposition is both.

    By the end of the week: You can take an unnormalised relation you have never seen, decompose it to BCNF, and justify each step.

  2. Week 2SQL you can write under time pressure

    • Joins, including the ones people avoid: self-joins and outer joins with filters in the ON clause versus the WHERE clause.
    • Aggregations with GROUP BY and HAVING, and why HAVING is not just a second WHERE.
    • Subqueries, correlated subqueries, and rewriting one as a join.
    • Write queries by hand on paper, not in an editor — autocomplete hides exactly the syntax the exam tests.

    By the end of the week: You can write a correct three-table join with an aggregate and a filter in under five minutes, on paper.

  3. Week 3Transactions, concurrency, and indexing

    • ACID properties, stated in your own words rather than memorised.
    • Schedules: conflict serialisability, precedence graphs, and testing a schedule for it.
    • Two-phase locking, deadlocks, and why strict 2PL exists.
    • B+ trees: insertion and splitting, traced by hand on at least three examples. Hashing at a high level only.

    By the end of the week: You can draw a precedence graph for an unseen schedule and say whether it is serialisable, with reasoning.

  4. Week 4Past papers and gap-closing

    • Three full past papers under exam conditions, timed, no notes.
    • After each one, list every question you could not start — those are your real gaps, not the ones you feel unsure about.
    • Re-do only the topics on that list. Resist the pull to revise what you already know well.
    • One light pass over ER diagrams and the ER-to-relational mapping rules the night before.

    By the end of the week: Three completed past papers and a shrinking list of topics you cannot start.

Where people lose time on this

  • Reading the textbook cover to cover. DBMS papers are procedural — you get marks for doing normalisation, not for recognising it.
  • Practising SQL only in a database that autocompletes and error-checks for you. The exam gives you neither.
  • Leaving past papers to the last two days. They are a diagnostic tool, and a diagnosis is useless if there is no time left to act on it.
  • Memorising the ACID acronym without being able to give an example of a violation of each. Examiners ask for the example.

Common questions

Is four weeks enough for DBMS?

For a semester paper, yes, if you have attended most lectures. Four weeks at eight hours a week is roughly 32 hours, which is enough to cover normalisation, SQL, transactions and indexing properly. It is not enough to learn the subject from zero — if you are starting from nothing, expect to need closer to 60 hours.

Should I learn SQL first or normalisation first?

Normalisation first. It teaches you how relations are structured, which makes joins intuitive rather than something you memorise. Doing it the other way round works, but you tend to write queries without understanding why the schema looks the way it does.

How much of the paper is usually numerical?

It varies by university, but typically 40–60% of marks come from questions where you produce something: decompose a relation, write a query, trace a B+ tree insertion, draw a precedence graph. Check your own past papers and weight your revision accordingly — this is the single most useful hour you can spend.

Related plans

Last reviewed