Cambridge O Level Computer Science · Syllabus 2210 · Databases
Table
What is Table?
A structure that holds data organised into rows and columns; each column is a field holding one category of data and each data row is a record holding all the field values for one item.
This definition is part of the Databases chapter in Cambridge O Level Computer Science.
Table in context
A database is an organised collection of data that can be stored, searched and processed. Topic 9 works entirely with a database made of one table: data arranged in rows and columns, where a field is a column holding one category of data and a record is a row holding all the field values for one item. Every field is given a data type (text/alphanumeric, character, Boolean, integer, real or date/time) and, where a rule can be stated, one or more validation checks. One field is chosen as the primary key because its value is different in every record. SQL is then used to ask questions of that table — and the answer to “what does this query output?” is found by working through the clauses in a fixed order, never in the order they are written.
A database is an organised collection of data that can be stored, searched and processed. The data is held in one or more tables, and a table is data organised into rows and columns. In Cambridge 2210 Topic 9 every database you meet contains exactly one table, so “the database” and “the table” usually refer to the same thing — but they are not the same idea, and the definition of each is worth knowing separately.
A design question gives you a paragraph describing what must be stored and asks you to define a table. The paragraph is not decoration — it is a checklist. Each separate item of data that the requirement says must be stored becomes exactly one field. You then give each field a meaningful name and a suitable data type, attach validation wherever the requirement states a rule, and choose a primary key. A field belongs in your design because a stated requirement puts it there, never because it would look realistic.
A primary key is a field whose value uniquely identifies each record in the table. Its purpose is to make every record findable and distinguishable: given one primary-key value, the database can return exactly one record, and no two records can ever be confused with one another. To be suitable, a field must have a different value in every record, must never be left empty, and should stay stable over time. That is the whole test — and it is a test about uniqueness, not about importance.
Every SQL example, activity and answer from here to the end of the chapter is worked against the single table below. It never changes: the same ten records, the same eight fields, the same values, from the first SELECT to the final mastery question. Keep this page in view while you work — every result printed later can be checked against it by hand, and you should check some of them.
Structured Query Language (SQL) is the language used to ask questions of a database. A Topic 9 query is built from at most four clauses, always written in the order SELECT, FROM, WHERE, ORDER BY, and finished with a semicolon. That written order is not the order the query is worked out in. The table is fetched first, the records are filtered next, the chosen fields are taken after that, any total or count is calculated, and the sort happens last. Getting those two orders straight is the single most useful thing in this half of the chapter.
SELECT chooses which fields appear in the output, and the fields appear in the order you write them. FROM names which table the data comes from. Together they are the minimum a query needs. On their own they do not filter anything: a query with no WHERE clause returns every record in the table — just fewer columns of each.
Topic 9 asks five kinds of question over and over: count something, choose a data type, choose a validation check, choose a primary key, and complete or interpret a query. Each has a shape. Learn the shape and you will never face a Topic 9 question with nothing to write — you fill the frame with the table in front of you.
Structure, data types, validation, primary keys, SQL completion and output interpretation, mixed together the way an examination mixes them. Every question refers to the BOOKING table earlier on this page — scroll back to it whenever you need to; that is exactly what you would do with a printed table in the exam. Answers are marked in this page only: nothing is stored and nothing is sent anywhere.
Common mistakes with Table
- M1 — “A database always contains just one table.” Why it is wrongReal databases routinely contain many tables that reference one another. The single table is a restriction of this syllabus, not a fact about databases. Correct“A database is an organised collection of data held in one or more tables. Cambridge 2210 Topic 9 works only with a database containing a single table.”
- M4 — “There are 11 records, because I counted 11 rows.” Why it is wrongThe heading row was counted. It holds field names, not field values, and there is no item in the database called “BookingRef”. Correct“The number of records is the number of data rows. The BOOKING table has 10.”
- M19 — “Without ORDER BY, the records come out in table order.” Why it is wrongSQL guarantees no order unless you ask for one. Writing them in printed-table order in an exam is sensible; claiming the database must do so is not true. Correct“If a particular order is required, an ORDER BY clause has to say so.”
- M22 — “SUM tells you how many records there are.” Why it is wrongSUM adds the values in a numeric field. Over the whole BOOKING table SUM(Places) is 165, while the number of records is 10. Correct“SUM adds values. COUNT counts records.”
- M24 — “Topic 9 SQL includes adding, changing and deleting records.” Why it is wrongThe syllabus limits SQL here to nine keywords, all of which read data. INSERT, UPDATE, DELETE and CREATE TABLE are not in the list. Correct“Topic 9 SQL queries a table. It does not modify it.”
- M25 — “I should write ASC and DESC, and I need joins for a proper answer.” Why it is wrongThe syllabus lists the sorting keywords written out in full, and there is only ever one table, so a join has nothing to join. Normalisation, foreign keys and entity-relationship diagrams are outside the topic as well. Correct“Write ASCENDING and DESCENDING, and answer every Topic 9 question from the single table given.”
Examiner tips on Table
- How to count without slipping. Put your pen at the top-left of the printed table. Move it along the heading row, tapping each heading, and write the total — that is the number of fields. Then move it down the left-hand column, tapping each data row, and write that total — that is the number of records. Two counts, two numbers, in two directions. The commonest slip is counting the heading row as a record, which makes every records answer exactly one too many.
- The two repeats are deliberate. Ashwood High School appears twice and 07/03/2026 appears twice. Those repeats are what disqualify GroupName and SessionDate as primary keys, and they are also what makes sorting on SessionDate produce a genuine tie. Real exam tables contain repeats like these for exactly the same reason.
- Command words, one more time. State and give want short factual answers — do not justify unless asked. Identify wants one thing chosen from what is in front of you. Explain and describe the purpose of want a reason as well as a fact. Complete means fill the printed gaps in the printed style. Show the output means write the result table, nothing more. Matching the answer to the command word is worth more marks in Topic 9 than any extra database knowledge.
Questions students ask about Table
Is a database the same thing as a table?
No. A database is an organised collection of data that can be stored, searched and processed; a table is the structure that holds the data in rows and columns. A database can contain many tables, although in Cambridge 2210 Topic 9 it always contains exactly one, which is why the two words are often used loosely for the same thing.
What if no field in the table is unique?
Say so, and say what should be done: a new identifier field must be created and used as the primary key. That is a complete answer, and it is the expected answer whenever a scenario describes data with no natural identifier. Combining two fields into a single key is outside this syllabus.
If a query has no ORDER BY, what order do the records come out in?
SQL makes no guarantee. In an examination, write the qualifying records in the order they appear in the printed table — that is what is expected and it will be marked correct. What you should not do is claim that a database must return them in that order, or assume that an unsorted query gives you a sorted result.
Do I need to know about joins, foreign keys or normalisation?
Not for Topic 9. Those belong to multi-table database design, which this syllabus does not examine. Every Topic 9 question is answerable from the single table you are given. If a question seems to need a second table, re-read it — it does not.
How much should I write for a “show the output” question?
Exactly the result table and nothing else: the selected fields as headings, in the SELECT order, and the qualifying records in the required sort order. No extra columns, no BookingRef unless it was selected, no explanation of why each record qualified. For a SUM or COUNT query, write the single value.