---

ВЫПОЛНИЛ СТУДЕНТ ГРУППЫ 3-09ПС-1
Манукян Артем
Дата выполнения 09.09.2026
Вариант №3. Аренда спортивного инвентаря в вузе























Сущность Инвентарь – хранит данные об имеющемся спортивном инвентаре для аренды
Атрибуты – Код (PK) (числовой), название (строковый), категория (строковый), состояние (строковый), залоговая стоимость (числовой)
Тип связи – многие-ко-многим через промежуточную сущность Аренда, один студент может арендовать много разных единиц инвентаря, одна единица инвентаря в разное время может выдаваться многим разным студентам.
Тип связи – многие-к-одному, одна конкретная запись аренды относится к одной единице инвентаря, но одна единица инвентаря сдается в аренду много раз
Сущность Студенты – хранит данные о студентах ВУЗа
Атрибуты – Номер студенческого (PK) (числовой), ФИО (строковый), группа (строковый)
Тип связи – многие-ко-многим через промежуточную сущность Аренда, один студент может арендовать много разных единиц инвентаря, одна единица инвентаря в разное время может выдаваться многим разным студентам
Сущность Аренда – хранит данные об актах аренды спортивного инвентаря
Атрибуты – Код (PK) (числовой), дата выдачи (дата), планируемая дата возврата (дата), фактическая дата возврата (дата), сумма оплаты (денежный), код инвентаря (FK), номер студенческого (FK)
Тип связи – многие-к-одному, одна конкретная запись принадлежит ровно одному студенту, но у одного студента может быть много аренд одновременно.
Тип связи – многие-к-одному, одна конкретная запись аренды относится к одной единице инвентаря, но одна единица инвентаря сдается в аренду много раз 
Сущность Тренер – хранит данные о работающих в заведении тренерах, которые могут закрепить за собой инвентарь для занятий
Атрибуты - Код (PK) (числовой), ФИО (строковый), специализация (строковый), контакты (строковый)
Тип связи – один-ко-многим, один тренер может закрепить за собой несколько единиц инвентаря
Тип связи – один-ко-многим, один тренер может вести несколько спортивных секций
Сущность Спортивные секции – хранит данные о проводимых спортивных секциях в учебном заведении
Атрибуты – Код (PK) (числовой), название (строковый), расписание (строковый), код тренера (FK) (числовой)
Тип связи – многие-ко-многим через промежуточную сущность Запись, в одну секцию может записаться много студентов, один студент может быть записан в несколько разных секций.
Тип связи – многие-к-одному, несколько секций могут вестись одним и тем же тренером, у каждой секции есть ровно один конкретный тренер
Сущность Журнал ремонта – хранит данные об инвентаре, отправленном на ремонт
Атрибуты – Код (PK) (числовой), дата сдачи (дата), описание поломки (строковый), дата возврата (дата), код инвентаря (FK)
Тип связи – многие-к-одному, одна единица инвентаря может ломаться и сдаваться в ремонт много раз, каждая запись о ремонте относится ровно к одной единице инвентаря
Сущность Запись – хранит данные о том, в какое время и в какие секции записываются студенты 
Атрибуты - Код (PK) (числовой), номер студенческого (числовой) (FK), код секции (FK) (числовой), дата записи (дата)
Тип связи – многие-к-одному, один студент может записаться в разные секции, но каждая запись принадлежит только одному студенту.
Тип связи – многие-к-одному, в одной секции состоит много студентов, но каждая строчка записи относится только к одному студенту.
Бизнес правила: 
1)	Единица инвентаря не может быть выдана студенту, если у нее есть открытая запись об аренде
2)	Фактическая дата возврата инвентаря в записи об аренде не может быть раньше даты его выдачи
3)	Если единица инвентаря передается в ремонт, ее состояние меняется на «В ремонте», и она становится недоступной для аренды студентами и закрепления за собой тренерами
4)	Тренер может закрепить за собой инвентарь только на время проведения тренировки секции, закрепленный инвентарь не может параллельно выдаваться в аренду студентам
5)	Студент может быть записан в одну и ту же спортивную секцию только один раз
Вопросы заказчику:
1)	Есть ли лимит на кол-во единиц инвентаря, которое может взять студент одновременно по одному студенческому билету?
2)	Требуется ли в системе хранить статус внесения/возврата залога?
3)	Нужно ли системе автоматически рассчитывать штраф, если фактическая дата возврата превышает планируемую?
4)	Может ли инвентарь списываться навсегда (если нет возможности вернуть его в эксплуатацию), и нужно ли хранить историю всех ремонтов после списания?
5)	В журнале ремонта фиксируется поломка, но нет связи со студентом. Если студент сломал инвентарь во время аренды, нужно ли привязывать запись о ремонте к конкретному акту аренды, чтобы выставить счет за порчу имущества? 
Вывод: Задача классическая, трудностей не возникло. Больше всего времени заняло проектирование связей типа «многие-ко-многим» между студентами и инвентарем, а также студентами и секциями. Задача была решена путем введения промежуточных сущностей, что позволило привести структуру к 3-й нормальной форме. Также были определены бизнес-ограничения и уточняющие вопросы к заказчику.