MARKING SCHEME AS-LEVEL COMPUTER SCIENCE

DBMS ENTITY-RELATIONSHIP DIAGRAM

(1) (i) One mark for each correct relationship. [2]

STUDENT STUDENT-
QUALIFICATION
QUALIFICATION

(ii) One-to-many [1]

(iii) Two points from: [2]

• The primary key in the QUALIFICATION table is QualCode.

• The foreign key in the STUDENT-QUALIFICATION table is QualCode.
• The primary key of QUALIFICATION is also included in QualCode.

(2a) ONE mark for each correct relationship as shown.

[2]

3(a) Many-to-one

3(b)(i) A-NURSE(NurseID, FirstName, FamilyName, WardName)

3(b)(ii) • The primary key WardName in the A-WARD table

• links to the foreign key WardName in the A-NURSE table.

3(c)(i) Many-to-many relationship

3(c)(ii) B-WARD-NURSE(WardName, NurseID)

Both attributes (with no additions)

Joint primary key correctly underlined

3(c)(iii)
B-NURSE B-WARD

B-WARD-NURSE

Correct relationship between B-NURSE and B-WARD-NURSE

Correct relationship between B-WARD and B-WARD-NURSE
 4(a) Many-to-many relationship

4(b)(i)

Both entities correctly labelled

Correct relationship between SHOP and SHOP-SUPPLIER
Correct relationship between SUPPLIER and SHOP-SUPPLIER

4(b)(ii) Table Primary key Foreign keys(s) Explanation

(if any)
SHOP ShopID None

SUPPLIER SupplierID None

SHOP-SUPPLIER ShopID AND ShopID OR To create a link

SupplierID SupplierID with the SHOP or
SUPPLIER
(or both) table.

• SHOP has primary key ShopID and SUPPLIER has primary key
SupplierID
• SHOP-SUPPLIER has primary key ShopID + SupplierID
• Both SHOP and SUPPLIER show foreign key as ‘None’
• SHOP-SUPPLIER shows foreign key ShopID or SupplierID
• Explanation for SHOP-SUPPLIER foreign key describes ShopID or
SupplierID creating a link

4(b)(iii) Two from:

• The database user will frequently want to search on contact name
• The contact name attribute has been indexed
• It allows for a fast/faster search using contact name
5 (a) (i) The table/each student has a repeated group of attributes. // Each student has a number
of subjects.
(ii) StudentName, TutorGroup and Tutor would need to be repeated for each record.

(b)
Table: Student Table: StudentSubjectChoices
StudentName TutorGroup Tutor Student Subject Level Subject
Name Teacher
Tom 6 SAN Tom Physics A SAN
Joe 7 MEB Tom Chemistry A MEB
Samir 6 SAN Tom General Studies AS DIL
Joe Geography AS ROG
Joe French AS HEN
Samir Computer Science A VAR
Samir Chemistry A MEB
Samir Maths A COR
Samir General Studies A DIL

(c) (i) primary key...

- an attribute/combination of attributes
- chosen to ensure that the records in a table are unique // used to identify a record/tuple

(ii) StudentName + Subject (This is the only correct answer.)

(iii) - There is a one-to-many relationship. // Student is the ‘one side’ table –

StudentSubjectChoices is the ‘many side’ table.
- the primary key (attribute StudentName) in Student
- links to StudentName in the StudentSubjectChoices table
- (StudentName in the) StudentSubjectChoices table is the foreign key. //
StudentName is the foreign key that links the two tables.

(d) - there are non-key attributes ...

- SubjectTeacher ...
- dependent only on part of the primary key (i.e. Subject) // partial dependency

(e) - there are dependent non-key attributes // there are non-key dependencies
- TutorGroup is dependent on Tutor // Tutor is dependent on TutorGroup
3 a (BookingNumber, Hotel, HotelAddress, Rating, (Date, RoomType,
NumberOfRooms, RoomRate)). (3 for all non-repeating attributes, 2 for all
repeating OR 1 mark each for any non-repeating and any repeating).
b (Booking(BookingNumber, Hotel, HotelAddress, Rating)
RoomTypebooking(BookingNumber(fk), RoomType, Date, NumberOfRooms,
RoomRate) (1 for two sensible tables, 1 for primary keys, 1 for other
attributes).
c To convert to 2NF only the repeating group data has to be changed. The
second table definition changes to the following two:
RoomTypebooking(BookingNumber(fk), RoomType(fk), Date,
NumberOfRooms)
RoomType(RoomType, RoomRate)
In the RoomTypebooking table a composite primary key is needed in which
both attributes are foreign keys. Note that this design assumes that the
RoomRate is the same for all rooms of a given type. You might wish to
discuss how the database would be designed if this were not the case. (2
for keys, 1 for other attributes, 2 for explanation).
d HotelAddress is dependent on Hotel (1) which is not the primary key (1) so
the Booking table is not in 3NF.