Технология и модели "клиент-сервер"

Раздел 2. Сервер базы данных

Современная СУБД должна удовлетворять ряду требований, важнейшее из которых - высокопроизводительный интеллектуальный сервер базы данных. Далее мы рассмотрим основные тенденции его развития и обсудим конкретные механизмы, в которых они находят свое воплощение.

Процесс технического совершенствования сервера базы данных пока остается невидимым для большинства пользователей современных СУБД. Поэтому при выборе той или иной системы они, как правило, не учитывают ни технический уровень решений, заложенных в механизм его функционирования, ни влияние этих решений на общую производительность СУБД. Между тем ее качество определяется отнюдь не богатством интерфейсов с пользователем, не разнообразием средств поддержки разработок, а в первую очередь зависит от особенностей архитектуры сервера базы данных. Далее будут рассмотрены модели технологии "клиент-сервер", определено место сервера БД в этих моделях и кратко описаны важнейшие механизмы сервера БД - процедуры, правила (триггеры), события. Последние будут проиллюстрированы примерами, в которых использован диалект SQL, принятый в СУБД Ingres.

Технология и модели "клиент-сервер".

В сети один и тот же компьютер может выполнять роль как клиента, так и сервера. Например, в информационной системе, включающей персональные… Этот же принцип распространяется и на взаимодействие программ. Если одна из… Рисунок 1. Системы с централизованной архитектурой.

Эволюция серверов баз данных

Чтобы понять суть проблемы, рассмотрим эволюцию серверов баз данных. Первое время доминировала модель, когда управление данными (функция Сервера) и… Рисунок 6. Централизованная архитектура (а) и архитектура "один к одному" (б).

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

Идея активного интеллектуального сервера БД возникла не сама по себе - она стала ответом на задачи реальной жизни. В Разделе 1 было сформулировано…

Актуальные задачи

Во-первых, необходимо, чтобы база данных в любой момент правильно отражала состояние предметной области - данные должны быть взаимно… Во-вторых, база данных должна отражать некоторые правила предметной области,… В-третьих, необходим постоянный контроль за состоянием базы данных, отслеживание всех изменений, и адекватная реакция…

Традиционные подходы

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

Пример 2.

Правила

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

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

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

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

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

CREATE RULE Проверить_деталь

AFTER UPDATE (Количество) OF Деталь

WHERE Деталь.Количество < 1000

EXECUTE PROCEDURE

Заказать_деталь (Номер детали = Деталь.Номер,

Остаток = Деталь.Количество);

{ СОЗДАТЬ ПРАВИЛО Проверить_деталь

ПОСЛЕ ОБНОВЛЕНИЯ (Количество) В Деталь

ГДЕ Деталь.Количество < 1000

ВЫПОЛНИТЬ ПРОЦЕДУРУ

Заказать_деталь (Номер детали=Деталь.Номер,

Остаток=Деталь.Количество);

}

Пример 3.

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

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

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

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

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

CREATE RULE Добавить_сотрудника

AFTER INSERT INTO Сотрудник

EXECUTE PROCEDURE Проверить_руководителя (Номер = Сотрудник.Номер);

{ СОЗДАТЬ ПРАВИЛО Добавить_сотрудника

ПОСЛЕ ВКЛЮЧЕНИЯ В Сотрудник

ВЫПОЛНИТЬ ПРОЦЕДУРУ Проверить_руководителя (Номер=Сотрудник.Номер)

}

Пример 4.

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

CREATE RULE

AFTER INSERT INTO Сотрудник

EXECUTE PROCEDURE Новый_сотрудник (Отдел = Сотрудник.Отдел);

{ СОЗДАТЬ ПРАВИЛО Включить_сотрудника

ПОСЛЕ ВКЛЮЧЕНИЯ В Сотрудник

ВЫПОЛНИТЬ ПРОЦЕДУРУ Новый_сотрудник (Отдел = Сотрудник.Отдел)

}

Пример 5.

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

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

События в базе данных

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

Рисунок 12.
События в базе данных.

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

Механизм событий используется следующим образом. Вначале в базе данных для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT - СОЗДАТЬ СОБЫТИЕ). Далее во все прикладные программы, на ход выполнения которых может повлиять это событие, включается оператор REGISTER DBEVENT (ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ), который оповещает сервер базы данных, что данная программа заинтересована в получении сообщения о наступлении события. Теперь любая прикладная программа или процедура базы данных может вызвать событие оператором RAISE DBEVENT (ВЫЗВАТЬ СОБЫТИЕ). Как только событие произошло, каждая зарегистрированная программа может получить его, для чего должна запросить очередное сообщение из очереди событий (оператор GET DBEVENT - ПОЛУЧИТЬ СОБЫТИЕ) и запросить информацию о событии, в частности, его имя (оператор SQL INQUIRE_SQL).

Пример 6 иллюстрирует обработку всех событий из очереди.

loop

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL (:event_name = DBEVENTNAME);

if (event_name = "event_1"

обработать событие event_1

else if (event_name = "event_2")

обработать событие event_2

else

...

endif

until event_name = " "

{ цикл

ПОЛУЧИТЬ СОБЫТИЕ

ПОЛУЧИТЬ ИМЯ СОБЫТИЯ

если (имя события = "первое событие")

обработать первое событие

иначе если (имя события = "второе событие")

обработать второе событие

иначе

...

конец если

пока имя события не равно пустой строке

}

Пример 6.

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

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

CREATE RULE Перегрев_инструмента

AFTER UPDATE OF

Инструмент (Температура)

WHERE Новое.Температура >= 500

EXECUTE PROCEDURE

Отключить_инструмент

(Номер_инструмента =

Инструмент.Номер);

{ СОЗДАТЬ ПРАВИЛО

Перегрев_инструмента

ПОСЛЕ ОБНОВЛЕНИЯ

Инструмент (Температура)

ГДЕ Новое.Температура >= 500

ВЫПОЛНИТЬ ПРОЦЕДУРУ

Отключить_инструмент

(Номер_инструмента =

Инструмент.Номер);

}

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

CREATE PROCEDURE

Отключить_инструмент

(Номер_инструмента) AS

BEGIN

UPDATE Инструмент

SET Статус = "ВЫКЛ"

WHERE Номер = Номер_инструмента;

RAISE DBEVENT Перегрев;

END;

{ СОЗДАТЬ ПРОЦЕДУРУ

Отключить_инструмент

(Номер_инструмента) КАК

НАЧАТЬ

ОБНОВИТЬ Инструмент

УСТАНОВИТЬ Статус = "ВЫКЛ"

ГДЕ Номер = Номер_инструмента;

ВЫЗВАТЬ СОБЫТИЕ Перегрев;

END;

}

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

CREATE DBEVENT Перегрев;

{ СОЗДАТЬ СОБЫТИЕ Перегрев }

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

...

EXEC SQL REGISTER

DBEVENT Перегрев;

...

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL

(Имя события = DBEVENTNAME, ...);

if (Имя события = "Перегрев")

then

послать сообщение;

отключить инструмент;

endif;

{...

ВЫПОЛНИТЬ SQL

ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ Перегрев;

...

ВЫПОЛНИТЬ SQL ПОЛУЧИТЬ СОБЫТИЕ;

ВЫПОЛНИТЬ SQL ПОЛУЧИТЬ ИМЯ СОБЫТИЯ;

если Имя события = "Перегрев"

то

послать сообщение;

отключить инструмент;

конец если;

}

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

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

2. Та же программа заносит в таблицу Инструмент новое значение температуры для данного инструмента.

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

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

5. Она изменяет значение в столбце Статус таблицы Инструмент на "ВЫКЛ".

6. Она же вызывает событие Перегрев.

7. Программа Монитор Событий получает (перехватывает) событие Перегрев.

8. Она же посылает сообщение на экран диспетчеру.

9. Она же отключает инструмент.

Рисунок 13.
Пример использования механизма событий в базе данных.

Когда используются традиционные методы опроса БД, логика работы совершенно иная. Пришлось бы разработать дополнительную программу, которая периодически выполняла бы операцию выборки из таблицы Инструмент по критерию "Температура > 5000". Это очень заметно сказалось бы на эффективности, поскольку операция SELECT влечет серьезные накладные расходы.

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

Типы данных, определяемые пользователем

Проблемы с типами данных, о которых шла речь выше, решаются за счет интеграции в сервер новых типов данных. К сожалению, далеко не все современные СУБД поддерживают типы данных, определенные пользователем. Пока только СУБД Ingres включает такой механизм. Эта система предоставляет программисту возможность определять собственные типы данных и операции над ними и использовать их в операторах SQL. Для определения нового типа данных необходимо написать и откомпилировать функции на языке СИ, после чего собрать редактором связей некоторые модули Ingres. Отметим, что введение новых типов данных является по сути изменением ядра СУБД. Важно и то, что в Ingres типы данных, определяемые пользователем, могут быть параметризованными.

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

Раздел 2. Сервер базы данных......................................................................................................................................................... 1

2.1. Технология и модели "клиент-сервер"............................................................................................................................... 1

2.2. Эволюция серверов баз данных.......................................................................................................................................... 8

2.3. Активный сервер.................................................................................................................................................................... 12

2.3.1. Актуальные задачи....................................................................................................................................................... 13

2.3.2. Традиционные подходы.............................................................................................................................................. 14

Процедуры базы данных....................................................................................................................................................... 19

Правила....................................................................................................................................................................................... 21

События в базе данных.......................................................................................................................................................... 24

Типы данных, определяемые пользователем................................................................................................................... 30