РУКОВОДСТВО ПО РЕЛЯЦИОННОЙ СУБД DB2

         

ОПРЕДЕЛЕНИЕ ПРЕДСТАВЛЕНИЯ


Общий синтаксис предложения CREATE VIEW (создать представление):

CREATE   VIEW имя—представления

[(имя—столбца[ , имя—столбца] . . .)]

AS подзапрос

[WITH CHECK OPTION];

Как обычно, подзапрос не может включать ни оператора UNION, ни фразы ORDER BY. Однако при этих ограничениях любая таблица, выборка которой может быть осуществлена с помощью предложения SELECT, может быть, с другой стороны, определена как представление. Ниже приведено несколько примеров.

1. CREATE           VIEW  КРАСНЫЕ_ДЕТАЛИ             (НОМЕР—ДЕТАЛИ,

НАЗВАНИЕ, ВЕС, ГОРОД)

AS            SELECT           НОМЕР_ДЕТАЛИ, НАЗВАНИЕ, ВЕС, ГОРОД

FROM              P

WHERE           ЦВЕТ = 'Красный';

Действие этого оператора заключается в том, чтобы создать новое представление, названное xyz.КРАСНЫЕ_ДЕТАЛИ, где xyz — известное системе имя пользователя, издавшего предложение CREATE VIEW. Пользователь xyz может называть это представление просто КРАСНЫЕ_ДЕТАЛИ. Другие же пользователи должны называть его xyz.КРАСНЫЕ_ДЕТАЛИ. С другой стороны, они могут, конечно, ввести для него синоним, как указывалось в главе 7. В этом представлении четыре столбца — НОМЕР_ДЕТАЛИ, НАЗВАНИЕ, ВЕС и ГОРОД, соответствующих четырем столбцам НОМЕР_ДЕТАЛИ, НАЗВАНИЕ, ВЕС и ГОРОД лежащей в основе базовой таблицы Р. Если имена столбцов явно не специфицированы в предложении CREATE VIEW, то представление очевидным образом наследует имена столбцов его источника. В приведенном примере наследуемыми именами были бы НОМЕР_ДЕТАЛИ, НАЗВАНИЕ, ВЕС и ГОРОД. Имена столбцов должны быть специфицированы явно для всех столбцов представления, если: а) какой-либо столбец этого представления продуцируется с помощью стандартной функции, арифметического выражения или константы (и не имеет, следовательно, имени, которое он мог бы наследовать) или б) два или более столбцов имели бы в противном случае одно и то же имя. Каждый из этих двух случаев иллюстрируется в следующих двух примерах.

2. CREATE           VIEW PQ         (НОМЕР_ДЕТАЛИ, ОБЩЕЕ_КОЛИЧЕСТВО)




AS                   SELECT           НОМЕР_ДЕТАЛИ, SUM (КОЛИЧЕСТВО)

FROM              SP

GROUP           BY НОМЕР_ДЕТАЛИ;

В этом примере нет такого имени, которое могло бы наследоваться для второго столбца, поскольку этот столбец продуцируется с помощью стандартной функции. Поэтому имена столбцов здесь должны быть специфицированы явным образом, как было показано в примере. Обратите внимание, что это представление не является просто подмножеством строк и столбцов лежащей в основе базовой таблицы (в отличие от рассмотренных выше представлений КРАСНЫЕ_ДЕТАЛИ и ХОРОШИЕ_ПОСТАВЩИКИ). Его можно было бы рассматривать как некоторого рода статистическую сводку или сжатие лежащей в основе таблицы.

3. CREATE           VIEW              ПАРЫ_ГОРОДОВ (ГОРОД_ПОСТАВЩИКА,

ГОРОД_ДЕТАЛИ)

AS            SELECT           S. ГОРОД, Р. ГОРОД

FROM              S, SP, P

WHERE           S. НОМЕР_ПОСТАВЩИКА =

SP. НОМЕР_ПОСТАВЩИКА

AND                            SP.HOMEP_ДЕТАЛИ = Р.НОМЕР_ДЕТАЛИ;

Смысл этого представления в том, что пара имен городов (х,у) будет входить в данное представление, если поставщик с местоположением в городе х поставляет какую-либо деталь, хранимую в городе у. Например, поставщик S1 поставляет деталь Р1. При этом поставщик S1 находится в Лондоне и деталь Р1 хранится тоже в Лондоне. И поэтому пара (Лондон, Лондон) входит в данное представление. Обратите внимание, что в определении этого представления используется соединение и, таким образом, оно является примером представления, продуцируемого из нескольких положенных в основу таблиц. Примечание. Мы могли бы при желании включить в определение этого представления спецификацию DISTINCT. Сравните с примером 4.3.5 в главе 4.

4. CREATE           VIEW              ЛОНДОНСКИЕ_КРАСНЫЕ_ДЕТАЛИ

AS            SELECT           НОМЕР_ДЕТАЛИ, ВЕС

FROM              КРАСНЫЕ_ДЕТАЛИ

WHERE           ГОРОД = 'Лондон';

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



5. CREATE           VIEW  ХОРОШИЕ_ПОСТАВЩИКИ

AS                   SELECT           НОМЕР_ПОСТАВЩИКА, СОСТОЯНИЕ, ГОРОД

FROM              S

WHERE           СОСТОЯНИЕ > 15

WITH              CHECK OPTION;

Фраза «WITH CHECK OPTION» ( с проверкой) указывает, что для операций UPDATE и INSERT над этим представлением должна осуществляться проверка, которая обеспечивает удовлетворение определяющего представление предиката обновленной или вставляемой строкой (в данном примере СОСТОЯНИЕ>15). Вариант CHECK более подробно описан в разделе 8.4.

Предложение DROP VIEW имеет следующий синтаксис:

DROP VIEW имя — представления;

В результате исполнения этого предложения уничтожается специфицированное представление, т. е. из каталога удаляется его определение. Все представления, определенные с его использованием, также автоматически уничтожаются.

Пример рассматриваемого предложения:

DROP VIEW КРАСНЫЕ_ДЕТАЛИ;

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

Предложения ALTER VIEW (изменить представление) в языке SQL нет. Предложение ALTER TABLE, которое добавляет новый столбец к базовой таблице, не оказывает влияния на любые существующие представления.


Содержание раздела