Понимание 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 выполняет действия через специальных пользователей в специальной системе базы данных. Сама команда GRANT достаточно проста: с ее помощью, вы предоставляете те или иные привилегии объекта одному или более пользователям. Если вы предоставляете привилегию WITH GRANT OPTION пользователю, этот пользователь может в свою очередь предоставить эту привилегию другим. Теперь вы понимаете намеки на использование привилегий в представлениях - чтобы усовершенствовать привилегии в базовых таблицах, или как альтернативы к ограничениям - и на некоторые преимущества и недостатки такого подхода. Привилегии системы, которые необходимы, но не входят в область стандарта SQL, обсуждались в их наиболее общей форме и поэтому вы будете знакомиться с ними на практике.
Глава 23 продолжит обсуждение о выводах в SQL, таких как сохранение или восстановление изменений, создание ваших собственных имен для таблиц принадлежащих другим людям, и понимание что происходит когда различные пользователи пытаются обращаться к одному и тому же объекту одновременно.
* Передайте Janet право на изменение оценки заказчика.
* Передайте Stephan право передавать другим пользователям право делать запросы в таблице Порядков.
* Отнимите привилегию INSERT( ВСТАВКА) в таблице Продавцов у Claire и у всех пользователей которым она была предоставлена.
* Передайте Jerry право вставлять или модифицировать таблицу Заказчиков с сохранением его возможности оценивать значения в диапазоне от 100 до 500.
* Рарешите Janet делать запросы в таблице Заказчиков, но запретите ему уменьшать оценки в той же таблице Заказчиков.
Глава 23. ГЛОБАЛЬНЫЕ АСПЕКТЫ SQL
ЭТА ГЛАВА БУДЕТ ОБСУЖДАТЬ АСПЕКТЫ ЯЗЫКА SQL которые имеют отношение к базе данных как к единому целому, включая использование многочисленых имен для объектов данных, размещение запоминаемых данных, восстановлние и сохранение изменений в базе данных а также координирование одновременных действий многочисленных пользователей. Этот материал даст вам возможность конфигурации вашей базы данных, отмены действия ошибок, и определения как действия одного пользователя в базе данных будут влиять на действия других пользователей.
Каждый раз, когда вы ссылаетесь в команде к базовой таблице или представлению не являющимися вашей собственностью, вы должны установить в ней префикс имени владельца, так что бы SQL знала где ее искать. Так как это со временем становится неудобным, большинство реализаций SQL позволяют вам создавать синонимы для таблиц (что не является стандартом ANSI ) Синоним - это альтернативное имя, наподобии прозвища, для таблицы. Когда вы создаете синоним, вы становитесь его собственником, так что нет никакой необходимости, чтобы он предшествовал другому пользовательскому идентификатору доступа( имени пользователя ) Если вы имеете по крайней мере одну привилегию в одном или более столбцах таблицы; вы можете создать для них синоним. (Некоторое отношение к этому может иметь специальная привилегия для создания синонимов.)
Adrian может создать синоним с именем Clients, для таблицы с именем Diane.Customers, с помощью команды CREATE SYNONYM следующим образом:
CREATE SYNONYM Clients FOR Diane.Customers;
Теперь, Adrian может использовать таблицу с именем Clients в команде точно так же как ее использует Diane.Customers. Синоним Clients - это собственность, используемая исключительно для Adrian.
Префикс (прозвище) пользователя - это фактически часть имени любой таблицы. Всякий раз, когда вы не указываете ваше собственное имя пользователя вместе с именем вашей собственной таблицы, SQL сам заполняет для вас это место. Следовательно, два одинаковых имени таблицы но связанные с различными владельцами, становятся не идентичными и следовательно не приводят к какому-нибудь беспорядку (по крайней мере в SQL).