Проверяемый текст
Пушников А.Ю. Введение в системы управления базами данных. Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999.
[стр. 18]

2.
При декларировании ограничения СУБД автоматически генерирует триггеры, выполняющие необходимые действия по проверке ограничений.
Примером использования функций ядра для проверки декларативных ограничений является автоматическая проверка уникальности индексов, соответствующих потенциальным ключам отношений.
В качестве другого примера можно привести поддержку ссылочной целостности средствами СУБД ORACLE.
Ограничение ссылочной целостности является в ORACLE объектом базы данных, хранящим формулировку этого ограничения.
Проверка ограничения выполняется функциями ядра ORACLE со ссылкой на этот объект.
Ограничение целостности в этом случае нельзя модифицировать иначе, как используя декларативные операторы создания и модификации ограничений.
Примером генерации новых триггеров для реализации декларативных ограничений, может служить система Visual FoxPro.
Триггеры, автоматически сгенерированные Visual FoxPro при объявлении ограничений ссылочной целостности можно посмотреть и даже внести в них изменения, так чтобы они могли выполнять некоторые дополнительные действия.
Если система не поддерживает ни декларативную поддержку ссылочной целостности, ни триггеры,
то программный код, следящий за корректностью базы данных, приходится размещать в пользовательском приложении (такой ведь код все равно необходим!).
Это сильно затрудняет разработку программ и не защищает от попыток пользователей напрямую внести некорректные данные в базу данных
[45].
Особенно сложно становится в том случае, когда имеется сложная база данных и множество различных приложений, работающих с ней (например, к базе данных торгового предприятия может обращаться несколько приложений, таких как "Складской учет", "Прием заказов", "Главный бухгалтер" и т.п.).
Каждое из таких приложений должно содержать один и тот же код, отвечающий за поддержание целостности базы данных.
Особенно весело становится разработчику, когда необходимо внести изменения в логику поддержания целостности.
Приходится заменять во всех
18
[стр. 135]

Если ограничение целостности реализовано в виде триггеров, то этот программный код является просто телом триггера.
Если используется декларативное ограничение целостности, то возможны два подхода: 1.
При декларировании (объявлении) ограничения текст ограничения хранится в виде некоторого объекта СУБД, а для реализации ограничения используются встроенные в СУБД функции, и тогда этот код представляет собой внутренние функции ядра СУБД.
2.
При декларировании ограничения СУБД автоматически генерирует триггеры, выполняющие необходимые действия по проверке ограничений.
Примером использования функций ядра для проверки декларативных ограничений является автоматическая проверка уникальности индексов, соответствующих потенциальным ключам отношений.
В качестве другого примера можно привести поддержку ссылочной целостности средствами СУБД ORACLE.
Ограничение ссылочной целостности является в ORACLE объектом базы данных, хранящим формулировку этого ограничения.
Проверка ограничения выполняется функциями ядра ORACLE со ссылкой на этот объект.
Ограничение целостности в этом случае нельзя модифицировать иначе, как используя декларативные операторы создания и модификации ограничений.
Примером генерации новых триггеров для реализации декларативных ограничений, может служить система Visual FoxPro.
Триггеры, автоматически сгенерированные Visual FoxPro при объявлении ограничений ссылочной целостности можно посмотреть и даже внести в них изменения, так чтобы они могли выполнять некоторые дополнительные действия.
Если система не поддерживает ни декларативную поддержку ссылочной целостности, ни триггеры
(как, например, FoxPro 2.5), то программный код, следящий за корректностью базы данных, приходится размещать в пользовательском приложении (такой ведь код все равно необходим!).
Это сильно затрудняет разработку программ и не защищает от попыток пользователей напрямую внести некорректные данные в базу данных.

Особенно сложно становится в том случае, когда имеется сложная база данных и множество различных приложений, работающих с ней (например, к базе данных торгового предприятия может обращаться несколько приложений, таких как "Складской учет", "Прием заказов", "Главный бухгалтер" и т.п.).
Каждое из таких приложений должно содержать один и тот же код, отвечающий за поддержание целостности базы данных.
Особенно весело становится разработчику, когда необходимо внести изменения в логику поддержания целостности.
Приходится заменять во всех
программах одни и те же места, перекомпилировать все приложения и распространять по рабочим местам новые версии.
Классификация ограничений целостности по времени проверки По времени проверки ограничения делятся на:  Немедленно проверяемые ограничения.
 Ограничения с отложенной проверкой.
Определение 6.
Немедленно проверяемые ограничения проверяются непосредственно в момент выполнения операции, могущей нарушить ограничение.
Например, проверка уникальности потенциального ключа проверяется в момент вставки записи в таблицу.
Если ограничение нарушается, то такая операция отвергается.
Транзакция, внутри которой произошло нарушение немедленно проверяемого утверждения целостности, обычно откатывается.
Определение 7.
Ограничения с отложенной проверкой проверяется в момент фиксации транзакции оператором COMMIT WORK.
Внутри транзакции ограничение может не выполняться.
Если в момент фиксации транзакции обнаруживается нарушение ограничения с отложенной проверкой, то транзакция откатывается.
Примером ограничения, которое не может быть

[Back]