Tables, records and fields
A database is an organised store of data that a computer can search and sort.
Data sits in tables. A record is one row: all the data about one thing, such as one member.
A field is one column: one piece of data about every record, such as LastName.
Through this topic we use one example: a sports centre in Madrid. It has a Members table and a Bookings table.
?Why?Splitting data into fields lets the software search one field at a time. You can ask for every Junior member without reading every row yourself.
Import a .csv or .txt file
In the exam you do not type the data. Cambridge gives you a source file, usually .csv (comma separated values) or .txt.
A .csv file is plain text. Each line is one record. Commas separate the fields.
When you import, tell the software that the first row contains field names. Then the headings become field names, not a record.
During the import you can set each field's type and choose the primary key. Check the result against the source file after importing.
BookingID,MemberID,Activity,BookDate,Hours,Rate,Paid
101,M02,Padel,06/10/2026,1.5,12.00,Yes
102,M01,Swimming,06/10/2026,1,4.50,Yes
103,M04,Tennis,07/10/2026,2,11.00,No
!Watch outIf you forget to tick "first row contains field names", the headings become record 1 and every field gets a name like Field1. The examiner cannot see the field names you were asked to use.
Field types and sub-types
A field type (data type) tells the software what kind of data a field holds. It controls how data is stored, checked and sorted.
Cambridge names four main types: text, numeric, date/time and Boolean. Numeric has sub-types: integer, decimal, currency and percentage.
The table shows each type with a field from our sports centre.
!Watch outPhone numbers are text, not numeric. You never add or average them. A numeric field also drops a leading zero or a "+34" and cannot store spaces.
Why the wrong type loses marks
The examiner checks your table design. Each wrong type usually costs a mark.
If Hours is set to integer, the value 1.5 is stored as a whole number. The cost of booking 101 is then wrong too.
If BookDate is text, sorting goes by characters, not by date. "06/11/2026" (6 November) sorts before "10/10/2026" (10 October), because 0 comes before 1.
If Paid is text, someone can type "yes", "Y" or "paid". A Boolean field only allows two values, so searches work every time.
?Why?The type is a promise about the data. Keeping that promise makes searching, sorting and calculating reliable.
!Watch outYour screenshot of the table design must show every field name in full and its type. Widen the column before you take the screenshot.
Display formats
A display format changes how a value looks, not the value stored.
Dates can show as 07/10/2026 or 7 October 2026. Currency shows a symbol and 2 decimal places, such as €4.50.
Decimal fields can show a set number of places: Hours as 1.0, 1.5, 2.0. A Boolean field can show as Yes/No or as a check box.
Read the task carefully. If it says "currency in euros with 2 decimal places", both parts are marked.
e.g.ExampleRate stored: 4.5
Display format: currency, euro, 2 decimal places
Shown on screen: €4.50
Discount stored: 0.3
Display format: percentage, 0 decimal places
Shown on screen: 30%
!Watch outFormatting to 0 decimal places only hides the decimals. The value 1.5 still shows as 2 on screen, which looks wrong. Choose the places the task asks for.
Primary keys and foreign keys
A primary key is a field that holds a different value for every record. It identifies each record exactly. MemberID is the primary key of Members.
BookingID is the primary key of Bookings. Two bookings can share a member, an activity or a date, but never a BookingID.
A foreign key is a field in one table that is the primary key of another table. MemberID in Bookings is a foreign key. It tells you who made each booking.
!Watch outA name is a poor primary key. Two members can both be called Lucía García. Use an ID that the system gives out once.
One-to-many relationships
A relationship links two tables through a shared field. Here the link is MemberID.
It is one-to-many: one member can make many bookings, but each booking belongs to one member.
The "one" side is the primary key (Members.MemberID). The "many" side is the foreign key (Bookings.MemberID).
Many programs let you switch on referential integrity. Then you cannot add a booking for a member who does not exist, such as M09.
e.g.ExampleM01 (Lucía García) → bookings 102 and 108
M02 (Pablo Ruiz) → bookings 101 and 104
M03 (Carmen López) → booking 105
M04 (Diego Martín) → bookings 103 and 107
M05 (Sofía Navarro) → booking 106
There is a diagram for this step in the IGCSE library.
Flat-file and relational databases
A flat-file database has one table. A relational database has two or more linked tables.
In a flat file, Pablo Ruiz's name and phone would be typed again on every booking he makes.
Repeated data wastes space and causes mistakes. If Pablo changes phone, you must find and change every copy.
?Why?Storing each fact once means it can only be wrong in one place. That keeps the data consistent.
Data entry forms
A data entry form shows one record at a time so a person can type data into a table. Good forms reduce typing errors.
Use radio buttons when the user must pick exactly one of a few options: Category is Junior, Adult or Senior.
Use a check box for a Boolean field: Paid is ticked or not.
Use a drop-down menu for a longer fixed list: Activity is Padel, Pilates, Swimming or Tennis.
Good design: a clear title, fields in a sensible order, one font, readable size, labels lined up, and white space between groups.
e.g.ExampleNew booking form (top to bottom)
Title: New Booking
BookingID: [filled in by the system]
MemberID: [drop-down of M01–M05]
Activity: [drop-down]
BookDate: [date box]
Hours: [box]
Paid: [check box]
!Watch outMarks are lost for cramped forms, mixed fonts, labels cut off, or fields in a random order. Follow the order the task gives, and check every label is fully visible.