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

8.5. Ceri S., Widom J. Deriving Production Rules for Constraint Maintenance Proc. 16th Intern. Conf. on Very Large Data Bases. - Brisbane, Australia, August, 1990.

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

8.6. Ceri S., Fratemali P., Paraboschi S., and Tanca L. Automatic Generation of Production Rules for Integrity Maintenance ACM TODS. - September, 1994. - 19, № 3.

В статье, основанной на работе [8.5], представлены возможности автоматического исправления повреждений, внесенных в результате нарушения ограничения. Ограничения транслируются в правша вывода с помощью следующих компонентов.

1. Список операций, которые могут нарушать Офаничение.

2. Булево выражение, в результате вычисления которого будет получено значение истина, если ограничение нарушено (в основном, это просто отрицание первоначального ограничения).

3. Восстановительная процедура на языке SQL.

В статье также приведен широкий обзор работ, связанных с этой темой.

8.7. Cochrane R., Pirahesh Н., and Mattos N. Integrating Triggers and Declarative Constraints in SQL Database System Proc. 22 Int. Conf. on Very Large Data Bases. - Mumbai (Bombay), India, September, 1996.

Цитата: Семантика взаимодействия триггеров и декларативных ограничений должна быть точно определена, что позволит избежать противоречий при выполнении и обеспечить пользователей подробной моделью для упрощения понимания подобных взаимодействий. Эта [статья] определяет такую модель . Рассматриваемая модель была применена в среде СУБД DB2 и принята как модель для ожидаемой новой версии стандарта языка SQL (SQL3) (см. приложение Б).

8.8. Codd E.F. Domains, Keys, and Referential Integrity in Relational Databases lnfoDB3. - 1988, -3,№ 1.

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

нию, оставила слишком много вопросов неразрешенными и невыясненными. Между прочим, в ней приводятся следующие аргументы в пользу соблюдения требования, чтобы один потенциальный ключ обязательно выбирался в качестве первичного ключа: Отказаться от этого правила - это то же самое, что попытаться использовать компьютер со схемой адресации основной памяти..., в которой основание системы исчисления изменяется всякий раз при возникновении определенных условий (например, если встретился адрес, являющийся простым числом) . Однако, рассуждая подобным образом, можно прийти к выводу, что одну и ту же схему адресации следует использовать для всех видов объектов. Но разве не удобнее адресовать поставщиков с помощью номера поставщика, а детали - с помощью номеров деталей (не говоря уже о поставках, для которых используется составной адрес )? (На самом деле эта идея глобальной универсальной схемы адресации заслуживает дальнейшего обсуждения. См. обсуждение 5аеяг/телег7 в аннотации к [13.16] в главе 13.)

8.9. Date C.J. Referential Integrity Proc. 7th Intern. Conf on Very Large Data Bases. - Cannes, France, September, 1981. Позднее была издана пересмотренная версия этой статьи (Date C.J. Relational Database: Selected Writings. - Reading, Mass.: Addison-Wesley, 1986).

В статье предложены правила ссылочных действий (преимущественно RESTRICT и CASCADE), которые обсуждались в разделе 8.8 этой главы.

Замечание. Основное различие между первой версией статьи (VLDB 1981) и пересмотренной версией состоит в том, что в первой версии, следовавшей [13.6], для внешнего ключа допускались ссылки на любое количество переменных-отношений, тогда как в пересмотренной версии (соображения по этому поводу рассматриваются в [8.10]) автор уже не придерживается такой чрезмерно общей позиции.

8.10. Date C.J. Referential Integrity and Foreign Keys, (в двух частях) Relational Database Writings 1985-1989. - Reading, Mass.: Addison-Wesley, 1990.

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

Замечание. Определенные позиции этой статьи несколько (не очень существенно) опровергаются аргументами статьи [8.13].

8.11. Date C.J. А Contribution to the Study of Database Integrity Relational Database Writings 1985-1989. - Reading, Mass.: Addison-Wesley, 1990.

Цитата из резюме: В этой статье предпринята попытка наложить некоторую структуру на проблему [целостности] с помощью предлагаемой схемы классификации для ограничений целостности, использования этой схемы для объяснения основополагающих понятий целостности данных, краткого описания подхода к созданию конкретного языка формулирования офаничений целостности и определения некоторых областей для дальнейшего исследования . Эта глава частично ос-

новывается на материале данной статьи, но саму предлагаемую схему классификации следует рассматривать как устаревшую и подлежашую замене пересмотренной версией, описанной в разделах 8.2-8.5 настояшей главы.

8.12. Date C.J. Integrity Chapter 11 of C.J. Date and Colin J. White. A Guide to DB2 (4th ed.). -Reading, Mass.: Addison-Wesley, 1993.

Bo время написания этой книги СУБД DB2 корпорации IBM обеспечивала декларативную поддержку первичных и внешних ключей (одна из первых, если не первая, СУБД среди всех коммерческих СУБД). Следует отметить, что в СУБД DB2 упомянутая поддержка пострадала от введения в реализации нескольких ограничений, общее назначение которых состояло в обеспечении предсказуемого поведения системы. Приведем простой пример. Пусть переменная-отношение R содержит только 2 кортежа со значениями первичного ключа, равными 1 и 2 соответственно. Рассмотрим следующий запрос на обновление: Удвоить каждое значение первичного ключа в переменной-отношении R . При правильном выполнении запроса новые значения первичных ключей в кортежах будут равны 2 и 4 соответственно. Если в СУБД DB2 вначале будет обновляться значение 2 (оно заменяется значением 4), а затем - значение 1 (оно заменяется значением 2), то запрос будет выполнен успешно. Но если вначале попытаться обновить значение 1 (заменяя его значением 2), то будет утрачена уникальность значений первичного ключа и запрос не будет выполнен (база данных останется неизменной). Итак, мы видим, что результат выполнения запроса непредсказуем. Чтобы избежать подобной непредсказуемости, в СУБД DB2 просто запрещены ситуации, в которых она может возникнуть. Однако, к сожалению, некоторые из этих ограничений довольно жесткие [8.17].

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

8.13. Date C.J. The Primacy of Primary Keys: An Investigation Relational Database Writings 1991-1994. - Reading, Mass.: Addison-Wesley, 1995.

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

8.14. Hammer М.М., Sarin S.K. Efficient Monitoring of Database Assertions Proc. 1978 ACM SIGMOD Intern. Conf. on Management of Data. - Austin, Texas, May/June, 1978.

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