Examhaus — Achieve with confidence.

IB Computer Science A3.2: Database design

New IB Computer Science syllabus · first exams May 2027 · Theme A · SL & HL

A3.2 is about designing a database properly: from high-level schemas and ER diagrams, through tables and keys, to normalizing a design to third normal form. It's one of the most heavily construct-based sub-units, so expect to draw and build, not just describe.

StatementTopicCommand term
A3.2.1Database schemasDescribe
A3.2.2ERDsConstruct
A3.2.3Data typesOutline
A3.2.4Tables for relational databasesConstruct
A3.2.5Normal formsExplain
A3.2.6A database normalized to 3NFConstruct
A3.2.7The need for denormalizingEvaluate

Key points

A3.2.1 Schemas

  • Conceptual schema: a high-level, technology-independent view of what is stored and how entities relate (an ERD).
  • Logical schema: the tables, columns, data types, keys and relationships.
  • Physical schema: how the data is actually stored, such as files, indexes and partitioning. It is specific to the database system.

A3.2.2 ERDs

  • Entities are drawn as rectangles, attributes as ovals with the primary key underlined, and relationships as diamonds.
  • Cardinality shows how many: one or many.
  • Modality shows whether the relationship is optional (0) or required (1).

A3.2.3 Data types

Common types are INT, DECIMAL, CHAR, VARCHAR, DATE, BOOLEAN and BLOB. Consistency matters: the wrong type causes errors, wasted storage and bad sorting. For example, storing dates as text sorts them incorrectly.

A3.2.4 Tables

Build tables with primary, foreign, composite and concatenated keys, plus constraints (NOT NULL, UNIQUE, CHECK, DEFAULT) to protect data integrity.

A3.2.5 Normal forms ("the key, the whole key, and nothing but the key")

  • 1NF: atomic values (one value per cell) and a unique identifier for every row.
  • 2NF: in 1NF, with no partial-key dependencies. No non-key attribute depends on only part of a composite key.
  • 3NF: in 2NF, with no transitive dependencies. No non-key attribute depends on another non-key attribute.

A3.2.6 Normalizing to 3NF

Practise on the guide's scenarios: a library, hospital, e-commerce platform, school, employee records, inventory, or police crime reporting. Find each dependency and split it into its own table.

A3.2.7 Denormalization (Evaluate)

This means deliberately re-introducing some redundancy to speed up reads, which helps in read-heavy systems such as reporting. The cost is more redundancy and a risk of update anomalies. Weigh simpler, faster queries against the risk of inconsistent data.

Exam-style question

Explain the difference between second normal form (2NF) and third normal form (3NF). [4]

Mark scheme

Award [2] per normal form:

  • 2NF [2]: a table is in 2NF if it is in 1NF and has no partial-key dependencies [1]. A partial dependency is when a non-key attribute depends on only part of a composite primary key; fix it by moving that attribute to a separate table [1].
  • 3NF [2]: a table is in 3NF if it is in 2NF and has no transitive (non-key) dependencies [1]. A transitive dependency is when a non-key attribute depends on another non-key attribute rather than on the key; fix it by moving those attributes to their own table [1].

Common mistakes that cost marks

  • Writing "it removes redundancy" for every normal form. Name the specific dependency each form removes.
  • Missing cardinality or modality on an ERD, or forgetting to underline primary keys.
  • Treating denormalization as simply "bad design". "Evaluate" needs both its benefits and its risks.

Frequently asked questions

How far do I need to normalize?
To third normal form (3NF), for a range of real-world scenarios.

What's the difference between cardinality and modality?
Cardinality is how many (one or many). Modality is whether the relationship is optional (0) or required (1).

Go further