Активный сервер

В распределенных БД возникают следующие проблемы:

• база данных в любой момент времени должна правильно отражать состояние предметной области —дан­ные должны быть взаимно непротиворечивыми. Пусть, например, база данных Кадры хранит сведения о рядовых сотрудниках, отделах, в которых они работают, и их руководителях. Нужно учесть следующие правила: каждый сотрудник должен быть подчинен реальному руководителю; если руководитель уволился, то все его сотрудники пере­ходят в подчинение другому, а отдел реорганизуется; во главе каждого отдела должен стоять реальный руководи­тель; если отдел сокращен, то его руководитель перево­дится в резерв на выдвижение и т. д.;

• база данных должна отражать некоторые правила предметной области, законы, по которым она функ­ционирует (business rules). Завод может нормально работать только в том случае, если на складе имеется достаточный запас деталей определенной номенклатуры. Следовательно как только количество деталей некоторого типа станет меньше минимально допустимого, завод должен докупить их в нужном количестве;

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

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

• важная функция — контроль типов данных. В базе данных каждый столбец в любой таблице содержит данные некоторых типов. Тип данных определяется при создании таблицы. Каждому столбцу присваивается один из стандартных типов данных, разрешенных в СУБД.

Концепция активного сервера опирается на следую­щие принципы:

• процедуры базы данных;

• правила (триггеры);

• события в базе данных.

Процедуры базы данных. Вразличных СУБД они носят назва­ние хранимых (stored), присоединенных, разделяемых и т. д. Ниже используется терминология, принятая в СУБД Ingres.

Использование процедур базы данных преследует четыре цели:

• обеспечивается новый независимый уровень центра­лизованного контроля доступа к данным, осущест­вляемый администратором базы данных;

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

• значительное снижение трафика сети в системах с архитектурой «клиент—сервер». Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры. В процедуре, как правило, концентрируются повторяющиеся фрагменты из нескольких прикладных программ (рис. 7.4). Если бы эти фрагменты остались ча­стью программы, они загружали бы сеть посылкой полных SQL-запросов;

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

Процедура обычно хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается опера­тором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) И содержит определения переменных, операторы SQL (например, SELECT, INSERT), операторы проверки условий (if/then/else), операторы цикла (for, while), а также некоторые другие.

Пусть, например, необходимо разработать процедуру, кото­рая переводила бы рядового сотрудника в резерв на выдвижение на руководящую должность. Процедура Назначение перемещает строки из таблицы Сотрудник, которая содержит сведения о со­трудниках, в таблицу Резерв для всех сотрудников с указанным номером. Номер сотрудника представляет собой целое число (тип integer), который не может иметь пустое значение, явля­ется параметром процедуры и передается ей при вызове из при­кладной программы оператором execute procedure (выпол­нить процедуру):

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

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

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

Это требование может быть описано правилом Прове­рить_деталь. Оно применяется в случае обновления столбца количество таблицы Деталь: если новое значение в столбце меньше 1000, то выполняется процедура Заказать_деталь. В качестве параметров ей передаются номер детали данного типа и остаток (число деталей на складе):

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

Важнейшая цель механизма правил — обеспечение целостности базы данных. Один из аспектов целостности — целостность по ссылкам (referential integrity) — относится к связи двух таблиц между собой.

Допустим, таблица Руководитель содержит сведения о начальниках, а таблица Сотрудник — о сотрудниках некоторой организации (см. рис. 5.6). СтолбецНомер_руководителя является внешним ключом таблицы Сотрудник и ссылкой на таблицу Руководитель.

Для обеспечения целостности ссылок должны быть учтены два требования. Во-первых, если в таблицу Сотрудник добавля­ется новая строка, значение столбца номер руководителя должно быть взято из множества значений столбца Номер таблицы Ру­ководитель (сотрудник может быть подчинен только реальному руководителю). Во-вторых, при удалении любой строки из таб­лицы Руководитель в таблице Сотрудник не должно остаться ни одной строки, в которой в столбце Номер_руководителя было бы значение, тождественное значению столбца Номер в удаляемой строке (все сотрудники, если их руководитель уволил­ся, должны перейти в подчинение другому).

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

Механизм правил позволяет реализовать и более общие огра­ничения целостности. Пусть, например, таблица Сотрудник со­держит информацию о сотрудниках, в том числе имя и название отдела, в котором они работают. Таблица Отдел хранит для каждого отдела количество работающих в нем сотрудников в столбце Количество_сотрудников. Одно из ограничений целостности заключается в том, что это количество должно совпадать с числом строк для данного отдела в таблице Сотрудник. Чтобы это ограничение, можно использовать правило Добавить_сотрудника, которое применяется при включении строки в таблицу Сотрудник и запускает процедуру Новый_сотрудник. Она, в свою очередь, обновляет значение столбца Количество_сотрудников, увеличивая его на единицу. Параметр проце­дуры — название отдела.

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

Аналогом правил послужили триггеры (triggers), которые впервые появились в СУБД Sybase и впоследствии были реали­зованы в том или ином виде и под тем или иным названием в большинстве многопользовательских СУБД.

События в базе данных. Механизм событий в базе данных (database events) позволяет прикладным программам и серверу базы данных уведомлять другие программы о наступлении в базе данных определенного события и тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление, часто называют сигнализаторами событий в базе данных (database event alerters). Функции управления событиями цели­ком ложатся на сервер базы данных.

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

Механизм событий используется следующим образом. Вначале в базе данных для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор create dbevent - создать событие). Далее, во все прикладные программы, на ход выполнения которых может повлиять это событие, включается оператор register dbevent (зарегистриро­вать событие), который оповещает сервер базы данных, что программа заинтересована в получении сообщения о наступле­нии события.

Теперь любая прикладная программа или процеду­ра базы данных может вызвать событие оператором RAISE dbevent (вызвать событие). Как только событие произошло, каждая зарегистрированная программа может получить его, для чего она должна запросить очередное сообщение из очереди со­бытий (оператор get dbevent — получить событие) и запро­сить информацию о событии, в частности его имя (оператор SQLINQUIRE_SQL).

Следующий пример иллюстрирует обработку всех событии из очереди:

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

Создается правило, которое применяется всякий раз, когда новое значение температуры инструмента заносится в таблицу Инструмент. Как только оно превосходит 500 градусов, правило вызывает процедуру Отключить__инструмент.

Создается процедура базы данных Отключить_инструмент, которая вызывает событие Перегрев; она будет выполнена в ре­зультате применения правила, определенного на шаге 1.

Создается событие Перегрев, которое будет вызвано, когда инструмент перегреется:

Наконец создается прикладная программа Монитор_Инструментов, которая следит за состоянием инструментов. Она регистрируется сервером в качестве получателя события Перегрев с помощью оператора register dbevent. Если событие произошло, программа посылает сообщение пользователю и сигнал необходимый для отключения инструмента:

Описанные выше конструкции в совокупности определяют логику работы (рис. 7.6).

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

Всякий раз, когда это происходит, т. е. обновляется значение столбце Температура таблицы Инструмент, применяется пра­вило Перегрев_инструмента.

Применение правила состоит в проверке нового значения температуры. Если оно превышает максимально допустимое, то запускается процедура Отключить_инструмент.

В том случае, когда используются традиционные методы оп­роса БД, логика работы была бы совершенно иной. Пришлось бы разработать дополнительную программу, которая периодиче­ски выполняла бы операцию выборки из таблицы Инструмент по критерию Температура > 500. Это очень сильно сказалось бы на эффективности, поскольку операция select является ре­сурсоемкой. Разумеется, пример приведен лишь для иллюстра­ции схемы срабатывания механизма «правило — процедура — событие».