Revise Databases for Computer Science 0478 (O Level) — revision notes and instant AI marking. Free to start.
📖 Revision notes · preview
Cambridge (CIE) IGCSE · Computer Science
Databases
Big idea: A database is just an organised, secure way of storing information in tables —
made of rows (records) and columns (fields) — where a primary key
guarantees every record can be found uniquely, and validation rules stop bad data getting in.
A database is an organised collection of data, made of one or more tables, stored on secondary storage.
Databases beat plain text files once your data gets large — they're faster to search, more secure, and multiple people can use them at once.
A field = one column = one piece of information. A record = one row = all the info about one item/person.
Validation rules (length, format, range, presence, type, check digit) control what data is allowed into a field — they stop nonsense being entered, but don't check if it's actually true.
Every field has a data type (integer, real, text, character, date/time, Boolean) that matches the kind of data it stores.
A primary key is a unique field used to identify each record — no two records can ever share one.
1. Single Table Databases
What actually is a database?
Think of a database as a giant, super-organised filing cabinet. Instead of loose paper stuffed into folders,
everything is arranged into neat tables — and each table is arranged into rows and columns, a bit like a
spreadsheet. This structure is what makes a database so powerful: because the computer knows exactly where every piece
of data lives, it can find, sort, and update information almost instantly, even if there are millions of entries.
A database is made up of one or more tables, and each table is built from fields (the columns)
and records (the rows). Databases are stored on secondary storage (like a hard drive or SSD)
because they're usually too big — and too important to lose — to just live in RAM. Many databases also live on
remote servers, so lots of different people (think: hundreds of customers on an online shop) can access
and use the same data at the same time.
Why use a database instead of a text file?
Because a database is secure, efficient to search/sort (it can use smart structures
like indexes), and it can handle large amounts of data reliably — whereas a text file gets messy,
slow, and insecure once the data grows.
Databases vs. Text Files — what's the real difference?
This is a classic exam comparison, so let's nail it properly. A text file is fine for small amounts
of data — it's just a plain list where each entry sits on its own line, or entries are separated by something like a
comma. The problem is that a text file has no real structure. The computer doesn't inherently know
where one record ends and another begins — it's just guessing based on line breaks or commas. If your data is messy
(say, someone's address contains a comma), a text file can get confused about where fields start and stop.
A database solves this by giving every piece of data an explicit "home" — a specific field, in a specific table.
That structure is exactly why databases are described as more secure (you can set permissions per
table or field), easier to search and sort (the software knows the structure so it can use efficient
algorithms), and better suited to large-scale, multi-user situations like websites and business systems.
Feature
Text File
Database
Best for
Small amounts of data
Large amounts of data
Structure
Loose — lines/commas only
Strict — tables, fields, records
Multi-user access
Difficult
Designed for it
Security
Low
High
Searching/sorting
Slow, basic
Fast, uses advanced structures
Practice Question
Explain two reasons why a business handling thousands of customer orders per day would use a database rather than a text file. [4]
2. Fields & Records
This is the single most-tested definition pair in this topic, so let's make it stick permanently.
Table: Employees
┌───────────┬────────────┬──────────┬─────┐ ← Column headers = FIELD NAMES
│ Name │ Department │ Salary │ Age │
├───────────┼────────────┼──────────┼─────┤
│ Greg │ Sales │ 39000 │ 43 │ ← ONE ROW = ONE RECORD
├───────────┼────────────┼──────────┼─────┤
│ Lucy │ HR │ 26750 │ 28 │ ← another RECORD
├───────────┼────────────┼──────────┼─────┤
│ Jordan │ Payroll │ 45000 │ 31 │ ← another RECORD
└───────────┴────────────┴──────────┴─────┘
↑ Each COLUMN (e.g. "Salary") is a FIELD — one piece of info, repeated down every record
The rule to lock in
Field = one piece of information = a column. Record = a full collection of fields about one thing = a row.
Common mix-up
Students very often swap these around under exam pressure. A quick memory trick: "Field" and
"column" don't share a letter to anchor onto, so instead remember Records go across,
fields go down — or simply picture a spreadsheet: columns are labelled at the top (fields), and
each full row is one entry (record).
Text files, revisited
A text file stores data as plain lines of text on secondary storage, and gets "read" into a program
when it's needed. Text files are used to store information when the application is closed (so the
data isn't lost) — but because there's no strict structure, it can be genuinely hard for a program to know
where one record ends and the next begins, especially if the data itself contains the separator character
(like a comma inside an address).
Practice Question
A table called Books has the fields: BookID, Title, Author, Price. How many fields does this table have, and what would one record from this table represent?
3. Validation
When a table is designed, each field can be given a validation rule. Validation is a gatekeeper —
it checks that data being entered follows a specific set of rules before it's allowed into the field.
It's important to understand that validation only checks whether data is reasonable/sensible in format —
it can never guarantee the data is actually correct or true. For example, a validation
rule could check that an age is between 0 and 120 — but it can't tell if "37" is really the person's actual age.
(That's the job of a different concept called verification, which isn't covered in this chapter.)
Type
What it checks
Example
Length Check
Number of characters entered
A phone number must be exactly 11 characters
Format Check
Data matches an exact pattern
A product code must be 2 letters then 5 numbers
Range Check
Number falls within a set range
A dog's age must be between 0 and 40
Presence Check
Field isn't left blank
A "Surname" field cannot be empty
Type Check
Data matches the expected data type
A date-of-birth field must reject text like "hello"
Check Digit
An extra calculated digit confirms accuracy
Credit card numbers, barcodes, ISBNs
Check digits — the one students find trickiest
A check digit is a single extra digit added to the end of a longer number (like a barcode or credit
card number). It's calculated by running the other digits through a specific algorithm. Later, whenever that number
is typed in again, the computer re-runs the same algorithm on the digits — if the result doesn't match the check
digit, the computer knows an error was made (a mistyped digit, a swapped pair of digits, etc.) and rejects the entry.
It's essentially a built-in "self-checking" mechanism for long important numbers.
Golden rule of validation
Validation checks the data is sensible/in the right format — it does not check the data
is accurate/true. A range check will happily accept "25" as an age even if the real person is 30 —
it just knows 25 is a believable number.
Common mistake
Students often write "validation checks the data is correct" — this loses marks! Always say validation checks data
is reasonable / follows the rules set, not that it's guaranteed to be true.
Practice Question
A field called "ExamScore" should only accept whole numbers from 0 to 100. Name and describe the validation check(s) you would use, and explain why a presence check might also be useful here. [4]
4. Data Types
Every field in a table needs a data type — this is decided when the table is first designed, and it
defines what kind of data that field is allowed to hold. Choosing the right data type isn't just a technicality:
it affects how much storage space is used, what operations can be performed on the data (you can't do maths on text!),
and it acts as a first line of defence against bad data (a type check will use this to reject the wrong kind of input).
Data Type
Stores
Example
Integer
Whole numbers
25, -3, 1000
Real
Decimal numbers
24950.00, 3.14
Text / Alphanumeric
Letters, numbers, symbols as text
"Peugeot", "AB123CD"
Character
A single character
"M", "F", "Y"
Date / Time
Calendar dates and/or times
05/03/1976, 14:30
Boolean
True or false values
True, False / Y, N
Worked example — matching data types to a real table
car_id
make
model
colour
price
1
Peugeot
2008
Red
24950
2
Mazda
MX5
Blue
17995
Here, car_id is an integer (a whole counting number), make,
model, and colour are all text/alphanumeric (they store words),
and price is a real number because it could realistically include decimals
(e.g. 24950.99), even though in this sample it happens to look whole.
Handy tip
A quick giveaway for real vs integer: if the field could ever sensibly need a
decimal point (money, measurements, averages), it's real. If it's a count of whole things
(age, quantity, an ID number), it's integer.
Practice Question
A table stores information about products in a shop: ProductID, ProductName, InStock (whether it's currently available), UnitPrice. State the most suitable data type for each field.
5. Primary Keys
A primary key is a unique field that identifies each record in a table.
"Unique" is the operative word here — no two records in the table are ever allowed to share the same primary
key value. This is exactly how a database avoids confusion: even if two customers happen to have the exact
same name and date of birth, their CustomerID will always be different, so the database can
always tell them apart.
CustomerID
FirstName
LastName
DOB
PhoneNumber
001
Andrea
Bycroft
05031976
0746762883
002
Melissa
Langler
22012001
0756372892
003
Amy
George
22111988
074637
Here, CustomerID is the primary key. Notice that FirstName or LastName
alone would be a bad choice for a primary key — plenty of different customers could share the
same first name, or even the same full name. A good primary key candidate is always a field specifically
designed to be unique, like an ID number.
Typical primary key examples
Student_ID in a school database · Car_Registration in a car database ·
Product_ID in a shop database
How to pick a primary key in an exam question
Ask yourself: "Could two records in this table ever have the same value here?" If the answer is yes
(like Name, or DOB, or PhoneNumber where two people might share a landline), it's not a good
primary key. If it's a field specifically designed as an ID number for that record, it almost always is.
Key database terminology — quick reference
Term
Definition
Table
A collection of records with a similar structure
Record
A group of related fields, representing one data entry (a row)
Field
A single piece of data in a record (a column)
Data type
The type of data held in a field
Primary key
A unique identifier for each record in a table, usually an ID number
Practice Question
A database has been developed for a dance club, with one table: Members (fields: MemberID, FirstName, LastName, DateJoined). State the field most suitable to use as the primary key, and explain why. [2]
What to Memorise
Database
An organised collection of data, made of tables of fields and records, for easy storage/retrieval/management.
Field
One piece of information about a person/item/object. Represented by a column.
Record
A collection of fields relating to one person/item/object. Represented by a row.
Table
A collection of records with a similar structure.
Primary Key
A unique field used to identify each record in a table — no duplicates allowed.
Length Check
Validates the number of characters entered (e.g. exactly 11 digits).
Format Check
Validates data matches an exact pattern (e.g. 2 letters + 5 numbers).
Range Check
Validates a number falls between set minimum and maximum values.
Presence Check
Validates that a field has not been left blank.
Type Check
Validates data matches the field's expected data type.
Check Digit
An extra digit calculated from the other digits, used to verify accuracy (e.g. barcodes).
Tick these off honestly as you revise — if you can't confidently tick it, go back and reread that bit.
Exam Tips
Fields vs Records
You will almost certainly be shown a sample table and asked "how many fields/records does this have?" —
a record is a row, a field is a column. Count the column headers for fields; count the data
rows (not including the header row!) for records.
Give the "why", not just the "what"
Mark schemes for validation questions usually award marks in pairs: one mark for naming the
check (e.g. "range check"), and one mark for applying it specifically to the field in the question
(e.g. "to ensure the score is between 0 and 100"). Never just name the check — always explain how it applies
to the exact scenario given.
Don't confuse validation with verification
Validation is an automatic check done by the computer on the data's format/reasonableness. It is not
the same as checking data is factually correct. If a question asks "will this validation check guarantee correct
data?" — the answer is always no.
Picking a primary key
When asked to justify a primary key choice, always explain why the other fields would NOT work
(they could repeat/aren't guaranteed unique) as well as why your chosen field does work
(it's unique to every record). This two-sided justification often earns extra marks.
Data type precision
Examiners distinguish between "integer" and "real" carefully — don't just say "number." If there's ANY chance
a value needs a decimal point (price, weight, average), it should be real, not integer.