Data Integrity

Data integrity means the data is accurate, complete and consistent. Errors creep in when data is entered by a human or transferred between systems, so we use two complementary kinds of check.

	Validation	Verification
Question it answers	Is the data reasonable / sensible?	Has the data changed / does it match the source?
Who does it	The computer, against defined rules	The computer or a person, by comparing copies
When	Mainly on entry	On entry AND on transfer

Crucial limitation (examiners test this): neither check proves the data is correct.

• Validation only proves the value is acceptable — a date of birth of 03/03/2010 is valid even if the real date was 03/03/2011.
• Verification only proves the value was entered/copied without change — typing the same wrong number twice still passes double entry.

So validation and verification reduce errors; they cannot guarantee truth.

Validation rules are built into the program. You must be able to name, describe and apply each of these:

Check	What it tests	Example rule
Range check	value lies between an upper AND lower boundary	1 ≤ month ≤ 12
Limit check	value against one boundary only	quantity ≥ 0
Format (picture) check	data matches a required pattern	date as DD/MM/YYYY
Length check	the number of characters	phone number = 11 digits
Presence check	a field is not left blank	email must be entered
Existence check	the data actually exists	product code matches a record on file
Check digit	an extra digit recomputed from the others (see §5)	last digit of a barcode/ISBN

Range vs limit is a favourite discriminator: a range check has two boundaries; a limit check has one. A format check is about the pattern of characters; a length check is about how many characters.

A field can need several checks at once — e.g. an age might use a presence check (not blank) AND a range check (0–120).

When a human types data in, verification confirms it was copied faithfully from the source.

Visual check — after typing, a person compares the data on screen with the original source document and corrects any differences. It is manual, so it depends on human attention and can miss errors over many records.

Double entry — the same data is entered twice and the computer compares the two copies. If they match, the data is accepted; if they differ, the user is asked to re-enter. This is how new passwords and important reference numbers are commonly verified.

	Visual check	Double entry
Comparison done by	a person	the computer
Reliability	depends on human attention	consistent, always flags a mismatch
Weakness	easy to overlook an error	fails if the same mistake is made twice

Both verify that the entry matches — neither proves the original source value was right.

When data is transmitted, individual bits can flip due to interference. A parity check detects this.

Parity bit (single / 1D). Before sending, an extra parity bit is added to each byte so that the total number of 1s follows an agreed scheme — even parity (an even number of 1s) or odd parity (an odd number). The receiver re-counts the 1s; if the parity no longer matches, at least one bit changed in transfer.

For the 7 data bits 0110101 with even parity, there are four 1s (already even), so the parity bit is 0, and the byte sent is 00110101:

Weakness: a single parity bit only catches an odd number of flipped bits. If two bits flip, parity is restored and the error slips through — and it can never say which bit is wrong.

Block (2D) parity. Send several bytes as rows, apply parity to each row, and add a final parity byte for the columns. If one bit flips, exactly one row and one column fail their parity. Their intersection is the corrupted bit, which is then flipped back:

So a single parity bit only detects an error; block (2D) parity also locates it.

Checksum. Before sending a block of data, the sender runs an agreed calculation over all the bytes to produce a single checksum value, which is sent alongside the data. The receiver performs the same calculation on the data it received and compares the two values:

• match → data accepted as transferred correctly;
• mismatch → data was corrupted, so it is re-requested.

A checksum therefore protects a whole block during transfer and, like parity, only detects errors (it does not correct them).

Check digit. This is a validation/verification of a short code (barcodes, ISBNs, account numbers). An extra digit is calculated from the other digits using a fixed algorithm and appended. When the code is read or typed, the system recomputes the check digit from the body digits and compares it with the supplied one — a mismatch means an error.

Hand-worked example (no calculator): using weights 1, 2, 3, 4, 5 from the left on the code 4 1 3 2 0:

$(4\times1)+(1\times2)+(3\times3)+(2\times4)+(0\times5) = 4+2+9+8+0 = 23$

then $23 \bmod 11 = 1$, so the check digit is 1 and the full code is 413201.

A check digit is especially good at catching transposition errors (two digits swapped, e.g. 41 ↔ 14), which a length or format check would miss because the code still has the right length and pattern.

Checksum vs check digit (don't mix them up):

	Check digit	Checksum
Applied to	a short code (barcode, ISBN)	a whole block of data
Mainly guards against	data-entry errors (mistype, transposition)	transfer/transmission errors
Size	a single digit	a value summarising many bytes