Модифицирование представлений

Представление может теперь изменяться командами модификации 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, или который основывается на других групповых представлениях.

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

Вместо того, чтобы конструировать каждый раз сложный запрос, вы можете просто создать следующее представление:

CREATE VIEW Totalforday
AS SELECT odate, COUNT(DISTINCT cnum), COUNT(DISTINCT snum),
COUNT(onum), AVG(amt), SUM(amt)
FROM Orders
GROUP BY odate;

Теперь вы сможете увидеть всю эту информацию с помощью простого запроса:

SELECT *
FROM Totalforday;

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

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