Определение привилегий

Примеры

• Следующая инструкция создает модифицируемый вид:

CREATE VIEW SNOW_LINE (CITY, STATE, SNOW_ALTITUDE) AS

SELECT CITY, STATE, ALTITUDE

FROM CITIES

WHERE ALTITUDE > 5000;

• Следующая инструкция использует вложенные запросы для создания вида:

CREATE VIEW RECENT_CITIES AS

SELECT STATE, CITY, POPULATION FROM CITIES WHERE STATE IN

(SELECT STATE FROM STATES WHERE STATEHOOD > "1-JAN-1850");

• В модифицируемом виде, WITH CHECK OPTION предотвращает любые вставки или модификации через вид, которые не удовлетворяют предложению WHERE в инструкции CREATE VIEW SELECT:

CREATE VIEW HALF_MILE_CITIES AS

SELECT CITY, STATE, ALTITUDE FROM CITIES

WHERE ALTITUDE > 2500

WITH CHECK OPTION;

• Предложение WITH CHECK OPTION в предыдущем виде, предотвратило бы следующую вставку:

INSERT INTO HALF_MILE_CITIES (CITY, STATE, ALTITUDE)

VALUES ("Chicago", "Illinois", 250);

• С другой стороны, следующий UPDATE был бы разрешен:

INSERT INTO HALF_MILE_CITIES (CITY, STATE, ALTITUDE)

VALUES ("Truckee", "California", 2736);

• Предложение WITH CHECK OPTION не допускают модификаций через вид, которые изменяют значения строки, так что вид не сможет отыскать их:

UPDATE HALF_MILE_CITIES

SET ALTITUDE = 2000

WHERE STATE = "NY";

• Следующая инструкция создает вид, который join две таблицы и поэтому только для чтения:

CREATE VIEW PHONE_LIST AS SELECT

EMP_NO, FIRST_NAME, LAST_NAME, PHONE_EXT, LOCATION, PHONE_NO

FROM EMPLOYEE, DEPARTMENT

WHERE EMPLOYEE.DEPT_NO = DEPARTMENT.DEPT_NO;

• Следующая инструкция создает просмотр для учебной базы данных:

CREATE VIEW PDV(PNAME, DNAME, VOLUME)

AS SELECT A.PNAME, B.DNAME, C.VOLUME

FROM P A, D B, PD C WHERE A.PNUM = C.PNUM AND B.DNUM = C.DNUM;

В соответствии с идеологией языка SQL контроль прав доступа данного пользователя к таблицам БД производится на основе механизма привилегий. Фактически, этот механизм состоит в том, что для выполнения любого действия над таблицей пользователь должен обладать соответствующей привилегией (реально все возможные действия описываются фиксированным стандартным набором привилегий). Пользователь, создавший таблицу, автоматически становится владельцем всех возможных привилегий на выполнение операций над этой таблицей. В число этих привилегий входит привилегия на передачу всех или некоторых привилегий по отношению к данной таблице другому пользователю, включая привилегию на передачу привилегий. Иногда поддерживается и обратная операция изъятия привилегий от пользователя, ранее их получившего.

В SQL/89 определяется упрощенная схема механизма привилегий. Во-первых, «раздача» привилегий возможна только при определении таблицы. Во-вторых, пользователь, получивший некоторые привилегии от других пользователей, может передать их дальше только при определении схемы.

Определение привилегий производится в следующем синтаксисе:

<privilege definition>::=

GRANT <privileges> ON <table name> TO <grantee> [{,<grantee>}...] [WITH GRANT OPTION]

<privileges>::= ALL PRIVILEGES | <action> [{,<action>}...]

<action>::= SELECT | INSERT | DELETE | UPDATE [(<grant column list>)] | REFERENCES [(<grant column list>]

<grant column list>::= <column name> [{,<column name>}...]

<grantee>::= PUBLIC | <authorization identifier>

Смысл механизма определения привилегий в SQL/89 достаточно понятен из этого синтаксиса. Заметим лишь, что привилегией REFERENCES по отношению к указанным столбцам таблицы T1 необходимо обладать, чтобы иметь возможность при определении таблицы T определить ограничение по ссылкам между этой таблицей и существующей к этому моменту таблицей T1.

Еще раз заметим, что хотя в общем смысле во всех SQL-ориентированных СУБД поддерживается механизм защиты доступа на основе привилегий, реализации могут различаться в деталях. Это опять то место, которое нужно локализовывать, если стремиться к созданию мобильной прикладной системы.