Grading criteria

Rubric

Task 1 - Scenario A genuine attempt has been At least have 10 correct

business rules and made to write at least 10 and well-written business
assumptions business rules and at least 8 rules.
of them is correct and well-
7 points
written.

5.5 points

Task 1 - ERD entities Most entities identified All entities are identified
correctly, but a few of them correctly (may have one
are incorrect/missing. minor problem at most),
but nothing is missing.
5.5 points
7 points

Task 1 - ERD Most of the attributes are Nearly (or all) relevant
attributes correctly identified and well- attributes are correctly
suited to their corresponding identified and well-suited
types and entities. to their types and
corresponding entities.
4 points
5 points

Task 1 - ERD Most relationships are Nearly (all) relationships

relationships correctly placed between are clear, well-defined,
entities with minor issues and accurately represent
that cannot be overlooked. the connections between
entities.
5.5 points
7 points

Task 1 - ERD Most cardinalities are The cardinalities are

Cardinalities correctly identified, with accurately defined for
some minor mistakes. No nearly (all) relationships,
missing cardinalities clearly representing the
anywhere in the diagram, nature of each
but there are some errors connection.
that cannot be ignored.
5 points
4 points
Task 1 - ERD No missing constraints The constraints are
Constraints anywhere in the diagram, accurately defined for
but there are some errors nearly (all) relationships,
that cannot be ignored. clearly representing the
nature of each
4 points
connection.

5 points

Task 1 - ERD layout The diagram is well The diagram is well-

formatted. Only relationship structured, clear, and
lines crossing each other easy to follow, reflecting
that cannot be avoided still a solid understanding of
exist. The entities have been the design principles. All
grouped logically. Most entity entity and attribute
and attribute names are names are consistent.
consistent.
4 points
3 points

Task 1 - Additional Any additional business rule Any additional business

business rule(s) and is sound. All entities and rule is sound and
ERD relationships have been improve the functionality
added correctly in the of the database. All
diagram with relevant entities and relationships
attributes. May have minor have been added
issues. correctly in the diagram
with relevant attributes.
4 points
5 points

Task 2 - Steps 1-2 Nearly all entities have been All (nearly all) entities
(including any transformed correctly, with have been accurately
repeats, if only a few minor issues. transformed with no
applicable) Errors in the diagram have errors.
been forwarded to this stage
12 points
and cannot be overlooked.

10 points

Task 2 - Steps 3-5 Nearly all relationships have All (nearly all)
(including any been transformed correctly, relationships have been
repeats, if with only a few minor issues. accurately transformed
applicable) Errors in the diagram have with no errors.
been forwarded to this stage
12 points
and cannot be overlooked.
 10 points

Task 2 - Steps 6-7 Nearly all of the All transformations have

(including any transformations are correct, been accurately
repeats, if with only a few minor issues. completed with no errors.
applicable) Errors in the diagram have
11 points
been forwarded to this stage
and cannot be overlooked.

9 points

Task 2 - Final table The final list is nearly The final list of tables
list correct, with only a few with PKs and FKs is
minor issues in identifying complete and accurate.
PKs and FKs. Errors in the
5 points
diagram have been
forwarded to this stage and
cannot be overlooked.

4 points

Task 3 - Keys All PKs and most FKs from All PKs and FKs from the
the final table list are final table list are
correctly depicted. correctly depicted.

4 points 5 points

Task 3 - Data types All attributes have been All (or nearly all) data
assigned a data type and types chosen for the
most are reasonable. attributes are reasonable.

4 points 5 points

Task 3 - Data length All text and numeric All (or nearly all) data
attributes have been lengths (where
assigned data lengths that applicable) chosen for the
are mostly reasonable. attributes are reasonable
and not wasteful.
4 points
5 points

Marks Breakdown
Total mark: 100
Weight: 30%

Breakdown

 Task 1 (45 marks)

o Scenario business rules and assumptions (7 marks)

o ERD entities (7 marks)

o ERD attributes (5 marks)

o ERD relationships (7 marks)

o ERD Cardinality (5 marks)

o ERD Constraints (5 marks)

o ERD layout (4 marks)

o Additional business rule(s) with the corresponding entity(ies) and

relationship(s) (5 marks)

 Task 2 (40 marks)

o Steps 1-2 (12 marks)

o Steps 3-5 (12 marks)

o Steps 6-7 (11 marks)

o Final table list (5 marks)

 Task 3 (15 marks)

o Keys and relationships (5 marks)

o Data types (5 marks)

o Data length (5 marks)

Overview
Learning Outcomes

LO aspects related to the assessment are in bold)

 ULO1: Analyse data requirements and design and develop

conceptual database models.

 ULO2: Implement system models into databases, design and create

simple databases for business information systems and write programs to
produce interactive queries.
  ULO3: Use data analysis and data modelling techniques and tools
for introductory level database design and specification

You are expected to work on this assignment as a group of 3-4 members from the
same practical class. The assignment is designed to be worked in a group of 2-3
members, which means even if you lose group members, you would be able to
complete it with the remaining team members. You will be required to be in a
group by week 3. Otherwise, we will assign you randomly to a group.

Task 1 – Conceptual Design (45%)

Based on the given scenario, identify and write the business rules (min.
10) and assumptions (if any), then construct an ER diagram using Crow’s
Foot notation. The ER diagram should include entities, attributes, and
identifiers. Each relationship should note either identifying or non-identifying
relationship and have a name, a constraint and a cardinality. You may choose to
add attributes to the relationships (if there are any) or create an associative
entity, when necessary.

Once you have completed this task, formulate ONE plausible new business
rule that is relevant to the current database, which then will require an
extension to the current model by adding at least one new entity with
at least one new relationship to an existing entity. Ensure that any
additional entities are using a different colour to the original entities.

Task 2 – Logical Design (40%)

Based on your ER diagram from Task 1, perform a logical transformation. You

must include a step-by-step transformation and the final list of tables
with primary and foreign keys denoted with (PK) and (FK). Please note
that if there are errors in the ER diagram, this may impact your marks in the
transformation. However, the correctness of the process will be considered.

Task 3 – Physical Design (15%)

Based on your final list table from Task 2, create the physical design. For each
table, include the table name and field names, whether it is a key (PK/FK),
and the data type (MySQL compatible) with the appropriate length, where
applicable.

Expected Time Spent

27 hours per student (weeks 3-7)

 2 hours across the practical classes (e.g. there may be some time that the
groups can spend within the class time over the next few weeks)

o If you miss a practical class, then you will need to make up for it
outside of class

 25 hours per student outside of class time

Scenario - Jellystone Theme Park
Background
Jellystone Theme Park is a place where people can come and enjoy various
experiences (rides, shows, food, and so on). Over the years, the ticketing
process has been a manual process without things really being stored in any
kind of information system (other than a bunch of logbooks, whiteboards of
rosters, “suggested experiences to do in a day” pamphlets, or manually
punched tickets).

The operators of the theme park would like to move to a computer-based

system to allow the ticketing for different aspects of the park to be tracked
and stored through a database system. Below is a bit of a description of the
kinds of things the operators would like to be able to track in the new system.

Your mission is to take the scenario business needs (below) and do a

conceptual design of the system, transform that completed conceptual
design into a logical design, and then convert it to a physical design targeting
MySQL-compatible data types.

Scenario and Business Needs

The theme park has many areas where the experiences (rides, shows, food
stalls, or merchandise shops) are available. Each area has a unique
identifier, a name, a location, a list of facilities available, and the area size.
Within each area, there are various experiences available, which is the
universal term that the park uses for rides, shows, games stalls, merchandise
shops, or food stalls. Each experience has a unique identifier, a name,
capacity, and a type. These experience types would have an identifier and
a name. Experiences may be located within a venue that may hold other
experiences, too. For example, Boo Boo Café, Howl Along Show, and Quack-
Up Arcade are inside the Tiki Hut, which is in the Bear’s Den area.

To enjoy any experience, there are different types of ticket classes on

offer. The rainbow ticket is valid for kids-appropriate rides/shows, the silver
ticket is valid for rainbow class plus some rides/shows, the gold ticket is valid
for all rides/shows, while the platinum is similar to the gold ticket with
express lane permit. These ticket classes need to be recorded with a unique
identifier, class name, description, and price.

A park visitor can be a member to get updates and promotions, a

discounted ticket during their birthday month and points that can be
redeemed for merchandise. Only visitors who are members will have their
details stored. The details stored are the member’s ID, name (given and
surname), email address, date of birth, state and country of residence. When
a member purchases a ticket to enter the park, an entry into the member
purchase history will be created with the date, the points gained, and the
ticket class. Each purchase history is uniquely identified using the purchase
date based on the member making the purchase.
Jellystone Park employs personnel for various role types (e.g. operator,
greeter, cleaner, etc.) and seniority levels (e.g. junior, senior, manager, etc.).
Each role type would have an identifier, a description, and the basic pay
rate. While the seniority level would have an identifier, level description,
and additional pay loading in percentage. Personnel contains the employees'
information, both current and past employees. Data recorded include the ID,
given name and surname, mobile number, email address, and date of birth.
Personnel can have different role allocations. These role allocations
comprise a role type and a seniority level, but no personnel should have
duplicates of the same role type and seniority level. Personnel will be
rostered to support a particular experience through their assigned role
allocation and a history of this roster assignment will be kept, where each
roster entry also includes the date of the roster, start time, and duration in
hours. Personnel may have a supervisor, but not all of them would have
one.

A curated recommended visit would have an identifier, a title, a

description, recommended age group, and the thrill level. It would have an
experience as a starting point, another experience as the ending point, and
possibly many other experiences (up to 10) in between to fill the day.

Each experience would need maintenance work to be done on a regular

basis, which is stored in the maintenance schedule. For each maintenance,
an identifier, the experience affected, the description of work involved, the
start date, status, and staff who will be the point of contact and oversee the
maintenance will be assigned.

Submission Requirements
Only one submission per group. Multiple submissions by different members will
overwrite any prior submissions.

You can submit many times up until the deadline (so get an early version in, just
in case). You need to rename the templates provided using the format
UnitCode_GroupID.pdf (e.g. comp1350_UG01-A.pdf)

It is your responsibility to make sure you have submitted the correct file. Failure
to do so will incur penalties.

Test your submission by downloading it to your own device and view.

General requirements

Must be using the template provided, which includes the following:

 Cover page

o Title

o Group ID

o Members’ full names (as displayed on iLearn) and student IDs

  Task 1

o A list of business rules (min. 10)

 These should be derived from the scenario.

o Addition business rule (complete this AFTER a full completion of ERD

based on the scenario)

o A list of assumptions, if any

 These should not contradict the scenario and used to fill the
gap(s) in the description.

o A clear image of the ER model in Crow’s Foot notation that you have
created. You can use a tool of your choice to generate the diagram.
Digital copies of hand-drawn diagrams will not be accepted. See the
image requirements below.

 Task 2

o Write the steps in the appropriate order (Step 1, followed by Step 2,

etc.)

o In each step,

 provide the relevant transformation process. Write “Not

applicable”, if nothing needs to be done in a step at that
stage.

 clearly list the primary key and foreign key(s), if any.

 If repeating any steps after a full pass of steps 1-7, label it as

Step # repeat

o Provide the final table list in alphabetical order of the table name.

 Task 3

o A clear image of the physical model that you have created. You can
use a tool of your choice to generate the diagram. Digital copies of
hand-drawn diagrams will not be accepted. See the image
requirements below.

Image requirements

 Image quality

o If we cannot see your diagram clearly, unfortunately, we cannot

mark it, and you will be given zero for this part. We can zoom in to
check the diagram but should not have to deal with images that are
blurry/fuzzy.

 Image
 o Ensure that the entire image fits within the document page and
does not go beyond the page. We will only mark the visible part of
the image. Please include the image in landscape view.

 Readability

o Ensure the texts in your image are readable. Be mindful of the

contrast between background colour (use soft light colours) and text
colour (use black).

My Work
Business Rules

Below are at least 10 business rules derived from the scenario, reflecting
constraints and requirements:

1. Area Uniqueness: Each area must have a unique identifier, name,

location, list of facilities, and size.

2. Experience Definition: Each experience must have a unique

identifier, name, capacity, and one experience type.

3. Experience Location: An experience is either directly located in

one area or in one venue, but not both.

4. Venue Containment: Each venue must be located in one area and

can contain multiple experiences.

5. Ticket Class Specification: Each ticket class must have a unique

identifier, class name, description, and price.

6. Member Purchases: A member can purchase multiple tickets, with

each purchase recorded in the purchase history including purchase
date, points gained, and ticket class, uniquely identified by member
and purchase date.

7. Member Details: Each member must have a unique ID, name

(given and surname), email, date of birth, state, and country.

8. Personnel Roles: Each personnel must have a unique ID, name

(given and surname), mobile number, email, and date of birth, and
can have multiple role allocations, but no duplicate combinations of
role type and seniority level are allowed for the same personnel.

9. Role Allocation Composition: Each role allocation consists of one

role type (with identifier, description, pay rate) and one seniority
level (with identifier, description, pay loading percentage) for a
personnel.
 10. Rostering: Personnel are rostered to support specific
experiences through their assigned role allocations, with each roster
entry including date, start time, and duration.

11. Supervision: A personnel may have one supervisor, who is

another personnel, but not all personnel have supervisors.

12. Curated Visits Structure: Each curated recommended visit

must have a unique identifier, title, description, age group, thrill
level, one starting experience, one ending experience, and up to 10
additional experiences in a specific sequence.

13. Maintenance Tracking: Each maintenance schedule must

have a unique identifier, be associated with one experience, include
a description, start date, status, and be overseen by one personnel.

These rules capture the core constraints and relationships specified in the
scenario.

Assumptions

Assumptions are necessary where the scenario lacks explicit detail. They
do not contradict the scenario and help fill gaps:

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

directly in one area or in one venue within an area, but not both.
Venues are distinct entities within areas, and if an experience is not
in a venue, it is directly associated with the area. Venue attributes
are limited to an identifier, name, and area location due to lack of
further specification.

2. Facilities Attribute: The “list of facilities” for an area is a single

text attribute (e.g., a comma-separated string), as no separate
entity or structure is specified.

3. Purchase History Identification: The purchase history is uniquely

identified by the combination of member ID and purchase date,
assuming a member cannot make multiple purchases on the same
date unless distinguished by time (not specified).

4. Roster Identification: Each roster entry is uniquely identified by a

combination of role allocation, experience, date, and start time,
assuming no overlapping assignments for the same personnel on
the same experience at the same time.

5. Curated Visit Sequence: The sequence of up to 10 in-between

experiences in a curated visit is ordered, managed via a position
attribute in an associative entity.
These assumptions ensure the design remains consistent and feasible.

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)

 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

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 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:

o 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))

 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.

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)

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).

Action: Create a new associative table PurchaseTicketClass with a

composite primary key from PurchasesHistory (MemberID, PurchaseID)
and TicketClass (TicketClassID).

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)

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:

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, 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))
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))