MEMBER_REGISTRATION
username email passward first_name last_name gender date_of_birth
1NF:
username email passward first_name last_name gender date_of_birth
emily emily @[Link] Emily_uni emily rockson Female 2001-12-21
david David@[Link] David_2193 david alikson male 2009-02-12
alex Alex@[Link] Alexhi!23 alex vickie male 2007-01-13
The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
Username -> email
Username -> passwords
Username -> first_name
Username -> last_name
Username -> gender
Username -> date_of_birth
In 2NF since the username will define all the other attributes since there is no partial dependency
3NF:
There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
MEMBER_PROFILE
Member_id address contact username
1NF:
Member_id address contact username
1 ottawa 343-123-323 emily
2 toronto 343-123-321 david
3 Toronto 343-123-327 alex
The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
Member -> address
Member -> contact
Member -> username
- In 2NF since the Member_id will define all the other attributes since there is no partial
dependency
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
FITNESSGOAL
Fitness_goalD Fitness_goal weight_goal muscle_goal fat Member_id
1NF:
Fitness_goalD Fitness_goal weight_goal muscle_goal fat
1 TONE 64 # #
2 BUILD MUSCLES 52 # #
3 BURN FAT 80 # #
The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
Fitness_goalD-> Fitness_goal
Fitness_goalD -> weight_goal
Fitness_goalD -> muscle_goal
Fitness_goalD ->fat
Fitness_goalD ->member_id
In 2NF since the Fitness_goalD will define all the other attributes since there is no partial
dependency
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
HEALTH_METRICS
HealthID Med Weight Height Member_id
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
healthID -> med
healthID -> weight
healthID -> height
healthID -> member_id
- In 2NF since the healthID will define all the other attributes since there is no partial dependency
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
FITNESS_ACHIEVEMENT
FitnessID Weight_achieved Muscle_achieved Fat_achieved DashboardID
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
fitnessID -> weight_achieved
fitnessID -> muscle_achieved
fitnessID -> fat_achieved
fitnessID -> Fitness_goal_achieved
fitnessID -> dashboardID
- In 2NF since the fitnessID will define all the other attributes since there is no partial dependency
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
DASHBOARD
DashboardID Loyaltypoints Member_id
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
dashboardID -> loyaltypoints
dashboardID -> member_id
- In 2NF since the dashboardID will define all the other attributes since there is no partial
dependency ( we cant get loyaltypoints from member_id)
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
EXERCISE_ROUTINE
routineid date exerciseType dashboardID
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
routineid -> date
routineid -> exerciseType
routineid -> dashboardID
- In 2NF since the routineid will define all the other attributes since there is no partial dependency
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
HEALTH_STATS
Health_Stat_id Health_Stat Current_weight Current_height dashboardID
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
healthStatId -> health_Stat
healthStatId -> current_weight
healthStatId -> current_height
healthStatId -> dashboardID
- In 2NF since the healthStatId will define all the other attributes since there is no partial
dependency
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
PERSONAL_TRAINING_SESSIONS
TRAINING_SESSION_ID trainer_id amount cost_per_sessions duration number_s
essions
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
TRAINING_SESSION_ID -> trainer_id
TRAINING_SESSION_ID -> amount
TRAINING_SESSION_ID -> cost_per_session
TRAINING_SESSION_ID -> duration
TRAINING_SESSION_ID -> number_sessions
- In 2NF since the TRAINING_SESSION_ID will define all the other attributes since there is no
partial dependency
3NF:
- The issue here arises in the cost_per_session since it depends on the number_sessions and since
the amount can be calculated by using both cost_per_session and number_sessions thus we must
create a new table
BEFORE:
TRAINING_SESSION_ID trainer_id amount cost_per_sessions duration number_sessions
AFTER:
TRAINING_SESSION_ID trainer_id cost_per_session duration
TRAINING_SESSION_ID number_sessions amount
SESSIONS
SESSION_id status club_name sTime sDate duration sLocation TRAINGING_ dashboardID
SESSION_ID
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
SESSION_id -> status
SESSION_id -> club_name
SESSION_id -> sTime
SESSION_id -> sDate
SESSION_id -> duration
SESSION_id ->sLocation
SESSION_id -> TRAINING_SESSION_ID
SESSION_id -> dashboardID
- In 2NF since the SESSION_id will define all the other attributes since there is no partial
dependency
3NF:
- This table is not in 3rd normal form as the non primary attribute slocation determines the
club_name and session_id determines the club_name. we have a transitive dependency here.
SESSION_id -> sLocation
sLocation -> club_name
Decompose:
SESSION_id status sTime sDate duration sLocation TRAINGING_SE dashboardID
SSION_ID
SESSION_id club_name
EVENTS
event_id type_of_event Instructor status Amount dashboardID
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
event_id -> type_of_event
event_id -> instructor
event_id -> status
event_id -> amount
event_id -> dashboardID
- In 2NF because the primary key (event_id) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
BOOKED_EVENTS
booking_id club_name date time location event_id
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
booking_id -> club_name
booking_id -> date
booking_id -> time
booking_id -> location
booking_id -> event_id
- In 2NF because the primary key (booking_id) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
TRAINER
trainer_id first_name last_name gender
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
trainer_id -> first_name
trainer_id -> last_name
trainer_id -> gender
- In 2NF because the primary key (trainer_id) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
NOTES
note_id note training_date trainer_id dashboardID
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
note_id -> note
note_id -> training_date
note_id -> trainer_id
note_id -> dashboardID
- In 2NF because the primary key (note_id) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
LOYALITY_PROGRAM
programID points reward_type admin_id
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
programID -> points
programID -> reward_type
programID -> admin_id
- In 2NF because the primary key (programID) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
ADMINISTRATION
ADMIN_ID email first_name last_name department phone
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
ADMIN_ID -> email
ADMIN_ID -> first_name
ADMIN_ID -> last_name
ADMIN_ID -> department
ADMIN_ID -> phone
- In 2NF because the primary key (ADMIN_ID) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
MANAGE_ROOMS
roomNumber Room_status capacity Last_cleaned Room_repair ADMIN_ID
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
roomNumber -> room_status
roomNumber -> capacity
roomNumber -> last_cleaned
roomNumber -> room_repair
roomNumber -> admin_id
- In 2NF because the primary key (Room_num) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
MONITOR_GYM
equipmentID last_serviced repairs_required maintaince_status ADMIN_ID
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
equipmentID -> last_serviced
equipmentID -> repairs_required
equipmentID -> maintenance_status
equipmentID -> ADMIN_ID
- In 2NF because the primary key (equipmentID) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
BILLINGS
transactionID points_earned transaction_date amount transaction_ ADMIN_ID member_id
Type
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
transactionID -> points_earned
transactionID -> transaction_date
transactionID -> amount
transactionID -> transaction type
transactionID -> ADMIN_ID
transactionID -> member_id
- In 2NF because the primary key (transactionID) uniquely identifies all other on primary attributes
without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute
REDEMPTION
redemptionID points_used reward_status date_reward programID member_id
1NF: The relation is in 1NF since there are not composite or multivalues
2NF: Collect FDS
redemptionID -> points_used
redemptionID -> reward_status
redemptionID -> date_reward
redemptionID -> programID
redemptionID -> member_id
- In 2NF because the primary key (redemptionID) uniquely identifies all other on primary
attributes without any partial dependencies
3NF:
- There is no transitive dependency thus it is in 3NF since no none primary attribute depend on
other none primary attribute