Содержание к диссертации
Введение
1. Обеспечение целостности данных в автоматизи рованных системах 10
1.1. Требование достоверности и причины возникновения ошибок в данных 10
1.2. Достоверность и целостность данных. Методы обеспечения целостности 17
1.3. Современные концепции проектирования автоматизированных систем 23
1.4. Открытые проблемы проектирования и использования средств обеспечения целостности 32
Выводы 37
2. Построение и анализ баз данных, свободных от аномалий корректировок . 38
2.1. Анализ аномалий корректировок 38
2.2. Постановка и решение задачи проектирования концептуальной схемы базы данных 50
2.3. Постановка и решение задачи проектирования концептуальной схемы базы данных при ограничениях на внешние схемы 56
2.4. Ликвидация аномалий корректировок при проектировании баз данных минимальной избыточности 62
Выводы 68
3. Автоматизация программирования средств обеспечения семантической целостности 69
3.1. Построение концептуальной модели правил целостности 69
3.2. Анализ языков описания правил целостности 73
3.3. Язык концептуального описания правил целостности ЛИРА 82
3.4. Методика проектирования инструментальных средств обеспечения целостности 90
Выводы 94
4. Реажзащя и внедрение сріздств обеспечения целостности 95
4.1. Программное обеспечение систем генерации программ контроля . 95
4.2. Реализация инструментальных средств генерации программ контроля в системе ИНЕС 105
4.3. Практическое применение ППП "СОЦ-ИНЕС" 115
4.4. Применение методики проектирования баз данных в "Автоматизированной библиотечной системе" МИФИ 125
Выводы 130
Заключение 131
Литература 133
Приложение 141
- Требование достоверности и причины возникновения ошибок в данных
- Постановка и решение задачи проектирования концептуальной схемы базы данных
- Язык концептуального описания правил целостности ЛИРА
- Программное обеспечение систем генерации программ контроля
Введение к работе
В основных направлениях развития народного хозяйства СССР на I98I-I985 гг. и на период до 1990 г. предусмотрено обеспечить дальнейшее ускорение научно-технического прогресса и совершенствование управления экономикой, В директивных документах ноябрьского (1982 г.), июньского (1983 г.) Пленумов ЦК КПСС, в постановлении ЦК КПСС и Совета Министров СССР "О мерах по ускорению научно-технического прогресса в народном хозяйстве" эти задачи конкретизируются и подчеркивается необходимость существенного повышения производительности труда во всех сферах народного хозяйства. В связи с этим в статьях Г.И.Марчука [32] и А.П.Александрова [і] отмечается необходимость повышения эффективности воздействия достижений науки на темпы роста экономики страны и подчеркивается, что одной из главнейших задач является широчайшее использование в народном хозяйстве средств автоматизации. Один из путей решения поставленной задачи состоит в разработке автоматизированных систем управления (АСУ), среди которых важное место занимают автоматизированные системы организационного управления (АСОУ). Любая АСУ "...органически включает автоматизированную систему обработки данных (АСОД), главной целью которой является автоматизация процессов сбора, переработки информации и усовершенствование формы и организации их выполнения" [20].
Одним из основных требований, предъявляемых к АСОД, является обеспечение достоверности обрабатываемых данных. Разработкой методов и средств обеспечения достоверности данных занимались многие советские ученые: Будзко В.И., Дмитриев Н.И., Куцык Б.С, Пепеля-ев А.Н., Селетков С.Н., Шураков В.В. и другие, а также их зарубежные коллеги: Дейт К., Дэвенпорт Р., Кодд Е., Майерс Г., Маклеод Д., Хоффман Л. и другие.
Важность проблемы обеспечения достоверности данных и влияние
ошибок, приводящих к снижению уровня достоверности, целесообразно проиллюстрировать следующими цитатами [30] : "Поскольку обработка данных затрагивает нашу жизнь во все большей степени, ошибки ЭВМ могут теперь иметь такие последствия, как нанесение материального ущерба, нарушение секретности, оскорбление личности и даже смерть... Ошибка в единственном операторе программы на Фортране привела к неудаче при первом запуске американского исследовательского корабля на Венеру. Что хуже всего, ошибки в медицинском программном обеспечении явились причиной нескольких смертных случаев, а ошибки при проектировании самолета вызвали несколько серьезных авиакатастроф".
Отличительной особенностью АСУ одиннадцатой пятилетки является ориентация их работы на машины третьего поколения и использование при разработке систем новых методов, основанных на концепции банков данных. В настоящее время проблематика проектирования, внедрения и эксплуатации автоматизированных банков данных (АБД) является центральной при разработке АСОД. В основе АБД лежит принцип максимальной независимости программной реализации функциональных задач от организации и состава информационной базы. От простых файловых систем к автоматизированным банкам данных, и далее, к распределенным банкам данных - вот шаги прогресса в развитии архитектуры систем обработки данных, вызванные как развитием технической базы от ЭВМ второго поколения к мощным вычислительным системам третьего поколения, так и формированием основ теории систем обработки данных и практикой их функционирования.
Указанные изменения архитектуры систем обработки данных потребовали принципиальных изменений в архитектуре систем управления базами данных (СУБД): от архитектуры систем управления данными ОС ЕС ЭВМ [її]» к архитектуре, предложенной комитетом КОДАСЙЛ [17,35] и, наконец, к архитектуре, предложенной комитетом ANSI/SPAEC
[78,80] Появление последней обусловлено созданием большого числа СУБД, поддерживающих различные модели данных, и неочевидностью выбора СУБД для конкретной системы обработки данных. Уровень проектирования АСОД, независящий от конкретной, реализованной в рамках определенной СУБД, модели данных, называют концептуальным уровнем.
В настоящее время появилось большое число работ, посвященных методам концептуального проектирования [6,73,25,12,71,80],и в некоторых из них отмечается привлекательность реляционного подхода к описанию концептуального проекта системы [ 6,,12,73] . Однако в этих работах недостаточно исследованы вопросы языкового представления на концептуальном уровне требований к достоверности данных, а также способам автоматизированного погружения этих требований в реально существующие СУБД. Здесь важно отметить, что "...существеннейшей научно-технической задачей является создание вычислительной техники и автоматизации очень высокой надежности... . Изготовление программных средств должно быть, как и в космической технике, в значительной степени автоматизировано и приспособлено к автоматическим системам поиска ошибок... Это сложные технические задачи, но их обязательно нужно решить" [і].
В настоящей работе ставятся открытые вопросы концептуального описания требований к достоверности данных и автоматизированного проектирования программной компоненты, предназначенной для обеспечения контроля данных в АСОД.
Диссертация состоит из введения, четырех глав, заключения и приложения.
В первой главе дается анализ проблемы обеспечения достоверности. Формулируются определения и уточняется используемая терминология. Отмечается, что для обеспечения достоверности данных необходимо предоставить проектировщику системы или администратору
данных комплекс методов и средств по обеспечению целостности, К ним относятся методы и средства предупреждения неумышленных ошибок, а также обнаружения и устранения всех ошибок в данных, циркулирующих в системе.
Рассматривается современный подход к проектированию АСОД, включающий этап концептуального проектирования систем. Показывается, что вопросы обеспечения целостности должны решаться уже на концептуальном уровне, обеспечивающим простоту описания проекта и его устойчивость к изменению системных средств программирования. Отмечается, что использование реляционного подхода при проектировании баз данных требует устранения аномалий корректировок, приводящих к ошибкам актуализации данных и, следовательно, снижению уровня достоверности. Показана актуальность задачи исследования аномалий корректировок и разработки методов их устранения.
Показана также актуальность задачи исследования и разработки языков концептуального описания семантических зависимостей в проблемной области, а также разработки трансляторов, преобразующих эти описания в прикладные программы контроля данных. Отмечается, что такие инструментальные средства автоматизации программирования позволяют ускорить процесс разработки и внедрения программной компоненты системы.
Во второй главе рассматриваются вопросы построения баз данных, свободных от аномалий корректировок. Дается анализ аномальных эффектов корректировок и их классификация, основанная на использовании известных свойств функциональных и многозначных зависимостей. Ставится задача проектирования концептуальной схемы базы данных, свободной от аномалий корректировок и приводятся традиционные методы ее решения, предложенные Коддом, Бойсом и Фэджином. Показано, что четвертая нормальная форма позволяет устранить все аномальные эффекты только при использовании нуль-значений в неключевых
атрибутах отношения. В противном случае необходима дальнейшая нормализация отношения и приведение его к конечной нормальной форме, предлагаемой автором.
Ставится задача проектирования концептуальной схемы базы данных, свободной от аномалий корректировок, с учетом ограничений на внешние схемы ввода. Предлагается решение этой задачи в виде утверждений, приводящее отношения к конечной псевдонормальной форме. Также предлагаются правила выбора одного из методов решения задачи устранения аномалий корректировок в зависимости от критериев простоты описания концептуального проекта, устойчивости к изменениям во внешних схемах и минимизации избыточности данных.
В третьей главе строится концептуальная модель правил целостности, расширенная по отношению к известным моделям и включающая прежде всего человеко-машинные процедуры проверки правильности данных. Показано применение аппарата реляционной алгебры для единообразного описания различных методов контроля, основанного на использовании информационной избыточности. Также показывается, что известные реляционные языки описания правил целостности не удовлетворяют требованиям простоты и полноты описания расширенной модели. Предлагается простой операторный язык ЛИРА, ориентированный на описание правил целостности. Дается методика проектирования инструментальных средств обеспечения семантической целостности, основу которых составляют генераторы прикладных программ контроля данных.
В четвертой главе рассматриваются вопросы реализации генераторов программ контроля. Обосновывается состав программных компонент, включаемых в систему генерации программ контроля и выбор языков, на которые должна быть осуществлена препроцессия программ контроля. Далее рассматриваются вопросы реализации инструменталь-
ных средств генерации программ контроля в системе ИНЕС, Обосновывается состав систем ; генерации программ для АСОД, построенных на базе ШЇЇІ ИНЕС. Даются схемы генерации программ контроля с использованием ППП "СОЦ-ИНЕС", разработанного автором, В качестве языка программирования модулей ППП "СОЦ-ИНЕС" выбран язык РЕФАЛ.
Приводятся характеристики модулей пакета и результаты его практического применения. Показывается, что использование ППП "СОЦ-ИНЕС" позволяет повысить производительность труда прикладного программиста при разработке им программ контроля на языке КОБОЛ в среднем в 12,5 раз, а на Языке Запросов системы ИНЕС - в 4,5 раза.
В данной главе также приводятся результаты применения методики проектирования баз данных, свободных от аномалий корректировок, при разработке концептуальной схемы "Автоматизированной библиотечной системы" МИФИ.
Научные результаты исследований докладывались на втором и третьем всесоюзных научных семинарах "Интеллектуальные банки данных" (1980 г., 1982 г.), на втором всесоюзном научно-техническом симпозиуме "Диалоговые и фактографические системы информационного обеспечения" (1981 г.), на научных конференциях МИФИ (секция "Автоматизированные системы управления" 1979 г., 1981 г., 1983 г.), отражены в отчетах - № Гос. per. 0283.0050610, 0283.0037937, 0.283.0037242, 0283.0045913, Б663387, 0I8I60I03I6 и в пяти печатных работах [4,10,16,24,25].
Основные результаты представлены в настоящей диссертации.
Требование достоверности и причины возникновения ошибок в данных
Объектами исследования данной работы являются автоматизированные системы обработки данных (АСОД) фактографического типа, главная цель создания и использования которых состоит в удовлетворении информационных потребностей внешних пользователей. Поэтому требования, которые пользователи предъявляют к вводимым, хранимым и обрабатываемым данным, должны являться определяющими при проектировании системы.
Наряду с требованиями, которым должна удовлетворять система в целом: мощностью множества функций, удобством эксплуатации, простотой общения, оперативностью выполнения функций, эффективностью, надежностью работы, адаптивностью, живучестью, мобильностью и т.п., можно выделить требования, относящиеся собственно к данным, циркулирующим в системе. Это - требования удобства языка представления данных, секретности данных и адекватности получаемых пользователем данных информации предметной области в текущий момент времени.
Вопросы разработки языков представления данных (языков кодирования данных и языков документов системы) традиционно относятся к лингвистическому обеспечению АСУ [19,49] , а обеспечение секретности данных, реализуемое механизмами предупреждения несанкционированного получения и использования данных,рассматривается в работах по защите информации [26,46].
Говоря об адекватности данных,необходимо подчеркнуть, что это требование предполагает как концептуальную адекватность, достигаемую при проектировании, так и адекватность динамического отображения информации предметной области в системе, обеспечиваемую при функционировании АСОД. В свою очередь концептуальная адекватность означает обеспечение при проектировании системы концептуальной полноты и концептуальной точности данных. Концептуальная полнота предполагает полноту схемы базы данных, достаточную для реализации всего множества функций, предусмотренного при проектировании системы. Обеспечение концептуальной точности данных состоит в определении необходимой точности представления количественных характеристик объектов, понятий и свойств внешнего мира и в разработке кодификаторов для качественных характеристик, причем полнота кодификаторов должна удовлетворять пользователей. Основное внимание будет уделено проблемам обеспечения адекватного динамического отображения информации предметной области в автоматизированных системах.
В идеале конечного пользователя может интересовать адекватное отображение информации на текущий момент времени, однако это требование практически не достижимо, так как такой сложный преобразователь информации как АСОД несомненно вносит отличное от нуля запаздывание.
Поэтому будем говорить об адекватности отображения информации предметной области в пределах допустимого запаздывания, определенного при концептуальном проектировании системы. Кроме того, целесообразно говорить о степени соответствия данных, получаемых конечным пользователем, информации проблемной области или о достоверности данных.
По аналогии с [34] определим достоверность данных в АСОД как степень соответствия в некотором вероятностном смысле, данных, получаемых конечными пользователями, информации предметной области на момент времени Т = тек-АІ-ЗАП (где -тек " текУЩии момент времени,Л 1здП- допустимое время запаздывания), при обеспеченной концептуальной адекватности этих данных.
Говоря о достоверности данных в АСОД,будем различать полноту и точность динамического отображения информации внешнего мира в любой момент времени функционирования системы.
Полнота данных означает, что вся информация о предметной области, существенная для функционирования АСОД (т.е. ограниченная концептуальной полнотой), с удовлетворяющим пользователей запаздыванием находит отражение в данных, циркулирующих в системе.
Точность данных заключается в том, что все данные, введенные в систему, правильно отражают информационную картину внешнего мира при обеспечении концептуальной точности.
С учетом введенных определений классификация требований конечных пользователей АСОД к обрабатываемым данным приведена на рис. І.І. Для количественной характеристики допустимого уровня достоверности данных часто используют значение вероятности появления необнаруженных ошибок. Допустимое значение вероятности появления необнаруженных ошибок, сложившееся в практике проектирования АСУ лежит в пределах 10 "410 . Учитывая, что средняя вероятность появления ошибки только по вине операторов подготовки данных равна 0,11 І0""5 0,57 10 3 и тот факт, что наличие ошибок в выходных данных АСОД может привести к непредсказуемым результатам и к значительным непроизводительным потерям временных, материальных и трудовых ресурсов, можно сделать вывод о том, что обеспечение достоверности данных является важной задачей проектирования и функционирования автоматизированных систем.
"Работы по проверке и обеспечению достоверности данных стали одним из главных факторов, определяющих затраты на функционирование банка данных. Так, после проведения тестов и проверки достоверности данных Управление общего учета военно-морского флота США установило, что в 83% данных об офицерах и 79% данных о новобранцах имеется одна или несколько ошибок"[50].
Какова природа подобных ошибок и какова причина их появления?
Классифицировать причины возникновения ошибок в данных АСОД можно по различным основаниям классификации: в соответствии с мотивацией их появления (умышленные или неумышленные ошибки); на основании их природы (ошибки, вызванные запаздыванием динамического отображения информации внешнего мира, или ошибки, связанные с искажениями значений данных). Известны классификации ошибок по месту их возникновения, по степени влияния на процессы обработки данных, по источникам ошибок, по способам их обнаружения [9,13,15, 37,30].
Постановка и решение задачи проектирования концептуальной схемы базы данных
Формальная постановка задачи проектирования концептуальной схемы базы данных (КСБД), свободной от аномалий корректировок будет иметь вид: Пусть задано: а) Концептуальная схема универсального отношения: So = R0(U0) , где Uo - множество имен атрибутов; б) множества f = {?iLlei,t и M = {mj}, j l,k , где & - множество функциональных зависимостей на "R0, М - множество многозначных зависимостей на R0. Требуется спроектировать концептуальную схему базы данных S={Ri(Ut), t =1,2,...,р}, такую, что в) S S0, г) nun I S , д) для Vv, , 3Q3(Vj,S),ji7H4lf где Uj - внешняя схема ввода; Vg- множество произвольных внешних схем ввода; Qj(ir.j,S) - преобразование "внешний-концептуальный", записанное в нотации алгебры кодда.
Отметим, что в отличие от такой постановки задачи в литературе [l4] рассматривается задача проектирования схемы базы данных по критерию минимизации избыточности связей и данных в отношениях, а не устранения аномалий корректировок. Однако методы решения обоих задач во многом совпадают и основываются на использовании свойств функциональных и многозначных зависимостей и приведении отношений к нормальному виду. Кроме того, в данном параграфе будут рассмотрены решения задачи в предположении, что неопределенные значения неключевых атрибутов в системе отсутствуют. Решение А.
Кодд и Бойс [.12,59] предложили следующее решение задачи проектирования КСБД: Каждое отношение базы данных должно находиться в первой нормальной форме (ІНФ) и если из того, что какой-либо атрибут, не принадлежащий извлеченной из отношения R произвольной совокупное ти атрибутов С, функционально зависит от С, следует, что все атрибуты отношения R функционально зависят от С. Построение отношений, удовлетворяющих этим условиям, называется приведением отношений базы данных к Бойса-Кодда Нормальной Форме (БКНФ) или третьей норальной Форме (ШФ). Однако решение, предложенное Коддом и Бойсом, хотя и позволяет устранить аномальный эффект свойства дополнения и аномальный эффект свойства транзитивности функциональных зависимостей, но не устраняет аномальный эффект свойства декомпозиции функциональных зависимостей и аномальные эффекты свойств многозначных зависимостей. Более полное решение задачи проектирования КСБД предложил Фэджин [67].
Определение 12. Отношение КМБД, на котором определена только одна элементарная функциональная или одна элементарная многозначная зависимость называется отношением в Конечной Нормальной Форме (КНФ), Следует отметить, что решением задачи проектирования концептуальной схемы базы данных, поставленной по критерию минимума связей и избыточности данных, является приведение отношений базы данных к 4НФ. Действительно, при переходе от 4НФ к КНФ возможно увеличение избыточности данных за счет дублирования данных в ключевых атрибутах. Однако требование устранения всех аномалий корректировок является более существенным, чем требование минимизации избыточности.
Нормальные аномальные эффекты отсутствуют в отношениях, приведенных к КНФ. Можно заметить, что отношение, приведенное к бинарному виду, будет всегда находиться в КНФ,и многие крупные специалисты продолжают выступать за использование бинарных отношении [12].
Следует отметить, что несмотря на достоинства, дальнейшая нормализация отношений имеет ряд недостатков. Такие недостатки могут иметь место на концептуальном уровне проектирования системы и на физическом уровне (табл. 2.2). Например, при концептуальном проектировании увеличение уровня нормализации усложняет описание преобразования концептуальный-внешний, так как приводит к необходимости написания проектировщиком АБД длинных цепочек алгебраических выражений. Тем самым нарушается один из принципов простоты общения с базой данных (число основных конструкций должно быть мало) [12]. Другим недостатком представления отношения Ro степени ft в виде нескольких отношений меньшей степени состоит в увеличении числа имен атрибутов. Если отношение Ro содержит fl +1 имя, то совокупность новых отношений будет содержать p + fl имен, где р -число отношений. В частности, представление отношения R0 в виде совокупности бинарных отношений, если ключ отношения атомарный, приведет к увеличению числа имен до 2П-І. (если ключ отношения составной, то число имен будет 2я +1, так как необходимо введение нового атомарного ключа [12]). На физическом уровне увеличение числа отношений может привести к увеличению времени обработки базы данных.
Метод устранения аномальных эффектов, основанный на приведении базы данных к совокупности отношений в КНФ, основан на устранении неполных, транзитивных и декомпозиционных зависимостей в отношениях. Этот метод не учитывает структуру зависимостей во внешних схемах. Однако существование аномальных эффектов может зави 55 сеть от вида внешних схем. Учитывая такие зависимости,можно упростить концептуальное описание оазы данных.
Язык концептуального описания правил целостности ЛИРА
Как было показано ранее, необходим простой операторный язык описания правил целостности на уровне концептуального проекта системы, удовлетворяющий модели (3.2). При описании ограничений целостности в этом языке целесообразно использовать набор операторов, предложенных в [ 12,73] , расширив его операторами, необходимость включения которых обсуждалась и обосновывалась в п. 3.2.
Язык описания правил целостности вида (3.2) назовем "ЛИРА". Программа на языке ЛИРА в общем случае состоит из двух частей: а) описания типов (предикатов и действий); б) предложений контроля. Описание типов в программе может отсутствовать. Рассмотрим правила описания в программе предложений контроля. Каждое предложение контроля реализует правило целостности вида (3.2). Порядок предложений в программе несущественен. Предложения контроля в программе будут иметь следующую структуру: ( X ) ( Pj ) ( Р2 ) (Р3?4 ) ( Д ) Параметр Рт представляет собой формализованную запись событийно--временного ограничения целостности. X представляется в виде (A-j-)(A2)...(AK), где Aj, je l,k - имя контролируемого атрибута. Ограничение Р? записывается в виде последовательности операторов контроля, состав которых приведен на рис. 3.3. Допускается вложенность операторов. Условно все предлагаемые в языке ЛИРА операторы контроля можно разделить на три группы:
а) операторы лексико-семантического контроля атрибута;
б) операторы семантического контроля выборки;
в) операторы семантического контроля отношения.
Для описания лексико-семантических свойств атрибута в языке ЛИРА дополнительно к оператору КОНТР (предложенному в п. 3.2) имеется следующий набор операторов:
а) BOUNDSftrJ-.rfHr : ).. !1 )) оператор специфицирует диапазон значений, которые может принимать атрибут. Например, спецификация BOUNDS ((0:5) (Io:I5)) устанавливает правило, что каждое значение контролируемого атрибута должно находиться в диапазоне от 0 до 5 или от 10 до 15.
б) VALUES( (значение I) (значение 2)... (значение ТП) ) оператор специфицирует множество допустимых значении, которые мо жет принимать контролируемый атрибут. Например, спецификация VALUES ( (A) (ti) (Т) ) устанавливает правило, что каждое значение контролируемого атрибута должно оыть равно значению А, либо К, либо Т.
в) EXCEPT ( (значение I) (значение 2)... (значениеW) ) оператор специфицирует множество недопустимых значений для конт ролируемого атрибута. Например, спецификация EXCEPT ( (X) (Y) ) устанавливает правило, что значениями атрибутов не могут быть X и Y .
г) "FORMAT (определитель класса данного (число) ) - опера тор специфицирует класс части контролируемого атрибута. Фактичес ки, оператор FORMAT отсекает заданное число символов в значении атрибута и утверждает, что все символы будут либо бук венного (А), либо цифрового (9), либо буквенно-цифрового (X) класса. Например, спецификация FORMAT (А(2) ) для атрибута "ФАМИЛИЯ" указывает на то, что первые два символа в значении этого атрибута должны быть буквами.
д) МЕТКА (имя метки) (последовательность операторов) - опе ратор специфицирует имя части контролируемого атрибута. Этот оператор может стоять перед одним или несколькими операторами, включающими оператор FORMAT . Использование оператора МЕТКА позволяет описывать семантические зависимости между частями атрибута или разных атрибутов. При этом необходимо использовать оператор LOGIG.
е) LOGIC (условие) (утверждение) - оператор специфициру ет семантические зависимости между поименованными частями атрибута. Например, можно следующим образом специфицировать проверку значений атрибута "ДАТА". (МЕТКА (Д) ) ( FORMAT (9(2) ). BOUNDS (1:31). FORMAT(X(I) ). VALUES ( . ). МЕТКА (M) ( FORMAT(9(2) ). BOUNDS (1:12). LOGIG (M = 2) (Д 30). LOGIC ( (M = 4) (M = 6) (M = 9) (M = II) ) ( Д 31)
Частями атрибута являются: день (Д) - первые две цифры и месяц (М) - Ц- и 5 цифры в значении атрибута. При этом утверждается, что в феврале не может быть более 29 дней, а в 4-ом, 6-ом, 9-ом и 11-ом месяцах не может быть более 30 дней.
Для проверки семантических свойств выборки в отношении удобно использовать дополнительно к оператору КОНТР оператор LOGIG (условие) (утверждение), в функции которого входит спецификация семантических зависимостей между различными атрибутами и частями различных атрибутов. Для проверки семантических свойств отношения, предлагается использовать следующие операторы:
а) FZ((Ail)(A32)...CAjk)#(AiK+1)(AjK+2)...(AJK+t)) оператор специфицирует существование функциональной зависимости между атрибутами. Например, спецификация FZ ( (КАФЕДРА) # (ФАКУЛЬТЕТ) ) указывает на то, что в отношении существует функциональная зависимость атрибута "ФАКУЛЬТЕТ" от атрибута "КАФЕДРА".
б) МХ((А4А)(АзЕ)...(Азк)## (AiK+1)(Aik+2)...(AjKU)) оператор специфицирует существование многозначной зависимости между множествами атрибутов.
в) UNIQUE t(Ai1)CAia)...(Ajm)) оператор специфицирует уникальность значений множества атрибутов Aji» Aj2,..., Ajm.
г) SUBSET((A3i)(Aj2)...(A3k) (Ajk41)(AJk+2)...(AJK+e)) оператор специфицирует принадлежность значений множества атрибутов Aj4, Aj2, ..., AjK к множеству значений атрибутов A.jk+l Азю2» " AjK+e .
Дополнительно ко всем приведенным операторам целесообразно ввести в язык ЛИРА еще один оператор: REF (имя описания типа предиката). Такой оператор специфици рует ссылку на конкретное описание типа предиката. Использование оператора REF позволяет упростить описание предиката Б предложении контроля, поскольку в программе возможно частое повторение одного и того же предиката.
Возникает вопрос: достаточно ли этих операторов для описания любых ограничений целостности. Очевидно, что недостаточно. Правда, как было показано в п. 3.2, введение оператора КОНТР позволяет обеспечить полноту лексико-семантического контроля атрибута и семантического контроля выборки на концептуальном уровне, однако его использование во многих случаях затруднено. Фактически операторы BOUNDS и VALUES представляют собой модификации оператора КОНТР при ограниченном числе значений атрибута или интервальном задании значений.
Программное обеспечение систем генерации программ контроля
Как было показано в главе 3, основу инструментальной системы обеспечения целостности составляют средства генерации программ контроля (СГПК). С помощью СГПК должен быть сгенерирован программный комплекс, который будет использоваться администратором данных для поддержания целостности данных в АСОД. Такой комплекс программ назовем ПКАД (программный комплекс администратора данных).
Для обоснования структуры программного обеспечения СГПК целесообразно рассмотреть состав ПКАД, существенно зависящий от способов организации программ контроля, от используемого периферийного оборудования и режима обработки данных. В дальнейшем будем предполагать, что программы как СГПК, так и ПКАД функционируют под управлением ОС ЕС ЭВМ.
В системе обработки данных можно различать точки добазового контроля (если при контроле не используются данные, хранимые в БД) и базового (если такие данные используются). В свою очередь существует известная классификация базового контроля [12] на динамический (когда при контроле используются вводимые и хранимые в БД данные) и статический (используются только хранимые данные в БД).
В случае пакетного режима обработки данных программная реализация ПКАД для отмеченных точек контроля приведена на рис. 4.1а), б), в), г). Адаптация программ к видам носителей осуществляется средствами ОС ЕС. Модули добазового и динамического контроля принимают запись исходных данных как входные параметры, а в качестве выходных параметров передают значение индикатора ошибок и текстовое поле сообщения об ошибке.
В соответствии с выводами из параграфа 3.1 индикатор ошибок может принимать три значения: равно I при соответствии контролируемых данных правилам целостности, равно 0 при несоответствии данных правилам целостности и равно 2 при несоответствии данных программно проверяемым ограничениям целостности, в случае необходимости проверки внемашинных ограничений и исключений из правил.
Программы автономного добазового контроля целесообразно использовать на этапе первичной загрузки базы данных. При этом в случае использования телепакетного режима целесообразно кроме сообщений об ошибках подготовить на машинном носителе (МД или МЛ) файл корректировки данных, подготавливаемых к вводу. После обработки такого файла текстовым редактором ОС ЕС (внесения правильных значений данных) он может использоваться для корректировки исходных данных и формирования данных, подготовленных к вводу в базу данных (рис. 4.2). Сообщения об ошибках удобно выдавать в виде, приведенном на рис. 4.3. В левой части листинга выдаются сообщения об ошибках в данных, а в правой части проставляются правильные значения этих данных. На основании такого протокола и редактируется файл корректировки.
На рис. ЬЛ а), б) и в) приведена программная реализация ПКАД для оперативного режима обработки данных в АСОД. Легко видеть, что программная реализация модуля добазового контроля и модуля динамического контроля совпадают с аналогичной реализацией их для пакетного режима (рис. 4.1 б) ив). Различие заключается в обработке ошибочных записей: если для пакетного режима программы ввода блокируют ввод при значении индикатора ошибки = I и пишут запись в базу при значении индикатора = 2, то для оперативного режима ввод блокируется в любом случае (значение индикатора = I или = 2), но при значении индикатора равно 2 программа ввода должна иметь возможность обращения к администратору данных для осуществления внемашинной проверки данных и проверки исключений из правил. Только в случае подтверждения администратором правильности данных запись может быть введена в базу данных. Однако отметим, что это различие никак не сказывается на программной реализации модулей контроля.
Необходимо пояснить совпадение программных реализаций статического контроля (тестирования) базы данных для оперативного и пакетного режимов обработки данных в АСОД. Независимо от режима обработки данных тестирование представляет собой процесс, не связанный с обработкой данных по запросам конечных пользователей. Результаты тестирования целесообразно отображать на экране дисплея вследствие того, что для выяснения причины возникновения ошибок и для определения корректирующих данных требуется обращение администратора данных к информации предметной области, а это не согласуется с временными характеристиками оперативной обработки данных.
Из предыдущего анализа следует, что для генерации программ контроля ПКАД любой АСОД необходимо включить в состав СГПК средства генерации следующих программных компонент:
а) программ автономного добазового контроля;
б) модулей добазового контроля;
в) модулей динамического контроля;
г) программ тестирования базы данных.
При создании СГПК необходимо решать вопросы адаптации ПКАД к структуре контролируемых данных и их представления на внешних носителях; при этом можно использовать следующие два подхода:
а) основанный на генерации программ контроля, адаптируемых к произвольно заданной структуре и организации данных;
б) основанный на преобразовании обрабатываемых данных к оп ределенному виду (например, к стандартной последовательной орга низации данных в ОС ЕС). При этом программы контроля будут обра батывать данные стандартного вида, а в СГПК должны входить модули редактирования данных, осуществляющие преобразование данных к стандартному виду.
Первый подход позволяет эффективнее обрабатывать контролируемые данные, так как отсутствуют затраты на их преобразование. Однако использование этого подхода увеличивает затраты машинного времени на генерацию программ контроля и кроме того, трудно предусмотреть все возможное многообразие структур контролируемых данных. Второй подход позволяет упростить генерацию программ контроля, унифицировать процесс генерации программ и использовать для контроля данных стандартные языки ОС ЕС. Далее кратко остановимся на вопросе выбора языков, на которые должна быть осуществлена препроцессия программ контроля. Выбор таких языков может зависеть от места использования программы контроля в схеме обработки данных.
Для контроля данных, подготавливаемых к вводу, исходя из предположения о стандартной для ОС ЕС организации этих данных и требования минимизации времени обработки наборов данных, можно сделать вывод о целесообразности использования стандартного языка КОБОЛ [29] ОС ЕС ЭВМ. Хорошей альтернативой языку КОБОЛ является АССЕМБЛЕР, но ориентация на АССЕМБЛЕР увеличивает время реализации инструментальной системы, В том случае, когда должны быть использованы модули редактирования данных, выполняющие функции нормализации (например, приведения наборов данных иерархической структуры к линейной) и редактирования форматов данных, то необходимо использовать удобные средства символьных преобразований. При этом целесообразно использовать языки РЕФАЛ, ЛИСП, АССЕМБЛЕР, ПЛ/І. Если данные имеют скобочную структуру, то предпочтительно использование языка РЕФАЛ.
