Оператор drop trigger

Оператор CREATE TRIGGER

DELETE FROM T1

DELETE FROM T1

Команда DELETE

Команда предназначена для удаления записей, удовлетворяющих условиям подзапроса, из указанной таблицы. Директива DELETE не может удалять столбцы (изменяет структуру таблицы команда ALTER TABLE) и не может удалить саму таблицу (DROP TABLE). Команда DELETE не может также удалить или очистить содержимое отдельных полей (UPDATE).

DELETE FROM T1;

DELETE FROM T1 WHERE (ID = 124;

WHERE (FIO LIKE '%Иванов%') or (PASPORT = 786324);

WHERE (OKLAD < (SELECT AVG(OKLAD) FROM T1));

Так как все операторы раздела DML можно считать "потоковыми", выполнение всех действий будет происходить не поштучно, а большими синхронными порциями (итерациями). Это происходит потому, что СУБД является не интерпретатором, а транслятором стандартных команд.

Работа с триггерами

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

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

Из-за серьезного расхождения в синтаксисе оператора в различных реализациях SQL приведем два наиболее часто встречающихся шаблона:

Стандарт Microsoft:

CREATE TRIGGER ИМЯ_ТРИГГЕРА ON ИМЯ_ТАБЛИЦЫ

FOR {INSERT или UPDATE или DELETE} AS

Операторы SQL RETURN;

Стандарт Oracle:

CREATE OR REPLACE TRIGGER ИМЯ_ТРИГГЕРА BEFORE или AFTER INSERT или UPDATE или DELETE ON ИМЯ_ТАБЛИЦЫ

FOR EACH ROW WHEN УСЛОВИЕ Операторы SQL;

Например, триггер, заполняющий поле первичного ключа таблицы (счетчик – в Microsoft Access), в БД InterBase сильно напоминает стандарт Microsoft:

CREATE TRIGGER TR_ID_T1 FOR T1

BEFORE INSERT AS

BEGIN

NEW.ID = GEN_ID(GEN_ID_T1, 1); END;

Однако этот триггер будет работать только, если генератор GEN_ID_T1 существует и имеет определенное значение:

CREATE GENERATOR GEN_ID_T1; SET GENERATOR GEN_ID_T1 to 1;

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

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

DROP TRIGGER ИМЯ ТРИГГЕРА;

После всего этого, была получена директива начальства: "Удалить из списка постоянных покупателей отдел ЦКБ за несвоевременность расчетов и малые объемы заказов". Подразумевается, что наше руководство отдает себе отчет в том, что будет произведено не только удаление самого покупателя, но и всех сделок, которые он совершил. Следующий оператор, разумеется, приведет к очевидной ошибке:

DELETE FROM T_Customer

WHERE (Name LIKE '%ЦКБ%');

Корректной будет лишь следующая цепочка операторов:

DELETE FROM T_Sell WHERE (Customer_ID = 2);

DELETE FROM T_Customer WHERE (ID = 2);

Если такая ситуация повторяется периодически рационально разработать триггер (BEFORE DELETE), который перед удалением записи в T_Customer: будет производить удаление всех связанных записей в T_Sell.

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

NEW - это "новая" запись или ее новое состояние;

OLD - это "старая" запись или ее первоначальное состояние. Например, увеличим стоимость на 25 %

NEW.Cost = OLD.Cost *1,25

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

DELETE FROM T_Customer WHERE (Name LIKE '%ЦКБ%');

15. Модели "Клиент-сервер" в технологии баз данных

В зависимости от взаимного расположения программы и хранилища данных можно выделить типы БД: локальные и удаленные. Для работы с локальными БД используются "локальные" приложения, а для работы с удаленными данными - "клиент - серверные" приложения.

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

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

1) Пользователь работает с локальной копией БД, содержимое которой обновляется при формировании нового запроса. При этом с сервера пересылается новая копия всей таблицы. В результате - резко возрастает нагрузка сети.

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

3) Работа с БД осуществляется с разных компьютеров, причем контроль доступа очень условен.

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

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

Наряду с появившимися проблемами по установке ПО на всех компьютерах клиентов, технология обладает рядом существенных достоинств:

1) Необычайно снижается трафик сети;

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

3) Резкое уменьшение сложности клиентских приложений за счет отсутствия в них кода, связанного с контролем за состоянием БД и разграничения доступа к ней.

Для реализации архитектуры "клиент-сервер" используются многопользовательские СУБД (Oracle, Microsoft SQL Server). Описанная архитектура является двухуровневой. Клиентское приложение в ней называют "сильным" или "толстым" клиентом.

Развитие архитектуры "клиент-сервер" привело к появлению трехуровневой архитектуры, в которой кроме сервера и приложений клиентов присутствует еще и сервер приложений. Он является промежуточным звеном между сервером БД и клиентами.

Выгоды этой технологии очевидны:

1) Явное упрощение клиентских приложений и их настроек;

2) Разгрузка сервера БД (часть функций выполняет сервер приложений);

3) Единое поведение всех клиентов и независимость от платформы. Такие системы, основанные на трехуровневой сетевой архитектуре, называют также распределенными (см. аналогию с распределенной БД). Однако разработка таких систем достаточно проблемна, так как требует знания технологии MIDAS (Multi-tier Distributed Application Services) - службы многоуровневых распределенных приложений. Эта технология состоит из ряда элементов:

1) Удаленный брокер данных (Remote Data Broker) - интерфейс обмена данными между сервером приложений и клиентом;

2) Брокер бизнес - объектов (Business Objects Broker) - позволяет размешать сервер приложений одновременно на нескольких компьютерах;

3) брокер ограничений (Constraints Broker) - распределяет ограничения между отдельными уровнями системы.

Методология MIDAS поддерживает разработку приложений на следующих технологиях межпрограммного и межкомпьютерного взаимодействия:

1) DCOM (Distributed Component Object Model) - модель распределенных (удаленных) объектов;

2) MTS (Microsoft Transaction Server) - дополнение технологии СОМ для управлениями транзакциями;

3) CORBA (Common Object Request Broker Architecture) – взаимодействие между объектами, расположенными на различных платформах. В заключении можно сказать, что выбор наиболее подходящей архитектуры ("локальной" - одноуровневой или "клиент-серверной" - многоуровневой) должен зависеть только от поставленной перед разработчиком задачи.

Работа технологии "клиент-сервер"

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

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

– Обеспечивается более широкий доступ к существующим базам данных.

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

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

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

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

– Эта архитектура весьма естественно отображается на архитектуру откры­тых систем.

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

Дата добавления: 2015-05-09