James Gillespie's High School · Higher Computing Science 2026–27
Completed:
📁 File in OneNote: Higher Computing Science → Database Design & Development → DDD5
Answer before the lesson begins — it's fine if you're unsure.
qualified (Instructor) a data type. What data type is it?postcode (Member) in DDD4's data dictionary?Validation is an automatic check applied when data is entered into a database, designed to catch data that is clearly wrong before it gets stored. Validation cannot guarantee data is correct — a presence check on firstName would happily accept "Xyzzy" as a first name — but it can catch data that is clearly invalid, like a blank required field or a day of the week that doesn't exist. The Higher course names exactly four validation types, and no others: presence check, restricted choice, field length, and range.
A presence check confirms that a required field has not been left blank. It's the simplest validation type, and it's applied to any attribute the database genuinely cannot function without — most obviously, primary keys. Member's memberID needs a presence check, because a booking system cannot process a member record with no ID.
A restricted choice check confirms that an entered value matches one item from a fixed, pre-defined list of allowed values — anything not on the list is rejected. Class's dayOfWeek is a natural fit: the only valid values are Monday through Sunday, so a restricted choice check against that exact list of seven values catches typos like "Mundy" immediately. Boolean attributes like qualified and attended are also, in effect, restricted choice checks with only two allowed values: True and False.
A field length check confirms that the number of characters entered does not exceed the field size set in the data dictionary. If postcode has a field size of 8, a field length check rejects any entry longer than 8 characters — protecting against data that would otherwise be silently truncated or cause a storage error.
A range check confirms that a numeric value falls between a stated minimum and maximum. Class's capacity is a strong example: a class can't sensibly have a capacity of 0 or a capacity of 500 in a small sports hall, so a range check of, say, 1 to 30 catches obviously wrong entries — a capacity of -5 or 999 — that would otherwise be accepted as valid numbers.
Adding validation to a data dictionary means adding one more column — Validation — to the structure already built in DDD4 (entity, attribute, PK/FK, data type, field size). Every attribute's validation entry should be specific and exemplified, not just the type name: "Range check, 1–30" is a complete answer; "range check" alone is not, because it doesn't state which range.
memberID (Member's primary key).memberID must not be left blank.dayOfWeek (Class).dayOfWeek must be one of: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday.postcode (Member), field size 8. Ask: is there a fixed maximum length? Yes — the field size itself sets it.postcode must not exceed 8 characters.capacity (Class). Ask: is there a sensible numeric minimum and maximum? Yes — a realistic class size.capacity must be between 1 and 30.| Entity | Attribute | PK/FK | Data type | Field size | Validation |
|---|---|---|---|---|---|
| Member | memberID | PK | Text | 6 | Presence check |
| Member | postcode | — | Text | 8 | Field length check, max 8 characters |
| Class | dayOfWeek | — | Text | 10 | Restricted choice: Monday–Sunday |
| Class | capacity | — | Number | n/a | Range check, 1–30 |
| Class | feePerSession | — | Number | n/a | Range check, 0–50 |
| Instructor | qualified | — | Boolean | n/a | Restricted choice: True, False |
Booking's bookingRef is a text primary key (field size 8), and attended is a Boolean. State an appropriate, specific validation rule for each.
bookingRef — Presence check (it's the primary key, so it must not be left blank) — you could also add a field length check of max 8 characters, since both are genuinely applicable here.attended — Restricted choice: must be True or False.When asked to "exemplify" validation, always state the actual rule — the specific list, the specific maximum length, or the specific numeric range — rather than only naming which of the four types applies. A correct type name with no specific value attached typically only earns partial credit.
className (e.g. "Pilates", "Yoga")?capacity (using the range 1–30 established in the worked examples).dayOfWeek than for surname?qualified.bookingDate, not just a number like capacity? Explain how this would work differently.📁 File this in OneNote under:
Higher Computing Science → Database Design & Development → DDD5
Suggested timing: 8 min warm up · 15 min notes (four validation types) · 15 min worked examples · 5 min now you try · 20 min Task Set B · 5–10 min Task Set C / review, if time allows.
Key misconception: pupils often name a validation type without stating the specific rule (e.g. writing "range check" instead of "range check, 1–30"). Model the exemplified form every time in class, and dock marks consistently for un-exemplified answers in feedback, matching how SQA's own marking instructions expect specifics.
Spec-accuracy note: do not introduce format check or check digit as a fifth/sixth validation type, even informally — these are National 5 techniques and are confirmed absent from the Higher DDD content statement (see ddd/DDD.md §1).
SQA command words covered: "exemplify" (state the actual rule, not just the type name — see the exam tip box), "describe".
Extension suggestion: pupils who finish Task Set C early could complete a full validation column for every attribute across all four entities, cross-checking against DDD4's complete data dictionary.