Предварительно установленные роли базы данных

Oracle определяет несколько предварительно установленных ролей, которые можно применять для предоставления привилегий пользовате­лям баз данных:

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

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

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

SELECT_CATALOG_ROLE Позволяет обращаться с запросами к представлениям словаря данных, созданным администратором.

DELETE_CATALOG_ROLE Позволяет удалять записи из журнала аудита базы данных (подробная информация об аудите приведена в разделе "Аудит баз данных" этой главы).

EXECUTE_CATALOG_ROLE Позволяет выполнять модули утилиты DBMS.

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

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

Роли, определяемые пользователями

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

CREATE ROLE order_entry;

-- Предоставляем этой роли привилегии

GRANT SELECT, INSERT, UPDATE, DELETE

ON sales.customers TO order_entry;

GRANT SELECT, INSERT, UPDATE, DELETE

ON sales.orders TO order_entry;

GRANT SELECT, INSERT, UPDATE, DELETE

ON sales.items TO order_entry;

GRANT SELECT, UPDATE,

ON sales.parts TO order_entry;

-- Предоставляем роль пользователям

GRANT order_entry TO ssmith, thrown, ptate;

Разрешение и запрещение ролей

Пользователь, которому предоставлена роль, не всегда имеет доступ к ее привилегиям. В Oracle приложения могут разрешать и запрещать роли для любого пользователя. После того как приложение разрешает (enables) роль для пользователя, ему становятся доступны ее привилегии. И, соответственно, когда приложение запрещает (disables) роль для пользователя, он более не имеет доступа к ее привилегиям. Возможность динамически управлять набором привилегий позволяет приложениям обеспечивать постоянную корректность наборов привилегий пользователей во время работы с данным приложением. Например, когда пользователь запускает приложение по вводу заказов, с помощью SQL-команды SET ROLE это приложение разрешает ему применять для работы роль ORDER_ENTRY. Когда пользователь завершает свою работу, приложение запрещает для него роль ORDER_ENTRY, и он не может применять привилегии приложения по вводу заказов во время работы с другим приложением.

Роли по умолчанию

Каждый пользователь имеет перечень ролей по умолчанию (default roles). Их Oracle создает автоматически при установлении пользователем нового сеанса связи с базой данных. Они удобны, когда нужно разрешить роли, необходимые пользователю во время работы с Oracle, независимо от того, какое приложение он применяет.

Аутентификация ролей

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

Транзакции и параллелизм

При работе СУБД возникает необходимость защиты БД от возможных случайных или преднамеренных ситуаций, когда су­ществует вероятность потери данных. Например, при доступе к БД сразу нескольких пользователей возможно повреждение или неправильная запись данных, что, в свою очередь, может привести к непредсказуемым последствиям. Очевидно, что из таких ситуа­ций СУБД должна уметь корректно выходить. Одним из способов решения этих проблем является механизм транзакций [5].

Поддержание механизма транзакций - показатель уровня раз­витости СУБД. Корректное поддержание транзакций одновремен­но является основой обеспечения целостности БД. Транзакции также составляют основу изолированности пользователей в мно­гопользовательских системах.

Под транзакцией понимается законченная с точки зрения воз­действия на БД последовательность операторов манипулирования данными (чтения, удаления, вставки, модификации) такая, что возможны два итога:

• результаты всех операторов, входящих в транзакцию, соответствующим образом отображаются в БД;

• воздействие всех этих операторов полностью отсутствует.

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

В языке SQL новая транзакция начинается или явным указани­ем оператора BEGIN, или автоматически после завершения пре­дыдущей. При этом если транзакция завершена оператором COMMIT, то результаты фиксируются во внешней памяти; при завершении транзакции оператором ROLLBACK результаты отсут­ствуют во внешней памяти.

Оператор COMMIT устанавливает так называемую точку фик­сации, т.е. момент, когда заканчивается логическая единица рабо­ты. Следовательно, БД будет находиться в согласованном (цело­стном) состоянии как до начала, так и в конце транзакции. При завершении транзакции оператором ROLLBACK БД тоже будет находиться в согласованном состоянии (в том же, что и до начала), так как никакого влияния на данные такая транзакция не ока­жет. Здесь под согласованностью будем понимать тот факт, что транзакции переводят БД из одного согласованного состояния в другое, т.е. в такое, что выполняются все условия ограничения целостности и т.п.

В свою очередь, понятие восстановление СУБД - процесс, подразумевающий возвращение БД в правильное состояние, если какой-либо процесс вызвал сбой данных. Восстановление базиру­ется на принципе избыточности БД, при этом по части хранимых данных имеется возможность восстановления всей информации полностью.

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

Глобальный сбой полностью действует на СУБД. Обычно вы­деляют два вида: сбой системы, нарушающий все выполняемые в данный момент транзакции, но не нарушающий БД физически, и сбой носителей данных, который представляет собой физическую угрозу для данных.

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

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

Понятие транзакции имеет непосредственную связь с понятием целостности БД. Очень часто БД может обладать такими ограни­чениями целостности, которые просто невозможно не нарушить, выполняя изменение только одним оператором. Для поддержания подобных ограничений целостности допус­кается их нарушение внутри транзакции с тем условием, чтобы к моменту завершения транзакции условия целостности должны быть соблюдены. В системах с развитыми средствами ограниче­ния и контроля целостности каждая транзакция начинается при целостном состоянии БД и должна оставить это состояние целост­ным после своего завершения. Несоблюдение этого условия при­водит к тому, что вместо фиксации результатов транзакции проис­ходит ее откат (т.е. отмена транзакции, когда она вместо операто­ра COMMIT завершается оператором ROLLBACK), и БД остается в таком состоянии, в котором находилась к моменту начала тран­закции.

В многопользовательских системах с одной БД, вообще гово­ря, одновременно могут работать несколько пользователей или прикладных программ. Одной из основных задач СУБД является обеспечение изолированности пользователей, т.е. создание такого режима работы, чтобы каждому из пользователей казалось, что он работает с БД в одиночку. Такую задачу СУБД принято иногда называть параллелизмом транзакций.

При параллельной обработке БД возникает три основных про­блемы:

• проблема потери результатов обновления заключается в первую очередь в том, что транзакция может быть не завершена из-за того, что данные, которые она обрабатыва­ет, могут быть модифицированы другой транзакцией;

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

• проблема несовместимого анализа связана с тем, что в результате модификации БД транзакцией, другая транзакция может внести в БД некую информацию, которая не будет соответствовать целостному состоянию БД.

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

Различают два вида блокировки:

• блокировка записи - при этом транзакция блокирует кор­теж таким образом, что запрос другой транзакции к этому кортежу будет отменен;

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

В СУБД используют протокол доступа к данным, позволяю­щий избежать проблем параллелизма. Его суть заключается в следующем:

• транзакция, результатом действия которой на кортеж яв­ляется его извлечение, обязана наложить блокировку чте­ния на этот кортеж;

• транзакция, предназначенная для модификации кортежа, обязана наложить блокировку записи на этот кортеж;

• в случае, если запрашиваемая блокировка на кортеж от­вергается из-за того, что на кортеж уже наложена блоки­ровка, то транзакция переводится в режим ожидания до тех пор, пока блокировка не будет снята;

• блокировка записи сохраняется вплоть до конца выполне­ния транзакции, т.е. до выполнения операторов COMMIT или ROLLBACK.

Решение проблем параллельной обработки БД заключается в том, что кортеж блокируется, а последующие транзакции, моди­фицирующие этот кортеж, отвергаются и переводятся в режим ожидания.

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