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

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

Целостность данных - это механизм поддержания соответствия базы данных предметной области.

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

В реляционной модели данных определены два базовых требования обеспечения целостности:

1. Целостность по сущностям.

2. Целостность по ссылкам.

3. Целостность, определяемая пользователем.

Целостность сущностей. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение. Вполне очевидно, что если данное требование не соблюдается то в базе данных может хранится противоречивая информация об одном и том же объекте. Поддержание целостности сущностей обеспечивается средствами системы управления базой данных (СУБД). Это осуществляется с помощью двух ограничений:

- при добавлении записей в таблицу проверяется уникальность их первичных ключей

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

Целостность ссылок Значение внешнего ключа должно либо:

- быть равным значению первичного ключа цели;

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

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

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

Целостность определяемая пользователем. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется: уникальность тех или иных атрибутов, диапазон значений экзаменационная оценка от 2 до 5),принадлежность набору значений (пол "М" или "Ж").

В общем случае целостность данных может нарушаться по следующим основным причинам:

1) ошибки в создании структуры локальных БД и их заполнении;

2) просчеты в построении структуры РБД (процедуры фрагментации и локализации);

3) системные ошибки в программном обеспечении взаимодействия локальных БД (одновременный доступ);

4) аварийная ситуация (неисправность технических средств) и восстановление РБД.

Логическая целостность

Логическая целостность – нарушается, если база некорректно обновлена.

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

Семантическая целостность

Семантическая целостность – соответствие данных в разных полях. Осуществляется проверка связи между данными, хранящимися в разных полях.

Например, дата окончания школы не может быть на 16 лет раньше рождения.

Механизмы поддержания семантической целостности:

1. Механизм триггеров - активная процедура, автоматически вызывается, когда это необходимо.

2. Существуют специальные процедуры, которые осуществляют контроль за внесенной информацией.

Триггеры - средство, обеспечивающее автоматическое выполнение некоторых действий при каждой модификации таблицы.

Триггер характеризуется следующими классификационными признаками, которые должны быть заданы при его создании:

• условие активизации - действие над таблицей, которое вызывает запуск триггера - такими действиями являются операции INSERT, DELETE, UPDATE;
• время активизации - выполнение триггера до или после выполнения операции над таблицей;
• область действия - выполнение триггера либо один раз для каждого оператора модификации таблицы, либо для каждой строки, изменяемой / удаляемой / вставляемой в таблицу.

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

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

Триггеры: Oracle

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

Отличия триггера Oracle от триггера DB2 (многие из них видны из самого синтаксиса оператора) состоят в следующем:

• Оператор CREATE позволяет заменить триггер (в DB2 для этого нужно уничтожить триггер и создать его заново).
• Триггер можно создавать и для представления (это связано прежде всего с более широкими возможностями изменения представлений в Oracle).
• Введено новое условие активизации INSTEAD OF (триггер выполняется вместо оператора); оно применяется только для представлений и позволяет изменять базовые таблицы вместо неизменяемого представления.
• Для триггера могут быть назначены несколько условий активизации (через операцию OR). В этом случае действие триггера может "узнать" по какому условию запущен триггер, проверяя значения предикатов INSERTING, DELETEING, UPDATING.
• В условии фразы WHEN не допускаются запросы.
• Собственно выполняемые действия триггера задаются в виде блока на языке PL/SQL.

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

20. Восстановление данных в БД

Если РБД обеспечивает целостные, непротиворечивые данные, говорят об ее корректном состоянии (корректности).

Восстановление (управление восстановлением) связано с приведением системы в корректное состояние после (аппаратного) сбоя.

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

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

Система восстановления решает две группы задач:

1) при незначительной неисправности - откат в выполнении текущей транзакции;

2) при существенных отказах - минимизация работы по восстановлению РБД.

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

Копирование изменений возможно после закрытия БД. Однако для РБД с интенсивными обновлениями копирование (архивацию) следует проводить в процессе работы РБД.

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

Процедура восстановления проводится следующим образом.

1. Устраняется аппаратный сбой.

2. Восстанавливаются испорченные файлы данных путем копирования архивных копий и групп регистрации транзакций.

3. Запускается процесс восстановления:

а) с применением транзакций (применение к архивным копиям испорченных данных необходимых групп журнала транзакций);

б) с отменой - отмена незавершенных транзакций, оставшихся после восстановления с применением транзакций.

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

Изучим подробнее процесс отказа.

Возможно выделить следующие основные состояния узла: исправный, неисправный (застопоривший, неуправляемый), восстанавливаемый.

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

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

Обсудим два возможных случая работы узлов в надежной сети: без дублирования и с дублированием данных.

При отсутствии дублирования не рассматриваются неуправляемые узлы (узлы с потерей управления).

Обычно одна транзакция при удаленном вызове (рис. 14.1) делится на серию субтранзакций.

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

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

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

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

Может быть частичное и полное (в каждом узле находится полная копия РБД) дублирование.

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

Достоинствами метода основной копии являются единственная последовательность корректировки БД и уменьшение вероятности тупика.

В случае чтения во всех доступных узлах и использования активных узлов формируется и вводится список U записей об активных узлах, а основной узел используется для восстановления. «Основная» транзакция при обновлении должна запрашивать обстановку для записи и корректировки данных во всех узлах списка U, включая основной. Удается избежать некоторых конфликтов (чтение-запись, запись-запись), когда система полностью работоспособна. При наличии отказов и восстановлений список U меняется основным узлом и может возникнуть осложнение.

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

Пример 14.2. Пусть узел 2 восстановился. Он запрашивает информацию о пропущенных транзакциях. Основной узел передает данные по транзакциям T₁,..., T_n и добавляет узел 2 в список U. Однако транзакция T_n+1, находящаяся в состоянии фиксации, имеет старый список и не будет записывать в узел 2.

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

Возможны и другие методы [ ]:

1) выбор нового основного узла при отказе прежнего, при этом прежний узел должен быть восстанавливаемым, а новый - «видеть» обстановку, сложившуюся в прежнем узле. Доступ упрощается, но усложняется восстановление.

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

Схема восстановления одного из узлов показана на рис. 14.4.

Пусть в момент t₁ отказал узел 2 и его БД разрушилась. Если узел 2 не будет исправлен до момента времени t₅, то отказ узла 1 или 2 приведет к серьезному сбою. Узел 2 выявляет свой отказ к моменту t₂ и начинает восстанавливаться, используя «снимки» других узлов. На интервале t₃ - t₄ исправные узлы должны продолжать выполнение транзакций, которые должен запоминать узел 2 (и обрабатывать после момента t₄). С момента t₄ узел 2 присоединяется к остальным и система может выдержать второй отказ.

Меры преодоления проблем нарушения физической целостности:

1. введение копии базы данных

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

 

	RAID-массивы

Рис.1

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

Рис.2

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