Пользователь, который создает просмотр, становится его владельцем. При создании просмотра пользователь должен иметь соответствующие привилегии к базовым таблицам.
* Некоторые просмотры по своей природе являются просмотрами только для чтения (см. разд. "Просмотры только для чтения и изменяемые"). Для формирования просмотра только для чтения создателю нужны привилегии SELECT К каждой базовой таблице.
* Для изменяемых просмотров создателю нужны привилегии ALL К базовым таблицам.
В дополнение к этому владельцы базовых таблиц и других просмотров, к которым обращается создаваемый просмотр, должны предоставить все требуемые привилегии для доступа и модификации этих объектов через просмотр самому просмотру. То есть привилегии к этим базовым объектам должны быть предоставлены просмотру.
Владелец просмотра имеет к нему все привилегии, включая возможность предоставлять привилегии к нему другим пользователям, триггерам и хранимым процедурам.
Создатель просмотра должен предоставить соответствующие привилегии пользователям, хранимым процедурам и другим просмотрам, которым нужен доступ к этому просмотру. Пользователь может получить привилегии к просмотру без доступа к его базовым таблицам.
В случае изменяемых просмотров привилегии INSERT, UPDATE и DELETE должны быть предоставлены всем пользователям, которым нужно выполнять операции DML над базовыми таблицами через просмотр. И наоборот, предоставляйте пользователям только привилегию SELECT, если вы собираетесь создавать просмотр только для чтения.
Если пользователь уже имеет требуемые права к базовым объектам просмотра, он автоматически будет использовать те же права к просмотру.
! ! !
ВНИМАНИЕ! Чем меньше привилегий предоставлено пользователю, тем больше защищены объекты базы данных. При этом потенциально большое количество привилегий в иерархии может вызвать проблемы, если цепь будет разрушена удалением привилегий владельца просмотра. Учитывая привлекательность просмотров в качестве механизма защиты данных от просмотра ненужными людьми, системному администратору следует поддерживать документацию по всем предоставленным привилегиям.
. ! .
Подробное описание привилегий SQL см. в главе 35.
Создание просмотров
Оператором DDL, определяющим запрос, который будет трансформирован в объект просмотра, является CREATE VIEW. Хотя он определяет таблицу (пусть и виртуальную) и позволяет употреблять пользовательские имена для объявления столбцов, его синтаксис не включает никаких определений данных для столбцов. Его структура создается на основе списка столбцов оператора SELECT и таблиц, указанных в предложении FROM, а также в необязательных предложениях JOIN этого оператора.
Все стили соединения (join) и объединения (union) наборов, которые поддерживаются для запросов, также поддерживаются и для просмотров. При этом не существует возможности определять просмотр, который получает выходной набор из хранимой процедуры, недопустимо также включать предложение ORDER BY.
Оператор CREATE VIEW
Синтаксис для CREATE VIEW:
CREATE VIEW имя-просмотра
[(-имя-столбца-просмотра [, имя-столбца-просмотра [,...]])]
AS
<спецификация-выбора> [WITH CHECK OPTION];
Имя просмотра уникально идентифицирует просмотр как объект базы данных. Имя не может быть тем же самым, что и имя другого просмотра, таблицы или хранимой процедуры.
Задание списка имен столбцов просмотра является необязательным, если не существует дубликатов имен в списке столбцов. По умолчанию будут использованы имена столбцов базовой таблицы (таблиц).
В случае, когда результатом соединения является появление дубликатов имен, то здесь необходимо использовать список, который будет переименовывать столбцы.
Следующий довольно безобразный пример демонстрирует, как могут появиться дубликаты имен столбцов:
CREATE VIEW VJOB_LISTING
AS
SELECT E.*,
J. J0B_C0DE,
J.JOB_TITLE
FROM EMPLOYEE E
JOIN JOB J
ON E.JOB_CODE = J.JOB_CODE ;
ISC ERROR CODE:335544351
unsuccessful metadata update
STORE RDB$RELATION_FIELDS failed
attempt to store duplicate value (visible to active transactions)
in unique index "RDB$INDEX_15"
(ISC ERROR CODE:335544351 неудачное изменение
метаданных невозможно сохранить RDB$RELATION_FIELDS
попытка сохранить дубликат значения (видимый в активных транзакциях) в уникальном индексе "RDB$INDEX_15")
Индекс RDB$INDEX_15 является уникальным индексом для имени отношения и имени поля. Столбец JOB_CODE из таблицы EMPLOYEE уже сохранен для VJOB_LISTING, отсюда и исключение.
Необходимо именовать все столбцы в этом просмотре:
CREATE VIEW VJOB_LISTING (
EMP_NO, FIRST_NAME, LAST_NAME,
PHONE_EXT, HIRE_DATE, DEPT_NO,
EMP_JOB_CODE, /* альтернативное имя */
JOB_GRADE, JOB_COUNTRY, SALARY, FULL_NAME,
JOB_JOB_CODE, /* альтернативное имя * /
JOB_TITLE)
AS
SELECT
E.*,
J. JOB_CODE,
J. JOB_TITLE
FROM EMPLOYEE E
JOIN JOB J
ON E.JOB CODE = J.JOB_CODE ;
Список также является обязательным, если список столбцов содержит какие-либо поля, полученные из выражений. Например, следующее определение будет ошибочным:
CREATE VIEW VJOB_ALTNAMES
AS
SELECT JOB_СODE || 'for ' || JOB_TITLE AS ALTNAME
FROM JOB;
ISC ERROR CODE:335544569
Invalid command
mast specify column name for view select expression
(ISC ERROR CODE:335544569 Неверная команда,
нужно задать имя столбца для выражения в операторе SELECT в просмотре)
Следующее будет правильным:
CREATE VIEW VJOB_ALTNAMES
(ALTNAME)
AS
SELECT JOB_CODE || ' for ' || JOB_TITLE
FROM JOB;
Список имен столбцов просмотра должен соответствовать порядку и количеству столбцов, указанных в операторе SELECT.
Спецификация SELECT- это обычный оператор SELECT, который может включать соединения, поля выражений, спецификации группирования и условия поиска- но не условия упорядочения.
Выходной список в предложении SELECT определяет типы, позиции и (если не заданы явно) имена столбцов просмотра.
Запрос SELECT DISTINCT также допустим.
Предложение FROM вместе с любыми предложениями JOIN или подзапросами определяет базовые таблицы просмотра.
! ! !
ПРИМЕЧАНИЕ. Выражение SELECT * FROM <отношение> допустимо, однако для просмотров не рекомендуется, если в ваших планах эффективная документируемое?. Если используется такое выражение, то порядок следования столбцов будет соответствовать порядку в базовой таблице. Важно помнить, что вам нужно использовать предложение именования столбцов (см. разд. "Задание имен столбцов просмотра").
. ! .
Вы можете включить предложение WHERE, если вам нужно задать условия поиска. Также может быть включено предложение GROUP BY вместе с необязательным предложением HAVING.
Те же самые правила, которые применяются к любым выражениям для определения полей времени выполнения в запросах, также применимы к столбцам времени выполнения в спецификациях просмотров. Выход просмотра почти такой же, что и вычисляемые столбцы в таблице. При этом вычисляемый столбец имеет свои собственные отличные эффекты в просмотре:
* он требует, чтобы обязательно присутствовал список столбцов;
* он делает запрос неизменяемым.
Предположим, что вы хотите создать просмотр, который выводит гипотетическое увеличение на 10 процентов окладов всех служащих компании. Следующий пример создает просмотр только для чтения, который отображает всех служащих и их возможные новые оклады: