Представления не требуют чтобы их вывод осуществлялся из одной базовой таблицы. Так как почти любой допустимый запрос SQL может быть использован в представлении, он может выводить информацию из любого числа базовых таблиц, или из других представлений. Мы можем, например, создать представление которое показывало бы, порядки продавца и заказчика по имени:
CREATE VIEW Nameorders
AS SELECT onum, amt, a.snum, sname, cname
FROM Orders a, Customers b, Salespeople c
WHERE a.cnum=b.cnum
AND a.snum=c.snum;
Теперь вы можете выбрать (SELECT) все порядки заказчика или продавца (* ), или можете увидеть эту информацию для любого порядка. Например, чтобы увидеть все порядки продавца Rifkin, вы должны ввести следующий запрос (вывод показан в Таблице 20.3 ):
SELECT *
FROM Nameorders
WHERE sname='Rifkin';
SELECT * FROM Nameorders WHERE sname='Rifkin';
onum | amt | snum | sname | cname |
3001 | 18.69 | 1007 | Rifkin | Cisneros |
3006 | 1098.16 | 1007 | Rifkin | Cisneros |
Таблица 20.3: Порядки Rifkin показаные в Nameorders
Вы можете также объединять представления с другими таблицами, или базовыми таблицами или представлениями, поэтому вы можете увидеть все порядки Axelrodа и значения его комиссиионных в каждом порядке:
SELECT a.sname, cname, amt comm
FROM Nameorders a, Salespeople b
WHERE a.sname='Axelrod'
AND b.snum=a.snum;
Вывод для этого запроса показывается в Таблице 20.4.
В предикате, мы могли бы написать - " WHERE a.sname=|Axelrod' AND b.sname=|Axelrod| ", но предикат который мы использовали здесь более общеупотребительный. Кроме того поле snum - это первичный ключ таблицы Продавцов, и следовательно должен по определению быть уникальным.
SELECT a.sname, cname, amt * comm FROM Nameorders a, Salespeople b
WHERE a.sname='Axelrod' AND b.snum=a.snum;
onum | amt | snum | sname | cname |
3001 | 18.69 | 1007 | Rifkin | Cisneros |
3006 | 1098.16 | 1007 | Rifkin | Cisneros |
Таблица 20. 4: Обьединение основной таблицы с представлением
Если бы там например было два Axelrodf, вариант с именем, будет обединять вместе их данные. Более предпочтительный вариант - использовать поле snum чтобы хранить его отдельно.
Представления могут также использовать и подзапросы, включая соотнесенные подзапросы. Предположим ваша компания предусматривает премию для тех продавцов которые имеют заказчика с самым высоким порядком для любой указанной даты. Вы можете проследить эту информацию с помощью представления:
CREATE VIEW Elitesalesforce
AS SELECT b.odate, a.snum, a.sname,
FROM Salespeople a, Orders b
WHERE a.snum=b.snum
AND b.amt=
(SELECT MAX (amt)
FROM Orders c
WHERE c.odate=b.odate);
Если, с другой стороны, премия будет назначаться только продавцу который имел самый высокий порядок за последние десять лет, вам необходимо будет проследить их в другом представлении основанном на первом:
CREATE VIEW Bonus
AS SELECT DISTINCT snum, sname
FROM Elitesalesforce a
WHERE 10 <=
(SELECT COUNT (*)
FROM Elitesalestorce b
WHERE a.snum=b.snum);
Извлечение из этой таблицы продавца, который будет получать премию - выпоняется простым вопросом:
SELECT *
FROM Bonus;
Теперь мы видим истинную мощность SQL. Извлечение той же полученной информации программами RPG или COBOL будет более длительной процедурой. В SQL, это - только вопрос из двух комплексных команд, сохраненных, как представление совместно с простым запросом. При самостоятельном запросе - мы должны заботится об этом каждый день, потому что информация которую извлекает запрос, непрерывно меняется чтобы отражать текущее состояние базы данных.
Имеются большое количество типов представлений (включая многие из наших примеров в этой главе ) которые являются доступными только для чтения. Это означает, что их можно запрашивать, но они не могут подвергаться действиям команд модификации. (Мы будем рассматривать эту тему в Главе 21.)
Имеются также некоторые виды запросов, которые не допустимы в определениях представлений. Одиночное представление должно основываться на одиночном запросе; ОБЪЕДИНЕНИЕ (UNION) и ОБЪЕДИНЕНИЕ ВСЕГО (UNIOM ALL) не разрешаются. УПОРЯДОЧЕНИЕ ПО(ORDER BY) никогда не используется в определении представлений. Вывод запроса формирует содержание представления, которое напоминает базовую таблицу и является - по определению - неупорядоченным.
Синтаксис удаления представления из базы данных подобен синтаксису удаления базовых таблиц:
DROP VIEW < view name >
В этом нет необходимости, однако, сначала надо удалить все содержание как это делается с базовой таблицей, потому что содержание представления не является созданым и сохраняется в течении определеной команды. Базовая таблица из которой представление выводится, не эффективна когда представление удалено. Помните, вы должны являться владельцем представления чтобы иметь возможность удалить его.