щиках не из Лондона. Теперь представление с именем S можно создать, объединив переменные-отношения SA и SB. Если в данном представлении попытаться для по-ставшика из Лондона заменить название города каким-либо другим названием либо для поставшика не из Лондона попытаться указать, что поставшик находится в Лондоне, то при реализации запроса операция UPDATE будет преобразована в операцию DELETE для одной переменной-отношения и в операцию INSERT - для другой. Изложенные в этой главе правила работают в данном случае корректно, так как операция UPDATE определена как пара операций DELETE-INSERT. Однако было сделано неявное предположение, что для обеспечения большей эффективности в практической реализации может использоваться единственная операция UPDATE. Данный пример показывает, что преобразование операции UPDATE для представлений в операцию UPDATE для исходных базовых переменных-отношений не всегда дает правильный результат. Фактически поиск случаев, когда названное преобразование работает корректно, можно отнести к задачам оптимизации.

9.11. Вариант а - да; вариант б - да.

9.12. Операции INSERT и DELETE всегда будут противоположными, если база данных спроектирована в соответствии с принципом ортогонального проектирования (раздел 12.6 главы 12) и если СУБД соответствующим образом поддерживает работу с предикатами переменных-отношений. Но если данные условия не выполняются, возможно, что эти операции не будут взаимно противоположными. Например, если А и В - различные базовые переменные-отношения, вставка кортежа t в пересечение V = А INTERSECT В может привести к вставке кортежа t только в переменную-отношение А (если этот кортеж уже присутствует в переменной-отношении В). Далее, удаление кортежа t из представления V приведет к тому, что кортеж будет удален и из переменной-отношения А, и из переменной-отношения В. (С другой стороны, удаление кортежа t и его последующая повторная вставка всегда гарантируют сохранение статус-кво.) Однако обратите внимание на то, что подобная асимметрия может возникнуть только тогда, когда кортеж t удовлетворяет предикату переменной-отношения А, но до начала операции еще не представлен в этой переменной-отношении.

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

/* Определение новых базовых переменных-отношений */ VAR SNC BASE RELATION

{ SI SI, SNAME SNAME, CITY CHAR } PRIMARY KEY { S } ;

VAR ST BASE RELATION

{ SI SI, STATUS INTEGER } PRIMARY KEY { S } ;

/* Копирование данных в новые базовые переменные-отношения */ INSERT INTO SNC S { S, SNAME, CITY } ; INSERT INTO ST S { S, STATUS } ;

/* Уничтожение исходной переменной-отношения */ DROP VAR S ;

Теперь можно создать требуемое представление.

VAR S VIEW

SNC JOIN ST ;

Заметим, что каждый из атрибутов SI (в переменных-отношениях SNC и ST) можно рассматривать как внешние ключи, ссылаюшиеся друг на друга. Фактически мы имеем строгое отношение один к одному между кортежами переменных-отношений SNC и ST. Это позволяет перейти на уровень сложности один к одному , подробно обсуждавшийся в [13.7].

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

VAR SS BASE RELATION ,

{ SI S# } PRIMARY KEY { Si } ;

INSERT INTO SS S { St } ;

(Фактически именно этот проект рекомендуется использовать в [8.10], однако по совсем другим причинам.) Теперь определение представления S можно изменить следующим образом.

VAR S VIEW

SS JOIN SNC JOIN ST ;

Добавим также в определения переменных-отношений SNC и ST определения внешнего ключа.

FOREIGN KEY { St } REFERENCES SS

ON DELETE CASCADE ON UPDATE CASCADE

И наконец так изменим спецификацию внешнего ключа {SI} в переменной-отношении SP, чтобы этот ключ ссылался не на переменную-отношение S, а на переменную-отношение SS.

Замечание. Идея позволить внешним ключам ссылаться на представления вместо базовых переменных-отношений требует более глубокого изучения. 9.14. Что касается п. а данного упражнения, то ниже приведен пример операции выборки из представления, которая, определенно, завершится ошибкой в некоторых программных продуктах, сушествовавших на момент написания книги. Рассмотрим следующее SQL-определение представления (пример 3 из раздела 9.6).

CREATE VIEW PQ AS

SELECT SP.PI, SUM (SP.QTY ) AS TOTQTY FROM SP

GROUP BY SP.PI ;

Проанализируем результат попытки выполнить следующий запрос.

SELECT AVG ( PQ.TOTQTY ) AS PT FROM PQ ;

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

SELECT AVG ( SUM ( SP.QTY ) ) AS PT

FROM SP

GROUP BY SP.PI;

Однако этот оператор SELECT некорректен, поскольку (как отмечалось при обсуждении примера 7.7.7 в главе 7) язык SQL не допускает, чтобы обобщающие операторы были вложены подобным образом.

Вот еще один пример запроса к тому же представлению PQ, который также вызовет ошибку в некоторых продуктах и по той же причине.

SELECT PQ.Pl FROM PQ

WHERE PQ.TOTQTY > 500 ;

Именно в связи с затруднениями, продемонстрированными в приведенных выше примерах, некоторые профаммные продукты (в частности, СУБД DB2 фирмы IBM) иногда овеществляют представление (вместо использования обычного в этих случаях процесса подстановки) и после этого выполняют запрос в уже овеществленной версии представления. Этот прием, конечно, всегда дает правильные результаты, но существенно снижает производительность. Кроме того, в случае СУБД DB2 для некоторых типов представлений все еще существуют отдельные операции выборки, которые не срабатывают, т.е. в СУБД DB2 либо овеществление используется не во всех случаях, когда подстановка не срабатывает, либо возникают ситуации, когда система затрудняется точно сказать, сработает ли процедура подстановки. Например, второй из двух приведенных выше примеров завершался в СУБД DB2 ошибкой (на время написания книги). См. [4.20], где этот вопрос освещен подробнее.

9.15. Сначала приведем определение проекта варианта б в терминах проекта варианта а.

VAR SSP VIEW S JOIN SP ;

VAR XSS VIEW

S MINUS ( S JOIN SP ) { SI, SNAME, STATUS, CITY } ; Теперь приведем определение проекта варианта а в терминах проекта варианта б. VAR S VIEW

XSS UNION SSP { SI, SNAME, STATUS, CITY } ;