COMP1350/6150 Group Project S1,

2025

Group ID: z_UG04-B

Group Members:

Student ID Student Full Name (as shown on iLearn)

49171682 Patrick Beed

48523968 Daniel Harvey

48861901 Constantinos Vidiniotis

49102656 Joshua Iliffe

1 of 17
Task 1 – Conceptual Design (45%)
Business Rules Based on Scenario :
1. Area Definition and Facilities: Each area must have a unique identifier (AreaID),
name, location, area size, and a list of facilities, with facilities stored in the
AreaFacilities entity (AreaID, Facility) to allow multiple facilities per area.
2. Experience Definition: Each experience must have a unique identifier (ExperienceID),
name, capacity, and exactly one associated experience type, as defined by the
Experience and ExperienceType entities.
3. Venue Containment: Each venue must be located in exactly one area (via AreaID)
and can house zero or more experiences, as indicated by the Contains (Area to Venue)
and Houses (Venue to Experience) relationships.
4. Experience Location Constraint: Each experience must be associated with either
one area directly or one venue (which is within an area), but not both, as implied by the
mutually exclusive relationships between Experience and Area or Venue.
5. Ticket Class Specification: Each ticket class must have a unique identifier
(TicketClassID), class name, description, and price, as stored in the TicketClass entity,
and can be associated with multiple purchases via the PurchaseTicketClass entity.
6. Member Details and Relationships: Each member must have a unique identifier
(MemberID), given name, surname, email address, date of birth, state, and country of
residence, and can receive updates and promotions, as linked via EventID and
PromotionID in the Member entity.
7. Member Purchases: Each member can have multiple purchase records in the
PurchasesHistory entity (MemberID, PurchaseID), with each purchase including a date,
points gained, and associated ticket classes via the PurchaseTicketClass entity.
8. Personnel Details and Supervision: Each personnel must have a unique identifier
(PersonnelID), given name, surname, mobile number, email address, and date of birth,
and may have one supervisor (another personnel via SupervisorPersonnelID), as
indicated by the self-referencing Supervisors relationship in the Personnel entity.
9. Role Allocation for Personnel: Each personnel can have multiple role allocations in
the RoleAllocation entity, linking one personnel to one role type (RoleTypeID,
description, pay rate) from RoleType and one seniority level (SeniorityLevelID, level
description, pay loading percentage) from SeniorityLevel, with no duplicate
combinations of role type and seniority level per personnel.
10.Rostering Personnel: Each roster entry in the Roster entity (DateOfRoster, start time,
duration) can have multiple assignments in the RosterAssignmentHistory entity
(DateOfRoster, HistoryID), linking personnel to experiences they support.
11.Maintenance Scheduling: Each maintenance schedule in the MaintenanceSchedule
entity must have a unique identifier (ScheduleID), be associated with one experience
(via ExperienceID), include a description of work, start date, end date, status, and be
overseen by one personnel (via PersonnelID).
12.Curated Recommendation Structure: Each curated recommendation in the
CuratedRecommendation entity must have a unique identifier (CuratedID), title,
description, recommended age group, thrill level, one starting experience, one ending
experience, and up to 10 in-between experiences in a specific sequence, managed via
the VisitExperience entity (CuratedID, Position, ExperienceID).

2 of 17
Additional Business Rule (Curated_Rating)

 Additional Business Rule: Members can submit ratings for experiences they have
visited, with each rating recorded in the Curated_Rating entity, including a rating score,
comment, and date, uniquely identified by the combination of MemberID and
ExperienceID.

Assumptions (7 Assumptions)

1. Experience-Venue-Area Relationship: Each experience is either directly associated

with one area or one venue within an area, but not both, as implied by the scenario’s
example (e.g., experiences in Tiki Hut are not directly in Bear’s Den area).
 Facilities Storage: The list of facilities for an area is assumed to be a multi-valued
attribute, normalized into the AreaFacilities entity (AreaID, Facility) to allow multiple
facilities per area.
 Purchase History Identification: The PurchasesHistory entity is uniquely identified
by MemberID and PurchaseID, assuming a member can make multiple purchases on
the same date, distinguished by a sequential PurchaseID.
 Roster Assignment Identification: Each roster assignment in the
RosterAssignmentHistory entity is uniquely identified by DateOfRoster and HistoryID,
assuming personnel assignments to experiences on the same date are distinguished by
a unique history identifier.
 Curated Visit Sequence Management: The sequence of up to 10 in-between
experiences in a curated recommendation is managed by the Position attribute in the
VisitExperience entity, with Position values ranging from 1 to 12 (start, up to 10 in-
between, end).
 Maintenance Oversight: Only authorized personnel can oversee maintenance
schedules, as implied by the assignment of a personnel as the point of contact in the
MaintenanceSchedule entity.
 Personnel Data Retention: Data for past employees is retained in the Personnel
entity to preserve historical records, such as role allocations and roster assignments.

3 of 17
ER Model in Crow’s Foot Notation :

4 of 17
Task 2 – Logical Design (45%)
Process Overview:
Step 1 Convert Strong Entity
- Area (AreaID(PK), Name, Location, Facilities, AreaSize)
- Member (MemberID(PK), GivenName, Surname, EmailAddress, DOB, State,
CountryOfResidence)
- Experience (ExperienceID(PK), Name, Capacity)
- MaintenanceSchedule (ScheduleID(PK), DescriptionOfWork, StartDate, EndDate,
Status, PointOfContactStaff)
- RoleType (RoleTypeID(PK), Description, PayLoad)
- Roster (DateOfRoster(PK), StartTime(hours), Duration(hours))
- TicketClasses (TicketClassID(PK), ClassName, Description, Price)
- Personnel (PersonnelID(PK), GivenName, Surname, MobileNum, EmailAddress, DOB)
- SeniorityLevel (SeniorityLevelID(PK), SeniorityLevel, LevelDescription, PayLoad)
- Promotion (PromotionID(PK), Description, StartDate, EndDate)
- CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup, ThrillLevel)
- Update (EventID (PK), Description, StartDate, EndDate)

Step 2 Convert Weak Entity

- PurchasesHistory (MemberID(PK, FK), PurchaseID (PK), Date, PointsGained,
TicketClass)
- RosterAssignmentHistory (DateOfRoster(PK, FK), HistoryID (PK) StartTime(hours),
Duration(hours))
- Venue (AreaID(PK, FK), VenueID(PK), Name, Location)
- ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name)

Step 3 Convert 1 to 1 Relationships

- ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name, TicketClassID(FK))

Step 4 Convert 1 to Many

- Area (AreaID(PK), Name, Location, Facilities, AreaSize, VenueID(FK))
- Experience (ExperienceID(PK), Name, Capacity, VenueID(FK))
- CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup, ThrillLevel,
ExperienceID(FK))
- PurchasesHistory (MemberID(PK, FK), PurchaseID(PK), Date, PointsGained,
TicketClassID(FK))
- CuratedRating (RatingID(PK), Rating, Comment, Date, MemberID(FK),
ExperienceID(FK))
- PurchasesHistory (MemberID(PK, FK), DateGained(PK), PointsGained,
TicketClassID(FK))
- Personnel (PersonnelID(PK), GivenName, Surname, MobileNum, EmailAddress, DOB,
ScheduleID(FK), SupervisorPersonnelID(FK))
- Member (MemberID(PK), GivenName, Surname, EmailAddress, DOB, State,
CountryOfResidence, PromotionID(FK))
- CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup, ThrillLevel,
ExperienceID(FK))

5 of 17
Step 5 Convert Many to Many
- PurchasesHistory (MemberID(PK, FK), PurchaseID(PK), Date, PointsGained)
- PurchaseTicketClass (MemberID(PK, FK), PurchaseID(PK, FK), TicketClassID(PK, FK))

Step 6 Convert Multi-valued Attributes

- AreaFacilities (AreaID(PK, FK), Facility(PK))

Step 7 Convert Associative Entities

- Curated_Rating (MemberID(PK, FK), ExperienceID(PK, FK), Rating, Comment, Date)
- VisitExperience (CuratedID(PK, FK), Position(PK), ExperienceID(FK))
- RoleAllocation (PersonnelID(PK, FK), RoleTypeID(PK, FK), SeniorityLevelID(PK, FK))

Final Table List :

1) Area (AreaID(PK), Name, Location, AreaSize, VenueID(FK))

2) AreaFacilities (AreaID(PK, FK), Facility(PK))
3) CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup, ThrillLevel,
ExperienceID(FK), StartExperienceID(FK), EndExperienceID(FK))
4) Curated_Rating (MemberID(PK, FK), ExperienceID(PK, FK), Rating, Comment, Date)
5) Experience (ExperienceID(PK), Name, Capacity, VenueID(FK))
6) ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name, TicketClassID(FK))
7) MaintenanceSchedule (ScheduleID(PK), DescriptionOfWork, StartDate, EndDate,
Status, PersonnelID(FK), ExperienceID(FK))
8) Member (MemberID(PK), GivenName, Surname, EmailAddress, DOB, State,
CountryOfResidence, PromotionID(FK), EventID(FK))
9) Personnel (PersonnelID(PK), GivenName, Surname, MobileNum, EmailAddress, DOB,
ScheduleID(FK), SupervisorPersonnelID(FK))
10) Promotion (PromotionID(PK), Description, StartDate, EndDate)
11) PurchasesHistory (MemberID(PK, FK), PurchaseID(PK), Date, PointsGained)
12) PurchaseTicketClass (MemberID(PK, FK), PurchaseID(PK, FK),
TicketClassID(PK, FK))
13) RoleAllocation (PersonnelID(PK, FK), RoleTypeID(PK, FK), SeniorityLevelID(PK,
FK))
14) RoleType (RoleTypeID(PK), Description, PayLoad)
15) Roster (DateOfRoster(PK), StartTime(hours), Duration(hours))
16) RosterAssignmentHistory (DateOfRoster(PK, FK), HistoryID(PK),
PersonnelID(FK))
17) SeniorityLevel (SeniorityLevelID(PK), SeniorityLevel, LevelDescription,
PayLoad)
18) TicketClass (TicketClassID(PK), Description, ClassName, Price)
19) Update (EventID(PK), Description, StartDate, EndDate)
20) Venue (AreaID(PK, FK), VenueID(PK), Name, Location)
21) VisitExperience (CuratedID(PK, FK), Position(PK), ExperienceID(FK))

6 of 17
Step-by-Step Process for Logical Transformation
Step 1: Identify Strong Entities

Objective: List tables for all strong entities, including all simple attributes and
marking the primary key as "PK." Exclude multi-valued attributes at this stage.

Process: Strong entities exist independently and have a unique primary identifier. I’ll
identify these from the ERD in Attachment 4 and create initial tables with simple
attributes only.

 Area
o Attributes: AreaID (PK), Name, Location, Facilities, AreaSize
o Table: Area (AreaID(PK), Name, Location, Facilities, AreaSize)
 Member
o Attributes: MemberID (PK), GivenName, Surname, EmailAddress, DOB,
State, CountryOfResidence, PurchaseHistory
o Note: PurchaseHistory is likely multi-valued (implied by its context as a
history of purchases), so it’s excluded here.
o Table: Member (MemberID(PK), GivenName, Surname, EmailAddress, DOB,
State, CountryOfResidence)
 Experience
o Attributes: ExperienceID (PK), Name, Capacity
o Table: Experience (ExperienceID(PK), Name, Capacity)
 MaintenanceSchedule
o Attributes: ScheduleID (PK), DescriptionOfWork, StartDate, EndDate,
Status, PointOfContactStaff
o Table: MaintenanceSchedule (ScheduleID(PK), DescriptionOfWork,
StartDate, EndDate, Status, PointOfContactStaff)
 RoleType
o Attributes: RoleTypeID (PK), Description, PayLoad
o Note: PayLoad(%) is simplified to PayLoad for consistency.
o Table: RoleType (RoleTypeID(PK), Description, PayLoad)
 Roster
o Attributes: DateOfRoster (PK), StartTime(hours), Duration(hours)
o Note: StartTime and Duration include "hours" in the ERD, which I retain for
clarity.
o Table: Roster (DateOfRoster(PK), StartTime(hours), Duration(hours))
 TicketClasses
o Attributes: TicketClassID (PK), ClassName, Description, Price
o Table: TicketClasses (TicketClassID(PK), ClassName, Description, Price)
 Personnel
o Attributes: PersonnelID (PK), GivenName, Surname, MobileNum,
EmailAddress, DOB
o Table: Personnel (PersonnelID(PK), GivenName, Surname, MobileNum,
EmailAddress, DOB)

7 of 17
  SeniorityLevel
o Attributes: SeniorityLevelID (PK), SeniorityLevel, LevelDescription, PayLoad
o Table: SeniorityLevel (SeniorityLevelID(PK), SeniorityLevel,
LevelDescription, PayLoad)
 Promotion
o Attributes: PromotionID (PK), Description, StartDate, EndDate
o Table: Promotion (PromotionID(PK), Description, StartDate, EndDate)
 CuratedRecommendation
o Attributes: CuratedID (PK), Title, Description, AgeGroup, ThrillLevel
o Table: CuratedRecommendation (CuratedID(PK), Title, Description,
AgeGroup, ThrillLevel)
 Updates
o Attributes: EventID (PI), Description, StartDate, EndDate
o Table: Update (EventID (PK), Description, StartDate, EndDate)
Tables After Step 1:

1. Area (AreaID(PK), Name, Location, Facilities, AreaSize)

2. Member (MemberID(PK), GivenName, Surname, EmailAddress, DOB, State,
CountryOfResidence)
3. Experience (ExperienceID(PK), Name, Capacity)
4. MaintenanceSchedule (ScheduleID(PK), DescriptionOfWork, StartDate,
EndDate, Status, PointOfContactStaff)
5. RoleType (RoleTypeID(PK), Description, PayLoad)
6. Roster (DateOfRoster(PK), StartTime(hours), Duration(hours))
7. TicketClass (TicketClassID(PK), Description, ClassName, Price)
8. Personnel (PersonnelID(PK), GivenName, Surname, MobileNum, EmailAddress,
DOB)
9. SeniorityLevel (SeniorityLevelID(PK), SeniorityLevel, LevelDescription,
PayLoad)
10. Promotion (PromotionID(PK), Description, StartDate, EndDate)
11. CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup,
ThrillLevel)
12. Update (EventID (PK), Description, StartDate, EndDate)

Step 2: Weak Entities

Objective: Create tables for weak entities, where the primary key is a composite of
the owner’s primary key (as a foreign key, FK) and the weak entity’s main attribute.

Process: Weak entities depend on a strong entity (owner) and lack a standalone
unique identifier. Their primary key combines the owner’s PK with a partial key.

 PurchasesHistory
o Owner: Member (PK: MemberID)
o Attributes: PurchaseID, Date, PointsGained, TicketClass
o Partial Key: PurchaseID

8 of 17
 o Table: PurchasesHistory (MemberID(PK, FK), PurchaseID (PK), Date,
PointsGained, TicketClass)
 RosterAssignmentHistory
o Owner: Roster (PK: DateOfRoster)
o Attributes: HistoryID, DateOfRoster, StartTime(hours), Duration(hours)
o Note: The ERD lists DateOfRoster as an attribute, which overlaps with the
owner’s PK.
o Table: RosterAssignmentHistory (DateOfRoster(PK, FK), HistoryID (PK)
StartTime(hours), Duration(hours))
 Venue (Weak Entity):
o Owner: Area (PK: AreaID).
o Attributes: VenueID(PI), Name, Location.
o Note: As a weak entity, Venue’s primary key must include the owner’s PK
(AreaID). VenueID serves as the partial key to ensure uniqueness within
each Area. The "Contains" relationship is now identifying (solid line),
reflecting Venue’s dependency on Area. The "Houses" relationship (1:N)
will add VenueID as a foreign key to Experience in Step 4.
o Table: Venue (AreaID(PK, FK), VenueID(PK), Name, Location).
 ExperienceType (Weak Entity):
o Owner: Experience (PK: ExperienceID).
o Attributes: TypeID(PI), Name.
o Note: As a weak entity, ExperienceType’s primary key must include the
owner’s PK (ExperienceID). TypeID serves as the partial key to ensure
uniqueness within each Experience.
o Table: ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name).
Tables After Step 2 (adding new tables):

 Existing strong entity tables from Step 1 remain unchanged.

 New tables:
o PurchasesHistory (MemberID(PK, FK), PurchaseID (PK), Date, PointsGained,
TicketClass)
o RosterAssignmentHistory (DateOfRoster(PK, FK), HistoryID (PK)
StartTime(hours), Duration(hours))
o Venue (AreaID(PK, FK), VenueID(PK), Name, Location).
o ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name).

Step 3: One-to-One Relationships

Objective: For each 1:1 relationship, add the primary key of one entity (usually the
mandatory side) as a foreign key in the other entity’s table.

 Relationship: TicketClass and ExperienceType

o ER Diagram Analysis: The ER diagram shows a "Classifies" relationship
between TicketClass (strong entity) and ExperienceType (weak entity
dependent on Experience) with a single line and no explicit "N" cardinality,
supporting the query's specification of a 1:1 relationship. This implies
9 of 17
 each TicketClass is associated with exactly one ExperienceType, and vice
versa.
o Decision: In a 1:1 relationship, the primary key of one entity is added as a
foreign key to the other. Since ExperienceType is a weak entity
(dependent on Experience with ExperienceID as part of its PK), it is logical
to add TicketClassID (PK of TicketClass) as a foreign key to
ExperienceType. This reflects that each ExperienceType is uniquely tied to
a TicketClass, and the dependency structure is maintained.
 Updated Table:
o ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name,
TicketClassID(FK))
 Explanation:
o TicketClass remains unchanged: TicketClasses (TicketClassID(PK),
ClassName, Description, Price).
o ExperienceType already includes ExperienceID (FK from Experience) as
part of its composite PK with TypeID. Adding TicketClassID(FK) enforces
the 1:1 relationship without altering its weak entity status.
Tables after step 3:

 ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name,

TicketClassID(FK))

Step 4: One-to-Many Relationships

Objective: Include the primary key of the "1" side as a foreign key in the "N" side of
the relationship.

Process: Identify 1:N relationships (single line with an arrow or context suggesting
one-to-many). Add the PK from the "1" side to the "N" side table.

 Contains (Venue to Area)

o Venue (1) contains many Areas (N).
o Action: Add VenueID to Area.
o Updated Table: Area (AreaID(PK), Name, Location, Facilities, AreaSize,
VenueID(FK))
 Houses (Venue to Experience)
o Venue (1) houses many Experiences (N).
o Action: Add VenueID to Experience.
o Updated Table: Experience (ExperienceID(PK), Name, Capacity,
VenueID(FK))
 Informs (Member to Updates)
 Relationship: CuratedRecommendation (N) to Experience (1)
 Action: Add ExperienceID (PK of Experience) as a foreign key to
CuratedRecommendation (the "N" side).
 Updated Table: CuratedRecommendation (CuratedID(PK), Title, Description,
AgeGroup, ThrillLevel, ExperienceID(FK))

10 of 17
 Explanation: Each CuratedRecommendation is now linked to a single Experience
via ExperienceID(FK), reflecting that many curated recommendations can
support one experience. This reverses the previous transformation where
CuratedID was added to Experience.

 Records (Member to PurchasesHistory)

o Member (1) records many PurchasesHistories (N).
o Action: Already handled in Step 2 (MemberID as PK, FK in
PurchasesHistory).
o Updated table: PurchasesHistory (MemberID(PK, FK), PurchaseID(PK),
Date, PointsGained, TicketClassID(FK))
 Submits (Member to CuratedRating)
o Member (1) submits many CuratedRatings (N).
o Action: Already handled in Step 2 (MemberID as PK, FK in CuratedRating).
o Updated Table: CuratedRating (RatingID(PK), Rating, Comment, Date,
MemberID(FK), ExperienceID(FK))
 References (TicketClasses to PurchasesHistory)
o TicketClasses (1) referenced by many PurchasesHistories (N).
o Action: Add TicketClassID to PurchasesHistory (replacing TicketClass
attribute for normalization).
o Updated Table: PurchasesHistory (MemberID(PK, FK), DateGained(PK),
PointsGained, TicketClassID(FK))
 Oversees (MaintenanceSchedule to Personnel)
o MaintenanceSchedule (1) oversees many Personnel (N).
o Action: Add MaintenanceID to Personnel.
o Updated Table: Personnel (PersonnelID(PK), GivenName, Surname,
MobileNum, EmailAddress, DOB, ScheduleID(FK))
 Supervises (Personnel to Personnel) – So is SupervisorPersonnelID the
same as PersonnelID?
· Instruction: "Personnel (1) supervises many Personnel (N, self-referencing).
Action: Add SupervisorPersonnelID to Personnel."
· ER Diagram Analysis: The ERD shows a "Supervisors" self-referencing
relationship within Personnel, with a crow’s foot indicating Personnel (1)
supervises many Personnel (N).
· Action: Add SupervisorPersonnelID (FK referencing PersonnelID) to
Personnel.
· Updated Table:
o Personnel (PersonnelID(PK), GivenName, Surname, MobileNum,
EmailAddress, DOB, ScheduleID(FK), SupervisorPersonnelID(FK))
· Explanation: This self-referencing foreign key models a hierarchical
supervision structure within Personnel.
 Sends (Promotion to Member)
o Promotion (1) sends to many Members (N).
o Action: Add PromotionID to Member.

11 of 17
 o Updated Table: Member (MemberID(PK), GivenName, Surname,
EmailAddress, DOB, State, CountryOfResidence, PromotionID(FK))
 Supports (CuratedRecommendation to Experience)
 Relationship: CuratedRecommendation (N) to Experience (1)
 Action: Add ExperienceID (PK of Experience) as a foreign key to
CuratedRecommendation (the "N" side).
 Updated Table: CuratedRecommendation (CuratedID(PK), Title, Description,
AgeGroup, ThrillLevel, ExperienceID(FK))
 Explanation: Each CuratedRecommendation is now linked to a single Experience
via ExperienceID(FK), reflecting that many curated recommendations can
support one experience. This reverses the previous transformation where
CuratedID was added to Experience.

 Tables After Step 4 (updated tables):

o Area (AreaID(PK), Name, Location, Facilities, AreaSize, VenueID(FK))
o Experience (ExperienceID(PK), Name, Capacity, VenueID(FK))
o CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup,
ThrillLevel, ExperienceID(FK))
o PurchasesHistory (MemberID(PK, FK), PurchaseID(PK), Date, PointsGained,
TicketClassID(FK))
o CuratedRating (RatingID(PK), Rating, Comment, Date, MemberID(FK),
ExperienceID(FK))
o PurchasesHistory (MemberID(PK, FK), DateGained(PK), PointsGained,
TicketClassID(FK))
o Personnel (PersonnelID(PK), GivenName, Surname, MobileNum,
EmailAddress, DOB, ScheduleID(FK))
o Personnel (PersonnelID(PK), GivenName, Surname, MobileNum,
EmailAddress, DOB, ScheduleID(FK), SupervisorPersonnelID(FK))
o Member (MemberID(PK), GivenName, Surname, EmailAddress, DOB, State,
CountryOfResidence, PromotionID(FK))
o CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup,
ThrillLevel, ExperienceID(FK))

Step 5: Many-to-Many Relationships

Objective: Create a new associative table for each M:N relationship, with a composite
primary key from the two entities’ primary keys, including any relationship attributes.

Process: Identify M:N relationships (typically shown with double lines or context
suggesting many-to-many). Create new tables accordingly.
 References (PurchasesHistory to TicketClass)
o Relationship: PurchasesHistory (M) to TicketClass (N) (adjusted from one-to-
many to many-to-many, as a single purchase can involve multiple ticket classes,
and a ticket class can be part of multiple purchases).

12 of 17
 o Action: Create a new associative table PurchaseTicketClass with a composite
primary key from PurchasesHistory (MemberID, PurchaseID) and TicketClass
(TicketClassID).
o New Table: PurchaseTicketClass (MemberID(PK, FK), PurchaseID(PK, FK),
TicketClassID(PK, FK))
 Explanation: This table links PurchasesHistory and TicketClass, allowing a single
purchase to include multiple ticket classes and a ticket class to be part of multiple
purchases.
 Update to PurchasesHistory (Removing TicketClass Attribute)
o Reason for Removal: The TicketClass attribute (previously replaced by
TicketClassID(FK) in Step 4) in PurchasesHistory is removed because the many-
to-many relationship is now handled by the PurchaseTicketClass table. Including
TicketClassID directly in PurchasesHistory would imply a one-to-many
relationship, which is no longer accurate.
 Updated Table: PurchasesHistory (MemberID(PK, FK), PurchaseID(PK), Date,
PointsGained)
 Explanation: The direct reference to TicketClass is removed from PurchasesHistory to
avoid redundancy and maintain normalization, as the relationship is now managed
through the associative table.
 Tables After Step 5 (Updated/New Tables):
 PurchasesHistory (MemberID(PK, FK), PurchaseID(PK), Date, PointsGained) –updated by
removing tickerclassID (FK) as it is redundant through the many-to-many relationship
table.
 PurchaseTicketClass (MemberID(PK, FK), PurchaseID(PK, FK), TicketClassID(PK, FK))

Step 6: Multi-valued Attributes

Objective: Create a new table for each multi-valued attribute, including the attribute
and the entity’s primary key.

Process: Identify multi-valued attributes (marked with {…} or implied by context). No

explicit notation exists in the ERD, but PurchaseHistory is inferred as multi-valued.

Area

 Attributes: AreaID(PK), Name, Location, Facilities, AreaSize

 Potential Multi-Valued Attribute: Facilities
o The scenario states: "Each area has a unique identifier, a name, a
location, a list of facilities available, and the area size." The term "list
of facilities" implies that an Area can have multiple facilities (e.g.,
restrooms, benches, water fountains).
o In the ERD, Facilities is listed as a single attribute, but its multi-valued
nature is implied by "list."
o Normalization: Create a new table for AreaFacilities to store multiple
facilities per area:
 AreaFacilities (AreaID(PK, FK), Facility(PK))
 AreaID(FK) links to Area, and Facility stores each facility name.
Tables After Step 6:

13 of 17
AreaFacilities (AreaID(PK, FK), Facility(PK))

Step 7: Associative Entities

Objective: Handle associative entities (especially n-ary relationships), with a

composite primary key from participating entities on the "many" side.

Process: Identify entities that represent relationships (often from M:N or ternary
relationships) and ensure proper key structure.

Curated_Rating (Associative Entity):

 Related Entities: Member (PK: MemberID), Experience (PK: ExperienceID).

 Attributes: Rating, Comment, Date, MemberID, ExperienceID.
 Note: As an associative entity, Curated_Rating links Member and Experience to
record ratings. Its primary key is a composite of the related entities’ primary
keys (MemberID, ExperienceID). The "Receives" and "Subject" relationships are
non-identifying (dashed lines), which is typical for AEs. The attributes MemberID
and ExperienceID in the ERD are redundant (implied by the relationships) and
should be removed from the ERD, but they’ll be added as foreign keys in the
table.
 Table: Curated_Rating (MemberID(PK, FK), ExperienceID(PK, FK), Rating,
Comment, Date).
VisitExperience (Associative Entity):

 Related Entities: CuratedRecommendation (PK: CuratedID), Experience (PK:

ExperienceID).
 Attributes: VisitID, Position, ExperienceID.
 Note: VisitExperience links CuratedRecommendation and Experience to define
the sequence of experiences in a curated visit. The scenario states that a
curated recommendation includes a starting point, ending point, and up to 10
experiences in between, suggesting Position as an attribute to order the
experiences. The primary key should include CuratedID and a partial key to
ensure uniqueness within each CuratedRecommendation. VisitID is listed as a PI,
but Position can serve as the partial key (e.g., positions 1 to 12 for start, end,
and up to 10 in-between). ExperienceID is redundant in the ERD (implied by the
"Includes" relationship) and should be removed from the ERD attributes. The
primary key will be CuratedID and Position.
 Table: VisitExperience (CuratedID(PK, FK), Position(PK), ExperienceID(FK))
RoleAllocation (Associative Entity):

 Related Entities: Personnel (PK: PersonnelID), RoleType (PK: RoleTypeID),

SeniorityLevel (PK: SeniorityLevelID).
 Attributes: PersonnelID, RoleTypeID, SeniorityLevelID.
 Note: RoleAllocation links Personnel, RoleType, and SeniorityLevel to define
personnel role allocations. The scenario states, "Personnel can have different
role allocations... but no personnel should have duplicates of the same role type
and seniority level," so the primary key must include all three keys (PersonnelID,
14 of 17
 RoleTypeID, SeniorityLevelID) to enforce uniqueness. We previously removed the
redundant SeniorityLevel attribute.
 Table: RoleAllocation (PersonnelID(PK, FK), RoleTypeID(PK, FK),
SeniorityLevelID(PK, FK)).

Tables After Step 7 (replacing/adjusting):

 Curated_Rating (MemberID(PK, FK), ExperienceID(PK, FK), Rating, Comment,

Date).
 Table: VisitExperience (CuratedID(PK, FK), Position(PK), ExperienceID(FK))
 RoleAllocation (PersonnelID(PK, FK), RoleTypeID(PK, FK), SeniorityLevelID(PK,
FK)).

Final Table List

Objective: Combine all tables, using the most updated versions, and remove
duplicates by going bottom-up.

Process: Collect all tables from Steps 1–7, ensuring each reflects modifications (e.g.,
foreign keys added in Steps 3–4). Eliminate duplicates by retaining the latest version.

1. RoleAllocation (PersonnelID(PK, FK), RoleTypeID(PK, FK), SeniorityLevelID(PK,

FK))
2. VisitExperience (CuratedID(PK, FK), Position(PK), ExperienceID(FK))
3. Curated_Rating (MemberID(PK, FK), ExperienceID(PK, FK), Rating, Comment,
Date)
4. AreaFacilities (AreaID(PK, FK), Facility(PK))
5. ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name, TicketClassID(FK))
6. Venue (AreaID(PK, FK), VenueID(PK), Name, Location)
7. RosterAssignmentHistory (DateOfRoster(PK, FK), HistoryID(PK),
PersonnelID(FK))
8. PurchasesHistory (MemberID(PK, FK), PurchaseID(PK), Date, PointsGained)
9. Update (EventID(PK), Description, StartDate, EndDate)
10. CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup,
ThrillLevel, ExperienceID(FK), StartExperienceID(FK), EndExperienceID(FK))
11. Promotion (PromotionID(PK), Description, StartDate, EndDate)
12. SeniorityLevel (SeniorityLevelID(PK), SeniorityLevel, LevelDescription,
PayLoad)
13. Personnel (PersonnelID(PK), GivenName, Surname, MobileNum,
EmailAddress, DOB, ScheduleID(FK), SupervisorPersonnelID(FK))
14. TicketClass (TicketClassID(PK), Description, ClassName, Price)
15. Roster (DateOfRoster(PK), StartTime(hours), Duration(hours))
16. RoleType (RoleTypeID(PK), Description, PayLoad)
17. MaintenanceSchedule (ScheduleID(PK), DescriptionOfWork, StartDate,
EndDate, Status, PersonnelID(FK), ExperienceID(FK))

15 of 17
 18. Experience (ExperienceID(PK), Name, Capacity, VenueID(FK))
19. Member (MemberID(PK), GivenName, Surname, EmailAddress, DOB, State,
CountryOfResidence, PromotionID(FK), EventID(FK))
20. Area (AreaID(PK), Name, Location, AreaSize, VenueID(FK))
21. PurchaseTicketClass (MemberID(PK, FK), PurchaseID(PK, FK),
TicketClassID(PK, FK))

In Alphabetical order:

1. Area (AreaID(PK), Name, Location, AreaSize, VenueID(FK))

2. AreaFacilities (AreaID(PK, FK), Facility(PK))
3. CuratedRecommendation (CuratedID(PK), Title, Description, AgeGroup, ThrillLevel,
ExperienceID(FK), StartExperienceID(FK), EndExperienceID(FK))
4. Curated_Rating (MemberID(PK, FK), ExperienceID(PK, FK), Rating, Comment, Date)
5. Experience (ExperienceID(PK), Name, Capacity, VenueID(FK))
6. ExperienceType (ExperienceID(PK, FK), TypeID(PK), Name, TicketClassID(FK))
7. MaintenanceSchedule (ScheduleID(PK), DescriptionOfWork, StartDate, EndDate, Status,
PersonnelID(FK), ExperienceID(FK))
8. Member (MemberID(PK), GivenName, Surname, EmailAddress, DOB, State,
CountryOfResidence, PromotionID(FK), EventID(FK))
9. Personnel (PersonnelID(PK), GivenName, Surname, MobileNum, EmailAddress, DOB,
ScheduleID(FK), SupervisorPersonnelID(FK))
10.Promotion (PromotionID(PK), Description, StartDate, EndDate)
11.PurchasesHistory (MemberID(PK, FK), PurchaseID(PK), Date, PointsGained)
12.PurchaseTicketClass (MemberID(PK, FK), PurchaseID(PK, FK), TicketClassID(PK, FK))
13.RoleAllocation (PersonnelID(PK, FK), RoleTypeID(PK, FK), SeniorityLevelID(PK, FK))
14.RoleType (RoleTypeID(PK), Description, PayLoad)
15.Roster (DateOfRoster(PK), StartTime(hours), Duration(hours))
16.RosterAssignmentHistory (DateOfRoster(PK, FK), HistoryID(PK), PersonnelID(FK))
17.SeniorityLevel (SeniorityLevelID(PK), SeniorityLevel, LevelDescription, PayLoad)
18.TicketClass (TicketClassID(PK), Description, ClassName, Price)
19.Update (EventID(PK), Description, StartDate, EndDate)
20.Venue (AreaID(PK, FK), VenueID(PK), Name, Location)
21.VisitExperience (CuratedID(PK, FK), Position(PK), ExperienceID(FK))

16 of 17
Task 3 – Physical Design (10%)

17 of 17