CC BY
102
Шибанов С.В. , Лысенко Э.В., Скоробогатько А.А., Зудов А.Б. , Вишняков П.В.
РЕАЛИЗАЦИЯ АБСТРАКТНОЙ МОДЕЛИ АКТИВНЫХ БАЗ ДАННЫХ СРЕДСТВАМИ СОВРЕМЕННЫХ СУБД
1. Актуальность исследований и разработок активных баз данных. Традиционно базы данных (БД) рассматривались как репозитории, которые хранят необходимую для приложений информацию и доступны прикладным программам или пользователям через интерактивные интерфейсы. Традиционные системы управления базами данных (СУБД) пассивны в том смысле, что действия, выполняемые СУБД, инициируются пользователями или программными приложениями. Данный подход может оказаться весьма неэффективным в некоторых случаях.
Типичным примером подобного случая может быть информационная система железной дороги. В ней хранится информация о поездах, расписаниях, местах, имеется возможность покупать билеты через различные терминалы. Во время праздников и других важных событий может быть полезным добавить вагоны к некоторым поездам, если число свободных мест в поездах упало до определённого порога. При этом добавленные вагоны и имеющиеся в наличии места должны своевременно отображаться в терминалах и быть доступными для заказа и покупки билетов пользователями. Администратор базы данных может реализовать это двумя способами. С одной стороны, можно добавить соответствующую функциональность в каждую программу продажи билетов, чтобы контролируемая ситуация проверялась при каждой продаже. Но тогда семантика задачи становится распределённой по терминалам, скрытой и продублированной множество раз. Другая возможность - создать единый опрашивающий механизм, который должен периодически проверять число свободных мест. Но трудность состоит в частоте - слишком частый опрос приведёт к уменьшению производительности, а при слишком редком запросе реакция системы будет сильно запаздывать, и кому-то может быть отказано в продаже, пока вагон не добавится. Кроме того, могут возникнуть аналогичные ситуации, и для каждой из них придется создавать приложение, реализующее необходимую функциональность.
Приведенный пример не является единственным и узкоспециальным, как может показаться на первый взгляд. Множество разработчиков баз данных информационных систем, связанных с электронной коммерцией, сталкиваются с подобными проблемами. Особенно остро они ощущаются, когда БД становится распределённой, и взаимодействовать компоненты должны через Интернет. Клиентов несравнимо больше, чем в предыдущем примере, связь с ними хуже, значит и опрос - долгая, а иногда и требовательная по производительности процедура. С другой стороны, если функциональность содержится в клиентских приложениях, они не только становятся громоздкими, их как-то необходимо обновлять, следя за тем, чтобы у всех была последняя версия, обеспечивая при этом безопасность.
Те же проблемы распространяются и на системы мониторинга, контроля и планирования. Речь идёт о более узкоспециальных и разнотипных системах, таких как системы планирования и управления рабочим процессом [3], мониторинга физических процессов и так далее. Эти задачи требуют своевременного обнаружения критических ситуаций и ответа на них, а значит, необходима высокая адаптивность всей системы, что для базы данных значит автоматическую реакцию на определённые события, описанную в терминах триггеров.
Всё большее распространение получают базы данных движущихся объектов (Moving Objects Database -MODB). [4] Эти объекты изначально не статичны и обладают поведением, перемещаясь по локациям разных типов, меняя тем самым свои характеристики и влияя на характеристики локаций. Таким образом, ситуаций возникает много, а на них нужно реагировать всё так же быстро. Сейчас стали необходимы системы, позволяющие моделировать и прогнозировать пробки и аварии, проектировать транспортные пути и автоматизировать управление трафиком. Похожими на мониторинг трафика задачами являются моделирование сражений, контроль перемещения животных и птиц в экологии и, конечно же, средства мобильной коммуникации.
Для БД движущихся объектов, помимо вышеозначенных проблем, появляется проблема гибкости описания поведения объектов. В терминах традиционных СУБД некоторые аспекты поведения описать сложно или невозможно, например, не все источники событий могут быть описаны традиционными средствами.
Обширная область исследований - пиринговые (одноранговые, децентрализованные) сети, то есть сети, в которых каждый узел (пир) является одновременно клиентом и сервером. Сложность таких систем не только в том, что база данных оказывается распределённой, но и в том, что число источников событий постоянно изменяется [5]. Пирами могут быть не только стационарные машины, но и мобильные устройства. В этом случае БД будет объединять некоторые особенности баз данных движущихся объектов и систем на основе пиринговые сетей. [6] С такой задачей традиционные СУБД часто не справляются даже в аспекте производительности. Чтобы решить эту проблему, необходим подход, при котором неким образом упрощалась бы обработка запросов.
В настоящее время перед современными СУБД, обслуживающими различные информационные системы, все чаще и чаще ставятся задачи, требующие активно реагировать на события, происходящие как внутри информационной системы, так и за ее пределами. Приведенный здесь достаточно краткий обзор проблем традиционных систем управления базами данных показывает актуальность теоретических исследований и практических разработок активных баз данных и систем управления активными базами данных (СУАБД), которые могли бы успешно справляться с указанными проблемами. АБД и СУАБД интегрируют необходимую функциональность внутри самой системы управления базами данных, что обеспечивает создание баз данных с более обширными средствами моделирования как структурных, так и поведенческих аспектов приложения.
2. Модель знаний для АБД. Активная БД должна поддерживать модель знаний, например, механизм описания, и модель выполнения, например, стратегию времени выполнения, чтобы поддерживать реагирующее поведение.
2.1. Классическая модель знаний (модель ECA-правил). Классическая модель знаний АБД основывается на правилах, которые содержат три компонента: событие (event), условие (condition) и действие (ac-
tion). Такого рода правила называют ECA-правилами.
Часть события (event) правила описывает какое-либо событие, которое может произойти в системе или вне нее, и которое должна распознать активная база данных. Спецификация события, таким образом, включает поддержку описания чего-то происходящего, что должно контролироваться. Суть описания и способ, которым событие может быть обнаружено, в значительной степени зависят от источника, или генератора события. Как правило, выделяются следующие источники возникновения событий:
Структурная операция (structure operation) - событие порождается операцией над некоторой частью структуры данных, например, вставить кортеж, изменить атрибут, получить доступ к кортежу;
Вызов поведения (behavior invocation) - событие порождается выполнением некой операции, описанной пользователем, часто событие может порождаться до или после выполнения операции;
Транзакция (transaction) - событие порождается командами транзакций (например, begin transaction, commit, rollback);
Абстрактные (abstract) - описанные пользователем события, механизм программирования которых позволяет сигнализировать о возникновении события явно, например, в ответ на некоторую информацию, введённую пользователем;
Исключения (exeptions) - событие появляется в результате некоторого возникшего исключения, например, была сделана попытка получить доступ к данным без соответствующей авторизации;
Часы (clock) - событие возникает в некоторый момент времени - абсолютное, например, 1З Ноября 199B в 15:00, относительное, например, 10 дней после того, как акции проданы, и периодическое, например, в первый день каждого месяца временные события;
Внешние (external) - событие порождается чем-то извне, например, измеряемая датчиком температура выше 3 0 градусов.
Масштаб события (Event Granularity) указывает на то, что событие определено:
для каждого объекта в наборе (set) - например, каждого экземпляра класса;
для заданных поднаборов (subset) - например, все штатные сотрудники, кроме профессоров;
для некоторых членов (members) набора - например, чтобы предотвратить неавторизованный доступ к некоторым экземплярам, или чтобы сделать возможным обновление тех объектов, которые сейчас отображаются на экране.
Тип (Type)события может быть:
примитивным (primitive) - событие порождается одиночным низкоуровневым действием, что описанным как источник. Например, событие on insert to Owns контролирует вставку новых кортежей в отношение Owns;
сложным (composite) - событие порождается комбинацией примитивных или сложных событий, используя ряд операторов, которые составляют алгебру событий.
Роль события указывает, должно ли оно всегда задаваться для активных правил, или же явное обозначение не является необходимым. Если роль опциональна (optional), то речь идет о существовании правил условие-действие (помимо ECA), в которых событие опущено. Если роли нет (none), то события не могут быть определены, и все правила являются условиями-действиями. Если роль обязательная (mandatory), то поддерживаются только ECA-правила.
Часть условия (condition) правила проверяет контекст, при котором событие произошло. Роль условия показывает, должно ли оно обязательно присутствовать. В ECA-правилах роль условия обычно опциональны. Когда оно не задано, или когда роли нет (none), получается правило событие-действие. В системах, в которых и событие, и условие необязательны, должно присутствовать хотя бы одно.
Контекст указывает на окружение, в котором условие вычисляется. Различные компоненты правила не вычисляют изолированно друг от друга, и более того, они не могут быть вычислены моментально. Как результат, обработка одиночного правила может быть потенциально ассоциировано, как минимум, с четырьмя разными состояниями БД:
1) DBT - база данных в начале транзакции;
2) DBE - база данных в момент; когда событие появилось;
3) DBC - база данных в момент, когда вычислено условие;
4) DBa - база данных в момент, когда выполнено действие.
Системы активных правил должны поддерживать внутри условия возможность доступ к нулю или больше состояний DBt, DBe и DBc, и также обеспечить доступ к связкам с событием (BindE).
Действие (action) описывает задачу, которая должна быть выполнена правилом, если соответствующее событие произошло и условие оказалось истинным. Список задач, которые могут быть выполнены действием определяются как его Опции. Действия могут менять структуру (structure) базы данных или набора правил, выполнять некоторый вызов поведения (behavior invacation) внутри базы данных или внешний (external) вызов, информировать (inform) пользователя или системного администратора о какой-либо ситуации, прерывать (abort) транзакцию или принимать альтернативную линию поведения, используя do-instead.
В некоторых случаях в ECA-правиле событие или условие может быть пропущено или скрыто. Если нет события, то результирующее правило является условием-действием, или продукционным. Если нет условия, то это событие-действие.
2.2. Расширенная модель знаний (SECA-модель). Классическая ECA-модель не учитывает, что в реальных приложениях поведение объекта часто зависит от его состояния.
Например, учетная запись пользователя может быть «активна» или «заблокирована», и в зависимости от этого различной может быть реакция на попытку входа пользователя в систему.
В системе документооборота документ может находиться в состояниях «свободен» и «редактируется». Если документ свободен, то любой пользователь может начать его редактирование и документ переводится в состояние «редактируется». После этого остальные пользователи не имеют доступа к документу, пока не завершится его редактирование, и он не вернется в состояние «свободен».
Состояние - это абстракция значений и связей объекта. Множество значений и связей группируются в состояние в соответствии с массовым поведением объекта. При определении состояния не учитываются атрибуты, не оказывающие влияния на поведение объекта. В состояние объединяются все комбинации значений и связей, характеризующиеся одинаковым откликом на события. Остальные атрибуты можно рассматривать как значения параметров состояния. Объекты класса обладают конечным числом возможных состояний. В каждый момент времени объект может находиться только в одном состоянии. Объекты могут проходить через одно или несколько состояний в течение времени своего существования.
Состояние описывает отклик объекта на получаемые события: в конкретном состоянии игнорируются любые события, за исключением тех, поведение при получении которых описано явным образом. Это свойство состояний особенно важно - оно позволяет наделить объекты системы свойством изменчивости - способности изменять свое поведение в зависимости от возникающих событий.
Добавление в классическую ECA-модель понятия состояния сокращает количество необходимых правил и упрощает процесс разработки активной системы. Возможные типы поведения объекта группируются в соответствии с его состояниями, поведение объекта структурируется и становится доступнее для понимания. Модель ECA-правил, учитывающую состояние объекта называется расширенной моделью ECA-правил, или SECA-моделью (State-Event-Condition-Action).
Графической интерпретацией SECA-модели являются диаграммы состояний UML. Диаграмма состояний -это граф, узлами которого являются состояния, а направленными дугами - переходы между состояниями.
Понятие перехода (transition) от исходного к целевому состоянию в SECA-модели аналогично понятию ECA-правила в ECA-модели. С переходом связывается вызывающее его событие, сторожевое условие и выполняемое при переходе действие, а также два состояния - исходное и целевое. При возникновении события и выполнении сторожевого условия происходит не только выполнение действия, но и переход объекта из исходного состояния в целевое. Исходное и целевое состояния могут совпадать, что аналогично простому ECA-правилу.
Диаграммы состояний UML позволяют наглядно изобразить поведение объекта. В этом кроется еще одно преимущество SECA-модели перед классической ECA-моделью, которая представляется списком правил.
Диаграмма состояний может быть реализована непосредственным преобразование семантики в эквивалентный программный код. Однако, как правило, это процесс является трудоемким и получающийся программный код сложен для понимания и сопровождения. Этого можно избежать, разработав инструментальные средства, автоматизирующие построение кода по диаграмме состояний. В контексте активных баз данных эти средства должны включать:
1) Набор метаданных, содержащих информацию о возможных состояниях, событиях, условиях и действиях, а также о возможных переходах между состояниями;
2) Набор процедур, настраивающих СУБД на поведение в соответствии с диаграммой состояний;
Метаданные SECA-модели целесообразно разделить на две части:
1) Модель состояний с абстрактными событиями, условиями и действиями, не привязанными к конкретной модели данных и СУБД;
2) Реализация событий, состояний и условий в конкретной СУБД, например, абстрактное событие блокировки учетной записи пользователя может быть событием вызова операции UPDATE над таблицей учетных записей, модифицирующей атрибут «заблокирована». В ООБД это же событие может быть событием вызова соответствующего метода.
Такое разделение упрощает перенос модели между различными СУБД: для использования модели в новой
СУБД нужно только указать реализацию событий, условий и действий на языке конкретной СУБД - остальные действия будут выполнены автоматически. Кроме этого, упрощается модификация модели, т.к. изменение реализации не затрагивает абстрактную модель, и наоборот, изменение абстрактной модели не затрагивает реализацию, за исключением добавления новых событий, условий или действий — тогда нужно указать соответствующую реализацию.
3. Реализация абстрактной модели АБД средствами реляционных СУБД. Основными инструментами по реализации активности в реляционных СУБД являются триггеры, хранимые процедуры и мониторы событий.
Мониторы событий отвечают за распознавание возникновения событий и передачи сигнала о них в систему или пользователю. Хранимые процедуры представляют собой набор команд SQL, которые могут компилироваться и храниться на сервере. Таким образом, вместо того, чтобы хранить часто используемый запрос, клиенты могут ссылаться на соответствующую хранимую процедуру.
Триггеры реализуют реакции сервера данных на определенные события. По своей сути триггер - это особая разновидность хранимой процедуры, выполняемая автоматически при возникновении события на сервере базы данных. Триггеры языка обработки данных выполняются по событиям, вызванным попыткой пользователя изменить данные с помощью языка обработки данных. Событиями DML являются процедуры INSERT, UPDATE или DELETE, применяемые к таблице или представлению. Эти триггеры срабатывают при запуске любого допустимого события независимо от того, влияет ли оно на какие-либо строки таблицы.
По своей сути триггеры являются ECA-правила, для которых событиям возникновения являются операции NSERT, UPDATE или DELETE. В них также можно определить условие, для дальнейшего выполнения и действие, которое может быть отличным от первоначального события, которое инициировало триггер
Таблица 1 - Возможности СУБД Microsoft SQL Server 2008 по реализации основных особенностей АБД
Особенность СУАБД Microsoft SQL Server Оценка
І І СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере + + +
1.2 Поддержка модели ECA-правил Определение типов событий Определяет события «до» и «после» для некоторых событий. Определение сложных событий отсутствует. + - -
Определение условий Для представления условий возможно использование как языка SQL, представляющего собой язык 4-го уровня, так и .NET-совместимые языки (в частности - C# и C++.NET) + + +
Определение действия Для представления условий возможно использование как языка SQL, представляющего собой язык 4-го уровня, так и .NET-совместимые языки (в частности - C# и C++.NET). + + +
1.3 Средства для управления базами правил и их эволюции Управление базами правил Ядро СУБД предопределяет список обнаруживаемых событий + - -
Поддержка эволюции базы правил Условие и действие могут быть изменены с помощью директив SQL, требуется повторная компиляция только измененных данных. + + -
Возможность активировать или деактивировать правила Присутствует возможность селективного управления активностью триггеров
1 2 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Сложные события не обнаруживаются + - -
Поддержка режима связывания Событие связывается с конкретным объектом + - -
Механизм проверки условий Условие имеет доступ как к текущему, так и к предыдущему (последующему) состояниям объекта, а также другим объектам БД + + +
Механизм выполнения действий Существуют ограничения, определяемые возникшим событием + + -
2.2 Методы сцепления транзакций Реализованы различные механизмы сцепления транзакций +++
2.3 Способы выявления сложных событий Механизм выявления сложных событий отсутствует
2 Управление историей событий Любые события записываются в системный журнал базы данных + + -
2.5 Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного способа блокировок, возможна дополнительная эскалация блокировок + + -
1 3 Поддержка программной окружающей среды Специализированные средства разработки правил отсутствуют. Наращивание возможностей по обработке возможно только в рамках существующей схемы событий.
3.2 Настройка СУАБД Проектирование может быть осуществлено с использованием двух- или трехуровневой модели. + + +
Таблица 2 - Возможности СУБД Oracle 11д по реализации основных особенностей АБД
№ Особенность СУАБД Характеристики СУБД Oracle Оценка
1.1 СУАБД есть просто СУБД В полной мере поддерживает возможности реляционных СУБД + + +
1.2 Поддержка модели ЕСА- правил Определение типов событий Простейшими событиями, которые можно обнаружить внутри базы данных, являются вставка, обновление и удаление, остальные же события должны быть реализованы как сложные. Сложных событий в Oracle нет, и их необходимо добавить разработчику СУАБД. На внешние события такое ограничение не распространяется + + -
Определение условий Условия можно задавать различными языками (PL/SQL, C++, Java) + + +
Определение действия Как и в случае условий, ограничений в определении действий нет + + +
1.3 Средства для управления базами правил и их эволюции Управление базами правил Базу правил можно хранить как совокупность скриптов, хранимых процедур и триггеров + + +
Поддержка эволюции базы правил Если хранить скрипты в таблицах, то их можно изменять как обычные строковые данные. В зависимости от того, на каком языке написаны правила, их изменения может требовать (в случае PL/SQL) или не требовать перекомпиляции. Ограничений в модификации триггеров тоже нет. + + +
Возможность активировать или деактивировать правила Деактивация правил - это деактивация обнаружения событий. Так как оно реализуется через триггеры, которые в Oracle можно деактивировать, данный способ управления базой правил поддерживается полностью + + +
2.1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события Для обнаружения сложных событий должен быть реализован специальный детектор. Простые события могут обнаруживаться с помощью триггеров + + -
Поддержка режима связывания Любое событие может снабжаться информацией о связанных с событием данных без каких-либо ограничений, так как в случае простых событий для этой цели служат переменные new и old, а для сложных событий детектор может объединять значения этих переменных, пришедших от разных простых событий + + +
Механизм проверки условий Проверка условий может состоять в извлечении из запуске соответствующего скрипта. При этом условию доступно текущее и предыдущее состояние связанных с событием данных + + +
Механизм выполнения действий Так как в Oracle поддерживаются триггеры типов AFTER и BEFORE, правило может выполняться до и после события. Действию доступны те же данные, что и условию + + +
2.2 Методы сцепления транзакций По умолчанию используется немедленное сцепление транзакций, при использовании автономных транзакций возможна реализация расцепленного метода + + -
2.3 Способы выявления сложных событий Встроенные средства реализации обнаружения сложных событий отсутствуют + - -
2.4 Управление историей событий Не все структуры, подходящие для хранения истории событий, могут быть реализованы эффективно. + + -
2.5 Механизмы разрешения коллизий Oracle поддерживает гибкие возможности параллельного выполнения + + +
3.1 Поддержка программной окружающей среды Перечисленные средства отсутствуют. Кроме того, многое из перечисленного необходимо реализовывать с привлечением не входящих в СУБД средств + - -
3.2 Настройка СУАБД Ограничений в возможности реализации настройки СУАБД нет + + +
Таблица 3 - Возможности СУБД Progress по реализации основных особенностей АБД
№ Особенность СУАБД Характеристики СУБД Progress Оценка
\—і \—і СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере. + + +
2 \—і Поддержка модели ECA-правил Определение типов событий Определяет события CREATE, DELETE, WRITE, ASSIGN, FIND. Все события имеют тип «до». Определение сложных событий отсутствует. + - -
Определение условий Для представления условий и действий используется язык Progress 4GL (ABL). С версии 10 в нем реализована полная поддержка + + +
Определение действия + + +
ООП.
1.3 Средства для управления базами правил и их эволюции Управление базами правил Информация о триггерах хранится в системных таблицах и доступна пользователям посредством специального инструмента - Data Dictionary. Код триггеров хранится отдельно от базы данных в файлах процедур(p-модулях). + + +
Поддержка эволюции базы правил Событие, условие и действие могут быть изменены, но для этого необходима перекомпиляция соответствующего p-модуля. + + -
Возможность активировать или деактивировать правила Для активации и деактивации правил используется специальная утилита. + + +
2.1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Обнаруживаются только простые события + - -
Поддержка режима связывания CREATE, WRITE, DELETE и FIND связаны с отдельным картежом, ASSIGN - с отдельным полем. + + -
Механизм проверки условий Условие имеет доступ к старым и новым значениям полей, может обращаться к другим объектам БД. + + +
Механизм выполнения действий Действие может изменять результат выполнения операции над базой данных, выполнять запросы на вставку, удаление и модификацию данных. + + +
2 2 Методы сцепления транзакций Реализовано только немедленное сцепление транзакций. Триггер всегда выполняется внутри вызвавшей его транзакции. + - -
3 2 Способы выявления сложных событий Механизм выявления сложных событий отсутствует. - - -
2 Управление историей событий История событий отсутствует - - -
LO 2 Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного пользователем режима блокировок. По умолчанию используется разделяемая (shared) блокировка для чтения и эксклюзивная (exclusive) для записи. + - -
1 3 Поддержка программной окружающей среды Доступны средства разработки классов, которые позволяют добавить в класс обработку некоторых событий. Специализированные средства для разработки правил отсутствуют. + - -
2 3 Настройка СУАБД Проектирование можно осуществлять с использованием трехуровневой модели + + +
Тип триггера определяется тем, какое событие его активизирует - INSERT (вставка), UPDATE (изменение) или DELETE (удаление). Триггеры могут активизироваться до (BEFORE) или после (AFTER) наступления события, а также для строки таблицы (кортежа) или оператора, вызвавшего события в целом. Если триггер является строковым (кортежным), то он активизируется один раз для каждой из строк, на которые воздействует оператор, который вызвал срабатывание триггера. Если триггер является операторным, то он активизируется один раз до или после выполнения оператора. Строковые триггеры содержат фразу FOR EACH ROW в описании триггера.
В таблице 1 представлены основные возможности СУБД MS SQL Server 2008 для реализации абстрактной модели и построения АБД. В таблице 2 представлены основные возможности СУБД Oracle 11g для реализации абстрактной модели и построения АБД. В таблице 3 представлены основные возможности СУБД Progress для реализации абстрактной модели и построения АБД.
Подводя итог анализу возможности реализации абстрактной модели АБД в современных реляционных СУБД, можно сделать вывод о том, что разработчик применяют в предоставляют триггеры и хранимые процедуры, как основной инструмент по реализации активных компонентов. Но триггеры срабатывают на определенный тип событий, такие как операции над данными или структурой БД, что накладывает ограничения на проектирование и разработку соответствующих средств управления АБД.
4. Реализация абстрактной модели АБД средствами объектно-ориентированных СУБД. Объектноориентированные базы данных (ООБД), в отличие от реляционных, изначально поддерживают близкую связь данных и поведения. Это выражается в объединении данных и методов в одну сущность (класс). Пользовательские методы позволяют определить требуемую реакцию ООБД на внешние события, например, для изменения состояния объекта пользователь вызывает метод setValue, который помимо установки нового значения поля объекта может выполнить дополнительные действия.
В ООБД схема данных строится в соответствии с объектно-ориентированной концепцией. База данных представляется пользователю в виде набора классов, каждый из которых обладает индивидуальностью -набором атрибутов и поведением - набором методов. Работа с базой данных ведется не в терминах запросов, как в реляционных БД, а в терминах работы с объектами - чтение атрибутов объекта и вызов его методов. В связи с этим слой активности ООБД должен поддержать обнаружение другого набора событий, таких как извлечение объекта из БД, вызов метода объекта, сохранение объекта из БД и т.п.
Обнаружение событий создания объекта, извлечения объекта из базы данных и сохранения объекта возможно с помощью механизма функций обратного вызова (Callback Methods).
Функции обратного вызова запускаются СУБД при выполнении определенных действий с объектом. Они являются аналогией механизма триггеров в реляционных СУБД. ООБД Cache поддерживает следующие функции обратного вызова:
%OnNew - вызывается при создании нового объекта в оперативной памяти в тот момент, когда выделена память под объект и инициализированы его свойства.
%OnOpen - функция вызывается перед извлечением существующего объекта из базы данных.
%OnDelet - данная функция вызывается перед удалением объекта.
%OnBeforSave и %OnAfterSave -вызываются непосредственно перед и сразу после сохранения объекта в базу данных соответственно.
Для обнаружения вызова методов в ООБД используют механизм оберток (wrappers). В наблюдаемый метод класса добавляется дополнительный код, уведомляющий уровень активности о наступлении события. Как правило, код добавляется в самом начале метода (до выполнения методом каких-либо действий) и в самом конце метода (перед возвратом результата). Обертка должна передать в уровень активности ссылку на объект, которому принадлежит вызванный метод, и список значений параметров вызванного метода.
Автоматическое добавление оберток к наблюдаемому методу требует доступа к информации об атрибутах и методах классов. Другими словами, должна иметься возможность изменять определение класса во время выполнения. В Cache эту задачу решает механизм классов-определений (Class Definition Classes). Механизм реализован в виде отдельного пакета (%Dictionary, словарь определений классов) и позволяет просматривать определения существующих в базе данных классов и вносить в них изменения.
Классы пакета %Dictionary позволяют получить полный доступ к определениям классов, находящихся в базе данных. Они дают возможность просматривать списки методов и атрибутов класса, добавлять новые атрибуты и методы и изменять существующие. Cache позволяет работать с определениями классов как с обычными объектами базы данных. Например, для создания нового класса необходимо создать объект класса %Dictionary.ClassDefinition, добавить к объекту методы и свойства и сохранить его в базу данных.
Рассмотренные выше способы обнаружения событий позволяют обнаружить события одного типа источников - StructureOp, операции над структурой БД. Теперь рассмотрим способы обнаружения других типов событий:
1) Тип события UserDefined. Пользовательская операция позволяет клиентской программе запустить выполнение некоторой программы на сервере. Этот тип события отличается от простого вызова метода тем, что метод может быть вызван не только по запросу пользователя, но и самой СУБД. При обнаружении данного типа события следует удостоверится, что запуск активности был инициирован пользовательской программой. Это может быть реализовано созданием в базе данных отдельного класса для хранения пользовательских событий (UserAction). Объекты класса будет хранить описание события и дополнительную связанную с событием информацию (Например, событие «Пользователь входит в систему» может в качестве дополнительной информации хранить введенные пользователем логин и пароль). Активация события будет производиться вызовом специального метода объекта UserAction.FireAction().
2) Тип события Clock. Можно выделить два способа обнаружения событий наступления определенного
момента времени. Первый способ заключается в написании программы на Cache Object Script, выполняющейся на сервере и периодически проверяющей наступление события. Этот подход обладает более высокой производительностью (отсутствуют затраты на взаимодействие сервера Cache и клиента планировщика), но страдает недостаточной гибкостью. Второй способ заключается в использовании сторонних программ-планировщиков для запуска задач по расписанию (at, Cron, Anacron в Linux, TaskScheduler в Windows). В качестве задачи планировщику можно назначить выполнение автоматически генерируемого скрипта или запрос URL, содержащего CGI программу активации события. Преимущество этого способа заключается в возможности использования различных программ-планировщиков или даже написания своих для поддержания особой функциональности. На мой взгляд, при разработке уровня активности следует поддержать оба подхода: первый для обеспечения базовой функциональности и второй, в виде Web-интерфейса для внешних
программ-планировщиков, для обеспечения расширяемости.
3) Тип события External. Внешние события можно разделить на две категории: события периферийных
устройств и удаленные события. Для обнаружения событий периферийных устройств можно использовать библиотеку управления вводом/выводом (Cachte I/O Device). Данная библиотека позволяет работать с периферийными устройствами напрямую из методов объектов с использованием языка Cache Object Script. Cache поддерживает работу с разнообразным периферийным оборудованием, в том числе принтерами, жесткими дисками, магнитными лентами, терминалами и многими другими.
Если событие происходит на удаленном компьютере и обнаружить его напрямую невозможно, назовем его удаленным событием. Например, Cache может получать данные от внешних web-сервисов и при определенных сочетаниях полученных значений активировать ECA-правила. Для работы с web-сервисами по протоколу HTTP из Cache Object Script можно использовать библиотеку %Net и класс %Net.HttpRequest.
4) Тип события Exception. Для обнаружения возникновения ошибочных ситуации в СУБД используется механизм обработчика ошибок (Error handler). Cache позволяет при возникновении ошибки передать управление пользовательской функции-обработчику.Для этого устанавливается значение системной переменой $ETRAP.
SET $ETRAP="GOTO LogErrorAErrRoutine"
Переменная $ETRAP содержит код на Cache Object Script, который выполняется при возникновении ошибки. В приведенном выше примере управление передается функции LogError (которая является частью функции ErrRoutine). Функции-обработчикудоступна следующая информация:
1) Тип контекста (DO, EXCUTE или функция пользователя);
2) Номер строки в исходном тексте, где произошла ошибка;
3) Код ошибки.
Таблица 4 - Возможности СУБД Cache по реализации основных особенностей АБД
№ Особенность СУАБД Характеристики СУБД Cache 2009.1 Оценка
І І СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере. + + +
2 І Поддержка модели ECA-правил Определение типов событий Определяет события «до» и «после» для некоторых событий. Определение сложных событий отсутствует. + - -
Определение условий Для представления условия используется язык Cache Object Script, являющийся полноценным объектноориентированным языком программирования. + + +
Определение действия Для представления действия используется язык Cache Object Script, являющийся полноценным объектно-ориентированным языком программирования. + + +
1.3 Средства для управления базами правил и их эволюции Управление базами правил Централизованное хранение правил отсутствует, но информацию о правилах можно получить из описания класса. + - -
Поддержка эволюции базы правил Событие, условие и действие могут быть изменены, но для этого необходима перекомпиляция класса. + + -
Возможность активировать или деактивировать правила Возможность активации и деактивации правил отсутствует.
\—1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Обнаруживаются только простые события + - -
Поддержка режима связывания Событие связывается только с конкретным объектом + - -
Механизм проверки условий Условие имеет доступ только к текущему состоянию объекта, может обращаться к другим объектам БД. + + -
Механизм выполнения действий Возможно выполнение любого действия с базой данных (создание и удаление объектов, вызов методов и т.д.) + + +
Методы сцепления транзакций Реализовано только немедленное сцепление транзакций. + - -
ГО CN Способы выявления сложных событий Механизм выявления сложных событий отсутствует.
CN Управление историей событий История событий отсутствует
LO CN Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного пользователем режима блокировок. По умолчанию блокировки не используются. + - -
\—1 ГО Поддержка программной окружающей среды Доступны средства разработки классов (Cache Studio), которые позволяют добавить в класс обработку некоторых событий. Специализированные средства для разработки правил отсутствуют. + - -
CN ГО Настройка СУАБД Проектирование можно осуществлять с использованием трехуровневой модели + + -
Таблица 5 - Обобщенные результаты анализа возможностей СУБД по реализации абстрактной модели и
разработке АБД
SQL Server
№ Особенность СУАБД Cache Progress Oracle
\—і \—і СУАБД есть просто СУБД + + + +++ + + + + + +
\—1 Поддержка модели ЕСА-правил Определение типов событий + - - + - - + - - + + -
Определение условий + + + +++ + + + + + +
Определение действия + + + +++ + + + + + +
ГО \—1 Средства для управления базами правил и их эволюции Управление базами правил + - - + - - + + + + + +
Поддержка эволюции базы правил + + - ++- + + - + + +
Возможность активировать или деактивировать правила + + + + + +
\—1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. + - - + - - + - - + + -
Поддержка режима связывания + - - + - - + + - + + +
Механизм проверки условий + + - +++ + + + + + +
Механизм выполнения действий + + + ++ - + + + + + +
Методы сцепления транзакций + - - +++ + - - + + -
ГО Способы выявления сложных событий - - - - - - + - -
Управление историей событий - - - ++ - - - - + + -
LO Механизмы разрешения коллизий + - - ++ - + - - + + +
\—1 ГО Поддержка программной окружающей среды + - - + - - + - -
ГО Настройка СУАБД + + - +++ + + + + + +
Таким образом, обнаружение событий типа Exception сводится к установке обработчика, который будет информировать слой активности о всех возникающих ошибках.
5) Тип события Transaction. Из событий управления транзакциями Cache поддерживает обнаружение только событие отката транзакции. Обнаружить событие можно с помощью функции обратного вызова %OnRollBack. Функция вызывается перед началом отката транзакции.
Откат транзакции может быть остановлен (для этого необходимо вернуть код ошибки, отличный от $$$OK). Начало транзакции может быть косвенно определено как вызов метода %Save объекта (вызов %Save автоматически начинает транзакцию). Однако этот метод не является надежным, т.к. Cache позволяет сохранить несколько объектов в одной транзакции с помощью специальных конструкций Cache Object Script (TSTART, TCOMMIT, TROLLBACK).
Основные возможности СУБД Cache для реализации абстрактной модели и построения АБД представлены в таблице 4. Выделенные особенности СУБД Cache показывают, что в данной системе реализован большой функционал по определению событий, которые является одним из основных компонентов активной базы данных. Данный функционал значительно шире, чем в традиционных реляционных базах данных, что является следствием объектно-ориентированной структуры данных. Таким образом, Cache находится ближе к понятию активных баз и предоставляет значительно шире набор инструментов по реализации абстрактной модели АБД для пользователя.
Обобщенные результаты сравнительного анализа возможностей СУБД по реализации абстрактной модели и разработке АБД сведены в таблицу 5. Они показывают, что современные коммерческие СУБД обладают средствами, позволяющие реализовывать в рамках той или иной модели данных активные базы данных и управление активностью. Однако применение данных средств требует разработки прикладного программного обеспечения и не позволяет реализовывать полномасштабные систему управления активными базами данных.
