Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 24)

- 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 для ответов.)

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

Это иногда делается когда представление, рассматривается как сама таблица - например, если представление просто использует CHECK OPTION как заменитель ограничения CHECK в базовой таблице (смотрите Главу 22 для подробностей). Вы можете также создавать ваши собственные синонимы, имена которых будут такими же что и первоначальные имена таблиц. Например, Adrian может определить Customers, как свой синоним для таблицы Diane.Customers :

CREATE SYNONYM Customers FOR Diane.Customers;

С точки зрения SQL, теперь имеются два разных имени одной таблицы:

Diane.Customers и Adrian.Customers. Однако, каждый из этих пользователей может ссылаться к этой таблице просто как к Customers, SQL как говорилось выше сам добавит к ней недостающие имена пользователей.

ОДНО ИМЯ ДЛЯ КАЖДОГО

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

CREATE PUBLIC SYNONYM Customers FOR Customers;

Мы понимаем, что таблица Заказчиков это ваша собственность, поэтому никакого префикса имени пользователя в этой команды не указывается. В основном, общие синонимы создаются владельцами объектов или привилегированными пользователями, типа DBA. Пользователям кроме того, должны еще быть предоставлены привилегии в таблице Заказчиков чтобы они могли иметь к ней доступ. Даже если имя является общим, сама таблица общей не является. Общие синонимы становятся собственными с помощью команды PUBLIC, а не с помощью их создателей.

УДАЛЕНИЕ СИНОНИМОВ

Общие и другие синонимы могут удаляться командой DROP SYNONYM. Синонимы удаляются их владельцами, кроме общих синонимов, которые удаляются соответствующими привилегированными личностями, обычно DBA. Чтобы удалить например синоним Clients, когда вместо него уже появился общий синоним Customers, Adrian может ввести

DROP SYNONYM Clients;

Сама таблица Заказчиков, естественно, становится не эффективной.

КАК БАЗА ДАННЫХ РАСПРЕДЕЛЕНА ДЛЯ ПОЛЬЗОВАТЕЛЕЙ ?

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

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

В больших SQL системах, база данных будет разделена на области, так называемые Области Базы Данных или Разделы.

Это области сохраняемой информации, которые размещены так, чтобы информация внутри них находилась близко друг к другу для выполнения команд; то есть программа не должна искать где-то далеко информацию, сгруппированную в одиночной области базы данных. Хотя ее физические возможности зависят от аппаратного оборудования, целесообразно чтобы команда работала в этих областях внутри самой SQL. Системы которые используют области базы данных (в дальнейшем называемых - DBS (Data Base Spaces)), позволяют вам с помощью команд SQL обрабатывать эти области как объекты.

DBS создаются командами

CREATE DBSPACE (СОЗДАТЬ DBS),

ACQUIRE DBSPACE(ПОЛУЧИТЬ DBS) или

CREATE TABLE-SPACE (СОЗДАТЬ ТАБЛИЧНУЮ ОБЛАСТЬ),

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

Мы можем создать DBS с именем Sampletables, следующей командой:

CREATE DBSPACE Sampletables

(pctindex 10,

Характеристики

Список файлов книги