9.7. Резюме

Представление — это, по сути, именованное реляционное выражение. Представле­ние можно рассматривать как производную виртуальную переменную-отношение. Операции над представлениями обычно реализуются с помощью процедуры подстанов­ки, состоящей в замене ссылки на имя представления тем выражением, которое это представление определяет. Процедура подстановки работает корректно благодаря свой­ству реляционной замкнутости. Для операций выборки процесс подстановки коррект­но выполняется в 100% случаев (по крайней мере, теоретически, но необязательно на практике для существующих продуктов). Для операций обновления процесс подстанов­ки корректно выполняется также в 100% случаев¹⁰ (опять же, теоретически, но необяза­тельно на практике). Однако для некоторых представлений (например, представлений, определяемых в терминах операции обобщения) попытка обновления обычно приводит к ошибке, поскольку нарушаются установленные в системе ограничения целостности. В этой главе также рассматривался обширный набор принципов, которым должна удовле­творять схема обновления. Была подробно рассмотрена работа схемы обновления для представлений, определенных в терминах операций объединения, пересечения, вычи­тания, выборки, проекции, соединения и расширения. Для каждой из этих операций были описаны соответствующие правила вывода предиката (переменной-отношения).

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

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

Упражнения

' Поскольку мы рассматриваем представления как переменные-отношения, а любые пере­менные всегда обновляемы по определению.

1. Используя реляционное исчисление, предоставьте аналоги алгебраических опре­делений представлений, приведенных в подразделе "Дополнительные примеры" раздела 9.1.

2. Дайте определение представления, содержащего номера поставщиков и номера дета­лей для тех поставщиков и деталей, которые размещены не в одном и том же городе.

3. Дайте определение представления, содержащее кортежи для тех поставщиков, ко­торые находятся в Лондоне.

4. В контексте базы данных поставщиков, деталей и проектов переопределите пере­менную-отношение SP как представление на базе переменной-отношения SPJ.

1. В контексте базы данных поставщиков, деталей и проектов определите представ­ление, включающее данные обо всех проектах (атрибуты номера проекта и назва­ния города), детали для которых поставляет поставщик с номером 'S1' ив кото­рых используется деталь с номером ' Р1'.

2. Пусть имеется представление, определенное следующим образом.

VAR HEAVYWEIGHT VIEW

( { Р RENAME WEIGHT AS WT, COLOR AS COL )

WHERE WT > WEIGHT ( 14.0 ) ) { Pi, WT, COL } ;

Покажите преобразованную форму каждого из перечисленных ниже операторов после выполнения процедуры подстановки.

а) RA := HEAVYWEIGHT WHERE COL = COLOR ( 'Green' ) ;

б) RB := ( EXTEND HEAVYWEIGHT ADD WT + WEIGHT ( 5.3 ) AS WTP )

{ Pi, WTP } ;

в) UPDATE HEAVYWEIGHT WHERE WT = WEIGHT ( 18.0 ) COL := 'White' ; r) DELETE HEAVYWEIGHT WHERE WT < WEIGHT ( 10.0 ) ;

д) INSERT INTO HEAVYWEIGHT

RELATION { TUPLE { Pi Pi ( 'P99' ),

WT WEIGHT ( 12.0 ),

COL COLOR ( 'Purple' ) } } j

9.7. Предположим, что приведенное в упр. 9.6 определение представления HEAVYWEIGHT изменено следующим образом.

VAR HEAVYWEIGHT VIEW

( ( ( EXTEND Р ADD WEIGHT * 454 AS WT ) RENAME COLOR AS COL ) WHERE WT > WEIGHT ( 14.0 ) ) { Pi, WT, COL } ;

(Атрибут WT теперь содержит вес в граммах, а не в фунтах.) Выполните упр. 9.6 для этого случая.

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

9. Какие расширения системного каталога, описанного в главах 3 и 5, необходимы для поддержки механизма представлений? Что можно дополнительно сказать по поводу моментальных снимков?

10. Предположим, что базовая переменная-отношение R была заменена выборками А и В, такими, что объединение A UNION В всегда эквивалентно исходному отношению R, а пересечение A INTERSECT В всегда пустое. Достижима ли в этом случае логи­ческая независимость данных?

9.11.

а) Пересечение A INTERSECT В эквивалентно соединению A JOIN В (это соедине­ние типа "один к одному", что не совсем точно, поскольку в переменной-отношении А могут существовать кортежи, для которых нет соответствующих кортежей в переменной-отношении В, и наоборот). Совместимы ли с подобной эквивалентностью изложенные в разделе 9.4 правила обновления представле­ний, определенных посредством операций пересечения и соединения?

б) Пересечение A INTERSECT В также эквивалентно вычитанию A MINUS (A MINUS В) и вычитанию В MINUS (В MINUS А). Совместимы ли с подобной эквивалентностью изложенные в разделе 9.4 правила обновления представле­ний, определенных посредством операций пересечения и вычитания?

12. Один из принципов, изложенных в разделе 9.4, состоит в том, что операции INSERT и DELETE, насколько это возможно, должны быть противоположными од­на другой. Следуют ли этому принципу изложенные в этом разделе правила об­новления представлений, определенных посредством операций объединения, вычитания и пересечения?

13. В разделе 9.2 (при рассмотрении проблемы логической независимости данных) об­суждалась возможность реструктуризации базы данных поставщиков и деталей по­средством замены базовой переменной-отношения S двумя проекциями этой пере­менной-отношения с именами SNC и ST. Там же отмечалось, что подобная реструк­туризация не всегда тривиальна. Какой смысл имеет последнее замечание?

14. Исследуйте любой доступный для вас SQL-продукт и дайте ответы на следую­щие вопросы.

а) Можно ли привести примеры каких-либо операций выборки данных из пред- ставлений, которые приведут к ошибке?

б) Каковы правила обновления представлений для этого продукта? (Возможно, они окажутся менее строгими в сравнении с теми требованиями, которые были изложены в разделе 9.6.)

9.15. Рассмотрим базу данных поставщиков и деталей, но для простоты будем игнори- ровать наличие переменной-отношения деталей. Ниже сокращенно описаны два возможных варианта проекта базы данных поставщиков и поставок.

а) S (Si, SNAME, STATUS, CITY } SP { St, Pt, QTY }

б) SSP { St, SNAME, STATUS, CITY, Pt, QTY } XSS { St, SNAME, STATUS, CITY }

Проект а можно считать обычным. В проекте б, напротив, переменная-отношение SSP содержит кортеж для каждой поставки, включающий соответст­вующий номер детали, количество деталей и полную информацию о поставщике, тогда как переменная-отношение XSS содержит информацию о тех поставщиках, которые вовсе не поставляют деталей. (Обратите внимание, что оба проекта ин­формационно равносильны и, следовательно, эти проекты служат иллюстрацией принципа взаимозаменяемости!) Напишите определения представлений для вы­ражения проекта б в виде представлений в составе проекта а и наоборот. Также предоставьте все необходимые ограничения базы данных для каждого из вариан­тов проекта (см. главу 8, если потребуется освежить в памяти материал об огра­ничениях базы данных). Имеет ли каждый из проектов какие-либо явные пре­имущества по сравнению с другим? Если да, то какие?

16. Выполните упр. 9.2-9.5 с использованием языка SQL.

17. Еще раз обратитесь к определению реляционной модели, приведенному в конце раздела 3.2 в главе 3, и убедитесь, что теперь вы его понимаете полностью.

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

9.1. Adelberg В., Garcia-Molina Н., Widom J. The STRIP Rule System for Efficiently Maintaining Data // Proc. ACM SIGMOD Int. Conf. on Management of Data.— Tucson, Ariz., May, 1997.

STRIP-— это сокращение полного названия процессора Stanford Real-time Information Processor. Данный процессор использует "правила", т.е., по сути, триг­герные процедуры (см., например, [8.22]), для обновления моментальных снимков (здесь они называются производными данными) при каждом изменении исходных данных в базе. Проблема использования такой системы заключается в том, что ес­ли данные в базе изменяются достаточно часто, то дополнительная нагрузка на систему в связи с выполнением установленных правил оказывается чрезмерной. В статье описываются методы STRIP, позволяющие уменьшить эту нагрузку.

9.2. Adiba М, Derived Relations: A Unified Mechanism for Views, Snapshots, and Distributed Data // Proc. Int. Conf. On Very Large Data Bases. — Cannes, France., September, 1981. См. также более раннюю версию: Adiba М.Е., Lindsay B.G. Database Snapshots // IBM Research Report RJ2772. — March, 1980.

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

9.3. Agrawal D., El Abbadi A., Singh A., and Yurek Т. Efficient View Maintenance of Data Warehouses // Proc. ACM SIGMOD Int. Conf. on Management of Data. — Tucson, Ariz., May, 1997.

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

9.4. Buff H.W. Why Codd's Rule №6 Must Be Reformulated // ACM SIGMOD.— Desember, 1988. — 17, № 4.

В 1985 году Кодд (Codd) опубликовал набор из двенадцати правил, предназначен­ных для использования в качестве "части теста для определения, является ли про­дукт, объявленный как полностью реляционный, на самом деле таковым" [9.5]. Правило Кодда № 6 требует, чтобы все представления, теоретически обновляемые, были обновляемы и в данной конкретной системе. В этой короткой заметке Буфф (Buff) утверждает, что общая проблема обновляемости представлений неразреши­ма, т.е. не существует общего алгоритма определения обновляемости (в смысле

определения Кодда) или ее отсутствия для произвольного представления. Тем не менее следует заметить, что определение обновляемости, использованное в этой главе, несколько отличается от определения, введенного Коддом. Различие состоит в том, что использованное в данной главе определение обновляемости сформули­ровано в терминах предикатов переменных-отношений.

5. Codd E.F. Is Your DBMS Really Relational? and Does Your DBMS Run by the Rules? Computerworld. — October, 1985. — № 14, №21.

6. Colby L.S. Supporting Multiple View Maintenance Policies // Proc. ACM SIGMOD Int. Conf. on Management of Data. — Tucson, Ariz., May, 1997.

"Представлениями" в этой статье именуются не представления, а моментальные снимки. Существует три широко распространенных подхода к поддержке актуаль­ности моментальных снимков.

1. Непосредственный. При каждом обновлении любых исходных переменных-отношений немедленно запускается соответствующая процедура обновления моментального снимка.

2. Отложенный. Моментальный снимок обновляется только по требованию поль­зователя.

3. Периодический. Моментальный снимок обновляется через указанные интерва­лы времени (например, каждый день).

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

9.7. Chamberlin D.D., Gray J.N., Traiger I.L. Views, Authorization, and Locking in a Relational Data Base System // Proc. NCC 44. — Calif. Montvale, N.J.: AFIPS Press, May, 1975.

Содержит краткое логическое обоснование подхода, выбранного для организации обновления представлений в прототипе системы System R (и, следовательно, в сис­темах SQL/DS и DB2, в стандарте SQL и т.п.). См. также [9.15], где можно найти аналогичное обоснование для прототипа системы INGRES.

8. Darwen Н. Without Check Option. Relational Database Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1992.

9. Date C.J., McGoveran D. Updating Union, Intersection, and Difference Views, and Updating Joins and Other Views. Relational Database Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1995.

Замечание. Формальные версии этих статей на время написания настоящей книги находились в процессе подготовки.

9.10. Dayal U., Bernstein Р.А. On the Correct Translation of Update Operations on Relational Views // ACM TODS. — September, 1982. — 7, № 3.

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

9.11. Furtado A.L., Casanova M.A. Updating Relational Views // Query Processing in Database Systems. — New York, N.Y.: Springer Verlag, 1985.

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

9.12. Goodman N. View Update Is Practical // InfoDB. — 1990. — 5, № 2.

Весьма неформальный прагматический обзор проблемы обновляемости представлений. Вот цитата из введения (несколько перефразированная): "Дайал (Dayal) и Бернштейн (Bernstein) [9.10] доказали, что, по существу, все интересные представления не являются обновляемыми. Буфф (Buff) [9.4] доказал, что не существует алгоритма определения обновляемости произвольного представления. Но, кажется, есть небольшая надежда. [Однако] ничто не может быть дальше от истины. Обновления представлений возможны и реальны". И далее в статье приводится ряд методов обновления представлений. Однако ключевое понятие предикатов переменных-отношений не рассматривается.

13. Keller A.M. Algorithms for Translating View Updates to Database Updates for Views Involving Selections, Projections, and Joins // Proc. 4th ACM SIGACT-SIGMOD Symposium on Principles of Database Systems. — Portland, Ore., March, 1985. Предложен набор из пяти критериев, которым должен удовлетворять алгоритм об­новления представлений: отсутствие побочных эффектов, только одноэтапные из­менения, отсутствие ненужных изменений, отсутствие возможности более простых замен и отсутствие пар операций DELETE-INSERT вместо операции UPDATE. В этой работе также представлены алгоритмы, которые удовлетворяют изложенным кри­териям. Кроме всего прочего, приведенные в книге алгоритмы позволяют реализо­вать обновления одного типа с помощью операций другого типа. Например, опе­рация DELETE для представления может быть реализована посредством операции UPDATE в исходной базовой переменной-отношении (например, поставщик может быть удален из представления, описывающего лондонских поставщиков, посредст­вом замены значения атрибута города CITY значением 'Paris'). Другой пример (не вошедший в работу Келлера (Keller)): операция DELETE в представлении V (где V определено посредством операции вычитания A MINUS В) может быть реализована как вставка кортежа в переменную-отношение В, а не как удаление кортежа из пе­ременной-отношения А. Заметьте, что в данной главе мы отбросили подобные спо­собы реализации операций обновления на основании описанных в ней принципов.

14. Quass D. and Widom J. On-Line Warehouse View Maintenance // Proc. ACM SIGMOD Int. Conf. on Management of Data. —Tucson, Ariz., May, 1997.

Под представлениями (view), упомянутыми в заголовке этой статьи, понимаются не представления, а моментальные снимки. В ней приведен алгоритм поддержки моментальных снимков. Он позволяет одновременно выполнять транзакции со­провождения моментальных снимков и запросы к их данным.

9.15. Stonebraker M.R. Implementation of Views and Integrity Constraints by Query Modification // Proc. ACM SIGMOD Intern. Conf. on Management of Data. — San Jose, Calif., May, 1975.

См. комментарии к [9.7].

9.16. Zhuge Y., Garcia-Molina H., Hammer J. and Widom J. View Maintenance in a Warehousing Environment // Proc. ACM SIGMOD Int. Conf. on Management of Data. — San Jose, Calif., May, 1995.

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

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

9.1. Приведенные ниже ответы пронумерованы как 9.1.п, где п— номер примера в разделе 9.1. Здесь используются наши обычные допущения относительно перемен- ных диапазона.

9.1.1. VAR REDPART VIEW

( PX.Pt, PX.PNAME, PX.WEIGHT AS WT, PX.CITY ) WHERE PX.COLOR = COLOR ( 'Red' ) ;

9.1.2. VAR PQ VIEW

( PX.Pt,

SUM ( SPX WHERE SPX.Pt = PX.Pt, QTY ) AS TOTQTY ) ;

9.1.3. VAR CITY_PAIR VIEW

( SX.CITY AS SCITY, PX.CITY AS PCITY ) WHERE EXISTS SPX ( SPX.St = SX.St AND SPX.Pt = PX.Pt ) ;

9.1.4. VAR HEAVY_REDPART VIEW

RPX WHERE RPX.WT > WEIGHT ( 12.0 ) ;

Здесь RPX— это переменная диапазона, которая изменяется на представлении REDPART.

9.2. VAR NON_COLOCATED VIEW

( S TIMES P ) ( St, Pt } MINUS ( S JOIN P ) ( St, Pt } ;

9.3. VAR LONDON SUPPLIER VIEW

( S WHERl CITY = 'London' ) { ALL BUT CITY } ;

Замечание. Из представления исключен атрибут CITY, так как известно, что он все­гда будет иметь значение 'London'. Тем не менее следует заметить, что подобный пропуск атрибута приводит к тому, что любая операция INSERT для данного пред­ставления будет завершаться неудачей (только если для атрибута CITY в исходной переменной-отношении поставщиков не установлено принимаемое по умолчанию значение, равное 'London'). Другими словами, подобные представления, вероятно, вовсе не могут поддерживать операцию INSERT. (В качестве альтернативы сущест­вует идея определения значения по умолчанию для атрибута CITY, равного значе­нию 'London', но только для кортежей, вставляемых через данное представле­ние. Идея значений по умолчанию, специфических для представления, требует более глубокого изучения.)

9.4. Проблема здесь состоит в следующем: "Как определить атрибут QTY в представле- нии SP?". Разумным решением будет такой ответ: для данной пары S#—Р# атрибут SP.QTY нужно определить как сумму всех значений SPJ.QTY, вычисляемую по всем номерам Jt для выбранной пары S#—Р#.

VAR SP VIEW

SUMMARIZE SPJ PER SPJ { St, Pf }

AND SUM ( QTY ) AS QTY ;

9.5. VAR JC VIEW

( SPJ WHERE S# = S# ( 'SI' ) ) { Jf } JOIN ( SPJ WHERE Pi = Pi ( 'РГ ) ) { Ji } ) JOIN

J { Ji, CITY } ;

6. Преобразованные формы читателю предлагается записать самостоятельно. Тем не менее заметим, что случай д приведет к ошибке, так как вставляемый кортеж не удовлетворяет предикату представления.

7. И снова случай д приведет к ошибке, но теперь причина несколько иная. Во-первых, СУБД будет использовать для атрибута WEIGHT значение по умолчанию (скажем, w), поскольку пользователь не передает системе конкретного значения этого атрибута (и, конечно, не может этого сделать). Во-вторых, значение атрибута WT, которое указал пользователь, необязательно будет равным w*454, даже если (что в нашем примере не наблюдается) значение атрибута WT превышает 14.0. Следовательно, вставляемый кортеж опять не удовлетворяет предикату представления.

Замечание. Можно привести доводы, что значение атрибута WEIGHT в новом кортеже должно быть установлено правильно, т.е. равняться указанному для атрибута WT зна­чению, деленному на 454. Эта возможность также требует дальнейшего изучения.

9.8. Приведенный список причин взят из [5.7].

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

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

• СУБД может не включать средств определения потенциальных ключей для соб­ственных нужд (это утверждение истинно для всех современных СУБД). Таким образом, явное объявление потенциальных ключей— единственно доступный (для администратора базы данных) способ информирования СУБД и пользовате­лей о наличии таких ключей.

• Даже если бы СУБД могли самостоятельно определять потенциальные ключи для собственных нужд, явное объявление по крайней мере позволило бы системе удостовериться, что определенные ею ключи не являются несовместимыми с ключами, которые объявил администратор базы данных.

• Администратор базы данных может располагать дополнительной информацией, которая не заложена в СУБД, и, следовательно, оптимизировать ключи, опреде­ленные СУБД автоматически. В [5.7] приведен пример такого случая.

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

9.9. Очевидно, что на эти вопросы невозможно дать окончательных ответов. Ниже из- ложены некоторые соображения.

• Каждому представлению и каждому моментальному снимку в базе данных в ее каталоге будет соответствовать запись в переменной-отношении RELVAR со зна­чением 'View' или 'Snapshot' в атрибуте RVKIND соответственно.

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

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

• Еще одна переменная-отношение в каталоге должна содержать сведения о том, какие переменные-отношения использовались в определениях каждого из представлений и моментальных снимков. Обратите внимание, что структура этой переменной-отношения в определенной степени подобна структуре пере­менной-отношения PART_STRUCTURE (см. рис. 4.6 в главе 4): как одна деталь (или узел) может включать в себя другую, так и некоторое представление (или моментальный снимок) может быть определено в терминах других представ­лений (или снимков). Поэтому проблемы, обсуждавшиеся в ответе к упр. 7.7 в главе 7, имеют отношение и к данному случаю.

9.10. Да! Но отметим следующее. Предположим, что переменная-отношение S с данными о поставщиках заменена выборками SA и SB, где переменная-отношение SA содержит данные о поставщиках из Лондона, а переменная-отношение SB — данные о постав-

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

11. Варианта — да; вариант б — да.

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

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

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

{ Si Si, SNAME SNAME, CITY CHAR } PRIMARY KEY { Si } ;

VAR ST BASE RELATION

{ Si Si, STATUS INTEGER } PRIMARY KEY { Si } ;

/* Копирование данных в новые базовые переменные-отношения */ INSERT INTO SNC S { Si, SNAME, CITY } ; INSERT INTO ST S { Si, 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 { Si } ;

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

VAR S VIEW

SS JOIN SNC JOIN ST ;

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

FOREIGN KEY { Si } REFERENCES SS

ON DELETE CASCADE ON UPDATE CASCADE

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

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

CREATE VIEW PQ AS

SELECT SP.Pf, SUM {SP.QTY j 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.Pi 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 } ;

VAR SP VIEW

SSP { Si, Pi, QTY } ;

Для двух проектов были бы уместны следующие ограничения целостности базы данных.

CONSTRAINT DESIGN_A

IS_EMPTY ( SP { Si } MINUS S { St } ) ; CONSTRAINT DESIGN В

IS_EMPTY ( SSP { Si } INTERSECT XSS { Si } ) ;

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

Проект варианта а, очевидно, лучший по причинам, которые подробно объясняют­ся в главе 11.

9.16. Приведенные ниже ответы пронумерованы как 9.16.И, где я— номер исходного упражнения.

9.16.2. CREATE VIEW N0N_C0L0CATED

AS SELECT S.Si, P.Pt FROM S, P

WHERE S.CITY <> P.CITY ;

9.16.3. CREATE VIEW LONDON SUPPLIER

AS

SELECT S.Si, S.SNAME, S.STATUS FROM S

WHERE S.CITY = 'London' ;

9.16.4. CREATE AS

VIEW SP

SELECT SPJ.Si, SPJ.Pi, SUM ( SPJ. QTY ) AS QTY

9.16.5. CREATE AS

FROM SPJ

GROUP BY SPJ.Si, SPJ.Pi ; VIEW JC

SELECT J.Jt, J.CITY FROM J

WHERE J.Jt IN ( SELECT SPJ.Jt

FROM SPJ

WHERE SPJ.St = 'SI' )

AND J.Jt IN ( SELECT SPJ.Jt

FROM SPJ

WHERE SPJ.P = 'PI' ) ;