Пусть имеется БД, в которой определены два пользователя: User1 и User2. Пользователь User1 имеет право на выполнение хранимой процедуры aProcedure, а User2 – на выполнение всех DML-операций в таблице aTable. Также в БД имеется роль приложения anAppRole, которой дано разрешение только на выборку из таблицы aTable. Предположим, некое клиентское программное приложение взаимодействует с БД, не используя роль anAppRole. Тогда справедливо следующее:
· приложение может соединяться с БД от имени пользователя User1 или User2;
· если приложение работает с БД от имени User1, то ему будет разрешен запуск хранимой процедуры aProcedure;
· если приложение работает с БД от имени User2, то ему будут разрешены операции вставки, обновления, удаления и выборки в таблице aTable.
Если же клиентское приложение пользуется правами роли приложения, то ситуация с правами доступа меняется:
· приложение соединяется с БД от имени пользователя User1 или User2;
· не зависимо от того, какой из двух пользователей установил соединение, программе будет разрешена только выборка из таблицы aTable; прочие операции в этой таблице, а также запуск хранимой процедуры aProcedure не будут разрешены, т. к. у используемой роли приложения нет соответствующих прав.
Преимущество ролей приложения, особенно для ранних версий SQL Server, - в том, что они обеспечивают клиентские приложения правами доступа, не зависящими от конкретного пользователя, и в то же время позволяют избежать проникновения в БД нелегального пользователя. Однако в SQL Server 2005 появились новые возможности, благодаря которым роли приложения зачастую оказываются ненужными. Эти возможности будут рассмотрены позже.
Создание нового пользователя БД
Создание нового пользователя БД выполняется с помощью команды CREATE USER, имеющей следующий синтаксис:
CREATE USER имя_пользователя
[ { { FOR | FROM }
{
LOGIN имя_учетной_записи
| CERTIFICATE сертификат
| ASYMMETRIC KEY асимметричный_ключ
}
| WITHOUT LOGIN
]
[ WITH DEFAULT_SCHEMA = схема_по_умолчанию]
В секции FOR LOGIN задается имя учетной записи для привязки пользователя. В качестве альтернативного варианта привязки можно использовать цифровой сертификат (FROM CERTIFICATE) или асимметричный ключ (FROM ASYMMETRIC KEY). Если пользователя не нужно сразу отображать на существующую учетную запись, то вместо секции FOR ставятся ключевые слова WITHOUT LOGIN.
Опция WITH DEFAULT_SCHEMA используется для задания пользователю схемы по умолчанию. Что это означает?Схема (schema) в терминах SQL Server – это своего рода контейнер для объектов БД или, иначе говоря, набор объектов БД, объединенных общим пространством имен. Имя схемы включается в полное имя объекта БД. Что касается связи схем и пользователей, то, во-первых, для каждого пользователя определяется схема, владельцем которой он является по умолчанию. Имя такой схемы часто совпадает с именем пользователя, что весьма удобно: при таком подходе каждый пользователь имеет «свою» схему в БД.
В свете вышесказанного имеет смысл обратиться к правилам именования объектов БД в Microsoft SQL Server. Предположим, в БД myDatabase имеется пользователь ivanivanov, владеющий схемой ivanivanov (в данном примере название схемы совпадает с именем ее владельца). В схеме ivanivanov имеется таблица aTable. Запрос на выборку строк из этой таблицы с указанием ее полного имени будет выглядеть так:
select * from myDatabase.ivanpetrov.aTable
Однако SQL Server допускает использование имен объектов без явного указания БД и схемы. Если имя БД не указывается, сервер «считает», что объект находится в текущей (для данного соединения) БД. Если при этом не указывается и схема, то обращение будет производиться к объекту, расположенному в умалчиваемой схеме пользователя, выполнившего запрос. Предположим, что пользователь ivanivanov, по умолчанию – владелец одноименной схемы ivanivanov, установил соединение с БД myDatabase. В этом случае он имеет право выполнить запрос к таблице aTable, указывая сокращенное, а не полное имя:
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.