    Часть V 

    Дополнительные аспекты 

    В части II этой книги было показано, что реляционная модель служит основой 
современных технологий баз данных, и это именно так. Однако реляционная модель 
является только основой. Как следует из части II, кроме реляционной модели, в 
реляционной технологии существует множество других аспектов, причем и 
профессионалы, и студенты, изучающие базы данных, должны в полной мере владеть 
различными концепциями и возможностями для широкого использования реляционной 
технологии (это также следует из материала, изложенного в частях 111 и IV). 
Теперь сосредоточим внимание на аспектах реляционной технологии, описанных в 
этой части книги. 
    •  Представления (глава 17). 
    •  Оптимизация (глава 18). 
    •  Домены, отношения и типы данных (глава 19). 
    •  Отсутствующая информация (глава 20). 
    •  Распределенные базы данных и системы клиент/сервер (глава 21). 
    Материал изложен, исходя из предположения, что главы будут читаться по порядку. 


    Глава 17 

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

    17.1. Введение 

    Как отмечалось в главе 3, представление, по сути, является именованным 
выражением реляционной алгебры или реляционного исчисления. Ниже показан 
простой пример создания представления (view) на основе алгебры: 

    CREATE VIEW GOOD_SUPPLIERS AS 
    ( S WHERE STATUS > 15 ) [ S#, STATUS, CITY ] ; 

    Когда данное выражение выполняется, то часть, следующая за инструкцией AS 
и являющаяся собственно определением представления, на самом деле не 
выполняется, а "запоминается" системой посредством записи этого выражения в 
каталоге базы данных под именем GOOD_SUPPLIERS. Тем не менее, пользователю 
представляется, будто в базе данных существует реальное отношение 
GOOD_SUPPLIERS со своими кортежами и атрибутами, показанными в незатененной 
части таблицы на рис. 17.1. Другими словами, имя GOOD_SUPPLIERS ссылается на 
виртуальное отношение, т.е. на отношение, которое является результатом 
вычисления выражения, определяющего представление. 

    GOOD SUPPLIERS 

    S#	SNAME	STATUS	CITY 

    SI	Smith	20	London 
    S2	Jones	10	Paris 
    S3	Blake	30	Paris 
    S4	Clark	20	London 
    S5	Adams	30	Athens 
    
    Рис. 17.1. GOOD_SUPPLIERS как представление исходного отношения S. В 
представление входят данные, приведенные в незатененной части таблицы 

    В главе 3 также было показано, что представление в некотором смысле может 
служить окном для просмотра данных. Любые изменения, вносимые в исходные 
данные, будут автоматически и мгновенно отображаться в представлении (в этом 
окне), и наоборот, все изменения, вносимые в данные представления, будут 
автоматически вноситься в исходные данные и соответственно отображаться в 
представлении. В приведенных выкладках предполагается, что изменения вносятся 
в области определения представления. 
    Теперь, в зависимости от опыта работы (и, возможно, от сложности 
используемого приложения), пользователь может не догадываться, что 
GOOD_SUPPLIERS — представление. Некоторые пользователи знают об этом, а также 
о том, что существует реальное отношение S; другие могут искренне верить, что 
GOOD_SUPPLIERS — настоящее отношение. Независимо от догадок пользователей, 
суть представления состоит в том, что с ним можно работать так, как будто оно 
является настоящим отношением. Приведем пример запроса к GOODJSUPPLIERS: 

    Т1 := GOOD SUPPLIERS WHERE CITY # 'London' 
    I 

    440 Часть V. Дополнительные аспекты 

    Ниже показан результат выполнения этого выражения. 

    Т1 

    s#	STATUS	CITY 

    S3	30	Paris 
    S5	30	Athens 

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

    Т1 := ( ( S WHERE STATUS > 15 ) [ Stt, STATUS, CITY ] ) 
    WHERE CITY Ф 'London1 ; 
    Данное выражение легко преобразовать в более простую форму: 
    Т1 := ( S WHERE STATUS > 15 AND CITY * 'London1 ) 
    [ S#, STATUS, CITY ] ; 

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

    UPDATE GCOD_SUPPLIERS WHERE CITY = 'Paris' STATUS := STATUS + 10 ; 

    будет преобразована в операцию 

    UPDATE S WHERE STATUS > 15 AND CITY = 'Paris' STATUS := STATUS + 10 ; 

    Операции INSERT и DELETE обрабатываются аналогично. 

    17.2. Для чего нужны представления 

    Поддержка представлений желательна по нескольким причинам, но, возможно, 
самая важная из них — обеспечение логической независимости данных. Это понятие 
не следует путать с понятием физической независимости данных, описанным ниже в 
этой главе. Система обеспечивает физическую независимость данных, если 
пользователи и пользовательские программы не зависят от изменений в физической 
структуре базы данных. Система обеспечивает логическую независимость данных, 
если пользователи и пользовательские программы также не зависят и от изменений 
в логической структуре базы данных. С последним утверждением связаны два 
интересных аспекта — рост и реструктуризация базы данных. 
    • Рост базы данных. 

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

    Глава 17. Представления	441 

    По мере роста базы данных, аккумулирующей новую информацию, должен 
соответственно возрастать и объем определений. Существует два типа роста. 
    • Расширение существующего базового отношения с целью включения нового 
атрибута. Новый атрибут соответствует внесению новой информации, относящейся к 
объектам определенного типа. Например, добавление атрибута DISCOUNT (скидка) в 
базовое отношение, которое содержит информацию о поставщиках. 
    (Следует заметить, что здесь используется не совсем точная терминология. 
Как описано в главе 4, отношение нельзя расширить и включить в него новый 
атрибут. Говоря о расширении отношения, здесь имеют в виду замену одного 
отношения другим с тем же именем и дополнительным атрибутом, который 
требовалось вставить.) 
    • Создание нового базового отношения, соответствующее добавлению в базу 
данных информации об объектах нового типа. 
    Ни один из указанных типов роста не должен влиять на пользователей и 
пользовательские программы, по крайней мере в принципе. 

    Реструктуризация базы данных. 

    Иногда возникает необходимость реструктурировать базу данных так, чтобы 
общее информационное наполнение осталось тем же, а изменилось только 
расположение данных. Другими словами, в базе данных будут перегруппированы 
атрибуты отношений. Ниже показан простой пример реструктуризации. Предположим, 
что по какой-то причине (в данном случае точная причина не имеет значения) 
необходимо заменить отношение S двумя следующими отношениями: 

    SNC ( S#, SNAME, CITY ) 
    PRIMARY KEY ( S# ) ST { Stt, STATUS ) 
    PRIMARY KEY ( Stt ) 

    Здесь важно заметить, что старое отношение S является соединением двух 
новых отношений SNC и ST(a отношения SNC и ST являются проекциями отношения 
S). Следовательно, можно создать представление с именем S, которое будет 
представлять старое отношение S: 

    CREATE VIEW S AS SNC JOIN ST ; 

    Любая программа или интерактивная операция, в которой использовалось 
старое отношение S, теперь будет использовать представление S. Следовательно, 
так как система корректно обрабатывает операции манипуляции с данными на 
представлениях, пользователи и пользовательские программы действительно 
логически не зависят от частичных реструктуризации базы данных1. 
    Следует отметить, что замена отношения S, содержащего данные о 
поставщиках, двумя проекциями этого отношения, SNC и ST, — не всегда 
тривиальная задача. Например, предположим, что нужно выполнить некоторые 
операции на отношении SP, содержащем данные о поставках. Кроме того, в этом 
отношении используется внешний ключ, ссылающийся на основной ключ отношения, в 
котором хранятся данные о поставщиках (см. упражнения в конце этой главы). 
    Это в принципе! К сожалению, современные продукты (и стандарт SQL) обычно 
не поддерживают корректно операции манипуляций данными на представлениях, 
следовательно, эти программные продукты не обеспечивают в должной мере 
логической независимости от изменений, показанных в примере. Более того, 
большинство программных продуктов (но не все) корректно поддерживает только 
операции выборки данных на представлениях и не поддерживает операций 
обновления данных в представлениях. Поэтому такие продукты обеспечивают 
логическую независимость от структуры базы данных только для операций выборки 
данных, но не для операций обновления данных. 

    442	Часть V. Дополнительные аспекты 

    Чтобы вернуться к теме обсуждения, необходимо заметить: из примера с 
отношениями SNC и ST не следует, что логическая независимость данных может 
быть достигнута в контексте множества всех возможных реструктуризации. Важно 
понимать, где в базе данных существует однозначное (необратимое) отображение 
между реструктурированной версией базы данных и предыдущей ее версией (или 
обратима ли реструктуризация базы данных). Другими словами, являются ли 
названные версии базы данных информационно-эквивалентными. Если нет, то 
логическая независимость абсолютно недостижима. 
    В заключение перечислим не оговоренные ранее преимущества представлений 
(логическая независимость от реструктуризации — основное, но не единственное 
преимущество представлений). 
    •  Представления позволяют разным пользователям различными способами 
просматривать одни и те же данные в одно и то же время. 
    Другими словами, представления позволяют пользователям сосредоточить 
внимание и, возможно, логически реструктурировать только ту часть базы данных, 
которая их интересует, и игнорировать остальные данные. Это утверждение 
особенно важно для интегрированных баз данных, с которыми независимо работают 
разные категории пользователей. 
    •  Представления   обеспечивают   пользователей   механизмом   сокращений, 
   или "макросов". 
    Рассмотрим запрос "Получить все города, в которых хранятся детали, 
поставляемые поставщиком из Лондона". Ниже в этой главе приводится пример 
определения представления CITY_PAIRS (пары городов) с атрибутами SCITY и PCITY 
таким образом, чтобы пары имен городов {SCITY :x, PCITY:y} появлялись в 
представлении тогда и только тогда, когда поставщик, находящийся в городе х, 
поставляет детали, которые хранятся в городе у. Представление CITY_PAIRS 
позволяет записать сформулированный выше запрос в следующем виде: 

    ( CITY_PAIRS WHERE SCITY = 'London' ) [ PCITY ] 

    He используя представление, этот запрос определить значительно сложнее: 

    ( ( ( S RENAME CITY AS SCITY ) JOIN SP JOIN ( P RENAME CITY AS PCITY ) } 
    WHERE SCITY = 'London' ) [ PCITY ] 

    Хотя пользователи могут прибегнуть ко второму определению запроса (правила 
защиты данных позволяют), первое определение, безусловно, короче. Но первое 
определение является простым сокращением второго определения. Перед 
вычислением механизм обработки представлений расширит первое определение до второго. 
    Просматривается явная аналогия с макросами в языках программирования. В 
принципе пользователь может непосредственно записывать расширенные выражения в 
собственный код, но намного удобнее (по известным причинам) не делать этого и 
использовать макросокращения, возложив процедуру расширения макросов на 
процессор макросов языка программирования. Аналогичные соображения характерны 
и для представлений. Таким образом, в СУБД представления играют роль, 
аналогичную роли макросов в системах программирования, а хорошо известные 
преимущества и возможности макросов характерны и для представлений. В 
частности, следует заметить, что, как и при использовании макросов в языках 
программирования, использование представлений не приводит к дополнительным 
затратам производительности на этапе выполнения приложений— небольшие затраты 
производительности наблюдаются только на этапе определения представлений. 

    Глава 17. Представления	443 

    Для скрытых данных обеспечивается автоматическая защита. 
    Под "скрытыми данными" здесь понимают данные, которые не видны в 
определенном представлении. Таким образом, пользователи вынуждены получать 
доступ к базе данных через представления; это простой и эффективный механизм 
контроля доступа и аутентификации. Эта тема уже обсуждалась в главе 15. 

    17.3. Определение данных 

    Общий синтаксис инструкции определения представления CREATE VIEW выглядит 
следующим образом: 

    CREATE VIEW имя AS вьражение ; 

    В приведенном выражении имя обозначает имя представления, а выражение 
(выражение реляционной алгебры или реляционного исчисления) является 
определением представления. Аналогично инструкция CREATE VIEW комбинирует 
функцию внешней схемы и функцию концептуальной схемы (использована 
терминология ANSI/SPARC из главы 2), так как эта инструкция определяет вид 
внешних объектов и их отображение на концептуальном уровне. 
    Ниже приведены примеры, записанные для определенности в синтаксисе 
реляционной алгебры. 

    1. CREATE VIEW REDPARTS AS 
    ( ( P WHERE COLOR = 'Red' ) [ P#, PNAME, WEIGHT, CITY] ) 
    RENAME WEIGHT AS WT ; 

    Вычисление этого выражения приведет к созданию представления REDPARTS, 
которое содержит кортежи с данными о деталях только красного цвета. Эти 
кортежи обладают четырьмя атрибутами: Р#, PNAME, WT и CITY, которые 
соответствуют атрибутам Р#, PNAME, WEIGHT и CITY исходного отношения Р. 

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

    2. CREATE VIEW PQ AS 
    SUMMARIZE SP BY ( P# ) ADD SUM ( OTY ) AS TOTOTY ; 

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

    3. CREATE VIEW CITY_PAIRS AS 
    ( ( S RENAME CITY AS SCITY ) JOIN SP JOIN 
    ( P RENAME CITY AS PCITY ) ) [ SCITY, PCITY ] ; 

    Данное представление было описано выше в этой главе. Как уже упоминалось, 
пара имен городов (х, у) появляется в представлении тогда и только тогда, 
когда поставщик, находящийся в городе х, поставляет детали, которые хранятся в 
городе у. Например, поставщик S1 поставляет детали Р1; поставщик S1 расположен 
в Лондоне и поставляемые им детали хранятся в Лондоне. Таким образом, пара 
имен (Лондон, Лондон) появляется в представлении. 

    4. CREATE VIEW LCNDCN_REDPARTS AS 
    REDPARTS WHERE CITY = 'London' ; 

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

    444	Часть V. Дополнительные аспекты 

    Инструкция DESTROY VIEW имеет следующий синтаксис: 

    DESTROY VIEW имя ; 

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

    DESTROY VIEW REDPARTS  ; 

    В главе 4 показано, что операция DESTROY BASE RELATION завершится 
неудачей, если существует хотя бы одно определение представления (или снимка 
(snapshot)), в котором используется удаляемое отношение. Аналогично, операция 
DESTROY VIEW завершится неудачей, если определение какого-либо представления 
(или снимка) ссылается на удаляемое представление. Дополнительно в инструкции 
CREATE VIEW (и CREATE SNAPSHOT) можно использовать инструкции RESTRICTED или 
CASCADES. Инструкция RESTRICTED означает, что попытка удалить исходные 
отношения потерпит неудачу, a CASCADES — что подобная попытка будет завершена 
успешно, после чего "по каскаду" будут удалены все представления (и снимки 
данных)1. Инструкция RESTRICTED применяется по умолчанию. 

    17.4. Манипуляции с данными: операции выборки 

    В предыдущих разделах кратко описано преобразование операций выборки на 
представлении в эквивалентные операции на базовом отношении (отношениях). В 
данном разделе приводится формальное описание этого преобразования. 
    Прежде всего следует заметить, что данное реляционное выражение можно 
преобразовать в функцию на множестве отношений. Другими словами, в качестве 
аргументов эта функция будет получать различные отношения, а результатом ее 
вычисления будет другое отношение. Пусть D — это база данных (которую для 
текущих задач будем представлять как множество отношений), а У— это 
представление, определенное на множестве D, т.е. представление, определение 
которого является функцией А" на множестве D: 

    V = X  ( D ) . 

    Пусть R — операция выборки на представлении V. Тогда R является функцией 
на множестве отношений: 

    R(V)=R(X(D)). 

    Таким образом, результат операции выборки по определению совпадает с 
результатом вычисления функции X на множестве D (материализации представления 
V) и последующего выполнения операции R на материализованном отношении. Однако 
на практике эффективнее использовать описанную выше процедуру подстановки, 
которая эквивалентна формированию функции С, являющейся композицией R(X) двух 
функций X и R (именно в этом порядке), и вычислению значения функции С 
непосредственно на D. 
    Теперь изложенное в предыдущих разделах должно значительно проясниться для 
читателя. Тем не менее, этот материал помещен именно здесь, и вот почему 
    •  Во-первых, это создает базу для аналогичного обсуждения операций 
обновления в 
    следующем разделе. 
    •  Во-вторых, подробное рассмотрение операций выборки показало, что 
материализация — хотя и более разумный, но, похоже, неэффективный способ 
реализации представлений. 
    1 Стандарт SQL [8.1] не поддерживает инструкций RESCTRICTED и CASCADES; 
эти инструкции включены в DROP TABLE и DROP VIEW (соответственно инструкциям 
DESTROY BASE RELATION и DESTROY VIEW). Но инструкция CREATE VIEW не 
поддерживает инструкций RESTRICTED и CASCADES. Для них в стандарте SQL не 
предусмотрено значения по умолчанию и нужно явно указывать одну из инструкций. 

    Глава 17. Представления	445 

    I •  В-третьих, хотя в принципе процедура подстановки определений 
представления вполне понятна и отлично работает в ста процентах случаев, 
весьма огорчает тот факт, что в некоторых программных продуктах для работы с 
SQL этот процесс не реализован; в этих приложениях выборки данных на 
представлениях могут неожиданно завершиться неудачей. Процедура подстановки не 
реализована в версиях стандарта SQL, выпущенных до 1992 года. Причиной, по 
которой в приложениях и стандартах SQL не работают операции выборки на 
представлениях, является неполная поддержка свойства реляционной замкнутости. 

    17.5. Манипуляции с данными: операции обновления 

    Проблема обновления данных в представлениях может быть коротко 
сформулирована в следующем виде. Рассмотрим конкретную операцию обновления на 
конкретном представлении. Какие обновления нужно внести в исходные отношения 
базы данных, чтобы в результате получить требуемое обновление данных в 
представлении? Формальное описание проблемы выглядит так. Пусть D— это база 
данных, а V— представление, определенное на D, т.е. представление, определение 
которого является функцией X на множестве D (как уже было описано выше): 

    V = X  ( D ). 

    Теперь пусть U — это операция обновления на представлении V. Так как U 
является функцией на множестве отношений, то ее результат можно представить в виде 

    U  ( V )   = U  ( X  ( D )   ) . 

    Тогда проблема операций обновления на представлениях сводится к поиску 
такой операции обновления (/', для которой истинно выражение 

    U(X(D))=X(U'(D)). 

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

    Замечание. Для полноты изложения заметим, что операция U' может не 
являться функцией на множестве отношений, результатом этой функции может быть 
множество разных отношений (если рассматривать операции обновления 
представлений, которые соединяют несколько отношений с помощью операции JOIN и 
в которых необходимо обновлять все отношения). 

    Прежде чем продолжить изложение, хотелось бы подчеркнуть, что на 
протяжении последних нескольких лет проблема обновления представлений была 
предметом важных исследований, в результате которых разработано множество 
различных подходов к решению этой проблемы, в частности предложения Кодда 
(Codd) для системы RM/V2 [4.4] (см. также [17.3, 17.7-17.9, 17.11, 17.13]). В 
этой главе изложен относительно новый подход [17.5, 17.6], менее специальный 
по сравнению с некоторыми предыдущими подходами и обладающий достоинством 
обратной совместимости с лучшими возможностями более ранних подходов. Кроме 
того, данный подход позволяет гораздо большее число представлений трактовать 
как обновляемые. 

    Некоторые важные принципы 

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

    446	Часть V. Дополнительные аспекты 

    (Этот принцип является простым изложением описанного в главе 4 факта, 
который гласит, что предикат данного отношения является критерием применимости 
операций обновления к этому отношению.) 
    Следует заметить, что в этой главе рассматриваются некоторые детали 
вопроса о том, что служит предикатом произвольного порожденного отношения. 
    Перечислим другие важные принципы обновления представлений. 
    1. Обновляемость или отсутствие обновляемости представления — понятие 
семантическое, а не синтаксическое. Другими словами, это понятие не зависит от 
выбранной формы записи определения представления. Например, два приведенных 
ниже представления семантически идентичны: 

    CREATE VIEW V AS 
    S WHERE STATUS > 25 OR CITY = 'Paris' ; CREATE VIEW V AS 
    ( S WHERE STATUS > 25 ) UNION ( S WHERE CITY = 'Paris' ) ; 

    Ясно, что оба представления должны быть обновляемыми. (В отличие от 
теоретического изложения, стандарт SQL и большинство современных 
SQL-приложений обеспечивают обновляемость только для первого представления. В 
контексте стандарта SQL и современных SQL-приложений второе представление не 
является обновляемым, что описывается ниже в этой главе.) 
    2.  Из предыдущего пункта следует, что правила обновляемости должны 
корректно работать на представлениях особого вида — отношениях базы данных. 
Это утверждение должно быть истинным, так как любое отношение В базы данных 
можно рассматривать как представление, определенное как В UNION В, В INTERSECT 
В, В WHERE true, В MINUS С (если С— это отличное от В отношение, которое не 
имеет общих кортежей с отношением В) или любое другое выражение, результат 
которого в точности совпадает с отношением В. Таким образом, правила 
обновления, например объединенных представлений, используемые на представлении 
V = В UNION В, должны давать результат, аналогичный полученному после 
применения этих правил непосредственно на отношении В. 
    3.  Применяемые правила должны сохранять симметричность. Например, правило 
DELETE для пересечения V = A INTERSECT В не должно удалять кортежи произвольно 
из отношений А или В, так как удаление кортежа хотя бы из одного отношения 
удалит этот кортеж из представления. Вместо этого кортежи должны удаляться из 
обоих отношений А и В. (Другими словами, не должно существовать 
неоднозначности. Всегда должен быть единственный способ реализации данного 
обновления, который должен работать во всех случаях.) 
    4.   Правила должны учитывать любые действия-триггеры, такие как каскадное удаление. 

    Замечание. По многим известным причинам здесь отдается предпочтение 
объявлению указанных триггеров, а не включению специального кода в правила. 
Тем не менее, правила прямого обновления представлений не выдвигают таких требований. 

    5. Для упрощения выкладок желательно представлять инструкцию UPDATE как 
последовательность конструкции удаления и вставки кортежа (DELETE-INSERT), 
именно так эта инструкция и будет представлена. Это сокращение вполне 
приемлемо, поэтому нужно понимать следующее. 
    • "В середине" процесса данного обновления не выполняется проверка 
предикатов отношений. Таким образом, расширенная запись инструкции 
    UPDATE    ВЫГЛЯДИТ    КЗК    DELETE-INSERT-проверка,    а    НС    КЗК    
DELETE-проверка
    iNSERT-проверка. Причиной служит тот факт, что инструкция DELETE времен-но 
нарушает истинность предиката отношения, в то время как инструкция 

    Глава 17. Представления	447 

    UPDATE не нарушает. Например, предположим, что отношение R содержит 10 
кортежей, и рассмотрим эффект операции "ОБНОВИТЬ кортеж F на отношении R, если 
из предиката отношения R следует, что это отношение должно содержать не меньше 
10 кортежей. 
    • Триггеры никогда не запускаются "в середине" любой операции обновления. 
(Фактически триггеры запускаются по окончании операции, но перед проверкой 
предиката отношения.) 
    • Сокращения требуют некоторых "незначительных усовершенствований" для 
представлений типа проекции. 
    Как отмечалось выше, трактовка инструкции UPDATE как комбинации 
DELETE-INSERT означает, что эту инструкцию можно рассматривать как операцию 
над целым кортежем, а не как замену отдельных значений атрибутов в составе кортежа. 
    6.  Все операции обновления на представлениях реализуются на однотипных 
операциях обновления исходных отношений. Таким образом, операции вставки 
(INSERT) и удаления (DELETE) на представлениях реализуются соответственно с 
помощью операций вставки и удаления на исходных отношениях (учитывая 
предыдущий пункт, можно не рассматривать операцию UPDATE). С другой стороны, 
предположим, что существует некоторый тип представлений (пусть это 
представления, полученные с помощью операции объединения (UNION)), для которых 
операции INSERT преобразуются в операции DELETE на исходных отношениях. Тогда 
в некоторых случаях операции INSERT на исходных отношениях тоже иногда можно 
преобразовать в операции DELETE! Это следует из утверждения (см. пункт 2), что 
любое базовое отношение В можно представить в виде объединяющего представления 
V = В UNION В. Аналогичное утверждение применимо и для представлений остальных 
типов (выборка, проекция, пересечение и т.д.). Однако утверждение, что на 
базовых отношениях о перации вставки данных могут являться операциями 
удаления, — очевидный абсурд. Таким образом, истинным является утверждение, 
что операции INSERT и DELETE на представлениях преобразуются в соответствующие 
операции INSERT и DELETE на базовых отношениях. 
    7.  В основном применение правил на выбранном представлении V указывает 
операции, предназначенные для выполнения на отношениях, на которых определено 
представление V. Эти правила должны работать даже тогда, когда отношения, на 
которых определено представление, в свою очередь, являются порожденными. 
Другим словами, правила должны обладать свойством рекурсивного применения. 
Конечно, если попытка обновить выбранное представление приводит к попытке 
обновления исходного отношения, которое не является обновляемым, то исходная 
операция обновления завершится неудачей. 
    8.  Правила не должны "предполагать", что база данных хорошо 
спроектирована (т.е. полностью нормализована). Тем не менее, правила могут 
привести к несколько неожиданным результатам, если база данных спроектирована 
неудачно. Это лишний раз свидетельствует в пользу поддержки хорошей структуры 
базы данных. Ниже будет приведен пример с несколько неожиданными результатами. 
    9.  Если представление обновляемо, то не должно существовать никаких 
причин, запрещающих операции обновления определенного типа (например, нельзя 
разрешать операции DELETE и запрещать операции INSERT). 
    10. Операции INSERT и DELETE должны быть противоположными, по крайней 
мере, если это возможно. 
    Напомним читателю еще один важный принцип. Как было показано ранее в этой 
книге, реляционные операции всегда выполняются на множестве кортежей 
одновременно, а множество, состоящее из одного кортежа, является частным 
случаем. 

    448	Часть V. Дополнительные аспекты 

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

    17.6. Обновление операций объединения, пересечения и вычитания 

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

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

    Объединение 

    Приведем правило вставки кортежа в представление вида A UNION В. 
    •  INSERT. Новый кортеж должен удовлетворять предикату РА или РВ либо 
обоим предикатам одновременно. Если новый кортеж удовлетворяет РА, то этот 
кортеж должен быть вставлен в А (заметьте, что операция вставки может иметь 
побочный эффект, в результате которого новый кортеж будет вставлен и в В). 
Если новый кортеж удовлетворяет предикату РВ, то этот кортеж вставляется в В 
только при условии, что он еще не вставлен в В в результате побочного эффекта 
от вставки в А. 

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

    Пояснение. Новый кортеж должен удовлетворять предикату РА или РВ, так как 
в противном случае данный кортеж не попадет в A UNION В, другими словами, не 
будет удовлетворять предикату объединения (PA) OR (РВ). (Кроме того, новый 
кортеж не должен уже присутствовать ни в А, ни в В, так как в противном случае 
будет выполняться попытка вставки кортежа, который уже существует.) 
Предположим, что перечисленные условия удовлетворены, тогда новый кортеж будет 
вставлен в А или В в зависимости от того, к какому виртуальному отношению этот 
кортеж принадлежит (возможно к обоим). 

    Глава 17. Представления	449 
    15 Введение в системы баз данных 

    Примеры. Пусть представление UV определено как 

    ( S WHERE STATUS > 25 ) UNION ( S WHERE CITY = 'Paris' ) 

    В таблице на рис. 17.2 приведены пробные данные рассматриваемого 
представления с пробными значениями атрибутов. 

    UV 

    s#	SNAME	STATUS	CITY 

    S2	Jones	10	Paris 
    S3	Blake	30	Paris 
    S5	Adams	30	Athens 
    
    
    Рис.17.2. Представление UV (пробные значения) 

    •  Пусть (S6, Smith, 50, Rome) — кортеж, который нужно вставить в 
представление UV. Этот кортеж удовлетворяет предикату s WHERE STATUS > 25 
(однако не удовлетворяет предикату s WHERE CITY = 'Paris'). Следовательно, 
новый кортеж вставляется в отношение, удовлетворяющее предикату s WHERE STATUS 
> 25. Из правил вставки кортежей в выборку, которые достаточно просты (см. 
ниже), следует, что новый кортеж будет вставлен в базовое отношение, 
содержащее информацию о поставщиках. 
    •   Теперь предположим, что в представление UV нужно вставить кортеж (S7, 
Jones, 50, Paris). Этот кортеж удовлетворяет обоим предикатам 

    S WHERE STATUS > 25 И S WHERE CITY =   'Paris'. 

    ЛОГИЧНО ПрСДПОЛОЖИТЬ, ЧТО ЭТОТ КОртеж должен быть вставлен в оба виртуальных 
отношения. Тем не менее, следует заметить, что вставка кортежа в одно из виртуальных 
отношений имеет побочный эффект, вследствие которого кортеж вставляется и в другое 
виртуальное отношение. Таким образом, не нужно явно вставлять кортеж в другое 
отношение. 
    Теперь рассмотрим два различных базовых отношения, SA и SB. Отношение SA 
содержит информацию о поставщиках, для которых атрибут STATUS превышает 25. 
Отношение SB содержит информацию о поставщиках, расположенных в Париже (рис. 
17.3). Предположим, что представление UV определено как объединение SA UNION 
SB, и вновь рассмотрим операцию вставки двух обсуждаемых выше кортежей. 
Вставка кортежа (S6, Smith, 50, Rome) в представление UV приведет к вставке 
кортежа в базовое отношение SA, если предположить, что такая вставка 
необходима. В то же время вставка кортежа (S7, Jones, 50, Paris) в 
представление UV приведет к вставке кортежа в оба отношения, SA и SB. 
Полученный результат логически корректен, хотя и не совсем интуитивно понятен 
(именно этот результат выше был назван "несколько неожиданным"). Подобные 
"неожиданности" возникают исключительно как следствие плохо спроектированной 
структуры базы данных. В частности, если плохо спроектирована структура базы 
данных, позволяющая достаточно похож им кортежам присутствоват ь в различных 
отношениях. Эта проблема (возможно, спорная) детально рассматривается в [17.12]. 

    SA                                   SB 

    S#	SNAME	STATUS	CITY		S#	SNAME	STATUS	CITY 

    S3	Blake	30	Paris			S2	Jones	10	Paris 
    35	Adams	30	Athens		S3	Blake	30	Paris 
    
    Рис. 17.3. Базовые отношения SA и SB (пробные значения атрибутов) 

    Теперь сосредоточимся на правилах удаления кортежей из представлений типа 
A UNION В. 

    450 Часть V. Дополнительные аспекты 

    •   DELETE. Если удаляемый кортеж принадлежит А, то он удаляется из А 
(заметьте, что это удаление может иметь побочный эффект, вследствие которого 
этот же кортеж будет удален и из В). Если после удаления кортежа из А этот 
кортеж присутствует в В, то он удаляется и из В. 
    Примеры для демонстрации этого правила предлагается создать пользователю в 
качестве упражнения. Следует заметить, что удаление кортежа из А или В может 
привести к каскадным операциям DELETE или к запуску других триггеров. 
    И наконец, рассмотрим правила обновления. 
    •   UPDATE. Обновляемый кортеж должен быть таким, чтобы его обновленная 
версия удовлетворяла предикату РА или РВ либо обоим предикатам. Если кортеж 
принадлежит А, то его удаляют из А без запуска каких-либо триггеров, связанных 
с обычной операцией удаления (каскадное удаление и т.п.). Кроме того, после 
удаления предыдущей версии кортежа не выполняется проверка предиката для А. 
Следует заметить, что операция удаления (DELETE) может иметь побочный эффект, 
вследствие которого выбранный кортеж будет удален и из В. Если после удаления 
из А (и, возможно, побочного эффекта) кортеж все еще присутствует в В, то он 
удаляется из В (опять же без проверки предиката для В и без запуска каких-либо 
триггеров). После этого, если обновленная версия кортежа удовлетворяет 
предикату РА, кортеж вставляется в А (эта операция может иметь побочный 
эффект, вследствие которого новая версия кортежа может появиться и в б). И 
наконец, если обновленная версия кортежа удовлетворяет предикату РВ, то кортеж 
вставляется в В только в том случае, если он не вставлен в В в результате 
побочного эффекта от вставки в А. 
    Приведенное правило обновления в основном состоит из правила удаления, за 
которым следует правило вставки. Единственным исключением является отсутствие 
триггеров и проверок предикатов отношений после удаления старой версии кортежа 
(любые триггеры и проверки, связанные непосредственно с операцией обновления 
(UPDATE), выполняются после завершения всех операций удаления и вставки). 
    Рассмотрим одно важное следствие приведенной трактовки операции обновления 
(UPDATE), которое состоит в том, что после операции обновления представления 
кортеж может мигрировать из одного отношения в другое. В базе данных, 
показанной на рис. 17.3, обновление в представлении LJV кортежа (S5, Adams, 
30, Athens) на кортеж (S5, Adams, 15, Paris) приведет к удалению кортежа из 
отношения SA и вставке этого кортежа в отношение SB. 

    Пересечение 

    Приведем правила обновления представлений вида A INTERSECT В. Причем в 
данном случае ограничимся только формулированием правил без каких-либо 
дополнительных пояснений (они аналогичны пояснениям для правил обновления 
объединений). Единственное, о чем следует помнить, — это то, что для 
представлений вида A INTERSECT В предикат примет вид (PA) AND (PB). Примеры 
для приведенных ниже правил предлагается создать читателю в качестве упражнения. 
    •  INSERT. Новый кортеж должен удовлетворять предикатам РА и РВ. Если 
новый кортеж не входит в А, то этот кортеж будет вставлен в А (заметьте, что 
операция вставки может иметь побочный эффект, вследствие которого новый кортеж 
появится и в В). Если (все же) новый кортеж не входит в В, то он вставляется и 
в В. 
    •  DELETE. Кортеж, который нужно удалить из представления, удаляется из А 
(заметьте, что операция удаления может иметь побочный эффект, в результате 
которого удаляемый кортеж исчезнет и из В). Если (все же) кортеж не удален из 
В, то он удаляется и из В. 

    Глава 17. Представления	451 

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

    Вычитание 

    Ниже приведены правила обновления представлений вида A MINUS В (для 
представлений данного вида предикат отношения можно записать так: (PA) AND NOT (PB)). 
    •  INSERT. Новый кортеж должен удовлетворять предикату РА и не должен 
удовлетворять предикату РВ. Новый кортеж вставляется в А. 
    •  DELETE. Кортеж, который нужно удалить из представления, удаляется из А. 
    •   UPDATE. Обновляемый кортеж должен быть таким, чтобы его обновленная 
версия удовлетворяла предикату РА и не удовлетворяла предикату РВ. Кортеж 
удаляется из А без запуска триггеров и выполнения проверок предикатов. 
Обновленная версия кортежа вставляется в А. 

    17.7. Обновление представлений других видов 

    Ниже рассматриваются оставшиеся операции реляционной алгебры — выборка, 
проекция, соединение и т.п. 

    Выборка 

    Рассмотрим операцию выборки общего вида: 
    A WHERE условие 
    Предикат отношения, которое является результатом показанной операции 
выборки, примет следующий вид: (PA) AND (условие). Например, предикат 
отношения для 
    ВЫбОрКИ S WHERE CITY =   'London' ПрИМСТ ВИД  (PS)  AND   (CITY =   
'London'), ГДС PS ЯВЛЯСТСЯ предикатом отношения S. Из этого следует, например, 
что любой кортеж /, выбранный для вставки в представление, которое определено 
как выборка, должен удовлетворять условиям PS(/) и /.CITY = 'London', в 
противном случае операция INSERT завершится неудачей. 
    Приведем правила обновления представлений вида A WHERE условие. 
    •   INSERT. Новый кортеж должен удовлетворять предикату РА и условию. 
Новый кортеж вставляется в А. 
    •   DELETE. Кортеж, который нужно удалить, удаляется из А. 
    •   UPDATE. Обновляемый кортеж должен быть таким, чтобы его обновленная 
версия удовлетворяла предикату РА и условию. Кортеж удаляется из А без запуска 
триггеров и выполнения проверок предикатов. Обновленная версия кортежа 
вставляется вА. 

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

    S WHERE CITY = 'London1 


    452	Часть V. Дополнительные аспекты 


    На рис. 17.4 показана таблица значений этого представления. 

    LS 

    S#	SNAME	STATUS	CITY 

    SI	Smith	20	London 
    S4	Clark	20	London 

    Рис. 17.4. Представление LS (значения для примера) 

    •  Попытка вставить кортеж (S6, Green, 20, London) в представление LS 
будет выполнена успешно. Новый кортеж будет вставлен в отношение S и, 
следовательно, появится в представлении LS. 
    •  Попытка вставить кортеж (SI, Green, 20, London) завершится неудачей, 
так как этот кортеж не удовлетворяет предикат отношения S (и, следовательно, 
представления LS). В частности, этот кортеж нарушает правило уникальности 
потенциального ключа в атрибуте S.S#. 
    •  Попытка вставить кортеж (S6, Green, 20, Athens) завершится неудачей, 
так как этот кортеж не удовлетворяет условию CITY = 'London'. 
    •  Попытка удалить из представления LS кортеж (S I, Smith, 20, London) 
будет выполнена успешно. Кортеж будет удален из отношения S и, следовательно, 
из представления LS. 
    •  Попытка обновить кортеж (SI, Smith, 20, London) кортежем (S6, Green, 
20, London) будет выполнена успешно. Попытка обновить кортеж (SI, Smith, 20, 
London) кортежем (S2, Smith, 20, London) или кортежем (SI, Smith, 20, Athens) 
потерпит неудачу (ответьте, почему это происходит в каждом случае?). 

    Проекция 

    Этот раздел также начнется с записи соответствующего предиката. Пусть 
атрибуты отношения А разделены на две несвязанные группы —Xи Y. Будем 
рассматривать Л" и У как составные атрибуты. Следовательно, данный кортеж 
{Х:х} появится в проекции А[Х\ тогда и только тогда, когда существует значение 
у из области значений атрибута Y, такое что кортеж [Х:х, Y:y] входит в А. 
Например, рассмотрим проекцию описанного ранее отношения S по атрибутам S#, 
SNAME и CITY. Для каждого кортежа (s, n, с), который входит в проекцию, 
существует значение статуса t, такое что кортеж (s, n, t, с) принадлежит 
отношению S. 
    Ниже приведены правила обновления проекций. 
    •  INSERT. Пусть (*)— кортеж, который нужно вставить, и пусть у— значение 
по умолчанию, выбираемое из области значений К (если такого значения по 
умолчанию не существует, т.е. применяется правило "запретить значения по 
умолчанию", то это ошибка). Кортеж (х,у), который должен удовлетворять 
предикату РА, будет вставлен в А. 

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

    •  DELETE. Из А будут удалены все кортежи, в которых значение X совпадает 
со значением Xв удаляемом из представления А[Х] кортеже. 
    Замечание. На практике желательно, чтобы множество атрибутов А'включало 
хотя бы один потенциальный ключ, тогда удаляемому из проекции А[Х] кортежу 
будет соответствовать единственный кортеж а в отношении А. Тем не менее, нет 
никаких логических причин превращать это пожелание в жесткое требование. 
Аналогичные соображения также применимы к операции UPDATE (см. ниже). 

    Глава 17. Представления 453 

    •   UPDATE. Пусть (х) — кортеж, который нужно обновить, а (х *) — 
обновленная версия кортежа (х). Пусть а — кортеж отношения А, в котором то же 
значение х атрибута^. Пусть у— значение атрибута Y в кортеже А. Сначала из А 
будут удалены все подобные кортежи а без запуска триггеров и без выполнения 
проверок предикатов отношений. После этого в отношение А для каждого значения 
у будет вставлен кортеж (х', у), который удовлетворяет предикату РА. 

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

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

    SC   [  S#,   CITY  ] 

    На рис. 17.5 это представление показано в виде таблицы. 

    SC 

    s#	CITY 

    SI	London 
    S2	Paris 
    S3	Paris 
    S4	London 
    S5	Athens 
    
    
    Рис. 17.5. Представление SC (значения для примера) 

    •  Попытка вставить в представление SC кортеж (S6, London) будет успешно 
выполнена. В результате этой операции в отношение S будет вставлен кортеж (S6, 
п, t, London), где п и / являются значениями, которые используются по 
умолчанию для атрибутов S.SNAME и S.STATUS соответственно. 
    •  Попытка вставить кортеж (SI, London) в представление SC завершится 
неудачей, так как этот кортеж не удовлетворяет предикату отношения S (и, 
следовательно, представления SC). В частности, этот кортеж нарушает правило 
уникальности потенциального ключа в атрибуте S.S#. 
    •  Попытка удалить из представления SC кортеж (S I, London) будет 
выполнена успешно. Кортеж будет удален из отношения S. 
    •  Попытка обновить кортеж (SI, London) кортежем (SI, Athens) будет 
выполнена успешно. Это приведет к замене в отношении S кортежа (SI, Smith, 20, 
London) кортежем (SI, Smith, 20, Athens), а не (SI, л, /, Athens), пожалуйста, 
запомните это. 
    •  Попытка обновить в SC тот же кортеж (SI, London) кортежем (S2, London) 
завершится неудачей (укажите причину). 
    Случай, когда проекция не включает потенциальных ключей исходного 
отношения (например, проекция отношения S по атрибутам STATUS и CITY), 
оставлен для рассмотрения читателями в качестве упражнения. 

    Расширение 

    Предикат РЕ отношения Е, которое является результатом операции расширения 

    EXTEND A ADD елр AS X, 

    примет следующий вид: 

    РА  ( a )  AND е.Х = exp ( a ) 

    454 Часть V. Дополнительные аспекты 

    Здесь е— это кортеж отношения Е, а а— проекция кортежа епо всем атрибутам 
отношения А. Иначе это можно сформулировать следующим образом: 
    Каждый кортеж е в "расширенном" отношении такой, что: 1) кортеж а является 
порождением кортежа е посредством проекции, исключающей значение е.Х, и 
удовлетворяет предикату РА; 2) значение е.Х равно результату выражения ехр от 
кортежа а. 
    Приведем правила обновления представления вида Е = EXTEND A ADD ехр AS X. 
    •   INSERT. Пусть е — кортеж, который нужно вставить. Этот кортеж должен 
удовлетворять предикату РЕ. В А будет вставлен кортеж а, порожденный кортежем 
е посредством проекции, исключающей значение е.Х. 
    •  DELETE. Пусть е — кортеж, который нужно удалить. Из А будет удален 
кортеж а, порожденный кортежем е посредством проекции, исключающей значение е.Х. 
    •   UPDATE. Пусть е— кортеж, который нужно обновить, а'е'— обновленная 
версия кортежа е. Сначала из А без запуска триггеров и без выполнения проверок 
предикатов отношений будет удален кортеж а, порожденный кортежем е посредством 
проекции, исключающей значение е.Х. Затем в А будет вставлен кортеж а', 
порожденный кортежем е' посредством проекции, исключающей значение е'.Х. 

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

    EXTEND P ADD   (  WEIGHT  *   454   )   AS СМИТ 

    На рис. 17.6 приведена таблица значений представления РХ. 

    РХ 

    р#	PNAME	COLOR	WEIGHT	CITY	GMWT 

    Р1	Nut	Red	12	London	5448 
    Р2	Bolt	Green	17	Paris	7718 
    РЗ	Screw	Blue	17	Rome	7718 
    Р4	Screw	Red	14	London	6356 
    Р5	Cam	Blue	12	Paris	5448 
    Рб	Cog	Red	19	London	8626 

    Рис. 17.6. Представление РХ (значения для примера) 

    • Попытка вставить кортеж (Р7, Cog, Red, 12, Paris, 5448) будет завершена 
успешно и приведет к вставке кортежа (Р7, Cog, Red, 12, Paris) в отношение Р. 
    •  Попытка вставить кортеж (Р7, Cog, Red, 12, Paris, 5449) потерпит 
неудачу (почему?). 
    •  Попытка вставить кортеж (PI, Cog, Red, 12, Paris, 5448) потерпит 
неудачу (почему?). 
    •  Попытка удалить кортеж с ключом Р1 будет завершена успешно и приведет к 
удалению кортежа с ключом Р1 из отношения Р. 
    •  Попытка обновить кортеж с ключом Р1 кортежем (PI, Nut, Red, 10, Paris, 
4540) будет завершена успешно и приведет к замене кортежа (PI, Nut, Red, 12, 
London) в отношении Р кортежем (PI, Nut, Red, 10, Paris). 
    •  Закончится неудачей попытка обновить тот же кортеж кортежем с ключом Р2 
(и неизменными остальными атрибутами) или кортежем, в котором значение 
атрибута GMWT не равно значению атрибута WEIGHT, умноженному на 454 (в каждом 
случае укажите причину неудачи). 

    Глава 17. Представления 455 

    Соединение 

    Большинство трактовок проблемы обновления представлений, включая 
трактовки, рассмотренные в предыдущих редакциях этой книги и в других книгах 
данного автора, доказывают, что обновляемость или ее отсутствие для 
представления зависят, по крайней мере частично, от того, принадлежит ли 
соединение к типу один-к-одному, один-ко-многим или многие-ко-многим. В 
отличие от всех предыдущих подходов к решению проблемы обновления 
представлений, автор утверждает, что соединения всегда обновляемы. Более того, 
для всех трех перечисленных типов соединений правила идентичны и в основном 
достаточно прямые. 
    Это утверждение делает вероятным (поразительно даже с первого взгляда) 
новое видение проблемы, благодаря адаптации изложенных выше в этой главе 
фундаментальных принципов к эффекту, который состоит в том, что предикат 
данного отношения является критерием обновляемости этого отношения. Вообще 
говоря, цель поддержки представлений всегда состояла в стремлении по 
возможности стереть разницу между представлениями и базовыми отношениями, и 
это похвально. Тем не менее: 
    •  всегда предполагалось (неявно), что можно обновить отдельный кортеж 
базового отношения, не влияя на остальные кортежи этого отношения; 
    •   в то же время очевидно, что не всегда возможно обновить отдельный 
кортеж представления, не влияя на остальные кортежи этого представления. 
    Например, в [10.2] Кодд (Codd) показал, что из конкретного соединения 
невозможно удалить единственный кортеж, так как это приведет к получению 
отношения, которое "не является соединением двух любых отношений" (это, в свою 
очередь, означает, что результат, возможно, не будет удовлетворять предикату 
представления). Исторически сложилось так, что подобные операции обновления 
представлений отбрасывались ввиду невозможности сделать эти операции полностью 
идентичными обновлениям базовых отношений. 
    Наш подход значительно отличается. Мы признаем тот факт, что даже в 
базовых отношениях не всегда возможно обновить отдельный кортеж независимо от 
остальных кортежей. Следовательно, рассматриваемый подход позволяет принять 
операции обновления представлений, которые по сложившейся традиции не 
рассматривались, и интерпретировать эти операции четко и логически корректно 
для применения к исходным отношениям представлений. Более того, операции 
обновления рассматриваются с учетом побочных эффектов, которые может иметь 
обновление исходных отношений для представления. Тем не менее, такие побочные 
эффекты необходимы, так как в противном случае представление может не 
удовлетворять собственному предикату. 
    Закончив вступительную часть, давайте перейдем к детальному обсуждению. 
Прежде всего, определим термины. После этого приведем правила для обновления 
представлений на базе соединения. Затем рассмотрим применение этих правил для 
всех трех типов соединений (один-к-одному, один-ко-многим, многие-ко-многим). 
    Рассмотрим соединение J = A JOIN В, где отношения А, В и J имеют заголовки 
{X, Y}, {Y, 2} и {X, У, Z} соответственно. Пусть РА и РВ — предикаты для 
отношений А и В соответственно. Тогда предикат PJ представления J имеет 
следующий вид: 

    РА  (  a  )   AND РВ  ( Ь ), 

    где а является "Л-частью" данного кортежа j (т.е. кортежем, который 
порожден от у' посредством проекции, исключающей значение/Z), В является 
"б-частью" кортежа у' (т.е. кортежем, который порожден от у посредством 
проекции, исключающей значение j.X). Другими словами: 
    Каждый кортеж в соединении таков, что Л-часть удовлетворяет предикату РА, 
а 5-часть удовлетворяет предикату РВ. 

    456	Часть V. Дополнительные аспекты 

    Например, предикат для соединения часто обсуждаемых в этой книге отношений 
S и SP по атрибуту S# можно сформулировать так: 
    Каждый кортеж (s, n, t, с, р, q) в соединении таков, что кортеж (s, n, t, 
с) удовлетворяет предикату отношения S и кортеж (s, p, q) удовлетворяет 
предикату отношения SP. 
    Приведем правила для обновления представлений вида J = A JOIN В. 
    •   INSERT. Новый кортежу должен удовлетворять предикату PJ. Если Л-часть 
кортежа у' не входит в А, то Л-часть вставляется в А*. Если В-часть не 
присутствует в В, то В-часть вставляется в В. 
    •   DELETE. Л-часть удаляемого кортежа удаляется из А. В-часть удаляемого 
кортежа удаляется из В. 
    •  UPDATE. Обновляемый кортеж должен быть таким, чтобы его обновленная 
версия удовлетворяла PJ. Л-часть удаляется из А без запуска каких-либо 
триггеров и без выполнения проверок предикатов, В-часть удаляется из В опять 
же без запуска каких-либо триггеров и без выполнения проверок предикатов. Если 
после этого Л-часть обновленного кортежа не входит в А, то Л-часть вставляется 
в А. Если В-часть не присутствует в В, то В-часть вставляется в В. 
    Теперь проверим применение сформулированных правил на трех типах соединений. 
    Тип 1 (один-к-одно.му). Заметьте, что в данном случае термин 
"один-к-одному" можно заменить более точным термином 
"(один-или-нуль)-к-(одному-или-нулю)". Другими словами, существует стандартное 
для СУБД ограничение целостности, гарантирующее, что для каждого кортежа из А 
существует по крайней мере один соответствующий кортеж из В и наоборот. 
Точнее, множество атрибутов У, по которому выполняется соединение, должно 
содержать подмножество К такое, что К является потенциальным ключом для А и 
для В. 
    Примеры: 
    •  В качестве первого примера читателю предлагается рассмотреть эффект 
применения правил на соединении отношения S (с информацией о поставщиках) с 
самим собой только по номеру поставщика (атрибут S#). 
    •  Рассмотрим второй пример. Предположим, что база данных поставщиков и 
деталей содержит еще одно отношение SR { S#, REST }, где атрибут S# 
идентифицирует поставщика, а атрибут REST содержит информацию о любимом 
ресторане поставщика. Предположим, что не все поставщики представлены в 
отношении SR. Читателю предлагается рассмотреть эффект применения изложенных 
правил на соединении отношений S и SR (по атрибуту S#). Что изменится, если 
поставщик будет представлен в отношении SR и не будет представлен в отношении S? 
    Тип 2 (один-ко-.многим). Термин "один-ко-многим" можно заменить более 
точным термином "(нуль-или-один)-к-(нулю-или-многим)". Другими словами, 
существует стандартное для СУБД ограничение целостности, гарантирующее, что 
для каждого кортежа из В существует не более одного соответствующего кортежа в 
А. Точнее, множество атрибутов У, по которому выполняется соединение, должно 
содержать подмножество К, такое что К является потенциальным ключом для А и 
соответствующим внешним ключом для В. 

    1 Заметьте, что операция INSERT может иметь побочный эффект, вследствие 
которого В-часть кортежа у будет вставлена в В, как в случае с 
представлениями, описанными выше. Аналогичные соображения применимы к правилам 
для операций DELETE и UPDATE. Для краткости возможность побочных эффектов не 
будет упоминаться в каждом правиле. 

    Глава 17. Представления	457 

    Замечание. Если сформулированные выше требования выполняются и если 
внешний ключ определен с помощью инструкции NULLS NOT ALLOWED, то выражение 
"нуль или один" можно заменить выражением "точно один". 

    Примеры. Пусть представление SSP определено следующим выражением: 

    S JOIN SP 

    Это, конечно, соединение с внешним согласованным потенциальным ключом. 
Образцы данных представления SSP показаны на рис. 17.7. 

    SSP 

    s#	SNAME	STATUS	CITY	P#	QTY 

    SI	Smith	20	London	PI	300 
    SI	Smith	20	London	P2	200 
    SI	Smith	20	London	P3	400 
    SI	Smith	20	London	P4	200 
    SI	Smith	20	London	P5	100 
    SI	Smith	20	London	P6	100 
    S2	Jones	10	Paris	PI	300 
    S2	Jones	10	Paris	P2	400 
    S3	Blake	30	Paris	P2	200 
    S4	Clark	20	London	P2	200 
    34	Clark	20	London	P4	300 
    S4	Clark	20	London	P5	400 
    
    Рис. 17.7. Представление SSP (значения для примера) 

    •  Попытка вставить кортеж (S4, Clark, 20, London, Р6, 100) в 
представление SSP будет завершена успешно и приведет к вставке кортежа (S4, 
Р6, 100) в отношение SP (следовательно, новый кортеж появится в представлении). 
    •  Попытка вставить кортеж (S5, Adams, 30, Athens, P6, 100) в 
представление SSP будет завершена успешно и приведет к вставке кортежа (S5, 
Р6, 100) в отношение SP (следовательно, новый кортеж появится в представлении). 
    •  Попытка вставить кортеж (S6, Green, 20, London, P6, 100) в 
представление SSP будет завершена успешно и приведет к вставке кортежа (S6, 
Green, 20, London) в отношение S и к вставке кортежа (S6, Р6, 100) в отношение 
SP (следовательно, новый кортеж появится в представлении). 

    Замечание. Предположим на мгновение, что возможно присутствие кортежей в 
отношении SP без соответствующих кортежей в отношении S. Более того, 
предположим, что отношение SP уже содержит несколько кортежей с номером 
поставщика S6 (но в этом отношении отсутствует кортеж с поставщиком S6 и 
деталью Р1). Тогда последняя из перечисленных операций вставки приведет к 
вставке дополнительных кортежей в представление, а именно: в отношении 
появятся соединения кортежа (S6, Green, 20, London) и тех кортежей поставщика 
S6, которые ранее присутствовали в отношении SP. 

    •   Попытка вставить кортеж (S4, Clark, 20, Athens, P6, 100) в 
представление SSP завершится неудачей (почему?). 
    •  Попытка вставить кортеж (S5, Adams, 30, London, P6, 100) в 
представление SSP завершится неудачей (почему?). 
    •  Попытка вставить кортеж (SI, Smith, 20, London, PI, 400) в 
представление SSP завершится неудачей (почему?). 
    •  Попытка удалить кортеж (S3, Blake, 30, Paris, P2, 200) из представления 
SSP будет выполнена успешно и приведет к удалению кортежа (S3, Blake, 30, 
Paris) из отношения S и кортежа (S3, Р2, 200) из отношения SP. 

    458 Часть V. Дополнительные аспекты 

    •  Попытка удалить кортеж (S1, Smith, 20, London, P1,300) из представления 
SSP условно будет выполнена успешно (см. замечание ниже) и приведет к удалению 
кортежа (SI, Smith, 20, London) из отношения S и кортежа (SI, P1,300) из 
отношения SP. 
    Замечание. На самом деле общий эффект приведенной операции удаления будет 
зависеть от правила удаления внешнего ключа из SP.S# в S.S#. Если используется 
правило RESTRICT, то операция удаления завершится неудачей. Если используется 
правило CASCADE, то удаление будет иметь побочный эффект, который приведет к 
удалению из отношения SP других кортежей, содержащих данные о поставщике S1. 
    •  Попытка обновить кортеж (SI, Smith, 20, London, PI, 300) в 
представлении SSP кортежем (SI, Smith, 20, London, PI, 400) будет успешно 
завершена и приведет к обновлению кортежа (SI, P1, 300) в отношении SP 
кортежем (SI, P1, 400). 
    •  Попытка обновить кортеж (SI, Smith, 20, London, PI, 300) в 
представлении SSP кортежем (SI, Smith, 20, Athens, PI, 400) будет успешно 
завершена и приведет к обновлению кортежа (SI, Smith, 20, London) в отношении 
S кортежем (SI, Smith, 20, Athens) и кортежа (SI, P1, 300) в отношении SP 
кортежем (SI, P1,400). 
    •  Попытка обновить кортеж (SI, Smith, 20, London, PI, 300) в 
представлении SSP кортежем (S6, Smith, 20, London, PI, 300) будет условно 
успешно завершена (см. замечание ниже) и приведет к обновлению кортежа (SI, 
Smith, 20, London) в отношении S кортежем (S6, Smith, 20, London) и кортежа 
(SI, P1, 300) в отношении SP кортежем (S6, Р 1,300). 
    Замечание. На самом деле эффект приведенной операции обновления будет 
зависеть от правила обновления внешнего ключа из SP.S# в S.S#. Детальное 
рассмотрение оставлено в качестве упражнения читателю. 
    Тип 3 (многие-ко-многим). Термин "многие-ко-многим" можно заменить более 
точным термином "(нуль-или-многие)-к-(нулю-или-многим)". Другими словами, не 
существует стандартного для СУБД ограничения целостности, которое гарантирует, 
что данный тип соединения не относится ни к первому, ни ко второму типу соединений. 
    Примеры. Предположим, что представление определено следующим выражением: 

    S JOIN P 

    Это соединение отношений S и Р по атрибуту CITY. Образцы данных показаны 
на рис.17.8. 
    
    s#					P#
    SNAME	STATUS	CITY		PNAME	COLOR	WEIGHT 

    SI	Smith	20	London	PI	Nut	Red	12 
    SI	Smith	20	London	P4	Screw	Red	14 
    SI	Smith	20	London	P6	Cog	Red	19 
    S2	Jones	10	Paris		P2	Bolt	Green	17 
    S2	Jones	10	Paris		P5	Cam	Blue	12 
    S3	Blake	30	Paris		P2	Bolt	Green	17 
    S3	Blake	30	Paris		P5	Cam	Blue	12 
    S4	Clark	20	London	PI	Nut	Red	12 
    S4	Clark	20	London	P4	Screw	Red	14 
    S4	Clark	20	London	P6	Cog	Red	19 
    
    
    Рис. 17.8. Соединение отношений S и Р по атрибуту CITY 

    •  Вставка кортежа (S7, Bruce, 15, Oslo, P8, Wheel, White, 25) будет 
успешно завершена и приведет к вставке кортежа (S7, Bruce, 15, Oslo) в 
отношение S и кортежа (Р8, Wheel, White, 25, Oslo) в отношение Р 
(следовательно, указанный кортеж попадет в представление). 

    Глава 17. Представления 459 

    •  Вставка кортежа (S1, Smith, 20, London, P7, Washer, Red, 5) будет 
успешно завершена и приведет к вставке кортежа (Р7, Washer, Red, 5, London) в 
отношение Р (следовательно, в представление попадет два кортежа— (SI, Smith, 
20, London, Р7, Washer, Red, 5) и (S4, Clark, 20, London, P7, Washer, Red, 5)). 
    •  Вставка кортежа (S6, Green, 20, London, P7, Washer, Red, 5) будет 
успешно завершена и приведет к вставке кортежа (S6, Green, 20, London) в 
отношение S и кортежа (Р7, Washer, Red, 5, London) в отношение Р 
(следовательно, в представление попадет шесть кортежей). 
    •  Удаление кортежа (SI, Smith, 20, London, PI, Nut, Red, 12) будет 
успешно завершено и приведет к удалению кортежа (SI, Smith, 20, London) из 
отношения S и кортежа (Р 1, Nut, Red, 12, London) из отношения Р 
(следовательно, из представления исчезнет четыре кортежа). 
    Остальные примеры в качестве упражнения предлагается создать читателю. 

    Другие операции 

    В этом разделе кратко описаны оставшиеся операции реляционной алгебры: 
декартово произведение, 0-соединение, переименование, деление и операция 
подведения итогов. 
    • Декартово произведение. Так как декартово произведение является частным 
случаем естественного соединения (A JOIN В вырождается в A TIMES В, если А и В 
не имеют общих атрибутов), то правила для декартова произведения (A TIMES В) 
являются частным случаем правил обновления соединений (A JOIN В). Детальный 
анализ правил оставлен в качестве упражнения. 
    •   в-соединение. Это выборка декартова произведения. Следовательно, 
правила обновления таких представлений можно получить из правил обновления для 
декартовых произведений. 
    • Переименование. Тривиальный случай. 
    • Деление. Деление (как и 6-соединение) не совсем примитивная операция, 
поэтому соответствующие правила можно получить из уже изложенных (в частности, 
из правил для вычитания, проекции и декартова произведения). Как и прежде, 
детальное изложение правил для данной операции оставлено в качестве упражнения 
для читателя, но следует заметить, что представления, полученные с помощью 
операции деления, возможно, вообще не являются обновляемыми (точно укажите причину). 
    •  Подведение итогов. В основном операция подведения итогов (SUMMARIZE) не 
является операцией, сохраняющей информацию. Поэтому не существует однозначного 
обратного отображения из результата в исходное отношение. Следовательно, 
представления, которые определены с помощью операции SUMMARIZE, не обновляемы. 

    Замечание о целевых отношениях 

    Завершим обсуждение проблемы обновления представлений следующим 
утверждением. Пусть, например, представление, построенное с помощью операции 
соединения, является обновляемым. Тогда нет никаких причин использовать в 
качестве целевых отношений в операциях INSERT, DELETE и UPDATE именованные 
отношения. Поэтому если выражение INSERT INTO SSP корректно (представление SSP 
приводилось выше в этой главе), то выражение INSERT INTO (s JOIN SP) также 
должно быть корректным. Конечно, аналогичные соображения применимы и для 
реляционных операций присвоения. 

    460	Часть V. Дополнительные аспекты 

    Для демонстрации предположим, что представление LSSP определено с помощью 
следующего выражения: 

    ( S WHERE CITY = 'London1 ) JOIN SP 

    Исходя из обычных образцов данных, попытка вставить кортеж (S6, Green, 20, 
London, Р6, 100) будет успешно завершена и приведет к вставке кортежа (S6, 
Green, 20, London) в отношение S и кортежа (S6, Р6, 100) в отношение SP. 
Точнее, первый из двух кортежей — (S6, Green, 20, London) — будет вставлен не 
непосредственно в отношение S, а в выборку s WHERE CITY = 'London1, Далее в 
игру вступает правило вставки кортежей в выборку, что и приводит к желаемому 
результату. Тем не менее, следует отметить один важный аспект: целевое 
отношение промежуточной операции INSERT представлено не именованным 
отношением, а выражением с операцией выборки. 

    17.8. Снимки 

    Здесь будет уместно, несколько отклонившись от основной темы, обсудить 
понятие снимков (snapshots) [17.1]. Снимки, также называемые снимками данных, 
имеют много общего с представлениями (но не следует путать эти понятия). Как 
описано в главе 4, снимок данных — это именованное производное отношение (т.е. 
реляционная переменная), как и представление. Тем не менее, в отличие от 
представления, снимок реален, а не виртуален: он представлен в базе данных не 
только своим определением в терминах других именованных отношений, но и (по 
крайней мере концептуально) своими собственными данными. Ниже приведен пример, 
заимствованный из главы 4. 

    CREATE SNAPSHOT SC AS 
    ( ( S JOIN SP ) WHERE P# = 'P2' ) [ S#, CITY ] REFRESH EVERY DAY; 

    Создание снимка во многом походит на выполнение запроса, за исключением 
того, что, во-первых, результат запроса хранится в базе данных под указанным 
именем (в примере это SC) как отношение, которое допускает только чтение', 
во-вторых, периодически (в примере — каждый день (EVERY DAY)) снимок данных 
обновляется, т.е. текущие данные аннулируются и запрос выполняется повторно, 
после чего результат запроса принимается в качестве нового значения снимка. 
Таким образом, снимок в примере представляет состояние данных, в котором они 
находились не более 24 часов назад. 
    Тонкость идеи снимков состоит в том, что многие приложения, возможно даже 
большинство приложений, могут использовать или даже запрашивать данные по 
состоянию на конкретный момент времени. Например, в эту категорию приложений 
попадают приложения для отчетности и бухгалтерского учета. Подобные приложения 
обычно требуют фиксирования состояния данных в нужный момент (например, в 
конце периода отчетности), и снимки позволяют выполнять такую фиксацию, не 
влияя на другие транзакции, обновляющие данные. Кроме того, как показано в 
главе 1, может понадобиться зафиксировать состояние данных большого объема для 
сложного запроса или приложения поддержки принятия решений без запрещения 
обновляющих транзакций. 

    Замечание. Эта идея становится еще привлекательнее в контексте 
распределенных баз данных (см. главу 21). 

    Приведем синтаксис инструкции CREATE SNAPSHOT: 

    CREATE SNAPSHOT снимок AS выражение REFRESH EVERY время_обновления ; 

    В этом выражении в качестве время_обновленш можно использовать, например, 
MONTH (месяц), WEEK (неделя), HOUR (час), п MINUTES (минуты), MONDAY 
(понедельник), WEEKDAY (день недели) и т.п. Ниже показан синтаксис 
соответствующего выражения 

    DESTROY: 
    DESTROY SNAPSHOT снимок ; 

    Глава 17, Представления	461 

    В результате этой операции снимок данных будет уничтожен (т.е. из каталога 
базы данных будет удалено определение снимка данных). 
    Замечание. Операция DESTROY SNAPSHOT завершится неудачей, если какой-либо 
снимок данных или представление ссылаются в этот момент на удаляемый снимок 
данных. Дополнительно в определении снимка данных можно использовать операторы 
RESTRICTED или CASCADES. Детально такая возможность не будет обсуждаться в 
этой главе. 

    17.9. Поддержка SQL 

    В этом разделе будут подытожены средства поддержки языка SQL для 
представлений (к сожалению, на данный момент SQL не поддерживает снимков 
данных в какой-либо форме). Прежде всего рассмотрим синтаксис инструкции 
CREATE VIEW: 

    CREATE VIEW представление AS табличное_ вьражение [ WITH CHECK OPTION ] ; 

    Пояснения: 
    1.  Выражение табличное_вьражение определяет представление. Подобные 
выражения уже описывались ранее в этой книге. 
    2.  Оператор WITH CHECK OPTION (если он указан) означает, что операции 
INSERT и UPDATE на представлении будут отменяться, если они будут нарушать 
условие, определяющее представление. Поэтому заметьте, что подобные операции 
будут завершаться неудачей (только когда указан оператор WITH CHECK OPTION), 
по умолчанию операции вставки и обновления кортежей будут завершаться успешно. 
Из сказанного можно сделать вывод, что подобный результат логически не 
корректен. Поэтому настоятельно рекомендуется для обновляемых представлений 
всегда указывать оператор WITH CHECK OPTION. (Конечно, здесь обновляемые 
представления рассматривается в контексте стандарта SQL (см. далее). 
Действительно, оператор WITH CHECK OPTION нельзя применять для представлений, 
не являющихся обновляемыми.) 

    Замечание. Оператор WITH CHECK OPTION обладает множеством нюансов, 
обсуждение которых выходит за рамки этой книги. Более детально, с примерами 
этот оператор описан в [8.5], а критический обзор понятия дан в [17.4]. 

    Примеры: 

    1. CREATE VIEW REDPARTS 
    AS SELECT P.P#, P.NAME, P.WEIGHT, P.CITY 
    FRCM  P 
    WHERE P.COLOR = 'Red' WITH CHECK OPTION ; 

    2. CREATE VIEW LREDPARTS 
    AS SELECT REDPARTS.P#, REDPARTS.WEIGHT 
    FRCM  REDPARTS 
    WHERE REDPARTS. CITY = 'London' WITH CHECK OPTION ; 

    3. CREATE VIEW CITYPAIRS 
    AS SELECT DISTINCT S.CITY AS SCITY, P.CITY AS PCITY FRCM  S, SP, P WHERE 
S.S# = SP.S# AND   SP.P# = P.P# ; 

    4. CREATE VIEW PQ 
    AS SELECT SP.P#,   SUM   (  SP.QTY )   AS TOTCTY FRCM      SP GROUP    BY 
SP.P#  ; 

    462	Часть V. Дополнительные аспекты 

    Существующее представление может быть уничтожено с помощью операции DROP 
VIEW, синтаксис которой показан ниже, 

    DROP VIEW представление опция ; 

    В этом операторе (как и в операторах DROP TABLE и DROP DOMAIN) опция— это 
операторы RESTRICT или CASCADE. Если используется оператор RESTRICT и на 
данное представление существуют ссылки из определений других представлений или 
из условий целостности, то операция DROP завершится неудачей. Если 
используется оператор CASCADE, то операция DROP будет завершена успешно и 
приведет к каскадному удалению всех представлений и ограничений целостности, 
определения которых ссылаются на удаляемое представление. 
    Операции выборки на представлениях. Как было показано выше в этой главе, 
все операции выборки на всех предстзвлениях рзботают корректно в текущей 
версии стандарта SQL (версия SQL/92). К сожалению, это утверждение нельзя 
применить к некоторым современным программным продуктам, впрочем, как и к 
предыдущим версиям стандарта SQL. 
    Операции обновления представлений. Стандарт SQL поддерживает весьма 
ограниченный нзбор операций обновления представлений. В основном как 
обновляемые рассматриваются только те представления, которые получены на 
основе одной таблицы базы данных с помощью некоторых комбинаций операций 
выборки и проекции. Более того, даже этот простой тип представлений трактуется 
непрзвильно. Причина заключается в том, что в стандарте SQL недостаточно 
развиты средства работы с предикатами отношений, в частности, таблицы 
стандэртз SQL могут содержать дублирующиеся строки. 
    Ниже более точно изложен критерий обновляемости представлений в стандзрте 
SQL (этот список взят из [8.5]). Стандарт SQL предполагает, что представление 
является обновляемым тогда и только тогдз, когдз для него истинны утверждения 1-8. 
    1.  Табличное выражение, которое определяет область действия 
представления, должно быть выражением выборки. Следовательно, в это выражение 
не должны входить операторы JOIN, UNION, INTERSECT и EXCEPT. 
    2.  Оператор SELECT в табличном выражении не должен непосредственно 
содержать ключевого слова DISTINCT. 
    3.  Каждый элемент выборки в операторе SELECT состоит из 
классифицированного имени столбца (возможно, сопровождаемого инструкцией AS), 
который представляет простую ссылку нз столбец исходной таблицы (см. пункт 5). 
    4.  Оператор FROM в выражении выборки содержит единственную ссылку на таблицу. 
    5.  Ссылка на таблицу представляет собой либо таблицу базы данных, либо 
обновляемое представление. Замечание. Таблица, указзнная с помощью ссылки, 
является единственной исходной таблицей для рассматриваемого представления. 
    6.  В выражение выборки не входит оператор WHERE, содержащий вложенное 
табличное выражение, которое включает оперзтор FROM, ссылающийся на ту же 
таблицу, что и оператор FROM, описанный в пункте 4. 
    7.  Выражение выборки не содержит инструкции GROUP BY. 
    8.  Выражение выборки не содержит инструкции HAVING. 

    Замечание J. Обновляемость в стандарте SQL реализована по принципу "все 
или ничего". Это значит, что все три операции, INSERT, UPDATE и DELETE, либо 
можно применять нз представлении, либо все три операции применять на 
представлении нельзя. Например, в контексте стандартз SQL невозможна ситуация, 
когдз на представлении можно применять операцию DELETE и нельзя применять 
операцию INSERT (хотя некоторые коммерческие программные продукты обладают 
такой возможностью). 

    Глава 17. Представления	463 


    Замечание 2. В стандарте SQL операция UPDATE либо применима к данному 
представлению, либо нет. В контексте стандарта SQL недопустима ситуация, когда 
одни столбцы представления являются обновляемыми, а другие — нет (хотя 
некоторые коммерческие программные продукты пошли дальше стандарта в этом отношении). 

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

    17.10. Резюме 

    Представление — это именованное реляционное выражение. Представления также 
называют именованными виртуальными отношениями (или переменными). Операции на 
представлениях обычно реализуются с помощью процесса подстановки, который 
состоит в замене имени представления выражением, определяющим представление. 
Такой процесс подстановки основан на свойстве замкнутости. Для операций 
выборки процесс подстановки корректно выполняется в ста процентах случаев (по 
крайней мере теоретически, но не обязательно на практике). Для операций 
обновления процесс подстановки корректно выполняется, только если 
представление является сохраняющим информацию (опять же теоретически, но не 
обязательно на практике). 
    В этой главе рассматривался обширный набор принципов, которые должны 
управлять процессом проектирования любого систематического механизма 
обновления представлений. Наиболее важным из них является принцип, гласящий, 
что предикат данного отношения (в частности, данного представления) служит 
критерием применимости операции обновления к данному отношению. Здесь также 
рассматривался механизм обновления, который на самом деле соответствует 
изложенным принципам. В частности, были изложены правила обновления 
представлений, определенных с помощью операций объединения, пересечения, 
вычитания, выборки, проекции, соединения и расширения. Кроме того, кратко 
рассматривались правила обновления представлений, определенных с помощью 
операций декартова произведения, 6-соединения, переименования и деления. 
    Также была затронута проблема логической независимости данных. Существует 
два аспекта такой независимости: аспект роста и аспект реструктуризации. Оба 
аспекта очень важны (но представления можно применять только в связи со вторым 
аспектом). Среди других преимуществ представлений можно отметить: способность 
представлений скрывать данные и, следовательно, обеспечивать некоторый уровень 
защиты, а также способность облегчать жизнь пользователей благодаря различным 
"макровозможностям". 
    Также здесь приведено обсуждение работы со снимками. И наконец, кратко 
описаны относящиеся к теме аспекты стандарта SQL. 
    Осталось обсудить одно утверждение, которое почти всем понятно, но крайне 
редко оценивается по достоинству. На это утверждение следует обратить особое 
внимание, так как оно придает дополнительную поддержку изложенному здесь 
подходу к решению проблемы обновления представлений. Вот это утверждение: 
    Для любой базы данных выбор, какие отношения должны быть базовыми, а какие 
представлениями, выполняется достаточно произвольно. 
    В случае отношения с информацией о поставщиках, например, можно сделать 
хорошо знакомое отношение S базовым и затем определить две проекции — SNC (на 
атрибутах S#, SNAME и CITY) и ST (на атрибутах S# и STATUS) — как 
представления. Или можно создать два базовых отношения, а затем определить 
представление S (как соединение SNC и ST). Суть в том, что, конечно, 
обновляемость выбранной базы данных не должна зависеть от вашего решения, 
какие отношения представлять в виде 

    464	Часть V. Дополнительные аспекты 

    базовых, а какие — в виде представлений1. В нашем примере обновляемость 
отношения 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 = 'Green1 ; 

    б) ТВ := ( EXTEND HEAVYWEIGHTS ADD WT + 5 AS WTP ) [ P#, WTP ] ; B) UPDATE 
HEAVYWEIGHTS WHERE WT 18 COL := 'White' ; Г) DELETE HEAVYWEIGHTS WHERE WT < 10 
; Д) INSERT ( ( P#:'P99', WT:12, COL:'Purple1 ) ) INTO HEAVYWEIGHTS ; 

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

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

    Теперь выполните задание упр. 17.6. 
    17.8. В главе 5 упоминалось, что иногда для представлений желательно 
объявлять потенциальные ключи (или первичный ключ), т.е. включать оператор 
CANDIDATE ИЛИ PRIMARY KEY В Выражение CREATE VIEW. Почему ЖСЛаТСЛЬНО ИМСТЬ 
такую возможность? 
    17.9. Какие расширения системного каталога (описывался в главах 3 и 4), 
необходимы для поддержки представлений? Что можно сказать по поводу снимков? 

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

    Глава 17. Представления	465 

    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) 
утверждает, что общая проблема обновляемости представлений неразрешима, т.е. 
не существует общего алгоритма определения обновляемости (в смысле Кодда) или 
ее отсутствия для произвольного представления. Тем не менее, следует заметить, 
что определение обновляемости, использованное в этой главе, несколько 
отличается от определения, введенного Коддом. Различие состоит в том, что 
использованное в этой главе определение обновляемости сформулировано в 
терминах предикатов отношений. 

    466	Часть V. Дополнительные аспекты 

    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, № 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, № 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 

    Глава 17. Представления	467 

    , 
    SIGACT-SIGMOD Symposium on Principles of Database Systems. — Portland, 
Ore., 1985. 
    Предложен набор из пяти критериев, которым должен удовлетворять алгоритм 
обновления представлений: отсутствие побочных эффектов, только одноэтапные 
изменения, отсутствие ненужных изменений, отсутствие более простых замен и 
отсутствие пар 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. 
    Пусть А и В являются произвольными отношениями с предикатами РА и РВ 
соответственно. Говорят, что А и В перекрываются тогда и только тогда, когда 
можно создать такой кортеж /, что истинными будут оба выражения, PA(t) и 
PB(t). Тогда принцип проектирования можно записать так: 
    Пусть А' и В'— два произвольных отношения базы данных и пусть А и В 
являются проекциями А' и В' соответственно по всем атрибутам, для которых не 
установлено значение по умолчанию. 
    Под "декомпозицией без потерь" здесь понимается декомпозиция данного 
отношения на несколько проекций, причем: а) данное отношение может быть 
воссоздано с помощью соединения всех проекций; б) ни одна из проекций не 
является избыточной в процессе воссоздания исходного отношения. 
    В работе представлено несколько примеров и аргументов в поддержку этого 
принципа, а также указаны последствия соблюдения этого принципа, состоящие в 
том, что если А и В — любые базовые отношения совместимых типов, то всегда 
истинны следующие утверждения: 

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

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

    468	Часть V. Дополнительные аспекты 

    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.3]. 

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

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

    17.1.1. CREATE VIEW REDPARTS AS 
    (  P.P#,   P.PNAME,   P.WEIGHT AS WT,   P.CITY  ) WHERE P.COLOR =   'Red'; 
    17.1.2. CREATE VIEW PQ AS (  SP.P#, SIM   (  SPX WHERE SPX.Ptt = SP.P#,   
OTY  )   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.Stt = S.S# 
    AND SP.P# = P.P# ) ; 

    17.1.4. CREATE VIEW LONDON_REDPARTS AS 
    ( REDPARTS WHERE REDPARTS.CITY = 'London' ) ; 

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

    17.2. CREATE VIEW NON_COLCCATED AS 
    ( S.S#, P.P# ) WHERE S.CITY Ф P.CITY ; 
    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#. 

    CREATE VIEW SP AS 
    ( SPJX.Sft, SPJX.P#, 

    Глава 17. Представления	469 

    SUM ( SPJY WHERE SPJY.S# = SPJX.Stf 
    AND  SPJY.P# = SPJX.Ptf, QTY ) AS QTY ) ; 

    17.5. CREATE VIEW JC AS 
    ( J.J#, J.CITY ) WHERE EXISTS SPJ ( SPJ.S# = 'SI' AND 
    SPJ.P* = 'PI' 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. 

    470	Часть V. Дополнительные аспекты 

    • Каждое представление также будет иметь запись в новом отношении, которое 
нужно включить в каталог базы данных. Назовем это отношение 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 В может привести к вставке кортежа / только в 
отношение А (если этот кортеж уже присутствует в В). Заметим еще раз, что 
подобная асимметрия может возникнуть, только если база данных плохо 
спроектирована [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 ) ) 

    Глава 17. Представления	471 

    PRIMARY KEY ( S# ) ; 
    INSERT S [ S#, SNAME, CITY ] INTO SNC ; INSERT S [ S#, STATUS ] INTO ST ; 
DESTROY BASE RELATION S ; 

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

    CREATE VIEW S AS 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.Ptf,   SUM   (SP.QTY  )   AS TOTQTY 
    FROM      SP 
    GROUP    BY SP.P#  ; 

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

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

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

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

    472	Часть V. Дополнительные аспекты 

    FRCM      SP 
    GROUP    BY SP.P#  ; 

    Это некорректное SELECT-выражение, так как SQL не позволяет вкладывать 
агрегативные функции друг в друга. 
    Ниже показан другой пример запроса к тому же представлению PQ, который 
также завершается неудачей (и по той же причине). 

    SELECT	PQ.P# 
    FROM	PQ 
    WHERE	PQ.TOTOTY > 500 ; 

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

    Глава 17. Представления	473 

