Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Определение просмотра не может быть упорядоченным. Добавление предложения ORDER BY вызывает исключение. Следовательно, не имеет смысла использовать в операторе SELECT ключевых слов FIRST и/или SKIP, поскольку они оперируют с упорядоченными наборами.

Спецификация группирования запроса (с использованием допустимого предложения GROUP BY) является нормальной практикой.

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

Таблица JOB в базе данных employee.fdb имеет восемь столбцов: JOB_CODE, JOB_GRADE, JOB_COUNTRY, JOB_TITLE, MIN_SALARY, MAX_SALARY, JOB_REQUIREMENT и LANGUAGE_REQ.

Следующий просмотр возвращает список диапазонов (подмножество столбцов) для всех работ (все строки) таблицы JOB:

CREATE VIEW JOB_SALARY_RANGES AS

SELECT JOB_CODE, MIN_SALARY, MAX_SALARY FROM JOB;

Этот просмотр возвращает только столбцы JOB_CODE и JOB_TITLE только для тех работ, где MAX_SALARY меньше $15 000:

CREATE VIEW ENTRY_LEVEL_JOBS AS

SELECT JOB_CODE, JOB_TITLE FROM JOB

WHERE MAX_SALARY < 15000;

Следующий пример показывает просмотр, который соединяет таблицы JOB и EMPLOYEE.

EMPLOYEE содержит 11 столбцов: EMP_NO, FIRST_NAME, LAST_NAME, PHONE_EXT, HIRE_DATE, DEPT_NO, JOB_CODE, JOB_GRADE, JOB_COUNTRY, SALARY и FULL_NAME.

Просмотр возвращает два столбца из таблицы JOB и два столбца из таблицы EMPLOYEE, фильтруя записи таким образом, что записи работников, чья зарплата составляет $15 000 и выше. не попадают в выходной набор:

CREATE VIEW ENTRY_LEVEL_WORKERS AS SELECT

E.JOB_CODE,

J.JOB_TITLE,

E.FIRST_NAME,

E. LAST_NAME

FROM JOB J

JOIN EMPLOYEE E

ON J.JOB_CODE - E.JOB_CODE

WHERE E.SALARY < 15000;

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

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

* Настраиваемый доступ к данным: просмотры предоставляют способ для такой адаптации выхода базы данных, что он будет ориентирован на задачу, будет подходить для специфических навыков и требований пользователей и будет сокращать объем перемещаемых по сети данных.

* Независимость данных: просмотры могут защитить пользовательские приложения от воздействия изменений структуры базы данных. Например, если администратор базы данных решает разделить одну таблицу на две, просмотр может быть создан как соединение этих двух новых таблиц. Приложения могут использовать этот просмотр, как если бы они продолжали обращаться к одной постоянной таблице.

* Безопасность данных: просмотры позволяют ограничить доступ к важным или не относящимся к делу частям таблиц.

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

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

* Некоторые просмотры по своей природе являются просмотрами только для чтения (см. разд. "Просмотры только для чтения и изменяемые"). Для формирования просмотра только для чтения создателю нужны привилегии SELECT К каждой базовой таблице.

* Для изменяемых просмотров создателю нужны привилегии ALL К базовым таблицам.

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

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

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

В случае изменяемых просмотров привилегии INSERT, UPDATE и DELETE должны быть предоставлены всем пользователям, которым нужно выполнять операции DML над базовыми таблицами через просмотр. И наоборот, предоставляйте пользователям только привилегию SELECT, если вы собираетесь создавать просмотр только для чтения.

Если пользователь уже имеет требуемые права к базовым объектам просмотра, он автоматически будет использовать те же права к просмотру.

! ! !

ВНИМАНИЕ! Чем меньше привилегий предоставлено пользователю, тем больше защищены объекты базы данных. При этом потенциально большое количество привилегий в иерархии может вызвать проблемы, если цепь будет разрушена удалением привилегий владельца просмотра. Учитывая привлекательность просмотров в качестве механизма защиты данных от просмотра ненужными людьми, системному администратору следует поддерживать документацию по всем предоставленным привилегиям.

. ! .

Подробное описание привилегий SQL см. в главе 35.

Оператором DDL, определяющим запрос, который будет трансформирован в объект просмотра, является CREATE VIEW. Хотя он определяет таблицу (пусть и виртуальную) и позволяет употреблять пользовательские имена для объявления столбцов, его синтаксис не включает никаких определений данных для столбцов. Его структура создается на основе списка столбцов оператора SELECT и таблиц, указанных в предложении FROM, а также в необязательных предложениях JOIN этого оператора.

Все стили соединения (join) и объединения (union) наборов, которые поддерживаются для запросов, также поддерживаются и для просмотров. При этом не существует возможности определять просмотр, который получает выходной набор из хранимой процедуры, недопустимо также включать предложение ORDER BY.