Операторы, используемые в процедурах и функциях

BEGIN... END – составной оператор

[ begin_label:] BEGIN

[ statement_list ]

END [ end_label ]

DECLARE – объявление локальных переменных, дескрипторов и состояний, курсоров в процедуре.

 

SET – присваивание значений переменным

SET var_name = expr [, var_name = expr ]...

SELECT... INTO – выборка данных в переменную, т.е. допустима выборка только одной записи. Имена переменных не являются регистрозависимыми.

SELECT id,data INTO x,y FROM test.t1 LIMIT 1;

DECLARE Conditions – определение состояний (условий)

Синтаксис: DECLARE condition_name CONDITION FOR condition_value

condition_value:

SQLSTATE [VALUE] sqlstate_value

| mysql_error_code

DECLARE Handlers – определение обработчика состояний

Синтаксис: DECLARE handler_type HANDLER FOR condition_value [,...] statement

handler_type:

CONTINUE

| EXIT

| UNDO

condition_value:

SQLSTATE [VALUE] sqlstate_value

| condition_name

| SQLWARNING

| NOT FOUND

| SQLEXCEPTION

| mysql_error_code

 

Объявление курсоров

Синтаксис: DECLARE cursor_name CURSOR FOR select_statement

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

 

Открытие курсора

Синтаксис: OPEN cursor_name

Оператор OPEN открывает для использования предварительно объявленный курсор.

 

Оператор считывания данных из курсора

Синтаксис: FETCH cursor_name INTO var_name [, var_name ]...

Оператор FETCH считывает очередную строку открытого курсора и перемещает указатель строки на следующую его строку. Если строк в курсоре больше нет, то вызывается состояние "Нет данных" (SQLSTATE=02000). Для определения состояния необходимо создать обработчик (HANDLER) для него.

 

Закрытие курсора

CLOSE cursor_name

Конструкции ветвления и циклов

 

Конструкция IF

IF search_condition THEN statement_list

[ELSEIF search_condition THEN statement_list ]...

[ELSE statement_list ]

END IF

Конструкция CASE

CASE

WHEN search_condition THEN statement_list

[WHEN search_condition THEN statement_list ]...

[ELSE statement_list ]

END CASE

Конструкция LOOP

17.2.10.3. LOOP Statement

[ begin_label:] LOOP

statement_list

END LOOP [ end_label ]

Конструкция REPEAT

REPEAT Statement

[ begin_label:] REPEAT

statement_list

UNTIL search_condition

END REPEAT [ end_label ]

Конструкция WHILE

WHILE Statement

[ begin_label:] WHILE search_condition DO

statement_list

END WHILE [ end_label ]

 

Тема 15: Постреляционные СУБД

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

Активные базы данных

· По определению БД называется активной, если СУБД по отношению к ней выполняет не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД. Основа этой идеи содержалась в языке SQL. На самом деле триггер - это введённое в БД правило, в соответствии с которым СУБД должна производить дополнительные действия. Плохо лишь то, что триггеры не были полностью реализованы ни в одной из известных систем. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна, накладна и не полностью понятна. Среди вопросов, ответы на которые до сих пор не получены, следующие:

· Как эффективно определить набор вспомогательных действий, вызываемых прямым действием пользователя? (т.е. алгоритм самого триггера).

· Каким образом распознавать циклы в цепочке “действие-условие-действие-...” и что делать при возникновении таких циклов?

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

Гораздо важнее в практических целях реализовать в реляционных СУБД аппарат триггеров. В проекте стандарта SQL - 3 предусматривается существование языковых средств определения условных воздействий. Его реализация будет первым практическим шагом к активным БД (как мы отмечали в разд.1, уже появились соответствующие коммерческие реализации).

Дедуктивные базы данных

По определению, дедуктивная БД состоит из двух частей: экстенсиональной, содержащей факты, и интенсиональной, содержащей правила для логического вывода новых фактов на основе экстенсиональной части и запроса пользователя.

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

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

Не будем более подробно рассматривать конкретные проблемы, применяемые ограничения и используемые методы в дедуктивных системах. Отметим лишь, что обычно языки запросов и определения интенсиональной части БД являются логическими (поэтому дедуктивные БД часто называют логическими). Имеется прямая связь дедуктивных БД с базами знаний (интенсиональную часть БД можно рассматривать как БЗ). Трудно провести грань между этими двумя типами систем.

Какова же связь дедуктивных БД с реляционными СУБД? Основным является то, что для реализации дедуктивной СУБД обычно применяется реляционная система. Такая система выступает в роли хранителя фактов и исполнителя запросов, поступающих с уровня дедуктивной СУБД. Такое использование реляционных СУБД резко актуализирует задачу глобальной оптимизации запросов.

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

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

 

Темпоральные базы данных

Реляционная модель не поддерживает время как особую переменную, хотя и располагает в SQL некоторыми функциями обработки данных типа date и time. Обычные БД хранят мгновенный снимок модели предметной области. Любое изменение в момент времени t некоторого объекта приводит к недоступности состояния этого объекта в предыдущий момент времени. В большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но возможности доступа со стороны пользователя нет.

Конечно, можно явно ввести в хранимые отношения явный временной атрибут и поддерживать его значения на уровне приложений. Более того, в большинстве случаев так и поступают. Недаром в стандарте SQL появились специальные типы данных date и time. Но в таком подходе имеются несколько недостатков: СУБД не знает семантики временного поля отношения и не может контролировать корректность его значений; появляется дополнительная избыточность хранения (предыдущее состояние объекта данных хранится и в основной БД, и в журнале изменений); языки запросов реляционных СУБД не приспособлены для работы со временем.

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

Примером кардинального решения проблемы темпоральных БД может служить СУБД Postgres. Эта система была разработана М.Стоунбрекером для исследований и обучения студентов в университете г.Беркли.

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

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

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

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