SQL Execution Log SELECT *

=ROM Londonstaff;

snum

1001 1004

sname

Peel Motika

city

comm

London London

0.1200 0.1100

Рисунок 20.1: Представление Londonstaff

Когда вы приказываете SQL выбрать (SELECT) все строки (*) из представления, он выполняет запрос содержащий в определении - Loncfonstaff, и возвращает все из его вывода.

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

Содержание представления не фиксировано, и переназначается каждый раз когда вы ссылаетесь на представление в команде. Если вы добавите завтра другого, живущего в Лондоне продавца, он автоматически появится в представлении.

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

CREATE VIEW Salesown AS SELECT snum, sname, city FROM Salespeople:

SQL Execution Log SELECT *

OOOM Oo:LeOoMn;

Рисунок 2 0.2: Представление Salesown

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

МОДИФИЦИРОВАНИЕ ПРЕДСТАВЛЕНИЙ

Представление может теперь изменяться командами модификации DML, но модификация не будет воздействовать на само представление. Команды будут на самом деле перенаправлены к базовой таблице:

UPDATE Salesown

SET city = -Palo Alto-

WHERE snum = 1004;

Его действие идентично выполнению той же команды в таблице Продавцов. Однако, если значение комиссионных продавца будет обработано командой UPDATE

UPDATE Salesown SET comm = .20

WHERE snum = 1004;

она будет отвергнута, так как поле comm отсутствует в представлении Salesown. Это важное замечание, показывающее что не все представления могут быть модифицированы.

Мы будем исследовать проблемы модификации представлений в Главе 21.

ИМЕНОВАНИЕ СТОЛБЦОВ

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

* когда некоторые столбцы являются выводимыми, и проэтому не имеющими

имен.

* когда два или более столбцов в объединении имеют те же имена, что в их базовой таблице.

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

КОМБИНИРОВАНИЕ ПРЕДИКАТОВ ПРЕДСТАВЛЕНИЙ И

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

Когда вы делаете запрос представления, вы собственно, запрашиваете запрос. Основной способ для SQL обойти это, - объединить предикаты двух запросов в один. Давайте посмотрим еще раз на наше представление с именем Londonstaff:

CREATE VIEW Londonstaff AS SELECT *

FROM Salespeople WHERE city = London;

Если мы выполняем следующий запрос в этом представлении

SELECT *

FROM Londonstaff WHERE comm > .12;

он такой же, как если бы мы выполнили следующее в таблице Продавцов:

SELECT *

FROM Salespeople

WHERE city = London AND comm > .12;

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

CREATE VIEW Ratingcount (rating, number)

AS SELECT rating, COUNT (*)

FROM Customers GROUP BY rating;

Это дает нам число заказчиков, которые мы имеем для каждого уровня оценки (rating). Вы можете затем сделать запрос этого представления чтобы выяснить, имеется ли какая-нибудь оценка, в настоящее время назначенная для трех заказчиков:

SELECT *

FROM Ratingcount WHERE number = 3;

Посмотрим, что случится, если мы скомбинируем два предиката:

SELECT rating, COUNT (*) FROM Customers

WHERE COUNT (*) = 3 GROUP BY rating;

Это недопустимый запрос. Агрегатные функции, такие как COUNT (СЧЕТ), не могут использоваться в предикате. Првильным способом при формировании вышеупомянутого запроса, конечно же будет следующий:

SELECT rating, COUNT (*) FROM Customers GROUP BY rating; HAVING COUNT (*) = 3;

Но SQL может не выполнить превращения. Может ли равноценный запрос вместо запроса Ratingcount потерпеть неудачу? Да может! Это - неоднозначная область SQL, где методика использования представлений может дать хорошие результаты.

Самоелучшеечтоможносделатьвслучае, когдаобэтомничегонесказанов вашей системной документации, так это попытка в ней разобраться. Если команда допустима, вы можете использовать представления чтобы установить некоторые ограничения SQL в синтаксисе запроса.

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

Групповные представления - это представления, наподобии запроса Ratingcount в предыдущем примере, который содержит предложение GROUP BY, или который основывается на других групповных представлениях.