Students will be able to select the most appropriate primitive or derived data type for a given problem, define a record in Cambridge‑style pseudocode, and produce a complete identifier table. The content also covers the required array and file concepts and introduces the basic abstract data types (ADTs) that appear later in the syllabus.
Why Data Types Matter
Memory efficiency – each type occupies a defined amount of storage.
Correct calculations – integer division vs. real‑valued division, rounding, precision.
Run‑time safety – prevents overflow, under‑flow and type‑mismatch errors.
Readability & maintainability – a clear type tells the programmer what the data represents.
Primitive Data Types (Cambridge Specification)
Type
Typical Size (bits)
Range / Values
Typical Use
INTEGER
32
‑231 to 231‑1
Whole numbers, counters, indexes
REAL
32 (single) or 64 (double)
≈ ±3.4 × 1038 (≈7 dp) or ±1.8 × 10308 (≈15 dp)
Measurements, scientific calculations, monetary values (when fixed‑point is not required)
CHAR
8
ASCII characters 0…127
Single characters, codes
STRING
Variable (1 byte per character)
Sequence of CHAR values; length fixed in the declaration
Names, messages, textual data
BOOLEAN
1 (conceptually)
TRUE / FALSE
Logical conditions, flags
DATE
Variable (often three INTEGER fields)
Valid calendar dates, e.g. 2025‑12‑30
Birth dates, timestamps, scheduling
Derived Data Types (Cambridge Specification)
ARRAY – ordered collection of elements of the same primitive (or record) type.
RECORD – grouping of fields that may be of different primitive types; models a real‑world entity.
FILE – sequential collection of records stored on secondary storage; accessed with OPEN, READ, WRITE, CLOSE.
Assessment Objective (AO) Mapping
AO
What is assessed
How the notes address it
AO1
Recall terminology and definitions
Lists of primitive/derived types, syntax for RECORD, ARRAY and FILE
AO2
Select appropriate data types and justify choices
Decision checklist, examples with justification, AO‑mapping table
AO3
Design and use records, arrays and files in a program
Full record definitions, identifier tables, array declaration, file‑handling snippets, bubble‑sort/linear‑search examples
Designing a Record – Step‑by‑Step
Identify the real‑world entity to be modelled.
List every attribute (field) that must be stored.
Choose the most suitable primitive type for each attribute, considering range, precision and any special constraints (e.g., maximum string length).
Write the record definition in Cambridge‑style pseudocode.
Provide an identifier table that documents each field.
Example 1 – Student Record
Record Definition (Cambridge pseudocode)
record Student
INTEGER studentID
STRING firstName[30]
STRING lastName[30]
DATE dateOfBirth
REAL gpa
BOOLEAN isFullTime
endrecord
Identifier Table
Identifier
Type
Description
studentID
INTEGER
Unique numeric identifier for the student
firstName
STRING[30]
Given name (max 30 characters)
lastName
STRING[30]
Family name (max 30 characters)
dateOfBirth
DATE
Birth date in the format YYYY‑MM‑DD
gpa
REAL
Grade Point Average (0.0 – 4.0)
isFullTime
BOOLEAN
TRUE if the student is enrolled full‑time
Using the Record (pseudocode)
DECLARE stud : Student
stud.studentID ← 10234
stud.firstName ← "Emma"
stud.gpa ← 3.75
IF stud.isFullTime THEN
// process full‑time student
ENDIF
Example 2 – Library Book Management System (including ARRAY and FILE)
Record Definition
record Book
STRING ISBN[13] // keep leading zeros
STRING title[100]
STRING author[50]
INTEGER publishedYear
REAL price
BOOLEAN isAvailable
endrecord
Identifier Table for Book
Identifier
Type
Description
ISBN
STRING[13]
13‑digit International Standard Book Number
title
STRING[100]
Title of the book
author
STRING[50]
Author’s name
publishedYear
INTEGER
Year the book was published
price
REAL
Retail price (e.g. £12.99)
isAvailable
BOOLEAN
TRUE if the book is on the shelf
Array of Records – Declaration
DECLARE library : ARRAY[1..1000] OF Book // up to 1000 books
DECLARE numberOfBooks : INTEGER ← 0
Identifier Table for the Array
Identifier
Type
Description
library
ARRAY[1..1000] OF Book
Stores the collection of books in the library
numberOfBooks
INTEGER
Current count of valid entries in library
File Handling – Saving the Library (Sequential Access)
OPEN "library.dat" FOR WRITE AS bookFile
FOR i ← 1 TO numberOfBooks DO
WRITE bookFile FROM library[i]
ENDFOR
CLOSE bookFile
File Handling – Loading the Library (Sequential Access)
OPEN "library.dat" FOR READ AS bookFile
i ← 1
WHILE NOT EOF(bookFile) DO
READ bookFile INTO library[i]
i ← i + 1
ENDWHILE
numberOfBooks ← i - 1
CLOSE bookFile
Selecting Data Types – Decision Checklist
Is the value whole or fractional? → INTEGER or REAL.
Will the value ever exceed the INTEGER range? → Use a larger type (e.g., LONG) or split the data.
Is the data textual? → CHAR for a single character, STRING[n] for longer text.
Does the value represent a calendar date? → DATE.
Do you need a binary condition? → BOOLEAN.
Are several related values required? → Define a RECORD and, if many instances are needed, an ARRAY of that record.
Will the data be stored permanently? → Use a FILE of the appropriate RECORD type.
Is numerical precision critical (e.g., money)? → Prefer REAL with explicit rounding or a fixed‑point representation.
Common Pitfalls
Overflow – using INTEGER for values > 2,147,483,647.
Leading zeros lost – storing identifiers such as ZIP codes or ISBNs as INTEGER; use STRING instead.
Unit mismatch – mixing metres and kilometres without conversion.
Uninitialised fields – can cause undefined behaviour; always assign a default value.
Incorrect file mode – opening a file for WRITE when you intend to READ will erase existing data.
Array out‑of‑bounds – accessing an index < 1 or > upper bound causes run‑time errors.
Summary
Effective problem solving begins with a careful analysis of the data involved. By matching each piece of information to the most appropriate primitive or derived type, documenting the choice in an identifier table, and grouping related items into a well‑defined RECORD (with optional ARRAY and FILE handling), students produce programs that are clear, efficient, and fully aligned with the Cambridge AS & A‑Level Computer Science 9618 syllabus.
10.2 Arrays
Array Fundamentals (Cambridge Specification)
Index base: Cambridge uses a lower bound of 1 unless otherwise stated.
Bounds: declared as ARRAY[lower..upper] OF <type>. The number of elements is upper – lower + 1.
Out‑of‑range errors occur if an index is less than the lower bound or greater than the upper bound.
Arrays may hold INTEGER, REAL, CHAR, STRING, BOOLEAN, DATE or any RECORD.
Iterating Over an Array (pseudocode)
DECLARE scores : ARRAY[1..10] OF INTEGER
FOR i ← 1 TO 10 DO
scores[i] ← 0 // initialise each element
ENDFOR
Bubble‑Sort Example (INTEGER array)
PROCEDURE bubbleSort(arr : ARRAY[1..n] OF INTEGER, n : INTEGER)
DECLARE i, j, temp : INTEGER
FOR i ← 1 TO n-1 DO
FOR j ← 1 TO n-i DO
IF arr[j] > arr[j+1] THEN
temp ← arr[j]
arr[j] ← arr[j+1]
arr[j+1] ← temp
ENDIF
ENDFOR
ENDFOR
ENDPROCEDURE
Linear‑Search Example (INTEGER array)
FUNCTION linearSearch(arr : ARRAY[1..n] OF INTEGER, n : INTEGER, key : INTEGER) RETURNS INTEGER
DECLARE i : INTEGER
FOR i ← 1 TO n DO
IF arr[i] = key THEN
RETURN i // position of the key
ENDIF
ENDFOR
RETURN 0 // 0 indicates “not found”
ENDFUNCTION
Array of Records – Identifier Table (re‑using the Book record)
Identifier
Type
Description
library
ARRAY[1..1000] OF Book
Collection of up to 1000 books
numberOfBooks
INTEGER
Current number of valid entries in library
10.3 Files
Why Files?
Data must often survive after the program terminates (e.g., student registers, library catalogues).
Files provide persistent storage on secondary media (disk, USB, cloud).
They allow programs to share data with other programs or later runs of the same program.
Sequential vs. Random Access
Sequential access: records are read or written one after another. Simple READ/WRITE loops are used; suitable for most Cambridge exam questions.
Random access: the program can jump directly to a particular record (e.g., the 57th book) using SEEK or by reopening the file and reading until the desired index is reached. Random access is not required for the 9618 exam but understanding the concept helps avoid logical errors.
File Declaration Syntax (Cambridge pseudocode)
DECLARE bookFile : FILE OF Book
Opening a File – Modes
FOR READ – open for reading; file must already exist.
FOR WRITE – open for writing; existing content is erased.
FOR APPEND – open for writing, but new records are added after the existing ones.
Sequential Access Example – Reading a Specific Record (Random‑access style)
PROCEDURE readBookByIndex(fileName : STRING, index : INTEGER) RETURNS Book
DECLARE bookFile : FILE OF Book
DECLARE temp : Book
OPEN fileName FOR READ AS bookFile
FOR i ← 1 TO index DO
READ bookFile INTO temp
IF EOF(bookFile) THEN
CLOSE bookFile
RETURN null // index out of range
ENDIF
ENDFOR
CLOSE bookFile
RETURN temp
ENDPROCEDURE
Common File Pitfalls
Opening a file in WRITE mode when you only need to read – this overwrites the file.
Forgetting to CLOSE a file – may lead to data loss or file‑handle exhaustion.
Not checking EOF before a READ – can cause run‑time errors.
Assuming a file is always present; always handle the “file not found” situation in exam code with a comment.
10.4 Abstract Data Types (ADTs)
What is an ADT?
An abstract data type defines a set of values and the operations that can be performed on those values, without specifying how the operations are implemented. In the Cambridge syllabus the focus is on the logical behaviour of three ADTs:
Linked List – a chain of nodes where each node contains data and a reference to the next node. Primary operations: INSERT, DELETE, SEARCH, TRAVERSE.
Implementing ADTs with Arrays (Cambridge‑style pseudocode)
Stack Using an ARRAY
DECLARE stack : ARRAY[1..MAX] OF INTEGER
DECLARE top : INTEGER ← 0
PROCEDURE push(value : INTEGER)
IF top = MAX THEN
// stack overflow – handle as required
ELSE
top ← top + 1
stack[top] ← value
ENDIF
ENDPROCEDURE
FUNCTION pop() RETURNS INTEGER
IF top = 0 THEN
// stack underflow – handle as required
RETURN -1
ELSE
pop ← stack[top]
top ← top - 1
ENDIF
ENDFUNCTION
Queue Using an ARRAY (circular technique)
DECLARE queue : ARRAY[1..MAX] OF INTEGER
DECLARE front, rear, count : INTEGER ← 0
PROCEDURE enqueue(value : INTEGER)
IF count = MAX THEN
// queue full
ELSE
rear ← (rear MOD MAX) + 1
queue[rear] ← value
count ← count + 1
ENDIF
ENDPROCEDURE
FUNCTION dequeue() RETURNS INTEGER
IF count = 0 THEN
// queue empty
RETURN -1
ELSE
front ← (front MOD MAX) + 1
dequeue ← queue[front]
count ← count - 1
ENDIF
ENDFUNCTION
Linked List – Conceptual Overview (no full code required for the exam)
Each node contains: data : <type> and next : POINTER TO Node.
Operations manipulate the next references rather than array indexes.
Advantages: dynamic size, easy insertion/deletion at any position.
Disadvantages: additional memory for pointers, no direct random access.
Why ADTs Matter for the Syllabus
They develop algorithmic thinking – students must choose the most suitable structure for a given problem.
Understanding the abstract behaviour helps when the exam asks for “explain what the operation does” without requiring full implementation.
Many past‑paper questions involve converting a real‑world scenario into a stack, queue or linked list description.
10.5 Summary Checklist for the Exam
Identify every piece of data and decide whether it is INTEGER, REAL, CHAR, STRING, BOOLEAN or DATE.
Group related fields into a RECORD and write a clear identifier table.
If you need several records, declare an ARRAY of that record type and include an identifier table for the array.
When data must survive beyond program execution, use a FILE. State the purpose, the mode (READ/WRITE/APPEND) and show at least one OPEN/READ/WRITE/CLOSE sequence.
For algorithmic questions, be ready to write simple array loops, a bubble‑sort, a linear‑search, and basic ADT operations (push/pop, enqueue/dequeue).
Check for common pitfalls – overflow, leading‑zero loss, out‑of‑bounds array access, file mode errors, and uninitialised variables.
Map your answer to the assessment objectives: terminology (AO1), justification of type choice (AO2), and correct implementation (AO3).
Suggested diagram: Memory layout of the Student record showing the byte offset of each field (illustrative only).