A primary key and foreign key GCSE computer science question is testing whether you understand how relational databases link separate tables together. A primary key uniquely identifies each row in its own table; a foreign key is a copy of another table's primary key, placed in a second table to create a relationship between the two.

What is a primary key in a database?

A primary key is a field (or combination of fields) in a table that uniquely identifies every row. No two rows in the table can share the same primary key value, and a primary key can never be left blank.

Common examples of primary keys include a StudentID, a ProductCode, or an OrderNumber — something specifically created (or chosen) to be unique, rather than a field like Surname, which could easily repeat across rows.

A good primary key has three properties:

  • Unique — no two rows can have the same value.
  • Not null — every row must have a value; it cannot be left empty.
  • Stable — the value should not need to change over time (a person's name might change; an ID number typically does not).

Databases usually mark the primary key field in a table's structure, and many systems (like MySQL or Microsoft Access) can auto-generate a new, unique number for it each time a row is added, so the designer never has to worry about duplicates.

A foreign key is a field in one table that stores the primary key value from another table. It does not have to be unique within its own table — in fact, the same foreign key value usually appears many times, because it is what connects many rows in one table to a single row in another.

For example, in a school database, a StudentID might be the primary key of a Students table. That same StudentID field, placed inside a Grades table, becomes a foreign key — linking every grade record back to exactly one student.

Foreign keys are what make a database relational: instead of repeating a student's full name and details in every single grade record (which wastes space and risks inconsistency), you store the student's details once and reference them by ID wherever needed.

How do primary and foreign keys create a relational database? A worked example

Consider a simple two-table database used to record students and their exam results.

Students table (primary key: StudentID)

StudentID FirstName Surname
S01 Amara Okafor
S02 Leo Chan
S03 Priya Patel

Grades table (primary key: GradeID; foreign key: StudentID)

GradeID StudentID Subject Grade
G101 S01 Computer Science 8
G102 S01 Mathematics 7
G103 S02 Computer Science 6
G104 S03 Computer Science 9

Here, StudentID is the primary key in the Students table (each value appears once) but a foreign key in the Grades table (the value S01 appears twice, because Amara has two grade records). This is exactly what allows a query to answer a question like "show me every grade Amara Okafor achieved" without storing her name in the Grades table at all — the database simply looks up every row in Grades where StudentID equals S01, then joins that to her name in Students.

If a new grade record was created with StudentID = S05, but no student S05 exists in the Students table, a well-designed database would reject it. This rule is called referential integrity — a foreign key value must always match an existing primary key value in the table it references (or be left blank, if the field allows it).

What makes a good primary key?

Not every unique-looking field makes a safe primary key. GCSE questions often test whether you can spot a poor choice.

  • Avoid names — two students could share the exact same first and last name, breaking uniqueness.
  • Avoid fields that can change — using an email address as a primary key becomes a problem if a student's email changes, since every foreign key referencing it would then need updating too.
  • Prefer a dedicated ID field — a purpose-built code like StudentID or an auto-incrementing number is stable, guaranteed unique, and never needs to carry meaning about the person it identifies.

This is why almost every real database — from a school's records system to a supermarket's stock system — uses invented ID codes rather than relying on natural, human-readable data as the primary key.

What is the difference between a primary key and a foreign key?

Feature Primary key Foreign key
Location The table it identifies A different, related table
Must be unique in its table Yes No — can repeat
Can be blank (null) No Sometimes, depending on the relationship
Purpose Uniquely identifies each row Links a row to a row in another table
Example StudentID in Students StudentID in Grades

A single field, like StudentID in the example above, can be a primary key in one table and a foreign key in another at the same time — that dual role is exactly what creates the relationship between the two tables.

Frequently asked questions

What is a primary key in a database, simply explained?

A primary key is the field in a table that uniquely identifies each row, so no two rows can ever share the same value and the field can never be left empty. It is usually a purpose-built ID, such as StudentID or OrderNumber, rather than a field like a name that could repeat. Every well-designed table needs exactly one primary key.

How is a foreign key different from a primary key?

A foreign key is a field in one table that stores a copy of another table's primary key, creating a link between the two tables. Unlike a primary key, a foreign key does not need to be unique — the same value can appear many times, since many rows in one table can relate to a single row in another (for example, many grades belonging to one student).

Why can't a name be used as a primary key?

Names are not reliably unique — two different students could share exactly the same first and last name, which would break the "no duplicates" rule a primary key must follow. Names can also change over time (through marriage or a legal name change), which would be a problem for any foreign key referencing that value. A dedicated, stable ID field avoids both issues.

What happens if a foreign key doesn't match any primary key value?

A properly designed relational database enforces referential integrity, which means a foreign key value must always correspond to an existing primary key value in the table it references — otherwise, the database should reject the entry or require the foreign key field to be left blank. This prevents "orphaned" records, such as a grade entry pointing to a student ID that does not actually exist in the Students table.


For Socratic computing tutoring at GCSE — from database design to full programming projects — see aitutors.me.