Мартин Грубер - Понимание SQL
Содержание представления не фиксировано, и переназначается каждый раз когда вы ссылаетесь на представление в команде. Если вы добавите завтра другого, живущего в Лондоне продавца, он автоматически появится в представлении.
Представления значительно расширяют управление вашими данными. Это - превосходный способ дать публичный доступ к некоторой, но не всей информации в таблице. Если вы хотите чтобы ваш продавец был показан в таблице Продавцов, но при этом не были показаны комиссии других продавцов, вы могли бы создать представление с использованием следующего оператора (вывод показан в Таблице 20.2 )
CREATE VIEW Salesown
AS SELECT snum, sname, city
FROM Salespeople:
SQL Execution Log
SELECT * FROM Salesown;
snum
sname
city
1001
Peel
London
1002
Serres
San Jose
1004
Motika
London
1007
Rifkin
Barcelona
1003
Axelrod
New York
Таблица 20.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, или который основывается на других групповных представлениях.
Групповые представления могут стать превосходным способом обрабатывать полученную информацию непрерывно. Предположим, что каждый день вы должны следить за порядком номеров заказчиков, номерами продавцов принимающих порядки, номерами порядков, средним от порядков, и общей суммой приобретений в порядках.
Чем конструировать каждый раз сложный запрос, вы можете просто создать следующее представление:
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 запросы могут дать вам полный комплекс возможностей, так что представления обеспечивают вас чрезвычайно гибким и мощным инструментом чтобы определить точно, как ваши данные могут быть использованы. Они могут также делать вашу работу более простой, переформатируя данные удобным для вас способом и исключив двойную работу.
ПРЕДСТАВЛЕНИЯ И ОБЬЕДИНЕНИЯПредставления не требуют чтобы их вывод осуществлялся из одной базовой таблицы. Так как почти любой допустимый запрос 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';
SQL Execution Log
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 - это первичный ключ таблицы Продавцов, и следовательно должен по определению быть уникальным.
SQL Execution Log
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 чтобы хранить его отдельно.
