8.10. Резюме

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

Ограничения целостности можно распределить по четырем категориям.

• Ограничения типа задают допустимые значения для данного типа (или домена) и проверяются при вызове соответствующего оператора выбора значения.

• Ограничения атрибута задают допустимые значения для данного атрибута и ни­когда не должны нарушаться (подразумевается, что ограничения типа проверены).

• Ограничения переменной-отношения задают допустимые значения для данной переменной-отношения и проверяются перед тем, как рассматриваемая перемен­ная-отношение будет обновлена.

• Ограничения базы данных устанавливают допустимые значения для данной ба­зы данных и проверяются при выполнении операторов COMMIT.

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

Затем в общих чертах были описаны основная идея ограничений перехода (остальные ограничения относятся к ограничениям состояния) и практически важные специальные случаи ограничений, представляющие потенциальные, первичные, аль­тернативные и внешние ключи. Потенциальные ключи должны обладать свойством уникальности и неизбыточности, и каждая переменная-отношение должна иметь по крайней мере один потенциальный ключ (исключений нет!). Ограничение, согласно ко­торому значения данного внешнего ключа должны совпадать со значениями соответст­вующего потенциального ключа, называется ссылочным ограничением. Мы познако­мились с несколькими следствиями из идеи ссылочной целостности, включая понятие ссылочных действий (в том числе каскадирование). Последнее обсуждение подвело нас к понятию триггерных процедур.

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

Упражнения

8.1. На основе представленного в разделах 8.2-8.5 синтаксиса запишите следующие ограничения целостности для базы данных поставщиков деталей и проектов.

а) Допустимыми городами являются Лондон ('London'), Париж ('Paris'), Рим ('Rome'), Афины ('Athens'), Осло ('Oslo'), Стокгольм ('Stockholm'), Мадрид ('Madrid') и Амстердам ('Amsterdam').

б) Допустимы только такие номера поставщиков, которые представлены символь- ной строкой, содержащей не менее двух символов, первым из которых является буква ' S', а оставшиеся образуют целое число в диапазоне от 0 до 9 999.

в) Все красные детали должны весить меньше 50 фунтов.

г) Никакие два проекта не могут находиться в одном и том же городе.

д) В любой момент в Афинах может находиться не более одного поставщика.

е) Ни одна поставка по количеству деталей не может превышать удвоенное сред- нее значение количества для всех поставок.

ж) Поставщик с наибольшим статусом не может находиться в одном городе с по- ставщиком с наименьшим статусом.

з) Каждый проект должен находиться в городе, в котором есть хотя бы один по- ставщик.

и) Каждый проект должен находиться в городе, в котором есть хотя бы один по- ставщик деталей данного проекта.

к) Должна существовать по крайней мере одна деталь красного цвета, л) Среднее значение статуса поставщика должно быть больше 18. м) Каждый поставщик в Лондоне должен поставлять деталь с номером 'Р2'. н) Хотя бы одна красная деталь должна весить меньше 50 фунтов, о) Поставщики в Лондоне должны поставлять больше видов деталей, чем постав­щики в Париже.

п) Поставщики в Лондоне должны в сумме поставлять больше деталей, чем по­ставщики в Париже.

р) Ни одна поставка не может быть сокращена (за одно обновление) более чем вдвое по сравнению с текущим значением.

с) Поставщики из Афин могут переехать только в Лондон или Париж, а постав­щики из Лондона — только в Париж.

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

3. Для каждого из ответов к упр. 8.1 приведите пример операции, которая может при­вести к нарушению данного ограничения.

4. Предположим, что выражения CHAR (5) и CHAR {3) обозначают символьные строки длиной 5 и 3 символа соответственно. Сколько типов здесь присутствует — один или два?

5. Пусть А и В — это две переменные-отношения. Определите потенциальные ключи для результата выполнения каждого из приведенных ниже выражений.

а) A WHERE ...

б) А {...}

в) A TIMES В

г) A ONION В

д) A INTERSECT В

е) A MINUS В

ж) A JOIN В

з) EXTEND В ADD <выражениё> AS Z

и) SUMMARIZE A PER В ADD <выражение> AS Z к) A SEMIJOIN В

л) A SEMIMINUS В

Для каждого случая предполагается, что переменные-отношения А и В удовлетво­ряют требованиям для соответствующей операции (т.е. имеют тот же тип, что и в случае операции UNION).

6. Пусть R — переменная-отношение степени п. Какое максимальное количество по­тенциальных ключей может иметь переменная-отношение R?

7. Пусть R— переменная-отношение, имеющая единственными допустимыми значе­ниями особые (и очень важные) отношения степени 0 с названиями DEE и DUM. Ка­кой потенциальный ключ (или ключи) имеет эта переменная-отношение R?

8. В данной главе для внешних ключей обсуждались правила удаления и обновления (DELETE и UPDATE), но не упоминались правила вставки (операция INSERT). Почему?

9. Используя значения из базы данных поставщиков, деталей и проектов (см. рис. 4.5), укажите, каким будет результат выполнения каждой из приведенных ниже операций.

а) Обновить кортеж проекта с номером 'J7', присвоив атрибуту CITY значение 'New York'.

б) Обновить кортеж детали с номером ' Р5', присвоив атрибуту р| значение ' Р4'.

в) Обновить кортеж поставщика с номером 'S5', присвоив атрибуту SI значение 'S8'. Предполагается, что для этой операции установлено правило обновления RESTRICT.

г) Удалить кортеж поставщика с номером 'S3'. Предполагается, что для этой операции установлено правило удаления CASCADE.

д) Удалить кортеж детали с номером 'Р2'. Предполагается, что для этой операции установлено правило удаления RESTRICT.

е) Удалить кортеж проекта с номером 'J4'. Предполагается, что для этой опера- ции установлено правило удаления CASCADE.

ж) Обновить кортеж поставки с ключом 'Sl'-'Pl'-'Jl', присвоив атрибуту Si значение 'S2'.

з) Обновить кортеж поставки с ключом 'S5'-'P5'-'J5', присвоив атрибуту Ji значение 'J7'.

и) Обновить кортеж поставки с ключом 'S5'—'Р5'—'J5', присвоив атрибуту Л значение 'J8'.

к) Вставить кортеж для поставки с ключом ' S5' -' Рб' -' J7'. л) Вставить кортеж для поставки с ключом ' S4' -' Р7' -' j6'.

м) Вставить кортеж для поставки с ключом 'Sl'-'P2'-'jjj' (где 'jjj' —значе­ние номера проекта по умолчанию).

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

COURSE { COURSE!, TITLE } /* Курс */

PREREQ { SUP COURSEI, SUB_C0URSEl } /* Условия */

OFFERING { COURSE*, OFFl, OFFDATE, LOCATION } /* Поток */

TEACHER { COURSEI, OFFl, EMP# } /* Преподаватель */

ENROLLMENT { COURSEI, OFFl, EMPi, GRADE } /* Списки */

EMPLOYEE { EMPi, ENAME, JOB } /* Работник */

Смысл переменной-отношения PREREQ (Предварительные условия) заключается в том, что определенный старший курс (SUP_C0URSEi) требует в качестве обязательного усло­вия предварительного прослушивания некоторого подчиненного курса (SUB_C0URSEi). Назначение остальных переменных-отношений должно быть понятно без каких-либо дополнительных пояснений. Начертите для этой базы данных соответствующую ссы­лочную диаграмму. Дайте также соответствующие определения базы данных (т.е. за­пишите соответствующий набор определений типов и переменных-отношений).

8.11. Две следующие переменные-отношения представляют базу данных, содержащую информацию об отделах и служащих.

DEPT { DEPTi, ... , MGR_EMP|, ... } EMP { EMPi, ... , DEPTi, ... }

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

8.12. Две следующие переменные-отношения представляют базу данных, содержащую информацию о служащих и программистах.

EMP { EMPi, ... , JOB, ... } PGMR { EMPi, ... , LANG, ... }

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

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

14. Запишите ответ к упр. 8.1 на языке SQL.

15. Сравните средства поддержки целостности в языке SQL и тот механизм поддержки целостности, который был описан в основной части этой главы, и укажите разли­чия между ними.

Список литературы

8.1. Aileen A., Hellerstein J.M., and Widom J. Static Analysis Techniques for Predicting the Behavior of Active Database Rules ACM TODS. — March, 1995. — 20, № 1.

В этой статье продолжена работа, начатая в [8.2], [8.5]; см. "экспертная система баз данных" (здесь она называется активной системой баз данных). В частности, в статье описана система правил прототипа Starburst компании IBM (см. [17.50], [25.14], [25.17], [25.21], [2522], а также [8.22]).

8.2. Balaris Е.А. and Widom J. An Algebraic Approach to Rule Analysis in Expert Database Systems // Proc. 20th Int. Conf. on Very Large Data Bases. — Santiago, Chile, September, 1994.

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

8.3. Bernstein Р.А., Blaustein В.Т., Clarke Е.М. Fast Maintenance of Semantic Integrity Assertions Using Redundant Aggregate Data // Proc. 6th Intern. Conf. on Very Large Data Bases. — Montreal, Canada, October, 1980.

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

8.4. Buneman О.P., Clemons Е.К. Efficiently Monitoring Relational Databases // ACM TODS. — September, 1979. —4, № 3.

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

8.5. Ceri S., Widora 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., Fraternali 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.

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

нию, оставила слишком много вопросов неразрешенными и невыясненными. Между прочим, в ней приводятся следующие аргументы в пользу соблюдения требования, чтобы один потенциальный ключ обязательно выбирался в качестве первичного ключа: "Отказаться от этого правила — это то же самое, что попы­таться использовать компьютер со схемой адресации основной памяти..., в ко­торой основание системы исчисления изменяется всякий раз при возникновении определенных условий (например, если встретился адрес, являющийся простым числом)". Однако, рассуждая подобным образом, можно прийти к выводу, что одну и ту же схему адресации следует использовать для всех видов объектов. Но разве не удобнее "адресовать" поставщиков с помощью номера поставщика, а детали — с помощью номеров деталей (не говоря уже о поставках, для которых используется составной "адрес")? (На самом деле эта идея глобальной универ­сальной схемы адресации заслуживает дальнейшего обсуждения. См. обсужде­ние заменителей в аннотации к [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. A 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.

Во время написания этой книги СУБД 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.

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

8.15. Horowitz В. M. A 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. M. 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.

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

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

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 A., 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.

a) TYPE CITY POSSREP ( CHAR ) CONSTRAINT THE_CITY (CITY )

'London'

OR THE_CITY (CITY )

OR THE_CITY (CITY )

OR THE_CITY (CITY )

OR THE CITY (CITY )

'Paris' 'Rome'

'Athens' 'Oslo'

OR THE_CITY (CITY ) = 'Stockholm'

OR THE_CITY (CITY ) = 'Madrid'

OR THE_CITY (CITY ) = 'Amsterdam' ;

Очевидным вариантом сокращенной записи этого выражения может быть сле­дующий.

TYPE CITY POSSREP ( CHAR )

CONSTRAINT THE_CITY ( CITY ) IN { 'London' , 'Paris'

'Rome' , 'Athens' ,

'Oslo' , 'Stockholm' ,

'Madrid' , 'Amsterdam' } ;

б) TYPE S# POSSREP ( CHAR ) CONSTRAINT

SUBSTR ( THE_Si ( S# ), 1, 1 ) = 'S' AND CAST_AS_INTEGER (SUBSTR ( THE_S# ( S# ), 2 ) > 0 AND CAST_AS_INTEGER (SUBSTR ( THE_S| ( Si ), 2 ) < 9999 ;

Здесь подразумевается, что в системе существуют операторы выделения под­строки SUBSTR и явного преобразования типов CAST_AS_INTEGER.

в) CONSTRAINT С IS_EMPTY ( Р WHERE WEIGHT > WEIGHT ( 50.0 ) ) ;

г) CONSTRAINT D COUNT ( J ) = COUNT ( J { CITY } ) ;

д) CONSTRAINT E COUNT ( S WHERE CITY = 'Athens' ) < 1 ;

е) CONSTRAINT F

IS EMPTY ( ( EXTEND SPJ ADD 2* AVG ( SPJ, QTY )

AS X ) WHERE QTY > X ) ;

ж) CONSTRAINT G

IS EMPTY ( ( S WHERE STATUS = MIN ( S { STATUS } ) ) JOIN ( S WHERE STATUS = MAX ( S { STATUS } ) } ) ;

В действительности понятия "поставщик с наибольшим статусом" и "поставщик с наименьшим статусом" не очень хорошо определены, поскольку значения статуса не являются уникальными. Заданное требование интерпретируется так, что если Sx и Sy — некоторые поставщики с "наибольшим статусом" и "наименьшим ста­тусом" соответственно, то Sx и Sy не должны находиться в одном городе. Также включена проверка того, что "наибольший статус" и "наименьший статус" не равны между собой, иначе заданное требование не будет выполняться, в частно­сти оно будет нарушаться, если существует лишь один поставщик.

з) CONSTRAINT Н IS_EMPTY ( J { CITY } MINUS S { CITY } ) ;

и) CONSTRAINT I IS EMPTY ( J WHERE NOT ( TUPLE { CITY CITY } IN

( J { Jl } JOIN SPJ JOIN S ) { CITY } ) ) ;

к) CONSTRAINT J NOT ( IS EMPTY

( P WHERE COLOR = COLOR ( 'Red' ) ) ) ; Заданное ограничение будет нарушено, если деталей нет совсем. Лучшей фор­мулировкой ограничения могла бы быть такая.

CONSTRAINT J IS EMPTY ( P ) OR NOT ( IS EMPTY

~ ( P WHERE COLOR = COLOR ( 'Red' ) ) ) ;

л) CONSTRAINT К IF NOT ( IS_EMPTY ( S ) )

THEN AVG ( S, STATUS ) > 18 END IF ;

В данном случае проверка существования поставщика необходима, поскольку вычисление функции AVG при отсутствии аргумента могло бы привести к воз­никновению исключительной ситуации, м) CONSTRAINT L ISJSMPTY

{ ( S WHERE CITY = 'London' ) { Sf } MINUS ( SPJ WHERE Pi = PI ( 'P2' ) ) { St } ) ;

h) CONSTRAINT M IS_EMPTY ( P ) OR NOT

( IS_EMPTY ( P WHERE COLOR = COLOR ( 'Red' ) AND

WEIGHT < WEIGHT ( 50.0 ) ) ) ;

o) CONSTRAINT N

COUNT ( ( ( S WHERE CITY = 'London' ) JOIN SPJ ) { Pi } ) > COUNT ( ( ( S WHERE CITY = 'Paris' ) JOIN SPJ ) { Pi } ) ;

n) CONSTRAINT О

SUM ( ( ( S WHERE CITY = 'London' ) JOIN SPJ ), QTY ) > SUM { ( ( S WHERE CITY = 'Paris' ) JOIN SPJ ), QTY ) ;

p) CONSTRAINT P IS EMPTY

( ( SPJ JOIN ( SPJ' RENAME QTY AS QTY' ) ) WHERE QTY > 0.5 * QTY' ) ;

c) CONSTRAINT Q IS_EMPTY (

( S JOIN ( S' WHERE CITY = 'Athens' ) ) WHERE CITY Ф 'Athens' AND CITY Ф 'London' AND CITY Ф 'Paris' ) AND IS EMPTY ( ( S JOIN ( S'"WHERE CITY = 'London' ) ) WHERE CITY * 'London' AND CITY Ф 'Paris' ) ;

В качестве вспомогательного упражнения можно попытаться сформулировать предыдущие ограничения в стиле реляционного исчисления, а не в стиле реля­ционной алгебры.

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

8.3.

а) Обращение к оператору выбора значения типа CITY.

б) Обращение к оператору выбора значения типа St.

в) Операция вставки кортежа (INSERT) в переменную-отношение Р, операция об- новления (UPDATE) значения атрибута веса детали WEIGHT.

г) Операция вставки (INSERT) кортежа в переменную-отношение J, операция обнов- ления (UPDATE) значения атрибута CITY — города, в котором выполняется проект.

д) Операция вставки (INSERT) кортежа в переменную-отношение S, операция обнов- ления (UPDATE) значения атрибута города, в котором находится поставщик CITY.

е) Операция вставки (INSERT) или удаления (DELETE) кортежа из переменной- отношения SPJ, операция обновления (UPDATE) значения атрибута размера по- ставки QTY.

ж) Операция вставки (INSERT) или удаления (DELETE) кортежа из переменной- отношения S, операция обновления (UPDATE) значения атрибута статуса постав- щика STATUS.

з) Операция вставки (INSERT) кортежа в переменную-отношение J, операция уда- ления (DELETE) кортежа из переменной-отношения S, операция обновления (UPDATE) значения атрибута города, в котором находится поставщик или в кото- ром выполняется проект CITY.

и) Операция вставки (INSERT) кортежа в переменную-отношение J, операция уда- ления (DELETE) кортежа из переменной-отношения SPJ, операция обновления (UPDATE) значения атрибута номера поставщика или номера проекта.

к) Операция вставки (INSERT) или удаления (DELETE) кортежа из переменной-отношения Р, операция обновления (UPDATE) значения атрибута цвета детали COLOR.

л) Операция вставки (INSERT) или удаления (DELETE) кортежа из переменной-отношения S, операция обновления (UPDATE) значения атрибута статуса постав­щика STATUS.

м) Операция вставки (INSERT) кортежа в переменную-отношение S, операция уда­ления (DELETE) кортежа из переменной-отношения SPJ, операция обновления (UPDATE) значения атрибутов CITY — города, в котором находится поставщик, номера поставщика St или номера детали Pi.

н) Операция вставки (INSERT) или удаления (DELETE) кортежа из перемен­ной-отношения Р, операция обновления (UPDATE) значения атрибута веса детали WEIGHT.

о) Операция вставки (INSERT) или удаления (DELETE) кортежа из переменной-отношения S или переменной-отношения SPJ, операция обновления (UPDATE) значения атрибута CITY — города, в котором находится поставщик, номера по­ставщика Si или номера детали Pi. п) Операция вставки (INSERT) или удаления (DELETE) кортежа из переменной-отношения S или переменной-отношения SPJ, операция обновления (UPDATE) значения атрибута CITY — города, в котором находится поставщик, номера по­ставщика S#, номера детали Р| или размера поставки QTY. р) Операция обновления (UPDATE) значения атрибута размера поставки QTY. с) Операция обновления (UPDATE) значения атрибута CITY ■— города, в котором

находится поставщик. Один тип. Уточнения "(5)" и "(3)" лучше рассматривать как ограничения целост­ности. Как отмечалось в [3.3], первое желательное следствие такого подхода со­стоит в том, что если переменные X и Y определены, как, скажем, CHAR(5) и CHAR(3) соответственно, то сравнение X и Y допустимо, поскольку в этом случае не нарушается условие, требующее, чтобы участвующие в сравнении операнды были одного и того же типа.

8.5. Мы предлагаем в качестве "чернового" следующий перечень ответов (см. замеча­ние в конце ответов к этому упражнению).

а) Любая операция выборки из переменной-отношения А наследует все потенци- альные ключи этой переменной-отношения.

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

в) Любое сочетание К потенциального ключа КА переменной-отношения А и по- тенциального ключа KB переменной-отношения В будет потенциальным ключом для декартова произведения A TIMES В.

г) Единственный потенциальный ключ объединения A UNION В — это комбинация из всех атрибутов (в общем случае).

д) Оставляем этот вариант в качестве упражнения для читателя (пересечение — это не примитивная операция).

е) Каждый потенциальный ключ переменной-отношения А является потенциаль- ным ключом для результата вычитания A MINUS В.

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

з) Потенциальные ключи переменной-отношения А являются потенциальными ключами и для произвольного расширения переменной-отношения А.

и) Потенциальными ключами для произвольной обобщающей операции в пере- менной-отношении А "по переменной-отношению В" являются потенциальные ключи переменной-отношения В.

к) Каждый потенциальный ключ переменной-отношения А является потенциальным ключом для результата выполнения операции полусоединения A SEMIJ0IN В.

л) Каждый потенциальный ключ переменной-отношения А является потенциальным ключом для результата выполнения операции полувычитания A SEMIMINUS В.

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

• Сочетание атрибутов {St, Pi, Ji} не является потенциальным ключом для ре­зультата выполнения операции выборки SPJ WHERE Si = Si ('SI'). Потенци­альным ключом в этом случае является сочетание атрибутов {Pi, Ji}.

• Если переменная-отношение А, имеющая заголовок {X, У, Z} и единственный потенциальный ключ X, удовлетворяет функциональной зависимости Y —> Z (глава 10), то атрибут Y является потенциальным ключом проекции переменной-отношения А по атрибутам Y и Z.

■ Если переменные-отношения А и В одновременно являются результатами выполнения операции выборки из переменной-отношения С, то каждый потенциальный ключ пе­ременной-отношения С является потенциальным ключом объединения A UNION В.

И т.д. Вопрос о наследовании потенциальных ключей подробно обсуждается в [10.6].

8.6. Пусть m— наименьшее целое число, большее либо равное п/2. Переменная- отношение R будет иметь максимально возможное количество потенциальных ключей, если все возможные множества из m атрибутов являются потенциальными ключами либо если п — нечетное число и все возможные множества из ш-1 атри- бутов являются потенциальными ключами. В обоих случаях максимальное количе- ство потенциальных ключей равно п! / (ш! * {n-m)!).

Замечание. Переменные-отношения ELEMENT и MARRIAGE в разделе 8.8 могут слу­жить примером переменных-отношений с максимально возможным количеством потенциальных ключей.

8.7. Переменная-отношение R имеет в точности один потенциальный ключ, а имен- но — пустое множество атрибутов {} (иногда обозначаемое как 0). Замечание. Понятие пустого (или нульарного) потенциального ключа требует не- которого уточнения. Такая переменная-отношение, как R, единственные допусти- мые значения которой есть отношения DEE и DUM, не должна иметь атрибутов, и по- этому "очевидно", что ее единственный потенциальный ключ тоже не имеет атри- бутов. Однако не только переменные-отношения без атрибутов могут иметь по- добный потенциальный ключ. Отметим, что если пустое множество 0 является по- тенциальным ключом некоторой переменной-отношения R, то должны быть вы- полнены следующие условия.

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

• В переменной-отношении R не может содержаться более одного кортежа, потому что в пустом множестве атрибутов любой кортеж имеет одно и то же значение.

Заметим, что наш синтаксис позволяет определить такую переменную-отношение, как, например, показано ниже.

VAR R BASE RELATION { ... } PRIMARY KEY { } ;

Также можно определить переменную-отношение без атрибутов, т.е. переменную-отношение, которая может принимать только два значения: DEE и DUM.

VAR R BASE RELATION { } PRIMARY KEY { } ;

Возвращаясь к вопросу о пустом потенциальном ключе, отметим, что если потенци­альный ключ может быть пустым, то, конечно, может быть пустым и соответствую­щий ему внешний ключ. В [5.5] эти возможности обсуждаются более подробно.

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

• Попытка вставить кортеж поставки (в переменную-отношение SP) будет успеш­ной, только если номер поставщика в этом кортеже существует как номер по­ставщика в переменной-отношении S и номер детали в этом кортеже существует как номер детали в переменной-отношении Р.

• Попытка обновить кортеж поставки будет успешной, если в обновленном кортеже номер поставщика существует как номер поставщика в переменной-отношении S и номер детали существует как номер детали в переменной-отношении Р.

Обратите особое внимание на то, что предыдущие замечания относятся к ссылаю­щейся переменной-отношению, тогда как правила удаления и обновления (явные) применяются к ссылочной переменной-отношению. Поэтому "правило вставки" нельзя рассматривать как правило, подобное правилам удаления и обновления. Это еще одна причина, по которой в конкретный синтаксис не включено никакое явное "правило вставки".

8.9.

а) Операция допустима.

б) Операция недопустима (нарушение уникальности потенциального ключа).

в) Операция недопустима (нарушение правила обновления с установленной опци- ей RESTRICTED).

г) Операция допустима (удаляется кортеж поставщика с номером 's3' и соответ- ствующие кортежи его поставок).

д) Операция недопустима (нарушение правила обновления с установленной опци- ей RESTRICTED).

е) Операция допустима (удаляется кортеж проекта под номером ' j4' и соответст- вующие кортежи поставок для этого проекта).

ж) Операция допустима.

з) Операция недопустима (нарушение уникальности потенциального ключа).

и) Операция недопустима (нарушение ссылочной целостности), к) Операция допустима.

л) Операция недопустима (нарушение ссылочной целостности), м) Операция недопустима (нарушение ссылочной целостности— номер проекта по умолчанию (' j j j') не существует в переменной-отношении J).

8.10. Ссылочная диаграмма показана на рис. 8.1. Возможный вариант определения базы данных представлен ниже. Для упрощения никакие ограничения типов не опреде­ляются, если не считать того, что спецификация P0SSREP для данного определения типа, безусловно, может априори пониматься, как его ограничение.

TYPE COURSE*	POSSREP	CHAR
TYPE TITLE	POSSREP	CHAR
TYPE OFF*	POSSREP	CHAR
TYPE OFFDATE	POSSREP	DATE
TYPE CITY	POSSREP	CHAR
TYPE EMP*	POSSREP	CHAR
TYPE NAME	POSSREP	NAME
TYPE JOB	POSSREP	CHAR
TYPE GRADE	POSSREP	CHAR

VAR COURSE BASE RELATION { COURSE* COURSE*, TITLE TITLE } PRIMARY KEY { COURSE* } ; VAR PREREQ BASE RELATION

{ SUP_COURSE# COURSE*,

SUB COURSE* COURSE* } PRIMARY KEY { SUP COURSE*, SUB_COURSEl } FOREIGN KEY { RENAME SUP_COURSE* AS COURSE* }

REFERENCES COURSE ON DELETE CASCADE ON UPDATE CASCADE FOREIGN KEY { RENAME SUB_COURSE| AS COURSE* }

REFERENCES COURSE ON DELETE CASCADE ON UPDATE CASCADE ;

VAR OFFERING BASE RELATION { COURSE* COURSE*, OFF* OFF*, OFFDATE OFFDATE, LOCATION CITY } PRIMARY KEY { COURSE*, OFF* } FOREIGN KEY { COURSE* } REFERENCES COURSE

ON DELETE CASCADE ON UPDATE CASCADE ;

VAR EMPLOYEE BASE RELATION { EMP* EMP#,

ENAME ENAME,

JOB JOB } PRIMARY KEY { EMP* } ;

VAR TEACHER BASE RELATION { COURSE* COURSE*, OFF* OFF*, EMP* EMP* } PRIMARY KEY { COURSE*, OFF*, EMP* }

FOREIGN KEY { COURSE!, OFFI } REFERENCES OFFERING

ON DELETE CASCADE ON UPDATE CASCADE ; FOREIGN KEY { EMPi } REFERENCES EMPLOYEE ON DELETE CASCADE ON UPDATE CASCADE ;

VAR ENROLLMENT BASE RELATION { COURSE! COURSE!, OFF! OFFi, EMPf EMPf GRADE GRADE } PRIMARY KEY { COURSE!, OFFi, EMPi } FOREIGN KEY { COURSE!, OFF! } REFERENCES OFFERING

ON DELETE CASCADE ON UPDATE CASCADE FOREIGN KEY { EMPi } REFERENCES EMPLOYEE ON DELETE CASCADE ON UPDATE CASCADE ;

PREREQ

SUP COURSE*

SUB COURSE*

COURSE

COURSE#,OFF#

COURSE*

COURSE#,OFF#

OFFERING

TEACHER

ENROLLMENT

EMPLOYEE

EMP*

EMP*

Рис. 8.1. Ссылочная диаграмма для учебной базы данных

Пояснения

1. Множества атрибутов (единичные) {COURSE!} в переменной-отношении TEACHER и {COURSE!} в переменной-отношении ENROLLMENT можно также рас­сматривать как внешние ключи, ссылающиеся на переменную-отношение COURSE. Если ссылочные ограничения от переменной-отношения TEACHER к переменной-отношению OFFERING, от переменной-отношения ENROLLMENT к переменной-отношению OFFERING и от переменной-отношения OFFERING к переменной-отношению COURSE организованы должным образом, то ссылоч­ные ограничения от переменной-отношения TEACHER к переменной-отношению COURSE будут поддерживаться автоматически. Более детальное обсуждение этого вопроса приведено в [8.10].

2. Переменная-отношение OFFERING в этом примере является одновременно ссы- лающейся и ссылочной: существует ссылочное ограничение к переменной- отношению OFFERING от переменной-отношения ENROLLMENT (на самом деле от переменной-отношения TEACHER) и от переменной-отношения OFFERING к пере- менной-отношению COURSE.

ENROLLMENT > OFFERING > COURSE

3. Обратите внимание, что существует два различных ссылочных пути от пере- менной-отношения ENROLLMENT к переменной-отношению COURSE: один непо- средственный (внешний ключ {COURSE!} в переменной-отношении ENROLLMENT) и другой — непрямой, через переменную-отношение OFFERING (внешние ключи {COURSE!,OFFi} в переменной-отношении ENROLLMENT и {COURSE!} в перемен- ной-отношении OFFERING).

ENROLLMENT -> OFFERING -» COURSE

Однако в действительности эти пути не являются независимыми (верхний путь представляет собой комбинацию двух нижних). Более подробное обсуждение этого вопроса можно найти в [8.10]. 4. Также существует два различных ссылочных пути от переменной-отношения PREREQ к переменной-отношению COURSE, но на этот раз они действительно не­зависимы (и имеют совсем разный смысл). И вновь за подробным обсуждением обратитесь к [8.10].

DEPT

DEPT#

MGR EMP#

EMP

8.11. Ссылочная диаграмма показана на рис. 8.2. Обратите внимание, что в базе данных име- ется ссылочный цикл (т.е. существует ссы- лочный путь от каждой из двух перемен- ных-отношений к самой себе). Поскольку определение базы данных для этого упраж- Рис. 8.2. Ссылочная диаграмма с нения несложное, мы его опускаем и не циклом

вдаемся в подробности.

8.12. Ниже приведены только определения переменных-отношений (и лишь схематически).

VAR EMP BASE RELATION { EMPi ... ,

JOB ... } PRIMARY KEY { EMPi } ;

VAR PGMR BASE RELATION { EMPi ... ,

...... ,

LANG ... } PRIMARY KEY { EMPi }

FOREIGN KEY { EMPf } REFERENCES EMP ON DELETE CASCADE ON UPDATE CASCADE ;

Пояснения

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

2. Отметим, что в этом примере существует еще одно ограничение целостности, которое также необходимо поддерживать: служащий должен быть представлен в переменной-отношении PGMR тогда и только тогда, когда значение атрибута ЕМР.JOB для этого служащего— 'Программист'. Однако это, безусловно, не ссылочное ограничение.

8.14. Отметим, что приведенные ниже варианты решения для пп. а и б— это лишь при­ближения к их аналогам, представленным в ответах к упр. 8.1.

а) CREATE DOMAIN CITY CHAR{15) VARYING

CONSTRAINT VALID_CITIES

CHECK ( VALUE IN ( 'London', 'Paris', 'Rome',

'Athens', 'Oslo', 'Stockholm'^

'Madrid', 'Amsterdam' ) ) ;

б) CREATE DOMAIN Si CHAR{5JVARYING CONSTRAINT VALID_S# CHECK

( SUBSTRING ( VALUE FROM 1 FOR 1 ) = 'S' AND CAST ( SUBSTRING ( VALUE FROM 2 ) AS INTEGER ) >= 0 AND CAST ( SUBSTRING ( VALUE FROM 2 ) AS INTEGER ) <= 9999 ) ;

в) CREATE ASSERTION SQL_C CHECK

( P.COLOR <> 'Red' OR P.WEIGHT < 50.0 ) ;

r) CREATE ASSERTION SQL_D CHECK

( NOT EXISTS ( SELECT * FROM J JX WHERE EXISTS ( SELECT * FROM J JY WHERE ( JX.Jt О JY.Jt AND JX.CITY = JY.CITY ) ) ) ) ;

д) CREATE ASSERTION SQL_E CHECK

( ( SELECT COUNT (*) FROM S

WHERE S.CITY = 'Athens' ) < 2 ) ;

е) CREATE ASSERTION SQL_F CHECK

( NOT EXISTS ( SELECT *

FROM SPJ SPJX

WHERE SPJX.QTY > 2 *

( SELECT AVG ( SPJY.QTY ) FROM SPJ SPJY ) ) ) ;

ж) CREATE ASSERTION SQL_G CHECK

{ NOT EXISTS ( SELECT * FROM S SX WHERE EXISTS ( SELECT * FROM S SY WHERE

SX.STATUS = ( SELECT MAX ( S.STATUS )

FROM S ) AND SY.STATUS = ( SELECT MIN ( S.STATUS )

FROM S ) AND SX.SATUS <> SY.STATUS AND SX.CITY = SY.CITY ) ) ) ;

з) CREATE ASSERTION SQL_H CHECK

( NOT EXISTS ( SELECT * FROM J WHERE NOT EXISTS ( SELECT * FROM S WHERE

S. CITY = J. CITY ) ) ) ;

и) CREATE ASSERTION SQL_I CHECK

( NOT EXISTS ( SELECT * FROM J WHERE NOT EXISTS ( SELECT * FROM S WHERE S.CITY = J.CITY AND EXISTS ( SELECT * FROM SPJ

WHERE SPJ.S* = S.SI

AND SPJ.Ji = J.Ji ) ) ) ) ;

к) CREATE ASSERTION SQL J CHECK

( NOT EXISTS ( SELECT * FROM P ) OR EXISTS ( SELECT * FROM P

WHERE P.COLOR = 'Red' ) ) ;

л) CREATE ASSERTION SQL_K CHECK

( ( SELECT AVG ( S.STATUS ) FROM S } > 18 ) ;

Если таблица поставщиков пуста, SQL-оператор AVG будет (ошибочно!) воз­вращать нулевое значение, результатом условного выражения будет значение неизвестно и ограничение не будет считаться нарушенным. В главе 18 можно получить дополнительные сведения по этому вопросу.

м) CREATE ASSERTION SQL_L CHECK

( NOT EXISTS ( SELECT * FROM S

WHERE S.CITY = 'London' AND NOT EXISTS

( SELECT * FROM SPJ WHERE SPJ.Si = S.Si AND SPJ.Pi = 'P2' ) ) ) ;

h) CREATE ASSERTION SQL_M CHECK

( NOT EXISTS ( SELECT * FROM P

WHERE P.COLOR = 'Red' ) OR EXISTS ( SELECT * FROM P

WHERE P.COLOR = 'Red'

AND P.WEIGHT < 50.0 ) ) ;

о) CREATE ASSERTION SQL_N CHECK

( ( SELECT COUNT (*} FROM P

WHERE EXISTS ( SELECT * FROM SPJ WHERE EXISTS ( SELECT * FROM S WHERE

( SELECT COUNT WHERE EXISTS EXISTS

( P.Pt = SPJ.St S.CITY (*) FROM ( SELECT ( SELECT ( P.Pt = SPJ.St S.CITY

SPJ.Pi AND

= S.St AND

= 'London' ) ) )

P

• FROM SPJ WHERE

• FROM S WHERE SPJ.Pi AND

= S.Si AND

= 'Paris' ) ) ) )

>

n) CREATE ASSERTION SQL_0 CHECK

( ( SELECT SUM (SPJ.QTY) FROM SPJ WHERE ( SELECT S.CITY FROM S

WHERE S.Si = SPJ.Si ) = 'London' ) > ( SELECT SUM (SPJ.QTY) FROM SPJ WHERE ( SELECT S.CITY FROM S

WHERE S.St = SPJ.St ) = 'Paris' ) ) ;

p) Реализовать невозможно, с) Реализовать невозможно.

Глава

Представления