erDiagram
companies ||--o{ agro_fields : "manages"
agro_fields ||--o{ tracking_sessions : "hosts"
crop_standards ||--o{ tracking_sessions : "defines parameters"
tracking_sessions ||--o{ tracking_event_log : "generates events"
tracking_sessions ||--o{ voice_transcripts : "buffers speech"
tracking_sessions {
uuid session_id PK
int user_id FK
int field_id FK
varchar activity_type
varchar status
timestamp end_time
int total_duration_seconds
}
tracking_event_log {
int event_id PK
uuid session_id FK
varchar activity_name
timestamp timestamp
jsonb payload
}
voice_transcripts {
int transcript_id PK
uuid session_id FK
uuid correlation_id
varchar raw_audio_path
text recognized_text
numeric parsed_quantity
varchar vtt_status
}
Проектирование ER-диаграммы сущностей приложения
Принципы реляционного моделирования и спецификация сущностей для смешанных операционных сред
1 Введение и назначение спецификации
Данный документ представляет собой базовое архитектурное описание реляционной модели данных верхнего уровня (Top-Level ERD) для платформы цифровых симуляторов. Модель разработана как инвариантное ядро, способное обеспечивать сквозной жизненный цикл фиксации событий, абстрагируясь от изменчивых правил конкретных прикладных бизнес-проектов.
Главная задача настоящей спецификации — зафиксировать логическую схему движения состояний, определить типы и силу межтабличных связей (Cardinality), а также описать выбор полуструктурированных и транзакционных сущностей. Проектирование дата-слоя ориентировано на создание универсальной шины хранения, которая изолирует шаги сложных распределенных процессов и накапливает консистентные операционные логи.
2 Теоретические основы и практическая роль ER-диаграмм
Диаграмма «сущность–связь» (Entity-Relationship Diagram, ERD) представляет собой инструмент визуального и структурного моделирования реляционных баз данных. В сложных программных комплексах ERD выполняет роль декларативного контракта между системными архитекторами, DevOps-инженерами и разработчиками бэкенда.
2.1 Задачи, решаемые внедрением ER-модели:
- Формализация бизнес-логики: Перевод абстрактных регламентов оперирования на язык реляционных отношений, ограничений целостности (Foreign Keys) и уникальности данных.
- Предотвращение транзакционного оверхеда:1 Определение оптимального баланса между нормализацией справочников (измерений) и денормализацией таблиц фактов под высокими нагрузками.
- Обеспечение консистентности трассировки: Создание сквозных цепочек идентификаторов, связывающих пользовательский ввод с внутренними системными логами.
2.2 Специфика единого дата-слоя для реальных пользователей и цифровых двойников
Ключевая инженерная задача при проектировании архитектуры данных симулятора заключается в том, что спроектированные таблицы и интерфейсы СУБД являются совместно используемыми (Shared Data Layer). Модель данных не разделяется на «клиентскую» и «эмуляционную»:
- Идентичность сетевого и транзакционного следа: Когда реальный сотрудник выполняет операцию в мобильном приложении, система инициирует точно такие же реляционные транзакции, какие генерируют боты цифровых симуляторов при ускоренном воспроизведении сценариев.
- Синхронизация Master Data: И боты, и люди обращаются к единым эталонным каталогам и матрицам разрешений. Это гарантирует, что синтетические данные, накопленные в процессе симуляции, по своей структуре и ограничениям абсолютно идентичны реальным логам.
- Прозрачность для бизнес-анализа: Использование общих таблиц сессий и событий позволяет внешним аналитическим инструментам бесшовно обрабатывать смешанный трафик, выявляя скрытые зацикливания и инфраструктурные заторы по единым алгоритмам.
3 Концептуальное проектирование ER-диаграммы ядра платформы (для приложения AgroLaborApp)
Для обеспечения максимальной пропускной способности СУБД при одновременной обработке действий реальных пользователей и плотных потоков синтетического трафика от симуляторов, структура данных сведена к компактному архитектурному ядру.
NoteМетодология декомпозиции схемы Data Reduction
Для оптимизации визуального восприятия и предотвращения перегрузки архитектурного графа, из схемы намеренно исключены очевидные связующие таблицы прав доступа (user_field_permissions, user_activity_permissions), промежуточные перекрестные справочники (field_allowed_activities) и низкоуровневые системные поля.
На схеме отображено исключительно концептуальное ядро платформы: долгоживущие таблицы измерений (companies, agro_fields, crop_standards), транзакционные сессии оперирования (tracking_sessions), а также полуструктурированные буферы логирования атомарных событий (tracking_event_log) и транскрипции голосовых потоков (voice_transcripts). Атрибуты технического логирования, суррогатные ключи связей и базовые константы инкапсулированы и опущены.
3.1 Диаграмма связей сущностей ядра системы (Entity Relations Diagram)
WarningВажное примечание
В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.
Ниже представлена компактная архитектурная схема реляционных контуров, фиксирующая жизненный цикл сессий оперирования, генерации телеметрии и прохождения буферов распознавания данных:
4 Архитектурный анализ реляционных доменов данных
NoteСправка по разделу
Архитектурный анализ реляционных доменов данных — это специализированный раздел технической документации, который объясняет, как и почему единая база данных проекта разделена на изолированные смысловые зоны (домены), и как эти зоны взаимодействуют друг с другом.
4.1 Контур транзакционных сессий и координации (tracking_sessions)
Сущность tracking_sessions выступает центральным узлом фиксации жизненного цикла любых процессов в системе. Поля этой таблицы спроектированы как общие инфраструктурные рельсы:
- Синхронизация субъектов и зон оперирования: Поля
user_idиfield_idсвязывают сессию с конкретным исполнителем (человеком или ботом-симулятором) и пространственными границами объекта (agro_fields). Это позволяет системе применять идентичные правила валидации к действиям любого типа. - Управление условными переходами: Поле
statusконтролирует текущую стадию сессии. Ограничение длительности и логика переходов состояний напрямую зависят от фонового пересчета параметров по таймеру (SES-250), что предотвращает застревание незавершенных сессий в СУБД.
4.2 Слой асинхронного логирования и гибких схем фактов (tracking_event_log)
- Инкапсуляция денормализованных событий: Таблица
tracking_event_logфункционирует какAppend-Only хранилище атомарных событий сессии. Связь с сессией по ключуsession_id(\(1:M\)) обеспечивает строгую реляционную целостность.
NoteАрхитектурное обоснование Append-Only & Атомарности
Использование модели Append-Only (полный отказ от операций UPDATE и DELETE в ядре) гарантирует линейную скорость последовательной записи логов телеметрии на физический диск без транзакционных блокировок строк (Row Locks).
Атомарность и неизменяемость исторических фактов сессии обеспечивают математическому движку Affinity Decay (постепенное уменьшение веса старых взаимодействий пользователя с объектом) две фундаментальные гарантии: 1. Точный расчет \(\Delta t\): Время деградации вычисляется напрямую через MAX(event_timestamp) без ресурсоемкого восстановления состояний. 2. Идемпотентность (Time Travel)2: Возможность полной перезагрузки и пересчета веса старых взаимодействий пользователя с объектом в профиле с нуля за любой исторический период при изменении коэффициентов взаимосвязи \(\lambda\).
- Гибкость полуструктурированных данных: Интеграция типа данных
JSONBдля поляpayload— это стратегическое архитектурное решение. Оно позволяет симуляторам динамически менять состав, вложенность и схемы передаваемых параметров телеметрии, не затрагивая физическую структуру таблиц СУБД и изолируя распределенные транзакции от оверхеда на DDL-операции.
4.3 Буфер асинхронной транскрипции и обучения ИИ (voice_transcripts)
- Изоляция вычислительного слоя: Сущность
voice_transcriptsизолирует транзакционный контур бизнес-логики от тяжелых фоновых вычислений ИИ-нод (gRPC Service). Сюда асинхронно складываются ссылки на медиафайлы (raw_audio_path) и промежуточные результаты распознавания Whisper. - Трассировка и сбор датасетов: Поле
correlation_idсвязывает транскрипт со сквозными логами очередей Kafka, обеспечивая выполнение задачиSES-233(Error Handling & Tracing). Полеvtt_statusконтролирует жизненный цикл распознавания, позволяя выгружать пары “сырой текст — эталон” для дообучения нейросетей.
5 Детальные спецификации ключевых транзакционных сущностей
В соответствии с методологией декомпозиции схемы данных, детальному системному анализу подлежат исключительно ключевые транзакционные таблицы. Данные сущности инкапсулируют сложную логику асинхронной координации, условные переходы конечного автомата состояний и полуструктурированные типы данных, что определяет их универсальную архитектурную ценность как для симуляторов, так и для реальных пользователей.
5.1 Контур координации и time_tracking(хронометража) сессий (tracking_sessions)
Таблица tracking_sessions функционирует как центральный реляционный рельс платформы. В момент, когда реальный сотрудник агро комплекса через интерфейс или бот-симулятор в рамках скрипта эмуляции активируют операцию, бэкенд FastAPI генерирует уникальную строку сессии, изолируя транзакционный контекст выполнения.
5.2 Слой асинхронного логирования телеметрии (tracking_event_log)
Сущность tracking_event_log решает задачу накопления плотных массивов данных. Использование полуструктурированного формата JSONB для поля payload позволяет эффективно аккумулировать транзакции смешанной среды. Симуляторы и реальные мобильные клиенты записывают атомарные события в одну таблицу, не перегружая СУБД частыми изменениями физических схем.
5.3 Буфер асинхронной транскрипции и обучения ИИ (voice_transcripts)
Сущность voice_transcripts изолирует транзакционную бизнес-логику от тяжелых вычислений на gRPC-нодах ИИ. Таблица выступает в роли общего буфера для Сценария Б (голосовой ввод). Фиксация пары «сырой текст — скорректированное значение» позволяет накапливать чистые датасеты для последующего дообучения Whisper, контролируя консистентность через жизненный цикл поля vtt_status.
6 Заключение
Проектирование схемы данных верхнего уровня (Top-Level ERD) на базе концептуального абстрагирования позволило сформировать инвариантный дата-слой, независимый от специфики конкретных бизнес-приложений.
Совместное использование разработанной структуры tracking_sessions и tracking_event_log как реальными пользователями (через интерфейсы Flutter), так и автоматизированными ботами симулятора гарантирует абсолютную идентичность сетевого и транзакционного следа. Внедрение полуструктурированных хранилищ (JSONB payload) обеспечило гибкость эволюции схем данных без деградации производительности СУБД, а асинхронные буферы voice_transcripts изолировали вычислительную нагрузку ИИ-сервисов. Спроектированная топология сущностей полностью готова к развертыванию миграционного слоя СУБД и накоплению чистых операционных логов для последующего системного анализа.
7 Приложение A: Конвейеры фонового пересчета пайплайна (Affinity Decay Pipeline) (Вариант для AgroLaborApp)
Для симуляции реалистичного поведения цифровых двойников недостаточно использовать фиксированные статические профили. Поведенческие паттерны автоматизированных агентов должны динамически эволюционировать во времени под воздействием внутренних триггеров (накопление усталости, деградация ресурсов, изменение приоритетов сессий). За выполнение этой задачи отвечает фоновый архитектурный конвейер пересчета матрицы угасания интереса предпочтений (Affinity Decay Matrix), функционирующий по таймеру (SES-250).
Процесс реализует концепцию процесса экспоненциального угасания интереса (Exponential Decay), где текущее значение склонности агента к определенному действию или выбору узла (\(A_t\)) рассчитывается на основе его базового веса (\(A_0\)) и времени, прошедшего с момента закрытия последней активной сессии (\(\Delta t\)):
\[A_t = A_0 \cdot e^{-\lambda \cdot \Delta t}\]
Где \(\lambda\) — коэффициент интенсивности падения интереса, индивидуальный для каждого психотипа субъекта (h_deviation).
7.1 Схема взаимодействия компонентов при фоновом пересчете
Фоновый процесс пересчета полностью изолирован от синхронного API-шлюза FastAPI, чтобы исключить деградацию времени ответа для реальных пользователей. Задача вынесена на уровень асинхронных воркеров, координируемых внутренним планировщиком задач.
WarningВажное примечание
В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.
Ниже представлена диаграмма последовательности выполнения фонового конвейера по таймеру:
sequenceDiagram
autonumber
participant Cron as ⏱️ Планировщик Задач (Celery / APScheduler)
participant Worker as ⚙️ Фоновый Воркер (Worker Node)
participant DB as 🗄️ PostgreSQL (Business DB)
participant Kafka as 📨 Apache Kafka Broker
Cron->>Worker: Срабатывание таймера (Интервал: X сек)
activate Worker
%% Блокировка и выгрузка активных матриц
Worker->>DB: SELECT * FROM map_habits_matrix WHERE is_active = TRUE
activate DB
DB-->>Worker: Возврат текущих весов и коэффициентов двойников
deactivate DB
Note over Worker: Анализ закрытых сессий в tracking_sessions.<br/>Расчет дельты времени Δt для каждого user_id.
loop Для каждого активного цифрового двойника
Worker->>Worker: Вычисление веса(-ов) экспоненциального падения интереса (Affinity Decay)
Worker->>Worker: Модификация коэффициентов h_intensity и h_anxiety
end
%% Атомарное обновление СУБД
Worker->>DB: UPDATE map_habits_matrix SET h_intensity = ..., h_anxiety = ... WHERE user_id = ...
activate DB
DB-->>Worker: Подтверждение фиксации транзакции
deactivate DB
%% Пуш обновленных весов в шину данных для симулятора
Worker->>Kafka: Пуш DTO в топик "simulator.habits.updates" (Обновленные матрицы)
Note over Worker, Kafka: Симуляторы на внешнем периметре подхватывают<br/>новые веса без перезапуска контейнеров
deactivate Worker
7.2 Системные требования к конвейеру пересчета
- Предотвращение эффекта «гонки за данными» (Race Conditions): Фоновые воркеры осуществляют запись изменений в таблицу
map_habits_matrixс использованием оптимистической блокировки или изолированных пакетов транзакций. Если реальный пользователь в этот же момент совершает действие, требующее изменения его профиля, приоритет записи отдается синхронной транзакции бэкенда FastAPI, а фоновый пересчет сдвигается на следующий шаг таймера. - Амортизация дискового ввода-вывода (IO-Bound Mitigation): Чтобы массовый пересчет тысяч матриц ботов-симуляторов не вызывал выгорания транзакционного лога СУБД (WAL PostgreSQL), воркер производит пакетное обновление (Bulk Update). Изменения накапливаются в оперативной памяти воркера и сбрасываются в персистентный (постоянный) слой СУБД единым скоординированным SQL-запросом.
- Синхронизация через Event-Driven шину: Сразу после фиксации изменений в PostgreSQL, обновленные коэффициенты «интереса» и «стресса» транслируются в топик Apache Kafka. Движки симуляции, управляющие поведением ботов на внешнем периметре, считывают этот стрим в неблокирующем режиме. Это позволяет ботам мгновенно корректировать свои поведенческие тайминги и условные переходы в
tracking_sessions«на лету», без необходимости постоянного выполнения тяжелыхSELECTзапросов к СУБД.
8 Источники и нормативные спецификации
- Стандарты моделирования и структуры данных:
- Спецификации реляционного моделирования данных и языковых стандартов: ANSI/ISO/IEC 9075-1:2023 Information technology — Database languages — SQL
- Требования к валидации и индексированию полуструктурированных документов: PostgreSQL Global Development Group: JSON Types and JSONB Storage Documentation
- Стандарты генерации и валидации уникальных системных идентификаторов: RFC 9562 Universally Unique Identifier (UUID) Specification
- Протоколы межсервисного взаимодействия и ИИ:
- Архитектура асинхронной координации фоновых задач бэкенда: FastAPI Core Concurrency and Background Tasks Spec
- Спецификации бинарной сериализации в распределенных средах: Protocol Buffers Version 3 Language Guide
- Интеграция пространственных и медиа-контуров:
- Стандарты обмена и кодирования геоданных в веб-интерфейсах: RFC 7946 The GeoJSON Format Specification
- Спецификации развертывания облачных хранилищ неструктурированных объектов: MinIO Object Storage Core Architecture Guide
Footnotes
Транзакционный оверхед (от англ. transactional overhead — транзакционные накладные расходы) — это избыточные затраты вычислительных ресурсов (процессора, памяти, сети, дискового I/O) и времени, которые система тратит на обеспечение атомарности, согласованности, изолированности и надежности передачи или записи данных.↩︎
Паттерн проектирования хранилищ данных. Он гарантирует, что повторная обработка одного и того же события не изменит состояние системы, а любое историческое состояние можно восстановить на любой момент времени.↩︎