Обеспечение целостности данных. Ограничения целостности

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

1. Значения первичного ключа любого отношения (файла) должны быть уникальны. СУБД должна отклонить любую попытку ввести в БД запись со значением уже имевшегося ключа. 2. Возможны и вторые уникальные ключи.

СУБД поддерживает также ограничения логической и семантической целостности реальных значений данных, хранимых в БД, которые требуют, чтобы значение поля принадлежало некоторому диапазону значений, либо выражают некоторое арифметическое соотношение между значениями различных полей, например: 1. Между значениями полей А и В должно всегда выполняться со отношение (А) >=( В).

2. Значения некоторого атрибута ограничивается заданным диапазоном.

3. Для некоторого атрибута (или их комбинации) мажет существовать конечный, небольшой по размеру набор допустимых значений (например, по атрибуту ОБРАЗОВАНИЕ могут быть только значения НАЧАЛЬНОЕ, НЕПОЛНОЕ СРЕДНЕЕ, СРЕДНЕЕ, НЕПОЛНОЕ ВЫСШЕЕ, ВЫСШЕЕ).

4. Значения некоторого атрибута должны удовлетворять определенному формату.

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

6. Множество значений некоторого столбца файла является под множеством значений другого столбца этого файла. Указанные (и другие) ограничения специфицируются специальными выражениями или фразами ЯМД.

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

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

Чтобы уменьшить вероятность разрушения файлов (баз данных их необходимо резервировать. Возможны следующие стратегии резервирования.

1. Хранится некоторое число копий используемых файлов. Если основной файл разрушился, то используется первая его копия, если и она разрушилась, то используется следующая и т.д.

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

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

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