Гайдамакин Н. А. 10 страница

Для примера приведем запросы по добавлению в таблицу «Сотрудники» нового поля «Оклад», добавлению нового индек­са «ОкладСотрудники», удалению поля «Оклад», добавлению внешнего ключа «№_Отдела» и удалению внешнего ключа:

ALTER TABLE Сотрудники ADD COLUMN Оклад CURRENCY;

ALTER TABLE Coтрудники АDD CONSTRAINT OкладCoтрудники Оклад;

ALTER TABLE Сотрудники DROPCOLUMN Oклад;

ALTER TABLE Сотрудники ADD CONSTRAINT Работа FOREIGN KEY (№_Отдела)

REFERENCES Подразделения (№_Отдела);

ALTER TABLE Сотрудники DROP CONSTRAINT Работа;

Запросы на удаление таблицы или индекса реализуются SQL-инструкцией DROP TABLE с указанием имени удаляемой таблицы или индекса. Следующий пример иллюстрирует уда­ление из базы данных таблицы «Сотрудники» и удаление ин­декса «ОкладСотрудники»:

DROPTABLE Сотрудники;

DROPINDEX ОкладСотрудники ON Сотрудники;

Запросы на создание индекса реализуются SQL-инструкцией CREAТЕINDEX с использованием зарезервированного слова UNIQUE для запрета повтора значений в индексируемом поле и необязательного предложения WITH с параметрами DISALLOW NULL и IGNORE NULL для запрета/разрешения нулевых (пустых) значений в индексируемом поле. Зарезерви­рованное слово PRIMARY позволяет определить создаваемый индекс ключом таблицы (при этом создаваемый индекс по умол­чанию является уникальным, т.е. повторы значений не допус­каются).

В следующем примере в таблице «Сотрудники» создастся уникальный индекс «ИндексСотрудника» по полю «Таб_№» с запретом пустых значений:

CREAТЕ UNIQUE INDEX ИндексСотрудника

ON Сотрудники (Таб_№)

WITH DISALLOW NULL;

4.3.2.4. Подчиненные (сложные) запросы

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

Первый вариант реализуется через указание в SQL-инструкциях в качестве имен таблиц и имен полей имен запросов и полей запросов. Синтаксис таких запросов ничем не отличает­ся от обычных запросов, а его исполнение осуществляется в две фазы. По запуску основного запроса сначала неявно запус­кается запрос, формирующий источник данных, и по заверше­нию его исполнения запускается основной (внешний) запрос.

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

Использование внутренней инструкции SELECT для фор­мирования условий отбора записей во внешнем запросе возмож­но одним из трех способов:

• через предикаты сравнения «для некоторых/для всех» — ANY, SOME, ALL;

• через предикат вхождения IN;

• через предикат существования EXISTS.

В первом способе конструкция запроса может выглядеть следующим образом:

SELECT.. FROM...WHERE Выражениеà[ ANY|SOME|ALL ] (SELECT...);

где à — оператор сравнения.

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

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

Для примера на рис. 4.23, а приведен запрос по отбору из таблицы «Заявки» тех записей, которые могут быть удовлетво­рены в соответствии с данными по таблице «Квартиры», т. е. тех записей из таблицы «Заявки», которые удовлетворяют срав­нению по полям «КолКомп», «Площадь» и «Этаж» хотя бы с некоторыми (ANY) записями из таблицы «Квартиры», выбира­емыми при условии «Продано=Нет».

Рис. 4.23, а. Пример подчиненного запроса на основе предиката ANY

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

Рис. 4.23, б. Пример подчиненного запроса па основе предиката ALL

Принцип действия запроса по второму способу заключа­ется в поиске среди результирующего набора записей внешней SQL-инструкции тех записей, для которых значение определен­ного выражения входит в список записей, отбираемых внутренней инструкцией SELECT. Конструкция запроса с предика­том IN выглядит следующим образом:

SELECT... FROM... WHERE Выражение [ NOT ] IN (SELECT...);

В качестве примера на рис. 4.24 приведен запрос по тем же исходным данным (таблицы «Сотрудники» и «Премирование») для отбора записей только тех сотрудников, записи которых по премиям были в списке премий, равных или превышающих 100%.

Рис. 4.24. Пример с подчиненным запросом на основе предиката IN

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

В третьем способе построения подчиненного запроса пре­дикат EXISTS (с необязательным зарезервированным словом NOT) используется в логическом выражении для определения того, должен ли подчиненный запрос возвращать какие-либо записи. Исходя из этого, каждая запись, отбираемая во внеш­ней SQL-инструкции, идет в итоговый набор данных только тог­да, когда при ее условиях отбирается (существует) хотя бы одна запись по внутренней инструкции SELECT. Конструкция зап­роса в этом случае может выглядеть следующим образом:

SELECT...FROM..WHERE ([NOT] Exists (SELECT...));

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

Рис. 4.25. Пример с подчиненным запросом на основе предиката EXISTS

Следует заметить, что использование предиката NOT EXISTS сформирует список ни разу не премированных сотруд­ников. В последнем примере можно также увидеть, что альтер­нативным решением для реализации такого запроса является использование запроса на внутреннее соединение (INNER JOIN).

Внутренняя инструкция SELECT может также использо­ваться в качестве выражения для вычисляемого поля внешней SQL-инструкции. Конструкция запроса в этом случае может выглядеть следующим образом:

SELECT... (SELECT... ИмяВычПоля FROM..WHERE...;

Обязательным условием при этом является то, чтобы внут­ренняя инструкция SELECT для каждой отбираемой по внеш­ней SQL-инструкции записи возвращала не более чем одну за­пись но не более чем одному полю.

Приведем пример подобного запроса, отбирающего все за­писи по полю «Марка» из таблицы «Товары», с формированием дополнительного поля «Категория», значения которого воз­вращаются внутренней инструкцией SЕLЕСТ из таблицы «ТипыТоваров» при условии совпадения значения поля «КодТипа» из таблицы «Товары» для текущей записи внешней SQL-инструкции с аналогичным полем «КодТипа» в записях таблицы «ТипыТоваров»:

SELECT Товары.Марка, (SELECT ТипыТоваров.Категория FRОМ Типы

WHERE (Товары.КодТипа=ТипыТоваров.КодТипа);)

AS Категория

FROM Товары;

Нетрудно заметить, что целью использования в данном при­мере внутренней инструкции SELECT является формирование в наборе данных, отбираемых из таблицы на стороне «Мно­гие», дополнительного поля по значению какого-либо поля из связанной таблицы на стороне «Один». Исходя из этого, аль­тернативным способом решения данной задачи может быть ис­пользование запроса на внутреннее соединение:

SELECT Товары.Марка,ТипыТоваров.Категория

FROM Товары INNER JOINT ТипыТоваров ON Товары.Код-Типа = ТипыТоваров.КодТипа;

В тех случаях, когда отбор данных внешней SQL-инструкцией осуществляется из таблицы на стороне «Один», внутрен­няя инструкция SELECT может использоваться для дополни­тельного поля, формируемого на основе групповой операции по группам соответствующих связанных записей в таблице на стороне «Многие». Приведем пример отбора записей по полю «Категория» из таблицы «ТипыТоваров» с дополнительным полем «СредняяЦена», формируемым на основе статистичес­кой функции AVG по полю «Цена» для групп связанных запи­сей в таблице «Товары»:

SELECT ТипыТоваров.Категория, (SELECT Avg(Toвары.Цена)

AS СредняяЦена

FROM Товары

GROUPВY Товары.КодТипа

НАVING (ТипыТоваров.КодТипа=Товары.КодТипа);) АS Сред­няяЦена

FROM ТипыТоваров;

Опять-таки отметим, что альтернативным решением по данному примеру может быть использование следующего зап­роса на внутреннее соединение:

SELECT ТипыТоваров.Категория, Avg(Toвapы.Цена) AS СредняяЦена

FROM ТипыТоваров INNER JOINT Товары ON ТипыТоваров.КодТипа=Товары.КодТипа

GROUP ВY ТипыТоваров.Категория;

4.3.2.5. Оптимизация запросов

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

^* Кузнецов С.Д. Введение в СУБД. // СУБД. — № 4. — 1995. — С. 98.

 

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

• лексический и синтаксический разбор запроса;

• логическую оптимизацию;

• семантическую оптимизацию;

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

• непосредственное выполнение запроса.

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

Логическая оптимизация запроса может включать различ­ные эквивалентные преобразования, «улучшающие» представ­ление запроса. Такие преобразования можно разбить на три группы:

• преобразования предикатов сравнения;

• преобразования порядка реляционных операций (соеди­нения, объединения, выборки);

• приведение запросов с подчиненными запросами к зап­росам на соединение (JOIN).

Преобразования предикатов сравнения, улучшающие в целях оптимизации представление запроса, в свою очередь, разделяются на:

• приведение предикатов сравнения к каноническому виду;

• приведение логического условия сравнения к каноничес­кому виду.

Каноническим называется такой вид предикатов сравнения, который содержит сравнение простых выражений. Можно выделить три типа таких сравнений:

• Имя поля Операция сравнения Константное арифмети­ческое выражение;

• Имя поля Операция сравнения Арифметическое выраже­ние;

• Арифметическое выражение Операция сравнения Кон­стантное арифметическое выражение.

В первом типе под «Константным арифметическим вы­ражением» понимается такое выражение, которое содержит константы и так называемые объемлющие переменные, в лю­бой момент имеющие одинаковое значение в отношении всех

где МРОТ — объемлющая переменная, определяющая величи­ну минимального размера оплаты труда.

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

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

где КолДней — переменная, равная количеству рабочих дней в данном месяце.

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

где ИЖД — имя поля той же таблицы «Сотрудники», с данны­ми по количеству иждивенцев для конкретного сотрудника; на­звания таблицы «Сотрудники» для краткости опущены.

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

Преобразования порядка реляционных операций также на­правлены на сокращение возможного количества операций при обработке запросов. Одними из наиболее частых реляционных операций в запросах являются операции соединения (JOIN) и операции ограничения (WHERE restriction). В этом отношении общим правилом оптимизирующего преобразования запросов будет замена последовательности операции соединения с пос­ледующими ограничениями на предварительные ограничения с последующим соединением:

где А и В — имена таблиц.

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

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

Каноническим представлением запроса по данным из n таблиц называется запрос, содержащий n–1 предикат соедине­ния и не содержащий предикатов с подчиненными запросами. Если вернуться к примеру подчиненного запроса с предикатом In на рис. 4.24, то его эквивалентным оптимизируемым выра­жением будет следующее:

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

Для примера предположим, что в таблице «Сотрудники» по полю «Оклад» наложено ограничение целостности, заклю­чающееся в том, что оклад не может быть меньшим величины минимального размера оплаты труда МРОТ, равного 84 руб. Предположим также, что нужно сформировать список сотруд­ников, чей оклад меньше 50 руб. Соответствующий запрос име­ет вид:

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

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

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

Для иллюстрации вариантности процедурных планов рас­смотрим запрос по выборке записей из таблицы «Сотрудники» по возрасту не старше 30 лет и с должностным окладом более 100руб.:

Если по полям «Дата_Рожд» и «Оклад» таблицы «Сотруд­ники» существуют индексы, то возможны три варианта плана выполнения запроса:

1) последовательно без учета индексации просматривать (сканировать) записи таблицы «Сотрудники» и отбирать запи­си при выполнении требуемых условий;

2) сканировать индекс поля «Дата_Рожд» с условием вы­борки «>=#01/01/68#», выбирать соответствующие записи из таблицы «Сотрудники» и среди них отбирать те, которые удов­летворяют условию по полю «Оклад»;

3) сканировать индекс поля «Оклад» с условием выборки «>100 руб.», выбирать соответствующие записи из таблицы «Сотрудники» и среди них отбирать те, которые удовлетворя­ют условию по полю «Дата_Рожд».

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

Если количество записей в таблице «Сотрудники» невели­ко и все они умещаются в одной странице (в одном блоке) фай­ла базы данных, то наименее затратным будет первый вариант. Если записи таблицы «Сотрудники» распределены по множе­ству страниц, менее затратными являются 2-й и 3-й варианты. При этом различия между ними будут определяться так назы­ваемой селективностью значений по полям «Дата_Рожд» и «Оклад».

Селективность определяется главным образом характером статистического распределения значений по соответствующим полям. Исходя из мощности (количества записей), вида (равно­мерное, нормальное) и параметров распределения (среднее зна­чение, максимальное и минимальное значение) можно полу­чить приблизительные оценки количества страниц (блоков) файла базы данных, пересылка которых потребуется в опера­тивную память в ходе выполнения запроса. Так, если по при­веденному примеру имеются некоторые априорные или апос­териорные данные о том, что распределение значений по воз­расту сотрудников является нормальным со средним значением 27 лет, а распределение величин должностных окладов являет­ся равномерным в интервале от 50 руб. до 500 руб., то, очевид­но, наименее затратным будет 2-й вариант процедурного плана выполнения запроса, так как потребует меньшего количества пересылок страниц файла базы данных.

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

4.3.3. Процедуры, правила (триггеры) и события в базах данных

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

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

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

• известить пользователей АИС, имеющих полномочия на принятие резолюций по входящим документам (руководители организации или их секретариаты), и предоставить им доступ к сформированному набору данных;

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

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

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

Разработчиками известной СУБД SyBase был предложен другой оригинальный подход, который можно проиллюстри­ровать следующей схемой:

Функционирование базы данных согласно приведенной схе­ме осуществляется следующим образом:

Рис. 4.26. Принцип механизма событий, правил и процедур в ба­зах данных

1. В базе данных определяются так называемые события (database events), связанные с изменениями данных — добав­ление новой записи (ей) в определенную таблицу, изменение записи(ей), удаление записи (ей).* Для реализации механизма событий в языке SQL введены специальные конструкции (Create DBEvent «Имя» — создать событие, Exec SQL Get DBEvent — получить событие и т.д.);

2. Для каждого события в базе данных определяются пра­вила (triggers) по проверке определенных условий состояния данных. Соответственно в SQL введены конструкции для опи­сания правил (Create Rule «Имя» — создать правило);

3. В зависимости от результатов проверки правил в базе данных запускаются на выполнение предварительно определен­ные процедуры. Процедуры представляют собой последова­тельности команд по обработке данных, имеющие отдельное смысловое значение, и могут реализовываться на упрощенном макроязыке (последовательность команд запуска запросов или выполнения других действий, например по открытию-закры­тию форм, таблиц и т. п.) или на языке 4GL, встроенном в СУБД.

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

 

В последнем случае процедуры представляют собой подпрог­раммы для осуществления сложных операций обработки и ди­алога с пользователем. В язык SQL также введены специаль­ные конструкции описания процедур (Create Procedure «Имя» — создать процедуру).

Суть идеи механизма событий, правил и процедур заклю­чается в том, что они после определения хранятся(!!!)* вмес­те с данными. Соответствующие конструкции введены в стан­дарт SQL — SQL2. Ядро СУБД при любом изменении состоя­ния базы данных проверяет, не произошли ли ранее «поставленные на учет» события, и, если они произошли, обес­печивает проверку соответствующих правил и запуск соответ­ствующих процедур обработки.

* То есть зарегистрировать для автоматической обработки в БД.

 

В отличие от традиционного подхода, когда специальные прикладные программы постоянно «опрашивают» базу данных для обнаружения ситуаций, требующих обработки, «событий­ная» техника более экономична и естественна в технологичес­ком плане. Кроме того, SQL-инструкции, реализующие техни­ку «событий-правил-процедур» в некоторых СУБД с развитым интерфейсом, могут быть созданы, так же как и сложные зап­росы, через специальные конструкторы и мастера, что дает воз­можность их освоения и использования пользователями-непрог­раммистами.

В настоящее время механизм событий, правил и процедур широко распространен и в той или иной мере реализован прак­тически в любой современной СУБД.