lOMoARcPSD|64109549
OCR H446 Topic Practice Topic Practice Papers - Mark Scheme
OCR A Level Computer Science H446
Topic Practice Papers - Mark Scheme
This mark scheme matches the six original topic practice papers in the bundle. Award equivalent credit for
clearly correct alternatives. SQL syntax may vary slightly between database systems.
Paper Topic Marks
H446-T1 Normalisation: 1NF and 2NF 40
H446-T2 SQL 40
H446-T3 HTML and Web Forms 35
H446-T4 Karnaugh Maps 35
H446-T5 Boolean Expressions and Logic 40
H446-T6 Object-Oriented Programming 40
Page 1
messages.downloaded_by
, lOMoARcPSD|64109549
OCR H446 Topic Practice Topic Practice Papers - Mark Scheme
H446-T1 Normalisation: 1NF and 2NF
Question 1
(a) [2] Primary key is a field or set of fields that uniquely identifies a record/row (1); it must not contain
duplicate values / should not be null (1).
(b) [1] BookingID is acceptable for the original unnormalised table because each visible booking row is
unique.
(c) [2] The table contains repeating groups / multiple values in one cell (SkillCodes and SkillNames) (1);
each field is not atomic / there are lists of skills for a single booking (1).
Question 2
(a) [4] Two separate B101 rows shown (1), common booking/student/tutor data repeated correctly (1), one
row contains SC1 and Scales (1), one row contains SC4 and Sight reading (1).
(b) [2] After 1NF, a booking can have more than one skill row (1); BookingID would repeat so it would not
uniquely identify one row (1).
(c) [2] BookingID + SkillCode as a composite primary key. Award 1 mark for each correct component.
Question 3
(a) [2] A table is in 1NF (1) and every non-key attribute depends on the whole of the composite key, not
only part of it (1).
(b) [2] Accept any two valid examples: StudentName, StudentEmail, LessonDate, TutorID, TutorName,
Instrument or Room depend on BookingID; SkillName depends on SkillCode.
(c) [3] TutorName is repeated across rows (1); if the tutor name changes, all repeated rows must be
updated (1); if some rows are missed, inconsistent data is stored (1).
Question 4
(a) [10] One suitable design: Student(StudentID PK, StudentName, StudentEmail); Tutor(TutorID PK,
TutorName); Booking(BookingID PK, StudentID, LessonDate, TutorID, Instrument, Room); Skill(SkillCode
PK, SkillName); BookingSkill(BookingID PK/FK, SkillCode PK/FK). Award marks for sensible tables (up to
4), correct attributes (up to 3), correct primary keys (up to 2), valid junction table for repeated skills (1).
(b) [3] StudentID in Booking references Student (1); TutorID in Booking references Tutor (1); BookingID
and SkillCode in BookingSkill reference Booking and Skill (1).
Question 5
(a) [2] Any two: reduces data redundancy, reduces update/insert/delete anomalies, improves consistency,
improves integrity.
(b) [2] A new Skill record can be inserted independently (1); it does not require a fake booking / no
repeated booking data is needed (1).
(c) [3] Data is split across more tables (1); queries may need joins (1); joins can make SQL longer or more
processing-intensive (1).
Page 2
messages.downloaded_by
OCR H446 Topic Practice Topic Practice Papers - Mark Scheme
OCR A Level Computer Science H446
Topic Practice Papers - Mark Scheme
This mark scheme matches the six original topic practice papers in the bundle. Award equivalent credit for
clearly correct alternatives. SQL syntax may vary slightly between database systems.
Paper Topic Marks
H446-T1 Normalisation: 1NF and 2NF 40
H446-T2 SQL 40
H446-T3 HTML and Web Forms 35
H446-T4 Karnaugh Maps 35
H446-T5 Boolean Expressions and Logic 40
H446-T6 Object-Oriented Programming 40
Page 1
messages.downloaded_by
, lOMoARcPSD|64109549
OCR H446 Topic Practice Topic Practice Papers - Mark Scheme
H446-T1 Normalisation: 1NF and 2NF
Question 1
(a) [2] Primary key is a field or set of fields that uniquely identifies a record/row (1); it must not contain
duplicate values / should not be null (1).
(b) [1] BookingID is acceptable for the original unnormalised table because each visible booking row is
unique.
(c) [2] The table contains repeating groups / multiple values in one cell (SkillCodes and SkillNames) (1);
each field is not atomic / there are lists of skills for a single booking (1).
Question 2
(a) [4] Two separate B101 rows shown (1), common booking/student/tutor data repeated correctly (1), one
row contains SC1 and Scales (1), one row contains SC4 and Sight reading (1).
(b) [2] After 1NF, a booking can have more than one skill row (1); BookingID would repeat so it would not
uniquely identify one row (1).
(c) [2] BookingID + SkillCode as a composite primary key. Award 1 mark for each correct component.
Question 3
(a) [2] A table is in 1NF (1) and every non-key attribute depends on the whole of the composite key, not
only part of it (1).
(b) [2] Accept any two valid examples: StudentName, StudentEmail, LessonDate, TutorID, TutorName,
Instrument or Room depend on BookingID; SkillName depends on SkillCode.
(c) [3] TutorName is repeated across rows (1); if the tutor name changes, all repeated rows must be
updated (1); if some rows are missed, inconsistent data is stored (1).
Question 4
(a) [10] One suitable design: Student(StudentID PK, StudentName, StudentEmail); Tutor(TutorID PK,
TutorName); Booking(BookingID PK, StudentID, LessonDate, TutorID, Instrument, Room); Skill(SkillCode
PK, SkillName); BookingSkill(BookingID PK/FK, SkillCode PK/FK). Award marks for sensible tables (up to
4), correct attributes (up to 3), correct primary keys (up to 2), valid junction table for repeated skills (1).
(b) [3] StudentID in Booking references Student (1); TutorID in Booking references Tutor (1); BookingID
and SkillCode in BookingSkill reference Booking and Skill (1).
Question 5
(a) [2] Any two: reduces data redundancy, reduces update/insert/delete anomalies, improves consistency,
improves integrity.
(b) [2] A new Skill record can be inserted independently (1); it does not require a fake booking / no
repeated booking data is needed (1).
(c) [3] Data is split across more tables (1); queries may need joins (1); joins can make SQL longer or more
processing-intensive (1).
Page 2
messages.downloaded_by
