Ограничения целостности.

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

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

Отношение «Студенты» Отношение «Оценки студентов»

№ зач.	Груп-па	ФИО Студента	Дата рожд.		№ зач.	Шифр Курса	Оцен-ка
4567	5203	Петров	01.10.80		4567	М	3
4568	5203	Иванов	14.05.79		4567	Ф	3
4569	5104	Сидоров	17.08.80		4567	А	4
					4568	М	5
					4568	Ф	5
					4569	М	4

Представим себе, что оператор, вследствие какой- либо ошибки изменяет значение атрибута «№ зач.» в таблице «Студенты» с 4568 на 4567 (предположим, что такая операция возможна). Тогда аналогичная замена должна произойти и в таблице «Оценки студентов», в противном случае данные об оценках студента с номером зачетки 4568 будут потеряны. Но после такого изменения оценки студентов Петрова и Иванова будет невозможно разделить средствами сопровождения базы данных, поскольку отличаются они лишь первичным ключом. Очевидно, что подобные конфликты возможны не только при изменении значений полей, но также при вставке и удалении. Способом устранения таких противоречий является формулировка (и соблюдение) правил, накладывающих ограничения на изменения полей связных таблиц. Такой набор правил называется ограничениями целостности данных. Формулируются ограничения целостности исходя из особенностей предметной области, а также из особенностей реализации связи.

В данной ситуации таблица «Студенты» будет называться порождающей, родительской (parent), а таблица «Оценки студентов» - порожденной, дочерней (child). Формальная разница между ними заключается в том, что в отношении «Студенты» поле № зач. является первичным ключом, а в отношении «Оценки студентов» то же поле является внешним ключом. Ранее было показано, что в корректно спроектированной базе данных для каждого ключевого поля возможно только одно порождающее отношение и несколько (сколько угодно) дочерних отношений. Для каждой из таблиц пары «порождающий – дочерний» должны быть сформулированы ограничения целостности отдельно для вставки, обновления и удаления данных.

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

При обновлении значений поля № зач в таблице «Студенты» накладываются требования во- первых, на уникальность нового значения ключа, а во – вторых, одновременно должны измениться и значения соответствующего внешнего ключа в порожденной таблице (или таблицах, если их несколько). Здесь следует отметить, что в момент выполнения этой операции невозможно соблюдение целостности данных в каждый момент времени; очевидно, что алгоритм смены номера зачетки должен выглядеть следующим образом: смена значения поля в таблице «Студенты», затем просмотр таблицы «Оценки студентов» с поиском старых значений ключа и заменой их на новое значение. Таким образом база данных из одного целостного состояния переводится в другое, но в процессе перехода нарушения целостности не только возможны, но и неизбежны. Сбой в обработке в момент изменения данных может привести к потере данных, поэтому следует принимать возможные меры для того, чтобы провести такое обновление как можно быстрее. Обновление ключевого поля в таблице «Оценки студентов» возможно проводить без каких- либо дополнительных действий, соблюдая лишь требование принадлежности множеству значений первичного ключа порождающей таблицы. Можно представить себе такое построение интерфейса пользователя, при котором смену внешнего ключа дочерней таблицы можно вообще запретить. В случае с оценками студента смена значения поля № зач. соответствует «передаче» оценки от одного студента другому. Возможно, если в прикладной программе предложить пользователю удалить ошибочно введенную оценку, а затем ввести ее снова, то интерфейс пользователя станет проще и «прозрачнее».

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

Технически соблюдение требований целостности можно осуществлять на уровне интерфейса пользователя, т.е. в приложениях. В этом случае каждая попытка изменения значений ключевых полей должна обрабатываться на предмет проверки допустимости этой операции. Многие современные СУБД, особенно те из них, что ориентированы на технологию «клиент – сервер», предоставляют разработчику еще один способ отслеживания ограничений целостности. Процедуры проверки корректности изменений хранятся не в клиентских приложениях, а в приложении – сервере, в виде т. наз. триггеров. Запуск их производится сервером автоматически, при каждой попытке изменения ключевых полей, независимо от того, какое приложение вызвало эти изменения. Операции изменения данных производятся на сервере, а не на рабочих станциях, которые передают на сервер запросы на изменения. При этом, кроме повышения скорости работы приложений и снижения нагрузки на локальную сеть происходит и заметное повышение надежности хранения данных, так как компьютер - сервер как правило более надежен и отказоустойчив, а приложение – сервер обладает дополнительными средствами защиты данных. Кроме того, использование триггеров для контроля изменений существенно упрощает разработку клиентских приложений, в которых до 30 – 50 % всего кода составляет именно реализация защиты целостности данных.

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

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

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

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

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