>

4. В правой панели дважды щелкните Joe.

Откроется окно Database User Properties - Joe. -

5. В группе Database Role Membership пометьте флажок Dbownern щелкните Apply.

6. Раскройте меню Start\Programs\Microsoft SQL Server и выберите Query Analyzer. Откроется окно Connect To SQL Server.

7. Щелкните SQL Server Authentication.

8. В поле Login Name введите Joe.

9. В поле Password введите password и щелкните OK

Обратите внимание, что вы подключились к БД master под именем пользователя Joe.

10. В панели инструментов в списке Database выберите в качестве текущей БД SSEMDB. И. Б панели запросов введите SELECT * FROM Customer.

В панели инструментов щелкните Execute Query.

Обратите внимание, что пользователь Joe может просматривать все записи в таблице Customer. . ; . ..

13. Переключитесь в SQL Server Enterprise Manager.

14. В группе Database Role Membership пометьте флажок Db denydatareader и щелкните Apply.

Не закрывайте окно Database User Properties - Joe. Оно понадобится вам в следу-упражнении.

15. Переключитесь в SQL Query Analyzer.

16. В панели инструментов щелкните Execute Query, чтобы еще раз выполнить запрос SELECT * FROM Customer.

Заметьте: у пользователя Joe теперь нет разрешений на просмотр записей таблицы Customer. Возник конфликт разрешений - блокировка разрешения (DENY) приостанавливает действие всех предоставленнгх разрешений доступа.

17. Не закрывайте окна SQL Server Enterprise Manager и SQL Query Analyzer.

Управление разрешениями на выполнение операторов

Разрешения на выполнение операторов (statement permissions) - это разрешения на выполнение отдельнгх операторов Transact-SQL, используемгх для создания БД и их объектов, например таблиц, представлений и хранимых процедур. В табл. 11-3 перечислены разрешения доступа, связанные с этими операторами. Разрешения на выполнение каждого из этих операторов можно предоставить, отозвать или блокировать.

Табл Разрешения мненне операторов

Оператор Transact-SQL Разрешения на в1полнение оператора Transact-SQL

CREATE DATABASE Данные разрещения наследуются членами ролей сервера sysadmin и dbcreator. Хотя участники ролей sysadmin и securityadmin

могут предоставлять разрешения на выполнение этого оператора пользователям, расширенными разрешениями в рамках защиты данных, но в основном, разрешения все эти пользователи получают через роль сервера dbcreator, если системный администратор делегирует разрешения доступа. Эти разрещения доступа существуют только в БД master

Табл-1. (окончание)

Оператор Transact-SQL

Разрешения на выполнение оператора ansact-SQL

BACKUP DATABASE BACKUP LOG

CREATE TABLE

CREATE

CREATE PROCEDURE CREATE DEFAULT CREATE RULE

CREATE FUNCTION

CREATE TRIGGER

Данные разрешения наследуются членами роли сервера sysadmin, а также фиксированных ролей БД dbowner popera(or. Хотя вы можете предоставлять разрешения на выполнение этих операторов адьным пользователям, но главным образом, вы будете использовать для этого постоянную роль БД db backupoperator

Эти разрешения наследуются членами роли сервера sysadmin и фиксированных ролей БД db owneT и db ddladmin. В процессе разработки БД разрешения на создание даннгх объектов иногда предоставляются непосредственно программистам (либо группе программистов или соответхггвуюшей роли). По умолчанию объекты принадлежат их создателю (хотя объекты, созданные пользователями - участниками роли сервера dmin, принадлежат dbo). Пользователи, входящие в состав постоянных ролей wner iadmni, могут указывать роль dbo в качества мельпя создаваемгх ими объектов. К тому же члены роли сервера sysadmin или постоянной роли БД dbddladmin могут указать любого пользователя как владельца созданного ими объекта. Однако пользователи, не участниками ни одной из этих ролей, не могут

указывать другого пользователя ил ль dbo в качестве созданного ими объекта

Данные разрешения доступа наследуются в которой определен триггер, а также членами роли сервера sysadmin и фиксированных ролей БД db owner и db ddlad-min. Они не могут разрешения доступа на запуск

этого оператора другим учетным записям

Проблемы с созданием кгов, вызываемые цепочкой владельцев

Когда пользователь создает объект БД, например таблицу или представление, он становится владельцем этого объекта, пока другой пользователь, группа или рол i > будут определены в качестве владельца. Доступ пользователя к своим объектам может быть полезен ессе разработки БД, однако в процессе реальной эксплуатации БД могут возникнуть проблемы, и вам следует опасаться этого по нескольким причинам (об этом - далее). Полезно предоставить роли dbo разрешение адельца над всеми объектами производственной БД.

Когда пользователь обращается к какому-либо объекту в сценарии, в имени этого объекта может быть указано или не указано имя владельца. Если им ельца объекта не указано, SQL Server 2000 ищет в БД объект, принадлежащий пользователю, создавшему сценарий, или принадлежащий члену роли dbo, Если объект не принадлежит ни одному из этих двух пользователей, SQL Server 2000 возвращает сообщение об ошибке.

Следующий запрос выводит все данные таблицы Customer при условии, что таблица принадлежит либо роли dbo, либо пользователю, выполняющему сценарий:

SELECT * FROM Customer

Следующий запрос выводит данные таблицы Customer, принадлежащей Joe. Если в БД есть другая роли dbo, данные не выводятся.

Если в БД имеется несколько таблиц с одинаковыми именами, то при указании имени, отличного от dbo, може мкнуть ошибка.

SELECT FROM Joe.Customer . .

Представления и хранимые процедуры могут быть созданы в таблицах. Когда пользователь пытается выполнить запрос на выборку нужной информации через представление или процедуру, SQL Server 2000 должен проверить, имеет ли пользователь разрешение просматривать данные. Если представление или принадлежит одному пользователю, а базовая таблица - другому, тогда SQL Server 2000 должен проверить разрешения на каждый объект в цепочке. Поскольку цепочка владельцев удлиняется, это может повлиять на производительность системы. Однако более важным является тот факт, что проследить и отладить возможные конфликты разрешений доступа администратору будет совсем не просто.

Когда члены ролей БД db oWT:er и dbddladmin создают объекты БД, лучше указать роль dbo в качестве владельца создаваемхх объектов. Если владелец не будет явно указан, право собственности на этот объект по умолчанию будет предоставлено пользователю Windows или учетной записи SQL Server 2000, под именем которой создавался объект.

В следующем примере показано создание таблицы с предоставлением права собственности на эту таблицу роли dbo. Только члены роли сервера min и ролей БД db owner или dbddladmin имеют разрешение выполнять этот оператор:

CREATE TABLE Northwind.dbo,CustomerTable ( CustID nchar (5) , CustomerN&fne nvarchar (40) )

Смена владельца объекта

Если владельцем некоторого объекта БД является не dbo, вам может понадобиться изменить права собственности на этот объект. Члены ролей БД db owner, db ddladmin или db securityadmin, либо роли сервера sysadmin могут менять права собственности на любой объект БД при помощи системной хранимой процедуры sp changeobject-owner.

В следующем примере меняется владелец таблицы Customer. Вместо пользователя владельцем таблицы становится роль dbo:

sp changeob]ectowner SelfPacedSOL\Bill.Customer , dbo

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

Предоставление, блокирование и отзыв разрешений на выполнение операторов средствами SQL Server Enterprise Manager

SQL Server Enterprise Manager предоставляет простой графический интерфейс для

просмотра разрешений доступа на выполнение операторов, а также для