Определение привилегий
В соответствии с идеологией языка 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-ориентированных СУБД поддерживается механизм защиты данных на основе привилегий доступа, реализации могут различаться в деталях. Это опять то место, которое нужно локализовывать, если стремиться к созданию мобильной прикладной системы.
