17.10. Резюме

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

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

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

Также здесь приведено обсуждение работы со снимками. И, наконец, кратко опи­саны относящиеся к теме аспекты стандарта SQL.

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

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

В случае отношения с информацией о поставщиках, например, можно сделать хо­рошо знакомое отношение S базовым и затем определить две проекции — SNC (на атрибутах S#, SNAME и CITY) и ST (на атрибутах S# и STATUS) — как представле­ния. Или можно создать два базовых отношения, а затем определить представление S (как соединение SNC и ST). Суть в том, что, конечно, обновляемость выбранной базы данных не должна зависеть от вашего решения, какие отношения представлять в виде базовых, а какие — в виде представлений. В нашем примере обновляемость отноше­ния S не должна зависеть от того, является ли S базовым отношением или представ­лением.

Упражнения

17.1. Создайте на базе реляционного исчисления аналоги алгебраических опреде­лений представлений, показанных в разделе 17.3.

17.2. Создайте представление, содержащее номера поставщиков и номера деталей для поставщиков и деталей, которые не совмещены в одном городе.

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

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

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

17.6. Рассмотрите представление, определенное с помощью следующего выражения:

CREATE VIEW HEAVYWEIGHTS AS

( ( ( P RENAME WEIGHT AS WT, COLOR AS COL ) )

WHERE WT > 14 ) [ P#, WT, COL ] ;

Укажите операции, которые будут реально выполнены (преобразованная форма) для каждого из перечисленных ниже случаев:

а) ТА := HEAVYWEIGHT WHERE COL = 'Green' ;

б) ТВ := ( EXTEND HEAVYWEIGHTS ADD WТ + 5 AS WTP ) [ P#, WTP ] ;

в) UPDATE HEAVYWEIGHTS WHERE WT 18 COL := 'White' ;

г) DELETE HEAVYWEIGHTS WHERE WT < 10 ;

д) INSERT ( ( P#:'P99', WT:12, COL:'Purple' ) )

INTO HEAVYWEIGHTS ;

17.7. Предположим, приведенное выше определение представления HEAVYWEIGHTS изменено следующим образом:

CREATE VIEW HEAVYWEIGHTS AS

( ( ( EXTEND P ADD WEIGHT * 454 AS WT ) RENAME COLOR AS COL ) WHERE WT > 14 ) [ P#, WT, COL ] ;

Теперь выполните задание упр. 17.6.

17.8. В главе 5 упоминалось, что иногда для представлений желательно объявлять потенциальные ключи (или первичный ключ), т.е. включать оператор candidate или primary key в выражение create view. Почему желательно иметь такую возможность?

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

17.10. Предположим, что данное базовое отношение R заменено двумя выборками А и В, такими, что объединение A union В всегда равно R, а пересечение A intersect В всегда пустое. Достижима ли логическая независимость данных?

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

б) Пересечение A intersect В также эквивалентно вычитанию A minus (A minus В) и вычитанию В minus (В minus А). Совместимы ли изложенные в этой главе правила обновления пересечений и вычитаний с подобной экви­валентностью?

17.12. Один из принципов, описанных в этой главе, состоит в том, что операции INSERT И DELETE по возможности должны быть противоположными. Удовлетворяют ли этот принцип правила обновления объединений, вычитаний и пересечений?

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

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

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

17.1. Adiba M.E., Lindsay B.G. Database Snapshots // IBM Research Report RJ2772. — 1980.

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

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

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

17.3. 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, 1975.

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

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

17.5. Date C.J., McGoveran D. Updating Union, Intersection, and Difference Views // Database Programming & Design. — 1994. — 7, № 6.

17.6. Date C.J., McGoveran D. Updating Joins and Other Views // Ibid. —.№ 8.

17.7. Date C.J. Updating Views. Relational Database: Selected Writings.— Reading, Mass.: Addison-Wesley, 1986.

Здесь приведена более ранняя трактовка правил обновления представлений. Изложены правила только для обновления выборки, проекции и соединения. Эта работа упоминается здесь только для того, чтобы пояснить, что предло­женные в ней идеи следует заменить новыми, изложенными в этой главе.

17.8. Dayal U., Bernstein P.A. On the Correct Translation of Update Operations on Relational Views // ACM TODS. — 1982. — 7, Ns 3.

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

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

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

17.10. Goodman N. View Update Is Practical // InfoDB. — 1990. — 5, Ns 2.

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

17.11. 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., 1985. -l

Предложен набор из пяти критериев, которым должен удовлетворять алго­ритм обновления представлений: отсутствие побочных эффектов, только одноэтапные изменения, отсутствие ненужных изменений, отсутствие более простых замен и отсутствие пар DELETE-INSERT вместо UPDATE. В этой работе также представлены алгоритмы, которые удовлетворяют изложен­ным критериям. Кроме всего прочего, приведенные в книге алгоритмы по­зволяют реализовать обновления одного типа операциями другого типа. На­пример, операция DELETE на представлении может быть реализована по­средством операции UPDATE на исходном базовом отношении (т.е. по­ставщик может быть удален из представления лондонских поставщиков пу­тем замены значения атрибута города CITY на значение Paris). Другой при­мер (не вошедший в работу Келлера (Keller)): операция DELETE на пред­ставлении V (где V определено как вычитание A minus В) может быть реали­зована как вставка кортежа в В, а не как удаление кортежа из А. Заметьте, что в данной главе мы отбросили подобные способы реализации операций обновления вследствие описанных в этой главе принципов.

17.12. McGoveran D., Date C.J. A New Database Design Principle // Database Programming & Design. — 1994. — 7, № 7.

Пусть А и В являются произвольными отношениями с предикатами РА и РВ соответственно. Говорят, что А и В перекрываются тогда и только тогда, ко­гда можно создать такой кортеж t, что истинными будут оба выражения, PA(t) и PB(t). Тогда принцип проектирования можно записать так:

Пусть А' и В'— два произвольных отношения базы данных и пусть А и В являются проекциями А' и В' соответственно по всем атрибутам, для ко­торых не установлено значение по умолчанию.

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

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

A UNION В непересекающееся объединение A INTERSECT В всегда пустое множество

A MINUS В равно А

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

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

См. комментарии к [17.3J.

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

17.1. Приведенные ниже ответы пронумерованы как 17.1.и, где п— номер при­мера в разделе 17.3.

17.1.1. CREATE VIEW REDPARTS AS

( P.P#, P.PNAME, P.WEIGHT AS WT, Р.СIТУ ) WHERE P.COLQR = 'Red' ;

17.1.2. CREATE VIEW PQ AS

( SP.P#,

SUM ( SPX WHERE SPX.P# = SP.P#, QТУ ) AS TOTQTY ) ;

Конечно, в этом выражении предпочтительнее заменить два вхождения SP.P# на Р.Р#, но тогда будет получено представление, не являющееся точ­ным аналогом исходного алгебраического представления.

17.1.3. CREATE VIEW CITY_PAIRS AS

( S.CITY AS SCITY, P.CITY AS PCITY ) WHERE EXISTS ( SP WHERE SP.S# = S.S# AND SP.P# = P.P# ) ;

17.1.4. CREATE VIEW LCNDON_REDPARTS AS

( REDPARTS WHERE REDPARTS. CITY = 'London' ) ;

Замечание. Ответы к упр. 17.2-17.5 также сформулированы в терминах ре­ляционного исчисления.

17.2. CREATE VIEW NQN_COLOCATED AS

( S.S#, P.P# ) WHERE S.CITY <> Р.С1ТУ ;

17.3. CREATE VIEW LONDON_SUPPLIERS AS

( S.S#, S.SNAME, S.STATUS ) WHERE S.CITY = 'London' ;

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

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

СREAТЕ VIEW SP AS

( SPJX.S#, SPJX.P#,

SUM ( SPJY WHERE SPJY.S# = SPJX.S#

AND SPJY.P# = SPJX.P#, QTY ) AS QTY ) ;

17.5. CREATE VIEW JC AS

( J.J#, J.CITY ) WHERE EXISTS SPJ ( SPJ.S# = 'Sl' AND SPJ.P# = 'Р1’ AND

SPJ.J# = J.J# ) ;

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

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

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

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

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

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

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

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

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

• Каждое представление и каждый снимок будет иметь запись в отношении RELATIONS с соответствующим ("View" или "Snapshot") значением атри­бута RELTYPE.

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

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

• Еще одно новое отношение будет содержать информацию о ссылках меж­ду представлениями и снимками. Заметьте, что структура этого отношения подобна структуре отношения PART_STRUCTURE (см. рис. 4.4 в гла­ве 4) — как одна часть может содержать другую, так и представление мо­жет быть определено в терминах других представлений и снимков.

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

17.11. а) да; б) да.

17.12. Для объединения и вычитания операции insert и delete всегда являются про­тивоположными, хотя для пересечения это может быть не так. Например, если А и В — различные базовые отношения, то вставка кортежа t в пересе­чение V = A intersect В может привести к вставке кортежа t только в отно­шение А (если этот кортеж уже присутствует в В). Заметим еще раз, что по­добная асимметрия может возникнуть, только если база данных плохо спро­ектирована [17.12].

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

CREATE BASE RELATION SNC

( S# DOMAIN ( S# ),

SNAME DOMAIN ( NAME ),

CITY DOMAIN ( CITY ) )

PRIMARY KEY ( S# ) ;

CREATE BASE RELATION ST '.

( S# DOMAIN ( S# ), STATUS DOMAIN ( STATUS ) )

PRIMARY KEY ( S# ) ;

INSERT S [ S#, SNAME, CITY ] INTO SNC ;

INSERT S [ S#, STATUS ] INTO ST ;

DESTROY BASE RELATION S ;

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

CREATE VIEW S ИЗ SNC JOIN ST ;

Заметим, что каждый из атрибутов SNC.S# и ST.S# можно рассматривать как внешние ключи, ссылающиеся друг на друга.

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

CREATE BASE RELATION SS

( S# DOMAIN ( S# ) )

PRIMARY KEY ( S# ) ;

INSERT S [ S# ] INTO SS ;

(Фактически в [12.9] этот прием рекомендуется использовать по разным другим причинам.) Теперь определение представления S примет вид

CREATE VIEW S AS SS JOIN SNC JOIN ST ;

Кроме этого, в определения отношений SNC и ST добавляются определения внешнего ключа:

FOREIGN KEY ( S# ) REFERENCES SS

DELETE CASCADES UPDATE CASCADES

И, наконец, нужно поменять спецификацию внешнего ключа SP.S# в отно­шении SP, чтобы этот ключ ссылался не на отношение S, а на отношение SS.

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

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

CREATE VIEW PQ AS

SELECT SP.P#, SUM (SP.OTY ) AS TOTQTY

FROM SP

GROUP BY SP.P# ;

Рассмотрим также следующий запрос:

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

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

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

FROM SP

GROOP BY SP.P# ;

Это некорректное SELECT-выражение, так как SQL не позволяет вклады­вать агрегативные функции друг в друга.

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

SELECT PQ.P#

FROM PQ

WHERE PQ.TOTQTY > 500 ;

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