fitness_center_presentation(1)

1.

Министерство науки и высшего образования РФ
ФГБОУ ВО «Нижневартовский государственный университет»
Факультет информационных технологий и математики
Анализ и проектирование
информационной системы
для фитнес-центра
Курсовой проект | Направление 09.03.01 – Информатика и вычислительная техника
Выполнил: студент группы ИиВТ-3312 Герасимов И.Р.
Научный руководитель: Мамедли Р.Э.
г. Нижневартовск, 2026

2.

Актуальность и цель работы
Обоснование необходимости разработки информационной системы
Проблема
Цель и задачи
✗ Excel-таблицы и бумажные журналы для учёта клиентов
ЦЕЛЬ: спроектировать архитектуру БД, автоматизирующей ключевые
бизнес-процессы фитнес-центра
✗ Ошибки контроля остатка занятий по абонементам (>12%)
✗ Конфликты расписания: один зал / один тренер — два занятия
✗ Долгое обслуживание на ресепшене (до 3 минут)
✗ Отсутствие управленческой аналитики и онлайн-записи
▸ Анализ предметной области и выявление недостатков
▸ Формирование функциональных и нефункц. требований
▸ Обзор и сравнение рыночных аналогов
▸ Разработка концептуальной ER-модели (нотация Чена)
▸ Построение логической схемы реляционной БД (3НФ)
▸ Подготовка типовых SQL-запросов
ФГБОУ ВО «Нижневартовский государственный университет»
2 / 13

3.

Анализ предметной области
Ключевые сущности фитнес-центра и охватываемые бизнес-процессы
Client
MembershipType
Membership
Trainer
WorkoutCategory
Клиент
Тип абонемента
Абонемент
Тренер
Категория
Hall
Workout
Booking
Attendance
Payment
Зал
Занятие
Запись
Посещение
Платёж
3. Фиксация посещения
и списание занятий
4. Управление
расписанием
5. Финансовая
отчётность и аналитика
Ключевые бизнес-процессы, охваченные системой
1. Регистрация клиентов
и продажа абонементов
2. Запись
на групповые занятия
ФГБОУ ВО «Нижневартовский государственный университет»
3 / 13

4.

Недостатки существующей системы и анализ аналогов
Обоснование разработки собственного решения
Недостаток
Фрагментация данных в Excel
Ручной подсчёт занятий
Нет авто-контроля срока
Последствие
Несогласованность версий
Финансовые потери
Пропуск просроченных карт
Функция
Учёт клиентов
Сравнение аналогов
Продукт
Тип
Стоимость
Малый клуб
FitStars
Облако
Высокая
±
ProFIT
Локал.
Средняя
+
1С:Фитнес
Локал.
Очень выс.
–
Контроль абонементов
Контроль доступа
Текстовое расписание
Конфликты «зал/тренер-время»
Организация тренировок
Yclients
Облако
Средняя
+
Бумажные журналы
Долгий поиск, риск утраты
Учёт посещаемости
Наша ИС
Любой
—
✓
Нет финансовой аналитики
Нельзя рассчитать метрики
Управленческая отчётность
ФГБОУ ВО «Нижневартовский государственный университет»
4 / 13

5.

Функциональные и нефункциональные требования
Основные требования к проектируемой информационной системе
Функциональные требования (FR)
Нефункциональные требования (NFR)
FR-1.1–1.3
NFR-1 Надёжность
ACID-транзакции; доступность ≥ 99,5%
FR-2.1–2.3
FR-3.1–3.3
Управление клиентами: CRUD, история, статусы
Расписание: создание, контроль конфликтов, серии
Абонементы: справочник, авто-расчёт даты, платежи
NFR-2 Безопасность
RBAC: роли администратора, тренера, клиента
NFR-3 Производит.
Отклик ≤ 2 с при 10 пользователях
NFR-4 Масштаб.
Индексы на FK; линейный рост времени
FR-4.1–4.3
FR-5.1–5.3
Посещаемость: проверка, списание, отмена записи
Аналитика: загрузка залов, выручка, история клиента
ФГБОУ ВО «Нижневартовский государственный университет»
NFR-5 Сопровождение
Словарь данных; 1 таблица = 1 сущность
NFR-6 Локализация
Интерфейс на русском; формат ДД.ММ.ГГГГ
5 / 13

6.

Концептуальная модель данных (нотация Чена)
Описание сущностей, атрибутов и семантики связей ER-модели
Client / Клиент
Связи между сущностями
Центральный объект системы. Хранит персональные данные, статус активности
и историю взаимодействия с клубом. Может владеть несколькими
абонементами.
1:N
Клиент владеет несколькими абонементами
1:N
MembershipType → Membership
Один тип продаётся многократно
Membership / Абонемент
Инструмент контроля доступа. Содержит даты действия, тип и счётчик
SessionsLeft — уменьшается на 1 при каждом фактическом посещении.
Client → Membership
1:N
Client → Booking
Клиент делает несколько записей
1:N
Membership → Booking
Абонемент используется в записях
Workout / Занятие
1:N
Событие в расписании. Привязано к тренеру, залу и категории. Имеет параметр
MaxCapacity — индивидуальный лимит участников.
1:1
На занятие записано много клиентов
Booking → Attendance
Одна запись — одно посещение (или нет)
1:N
Trainer → Workout
Тренер проводит несколько занятий
Booking / Запись ★
Центральная связующая сущность. Объединяет клиента, абонемент и занятие в
единую цепочку оказания услуги. Хранит статус и момент бронирования.
Workout → Booking
1:N
Hall → Workout
В зале проводится несколько занятий
1:N
WorkoutCategory → Workout
Категория классифицирует занятия
Attendance / Посещение
1:N
Факт оказания услуги. Связана с Booking отношением 1:1. Фиксирует время
прихода/ухода. При неявке запись не создаётся — SessionsLeft не списывается.
1:N
ФГБОУ ВО «Нижневартовский государственный университет»
Client → Payment
Клиент совершает несколько платежей
Membership → Payment
Абонемент оплачивается траншами
6 / 13

7.

Нормализация до третьей нормальной формы (3НФ)
Устранение избыточности и аномалий данных
1НФ
2НФ
3НФ
Первая нормальная форма
Вторая нормальная форма
Третья нормальная форма
Все атрибуты атомарны. Устранено хранение
списка посещений внутри карточки клиента
— вынесено в отдельную таблицу Attendance.
Несколько телефонов — отдельные записи.
Устранены частичные зависимости от
составного ключа. «Специализация» зависела
только от тренера → таблица Trainer.
«Вместимость» зависела только от зала →
таблица Hall.
Устранены транзитивные зависимости.
Данные о типе абонемента (цена,
длительность) вынесены в таблицу
MembershipType и связываются через
внешний ключ MembershipTypeID.
Результат: схема из 10 таблиц без избыточности — защита от аномалий вставки, обновления и удаления
ФГБОУ ВО «Нижневартовский государственный университет»
7 / 13

8.

Логическая модель данных: структура и ограничения
Академическое описание ключевых таблиц реляционной базы данных
Client
Membership
Booking
Attendance
Клиенты
Абонементы
Записи
Посещения
ClientID
MembershipID
BookingID
AttendanceID
INTEGER
INTEGER
INTEGER
INTEGER
PK · AUTOINCREMENT · уникальный идентификатор
PK · уникальный идентификатор
PK · уникальный идентификатор
PK · уникальный идентификатор
FullName
ClientID
ClientID
BookingID
VARCHAR(150)
INTEGER
INTEGER
INTEGER
NOT NULL · ФИО клиента
FK → Client · NOT NULL
FK → Client · NOT NULL
FK → Booking · UNIQUE · связь 1:1
Phone
MembershipTypeID
WorkoutID
CheckInTime
VARCHAR(20)
INTEGER
INTEGER
TIMESTAMP
NOT NULL · UNIQUE · международный формат
FK → MembershipType · NOT NULL
FK → Workout · NOT NULL
NOT NULL · время прохода
Email
StartDate / EndDate
MembershipID
CheckOutTime
VARCHAR(100)
DATE
INTEGER
TIMESTAMP
UNIQUE · может быть NULL
NOT NULL · CHECK: EndDate ≥ StartDate
FK → Membership · NOT NULL
CHECK: ≥ CheckInTime · может быть NULL
JoinDate
SessionsLeft
BookingDateTime
Status
DATE
INTEGER
TIMESTAMP
VARCHAR
NOT NULL · DEFAULT CURRENT_DATE
NULL для безлимитных · CHECK ≥ 0
NOT NULL · DEFAULT CURRENT_TIMESTAMP
CHECK: Присутствовал | Неявка
Status
Status
UNIQUE
VARCHAR(20)
VARCHAR(20)
–
CHECK: Новый | Активный | Неактивный |
Заблокирован
Активен | Истек | Заблокирован | Отменен
ограничение (ClientID, WorkoutID)
ФГБОУ ВО «Нижневартовский государственный университет»
8 / 13

9.

Улучшения и исправления исходной модели
Выявленные логические несоответствия и способы их устранения
1
SessionsLeft в Membership
2
Атрибут отсутствовал в исходной схеме. Без него
невозможно реализовать автоматическое
списание занятий при фиксации посещения.
4
Кардинальность Workout→Trainer
Исправлена с «0» на «1:N»: каждое занятие
обязательно проводится одним тренером —
«ноль тренеров» недопустимо по смыслу.
ФГБОУ ВО «Нижневартовский государственный университет»
Таблица WorkoutCategory
3
Вынесена отдельной справочной сущностью для
фильтрации расписания по направлениям (йога,
кроссфит, пилатес) и тематических отчётов.
5
UNIQUE(ClientID, WorkoutID)
Добавлено ограничение в Booking: один клиент
не может быть записан на одно занятие дважды
— формализация бизнес-правила.
Таблица Payment
Введена для прозрачного финансового учёта:
дата, сумма, способ оплаты (наличные / карта /
онлайн), статус транзакции.
6
Атрибуты Status, HireDate
Добавлены в Client, Trainer, Workout для
обработки временной недоступности без
физического удаления записей из БД.
9 / 13

10.

Примеры информационных SQL-запросов
Проверка работоспособности спроектированной логической модели
Свободные места на занятиях
Валидность абонемента клиента
Поиск актуальных занятий с наличием мест на указанную дату
Проверка активного абонемента перед записью на занятие
SELECT w.WorkoutName, (w.MaxCapacity - COUNT(b.BookingID)) AS SeatsLeft
FROM Workout w
LEFT JOIN Booking b
ON w.WorkoutID = b.WorkoutID
AND b.Status = 'Подтверждена'
WHERE DATE(w.WorkoutDateTime) = '2026-06-20'
AND w.Status = 'Запланировано'
GROUP BY w.WorkoutID, w.MaxCapacity
HAVING SeatsLeft > 0
ORDER BY w.WorkoutDateTime;
SELECT m.MembershipID, mt.TypeName
m.EndDate, m.SessionsLeft
FROM Membership m
JOIN MembershipType mt
ON m.MembershipTypeID = mt.MembershipTypeID
WHERE m.ClientID = 12345
AND m.Status = 'Активен'
AND m.EndDate >= CURRENT_DATE
AND (m.SessionsLeft IS NULL OR
m.SessionsLeft > 0);
Выручка по типам абонементов
История посещений клиента
Финансовая аналитика с группировкой по месяцам
Персональный отчёт за произвольный период
SELECT mt.TypeName, EXTRACT(YEAR FROM p.PaymentDate) AS Year
EXTRACT(MONTH FROM p.PaymentDate) AS Month
SUM(p.Amount) AS TotalRevenue
FROM Payment p
JOIN Membership m ON p.MembershipID = m.MembershipID
JOIN MembershipType mt ON m.MembershipTypeID = mt.MembershipTypeID
WHERE p.Status = 'Проведен'
GROUP BY mt.TypeName, Year, Month
ORDER BY Year, Month, mt.TypeName;
SELECT a.CheckInTime, w.WorkoutName
t.FullName AS TrainerName, h.HallName, a.Status
FROM Attendance a
JOIN Booking b ON a.BookingID = b.BookingID
JOIN Workout w ON b.WorkoutID = w.WorkoutID
JOIN Trainer t ON w.TrainerID = t.TrainerID
JOIN Hall h ON w.HallID = h.HallID
WHERE b.ClientID = 12345
AND a.CheckInTime BETWEEN '2026-06-01' AND '2026-06-30'
ORDER BY a.CheckInTime;
ФГБОУ ВО «Нижневартовский государственный университет»
10 / 13

11.

Тестирование SQL-запросов: симуляция результатов
Проверка корректности логической модели на эмулированных данных
Тестовый датасет: 5 клиентов · 3 тренера · 4 зала · 8 занятий · 12 записей · 10 посещений · 5 платежей
Запрос 1 — свободные места (дата: 2026-06-20)
Запрос 2 — абонемент клиента #12345
WorkoutName
Тренер
Зал
SeatsLeft
Йога. Утренний поток
Смирнова Е.В.
Студия йоги
3
Абонемент 30 дней
Кроссфит. Базовый
Козлов А.П.
Зал ОФП
7
✓ Абонемент активен — запись разрешена
Пилатес. Баланс
Смирнова Е.В.
Зал групп.
1
Запрос 3 — выручка по типам (2026 г.)
TypeName
Month
TypeName
StartDate
2026-06-01
EndDate
2026-06-30
SessionsLeft
NULL (безлим.)
Запрос 4 — история посещений клиента #12345
TotalRevenue
PaymentsCount
CheckInTime
WorkoutName
Trainer
Status
Абонемент 30 дней
4
42 000 ₽
6
2026-06-03 09:02
Йога. Утренний поток
Смирнова Е.В.
Присутство
вал
Абонемент 30 дней
5
35 000 ₽
5
2026-06-07 10:15
Пилатес. Баланс
Смирнова Е.В.
Присутство
вал
Пакет 10 занятий
4
18 500 ₽
3
2026-06-10 08:55
Кроссфит. Базовый
Козлов А.П.
Присутство
вал
Пакет 10 занятий
5
22 000 ₽
4
2026-06-14 09:00
Йога. Утренний поток
Смирнова Е.В.
Неявка
Годовой безлимит
4
65 000 ₽
2
2026-06-18 18:30
Силовая. Продвинутый
Орлов Д.С.
Присутство
вал
ФГБОУ ВО «Нижневартовский государственный университет»
11 / 13

12.

Результаты курсового проекта
Достигнутые цели и практическая значимость
Анализ
предметной области
Концептуальная
ER-модель
Логическая
модель (3НФ)
Выявлено 8 критических недостатков. Сравнительный
анализ 4 рыночных аналогов. Сформулировано 15 FR и
6 NFR.
10 сущностей в нотации Чена. Booking — центральный
объект, связывающий клиента, абонемент и занятие.
10 реляционных таблиц без избыточности. PK, FK,
UNIQUE, CHECK. Исправлено 8 логических
несоответствий.
SQL-запросы
и тестирование
Практическая
значимость
Перспективы
развития
6 типовых запросов. Тестирование на симуляции:
свободные места, валидация, выручка, история
посещений.
Время обслуживания: 180 с → 20-30 с. Исключены
конфликты расписания. Прозрачный финансовый учёт.
UI администратора и клиента, мобильное приложение,
интеграция с эквайрингом, ML-прогнозирование
загрузки.
ФГБОУ ВО «Нижневартовский государственный университет»
12 / 13

13.

Спасибо за внимание!
Готов ответить на вопросы.
✓ Разработана ER-модель из 10 сущностей в нотации Чена
✓ Построена логическая схема реляционной БД, нормализованная до 3НФ
✓ Устранено 8 логических несоответствий исходной схемы
✓ Проведено тестирование на симулированных данных — 4 SQL-запроса
✓ Сформировано 15 функциональных и 6 нефункциональных требований
Герасимов И.Р. | группа ИиВТ-3312 | науч. рук. Мамедли Р.Э.