CC BY
25
УДК 004.652
ФОРМАЛЬНОЕ ПРЕДСТАВЛЕНИЕ ПРАВИЛ В АКТИВНЫХ БАЗАХ ДАННЫХ КАК ПОСЛЕДОВАТЕЛЬНЫХ ВЗАИМОДЕЙСТВУЮЩИХ ПРОЦЕССОВ
С. В. Шибанов, А. Б. Зудов
FORMAL PRESENTATION OF THE RULES IN ACTIVE DATABASES AS A SEQUENCE OF INTERACTING PROCESSES
S. V. Shibanov, A. B. Zudov
Аннотация. Актуальность и цели. Для активных баз данных (АБД) системы управления выполняют не только действия, явно указанные пользователями, но и дополнительные действия в соответствии с правилами, заложенными в саму базу данных. Системы управления активными базами данных (СУАБД) отслеживают возникновение заданных событий и реагируют на них в соответствии с определенными правилами (активными правилами). При этом СУАБД должна контролировать взаимодействие активных правил, в том числе выявлять возможные конфликтные ситуации. Цель исследования - разработка формального представления взаимодействия активных правил в процессе их конструирования и исполнения в СУАБД. Материалы и методы. В качестве формального аппарата для решения поставленных задач выбрана нотация взаимодействующих последовательных процессов, разработанная Ч. Хоаром и относящаяся к классу алгебр событий. В терминах взаимодействующих последовательных процессов описаны свойства наборов активных правил и различные конфликтные ситуации, возникающие в процессе исполнения правил. Результаты. Разработано формальное представление активных правил в АБД как последовательных взаимодействующих процессов. АБД определяется в виде единого процесса, в котором правила и триггеры обрабатывают соответствующие события параллельно. На основе понятия алфавита процесса формально описаны конфликтные ситуации при исполнении правил (зацикливание и состояние гонки) и свойства набора правил (терминальность и конфлюентность). Выводы. Формализация взаимодействия активных правил позволяет в рамках единого модельного представления описать свойства наборов правил и конфликтных ситуаций в процессе их исполнения; она может служить основой для построения моделей и алгоритмов анализа активных правил.
Ключевые слова: активная база данных, активное правило, взаимодействие активных правил, взаимодействующие активные процессы.
Abstract. Background. In active databases (ADB) management system provides not just actions requested by user but also additional actions according to rules stored in database. Active database management systems (ADBMS) tracks occurrences of specified events and responds to them according to certain rules (active rules). The ADBMS must control interactions of active rules, including possible conflict situations. The purpose of this research is to develop a formal representation of active rules interaction on construction and execution stages in ADBMS. Materials and methods. Communicating Sequential Processes, developed by Ch. Hoar and related to events algebra, is used as a formal apparatus for solving of research objectives. Properties of active rule sets and various conflict situations, which occurs while rules execution process, are described in terms of communicating sequential processes. Results. Formal representation of active rules in ADB is developed as communicating sequential processes. ADB specified as one process, where rules and triggers processing corresponding events in a parallel way. Conflict situations and rule set
properties are formalized on a base of process alphabet conception. Conclusions. Formali-zation of active rules interactions allows to describe a rule set properties and conflicts and can be used to develop models and algorithms of active rules analysis.
Key words: active database, active rule, active rules interactions, communicating sequential processes.
Введение
Обработка событий, возникающих в информационно-управляющих системах, требует применения событийно-ориентированного подхода, в котором база данных (БД) является объектом мониторинга.
В некоторых случаях достаточно функциональности систем управления базами данных (СУБД) и механизма триггеров. Триггеры применяются для обработки элементарных (простых) событий, связанных с операциями над данными. Логика обработки событий в этом случае предельно проста, ограничена жесткими временными рамками, не предусматривает отслеживания и обработки взаимосвязанных событий. Однако обработка событий, близких по уровню абстракции к терминам предметной области, не может в полной мере выполняться триггерами из-за невозможности выявления составных (сложных) событий, являющихся композицией других событий [1].
Для отслеживания взаимосвязанных событий и реагирования на них используются системы обработки сложных событий (Complex Event Processing, CEP), такие как IBM InfoSphere, Oracle CEP, Microsoft Streamsight и CAP Event Insight. Системы данного класса автоматически проверяют корректность процессов обработки событий, выявляют ошибки и поддерживают безопасность данных. Однако CEP-системы не способны обеспечить контроль обработки событий в тех случаях, когда промежуточные события инициируются процессами обработки данных в БД и выявляются СУБД.
Для описания бизнес-логики ИС на высоком уровне абстракции предназначены системы управления бизнес-правилами (Business Rule Management System, BRMS), такие как Oracle SOA, IBM Industry Models, Microsoft BizTalk. При реагировании на события BRMS выступает по отношению к CEP-системе в роли внешнего приложения.
Совместное применение СУБД, CEP-систем и систем управления бизнес-правилами в рамках единого программного комплекса обеспечивает описание самих событий и реакции на их возникновение на должном уровне абстракции. Однако использование сразу трех сложных программных продуктов повышает стоимость создания и сопровождения ИС, увеличивает время отклика на события, требует применения различных нотаций для вычисления сложных событий и реагирования на них. Кроме того, анализ типов событий и бизнес-правил может проводиться только отдельно в каждой из подсистем.
Все это свидетельствует о необходимости единой концепции описания событий и реагирования на события в информационно-управляющих системах. В качестве такой концепции может выступать технология активных баз данных (АБД). Обработка событий в АБД выполняется с помощью активных правил, хранимых наравне с традиционным наполнением БД и обеспечивающих реагирование на события без необходимости в командах от внешнего приложения. Система управления активной базой данных (СУАБД) должна обеспечить проверку активных правил, направленную в том числе на выявление конфликтов правил при рекурсивном вызове. Реализация средств кон-
троля активных правил в процессе исполнения и проектирования в СУАБД определяет актуальность разработки формального представления активных правил и способов выявления потенциальных сценариев их взаимодействия.
1. Концепция активных правил и модели обработки событий в активных базах данных
В активной базе данных хранятся непосредственно данные, полное описание отслеживаемых событий и реакции на них. Системы управления активными базами данных в дополнение к традиционным возможностям СУБД способны обнаруживать события и реагировать на них на том же уровне абстракции, что и системы обработки сложных событий [2]. Для реагирования на события в АБД в составе СУАБД реализуется механизм активных правил хранящихся в АБД объектов специального вида, задающий реакцию на событие. Информация об обрабатываемых событиях, с которыми сопоставлены активные правила, хранится в реестре событий. В отличие от триггеров событие активного правила необязательно является элементарным. Событие для активного правила может быть связано с исполнением хранимых процедур (методов), триггеров или других активных правил. При этом функциональность активных правил является не заменой, а дополнением к функциональности триггеров, позволяя по примеру агентов в системах обработки сложных событий реагировать на события более высокого уровня абстракции.
Классической нотацией описания активных правил является нотация «Событие-Условие-Действие» (Event-Condition-Action, ECA) [3]. Выделяются понятия типа и экземпляра события. Все события объединяются в группы, каждая из которых соответствует конкретному типу события. Он характеризуется именем события, именами и типами параметров. Также для типа события опционально может быть указан объект-источник события, например некоторая таблица реляционной БД или класс объектно-ориентированной БД. Параметры события являются входными параметрами активного правила. Факт наступления события конкретного типа соответствует экземпляру события. Экземпляр события характеризуется типом события, временем возникновения и контекстом, представляющим собой комбинацию значений параметров.
Условие представляет собой логическую функцию от контекста события, определяющую, необходимо ли выполнение реакции на событие или же оно должно быть проигнорировано.
Действие активного правила - это последовательность операций с базой данных, выполняемых в качестве реакции на появление события. Параметры операций с БД, указанных в действии, являются выходными параметрами правила.
Выполнение активных правил является ядром функциональности системы управления активными базами данных [4]. При появлении экземпляра события СУАБД находит все сопоставленные ему правила и вызывает их. Для вызванных правил СУАБД производит вычисление условий на основе значений контекста. Результаты запросов к БД, производимых при вычислении условия, также будем считать частью контекста.
В процессе исполнения активное правило проходит несколько стадий. При появлении экземпляра соответствующего события правило считается вызванным и для него вычисляется условие. Если результат оказывается истинным, правило является запущенным. Выполненное правило характеризуется экземпляром события и результатом вычисления условия, а в случае истинности - дополнительно отметкой времени запуска и завершения действия, а также значениями выходных параметров.
Активные правила могут взаимодействовать друг с другом. Взаимодействие правил может осуществляться либо через события, либо посредством объектов БД. Взаимодействие через событие подразумевает инициирование активных правил друг другом при генерации экземпляров событий. Непосредственная инициация активным правилом другого активного правила происходит, если в ходе выполнения действия инициирующего правила возникает экземпляр события, соответствующий инициируемому правилу. В этом случае соответствующие правила называют непосредственно инициирующим и непосредственно инициируемым. Также активные правила могут инициировать друг друга опосредованно через промежуточные правила [5].
Взаимодействие правил через объекты базы данных происходит, когда несколько разных активных правил одновременно изменяют состояния одних и тех же объектов БД.
В ходе выполнения активных правил возможны конфликты, связанные с их взаимодействием. Одним из таких конфликтов является зацикливание (livelock), когда правила бесконечно инициируют вызов друг друга [4].
Другим конфликтом взаимодействия правил является состояние гонки (race condition), когда несколько активных правил независимо друг от друга изменяют состояние одного и того же объекта БД. При этом сохраняется только последнее изменение, которое определяется фактическим порядком запуска правил, зачастую случайным непредсказуемым образом [4].
Кроме того, для повышения эффективности работы СУАБД, снижения времени реакции желательно выявлять активные правила в группах исполняемых правил, действия которых не влияют на результат и являются необязательными. Это называется политикой результирующего эффекта (net effect policy) [1].
Моделирование сложных бизнес-процессов в динамично изменяющихся предметных областях с помощью активных правил требует постоянного контроля со стороны СУАБД. В традиционных СУБД надежность и стабильность системы достигается за счет ограничения функциональности триггеров. В системах обработки сложных событий задача обеспечения надежности также решается на концептуальном уровне - при описании сложных событий происходит переход на более высокий уровень абстракции, возвращение к элементарным событиям невозможно. В СУАБД такие решения не допустимы, так как ограничивается функциональность активных правил.
2. Формальное представление взаимодействия активных правил
Для формализации взаимодействия активных правил выбрана нотация взаимодействующих последовательных процессов (CSP, Communicating Sequential Processes), разработанная Ч. Хоаром и относящаяся к классу алгебр событий [6]. В CSP поведение процесса рассматривается относительно собы-
тий, в которых процесс принимает участие. Взаимодействием разных процессов считается участие в одном общем событии.
Каждому процессу X ставится в соответствие алфавит - множество событий аХ, в которых процесс способен участвовать. Процесс, не участвующий в событиях, обозначается STOP. Процессы описываются через события и подпроцессы с помощью символа префикса Запись вида (ek ^ X) обозначает процесс, который сначала участвует в событии ek, а затем ведет себя как подпроцесс X. Для описания процессов, которые ведут себя по-разному в зависимости от того, каким оказалось исходное событие, используется оператор выбора |. Процессы, работающие как независимые подпроцессы с общими событиями, описываются с помощью оператора параллельного выполнения 11.
Обозначим множество экземпляров событий АБД и множество элементарных событий как множества событий CSP E и Q, соответственно. Представим активное правило, вызванное для обработки некоторого события, как процесс, который совершает последовательность событий-операций с БД и затем останавливается в виде rk = (dnk ^ (di2k . (dink ^ STOP))), где к -номер экземпляра события eeE, rk - правило при обработке экземпляра события ek, dj е QuE - некоторое элементарное событие или экземпляр промежуточного события, генерируемый правилом напрямую.
Опишем активное правило, обрабатывающее по-разному различные экземпляры событий, как процесс с выбором ri = I | [ek ^ rk ) I, где i = 1, 2, 3... -
номер активного правила, к = 1, 2, 3. - номер экземпляра события.
Вызову процедуры генерации экземпляра события ставится в соответствие процесс, запускающийся элементарным событием и генерирующий экземпляр события trk = (ю ^ (e' ^ STOP)), где e' - генерируемый экземпляр события, к' - номер триггера.
Активную базу данных в целом опишем как процесс, в котором правила и триггеры обрабатывают события параллельно:
ADB = (||г) || (|| trk,), i = 1, 2, 3,..., к' = 1, 2, 3,...
i к'
При выполнении правил возможны случаи, когда события отменяют действия друг друга, например при обновлении и удалении одного и того же кортежа. Введем функцию %(eg, eh), равную 1, если одно из событий eg и eh отменяет результат другого, и равную 0 в противном случае.
Рассматривая вызов правила с некоторым экземпляром события как состояние системы, факт инициирования правила rj правилом ri можно представить в виде диаграммы состояний (рис. 1).
eg С N eh
М ri --->| rj
С
Рис. 1. Инициирование активного правила другим правилом
Выявление зацикливания состоит в отслеживании такого шаблона взаимодействия правил, при котором одно и то же состояние системы повторя-
ется более одного раза. Правило может инициировать само себя, если оно генерирует точно такой же экземпляр события, который обрабатывало (рис. 2).
Рассмотрим пример зацикливания одиночного правила. Здесь и далее для описания активных правил будет использоваться следующая конструкция:
CREATE RULE <имя правила> ON <тип события t> WHEN <условие> DO <действие>.
Тип события описывается аналогично событию триггера, условие - в виде блока where стандартного запроса SQL, а действие представляет собой один или несколько запросов на вставку, удаление или модификацию данных. В качестве экземпляров событий будут использованы операции с БД.
e1
Рис. 2. Зацикливание одиночного правила
Пример l. Зацикливание одиночного правила на примере правила R_Salary, реализующего премиальные выплаты по итогам года:
CREATE RULE R_Salary
ON INSERT INTO SalaryLog
WHEN MonthOf(Date) = 12
DO INSERT INTO SalaryLog
VALUES (new.Amount, new.Worker_id).
При появлении записи о новой выплате сотруднику проверяется дата выплаты. Если дата приходится на последний месяц года, выплачивается премия. Правило будет исполняться, если, например, появился экземпляр события INSERT INTO SalaryLog после выполнения следующей операции:
INSERT INTO Salary (Worker_id, Amount)
VALUES (1, 1000).
После запуска правило продублирует операцию, сгенерировав при этом новый экземпляр события, идентичный предыдущему.
Опосредованное инициирование активного правила через другие правила также может привести к зацикливанию. Экземпляр события, приводящий к зацикливанию, генерируется инициируемым правилом (рис. 3).
При обработке экземпляра события e зацикливание выявляется в том случае, когда существует такая последовательность запусков правил, при которой будет создан дубликат данного экземпляра событий: 3ekeaADB: (ek ^ ADB) с ADB.
e1 /-ч е.
1(eiQ X Г2(е2)
r3(e3)
e^l _
Рис. 3. Зацикливание нескольких правил 340
Пример 2. Рассмотрим пример активных правил в системе обмена сообщениями технической поддержки. Сообщения хранятся в таблице Messages, содержащей три поля: номер пользователя-отправителя Sender_id, номер получателя Recipient_id и текст сообщения MessageText. Сообщения являются платными, и у каждого пользователя есть свой лицевой счет, представленный таблицей Balance с номером пользователя User_id и размером доступных средств Money. Имеется правило RBalanceChk, отправляющее сообщение о пополнении баланса:
CREATE RULE R_BalanceChk ON UPDATE Balance WHEN old.Money < new.Money DO INSERT INTO Messages
VALUES (null, new.user_id, «Баланс пополнен»), Сотрудник технической поддержки получает оплату за каждое полученное сообщение, что моделируется правилом RSupportPay: CREATE RULE R_SupportPay ON INSERT INTO Messages WHEN new.Recipient_id = 15 DO UPDATE Balance SET (Money) = ( SELECT Money + 1 FROM Balance WHERE user_id = 15
)
WHERE User_id = 15. Выполнение операции, добавляющей сообщение
INSERT INTO Messages (Sender_id, Recipient_id, MessageText) VALUES (1, 15, «Не вижу сообщения»),
приведет к появлению экземпляра события INSERT INTO Messages, который будет обработан правилом R SupportPay, которое, в свою очередь, сгенерирует экземпляр события UPDATE Balance после выполнения операции:
UPDATE Balance set (Money) = (11) WHERE User_id = 15.
Это приведет к инициированию правила RBalanceChk и выполнению операции
INSERT INTO Messages (Sender_id, Recepient_id, ToString VALUES (null, new.user_id, «Баланс пополнен»), в результате чего появится событие INSERT INTO Messages, которое снова будет обработано правилом RSupportPay.
Состояние гонки активных правил (рис. 4) наблюдается в том случае, когда при обработке события e правилом rk были непосредственно или опосредованно инициированы правила ri и j сгенерировавшие события, одно из которых отменяет другое - 3d1earlk, 3d2ear/: %(db d2) = 1, где d1 и d2 - некоторые операции с БД.
Пример 3. Рассмотрим активные правила, моделирующие скидки при продажах. Правило RSeasonalDiscount реализует сезонную скидку, применяемую в конце года:
CREATE RULE R_SeasonalDiscount
ON INSERT INTO Sales
WHEN MonthOf(new.sale_date) = 12
DO UPDATE Sales SET (Price) = (new.Price * 0.9)
WHERE Sale_id = new.Sale_id. Правило RProductDiscount реализует скидку по товару: CREATE RULE R_ProductDiscount ON INSERT INTO Sales WHEN new.Product_id = 10
DO UPDATE Sales SET (Price) = (new.Price * 0.75)
WHERE Sale_id = new.Sale_id. Экземпляр события INSERT INTO Sales появится после выполнения следующей операции:
INSERT INTO Sales (Sale_id, Product_id, Price, Sale_date) VALUES (1, 10, 100, '31.12.2013').
В ответ на появление экземпляра события INSERT INTO Sales при выполнении правила R SeasonalDiscount сезонная скидка составит 10 %:
UPDATE Sales SET (Price) = (90) WHERE Sale_id = 1.
Также в ответ на появление экземпляра события INSERT INTO Sales выполнится правило R_ProductDiscount, и скидка на товар составит 25 %:
UPDATE Sales SET (Price) = (75) WHERE Sale_id = 1.
Оба активных правила привязаны к событию вставки в таблицу продаж и обновляют одно и то же поле. Однако при записи используются разные значения, так как правила реализуют различные скидки.
3. Свойства наборов активных правил
При формировании наборов активных правил необходимо избежать рассмотренных ранее конфликтных ситуаций. Для этого набор правил должен обладать свойствами терминальности (termination) и конфлюентности (confluence).
Набор правил обладает свойством терминальности, если при выполнении правил из набора невозможно появление состояния зацикливания при появлении любых допустимых экземпляров событий и при любом допустимом состоянии базы данных. Иными словами, для всех типов событий не существует такой комбинации параметров значений контекста, при которых обработка экземпляра событий привела бы к бесконечному вызову той или иной последовательности правил VekeaABD: (ek ^ ADB) £ ADB.
Свойство конфлюентности для набора правил определяет невозможность возникновения состояния гонки при выполнении правил из набора, когда любые два правила rt и Tj, инициированных правилом ri, не способны генерировать события, одно из которых отменяет операцию другого: если VdgeaADB,VdheaADB: (ek ^ ... (dg ^ ... )) || (ek ^ ... (dh ^ ... )) с ADB, то x(dg, dh) = 0.
Заключение
Для надежной и стабильной работы СУАБД должна обеспечивать контроль взаимодействия правил как при их проектировании, так и в процессе исполнения. Статический анализ активных правил направлен на выявление возможных вариантов взаимодействия правил и выделение среди них потенциальных угроз с точки зрения стабильности работы системы. Динамический анализ активных правил обеспечивает контроль корректности исполнения и поиска наиболее эффективного варианта исполнения.
Предложенная формализация активных правил в рамках единого модельного представления описывает свойства наборов правил и конфликтных ситуаций в процессе их исполнения, она может служить основой для построения моделей и алгоритмов статического и динамического анализа активных правил.
Список литературы
1. Шибанов, С. В. Проблемы построения правил в активных базах данных /
C. В. Шибанов, А. Б Зудов // Математическое и программное обеспечение систем в промышленной и социальной сферах : Междунар. сб. науч. тр. - Магнитогорск : Изд-во Магнитогорск. гос. техн. ун-та им. Г. И. Носова, 2011. - Ч. 1. - С. 36-41.
2. SASE: Complex Event Processing over Streams [Электронный ресурс] /
D. Gyllstrom, E. Wu, H.-J. Chae, Y. Diao, P. Stahlberg, G. Anderson // Proceedings of the Third Biennial Conference on Innovative Data Systems Research (CIDR 2007), Asi-lomar, CA, January 2007. - URL: http://avid.cs.umass.edu/sase/uploads/pubs/sase-demo-cidr2007.pdf
3. Caroprese, L. Declarative Semantics for Active Integrity Constraints / L. Caroprese, M. Truszczynski // Logic Programming. Lecture Notes in Computer Science. - 2008. -№ 5366. - P. 269-283.
4. Kurabayashi, S. Modeling dynamic collections of interdependent objects using path-based rules / S. Kurabayashi, Y. Kiyoki // DBA'06 Proceedings of the 24th IASTED international conference on Database and applications. - 2006. - P. 115-122.
5. Ray, I. Detecting Termination of Active Database Rules Using Symbolic Model Checking / I. Ray // 5th East European Conference, Proceedings. - 2001. - № 13. - P. 266.
6. Хоар, Ч. Э. Р. Взаимодействующие последовательные процессы : пер. с англ. / Ч. Э. Р. Хоар. - М. : Мир, Редакция литературы по математическим наукам, 1989. -264 с.
Шибанов Сергей Владимирович
кандидат технических наук, доцент, кафедра математического обеспечения и применения ЭВМ,
Пензенский государственный университет E-mail: serega@pnzgu.ru
Зудов Антон Борисович
соискатель,
кафедра математического обеспечения и применения ЭВМ,
Пензенский государственный университет E-mail: phoenix_13666@mail.ru
Shibanov Sergey Vladimirovich candidate of technical sciences, associate professor, sub-department of mathematical provision and application of computers, Penza State University
Zudov Anton Borisovich applicant,
sub-department of mathematical provision and application of computers, Penza State University
УДК 004.652 Шибанов, С. В.
Формальное представление правил в активных базах данных как последовательных взаимодействующих процессов / С. В. Шибанов, А. Б. Зудов // Модели, системы, сети в экономике, технике, природе и обществе. - 2016. - № 1 (17). -С. 335-344.
