Целостность и сохранность баз данных

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

Рассмотрим различные типы ограничений целостности в языке SQL:

1. Уникальность значения первичного ключа (PRIMARY KEY).
2. Уникальность ключевого поля или комбинации значений ключевых полей:

UNIQUE(A),

где A – один или несколько атрибутов, указанных через запятую.

(1,2 – явные структурные ограничения целостности.)

1. Обязательность/необязательность значения (NOT NULL/NULL).
2. Задание диапазона значений атрибута Field:

CHECK(field BETWEEN min_value AND max_value)

1. Задание взаимоотношений между значениями атрибутов Field1 и Field2:

CHECK (field1 @ field2),где @ – оператор отношения (например, знак ">").

1. Задание списка возможных значений (констант) для атрибута Field:

CHECK (field IN (value1, value2,…, valueN)).

1. Определение формата атрибута Field (даты, числа и др.). Например:

CHECK (field LIKE '_ _ _-_ _-_ _') -- формат телефонного номера

1. Определение домена атрибута на основе значений другого атри Определение формата атрибута Field (даты, числа и др.). Например:
2. бута: множество значений некоторого атрибута отношения является под-множеством значений другого атрибута этого или другого отношения (внешний ключ, FOREIGN KEY)./li>

(3.-8. – явные ограничения целостности на значения данных.)

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

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

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

Обеспечение безопасности данных

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

Виды сбоев

В СУБД предусмотрены специальные механизмы, призванные нивелировать последствия сбоев в работе базы данных. Рассмотрим наиболее типичные сбои и способы защиты от них:

1. Сбой предложения.

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

1. Сбой пользовательского процесса.

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

1. Сбой процесса сервера.

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

1. Сбой носителя (диска).

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

1. Ошибка пользователя.

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

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