Learning Objectives
- Explain the purpose and limitation of validation.
- Select suitable validation checks for database fields.
- Apply range, type, length, presence, format and lookup checks.
- Distinguish valid data from factually correct data.
Key Terms
- Validation
- An automatic check that entered data satisfies predefined rules.
- Range check
- Tests that a value lies within allowed limits.
- Type check
- Tests that data is of the expected type.
- Length check
- Tests the number of characters.
- Presence check
- Tests that a required value has been entered.
- Format check
- Tests that data follows a required pattern.
- Lookup check
- Tests that a value appears in a permitted list.
Purpose Of Validation
Validation checks whether entered data is reasonable and follows the rules defined for a field. It is performed automatically when data is entered or imported.
A valid value is accepted; an invalid value is rejected and the user is normally asked to correct it. Validation reduces unsuitable data and helps maintain consistency across records.
Validation does not prove that data is true. The value 75 may pass a mark range check from 0 to 100 even if the student actually scored 57. The entered value is reasonable in form but factually wrong.
Range Checks
A range check tests lower and upper limits. A mark might be required to satisfy Mark >= 0 AND Mark <= 100. An age might have a minimum and maximum suitable for the scenario.
Limits may be inclusive or exclusive. State the exact rule. Price > 0 rejects zero, while Price >= 0 allows zero.
A range check is normally used with integer, real, date/time or other values that can be compared in an ordered way.
Type Checks
A type check verifies that data matches the field type. A StockQuantity field declared as integer should reject 4.5 and the text four.
Selecting the field data type already supports type validation in many database systems. In an examination answer, name the expected type and explain what incorrect input would be rejected.
A type check cannot test whether an integer lies in an acceptable range; combine checks when both conditions matter.
Length And Presence Checks
A length check tests the number of characters. A membership code may require exactly eight characters, while a username may allow between four and twelve.
A presence check rejects a blank value where data is required. It is suitable for fields such as ProductID or StudentName when every record must contain a value.
Presence does not test the quality of the value. A single question mark may be present but still fail a separate format or lookup check.
Format Checks
A format check tests a pattern. For example, a code may require one letter followed by four digits. The check focuses on positions and character categories.
A date/time field may use a format rule provided by the system. A telephone field may require a country code and a stated number of digits.
State only a pattern supported by the scenario. Do not invent an unnecessarily restrictive rule that would reject legitimate values.
Lookup Or List Checks
A lookup check compares input with a set of permitted values. A category character may be limited to A, B, C or D. A status field may allow Pending, Approved or Rejected.
For a Boolean field, the permitted values are already limited to TRUE and FALSE. For text or character fields, a lookup list prevents spelling variation and unsupported categories.
The rule should include every valid choice described by the requirement.
Choosing Validation By Field
| Field | Possible Validation | Why |
|---|---|---|
| ExamMark | Range 0 to 100 and integer type | Marks outside the range or fractional marks are invalid |
| StudentID | Presence, length and format | Every record needs a correctly structured identifier |
| Category | Lookup list A, B, C or D | Only known categories are accepted |
| Price | Real type and range >= 0 | Must be numeric and not negative |
| EmailAddress | Presence and suitable format rule if specified | Required text should follow the expected structure |
Validation And Error Messages
A useful validation process tells the user what is wrong, for example Enter a whole number from 0 to 100. A vague message such as Error does not help correction.
The syllabus requires understanding validation as part of defining a database. Detailed interface design is not required, but clear rules and reasons are expected.
Worked Examples
Valid But Incorrect
Question: A student mark is entered as 64, which passes the range 0 to 100. The actual mark was 46. Has validation succeeded?
- 64 is a numeric value inside the permitted range.
- The range check therefore accepts it.
- Validation cannot compare the entry with the original source unless another checking method is used.
Answer: Yes, the value is valid, but it is factually incorrect.
Validation For A Code
Question: A code must contain exactly six characters and cannot be blank. Name suitable checks.
- Use a presence check to reject blank input.
- Use a length check requiring exactly six characters.
- Add a format check only if the required character pattern is stated.
Answer: Presence check and length check of six characters.
Examination Guidance
- State the rule as well as the check name.
- Explain that validation checks reasonableness, not factual accuracy.
- Use inclusive limits correctly.
- Combine checks when one rule is insufficient.
- Do not confuse validation with verification.
Common Mistakes
- Claiming validation guarantees correct data.
- Naming a check without stating its allowed values.
- Using a range check for a field with unordered categories.
- Forgetting that zero may be a valid boundary.
- Inventing a format that excludes values permitted by the scenario.
Knowledge Check
1. What does validation test?
2. Does validation prove data is true?
3. Which check tests 0 to 100?
4. Which check rejects an empty required field?
5. Which check limits input to A, B or C?
6. Which check tests one letter followed by four digits?
