2.1.1. Синтаксис оператора create trigger

Оператор состоит из заголовка триггера и тела триггера. Заголовок содержит:

имя триггера, уникальное по БД;

имя таблицы, с которой ассоциируется триггер;

указание на момент, когда триггер должен вызываться.

Тело триггера состоит из опционального списка локальных переменных и операторов.

Синтаксис оператора:

CREATE TRIGGER name FOR { table | view}

[ACTIVE | INACTIVE]

{BEFORE | AFTER} {DELETE | INSERT | UPDATE}

[POSITION number]

AS < trigger_body>

< trigger_body> = [<variable_declaration_list>] < block>

< variable_declaration_list> =DECLARE VARIABLE variable datatype;

[DECLARE VARIABLE variable datatype; .]

< block> =

BEGIN

< compound_statement> [<compound_statement> .]

END

< compound_statement> = {<block> | statement;}

Модификация триггеров

Для модификации триггеров используется оператор ALTER TRIGGER. С помощью ALTER TRIGGER можно менять тело триггера, заголовок триггера, а также триггер целиком.

Для того чтобы изменить триггер, автоматически создаваемый СУБД для проверки условия CHECK, следует использовать оператор ALTER TABLE.

Синтаксис ALTER TRIGGER:

ALTER TRIGGER name

[ACTIVE | INACTIVE]

[{BEFORE | AFTER} {DELETE | INSERT | UPDATE}]

[POSITION number]

AS <trigger_body>

Удаление триггера

Триггер можно удалить командой DROP TRIGGER. Синтаксис оператора:

DROP TRIGGER <имя триггера>

Триггеры и транзакции

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

Триггеры и сообщения о событиях

Триггеры могут быть использованы для того, чтобы уведомить приложение о том, что произошло некоторое событие

Использование триггеров для обновления пользовательских представлений

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

№53) Обзор визуальных компонент. Компоненты работы с базами данных. Создание связанных курсоров (Linked cursors)

Имеются несколько основных компонент (объектов), которые Вы будете использовать постоянно для доступа к БД. Эти объекты могут быть разделены на три группы:

• невизуальные: TTable, TQuery, TDataSet, TField

• визуальные: TDBGrid, TDBEdit

• связующие: TDataSource

Первая группа включает невизуальные классы, которые используются для управления таблицами и запросами. Эта группа сосредотачивается вокруг компонент типа TTable, TQuery, TDataSet и TField. В Палитре Компонент эти объекты расположены на странице Data Access.

Вторая важная группа классов - визуальные, которые показывают данные пользователю, и позволяют ему просматривать и модифицировать их. Эта группа классов включает компоненты типа TDBGrid, TDBEdit, TDBImage и TDBComboBox. В Палитре Компонент эти объекты расположены на странице Data Controls.

Имеется и третий тип, который используется для того, чтобы связать предыдущие два типа объектов. К третьему типу относится только невизуальный компонент TDataSource.

Связанные курсоры позволяют программистам определить отношение один ко многим (one-to-many relationship). Например, иногда полезно связать таблицы КЛИЕНТЫ и ПРОДАЖИ так, чтобы каждый раз, когда пользователь выбирает имя заказчика, то он видит список заказов связанных с этим заказчиком. Иначе говоря, когда пользователь выбирает запись о заказчике, то он может просматривать только заказы, сделанные этим заказчиком.

Класс TDataSource используется в качестве проводника между TTable или TQuery

№54) Современные направления развития БД. Постреляционный подход.

Постреляционный подход.

Основные направления в области разработок постреляционных систем:

1. Postgres – основная характеристика: max следование известным принципам организации СУБД (коренная переделка системы управления внешней памятью).

2. Exodus / Genesis – основная характеристика: создание не системы, а генератора системы наиболее полно соответствующего потребностям приложения путем создания наборов модулей со стандартными интерфейсами.

3. Starburst – основная характеристика: достижение расширяемости системы путем приспособления к нуждам конкретных приложений. Система представляет собой интерпретатор системы правил и набор действий, вызываемых в соответствии с правилами.

В целом СУБД следующего поколения имеют прямую связь с реляционным подходом. Ориентация на расширенную реляционную модель.

1. Расширенная реляционная модель

Основное положение реляционной модели – требование нормализации отношений – атомарность значений. Для банковских систем, систем резервирования и другие требования нормализации не всегда opt.

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

2. Абстрактные типы данных

Самая известная модель СУБД 3-го поколения – Postgres.

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

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

Системы класса postgres не имеют собственного языка программирования, который одинаково понимается как внешней системой, так и СУБД.

3. Генерация систем БД, ориентированных на приложения

Идея – нельзя создать универсальную СУБД, которая будет как достаточна, так и неизбыточна в любом приложении.

Например: Oracle, Iformix.

В 90% случаях Oracle и Iformix используют на 30% возможностей системы, однако приложение несет всю тяжесть СУБД, рассчитанную на использование в более общих случаях.

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

Пример: система резервирования проездных билетов.

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

Пример 2: статистическая система: запросы произвольно-сложные. Например: выдать количество лиц мужского пола, проживающих в России с 1920 по 1930 г., имеющих трех детей и т.д.

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

Генерируется система БД, соответствующая потребностям приложения конкретной системной области.

Современные системы БД имеют выборочную установку приложений.

Существует два подтипа Exodus / Genesis. Основаны на модульности и точности соблюдения условия интерфейсов. Состоят из min ядра и механизма программирования дополнительных модулей. В системе Exodus имеется системное программирование Е (расширение С++) и поддерживается стабильное хранение данных во внешней памяти. Вместо «готовой» СУБД имеется набор «полуфабрикатов» с согласованными интерфейсами, из которых генерируется система, max отвечающая потребности приложений.