Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 43

В SQL Server 2005 появилась новая разновидность триггеров – DDL-триггеры. Они срабатывают в ответ на выполнение операторов языка определения данных (DDL) и охватывают всю группу операторов CREATE/ALTER/DROP, т. е. операторов создания, модификации структуры и уничтожения различных объектов БД. Создание DDL-триггера в текущей БД может выглядеть следующим образом:

CREATE TRIGGER DDLTrigger1 ON DATABASE FOR DROP_TABLE AS

            PRINT ‘Таблица была удалена’

DDL-триггер может быть создан и на уровне сервера СУБД. В этом случае после ключевого слова ON ставится опция ALL SERVER, а после FOR – CREATE_DATABASE, ALTER_DATABASE или DROP_DATABASE. В следующем примере создается триггер, срабатывающий в ответ на создание новой БД на сервере:

CREATE TRIGGER DDLTrigger2 ON ALL SERVER FOR CREATE_DATABASE AS

            PRINT ‘Создана новая база данных’

DDL-триггеры могут запускаться только после выполнения активизирующих операторов, т. е. не могут иметь тип INSTEAD OF. Временно отключить DDL-триггер можно при помощи специального оператора DISABLE TRIGGER. При этом нужно обязательно указывать, на каком именно уровне работает отключаемый триггер: на уровне сервера или текущей БД. Триггер DDLTrigger1 из текущей БД отключается следующим образом:

DISABLE TRIGGER DDLTrigger1 ON DATABASE

Триггер DDLTrigger2, работающий на уровне сервера, отключается так:

DISABLE TRIGGER DDLTrigger2 ON ALL SERVER

5.3.5. Рекомендации по реализации требований целостности

Использование ОЦ

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

Декларативные ОЦ следует использовать, если:

·  описатель требования является типовым, т. е. имеет вид (5.3) – (5.7);

·  само требование связано с одной таблицей БД (а не с соединением и не с объединением таблиц, вообще ни с каким результатом выполнения реляционных операций);

·  реализация требования не связана с автоматическим исправлением некорректных данных.

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

Напомним, что соответствие между типовыми описателями и ОЦ было показано ранее, в табл. 7.6.

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

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

Программирование триггеров связано с решением двух важных вопросов:

·  сколько нужно триггеров, чтобы требование было полностью реализовано;

·  какие именно действия должны выполняться в триггерах.

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

Требование целостности характеризуется множеством контролируемых таблиц tables

tables = {T1, T2, …, Tn}

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

operations = {ins(T1), upd(T1), del(T1), …, ins(Tn), upd(Tn), del(Tn)}.

Выделим подмножество operations’, включающее только те операции, выполнение которых может повлечь нарушение требования целостности; также выделим подмножество tables’ – таблицы, которые обрабатываются при выполнении операций из множества operations’. Тогда: