Правила активности

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

Активная база данных (Active Database) — это база дан­ных, в которой некоторые заранее определенные процес­сы, изменяющие состояние базы данных, запускаются на выполнение (активизируются) не по инициативе пользо­вателей (приложений), как это делается в традиционных пассивных базах данных, а системными механизмами са­мой базы данных (точнее, ее СУБД) в ответ на возникнове­ние некоторых заранее определенных условий (событий). Таким образом, в активных базах данных фрагменты логи­ки приложений¹, не требующие участия (принятия реше­ний) пользователей, вычленяются из приложений и пере­носятся, встраиваются в саму базу данных (рис. 1.12). На этапе концептуального проектирования необходимо опре­делить правила активности, т. е. какие действия и при на­ступлении каких событий будут выполняться автоматиче­ски; на последующих этапах проектирования нужно бу­дет реализовать правила активности средствами использу­емой СУБД².

Правило «событие-условие-действие» (Event-Condi­tion-Action Rule) или ЕСА-правило — распространенная форма задания правила активности. Смысл правила за­ключается в том, что при наступлении заданного события проверяется заданное в правиле условие; в случае, если оно выполняется, то выполняется и заданное действие.

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

Значения по умолчанию. Выше (на с. 18) уже говори­лось о значениях по умолчанию, которые автоматически присваиваются атрибутам в тех случаях, когда они не за­даны явным образом. Очевидно, что этот механизм мож­но представить как ЕСА-правило, исходным событием для которого является операция занесения нового экземпля­ра сущности в базу данных или изменение какого-либо существующего экземпляра, условием — наличие атрибу­та, для которого не задано значение и, вместе с тем, опре­делено значение по умолчанию, а действием — подста­новка значения по умолчанию на место отсутствующего значения.

Автоматическая генерация значения ключа. Значения некоторых ключевых атрибутов (идентификаторов) могут определяться правилами, позволяющими формировать их автоматически³. В отличие от таких идентификаторов как «номер паспорта» или «номер свидетельства о рождении», значения которых поступают в базу данных из предметной области (если только это не база данных паспортного стола или загса, где «рождаются» эти значения), рассматривае­мые значения могут генерироваться в базе данных и под­ставляться в новый экземпляр сущности при его занесении в базу данных аналогично значениям по умолчанию.

Пример. При зачислении нового студента ему присваивается уни­кальный код — номер зачетной книжки, — который сопровождает его в течение всего времени учебы в университете. Этот код может генери­роваться при занесении нового экземпляра сущности «Студент» в базу данных университета про правилу: первые две цифры — год зачисле­ния, третья — код факультета, четвертая-шестая — трехзначное чис­ло, уникальное для уже зачисленных в том же году на тот же факуль­тет студентов⁴. Впоследствии код, сгенерированный базой данных, ра­ботник канцелярии вписывает черной тушью в студенческий билет и зачетную книжку студента.

Обеспечение непрерывности значений. Выше (на с. 25) уже говорилось о непрерывности значений как частном случае требования согласованности значений атрибутов. Атрибуты типа «нпп» — «номер по порядку» — часто пред­полагают пересчет своих значений при добавлении или удалении экземпляров сущностей или агрегатов, наруша­ющих согласованность. Такой пересчет может быть реали­зован средствами активной базы данных.

Пример. Выше на рис. 1.5, с. 13 использовался атрибут «нпп», озна­чавший номер по порядку студента в студенческой группе. Пусть сту­денты в группе нумеруются в алфавитном порядке атрибута «фио»⁵ . То­гда при отчислении студента или переводе его в другую группу может образоваться «дыра» в последовательности значений «нпп», если толь­ко удаленный студент не являлся последним в списке. При добавлении нового студента в группу он в соответствии со своим «фио» может по­пасть куда-то в середину списка, что потребует пересчета «нпп» у тех студентов, которые будут следовать за ним. В соответствии с этими тре­бованиями можно сформулировать следующие ЕСА-правила:

1. событие — удаление некоторого экземпляра сущности «Сту­дент»; условие — удаляемый студент — не последний в списке группы, т.е. атрибут «нпп» удаляемого экземпляра имеет значение, не являю­щееся последним (максимальным) в списке экземпляров с одинаковы­ми значениями атрибутов «спец» и «группа»; действие — уменьшение на единицу значения «нпп» у тех студентов той же студенческой груп­пы, у которых «нпп» больше, чем у удаляемого студента;

2. событие — вставка нового экземпляра сущности «Студент»; условие — новый студент попадает не в конец списка группы, т. е атри­бут «фио» добавляемого экземпляра имеет значение, не являющееся последним по алфавиту среди экземпляров, относящихся к той же сту­денческой группе; действие — присвоение атрибуту «нпп» нового сту­дента значения в соответствии со значением «фио» и увеличение на еди­ницу значения «нпп» у тех студентов той же студенческой группы, у которых «нпп» равно или больше, чем у нового студента.

Специальный аудит. В многопользовательских базах данных администратору или руководителю нередко тре­буется контролировать определенные изменения, которые производятся в базе данных с определенными категория­ми объектов. Например, ответственный работник декана­та берет на контроль успеваемость некоторых категорий студентов и нуждается в оперативной информации о полу­чаемых ими оценках. Другой пример — контроль «подо­зрительных транзакций»⁶ («С какой это стати студенту N неудовлетворительная оценка была исправлена на отлич­ную в середине семестра да еще в 2 часа ночи?»). Один из возможных путей решения этих задач основан на создании правил активного поведения, обеспечивающих занесение интересующей информации об определенных событиях в виде экземпляров в предусмотренные для этого сущности-журналы⁷.

Автоматическое формирование архива. Эта задача по­хожа на предыдущую с той разницей, что в специальные сущности-архивы заносятся экземпляры с историческими данными, отражающими уже состоявшиеся факты. Необ­ходимость этого возникает при разделении общей базы данных на операциональную базу данных, отражающую текущее состояние моделируемого процесса (см. примеча­ние о OLTP на с. 7), и архивную базу данных или базу дан­ных поддержки принятия решений (хранилище данных), отражающую сведения о прошлых состояниях моделиру­емого процесса (см. примечание о OLAP на с. 7). Приме­нение правил активного поведения позволяет автоматизи­ровать процесс переноса потерявших актуальность данных из одной базы данных в другую.

Пример. Пусть операциональная база данных содержит сведения о текущих месте и должности работы сотрудника, а архивная — отра­жает всю его трудовую деятельность в данной организации. Тогда при изменении должности сотрудника или переходе в другое подразделе­ние необходимо соответствующим образом обновить операциональную базу и пополнить архивную. Пополнение архивной базы выполняет­ся автоматически в ответ на обновление операциональной (рис. 1.13, основанный на рис. 1.10, а, с. 23) в соответствии со следующими ЕСА-правилами:

1) событие — реги­страция нового сотруд­ника, т.е. вставка нового экземпляра сущности «Сотрудник»; дей­ствие — вставка нового экземпляра сущности « СотрАрх », одноименные атрибуты заимствуются из экземпляра «Сотруд­ник», значение атрибута «датаУхода» отсутствует;

2) событие — переход сотрудника на новую должность в пределах того же подразделения, сопровождается обновлением агрегата «Должность» в некотором экземпляре сущности «Со­трудник»⁸; действие — в экземпляре «СотрАрх», соответствующем данному сотруднику в последний экземпляр агрегата «Подразделе­ние» добавляется новый экземпляр агрегата «Должность», в котором атрибуту «нппДолж» присваивается следующее значение, а атрибутам «кодДолж» и «датаВступ» — значения из одноименных атрибутов экземпляра сущности «Сотрудник»;

3. событие — переход сотрудника на должность в другое подраз­деление, сопровождается обновлением агрегатов «Подразделение» и «Должность» в некотором экземпляре сущности «Сотрудник»: дей­ствие — в экземпляре «СотрДрх,», соответствующем данному сотруд­нику, в последнем экземпляре агрегата «Подразделение» атрибуту «да­таУхода» присваивается значение атрибута «датаВступ» из соответ­ствующего экземпляра сущности «Сотрудник». Далее добавляется но­вый экземпляр агрегата «Подразделение» с одним экземпляром агре­гата «Должность», атрибуту «нппПодр» присваивается следующее зна­чение, атрибуту «нппДолж» — единица, атрибутам «кодПодр», «код­Долж» и «датаВступ» — значения из одноименных атрибутов экзем­пляра сущности «Сотрудник», атрибут «датаУхода» не заполняется:

4. событие — увольнение сотрудника из организации, сопровожда­ется удалением некоторого экземпляра сущности «Сотрудник» и пре­доставлением значения «датаУхода»; действие — в экземпляре «Со­трАрх», соответствующем данному сотруднику, в последнем экземпляре агрегата «Подразделение» атрибуту «датаУхода» присваивается по­лученное из приложения значение.

¹ Логика приложения или логика бизнес-процесса (Business Logic) — совокупность компонентов приложения, реализующих вычислитель­ные операции, правила принятия решений и другие функции обработ­ки данных, которые составляют существо приложения.

² Основным средством реализации активного поведения базы данных в современных реляционных СУБД являются так называемые тригге­ры (Triggers) — процедуры базы данных, автоматически запускаемые в ответ на попытку вставки, удаления или изменения строки в той или иной таблице базы данных. Кроме того, триггеры могут заблокировать и отменить выполнение запустившей их операции, поэтому они являются мощным универсальным средством поддержания целостности базы данных там, где другие (стандартные) средства бессильны.

³ Иногда для идентификации сущностей вводят так называемые сур­рогатные ключи (Surrogate Keys) — уникальные идентификаторы, на­значаемые СУБД, никак не связанные с предметной областью и недо­ступные пользователю для модификации.

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

⁵ Обратите внимание на то, что в этом случае «нпп» студента, вообще говоря, может быть вычислен — достаточно отсортировать по «фио» и пересчитать по порядку студентов одной группы (с одинаковыми значе­ниями атрибутов «спец» и «группа»). Однако сделать этот атрибут вир­туальным (вычисляемым) можно только в случае рис. 1.5, а, где он не является ключевым. Дело в том, что использование виртуальных атри­бутов в качестве ключей недопустимо, поскольку порождает ряд трудно преодолимых проблем.

⁶Транзакция (Transaction) — совокупность операций манипулиро­вания данными (вставки, обновления, удаления), которая переводит базу данных из одного целостного состояния в другое. Понятие «по­дозрительной транзакции» связано с безопасностью данных — обеспе­чением защиты данных от умышленного или неумышленного несанк­ционированного доступа, используемого для их раскрытия, искаже­ния или разрушения. «Подозрительные транзакции» требуют дополни­тельного анализа лицом, ответственным за безопасность базы данных.

⁷ Журнал (Log, System Journal) — функциональный компонент СУБД, обеспечивающий регистрацию в процессе эксплуатации базы данных сведений об исполнении транзакций, о работающих пользова­телях, об исполняемых приложениях, о доступе к различным структу­рам данных и т. д. В данном случае имеется в виду не системный жур­нал, а сущности концептуального уровня абстракции, используемые сходным образом

⁸ Событие связано именно со сменой должности, а не просто с изме­нением значений атрибутов. Если у сотрудника изменен, скажем, код должности, это не всегда означает, что он сменил саму должность, воз­можно у должности просто изменился код.