ИССЛЕДОВАНИЕ И РАЗРАБОТКА АВТОМАТНОГО ПОДХОДА К РЕАЛИЗАЦИИ ЛОГИКИ АВТОМАТИЗИРУЕМЫХ БИЗНЕС-ПРОЦЕССОВ В РЕЛЯЦИОННЫХ БАЗАХ ДАННЫХ

RESEARCH AND DEVELOPMENT OF AN AUTOMATA-BASED APPROACH TO IMPLEMENTING THE LOGIC OF AUTOMATED BUSINESS PROCESSES IN RELATIONAL DATABASES

Makagonov Dmitry Alexandrovich

Student, Department of Informatics and Programming Technology, Volzhsky Polytechnic Institute - branch of Volgograd State Technical University,

Russia, Volzhsky

Rybanov Alexander Alexandrovich

Scientific Advisor, Candidate of Technical Sciences, Associate Professor, Volzhsky Polytechnic Institute - branch of Volgograd State Technical University,

Russia, Volzhsky

АННОТАЦИЯ

В работе рассмотрен процесс управления приема и обработки жалоб, выполнено исследование предметной области и обоснована необходимость автоматизации жизненного цикла заявок. Предложен авторский автоматный подход, обеспечивающий реализацию логики непосредственно на уровне реляционной базы данных.

ABSTRACT

The paper examines the complaint receiving and processing management, conducts a domain analysis, and substantiates the necessity of automating the request lifecycle. An original automata-based approach is proposed to implement business logic directly at the relational database level. 

Ключевые слова: бизнес-логика; бизнес-процесс; конечный автомат; postgreSQL; базы данных; Python.

Keywords: business logic; business process; finite state machine; PostgreSQL; databases; Python.

 В современных информационных системах организации уделяют особое внимание автоматизации бизнес-процессов. Для описания логики взаимодействия между базой данных и приложением конечного пользователя визуальная природа конечных автоматов обеспечивает общий язык между заказчиками, архитекторами и разработчиками: чем проще общение, тем лучше спецификация и, следовательно, удешевление процесса разработки [1, c. 41].

Эффективная автоматизация данного процесса позволяет сократить сроки реагирования, повысить прозрачность и согласованность операций, а также обеспечить аудит и контроль качества.

Реляционная база данных – тип базы данных, в которой данные находятся в таблицах, которые могут быть связаны с другими таблицами (находиться в отношениях), где каждая строка таблицы представляет собой запись с уникальным идентификатором, называемым ключом [2, c. 14]. В то же время, бизнес-процессы по своей сути являются динамическими системами, проходящими через последовательность состояний в соответствии с определенными правилами и ограничениями.

Рассмотрим типичный процесс обработки жалоб граждан. К ключевым процессам обработки заявок относится: "Регистрация заявки", "Разметка заявки ", "Первичный анализ заявки", "Решение / эскалация заявки", "Контроль статуса и сроков по заявке", "Проверка решения", "Оценка и закрытие заявки" [3, c. 3]. Каждый переход между этими состояниями должен происходить строго при выполнении определенных условий: например, жалоба не может перейти в состояние "Оценка и закрытие заявки" минуя этап "Проверка решения", а после финального закрытия заявки переходы в любые другие промежуточные статусы становятся невозможными. Более того, каждый переход в рамках данного бизнес-процесса может требовать выполнения дополнительных автоматических действий: отправки уведомлений заявителю, создания связанных записей в смежных таблицах и обязательного логирования событий.

Традиционный подход к решению этой задачи заключается в добавлении в таблицу с жалобами поля status или state, хранящего текущее состояние.

Альтернативный подход предполагает реализацию всей логики управления состояниями в коде приложения. При этом используются различные паттерны проектирования, такие как State Pattern или Strategy Pattern, а также специализированные библиотеки для работы с конечными автоматами.

Описанные подходы, несмотря на их распространенность, приводят к серьезным негативным последствиям для информационных систем:

1. Недостаточная надежность;
2. Высокая стоимость сопровождения;
3. Отсутствие единой и формализованной модели поведения.

Для решения выявленных недостатков назрела необходимость в создании специализированного, легковесного программного средства, которое бы позволило декларативно описывать конечный автомат, моделирующий жизненный цикл бизнес-сущности, и интегрировать эту модель непосредственно с объектами базы данных для обеспечения строгой валидации всех операций изменения состояния.

В ходе анализа проектируемой системы были выделены абстракции ролей – акторы, взаимодействующие с программным продуктом:

1. «Клиент» инициирует создание новых сущностей в информационной системе и запрашивает изменение их текущего статуса в процессе жизненного цикла.
2. Администратор – актор, задачи которого лежат в области конфигурационного управления и проектирования бизнес-логики.

В зависимости от потребностей выделенных участников системы, взаимодействующих с ней, были выявлены основные функциональные прецеденты (Use Cases) на рисунке 1.

Рисунок 1. Диаграмма прецедентов системы

Центральным местом в работе системы с объектами бизнес-процессов выступает процесс изменения статуса жалобы. Данный процесс включает в себя обязательную фазу сопоставления операционных данных приложения с декларативными правилами, заданными в метамодели, в ходе которой на уровне ядра СУБД проверяется выполнение всех заданных администратором переходов.

В процессе дальнейшего функционирования клиентское приложение активно взаимодействует с метаданными посредством предоставляемого API.

Система разделена на независимые блоки: метамодель автомата и бизнес-сущности изолированы на уровне схемы базы данных.

Блок метамодели автомата

• Таблица fsm_versions хранит реестр версий конфигураций бизнес-процесса;
• Таблица fsm_states является справочником состояний автомата;
• Таблица fsm_events содержит справочник событий;
• Таблица fsm_transitions является центральным элементом метамодели и реализует функцию переходов автомата;
• Таблица fsm_history представляет собой неизменяемый журнал всех успешных переходов состояний;
• Таблица outbox_tasks реализует паттерн Transactional Outbox для обеспечения надёжной доставки сообщений внешним системам.

Блок бизнес-сущностей

• Таблица complaints имеет технические поля version_id и status_id, которые образуют экземпляр автомата;
• Таблица users хранит учётные записи пользователей, выступающих инициаторами создания жалоб и смены их состояний

Ниже представлена логическая диаграмма базы данных, иллюстрирующая связи между компонентами системы.

Рисунок 2. Логическая диаграмма базы данных

Для обеспечения работоспособности программы изолированно от бизнес-сущностей были разработаны следующие триггеры:

• Триггер инициализации (trg_initialize) автоматически срабатывает при создании жалобы, принудительно связывая её с активной версией бизнес-процесса и устанавливая стартовый статус графа.
• Триггер валидации (trg_validate_transition) активируется при обновлении статуса; блокирует операцию и откатывает транзакцию, если маршрут перехода не разрешен или не выполнены Guard-условия.
• Триггер регистрации событий и внешних-запросов (trg_after_transition) после смены статуса синхронно логирует событие и формирует пакет данных для отправки во внешние системы через очередь Outbox.
• Триггер контроля метамодели (trg_fsm_versions_activate) при активации версии процесса проверяет граф на связность, отсутствие тупиковых и недостижимых состояний, исключая логические ошибки.

Архитектура программного средства реализована как трёхуровневая система, в которой каждый уровень несёт строго определённую функциональную нагрузку. Такое разделение бизнес-логики от кода призвано унифицировать алгоритмы информационных систем, стандартизировать обмен данными между независимыми приложениями и обеспечить возможность модификации структуры данных без изменения алгоритмов [4, с. 30].

На уровне клиентского приложения взаимодействие осуществляется исключительно через REST API по протоколу HTTP/HTTPS, передавая идентификатор сущности, тип сущности и код события, получая в ответ результат выполнения перехода или детализированное сообщение об ошибке.

Прикладной уровень реализован на языке Python 3.9, поддерживающий большое количество библиотек, а также легкость интеграции для взаимосвязи и автоматизации, технологиями, такими как базы данных, API, веб-службы [5, с. 395]. Его функциональная ответственность ограничена следующими задачами: маршрутизацией HTTP-запросов, валидацией входных данных с применением библиотеки Pydantic, формированием SQL-запросов к СУБД, обработкой исключений и преобразованием их в стандартизированные HTTP-ответы, а также асинхронной обработкой задач из очереди Outbox.

Уровень СУБД является центральным компонентом архитектуры. Именно здесь сосредоточена вся логика контроля переходов состояний, обеспечивается целостность данных и формируется неизменяемый журнал аудита. Реализация выполнена на PostgreSQL с использованием процедурного языка PL/pgSQL.

Диаграмма компонентов архитектуры разрабатываемого программного средства представлена на рисунке 3.

Рисунок 3. Архитектура программного средства

В заключение следует подчеркнуть фундаментальную важность требований ACID для обеспечения надежности и транзакционной целостности данных в реляционных СУБД [6, с. 38].

Целостность данных обеспечивается реляционными связями на уровне схемы БД: ссылочная целостность блокирует удаление версий метамодели при наличии связанных объектов и запрещает переходы к несуществующим состояниям. Атрибут version_id во всех ключевых сущностях изолирует элементы разных версий, исключая их смешивание.

Транзакционная атомарность гарантирует откат к согласованному состоянию при любых ошибках, исключая аномалии частичного применения изменений.

Иммутабельность реализуется за счет версионности метамодели. Вместо изменения существующих записей создаются новые версии, что сохраняет историческую достоверность – объекты продолжают работать по правилам той версии метамодели, в рамках которой были созданы.

Список литературы:

1. Рыбанов, А. А. Автоматный подход к реализации логики автоматизируемых бизнес-процессов в реляционных базах данных / А. А. Рыбанов, О. В. Свиридова, Е. М. Филиппова // Вестник Адыгейского государственного университета. Серия 4: Естественно-математические и технические науки. – 2023. – № 3(326).
2. Галигузова, Е. В. Сравнение реляционных и нереляционных СУБД / Е. В. Галигузова, Ю. Е. Илларионова // Символ науки: международный научный журнал. – 2023. – № 1-2. – С. 14-17.
3. Репецкий С.О., Репецкая Н.В. Обработка заявок в IT Service Desk // StudNet. 2021. №5. [Электронный ресурс]. Режим доступа: https://cyberleninka.ru/article/n/obrabotka-zayavok-v-it-service-desk (дата обращения: 17.06.2026).
4. Болдачев, А. Архитектура на основе событийной семантики / А. Болдачев // Открытые системы. СУБД. – 2021. – № 3. – С. 29-32.
5. Шайхатаров, А. Э. Python, как способ оптимизации бизнес-процессов / А. Э. Шайхатаров // Формирование профессиональной направленности личности специалистов - путь к инновационному развития России : сборник статей VI Всероссийской научно-практической конференции, Пенза, 16–17 декабря 2024 года. – Пенза: Пензенский государственный аграрный университет, 2024. – С. 394-398.
6. Костенко, И. П. Обеспечение требований ACID для высоконагруженных СУБД / И. П. Костенко, М. В. Ступина // Молодой исследователь Дона. – 2023. – Т. 8, № 3(42). – С. 35-39.