Databases, SQL and Normalisation - Worksheets, Questions and Revision

12 original exam-style questions - 6 pages of questions with a full mark scheme - free printable PDF.

Download PDF Jump to mark scheme (page 7)Read the revision guide

Next in this strand

Revision Library

revisionlibrary.co.uk

A-Level · Component 01: Computer Systems - Databases

A1.8 Databases, SQL and Normalisation

OCR H446 · Calculators not allowed · about 115 minutes

Total Marks

Name: _______________________________ Date: ____ / ____ / ______

Answer ALL questions. Show all your working.

This question is about the different types of key used in relational database tables.

(a)State what is meant by a primary key of a database table.(1)

(b)State what is meant by a foreign key.(1)

(c)A cinema stores ticket bookings in a table called Ticket. No single column is unique on its own, but the combination of ScreeningID and SeatNumber together always uniquely identifies one row. State the term for this type of key, and explain why two columns are needed rather than one.(2)

(d)A college's Student table has three columns that could each uniquely identify a student: StudentID, NationalInsuranceNumber and Email. StudentID is chosen as the primary key. State the term used for NationalInsuranceNumber and Email in this situation, and state one reason StudentID might be preferred as the primary key over NationalInsuranceNumber.(2)

(Total for Question 1 is 6 marks)

Ferngate Leisure Centre is replacing its paper-based booking system with a relational database. Management describe their requirements as follows:
- The centre employs several fitness instructors. Each instructor has one main speciality (e.g. yoga, spin, pilates) and runs one or more different fitness classes during the week.
- Each fitness class is run by exactly one instructor, on a fixed day and start time, and has a maximum number of places.
- Members join the centre and can book a place on any class. A member may book onto many different classes, and a class may have many members booked onto it, each on their own booking date, with a record kept of whether they actually attended.
- The centre needs to store each member's name, date of birth and the date they joined, and each instructor's name, speciality and contact number.

(a)Identify the four entities (tables) needed to model this system, and give a suitable name for each.(3)

(b)State, with a reason from the scenario, the relationship type (one-to-one, one-to-many or many-to-many) between Instructor and FitnessClass.(2)

(c)Explain why a linking entity (Booking) is needed to model the relationship between Member and FitnessClass, rather than a direct relationship between the two tables.(2)

(d)State a suitable primary key for each of the four entities you identified in part (a).(3)

(Total for Question 2 is 10 marks)

The analysis in Question 2 results in the following schema, which Ferngate Leisure Centre has now implemented (primary keys marked [PK], foreign keys marked [FK]):

Member(MemberID [PK], FirstName, LastName, DateOfBirth, JoinDate, MembershipType)
Instructor(InstructorID [PK], FirstName, LastName, Speciality, ContactNumber)
FitnessClass(ClassID [PK], ClassName, InstructorID [FK], DayOfWeek, StartTime, DurationMins, MaxCapacity)
Booking(BookingID [PK], MemberID [FK], ClassID [FK], BookingDate, Attended)

FitnessClass.InstructorID references Instructor.InstructorID. Booking.MemberID references Member.MemberID and Booking.ClassID references FitnessClass.ClassID. Attended holds the text 'Yes' or 'No'. Refer to this schema for every remaining question in this pack unless stated otherwise.

Write an SQL statement for each of the following.

(a)List the FirstName and LastName of every member whose MembershipType is 'Premium'.(2)

(b)List the ClassName and DayOfWeek of every fitness class, sorted alphabetically by ClassName.(2)

(c)Count how many bookings have been made for the class with ClassID 5.(2)

(d)Display each distinct MembershipType currently held by members, with no duplicates in the result.(2)

(e)List the LastName of every instructor whose Speciality contains the word 'Yoga' anywhere within it.(2)

(Total for Question 3 is 10 marks)

Refer to the Ferngate Leisure Centre schema given in Question 3. Write an SQL statement for each of the following.

(a)Insert a new row into the Member table for a new member with MemberID 214, first name Priya, last name Chandran, date of birth 14/03/2001, join date 01/07/2026, and membership type 'Standard'.(3)

(b)Increase the MaxCapacity of the class with ClassID 5 by 5 places.(2)

(c)Delete every booking record where Attended is 'No' and the BookingDate is before 01/01/2026.(3)

(Total for Question 4 is 8 marks)

Refer to the Ferngate Leisure Centre schema given in Question 3. The centre wants to add a new table, Payment, to record membership fee payments, with these columns: PaymentID (a whole number, and the primary key), MemberID (a whole number, a foreign key referencing Member), Amount (a decimal value), PaymentDate (a date) and Method (short text, e.g. 'Card' or 'Cash').

(a)Write the SQL statement to create the Payment table described above, including its primary key and foreign key constraints.(6)

(b)State why MemberID in the Payment table should be constrained as a foreign key rather than left as an ordinary, unconstrained column.(2)

(Total for Question 5 is 8 marks)

Refer to the Ferngate Leisure Centre schema given in Question 3.

(a)State what is meant by referential integrity in a relational database.(2)

(b)A member of staff tries to delete the row for InstructorID 3 from the Instructor table, but InstructorID 3 still appears as a foreign key value in three rows of the FitnessClass table. Explain what will happen if the DBMS enforces referential integrity with no cascade option set, and why this default behaviour is useful.(3)

(c)Explain, using this scenario, the difference in outcome if the foreign key constraint on FitnessClass.InstructorID were instead set to ON DELETE CASCADE.(3)

(Total for Question 6 is 8 marks)

Before adopting the schema in Question 3, Ferngate Leisure Centre kept class registers in a single flat table, ClassRegister, with no separate tables for classes, instructors or members. A sample of the data is shown below.

ClassRegister:

ClassID	ClassName	InstructorID	InstructorName	InstructorSpeciality	MemberID	MemberName	MemberPhone	BookingDate	Attended
5	Spin	12	Grace Whitfield	Cycling	88	Callum Ashworth	07700 900123	03/02/2026	Yes
5	Spin	12	Grace Whitfield	Cycling	91	Freya Doku	07700 900456	03/02/2026	No
7	Pilates	12	Grace Whitfield	Cycling	88	Callum Ashworth	07700 900123	04/02/2026	Yes

Using this table, describe an example of each type of anomaly named below.

(a)An insertion anomaly.(2)

(b)A deletion anomaly.(2)

(c)An update anomaly.(2)

(Total for Question 7 is 6 marks)

Refer to the ClassRegister table given in Question 7.

(a)State, with a reason, whether ClassRegister is in First Normal Form (1NF).(1)

(b)State the composite primary key of ClassRegister, and identify one partial dependency that prevents the table being in Second Normal Form (2NF).(3)

(c)Normalise ClassRegister to Second Normal Form (2NF) by removing the partial dependencies identified in part (b). State the resulting tables and the attributes (columns) in each.(4)

(d)State one transitive dependency remaining in your 2NF Class table from part (c), and normalise further to produce the resulting 3NF tables.(4)

(e)State one advantage of the normalised 3NF design from part (d) over the original flat ClassRegister table.(2)

(Total for Question 8 is 14 marks)

Refer to the Ferngate Leisure Centre schema given in Question 3. Write an SQL statement for each of the following.

(a)Using an INNER JOIN, list the FirstName and LastName of every member together with the ClassName of every class they have booked. Each member should appear once for every booking they have made.(4)

(b)Using a LEFT JOIN, list the FirstName and LastName of every member who has never made a booking.(4)

(c)State why an INNER JOIN would not be suitable for answering part (b).(2)

(Total for Question 9 is 10 marks)

Refer to the Ferngate Leisure Centre schema given in Question 3. Write an SQL statement for each of the following.

(a)Display the InstructorID and the number of classes each instructor runs, for instructors who run more than one class.(4)

(b)Using a subquery, display the ClassName of any class whose MaxCapacity is greater than the average MaxCapacity of all classes.(4)

(Total for Question 10 is 8 marks)

This question is about transaction processing in the Ferngate Leisure Centre database.

(a)State what each letter of the acronym ACID stands for, in the context of database transaction processing.(4)

(b)When a member books a class, the database must both insert a new row into Booking and update the count of places remaining for that class in FitnessClass, as a single transaction. Discuss why atomicity and isolation are both essential properties for this transaction, using this booking scenario to illustrate your answer.(4)

(Total for Question 11 is 8 marks)

This question is about how the Ferngate Leisure Centre database manages multiple users accessing it at the same time.

(a)State what is meant by record locking in a multi-user database system.(2)

(b)State one difference between pessimistic locking and optimistic (validation-based) concurrency control.(2)

(c)Two receptionists at different desks try, at almost the same moment, to book the last remaining place on the same fitness class for two different members. Discuss how the DBMS's concurrency control prevents this resulting in the class becoming overbooked, and explain what is meant by a deadlock and one method the DBMS could use to resolve one.(4)

(Total for Question 12 is 8 marks)

Mark scheme · A1.8 Databases, SQL and Normalisation

Question 1

(a) B1 A field (or minimal combination of fields) whose value uniquely identifies each record/row in a table (oe)
(a) Answer: A field, or minimal set of fields, that uniquely identifies each row in a table.
(b) B1 A field in one table that references (matches the value of) the primary key of another table, used to link the two tables (oe)
(b) Answer: A field in one table that holds the value of the primary key of another table, creating a link between the two tables.
(c) B1 Composite key (accept compound key)
(c) B1 Explains that neither ScreeningID alone (repeats for every seat sold at that screening) nor SeatNumber alone (repeats across different screenings) is unique by itself, so both are needed together to guarantee uniqueness (oe)
(c) Answer: Composite key (ScreeningID + SeatNumber). Neither column is unique alone: the same ScreeningID appears once per seat sold, and the same SeatNumber appears once per screening, so only the combination is guaranteed unique.
(d) B1 Candidate keys (accept alternate keys)
(d) B1 Valid reason, e.g. StudentID can be a simple, short, system-generated number under the college's control and is never missing, whereas National Insurance Number is sensitive personal data and may not yet be issued for a young student (oe)
(d) Answer: NationalInsuranceNumber and Email are candidate keys. StudentID may be preferred because it is a simple system-generated number under the college's control, avoiding the need to store sensitive personal data as the key and avoiding problems where a student does not yet have a National Insurance number.

Question 2

(a) B1 Member entity identified (oe name, e.g. Customer)
(a) B1 Instructor entity identified
(a) B1 Both FitnessClass and Booking entities identified (both required for this mark, since one links members to classes)
(a) Answer: Member, Instructor, FitnessClass, Booking (or equivalent names).
(b) B1 One-to-many
(b) B1 Correct justification: one instructor can run several classes, but each class has exactly one instructor (oe)
(b) Answer: One-to-many (one Instructor to many FitnessClass records), because each class has only one instructor but an instructor can run several classes.
(c) B1 States that the relationship between Member and FitnessClass is many-to-many (a member books many classes; a class has many members) (oe)
(c) B1 Explains that a relational database cannot represent a many-to-many relationship directly, so a linking entity is used to break it into two one-to-many relationships (oe)
(c) Answer: Because Member and FitnessClass have a many-to-many relationship, and a relational database can only directly represent one-to-many relationships; the Booking entity resolves this by forming a one-to-many relationship with each of Member and FitnessClass.
(d) B1 Member: MemberID and Instructor: InstructorID both correct
(d) B1 FitnessClass: ClassID correct
(d) B1 Booking: a new unique reference such as BookingID, not simply MemberID + ClassID alone if repeat bookings are possible - accept MemberID + ClassID + BookingDate as a valid composite alternative
(d) Answer: MemberID, InstructorID, ClassID, BookingID (each a unique system-generated reference for its entity).

Question 3

(a) B1 Correct SELECT ... FROM Member structure naming the two correct columns
(a) B1 Correct WHERE clause: WHERE MembershipType = 'Premium'
(a) Answer: SELECT FirstName, LastName FROM Member WHERE MembershipType = 'Premium';
(b) B1 Correct SELECT ClassName, DayOfWeek FROM FitnessClass
(b) B1 Correct ORDER BY ClassName (ascending is the default, so no ASC is required, though ASC is also accepted)
(b) Answer: SELECT ClassName, DayOfWeek FROM FitnessClass ORDER BY ClassName;
(c) B1 Correct use of COUNT(*) or COUNT(BookingID), FROM Booking
(c) B1 Correct WHERE ClassID = 5
(c) Answer: SELECT COUNT(*) FROM Booking WHERE ClassID = 5;
(d) B1 Correct use of the DISTINCT keyword
(d) B1 Correct FROM Member with no unnecessary WHERE clause or extra columns
(d) Answer: SELECT DISTINCT MembershipType FROM Member;
(e) B1 Correct SELECT LastName FROM Instructor
(e) B1 Correct use of LIKE with wildcards on both sides: WHERE Speciality LIKE '%Yoga%'
(e) Answer: SELECT LastName FROM Instructor WHERE Speciality LIKE '%Yoga%';

Question 4

(a) B1 Correct INSERT INTO Member (...) structure naming all six columns in a sensible order
(a) B1 Correct VALUES list with all six values in the same order as the named columns, text/date values single-quoted
(a) B1 Values match those given exactly: 214, 'Priya', 'Chandran', 14/03/2001, 01/07/2026, 'Standard'
(a) Answer: INSERT INTO Member (MemberID, FirstName, LastName, DateOfBirth, JoinDate, MembershipType) VALUES (214, 'Priya', 'Chandran', '2001-03-14', '2026-07-01', 'Standard');
(b) B1 Correct UPDATE FitnessClass SET MaxCapacity = MaxCapacity + 5 structure
(b) B1 Correct WHERE ClassID = 5
(b) Answer: UPDATE FitnessClass SET MaxCapacity = MaxCapacity + 5 WHERE ClassID = 5;
(c) B1 Correct DELETE FROM Booking structure
(c) B1 Correct WHERE Attended = 'No' condition
(c) B1 Correct AND condition on BookingDate before the given date, e.g. AND BookingDate < '2026-01-01', combined with AND (not OR)
(c) Answer: DELETE FROM Booking WHERE Attended = 'No' AND BookingDate < '2026-01-01';

Question 5

(a) B1 CREATE TABLE Payment syntax with all five columns listed
(a) B1 Appropriate data type chosen for each column (e.g. INT/INTEGER for PaymentID and MemberID, DECIMAL for Amount, DATE for PaymentDate, VARCHAR/CHAR/TEXT for Method)
(a) B1 PaymentID correctly declared PRIMARY KEY
(a) B1 MemberID declared as a foreign key using FOREIGN KEY (MemberID) REFERENCES Member(MemberID), or an equivalent inline REFERENCES clause
(a) B1 Statement is syntactically well-formed overall (matching brackets, commas between column definitions, terminating semicolon)
(a) B1 No contradictory or incorrect constraint added (e.g. does not also make MemberID a second primary key)
(a) Answer:CREATE TABLE Payment (
PaymentID INT PRIMARY KEY,
MemberID INT,
Amount DECIMAL(6,2),
PaymentDate DATE,
Method VARCHAR(10),
FOREIGN KEY (MemberID) REFERENCES Member(MemberID)
);
(b) B1 Enforces referential integrity: prevents a payment being inserted for a MemberID that does not exist in the Member table (oe)
(b) B1 Second valid point, e.g. it also restricts deletion/update of a referenced Member row unless a cascade rule is set, keeping the two tables consistent with each other (oe)
(b) Answer: It enforces referential integrity: the DBMS will reject any Payment row whose MemberID does not already exist in Member, and it controls what happens to Payment rows if the referenced Member row is later updated or deleted, keeping the two tables consistent.

Question 6

(a) B1 Rule(s) ensuring that a foreign key value in one table must either match an existing primary key value in the referenced table, or be null (oe)
(a) B1 Second point, e.g. this prevents 'orphaned' rows that reference a record which does not exist (oe)
(a) Answer: Referential integrity means every foreign key value must match an existing primary key value in the table it references (or be null), so no row can reference a record that does not exist.
(b) B1 The DELETE is rejected/fails with an error, because deleting would leave three FitnessClass rows referencing an Instructor that no longer exists (oe)
(b) B1 This is the default 'restrict'/'no action' behaviour of the foreign key constraint
(b) B1 Explains why this is useful: it protects data integrity by stopping the accidental creation of orphaned FitnessClass rows whose InstructorID would no longer correspond to any real instructor (oe)
(b) Answer: The DBMS rejects/blocks the deletion of InstructorID 3, because three FitnessClass rows still reference it as a foreign key. This restrict/no-action default protects the database from ending up with FitnessClass rows pointing at an instructor that no longer exists.
(c) B1 States that the DELETE would now be allowed to succeed rather than being rejected
(c) B1 Explains that all three FitnessClass rows referencing InstructorID 3 would automatically also be deleted (oe)
(c) B1 Notes the consequence/risk: those three classes would be removed from the system entirely rather than being kept and perhaps reassigned to a different instructor, which may not be the desired real-world outcome (oe)
(c) Answer: With ON DELETE CASCADE, deleting InstructorID 3 would succeed, and the DBMS would automatically delete all three FitnessClass rows that referenced InstructorID 3 as well, rather than blocking the deletion. This removes those classes from the system entirely, which may be undesirable if the centre only wanted to reassign them to a new instructor.

Question 7

(a) B1 Correctly identifies that a new instructor with no class assigned yet cannot be added to the database at all, because there is no class/booking row for their details to attach to (oe)
(a) B1 Links this clearly to the flat table structure: instructor data only exists as part of a class-booking row, so it cannot exist independently (oe)
(a) Answer: A newly hired instructor who has not yet been assigned a class cannot be entered into ClassRegister at all, because instructor details only ever appear attached to a ClassID/MemberID booking row; there is no row to insert their details into.
(b) B1 Correctly identifies that deleting a member's only booking row would also delete that member's own details, e.g. deleting Freya Doku's row (her only booking) loses all record of her (MemberID, name, phone) even though she is still a member (oe)
(b) B1 Explains why this happens: member/instructor data is not stored independently of booking rows, so deleting a booking row can unintentionally delete other data (oe)
(b) Answer: If Freya Doku's row (her only booking) is deleted because the booking was cancelled, all record of Freya Doku's details (MemberID, name, phone) is lost from the database too, even though she is still a member of the centre.
(c) B1 Correctly identifies that Grace Whitfield's details (InstructorName/InstructorSpeciality) are repeated in multiple rows (rows 1, 2 and 3), so changing her speciality requires updating every one of those rows (oe)
(c) B1 Explains the risk: if only some of the repeated rows are updated, the table becomes inconsistent, showing two different specialities for the same instructor (oe)
(c) Answer: Grace Whitfield's InstructorSpeciality ('Cycling') appears in all three sample rows. If she retrains and her speciality changes, every row containing her details must be updated; if even one row is missed, the table then holds two different, contradictory specialities for the same instructor.

Question 8

(a) B1 Yes, it is in 1NF, because every cell holds a single, atomic value and there are no repeating groups of columns within a single row (oe)
(a) Answer: Yes, ClassRegister is in 1NF: every column holds one atomic value per row, and there is no repeating group of columns (e.g. no Member1Name, Member2Name pattern).
(b) B1 Correct composite key identified: ClassID + MemberID (accept + BookingDate if the reasoning allows for a member booking the same class twice)
(b) B1 Correctly identifies that ClassName, InstructorID, InstructorName and InstructorSpeciality all depend only on ClassID, not on the whole key (oe)
(b) B1 Correctly identifies that MemberName and MemberPhone depend only on MemberID, not on the whole key, as a second example of partial dependency (oe)
(b) Answer: Composite primary key: ClassID + MemberID. Partial dependencies: ClassName, InstructorID, InstructorName and InstructorSpeciality depend only on ClassID (not on MemberID too); MemberName and MemberPhone depend only on MemberID (not on ClassID too).
(c) B1 A Class table extracted, with ClassID as its key, holding ClassName, InstructorID, InstructorName, InstructorSpeciality
(c) B1 A Member table extracted, with MemberID as its key, holding MemberName, MemberPhone
(c) B1 A Booking table retained, with the composite key ClassID + MemberID (plus BookingDate as needed), holding only BookingDate and Attended
(c) B1 All original data is still represented across the three tables with no column lost, and the tables correctly link back to each other via ClassID/MemberID (oe)
(c) Answer: Class(ClassID [PK], ClassName, InstructorID, InstructorName, InstructorSpeciality). Member(MemberID [PK], MemberName, MemberPhone). Booking(ClassID [FK], MemberID [FK], BookingDate, Attended), with ClassID + MemberID (+ BookingDate) as its key.
(d) B1 Correctly identifies that InstructorName and InstructorSpeciality depend on InstructorID, not directly on ClassID (i.e. ClassID -> InstructorID -> InstructorName/InstructorSpeciality is a transitive dependency)
(d) B1 Extracts a new Instructor table with InstructorID as its key, holding InstructorName and InstructorSpeciality
(d) B1 Reduces Class to ClassID [PK], ClassName, InstructorID [FK], with InstructorID now only a foreign key referencing Instructor
(d) B1 Member and Booking tables from part (c) are correctly carried forward unchanged, since neither contains a transitive dependency
(d) Answer: Transitive dependency: ClassID -> InstructorID -> InstructorName/InstructorSpeciality. 3NF tables: Instructor(InstructorID [PK], InstructorName, InstructorSpeciality); Class(ClassID [PK], ClassName, InstructorID [FK]); Member(MemberID [PK], MemberName, MemberPhone); Booking(ClassID [FK], MemberID [FK], BookingDate, Attended).
(e) B1 Valid advantage identified, e.g. eliminates the update anomaly from Question 7(c), since each instructor's speciality is now stored once, in one row of Instructor (oe)
(e) B1 Explanation linking the advantage to reduced redundancy, e.g. less data is duplicated overall, saving storage and avoiding the risk of the same fact being recorded inconsistently (oe)
(e) Answer: Each instructor's details are now stored exactly once, in a single row of the Instructor table, rather than being repeated in every ClassRegister row for that instructor; this removes the update anomaly from Question 7(c) and reduces overall data redundancy/storage.

Question 9

(a) M1 Correct INNER JOIN linking Member to Booking on Member.MemberID = Booking.MemberID
(a) M1 Correct second INNER JOIN linking Booking to FitnessClass on Booking.ClassID = FitnessClass.ClassID
(a) A1 Correct SELECT list: Member.FirstName, Member.LastName, FitnessClass.ClassName (or unambiguous unqualified equivalents)
(a) A1 Statement is fully well-formed overall, joining all three tables correctly with no missing/incorrect join condition
(a) Answer: SELECT Member.FirstName, Member.LastName, FitnessClass.ClassName FROM Member INNER JOIN Booking ON Member.MemberID = Booking.MemberID INNER JOIN FitnessClass ON Booking.ClassID = FitnessClass.ClassID;
(b) M1 Correct LEFT JOIN FROM Member ... Booking ON Member.MemberID = Booking.MemberID (Member must be the left/first table so unmatched members are kept)
(b) M1 Correct WHERE Booking.BookingID IS NULL (or another Booking column IS NULL) to isolate members with no matching booking row
(b) A1 Correct SELECT FirstName, LastName from Member
(b) A1 Statement fully well-formed, correctly combining the LEFT JOIN and the IS NULL filter
(b) Answer: SELECT Member.FirstName, Member.LastName FROM Member LEFT JOIN Booking ON Member.MemberID = Booking.MemberID WHERE Booking.BookingID IS NULL;
(c) B1 States that an INNER JOIN only returns rows where a match exists in both tables (oe)
(c) B1 Explains that members with no booking, by definition, have no matching Booking row, so an INNER JOIN would exclude them entirely from the result (oe)
(c) Answer: An INNER JOIN only keeps rows where both tables have a matching row. A member with no booking has no matching Booking row at all, so an INNER JOIN would exclude that member from the results completely, meaning the query could never list members with zero bookings.

Question 10

(a) M1 Correct SELECT InstructorID, COUNT(*) (or COUNT(ClassID)) FROM FitnessClass
(a) M1 Correct GROUP BY InstructorID
(a) A1 Correct HAVING COUNT(*) > 1 (must use HAVING, not WHERE, since it filters an aggregated value)
(a) A1 Statement fully well-formed with clauses in the correct order (SELECT ... FROM ... GROUP BY ... HAVING ...)
(a) Answer: SELECT InstructorID, COUNT(*) FROM FitnessClass GROUP BY InstructorID HAVING COUNT(*) > 1;
(b) M1 Correct inner subquery: (SELECT AVG(MaxCapacity) FROM FitnessClass)
(b) M1 Correct outer query structure: SELECT ClassName FROM FitnessClass WHERE MaxCapacity > (...)
(b) A1 Subquery correctly nested inside the WHERE comparison, with matching brackets and no comma/table-alias errors
(b) A1 Statement fully well-formed and would execute correctly as written
(b) Answer: SELECT ClassName FROM FitnessClass WHERE MaxCapacity > (SELECT AVG(MaxCapacity) FROM FitnessClass);

Question 11

(a) B1 Atomicity
(a) B1 Consistency
(a) B1 Isolation
(a) B1 Durability
(a) Answer: Atomicity, Consistency, Isolation, Durability.
(b) L1 (1-2): Basic, undeveloped reference to atomicity and/or isolation, with little or no link to the booking scenario.
(b) L2 (3-4): Clear explanation of both atomicity and isolation, each illustrated using the booking scenario, showing what could go wrong for the leisure centre if either property were missing.
(b) Answer: N/A - levels-marked extended response.