James Gillespie's High School · Higher Computing Science 2026–27
Completed:
📁 File in OneNote: Higher Computing Science → Database Design & Development → DDD2
Answer before the lesson begins — it's fine if you're unsure.
An entity is a person, place, thing, event, or concept that a database needs to hold data about. In the Craigmillar Community Sports Club scenario from DDD1, the entities are Member, Class, Instructor, and Booking — one entity for each distinct "thing" the club's stakeholders talked about. On an ER diagram, an entity is drawn as a labelled rectangle. The Higher course requires every ER diagram to have three or more entities, which the sports club scenario comfortably satisfies with four.
An attribute is a single piece of information stored about an entity — the same idea as a field from National 5, just applied at the design stage before any table exists. Each entity needs enough attributes to satisfy the functional requirements identified in DDD1. For example, the requirement "the database must have a query to calculate the average fee per session" tells us Class needs a feePerSession attribute; the requirement "sort members by the date they joined" tells us Member needs a dateJoined attribute. Attributes are traced directly back to requirements, not invented arbitrarily.
Every entity needs a primary key — a single attribute that uniquely identifies each record. Each attribute is drawn in its own oval connected to the entity rectangle by a plain line. Member's primary key is memberID; Class's is classCode. The primary-key text is underlined inside its oval. When one entity needs to refer to a record in another entity, it stores that entity's primary key as a foreign key, marked with an asterisk in the attribute oval. Booking therefore has memberID * and classCode * as foreign keys. DDD4 covers data dictionaries and compound keys in full detail — this lesson only needs enough of the key concept to draw sensible attribute ovals and relationship lines.
A relationship is the named line joining two entities on an ER diagram. The name should be a short verb phrase describing what one entity does to, or with, the other — "teaches", "makes", "generates" — not a noun. A relationship name should make sense read in one direction: "Instructor teaches Class" reads naturally; "Instructor Class" does not. Three relationships link the sports club's four entities: Instructor teaches Class, Class generates Booking, and Member makes Booking.
The line joining two entities carries a symbol at each end to show cardinality — how many records on one side can relate to how many on the other. SQA's house style uses crow's-foot notation: a fork (three short diverging lines) at the "many" end of a relationship, and a plain line at the "one" end. In the diagram below, the fork sits at Class's end of the "teaches" line, because one instructor teaches many classes, but each class has only one instructor. This lesson focuses on reading and drawing that notation correctly once you're told which side is "many" — working out which side is many, and why, for a relationship you haven't seen before is the focus of DDD3.
capacity) and Booking (the records being counted against it).capacity attribute, and confirms that Booking must link back to Class — which is exactly what the classCode foreign key does.instructorRef, firstName, surname, and qualified — and connect every oval to the Instructor rectangle with one plain line.instructorRef inside its oval because it uniquely identifies each instructor. None of Instructor's attributes are foreign keys, so none of its ovals needs an asterisk.instructorRef underlined.The single diagram below brings the whole design together. Each entity is a named rectangle; every attribute has its own connected oval. Primary-key text is underlined, foreign-key text has an asterisk, and the three entity-to-entity relationship lines use crow's-foot notation. Scroll horizontally to inspect the complete diagram if it is wider than your screen.
From here on, build your ER diagrams in draw.io rather than describing them in words. Use a plain rectangle for each entity, build every attribute oval as a separate shape, join each oval to its entity with a plain line, underline primary-key text, and add an asterisk to foreign-key text. Use labelled crow's-foot connectors only between entity rectangles. See the draw.io ER Diagram Guide for the exact steps, including which connector ends to use and which to avoid.
Open draw.io and build the Booking entity as a plain labelled rectangle. Add a separate connected oval for each of its five attributes, underline the primary key, and mark both foreign keys with an asterisk. The ovals can be arranged clearly around the rectangle in any sensible positions.
Compare your draw.io diagram against this: bookingRef is underlined in its oval (primary key), memberID * and classCode * are the foreign-key ovals, and bookingDate and attended are plain attribute ovals.
memberID) as a foreign key, not the member's full details again.When a question says "exemplify" an ER diagram, it wants an actual labelled diagram — entity rectangles, separate connected attribute ovals, primary-key text underlined, foreign-key text marked with *, and named relationship lines with crow's-foot notation — not a written description of what the diagram would contain. A correct written description without the diagram itself will not gain full marks.
memberID foreign key and a classCode foreign key?This is the same complete ER diagram shown in the notes — scroll up to compare its entity rectangles, connected attribute ovals, key markings, and relationship lines with your draw.io build.
📁 File this in OneNote under:
Higher Computing Science → Database Design & Development → DDD2
Suggested timing: 8 min warm up · 15 min notes & entity/attribute notation · 12 min worked examples & ER diagram walkthrough · 10 min draw.io onboarding (first use in DDD — walk through DrawioGuide.html's setup, entity rectangles, attribute ovals, and connector shapes together before pupils touch it independently) · 10 min now you try · 22 min Task Set B (B10 added, 19 Jul 2026 unit audit — the culminating full-diagram build; the two extra minutes and the draw.io onboarding both draw on this lesson's documented slack) · 5–10 min Task Set C / review, if time allows. Creating separate ovals and connectors takes longer than typing attributes into one shape, so use the documented double-period slack and model the workflow efficiently. This lesson has documented slack (double period, single-period content per DDD.md §11/§6), which is exactly what absorbs B10 without displacing anything else.
Key misconception: pupils very commonly draw Member as an attribute oval connected to Booking rather than recognising Booking stores only the member's key, memberID *. Worth addressing directly using the C3 extension question or a live example.
Live demo suggestion: project the entity-relationship SVG diagram and physically trace each line while asking "which end is many, and why?" before pupils attempt B7 — this rehearses reading crow's-foot notation live, ahead of DDD3's deeper cardinality-reasoning content.
SQA command words covered: "exemplify" (produce an actual labelled diagram, not a written description — see the exam tip box), "describe".
Extension suggestion: pupils who finish Task Set C early could sketch a rough ER diagram (in words) for a completely different scenario of their choosing, using the same four-part checklist (entities, attributes, primary/foreign keys, named relationships) taught in this lesson.
Deliberate scope limit: this lesson does not ask pupils to derive cardinality from a scenario — all three relationships are given as established facts from DDD1's requirements. Reasoning about why a relationship is one-to-one, one-to-many, or many-to-many (and entity-occurrence diagrams as the tool for showing that reasoning) is DDD3's job, not this lesson's.