Создание и исключение пользователей

Как был создан пользователь с именем Rodriguez? Каким образом определя­ется этот идентификатор автора? Во многих программных продуктах DBA со­здает пользователя автоматически, передавая ему привилегию CONNECT. В этом случае обычно добавляется предложение IDENTIFIED BY, позволяющее определить пароль. Например, DBA может ввести:

GRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon;

Команда создает пользователя Thelonius, дает ему право входа в систему и назначает ему пароль Redwagon. Теперь, поскольку Thelonious является распо­знаваемым пользователем, он или DBA могут использовать эту же команду для изменения пароля Redwagon. На практике встречаются ограничения такого рода. Невозможно иметь пользователя, который не может войти в систему даже вре­менно. Если не надо предоставлять пользователю право входа в систему, следует выполнить команду REVOKE для привилегии CONNECT, которая лишит поль­зователя этой привилегии. Некоторые программные продукты позволяют созда­вать и разрушать пользователей независимо от привилегии входа в систему.

При передаче пользователю привилегии CONNECT создается сам этот пользо­ватель. Для этого нужно иметь привилегию DBA. Если "этот пользователь должен создавать базовые таблицы, а не только представления, он должен также получить привилегию RESOURCE. Однако здесь возникает другая проблема. Если попы­таться отменить привилегию CONNECT для пользователя, имеющего собственные таблицы, то эта команда будет отвергнута, поскольку в противном случае появи­лись бы таблицы, не имеющие владельца, а такая ситуация запрещена в теории и практике баз данных. Необходимо удалить все таблицы пользователя, прежде чем лишать его привилегии CONNECT. Если эти таблицы не пусты, потребуется со­хранить их содержимое в других таблицах с помощью команды INSERT, использующей запрос. Отменять привилегию RESOURCE отдельно нельзя, отмена при­вилегии CONNECT эквивалентна уничтожению пользователя.

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

Обсуждение этих вопросов выводит нас за границы стандарта SQL, опреде­ленного в настоящее время, а в некоторых программных продуктах касается областей, вообще не относящихся к компетенции SQL. Эти проблемы не встре­чаются на практике, если только пользователь не является DBA или пользова­телем высокого уровня. Обычным пользователям требуются лишь знания концепции назначения системных привилегий, эти сведения можно получить из конкретной системной документации.