Материал: Graber_Martin_-_SQL_dlya_prostykh_smertnykh_-_2014

Глава 22. 01lределение llpaв дocmylla к данным

Команда GRANT в своей модифицированной форме применима и к системным, и к объектным привилегиям. Начальные привилегии назначаются пользователем DBA. Например, DBA может передать привилегию создания таблицы пользователю Rodriguez таким образом:

GRANT RESOURCE ТО Rodriguez;

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

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

GRANT CONNECT ТО Thelonius IDENTIFIED ВУ Redwagon;

Команда создает пользователя Thelonius, дает ему право входа в систему и назнача­

ет ему пароль Redwagoп. Теперь, поскольку Theloпious является распознаваемым

пользователем, он или DBA могут использовать эту же команду для изме~~ения пароля

Redwagoп. На практике встречаются ограничения такого рода. Невозможно иметь

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

тавлять пользователю право входа в систему, следует выполнить команду REVOKE для привилегии CONNECT, которая лишит пользователя этой привилегии. Некоторые

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

от привилегии входа в систему.

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

эквивалентна уничтожению пользователя.

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

определение или менее контролируемую систему привилегий.

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

246

Итоги

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

Итоги

Привилегии дают возможность увидеть SQL с новой точки зрения, а именно: дей­ ствия SQL выполняются конкретными пользователями в конкретной системе баз дан­ ных. Команда GRANT сама по себе достаточно проста: с ее помощью можно передать одну или несколько привилегий для объекта одно:v~у или нескольким пользователям. Если пользователю передается привилегия WIТH GRANT OPТION, то он может, в

свою очередь, передавать эту привилегию другим пользователям.

Мы изучили привилегии пользователя на представления, их преимущества и не­

достатки. Системные привилегии, которые являются необходимыми, но выходят за границы стандарта SQL, рассмотрены в самом общем виде.

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

когда различные пользователи пытаются осуществить доступ в один и тот же момент

времени к одному и тому же объекту.

247

Работаем на SQL

1.Дайте Janet право изменять рейтинги (ratings) продавцов.

2.Дайте Stephen право предоставлять другим пользователям право формулировать запросы к таблице Orders.

3.Отмените привилегию выполнять команду INSERT для таблицы Salespeople для

пользователя Claire и всех тех пользователей, которым Claire передал полномо­

чия.

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

5.Разрешите Janet формулировать запросы к таблице Customers, но запретите ей дос­ туп к тем покупателям (Customers), чей рейтинг является самым низким.

(Ответы см. в приложении А.)

248

Глава 23. Глобальные аспекты SQL

В этой главе обсуждаются аспекты языка SQL, имеющие общее отношение к

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

Переименование таблиц

Если в команде есть ссылка на базовую таблицу или представление, владельцем ко­ торых является другой пользователь, то нужно указать в качестве префикса перед име­ нем таблицы имя владельца; благодаря этому SQL знает, где ее искать. Поскольку в целом ряде случаев это может оказаться неудобным, многие программные реализации SQL позволяют создавать синонимы для таблиц (эта возможность не входит в стан­ дарт SQL). Синоним (synonym)- это альтернативное имя таблицы, подобное прозви­

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

синонимом не следует указывать другого идентификатора пользователя (имя пользо­ вателя).

Имея, по крайней мере, одну привилегию для одного или нескольких столбцов таб­ лицы, можно создать для них синоним. (Некоторые программные реализации SQL мо­ гут иметь специальную привилегию для создания синонимов.) Adгian может создать синоним, скажем, Clients для Diane.Customers, используя команду CREATE SYNONYM следующим образом:

CREATE SYNONYM Clients FOR Diane.Customers;

Теперь Adrian может использовать имя таблицы Clients в команде точно так же, как и имя Diane.Customers. Владельцем синонима Clients является Adrian, и только он мо­

жет его использовать.

Переименование с исnользованием того :нее имени

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

лежащих различным пользователям, реально не являются совпадающими, их нельзя

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

пользователя, им поименованное, и использовать в качестве имени представления имя

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

250