совершенно разные ситуации. Например, приведенная ниже совокупность операторов запрещает пользователю с именем Joe выполнять операции SELECT в отношении таблицы titles:

SQL:

grant select on titles to joe

revoke select on titles from public

A теперь рассмотрим те же операторы, но заданные в обратном порядке: SQL:

revoke select on titles from public

grant select on titles to joe

Теперь только Joe имеет право выполнять операцию SELECT.

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

Курсоры как механизм обеспечения безопасности

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

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

SQL:

revoke all on titles from public

grant all on bookview to public

grant all on titles

to mccann, himmelwright, brady, mandelbaum

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

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

Доступ может быть офаничен некоторым подмножеством столбцов таблицы базы. Можно, например, определить курсор, который будет содержать все строки таблицы titles, отсекая при этом столбцы ytdsales и advance, ввиду особой важности представленной в них информации.

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

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

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

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

Создание курсоров и реализация с их помощью (а таюке с помощью таблиц базы) системы доступа нередко является частью процесса определения данных. Однако ничто не мещает вам в любой момент изменить эту схему санкционирования, определив новые курсоры и написав новые операторы GRANT и REVOKE. Более подробная информация о курсорах приведена в главе 9.

ТРАНЗАКЦИИ

Транзакция (transaction) представляет собой логическую единицу работы СУБД. Управление транзакциями (transaction management) обеспечивает интерпретацию некоторой совокупности операторов SQL как единого блока (т.е. как неделимого объекта). Другими словами, управление транзакциями гарантирует, что либо будут выполнены все операции из некоторой группы (т.е. фанзакция), либо не будет выполнена ни одна из них: транзакция - это альтернатива типа все или ничего .

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

SQL автоматически управляет всеми командами, включая простые запросы на изменения данных, как транзакциями. Пользователь также может с помощью специальных команд сфуппировать некоторую совокупность операторов SQL в транзакцию, определенную пользователем (синтаксис этих команд меняется от системы к системы, но обычно они содержат такие ключевые слова, как BEGIN, COMMIT и ROLLBACK).

Транзакции и совпадения

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

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

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

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

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

Существует много видов блокировки, но для нас важнее всего понять разницу между исключительной (exclusive) блокировкой и совместной (shared) блокировкой. Исключительная блокировка применяется в системах баз данных в ходе операций модификации данных (так называемых операций записи): UPDATE, INSERT, DELETE. Когда исключительная блокировка применяется к некоторой совокупности данных, никакая другая транзакция не может установить по отношению к этим данным никакой вид блокировки до тех пор, пока в конце транзакции по модификации данных не будет снята исходная блокировка.

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

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