CC BY
7
ТЕХНИЧЕСКИЕ НАУКИ TECHNICAL SCIENCES
Научная статья
УДК 004.65
ББК 32.972.13
Р 93
DOI: 10.53598/2410-3225-2023-3-326-40-47
Автоматный подход к реализации логики автоматизируемых бизнес-процессов в реляционных базах данных
(Рецензирована)
1 2 Александр Александрович Рыбанов , Ольга Викторовна Свиридова ,
3
Евгения Михайловна Филиппова
1 2 Волжский политехнический институт (филиал) Волгоградского государственного технического университета, Волжский, Россия
1 rybanoff@yandex.ru
2 osviridova@inbox.ru
3 Волгоградский государственный социально-педагогический университет, Волгоград, Россия, em_filippova@mail.ru
Аннотация. Бизнес-логика или логика предметной области - это алгоритм, определяющий способ обмена информацией между базой данных и приложением конечного пользователя. В статье предлагается автоматный подход к встраиванию в реляционные базы данных логики автоматизируемых бизнес-процессов. Описаны этапы реализации бизнес-логики на языке SQL. Результаты тестирования предлагаемого подхода рассмотрены на примере бизнес-процесса «управление заказами» с использованием системы управления базами данных PostgreSQL.
Ключевые слова: бизнес-логика, бизнес-процесс, конечный автомат, postgreSQL, базы
данных
Original Research Paper
Automata-based approach to automated business process logic
in relational databases
1 2 3
Aleksandr A. Rybanov , Olga V. Sviridova , Evgeniya M. Filippova
1 2 Volzhsky Polytechnical Institute, Branch of the Volgograd State Technical University, Volzhskiy, Russia
1 rybanoff@yandex.ru
2 osviridova@inbox.ru
3 Volgograd State Socio-Pedagogical University, Volgograd, Russia, em_filippova@mail.ru
Abstract. Business or domain logic is an algorithm that defines how information is exchanged between a database and an end-user application. The article proposes an automata-based approach to embedding automated business process logic into relational databases. The steps of implementing business logic in SQL are described. The results of testing the proposed approach are considered on the example of the business process "order management" using the PostgreSQL database management system.
Keywords: business logic, business process, state machine, postgreSQL, databases
Введение. Конечный автомат - это математическая абстракция, используемая для разработки алгоритмов. Конечные автоматы и реляционная база данных [1-4] могут выглядеть совершенно не связанными друг с другом инструментами, однако они образуют интересную пару.
В работе [5] представлен архитектурный шаблон, основанный на конечных автоматах Smalldb [6]. Основная идея состоит в том, чтобы представить каждую сущность на уровне модели с помощью конечного автомата Smalldb, постоянного недетерминированного конечного автомата, который состоит из декларативного формального определения, реализации переходов и постоянного хранилища данных.
В работе [7] предложен новый способ репликации базы данных в кластере серверов, основанный на аппарате конечных автоматов. Предлагаемый конечный автомат базы данных основан на методе отложенного обновления. При использовании этого метода транзакции обрабатываются локально на одном сервере базы данных и во время фиксации пересылаются для сертификации на другие серверы.
В работе [8] представлен новый метод достижения целостности в логически связанных подмножествах данных в реляционных базах данных, использующий теорию конечных автоматов.
Непосредственное встраивание логики бизнес-процессов предметной области в базу данных остается актуальной задачей. Целью работы является снижение трудоемкости реализации контроля логики автоматизируемых бизнес-процессов путем ее моделирования аппаратом конечных автоматов и реализации на языке SQL.
Модель конечного автомата. Определим понятие конечного автомата как совокупность компонент:
M=(Q, V, 5, qo, F),
где Q - конечное, непустое множество (внутренние состояния автомата);
V - конечное непустое множество (множество допустимых входных символов автомата);
5 - функция переходов, которая определяет для некоторых пар (q;, x), где q;e Q, xe V, новое состояние qj: 5(q;,x)=qj ;
q0e Q - начальное состояние автомата;
F<^ Q - множество заключительных состояний автомата.
Конечные автоматы как способ описания бизнес-логики предметной области. Бизнес-логика или логика предметной области - это алгоритм, определяющий способ обмена информацией между базой данных и приложением конечного пользователя. Он включает в себя реальные бизнес-правила и рабочие процессы, определяющие взаимодействие между пользователями и программным обеспечением. Визуальная природа конечных автоматов (и бизнес-процессов) обеспечивает общий язык между заказчиками, архитекторами и разработчиками: чем проще общение, тем лучше спецификация и, следовательно, удешевляется процесс разработки.
Для моделирования потока логики внутри программы, представления состояний системы или для моделирования потока событий в бизнес-процессе широко используется теория конечных автоматов. Процесс представления бизнес-логики в виде конечного автомата рассмотрим на примере требований к системе управления заказами:
- заказы не должны быть отправлены покупателю до их оплаты;
- заказы могут быть отменены, но только если они еще не отправлены;
- денежные средства за заказ, который уже был оплачен, должны быть возвращены покупателю после отмены заказа.
Граф конечного автомата, моделирующий представленную выше бизнес-логику,
приведен на рисунке 1.
Рис. 1. Граф конечного автомата для бизнес-процесса «управление заказами» Fig. 1. State machine graph for the "order management" business process
Граф конечного автомата может быть полезен для обсуждения и анализа бизнес-логики предметной области. Например, можно сразу увидеть, что у клиента нет возможности отменить заказ после его отправки. Кроме того, процесс именования используемых состояний и событий автоматически создает точный язык, который может быть принят всеми заинтересованными сторонами проекта. На рисунке 1 показаны не все возможные комбинации всех состояний и всех событий. Причина в том, что пропущенные комбинации неявно приводят к состоянию ошибки.
Реализация конечного автомата средствами SQL. Реализацию конечного автомата рассмотрим на примере объектно-реляционной системы баз данных PostgreSQL. Для информационной поддержки процесса учета событий в системе управления заказами создадим таблицу orderevents (табл. 1), в которой для каждого заказа (orderid) будут фиксироваться все связанные с ним события: наименование события (event) и время наступления события (time).
Таблица 1. SQL-команда создания таблицы orderevents Table 1. SQL command to create the table of orderevents
CREATE TABLE order_events ( id serial PRIMARY KEY, order_id int NOT NULL, event text NOT NULL,
time timestamp DEFAULT now() NOT NULL )_
Функцию переходов конечного автомата, моделирующего бизнес-процесс, реализуем в виде sql-функции со следующей сигнатурой (табл. 2):
order_events_transition(state text, event text) RETURNS text,
где state - состояние бизнес-процесса; event - событие бизнес-процесса.
Функция перехода состояний order_events_transition(state, event) определяет, как конечный автомат бизнес-процесса меняет состояние state в ответ на событие event. Если конечный автомат находится в состоянии statex и получает событие eventx, то новым состоянием конечного автомата будет:
statey=order_events_transition(statex, eventx). Часто функции перехода состояний разрешается возвращать специальное значе-
ние, не являющееся состоянием, чтобы указать, что следующего состояния нет. В этом случае ввод не соответствует бизнес-логике, и говорят, что конечный автомат отклоняет его. В случае конечного автомата бизнес-процесса это сообщение об ошибке.
Таблица 2. SQL-реализация функции переходов order_events_transition(state, event) конечного автомата для бизнес-процесса «управление заказами»
Table 2. SQL implementation of the transition function order_events_transition(state, event) of the state machine for the business process "order management"
CREATE FUNCTION order_events_transition(state text, event text) RETURNS text
LANGUAGE sql AS
$$
SELECT CASE state
WHEN 'start' THEN CASE event
WHEN 'create' THEN 'awaiting_payment' ELSE 'error' END
WHEN 'awaiting_payment' THEN CASE event
WHEN 'pay' THEN 'awaiting_shipment' WHEN 'cancel' THEN 'canceled' ELSE 'error' END
WHEN 'awaiting_shipment' THEN CASE event
WHEN 'cancel' THEN 'awaiting_refund' WHEN 'ship' THEN 'shipped' ELSE 'error' END
WHEN 'awaiting_refund' THEN CASE event
WHEN 'refund' THEN 'canceled' ELSE 'error' END
ELSE 'error' END
$$;_
При реализации sql-функции переходов конечного автомата использованы следующие обозначения:
- события: create (создание заказа), pay (оплата заказа), ship (отправление заказа), cancel (отмена заказа), refund (расходы возмещены);
- состояния: start (начало), awaiting_payment (ожидание платежа), awaiting shipment (ожидание отгрузки), awaitingrefund (ожидание возмещения), shipped (заказ отправлен), canceled (заказ отменен), error (ошибка).
Для того чтобы применить функцию конечного автомата order_events_transition(state, event) ко всем записям одного и того же заказа orderid таблицы orderevents, необходимо взять список событий и рекурсивно вызвать функцию перехода для определения результирующего состояния, начиная с начального состояния start. В PostgreSQL это можно сделать несколькими способами, но самым эффективным является определяемый пользователем агрегат. Агрегат - это функция, имеющая внутреннее значение (состояние), которое обновляется для каждого входного значения, передаваемого в него с помощью функции перехода состояния.
В агрегатной функции order_events_fsm(text) указывается тип данных для состояния (STYPE), функции (SFUNC) и еще начальное значение состояния (INITCOND)
в виде строковой константы (табл. 3).
Таблица 3. SQL-реализация агрегатной функции order_events_fsm(text)
Table 3. SQL implementation of the aggregate function order_events_fsm(text)
CREATE AGGREGATE order_events_fsm(text) ( SFUNC = order_events_transition, STYPE = text, INITCOND = 'start'
J;_
Агрегатная функция order_events_fsm(text) принимает в качестве параметра text - состояние бизнес-процесса. PostgreSQL создает временную переменную типа данных STYPE для хранения текущего внутреннего состояния агрегата - state. В каждой входной строке вычисляются агрегированные значения аргументов и вызывается функция перехода состояний SFUNC=order_events_transition(state, event) с текущим значением состояния state и новым значением аргумента event для вычисления нового значения внутреннего состояния state. После обработки всех строк последняя функция вызывается один раз для вычисления возвращаемого значения агрегата state. Тестовый пример, демонстрирующий работу агрегатной функции orderevents_fsm(text), приведен в таблице 4.
Таблица 4. SQL-команда, демонстрирующая работу агрегатной функции
order_events_fsm(text)
Table 4. SQL command demonstrating how an aggregate function order_events_fsm(text)
SELECT order_events_fsm(event ORDER BY id)
FROM (VALUES (1, 'create'), (2, 'pay'), (3, 'cancel')
) examples(id, event);_
Работу функции order_events_fsm(event ORDER BY id) можно представить следующими итерациями:
- итерация 1: awaiting_payment=order_events_transition(start\ 'create');
- итерация 2: awaiting_shipment=order_events_transition(awaiting_payment ',
'pay');
- итерация 3: awaiting_refund=order_events_transition(awaiting_shipment\ 'cancel').
Агрегатная функция order events_fsm(text) является основой триггера BEFORE INSERT для таблицы order events, который будет гарантировать, что все события для заказа orderid соответствуют логике бизнес-процесса и не приводят к состоянию ошибки. Триггер ordereventstrigger создадим с помощью plpgsql функции order_events_tigger_func(), которая вызывает функцию order_events_fsm(text) для всех существующих событий текущего заказа order id и нового события, вставляемого в таблицу order events. В случае, если конечное состояние равно error, вызывается исключение, которое приводит к откату текущей транзакции (табл. 5).
Рассмотрим тестирование предложенного подхода на примере выполнения операции вставки в таблицу order events последовательности событий заказа (табл. 6), соответствующей и не соответствующей бизнес-логике процесса «управление заказами» (рис. 1).
Таблица 5. SQL-реализация триггера ordereventstrigger и триггерной функции order_events_tigger_func()
Table 5. SQL implementation trigger of ordereventstrigger and trigger function order_events_tigger_func()
CREATE FUNCTION order_events_tigger_func() RETURNS trigger LANGUAGE plpgsql AS $$ DECLARE new_state text; BEGIN
SELECT order_events_fsm(event ORDER BY id)
FROM ( SELECT id, event FROM order_events WHERE order_id = new.order_id UNION
SELECT new.id, new.event ) s INTO new_state;
IF new_state = 'error' THEN RAISE EXCEPTION 'invalid event'; END IF;
RETURN new;
END $$;
CREATE TRIGGER order_events_trigger BEFORE INSERT ON order_events FOR EACH ROW EXECUTE PROCEDURE order events tigger func();_
Таблица 6. Тестовая последовательность событий заказа Table 6. Test sequence of order events
_Соответствует бизнес-логике_
INSERT INTO order_events (order_id, event) VALUES (1, 'create'), (1, 'pay'),
(1, 'ship');_
_Не соответствует бизнес-логике_
INSERT INTO order_events (order_id, event) VALUES (2, 'create'),
(2, 'ship');_
При выполнении команды INSERT со значениями, соответствующими бизнес-логике, данные будут добавлены в таблицу (рис. 2).
0 order_events 1 X
<>T SELECT id, orderjd, event FROM order_events
ru 5 Ш ЩМ Jl 123 orderjd Tf J BBC event ТГ1
1 1 1 create
I 1 1 pay
5 3 1 ship
Рис. 2. Результат выполнения команды INSERT для корректных данных Fig. 2. Result of executing the INSERT command for correct data
При выполнении команды INSERT со значениями, не соответствующими бизнес-логике, будет инициировано сообщение об ошибке (рис. 3).
Рис. 3. Результат выполнения команды INSERT для некорректных данных Fig. 3. Result of executing the INSERT command for incorrect data
Заключение. Предложенный подход к встраиванию логики бизнес-процесса в базу данных может быть представлен следующими этапами:
1) создание таблицы productevents, в которой для каждого продукта (услуги) productid бизнес-процесса будут фиксироваться все связанные с ним события: наименование события (event) и время наступления события (time);
2) sql-реализация функции переходов order_events_transition(state, event) конечного автомата для бизнес-процесса;
3) sql-реализация агрегатной функции order_events_fsm(text), которая применяет функцию конечного автомата order_events_transition(state, event) ко всем записям одного и того же продукта (услуги) product id таблицы product events;
4) sql-реализации триггера producteventstrigger BEFORE INSERT для таблицы product events и функции order_events_tigger_func(), которые гарантируют, что все события для продукта (услуги) product id соответствуют логике бизнес-процесса и не приводят к состоянию ошибки.
Примечания
1. Кузьмин А. А., Рыбанов А. А. Исследование методов количественной оценки схем реляционных баз данных // Успехи современного естествознания. 2011. № 7. С. 137-138.
2. Рыбанов А. А. Метрики разнообразия типов данных в физической схеме базы данных MySQL // Вестник Адыгейского государственного университета. Сер.: Естественно-математические и технические науки. 2019. Вып. 4 (251). С. 87-90. URL: http://vestnik.adygnet.ru
3. Черняев А. О., Рыбанов А. А. Разработка и исследование алгоритмов автоматизированного проектирования логических схем реляционных баз данных // В мире научных открытий. 2010. № 4-11 (10). С. 128-129.
4. Kufner J., Marik R. State Machines and SQL Database // IEEE Access. 2019. Vol. 7. P. 144603-144617. DOI: 10.1109/ACCESS.2019.2944807
5. Kufner J., Marik R. State Machine Abstraction Layer // Information and Communication Technology. ICT-EurAsia 2014. Lecture Notes in Computer Science. 2014. Vol. 8407. P. 213-227. DOI: 10.1007/978-3-642-55032-4_21
6. Pedone F., Guerraoui R., Schiper A. The Database State Machine Approach // Distributed and Parallel Databases. 2023. Vol. 14 (1). P. 71-98. DOI: 10.1023/A:1022887812188
7. Malikov A., Voronkin V., Shiryaev N. Employing finite-state machines in data integrity problems // 20th International Conference on Circuits, Systems, Communications and Computers (CSCC 2016). 2016. Vol. 76 (Article Number 04017). P. 8. DOI: 10.1051/matecconf/20167604017
8. Thirumaran M., Dhavachelvan P., Naga Venkata Kiran G. Finite State Machine Based Business Logic Model for Web Services Change Management // International Conference on Advances in Computing and Communications, Cochin, India. 2012. P. 174-177. DOI: 10.1109/ICACC.2012.40
References
1. Kuzmin A.A., Rybanov A. A. Research of quantitative methods for relational database schemes // Successes of Modern Natural Science. 2011. No. 7. P. 137-138.
2. Rybanov A.A. Diversity metrics of data types for physical schema of data base MYSQL // The Bulletin of the Adyghe State University. Ser.: Natural-Mathematical and Technical Sciences. 2019. Iss. 4 (251). P. 87-90. URL: http://vestnik.adygnet.ru
3. Chernyaev A.O., Rybanov A.A. Development and research of algorithms for automated design of relational databases logical schemas // In the World of Scientific Discoveries. 2010. No. 411 (10). P. 128-129.
4. Kufner J., Marik R. State Machines and SQL Database // IEEE Access. 2019. Vol. 7. P. 144603-144617. DOI: 10.1109/ACCESS.2019.2944807
5. Kufner J., Marik R. State Machine Abstraction Layer // Information and Communication Technology. ICT-EurAsia 2014. Lecture Notes in Computer Science. 2014. Vol. 8407. P. 213-227. DOI: 10.1007/978-3-642-55032-4_21
6. Pedone F., Guerraoui R., Schiper A. The Database State Machine Approach // Distributed and Parallel Databases. 2023. Vol. 14 (1). P. 71-98. DOI: 10.1023/A:1022887812188
7. Malikov A., Voronkin V., Shiryaev N. Employing finite-state machines in data integrity problems // 20th International Conference on Circuits, Systems, Communications and Computers (CSCC 2016). 2016. Vol. 76 (Article Number 04017). P. 8. DOI: 10.1051/matecconf/20167604017
8. Thirumaran M., Dhavachelvan P., Naga Venkata Kiran G. Finite State Machine Based Business Logic Model for Web Services Change Management // International Conference on Advances in Computing and Communications, Cochin, India. 2012. P. 174-177. DOI: 10.1109/ICACC.2012.40
Авторы заявляют об отсутствии конфликта интересов.
Статья поступила в редакцию 19.08.2023; одобрена после рецензирования 29.08.2023; принята к публикации 30.08.2023.
The authors declare no conflicts of interests.
The article was submitted 19.08.2023; approved after reviewing 29.08.2023; accepted for publication 30.08.2023.
© А. А. Рыбанов, О. В.Свиридова, Е. М. Филиппова, 2023
