13 August 2026 · 8 min read
A database design assignment usually gives you a scenario — a clinic, a library, a small logistics firm — and asks for an ER diagram, a relational schema, normalisation to third normal form and some SQL. The scenario is written so that the entities and relationships are recoverable from the text, if you read it methodically.
Nouns are candidate entities: patient, appointment, doctor, prescription. Verbs are candidate relationships: a doctor sees many patients, a patient books many appointments. Adjectives and descriptive phrases are candidate attributes. Work through the text line by line and build three lists before drawing anything — most design errors come from starting the diagram too early.
Each entity becomes a table. One-to-many relationships put the foreign key on the many side. Many-to-many relationships become their own table. Choose primary keys deliberately: a surrogate key is usually cleaner than a natural key that might change, and if you use a natural key, say why it is stable and unique. Specify data types, nullability and the referential integrity actions on delete and update — most rubrics award marks for constraints.
Do not simply present a normalised schema. Show the progression: an unnormalised table, then 1NF by removing repeating groups and giving every field an atomic value, then 2NF by removing partial dependencies on part of a composite key, then 3NF by removing transitive dependencies where a non-key attribute determines another. At each step, name the specific dependency you eliminated — that sentence is what earns the mark, not the resulting table.
A short paragraph noting that a reporting-heavy workload might justify controlled denormalisation, and what it would cost in update anomalies, shows judgement beyond the mechanical exercise. Keep it brief and keep your submitted design normalised unless the brief says otherwise.
Assignment Byte's IT specialists can review your ER diagram, schema and normalisation reasoning, and check your SQL before you submit.