Комплект лекционных материалов по дисциплине “Разработка и эксплуатация удаленных баз данных” (стр. 3 )

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

Свойства транзакций.

Существуют определенные свойства, которыми должна обладать любая из транзакций. Ниже представлены четыре основных свойства транзакций, которые принято обозначать аббревиатурой ACID (Atomicity, Consistency, Isolation, Durability – неразрывность, согласованность, изолированность, устойчивость), состоящей из первых букв названий этих свойств.

· Неразрывность (атомарность). Это свойство, для описания которого применимо выражение «все или ничего». Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вообще. За обеспечение неразрывности отвечает подсистема восстановления СУБД.

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

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

· Устойчивость (долговременность). Результаты успешно завершенной (зафиксированной) транзакции должны храниться в БД постоянно и не должны быть утеряны в результате последующих сбоев. За обеспечение устойчивости отвечает подсистема восстановления.

СРЕДСТВА ВОССТАНОВЛЕНИЯ БАЗ ДАННЫХ

Восстановление БД – Процесс возвращения БД в приемлемое состояние, утраченное в результате сбоя или отказа.

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

Основным принципом согласованной политики записи измене­ний в журнал и непосредственно в базу данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказы­вается во внешней памяти базы данных. Соответствующий прото­кол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) — «пиши сначала в журнал», и состоит в том, что если требуется сохранить во внешней памяти измененный объект базы данных, то перед этим нужно гарантировать сохранение во внешней памяти журнала записи о его изменении.

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

Иногда для восстановления последнего согласованного состоя­ния базы данных после сбоя журнала изменений базы данных явно недостаточно. Основой восстановления в этом случае являются журнал и архивная копия базы данных.

Восстановление начинается с обратного копирования базы дан­ных из архивной копии. Затем для всех закончившихся транзакций в прямом смысле повторно выполняются все операции. Более точ­но, происходит следующее: по журналу в прямом направлении вы­полняются все операции; для транзакций, которые не закончились к моменту сбоя, выполняется откат (англ, back up).

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

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

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

В заключение сформулируем общие требования к системе вос­становления данных в составе СУБД.

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

Для восстановления базы данных СУБД имеют в своем составе сервисные программные средства:

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

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

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

Программы отката ликвидируют последствия выполнения оп­ределенной транзакции в БД.

Программы записи контрольных точек и повторного исполнения позволяют ускорить восстановление.

УПРАВЛЕНИЕ ДОСУПОМ К ДАННЫМ

СУБД должна предоставлять механизм, гарантирующий, что доступ к БД смогут получить только те пользователи, которые имеют соответствующее разрешение. Язык SQL включает операторы GRANT и REVOKE, предназначенные для организации защиты таблиц в БД. Применяемый механизм защиты построен на использовании идентификаторов пользователей, предоставляемых им прав владения и привилегий.

Идентификаторы пользователей и права владения

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

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

Привилегии

Привилегиями называют определения действий, которые пользователь имеет право выполнять в отношении данной таблицы БД или представления. В стандарте ISO определяется следующий набор привилегий:

SELECT – право выбирать данные из таблицы INSERT – право вставлять в таблицу новые строки UPDATE – право изменять данные в таблице DELETE – право удалять строки из таблицы REFERENCES – право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных. USAGE – право использовать домены, проверки, наборы символов и трансляции.

Привилегии INSERT и UPDATE могут ограничиваться лишь отдельными столбцами таблицы; в этом случае пользователь может модифицировать значения указанных столбцов, но не изменять значения остальных столбцов таблицы. Аналогичным образом, привилегия REFERENCES может распространяться только на отдельные столбцы таблицы, что позволит использовать их имена в формулировках требований защиты целостности данных (например, в конструкциях CHECK, FOREIGN KEY), входящих в определения других таблиц, тогда как применение для подобных целей остальных столбцов будет запрещено.

Когда пользователь с помощью оператора CREATE TABLE создает новую таблицу, он автоматически становится ее владельцем и получает по отношению к ней полный набор привилегий. Остальные пользователи первоначально не имеют каких-либо привилегий в отношении вновь созданной таблицы. Чтобы обеспечить доступ к ней, владелец должен явным образом предоставить им необходимые права, для чего используется оператор GRANT.

Предоставление привилегий другим пользователям (оператор GRANT)

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

GRANT {PrivilegeList | ALL PRIVILEGES}

ON ObjectName

TO {AuthorizationIdList | PUBLIC}

[WITH GRANT OPTION]

Параметр PrivilegeList представляет собой список, состоящий из одной или более привилегий, разделенных запятыми:

SELECT

DELETE

INSERT [(columnName [,..])]

UPDATE [(columnName [,..])]

REFERENCES [(columnName [,..])]

USAGE

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

Конструкция WITH GRANT OPTION позволяет всем указанным в списке параметра AuthorizationIdList пользователям передавать другим пользователям все предоставленные им в отношении указанного объекта привилегии. Если эти пользователи также передадут собственные полномочия другим пользователям с указанием конструкции WITH GRANT OPTION, то последние, в свою очередь, также получать право передавать свои полномочия другим пользователям. Если эта конструкция не будет указана, получатель привилегии не сможет передать свои права другим пользователям. Таким образом, владелец объекта может четко контролировать, кто получил право доступа к объекту и какие полномочия ему предоставлены.

Использование ключевого слова PUBLIC означает, что все пользователи (как уже существующие, так и те, которые будут созданы в базе данных впоследствии) получают право выбирать все данные, имеющиеся в таблице Branch. Обратите внимание на то, что в данном случае нет смысла использовать конструкцию WITH GRANT OPTION, поскольку указанные права получают все пользователи БД и предоставлять их больше некому.

Отмена предоставленных пользователям привилегий (оператор REVOKE)

В языке SQL для отмены предоставленных пользователям посредством оператора GRANT привилегий используется оператор REVOKE. С помощью этого оператора могут быть отменены все или некоторые из привилегий, предоставленных указанному пользователю раньше. Оператор REVOKE имеет следующий формат:

REVOKE [GRANT OPTION FOR] {PriviegeList | ALL PRIVILEGES}

ON ObjectName

FROM {AutorizationIdList | PUBLIC} [RESTRICT | CASCADE]

Ключевое слова ALL PRIVILEGES означает, что для указанного пользователя отменяются все привилегии, предоставленные ему ранее тем пользователем, который ввел данный оператор. Необязательная конструкция GRANT OPTION FOR позволяет для всех привилегий, переданных в исходном операторе GRANT конструкции WITH GRANT OPTION, отменять возможность их передачи независимо от самих этих привилегий.

Назначение ключевых слов RESTRICT и CASCADE аналогично тому, которое они имеют в операторе DROP TABLE. Поскольку для создания некоторых объектов необходимо наличие привилегий, в результате удаления привилегии пользователь может лишиться права, на основании которого им был создан тот или иной объект (подобные объекты, лишенные владельца, принято называть заброшенными). Выполнение оператора REVOKE будет отменено, если в результате могут появиться заброшенные объекты, если только в нем не указано ключевое слово CASCADE. Если в операторе присутствует ключевое слово CASCADE, то для любых заброшенных объектов, возникающих при выполнении исходного оператора REVOKE, будут автоматически выданы операторы DROP.

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

ХРАНИМЫЕ ПРОЦЕДУРЫ И ТРИГГЕРЫ

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

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

Язык хранимых процедур алгоритмический, с возможностями SQL.

Хранимая процедура создается следующим оператором:

CREATE PROCEDURE ИмяПроцедуры

[(<входной_параметр> <тип_данных>

[,<входной_параметр> <тип_данных> ...])]

[RETURNS (<выходной_параметр> <тип_данных>

[,<выходной_параметр> <тип_данных> ...])] AS

[<объявление локальных переменных>] BEGIN

<оператор>;

[<оператор>; .. . ] END

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

Как входные, так и выходные параметры могут быть опущены, если в них нет не­обходимости.

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

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

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

Устанавливаемые триггером бизнес-правила не должны противоречить аналогичным правилам, заданным БД на физическом уровне.

Триггер создается таким SQL-оператором:

CREATE TRIGGER <имя триггера> FOR <имя таблицы>

[ACTIVE | INACTIVE]

{BEFORE | AFTER}

{DELETE | INSERT | UPDATE}

[POSITION <НОМЕР>]

AS

[<объявление локальных переменных>]

BEGIN

<операторы>

END

Active| Inactive указывает, будет ли триггер активен (по умолчанию Active)

BEFORE| After определяет, будет ли триггер срабатывать до или после изменения данных.

Следующий параметр указывает тип изменения данных

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