Система управления базой данных объектов гражданской обороны для принятия решений в чрезвычайной ситуации (Диплом)

Государственный Комитет Российской Федерации по

высшему образованию

Московский Государственный Институт Радиотехники, Электроники и Автоматики

(Технический Университет)

Факультет ВМС

Кафедра Кибернетики

Шифр АВ-4-92156

Дипломный Проект

Тема: Система управления базой данных объектов Гражданской Обороны для

принятия решений в чрезвычайных ситуациях.

Исполнитель: Сафронов С. О.

Руководитель проекта: Мошкин В. В.

Консультант по спец. части: Юсупов Э. И.

Консультант по организационно-

экономической части: Забродина М. В.

Консультант по технике

безопасности: Ахобадзе Г.И.

Консультант по гражданской

обороне: к.т.н. Манукалов В.В.

Консультант по эргономике: Пименов А.И.

Рецензент:

«Допущен к защите»

Зав. Кафедрой:

МОСКВА - 1998 г.

ЗАДАНИЕ

РЕФЕРАТ

Темой разработанного дипломного проекта является "Система управления

базой данных объектов Гражданской Обороны для принятия решений в

чрезвычайных ситуациях".

Результатом дипломного проектирования является разработанная база

данных по объектам экономики, объектам гражданской обороны и учащихся в

учебно-методическом центре. А так же программа по управлению базой данных,

которая позволяет производить различные действия: ведение, корректировку

данных, построение отчетов и составление различной статистической

информации.

Дипломный проект содержит _____ страниц текста, ____ рисунков и

____ таблиц. Приложения занимают ____ страниц. Список литературы содержит

____ наименований.

В расчетно-пояснительной записке приведено экономическое

обоснование создание программного продукта; представлен расчет затрат и

определение цены ПП, экономическая эффективность разработки. Определены

мероприятия, обеспечивающие оптимальные условия труда пользователя на

рабочем месте. Произведена разработка программы по расчету основных

поражающих факторов ядерного взрыва. Приведен эргономический анализ стилей

программирования. Сделаны соответствующие выводы по выбору операционной

системы и базы данных.

Данная программа позволяет полностью автоматизировать существующую

систему сбора и хранения информации. Заменяет книги учёта объектов

Гражданской Обороны и облегчает корректировку и поиск любой необходимой

информации.

ОГЛАВЛЕНИЕ

ЗАДАНИЕ 2

РЕФЕРАТ 3

ОГЛАВЛЕНИЕ 4

СОКРАЩЕНИЯ 8

1. ВВЕДЕНИЕ 9

2. ВЫБОР ОПЕРАЦИОННОЙ СИСТЕМЫ 11

2.1. Определение операционной системы 11

2.2. ОС как система управления ресурсами 11

2.3. Классификация ОС 12

2.3.1. Особенности алгоритмов управления ресурсами 12

2.3.1.1. Поддержка многозадачности. 12

2.3.1.2. Поддержка многопользовательского режима. 13

2.3.1.3. Вытесняющая и невытесняющая многозадачность 13

2.3.1.4. Поддержка многонитевости 14

2.3.1.5. Многопроцессорная обработка 14

2.3.1.6. Поддержка сети 14

2.3.2. Особенности аппаратных платформ 15

2.3.3. Особенности областей использования 16

2.3.3.1. Системы пакетной обработки 16

2.3.3.2. Системы разделения времени 17

2.3.3.3. Системы реального времени 18

2.4.Обзор сетевых операционных систем 18

2.5. Выбор операционной системы 20

3. ВЫБОР БАЗЫ ДАННЫХ 24

3.1. Определение СУБД 24

3.2. Основные функции СУБД 24

3.2.1. Непосредственное управление данными во внешней памяти

3.2.2. Управление буферами оперативной памяти 25

3.2.3. Управление транзакциями 25

3.2.4. Журнализация 26

3.2.5. Поддержка языков БД 28

3.3. Варианты построения информационных приложений с использованием

СУБД 30

3.3.1. Централизованные многотерминальные системы 31

3.3.2. Файл-серверные приложения 32

3.3.3.Приложения клиент-сервер 33

4. ВЫБОР ЯЗЫКА ПРОГРАММИРОВАНИЯ 35

4.1.Традиционные системы программирования 36

4.2. Инструменты для создания файл-серверных приложений 37

4.3. Средства разработки приложений клиент-сервер 38

4.3.1. Среды разработки приложений для серверов баз данных 39

4.3.2. Средства поддержки распределенных информационных приложений

5. ВЫВОДЫ ПО ВЫБОРУ ОПЕРАЦИОННОЙ СИСТЕМЫ, ЯЗЫКА ПРОГРАММИРОВАНИЯ И БАЗЫ

ДАННЫХ 43

6. СТРУКТУРА И ОСНОВНЫЕ ЗАДАЧИ УПРАВЛЕНИЯ ПО ДЕЛАМ ГРАЖДАНСКОЙ ОБОРОНЫ И

ЧРЕЗВЫЧАЙНЫМ СИТУАЦИЯМ 46

6.1. Определение ГО 46

6.2. Основные задачи ГО 47

6.3. Схема управления по делам ГО и ЧС 47

7. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ СИСТЕМЫ УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ

ОБЪЕКТОВ ГО. 48

7.1. Назначение и цели создания программного продукта 48

7.2. Решаемые задачи 49

7.3. Определение необходимых таблиц базы данных 49

7.4. Нормализация базы данных 51

7.4.1. Первая нормальная форма 52

7.4.2. Вторая нормальная форма 52

7.4.3. Третья нормальная форма 53

7.4.4. Четвертая нормальная форма 53

7.4.5. Пятая нормальная форма 53

7.5. Определение столбцов в таблицах 54

7.6. Создание SQL сценария 68

7.6.1. Создание базы данных 68

7.6.2. Создание таблиц 69

7.6.3. Создание индексов 69

7.6.4. Определение первичных ключей 69

7.6.5. Определение вторичных ключей 70

7.6.6. Создание триггеров 70

7.6.7. Создание последовательностей 70

7.7.Выбор типа создаваемого приложения 71

7.8. Соглашение о название компонентов в программе GOBASE 71

7.9. Структура главного меню 73

7.9.1. Меню «Файлы» 74

7.9.2. Меню «Таблицы» 74

7.9.3. Меню «Отчеты» 75

7.9.4. Меню «Помощь» 75

7.10. Проектирование иерархий форм и отчетов 75

7.11. Иерархия форм программы 76

7.12. Основные органы управления форм программы GOBase 77

7.13. Основные формы программы 78

7.13.1. Форма ввода объектов экономики 78

7.13.2. Форма ввода учащихся в УМЦ 79

7.13.3. Форма отчетов (управления) 81

7.14. Экспорт в Excel 82

7.15. Требования к аппаратуре и программным средствам 84

7.16. Установка программы 84

8. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКИЙ РАЗДЕЛ 85

8.1. Введение 85

8.2. Описание программы 86

8.3. Последовательность выполнения работ 86

8.4. Оценка издержек на разработку программы. 92

8.4.1. Статья I. Оплата труда 93

8.4.2. Статья II. Материальные ресурсы 94

8.4.3. Статья III. Отчисления на социальные нужды 95

8.4.4. Статья IV. Накладные расходы 95

8.5. Цена программного продукта 96

8.6. Анализ эффективности внедрения программы 96

9. МЕРОПРИЯТИЯ, ОБЕСПЕЧИВАЮЩИЕ ОПТИМАЛЬНЫЕ УСЛОВИЯ ТРУДА ПОЛЬЗОВАТЕЛЯ НА

РАБОЧЕМ МЕСТЕ 99

9.1. Специфика дипломного проекта 99

9.2. Обзор вредных особенностей работы, встречающихся при изготовлении,

наладке и эксплуатации программ 99

9.3.1. Работа с монитором 99

9.3.2. Кресло 99

9.3.3. Клавиатура 100

9.3.4. Эффекты отражения и рабочий стол. 100

9.3.5. Оригиналодержатель 100

9.3.6. Шумы 100

9.3.7. Выделение избытков теплоты 101

9.4. Анализ категории тяжести труда инженера-программиста. 101

9.5. Анализ освещения на рабочем месте программиста. 106

10. ПРИМЕНЕНИЕ ЭВМ ДЛЯ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ РАБОТЫ ШТАБА ГО 110

10.1. Задачи гражданской обороны. 110

10.2. Основной расчет поражающих факторов ядерного взрыва 111

10.2.1. Исходные данные: 111

10.2.2. Выходные данные: 111

10.3. Текст программы 111

10.4. Проврка работоспособности 113

10.5. Выводы: 113

11. ЭРГОНОМИЧЕСКАЯ ОЦЕНКА ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ ЭВМ 114

11.1. Введение 114

11.2. Проектирование форм 114

11.3. Формы выдачи решений 117

11.4. Интерактивные формы. 118

11.5.Формы ввода данных. 119

11.6. Проектирование отчетов. 120

12. ВЫВОДЫ 122

13. ЛИТЕРАТУРА 124

ПРИЛОЖЕНИЕ 1 125

П.1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ 125

П.1.1 Общие сведения 125

П.1.2. Постановка задачи 125

П.1.3. Основания для разработки 125

П.1.4. Назначение и цели создания программного продукта 125

П.1.5. Требования к программе 126

П.1.6. Состав и содержание работ по созданию программы 127

П.1.7. Входная информация 127

П.1.8. Выходная информация 128

П.1.9. Порядок контроля и приемки программы 129

П.1.10. Требования к составу и содержанию работ по установке

программы на рабочем месте оператора 129

П.1.11. Требования к документированию 129

П.1.12. Источники разработки 129

ПРИЛОЖЕНИЕ 2 129

ПРИЛОЖЕНИЕ 3 132

ПРИЛОЖЕНИЕ 4 132

СОКРАЩЕНИЯ

|BL (Business or |Прикладная логика |

|Application Logic) | |

|DL (Data Logic |Логика управления данными |

|DS (Data Services) |Операции с БД |

|FK |Foreign Key (вторичный ключ) |

|FS (File Services) |Файловые операции |

|ID |идентификатор |

|ODBC |Open DataBase Connectivity |

|PK |Primary Key (первичный ключ) |

|PL (Presentation Logic) |Логика представлений |

|PS (Presentation | средства представления. |

|Services) | |

|RAD (Rapid Application |Средства быстрой разработки приложений |

|Development) | |

|АС |Автоматизированная система |

|АСУ |Автоматизированная система управления |

|БД |База данных |

|ВТ |Вычислительная техника |

|ГО |Гражданская Оборона |

|ДП |Дипломный проект |

|КЧС |Комиссия по ЧС |

|МТС |Материально-технические средства |

|ОП |Оперативная память |

|ОП |Особый период |

|ОС |Операционная система |

|ОТ |Охрана труда |

|ПК |Персональный компьютер |

|ПО |Программное обеспечение |

|ПП |Прикладная программа |

|ППП |Пакет ПП |

|ПУФ |Повышение устойчивости функционирования |

|ПЭВМ |Персональная ЭВМ |

|РФ |Российская Федерация |

|СУБД |Система управления базами данных |

|ТЗ |Техническое задание |

|ТП |Техническое предложение |

|УМЦ |Учебно-методический центр |

|ЦП |Центральный процессор |

|ЧС |Чрезвычайные ситуации |

|ЭВМ |Электронно-вычислительная машина |

|ЭЛТ |Электронно-лучевая трубка |

1. ВВЕДЕНИЕ

Прогресс, достигнутый за последние несколько лет во всех аспектах

вычислительной техники, включая теорию, технологию и приложения, привели

к значительному расширению области применения компьютеров и росту

числа их пользователей. Существенной частью современного общества

являются разнообразные системы доступа и хранения информации, которые

являются неотъемлемой составляющей современного научно-технического

прогресса. Существует много веских причин перевода существующей

информации на компьютерную основу, т.к. более быстрая обработка данных и

централизация их хранения с использованием клиент/серверных технологий

позволяют сберечь значительные средства, а главное и время для получения

необходимой информации, а также упрощает доступ и ведение.

В любой организации, как большой, так и маленькой, возникает проблема

такой организации управления данными, которая обеспечила бы наиболее

эффективную работу. Некоторые организации используют для этого шкафы с

папками, но большинство предпочитают компьютеризированные СУБД, позволяющие

эффективно хранить, извлекать информацию и управлять большими объемами

данных. Современные СУБД - многопользовательские системы управления базой

данных, которые специализируется на управлении массивом информации одним

или множеством одновременно работающих пользователей.

В настоящее время, вследствие нестабильной экономической и

политической ситуации в России возрастает опасность возникновения ЧС на

хозяйственных объектах (заводах, фабриках, электростанциях и т.п.),

возникновения аварий, стихийных бедствий и прочих катаклизмов. С каждым

годом чрезвычайные ситуации, порождаемые производственными и транспортными

авариями, катастрофами и стихийными бедствиями, становятся все более

частыми, масштабными и опасными, сопровождаются все большими человеческими

жертвами, материальным ущербом и деградацией природной сферы.

Как свидетельствует анализ статистических данных большая часть ЧС

возникает в РФ в регионах с высокой концентрацией предприятий угольной,

химической, нефтяной и газовой промышленности, с разветвленной сетью

автомобильных и железных дорог, а также в крупных городах. В основном это

ЧС техногенного характера (свыше 70% от общего числа) [1]. (См. ПРИЛОЖЕНИЕ

Для решения задач предотвращения и ликвидации ЧС, снижения возможных

потерь населения и ущерба экономике в случае их возникновения в РФ создана

и действует единая государственная система предупреждения и ликвидации ЧС.

В соответствии с законом “О защите населения и территорий от ЧС природного

и технического характера” в стране функционирует единая государственная

система предупреждения и ликвидации ЧС, которая располагает органами

управления, силами, техническими средствами и другими материальными

ресурсами для того чтобы защитить население и национальное достояние от

воздействий аварий, катастроф, экологических и стихийных бедствий или

уменьшить их воздействия.

Основной целью создания этой системы является объединение усилий

центральных органов исполнительной власти, органов представительной и

исполнительной власти республик в составе РФ, краев, областей, городов и

районов, а также организаций, учреждений и предприятий, их сил средств в

деле предупреждения и ликвидации ЧС.

В связи с этим необходимо уделить пристальное внимание вопросам

гражданской обороны, а также оснащенность частей гражданской обороны

современной техникой, в том числе компьютерной, для своевременного и

оперативного реагирования на возникшую критическую ситуацию и на устранение

ее последствий. Для этого компьютерная техника должна быть оснащена

соответствующим программным обеспечением.

К сожалению, на сегодняшний момент не существует единой базы данных

объектов ГО, даже для такого крупного города как Москва. Существующее

хранение информации только с использованием картотек становится не

приемлемым в складывающейся ситуации.

В данной дипломной работе разработана программа по управлению базой

данных объектов экономики, с помощью которой можно оперативно собрать все

необходимые данные (о находящейся в распоряжении техники, защитных

сооружений, близ находящиеся объектах и другой информации) об объектах

экономики округа или города в чрезвычайной ситуации при планировании и

организации спасательных и других неотложных работ и тем самым сократить

время на сбор информации, которая так необходима в первые минуты ЧС, когда

каждая минута промедления может стоить жизни людей. Результатом

дипломного проектирования является разработанная база данных по объектам

экономики, объектам гражданской обороны и учащихся в учебно-методическом

центре. А так же программа по управлению базой данных, которая позволяет

производить различные действия: введение, корректировку данных, построение

отчетов и составление различной статистической информации.

2. ВЫБОР ОПЕРАЦИОННОЙ СИСТЕМЫ

2.1. Определение операционной системы

Операционная система в наибольшей степени определяет облик всей

вычислительной системы в целом. Довольно затруднительно дать определение

операционной системе. Частично это связано с тем, что ОС выполняет две по

существу мало связанные функции: обеспечение пользователю-программисту

удобств посредством предоставления для него расширенной машины и повышение

эффективности использования компьютера путем рационального управления его

ресурсами.

2.2. ОС как система управления ресурсами

Идея о том, что ОС прежде всего система, обеспечивающая удобный

интерфейс пользователям, соответствует рассмотрению сверху вниз. Другой

взгляд, снизу вверх, дает представление об ОС как о некотором механизме,

управляющем всеми частями сложной системы. Современные вычислительные

системы состоят из процессоров, памяти, таймеров, дисков, накопителей на

магнитных лентах, сетевой коммуникационной аппаратуры, принтеров и других

устройств. В соответствии со вторым подходом функцией ОС является

распределение процессоров, памяти, устройств и данных между процессами,

конкурирующими за эти ресурсы. ОС должна управлять всеми ресурсами

вычислительной машины таким образом, чтобы обеспечить максимальную

эффективность ее функционирования. Критерием эффективности может быть,

например, пропускная способность или реактивность системы. Управление

ресурсами включает решение двух общих, не зависящих от типа ресурса задач:

. планирование ресурса - то есть определение, кому, когда, а для делимых

ресурсов и в каком количестве, необходимо выделить данный ресурс;

. отслеживание состояния ресурса - то есть поддержание оперативной

информации о том, занят или не занят ресурс, а для делимых ресурсов -

какое количество ресурса уже распределено, а какое свободно.

Для решения этих общих задач управления ресурсами разные ОС используют

различные алгоритмы, что в конечном счете и определяет их облик в целом,

включая характеристики производительности, область применения и даже

пользовательский интерфейс.

Так, например, алгоритм управления процессором в значительной степени

определяет, является ли ОС системой разделения времени, системой пакетной

обработки или системой реального времени.

2.3. Классификация ОС

Операционные системы могут различаться особенностями реализации

внутренних алгоритмов управления основными ресурсами компьютера

(процессорами, памятью, устройствами), особенностями использованных методов

проектирования, типами аппаратных платформ, областями использования и

многими другими свойствами.

Ниже приведена классификация ОС по нескольким наиболее основным

признакам.

2.3.1. Особенности алгоритмов управления ресурсами

От эффективности алгоритмов управления локальными ресурсами компьютера

во многом зависит эффективность всей сетевой ОС в целом. Поэтому,

характеризуя сетевую ОС, часто приводят важнейшие особенности реализации

функций ОС по управлению процессорами, памятью, внешними устройствами

автономного компьютера. Так, например, в зависимости от особенностей

использованного алгоритма управления процессором, операционные системы

делят на многозадачные и однозадачные, многопользовательские и

однопользовательские, на системы, поддерживающие многонитевую обработку и

не поддерживающие ее, на многопроцессорные и однопроцессорные системы.

2.3.1.1. Поддержка многозадачности.

По числу одновременно выполняемых задач операционные системы могут

быть разделены на два класса:

. однозадачные (например, MS-DOS, MSX)

. многозадачные (OC EC, OS/2, UNIX, Windows 95/NT).

Однозадачные ОС в основном выполняют функцию предоставления

пользователю виртуальной машины, делая более простым и удобным процесс

взаимодействия пользователя с компьютером. Однозадачные ОС включают

средства управления периферийными устройствами, средства управления

файлами, средства общения с пользователем.

Многозадачные ОС, кроме вышеперечисленных функций, управляют

разделением совместно используемых ресурсов, таких как процессор,

оперативная память, файлы и внешние устройства.

2.3.1.2. Поддержка многопользовательского режима.

По числу одновременно работающих пользователей ОС делятся на:

. однопользовательские (MS-DOS, Windows 3.x, ранние версии OS/2);

. многопользовательские (UNIX, Windows NT).

Главным отличием многопользовательских систем от однопользовательских

является наличие средств защиты информации каждого пользователя от

несанкционированного доступа других пользователей. Следует заметить, что не

всякая многозадачная система является многопользовательской, и не всякая

однопользовательская ОС является однозадачной.

2.3.1.3. Вытесняющая и невытесняющая многозадачность

Важнейшим разделяемым ресурсом является процессорное время. Способ

распределения процессорного времени между несколькими одновременно

существующими в системе процессами (или нитями) во многом определяет

специфику ОС. Среди множества существующих вариантов реализации

многозадачности можно выделить две группы алгоритмов:

. невытесняющая многозадачность (NetWare, Windows 3.x);

. вытесняющая многозадачность (Windows NT, OS/2, UNIX).

Основным различием между вытесняющим и невытесняющим вариантами

многозадачности является степень централизации механизма планирования

процессов. В первом случае механизм планирования процессов целиком

сосредоточен в операционной системе, а во втором - распределен между

системой и прикладными программами. При невытесняющей многозадачности

активный процесс выполняется до тех пор, пока он сам, по собственной

инициативе, не отдаст управление операционной системе для того, чтобы та

выбрала из очереди другой готовый к выполнению процесс. При вытесняющей

многозадачности решение о переключении процессора с одного процесса на

другой принимается операционной системой, а не самим активным процессом.

2.3.1.4. Поддержка многонитевости

Важным свойством операционных систем является возможность

распараллеливания вычислений в рамках одной задачи. Многонитевая ОС

разделяет процессорное время не между задачами, а между их отдельными

ветвями (нитями).

2.3.1.5. Многопроцессорная обработка

Другим важным свойством ОС является отсутствие или наличие в ней

средств поддержки многопроцессорной обработки - мультипроцессирование.

Мультипроцессирование приводит к усложнению всех алгоритмов управления

ресурсами.

В наши дни становится общепринятым введение в ОС функций поддержки

многопроцессорной обработки данных. Такие функции имеются в операционных

системах Solaris 2.x фирмы Sun, Open Server 3.x компании Santa Crus

Operations, OS/2 фирмы IBM, Windows NT фирмы Microsoft и NetWare 4.1 фирмы

Novell.

Многопроцессорные ОС могут классифицироваться по способу организации

вычислительного процесса в системе с многопроцессорной архитектурой:

асимметричные ОС и симметричные ОС. Асимметричная ОС целиком выполняется

только на одном из процессоров системы, распределяя прикладные задачи по

остальным процессорам. Симметричная ОС полностью децентрализована и

использует весь пул процессоров, разделяя их между системными и прикладными

задачами.

2.3.1.6. Поддержка сети

Выше были рассмотрены характеристики ОС, связанные с управлением

только одним типом ресурсов - процессором. Важное влияние на облик

операционной системы в целом, на возможности ее использования в той или

иной области оказывают особенности и других подсистем управления локальными

ресурсами - подсистем управления памятью, файлами, устройствами ввода-

вывода.

Специфика ОС проявляется и в том, каким образом она реализует сетевые

функции: распознавание и перенаправление в сеть запросов к удаленным

ресурсам, передача сообщений по сети, выполнение удаленных запросов. При

реализации сетевых функций возникает комплекс задач, связанных с

распределенным характером хранения и обработки данных в сети: ведение

справочной информации о всех доступных в сети ресурсах и серверах,

адресация взаимодействующих процессов, обеспечение прозрачности доступа,

тиражирование данных, согласование копий, поддержка безопасности данных.

2.3.2. Особенности аппаратных платформ

На свойства операционной системы непосредственное влияние оказывают

аппаратные средства, на которые она ориентирована. По типу аппаратуры

различают операционные системы персональных компьютеров, мини-компьютеров,

мейнфреймов, кластеров и сетей ЭВМ. Среди перечисленных типов компьютеров

могут встречаться как однопроцессорные варианты, так и многопроцессорные. В

любом случае специфика аппаратных средств, как правило, отражается на

специфике операционных систем.

Очевидно, что ОС большой машины является более сложной и

функциональной, чем ОС персонального компьютера. Так в ОС больших машин

функции по планированию потока выполняемых задач, очевидно, реализуются

путем использования сложных приоритетных дисциплин и требуют большей

вычислительной мощности, чем в ОС персональных компьютеров. Аналогично

обстоит дело и с другими функциями.

Сетевая ОС имеет в своем составе средства передачи сообщений между

компьютерами по линиям связи, которые совершенно не нужны в автономной ОС.

На основе этих сообщений сетевая ОС поддерживает разделение ресурсов

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

поддержания функций передачи сообщений сетевые ОС содержат специальные

программные компоненты, реализующие популярные коммуникационные протоколы,

такие как IP, IPX, Ethernet и другие.

Многопроцессорные системы требуют от операционной системы особой

организации, с помощью которой сама операционная система, а также

поддерживаемые ею приложения могли бы выполняться параллельно отдельными

процессорами системы. Параллельная работа отдельных частей ОС создает

дополнительные проблемы для разработчиков ОС, так как в этом случае гораздо

сложнее обеспечить согласованный доступ отдельных процессов к общим

системным таблицам, исключить эффект гонок и прочие нежелательные

последствия асинхронного выполнения работ.

Другие требования предъявляются к операционным системам кластеров.

Кластер - слабо связанная совокупность нескольких вычислительных систем,

работающих совместно для выполнения общих приложений, и представляющихся

пользователю единой системой. Наряду со специальной аппаратурой для

функционирования кластерных систем необходима и программная поддержка со

стороны операционной системы, которая сводится в основном к синхронизации

доступа к разделяемым ресурсам, обнаружению отказов и динамической

реконфигурации системы. Одной из первых разработок в области кластерных

технологий были решения компании Digital Equipment на базе компьютеров VAX.

Недавно этой компанией заключено соглашение с корпорацией Microsoft о

разработке кластерной технологии, использующей Windows NT. Несколько

компаний предлагают кластеры на основе UNIX-машин.

Наряду с ОС, ориентированными на совершенно определенный тип

аппаратной платформы, существуют операционные системы, специально

разработанные таким образом, чтобы они могли быть легко перенесены с

компьютера одного типа на компьютер другого типа, так называемые мобильные

ОС. Наиболее ярким примером такой ОС является популярная система UNIX. В

этих системах аппаратно-зависимые места тщательно локализованы, так что при

переносе системы на новую платформу переписываются только они. Средством,

облегчающем перенос остальной части ОС, является написание ее на машинно-

независимом языке, например, на С, который и был разработан для

программирования операционных систем.

2.3.3. Особенности областей использования

Многозадачные ОС подразделяются на три типа в соответствии с

использованными при их разработке критериями эффективности:

. системы пакетной обработки (например, OC EC),

. системы разделения времени (UNIX, VMS),

. системы реального времени (QNX, RT/11).

2.3.3.1. Системы пакетной обработки

Системы пакетной обработки предназначались для решения задач в

основном вычислительного характера, не требующих быстрого получения

результатов. Главной целью и критерием эффективности систем пакетной

обработки является максимальная пропускная способность, то есть решение

максимального числа задач в единицу времени. Для достижения этой цели в

системах пакетной обработки используются следующая схема функционирования:

в начале работы формируется пакет заданий, каждое задание содержит

требование к системным ресурсам; из этого пакета заданий формируется

мультипрограммная смесь, то есть множество одновременно выполняемых задач.

Для одновременного выполнения выбираются задачи, предъявляющие отличающиеся

требования к ресурсам, так, чтобы обеспечивалась сбалансированная загрузка

всех устройств вычислительной машины; так, например, в мультипрограммной

смеси желательно одновременное присутствие вычислительных задач и задач с

интенсивным вводом-выводом. Таким образом, выбор нового задания из пакета

заданий зависит от внутренней ситуации, складывающейся в системе, то есть

выбирается "выгодное" задание. Следовательно, в таких ОС невозможно

гарантировать выполнение того или иного задания в течение определенного

периода времени. В системах пакетной обработки переключение процессора с

выполнения одной задачи на выполнение другой происходит только в случае,

если активная задача сама отказывается от процессора, например, из-за

необходимости выполнить операцию ввода-вывода. Поэтому одна задача может

надолго занять процессор, что делает невозможным выполнение интерактивных

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

на которой установлена система пакетной обработки, сводится к тому, что он

приносит задание, отдает его диспетчеру-оператору, а в конце дня после

выполнения всего пакета заданий получает результат. Очевидно, что такой

порядок снижает эффективность работы пользователя.

2.3.3.2. Системы разделения времени

Системы разделения времени призваны исправить основной недостаток

систем пакетной обработки - изоляцию пользователя-программиста от процесса

выполнения его задач. Каждому пользователю системы разделения времени

предоставляется терминал, с которого он может вести диалог со своей

программой. Так как в системах разделения времени каждой задаче выделяется

только квант процессорного времени, ни одна задача не занимает процессор

надолго, и время ответа оказывается приемлемым. Если квант выбран

достаточно небольшим, то у всех пользователей, одновременно работающих на

одной и той же машине, складывается впечатление, что каждый из них

единолично использует машину. Ясно, что системы разделения времени обладают

меньшей пропускной способностью, чем системы пакетной обработки, так как на

выполнение принимается каждая запущенная пользователем задача, а не та,

которая "выгодна" системе, и, кроме того, имеются накладные расходы

вычислительной мощности на более частое переключение процессора с задачи на

задачу. Критерием эффективности систем разделения времени является не

максимальная пропускная способность, а удобство и эффективность работы

пользователя.

2.3.3.3. Системы реального времени

Системы реального времени применяются для управления различными

техническими объектами, такими, например, как станок, спутник, научная

экспериментальная установка или технологическими процессами, такими, как

гальваническая линия, доменный процесс и т.п. Во всех этих случаях

существует предельно допустимое время, в течение которого должна быть

выполнена та или иная программа, управляющая объектом, в противном случае

может произойти авария: спутник выйдет из зоны видимости, экспериментальные

данные, поступающие с датчиков, будут потеряны, толщина гальванического

покрытия не будет соответствовать норме. Таким образом, критерием

эффективности для систем реального времени является их способность

выдерживать заранее заданные интервалы времени между запуском программы и

получением результата (управляющего воздействия). Это время называется

временем реакции системы, а соответствующее свойство системы -

реактивностью. Для этих систем мультипрограммная смесь представляет собой

фиксированный набор заранее разработанных программ, а выбор программы на

выполнение осуществляется исходя из текущего состояния объекта или в

соответствии с расписанием плановых работ.

Некоторые операционные системы могут совмещать в себе свойства систем

разных типов, например, часть задач может выполняться в режиме пакетной

обработки, а часть - в режиме реального времени или в режиме разделения

времени. В таких случаях режим пакетной обработки часто называют фоновым

режимом.

2.4.Обзор сетевых операционных систем

Большое разнообразие типов компьютеров, используемых в вычислительных

сетях, влечет за собой разнообразие операционных систем: для рабочих

станций, для серверов сетей уровня отдела и серверов уровня предприятия в

целом. К ним могут предъявляться различные требования по производительности

и функциональным возможностям, желательно, чтобы они обладали свойством

совместимости, которое позволило бы обеспечить совместную работу различных

ОС.

Сетевые ОС могут быть разделены на две группы: масштаба отдела и

масштаба предприятия. ОС для отделов или рабочих групп обеспечивают набор

сетевых сервисов, включая разделение файлов, приложений и принтеров. Они

также должны обеспечивать свойства отказоустойчивости, например, работать с

RAID-массивами, поддерживать кластерные архитектуры. Сетевые ОС отделов

обычно более просты в установке и управлении по сравнению с сетевыми ОС

предприятия, у них меньше функциональных свойств, они меньше защищают

данные и имеют более слабые возможности по взаимодействию с другими типами

сетей, а также худшую производительность.

Сетевая операционная система масштаба предприятия прежде всего должна

обладать основными свойствами любых корпоративных продуктов, в том числе:

. масштабируемостью, то есть способностью одинаково хорошо работать в

широком диапазоне различных количественных характеристик сети,

. совместимостью с другими продуктами, то есть способностью работать в

сложной гетерогенной среде интерсети в режиме plug-and-play.

Корпоративная сетевая ОС должна поддерживать более сложные сервисы.

Подобно сетевой ОС рабочих групп, сетевая ОС масштаба предприятия должна

позволять пользователям разделять файлы, приложения и принтеры, причем

делать это для большего количества пользователей и объема данных и с более

высокой производительностью. Кроме того, сетевая ОС масштаба предприятия

обеспечивает возможность соединения разнородных систем - как рабочих

станций, так и серверов. Например, даже если ОС работает на платформе

Intel, она должна поддерживать рабочие станции UNIX, работающие на RISC-

платформах. Аналогично, серверная ОС, работающая на RISC-компьютере, должна

поддерживать DOS, Windows и OS/2. Сетевая ОС масштаба предприятия должна

поддерживать несколько стеков протоколов (таких как TCP/IP, IPX/SPX,

NetBIOS, DECnet и OSI), обеспечивая простой доступ к удаленным ресурсам,

удобные процедуры управления сервисами, включая агентов для систем

управления сетью.

Важным элементом сетевой ОС масштаба предприятия является

централизованная справочная служба, в которой хранятся данные о

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

службой каталогов, обеспечивает единый логический вход пользователя в сеть

и предоставляет ему удобные средства просмотра всех доступных ему ресурсов.

Администратор, при наличии в сети централизованной справочной службы,

избавлен от необходимости заводить на каждом сервере повторяющийся список

пользователей, а значит избавлен от большого количества рутинной работы и

от потенциальных ошибок при определении состава пользователей и их прав на

каждом сервере.

Важным свойством справочной службы является ее масштабируемость,

обеспечиваемая распределенностью базы данных о пользователях и ресурсах.

Такие сетевые ОС, как Banyan Vines, Novell NetWare 4.x, IBM LAN

Server, Sun NFS, Microsoft LAN Manager и Windows NT Server, могут служить в

качестве операционной системы предприятия, в то время как ОС NetWare 3.x,

Personal Ware, Artisoft LANtastic больше подходят для небольших рабочих

групп.

2.5. Выбор операционной системы

Критериями для выбора ОС масштаба предприятия являются следующие

характеристики:

. Органичная поддержка многосерверной сети;

. Высокая эффективность файловых операций;

. Возможность эффективной интеграции с другими ОС;

. Наличие централизованной масштабируемой справочной службы;

. Хорошие перспективы развития;

. Эффективная работа удаленных пользователей;

. Разнообразные сервисы: файл-сервис, принт-сервис, безопасность данных и

отказоустойчивость, архивирование данных, служба обмена сообщениями,

разнообразные базы данных и другие;

. Разнообразные программно-аппаратные хост-платформы: IBM SNA, DEC NSA,

UNIX;

. Разнообразные транспортные протоколы: TCP/IP, IPX/SPX, NetBIOS,

AppleTalk;

. Поддержка многообразных операционных систем конечных пользователей: DOS,

UNIX, OS/2, Mac;

. Поддержка сетевого оборудования стандартов Ethernet, Token Ring, FDDI,

ARCnet;

. Наличие популярных прикладных интерфейсов и механизмов вызова удаленных

процедур RPC;

. Возможность взаимодействия с системой контроля и управления сетью,

поддержка стандартов управления сетью SNMP.

Конечно, ни одна из существующих сетевых ОС не отвечает в полном

объеме перечисленным требованиям, поэтому выбор сетевой ОС, как правило,

осуществляется с учетом производственной ситуации и опыта. В таблице 2.1.

приведены основные характеристики популярных и доступных в настоящее время

сетевых ОС.

Таблица. 2.1. Основные характеристики сетевых ОС

|Novell |Специализированная операционная система, |

|NetWare |оптимизированная для работы в качестве файлового |

|4.1 |сервера и принт-сервера |

| |Ограниченные средства для использования в качестве |

| |сервера приложений: не имеет средств виртуальной |

| |памяти и вытесняющей многозадачности, а поддержка |

| |симметричного мультипроцесcирования отсутствовала до |

| |самого недавнего времени. Отсутствуют API основных |

| |операционных сред, используемых для разработки |

| |приложений, - UNIX, Windows, OS/2 |

| |Серверные платформы: компьютеры на основе процессоров|

| |Intel, рабочие станции RS/6000 компании IBM под |

| |управлением операционной системы AIX с помощью |

| |продукта NetWare for UNIX |

| |Поставляется с оболочкой для клиентов: DOS, |

| |Macintosh, OS/2, UNIX, Windows (оболочка для Windows |

| |NT разрабатывается компанией Novell в настоящее |

| |время, хотя Microsoft уже реализовала клиентскую |

| |часть NetWare в Windows NT) |

| |Организация одноранговых связей возможна с помощью ОС|

| |PersonalWare |

| |Имеет справочную службу NetWare Directory Services |

| |(NDS), поддерживающую централизованное управление, |

| |распределенную, полностью реплицируемую, |

| |автоматически синхронизируемую и обладающую отличной |

| |масштабируемостью |

| |Поставляется с мощной службой обработки сообщений |

| |Message Handling Service (MHS), полностью |

| |интегрированную (начиная с версии 4.1) со справочной |

| |службой |

| |Поддерживаемые сетевые протоколы: TCP/IP, IPX/SPX, |

| |NetBIOS, Appletalk |

| |Поддержка удаленных пользователей: ISDN, |

| |коммутируемые телефонные линии, frame relay, X.25 - с|

| |помощью продукта NetWare Connect (поставляется |

| |отдельно) |

| |Безопасность: аутентификация с помощью открытых |

| |ключей метода шифрования RSA; сертифицирована по |

| |уровню C2 |

| |Хороший сервер коммуникаций |

| |Встроенная функция компрессии диска |

| |Сложное обслуживание |

|Banyan |Серверные платформы: |

|VINES 6.0 |ENS for UNIX: работает на RISC-компьютерах под |

|и ENS |управлением SCO UNIX, HP-UX, Solaris, AIX ENS for |

|(Enterpris|NetWare: работает на Intel-платформах под управлением|

|e |NetWare 2.x, 3.x, 4.x |

|Network |VINES работает на Intel-платформах |

|Services) |Клиентские платформы: DOS, Macintosh, OS/2, UNIX, |

|6.0 |Windows for Workgroups, Windows NT |

| |Хороший сервер приложений: поддерживаются вытесняющая|

| |многозадачность, виртуальная память и симметричное |

| |мультипроцессирование в версии VINES и в ENS-версиях |

| |для UNIX. Поддерживаются прикладные среды UNIX, OS/2,|

| |Windows |

| |Поддержка одноранговых связей - отсутствует |

| |Справочная служба - Streettalk III, наиболее |

| |отработанная из имеющихся на рынке, с |

| |централизованным управлением, полностью |

| |интегрированная с другими сетевыми службами, |

| |распределенная, реплицируемая и автоматически |

| |синхронизируемая, отлично масштабируемая |

| |Согласованность работы с другими сетевыми ОС: |

| |хорошая; серверная оболочка работает в средах NetWare|

| |и UNIX; пользователи NetWare, Windows NT и LAN Server|

| |могут быть объектами справочной службы Streettalk III|

| | |

| |Служба сообщений - Intelligent Messaging, |

| |интегрирована с другими службами |

| |Поддерживаемые сетевые протоколы: VINES IP, TCP/IP, |

| |IPX/SPX, Appletalk |

| |Поддержка удаленных пользователей: ISDN, |

| |коммутируемые телефонные линии, X.25 |

| |Служба безопасности: поддерживает электронную подпись|

| |(собственный алгоритм), избирательные права доступа, |

| |шифрацию; не сертифицирована |

| |Простое обслуживание |

| |Хорошо масштабируется |

| |Отличная производительность обмена данными между |

| |серверами, хуже - при обмене сервер-ПК |

|Microsoft |Серверные платформы: компьютеры на базе процессоров |

|Windows NT|Intel, |

|Server |PowerPC, DEC Alpha, MIPS |

|3.51 и 4.0|Клиентские платформы: DOS, OS/2, Windows, Windows for|

| |Workgroups, Macintosh |

| |Организация одноранговой сети возможна с помощью |

| |Windows NT Workstation и Windows for Workgroups |

| |Windows NT Server представляет собой отличный сервер |

| |приложений: он поддерживает вытесняющую |

| |многозадачность, виртуальную память и симметричное |

| |мультипроцессирование, а также прикладные среды DOS, |

| |Windows, OS/2, POSIX |

| |Справочные службы: доменная для управления учетной |

| |информацией пользователей (Windows NT Domain |

| |Directory service), справочные службы имен WINS и DNS|

| | |

| |Хорошая поддержка совместной работы с сетями NetWare:|

| |поставляется клиентская часть (редиректор) для |

| |сервера NetWare (версий 3.х и 4.х в режиме эмуляции |

| |3.х, справочная служба NDS поддерживается, начиная с |

| |версии 4.0), выполненная в виде шлюза в Windows NT |

| |Server или как отдельная компонента для Windows NT |

| |Workstation; недавно Microsoft объявила о выпуске |

| |серверной части NetWare как оболочки для Windows NT |

| |Server |

| |Служба обработки сообщений - Microsoft Mail |

| |NT - Microsoft Message Exchange, интегрированная с |

| |остальными службами Windows NT Server |

| |Поддерживаемые сетевые протоколы: TCP/IP, IPX/SPX, |

| |NetBEUI, Appletalk |

| |Поддержка удаленных пользователей: ISDN, |

| |коммутируемые телефонные линии, frame relay, X.25 - с|

| |помощью встроенной подсистемы Remote Access Server |

| |(RAS) |

| |Служба безопасности: мощная, использует избирательные|

| |права доступа и доверительные отношения между |

| |доменами; узлы сети, основанные на Windows NT Server,|

| |сертифицированы по уровню C2 |

| |Простота установки и обслуживания |

| |Отличная масштабируемость |

|IBM LAN |Серверные платформы: операционные системы MVS и VM |

|Server 4.0|для мейнфреймов; AS/400 с OS/400, рабочие станции |

| |RS/6000 с AIX, серверы Intel 486 или Pentium под OS/2|

| | |

| |Поставляется с оболочками для клиентов: DOS, |

| |Macintosh, OS/2, Windows, Windows NT, Windows for |

| |Workgroups |

| |Серверы приложений могут быть организованы с помощью |

| |LAN Server 4.0 в операционных средах MVS, VM, AIX, |

| |OS/2, OS/400. В среде OS/2 поддерживаются: |

| |вытесняющая многозадачность, виртуальная память и |

| |симметричное мультипроцессирование |

| |Организация одноранговых связей возможна с помощью ОС|

| |Warp Connect |

| |Справочная служба - LAN Server Domain, то есть основа|

| |на доменном подходе |

| |Поддерживаемые сетевые протоколы: TCP/IP, NetBIOS, |

| |Appletalk |

| |Безопасность - избирательные права доступа, система |

| |не сертифицирована |

| |Служба обработки сообщений - отсутствует |

| |Высокая производительность |

| |Недостаточная масштабируемость |

3. ВЫБОР БАЗЫ ДАННЫХ

3.1. Определение СУБД

Традиционных возможностей файловых систем недостаточно для построения

даже простых информационных систем из-за возникающих потребностей, которые

не покрываются возможностями систем управления файлами:

. поддержание логически согласованного набора файлов;

. обеспечение языка манипулирования данными;

. восстановление информации после разного рода сбоев;

. реально параллельная работа нескольких пользователей.

Можно считать, что если прикладная информационная система опирается на

некоторую систему управления данными, обладающую этими свойствами, то эта

система управления данными является системой управления базами данных

(СУБД).

3.2. Основные функции СУБД

Более точно, к числу функций СУБД принято относить следующие:

3.2.1. Непосредственное управление данными во внешней памяти

Эта функция включает обеспечение необходимых структур внешней памяти

как для хранения данных, непосредственно входящих в БД, так и для служебных

целей, например, для убыстрения доступа к данным в некоторых случаях

(обычно для этого используются индексы). В некоторых реализациях СУБД

активно используются возможности существующих файловых систем, в других

работа производится вплоть до уровня устройств внешней памяти. В развитых

СУБД пользователи в любом случае не обязаны знать, использует ли СУБД

файловую систему, и если использует, то как организованы файлы. В

частности, СУБД поддерживает собственную систему именования объектов БД.

3.2.2. Управление буферами оперативной памяти

СУБД обычно работают с БД значительного размера; по крайней мере этот

размер обычно существенно больше доступного объема оперативной памяти.

Понятно, что если при обращении к любому элементу данных будет

производиться обмен с внешней памятью, то вся система будет работать со

скоростью устройства внешней памяти. Практически единственным способом

реального увеличения этой скорости является буферизация данных в

оперативной памяти. При этом, даже если операционная система производит

общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для

целей СУБД, которая располагает гораздо большей информацией о полезности

буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается

собственный набор буферов оперативной памяти с собственной дисциплиной

замены буферов.

3.2.3. Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых

СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД

фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней

памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.

Понятие транзакции необходимо для поддержания логической целостности БД.

Таким образом, поддержание механизма транзакций является обязательным

условием даже однопользовательских СУБД (если, конечно, такая система

заслуживает названия СУБД). Но понятие транзакции гораздо более важно в

многопользовательских СУБД.

То свойство, что каждая транзакция начинается при целостном состоянии

БД и оставляет это состояние целостным после своего завершения, делает

очень удобным использование понятия транзакции как единицы активности

пользователя по отношению к БД. При соответствующем управлении параллельно

выполняющимися транзакциями со стороны СУБД каждый из пользователей может в

принципе ощущать себя единственным пользователем СУБД (на самом деле, это

несколько идеализированное представление, поскольку в некоторых случаях

пользователи многопользовательских СУБД могут ощутить присутствие своих

коллег).

С управлением транзакциями в многопользовательской СУБД связаны важные

понятия сериализации транзакций и сериального плана выполнения смеси

транзакций. Под сериализаций параллельно выполняющихся транзакций

понимается такой порядок планирования их работы, при котором суммарный

эффект смеси транзакций эквивалентен эффекту их некоторого

последовательного выполнения. Сериальный план выполнения смеси транзакций -

это такой план, который приводит к сериализации транзакций. Понятно, что

если удается добиться действительно сериального выполнения смеси

транзакций, то для каждого пользователя, по инициативе которого образована

транзакция, присутствие других транзакций будет незаметно (если не считать

некоторого замедления работы по сравнению с однопользовательским режимом).

Существует несколько базовых алгоритмов сериализации транзакций. В

централизованных СУБД наиболее распространены алгоритмы, основанные на

синхронизационных захватах объектов БД. При использовании любого алгоритма

сериализации возможны ситуации конфликтов между двумя или более

транзакциями по доступу к объектам БД. В этом случае для поддержания

сериализации необходимо выполнить откат (ликвидировать все изменения,

произведенные в БД) одной или более транзакций. Это один из случаев, когда

пользователь многопользовательской СУБД может реально (и достаточно

неприятно) ощутить присутствие в системе транзакций других пользователей.

3.2.4. Журнализация

Одним из основных требований к СУБД является надежность хранения

данных во внешней памяти. Под надежностью хранения понимается то, что СУБД

должна быть в состоянии восстановить последнее согласованное состояние БД

после любого аппаратного или программного сбоя. Обычно рассматриваются два

возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно

трактовать как внезапную остановку работы компьютера (например, аварийное

выключение питания), и жесткие сбои, характеризуемые потерей информации на

носителях внешней памяти. Примерами программных сбоев могут быть: аварийное

завершение работы СУБД (по причине ошибки в программе или в результате

некоторого аппаратного сбоя) или аварийное завершение пользовательской

программы, в результате чего некоторая транзакция остается незавершенной.

Первую ситуацию можно рассматривать как особый вид мягкого аппаратного

сбоя; при возникновении последней требуется ликвидировать последствия

только одной транзакции.

Понятно, что в любом случае для восстановления БД нужно располагать

некоторой дополнительной информацией. Другими словами, поддержание

надежности хранения данных в БД требует избыточности хранения данных,

причем та часть данных, которая используется для восстановления, должна

храниться особо надежно. Наиболее распространенным методом поддержания

такой избыточной информации является ведение журнала изменений БД.

Журнал - это особая часть БД, недоступная пользователям СУБД и

поддерживаемая с особой тщательностью (иногда поддерживаются две копии

журнала, располагаемые на разных физических дисках), в которую поступают

записи обо всех изменениях основной части БД. В разных СУБД изменения БД

журнализуются на разных уровнях: иногда запись в журнале соответствует

некоторой логической операции изменения БД (например, операции удаления

строки из таблицы реляционной БД), иногда - минимальной внутренней операции

модификации страницы внешней памяти; в некоторых системах одновременно

используются оба подхода.

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал

(так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта

стратегия заключается в том, что запись об изменении любого объекта БД

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

попадет во внешнюю память основной части БД. Известно, что если в СУБД

корректно соблюдается протокол WAL, то с помощью журнала можно решить все

проблемы восстановления БД после любого сбоя.

Самая простая ситуация восстановления - индивидуальный откат

транзакции. Строго говоря, для этого не требуется общесистемный журнал

изменений БД. Достаточно для каждой транзакции поддерживать локальный

журнал операций модификации БД, выполненных в этой транзакции, и

производить откат транзакции путем выполнения обратных операций, следуя от

конца локального журнала. В некоторых СУБД так и делают, но в большинстве

систем локальные журналы не поддерживают, а индивидуальный откат транзакции

выполняют по общесистемному журналу, для чего все записи от одной

транзакции связывают обратным списком (от конца к началу).

При мягком сбое во внешней памяти основной части БД могут находиться

объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и

могут отсутствовать объекты, модифицированные транзакциями, которые к

моменту сбоя успешно завершились (по причине использования буферов

оперативной памяти, содержимое которых при мягком сбое пропадает). При

соблюдении протокола WAL во внешней памяти журнала должны гарантированно

находиться записи, относящиеся к операциям модификации обоих видов

объектов. Целью процесса восстановления после мягкого сбоя является

состояние внешней памяти основной части БД, которое возникло бы при

фиксации во внешней памяти изменений всех завершившихся транзакций и

которое не содержало бы никаких следов незаконченных транзакций. Для того,

чтобы этого добиться, сначала производят откат незавершенных транзакций

(undo), а потом повторно воспроизводят (redo) те операции завершенных

транзакций, результаты которых не отображены во внешней памяти.

Для восстановления БД после жесткого сбоя используют журнал и архивную

копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту

начала заполнения журнала (имеется много вариантов более гибкой трактовки

смысла архивной копии). Конечно, для нормального восстановления БД после

жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к

сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные

требования. Тогда восстановление БД состоит в том, что исходя из архивной

копии по журналу воспроизводится работа всех транзакций, которые

закончились к моменту сбоя. В принципе, можно даже воспроизвести работу

незавершенных транзакций и продолжить их работу после завершения

восстановления. Однако в реальных системах это обычно не делается,

поскольку процесс восстановления после жесткого сбоя является достаточно

длительным.

3.2.5. Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом

называемые языками баз данных. В ранних СУБД поддерживалось несколько

специализированных по своим функциям языков. Чаще всего выделялись два

языка - язык определения схемы БД (SDL - Schema Definition Language) и язык

манипулирования данными (DML - Data Manipulation Language). SDL служил

главным образом для определения логической структуры БД, т.е. той структуры

БД, какой она представляется пользователям. DML содержал набор операторов

манипулирования данными, т.е. операторов, позволяющих заносить данные в БД,

удалять, модифицировать или выбирать существующие данные.

В современных СУБД обычно поддерживается единый интегрированный язык,

содержащий все необходимые средства для работы с БД, начиная от ее

создания, и обеспечивающий базовый пользовательский интерфейс с базами

данных. Стандартным языком наиболее распространенных в настоящее время

реляционных СУБД является язык SQL (Structured Query Language).

Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет

определять схему реляционной БД и манипулировать данными. При этом

именование объектов БД (для реляционной БД - именование таблиц и их

столбцов) поддерживается на языковом уровне в том смысле, что компилятор

языка SQL производит преобразование имен объектов в их внутренние

идентификаторы на основании специально поддерживаемых служебных таблиц-

каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц

и их столбцов.

Язык SQL содержит специальные средства определения ограничений

целостности БД. Опять же, ограничения целостности хранятся в специальных

таблицах-каталогах, и обеспечение контроля целостности БД производится на

языковом уровне, т.е. при компиляции операторов модификации БД компилятор

SQL на основании имеющихся в БД ограничений целостности генерирует

соответствующий программный код.

Специальные операторы языка SQL позволяют определять так называемые

представления БД, фактически являющиеся хранимыми в БД запросами

(результатом любого запроса к реляционной БД является таблица) с

именованными столбцами. Для пользователя представление является такой же

таблицей, как любая базовая таблица, хранимая в БД, но с помощью

представлений можно ограничить или наоборот расширить видимость БД для

конкретного пользователя. Поддержание представлений производится также на

языковом уровне.

Наконец, авторизация доступа к объектам БД производится также на

основе специального набора операторов SQL. Идея состоит в том, что для

выполнения операторов SQL разного вида пользователь должен обладать

различными полномочиями. Пользователь, создавший таблицу БД, обладает

полным набором полномочий для работы с этой таблицей. В число этих

полномочий входит полномочие на передачу всех или части полномочий другим

пользователям, включая полномочие на передачу полномочий. Полномочия

пользователей описываются в специальных таблицах-каталогах, контроль

полномочий поддерживается на языковом уровне.

3.3. Варианты построения информационных приложений с использованием СУБД

Групповые и корпоративные информационные системы и соответствующие

приложения могут строиться различными способами:

. многотерминальные централизованные вычислительные системы;

. системы на основе локальной сети ПК (файл-серверные приложения);

. системы с архитектурой клиент-сервер;

Для лучшего понимания ограничений различных архитектур информационных

систем, разделим приложения на типовые.

Типовые компоненты информационных приложений

Выделим в информационном приложении типовые функциональные компоненты,

достаточные для формирования любого приложения на основе БД.

PS (Presentation Services) - средства представления. Обеспечиваются

устройствами, принимающими ввод от пользователя и отображающим то, что

сообщает ему компонент логики представления PL, плюс соответствующая

программная поддержка. Может быть текстовым терминалом или Х-терминалом, а

также ПК или рабочей станцией в режиме программной эмуляции терминала или Х-

терминала.

PL (Presentation Logic) - логика представления. Управляет

взаимодействием между пользователем и ЭВМ. Обрабатывает действия

пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе

элемента из списка.

BL (Business or Application Logic) - прикладная логика. Набор правил

для принятия решений, вычислений и операций, которые должно выполнить

приложение.

DL (Data Logic) - логика управления данными. Операции с базой данных

(SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для

реализации прикладной логики управления данными.

DS (Data Services) - операции с базой данных. Действия СУБД,

вызываемые для выполнения логики управления данными, такие как

манипулирование данными, определения данных, фиксация или откат транзакций

и т. п. СУБД обычно компилирует SQL - предложения.

FS (File Services) - файловые операции. Дисковые операции чтения и

записи данных для СУБД и других компонент. Обычно являются функциями ОС.

Можно привести несколько схем построения информационных систем (таблица

3.1.) в зависимости от размещения типовых компонентов приложения по узлам

сети.

Таблица 3.1. Схем построения информационных систем

| |с использованием |DL |FS |клиент-сервер, доступ|

3.3.1. Централизованные многотерминальные системы

В централизованной системе, характерной для Unix, терминал реализует

лишь функции представления данных PS, тогда как остальные функции

обеспечивает центральный узел. Центр должен реагировать на каждый запрос

пользователя (PL), выполнять логику приложения (BL, DL) и извлекать данные

из БД (DS, FS). Имеются две серьезные проблемы для централизованной схемы:

трудно обеспечить графический интерфейс; каждый дополнительный пользователь

и приложение вносят существенную нагрузку на сервер, теряется

масштабируемость.

3.3.2. Файл-серверные приложения

В отличии от централизованной системы архитектура "файл-сервер"

(таблица 3.1 и рисунок 3.1) не имеет сетевого разделения компонентов

диалога PS и PL, использует ПК для функций отображения, что облегчает

построение графического интерфейса. Файл-сервер только извлекает данные из

файлов, так что дополнительные пользователи и приложения добавляют лишь

незначительную нагрузку на ЦП. Каждый новый клиент добавляет вычислительную

мощность к сети.

[pic]

Рисунок 3.1.

Варианты построения файл-серверных приложений.

Объектами разработки в файл-серверном приложении являются компоненты

приложения, определяющие логику диалога PL, а также логику обработки BL и

управления данными DL. Разработанное приложение реализуется либо в виде

законченного загрузочного модуля или в виде специального кода для

интерпретации.

Однако такая архитектура имеет два основных недостатка: некоторые

запросы к БД могут перекачивать всю БД клиенту, загружая сеть и имея

непредсказуемое время реакции, тем самым, создавая значительный сетевой

график, а также возникающая проблема "толстого клиента" - Windows-

интерфейс, коды приложения и СУБД могут перегрузить даже мощный ПК.

Первый недостаток особенно сказывается при организации удаленного

доступа к базам данных на файл-сервере через низкоскоростные каналы связи.

В этом случае система с удаленными рабочими станциями оказывается

практически неработоспособной. В данным случае единственное решение -

удаленное управление файл-серверным приложением в сети (таблица 3.1 и

рисунок 3.1). В локальной сети ставится сервер приложений, совмещенный с

телекоммуникационным сервером (сервер доступа). В многозадачной среде этого

сервера выполняются обычные файл-серверные приложения. Особенность состоит

в том, что диалоговый ввод-вывод поступает через телекоммуникации от

удаленных клиентов. Приложения не должны быть слишком сложными, иначе шансы

перегрузки сервера увеличиваются, или же нужна очень мощная платформа для

сервера приложений. На клиентских узлах работают программы удаленного

управления или эмуляции терминалов, которые передают сигналы от клавиатуры

и мыши серверу приложений, а в ответ получают копии экранов и отображают их

на видеомониторе. Помимо перечисленных недостатков нужно отметить, что

многие "настольные СУБД", как традиционные инструменты файл-серверных

приложений, не отвечают требованиям сохранности данных, в частности не

поддерживают транзакции. Однако СУБД для ПК привлекают простотой

использования и доступностью, поэтому файл-серверные приложения еще будут

использоваться для рабочих групп.

3.3.3.Приложения клиент-сервер

Архитектура клиент-сервер предназначена для разрешения проблем файл-

серверных приложений путем разделения компонентов приложения и размещение

их там, где они будут функционировать более эффективно. Особенностью

архитектуры клиент-сервер является использование выделенных серверов баз

данных, понимающих запросы на языке структурированных запросов SQL и

выполняющих поиск, сортировку и агрегирование информации на месте без

излишней перекачки данных на рабочие станции.

Другая отличительная черта серверов БД - наличие словарьа данных, в

котором записаны структура БД, ограничения целостности данных, форматы и

даже серверные процедуры обработки данных по вызову или по событиям в

программе. Объектами разработки в таких приложениях помимо диалога и логики

обработки являются прежде всего реляционная модель данных и связанный с ней

набор SQL-операторов для типовых запросов для этой БД.

Большинство конфигураций клиент-сервер использует двухзвенную модель,

состоящую из клиента, который обращается к услугам сервера (сх. 3-5 в

таблице 3.1, рисунок 3.2). Для эффективной реализации такой схемы часто

применяют неоднородную сеть. Как минимум, предполагается, что диалоговые

компоненты PS и PL размещаются на клиенте, что позволяет обеспечить

графический интерфейс. Далее возможно разместить компоненты управления

данными DS и FS на сервере, а диалог (PS, PL), логику BL и DL на клиенте -

сх. 3 в таблице 3.1). Типовое определение архитектуры клиент-сервер -

приложение на клиенте, СУБД - на сервере - использует эту схему.

[pic]

Рисунок 3.2.

Варианты построения приложений клиент-сервер.

Поскольку эта схема предъявляет наименьшие требования к серверу, она

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

большое взаимодействие с БД, могут жестко загрузить как клиента, так и

сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому

что там находится логика принятия решения. Такая схема возлагает

дополнительное бремя администрирования приложений, разбросанных по

различным клиентским узлам.

Можно сократить нагрузку на клиента и сеть, переместив целиком

компонент BL на сервер, при этом вся логика принятия решений оформлена в

виде хранимых процедур и выполняется на сервере БД. Хранимая процедура -

процедура с операторами SQL для доступа к БД, вызываемая по имени с

передачей требуемых параметров и выполняемая на сервере БД. Компиляция

повышает скорость исполнения хранимых процедур и сокращает нагрузку на

сервер. Но, перегрузив хранимые процедуры прикладной логикой, можно

потерять преимущества по производительности. Хранимые процедуры улучшают

целостность приложений и БД, гарантируют актуальность коллективно

используемых операций и вычислений. Улучшается сопровождение таких

процедур, а также безопасность (нет прямого доступа к данным).

Переместив с клиента часть логики приложения на сервер, получим

систему клиент-сервер с разделенной логикой. Часть прикладной логики может

быть реализована на клиенте, а другая часть логики - в виде обработчиков

событий (триггеров) и хранимых процедур на сервере БД. Такая схема при

удачном разделении логики приводит к сбалансированной загрузке клиентов и

сервера, но при этом затрудняется сопровождение приложений.

[pic]

Рисунок 3.3.

Приложения клиент-сервер на основе многотерминальной системы.

На основе многотерминальной системы в качестве сервера приложений

также возможно создание архитектуры клиент-сервер (рисунок 3.3.). В этом

случае в многозадачной среде сервера приложений выполняются программы

пользователей, а клиентские узлы вырождены и представлены терминалами.

4. ВЫБОР ЯЗЫКА ПРОГРАММИРОВАНИЯ

Классификация средств разработки информационных приложений

Среди средств разработки информационных приложений можно выделить

следующие основные группы:

. традиционные системы программирования;

. инструменты для создания файл-серверных приложений;

. средства разработки приложений клиент-сервер;

Рассмотрим кратко отличительные черты и область применения каждой

группы инструментальных средств создания информационных приложений.

4.1.Традиционные системы программирования

Традиционные системы программирования представлены средствами создания

приложений на языках третьего поколения 3GL: C, Pascal, Basic и др. Среди

них по способам подготовки и выполнения программных модулей различают

системы компилирующего и интерпретирующего типа. Инструментальные средства

программирования могут быть представлены набором отдельных утилит (редактор

текстов, компилятор, компоновщик и отладчик) или интегрированной средой

программирования.

Процедурные языки программирования являются традиционными, они лишь

претерпели изменения от неструктурных до структурных языков

программирования. Объектно-ориентированное программирование - сравнительно

новое направление, однако оно в концептуальном плане более привлекательно,

позволяет рассматривать и реализовывать информационные и функциональные

свойства объектов в неразрывной связи.

Свойствами объектно-ориентированных языков, обуславливающими их

преимущества, являются сокрытие деталей реализации объекта (инкапсуляция),

наследование процедурных и информационных частей от объектов-родителей,

полиморфизм как возможность настройки на различные типы данных и др.

Примерами объектно-ориентированных систем программирования являются C++ и

Object Pascal.

Системы программирования 3GL нужны для организации специальных модулей

в информационных приложениях, для создания эффективных по быстродействию

программ обработки данных. Для создания с помощью систем программирования

полноценных информационных приложений необходимо расширить их за счет

использования библиотек диалога и доступа к базам данных, а также

макросредств встроенного языка структурированных запросов Embeded SQL.

Систему программирования Visual Basic можно использовать для создания

простых автономных приложений и компонентов VBX и OCX, для расширения и

интеграции функциональных пакетов (Word, Excel, Access), а также как

средство программирования для расширения систем документооборота и для

создания утилит администрирования.

С момента выхода продано существенно больше копий Delphi, чем Visual

Basic. Применение продукта возможно для создания расчетно-аналитических

программ, для разработки DLL, для сопровождения и развития разработок,

выполненных на Turbo и Borland Pascal, а также для быстрого

прототипирования будущих приложений. В ряде случаев решающим для выбора

будут умеренные требования Delphi-приложения к системно-техническому

обеспечению.

С++ применяется для расширения системного программного обеспечения,

для разработки крупных проектов, специальных приложений, создания библиотек

и классов для предметной области, разработки динамических библиотек DLL,

создания программного обеспечения для серверов приложений, разработки ОСХ,

использования совместно с CASE-системами, обеспечения многоплатформенности

и переносимости (по стандарту ANSI).

4.2. Инструменты для создания файл-серверных приложений

Основой разработки файл-серверных приложений для локальных сетей ПК

является инструментальное окружение различных "персональных" СУБД: FoxPro,

Clipper, Paradox, Clarion, Paradox, dBase и т.п. Такие средства, как

правило, реализованы в виде диалоговой интегрированной среды,

предоставляющих три уровня доступа:

. программирование и создание приложений на языке, сочетающем возможности

языка 3GL с некоторыми возможностями языков четвертого поколения 4GL;

. создание и ведение структуры БД и индексов, а также интерактивная

генерация макетного приложения и его компонентов (меню, форм или окон,

отчетов, запросов и программных модулей);

. использование диалоговой среды и генераторов конечными пользователями для

создания, ведения и просмотра БД, а также формирования несложных запросов

и отчетов.

Диалоговые среды поддерживают как текстовой для DOS, так и графический

интерфейс пользователя для Windows. Внедрение графического интерфейса

привело к развитию объектных свойств инструментов, средств визуальной

генерации программ и событийного механизма приложений.

База данных для этих СУБД представляет собой совокупность файлов БД и

индексов, а не единое информационное пространство, что усложняет ее

сопровождение. Ни одна из традиционных СУБД для ПК не имеет средств

ограничения целостности. Среди инструментальных средств СУБД для ПК

преобладают интерпретирующие системы, хотя многие предоставляют и

альтернативную возможность создания загрузочных модулей приложений.

СУБД для ПК MS Access может использоваться для создания масштабируемых

одиночных и групповых информационных приложений и для разработки клиентской

части приложений клиент-сервер, а также как средство автоматизации

делопроизводства в составе MS-Office.

Традиционные инструментальные средства класса xBase (такие как FoxPro,

Clipper, dBase и др.) теряют рынок (число их продаж значительно

сокращается) из-за несоответствия современным требованиям. По мере того,

как предприятия все шире используют СУБД MS Access и новые средства

разработки, такие как Visual Basic и Delphi, популярность среды Xbase

уменьшается. Более того, Microsoft может прекратить поддержку FoxPro, так

как эта СУБД с устаревшим языком и сокращающейся рыночной долей не

вписывается в долговременную стратегию развития средств разработки, которую

Microsoft строит вокруг Visual Basic и Access. Новые "визуальные"

инструменты этого класса (Visual FoxPro, CA-Visual Objects, Visual dBase)

пытаются сохранить и расширить прежний ареал. Они могут быть рекомендованы

для сопровождения и развития прежних xBase-разработок, для создания

масштабируемых одиночных и групповых файл-серверных приложений и для

переноса и адаптации приложений в архитектуру клиент-сервер с

использованием интерфейса ODBC. Но нужно четко осознавать, что при

применении нового инструментария для создания диалога и с переходом на SQL-

операторы от прежних xBase-приложений остается ничтожно мало, а, кроме

того, существенно меняется подход к разработке, и прежние навыки вряд ли

будут востребованы.

Инструментальное средство MS Access хорошо зарекомендовало себя в

разработке файл-серверных приложений с возможностью масштабирования, так

как оно имеет удобные средства визуального конструирования, отладки и

возможности использования как Access Basic, так и SQL. Интерфейс ODBC

открывает широкие возможности интероперабельности с различными СУБД. В 1995

г. на долю MS Access пришлось 57% рынка настольных баз данных, а FoxPro и

dBase - 9% и 2%, соответственно

4.3. Средства разработки приложений клиент-сервер

Группу инструментальных средств для создания информационных приложений

с архитектурой клиент-сервер можно разделить на следующие подгруппы:

. среды разработки приложений для серверов баз данных, независимые от СУБД

инструменты для создания приложений клиент-сервер;

. средства поддержки распределенных информационных приложений.

4.3.1. Среды разработки приложений для серверов баз данных

Среды разработки приложений для серверов БД представляют собой системы

программирования четвертого поколения 4GL или инструментальные средства

быстрой разработки приложений RAD (Rapid Application Development).

Особенностями этой подгруппы средств являются: реализация удаленного

доступа к СУБД по двухзвенной схеме клиент-сервер; связь клиентских

приложений с серверами БД с помощью непроцедурного языка структурированных

запросов SQL (кроме серверов Btrieve); обеспечение целостности БД, включая

целостность транзакций; поддержка хранимых процедур на серверах БД;

реализация клиентских и серверных триггеров-процедур; генерация элементов

диалогового интерфейса и отчетов.

В качестве примера можно назвать инструменты Informix/4GL,

Oracle*Forms и др. Сейчас новые среды разработки SQL-серверов БД (Informix

NewEra и Oracle Power Objects) развиваются в сторону независимых от СУБД

инструментов. Независимые инструментальные средства, ориентированные на

многие платформы СУБД, представлены в виде средств быстрой разработки

приложений RAD. Для таких средств создания приложений клиент-сервер

характерны: возможность распределения приложения на клиентах и/или

серверах; создание приложений для разных серверов БД; поддержка

спецификации ODBC для доступа к различным серверам БД, включая СУБД для ПК;

связь с мониторами транзакций для организации трехзвенной архитектуры

приложений клиент-сервер; объектно-ориентированное программирование

приложений; визуальный характер генерации приложения; ведение репозитария

объектов и их свойств, что облегчает интеграцию со средствами автоматизации

проектирования программ CASE; управление проектами и версиями приложений;

интеграция приложения с электронной почтой и средствами офисной

автоматизации.

Известными примерами независимых инструментальных средств разработки

являются: ErWin, SQLWindows, PowerBuilder, JAM и Uniface.

4.3.2. Средства поддержки распределенных информационных приложений

Средства поддержки распределенных приложений относятся к категории

промежуточного программного обеспечения middleware для организации серверов

приложений. Сюда входят разнообразные библиотеки и наборы инструментальных

средств: интерфейсы доступа к базам данных ODBC и IDAPI; шлюзы для систем

управления базами данных; протоколы и команды мониторов обработки

транзакций; почтовые интерфейсы MAPI, VIM, MHS, X.400 и EDI; средства

обмена сообщениями MOM; протоколы связывания и включения объектов OLE и

динамического обмена данными DDE; протоколы удаленного вызова процедур RPC

и именованных конвейеров Named Pipes, средства коммуникационного ввода-

вывода BSD Sockets и WinSock.

Инструментальные наборы для разработки приложений клиент-сервер

необходимо выбирать, исходя из следующих критериев (см. таблицу 4.1):

наличие объектно-ориентированной инфраструктуры, возможности распределения

приложений между клиентом и сервером, обеспечена ли поддержка мониторов

транзакций, доступность CASE-репозитария, возможность переноса приложений и

контроль версий. При этом следует выяснить, насколько опыт разработчиков

предприятия соответствует требованиям продукта, важна ли переносимость

приложений на другие аппаратные платформы и базы данных, какая степень

интеграции приложений устроит заказчика и нужно ли будет в дальнейшем

подключать к приложению дополнительных пользователей, функции и данные.

Таблица 4.1. Инструментальные наборы для разработки приложений клиент-

сервер

| |ра |клиентом | | | |

| | |и | | | |

|JAM |нет |да |да |нет |нет |

|New Era |да |нет |нет |да |да |

|Developer |нет |да |да |да |да |

|2000 | | | | | |

|Power |да |нет |да |да |да |

|Delphi |да |нет |да |да |да |

|MS-Access |нет |нет |нет |нет |нет |

|Oracle |да |нет |нет |нет |да |

Кроме того, развитие современных программных средств приводит к

расширению их функциональных возможностей, в результате чего программные

обеспечения разных типов конкурируют друг с другом. Так, продукт Borland

C++ Builder превращающий компилятор Borland Visual C++ в полноценную среду

разработки приложений в архитектуре клиент-сервер. Предлагаемый продукт

дополняет C++ визуальными "дизайнерами", интуитивными "мастерами" и

средствами доступа к объектно-ориентированным данным, сохраняя знакомое

окружение Visual C++.

Мощное средство Oracle Forms из набора Developer/2000 предназначено для

создания приложений баз данных в среде клиент/сервер, которые могут быть

перенесены на платформы с различными графическими и символьными

пользовательскими интерфейсами. Oracle Forms является частью

Developer/2000, который поддерживает разработку приложений во время всего

жизненного цикла. Приложения, созданные с помощью Developer/2000, полностью

масштабируемы и применимы на любом уровне: от систем поддержки принятия

решений для небольших рабочих групп до проектов с большим объемом

транзакций, которые поддерживают сотни пользователей. Приложения, созданные

с помощью Developer/2000, оптимизированы с целью использования всех

преимуществ сервера Oracle7, поэтому они должны быть основными средствами

при разработке приложений в среде Oracle7.

Инструментальная среда NewEra для СУБД Informix обладает всеми

свойствами для эффективной разработки приложений в этой среде.

Дополнительные преимущества - возможность интеграции с программами на С и

многоплатформенность - делают ее пригодной не только при разработке

приложений для СУБД Informix, но и для других систем. Следует заметить, что

вопрос интероперабельности Informix-Oracle решен неудовлетворительно.

Uniface поддерживает интерфейс практически со всеми известными

программно-аппаратными платформами, протоколами, СУБД и мониторами

транзакций. Это средство необходимо использовать при разработке и

сопровождении типовых комплексов приложений с высокой тиражируемостью.

Платой за универсализм является высокая стоимость продукта.

Анализ и апробация возможностей MS Access показал, что это

инструментальное средство хорошо зарекомендовало себя как в разработке файл-

серверных приложений, так и для разработки клиентской части приложений в

архитектуре клиент/сервер, наличие поддержки языка SQL и интерфейса ODBC

открывает доступ к SQL-серверам БД. Имеется средство для миграции

приложений MS Access в среду MS SQL Server. К достоинствам Access следует

отнести и пониженные требования к ресурсам. К сожалению, последние версии

пакета ориентированы лишь на офисную автоматизацию и не содержат runtime-

компонент для создания законченного информационного приложения.

Средство JAM имеет недостаточную разрядность и может быть использовано

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

аналитических систем. Но его отличает многоплатформенность и поддержка

мониторов транзакций.

Пакет Oracle Power Object предназначен для разработчиков, впервые

приступающих к разработке приложений клиент-сервер и переходящих от таких

систем, как FoxPro или Clipper, и наиболее пригоден для создания прототипов

больших систем.

Система Delphi чрезвычайно удобна для разработки приложений локальных

баз данных, которые при необходимости могут быть конвертированы в

приложения типа клиент-сервер. Delphi следует использовать для создания

масштабируемых приложений для рабочих групп, для разработки средств доступа

к различным БД, для создания аналитических систем, для создания одиночных и

групповых приложений, критичных по времени выполнения.

Все три средства - JAM, Oracle Power Object и Delphi - пригодны для

создания быстрых прототипов, и их использование в таком качестве может

иметь определенные достоинства.

5. ВЫВОДЫ ПО ВЫБОРУ ОПЕРАЦИОННОЙ СИСТЕМЫ, ЯЗЫКА ПРОГРАММИРОВАНИЯ И БАЗЫ

ДАННЫХ

Первоочередной задачей является выбор варианты построения

информационных приложений с использованием СУБД. Из рассмотренных вариантов

системы с архитектурой клиент-сервер наиболее эффективная и дешевая для

больших баз данных и множества пользователей, которым нужен доступ к

«свежим» данным. В масштабе предприятия вычисления клиент/сервер —

представляют собой ни что иное, как распределение обработки в

многопользовательской базе данных по нескольким компьютерам (ПК и рабочим

станциям).

Что же дает вычисление клиент/сервер по сравнению с традиционной

однокомпьютерной средой (с одной большой ЭВМ)? При корректной реализации

системы клиент/сервер получается система управления информацией с намного

лучшим отношением «цена/производительность», которую можно наращивать и

легко приспосабливать к меняющимся требованиям. Другой причиной выбора

технологии клиент/сервер является то обстоятельство, что менеджерам уже

более не нужно отслеживать сотни, а то и тысячи программ, нуждающихся в

обновлении и перекомпилировании каждый раз при небольшом изменении в базе

данных. К плюсам технологии клиент/сервер можно отнести простоту и удобство

пользовательских интерфейсов, открытость систем, эффективную среду

разработки (особенно при наличии объектно-ориентированных инструментов) и

быстроту решений.

На сегодняшний момент только четыре базы являются приемлемыми для

надежного хранения больших данных и удобства использования: Oracle,

Informix, Sysbase, Ingres.

Исходя из популярности в России (в ВПК) и на основе проведенного

анализа по литературе в частности [2],[3],[4] и из опыта работы компаний

«Рос.вооружение», НИИ «Восход», «Инком Банк» была выбрана база данных

Oracle.

Вторая задача это выбор операционной системы. На основании выводов

в главе 2.5. и таблицы 2.1 была выбрана Novell Netware 4.11 как основная

система для работы базы данных Oracle. Определяющими параметрами при выборе

были: надежность и стабильность работы, небольшее требование к ресурсам

системы и стоимость, возможность безболезненного переноса на платформу

Windows/NT. Ввиду полномасштабного использования компьютеров типа Pentium и

операционной системы Windows 95, а так же удобством разработки,

использования проектируемого продукта, работы с отчетными программами, в

качестве клиентских приложений была выбрана Windows 95.

На основании главы 4.3.2. и таблицы 4.1, а так же прочитанной

литературы [5],[6],[7],[8] и опыта программистов фирм: «Формоза-центр»,

«Инком Банк», «Рос.вооружение» был выбран язык программирования Delphi, как

наиболее удобный для работы с клиент/серверными приложениями, а так же в

плане перевода локальных баз данных на архитектуру клиент/сервер. Данный

язык, как никакой другой, поддерживает основные тенденции(направления)

современного языка программирования.

Одно направление - объектно-ориентированный подход, хорошо

структурирующий задачу, как таковую, так и ее решение в виде прикладной

системы.

Другое направление, возникшее во многом благодаря объектной

ориентации, - визуальные средства быстрой разработки приложений (RAD -

Rapid Application Development), основанные на компонентной архитектуре.

Третья тенденция - использование компиляции, а не интерпретации. Это

объясняется тем, что скоростные характеристики компилируемых приложений в

десятки раз лучше, чем у систем, использующих интерпретатор. При этом

повышается легкость отчуждаемости готовых систем, так как отпадает

необходимость "таскать за собой" сам интерпретатор (run-time), выполненный

обычно в виде динамической библиотеки и занимающий в лучшем случае

несколько сотен килобайт (а большинстве случаев - два-три мегабайта).

Отсюда и меньшая ресурсоемкость у скомпилированных систем.

Четвертая тенденция - возможность работы с базами данных

универсальными (единообразными) методами. Если мы попытаемся оценить

процент систем, которые так или иначе требуют обработки структурированной

информации (как для внутрикорпоративного использования, так и для

коммерческого или иного распространения), то окажется, что цифра 60- 70%

может представлять лишь нижнюю границу. Важным свойством средств

обеспечения доступа к базам данных является их масштабируемость, как

возможность не только количественного, но и качественного роста системы.

Например, обеспечение перехода от локальных ,в том числе, файл-серверных

данных к архитектуре клиент-сервер или тем более к многоуровневой N-tier

схеме.

Delphi создавался как продукт, в полной мере реализующий описанные

тенденции, с архитектурой, открытой для расширения спектра поддерживаемых

стандартов и подходов. Рассмотрим, насколько Delphi удовлетворяет выше

перечисленным требованиям.

Delphi использует язык 3-го поколения Object Pascal, обладающий полной

реализаций основных признаков объектной ориентации (инкапсуляция,

наследование, полиморфизм), поддержкой RTTI-RunTime Type Information и

встроенной обработкой исключительных ситуаций (Exception handling).

Компонентная архитектура Delphi является прямым развитием поддерживаемой

объектной модели. Все компоненты являются объектными типами (классами), с

возможностью неограниченного наследования. Компоненты Delphi поддерживают

PME-модель (Property, Method, Events), позволяющую изменять поведение

компонентов без необходимости создания новых классов.

Компоненты Delphi 2.Delphi 2 Client/Server Suite включает систему

контроля версий Intersolv PVCS, поддерживает работу со словарем данных

(Data Dictionary) и Репозитарием объектов (Object Repository). Среда

визуальной разработки Delphi позволяет единообразно работать как с

предопределенными, так и с пользовательскими компонентами, которые

разрабатываются на том же языке (Object Pascal), на котором создаются и

конечные приложения.

Borland Database Engine (BDE) обеспечивает единообразную работу с

локальными данными (Paradox, dBase) и серверами БД (Oracle, Sybase, MS SQL

Server, InterBase и т.д.), за счет применения навигационных методов доступа

к серверным СУБД (двунаправленные курсоры, закладки и т.п.) и SQL - к

локальным форматам (подмножество Local SQL).

Компилятор Delphi является самым быстрым; имеет общий генератор кода с

Borland C++ (Delphi 2 & BC++ 5). Компилятор Delphi (точнее, Object Pascal)

является продолжением линии компиляторов Turbo Pascal / Borland Pascal.

Открытые интерфейсы Delphi - Open Tools API - обеспечивают контроль

над средой разработки "из вне" и доступ к информации о проекте.

[pic]

Рисунок 7.1. Borland Database Engine

6. СТРУКТУРА И ОСНОВНЫЕ ЗАДАЧИ УПРАВЛЕНИЯ ПО ДЕЛАМ ГРАЖДАНСКОЙ ОБОРОНЫ И

ЧРЕЗВЫЧАЙНЫМ СИТУАЦИЯМ

6.1. Определение ГО

Гражданская оборона - постоянно действующий орган управления МЧС. Она

предназначена для предупреждения возникновения и развития чрезвычайных

ситуаций в мирное и в военное время, а также для ликвидации чрезвычайных

ситуаций при их возникновении.

Гражданская оборона объединяет:

. городские, окружные и районные органы исполнительной власти и управления

экономикой, коммунальным хозяйством; общественные организации, в

компетенцию которых входят функции, связанные с безопасностью и защитой

населения, предупреждением, реагированием и действиями ЧС;

. организации(объекты), независимо от формы собственности и ведомственной

принадлежности.

. силы и средства указанных органов управления, организаций(объектов),

используемые в целях координации их деятельности по предупреждению ЧС,

защите населения, материальных и культурных ценностей, окружающей среды,

ликвидации ЧС.

6.2. Основные задачи ГО

1. Создание и поддержание в готовности систем управления, сил и средств,

чрезвычайных резервов финансовых и материальных ресурсов.

2. Организация наблюдения и контроля за состоянием окружающей среды и

потенциально опасных объектов, прогнозирование чрезвычайных ситуаций.

3. Разработка и осуществление мер направленных на защиту населения,

повышение устойчивости функционирования отраслей экономики и городского

хозяйства в чрезвычайных ситуациях.

4. Совершенствование и обеспечение функционирования системы подготовки

органов управления, специалистов МЧС, обучение населения действиям в

чрезвычайных ситуациях.

5. Оповещения населения о возникновении чрезвычайной ситуации и порядке

действий в сложившейся обстановке.

6. Проведение работ по ликвидации чрезвычайных ситуаций, первоочередному

жизнеобеспечению населения, в первую очередь пострадавшего.

6.3. Схема управления по делам ГО и ЧС

[pic]

Рисунок 6.1. Схема управления по делам ГО и ЧС

Из существующей схемы управления по делам ГО и ЧС видно, что

данная организация разбита на 7 основных групп в которой есть свои отделы.

Первоочередной задачей для каждого отдела является оценка

складывающейся обстановки в возникшей ЧС. Соответственно каждому отделу

нужна информация об объекте (наличие опасных веществ, наличие защитных

сооружений, общая численность людей и т.д.) на котором возникла данная ЧС и

информация о близлежащих объектах для возможной эвакуации людей или

привлечения техники, различных формирований с других объектов.

К примеру, отделу радиационной, химической и биологической защиты

необходимы данные о количестве хранимых веществ на объекте; отделу

технического обеспечения оснащенность ближайших объектов техникой и т.д.

Данный проект позволяет вести необходимую информацию о объектах ГО и

оценить в ЧС складывающеюся обстановку.

7. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ СИСТЕМЫ УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ

ОБЪЕКТОВ ГО.

7.1. Назначение и цели создания программного продукта

Данное программное средство должно выполнять технологические функции

в интересах системы предупреждения и ликвидации ЧС.

Целью работы является создание одного из программных средств,

обеспечивающего:

. автоматизацию процесса подготовки к принятию решений при возникших ЧС;

. регистрацию объектов экономики и составление списка характеристик

объекта;

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

. техники;

. защитных сооружений;

. химически опасных веществ;

. материально-технических средств;

. формирований на объекте;

. снижение расходов на подготовку и уточнения списков объектов;

. учета готовности объекта к ЧС;

. учета проведения занятий с обучающимися в УМЦ.

. уменьшение времени на подготовку списков объектов экономики и списков

обучающихся на УМЦ по различным критериям;

7.2. Решаемые задачи

Ведение данных:

. объектов экономики;

. защитных сооружениях;

. опасных веществах;

. техники;

. материально-технических средств;

. формирований;

. обучаемых на УМЦ;

Формирование списков:

. объектов экономики;

. защитных сооружениях;

. опасных веществах;

. техники;

. материально-технических средств;

. формирований;

. обучаемых на УМЦ;

Составление статистической информации.

7.3. Определение необходимых таблиц базы данных

Рассмотрев определенные выше задачи можно спроектировать основные

таблицы базы данных. Для реализации данных задач потребуются следующие

таблицы:

1. таблица объектов экономики;

2. таблица-словарь территориальной принадлежности объектов;

3. таблица-словарь степени опасности объектов;

4. таблица-словарь характера деятельности в опасный период;

5. таблица-словарь ведомственной принадлежности объектов;

6. таблица-словарь формы собственности объектов;

7. таблица-словарь рода деятельности объектов;

8. таблица-словарь гражданских должностей руководителей объектов;

9. таблица-словарь должностей по ГО начальников ГО объектов;

10. таблица опасных веществ на объектах;

11. таблица-словарь опасных веществ;

12. таблица защитных сооружений на объектах;

13. таблица-словарь защитных сооружений;

14. таблица технических средств на объектах;

15. таблица-словарь технических средств;

16. таблица формирований на объектах;

17. таблица-словарь формирований;

18. таблица-словарь степени готовности формирований;

19. таблица-словарь служб ГО;

20. таблица материально-технических средств на объектах;

21. таблица-словарь материально-технических средств;

22. таблица обучаемых на УМЦ;

23. таблица-словарь должностей обучаемых;

24. таблица-словарь категории обучаемых;

25. таблица тем обучения по категориям;

26. таблица-словарь тем обучения;

27. таблица пользователей программы;

28. таблица соответствия идентификаторов пользователей программы и базы

данных Oracle;

Этот список строился из следующей цепи рассуждений:

Первая из основных задач приложения - регистрация объектов экономики.

Очевидно, что для того, чтобы хранить эту информацию, понадобится таблица

объектов экономики. Но даже после введения этой таблицы придется

регистрировать одну и туже информацию, к примеру, о районе при вводе

объектов одного и того же района. Чтобы избежать постоянного ввода названия

района, к которому принадлежит объект необходимо создать дополнительную

таблицу-словарь по районам (по территориальной принадлежности). По этой же

причине созданы и другие таблицы-словари.

Вторая из основных задач - это ввод дополнительной информации, к

примеру, о хранимых материально-технических средствах на объекте. Все эти

данные можно было бы хранить и в основной таблице, но тогда встает проблема

в количестве резервирования столбцов в главной таблице под каждый вид

средства. Можно было бы создать отдельную таблицу хранимых материально-

технических средств на объекте для каждого отдела. Но это не удобно, так

как нужно создавать столько таблиц, сколько отделов. Так же встает вопрос

при хранении новых материально-технических средств при создании нового

отдела(службы). Именно по этой причине создана отдельная таблица, в которой

содержится информация о всех хранимых МТС с ссылкой на название отдела.

Соответственно дополнение к таблице объектов экономики служат

таблицы:

. опасных веществ на объектах;

. защитных сооружений на объектах;

. технических средств на объектах;

. формирований на объектах;

. материально-технических средств на объектах;

. обучаемых на УМЦ;

В свою очередь каждая такая таблица имеет таблицу-словарь(и) на

которую она ссылается.

В данной базе данных предусмотрена защита информации, т.е. любые

действия по изменению данных в таблицах фиксируются автоматически в

соответствующих полях этой таблицы. Чтобы корректно отображать имена

операторов(людей которые будут заниматься вводом и корректировкой

информации) предусмотрена таблица пользователей программы, где хранится его

уникальный номер в системе GOBASE и его имя.

Так же существует дополнительная таблица соответствия идентификаторов

пользователей программы и базы данных Oracle. Каждому идентификатору

пользователя сопоставлен уникальный регистрационный номер пользователя в

базе данных Oracle. Через уникальный регистрационный номер пользователя

определяются его полномочия на работу с базой данных и его имя, которое

отображается в соответствующих полях ввода и корректировки.

В основных таблицах предусмотрена дополнительная информация по тому

кто и в какое время ввел данные в таблицу. Это поля:

|DATEADD |Дата ввода информации |

|NAMEADD_ID |Идентификатор пользователя, который ввел данные |

|DATEINS |Дата последней коррекции |

|NAMEINS_ID |Идентификатор пользователя, который изменил |

| |данные |

Для ввода дополнительной информации в основных таблицах предусмотрено

поле PRIM.

При проектировании таблиц важно уделять внимание нормализации базы

данных.

7.4. Нормализация базы данных

Процесс трансформации данных в реляционную форму называется

нормализацией[9]. Говоря проще, нормализация - это удаление избыточных

данных из каждой таблицы в базе данных. У нормализации двойная цель -

удалить лишние копии данных и обеспечить максимальную гибкость как в

структурах таблиц, так и в интерфейсных приложениях на случай возможных

будущих изменений в базах данных.

О нормализации таблиц в базе данных нужно заботится на раннем этапе

проектирования приложения, так как при «живых» данных довольно трудно

менять структуру базы. Иногда процесс нормализации порождает добавочные

таблицы, которые были не включены в первоначальный проект. Узнав об этом

как можно раньше, не придется зря тратить силы на их разработку.

Нормализация обычно подразделяется на пять форм или стадий— от первой

нормальной формы по пятую нормальную форму. То есть просто пять установок

реляционного критерия, который либо обнаруживает таблицу, либо нет. Каждая

последующая стадия строится на предыдущей. Формально существует пять форм,

но на практике, как правило, используется только первые три. Последние две

считаются слишком специальными, чтобы их применять к обычным проектам баз

данных.

7.4.1. Первая нормальная форма

Для того чтобы таблица считалась нормализованной к первой нормальной

форме, каждое из ее полей должно быть неделимым и не должно содержать

никаких повторяющихся групп.

Поле считается неделимым, если оно содержит только один элемент

данных. Например, поле Address, которое содержит не только название улицы,

но также и города, почтовый код, не является неделимым. Чтобы

соответствовать первой нормальной форме, такие столбцы должны быть разбиты

на несколько полей.

Повторяющаяся группа — это поле, которое повторяется внутри

определения записи с целью хранения нескольких значений для атрибута.

7.4.2. Вторая нормальная форма

Для того чтобы привести таблицу ко второй нормальной форме, нужно,

чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и

от каждого поля в первичном ключе, если последний состоит из нескольких

полей. Это значит, что каждое не ключевое поле должно уникально

определяться первичным ключом и полями, его составляющими.

7.4.3. Третья нормальная форма

Для того чтобы таблица была приведена к третьей нормальной форме,

нужно, чтобы все не ключевые поля полностью зависели от первичного ключа

таблицы и не зависели друг от друга. Таким образом, к квалификации второй

нормальной формы добавляется требование независимости каждого не ключевого

поля таблицы от других не ключевых полей.

7.4.4. Четвертая нормальная форма

Четвертая нормальная форма запрещает хранить независимые элементы в

одной и той же таблице, когда между этими элементами существуют

взаимоотношения типа многие-ко-многим. Четвертая нормальная форма требует,

чтобы запомнили такие элементы в отдельных таблицах и создали таблицу

отношений для организации связей между таблицами, характеризующихся

взаимоотношениями типа многие-ко-многим.

Конечно же, поскольку два столбца находятся во взаимоотношении многие-

ко-многим, то они уже не являются независимыми, и тем самым уже нарушают

третью нормальную форму. По этой причине четвертая нормальная форма

рассматривается больше теоретически, т.к. частично она перекрывается

третьей нормальной формой.

7.4.5. Пятая нормальная форма

Пятая нормальная форма требует, чтобы вы имели возможность

перестраивать свои данные в нормализованных таблицах, в которые они были

переведены. Это значит, что если вы начинаете с ненормализованных таблиц,

то у вас не должно быть препятствий к вырезке и вставке данных и после

нормализации. Это осуществимые, если есть гарантия, что в процессе

нормализации не будет потери данных.

На практике идея сохранения всех элементов в базе данных в процессе

нормализации воплощается чисто интуитивно. Ведь вряд ли будут слепо

выбрасывать из таблиц элементы данных. Но тем не менее, пятая нормальная

форма призвана застраховать вас от такого несчастного случая.

7.5. Определение столбцов в таблицах

Таблицы 7.1

|OBECONOM |Таблица объектов экономики |

|Столбец |Наименование |Ключ|

|OBJECT_ID |ID - уникальный ключ строки в таблице|PK |

|OBJECTNO |регистрационный номер объекта | |

|OBJECTNAME |наименование объекта | |

|ADDRESS_IND |почтовый индекс | |

|ADDRESS_CHAR |адрес объекта | |

|WORKNUMBER |количество работающих | |

|NRSM |наибольшая работающая смена в мирное | |

| |время | |

|NRSW |наибольшая работающая смена в военное| |

| |время | |

|DEPORTAMENT_ID |ведомственная принадлежность |FK |

|PECULIAR_ID |характер деятельности в особый период| |

| |(FK) | |

|RISK_ID |степень опасности |FK |

|REGION_ID |территориальная принадлежность |FK |

|ACTIVITY_ID |род деятельности |FK |

|PROPERTY_ID |форма собственности |FK |

|GLAVOBJECT_ID |подчиненность объекта |FK |

|DIRECTIONNAME |Ф.И.О. руководителя объекта | |

|POST_ID |занимаемая должность руководителя |FK |

| |объекта | |

|DIRECTIONWTEL |рабочий телефон руководителя объекта | |

|DIRECTIONHTEL |домашний телефон руководителя объекта| |

|COMMANDGONAME |Ф.И.О. начальника штаба ГО объекта | |

|POSTGO_ID |должность начальника штаба ГО объекта|FK |

|COMMANDGOWTEL |рабочий телефон начальника штаба ГО | |

| |объекта | |

|COMMANDGOHTEL |домашний телефон начальника ГО | |

| |объекта | |

|ZAMNAME |Ф.И.О. заместителя руководителя | |

|ZAMWTEL |рабочий телефон заместителя | |

| |руководителя | |

|ZAMHTEL |домашний телефон заместителя | |

| |руководителя | |

|P1NAME |Ф.И.О. председателя КЧС | |

|P1WTEL |рабочий телефон председателя КЧС | |

|P1HTEL |домашний телефон КЧС | |

|P2NAME |Ф.И.О. председателя ЭК | |

|P2WTEL |рабочий телефон председателя ЭК | |

|P2HTEL |домашний телефон ЭК | |

|P3NAME |Ф.И.О. председателя ПУФ | |

|P3WTEL |рабочий телефон председателя ПУФ | |

|P3HTEL |домашний телефон ПУФ | |

|DUTYTEL |телефон дежурного по объекту | |

|DUTY2TEL |телефон секретаря | |

|FAXTEL |факс | |

|MODEMTEL |модем | |

|NAMEADD_ID |владелиц |FK |

|DATEADD |дата ввода | |

|NAMEINS_ID |корректировщик |FK |

|DATEINS |дата последней коррекции | |

|PRIM |примечание | |

| | | |

|DEPARTAMENT |Таблица-словарь ведомств | |

|DEPARTAMENT_ID |ID - уникальный ключ строки в таблице|PK |

|DEPARTAMENT_CHAR |Наименование | |

| | | |

|PECULIAR |Таблица-словарь деятельностей в ОП | |

|PECULIAR_ID |ID - уникальный ключ строки в таблице|PK |

|PECULIAR_CHAR |Наименование деятельностей в ОП | |

| | | |

|REGION |Таблица-словарь районов | |

|REGION_ID |ID - уникальный ключ строки в таблице|PK |

|REGION_CHAR |Наименование районов | |

| | | |

|RISK |Таблица-словарь степени опасности | |

| |объектов | |

|RISK_ID |ID - уникальный ключ строки в таблице|PK |

|RISK_CHAR |Наименование степени опасности | |

| |объектов | |

| | | |

|PROPERTY |Таблица-словарь форм собственности | |

|PROPERTY_ID |ID - уникальный ключ строки в таблице|PK |

|PROPERTY_CHAR |Наименование форм собственности | |

| | | |

|ACTIVITY |Таблица-словарь рода деятельности | |

| |объектов | |

|ACTIVITY_ID |ID - уникальный ключ строки в таблице|PK |

|ACTIVITY_CHAR |Наименование рода деятельности | |

| |объектов | |

| | | |

|POST |Таблица-словарь гражданских | |

| |должностей | |

|POST_ID |ID - уникальный ключ строки в таблице|PK |

|POST_CHAR |Наименование гражданских должностей | |

| | | |

|POSTGO |Таблица-словарь должностей по ГО | |

|POSTGO_ID |ID - уникальный ключ строки в таблице|PK |

|POSTGO_CHAR |Наименование должностей по ГО | |

| | | |

|MATERIALOB |таблица опасных веществ на объектах | |

|MATERIAL_ID |ID - составной уникальный ключ |[pk]|

| |(MATERIAL_ID, OBJECT_ID) | |

| | |FK |

|OBJECT_ID |ID - составной уникальный ключ |[pk]|

| |(MATERIAL_ID, OBJECT_ID) | |

| | |FK |

|MATERIALNUM |количество | |

|NAMEADD_ID |владелиц |FK |

|DATEADD |дата ввода | |

|NAMEINS_ID |корректировщик |FK |

|DATEINS |дата последней коррекции | |

|PRIM |примечание | |

| | | |

|MATERIAL |Таблица-словарь опасных веществ | |

|MATERIAL _ID |ID - уникальный ключ строки в таблице|PK |

|MATERIAL _CHAR |Наименование опасных веществ | |

| | | |

|BUILDINGOB |таблица защитных сооружений на | |

| |объектах; | |

|BUILDING_ID |ID - составной уникальный ключ |[pk]|

| |(BUILDING _ID, OBJECT_ID) | |

| | |FK |

|OBJECT_ID |ID - составной уникальный ключ |[pk]|

| |(BUILDING_ID,OBJECT_ID) | |

| | |FK |

|BUILDINGNUM |количество | |

|NAMEADD_ID |владелиц |FK |

|DATEADD |дата ввода | |

|NAMEINS_ID |корректировщик |FK |

|DATEINS |дата последней коррекции | |

|PRIM |примечание | |

| | | |

|BUILDIN |Таблица-словарь защитных сооружений | |

|BUILDIN _ID |ID - уникальный ключ строки в таблице|PK |

|BUILDIN _CHAR |Наименование опасных веществ | |

| | | |

|TEHNICAOB |таблица техники на объектах; | |

|TEHNICA_ID |ID - составной уникальный ключ |[pk]|

| |(TEHNICA _ID, OBJECT_ID) | |

| | |FK |

|OBJECT_ID |ID - составной уникальный ключ |[pk]|

| |(TEHNICA_ID,OBJECT_ID) | |

| | |FK |

|TEHNICANUM |количество | |

|NAMEADD_ID |владелиц |FK |

|DATEADD |дата ввода | |

|NAMEINS_ID |корректировщик |FK |

|DATEINS |дата последней коррекции | |

|PRIM |примечание | |

| | | |

|TEHNICA |Таблица-словарь техники | |

|TEHNICA _ID |ID - уникальный ключ строки в таблице|PK |

|TEHNICA _CHAR |Наименование опасных веществ | |

| | | |

|FORMIROVOB |таблица формирований на объектах; | |

|FORMIROV_ID |ID - составной уникальный ключ |[pk]|

| |(FORMIROV _ID, OBJECT_ID) | |

| | |FK |

|OBJECT_ID |ID - составной уникальный ключ |[pk]|

| |(FORMIROV_ID,OBJECT_ID) | |

| | |FK |

|READY_ID |готовность |FK |

|PEOPLENUM |количество людей | |

|FORMIROVNUM |количество формирований | |

|NAMEADD_ID |владелиц |FK |

|DATEADD |дата ввода | |

|NAMEINS_ID |корректировщик |FK |

|DATEINS |дата последней коррекции | |

|PRIM |примечание | |

| | | |

|FORMIROV |Таблица-словарь формирований | |

|FORMIROV _ID |ID - уникальный ключ строки в таблице|PK |

|FORMIROV_CHAR |Наименование формирований | |

| | | |

|READY |Таблица-словарь готовности | |

|READY _ID |ID - уникальный ключ строки в таблице|PK |

|READY_CHAR |Наименование готовности | |

| | | |

|MATTEHOB |таблица МТС на объектах | |

|MATTEH_ID |ID - составной уникальный ключ |[pk]|

| |(MATTEH _ID, OBJECT_ID) | |

| | |FK |

|OBJECT_ID |ID - составной уникальный ключ |[pk]|

| |(MATTEH_ID,OBJECT_ID) | |

| | |FK |

|MATTEH NUM |количество | |

|NAMEADD_ID |владелиц |FK |

|DATEADD |дата ввода | |

|NAMEINS_ID |корректировщик |FK |

|DATEINS |дата последней коррекции | |

|PRIM |примечание | |

| | | |

|MATTEH |Таблица-словарь МТС | |

|MATTEH _ID |ID - уникальный ключ строки в таблице|PK |

|MATTEH_CHAR |Наименование МТС | |

|SERVIS_ID |Служба(отдел) |FK |

| | | |

|SERVIS |Таблица-словарь служб | |

|SERVIS _ID |ID - уникальный ключ строки в таблице|PK |

|SERVIS _CHAR |Наименование службы | |

| | | |

|STUDY |таблица обучаемых на УМЦ | |

|STUDY_ID |ID - уникальный ключ строки в таблице|PK |

|OBJECT_ID |объект экономики |FK |

|CATEGORY_ID |категория обучаемого |FK |

|NAME |Ф.И.О. обучаемого | |

|SPOST_ID |занимаемая должность |FK |

|WORKTEL |рабочий телефон | |

|LASTDATE |дата прошлого обучения | |

|NEXTDATE |дата следующего обучения | |

|NAMEADD_ID |владелиц |FK |

|DATEADD |дата ввода | |

|NAMEINS_ID |корректировщик |FK |

|DATEINS |дата последней коррекции | |

|PRIM |примечание | |

| | | |

|SPOST |Таблица-словарь должностей обучаемых | |

|SPOST _ID |ID - уникальный ключ строки в таблице|PK |

|SPOST _CHAR |Наименование должностей обучаемых | |

| | | |

|CATEGORY |Таблица-словарь категорий обучаемых | |

|CATEGORY_ID |ID - уникальный ключ строки в таблице|PK |

|CATEGORY_CHAR |Наименование обучаемых | |

|CATEGORY_TYPE |Тип категории | |

| | | |

|CATTEMA |Таблица категорированых тем | |

|TEMA_ID |ID - составной уникальный ключ |[pk]|

| |(TEMA_ID, CATEGORY_ID) | |

| | |FK |

|CATEGORY_ID |ID - составной уникальный ключ |[pk]|

| |(TEMA_ID, CATEGORY_ID) | |

| | |FK |

|CATTEMANUM |количество часов | |

|PRIM |примечание | |

| | | |

|TEMA |Таблица-словарь тем обучения | |

|TEMA_ID |ID - уникальный ключ строки в таблице|PK |

|TEMA_CHAR |Наименование темы | |

| | | |

|GOBASEUSER |таблица пользователей программы | |

|GOBASEUSER_ID |ID - уникальный ключ строки в таблице|PK |

|NAME |Имя пользователя | |

| | | |

|ORAUSER |таблица соответствия идентификаторов |

| |пользователей программы и базы данных |

| |Oracle |

|ORAUSER_ID |UID - идентификатор базы данных |PK |

| |Oracle | |

|GOBASEUSER_ID |идентификаторов пользователей |FK |

| |программы | |

Первичный ключ(PK) - это поле или поля таблицы, которые используются как

идентификатор элемента. Подобно идентификатору, значение первичного ключа

таблицы всегда уникально для каждой записи. Поля, составляющие первичный

ключ, используются также для построения индекса, предназначенного для

быстрого доступа к ее строкам.

Внешний ключ(FK) — это поле или поля таблицы, которые, не будучи

употребленными в качестве идентификатора, часто используются при

объединении с другими таблицами. В таблице объектов, например, поле номера

района служит в качестве внешнего ключа. Поле номера района не уникально

определяет конкретные записи объектов - для одного района может быть

несколько объектов.

Таблицы 7.2

|OBECONOM |Таблица объектов экономики |

|Столбец |Тип данных |раз|

| | |мер|

| | | | |

| | | | |

|PECULIAR |Таблица-словарь деятельностей в ОП |

| | | | |

| | | | |

|RISK |Таблица-словарь степени опасности объектов |

| | | | |

|PROPERTY |Таблица-словарь форм собственности |

| | | | |

|ACTIVITY |Таблица-словарь рода деятельности объектов |

| | | | |

|POST |Таблица-словарь гражданских должностей |

| | | | |

|POSTGO |Таблица-словарь должностей по ГО |

| | | | |

|MATERIALOB |Таблица опасных веществ на объектах |

| | | | |

|MATERIAL |Таблица-словарь опасных веществ |

| | | | |

|BUILDINGOB |Таблица защитных сооружений на объектах |

| | | | |

|BUILDIN |Таблица-словарь защитных сооружений |

| | | | |

| | | | |

| | | | |

|FORMIROVOB |Таблица формирований на объектах | |

| | | | |

|FORMIROV |Таблица-словарь формирований |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

|SPOST |Таблица-словарь должностей обучаемых |

| | | | |

|CATEGORY |Таблица-словарь категорий обучаемых |

| | | | |

| |тем | | |

| | | | |

| | | | |

|GOBASEUSER |Таблица пользователей программы |

| | | | |

|ORAUSER |Таблица соответствия идентификаторов |

| |пользователей программы и базы данных |

| |Oracle |

NOT NULL - должно иметь значение

[pic] Рисунок 7.2. Диаграмма потоков данных (взаимосвязь таблиц)

7.6. Создание SQL сценария

После того как таблицы созданы и определена их связь необходимо

составить SQL сценарий для создания базы данных.

7.6.1. Создание базы данных

Перед созданием базы данных ее необходимо спроектировать. Этап

проектирования базы данных включает в себя планирование ограничений файлов

и включение файлов а новую базу данных. Этап создания состоит в выполнении

этого плана с помощью команды SQL CREATE DATABASE и некоторых сценариев.

Основные задачи включают в себя следующее:

. Определение соответствующих значений в команде CREATE DATABASE. для

параметров ограничений файлов.

. Планирование размера и расположения файлов начальных данных табличной

области SYSTEM новой базы данных.

. Планирование для новой базы данных размера и расположения групп и членов

журнала транзакций.

. Определение набора символов для хранения информации базы данных.

. Создание файла параметров инициализации и спецификации имен управляющих

файлов базы данных.

Сценарий с файлами инициализации базы данных приведены в ПРИЛОЖЕНИИ 3.

7.6.2. Создание таблиц

Таблицы создаются с помощью оператора SQL CREATE TABLE.

Фрагмент из ПРИЛОЖЕНИЯ 4:

CREATE TABLE ACTIVITY

(

ACTIVITY_ID NUMBER(7) NOT NULL,

ACTIVITY_CHAR VARCHAR2(50) NULL

);

Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

7.6.3. Создание индексов

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

помощью оператора SQL CREATE INDEX. Фрагмент из ПРИЛОЖЕНИЯ 4:

CREATE UNIQUE INDEX IPKACTIVITY ON ACTIVITY

(

ACTIVITY_ID ASC

);

7.6.4. Определение первичных ключей

Добавление определения первичного ключа к существующей таблице:

ALTER TABLE ACTIVITY

ADD ( PRIMARY KEY (ACTIVITY_ID) ) ;

Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

7.6.5. Определение вторичных ключей

Добавление определения вторичного ключа к существующей таблице:

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (ACTIVITY_ID)

REFERENCES ACTIVITY ) ;

Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

7.6.6. Создание триггеров

Триггер - это скомпилированная программа SQL, которая выполняется,

когда в таблице происходит данное событие. С триггером, как правило,

связываются три самых распространенных события: вставка, удаление и

обновление строки.

CREATE TRIGGER IU_STUDY BEFORE INSERT OR UPDATE ON GO.STUDY

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

В частности в данной программе с помощью триггеров выполняется

автоматическая регистрация вводимых данных (кто вел, когда).

7.6.7. Создание последовательностей

С помощью последовательностей генерируются уникальные целые числа.

Последовательные номера используются для автоматической генерации

основных ключей.

CREATE SEQUENCE S_STUDY

Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

7.7.Выбор типа создаваемого приложения

Существует два варианта - системы обработки транзакций и системы

поддержки решений. Как правило, системы поддержки решений используются

управленческим персоналом компаний для обзора некоторой части данных, а

системы обработки транзакций отвечают за ввод и обработку этих данных.

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

данным только в режиме чтения, а системы обработки транзакций должны иметь

возможность как читать, так и записывать данные. Это фундаментальное

различие между двумя типами приложений лежит в основе выбора типа

приложения.

Система GOBASE - это приложение обработки транзакций. Поскольку

пользователи должны иметь возможность добавлять, изменять и удалять данные,

данная система выпадает из разряда приложений поддержки решений. Но, с

другой стороны, некоторая информация, полученная с помощью этого

приложения, по всей видимости, будет использоваться при принятии решений,

т.е. данная система - это в некотором роде гибрид. Однако основное

направление ее как приложение - это обработка транзакций.

7.8. Соглашение о название компонентов в программе GOBASE

Соглашение о название компонентов Таблица 7.3

|AutoObject |ao |QRDBText |qt |

|BatchMove |bm |QRDetailLink |qd |

|Bevel |be |QRGroup |qg |

|BiGauge |bg |QRLabel |ql |

|BiPict |bp |QRMemo |qm |

|Biswitch |bs |QRPreview |qp |

|BitBtn |bb |QRShape |qh |

|Button |bu |QRSysData |qs |

|Calendar |ca |Query |qu |

|ChartFX |ch |QuickReport |qr |

|CheckBox |ck |RadioButton |rb |

|ColorDialog |c_ |RadioGroup |rg |

|ColorGrid |сg |ReplaceDialog |r_ |

|ComboBox |cb |Report |rp |

|Database |db |RichEdit |re |

|DataModule, DBMemo |dm |SaveDialog |s_ |

|DataSource |ds |ScrollBar |sa |

|DBCheckBox |dk |ScrollBox |sx |

|DBComboBox |dc |Session |se |

|DBEdit |de |SpeedButton |sb |

|DBGrid |gr |SpinButton |su |

|DBImage |di |SpinEdit |sd |

|DBListBox |di |StatusBar |st |

|DBLookupComboBox, |lc |FindDialog |n_ |

|DBLookupListBox, |ll |Font Dialog |f_ |

|DBNavigator |na |Form |fm |

|DBRadioGroup |dg |Gauge |ga |

|DBText |te |Graphics Server |gs |

|DdeClientConv |cc |GroupBox |gs |

|DdeCI lent Item |ci |Header |he |

|DdeServerConv |sc |HeaderControi |hc |

|DdeServerItem |si |HotKey |hk |

|DirectoryListBox |dy |IBEventAierter |ie |

|DirectoryOutline |do |Image |im |

|DrawGrid |dr |Image List |il |

|DriveCoitiboBox |rc |Label |la |

|Edit |ed |ListBox |lb |

|FileListBox |fl |ListView |lv |

|FilterComboBox |fc |MainMenu |mm |

|MaskEdit |md |StoredProc |sp |

|MediaPlayer |mp |StringGrid |sg |

|Memo |me |TabbedNotebook |tn |

|Notebook |nb |TabControi |tc |

|OleContainer |ol |Table |ta |

|OpenDialog |od |TabSet |ts |

|OutLine |ou |Thread |th |

|PageControl |pc |Timer |ti |

|PaintBox |pb |TrackBar |tb |

|Panel |pa |TreeView |tv |

|PopupMenu |pu |UpdateSQL |us |

|PrintDialog |p_ |UpDown |ud |

|PrinterSetupDialog |i_ |VCFirstImpressio|vf |

| | |n | |

|ProgressBar |pr |VCFormulaOne |vo |

|QRBand |qb |VCSpeller |vs |

|QRDBCalc |qc | | |

Имена типов в программе начинаются с большой буквы T. Пример:

TBaseForm

В имена констант используются только прописные буквы. Пример: DEFSQL

7.9. Структура главного меню

Структура главного меню определяет характер работы приложения и дает

основные понятия по работе программы.

Главное меню программы состоит из пяти основных пунктов:

«Файлы», «Таблицы», «Отчеты» и «Помощь». (Рис. 7.3.)

[pic]

Рисунок 7.3. Главное меню программы

Главное меню содержит пять кнопок быстрого запуска:

. Объекты экономики (вызов формы ввода объектов экономики);

. Обучаемые на УМЦ (вызов формы ввода обучаеых на УМЦ);

. Отчеты (вызов формы отчетов, дерева отчетов);

. Справка (вызов справки о программе);

В нижней части главного меню располагается информация:

. о текущем пользователе;

. о текущей версии программы.

7.9.1. Меню «Файлы»

Меню файлы состоит из подменю: установка принтера и выход.

Подменю установка принтера предназначена для вызова стандартной формы

выбора принтера (Рис. 7.4.).

[pic]

Рисунок 7.4. Форма установки принтера

Подменю выход вызывает процедуры освобождения памяти занимаемой

программы, закрытие файлов и выход из программы.

7.9.2. Меню «Таблицы»

Меню «Таблицы» предназначена для доступа к любой таблице базы данных.

Данное меню состоит из следующих подменю:

. Объекты экономики (вызов подменю)

. Объекты экономики (вызов формы объектов экономики);

. Районы (вызов формы районов);

. Рода деятельности (вызов формы рода деятельности);

. Форма собственности (вызов формы собственности);

. Деятельность в ОП ( вызов формы по таблице-словарю деятельности в

особый период);

. Ведомства (вызов формы ведомства);

. Степень опасности (вызов формы степени опасности);

. Должность руководителя (вызов формы возможных должностей

руководителей на объекте);

. Должности по ГО (вызов формы возможных должностей руководителей

штабов ГО на объекте);

. Обучаемые на УМЦ (вызов подменю)

. Обучаемые на УМЦ (вызов формы ввода обучаемых на УМЦ);

. Категории обучаемых (вызов категории обучаемых на УМЦ);

. Гражданские должности (вызов формы возможных гражданских

должностей).

. Темы (вызов подменю)

. Категорированные темы (вызов формы категорированных тем обучения на

УМЦ);

. Темы (вызов формы тем обучения);

. Формирования;

. Степени готовности (степени готовности формирований);

. Защитные сооружения;

. Опасные вещества;

. Техника;

. Службы (службы ГО);

. МТС (вызов формы материально-технического обеспечения);

. Пользователи; (вызов формы ввода пользователей программы. Только для

администратора доступен этот пункт).

7.9.3. Меню «Отчеты»

Данное меню вызывает форму дерева отчетов программы.

Более подробно в пункте 7.13.3.

7.9.4. Меню «Помощь»

Данное меню вызывает гипертекст документации пользователя программы.

7.10. Проектирование иерархий форм и отчетов

Наметив, какие формы и отчеты необходимы приложению, можно разработать

отдельную иерархию форм и отчетов, чтобы воспользоваться преимуществами

средств поддержки наследственности визуальных форм Delphi. Другими словами,

необходимо организовать формы и отчеты в общие классы, которые строятся

друг на друге.

Например, следует определить для приложения форму верхнего уровня, из

которой будут происходить все другие формы. Если позже возникнет

необходимость изменять атрибут всех форм приложения, то вносить изменения

придется только в одном месте.

7.11. Иерархия форм программы

В программе используется более 28 форм для работы с таблицами базы

данных и 7 вспомогательных форм для работы с печатью, помощью и отчетами. В

виду такого количества форм необходимо составить иерархию форм (Рис 7.5.)

для облегчения программирования и уменьшения требовательности к ресурсам ОС

и аппаратным ресурсам.

[pic]

Рисунок 7.5. Иерархия форм

Формы сетки 1-4 используются для таблиц-справочников.

7.12. Основные органы управления форм программы GOBase

В каждой форме ввода присутствуют:

1. Навигатор по базе данных, который представляет собой десять кнопок (Рис

7.6) : «Первая строка в таблице», «Предыдущая строка», «Следующая

строка», «Последняя строка в таблице», «Вставка», «Удаление»,

«Редактирование», «Ввод», «Отмена», «Перечитать данные из таблицы»;

2. Кнопка выхода из формы с сохранением данных (OK);

3. Кнопка выхода из формы без сохранения данных (Cancel);

4. Кнопка минимизации окна;

5. Кнопка максимизации окна;

6. Кнопка закрытия окна (аналогична Cancel);

7. Выпадающий список (список строк другой таблицы)

8. Кнопка с темя точками - вызов формы редактирования таблицы, которая

подключена к выпадающему списку.

[pic]

Рисунок 7.6. Форма ввода формирований на текущем объекте

Любая форма ввода данных в основные таблицы содержит дополнительную

информацию о пользователе, который ввел и редактировал данную запись в

текущей таблице.

Благодаря иерархической структуре программы в каждой форме ввода

присутствуют одинаковые элементы вывода информации, что позволяет обычному

пользователю понять принцип работы программы за считанные минуты.

7.13. Основные формы программы

Ввиду большего количества форм в программе в данном разделе будут

приведены только основные формы программы, которые позволят понять логику

ее работы.

7.13.1. Форма ввода объектов экономики

Форма ввода объектов экономики (Рис 7.7) позволяет производить

вставку, редактирование и удаление информации по текущему объекту.

Комбинированные списки позволяют просматривать и вставлять значения из

таблиц-словарей. Кнопки с тремя точками вызывают соответствующие формы

редактирования таблиц-словарей.

Кнопки: «Формирования», «Защитные сооружения» и т.д, находящиеся в нижней

части меню позволяют вывести дополнительную информацию по текущему объекту.

Контрольный элемент «Головной объект» позволяет (в отключенном

состоянии) выбрать головной объект из выпадающего списка головных объектов.

[pic]

Рисунок 7.7. Форма ввода объектов экономики

В качестве примера дополнительной информации по объекту (на рис 7.6

смотри выше) показана форма ввода формирований на текущем объекте.

Аналогично построена форма ввода защитных сооружений, техники, химических

веществ.

Кнопка «Материалы» выводит форму по выбору интересующей службы, далее

после выбора службы вызывается форма ввода материально-технических средств

данной службы на данном объекте (Рис 7.8).

[pic]

Рисунок 7.8. Материально-технические средства на объекте

Кнопка «Обучаемые» выводит форму о обучаемых в УМЦ на текущем объекте.

7.13.2. Форма ввода учащихся в УМЦ

Данная форма ведет таблицу обучаемых на УМЦ (Рис 7.9). Поля «прошлая

дата обучения» и «следующая дата обучения» связаны интервалом в три года,

т.е. если поле «следующая дата» пустое, а в поле «прошлая дата обучения»

вводится новое число, то происходит автоматическая корректировка поля

«следующая дата».

Для удобства ввода даты создана форма «Выбор даты» (Рис7.10). Правые

верхние кнопки отвечают за выбор месяца, а левые верхние кнопки отвечают за

выбор года.

[pic]

Рисунок 7.9. Обучаемые на УМЦ

В форме выбора категории обучаемых существует возможность ввода тем

обучения для данной категории с указанием времени обучения. Категории

обучаемых подразделяются на две группы: командиры формирований и другие,

соответственно в главной форме по вводу обучаемых есть флажок «признак

категории».

[pic]

Рисунок 7.10 Выбор даты

7.13.3. Форма отчетов (управления)

Одна из самых главных форм - эта форма отчетов, которая позволяет

выбрать любые данные, практически по любым критериям, из базы данных. (Рис

7.11).

[pic]

Рисунок 7.11. Форма отчетов программы

Данная форма состоит из двух основных элементов: дерева отчетов и

сетки вывода запроса. Для удобства поиска данных предусмотрен выпадающий

список «Поле» который ограничивает запрос выбранным параметром. Так же

предусмотрена сортировка по любым полям таблицы. Данные два поля позволяют

создавать с помощью одного запроса комбинацию запросов по выбранным

критериям.

В виду того, что не всегда можно предугадать нужные запросы

пользователя в форме «отчеты» можно вызвать редактор SQL запроса, который

позволяет ввести любой запрос в буфер SQL (в буфер можно ввести файл c

готовым SQL , так же набранный SQL из буфера можно сохранить в файл) .

Алгоритм работы с формой отчетов представлен соответствующих четырех

плакатах.

В случае если SQL запрос содержит выборку в каком-либо временном

промежутке, то автоматически подключаются второстепенные органы управления

по работе с датами (Рис 7.12)

[pic]

Рисунок 7.12. Форма отчетов программы (работа с запросами содержащими

даты).

Одна из особенностей этой формы: если запрос связан с объектами, то

двойной щелчок по сетке приводи полную информацию о текущем объекте. Такая

же особенность и с обучающимся на УМЦ.

Кнопка «Excel» позволяет вызвать форму экспорта данных в Excel. На

рисунке 7.13. показан экспорт данных в Excel.

7.14. Экспорт в Excel

Существует множество способов и программ, которые позволяют создавать

отчетные документы. Но, как правило, отчеты полученные стандартными

способами или специальными программами не позволяют гибко менять структуру

отчета , а тем более редактировать его. При решении проблемы с отчетными

документами был выбран стандартный табличный - процессор Excel, как

наиболее гибкая программа для работы с отчетными документами. Excel не

имеет никаких стандартных функций для взаимодействия Delphi-приложениями.

Единственная возможность к доступу ячейкам Excel и к его командам это

использование DDE Windows.

[pic]

Рисунок 7.13 Экспорт отчета в Excel

Динамический обмен данными (DDE) обеспечивает коммуникационную основу

для программ Windows, которая позволяет открыть диалог между приложениями

клиента и сервера. Диалог DDE - это связь между взаимодействующими

программами, которая инициируется, а затем закрывается. Для того чтобы DDE-

диалог мог происходить, обе программы должны быть запущены.

Программа, которая инициирует диалог и получает содействие другой

программы, называется клиентом. Программа, которая обеспечивает содействие

клиенту, называется сервером.

DDE-взаимодействие имеет темы (Topics), или категории, которые

полностью зависят от приложения. Наиболее распространенный пример темы это

имя файла. Другие темы могут включать понятие system, которое используют

приложения Microsoft, когда нужно запросить через DDE информацию

относительно того, какие форматы Clipbord поддерживаются. В данном случае

Topic используется для доступа к листу Excel.

Данные, которые во время диалога перемещаются туда и обратно,

называются элементом (item). В данном случае элемент является спецификация

рядов/колонок диапазона листа Excel.

Примечание: Из руководства по пользованию DDE: К сожалению, нет

никакой систематической возможности найти, какие темы поддерживает

приложение. Ваше приложение должно знать заранее, какие темы поддерживает

приложение-сервер.

Исходя из прочитанной литературы в электронных сетях были установлены

основные команды по работе с Excel:

FORMAT(«строка», «rc») - вывод строки в ячейку.

READY – готовность Excel. А так же благодаря исследовательским работам

в этом направлении удалось вывести алгоритм поиска Excel. (поиск происходит

по реестру Windows).

Алгоритм вывода данных в Excel представлен на плакатах 1-2

7.15. Требования к аппаратуре и программным средствам

1. IBM PC XT/AT совместимый компьютер;

2. Windows 95 или Windows NT любой версии;

3. 5000Kb свободного пространства на диске;

4. Не менее 8 Mb оперативной памяти

5. При использовании отчетов необходим Microsoft Excel

6. База данных Oracle v7.2 или выше

7.16. Установка программы

Программа установки находится на первой установочной дискете (всего

три диска формата 1.44). Запустите с установочной дискеты программу

SETUP.EXE и укажите тип установки (Полная, выборочная или минимальная);

укажите путь для установки программы, далее программа установки

автоматически установит программу.

Для корректной работы программы должна быть установлена ЛВС со

стандартным IPX или IP протоколом и с сервер базы данных Oracle не ниже 7.2

версии.

8. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКИЙ РАЗДЕЛ

8.1. Введение

Для наиболее эффективной работы штаба по делам ГО и ЧС

необходимо иметь программу (базу данных), содержащую информацию об

объектах экономики округа или города, для возможности оперативного

реагирования в случаи возникающих чрезвычайных ситуаций.

Для оценки возможной чрезвычайной ситуации офицеры управления и

другие ответственные лица должны постоянно иметь свежую и

достоверную информацию об объекте, на котором может произойти ЧС.

Возникает необходимость организации управления и создания базы

данных таким образом, чтобы обеспечить быстроту и

надежность получения различных данных для наиболее четко слаженной

работы штаба.

Предъявляемые современными условиями требования к системам

управления могут быть удовлетворены лишь при помощи

современных средств автоматизации управления. Опыт показывает,

что в наше время для решения этих задач не обойтись

без помощи компьютерной техники, позволяющей в наиболее

удобной форме хранить и представлять пользователям интересующую

их служебную информацию.

Для наиболее слаженной работы различных служб штаба

данные удобно держать централизованно на главном компьютере и иметь к

ним доступ с других компьютеров (через сеть) с помощью программы по

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

осуществлять связь между различными пользователями этой сети,

находящимися на некотором расстоянии друг от друга (обычно,

в разных помещениях одного здания). Однако такие базы данных

требуют для своей работы соответствующего программного

обеспечения, которое могло бы позволять вводить, выводить, искать, а так

же производить обработку этих данных. Кроме того, к такому

программному обеспечению предъявляются такие требования как

удобство доступа к необходимой информации, простота в

обращении и защита от несанкционированного доступа к

конфиденциальной информации, а также, защита от порчи

различного рода программными вирусами.

Настоящая работа как раз и представляет собой подобное

программное обеспечение по управлению работой базы данных и

отвечает основным требованиям, предъявляемым к такого рода

программным продуктам.

Исходя из вышесказанного, предлагается создать данную программу и

перевести все данные на компьютер.

8.2. Описание программы

Данное программное средство выполняет функции в интересах системы

оповещения при ЧС.

Данная программа обеспечивает:

1). автоматизацию процесса подготовки к принятию решений при возникших

ЧС;

2). регистрацию объектов экономики и составление списка характеристик

объекта;

3). снижение расходов на подготовку и уточнения списков объектов;

4). учета готовности объекта к ЧС;

5). учета проведения занятий с обучающимися в УМЦ округа.

6). уменьшение времени на подготовку списков объектов экономики и

списков, обучающихся на УМЦ;

7). контроль однократности учета объектов и обучающихся;

В состав программы входит:

1). задача первоначального ввода информации об объектах экономики;

2). задача первоначального ввода информации об обучаемых на УМЦ;

3). задача формирования и печати списков объектов экономики;

4). задача формирования и печати списков, обучаемых на УМЦ;

8.3. Последовательность выполнения работ

Для планирования разработки применим сетевой метод, для чего составим

перечень событий и работ с учетом нормативных документов НИР. Перечень

событий и работ приводится в таблице (8.1). Результаты расчета параметров

сетевого графика сведены в таблицу (8.2). Сетевой график показан на (рис.

8.1).

По вышеизложенной методике проведено планирование разработки. Задача,

решаемая в дипломном проекте, поставленная перед научной группой из трех

человек, должна быть выполнена в течение 2 месяцев (44 дня). Путь, имеющий

максимальную продолжительность, равную 42 дням, является критическим. Это

путь:

0-1-2-3-4-8-9-10-13-14-15-17-18-19-21-22-23.

Для правильного выполнения сетевого графика должно выполняться

следующее условие : вероятность совершения события в заданный срок Р

(Ткр L = Л * ( H-h ) = 1,7 * ( 3,9 - 0,9 ) = 5,1 м.

Расстояние от стен до крайнего ряда светильников :

l = 1/3 * L = 1/3 * 5,1 = 1,7 ;

Будем располагать светильники параллельно ширине помещения. При длине

помещения B = 7 м. число рядов светильников n рассчитывается по формуле :

B - 2 * l 8 - 2 * 1,7

n = 1 + ------------- = 1 + --------------- = 2 ;

L 5,1

Нормировочная освещенность для данного вида работ

E = 400 лк

Для определения величины коэффициента используемого светового потока

подсчитывается индекс помещения:

A * B

i = ------------------

(H - h) * (A + B)

где i - индекс помещения;

A и B - длина и ширина помещения, м;

(H - h) - расчетная высота подвеса светильников над

рабочей поверхностью, м.

Для нашего помещения А = 7 м, В = 8 м, Н = 3.9 м.

7 * 8

i = ----------------------- = 1,24 ;

(3,9 - 0,9) * (7 + 8)

Коэффициент использования светового потока зависит кроме

индекса помещения еще и от коэффициентов отражения:

Rп - коэффициент отражения потолка (0.7);

Rс - коэффициент отражения стен (0.5);

По таблице определяем коэффициент использования светового

потока :Ku = 0.4 ;

Номинальный световой поток лампы ЛБ-40 составляет

Фл = 3120 лк .

Номинальный световой поток светильника , включающего 4 лампы

,составляет Фсв = 4 * Фл = 4 * 3120 = 12480 ;

Необходимое количество светильников подсчитывается по следующей

формуле :

E * Kз * S * z

N = ------------------ ,

n * Фсв * Ku * Kзт

где E - нормировочная освещенность, лк;

Кз - коэффициент запаса ;

S - площадь помещения ;

z - коэффициент неравномерности освещения ;

n - число рядов светильников ;

Фсв - номинальный световой поток светильника ;

Ku - коэффициент использования светового потока ;

Kзт - коэффициент затенения ;

По справочнику значение коэффициентов принимаем равными

соответственно :

Кз = 1,5 ;

z = 1,15 ;

Кзт = 0,85 .

Площадь помещения S = A * B = 7 * 8 = 56 м. ;

400 * 1,5 * 56 * 1,15

N = ------------------------- = 4 ;

2 * 12480 * 0,4 * 0,85

Определим длину разрывов между светильниками R :

A - N * lсв

R = ------------- ,

N - 1

где lсв - длина одного светильника ;

lсв = 1,33 м.

6 - 4 * 1,33

R = -------------- = 0,23 м.

4 - 1

9.6. Вывод

В данной части дипломного проекта проведен анализ категории тяжести

труда программиста; рассмотрены оптимальные условия труда инженера-

системотехника, факторы, действующие на него в процессе работы.

Рассмотрены параметры освещенности рабочего места. Таким образом, для

организации рабочего места инженера-программиста с категорией тяжести труда

2 необходим отдых

в перерывы и после работы, рационализация режима труда и отдыха.

10. ПРИМЕНЕНИЕ ЭВМ ДЛЯ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ РАБОТЫ ШТАБА ГО

Для того чтобы оценить возможные пути и способы применения

электронных вычислительных машин (далее ЭВМ) для повышения эффективности

работы штаба ГО, необходимо иметь четкое представление, во-первых, об

объеме и содержании решаемых задач, требованиях оперативности и способах

коммуникаций, и, во-вторых, о возможностях современных ЭВМ.

Что касается возможностей современных ЭВМ (причем речь идет не об

отдельно стоящей машине, а о компьютере с возможностью как автономной

работы, так и доступа к удаленным ресурсам), современный уровень технологии

позволяет обеспечить практически любой уровень производительности и

отказоустойчивости системы, который может потребоваться в рамках решаемой

задачи, будь то примитивный документооборот или управление ограниченными

ресурсами в боевых условиях в реальном времени при отсутствии источников

энергии. В данном случае требования к производительности определяются двумя

факторами: масштабом задач и ограниченностью ресурсов для их решения. Итак,

определим задачи ГО вообще.

10.1. Задачи гражданской обороны.

Гражданская оборона - составная часть системы общегосударственных

оборонных мероприятий, проводимых в мирное и военное время в целях защиты

населения и народного хозяйства от оружия массового поражения и других

современных средств нападения противника, а также для СИДНР в очагах

поражения и зонах катастрофического затопления.

1. Защита населения от оружия массового поражения и других средств

нападения противника осуществляется проведением комплекса защитных

мероприятий, что позволяет максимально ослабить результаты воздействия

оружия массового поражения, создать благоприятные условия для проживания и

деятельности населения, работы объектов, и действий сил ГО при выполнении

стоящих перед ними задач.

2. Повышение устойчивости работы объектов и отраслей экономики в

условиях военного времени может быть достигнуто заблаговременным

проведением организационных, инженерно-технических и других мероприятий,

направленных на максимальное снижение результатов воздействия оружия

массового поражения, создание благоприятных условий для быстрой ликвидации

последствий нападения противника.

3. Проведение спасательных аварийно-восстановительных работ в

очагах поражения и зонах затопления. Без успешного проведения таких работ

невозможно наладить деятельность объектов, подвергшихся ударам противника,

создать нормальные условия для жизнедеятельности населения пострадавших

городов.

10.2. Основной расчет поражающих факторов ядерного взрыва

Данная программа, написанная на языке высокого уровня Pascal,

позволяет рассчитать основные параметры поражающих факторов ядерного

взрыва. Данные параметры необходимы при анализе и повышении устойчивости

объектов производства, при планировании и организации спасательных и других

неотложных работ.

10.2.1. Исходные данные:

1. Вид взрыва: а) воздушный, б) наземный;

2. Мощность взрыва;

3. Расстояние до ОЭ;

4. Раcстояние до района рассредоточения;

5. Коэффицент ослабления атмосферы;

6. Скорость ветра;

7. Угол между осью следа радиоактивного облака и линией, проведенной через

ОЭ и эпицентр взрыа;

10.2.2. Выходные данные:

1. Избыточное давление во фронте ударной волны;

2. Импульс светового излучения;

3. Суммарная доза гамма-излучения;

4. Мощность дозы Г-излучения;

5. Поток нейтронов;

6. Вертикальная составляющая эл.поля ЭМИ;

7. Уровень радиации радиоактивного заражения;

10.3. Текст программы

program voina;

var

Pvzr,vid,rr,vv,bet:real;

R_onx,ko,dPf,qy,R,rs,U,Fn,Pg,Dz,Dosk,Dg,E,P0,alf:real;

begin

writeln('Введите вид взрыва,если взрыв воздушный -> нажми 1');

writeln(' если взрыв наземный -> нажми 2');

read(vid);

writeln('Введите мощность взрыва,Kт');

read(Pvzr);

writeln('Введите расстояние до ОЭ,км');

read(R_onx);

writeln('Введите раcстояние до района рассредоточения,км');

read(rr);

writeln('Введите коэфицент ослабления');

read(ko);

writeln('Введите скорость ветра,км/ч');

read(vv);

writeln('Введите угол,град');

read(bet);

qy:=0.5*Pvzr*1000000;

R:=R_onx*1000;

dPf:=105/R*exp(1/3*ln(qy))+410/R/R*exp(2/3*ln(qy))+1370/r/r/r*qy;

if vid=1 then

rs:=0.052*exp(0.4*ln(Pvzr))

else

rs:=0.068*exp(0.4*ln(Pvzr));

R:=R_onx;

U:=111*Pvzr/R/R*exp(-ko*(R-rs));

R:=R*1000;

Fn:=7.5*exp(22*ln(10))/R/R*Pvzr*exp(-R/190);

Pg:=exp(13*ln(10))/R/R*Pvzr*exp(-R/200);

Dz:=5*exp(8*ln(10))/R/R*Pvzr*exp(-R/410);

Dosk:=1.4*exp(9*ln(10))*Pvzr*(1+0.2*exp(0.65*ln(Pvzr)))/R/R*exp(-R/300);

Dg:=Dz+Dosk;

R:=R_onx;

alf:=Pi/4-2*bet*Pi/180;

E:=5*exp(3*ln(10))*(1+2*R)/R/R/R*ln(14.5*Pvzr)/ln(10);

P0:=10*Pvzr/(exp(1.5*ln(rr/22))*exp(sqrt(rr/vv)))*sqr(sqr(sin(alf)/cos(alf)

));

writeln('Избыточное давление во фронте ударной волны: ',dPf:1:3,' кПа');

writeln('Импульс светового излучения: ',U:1:3,' кДж/м¤');

writeln('Суммарная доза гамма-излучения: ',Dg:1:3);

writeln('Мощность дозы Г-излучения: ',Pg:1:3);

writeln('Поток нейтронов: ',Fn:3,' н/м¤');

if vid=2 then

writeln('Вертикальная составляющая эл.поля ЭМИ: ',E:1:3,' В/м');

writeln('Уровень радиации радиоактивного заражения: ',P0:1:3);

writeln('');

end.

10.4. Проврка работоспособности

Избыточное давление во фронте

ударной волны Pф,кПа

|R/q |100 |200 |300 |400 |500 |

|3 |21.614|31.134|39.068|46.196|52.813|

|4 |14.219|19.846|24.393|28.396|32.057|

|5 |10.51 |14.377|17.432|20.082|22.478|

|6 |8.31 |11.211|13.465|15.398|17.13 |

|7 |6.861 |9.164 |10.931|12.432|13.769|

|8 |5.839 |7.740 |9.184 |10.402|11.479|

|9 |5.079 |6.694 |7.91 |8.93 |9.828 |

|10 |4.493 |5.894 |6.942 |7.817 |8.584 |

где R - расстояние до центра взрыва, км;

q - мощность взрыва, кт.

10.5. Выводы:

Итак, используя эту программу можно уменьшить время расчета основных

показателей поражающих факторов ядерного взрыва. Сделать оперативно

необходимые выводы о защите объектов экономики и радиоэлектронной

аппаратуры.

11. ЭРГОНОМИЧЕСКАЯ ОЦЕНКА ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ ЭВМ

11.1. Введение

С развитием новых программ возникла необходимость привести в

соответствие их интерфейс с особенностью восприятия информации человеком.

Необходимость решения таких эргономических проблем была обусловлена

как возрастающими требованиями, предъявляемыми к эргономическому

совершенствованию программных изделий, так и возрастающим дефицитом рабочей

силы. Поэтому необходимо как можно лучше использовать человеческие

способности в процессе производства, постоянно повышать его культуру и

улучшать условия труда человека.

Соблюдение эргономических законов с самого начала разработки любого

программного изделия гарантирует повышение культуры производства, удобство

и эффективность человеческого труда, повышение потребительской ценности

промышленной продукции, оно создает уверенность в том, что система человек-

машина будет действовать эффективно, надежно и безопасно.

11.2. Проектирование форм

1. Выбор стиля. Стиль определяет внешний вид приложения и сказывается на

внешнем виде форм, его составляющих. Лучше придерживаться уже

установленного стиля пользовательских интерфейсов, потому что

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

цвета фона, размеры элементов изображений, расположение панели

инструментов должны быть согласованы с другими приложениями.

2. Выбор функций, вводимых в приложение. Не надо вводить ненужные свойства.

Перегрузка пользователя бесполезной информацией вызовет напрасные потери

времени. Надо определить какие свойства полезны, а какие нет.

3. Построение иерархии для форм и отчетов. Создание для приложения формы

верхнего уровня, из которой будут происходить все другие формы, облегчит

внесение изменений аспектов всех форм приложения, так как изменения

придется вносить только в верхнюю форму. Иерархия форм поможет

придерживаться последовательности при переходе от формы к форме.

4. Форма не должна включать более одного типа исходного документа

одновременно. Формы должны составляться как можно проще. Не следует

вводить на экран разные типы информации в одной форме.

5. Для лучшего восприятия человеческим глазом информации надо использовать

для форм нейтральный цвет фона.

6. Для отображения текущего режима работы приложения можно использовать

группы кнопок панели инструментов. Установив свойство набора кнопок

панели GroupIndex равное ненулевому числу, можно установить групповой

режим работы панели. Можно также установить свойство группы AllowAllUp

равное False. Если щелкнуть на одной из кнопок панели инструментов,

определенных таким образом, она будет оставаться в нажатом состоянии до

тех пор, пока пользователь не щелкнет на другой кнопке из этой группы.

7. Большие кнопки и легко отыскиваемые группы переключателей позволяют

легко манипулировать управляющими средствами приложения.

8. Для большой экономии времени пользователей, которые предпочитают

использовать клавиатуру, а не мышь, можно продублировать функции каждой

кнопки панели инструментов командами соответствующих меню и включить в

него также команды, которые не представлены кнопками формы.

9. Для часто используемых команд меню надо включить акселераторы меню. Для

этого нужно создать фиктивный элемент меню с соответствующей комбинацией

клавиш, а затем «привязать» код, который надо выполнить, к событию

OnClick этого элемента.

10. Установка на форме горячие клавиши для ключевых полей. Для этого

сначала определяют горячую клавишу метки с помощью свойства Caption

управляющего элемента метки (для обозначения горячей клавиши используют

символ «&»). Затем устанавливают в свойстве метки FocusControl имя

компонента, который предназначен для получения фокуса ввода при нажатии

горячей клавиши.

11. Расположение и функции устройств навигации должны быть одинаковыми для

всех форм и даже приложений. Если поместить управляющий элемент

DBNavigator внизу одной формы и вверху следующей, то тем самым будет

нарушена согласованность внутри приложения и пользователи могут

запутаться. Лучше размещать средства управления, которые выполняют

аналогичные или похожие функции, в одном и том же месте каждой формы.

12. Элементы пользовательского интерфейса должны быть как можно более

ненавязчивыми. Пользователь не должен останавливать свою работу и

напрягать зрение, пытаясь прочесть метку на кнопке. Лучше сделать

отдельные кнопки размером больше.

13. Шрифты без засечек читаются легче, чем шрифты с засечками. Поэтому

лучше использовать шрифт Arial, вместо Times New Roman.

14. Использование всплывающих подсказок предоставляет пользователю

великолепную возможность узнать, что делает данный элемент, не щелкая на

нем (это особенно важно для кнопок панели управления.). Всплывающие

подсказки представляют собой маленькие всплывающие метки, которые

отображаются, когда курсор мыши останавливается над определенными

значащими элементами экрана.

15. Включение интерактивной справки. Профессиональные приложения Windows

содержат полную справочную базу данных, которая включает связи между

родственными темами. Следует оснащать свои формы контекстно-

чувствительной справкой. Это можно сделать с помощью свойства HelpContext

формы и ее управляющих элементов. Когда будет затребована справка по

элементу формы, обладающему фокусом ввода, управление справкой Windows

автоматически будет передано соответствующей теме вашей справочной базы

данных.

16. Создание окна формы About (О программе). В него включают имя

приложения, номер текущей версии и название компании. Можно также внести

туда телефонный номер отдела технического сопровождения, отметку об

авторских правах и информацию об использовании ресурсов Windows. Название

продукта, номер версии и отметка об авторских правах должны быть включены

в приложение с помощью ресурса Windows VERSIONINFO.

17. Можно использовать страницы и вкладки для размещения большого числа

управляющих элементов на относительно маленькой площади экрана.

18. Для представления приложения в соответствующем меню или папке Windows

надо связать его с подходящей пиктограммой (важно, чтобы пользователи

могли отличить ее от пиктограмм других приложений). Для приложений Dephi

пиктограммы устанавливаются с помощью меню Project ( Options (

Applications.

19. Надо проектировать формы для самого низкого разрешения экрана. Скорее

всего, это будет разрешение VGA, поэтому в формах можно безопасно

установить разрешение 640*480. Для реализации этого лучше всего

переключить разрешение на видеоадаптере на VGA. Формы, разработанные в

расчете на большую разрешающую способность, чем стандарт VGA, не смогут

целиком появиться на экране.

20. Не надо перекладывать на оперативную справку объяснение, как

пользоваться приложением. В большинстве случаев его применение должно

быть интуитивным и не должно вынуждать пользователя закапываться в

руководство или читать оперативную справку.

11.3. Формы выдачи решений

Формы выдачи решений обычно используются людьми, которые не являются самыми

осведомленными в компьютерной области, но, как правило, обладают большим

влиянием, чем другие типы пользователей. Именно им нужны приложения

принятия решений, поскольку они играют определенную роль в процессе

выработки решений. Основная задача форм выдачи решений состоит в том, чтобы

они оставались простыми и достаточно информативными.

1. Максимальное использование экранной площади. Как правило, пользователи

предпочитают видеть вещи в максимально упрощенном и развернутом виде.

Можно также допустить, что пользователи редко запускают под управлением

Windows более одного приложения одновременно, поэтому позволительна

максимизация практически всех окон форм.

2. Надо избегать беспорядочного расположения на форме большого числа

деталей или табулированных данных. Обычно пользователя интересуют только

факты, и они хотят получить их в приятном и простом для понимания виде.

3. Использование графических диаграмм для визуального отображения

соответствия одних данных другим может стать мощным средством общения

сложных наборов данных. Если пользователь не прочь отказаться от сырых

цифр в пользу их графического представления, то диаграммы придадут

приложению изысканный и профессиональный вид при минимуме затраченных

усилий. Но при этом необходимо по-прежнему поддерживать средства доступа

к лежащим в их основе необработанным данным на случай, если пользователь

захочет знать из диаграмм точные цифры.

4. Если приложение ограничивается только чтением данных можно удалить

компоненты модификации данных. Можно обойтись компонентами DBText или

TLabel, чтобы отображать поля описательного типа, не прибегая к таким

насыщенным компонентам, как список или комбинированный список.

5. Не следует включать в приложение функций, которыми пользователь не

сможет воспользоваться. Необходимо избегать серых (недоступных) команд

меню и запрещенных кнопок, присутствие которых может вызвать недоумение.

Если какая-нибудь опция недоступна для данного пользователя,

устанавливают ее свойство Visible равным False, что сделает ее невидимой

(или совсем убрать ее) вместо того, чтобы просто запретить.

11.4. Интерактивные формы.

Интерактивные формы чаще всего встречаются в приложениях. Они

предоставляют средства ввода, редактирования и удаления данных. Типичный

пользователь таких форм, как правило, обладает высокой компьютерной

грамотностью. Интерактивная форма должна быть максимально простой и

благоприятной для эффективной навигации между данными и манипулирования

ими.

1. Желательно рассмотреть возможность увеличения и замены кнопок навигатора

Dilphi стандартными кнопками. Несмотря на мощность и простоту применения,

управляющим элементам DBNavigator недостает таких свойств, как средства

поиска и возможность присваивать клавиши ускоренного доступа или метки их

встроенным кнопкам.

2. Чтобы выбор управляющих средств был логичен и происходил интуитивно,

группируют управляющие средства по каждому применению и соответственно

размещают их. Располагают связанные элементы в тесной близости друг к

другу, выравнивают зависимые элементы группы переключателей, располагают

связанные кнопки близко друг от друга. Это помогает пользователю быстрее

познакомиться с приложением и избежать ошибок при работе с ним.

3. Для любителей работы с клавиатурой, используют комбинации клавиш для

командных кнопок и полей ввода. Надо расположить комбинации клавиши в

логическом, а не позиционном порядке, отдавая предпочтение кнопкам, а не

меткам. Другими словами, если есть поле вверху экрана, метка которого

начинается с буквы А, и, кроме того, есть кнопка, расположенная внизу

экрана с названием Add, устанавливают клавишу ускоренного доступа для

кнопки, а не для поля, равной .

4. Устанавливают логический порядок работы клавиши табуляции, который бы

позволил пользователю логически переходить на форме от поля к полю и от

кнопки к кнопке, а именно слева направо и сверху вниз.

5. Чтобы установить кнопки OK или Cancel используют свойство Kind

управляющего элемента Delphi TBitBtn (кнопка с растровым изображением).

Установка кнопки OK автоматически устанавливает ее свойство Default

равным True, делая тем самым ее кнопкой, которая действует для данной

формы по умолчанию. Это значит, что для завершения редактирования текущей

записи пользователь может нажать , а для отмены ввода- .

6. Для активизации всплывающего меню вместо командных кнопок или как

дополнение к ним рассматривают использование правого щелчка мыши.

Некоторые пользователи отдают предпочтение именно этому виду меню,

которое приобрело популярность благодаря продуктам Borland.

11.5.Формы ввода данных.

Формы ввода данных используются для интенсивного ввода данных, в

основном, в базы данных. Внимание здесь больше уделяется скорости, а не

эстетике экрана или таким деталям, как всплывающие подсказки или

раскрывающиеся списки. Формы ввода данных обычно в достаточной степени

лаконичны и включают только самые необходимые элементы. Как правило,

пользователями таких форм являются операторы ввода данных, которые во время

работы смотрят в основном на исходные документы, а не на экран. Особое

внимание уделяется здесь клавиатуре, поскольку использование мыши требует

визуального взаимодействия.

1. Когда скорость ввода является решающим фактором, используют полужирный

моноширинный шрифт, который легче читается с одного взгляда.

2. Убирают ненужные кнопки и поля, а также управляющие элементы, которые

оказываются лишними для быстрого ввода данных. Например, если

пользователю никогда не понадобится номер счета, надо убрать с формы

соответствующую кнопку - она только занимает экранную площадь. Если в

формах обработки транзакций некоторые элементы создают удобства, то

быстрому вводу данных они могут просто мешать.

3. Используют акселераторы, которые легко нажимать. Назначают клавиши

ускоренного доступа с учетом их применения, а не в зависимости от позиции

на экране. Если два управляющих элемента должны по идее иметь одну и ту

же горячую клавишу, отдают ее тому, который используется чаще, а не тому,

который позиционно расположен на форме первым. Для другого элемента

придумывают новый акселератор. Для самых часто используемых элементов

отводят самые простые клавиши.

4. Там, где это уместно, делают действующей по умолчанию не кнопку OK, а

кнопку Add, которая добавляет новую запись. Это относится к формам, в

которых главной функцией является добавление записей, в отличие от

обычных форм обработки транзакций. Это будет способствовать более быстрой

работе с приложением, когда пользователю приходится добавлять несколько

записей подряд.

5. Не делают больших форм. В отличие от других тип форм, эта форма должна

быть как можно меньше, поскольку это позволит переместить ее в удобное

для пользователя место и снизить утомляемость глаз. Пользователи этого

типа обычно смотрят на исходные документы, а не на экран, поэтому

открывают эту форму в нормальном окне (а не в максимизированном или

минимизированном).

11.6. Проектирование отчетов.

1. Используют для проектирования отчетов компоненты QuickReport. Их легче

настраивать и использовать, чем внешние построители отчетов.

2. Для отчетов, которые слишком сложны для компонентов QuickReport,

используют графические построители отчетов. Особой популярностью

пользуются утилиты ReportSmith, R&R SQL Report Writer for Windows и

Crystal Reports. Применение графического построителя отчетов имеет много

преимуществ. Во-первых, отчеты создаются и модифицируются визуально, Это

легче, быстрее и рождает меньше ошибок, чем создание отчетов с помощью

исходного кода Object Pascal. Во-вторых, такие механизмы, как управление

разбивкой, заголовки, сноски и суммирование, встроены во все приличные

построители отчетов - для их использования не нужно писать программный

код. В-третьих, можно позволить пользователям модифицировать отчеты или

на их основе создать новые, причем без необходимости модифицировать

исходный код приложения.

3. В заголовок отчетов включают имя отчета, текущие дату и время, а также

имя пользователя, запускающего отчет. Включение даты и времени поможет

отличить друг от друга несколько версий одного и того же отчета и даст

представление о времени ее создания, если его просматривали в более

поздний срок. Включение внутреннего имени отчета поможет отследить

«источник» для отчета, который может пригодиться для работы в дальнейшем.

Имя пользователя, если оно записано в заголовке отчета, может

способствовать развитию контакта с пользователем для обсуждения будущих

проблем.

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

отчете в его страничном заголовке. Если в интерфейсном приложении

пользователь поддерживал даты или другой критерий, надо внести их в

заголовок страниц отчета. Это необходимо сделать, потому что данные могут

быть выпущены из отчета из-за того, что критерий был задан в интерфейсе.

Это может запутать пользователя. Вероятность такого события особенно

повышается, когда между моментом запуска отчета и моментом его просмотра

прошло значительное время.

5. Для заголовков используют пропорциональные шрифты, а для данных -

моноширинные. Пропорциональные шрифты придают отчету более изысканный вид

и в полной мере используют преимущества высокоорганизованных принтеров,

которые получили широкое распространение в наши дни. Более того,

пропорциональные шрифты отличают отчеты, сгенерированные современными

системами PC, от созданных на более старых и менее развитых системах. К

сожалению, пропорциональные шрифты обладают недостатком, который

выражается в трудностях выравнивания табличных данных. Поскольку цифра 1

оказывается уже цифры 5, то колонки данных не будут идеально

выровненными. Вместо этого используются шрифты с фиксированным шагом.

Обычно в заголовках отчета используется такой пропорциональный шрифт, как

Arial или Times New Roman, а в самом отчете - такой непропорциональный

шрифт, как Courier New.

6. Если в отчете необходимо подчеркивание, надо использовать атрибут

подчеркивания шрифта. Во многих построителях можно встраивать в

создаваемые отчеты графические элементы, включая линии и прямоугольники.

Графика, реализованная таким путем, занимает память принтера и замедляет

построение отчета, поскольку линия представляет собой графический, а не

текстовый элемент или элемент шрифта. Другой способ выделения текста,

который остался от времен использования матричных принтеров, является

символ подчеркивания ( _ ).Линии, нарисованные таким способом, зря

расходуют целую строку под той строкой, которую они должны подчеркивать.

Поэтому, когда нужно подчеркнуть в отчете какие-нибудь элементы, надо

применять в любом шрифте вместо перечисленных способов атрибут

подчеркивания.

7. При представлении нумерованных данных используют правое выравнивание, а

для числовых идентификаторов - левое (например, для номеров заготовок или

номеров отчетов).

8. Для выделения элементов отчета можно использовать прогрессивные

возможности форматирования при печати, например, такие атрибуты шрифта,

как печать с тенью или полужирное начертание. Но надо иметь в виде, что

принтер пользователя должен обладать теми средствами, которые

предполагали при построении отчета.

12. ВЫВОДЫ

В результате работы над дипломным проектом были подробно изучены

современные операционные системы, базы данных, методы построения приложений

и языки программирования. В результате анализа этого была поставлена

задача создания программы по управлению базой данных объектов гражданской

обороны. Разработанный программный продукт позволяет обеспечить:

Ведение данных:

. объектов экономики;

. защитных сооружениях;

. опасных веществах;

. техники;

. материально-технических средств;

. формирований;

. обучаемых на УМЦ;

Формирование списков:

. объектов экономики;

. защитных сооружениях;

. опасных веществах;

. техники;

. материально-технических средств;

. формирований;

. обучаемых на УМЦ;

Составление любой(!!!) статистической информации по введенным данным.

Данный программный продукт автоматизирует процесс подготовки к

принятию решений при возникших ЧС; регистрацию объектов экономики и

составление списка характеристик объекта;

регистрацию наличия и численности различных составляющих объекта; снижает

расходы на подготовку и уточнения списков объектов; учета готовности

объекта к ЧС; учета проведения занятий с обучающимися в УМЦ; уменьшает

время на подготовку списков объектов экономики и списков обучающихся на УМЦ

по различным критериям;

Также в дипломном проекте были рассмотрены следующие вопросы:

Организационно-экономическая часть -

Экономическое обоснование создания программного продукта. Расчет

затрат на НИР. Определение затрат программного продукта. Оценка

экономической эффективности разработки;

Охрана труда и экология -

Оптимизация условия труда инженера-программиста при разработке

программного обеспечения;

Гражданская оборона -

Применение ЭВМ для повышения эффективности работы штаба ГО объекта

экономики;

Эргономическая часть -

Эргономическая оценка информационного обеспечения ЭВМ.

13. ЛИТЕРАТУРА

1. Атаманюк, Л.Г. Ширшев Гражданская оборона, Москва “Высшая школа”

1986г;

2. Журнал PCWEEK 30 сентября 1997 (65стр);

3. Журнал PCWEEK 19 августа 1997 (20стр);

4. Журнал ComputerWorld, Статья Делерри Хелд «Где же этот хваленый

универсальный сервер», 1997 21 номер;

5. Кен Хендерсон, Руководство разработчика баз данных в Delphi 2;

6. Журнал LAN апрель 1995, Статья Дж. Салеми;

7. Журнал LAN декабрь 1995, Статья Билла Лазарья;

8. Журнал СУБД 1995г №4 стр 50-57;

9. Dr. E.F. Codd "A Relational Model of Data for Large Share Data Banks",

1970;

10. Стивен Бобровски, Oracle 7 вычисление клиент/сервер;

11. С.Орлик, Секреты Delphi;

12. Сергей Дунаев, Borland технологии;

13. Эндрю Возневич, Освой самостоятельно Delphi;

14. А.Федоров, Создание Windows-приложений в среде Delphi;

15. Мартин Грабер, Введение в SQL;

16. А.М. Епанешников, Программирование в среде Delphi 2.0

17. B.Ю. Баженова, Windows SQL

18. В.В. Фаронов Библиотека Turbo Vision 6.0

19. Справочник по функциям и процедурам Borland Pascal 7.0

20. Подборка статей из эхо-конференции RU.DELPHI, RU.DELPHI.DB в сети

FIDONET (от сентября по декабрь1997 года).

ПРИЛОЖЕНИЕ 1

П.1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

П.1.1 Общие сведения

Система по управлению базой данных GOBASE предназначена для учета

объектов экономики, ведения базы данных о объектах экономики, учет

готовности объекта в случае возможных чрезвычайных ситуациях (ЧС),

формирования и печати списков объектов, а так же для учета обучаемых в

учебно-методическом центре (УМЦ).

GOBASE разрабатывается для использования в автоматизированной

системе оповещения при ЧС.

П.1.2. Постановка задачи

Спроектировать программный продукт, представляющий собой

доступ и управление базой данных в локальной вычислительной сети.

Разработка программы основывается на следующих документах:

1). Справочная литература по программированию на Delphi 2.0 для

Windows.

2). Справочная литература по работе с распределенной базой данных

Oracle.

3). Справочная литература по работе с операционной системой Windows.

4). Справочная литература по работе с операционной системой Novell

Netware.

Разработанный программный продукт необходимо представить в виде

исполняемых файлов.

П.1.3. Основания для разработки

Основанием для разработки является задание на дипломное проектирование.

Основанием для разработки также является договор на создание научно-

технической продукции между: Сафроновым С.О. и управлением по делам ГО и

ЧС ЮЗАО г.Москва.

П.1.4. Назначение и цели создания программного продукта

Данное программное обеспечение предназначено для выполнения

технологических функции в интересах системы предупреждения и ликвидации

ЧС.

Целью работы является создание программного продукта,

обеспечивающего:

1) автоматизацию процесса подготовки и принятия решения при

предупреждении и ликвидации ЧС;

2) регистрацию объектов экономики и их характеристик;

3) наличие и численного состава:

. техники;

. защитных сооружений;

. химически опасных веществ;

. материально-технических средств;

. формирований на объекте;

4) снижение времени на подготовку и уточнения данных по объектам ГО;

5) готовность объекта к ЧС;

6) проведение занятий с обучающимися в УМЦ;

7) контроль однократности учета объектов и обучающихся;

В состав функционального комплекса должны входить:

1) задача первоначального ввода информации об объектах экономики;

2) задача первоначального ввода информации об обучаемых на УМЦ;

3) задача формирования и печати списков объектов экономики;

4) задача формирования и печати списков обучаемых на УМЦ;

Необходимо спроектировать программу, содержащую стандартные элементы

управления. Программа должна удовлетворять эргономическим требованиям.

П.1.5. Требования к программе

Данная программа должна поддерживать интерфейс с пользователем

(верхний уровень) и интерфейс с распределенной базой данных (нижний

уровень). Программа GOBASE предназначена для работы под управлением

операционной среды Windows. Интерфейс пользователя должны соответствовать

стандартам Windows.

Для удобства отладки и тестирования программу целесообразно разделить

на отдельные блоки в соответствии с выполняемыми задачами.

При проектировании следует учитывать, что большинство пользователей

не является специалистами в вычислительной технике. Их знания компьютера

находятся на уровне оператора ЭВМ. Для работы с программой - пользователям

необходимо освоить работу в Windows на уровне оператора ЭВМ и ознакомиться

с руководством пользователя GOBASE.

В программе необходимо предусмотреть меры защиты от некорректных

действий пользователя. В частности предусмотреть запрос подтверждения

выполнения тех команд, выполнение которых может привести к значительным

потерям времени или к потери данных.

Программа должна обладать достаточной надежностью, работать под

операционной системой Windows 95 или Windows NT. Занимать не более 4Mb

оперативной памяти и не более 5Мб на диске в рабочем состоянии.

П.1.6. Состав и содержание работ по созданию программы

1). проектирование структуры базы данных;

2). проектирование прикладных процессов, необходимых для реализации

задачи;

3). разработка алгоритма программы;

4). кодирование алгоритма;

5). тестирование программы;

Следует учитывать, что при проектировании Windows - приложения

стирается грань между разработкой алгоритма и кодированием. При этом можно

начинать тестирование отдельных логически завершенных фрагментов программы

до завершения написания всей программы. Руководства по установке и

эксплуатации программного продукта могут входить в состав справочной

системы, к которой можно обращаться из основного исполнимого модуля

программы.

П.1.7. Входная информация

Входной информацией для функционального комплекса являются:

1). данные об объекте:

- наименование объекта;

- адрес объекта;

- количество работающих;

- наибольшая работающая смена;

- степень опасности;

- перечень хранимых опасных веществ;

- количество хранимых веществ;

- наличие и класс защитных сооружений;

- территориальная принадлежность к району;

- род деятельности;

- форма собственности;

- особенности объекта;

- подчиненность объекта;

- регистрационный номер объекта;

- Ф.И.О. руководителя объекта;

- занимаемая должность руководителя объекта;

- рабочий телефон руководителя объекта;

- домашний телефон руководителя объекта;

- Ф.И.О. начальника штаба ГО объекта;

- занимаемая должность начальника штаба ГО объекта;

- рабочий телефон начальника штаба ГО объекта;

- домашний телефон начальника штаба ГО объекта;

- телефон дежурного по объекту;

- телефон факса;

- телефон модема;

- время работы модема;

2). данные об обучаемых в УМЦ:

- Ф.И.О. обучаемого;

- индивидуальный номер обучаемого;

- категория обучаемого;

- занимаемая должность обучаемого;

- занимаемая должность обучаемого по ГО;

- рабочий телефон обучаемого;

- домашний телефон обучаемого;

- домашний адрес обучаемого;

- дата последнего обучения;

- дата планируемого обучения;

П.1.8. Выходная информация

Выходной информацией функционального комплекса являются:

1). списки объектов экономики установленной формы:

- в алфавитном порядке;

- по территориальной принадлежности к району;

2). списки обучаемых на УМЦ установленной формы:

- в алфавитном порядке;

- в порядке даты следующего обучения;

- в порядке принадлежности к объекту.

П.1.9. Порядок контроля и приемки программы

Контроль работоспособности программы возложить на Beta-тестеров

входящих в подразделение заказчика (не менее 3 человек).

П.1.10. Требования к составу и содержанию работ по установке программы на

рабочем месте оператора

Установка программы производится путем инсталляции программы с гибкого

диска изготовителя на жесткий диск компьютера. Перенос программы на другие

машины без разрешения изготовителя запрещен.

П.1.11. Требования к документированию

Изготовитель программного продукта обязан предоставить следующие

документы:

1). руководство пользователя программы GOBASE;

2). руководство по установке;

Эти документы должны быть включены в состав справочной системы

программы.

П.1.12. Источники разработки

Техническое задание на создание программы управления базой данных

локальной вычислительной сети.

ПРИЛОЖЕНИЕ 2

СОСТОЯНИЕ И ПЕРСПЕКТИВЫ РАЗВИТИЯ МОСКОВСКОЙ

ГОРОДСКОЙ СИСТЕМЫ ПРЕДУПРЕЖДЕНИЯ

И ЛИКВИДАЦИИ ЧРЕЗВЫЧАЙНЫХ СИТУАЦИЙ

Е.М. Кистанов

Начальник Штаба ГОЧС Москвы, генерал-майор

Город Москва - крупнейший политический, научный и

промышленный центр страны, важнейший транспортный узел.

речной порт и центр воздушных перевозок.

Площадь - 1061,0 кв.км. Население - 8,7 млн.чел. Москва

относится к химически опасным городам, на ее территории размещается большое

количество взрыво- и пожароопасных объектов.

Ежедневно железнодорожным и автомобильным транспортом в город

поступают и провозятся транзитом опасные грузы.

Большинство химически, -взрыво, -пожаро и других потенциально опасных

объектов размещаются в непосредственной близости от жилой зоны. Высокая

концентрация промышленных предприятий и автомобильного транспорта создают

сложную экологическую обстановку (задымление, загазованность) со

значительными превышениями предельно-допустимых концентраций.

В настоящее время в городе расположено около 70 химически опасных

объектов с общим запасом сильнодействующих ядовитых веществ 4600 т, в том

числе хлора 1300 т, аммиака 2300 т. различных кислот свыше 1000 т.

Наиболее крупными объектами являются по запасам хлора:

водопроводные станции - 4 (от 330 до 350 т); Московский электродный завод -

до 30 т.;

по запасам аммиака: 12 хладокомбинатов (от 10 до 120 т); 15 оптово-

розничных плодоовощных объединений (от 2 до 170 т);

по запасам кислот: Акционерное общество Желатиновый

завод - до 300 т соляной кислоты; Чертановская база кислот - 168

т азотной и соляной кислоты; Институт легких сплавов - 80 т

азотной кислоты; Московский завод полиметаллов - до 36 т азотной кислоты;

завод им. Войкова - до 70 т соляной кислоты.

В городской черте размещено: Московский нефтеперерабатывающий завод

(Капотня), 3 нефтебазы, около 200 АЗС.

Город Москва имеет развитую систему водо, газо, энергоснабжения.

Аварии на энергетических и инженерных сетях могут привести к нарушению

жизнедеятельности населения отдельных

районов и прекращению работы промышленных предприятий.

На территории города расположены три радиационно опас-

ных объекта (институт им.Курчатова - Северо-Западный АО, Мо-

сковский инженерно-физический институт - Южный АО, ВНИ-

КИЭТ - Центральный АО).

Город имеет большую сеть водных артерий (реки Москва,

Яуза, Сетунь, Сходня, канал им. Москвы), 2 речных вокзала

(Северный. Южный) и три речных порта (Северный, Западный и

Южный). Зона возможного катастрофического затопления может

составить свыше 80 кв.км. с населением 268,9 тыс.человек.

Через 20 железнодорожных станций на предприятия города

ежесуточно поступают под выгрузку до 30 вагонов со СДЯВ (хлор,

аммиак, кислоты) общим весом до 1800 т. В случае аварии при транспортировке

сильнодействующих ядовитых веществ зоны возможного химического заражения

будут соизмеримы с зонами соответствующих химически опасных объектов.

Практически при аварии на них угроза населению может возникнуть в любой

точке города.

Вот очень коротко о потенциальных опасностях для населе-

ния и территорий г. Москвы, не касаясь проблем экологии, геоло-

гического риска и вопросов медицины.

Анализ аварий и происшествий показывает, что характер

происшествий при перевозке СДЯВ и легковоспламеняющихся

жидкостей автомобильным и железнодорожным транспортом закономерно

повторяются принося значительный материальный и экологический ущерб. За

1996 год у нас зарегистрировано 14 производственных аварий на химически и

пожароопасных объектах.

шесть случаев с выбросом аммиака. Не уменьшается число происшествий на

метрополитене города. В 1996 году было 11 аварийных

ситуаций.

Увеличилось количество случаев обнаружения взрывоопасных устройств -

98 случаев. Трижды были обнаружены источники

радиоактивных веществ. Из-за неправильного использования и

хранения бытового газа в 11 случаях погибло 5 и пострадало 24

человека. Растет количество умышленных подрывов взрывных устройств.

Продолжают будоражить город анонимные звонки о минировании общественных и

жилых зданий, автомобилей. В каждом

таком случае проводится целый комплекс мероприятий, включающих оцепление,

эвакуацию, вызов дежурных подразделений и

т.д. И только в 0,3% из 1000 звонков были обнаружены взрывные

устройства.

В настоящее время важное социальное и экономическое

значение имеют профилактика, прогнозирование и ликвидации

последствий чрезвычайных ситуаций, возникающих в результате

аварий, катастроф и стихийных бедствий.

Снижение уровня техногенной нагрузки города Москвы.

который неоправданно велик, является одной из важнейших задач

перспективного генерального плана развития Москвы.

ПРИЛОЖЕНИЕ 3

spool build.log

connect internal

startup nomount pfile=STAS:ORANW722\DATABASE\initorcl.ora

create database gobase

controlfile reuse

logfile 'STAS:ORANW722\DATABASE\log1orcl.ora' size 200K reuse,

'STAS:ORANW722\DATABASE\log2orcl.ora' size 200K reuse

datafile 'STAS:ORANW722\DATABASE\sys1orcl.ora' size 100M reuse

autoextend on

next 100M maxsize 2000M

character set CL8MSWIN1251;

create rollback segment rb_temp;

alter rollback segment rb_temp online;

@build_db.sql

@STAS:ORANW722\RDBMS72\admin\catalog.sql

@STAS:ORANW722\RDBMS72\admin\catalog6.sql

@STAS:ORANW722\RDBMS72\admin\catproc.sql

connect system/manager

@STAS:ORANW722\RDBMS72\admin\catdbsyn.sql

@pupbld.sql

connect internal

alter rollback segment rb_temp offline;

shutdown;

spool off

ПРИЛОЖЕНИЕ 4

CREATE TABLE ACTIVITY

(ACTIVITY_ID NUMBER(7) NOT NULL,

ACTIVITY_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKACTIVITY

ON ACTIVITY

(

ACTIVITY_ID ASC

);

ALTER TABLE ACTIVITY

ADD ( PRIMARY KEY (ACTIVITY_ID) ) ;

CREATE TABLE BUILDING

(BUILDING_ID NUMBER(7) NOT NULL,

BUILDING_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKBUILDING

ON BUILDING

(

BUILDING_ID ASC

);

ALTER TABLE BUILDING

ADD ( PRIMARY KEY (BUILDING_ID) ) ;

CREATE TABLE BUILDINGOB

(OBJECT_ID NUMBER(9) NOT NULL,

BUILDING_ID NUMBER(7) NOT NULL,

BUILDINGNUM NUMBER(9) NULL,

NAMEADD_ID NUMBER(7) NOT NULL,

DATEADD DATE NOT NULL,

NAMEINS_ID NUMBER(7) NOT NULL,

DATEINS DATE NOT NULL,

PRIM VARCHAR2(100) NULL

);

CREATE UNIQUE INDEX IPKBUILDINGOB

ON BUILDINGOB

(

OBJECT_ID ASC,

BUILDING_ID ASC

);

CREATE INDEX IFKOBBUILDINGOB

ON BUILDINGOB

(

OBJECT_ID ASC

);

CREATE INDEX IFKBUBUILDINGOB

ON BUILDINGOB

(

BUILDING_ID ASC

);

ALTER TABLE BUILDINGOB

ADD ( PRIMARY KEY (OBJECT_ID, BUILDING_ID) ) ;

CREATE TABLE CATEGORY

(CATEGORY_ID NUMBER(7) NOT NULL,

CATEGORY_TYPE NUMBER(1) NOT NULL,

CATEGORY_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKCATEGORY

ON CATEGORY

(

CATEGORY_ID ASC

);

ALTER TABLE CATEGORY

ADD ( PRIMARY KEY (CATEGORY_ID) ) ;

CREATE TABLE CATTEMA

(TEMA_ID NUMBER(7) NOT NULL,

CATEGORY_ID NUMBER(7) NOT NULL,

CATTEMANUM NUMBER(4) NULL,

NAMEADD_ID NUMBER(7) NOT NULL,

DATEADD DATE NOT NULL,

NAMEINS_ID NUMBER(7) NOT NULL,

DATEINS DATE NOT NULL,

PRIM VARCHAR2(100) NULL

);

CREATE UNIQUE INDEX IPKCATTEMA

ON CATTEMA

(

TEMA_ID ASC,

CATEGORY_ID ASC

);

CREATE INDEX IFKTECATTEMA

ON CATTEMA

(

TEMA_ID ASC

);

CREATE INDEX IFKCACATTEMA

ON CATTEMA

(

CATEGORY_ID ASC

);

ALTER TABLE CATTEMA

ADD ( PRIMARY KEY (TEMA_ID, CATEGORY_ID) ) ;

CREATE TABLE DEPARTAMENT

(DEPARTAMENT_ID NUMBER(7) NOT NULL,

DEPARTAMENT_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKDEPARTAMENT

ON DEPARTAMENT

(

DEPARTAMENT_ID ASC

);

ALTER TABLE DEPARTAMENT

ADD ( PRIMARY KEY (DEPARTAMENT_ID) ) ;

CREATE TABLE FORMIROV

(FORMIROV_ID NUMBER(7) NOT NULL,

FORMIROV_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKFORMIROV

ON FORMIROV

(

FORMIROV_ID ASC

);

ALTER TABLE FORMIROV

ADD ( PRIMARY KEY (FORMIROV_ID) ) ;

CREATE TABLE FORMIROVOB

(FORMIROV_ID NUMBER(7) NOT NULL,

OBJECT_ID NUMBER(9) NOT NULL,

READY_ID NUMBER(7) NOT NULL,

FORMIROVNUM NUMBER(9) NULL,

PEOPLENUM NUMBER(9) NULL,

NAMEADD_ID NUMBER(7) NOT NULL,

DATEADD DATE NOT NULL,

NAMEINS_ID NUMBER(7) NOT NULL,

DATEINS DATE NOT NULL,

PRIM VARCHAR2(100) NULL

);

CREATE UNIQUE INDEX IPKFORMIROVOB

ON FORMIROVOB

(

FORMIROV_ID ASC,

OBJECT_ID ASC

);

CREATE INDEX IFKFOFORMIROVOB

ON FORMIROVOB

(

FORMIROV_ID ASC

);

CREATE INDEX IFKOBFORMIROVOB

ON FORMIROVOB

(

OBJECT_ID ASC

);

CREATE INDEX IFKREFORMIROVOB

ON FORMIROVOB

(

READY_ID ASC

);

ALTER TABLE FORMIROVOB

ADD ( PRIMARY KEY (FORMIROV_ID, OBJECT_ID) ) ;

CREATE TABLE GOBASEUSER

(GOBASEUSER_ID NUMBER(7) NOT NULL,

NAME VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKGOBASEUSER

ON GOBASEUSER

(

GOBASEUSER_ID ASC

);

ALTER TABLE GOBASEUSER

ADD ( PRIMARY KEY (GOBASEUSER_ID) ) ;

CREATE TABLE MATERIAL

(MATERIAL_ID NUMBER(7) NOT NULL,

MATERIAL_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKMATERIAL

ON MATERIAL

(

MATERIAL_ID ASC

);

ALTER TABLE MATERIAL

ADD ( PRIMARY KEY (MATERIAL_ID) ) ;

CREATE TABLE MATERIALOB

(OBJECT_ID NUMBER(9) NOT NULL,

MATERIAL_ID NUMBER(7) NOT NULL,

MATERIALNUM NUMBER(9) NULL,

NAMEADD_ID NUMBER(7) NOT NULL,

DATEADD DATE NOT NULL,

NAMEINS_ID NUMBER(7) NOT NULL,

DATEINS DATE NOT NULL,

PRIM VARCHAR2(100) NULL

);

CREATE UNIQUE INDEX IPKMATERIALOB

ON MATERIALOB

(

OBJECT_ID ASC,

MATERIAL_ID ASC

);

CREATE INDEX IFKOBMATERIALOB

ON MATERIALOB

(

OBJECT_ID ASC

);

CREATE INDEX IFKMAMATERIALOB

ON MATERIALOB

(

MATERIAL_ID ASC

);

ALTER TABLE MATERIALOB

ADD ( PRIMARY KEY (OBJECT_ID, MATERIAL_ID) ) ;

CREATE TABLE MATTEH

(MATTEH_ID NUMBER(7) NOT NULL,

SERVIS_ID NUMBER(7) NOT NULL,

MATTEH_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKMATTEH

ON MATTEH

(

MATTEH_ID ASC

);

CREATE INDEX IFKSEMATTEH

ON MATTEH

(

SERVIS_ID ASC

);

ALTER TABLE MATTEH

ADD ( PRIMARY KEY (MATTEH_ID) ) ;

CREATE TABLE MATTEHOB

(OBJECT_ID NUMBER(9) NOT NULL,

MATTEH_ID NUMBER(7) NOT NULL,

MATTEHNUM NUMBER(9) NULL,

NAMEADD_ID NUMBER(7) NOT NULL,

DATEADD DATE NOT NULL,

NAMEINS_ID NUMBER(7) NOT NULL,

DATEINS DATE NOT NULL,

PRIM VARCHAR2(100) NULL

);

CREATE UNIQUE INDEX IPKMATTEHOB

ON MATTEHOB

(

OBJECT_ID ASC,

MATTEH_ID ASC

);

CREATE INDEX IFKMAMATTEHOB

ON MATTEHOB

(

MATTEH_ID ASC

);

CREATE INDEX IFKOBMATTEHOB

ON MATTEHOB

(

OBJECT_ID ASC

);

ALTER TABLE MATTEHOB

ADD ( PRIMARY KEY (OBJECT_ID, MATTEH_ID) ) ;

CREATE TABLE OBECONOM

(OBJECT_ID NUMBER(9) NOT NULL,

OBJECTNO NUMBER(7) NOT NULL,

POSTGO_ID NUMBER(7) NOT NULL,

POST_ID NUMBER(7) NOT NULL,

DEPARTAMENT_ID NUMBER(7) NOT NULL,

RISK_ID NUMBER(7) NOT NULL,

PROPERTY_ID NUMBER(7) NOT NULL,

ACTIVITY_ID NUMBER(7) NOT NULL,

REGION_ID NUMBER(7) NOT NULL,

PECULIAR_ID NUMBER(7) NOT NULL,

GLAVOBJECT_ID NUMBER(7) NOT NULL,

OBJECTNAME VARCHAR2(100) NULL,

ADDRESS_IND CHAR(6) NULL,

TOWN_ID NUMBER(9) NULL,

ADDRESS_CHAR VARCHAR2(150) NULL,

WORKNUMBER NUMBER(7) NULL,

NRSM NUMBER(7) NULL,

NRSV NUMBER(7) NULL,

DIRECTIONNAME VARCHAR2(50) NULL,

DIRECTIONWTEL CHAR(7) NULL,

DIRECTIONHTEL CHAR(7) NULL,

ZAMNAME VARCHAR2(50) NULL,

ZAMWTEL CHAR(7) NULL,

ZAMHTEL CHAR(7) NULL,

COMANDGONAME VARCHAR2(50) NULL,

COMANDGOWTEL CHAR(7) NULL,

COMANDGOHTEL CHAR(7) NULL,

P1NAME VARCHAR2(50) NULL,

P1WTEL CHAR(7) NULL,

P1HTEL CHAR(7) NULL,

P2NAME VARCHAR2(50) NULL,

P2WTEL CHAR(7) NULL,

P2HTEL CHAR(7) NULL,

P3NAME VARCHAR2(50) NULL,

P3WTEL CHAR(7) NULL,

P3HTEL CHAR(7) NULL,

DUTYTEL CHAR(7) NULL,

DUTY2TEL CHAR(7) NULL,

FAXTEL CHAR(7) NULL,

MODEMTEL CHAR(7) NULL,

NAMEADD_ID NUMBER(7) NOT NULL,

DATEADD DATE NOT NULL,

NAMEINS_ID NUMBER(7) NOT NULL,

DATEINS DATE NOT NULL,

PRIM VARCHAR2(200) NULL

);

CREATE UNIQUE INDEX IPKOBECONOM

ON OBECONOM

(

OBJECT_ID ASC

);

CREATE INDEX IFKPEOBECONOM

ON OBECONOM

(

PECULIAR_ID ASC

);

CREATE INDEX IFKRIOBECONOM

ON OBECONOM

(

RISK_ID ASC

);

CREATE INDEX IFKPROBECONOM

ON OBECONOM

(

PROPERTY_ID ASC

);

CREATE INDEX IFKACOBECONOM

ON OBECONOM

(

ACTIVITY_ID ASC

);

CREATE INDEX IFKREOBECONOM

ON OBECONOM

(

REGION_ID ASC

);

CREATE INDEX IFKDEOBECONOM

ON OBECONOM

(

DEPARTAMENT_ID ASC

);

CREATE INDEX IFKPOOBECONOM

ON OBECONOM

(

POST_ID ASC

);

CREATE INDEX IFKPGOBECONOM

ON OBECONOM

(

POSTGO_ID ASC

);

ALTER TABLE OBECONOM

ADD ( PRIMARY KEY (OBJECT_ID) ) ;

CREATE TABLE ORAUSER

(ORAUSER_ID INTEGER NOT NULL,

GOBASEUSER_ID NUMBER(7) NOT NULL

);

CREATE UNIQUE INDEX IPKORAUSER

ON ORAUSER

(

ORAUSER_ID ASC

);

CREATE INDEX IFKGORAUSER

ON ORAUSER

(

GOBASEUSER_ID ASC

);

ALTER TABLE ORAUSER

ADD ( PRIMARY KEY (ORAUSER_ID) ) ;

CREATE TABLE PECULIAR

(PECULIAR_ID NUMBER(7) NOT NULL,

PECULIAR_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKPECULIAR

ON PECULIAR

(

PECULIAR_ID ASC

);

ALTER TABLE PECULIAR

ADD ( PRIMARY KEY (PECULIAR_ID) ) ;

CREATE TABLE POST

(POST_ID NUMBER(7) NOT NULL,

POST_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKPOST

ON POST

(

POST_ID ASC

);

ALTER TABLE POST

ADD ( PRIMARY KEY (POST_ID) ) ;

CREATE TABLE POSTGO

(POSTGO_ID NUMBER(7) NOT NULL,

POSTGO_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKPOSTGO

ON POSTGO

(

POSTGO_ID ASC

);

ALTER TABLE POSTGO

ADD ( PRIMARY KEY (POSTGO_ID) ) ;

CREATE TABLE PROPERTY

(PROPERTY_ID NUMBER(7) NOT NULL,

PROPERTY_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKPROPERTY

ON PROPERTY

(

PROPERTY_ID ASC

);

ALTER TABLE PROPERTY

ADD ( PRIMARY KEY (PROPERTY_ID) ) ;

CREATE TABLE READY

(READY_ID NUMBER(7) NOT NULL,

READY_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKREADY

ON READY

(

READY_ID ASC

);

ALTER TABLE READY

ADD ( PRIMARY KEY (READY_ID) ) ;

CREATE TABLE REGION

(REGION_ID NUMBER(7) NOT NULL,

REGION_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKREGION

ON REGION

(

REGION_ID ASC

);

ALTER TABLE REGION

ADD ( PRIMARY KEY (REGION_ID) ) ;

CREATE TABLE RISK

(RISK_ID NUMBER(7) NOT NULL,

RISK_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKRISK

ON RISK

(

RISK_ID ASC

);

ALTER TABLE RISK

ADD ( PRIMARY KEY (RISK_ID) ) ;

CREATE TABLE SERVIS

(SERVIS_ID NUMBER(7) NOT NULL,

SERVIS_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKSERVIS

ON SERVIS

(

SERVIS_ID ASC

);

ALTER TABLE SERVIS

ADD ( PRIMARY KEY (SERVIS_ID) ) ;

CREATE TABLE SPOST

(SPOST_ID NUMBER(7) NOT NULL,

SPOST_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKSPOST

ON SPOST

(

SPOST_ID ASC

);

ALTER TABLE SPOST

ADD ( PRIMARY KEY (SPOST_ID) ) ;

CREATE TABLE STUDY

(STUDY_ID NUMBER(9) NOT NULL,

OBJECT_ID NUMBER(9) NOT NULL,

SPOST_ID NUMBER(7) NOT NULL,

CATEGORY_ID NUMBER(7) NOT NULL,

NAME VARCHAR2(50) NULL,

WORKTEL CHAR(7) NULL,

LASTDATE DATE NOT NULL,

NEXTDATE DATE NOT NULL,

NAMEADD_ID NUMBER(7) NOT NULL,

DATEADD DATE NOT NULL,

NAMEINS_ID NUMBER(7) NOT NULL,

DATEINS DATE NOT NULL,

PRIM VARCHAR2(200) NULL

);

CREATE UNIQUE INDEX IPKSTUDY

ON STUDY

(

STUDY_ID ASC

);

CREATE INDEX IFKCASTUDY

ON STUDY

(

CATEGORY_ID ASC

);

CREATE INDEX IFKOBSTUDY

ON STUDY

(

OBJECT_ID ASC

);

CREATE INDEX IFKSPSTUDY

ON STUDY

(

SPOST_ID ASC

);

ALTER TABLE STUDY

ADD ( PRIMARY KEY (STUDY_ID) ) ;

CREATE TABLE TEHNICA

(TEHNICA_ID NUMBER(7) NOT NULL,

TEHNICA_CHAR VARCHAR2(50) NULL

);

CREATE UNIQUE INDEX IPKTEHNICA

ON TEHNICA

(

TEHNICA_ID ASC

);

ALTER TABLE TEHNICA

ADD ( PRIMARY KEY (TEHNICA_ID) ) ;

CREATE TABLE TEHNICAOB

(OBJECT_ID NUMBER(9) NOT NULL,

TEHNICA_ID NUMBER(7) NOT NULL,

TEHNICANUM NUMBER(9) NULL,

NAMEADD_ID NUMBER(7) NOT NULL,

DATEADD DATE NOT NULL,

NAMEINS_ID NUMBER(7) NOT NULL,

DATEINS DATE NOT NULL,

PRIM VARCHAR2(100) NULL

);

CREATE UNIQUE INDEX IPKTEHNICOB

ON TEHNICAOB

(

OBJECT_ID ASC,

TEHNICA_ID ASC

);

CREATE INDEX IFKTETEHNICAOB

ON TEHNICAOB

(

TEHNICA_ID ASC

);

CREATE INDEX IFKOBTEHNICAOB

ON TEHNICAOB

(

OBJECT_ID ASC

);

ALTER TABLE TEHNICAOB

ADD ( PRIMARY KEY (OBJECT_ID, TEHNICA_ID) ) ;

CREATE TABLE TEMA

(TEMA_ID NUMBER(7) NOT NULL,

TEMA_CHAR VARCHAR2(255) NULL

);

CREATE UNIQUE INDEX IPKTEMA

ON TEMA

(

TEMA_ID ASC

);

ALTER TABLE TEMA

ADD ( PRIMARY KEY (TEMA_ID) ) ;

ALTER TABLE BUILDINGOB

ADD ( FOREIGN KEY (BUILDING_ID)

REFERENCES BUILDING ) ;

ALTER TABLE BUILDINGOB

ADD ( FOREIGN KEY (OBJECT_ID)

REFERENCES OBECONOM ) ;

ALTER TABLE CATTEMA

ADD ( FOREIGN KEY (CATEGORY_ID)

REFERENCES CATEGORY ) ;

ALTER TABLE CATTEMA

ADD ( FOREIGN KEY (TEMA_ID)

REFERENCES TEMA ) ;

ALTER TABLE FORMIROVOB

ADD ( FOREIGN KEY (READY_ID)

REFERENCES READY ) ;

ALTER TABLE FORMIROVOB

ADD ( FOREIGN KEY (OBJECT_ID)

REFERENCES OBECONOM ) ;

ALTER TABLE FORMIROVOB

ADD ( FOREIGN KEY (FORMIROV_ID)

REFERENCES FORMIROV ) ;

ALTER TABLE MATERIALOB

ADD ( FOREIGN KEY (MATERIAL_ID)

REFERENCES MATERIAL ) ;

ALTER TABLE MATERIALOB

ADD ( FOREIGN KEY (OBJECT_ID)

REFERENCES OBECONOM ) ;

ALTER TABLE MATTEH

ADD ( FOREIGN KEY (SERVIS_ID)

REFERENCES SERVIS ) ;

ALTER TABLE MATTEHOB

ADD ( FOREIGN KEY (MATTEH_ID)

REFERENCES MATTEH ) ;

ALTER TABLE MATTEHOB

ADD ( FOREIGN KEY (OBJECT_ID)

REFERENCES OBECONOM ) ;

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (POSTGO_ID)

REFERENCES POSTGO ) ;

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (POST_ID)

REFERENCES POST ) ;

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (DEPARTAMENT_ID)

REFERENCES DEPARTAMENT ) ;

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (REGION_ID)

REFERENCES REGION ) ;

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (ACTIVITY_ID)

REFERENCES ACTIVITY ) ;

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (PROPERTY_ID)

REFERENCES PROPERTY ) ;

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (RISK_ID)

REFERENCES RISK ) ;

ALTER TABLE OBECONOM

ADD ( FOREIGN KEY (PECULIAR_ID)

REFERENCES PECULIAR ) ;

ALTER TABLE ORAUSER

ADD ( FOREIGN KEY (GOBASEUSER_ID)

REFERENCES GOBASEUSER ) ;

ALTER TABLE STUDY

ADD ( FOREIGN KEY (SPOST_ID)

REFERENCES SPOST ) ;

ALTER TABLE STUDY

ADD ( FOREIGN KEY (OBJECT_ID)

REFERENCES OBECONOM ) ;

ALTER TABLE STUDY

ADD ( FOREIGN KEY (CATEGORY_ID)

REFERENCES CATEGORY ) ;

ALTER TABLE TEHNICAOB

ADD ( FOREIGN KEY (OBJECT_ID)

REFERENCES OBECONOM ) ;

ALTER TABLE TEHNICAOB

ADD ( FOREIGN KEY (TEHNICA_ID)

REFERENCES TEHNICA ) ;

DROP INDEX IFKGORAUSER;

CREATE UNIQUE INDEX IFKGORAUSER

ON ORAUSER

(

GOBASEUSER_ID ASC

);

DROP INDEX IFKNOOBECONOM;

CREATE UNIQUE INDEX IFKNOOBECONOM

ON OBECONOM

(

OBJECTNO ASC

);

ALTER TABLE GO.OBECONOM ADD

(

FOREIGN KEY ( GLAVOBJECT_ID )

REFERENCES

GO.OBECONOM(OBJECT_ID)

);

ALTER TABLE GO.STUDY ADD

(

FOREIGN KEY ( NAMEADD_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.STUDY ADD

(

FOREIGN KEY ( NAMEINS_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.OBECONOM ADD

(

FOREIGN KEY ( NAMEADD_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.OBECONOM ADD

(

FOREIGN KEY ( NAMEINS_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.MATERIALOB ADD

(

FOREIGN KEY ( NAMEADD_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.MATERIALOB ADD

(

FOREIGN KEY ( NAMEINS_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.BUILDINGOB ADD

(

FOREIGN KEY ( NAMEADD_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.BUILDINGOB ADD

(

FOREIGN KEY ( NAMEINS_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.TEHNICAOB ADD

(

FOREIGN KEY ( NAMEADD_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.TEHNICAOB ADD

(

FOREIGN KEY ( NAMEINS_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.FORMIROVOB ADD

(

FOREIGN KEY ( NAMEADD_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.FORMIROVOB ADD

(

FOREIGN KEY ( NAMEINS_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.MATTEHOB ADD

(

FOREIGN KEY ( NAMEADD_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.MATTEHOB ADD

(

FOREIGN KEY ( NAMEINS_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.CATTEMA ADD

(

FOREIGN KEY ( NAMEADD_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

ALTER TABLE GO.CATTEMA ADD

(

FOREIGN KEY ( NAMEINS_ID )

REFERENCES

GO.GOBASEUSER(GOBASEUSER_ID)

);

CREATE TRIGGER IU_STUDY BEFORE INSERT OR UPDATE ON GO.STUDY

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

CREATE TRIGGER IU_OBECONOM BEFORE INSERT OR UPDATE ON GO.OBECONOM

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

CREATE TRIGGER IU_MATERIALOB BEFORE INSERT OR UPDATE ON GO.MATERIALOB

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

CREATE TRIGGER IU_BUILDINGOB BEFORE INSERT OR UPDATE ON GO.BUILDINGOB

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

CREATE TRIGGER IU_FORMIROVOB BEFORE INSERT OR UPDATE ON GO.FORMIROVOB

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

CREATE TRIGGER IU_TEHNICAOB BEFORE INSERT OR UPDATE ON GO.TEHNICAOB

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

CREATE TRIGGER IU_MATTEHOB BEFORE INSERT OR UPDATE ON GO.MATTEHOB

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

CREATE TRIGGER IU_CATTEMA BEFORE INSERT OR UPDATE ON GO.CATTEMA

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;

CREATE SEQUENCE S_STUDY;

CREATE SEQUENCE S_CATEGORY;

CREATE SEQUENCE S_TEMA;

CREATE SEQUENCE S_SPOST;

CREATE SEQUENCE S_OBECONOM;

CREATE SEQUENCE S_PECULIAR;

CREATE SEQUENCE S_REGION;

CREATE SEQUENCE S_RISK;

CREATE SEQUENCE S_DEPARTAMENT;

CREATE SEQUENCE S_PROPERTY;

CREATE SEQUENCE S_ACTIVITY;

CREATE SEQUENCE S_POST;

CREATE SEQUENCE S_POSTGO;

CREATE SEQUENCE S_MATERIAL;

CREATE SEQUENCE S_BUILDING;

CREATE SEQUENCE S_TEHNICA;

CREATE SEQUENCE S_MATTEH;

CREATE SEQUENCE S_SERVIS;

CREATE SEQUENCE S_FORMIROV;

CREATE SEQUENCE S_READY;