КаталогИндекс раздела

ОПЫТ БОРЬБЫ ЗА ЦЕЛОСТНОСТЬ ДАННЫХ В УСЛОВИЯХ НЕЧЕТКИХ СПЕЦИФИКАЦИЙ

А.С.ДЕРЕВЯНКО


Опубликовано в:

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

Любое руководство по созданию баз данных (БД) содержит рекомендации начинать проектирование с исчерпывающего исследования предметной области и построения инфологической и концептуальной моделей, включающих в себя описание ограничений целостности (см., напр. [1]). Такое моделирование возможно только при условии тесного сотрудничества между разработчиками и представителями заказчика, являющимися экспертами в предметной области. Но на практике добросовестное участие экспертов заказчика на этом этапе работы не всегда достижимо. Психологии заказчика в наших условиях можно было бы посвятить отдельную (и не одну) статью, здесь же мы отметим только, что вопросы интеграции данных в единую автоматизированную информационную систему (АИС) и обеспечения непротиворечивости этих данных, как правило, не относятся к тому кругу решений, которые с самого начала осознаются заказчиком, как необходимые. Занятие же разработчиком жесткой позиции в этом отношении зачастую может привести просто к потере заказа. Отсюда вытекает нечеткость и недостоверность исходных спецификаций АИС, вырабатываемых на начальном этапе проектирования, и необходимость их частых коррекций уже в ходе эксплуатации АИС.

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

Нам пришлось столкнуться с подобными условиями при проектировании и внедрении АИС, созданной по заказу Харьковской облгосадминистрации, для учета лиц, пострадавших вследствие аварии на ЧАЭС. Главная задача АИС - учет удостоверений - обеспечивается БД, содержащей более 30 тыс. записей в основной таблице, кроме того, АИС обеспечивает ряд частных прикладных задач (учет оздоровления, квартирный учет и т.д.), обеспечиваемых расширениями БД, интегрированными с основной таблицей. С самого начала разработчики ставили своей целью создание интегрированной многопользовательской БД, функционирующей в архитектуре клиент/сервер [2]. Это определило применение довольно мощной ПЭВМ в качестве сервера (IBM PC Server 310), и промышленной СУБД в качестве сервера БД (IBM DB2 v.2.1). Естественно, что соответствующие подходы были заложены и в структуру БД и приложений. Однако, следующий ряд обстоятельств чрезвычайно осложнил деятельность разработчиков.

  1. Начальный формат информации, которая должна храниться в БД, был выработан недобросовестно: с большим количеством лишней информации и недостачей некоторой необходимой информации. Даже "естественные" первичные ключи были определены неточно, что выяснилось только впоследствии.
  2. Первичный сбор и ввод информации производился рассредоточено (в более чем 40 филиалах), часто с привлечением неквалифицированного персонала. При вводе данных, полученных с мест, до 30% данных выбраковывалось по базовым ограничениям целостности из-за ошибок операторов. После исправления ошибок отбраковка составляла менее 1% и в основном отражала существенные ошибки в ведении исходной документации.
  3. Ввод в эксплуатацию ряда частных прикладных задач начался еще до окончания формирования основных таблиц БД, это привело к необходимости временного дублирования части информации основной БД в таблицах прикладных задач. При последующей интеграции временных таблиц с основной БД выявлялось до 60% нарушений ссылочной целостности. После устранения ошибок ввода число нарушений снизилось примерно до 3%, причем нарушения опять-таки отражали ошибки в исходной документации.
  4. Хронический дефицит людских ресурсов у заказчика не позволяет гарантировать оперативное устранение ошибок в исходных данных. Так, решение некоторых локальных проблем, связанных с неуникальностью естественных первичных ключей, растягивалось на месяцы.
  5. Прикладная область является притягательным полем деятельности для мошенников и лиц, стремящихся получить незаслуженные льготы. Например, только в Харьковском метрополитене еженедельно изымается 5-6 поддельных удостоверений чернобыльцев. Результаты противозаконной деятельности во многих случаях могут быть обнаружены в БД как нарушения целостности.

Может сложиться впечатление, что перечисленные выше осложняющие обстоятельства являются субъективными, связанными с недостатком ресурсов у заказчика и/или разработчика. Но, во-первых, ситуация нехватки ресурсов является достаточно типичной для наших условий. Во-вторых, мы возьмем на себя смелость утверждать, что можно обозначить определенный класс систем, для которых немедленное устранение "шума" во входных данных обходится слишком дорого. Такая система не должна требовать абсолютной внутренней целостности информации, а лишь поддерживать целостность на некотором необходимом и достаточном уровне.

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

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

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

  1. На начальном этапе разработки декларативные ограничения целостности практически не вводились вообще. Основным мероприятием, обеспечивающим правильность вводимой информации, являлась замена везде, где только возможно, ввода оператором текстовой информации выбором из меню. Причем, если при пуске АИС в эксплуатацию оператор мог как выбирать из меню, так и вводить текст, отсутствующий в меню, то очень скоро от второй возможности пришлось отказаться, поскольку она являлась постоянным источником ошибок. Та часть БД, которая выглядит для пользователя как основная таблица, в действительности помимо основной таблицы содержит еще и несколько таблиц-расширений. Для расширений с самого начала декларативно описывалась ссылочная целостность через внешние ключи, поскольку они принадлежат к внутренней (прозрачной для конечного пользователя) структуре БД, и поддержание целостности в этой структуре - внутренняя функция программного обеспечения БД.
  2. Опыт начальной эксплуатации АИС позволил определить некоторые минимальные ограничения целостности, которые стало возможно ввести декларативно, не рискуя потерять важные данные. Эти определения касались прежде всего создания доменов - типов данных для отдельных столбцов таблиц с определением диапазона возможных их значений. Большинство этих ограничений находили непосредственное отражение в составе меню, предлагаемых оператору при вводе данных.
  3. Следующий этап эксплуатации АИС характеризовался прежде всего вводом в БД информации, поступающей из различных, часто удаленных источников. На этом этапе стали обнаруживаться нарушения ограничений целостности, связанные с уникальностью значений и соотношениями между значениями в столбцах. Поскольку простая отбраковка записей, нарушающих целостность, была признана нецелесообразной, пришлось допустить наличие в БД таких записей. Вместе с тем был разработан ряд автономных процедур (SQL-скриптов), выполняемых администратором данных, которые должны были выявлять такие записи и составлять "таблицы исключений". Впоследствии по "таблицам исключений" квалифицированный персонал проводил исправления ошибок. В записях же, содержащих существенные нарушения целостности (например, неуникальные естественные первичные ключи) устанавливался признак недостоверности, и во все экранные формы, задающие выборки из БД, вводилось поле параметра, определяющего выполнение выборки с участием недостоверных записей или без них.
  4. Когда была накоплена достаточная информация о типовых нарушениях целостности, в БД на декларативном уровне были введены соответствующие именованные ограничения целостности. Но штатный режим функционирования АИС предусматривает отключенное состояние этих ограничений (SET INTEGRITY OFF ...). Включение ограничений производится только при выполнении специальных процедур проверки целостности.
  5. Следующим шагом развития АИС явилось внедрение триггеров для таблиц БД. Основные функции триггеров состоят в проверке ограничений целостности для вносимых или модифицированных записей и автоматическое выставление признака недостоверности. Одновременно триггеры служат средствам аудита изменений в БД.
  6. Автоматическая оценка достоверности и составление "таблиц исключений" продолжали развиваться с внедрением в разработку хранимых процедур. Основным назначением хранимых процедур было выполнение сложных транзакций, реализующих основную функциональность АИС. Побочным эффектом этого явилось повышение гарантий сохранения целостности, прежде всего - ссылочной целостности. Естественным стало также стремление разработчиков вложить в хранимые процедуры и проверку сложных ограничений целостности, которые не могли быть заданы декларативно или определены в триггерах.

В связи с темой нашей статьи следует отметить важность роли администратора данных, как работника, ответственного за "принятие решений, связанных с данными предприятия", а не за техническую поддержку СУБД и приложений [1]. Для разработчиков с самого начала, важность этой роли не составляла секрета. С расширением эксплуатации системы важность этой роли стала осознаваться и заказчиком. При уже отмечавшемся дефиците людских ресурсов у заказчика довольно скоро стало очевидным, что в те периоды, когда администратор данных имел возможность выполнять эту свою функцию в течение полного рабочего дня, резко сокращалось число конфликтных ситуаций с учетным контингентом, а следовательно - и общая нагрузка на персонал заказчика. Существенный прогресс в этом отношении был достигнут после проведения обучения персонала заказчика по программе "Администрирование СУБД и администрирование данных".

Ближайшая перспектива развития АИС - обеспечение электронной связи с филиалами - источниками данных. Естественно, что такая связь создаст дополнительные проблемы сохранения целостности. Разработчики планируют решать эти проблемы за счет свойств, изначально заложенных в архитектуру системы. Хотя аппаратные средства АИС соответствуют двухзвенной архитектуре клиент/сервер, программное обеспечение реализует архитектуру трехзвенную: между клиентом и сервером БД имеется еще программный сервер приложений (выполняющийся на ЭВМ-сервере) [2]. Планируется возложить на сервер приложений организацию приема данных из удаленных источников, проверки соответствия их правилам целостности и занесения их в БД и/или в таблицы исключений.

Литература

  1. Дейт К. Дж. Введение в системы баз данных. - К.: Диалектика, 1998.
  2. Гендельман Т.В., Деревянко А.С., Солощук М.Н., Штир Х. О путях и средствах развития автоматизированных информационных систем административного назначения. - Вестник ХГПУ, вып. 72, Харьков: ХГПУ, 1999, с. 80-85.

КаталогИндекс раздела