Понимание SQL

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

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

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

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

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