DDD5 — Validation: presence check, restricted choice, field length, range
- I can describe the four validation types required at Higher: presence check, restricted choice, field length, range.
- I can choose an appropriate validation type for a given attribute.
- I can extend a data dictionary with a validation column.
- I can explain, in my own words, what each of the four validation types checks for.
- I can state a specific, exemplified validation rule for an attribute (not just name the type).
- I can add a validation column to an existing data dictionary without changing its other columns.
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?Key vocabulary
Validating the data dictionary
What is validation, and why does it matter?
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.
Presence check
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.
Restricted choice
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.
Field length check
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.
Range check
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.
Extending the data dictionary
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.
Worked examples
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.
- Naming the validation type without exemplifying it. "Range check" alone is incomplete — state the actual minimum and maximum, e.g. "Range check, 1–30".
- Using restricted choice for anything with a lot of possible values. Restricted choice needs a genuinely fixed, short list — a surname has far too many valid values to be restricted choice; a data type like Boolean or a day of the week does not.
- Confusing field length with range. Field length counts characters in a text field; range checks a numeric value against a minimum and maximum — they apply to different data types and are never interchangeable.
Exam strategy: first recall the four Higher validation types — presence check, restricted choice, field length, and range — then choose from those four and state the actual rule: the specific list, maximum length, or numeric range. A correct type name with no specific value attached typically only earns partial credit.
field length and range without adding the word check.className a field size of 25 characters. Which validation rule is directly implied by that stated maximum?capacity using the established limits 1 to 30. Use lowercase; write the type, then a comma and one space, then the limits joined by a hyphen with no spaces.dayOfWeek than for surname?feePerSession must be from 0 to 50 inclusive. Which complete validation rule should be added to the data dictionary?qualified. Use lowercase, write the type followed by a colon and one space, then list true before false, separated by a comma and one space.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.