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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение.

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

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

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

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

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

Наконец, сама предметная область с течением времени может изменяться под влиянием каких – либо внешних обстоятельств.

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

[1] Естественно, что такая нотация не имеет ничего общего с форматом команд реальных СУБД, где присутствуют эти операции. Здесь эти обозначения вводятся для краткости записи, а также для того, чтобы не отвлекать читателя (пока) на изучение синтаксиса реальных языков манипулирования данными. Далее будет рассмотрено, как эти операции реализуются в стандартах языков Xbase и SQL.

[2] Этот прием, хотя и широко применяется в проектировании БД, был известен задолго до появления первых компьютеров. Те же табельные марки работников применяются как минимум с XIX века.

[3] Время поиска увеличивается при увеличении объема таблицы, хотя эта зависимость имеет нелинейный характер.

[4] Читатели, знакомые с основами ООП могли заметить, что приведенное определение почти совпадает с определением класса, принятом в объектно – ориентированном проектировании.

[5] Данный пример был выбран именно за то, что при почти всех сочетаниях классов принадлежности и степеней связи приводит к осмысленной в житейском смысле ситуации. Однако, некоторые сочетания этих параметров приводят к ситуации, которою любой здравомыслящий администратор всеми силами постарался бы избежать.

[6] Подробнее вопросы целостности данных будут рассмотрены ниже.

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

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

Дата добавления: 2015-07-19