Одним из основополагающих понятий в технологии баз данных является понятие целостности. В общем случае это понятие, прежде всего, связано с тем, что база данных отражает в информационном виде некоторый объект реального мира или совокупность взаимосвязанных объектов реального мира. В реляционной модели объекты реального мира представлены в виде совокупности взаимосвязанных отношений. Под целостностью будем понимать соответствие информационной модели предметной области, хранимой в базе данных, объектам реального мира и их взаимосвязям в каждый момент времени.
Любое изменение в предметной области, значимое для построенной модели, должно отражаться в базе данных, и при этом должна сохраняться однозначная интерпретация информационной модели в терминах предметной области.
В модели данных должны быть предусмотрены средства и методы, которые позволят обеспечивать динамическое отслеживание в базе данных согласованных действии, связанных с согласованным изменением информации.
Поддержка целостности в реляционной модели данных в ее классическом понимании включает в себя 3 аспекта.
Во - первых это поддержка структурной целостности, которая трактуется как то, что реляционная СУБД должна допускать работу только с однородными структурами данных типа «реляционное отношение». При этом понятие <реляционного отношения > должно удовлетворять всем ограничениям, накладываемым на него в классической теории реляционной БД (отсутствие дубликатов кортежей, соответственно обязательное наличие первичного ключа, отсутствие понятия упорядоченности кортежей).
В дополнение к структурной целостности необходимо рассмотреть проблему неопределенных Null значений. Неопределенное значение интерпретируется в реляционной модели как значение неизвестное на данный момент времени. Это значение при появлении дополнительной информации в любой момент времени может быть заменено на некоторое конкретное значение. При сравнении неопределенных значений не действуют стандартные правила сравнения. Одно неопределенное значение никогда не считается равным другому неопределенному значению. Для выявления равенства значения некоторого атрибута неопределенному значению применяют стандартные специальные операторы:
<имя атрибута>IS NULL и <имя атрибута> IS NOT NULL.
Если в данном кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то предикат IS NULL принимает значение TRUE (Истина), а предикат IS NOT NULL — FALSE (Ложь), в противном случае предикат IS NULL принимает значение FALSE а предикат IS NOT NULL принимает значение TRUE.
В стандарте SQL2 появилась возможность сравнивать не только конкретные значения атрибутов с неопределенным значением, но и результаты логических выражений сравнивать с неопределенным значением, для этого введена специальная логическая константа UNKNOWN. В этом случае операция сравнения выглядит так. Логическое выражение> IS {TRUE | FALSE | UNKNOWN}
Во вторых, это поддержка языковой целостности, которая состоит в том, что реляционная СУБД должна обеспечивать языки описания и манипулирования данными не ниже стандарта SQL. He должны быть доступны иные низкоуровневые средства манипулирования данными, не соответствующие стандарту.
Именно поэтому доступ к информации, хранимой в базе данных, и любые изменения этой информации могут быть выполнены только с использованием опреаторов языка SQL.
В третьих, это поддержка ссылочной целостности (Declarative Referential Integrity, DRI).
При поддержании ссылочной целостности между главной и подчиненной таблицами часто используются следующие правила:
• подчиненная строка не может быть вставлена, пока не существует главная строка. Например, нельзя ввести записи позиций счет - фактуры, пока в главной таблице не появится запись счета. Однако в поле внешнего ключа возможен ввод пустых значений, показывающих, что записи только подготавливаются и пока не являются связанными;
• главная строка не может быть удалена до удаления всех подчиненных строк. Например, нельзя удалить запись счет - фактуры, если в подчиненной таблице имеются записи позиций счета;
• если значение первичного ключа в главной строке изменено, все значения внешнего ключа, которые обращаются к этому значению первичного ключа, должны быть также обновлены; и наоборот, нельзя изменить значение ключевого поля в главной таблице, если существуют связанные записи.
Чтобы наложить эти правила на конкретную связь в СУБД Access, при ее создании следует установить флажок Обеспечение цело стности данных в окне Изменение связи. Если данный флажок установлен, то любая попытка выполнить действие, нарушающее одно из перечисленных выше правил, приведет к выводу на экран предупреждения, а само действие выполнено не будет.
Ссылочная целостность обеспечивает поддержку непротиворечивого состояния БД в процессе модификации данных при выполнении операций добавления или удаления.
С целью обеспечения целостности данных при создании приложений используются ограничения целостности.
Ограничение — некоторое ограничивающее условие. В базе данных — общее понятие, охватывающее широкий круг аспектов управления базой данных: ключи, значения, типы и форматы данных и т. д. Ограничения устанавливают для пользователя некоторые рамки при вводе, изменении или удалении данных приложения.
Например, ограничение можно использовать, чтобы гарантировать, что каждый служащий в базе данных будет относиться к какому-либо отделу или что пользователи не смогут случайно ввести отрицательное значение для цены товара.
Ограничения можно определять на двух уровнях:
В базе данных. Ограничения в базе данных ассоциируются с определениями объектов-таблиц. Например, для таблицы может быть установлено ограничение, которое требует, чтобы каждое значение в столбце было уникальным.
В приложении Access (в программном коде или свойствах объектов). Ограничения в приложении ассоциируются с объектами приложения, которые формируют интерфейс к информации базы данных. Например, текстовое поле может иметь ограничение, которое требует, чтобы все вводимые в него значения были больше 20.
Ограничения в базе данных. Ограничение в базе данных — декларативно определенное правило, ограничивающее значения, которые могут быть введены в столбец или набор столбцов в таблице. Ограничения базы данных являются декларативно определяемыми, так как определяют ограничения как часть структуры таблицы при ее создании или изменении.
Будучи однажды ассоциировано с таблицей, ограничение всегда поддерживается, если его явно не удалить или не деактивировать.
Размещение ограничений в базе данных имеет следующие преимущества:
Централизация. Ограничение базы данных определяется только один раз и может автоматически использоваться всеми клиентами, обращающимися к базе данных. Определение ограничения в базе данных освобождает разработчика от необходимости вносить одни и те же ограничения в каждую форму, которая использует данную информацию. Кроме того, при необходимости модифицировать ограничение изменения вносятся только в один объект;
Защита. Ограничения базы данных всегда поддерживаются, независимо от того, какой инструмент доступа к данным используется. С другой стороны, ограничения, определенные в приложении, могут быть нарушены пользователем, использующим для доступа к тем же таблицам другое приложение или инструмент;
Простота. Ограничения базы данных просты в определении и не требуют никакого программного кода.
Типы ограничений в базе данных. Типы ограничений, которые можно ассоциировать с таблицей, варьируются в зависимости от базы данных, в которой хранится эта таблица. Описанные ниже категории ограничений поддерживаются большинством реляционных баз данных, в том числе и Microsoft Access.
Ограничения Null или Not Null. Ограничения разрешают или запрещают ввод в столбец таблицы пустых значений. Оно всегда применяется к отдельным столбцам. Ограничения Not Null используются, чтобы гарантировать, что для важных данных всегда имеются значения. Например, это ограничение можно использовать, чтобы гарантировать, что в записи каждого служащего в базе данных был проставлен его оклад.
При определении структуры таблицы это ограничение в СУБД Access задается установкой значений свойств Обязательное поле и Пустые строки поля таблицы. Необходимо различать два типа пустых значений: пустые (Null) значения и пустые строки. В некоторых ситуациях поле может быть оставлено пустым потому, что данные для него либо существуют, но пока неизвестны, либо их не существует вовсе. В связи с этим и различают два типа пустых строк. Например, если в таблице есть поле "Номер факса", то оно может быть пустым потому, что пользователь не знает, есть ли у клиента номер факса или нет, или потому, что он знает, что номера факса у клиента нет. Таким образом, если поле имеет пустое (Null) значение, то это означает, что его значение неизвестно. Если же введена пустая строка (два знака прямых кавычек (" ")), то это означает, что строкового значения нет.
Ограничения Unique. Ограничение запрещает пользователю ввод в столбец или набор столбцов дублированных значений. Ограничение Unique может активироваться для отдельного столбца или для комбинации столбцов. В последнем случае ограничение Unique иногда называется составным ограничением Unique.
Ограничения Unique используются, чтобы гарантировать, что в таблице не будет дублированных значений столбцов. Например, оно может гарантировать, что каждому служащему в базе данных будет присвоен уникальный номер.
Ограничение Unique не запрещает пользователю ввод в таблицу нескольких пустых значений — пустое значение в столбце всегда удовлетворяет ограничению Unique. Чтобы предотвратить ввод в столбец с ограничением Unique пустых значений, к столбцу необходимо также добавить ограничение Not Null.
В Access ограничение Unique инициируется установкой значения " Да (Совпадения не допускаются)" для свойства Индексированное поле либо установкой значения " Да " для свойства Уникальный индекс.
Ограничения Primary Key. Ограничение Primary Key гарантирует, что каждая строка в таблице будет уникально идентифицирована значением в столбце или наборе столбцов первичного ключа. Ограничение по первичному ключу объединяет черты ограничения Unique и ограничения Not Null.
Обычно рекомендуется включать ограничение Primary Key в каждой создаваемой таблице. Использование первичного ключа может значительно повысить быстродействие доступа к строкам таблицы. Ограничение Primary Key также используется для поддержания ссылочной целостности, когда в базе данных определены отношения один – ко - многим. Установка ссылочной целостности позволяет поддерживать соответствие между главной и подчиненной таблицами. Для поддержания ссылочной целостности ограничения Primary Key используются в комбинации с ограничениями Foreign Key, описанными ниже.
Некоторые СУБД (такие, как Access) могут автоматически поддерживать полную ссылочную целостность после создания ограничений Foreign Key и Primary Key. В других базах данных (таких, как SQL Server ранних версий) необходимо определить обработку ссылочной целостности отдельно (обычно в триггере). Однако в любом случае, чтобы установить в базе данных правила ссылочной целостности, необходимо определить ограничения Primary Key и Foreign Key.
Примечание: Установить правила ссылочной целостности можно также в приложении. Поддержание ссылочной целостности на уровне приложения не требует специфицирования ограничений Primary Key и Foreign Key, однако в этом случае все требуемые процедуры и правила должны быть реализованы программным способом.
Ограничения Foreign Key. Ограничение Foreign Key (внешний ключ) гарантирует, что каждое значение, введенное в столбец, уже существует в некотором другом столбце (обычно в другой таблице). Ограничения Foreign Key обычно используются для поддержания ссылочной целостности, когда в базе данных определены отношения один – ко - многим. Ограничения Foreign Key всегда используются вместе с ограничениями Primary Key (описанными в предыдущем разделе).
В отношении один –ко - многим внешний ключ — столбец в подчиненной таблице, которая содержит идентификатор строки в главной таблице. Значение в столбце внешнего ключа равно значению в столбце первичного ключа в другой таблице.
В отношении один – к - одному каждая строка в подчиненной таблице соответствует уникальной строке в главной таблице. В отношении один – ко - многим одной строке в главной таблице может соответствовать любое количество строк в подчиненной таблице.
Кроме рассмотренных ограничений целостности существуют:
1. Ограничения реальных значений данных, хранимых в БД, чтобы значение поля принадлежало некоторому диапазону значений, либо соблюдалось некоторое арифметическое соответствие между значениями различных полей.
2. В заданном отношении для каждого кортежа между значениями полей А и В должно всегда выполняться условие, что первое больше второго.
3. Значения, которые принимает некоторый атрибут, должны быть ограничены заданным диапазоном.
4. Для некоторого атрибута (или комбинации атрибутов) может существовать конечный, небольшой по размеру набор допустимых значений (например, по атрибуту ОБРАЗОВАНИЕ может быть только значения НАЧАЛЬНОЕ, НЕПОЛНОЕ СРЕДНЕЕ, СРЕДНЕЕ, НЕПОЛНОЕ ВЫСШЕЕ, ВЫСШЕЕ).
5. Значение некоторого атрибута должны удовлетворять определенному формату.
5. Множество значений одного из атрибутов отношения должно удовлетворять некоторому статическому условию. Например, конкретное значение не должно превышать более чем в два раза среднее значение.
7. Множество значений некоторого столбца отношения является подмножеством значений другого столбца этого отношения.
Кроме перечисленных, существуют и другие ограничения целостности. Например, ограничения на условия выполнения параллельных операций над данными в базе; ограничения типа "старый" - "новый", когда БД переходит в новое состояние.
Описание ограничений целостности содержит две части. В первой из них выражается само ограничение, во второй описывается, когда, при каких условиях должна выполняться проверка. Язык манипулирования данными реальных систем позволяют в той или иной мере поддерживать многие из рассмотренных ограничений целостности.
2.3. Организация параллельных процессов обработки данных
Наглядным примером автоматизированных систем, в которых над базой данных требуется параллельно выполнять ряд процессов обработки, являются системы продажи авиа- или железнодорожных билетов. В этих системах к общей БД одновременный доступ имеют многие операторы, работающие в различных транспортных агентствах, но выполняющие одни и те же функции по продаже билетов пассажирам. Так как оператор не только читает данные из БД (поиск свободных мест на требуемые рейсы), но и вносит изменения в базу (отмечает проданные места, отмечает возвращенные билеты), то необходимо принимать специальные меры для исключения возможности продажи билетов на одно и то же место нескольким пассажирам.
Если бы выполнялись только операции чтения данных из БД, и не было никаких операций записи данных, то проблемы с организацией параллельных процессов обработки над одними и теми же данными не существовало бы. В таком случае следует максимально стремиться к использованию параллелизма а работе системы, чтобы повысить ее производительность. Примером подобных систем служит любая информационно-справочная система, в которой пользователям разрешен только режим чтения данных из БД и в период, когда работают пользователи, никаких изменений данных не производится.
Однако как только пользователи получают возможность выполнять операции изменения одних и тех же данных в БД, ситуация изменяется. Вернемся к системе продажи билетов. Например, три различных оператора, находясь в различных транспортных агенствах города, одновременно запросили один билет до Москвы на 1 февраля, в поезде N 351, в купейном вагоне. В этом случае будет независимо друг от друга выполнено три процесса (транзакции). Транзакция - это разовое выполнение некоторой программы (программа может быть сложной прикладной, выраженной на одном из языков программирования, а может быть реализацией простого запроса, выраженного на языке запросов системы).
Независимо от того, выполняется ли несколько независимых прогонов одной и той же программы или выполняется независимо несколько различных программ, каждая из самостоятельных реализаций самой программы считается отдельной транзакцией. Если в период выполнения этих трех транзакций в БД не поступало от других операторов системы изменений (именно на этот поезд, на это число, на места в купейных вагонах), то, поскольку трижды выполняется одна и та же программа, будет получено три одинаковых ответа. Если места удовлетворяют пассажиров, то каждый оператор посылает в систему сообщение, что место продано (будет также выполнено три транзакции, но уже другой программы, которая проставляет "месту" признак, что оно продано, т.е. первая транзакция поставит признак, а две другие его повторят).
Решение этой проблемы заключается в недопущении параллельного исполнения двух и более транзакций, в которых выполняется чтение и изменение одних и тех же данных.
Блокировки. Решение задачи защиты данных при параллельном доступе заключается во введение блокировок для доступа к данным. Прежде чем прочитать некоторое данное X, транзакция T1 обязана его заблокировать: УСТАНОВИТЬ - БЛОКИРОВКУ X. Блокировка предотвращает доступ к этому данному другой транзакции Т2. Транзакция Т2 должна ждать, пока транзакция T1 не закончит работу с данным Х и не разблокирует его: СНЯТЬ -БЛОКИРОВКУ X. Если некоторая транзакция пытается блокировать уже блокированный элемент, она становится в очередь на ожидание, пока блокировка с этого элемента данных не будет снята.
Для реализации механизма блокировок база разбивается структурно на элементы, которые можно блокировать. Выбор характера и размера элементов, подлежащих блокированию, выполняется исходя из специфики решаемых системой функциональных (прикладных) задач. Выбор больших по размеру элементов, подлежащих блокированию (например, отношений), снижает расходы ресурсов по поддержанию блокировок, однако снижает также и возможности параллельного исполнения процессов. Выбор малых по размеру элементов, подлежащих блокированию (например, кортежей или даже атрибутов), увеличивает возможности системы с точки зрения параллельного исполнения транзакций, однако увеличивает и затраты ресурсов системы на поддержание блокировок.
Модели блокировок. Для блокировки могут использоваться простая модель и модель с блокировкой для чтения и записи. Рассмотрим эти модели.
Простая модель. В данной модели не вводится различие блокировок для операции чтения или операции записи элемента X. Установление блокировки предотвращает доступ к элементу X от других транзакций как по операции чтения, так и по операции записи до тех пор, пока этот элемент не будет разблокирован.
Модель с блокировками для чтения и записи. В данной модели имеется два вида доступа к элементу X: доступ только для чтения, доступ для чтения и записи. Соответственно различают два типа команд блокировки.
1. Команда блокировки элемента Х по чтению. Транзакция, в которой требуется выполнить только чтение элемента X, осуществляет его блокировку по чтению. Блокировка по чтению запрещает любой другой транзакции выполнять запись нового значения элемента X, пока он не будет разблокирован. Блокировку элемента Х по чтению могут одновременно устанавливать несколько транзакций (т.е. допускается параллельная работа по чтению данных для нескольких транзакций).
2. Команда блокировки элемента Х по записи. Команда блокировки по записи соответствует команде блокировки в простой модели, т.е. предотвращается доступ к элементу Х от других транзакций по чтению и по записи. Если некоторая транзакция установила блокировку элемента Х по записи, то никакая другая транзакция не сможет его заблокировать ни по записи, ни по чтению. Блокировка по чтению и блокировка по записи снимается одной командой; СНЯТЬ - БЛОКИРОВКУ X. В модели допускается, что транзакция может вначале устанавливать блокировку элемента X по чтению, а затем блокировку элемента X по записи.
Ожидание и тупики. При использовании механизма блокировок сталкиваются с такими двумя нежелательными явлениями, как бесконечные ожидания и тупиковые ситуации.
Бесконечные ожидания могут, при определенных условиях, появится в любой системе с параллельным выполнением процессов. Например, элемент Х заблокирован выполняющейся транзакцией T1. Поступившая в систему транзакция Т2, которой необходима работа с этим элементом, переходит в состояние ожидания. В момент разблокировки элемента Х транзакцией T1, в систему поступает транзакция Т3, которой также требуется элемент Х и перехватывает инициативу по его блокировке и т.д. В таких условиях не исключена возможность, что транзакция Т2 будет все время находится в состоянии ожидания. Чтобы избежать бесконечного ожидания, система блокировок должна регистрировать все поступившие запросы и предоставлять им возможность блокировок требуемых элементов по правилу “первый вошел - первый обслуживается”.
Для пояснения тупиковой ситуации рассмотрим алгоритм двух программ П1 и П2.
Программа П1
1 шаг - войти в программу;
2 шаг - установить блокировку А;
3 шаг - читать А;
4 шаг - установить блокировку В;
5 шаг - читать В;
5 шаг - выполнить совместную обработку А и В;
7 шаг - писать А;
8 шаг - снять блокировку с А;
9 шаг - писать В;
10 шаг - снять блокировку с В;
11 шаг - выйти из программы.
Программа П2
1 шаг - войти в программу;
2 шаг - установить блокировку В;
3 шаг - читать В;
4 шаг - установить блокировку А;
5 шаг - читать А;
5 шаг - установить блокировку С;
7 шаг - читать С;
8 шаг - выполнить совместную обработку А, В и С;
9 шаг - писать В;
10 шаг - снять блокировку с В;
11 шаг - писать А;
12 шаг - с н я т ь б л о к и р о в к у с А;
13 шаг - писать С;
14 шаг - снять блокировку с А;
15 шаг - выйти из программы.
При попытке параллельного исполнения двух транзакций Т1 - выполнение программы П1, а Т2 - выполнение программы П2, они заблокируют друг друга и возникнет тупиковая ситуация. Вначале Т1 заблокирует элемент А, а Т2 - элемент В. Здесь никаких осложнений нет, элементы различны и система разрешает транзакциям Т1 и Т2 выполняться параллельно. Закончив 3-й шаг, транзакции Т1 и Т2 перейдут в состояние ожидания: транзакция T1 будет ждать разблокировки элемента В, заблокированного транзакцией Т2; транзакция Т2 будет ждать разблокировки элемента А, заблокированного транзакцией Т1. Ни одна транзакция не может продолжаться из-за блокировок общих элементов. Это и есть тупиковая ситуация.
Существуют следующие подходы к разрешению тупиковых ситуаций.
1.Выполняется линейное упорядочение элементов по любому принципу (например, последовательно перечислить все элементы БД, подлежащих блокированию) и вводится системное требование на составление программ, т.е. все программы должны выполнять блокировки в определенном порядке. Все транзакции будут запрашивать блокировки в соответствии с принятой, единой для всех упорядоченностью элементов, что предотвратит тупики.
2.Вводится системное требование, чтобы в каждой программе все блокировки запрашивались сразу. Каждая транзакция будет единовременно запрашивать все необходимые ей блокировки. Это позволит СУБД выполнять управление транзакциями без тупиковых ситуаций.
3. Не вводится никаких системных требований на написание программ. В этом случае СУБД следит за возникновением тупиковых ситуаций. При обнаружении тупика действие одной из транзакций аннулируется, все выполненные ею изменения в БД устраняются. Транзакция переводится в состояние ожидания, и через некоторое время выполняется ее рестарт или полностью аннулируется. Чтобы выполнить рестарт или аннулирование транзакции, СУБД фиксирует транзакцию, записывая для каждой транзакции ее идентификатор, все произведенные ею вычисления, время начала и завершения. Такая информация позволяет в случае системного сбоя выполнить также рестарт всех зафиксированных транзакций, которые не успели успешно завершиться.
Восстановление БД
Возникновение сбоя в аппаратном или программном обеспечении может вызвать необходимость восстановления и быстрого возращения в состояние, по возможности близкое к тому, которое было перед возникновением сбоя. Причинами сбоев могут являться отключение питания, отказ аппаратуры, системно-программные ошибки, ошибки пользователей в управлении данными и т.д. К числу причин, вызывающих необходимость восстановления, можно отнести также и возникновение тупиковой ситуации.
Уровни восстановления.
Укрупнено можно выделить три уровня восстановления;
1. Оперативное восстановление. Характеризуется возможностью восстановления на уровне отдельного логического элемента работы при аномальном окончании управления данными (ошибка в программе, ошибка в аргументе и т.д.).
2. Промежуточное восстановление. Если возникают аномалии в системе (системно-программные ошибки, сбой аппаратного обеспечения не связанный с разрушением базы данных), то требуется восстановить состояние всех выполняемых логических элементов работы на момент возникновения сбоя.
3. Длительное восстановление. При разрушении базы данных в результате дефекта на диске осуществляют восстановление с помощью копии базы данных. Затем воспроизводят результаты выполненных с момента снятия копии логических элементов работы и возвращают систему в состояние на момент разрушения.
