Перейти к оглавлению
22. КТО ЧТО МОЖЕТ ДЕЛАТЬ В БАЗЕ ДАННЫХ
В ЭТОЙ ГЛАВЕ, ВЫ ОБУЧИТЕСЬ РАБОТЕ С ПРИВИЛЕГИЯМИ. Как сказано в Гла-
ве 2, SQL используется обычно в средах, которые требуют распознавания
пользователей и различия между различными пользователями систем. Вооб-
ще говоря, администраторы баз данных, сами создают пользователей и да-
ют им привилегии. С другой стороны пользователи которые создают табли-
цы, сами имеют права на управление этими таблицами. Привилегии - это
то, что определяет, может ли указаный пользователь выполнить данную
команду. Имеется несколько типов привилегий, соответствующих несколь-
ким типам операций. Привилегии даются и отменяются двумя командами SQL
: - GRANT (ДОПУСК) и REVOKE (ОТМЕНА). Эта глава покажет вам как эти
команды используются.
============== ПОЛЬЗОВАТЕЛИ ===============
Каждый пользователь в среде SQL , имеет специальное идентификацион-
ное имя или номер. Терминология везде разная, но мы выбрали (следуя
ANSI) ссылку на имя или номер как на Идентификатор (ID) доступа. Ко-
манда, посланная в базе данных ассоциируется с определенным пользова-
телем; или иначе, специальным Идентификатором доступа. Посколько это
относится к SQL базе данных, ID разрешения - это имя пользователя, и
SQL может использовать специальное ключевое слово USER, которое ссыла-
ется к Идентификатору доступа связанному с текущей командой. Команда
интерпретируется и разрешается ( или запрещается ) на основе информа-
ции связанной с Идентификатором доступа пользователя подавшего коман-
ду.
РЕГИСТРАЦИЯ
В системах с многочислеными пользователями, имеется некоторый вид
процедуры входа в систему, которую пользователь должен выполнить чтобы
получить доступ к компьютерной системе. Эта процедура определяет какой
ID доступа будет связан с текущим пользователем. Обычно, каждый чело-
век использующий базу данных должен иметь свой собственный ID доступа
и при регистрации превращается в действительного пользователям. Одна-
ко, часто пользователи имеющие много задачь могут регистрироваться под
различными ID доступа, или наоборот один ID доступа может использо-
ваться несколькими пользователями.
С точки зрения SQL нет никакой разницы между этими двумя случаями;
он воспринимает пользователя просто как его ID доступа.
SQL база данных может использовать собственную процедуру входа в
систему, или она может позволить другой программе, типа операционной
системы ( основная программа которая работает на вашем компьютере ),
обрабатывать файл регистрации и получать ID доступа из этой программы.
Тем или другим способом, но SQL будет иметь ID доступа чтобы связать
его с вашими действиями, а для вас будет иметь значение ключевое слово
USER.
======== ПРЕДОСТАВЛЕНИЕ ПРИВИЛЕГИЙ =========
Каждый пользователь в SQL базе данных имеет набор привилегий. Это -
то что пользователю разрешается делать ( возможно это - файл регистра-
ции, который может рассматриваться как минимальная привилегия ). Эти
привилегии могут изменяться со временем - новые добавляться, старые
удаляться. Некоторые из этих привилегий определены в ANSI SQL, но име-
ются и дополнительные привилегии, которые являются также необходимыми.
SQL привилегии как определено ANSI, не достаточны в большинстве ситуа-
ций реальной жизни. С другой стороны, типы привилегий, которые необхо-
димы, могут видоизменяться с видом системы которую вы используете -
относительно которой ANSI не может дать никаких рекомендаций. Привиле-
гии которые не являются частью стандарта SQL могут использовать похо-
жий синтаксис и не полностью совпадающий со стандартом.
СТАНДАРТНЫЕ ПРИВИЛЕГИИ
SQL привилегии определенные ANSI - это привелегии объекта. Это озна-
чает что пользователь имеет привилегию чтобы выполнить данную команду
только на определенном объекте в базе данных. Очевидно, что привилегии
должны различать эти объекты, но система привилегии основанная исклю-
чительно на привилегиях объекта не может адресовывать все что нужно
SQL, как мы увидем это позже в этой главе. Привилегии объекта связаны
одновременно и с пользователями и с таблицами. То есть, привилегия да-
ется определенному пользователю в указаной таблице, или базовой табли-
це или представлении. Вы должны помнить, что пользователь создавший
таблицу (любого вида), является владельцем этой таблицы.
Это означает, что пользователь имеет все привилегии в этой таблице и
может передавать привелегии другим пользователям в этой таблице. При-
вилегии которые можно назначить пользователю:
SELECT Пользователь с этой привилегией может выполнять
запросы в таблице.
INSERT Пользователь с этой привилегией может выполнять
команду INSERT в таблице.
UPDATE Пользователь с этой привилегией может выполнять
команду UPDATE на таблице. Вы можете ограничить эту
привилегию для определенных столбцов таблицы.
DELETE Пользователь с этой привилегией может выполнять
команду DELETE в таблице.
REFERENCES Пользователь с этой привилегией может определить
внешний ключ, который использует один или более
столбцов этой таблицы, как родительский ключ. Вы можете
ограничить эту привилегию для определенных столбцов.
(Смотрите Главу 19 для подробностей относительно внешнего
ключа и родительского ключа.)
Кроме того, вы столкнетесь с нестандартными привилегиями объекта,
такими например как INDEX (ИНДЕКС) дающим право создавать индекс в
таблице, SYNONYM (СИНОНИМ) дающим право создавать синоним для объекта,
который будет объяснен в Главе 23, и ALTER (ИЗМЕНИТЬ) дающим право вы-
полнять команду ALTER TABLE в таблице. Механизм SQL назначает пользо-
вателям эти привилегии с помощью команды GRANT.
КОМАНДА GRANT
Позвольте предположить, что пользователь Diane имеет таблицу Заказ-
чиков и хочет позволить пользователю Adrian выполнить запрос к ней.
Diane должна в этом случае ввести следующую команду:
GRANT INSERT ON Salespeople TO Diane;
Теперь Adrian может выполнить запросы к таблице Заказчиков. Без дру-
гих привилегий, он может только выбрать значения; но не может выпол-
нить любое действие, которые бы воздействовало на значения в таблице
Заказчиков ( включая использование таблицы Заказчиков в качестве роди-
тельской таблицы внешнего ключа, что ограничивает изменения которые
выполнять со значениям в таблице Заказчиков). Когда SQL получает ко-
манду GRANT, он проверяет привилегии пользователя подавшего эту коман-
ду, чтобы определить допустима ли команда GRANT.
Adrian самостоятельно не может выдать эту команду. Он также не может
предоставить право SELECT другому пользователю: таблица еще принадле-
жит Diane ( позже мы покажем как Diane может дать право Adrian предос-
тавлять SELECT другим пользователям). Синтаксис - тот же самый, что и
для предоставления других привилегий. Если Adrian - владелец таблицы
Продавцов, то он может позволить Diane вводить в нее строки с помощью
следующего предложения
GRANT INSERT ON Salespeople TO Diane;
Теперь Diane имеет право помещать нового продавца в таблицу.
ГРУППЫ ПРИВЕЛЕГИЙ, ГРУППЫ ПОЛЬЗОВАТЕЛЕЙ
Вы не должны ограничивать себя предоставлением одиночной привилегии
отдельному пользователю командой GRANT. Списки привилегий или пользо-
вателей, отделяемых запятыми, являются совершенно приемлемыми. Stephen
может предоставить и SELECT и INSERT в таблице Порядков для Adrian
GRANT SELECT, INSERT ON Orders TO Adrian;
или и для Adrian и для Diane
GRANT SELECT, INSERT ON Orders TO Adrian, Diane;
Когда привилегии и пользователи перечислены таким образом, весь спи-
сок привилегий предоставляются всем указанным пользователям. В строгой
ANSI интерпретации, вы не можете предоставить привилегии во многих
таблицах сразу одной командой, но в некоторых реализациях это ограни-
чение может быть ослаблено, позволяя вам указывать несколько таблиц,
отделяя их запятыми, так что бы весь список привелегий мог быть пре-
доставлен для всех указанных таблиц.
ОГРАНИЧЕНИЕ ПРИВИЛЕГИЙ НА ОПРЕДЕЛЕННЫЕ СТОЛБЦЫ
Все привилегии объекта используют один тот же синтаксис, кроме ко-
манд UPDATE и REGERNCES в которых необязательно указывать имена столб-
цов. Привилегию UPDATE можно предоставлять на подобии других привиле-
гий:
GRANT UPDATE ON Salespeople TO Diane;
Эта команда позволит Diane изменять значения в любом или во всех
столбцах таблицы Продавцов. Однако, если Adrian хочет ограничить Diane
в изменении например комиссионных, он может ввести
GRANT UPDATE (comm) ON Salespeople TO Diane;
Другими словами, он просто должен указать конкретный столбец к кото-
рому привилегия UPDATE должна быть применена, в круглых скобках после
имени таблицы. Имена многочисленых столбцов таблицы могут указываться
в любом порядке, отделяемые запятыми:
GRANT UPDATE (city, comm) ON Salespeople TO Diane;
REFERENCES следует тому же самому правилу. Когда вы предоставите
привилегию REFERENCES другому пользователю, он сможет создавать внеш-
ние ключи ссылающиеся на столбцы вашей таблицы как на родительские
ключи. Подобно UPDATE, для привилегии REFERENCES может быть указан
список из одного или более столбцов для которых ограничена эта приви-
легия. Например, Diane может предоставить Stephen право использовать
таблицу Заказчиков, как таблицу родительского ключа, с помощью такой
команды:
GRANT REFERENCES (cname, cnum)
ON Customers TO Stephen;
Эта команда дает Stephen право использовать столбцы cnum и cname, в
качестве родительских ключей по отношению к любым внешним ключам в его
таблицах. Stephen может контролировать то как это будет выполнено. Он
может определить (cname, cnum) или, как в нашем случае( cnum, cname),
как двух-столбцовый родительский ключ, совпадающий с помощью внешнего
ключа с двумя столбцами в одной из его собственных таблиц. Или он мо-
жет создать раздельные внешние ключи чтобы ссылаться на поля индивиду-
ально, обеспечив тем самым чтобы Diane имела принудительное присвоение
родительского ключа (см. Главу 19 ).
Не имея ограничений на номера внешних ключей он должден базироваться
на этих родительских ключах, а родительские ключи различных внешних
ключей - разрешены для совмещения(overlap).
Как и в случае с привилегией UPDATE, вы можете исключить список
столбцов и таким образом позволять всем без исключения столбцам быть
используемыми в качестве родительских ключей. Adrian может предоста-
вить Diane право сделать это следующей командой:
GRANT REFERENCES ON Salespeople TO Diane;
Естественно, привилегия будет пригодна для использования только в
столбцах, которые имеют ограничения требуемые для родительских ключей.
ИСПОЛЬЗОВАНИЕ АРГУМЕНТОВ ALL И PUBLIC
SQL поддерживает два аргумента для команды GRANT, которые имеют спе-
циальное значение: ALL PRIVILEGES (ВСЕ ПРИВИЛЕГИИ) или просто ALL и
PUBLIC (ОБЩИЕ). ALL используется вместо имен привилегий в команде
GRANT чтобы отдать все привилегии в таблице. Например, Diane может
дать Stephen весь набор привилегий в таблице Заказчиков с помощью та-
кой команды:
GRANT REFERENCES ON Salespeople TO Diane;
(привилегии UPDATE и REFERENCES естественно применяются ко всем столб-
цам.) А это другой способ высказать ту же мысль:
GRANT ALL ON Customers TO Stephen;
PUBLIC - больше похож на тип аргумента - захватить все (catch-all),
чем на пользовательскую привилегию. Когда вы предоставляете привилегии
для публикации, все пользователи автоматически их получают. Наиболее
часто, это применяется для привилегии SELECT в определенных базовых
таблицах или представлениях которые вы хотите сделать доступными для
любого пользователя. Чтобы позволить любому пользователю видеть табли-
цу Порядков, вы, например, можете ввести следующее:
GRANT SELECT ON Orders TO PUBLIC;
Конечно, вы можете предоставить любые или все привилегии обществу,
но это видимо нежелательно. Все привилегии за исключением SELECT поз-
воляют пользователю изменять ( или, в случае REFERENCES, ограничивать)
содержание таблицы. Разрешение всем пользователям изменять содержание
ваших таблиц вызовет проблему. Даже если вы имеете небольшую компанию,
и в ней работают все ваши текущие пользователи способные выполнять ко-
манды модификации в данной таблице, было бы лучше предоставить приви-
легии каждому пользователю индивидуально, чем одни и те же привелегии
для всех. PUBLIC не ограничен в его передаче только текущим пользова-
телям. Любой новый пользователь добавляемый к вашей системе, автомати-
чески получит все привилегии назначенные ранее всем, так что если вы
захотите ограничить доступ к таблице всем, сейчас или в будущем, лучше
всего предоставить привилегии иные чем SELECT для индивидуальных поль-
зователей.
ПРЕДОСТАВЛЕНИЕ ПРИВЕЛЕГИЙ С ПОМОЩЬЮ WITH GRANT OPTION
Иногда, создателю таблицы хочется чтобы другие пользователи могли
получить привилегии в его таблице. Обычно это делается в системах, где
один или более людей создают несколько (или все) базовые таблицы в ба-
зе данных а затем передают ответственность за них тем кто будет факти-
чески с ними работать. SQL позволяет делать это с помощью предложения
WITH GRANT OPTION. Если Diane хотела бы чтобы Adrian имел право пре-
доставлять привилегию SELECT в таблице Заказчиков другим пользовате-
лям, она дала бы ему привилегию SELECT с использованием предложения
WITH GRANT OPTION:
GRANT SELECT ON Customers TO Adrian
WITH GRANT OPTION;
После того Adrian получил право передавать привилегию SELECT третьим
лицам; он может выдать команду
GRANT SELECT ON Diane.Customers TO Stephen;
или даже
GRANT SELECT ON Diane.Customers TO Stephen
WITH GRANT OPTION;
Пользователь с помощью GRANT OPTION в особой привилегии для данной
таблицы, может, в свою очередь, предоставить эту привилегию к той же
таблице, с или без GRANT OPTION, любому другому пользователю. Это не
меняет принадлежности самой таблицы; как и прежде таблица принадлежат
ее создателю. ( поэтому пользователи получившие права, должны устанав-
ливать префикс ID доступа владельца когда ссылаются к этим таблицам.
Следующая глава покажет вам этот способ. ) Пользователь же с помощью
GRANT OPTION во всех привилегиях для данной таблицы будет иметь всю
полноту власти в той таблице.
ОТМЕНА ПРИВИЛЕГИЙ
Также как ANSI предоставляет команду CREATE TABLE чтобы создать таб-
лицу, а не DROP TABLE чтобы от нее избавиться, так и команда GRANT
позволяет вам давать привилегии пользователям, не предоставляя способа
чтобы отобрать их обратно. Потребность удалять привилегии сводится к
команде REVOKE, фактически стандартному средству с достаточно понятной
формой записи. Синтаксис команды REVOKE - похож на GRANT, но имеет об-
ратный смысл. Чтобы удалить привилегию INSERT для Adrian в таблице По-
рядков, вы можете ввести
REVOKE INSERT ON Orders FROM Adrian;
Использование списков привилегий и пользователей здесь допустимы как и
в случае с GRANT, так что вы можете ввести следующую команду:
REVOKE INSERT, DELETE ON Customers
FROM Adrian, Stephen;
Однако, здесь имеется некоторая неясность. Кто имеет право отменять
привилегии? Когда пользователь с правом передавать привелегии другим,
теряет это право? Пользователи которым он предоставил эти привилегии,
также их потеряют ? Так как это не стандартная особенность, нет ника-
ких авторитетных ответов на эти вопросы, но наиболее общий подход -
это такой: * Привилегии отменяются пользователем который их предоста-
вил, и отмена будетт каскадироваться, то-есть она будет автоматически
распространяться на всех пользователям получивших от него эту привиле-
гию.
ИСПОЛЬЗОВАНИЕ ПРЕДСТАВЛЕНИЙ ДЛЯ ФИЛЬТРАЦИИ ПРИВЕЛЕГИЙ
Вы можете сделать действия привилегий более точными, используя
представления. Всякий раз, когда вы передаете привилегию в базовой
таблице пользователю, она автоматически распространяется на все стро-
ки, а при использовании возможных исключений UPDATE и REFERENCES, на
все столбцы таблицы. Создавая представление которое ссылается на ос-
новную таблицу и затем переносит привилегию на представление, а не на
таблицу, вы можете ограничивать эти привилегии любыми выражениями в
запросе содержащимся в представлении. Это значительно улучшает базис-
ные возможности команды GRANT.
КТО МОЖЕТ СОЗДАВАТЬ ПРЕДСТАВЛЕНИЯ?
Чтобы создавать представление, вы должны иметь привилегию SELECT во
всех таблицах на которые вы ссылаетесь в представлении. Если представ-
ление - модифицируемое, любая привелегия INSERT, UPDATE, и DELETE ко-
торые вы имеете в базовой таблице, будут автоматически передаваться
представлению. Если вы испытываете недостаток в привилегиях на модифи-
кацию в базовых таблицах, вы не сможете иметь их и в представлениях
которые создали, даже если сами эти представления - модифицируемые.
Так как внешние ключи не используются в представлениях, привилегия RE-
FERENCES никогда не используется при создании представлений. Все эти
ограничения - определяются ANSI. Нестандартные привилегии системы (
обсуждаемые позже в этой главе ) также могут быть включены. В последу-
ющих разделах мы предположим, что создатели представлений которые мы
обсуждаем, имеют частные или соответствующие привилегии во всех базо-
вых таблицах.
ОГРАНИЧЕНИЕ ПРИВИЛЕГИИ SELECT ДЛЯ ОПРЕДЕЛЕННЫХ СТОЛБЦОВ
Предположим вы хотите дать пользователю Claire способность видеть
только столбцы snum и sname таблицы Продавцов. Вы можете сделать это,
поместив имена этих столбцов в представление
CREATE VIEW Clairesview
AS SELECT snum, sname
FROM Salespeople;
и предоставить Claire привилегию SELECT в представлении, а не в самой
таблице Продавцов:
GRANT SELECT On Clairesview to Claire;
Вы можете создать привилегии специально для столбцов наподобии ис-
пользования других привилегий, но, для команды INSERT, это будет озна-
чать вставку значений по умолчанию, а для команды DELETE, ограничение
столбца не будет иметь значения. Привелегии REFERENCES и UPDATE, ко-
нечно, могут сделать столбцы специфическими не прибегая к представле-
нию.
ОГРАНИЧЕНИЕ ПРИВЕЛЕГИЙ ДЛЯ ОПРЕДЕЛЕННЫХ СТРОК
Обычно, более полезный способ чтобы фильтровать привилегии с предс-
тавлениями - это использовать представление чтобы привилегия относи-
лась только к определенным строкам. Вы делаете это, естественно, ис-
пользуя предикат в представлении который определит, какие строки явля-
ются включенными. Чтобы предоставить пользователю Adrian, привилегию
UPDATE в таблице Заказчиков, для всех заказчиков размещенных в Лондо-
не, вы можете создать такое представление:
CREATE VIEW Londoncust
AS SELECT *
FROM Customers
WHERE city = 'London'
WITH CHECK OPTION;
Затем Вы должны передать привилегию UPDATE в этой таблице для Adrian:
GRANT UPDATE ON Londoncust TO Adrian;
В этом отличие привилегии для определенных строк от привилегии UPDATE
для определенных столбцов, которая распространена на все столбцы таб-
лицы Заказчиков, но не на строки, среди которых строки со значением
поля city иным чем London не будут учитываться. Предложение WITH CHECK
OPTION предохраняет Adrian от замены значения поля city на любое зна-
чение кроме London.
ПРЕДОСТАВЛЕНИЕ ДОСТУПА ТОЛЬКО К ИЗВЛЕЧЕННЫМ ДАННЫМ
Другая возможность состоит в том, чтобы предлагать пользователям
доступ к уже извлеченным данным, а не к фактическим значениям в табли-
це. Агрегатные функции, могут быть весьма удобными в применении такого
способа. Вы можете создавать представление которое дает счет, среднее,
и общее количество для порядков на каждый день порядка:
CREATE VIEW Datetotals
AS SELECT odate, COUNT (*), SUM (amt), AVG (amt)
FROM Orders
GROUP BY odate;
Теперь вы передаете пользователю Diane - привелегию SELECT в представ-
лении Datetotals:
GRANT SELECT ON Datetotals TO Diane;
ИСПОЛЬЗОВАНИЕ ПРЕДСТАВЛЕНИЙ В КАЧЕСТВЕ АЛЬТЕРНАТИВЫ К ОГРАНИЧЕНИЯМ
Одной из последних прикладных программ из серии, описанной в Главе
18, является использование представлений с WITH CHECK OPTION как аль-
тернативы к ограничениям. Предположим что вы хотели удостовериться,
что все значения поля city в таблице Продавцов находятся в одном из
городов где ваша компания в настоящее время имеет ведомство. Вы можете
установить ограничение CHECK непосредственно на столбец city, но позже
может стать трудно его изменить, если ваша компания например откроет
там другие ведомства. В качестве альтернативы, можно создать представ-
ление, которое исключает неправильные значения city:
CREATE VIEW Curcities
AS SELECT *
FROM Salespeople
WHERE city IN ('London', 'Rome', 'San Jose', 'Berlin')
WITH CHECK OPTION;
Теперь, вместо того, чтобы предоставить пользователям привилегии мо-
дифицирования в таблице Продавцов, вы можете предоставить их в предс-
тавлении Curcities. Преимущество такого подхода - в том, что если вам
нужно сделать изменение, вы можете удалить это представление, создать
новое, и предоставить в этом новом представлении привилегии пользова-
телям, что проще чем изменять ограничения. Недостатком является то,
что владелец таблицы Продавцов также должен использовать это представ-
ление если он не хочет чтобы его собственные команды были отклонены. С
другой стороны, этот подход позволяет владельцу таблицы и любым другим
получить привилегии модификации в самой таблице, а не в представлении,
чтобы делать исключения для ограничений.
Это часто бывает желательно, но не выполнимо, если вы используете
ограничения в базовой таблице. К сожалению, эти исключения нельзя бу-
дет увидеть в представлении. Если вы выберите этот подход, вам захо-
чется создать второе представление, содержащее только исключения:
CREATE VIEW Othercities
AS SELECT *
FROM Salespeople
WHERE city NOT IN ('London', 'Rome', 'San Jose',
'Berlin')
WITH CHECK OPTION;
Вы должны выбрать для передачи пользователям только привилегию SE-
LECT в этом представлении, чтобы они могли видеть исключенные строки,
но не могли помещать недопустимые значения city в базовую таблицу.
Фактически, пользователи могли бы сделать запрос обоих представлений в
объединении и увидеть все строки сразу.
========= ДРУГИЕ ТИПЫ ПРИВИЛЕГИЙ ===========
Вы разумеется хотите знать, кто же имеет право первым создать табли-
цу. Эта область привилегии не относится к ANSI, но не может игнориро-
ваться. Все стандартные привилегии ANSI вытекают из этой привилегии;
привилегии создателей таблиц которые могут передавать привилегии объ-
екта. Если все ваши пользователи будут создавать в системе базовые
таблицы с разными размерами это приведет к избыточности в них и к не-
эффетивности системы. Притягивают к себе и другие вопросы:
- Кто имеет право изменять, удалять, или ограничивать таблицы?
- Должны ли права создания базовых таблиц отличаться от прав создания
представлений?
- Должен ли быть суперпользователь - пользователь который отвечает за
поддержание базы данных и следовательно имеющий наибольшие, или все
привилегии, которые не предоставляются индивидуально?
Пока ANSI не принимает в этом участие, а SQL используется в различ-
ных средах, мы не можем дать окончательный ответ на эти вопросы. Мы
предлагаем рассмотреть здесь кусок наиболее общих выводов.
Привилегии которые не определяются в терминах специальных объектов
данных называются - привилегиями системы, или правами базы данных. На
базисном уровне, они будут вероятно включать в себя право создавать
объекты данных, вероятно отличающиеся от базовых таблиц( обычно созда-
ваемыми несколькими пользователями ) и представления ( обычно создава-
емые большинством пользователей). Привилегии системы для создания
представлений, должны дополнять, а не заменять привилегии объекта ко-
торые ANSI требует от создателей представлений ( описанных ранее в
этой главе ). Кроме того, в системе любого размера всегда имеются не-
которые типы суперпользователей - пользователей которые автоматически
имеют большинство или все привилегии - и которые могут передать свой
статус суперпользователя кому-нибудь с помощью привилегии или группы
привилегий. Администратор Базы Данных, или DBA, является термином наи-
более часто используемым для такого суперпользователя, и для привиле-
гий которыми он обладает.
ТИПИЧНЫЕ ПРИВИЛЕГИИ СИСТЕМЫ
При общем подходе имеется три базовых привилегии системы:
- CONNECT (Подключить),
- RESOURCE (Ресурс), и
- DBA (Аминистратор Базы Данных).
Проще, можно сказать, что CONNECT состоит из права зарегистрировать-
ся и права создавать представления и синонимы(см. Главу 23), если пе-
реданы привилегии объекта. RESOURCE состоит из права создавать базовые
таблицы. DBA - это привилегия суперпользователя, дающая пользователю
высокие полномочия в базе данных. Один или более пользователей с функ-
циями администратора базы данных может иметь эту привилегию. Некоторые
системы кроме того имеют специального пользователя, иногда называемого
SYSADM или SYS (Системный Администратор Базы Данных), который имеет
наивысшие полномочия; это - специальное имя, а не просто пользователь
со специальной DBA привилегией. Фактически только один человек имеет
право зарегистрироваться с именем SYSADM, являющимся его идентификато-
ром доступа. Различие весьма тонкое и функционирует по разному в раз-
личных системах. Для наших целей, мы будем ссылаться на высокопривиле-
гированного пользователя, который разрабатывает и управляет базой дан-
ных имея полномочия DBA, понимая что фактически эти полномочия - та же
самая привилегия. Команда GRANT, в измененной форме, является пригод-
ной для использования с привилегиями объекта как и с системными приви-
легиями. Для начала передача прав может быть сделана с помощью DBA.
Например, DBA может передать привилегию для создания таблицы пользова-
телю Rodriguez следующим образом:
GRANT RESOURCE TO Rodriguez;
СОЗДАНИЕ И УДАЛЕНИЕ ПОЛЬЗОВАТЕЛЕЙ
Естественно появляется вопрос, откуда возьмется пользователь с име-
нем Rodriguez ? Как определить его ID допуска ? В большинстве реализа-
ций, DBA создает пользователя, автоматически предоставляя ему привиле-
гию CONNECT. В этом случае, обычно добавляется предложение IDENTIFIED
BY, указывающее пароль. ( Если же нет, операционная система должна оп-
ределить, можете ли вы зарегистрироваться в базе данных с данным ID
доступа. ) DBA может, например, ввести
GRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon;
что приведет к созданию пользователя, с именем Thelonius, даст ему
право регистрироваться, и назначит ему пароль Redwagon, и все это в
одном предложении.
Раз Thelonious - уже опознаный пользователь, он или DBA могут ис-
пользовать эту же команду чтобы изменить пароль Redwagon. Хотя это и
удобно, но все же имеются ограничения и в этом подходе. Это невозмож-
ность иметь пользователя который не мог бы зарегистрироваться, хотя бы
временно. Если вы хотите запретить пользователю регистрироваться, вы
должны использовать для REVOKE привилегию CONNECT, которая "удаляет"
этого пользователя. Некоторые реализации позволяють вам создавать и
удалять пользователей, независимо от их привилегий при регистрации.
Когда вы предоставляете привилегию CONNECT пользователю, вы создаете
этого пользователя. При этом чтобы сделать это Вы сами, должны иметь
DBA привилегию. Если этот пользователь будет создавать базовые таблицы
( а не только представления ), ему нужно также предоставить привилегию
RESOURCE. Но это сразу порождает другую проблему.
Если вы сделаете попытку удалить привилегию CONNECT пользователя,
который имеет им созданые таблицы, команда будет отклонена, потому что
ее действие оставит таблицу без владельца, а это не позволяется. Вы
должны сначала удалить все таблицы созданные этим пользователем, преж-
де чем удалить его привилегию CONNECT . Если эти таблицы не пустые, то
вы вероятно захотите передать их данные в другие таблицы с помощью ко-
манды INSERT, которая использует запрос. Вам не нужно удалять отдельно
привилегию RESOURSE; достаточно удалить CONNECT чтобы удалить пользо-
вателя. Хотя все выше сказаное - это вполне стандартный подход к при-
вилегиям системы, он также имеет значительные ограничения. Появились
альтернативные подходы, которые более конкретно определены и точнее
управляют привилегиями системы.
Эти выводы несколько выводят нас за пределы стандарта SQL как это
определено в настоящее время, и, в некоторых реализациях, могут пол-
ностью выйти за пределы стандарта SQL. Эти вещи вероятно не будут
слишком вас касаться, если вы не DBA или не пользователь высокого
уровня. Обычные пользователи просто должны быть знакомыми с привилеги-
ями системы в принципе, справляясь со своей документации только в слу-
чае специальных сообщений.
================ РЕЗЮМЕ ===============
Привилегии дают вам возможность видеть SQL под новым углом зрения,
когда SQL выполняет действия через специальных пользователей в специ-
альной системе базы данных. Сама команда GRANT достаточно проста: с ее
помощью, вы предоставляете те или иные привилегии объекта одному или
более пользователям. Если вы предоставляете привилегию WITH GRANT OP-
TION пользователю, этот пользователь может в свою очередь предоставить
эту привилегию другим. Теперь вы понимаете намеки на использование
привилегий в представлениях - чтобы усовершенствовать привилегии в ба-
зовых таблицах, или как альтернативы к ограничениям - и на некоторые
преимущества и недостатки такого подхода. Привилегии системы, которые
необходимы, но не входят в область стандарта SQL, обсуждались в их на-
иболее общей форме и поэтому вы будете знакомиться с ними на практике.
Глава 23 продолжит обсуждение о выводах в SQL, таких как сохранение
или восстановление изменений, создание ваших собственных имен для таб-
лиц принадлежащих другим людям, и понимание что происходит когда раз-
личные пользователи пытаются обращаться к одному и тому же объекту од-
новременно.
************** РАБОТА С SQL **************
1. Передайте Janet право на изменение оценки заказчика.
2. Передайте Stephan право передавать другим пользователям право де-
лать запросы в таблице Порядков.
3. Отнимите привилегию INSERT( ВСТАВКА) в таблице Продавцов у Claire и
у всех пользователей которым она была предоставлена.
4. Передайте Jerry право вставлять или модифицировать таблицу Заказчи-
ков с сохранением его возможности оценивать значения в диапазоне от
100 до 500.
5. Рарешите Janet делать запросы в таблице Заказчиков, но запретите
ему уменьшать оценки в той же таблице Заказчиков.
( См. Приложение A для ответов. )
Перейти к оглавлению
