Field design — name, length, type, coding
Every field gets four design decisions. Field name — an exact label, underscores as given (date_of_birth). Field length — maximum characters allowed; too short truncates real data, too long wastes storage. Data type — text/alphanumeric, numeric, date/time, Boolean or currency; it limits what can legally be entered and which checks are possible. Coding — a short code such as M/F where a field has few possible values, saving storage and speeding entry.
Validation — seven checks, seven jobs
Validation is an automatic test that entered data is reasonable and satisfies a defined rule, designed into the file structure at this stage. Cambridge names seven, each catching a different kind of error: range, length, character, type, format, presence and check digit. The check digit is the outlier — an extra digit recalculated from the other digits on re-entry, catching a transposition the rest let through. One field often needs several checks.
Formats — capture form, screen, report
Input — the data capture form. Fields follow the paper source document order, each box sized to its field length and clearly labelled; a coded field offers a drop-down of pre-set options so it cannot be mistyped. Outputs. A screen layout suits quick interactive use and may carry buttons, scrolling and links; a report has no navigation and needs a title, date, page numbers and a table structure, read on paper as a stand-alone record. Design both for audience and purpose.
Drawn from real examiner reports.
"Digit check" is not "check digit"
Mark schemes credit the exact term check digit; writing "digit check" scores nothing. The same precision applies to every other name — "range check" not "number check", "presence check" not "empty check". Learn the seven as fixed labels rather than describing what the check does and hoping the examiner infers which one you mean.
w22 P13 Q7 / s22 P11 Q14 / s22 P13 Q2 / w23 P13 Q1
Presence check ≠ every field
A presence check only makes sense on a compulsory field — one that can never legitimately be blank, such as surname on a membership record. Applying it to an optional field (a middle-name field many people leave empty) is the wrong check for that scenario. Name whichever check actually fits the field described, not presence check by default.
w23 P11 Q10b
Field names must be copied exactly
Design tables give field names exactly as they must be written, underscores included — date_of_birth, not "date of birth" or "DOB". The design document is a formal specification other people build from, so a paraphrased field name can lose the mark even when the validation check named alongside it is the right one.
w22 P13 Q7 / s22 P11 Q14 / s22 P13 Q2 / w23 P13 Q1
Design stage ≠ analysis stage
Analysis comes first — researching the current system, interviewing users, reading existing documentation (topic 7.1). Design then decides file/data structures, validation checks and input/output layouts. Asked what is designed once analysis is complete, candidates offered analysis activities instead. Give design deliverables only.
w23 P13 Q10b
Validation ≠ correct data
Validation only proves data is reasonable and allowable against a designed rule; verification only proves it was copied correctly from the source. Neither on its own — nor both together — proves the data is actually correct. A record can pass every check on the file and still be factually wrong, because the wrong source was copied in the first place.
w23 P11 Q10 / w23 P12 Q9 / s22 P13 Q13b
Data type without a field length
A file-structure answer needs field name, data type AND field length for every field — giving a data type with no length (or a length with no type) throws away cells the mark scheme awards separately. Watch too for a field with only two or three possible values left as free text when it is an obvious candidate for coding.
Storage = records, not fields
Storage for one field is field length multiplied by the number of records, not by the number of fields designed. At one byte per character a 12-character field across 3000 records needs 12 x 3000 = 36 000 bytes. Field length is a per-character limit, so multiplying it by the field count answers a different question entirely.
Design a file structure? Use a table
Lay the answer out as a table with one row per field and columns for field name, data type and field length. Marks are awarded cell by cell, so a table makes every decision visible and stops you omitting the length for a field you have already named.
Name the check and its rule
Never name a check in isolation. State the check and the rule it enforces on that field — not "range check" but "range check: the value must lie between 0 and 120". The rule is what shows the check has been matched to the particular field the scenario describes.
Explain needs a because
Explain and describe need the reason, not just the outcome. "A check digit catches a swapped pair" is a statement; "because the check digit is recalculated from the other digits, a transposition changes the result" earns the mark. Start the second half of the answer with because.
Compare the design, not the data
For compare and discuss, compare the design considerations — interactivity and navigation against title, date and page numbers — not the data each output happens to show. Make matched points, close a discuss with a judgement, and never split the answer into two columns.
date_of_birth); write exact field names, including underscores.Full notes, flashcards, Q&A and the topic quiz for every premium subject.
Premium plans are US$8.99/month or US$49.99/year — first month free.
Studying with a parent's blessing? Show them this.