Добро пожаловать!
Здесь вы можете найти ответ на интересующий вас вопрос в отрасли сайтостроения, познакомится ближе с web технологиями и web стандартами.

SQL

Глава 22. Организация доступа к базе данных *

В этой главе вы узнаете о привилегиях. SQL используется главным образом в такой среде, где требуется распознавать и дифференцировать пользователей системы. Администраторы баз данных создают других пользователей и назначают им привелегии. Пользователи, создающие таблицы, автоматически получают контроль над этими таблицами. Привилегии (privileges) определяют, может ли отдельный пользователь выполнять данную операцию. Типы привелегий соответствуют нескольким типам операций. Назначение и отмену привилегий обеспечивают два оператора SQL - GRANT и REVOKE, которые ма и рассмотрим в этой главе.

Пользователи и привилегии

Пользователи и привилегии в среде SQL упоминались с в главе 1. Рассмотрим эту тему более подробно. Повторим и уточним то, о чем уже было сказано:

  • Формальным именем пользователя базы данных является идентификатор авторизации (Authorization ID).
  • В концептуальном плане пользователи бызы данных похожи на пользователей операционной системы (ОС). Они имеют имя, ассоциированное с определенным набором привелегий, набором объектов и множеством сеансов базы данных.
  • Между пользователем базы данных и пльзователем ОС не обязательно должно быть взаимно однозначное ссответствие, как и между любым из этих пользователей и реальным человеком.
  • Все объекты, подконтрольные отдельному пользователю, входят в схему этого пользователя. В общем случае эти объекты должны быть связаны. Таким образом, пользователи базы данных часто сопоставляются с данными, а не с людьми, использующими эти данные. Пользователь базы данных является владельцем определенного набора связанных между собой объектов базы данных. Все приложения, использующие эти объекты, обычно соединяются с базой данных под именем этого пользователя, независимо от того, кто работает с приложением. В частности, такой подход используется на Web-сайтах с интерфейсом к базе данных, где не всегда известно, кто запускает приложение, и по этой причине создание уникального пользователя для каждого посетителя сайта лишено смысла.
  • Пользователи базы данных идентифицируются с помощью процедуры входа, обычно включающей ввод имени пользователя и пароля. В приложениях это часто выполняется незаметно для конечного пользователя.
  • После входа пользователь инициирует сеанс (session) связи с СУБД, называемый также соединением (connection). Этот сеанс продолжается вплоть до завершения работы. Во время сеанса пользователь выдает последовательность команд. Команды из одновременных сеансов одного или разных пользователей образуют независимые последовательности.
  • Так же, как пользователи ОС владеют некоторым набором файлов и каталогов и могут получить доступ к другим ресурсам, пользователи базы данных обычно владеют одной схемой и при этом могут обращаться к другим схемам. Пользователю базы данных может принадлежать одна или несколько схем. Приложение, которое должно иметь доступ к схеме, частоо действует под видом этого пользователя базы данных независимо от того, каким пользователем ОС оно было запущено. Это существенно упрощает работу.
  • Иногда приложения могут выполняться с привилегиями, ассоуиированным с самим приложением, а не с пользователем, запустившим его.

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

Регистрация

В системах с многочисленными пользователями имеется некоторый вид процедуры входа в систему, которую пользователь должен выполнить, чтобы получить доступ к компьютерной системе. Эта процедура определяет, какой 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) является владельцем таблицы Customers и хочет разрешить Адриану (Adrian) выполнение запросов к этой таблице. Для этого она может ввести следующий оператор: 

GRANT SELECT ON Salespeople TO Adrian;

Теперь Adrian может выполнить запросы к таблице Customers. Без других привилегий ему доступен только оператор SELECT, и он не может выполнять никаких действий, влияющих на значения в таблице Customers (включая использование этой таблицы в качестве родительской для внешнего ключа, поскольку это ограничивает изменения, которые могут выполняться к таблице Customers.

Когда СУБД получает команду GRANT, она проверяет привилегии пользователя, выдавшего ее, чтобы определить, разрешена ли ему эта команда. Сам Адриан не может ввести такую команду. Он также не может предоставить привилегию SELECT другому пользователю, поскольку таблица по-прежнему принадлежит Диане (как Диана может разрешить Адриану предоставление привилегии SELECT, см. ниже).

При назначении других привилегий синтаксис остается прежним. Если Адриану принадлежит таблица Salepeople, он может разрешить Диане вводить в нее строки: 

GRANT INSERT ON Salespeople TO Diane;

Теперь Диана может поместить в таблицу нового продавца.

В одном операторе GRANT необязательно назначать только одну привилегию единственному пользователю. Допустимо перечислять или привилегии через запятую. Стефан (Stephen) может назначить привилегии SELECT и INSERT для таблицы Orders либо Адриану: 

GRANT SELECT, INSERT ON Orders TO Adrian;

либо Адриану и Диане: 

GRANT SELECT, INSERT ON Orders TO Adrian, Diane;

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

Ограничение табличных привилегий определенными столбцами

Большинство объектных привилегий используют одинаковый синтаксис. Исключение составляют UPDATE, INDEX и REFERENCES, для которых можно дополнительно указывать столбцы. Вы можете назначить привилегию UPDATE аналогично любой другой привилегии: 

GRANT UPDATE ON Salespeople TO Diane;

Этот оператор позволит Диане изменять значения в любом или во всех столбцах таблицы Salespeople. Но если Адриану нужно, чтобы она изменяла только комиссионные, он может ввести 

GRANT UPDATE (comm) ON Salespeople TO Diane;

В скобках после имени привилегии указан столбец, к которому применяется эта привилегия. Можно указывать несколько столбцов таблицы в любом порядке, разделяя их запятыми: 

GRANT UPDATE (city, comm) ON Salespeople TO Diane;

Привилегия REFERENCES следует тому же шаблону. Получив от вас эту привилегию, другой пользователь может создавать внешние ключи, которые ссылаются на родительские ключи вашей таблицы. Как и UPDATE, привилегия REFERENCES может ограничиваться одним или несколькими столбцами. Например, Диана может предоставить Стефану право использовать таблицу Customers в качестве таблицы с родительскими ключами, введя оператор 

GRANT REFERENCES (cname, cnum) ON Customers TO Stephen;

Этот оператор позволяет Стефану использовать любой из столбцов cnum и cname (или оба столбца) в качестве родительского ключа для любых внешних ключей своей таблицы. Ему следует использовать cnum, поскольку это первичный ключ. Но в принципе он может определить родительский ключ из двух столбцов (cname, cnum), соответствующий внешнему ключу своей таблицы, также состоящему из двух столбцов. Кроме того, он может создать раздельные внешние ключи, чтобы ссылаться на каждый из столбцов в отдельности. В любом случае, Диана должна указать для родительского ключа (или ключей) ограничение UNIQUE или PRIMARY KEY. Количество внешних ключей, которые могут быть основаны на этих родительских ключах, не ограничено, а родительские ключи различных внешних ключей могут перекрываться.

Как и для привилегии UPDATE, вы можете опустить список столбцов т и тем самым разрешить использование всех столбцов своей таблицы в качестве родительских ключей. Адриан мог бы предоставить Диане право использовать все столбцы таблицы Salespeople с помощью следующего оператора: 

GRANT REFERENCES ON Salespeople TO Diane;

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

Привилегия INDEX позволяет создавать индекс. Индекс - это объект базы данных, который нужен главным образом для повышения производительности. Однако некоторые индексы могут действовать как ограничения UNIQUE и тем самым сужать диапазон возможных значений столбцов. По этой причине для их использования требуется наличие привилегии. Синтаксис привилегии INDEX в целом аналогичен синтаксису для REFERENCES, но поскольку индексы не входят в стандарт SQL, возможны небольшие отличия.

Использование аргументов ALL и PUBLIC

Оператор GRANT может иметь аргументы со специальным значением: ALL PRIVILEGES (или просто ALL) и PUBLIC. Аргумент ALL обозначает все привилегии, которые можно предоставить пользователю для данной таблицы. Например, с помощью такого оператора Диана может предоставить Стефану весь набор привилегий для таблицы Customers: 

GRANT ALL PRIVILEGES ON Customers TO Stephen;

(Привилегии UPDATE, INDEX и REFERENCES, назначенные в составе ALL PRIVILEGES, применяются ко всем столбцам.) То же самое можно записать альтернативным способом: 

GRANT ALL ON Customers TO Stephen;

Аргумент PUBLIC действует аналогично ALL, но обозначает пользователей, а не привилегии. Когда вы предоставляете привилегии "всем", их автоматически получает каждый пользователь. Чаще всего этот аргумент используется с привилегией SELECT для тех базовых таблиц или представлений, которые должны быть доступны для всеобщего обозрения. Чтобы разрешить просмотр таблицы Orders любому пользователю, вы можете ввести следующий оператор: 

GRANT SELECT ON Orders TO PUBLIC;

Таким образом можно предоставить любые (или все) привилегии, но это обычно не рекомендуется. Все привилегии, за исключением SELECT и INDEX, позволяют изменять (или - в случае REFERENCES - ограничивать) содержимое таблицы. Разрешая это всем пользователям, вы провоцируете возникновение проблем. Даже если у вас маленькая компания и обновление содержимого данной таблицы можно доверить любому из текущих пользователей, лучше назначить привилегии каждому из них в отдельности. PUBLIC Подразумевает не только текущих пользователей. Любой новый пользователь, добавленный в систему, автоматически получит все привилегии, присвоенные с помощью 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 во всех привилегиях для данной таблицы будет иметь всю полноту власти в той таблице.

Отмена привилегий

Итак, привилегии назначены. Пользователи просматривают и изменяют ваши таблицы, и в базе данных постепенно возникает беспорядок. Теперь нужно научиться отменять назначенные привилегии.

Соответствующий оператор называется REVOKE. Его синтаксис аналогичен GRANT, но имеет противоположное значение. Чтобы отменить привилегию INSERT для таблицы Orders, предоставленную Адриану, вы можете ввести 

REVOKE INSERT ON Orders FROM Adrian;

Как и в GRANT, здесь допустимы списки привилегий и пользователей, поэтому вы можете ввести оператор 

REVOKE INSERT, DELETE ON Customers FROM Adrian, Stephen;

При использовании REVOKE возникают некоторые специфические вопросы. Кто имет право отменять привилегии? Когда пользователь с GRANT OPTION теряет привилегию, должны ли пользователи, которым он предоставил эту привилегию, также терять ее?

Общие принципы здесь следующие:

  • Вы можете отменять только ту привилегию, которую назначили.
  • Когда вы отменяете привилегию, назначенную с GRAND OPTION, все пользователи, получившие эту привилегию в результате применения GRAND OPTION, также теряют ее.
  • Существование некоторых объектов может зависеть от наличия определенных привилегий. Например, поскольку представление содержит запрос, вы можете создать представление таблицы только в том случае, если у вас есть привилегия SELECT для этой таблицы. А что произойдет с представлением, если вы создали его, а затем потеряли свою привилегию SELECT? SQL92 позволяет указать при отмене привилегии атрибут CASCADE или RESTRICT. Если используется CASCADE, то все зависимые объекты, такие как представления, автоматически удаляются. При использовании RESTRICT оператор REVOKE отменяется, если его выполнение может привести к удалению объектов.
  • Вы можете отменить GRANT OPTION для данной привилегии без отмены самой привилегии. При этом можно указать CASCADE или RESTRICT (см. выше).

Использование представлений для фильтрации табличных привилегий

Вы можете сделать действия привилегий более точными, используя представления. Всякий раз, когда вы передаёте привилегию в базовой таблице пользователю, она автоматически распространяется на все строки, а при использовании возможных исключений UPDATE и REFERENCES - на все столбцы таблицы.

Создавая представление, которое ссылается на основную таблицу и затем переносит привилегию на представление, а не на таблицу, вы можете ограничивать эти привилегии любыми выражениями в запросе, содержащемся в представлении. Это значительно улучшает базисные возможности команды GRANT.

Кто может создавать представления?

Чтобы создавать представление, вы должны иметь привилегию SELECT во всех таблицах, на которые вы ссылаетесь в представлении. Если это представление модифицируемое, любая привилегия INSERT, UPDATE и DELETE, которые вы имеете в базовой таблице, будут автоматически передаваться представлению.

Если у вас отсутствуют привилегии на модификацию в базовых таблицах, вы не сможете иметь их и в представлениях, которые вы создали, даже если сами эти представления - модифицируемые.

Так как внешние ключи не используются в представлениях, привилегия REFERENCES никогда не используется при создании представлений. Все эти ограничения определяются 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;

Вы должны выбрать для передачи пользователям только привилегию SELECT в этом представлении, чтобы они могли видеть исключенные строки, но не могли помещать недопустимые значения city в базовую таблицу. Фактически пользователи могли бы сделать запрос обоих представлений в объединении и увидеть все строки сразу.

Другие виды привилегий

Кто в первую очередь должен иметь право на создание таблиц? ISO не затрагивает этого вопроса, но мы не можем его игнорировать. Именно создатели таблиц назначают табличные привилегии, точно так же, как создатели других объектов назначают для них привилегии USAGE. Разрешение создавать базовые таблицы всем пользователям влечет за собой избыточность и неэффективность. Сюда же относятся и другие вопросы: кто должен иметь право изменять, удалять или ограничивать таблицы? Должно ли право создавать базовые таблицы быть отделено от права создавать представления или преводить временные таблицы в постоянные? Должны ли существовать суперпользователи (superusers) - пользователи, отвечающие за ведение базы данных и автоматически получающие все или почти все привилегии?

Поскольку стандарты в этой области отсутствуют, а SQL используется в самых разных окружениях, отвечать на поставленные вопросы можно только применительно к конкретной СУБД. Здесь представлены лишь наиболее общие подходы.

Привилегии, не относящиеся к конкретным объектам данных, обычно называют системными привилегиями (system privileges) или полномочиями базы данных (database authorities). Чаще всего к ним относится право создавать объекты данных, а также различать базовые таблицы (обычно создаваемые несколькими пользователями) и представления (обычно создаваемые многими или всеми пользователями). Системная привилегия на создание представлений должна дополнять, а не заменять объектные привилегии, требуемые стандартом. Кроме того, в системе любого размера обычно существует суперпользователь - пользователь, которые автоматически получает все или многие привилегии. Как правило, суперпользователь имеет специальное имя - SYS, System или DBA (от Database Administrator).

Типичные привилегии системы

При обычном подходе имеется три базовых привилегии системы: 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 OPTION пользователю, этот пользователь может, в свою очередь, предоставить эту привилегию другим. Теперь вы понимаете намеки на использование привилегий в представлениях - чтобы усовершенствовать привилегии в базовых таблицах, или как альтернативы ограничениям - и на некоторые преимущества и недостатки такого подхода.

Привилегии системы, которые необходимы, но не входят в область стандарта SQL, обсуждались в их наиболее общей форме, поэтому вы будете знакомиться с ними на практике. Глава 23 продолжит обсуждение таких вопросов о выводе в SQL как сохранение или восстановление изменений, создание ваших собственных имён для таблиц, принадлежащих другим людям и понимание того, что происходит, когда различные пользователи пытаются обращаться к одному и тому же объекту одновременно.

Работа с SQL

1. Передайте Janet право на изменение оценки заказчика.

2. Передайте Stephan право передавать другим пользователям право
   делать запросы в таблице Заказов.

3. Отнимите привилегию INSERT (ВСТАВКА) в таблице Продавцов
   у Claire и у всех пользователей, которым она была предоставлена.

4. Передайте Jerry право вставлять в или модифицировать таблицу
   Заказчиков с сохранением его возможности оценивать значения
   в диапазоне от 100 до 500.

5. Разрешите Janet делать запросы в таблице Заказчиков, но запретите
   ей уменьшать оценки в той же таблице Заказчиков.

(См. ответы в Приложении A.)