Генералова - БД (стр. 6 )

Применительно к двучленной конъюнкции xy это значит:

Вычисляется x':

инвертируемое	0	1	1
инверсия	0	1	1

Заметим, что дополнение булева выражения двойственно его инверсии: в приведенном примере дополнительное выражение x' ∨ y' отличается от инверсного x' ∧ y' тем, что в нем заменен двойственным (перевернут, «инвертирован») знак ∧. Взаимосвязь операций инверсии, дополнения и получения двойственного («дуалирования») δ (διπλoη — двойственное) булева выражения e представима тождествами:

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

[править] Импликация

Импликация — (от лат. implicatio — сплетение, от implico — тесно связываю) — логическая связка, соответствующая грамматической конструкции «если ..., то...», с помощью которой из двух простых высказываний образуется сложное высказывание. В импликативном высказывании различают антецедент (основание) — высказыва­ние, идущее после слова «если», и консеквент (следствие) — выска­зывание, идущее за словом «то». Импликативное высказывание представляет в языке логики условное высказывание обычного языка. Последнее играет особую роль как в повседневных, так и в науч­ных рассуждениях, основной его функцией является обоснование одного путем ссылки на нечто другое. В современной логике имеется большое число импликаций, различающих­ся своими формальными свойствами:

материальная Лукасевича Гейтинга Троичная функция следования (Брусенцова)

[править] Импликация материальная

Материальная импликация — одна из основных связок классической логики. Определяется она т. о.: Импликация ложна только в случае истинности основание(антецедента) и ложности следствия(консеквента) и истинна во всех остальных случаях. Условное высказывание «Если x, то y» предполагает некоторую реальную связь между тем, о чем говорится в x и y; выражение «x материально имплицирует y» такой связи не предполагает.

Вычисляется импликация материальная max(−x, y); ; x' ∨ y :

1-е высказывание (x)	0	0	0	1	1	1	1	1	1
2-е высказывание (y)	0	1	1	0	1	1	0	1	1
Импликация	0	1	0	0	1	1	1	1	1

или

x

^

|

1 | 1 0 1

0 | 0 0 1

1 | 1 1 1

---+> y

| 1 0 1

[править] Импликация Лукасевича

Это часть модальной логики.

x

^

|

1 | 1 0 1

0 | 0 1 1

1 | 1 1 1

---+> y

| 1 0 1

[править] Импликация Гейтинга

Это часть многозначной логики. Логика Гейтинга охватывала лишь часть классической формальной логики.

Имп­ликацию (если р, то q) можно утверждать, только если имеется такое построение, которое, будучи объединено с построением р, автоматически даёт построение q. Например, из истинности высказывания p следует: неверно, что p ложно. Но из утверждения "неверно, что p ложно" ещё не следует, что p истинно, так как высказывание p может оказаться неконструктивным.

x

^

|

1 | 1 0 1

0 | 1 1 1

1 | 1 1 1

---+> y

| 1 0 1

[править] Троичная функция следования (Брусенцова)

Вычисляется :

1-е высказывание (x)	0	0	0	1	1	1	1	1	1
2-е высказывание (y)	0	1	1	0	1	1	0	1	1
Импликация	0	0	0	0	1	1	0	0	1

или

x

^

|

1 | 1 0 1

0 | 0 0 0

1 | 1 0 0

---+> y

| 1 0 1

[править] Применение троичной логики

Джордж Буль изобрёл «математику мысли», устранив из числовой математики все значения, кроме 0 и 1, интерпретируемых как «нет» и «есть», либо «исключено» и «дано», либо «ложь» и «истина». Такую систему называют двузначной, что не представляется верным, ибо двузначность — синоним двусмысленности. Корректней назвать её двухзначной системой, двухзначной логикой. Но это только поверхностное, «косметическое» уточнение, а по существу проблема двухзначности несравненно глубже, фундаментальней. Противопоставленный стоиками аристотелеву Органону хрисиппов принцип двухзначности в его «классической» трактовке (либо истина, либо ложь и ничего третьего) радикально отделил формальную логику — и традиционную, и математическую — от диалектики.

Впрочем, основоположник математической логики Буль, не в пример современным представителям этой науки, сосредоточившим всё внимание на проблеме двухзначного (дихотомического) вывода, считал важнейшей её задачей решение логических уравнений, чем и оправдывалось название «математическая». Решение этой обратной задачи, предпринятое самим Булем, показало, что удовлетворяющим логическому уравнению значением термина может быть не только 1 либо 0, но и нечто третье — «неопределённость», которую Буль обозначал буквой u . В дальнейшем выяснилось, что в зависимости от условий, определяемых значениями прочих входящих в уравнение терминов, для искомого термина x имеется четыре альтернативы:

1) x = 0, 2) x = 1, 3) x свободно, не фиксировано (у Аристотеля — συμβεβηκός — «привходяще»), 4) решение не существует.

Например, решение относительно термина y уравнения xy = 0, как нетрудно проверить, таково:

при x = 0 значение y привходяще, при x = 1 y = 0.

Решение уравнения x ∨ y = 0, то есть x'y' = 1,

при x = 1 не существует, при x = 0 y = 0.

Целостность сущностей

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

Это определяет следующее правило целостности сущностей:

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

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

«Ссылочная целостность в реляционной базе данных – это согласованность между связанными таблицами. Ссылочная целостность обычно поддерживается путем комбинирования первичного ключа и внешнего ключа. Для соблюдения ссылочной целостности требуется, чтобы любое поле в таблице, объявленное внешним ключом, могло содержать только значения из поля первичного ключа родительской таблицы …» [5] «[Ссылочная целостность – это] свойство, обеспечиваемое реляционными системами управления базами данных (РСУБД), которое предотвращает ввод несогласованных данных пользователями или приложениями. В большинстве РСУБД имеются различные правила ссылочной целостности, которые можно применить при создании связи между двумя таблицами.» [6] «[Ссылочная целостность – это] предохранительное устройство системы управления базами данных, гарантирующее, что каждый внешний ключ соответствует первичному ключу. Например, номера заказчиков являются первичными ключами в файле заказчиков и внешними ключами в файле заказов. При удалении записи заказчика должны быть удалены соответствующие записи заказов; в противном случае они останутся без исходной связи. Если СУБД не проверяет этого, соответствующий механизм должен программироваться в приложении.» [7]

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

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

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

6. Транзакции и целостность баз данных. Определение транзакции, свойства плоских транзакций, фиксация транзакций, откат транзакции. Журнал транзакций. Восстановление после мягкого сбоя, восстановление после жесткого сбоя.

Транзакции и целостность баз данных

Понятие транзакции имеет непосредственную связь с понятием целостности БД. Очень часто БД может обладать такими ограничениями целостности, которые просто невозможно не нарушить, выполняя только один оператор изменения БД. Например, в базе данных СОТРУДНИКИ-ОТДЕЛЫ естественным ограничением целостности является совпадения значения атрибута ОТД_РАЗМЕР в кортеже отношения ОТДЕЛЫ, описывающем данный отдел (например, отдел 320), с числом кортежей отношения СОТРУДНИКИ таких, что значение атрибута СОТР_ОТД_НОМЕР равно 320. Как в этом случае принять на работу в отдел 320 нового сотрудника? Независимо от того, какая операция будет выполнена первой, вставка нового кортежа в отношение СОТРУДНИКИ или модификация существующего кортежа в отношении ОТДЕЛЫ, после выполнения операции база данных окажется в нецелостном состоянии.

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

Если быть немного более точным, различаются два вида ограничений целостности: немедленно проверяемые и откладываемые. К немедленно проверяемым ограничениям целостности относятся такие ограничения, проверку которых бессмысленно или даже невозможно откладывать. Примером ограничения, проверку которого откладывать бессмысленно, являются ограничения домена (возраст сотрудника не может превышать 150 лет). Более сложным ограничением, проверку которого невозможно отложить, является следующее: зарплата сотрудника не может быть увеличена за одну операцию более, чем на 100,000 рублей. Немедленно проверяемые ограничения целостности соответствуют уровню отдельных операторов языкового уровня СУБД. При их нарушениях не производится откат транзакции, а лишь отвергается соответствующий оператор.

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

И еще одно замечание. С точки зрения внешнего представления в момент завершения транзакции проверяются все откладываемые ограничения целостности, определенные в этой базе данных. Однако при реализации стремятся при выполнении транзакции динамически выделить те ограничения целостности, которые действительно могли бы быть нарушены. Например, если при выполнении транзакции над базой данных СОТРУДНИКИ-ОТДЕЛЫ в ней не выполнялись операторы вставки или удаления кортежей из отношения СОТРУДНИКИ, то проверять упоминавшееся выше ограничение целостности не требуется (а проверка подобных ограничений вызывает достаточно большую работу).

Ко всем типам транзакций предъявляется набор требований, известный

под названием ACID (atomocity, consistency, isolation, durability). Смысл

этих требований заключается в следующем.

- Атомарность. Транзакция представляет собой некоторый набор действий.

Система обеспечивает их выполнение по принципу "все или ничего" - либо

выполняются все действия, т. е. транзакция фиксируется, либо не выполняется

ни одно, т. е. транзакция прерывается.

- Согласованность. Предполагается, что в результате транзакции система

переходит из одного абстрактного корректного состояния в другое. Понятие

транзакции позволяет программисту декларировать условия таких согласованных

состояний данных, а системе - подтверждать согласованность, производя

описанные в приложении проверки.

- Изолированность. Поскольку транзакция изменяет разделяемые данные, то они

могут временно находиться в несогласованном состоянии. Данные, находящиеся

в несогласованном состоянии, не должны быть видны другим транзакциям, пока

изменения не будут завершены (т. е. пока все модификации не будут формально

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

выполняется изолированно, как если бы прочие транзакции либо завершились до

ее начала, либо начнут выполняться после ее завершения.

- Долговечность. Если транзакция зафиксирована, то ее результаты должны

быть долговечными. Новые состояния всех объектов сохранятся даже в случае

аппаратных или системных сбоев.

Модели плоских транзакций соответствует один управляющий слой,

которому подчинено произвольное число элементарных действий. В современных

информационных системах - это, как правило, единственная поддерживаемая на

прикладном уровне модель транзакций, хотя внутренние компоненты системы

(например, SQL) могут включать более изощренные средства обработки

транзакций; однако они не доступны на уровне прикладного программирования.

Плоские транзакции - это основные строительные блоки для реализации

принципа атомарности; иначе говоря, выделение некоторой последовательности

действий в виде плоской транзакции обеспечивает принцип "все или ничего".

Во многих прикладных окружениях, в особенности с централизованными

обработкой и управлением ресурсами (например, базами данных и файлами),

механизм плоских транзакций на протяжении многих лет предоставлял вполне

удовлетворительные возможности как для создания, так и для выполнения

приложений; простые преобразования состояний системы вполне укладывались в

рамки атомарных единиц работы.

По мере того как данные и вычисления становятся все более

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

неудобством. Рассмотрим пример на рис. 2. Согласно правилам обработки

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

глобальной транзакции, либо не должна завершиться ни одна из них. Например,

если неудачей завершилось только изменение одной удаленной базы данных под

управлением некоторого менеджера ресурсов, то и все остальные компоненты

должны быть возвращены в состояние, предшествовавшее началу транзакции.

Учитывая количество информации, обрабатываемой в крупной или даже средней

организации со множеством серверов LAN на ПК и, возможно, с мобильными

базами данных, можно предположить, что вероятность отказа хотя бы одного

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

заново выполнять все составные части транзакции, что существенно повышает

требования к вычислительным ресурсам и отнимает значительную долю

пропускной способности системы.

Журнал транзакций

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

Однако назначение журнала транзакций гораздо шире. Он предназначен для обеспечения надежного хранения данных в БД.

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

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

результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных; результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.

Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.

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

Индивидуальный откат транзакции. Этот откат должен быть применен в следующих случаях:
стандартной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK; аварийное завершение работы прикладной программы, которое логически эквивалентно выполнению оператора ROLLBACK, но физически имеет иной механизм выполнения; принудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. В подобном случае для выхода из тупика данная транзакция может быть выбрана в качестве «жертвы» и принудительно прекращено ее выполнение ядром СУБД.
Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть в следующих случаях:
при аварийном выключении электрического питания; при возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т. д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти.
Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.

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

Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных.

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

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

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

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

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

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

Ведение журнала по принципу отложенных изменений предполагает следующий механизм выполнения транзакций:

Когда транзакция Т1 начинается, в протокол заносится запись

<Т1 Begin transaction>

На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение: <T1, ID_RECORO. атрибут, новое значение ... >. Здесь ID_RECORD — уникальный номер записи. Если все действия, из которых состоит транзакция Т1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится <Т1 СОММIТ>. После того как транзакция фиксирована, записи протокола, относящиеся к Т1, используются для внесения соответствующих изменений в БД. Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Транзакцию Т1 необходимо переделать, если протокол содержит обе записи <Т1 BEGIN TRANSACTION и <Т1 СОММIТ>. БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется некоторая системная процедура REDOQ, которая заменяет все значения элементов данных на--новые, просматривая протокол в прямом порядке. Если в протоколе не содержится команда фиксации транзакции COMMIT, то никаких действий проводить не требуется, а транзакция запускается заново.

Рис. 11.3. Журнал транзакций

Альтернативный механизм с немедленным выполнением предусматривает внесение изменений сразу в БД, а в протокол заносятся не только новые, но и все старые значения изменяемых атрибутов, поэтому каждая запись выглядит <Т1, ID_RECORD, атрибут новое значение старое значение...>. При этом запись в журнал предшествует непосредственному выполнению операции над БД. Когда транзакция фиксируется, то есть встречается команда <Т1 СОММIТ> и она выполняется, то все изменения оказываются уже внесенными в БД и не требуется никаких дальнейших действий по отношению к этой транзакции.

При откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу начиная с команды BEGIN TRANSACTION.

Для восстановления при сбое используется следующий механизм:

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

Восстановление после мягкого сбоя

К числу основных проблем восстановления после мягкого сбоя относится то, что одна логическая операция изменения базы данных может изменять несколько физических блоков базы данных, например, страницу данных и несколько страниц индексов. Страницы базы данных буферизуются в оперативной памяти и выталкиваются независимо. Несмотря на применение протокола WAL, после мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, то есть часть страниц внешней памяти соответствует объекту до изменения, часть — после изменения. К такому состоянию объекта неприменимы операции логического уровня.

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

Будем считать, что в журнале отмечаются точки физической согласованности базы данных — моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились, а буфер журнала вытолкнут во внешнюю память. Немного позже мы рассмотрим, как можно достичь физической согласованности. Назовем такие точки tpc (time of physical consistency) — точками физического согласования.

Тогда к моменту мягкого сбоя возможны следующие состояния транзакций:

транзакция успешно завершена, то есть выполнена операция подтверждения транзакции COMMIT и для всех операций транзакции получено подтверждение ее выполнения во внешней памяти; транзакция успешно завершена, но для некоторых операций не получено подтверждение их выполнения во внешней памяти; транзакция получила и выполнила команду отката ROLLBACK; транзакция не завершена.

Восстановление после жесткого сбоя

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

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

Более точно, происходит следующее:

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

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

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

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

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

7. Управление транзакциями. Изолированность пользователей. Проблемы при параллельном выполнении транзакций. Конфликты доступа. Устранение проблем параллельности. Блокировка. Протокол доступа к данным. Матрица совместимости. Взаимная блокировка. Матрица совместимости расширенная блокировками намерения. Диаграмма приоритетов. Уровни изоляции SQL. Сериализация транзакций. Методы сериализации транзакций

Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.