Data validation and integrity for QCE Digital Solutions Unit 3
“Design and implement data validation that checks input for type, range, presence and format so that only valid data enters the solution, protecting data integrity”
Validation is the automatic checking of input against rules (type, range, presence, format and lookup) before data is stored, so that invalid data is rejected at the point of entry; it protects data integrity, which is the accuracy, completeness and consistency of the data a solution holds.
Jump to a section
What this dot point is asking
QCAA wants you to make sure only correct, usable data enters your solution. Validation is the automatic checking of input before it is stored or processed, and it is what protects data integrity (the accuracy, completeness and consistency of stored data). A solution that stores a mark of 250 out of 100, or an empty email field, has a data-integrity failure that every later report and query inherits. Validation is assessed in IA2 implementation and tested in your test plan.
Validation versus verification
These are different ideas and markers reward the distinction.
- Validation checks that data is reasonable against rules: is it the right type, in range, present and correctly formatted? It cannot prove the value is true, only that it is plausible.
- Verification checks that data was entered correctly, for example a double-entry password field or a confirmation prompt.
A birth year of 1850 passes verification if it was typed accurately, but fails validation because it is out of a sensible range.
The standard validation checks
QCAA expects you to know and apply these checks:
- Type check: the value is the expected data type (a number where a number is required).
- Range check: a numeric value falls between a minimum and maximum (a mark from 0 to 100).
- Presence (existence) check: a required field is not empty.
- Length check: a string is within an allowed number of characters (a 4-digit PIN).
- Format (pattern) check: the value matches a pattern, often a regular expression (an email, a postcode).
- Lookup check: the value exists in a known set (a subject code that is in the subjects table).
def validate_mark(raw):
if raw.strip() == "": # presence check
return False, "Mark is required"
if not raw.isdigit(): # type check
return False, "Mark must be a whole number"
mark = int(raw)
if mark < 0 or mark > 100: # range check
return False, "Mark must be 0 to 100"
return True, mark
ok, result = validate_mark("250")
print(ok, result) # False Mark must be 0 to 100
The function applies presence, type and range checks in order and returns a clear message, so the interface can tell the user exactly what to fix. Returning the converted integer on success means the caller never re-parses the input.
Where validation sits
Validation belongs between the user interface and the database. The interface collects raw text; the program validates it; only valid, typed data reaches the database. Putting validation only in the interface is fragile because data can arrive from imports or APIs too, so the safest designs validate in the program layer and also use database constraints (NOT NULL, CHECK, foreign keys) as a second line of defence. This layering is what keeps integrity intact even when one path is bypassed.
Validation and the user experience
Good validation is also a usability feature. Inline messages that name the field and the rule, sensible defaults, and input masks that prevent bad data being typed at all reduce user frustration. This connects validation to the user-centred interface design dot point: the goal is not just rejecting bad data but guiding the user to enter good data the first time.
Integrity beyond input
Data integrity is broader than input validation. It also depends on referential integrity in the database (foreign keys that prevent orphaned rows), transactions that keep related updates consistent, and constraints that stop duplicate keys. Input validation is the front line, but a strong solution defends integrity at every layer where data is written.
- Validating only in the interface. Imports and API data skip the form, so validate in the program and enforce database constraints too.
- Confusing validation with verification. Validation checks plausibility against rules; verification checks the data was entered correctly.
- Range check without a type check. Comparing text to a number errors or silently misbehaves; check the type first, then convert, then range-check.
- Accepting empty strings as present. A field of spaces is not really present; strip whitespace before the presence check.
- No feedback. Rejecting input without saying which rule failed makes the solution feel broken; always return a specific message.
Exam-style questions
Questions in the style of QCAA exam questions on this dot point, each with a worked answer. They are written by ExamExplained unless tagged "Past paper"; the year shows the paper a question is modelled on.
Practice7 marksA booking form captures an age that must be an integer between 1 and 120. Use pseudocode to symbolise validation that re-prompts until the input is valid, and explain which validation checks your code applies.Show worked answer →
A 7 mark symbolise-and-explain answer rewards a correct validation loop and naming the checks.
Symbolise a presence, type and range check with re-prompting:
REPEAT
INPUT age
SET valid TO TRUE
IF age IS EMPTY OR age IS NOT a whole number THEN
SET valid TO FALSE
ELSE IF age < 1 OR age > 120 THEN
SET valid TO FALSE
END IF
IF valid = FALSE THEN OUTPUT "Enter a whole number from 1 to 120"
UNTIL valid = TRUE
Explain: this applies a presence check (not empty), a type check (whole number) and a range check (1 to 120). Markers reward a loop that keeps prompting until valid and correctly naming the checks applied.
Practice4 marksAnalyse the difference between validation and verification, and explain why validation alone cannot guarantee data integrity.Show worked answer →
A 4 mark analyse answer needs both terms and the limit of validation.
Validation checks that input is reasonable and well formed (type, range, presence, format) before it enters the system. Verification checks that the data entered matches the intended (real) value, for example double entry or a confirmation step.
Validation alone cannot guarantee integrity because a value can be perfectly valid yet wrong: a correctly formatted but mistyped date passes every validation check. Markers reward the validation-versus-verification distinction and the point that valid does not mean correct.