ER-модель системы RetailFlow
Описание
ER-модель описывает логическую структуру базы данных системы RetailFlow.
Система предназначена для автоматизации передачи смен, фиксации задач, контроля выполнения работ и формирования отчетности в розничном магазине.
Модель данных отражает основные объекты системы: пользователей, роли, смены, задачи, записи передачи смены и проверки директором.
Основные сущности
1. Role
Сущность Role хранит роли пользователей системы.
Роли определяют уровень доступа пользователя и набор доступных функций.
Примеры ролей:
– сотрудник магазина;
– старший смены;
– директор / руководитель;
– администратор.
Атрибуты:
| Атрибут | Описание |
|---|---|
| id | уникальный идентификатор роли |
| role_name | название роли |
2. User
Сущность User хранит данные пользователей системы.
Пользователями системы являются сотрудники магазина, старшие смены, директор и администратор.
Атрибуты:
| Атрибут | Описание |
|---|---|
| id | уникальный идентификатор пользователя |
| full_name | ФИО пользователя |
| phone | номер телефона |
| login | логин для входа в систему |
| password_hash | пароль в хешированном виде |
| role_id | ссылка на роль пользователя |
| is_active | статус активности пользователя |
3. Shift
Сущность Shift хранит данные о рабочей смене.
Смена отражает период работы сотрудника и используется для фиксации задач, передачи смены и контроля выполнения работ.
Атрибуты:
| Атрибут | Описание |
|---|---|
| id | уникальный идентификатор смены |
| user_id | сотрудник, ведущий смену |
| start_time | время начала смены |
| end_time | время окончания смены |
| status | статус смены: открыта, передана, закрыта |
| next_user_id | сотрудник, которому передана смена |
4. Task
Сущность Task хранит задачи, которые выполняются сотрудниками в рамках смены.
Задача может быть назначена конкретному сотруднику и связана с определённой сменой.
Атрибуты:
| Атрибут | Описание |
|---|---|
| id | уникальный идентификатор задачи |
| title | название задачи |
| description | подробное описание задачи |
| status | статус выполнения задачи |
| deadline | срок выполнения задачи |
| photo_url | ссылка на фотоотчёт |
| user_id | исполнитель задачи |
| shift_id | смена, к которой относится задача |
5. ShiftRecord
Сущность ShiftRecord хранит запись передачи смены.
Запись передачи смены фиксирует важную информацию, комментарии, проблемы и прикреплённые материалы.
Атрибуты:
| Атрибут | Описание |
|---|---|
| id | уникальный идентификатор записи |
| shift_id | ссылка на смену |
| comment | передаваемая информация или заметки |
| issues | проблемы и несоответствия |
| photo_url | ссылка на приложенные материалы |
| created_at | дата и время создания записи |
6. DirectorCheck
Сущность DirectorCheck хранит результаты проверки директором.
Проверка может относиться к смене целиком или к отдельной задаче.
Атрибуты:
| Атрибут | Описание |
|---|---|
| id | уникальный идентификатор проверки |
| director_id | пользователь-директор, который выполняет проверку |
| shift_id | смена, которую проверяли |
| task_id | задача, которую проверяли |
| comment | комментарий директора |
| check_date | дата проверки |
| status | результат проверки |
Связи между сущностями
Role — User
Одна роль может быть назначена нескольким пользователям.
Каждый пользователь имеет одну роль.
Role 1 ─── * User
User — Shift
Один пользователь может вести несколько смен.
Каждая смена связана с одним сотрудником, который её ведёт.
User 1 ─── * Shift
Также смена может содержать ссылку на следующего сотрудника, которому она передаётся.
User 1 ─── * Shift
В модели это отражается двумя внешними ключами в сущности Shift:
– user_id — сотрудник, который ведёт смену;
– next_user_id — сотрудник, которому передана смена.
User — Task
Один пользователь может быть исполнителем нескольких задач.
Каждая задача назначается одному исполнителю.
User 1 ─── * Task
Shift — Task
Одна смена может содержать несколько задач.
Каждая задача относится к одной смене.
Shift 1 ─── * Task
Shift — ShiftRecord
Одна смена может иметь одну или несколько записей передачи смены.
Каждая запись передачи смены относится к конкретной смене.
Shift 1 ─── * ShiftRecord
User — DirectorCheck
Один директор может выполнить несколько проверок.
Каждая проверка связана с пользователем, который выполнил контроль.
User 1 ─── * DirectorCheck
В модели это отражается через поле director_id в сущности DirectorCheck.
Shift — DirectorCheck
Одна смена может быть проверена директором.
Проверка фиксируется в отдельной сущности DirectorCheck.
Shift 1 ─── * DirectorCheck
Task — DirectorCheck
Проверка директора может относиться к конкретной задаче.
Одна задача может иметь несколько проверок или комментариев руководителя.
Task 1 ─── * DirectorCheck
Логика модели данных
Модель данных RetailFlow отражает основной процесс работы системы.
Пользователь входит в систему под своей ролью. Если это сотрудник магазина, он работает со своей сменой, видит задачи, отмечает выполнение и фиксирует проблемы. Каждая задача связана с конкретной сменой и исполнителем.
Когда смена завершается, создаётся запись передачи смены. В ней сохраняются комментарии, проблемы, фотоотчёты и другая информация, необходимая следующему сотруднику.
Старший смены и директор могут контролировать выполнение задач. Проверки директора фиксируются в отдельной сущности DirectorCheck, что позволяет хранить историю контроля и управленческих замечаний.
Ключевые особенности ER-модели
– пользователи связаны с ролями;
– смены связаны с сотрудниками;
– задачи связаны с исполнителями и сменами;
– запись передачи смены хранит комментарии, проблемы и фотоотчёты;
– директорская проверка может относиться к смене или конкретной задаче;
– модель позволяет хранить историю смен, задач и контроля;
– структура поддерживает разграничение прав доступа по ролям.
Возможные улучшения модели
При дальнейшем развитии системы ER-модель можно расширить.
Возможные доработки:
– добавить сущность Store для хранения магазинов;
– добавить сущность TaskTemplate для шаблонов задач;
– добавить сущность TaskStatusHistory для истории изменения статусов задач;
– добавить сущность Notification для уведомлений;
– добавить сущность Attachment для хранения нескольких фото и файлов;
– добавить сущность Report для сохранённых отчетов;
– добавить сущность AuditLog для фиксации действий пользователей.
