AQA A-Level Computer Science: Databases & SQL — Complete Revision Guide (7517)

Databases sit in specification area 4.10 of AQA A-Level Computer Science (7517), and they are one of the most learnable, highest-return topics on the entire course. Unlike some theory areas where marks hinge on subtle wording, database questions reward two concrete, practisable skills: organising data correctly through normalisation, and reading and writing accurate SQL. Once those skills are secure, this becomes a reliable source of marks rather than a place where they leak away.

The topic is assessed across both written components. Paper 2 (written, 2 hours 30 minutes, 100 marks, 40% of the A-Level) is where database theory is examined directly — entity-relationship modelling, normalisation to third normal form, SQL queries, and the properties that keep a database consistent. Paper 1 (on-screen, 2 hours 30 minutes, 100 marks, 40%) is programming-focused, but database access frequently underpins the problems you solve, and SQL or query logic can appear in code. The Non-Exam Assessment (NEA, 75 marks, 20%) is where databases really come into their own: a well-designed, normalised database with sensible relationships and integrity constraints is exactly the kind of feature that accesses the higher mark bands for the technical solution.

This guide works through every lesson in the LearningBro Databases course as a revision narrative — explaining each concept, why it matters in the exam, and the pitfalls that catch students out — with direct links to each lesson so you can drill the parts you find hardest.

Guide Overview

This guide covers every lesson in the AQA A-Level Computer Science: Databases course:

• Relational Database Concepts — tables, records, fields, primary and foreign keys, and why relational design matters.
• Entity-Relationship Diagrams — entities, attributes, relationships and cardinality.
• Normalisation — 1NF, 2NF and 3NF, and how to eliminate redundancy and anomalies.
• SQL: SELECT, WHERE, ORDER BY — retrieving and filtering data.
• SQL JOIN Operations — combining data across related tables.
• SQL: INSERT, UPDATE, DELETE, CREATE — modifying data and defining table structures.
• SQL Aggregate Functions and GROUP BY — summarising data with COUNT, SUM, AVG and grouping.
• Transactions and ACID Properties — atomicity, consistency, isolation, durability.
• Database Security and Integrity — referential integrity, access control, backups and recovery.
• Databases Exam Practice — mixed exam-style questions across the whole topic.

Relational Database Concepts: The Foundation

Everything in this topic rests on the relational model, covered in relational database concepts. A relational database organises data into tables (relations). Each row is a record (tuple) representing one instance of an entity, and each column is a field (attribute) representing one property. The power of the model comes from linking tables together through keys rather than duplicating data.

The key vocabulary must be exact, because the exam tests it directly:

Term	Meaning
Primary key	A field (or combination of fields) that uniquely identifies each record; cannot be null and must be unique
Composite key	A primary key made up of two or more fields together
Foreign key	A field in one table that references the primary key of another, creating a link
Secondary key	A field used as an index for faster searching, which need not be unique

The central idea AQA wants you to grasp is why relational design is preferable to a single flat table. A flat file holding customers and their orders together repeats every customer's details on each order, which wastes storage and — more importantly — invites update anomalies: change a customer's address and you must find and edit every row that mentions them, or the data becomes inconsistent. Splitting the data into a Customers table and an Orders table, linked by a foreign key, stores each fact once. This motivation for relational design is the thread that runs through entity-relationship modelling and normalisation, so internalise it now.

Entity-Relationship Diagrams: Modelling Before Building

Before any tables are created, a designer models the data requirements. The entity-relationship diagrams lesson covers this. An entity is a real-world object or concept the system stores data about (Student, Course, Order). An attribute is a property of an entity (StudentName, OrderDate). A relationship describes how entities are associated.

The concept that earns and loses the most marks is cardinality — the degree of a relationship:

Cardinality	Example
One-to-one (1:1)	One school has one headteacher
One-to-many (1:M)	One teacher teaches many students
Many-to-many (M:N)	Many students enrol on many courses

The crucial exam skill is recognising that a relational database cannot directly implement a many-to-many relationship. A M:N relationship must be resolved into two one-to-many relationships by introducing a linking table (also called a junction or bridge table). For the students-and-courses example, you create an Enrolment table containing a foreign key to Student and a foreign key to Course; each enrolment row links exactly one student to exactly one course, and the two original tables each have a one-to-many relationship with Enrolment. Questions that present a M:N scenario and ask you to design the tables are common, and forgetting the linking table is the most frequent mistake — it is also the natural connection point into normalisation, where the same restructuring falls out of the formal rules.

Normalisation: The Highest-Yield Skill in the Topic

Normalisation, covered in normalisation, is the process of structuring tables to minimise redundancy and eliminate update, insertion and deletion anomalies. AQA examines up to third normal form (3NF), and these questions reward a methodical, show-your-working approach. There is a well-known mnemonic for 3NF: every non-key attribute must depend on the key, the whole key, and nothing but the key.

First Normal Form (1NF): a table is in 1NF when every field holds a single atomic value, there are no repeating groups, and each record is uniquely identifiable by a primary key. The classic violation is a single field holding a comma-separated list (for example a Subjects field containing "Maths, Physics, CS"), or a set of repeated columns (Subject1, Subject2, Subject3). The fix is to move the repeating data into its own table.

Second Normal Form (2NF): a table is in 2NF when it is in 1NF and every non-key attribute is fully functionally dependent on the whole primary key. This only bites when the primary key is composite. If part of the key determines an attribute on its own, that is a partial dependency and it must be removed by splitting it into a separate table. For instance, in an Enrolment(StudentID, CourseID, StudentName, CourseTitle) table with composite key (StudentID, CourseID), StudentName depends only on StudentID and CourseTitle depends only on CourseID — both are partial dependencies, so student and course details belong in their own tables.

Third Normal Form (3NF): a table is in 3NF when it is in 2NF and there are no transitive dependencies — that is, no non-key attribute depends on another non-key attribute. If OrderID determines CustomerID, and CustomerID determines CustomerName, then CustomerName depends transitively on OrderID through CustomerID. The remedy is to move customer details into a Customers table keyed on CustomerID, leaving the order table to reference it by foreign key.

The reliable method for normalisation questions: identify the primary key first; check for repeating groups and non-atomic fields (1NF); check for partial dependencies on a composite key (2NF); check for transitive dependencies (3NF); and at each stage write out the resulting tables with primary keys and foreign keys clearly marked. A clean way to present your answer is the convention of listing each table with its primary key underlined and foreign keys flagged:

Student(StudentID, StudentName, FormGroup)
Course(CourseID, CourseTitle, Level)
Enrolment(StudentID, CourseID, EnrolmentDate)

Here Enrolment has the composite primary key (StudentID, CourseID), with both columns also acting as foreign keys. Presenting the final schema explicitly — rather than just describing the changes in prose — is what secures the marks.

SQL: Retrieving Data with SELECT, WHERE and ORDER BY

With the structure understood, the SQL SELECT, WHERE, ORDER BY lesson begins the query language. AQA expects you to read SQL fluently and write correct statements by hand under exam conditions. The SELECT statement is the workhorse:

SELECT StudentName, FormGroup
FROM Student
WHERE FormGroup = '12A'
ORDER BY StudentName ASC;

SELECT chooses the columns, FROM names the table, WHERE filters rows against a condition, and ORDER BY sorts the result (ascending by default, or DESC for descending). The WHERE clause supports comparison operators (=, <, >, <=, >=, <>), logical operators (AND, OR, NOT), BETWEEN for ranges, IN for sets of values, and LIKE with wildcards for pattern matching:

SELECT *
FROM Student
WHERE StudentName LIKE 'A%' AND FormGroup IN ('12A', '12B');

Here 'A%' matches any name beginning with A (the % wildcard stands for any sequence of characters; _ stands for a single character). Common pitfalls to avoid: using = to compare against a list when IN is needed, using double quotes instead of single quotes around string literals, and omitting the WHERE clause when filtering is required. Precision with operators and quoting is exactly what the mark scheme checks.

SQL JOIN Operations: Reassembling Related Data

Because normalisation deliberately splits data across tables, you need SQL JOIN operations to bring it back together. A join combines rows from two or more tables based on a related column — almost always a foreign key matching a primary key.

SELECT Student.StudentName, Course.CourseTitle
FROM Student
INNER JOIN Enrolment ON Student.StudentID = Enrolment.StudentID
INNER JOIN Course ON Enrolment.CourseID = Course.CourseID;

This query walks the linking table to answer "which students take which courses" — the exact inverse of the normalisation that separated them. The key points for the exam are to qualify column names with their table name when the same field exists in more than one table (for example Student.StudentID), and to provide the correct ON condition matching the foreign key to the primary key it references. An inner join returns only rows where the match succeeds in both tables, which is what most AQA questions require. Many-to-many questions are the natural setting for a join, so be ready to chain two joins through a linking table as shown above. The single most common error is a missing or incorrect ON clause — without it the query produces a meaningless combination of every row with every other row.

SQL: Modifying Data with INSERT, UPDATE, DELETE and CREATE

Querying is only half of SQL. The SQL INSERT, UPDATE, DELETE, CREATE lesson covers the statements that change data and define structure.

INSERT INTO Student (StudentID, StudentName, FormGroup)
VALUES (101, 'Alice Okoro', '12A');

UPDATE Student
SET FormGroup = '13A'
WHERE StudentID = 101;

DELETE FROM Student
WHERE StudentID = 101;

INSERT adds a new record; UPDATE modifies existing records; DELETE removes them. The most important — and most frequently examined — point is that UPDATE and DELETE without a WHERE clause affect every row in the table. Omitting the WHERE is a catastrophic real-world error and a deliberate trap in exam questions, so always state the condition explicitly.

CREATE TABLE defines a new table, naming each column, its data type, and constraints such as primary and foreign keys:

CREATE TABLE Enrolment (
  StudentID INTEGER,
  CourseID INTEGER,
  EnrolmentDate DATE,
  PRIMARY KEY (StudentID, CourseID),
  FOREIGN KEY (StudentID) REFERENCES Student(StudentID),
  FOREIGN KEY (CourseID) REFERENCES Course(CourseID)
);

This example shows a composite primary key and two foreign keys — the SQL realisation of the linking table you derived during normalisation. Being able to translate a normalised design straight into CREATE TABLE statements with the right constraints is a strong, examinable skill and ties the whole topic together.

Aggregate Functions and GROUP BY: Summarising Data

The SQL aggregate functions and GROUP BY lesson covers how to summarise data rather than list it. The aggregate functions you must know are:

Function	Returns
COUNT	The number of rows
SUM	The total of a numeric column
AVG	The average of a numeric column
MIN	The smallest value
MAX	The largest value

Used alone, an aggregate collapses a whole result set to a single value:

SELECT COUNT(*) FROM Student WHERE FormGroup = '12A';

The real power comes with GROUP BY, which partitions rows into groups and applies the aggregate to each group separately:

SELECT FormGroup, COUNT(*) AS NumberOfStudents
FROM Student
GROUP BY FormGroup;

This returns one row per form group with its student count. The classic exam subtlety is the difference between WHERE and HAVING: WHERE filters individual rows before grouping, whereas HAVING filters groups after aggregation. To find only the form groups with more than 25 students you must use HAVING COUNT(*) > 25, because you are filtering on an aggregated value that does not exist until after grouping. Confusing the two — trying to put an aggregate condition in WHERE — is a frequent and easily avoided error.

Transactions and ACID Properties: Keeping Data Consistent

The transactions and ACID properties lesson explains how a database stays reliable when many operations happen at once or when failures occur. A transaction is a sequence of operations treated as a single, indivisible unit of work — the textbook example being a bank transfer, where money debited from one account must be credited to another, and either both happen or neither does.

The four ACID properties guarantee reliable transactions, and you must be able to define and illustrate each:

Property	Meaning
Atomicity	A transaction is all-or-nothing; if any part fails, the whole transaction is rolled back so no partial change persists
Consistency	A transaction moves the database from one valid state to another, never leaving it violating its rules or constraints
Isolation	Concurrent transactions do not interfere; each behaves as if it ran alone, so intermediate states are not visible to others
Durability	Once a transaction is committed, its changes survive even a subsequent power failure or crash

Bring these to life with the transfer example: atomicity ensures that if the credit fails after the debit, the debit is undone so money is not lost. Consistency ensures the total balance across accounts is preserved. Isolation ensures two simultaneous transfers do not read each other's half-finished state and corrupt the balances. Durability ensures that once the transfer is confirmed, it is not lost if the server crashes a moment later. Record locking is the typical mechanism that delivers isolation — locking the records a transaction is using so other transactions cannot modify them mid-flight, which prevents the lost-update problem where two transactions overwrite each other's changes. Anchoring each property to a concrete consequence, rather than reciting the one-word labels, is what distinguishes a top answer.

Database Security and Integrity: Protecting the Data

The database security and integrity lesson covers the measures that keep data correct and protected. Referential integrity is the constraint that every foreign key value must match an existing primary key in the referenced table (or be null where permitted). It prevents orphan records — for example an enrolment that references a student who no longer exists — and the database management system enforces it by rejecting inserts, updates or deletes that would break the link. This is the formal guarantee that the relationships you modelled in your E-R diagram actually hold in the stored data.

Beyond integrity, the lesson covers protective measures: access control through user accounts and privileges so that users can only perform permitted operations; encryption of stored data so that a stolen database file is unreadable; regular backups with a tested recovery procedure so data can be restored after loss or corruption; and audit logs that record who changed what and when. The recurring exam skill, as elsewhere in 7517 security, is to match each measure to the specific risk it addresses and justify it in context — for instance, recognising that referential integrity protects correctness, whereas encryption protects confidentiality, and that a system usually needs both.

Putting It Into Practice

Databases reward exactly the kind of deliberate, worked practice that exam conditions demand: normalise a few messy datasets until the 1NF/2NF/3NF steps are automatic, and write SQL by hand until joins, grouping and the WHERE/HAVING distinction come without hesitation. The databases exam practice lesson pulls the whole topic together with mixed questions in AQA's style and depth, so you can confirm your design and query skills are secure before Paper 2. Always show your working on normalisation, mark your keys, and never write an UPDATE or DELETE without a WHERE.

Next Steps

Work through the AQA A-Level Computer Science: Databases course in order, prioritising normalisation and SQL joins — the two highest-yield skills — using the lesson links above to target your weakest areas. Then place databases within the wider qualification by following the A-Level Computer Science (AQA) learning path, which sequences databases alongside architecture, networking and the programming components so your revision builds coherently towards Paper 1, Paper 2 and a strong NEA.