លំហសិក្សាធិការកម្ពុជា
V1.0
លំហសិក្សាធិការកម្ពុជា
V1.0
Many gyms still manage member information, memberships, attendance, and trainer scheduling using paper records or disconnected spreadsheets. This slows down daily operations, increases the chance of data-entry errors, and makes it difficult for staff to quickly check a member's status or history. This proposal presents the design of the Gym Management System (GMS), a web-based application built with Python, Flask, and MySQL that centralizes member registration, online membership purchase, attendance logging, trainer-session booking, and payment tracking within a single role-based platform. Visitors can browse membership plans and trainers freely; creating an account is only required to purchase a membership or request a trainer. The system supports four roles (Administrator, Staff, Trainer, and Member) each governed by a role-and-permission model that restricts every user to the features relevant to their responsibilities. Members log in to their own self-service dashboard to view their current membership plan and expiry date, their assigned trainer, their attendance history, and the total amount they have spent on membership and trainer sessions. The application is built on a three-layer object-oriented architecture (Domain Models, Service Layer, and Repository Layer) on top of a normalized MySQL database, keeping the codebase testable, maintainable, and easy to extend. This document sets out the problem the system addresses, its objectives and scope, its target users and stakeholders, its proposed features, its object-oriented and database design, and the timeline the team will follow to deliver it.
Advanced OOP R&D Project Standard
Python
+ Flask +
MySQL
PROJECT PROPOSAL
Gym Management System
Team Members: Teng Kanika, Rith Tola, Svay
Sereyratana, Try Hengleap
Course: Advanced OOP
Lecturer: Sek Socheat
Semester: 2, Year 2
Submission Type: Proposal
Many gyms still manage member information, memberships,
attendance, and payments using paper records or separate files. This can make
it difficult for staff to quickly find and update member information, check
membership status, and track attendance. Manual management can also lead to
data entry errors, missing records, and difficulties in tracking membership
renewals. These problems can increase staff workload and reduce the efficiency
of daily gym operations. Members may also experience delays when registering,
renewing memberships, or checking their information.
Therefore, there is a need for a Gym Management System
that provides a centralized and organized way to manage members, memberships,
trainers, and attendance. The system aims to reduce manual work, improve data
accuracy, and make gym management more efficient and convenient for gym staff.
General
Objective
To develop a Gym Management System that provides an
organized, accurate, and efficient way to manage members, memberships, trainer
bookings, attendance, and payments, while giving members secure self-service
access to their own information.
Specific
Objectives
●
To manage at least 100
member records accurately, including personal information and membership
details.
●
To manage at least 5
membership plans and accurately track membership status, start dates,
expiration dates, and renewals.
●
To record and retrieve 100%
of member attendance records accurately through the system.
●
To let visitors browse
membership plans and trainer profiles without an account, while requiring a
registered, logged-in account to purchase a membership or request a trainer.
●
To let new users
self-register for a Member account and purchase a membership online, with
payment processed securely through a payment gateway.
●
To let members browse
available trainers and request one to work with, and let trainers accept or
reject those requests before any sessions are scheduled.
●
To enable members and their
accepted trainer to schedule and track sessions, ensuring accurate booking
status and preventing double-booking conflicts.
●
To accurately record and
total 100% of membership and trainer-session payments, including each member's
total amount spent.
●
To provide members with a
secure self-service login where they can view their own membership, assigned
trainer, attendance, and spending information.
●
To achieve at least 90%
user satisfaction regarding the system's usability, efficiency, and ease of
managing gym information, based on user evaluation.
●
How can the system improve
the management of member information?
●
How does letting visitors
browse freely, but requiring an account to purchase or book, affect how many
visitors convert into registered, paying members?
●
How reliably and securely
can the system process online membership payments through a payment gateway?
●
How can the system make
membership registration and renewal easier and more efficient?
●
How accurately can the
system record and track member attendance?
●
How effective is a
browse-and-request workflow — where a member selects a trainer and the trainer
accepts or rejects the request — at matching members with trainers?
●
How can the system help
members and trainers schedule and manage sessions more effectively once a
request is accepted?
●
How accurately can the
system record and total each member's membership and trainer-session payments?
●
How does giving members
self-service login access affect their awareness of their own membership,
trainer, and spending information?
●
How satisfied are users
with the system in terms of usability, efficiency, and ease of use?
The Gym Management System will focus on managing gym
members, memberships, trainer bookings, and attendance. The system is designed
to make daily gym management more organized, efficient, and easier to use.
Scope
●
Allow visitors to browse
membership plans and trainer profiles publicly, without needing an account.
●
Let a new user
self-register for a Member account directly from the website (creates a login
account and a member profile together).
●
Require a logged-in account
to purchase a membership or submit a trainer request; Admin/Staff can also
register a member directly (e.g., for walk-ins).
●
Let a logged-in member
purchase and pay for a membership plan online through a payment gateway, which
automatically activates the plan.
●
Manage membership plans,
status, and expiration dates.
●
Manage member attendance
records.
●
Let members browse trainers
and request one to work with, subject to that trainer accepting or rejecting
the request.
●
Schedule and manage
sessions between a member and their accepted (assigned) trainer.
●
Record membership and
trainer-session payments (online or staff-recorded) and calculate each member's
total spending.
●
Provide members with
self-service login access to view their own membership, trainer, attendance,
and payment information.
●
Manage system users, roles,
and permissions for Admin, Staff, Trainer, and Member accounts.
●
Allow staff to search and
view member records.
Limitation
●
Online workout or exercise
classes.
●
Diet and nutrition
management.
●
Advanced fitness tracking,
such as heart rate or calories.
●
Online payment for trainer
sessions — trainer-session payments are still recorded manually by staff after
being collected; only membership purchases are paid online.
●
Equipment inventory and
maintenance management.
User
Types
●
Admin/Staff: Manage members, memberships, trainer profiles, bookings,
attendance, payments, and system user accounts.
●
Trainer: Accept or reject trainer requests from members, view
assigned member bookings, and mark attendance for their sessions.
●
Member: Self-registers or is registered by Admin/Staff, logs in
to purchase a membership online, browse and request a trainer, and view their
own membership, assigned trainer, attendance, and spending information.
●
Visitor (not logged in):
Can browse membership plans and trainer
profiles, but must create an account and log in to purchase a membership or
request a trainer.
Core
Features
●
Member Management
●
Membership Management
●
Trainer Booking Management
●
Attendance Management
●
Payment & Spending
Tracking
●
Member Self-Service Portal
●
Role-Based Access Control
(Users, Roles & Permissions)
●
Search and Records
Assumptions
●
Users (Admin, Staff,
Trainer, Member) have valid accounts and appropriate access permissions.
●
Member information entered
into the system is accurate.
●
Staff are responsible for
updating member, membership, and payment information.
●
Trainers or staff record
attendance correctly.
●
Members are responsible for
keeping their own login credentials confidential.
●
The system is used only by
authorized gym staff, trainers, and registered members.
●
The payment gateway (e.g.,
Stripe) collects and stores card details on its own secure, PCI-compliant
servers; the system itself never stores raw card numbers, only the payment
amount, status, and a gateway transaction reference.
The Gym Management System is designed to support the
daily management of gym members, memberships, trainer bookings, and attendance.
Target
Users
Visitor
(Not Logged In)
●
Browse membership plans and
trainer profiles without creating an account.
●
Must register and log in
before purchasing a membership or requesting a trainer.
Admin /
Staff
●
Register and manage member
information.
●
Manage memberships and
trainer bookings.
●
Manage system users, roles,
and permissions.
Trainer
●
Maintain a trainer profile
(specialization, bio) that members can browse.
●
Accept or reject trainer
requests sent by members.
●
View assigned member
bookings.
●
Mark attendance for members
in their sessions.
●
View relevant member
membership information.
Members
Members are the individuals the gym serves. Anyone can
create their own Member account by registering on the website (Admin/Staff can
also register a member directly, e.g., for walk-ins). Once logged in, a member
can:
●
Purchase and pay for a
membership plan online through the payment gateway.
●
Browse available trainers
by specialization/bio and request one to work with.
●
View their current
membership plan and its expiry date.
●
View their assigned trainer
(once a trainer accepts their request).
●
View their attendance
history.
●
View the total amount they
have spent on membership and trainer sessions.
Other
Stakeholders
Gym
Manager / Owner
●
Monitor gym activities,
members, memberships, attendance, trainer bookings, and payments.
●
Use system information to
support management decisions.
IT /
System Administrator
●
Maintain the system and
database.
●
Manage user accounts and
system security.
●
Solve technical problems.
The Gym Management System (GMS) is a web-based platform
built with Python, Flask, and MySQL. It provides structured management of
member information, membership plans, trainer bookings, attendance, and
payments, and gives members a self-service view of their own information. The
system is divided into the following modules:
●
Public (unauthenticated)
browsing of membership plans and trainer profiles — no account is required just
to look.
●
A visitor can self-register
for a Member account directly from the website; this creates their login
(users) record and their member profile together in one step.
●
Purchasing a membership or
submitting a trainer request requires being logged in — unauthenticated
attempts are redirected to log in or register first.
●
Secure login and logout
using PBKDF2-HMAC-SHA256 password hashing with a unique per-user salt.
●
Four user roles:
Administrator, Staff, Trainer, and Member.
●
Session-based
authentication using Flask-Login.
●
Protected routes to prevent
unauthorized access; a Member's routes are restricted to that member's own
data.
●
Unauthorized users
attempting a protected action are redirected to the login page.
●
Administrator can create,
edit, and deactivate user accounts (staff, trainer, and member accounts alike).
●
Administrator can create
roles and permissions, and assign roles to users.
●
Role-based permissions
determine which features each user can access.
●
A visitor can self-register
for a Member account (full name, email, phone, username, password); the system
creates their login account and member profile in the same step, with no
membership plan yet attached.
●
Admin/Staff can also
create, edit, and delete member records directly, including creating a member's
login account on their behalf (e.g., for walk-in registrations).
●
Each member has a unique ID
and is linked one-to-one with a login account.
●
Member information
includes: full name, phone number, email, join date, status, membership type,
membership start date, membership expiry date, assigned trainer (set once a
trainer accepts the member's request), and notes.
●
Admin/Staff can search and
filter members.
●
Admin/Staff can filter
members whose memberships are expiring soon.
●
A member's profile (as seen
by Admin/Staff) displays their membership, assigned trainer, attendance,
trainer-booking, and payment history.
Once logged in, a Member sees a personal dashboard
limited to their own records, with two self-service actions — purchasing a
membership and choosing a trainer — layered on top of an otherwise read-only
view:
●
Browse membership plans and
purchase/pay for one online; the plan activates automatically once payment
succeeds.
●
Browse available trainers
(specialization and bio) and submit a request to work with one of them.
●
Their current membership
plan and its expiry date.
●
Their assigned trainer,
once a requested trainer accepts.
●
Their attendance history
(dates and status).
●
The total amount they have
spent on membership and on trainer sessions, and a combined grand total.
●
Members cannot directly
edit their own membership, payment, or attendance data — attendance and payment
records are still entered by Admin/Staff/Trainer, and a trainer request only
takes effect once the chosen trainer accepts it. The exception is checkout:
purchasing a membership plan is a member-initiated action, completed the moment
the payment gateway confirms payment.
●
Anyone — logged in or not —
can view the list of available membership plans and their pricing/duration.
●
A logged-in member selects
a plan and pays for it online through the payment gateway; on a successful
payment, the system automatically sets that as their current membership type,
starting today, with an expiry date calculated from the plan's duration.
●
Admin/Staff can also
create, edit, and delete membership types, and can manually assign or change a
member's plan (e.g., for a walk-in payment or a correction).
●
Each membership type
contains: plan name, duration (in days), price, and description.
●
Each member is linked to at
most one current membership type, with a start date and a system-calculated
expiry date.
●
The system flags a member's
membership as expiring when the expiry date falls within the next 7 days.
●
Admin/Staff can set a
member's status (e.g., active, inactive, suspended) independently of membership
expiry.
●
Anyone — logged in or not —
can browse trainer profiles (specialization and bio).
●
Sending a request to a
specific trainer requires being logged in as a Member; a visitor who tries is
prompted to register or log in first.
●
Each trainer sees their
incoming requests and can accept or reject them; a rejected request lets the
member browse and request a different trainer.
●
Once a trainer accepts,
that trainer becomes the member's assigned (primary) trainer, shown on the
member's dashboard — Admin/Staff can also set or reassign this directly if
needed.
●
With an accepted trainer in
place, the member and trainer (or Admin/Staff) can schedule individual sessions
between them.
●
A booking records the
member, the trainer, the booking date, duration, status, and optional notes.
●
Trainers can view their
pending requests as well as their upcoming and past bookings.
●
Both request status
(Pending → Accepted / Rejected) and booking status (Scheduled → Completed /
Cancelled) are tracked separately.
●
The system prevents
double-booking a trainer for overlapping time slots.
●
Trainer/Staff can record a
member's check-in for the day.
●
The system records: member,
attendance date, check-in time, the staff/trainer who marked it, and status
(present/absent).
●
Trainers can view
attendance records for members in their sessions.
●
Admin/Staff can view,
filter, and manage all attendance records.
●
Members can view their own
attendance history from their portal.
●
The system prevents
duplicate attendance entries for the same member on the same day.
●
A logged-in member can pay
for a membership plan online: the system sends the amount to a payment gateway
(e.g., Stripe), and on a confirmed successful payment, records the payment and
activates the plan automatically — no staff involvement needed.
●
Trainer-session payments
are still recorded manually: Admin/Staff (or the Trainer) enters the payment
after it is collected in person.
●
Each payment records: the
member, a category (membership or trainer session), the related membership type
or booking, amount, payment date, status, payment method (online or manual), a
gateway transaction reference for online payments, and — for manually recorded
payments — the staff member who recorded it.
●
Admin/Staff can view each
member's full payment history.
●
The system calculates each
member's total spending on memberships, total spending on trainer sessions, and
a combined total.
●
Members can view their own
membership total, trainer-session total, and combined total from their portal,
but cannot view other members' payments.
●
The system never stores raw
card numbers — the payment gateway handles and stores card details on its own
secure servers; only the resulting amount, status, and transaction reference
are saved.
●
Server-side input
validation on all forms using WTForms.
●
Required fields and valid
data formats are enforced.
●
User-friendly error
messages are displayed.
●
Raw Python
errors/tracebacks are not exposed to users.
●
Duplicate records (e.g.,
usernames, membership type names) are prevented.
●
Trainer-booking conflicts
are detected and rejected.
●
Payment amounts and
categories are validated before being recorded.
●
Business rules are enforced
at the service layer.
●
Monthly member attendance
reports.
●
Member attendance
statistics.
●
Membership expiration
summaries.
●
Trainer booking statistics.
●
Membership and
trainer-session revenue summaries.
●
Dashboard displaying key
statistics: active members, memberships expiring soon, attendance today,
staff/trainer accounts, and total revenue.
Model Summary
| Module | What its handle |
|---|---|
| Authentication & Role-Based Access Control | Public browsing, self-registration, login/logout, password security, roles & permissions |
| Member Management | Self-registration plus Admin/Staff create, edit, delete, and manage member accounts |
| Member Self-Service Portal | Member's own view of membership, trainer, attendance, and spending |
| Membership Management | Manage membership types, pricing, duration, and member subscriptions |
| Trainer Booking Management | Browse/request trainers, accept/reject requests, schedule sessions, conflict prevention |
| Attendance Management | Record and view member check-ins and attendance history |
| Payment & Spending Tracking | Record membership/trainer payments; calculate each member's total spending |
| Validation & Error Handling | Input validation, business rules, conflict detection, user-friendly errors |
| Reports & Summary | Attendance reports, expiration summaries, spending, and dashboard statistics |
The system is designed using a clean three-layer OOP
architecture: Domain Models, Service Layer, and Repository Layer. This
separation means each class has a single, clear responsibility, which keeps the
codebase testable and maintainable.
7.1 Layer Overview
|
Layer |
Responsibility |
Example
Classes |
|
Domain Models |
Represents the
core entities and their data in the system. Defines attributes and
relationships between entities. Contains business data but does not handle
database queries or HTTP requests. |
User, Member,
MembershipType, TrainerProfile, TrainerRequest, TrainerBooking, Attendance,
Payment, Role, Permission |
|
Service Layer |
Contains the
application's business logic and rules. Validates operations, handles trainer
requests and booking conflicts, checks membership status, totals member
spending, and coordinates between Models and Repositories. |
AuthService,
MemberService, MembershipService, TrainerService, AttendanceService,
PaymentService, UserService, ReportService |
|
Repository
Layer |
Handles
communication with the MySQL database. Responsible for creating, retrieving,
updating, and deleting data. Keeps database queries separate from business
logic. |
UserRepository,
MemberRepository, MembershipTypeRepository, TrainerProfileRepository,
TrainerRequestRepository, BookingRepository, AttendanceRepository,
PaymentRepository, RoleRepository, PermissionRepository |
|
Flask Routes |
Handles HTTP
requests and responses. Receives requests from users, calls the appropriate
Service Layer method, and returns HTML pages or responses. A member's routes
are scoped to that member's own account. Routes do not contain business logic
or direct database queries. |
AuthRoutes,
MemberRoutes, MembershipRoutes, TrainerRoutes, AttendanceRoutes,
PaymentRoutes, UserRoutes, ReportRoutes |
Domain
Classes
|
Domain Class |
Important
Attributes |
Main
Responsibilities |
|
User |
id, username,
full_name, email, phone, password_hash, salt, is_active |
Represents any
login account — Admin, Staff, Trainer, or Member. Assigned role(s) determine
permissions. |
|
Member |
id, user_id,
join_date, status, membership_type_id, membership_start, membership_expiry,
assigned_trainer_id, notes |
Represents a
gym member's profile. Linked one-to-one with a User account so the member can
log in. |
|
MembershipType |
id, type_name,
duration_days, price, description |
Represents a
membership plan offered by the gym. |
|
TrainerProfile |
id, user_id,
specialization, bio, created_at |
Extends a
Trainer user with the information members browse before choosing them
(specialization, bio, availability). |
|
TrainerRequest |
id, member_id,
trainer_user_id, status, requested_at, responded_at |
Represents a
member's request to work with a specific trainer, and that trainer's
accept/reject decision. |
|
TrainerBooking |
id, member_id,
trainer_user_id, booking_date, duration_minutes, status, notes |
Represents a
scheduled session between a member and their (already accepted) trainer. |
|
Attendance |
id, member_id,
attendance_date, check_in_time, marked_by_user_id, status |
Records a
member's daily check-in and who marked it. |
|
Payment |
id, member_id,
category, membership_type_id, booking_id, amount, payment_date, status,
recorded_by_user_id |
Represents a
payment a member made for a membership plan or a trainer session. |
|
Role |
id, role_name,
description |
Represents a
named user role (Administrator, Staff, Trainer, Member). |
|
Permission |
id,
permission_key, description |
Represents a
single granular permission that can be granted to a role. |
Service
Classes
|
Service
Class |
Important
Methods |
Responsibility |
|
AuthService |
register(),
login(), logout(), validate_credentials() |
Handles public
self-registration (creates a User + Member together), plus authentication and
session access for every role. |
|
MemberService |
create_member(),
update_member(), delete_member(), search_members(), get_expiring_members(),
get_own_dashboard() |
Handles
member-related business operations, including assembling a member's own
self-service dashboard. |
|
MembershipService |
get_public_plan_list(),
create_membership_type(), get_available_types(), purchase_membership(),
calculate_expiry() |
Lets anyone
browse plans, manages membership plans, and handles a logged-in member's
online plan purchase and activation. |
|
TrainerService |
browse_trainers(),
request_trainer(), accept_request(), reject_request(), book_session(),
check_conflict(), get_trainer_bookings(), get_member_bookings() |
Lets anyone
browse trainers publicly; lets a logged-in member request one, lets a trainer
accept/reject that request, and — once accepted — handles session scheduling
and conflict checks. |
|
AttendanceService |
mark_attendance(),
get_member_attendance(), get_today_attendance() |
Handles
attendance recording and retrieval rules; prevents duplicate check-ins. |
|
PaymentService |
process_online_payment(),
record_payment(), get_member_payments(), get_member_totals(),
get_revenue_summary() |
Sends
membership purchases to the payment gateway and records the result; also
handles manually recorded trainer-session payments and spending totals. |
|
UserService |
create_user(),
assign_role(), assign_permission(), get_user_permissions() |
Handles user
accounts, roles, and permission assignment for all four roles. |
|
ReportService |
dashboard_summary(),
monthly_attendance(), expiring_memberships(), revenue_summary() |
Generates
reports and system-wide summaries. |
Repository
Classes
|
Repository
Class |
Important
Methods |
Responsibility |
|
UserRepository |
find_by_username(),
create(), update(), delete() |
Retrieves and
manages user records (all roles). |
|
MemberRepository |
find_by_id(),
find_by_user_id(), find_all(), search(), create(), update(), delete() |
Handles member
database operations, including looking up a member from their logged-in user
account. |
|
MembershipTypeRepository |
find_by_id(),
find_all(), create(), update(), delete() |
Handles
membership plan database operations. |
|
TrainerProfileRepository |
find_by_id(),
find_by_specialization(), find_all() |
Retrieves
trainer profiles for members to browse. |
|
TrainerRequestRepository |
find_by_member(),
find_by_trainer(), create(), update_status() |
Handles
trainer-request records and their pending/accepted/rejected status. |
|
BookingRepository |
find_by_id(),
find_by_member(), find_by_trainer(), create(), update_status() |
Handles
trainer-booking database operations, including conflict lookups. |
|
AttendanceRepository |
create(),
find_by_member(), find_by_date() |
Handles
attendance records. |
|
PaymentRepository |
create(),
find_by_member(), sum_by_member_and_category() |
Handles
payment records and per-member spending totals. |
|
RoleRepository
/ PermissionRepository |
find_all(),
create(), update(), delete() |
Handles roles,
permissions, and their assignments. |
Figure 1 (next page) summarizes how the services,
repositories, and domain classes relate to one another at the OOP level each
service uses its repositories to reach the database, and the domain classes
underneath show how a Member connects to a MembershipType, a
TrainerProfile/TrainerRequest/TrainerBooking, Attendance, and Payment records
(the physical database version of these same relationships is detailed in
Figure 4, Section 9.3).
Figure 1 — Service, Repository, and
Domain Class Relationship Diagram
Every request flows top-down through the layers below,
and every response flows back up the same path:
Figure 2 — Call Flow Between OOP Layers
The Gym Management System (GMS) follows a layered,
MVC-inspired web architecture built with the Flask Application Factory pattern.
The system is organized into distinct vertical layers, where each layer
communicates only with the layer directly below it.
|
Layer |
Technology |
Responsibility |
|
Presentation /
UI |
Jinja2 HTML
templates + Bootstrap 5 |
Render forms
and pages, including the member self-service dashboard; send user actions to
Flask routes |
|
Routing /
Controller |
Flask
Blueprints |
Receive HTTP
requests; validate session and role; delegate to services; return response |
|
Service Layer |
Plain Python
classes |
Enforce
business rules; coordinate between repositories and domain objects |
|
Repository
Layer |
Plain Python
classes + mysql-connector-python |
Execute
parameterized SQL; map rows to domain objects |
|
Domain Model
Layer |
Python
dataclasses / plain classes |
Represent
entities; carry field-level validation and computed properties |
|
Database |
MySQL 8 |
Persist all
relational data; enforce FK constraints and indexes |
|
Payment
Gateway (external) |
Stripe API
(sandbox/test mode) |
Collects and
stores card details off-platform; processes the charge; returns a transaction
result that PaymentService records |
Every web request follows the numbered path below down
through the layers, and the response follows the same path back up. A Member's
requests are always scoped to that member's own account, whichever step is
handling them.
Figure 3 — Request–Response Flow Through
the System
The Gym Management System (GMS) utilizes MySQL 8 as its
relational database management system (RDBMS). The schema below extends the
team's original entity-relationship design to add member login accounts,
self-registration, trainer browsing/requests, and online payment tracking
(Figure 4), and remains normalized to reduce redundancy while keeping queries
efficient.
●
Authentication &
Identity: All login accounts (Administrator, Staff, Trainer, and now Member) are held in the users table.
Roles are assigned through the user_roles junction table, and each role is
granted permissions through the role_permissions junction table, enabling
Role-Based Access Control (RBAC).
●
Members: The members table holds each member's gym profile such as join
date, status, current membership type, membership start/expiry dates, assigned
trainer, and notes, and links one-to-one to a users row (member_id ↔ user_id)
so the member can log in to their own dashboard.
●
Membership Plans: The membership_types table defines the available plans
(name, duration, price, description). Each member links to at most one current
plan via membership_type_id.
●
Trainer Profiles: The trainer_profiles table extends a Trainer user's
account with the information members need to browse and compare trainers specialization and a short bio linked one-to-one to a users row
(trainer_profiles.user_id).
●
Trainer Requests: The trainer_requests table records a member's request to
work with a specific trainer: who requested whom, and a status (pending,
accepted, or rejected) that the trainer sets. Once a trainer accepts, the
member's assigned_trainer_id on the members table is updated to that trainer.
●
Trainer Bookings: Once a member has an accepted trainer, the
user_trainer_bookings table records each individual scheduled session between
the member and that trainer including date, duration, status, and notes.
●
Attendance: The attendance table logs each member's daily check-in,
referencing the staff or trainer user who recorded it.
●
Payments: The payments table records every amount a member has
paid, tagged by category (membership or trainer_session) and linked to the
relevant membership_type or booking. A payment_method column distinguishes
online (gateway) payments from manual (staff-recorded) ones, and
gateway_transaction_id stores the payment gateway's own reference for online
payments (null for manual ones) — never a card number. Summing this table per
member produces the membership total, trainer-session total, and combined total
shown on the member's dashboard.
Figure 4 — Gym Management System Entity
Relationship Diagram (updated: member login accounts, trainer browsing &
requests, and payments)
|
Parent Table |
Child Table |
Relationship |
Key
Mechanism & Purpose |
|
users |
members |
One-to-One |
members.user_id
→ users.id (UNIQUE) — gives every member a login account for the self-service
portal. |
|
users |
members |
One-to-Many |
members.assigned_trainer_id
→ users.id — identifies each member's primary trainer (a user holding the
Trainer role). |
|
membership_types |
members |
One-to-Many |
members.membership_type_id
→ membership_types.id — defines which plan a member currently subscribes to. |
|
users |
user_roles |
One-to-Many |
user_roles.user_id
→ users.id — part 1 of the many-to-many system; links a user to one or more
roles. |
|
roles |
user_roles |
One-to-Many |
user_roles.role_id
→ roles.id — part 2 of the many-to-many system; links a role to many users. |
|
roles |
role_permissions |
One-to-Many |
role_permissions.role_id
→ roles.id — links a role to the permissions it has been granted. |
|
permissions |
role_permissions |
One-to-Many |
role_permissions.permission_id
→ permissions.id — links a permission to every role granted it. |
|
members |
attendance |
One-to-Many |
attendance.member_id
→ members.id — logs each attendance/check-in event for a member. |
|
users |
attendance |
One-to-Many |
attendance.marked_by_user_id
→ users.id — identifies the staff/trainer user who recorded the entry. |
|
users |
trainer_profiles |
One-to-One |
trainer_profiles.user_id
→ users.id (UNIQUE) — extends a Trainer user with specialization/bio so
members can browse them. |
|
members |
trainer_requests |
One-to-Many |
trainer_requests.member_id
→ members.id — records every trainer request a member has sent. |
|
users |
trainer_requests |
One-to-Many |
trainer_requests.trainer_user_id
→ users.id — identifies the trainer being requested, who accepts or rejects
it. |
|
members |
user_trainer_bookings |
One-to-Many |
user_trainer_bookings.member_id
→ members.id — records every trainer session booked for a member. |
|
users |
user_trainer_bookings |
One-to-Many |
user_trainer_bookings.trainer_user_id
→ users.id — identifies the trainer for the booking. |
|
members |
payments |
One-to-Many |
payments.member_id
→ members.id — records every payment a member has made. |
|
membership_types |
payments |
One-to-Many |
payments.membership_type_id
→ membership_types.id (nullable) — set when the payment is for a membership
plan. |
|
user_trainer_bookings |
payments |
One-to-Many |
payments.booking_id
→ user_trainer_bookings.id (nullable) — set when the payment is for a trainer
session. |
|
users |
payments |
One-to-Many |
payments.recorded_by_user_id
→ users.id — identifies the staff member who recorded the payment. |
●
Primary Key: Uniquely identifies each record in a table (e.g., the id
column on every table). Enforces uniqueness and disallows NULL.
●
Foreign Key: Establishes and enforces a relationship between two
tables (e.g., members.membership_type_id → membership_types.id).
●
Unique: Ensures values in a column are distinct across all rows
(e.g., users.username; members.user_id, so each login account maps to at most
one member profile; one attendance record per member per day via
UNIQUE(member_id, attendance_date)).
●
Check: Restricts the values allowed in a column (e.g.,
membership_types.duration_days must be greater than 0; payments.amount must be
greater than or equal to 0; payments.category must be 'membership' or
'trainer_session').
●
Not Null: Requires a column to always contain a value (e.g.,
members.user_id, users.password_hash, payments.amount).
●
Default: Automatically inserts a predefined value when none is
supplied (e.g., members.status defaults to 'active'; payments.status defaults
to 'paid'; members.join_date defaults to the current date).
A clear timeline and a proactive risk management plan
were essential to keeping the Gym Management System project on schedule and
under control. This section explains how the project was broken down into
sprints, what each sprint was expected to deliver, and the key risks the team
anticipated, along with the strategies used to reduce their impact.
The project was organized into four sprints, each with a
clear focus so progress could be tracked and reviewed regularly. Breaking the
work into sprints made it easier to catch problems early, reassign tasks when
needed, and ensure that every core module — authentication, member management,
memberships, trainer bookings, and attendance — was completed before moving on
to testing and final documentation.
Figure 5 — Sprint Sequence
|
Sprint |
Focus |
Key Tasks
& Deliverables |
|
1 |
Planning &
Database Design |
Gathered and
confirmed system requirements; designed the entity-relationship diagram
covering Users, Members (with login accounts), Membership Types, Trainer
Bookings, Attendance, and Payments; defined primary/foreign key relationships
and set up the development environment. |
|
2 |
Core
Development |
Built the
Flask backend using the three-layer OOP architecture (Domain Models, Service
Layer, Repository Layer); implemented Authentication & RBAC (four roles),
Member Management, the Member Self-Service Portal, Membership Management,
Trainer Booking, Attendance, and Payment modules. |
|
3 |
Testing &
Integration |
Tested
individual features against test cases; identified and fixed bugs; integrated
all modules so data flows correctly between members, memberships, trainer
bookings, attendance, and payments; verified that each member's self-service
view shows only their own data. |
|
4 |
Finalization
& Demo |
Carried out
the final review against the project objectives, completed the user guide,
test report, and final manual, and prepared and rehearsed the live
demonstration. |
Every project carries risks that can affect quality,
timeline, or teamwork. The table below lists the main risks identified for this
project, how likely each one was to occur, its potential impact, and the
mitigation strategy the team put in place.
|
Risk |
Likelihood |
Impact |
Mitigation
Strategy |
|
Data errors |
Medium |
High |
Validate all
user input at the form level and the database level, and test each feature
thoroughly before moving to the next sprint. |
|
Tight timeline |
High |
Medium |
Break the
project into four clearly scoped sprints and track progress weekly so that
delays are caught and addressed early. |
|
Integration
issues |
Medium |
High |
Test each
module individually before combining them, and run integration tests once
modules are connected to catch mismatches early. |
|
Team
availability |
Low |
Medium |
Assign backup
tasks for critical work and maintain regular communication so the team can
adapt if a member is unavailable. |
By the end of the project, the team is expected to
deliver four main outputs: a working piece of software, evidence that it has
been tested, a written report documenting the process, and a live
demonstration.
A fully working, web-based Gym Management System built
with Python, Flask, and MySQL. The system brings together the core modules
defined in the project scope:
●
Public Browsing &
Self-Registration: visitors browse membership plans and trainers freely;
anyone can self-register for a Member account.
●
Authentication &
Role-Based Access Control: secure login for Administrators, Staff, Trainers,
and Members.
●
Member Management: create,
edit, search, and manage member records and their login accounts.
●
Member Self-Service Portal: members log in to view their own membership, trainer, attendance, and
spending.
●
Membership Management: logged-in members browse and purchase membership plans online, with automatic
activation.
●
Trainer Booking Management: members browse and request trainers, trainers accept/reject, and accepted
sessions are scheduled and tracked with conflict prevention.
●
Attendance Management: record and view member check-ins and attendance history.
●
Payment & Spending
Tracking: online membership payments via a payment gateway, manually recorded
trainer-session payments, and per-member spending totals.
●
User, Role & Permission
Administration: manage staff and member accounts and access control.
These modules are connected through the database
relationships defined in the design phase, so that data stays consistent across
the whole system.
Pallets Projects. (n.d.). Flask
documentation. https://flask.palletsprojects.com/
Oracle Corporation. (n.d.). MySQL 8.0
reference manual. https://dev.mysql.com/doc/refman/8.0/en/
Bootstrap Core Team. (n.d.).
Bootstrap documentation (v5.3). https://getbootstrap.com/docs/5.3/
Flask-Login Contributors. (n.d.).
Flask-Login documentation. https://flask-login.readthedocs.io/
Pallets-Eco. (n.d.). WTForms
documentation. https://wtforms.readthedocs.io/
Python Software Foundation. (n.d.).
hashlib — Secure hashes and message digests.
https://docs.python.org/3/library/hashlib.html
Schwaber, K., & Sutherland, J.
(2020). The Scrum guide: The definitive guide to Scrum — The rules of the game.
https://scrumguides.org/scrum-guide.html
Mindbody Inc. (n.d.). Mindbody:
Fitness and wellness business management software.
https://www.mindbodyonline.com/
ABC Fitness / Glofox. (n.d.). Glofox:
Gym and fitness studio management software. https://www.glofox.com/
Sek, Socheat. (2026). Advanced OOP R&D project standard template: Python + Flask + MySQL [Course handout]. University of Technology and Entrepreneurship (UTE).
