8.15. Horowitz В. М. А Run-Time Execution Model for Referential Integrity Maintenance Proc. 8th Intern. Data Engineering Conf - Phoenix, Ariz., February, 1992.

Хорошо известно, что определенные комбинации

1. ссылочных структур (т.е. наборов переменных-отношений, связанных между собой с помощью ссылочных Офаничений);

2. правил удаления и обновления внешних ключей;

3. реальных значений данных в базе данных

могут привести к возникновению некоторых конфликтных ситуаций и потенциально стать причиной непредсказуемого поведения в части реализации (см. [8.10], где можно найти подробные объяснения). Существует три общих подхода к решению подобных проблем.

а) Оставить все это пользователю.

б) Заставить систему выявлять и запрещать попытки определения структур, потенциально способных привести к конфликтам во время выполнения.

в) Заставить систему выявлять и отклонять конфликты, действительно возникающие во время выполнения.

Первый подход не стоит рассматривать, а второй часто приводит к чрезмерным Офаничениям [8.12], [8.17]. Поэтому автор предлагает остановиться на третьем подходе. В статье приведен набор правил осуществления подобных действий во время выполнения и доказана их корректность. Однако отметим, что вопрос о производительности таких динамических проверок не рассматривается. Автор статьи г-н Хорвиц (Horowitz) был активным членом комитета, задачей которого было определение стандарта SQL/92. Высказанные в этой статье предложения действительно были учтены в соответствующих разделах стандарта, связанных со ссылочной целостностью.

8.16. Markowitz V. М. Referential Integrity Revisited: An Object-Oriented Perspective Proc. 16th Intern. Conf on Very Large Data Bases. - Brisbane, Australia, August, 1990. Название статьи, Объектно-ориентированная перспектива , действительно отражает открытую позицию автора, состоящую в том, что ссылочная целостность лежит в основе реляционного представления объектно-ориентированных структур . Однако сама статья посвящена вовсе не обсуждению объектно-ориентированных систем. На самом деле в ней представлен алгоритм, генерирующий на основе диаграммы сущность-связь (глава 13) определение реляционной базы данных, в которой не возникает некоторых проблем, указанных в [8.10] (перекрывающиеся внешние ключи).

В статье также обсуждаются три коммерческих продукта (СУБД DB2, SYBASE и INGRES по состоянию на 1990 год) с точки зрения обеспечения ссылочной целостности. СУБД DB2, предоставляющая декларативную поддержку, показана чрезмерно офаниченной; системы SYBASE и INGRES, предоставляющие процедурную поддержку (с помощью триггеров и правил соответственно), показаны менее офаниченными, чем СУБД DB2, однако громоздкими и сложными в использовании (хотя и сказано, что процедурная поддержка СУБД INGRES технически превосходит поддержку ссылочной целостности в системе SYBASE).

8.17. Markowitz V. М. Safe Referential Integrity Structures in Relational Databases Proc. 17th Intern. Conf. on Very Large Data Bases. - Barselona, Spain, September, 1991.

В статье предлагаются два формальных условия безопасности , гарантирующих, что определенные проблемные ситуации, описанные, например, в [8.10], [8.15], не возникнут. В ней также обсуждается, что именно предоставляется в целях удовлетворения этих условий в коммерческих СУБД DB2, SYBASE и INGRES (опять же, на 1990 год). Применительно к СУБД DB2 показано, что одни реализованные офаничения, налагаемые в целях безопасности [8.12], логически излишни, хотя другие в то же время явно недостаточны (т.е. в системах с СУБД DB2 возможно возникновение некоторых небезопасных ситуаций). Относительно систем SYBASE и INGRES отмечено, что реализованная в них процедурная поддержка не предоставляет возможности обнаружения опасных (и даже некорректных!) ссылочных спецификаций.

8.18. Ross R. G. The Business Rule Book: Classifying, Defining, and Modeling Rules (Version 3.0). - Boston, Mass.: Database Research Group, 1994.

Cm. аннотацию к [8.19].

8.19. Ross R. G. Business Rule Concepts. - Houston, Tx.: Business Rule Solutions, Inc., 1998. Ha протяжении нескольких последних лет в коммерческих продуктах получила широкое распространение поддержка бизнес-правил. Некоторые ведущие специалисты компьютерной индустрии стали склоняться к тому, что они могут представлять собой лучшую основу для разработки и построения баз данных и их приложений (т.е. лучшую, чем ранее признанные методы, подобные созданию моделей сущность-связь , объектному моделированию, семантическому моделированию и т.д.). И мы с этим согласны, поскольку бизнес-правила, по существу, представляют собой ни что иное, как более дружественный пользователю (т.е. менее академический и менее формальный) способ описания предикатов, утверждений и прочих аспектов целостности данных, обсуждавшихся в настоящей главе. Автор этой работы является одним из основных защитников подхода, основанного на использовании бизнес-правил, и его книги рекомендуются всем серьезным практикам. В [8.18] дано исчерпывающее освещение рассматриваемой темы, а [8.19] представляет собой краткое учебное пособие.

8.20. Stonebraker M.R., Wong Е. Access Control in a Relational Data Base Management System by Query Modification Proc. ACM National Conf - 1974. Университетский прототип СУБД INGRES [7.11] был пионером в интересном подходе к реализации ограничений целостности (и офаничений безопасности также; см. главу 16), основанном т.модификации запроса. Ограничения целостности определялись с помощью оператора DEFINE INTEGRITY, имеющего следующий синтаксис.

DEFINE INTEGRITY ON <имя переменной-отношениЯ> IS <логическое выражениё> Например:

DEFINE INTEGRITY ON S IS S.STATUS > 0

Допустим, что пользователь U пытается выполнить операцию REPLACE языка QUEL.

REPLACE S ( STATUS = S.STATUS - 10 ) WHERE S.CITY = London

в системе INGRES она будет автоматически заменена следующей операцией.

REPLACE S ( STATUS = S.STATUS - 10 ) WHERE S.CITY = London AND ( S.STATUS - 10 ) > 0

Конечно, измененная таким образом операция не сможет нарушить офаничение целостности. Недостатком этого подхода является то, что не все офаничения целостности могут быть реализованы таким же простым способом. Фактически в языке QUEL поддерживаются только Офаничения, которые задаются на основе простого ограничивающего условия. Однако даже такую офаниченную поддержку целостности в то время можно было найти далеко не во всех системах.

8.21. Walker А., Salveter S. С. Automatic Modification of Transactions to Preserve Data Base Integrity Without Undoing Updates: Technical Report 81/026.- Stony Brook, N.Y.: State University of New York, June, 1981.

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

8.22. Widom J. and Ceri S. (eds.). Active Database Systems: Triggers and Rules for Advanced Database Processing. San Francisco, Calif.: Morgan Kaufmann, 1996.

Это полезный конспект исследований и руководств по активным системам баз данных (т.е. системам баз данных, которые автоматически выполняют определенные действия в ответ на определенные события; другими словами, по системам с триггерными процедурами). Здесь описано несколько прототипов систем, в частности СУБД Starburst лаборатории IBM Research [25.26], [25.14], [25.17], [25.21], [25.22] и СУБД Postgres Калифорнийского университета в Беркли [25.26], [25.30], [25.32]. В этой книге также излагаются вопросы, относящиеся к стандартам SQL/92, SQL3 (начальной версии) и некоторым коммерческим продуктам (к СУБД Oracle, Informix и Ingres в том числе). Также в книге представлена обширная библиография.

Ответы к некоторым упражнениям

8.1.

а) TYPE CITY POSSREP ( CHAR )

CONSTRAINT THE CITY (CITY ) = London

OR THE CITY (CITY ) = Paris

OR THE CITY (CITY ) = Rome

OR THE CITY (CITY ) = Athens

OR THE CITY (CITY ) = Oslo