|
Система управления базой данных объектов гражданской обороны.
Государственный Комитет Российской Федерации по
высшему образованию
Московский Государственный Институт Радиотехники,
Электроники и Автоматики (Технический Университет)
Факультет ВМС
Кафедра Кибернетики
Шифр АВ-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. Непосредственное управление данными во внешней
памяти 25
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. Средства поддержки распределенных информационных
приложений 40
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. ВЫБОР ОПЕРАЦИОННОЙ СИСТЕМЫ
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
(Enterprise
Network
Services)
6.0
Серверные платформы:
ENS for UNIX: работает на RISC-компьютерах под
управлением SCO UNIX, HP-UX, Solaris, AIX ENS for
NetWare: работает на Intel-платформах под управлени-
ем NetWare 2.x, 3.x, 4.x
VINES работает на Intel-платформах
Клиентские платформы: DOS, Macintosh, OS/2, UNIX,
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 Server
3.51 и 4.0
Серверные платформы: компьютеры на базе процессо-
ров Intel,
PowerPC, DEC Alpha, MIPS
Клиентские платформы: 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
Server 4.0
Серверные платформы: операционные системы MVS и
VM для мейнфреймов; 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. Вa?eaiou пino?iaiey иioi?iaoeiiiuo п?eei?aiee с
использованием СУБД
Г?oiiiaua e кi?ii?aoeaiua иioi?iaoeiiiua сenoaiu e
сiioaaonoao?uea прeei?aiey моaoo ст?ieouny рacee?iuie сiiniaaie:
? мiiaioa?ieiaeuiua цaio?aeeciaaiiua вu?eneeoaeuiua сenoaiu;
? сenoaiu нa оniiaa лieaeuiie сaoe IE (фaee-na?aa?iua п?eei?aiey);
? сenoaiu n а?oeoaeoo?ie кeeaio-сa?aa?;
Дey лo?oaai пiieiaiey оa?aie?aiee рacee?iuo а?oeoaeoo?
иioi?iaoeiiiuo сenoai, рacaaeei п?eei?aiey нa тeiiaua.
Типовые компоненты информационных приложений
Выделим в информационном приложении типовые функцио-
нальные компоненты, достаточные для формирования любого при-
ложения на основе БД.
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. Схем построения информационных систем
№
Оienaiea сoaiu
Клeaio
Сa?aa?
П?eia? рaaeecaoee
1
Централизованная
многотерминальная
система
PS
PL,
BL,
DL,
DS, FS
Сервер Sun с X-
терминалами в среде
ОС Solaris
2
Локальная сеть ПК с
файл серверными
приложениями
PS, PL,
BL, DL
DS, FS
Локальная сеть ПК в
среде NetWare, про-
граммы на FoxPro,
Clipper и др.
3
Удаленный доступ к
данным на сервере
БД
PS, PL,
BL, DL
DS, FS
Система клиент-
сервер с доступом ПК
к серверу БД: Informix
(NetWare)
4
Удаленный доступ к
БД с использованием
хранимых процедур
PS, PL,
DL
BL,
DS, FS
Система клиент-
сервер, доступ ПК к
серверу ORACLE в
среде SCO Unix
5
Удаленный доступ к
БД с разделением ло-
гики приложения
PS, PL,
BL, DL
BL,
DL,
DS, FS
Система клиент-
сервер, доступ ПК к
серверу ORACLE на
Sun (Solaris)
3.3.1. Централизованные многотерминальные системы
В централизованной системе, характерной для Unix, терминал
реализует лишь функции представления данных PS, тогда как ос-
тальные функции обеспечивает центральный узел. Центр должен
реагировать на каждый запрос пользователя (PL), выполнять логику
приложения (BL, DL) и извлекать данные из БД (DS, FS). Имеются
две серьезные проблемы для централизованной схемы: трудно обес-
печить графический интерфейс; каждый дополнительный пользова-
тель и приложение вносят существенную нагрузку на сервер, теря-
ется масштабируемость.
3.3.2. Файл-серверные приложения
В отличии от централизованной системы архитектура "файл-
сервер" (таблица 3.1 и рисунок 3.1) не имеет сетевого разделения
компонентов диалога PS и PL, использует ПК для функций отобра-
жения, что облегчает построение графического интерфейса. Файл-
сервер только извлекает данные из файлов, так что дополнительные
пользователи и приложения добавляют лишь незначительную на-
грузку на ЦП. Каждый новый клиент добавляет вычислительную
мощность к сети.
Рисунок 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). Типовое определение архитектуры
клиент-сервер - приложение на клиенте, СУБД - на сервере - ис-
пользует эту схему.
Рисунок 3.2.
Варианты построения приложений клиент-сервер.
Поскольку эта схема предъявляет наименьшие требования к серве-
ру, она обладает наилучшей масштабируемостью. Однако сложные
приложения, вызывающие большое взаимодействие с БД, могут же-
стко загрузить как клиента, так и сеть. Результаты SQL-запроса
должны вернуться клиенту для обработки, потому что там находит-
ся логика принятия решения. Такая схема возлагает дополнительное
бремя администрирования приложений, разбросанных по различ-
ным клиентским узлам.
Можно сократить нагрузку на клиента и сеть, переместив це-
ликом компонент BL на сервер, при этом вся логика принятия ре-
шений оформлена в виде хранимых процедур и выполняется на сер-
вере БД. Хранимая процедура - процедура с операторами SQL для
доступа к БД, вызываемая по имени с передачей требуемых пара-
метров и выполняемая на сервере БД. Компиляция повышает ско-
рость исполнения хранимых процедур и сокращает нагрузку на сер-
вер. Но, перегрузив хранимые процедуры прикладной логикой,
можно потерять преимущества по производительности. Хранимые
процедуры улучшают целостность приложений и БД, гарантируют
актуальность коллективно используемых операций и вычислений.
Улучшается сопровождение таких процедур, а также безопасность
(нет прямого доступа к данным).
Переместив с клиента часть логики приложения на сервер, по-
лучим систему клиент-сервер с разделенной логикой. Часть при-
кладной логики может быть реализована на клиенте, а другая часть
логики - в виде обработчиков событий (триггеров) и хранимых про-
цедур на сервере БД. Такая схема при удачном разделении логики
приводит к сбалансированной загрузке клиентов и сервера, но при
этом затрудняется сопровождение приложений.
Рисунок 3.3.
Приложения клиент-сервер на основе многотерминальной сис-
темы.
На основе многотерминальной системы в качестве сервера
приложений также возможно создание архитектуры клиент-сервер
(рисунок 3.3.). В этом случае в многозадачной среде сервера прило-
жений выполняются программы пользователей, а клиентские узлы
вырождены и представлены терминалами.
4. ВЫБОР ЯЗЫКА ПРОГРАММИРОВАНИЯ
Кeanneoeeaoey с?aanoa рac?aaioee иioi?iaoeiiiuo п?eei?aiee
С?aae с?aanoa рac?aaioee иioi?iaoeiiiuo п?eei?aiee мi?ii
вuaaeeou сeaao?uea оniiaiua г?oiiu:
? т?aaeoeiiiua сenoaiu п?ia?aiie?iaaiey;
? иino?oiaiou дey сicaaiey фaee-na?aa?iuo п?eei?aiee;
? с?aanoaa рac?aaioee п?eei?aiee кeeaio-сa?aa?;
Рanniio?ei к?aoei оoee?eoaeuiua чa?ou e оaeanou п?eiaiaiey
кa?aie г?oiiu иino?oiaioaeuiuo с?aanoa сicaaiey иioi?iaoeiiiuo
п?eei?aiee.
4.1.Т?aaeoeiiiua сenoaiu п?ia?aiie?iaaiey
Традиционные системы программирования представлены
средствами создания приложений на языках третьего поколения
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. Eino?oiaiou дey сicaaiey фaee-na?aa?iuo прeei?aiee
Основой разработки файл-серверных приложений для локаль-
ных сетей ПК является инструментальное окружение различных
"персональных" СУБД: 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. С?aanoaa рac?aaioee прeei?aiee кeeaio-na?aa?
Группу инструментальных средств для создания информаци-
онных приложений с архитектурой клиент-сервер можно разделить
на следующие подгруппы:
? среды разработки приложений для серверов баз данных, незави-
симые от СУБД инструменты для создания приложений клиент-
сервер;
? средства поддержки распределенных информационных приложе-
ний.
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-репозитария, возможность переноса приложений и кон-
троль версий. При этом следует выяснить, насколько опыт разра-
ботчиков предприятия соответствует требованиям продукта, важна
ли переносимость приложений на другие аппаратные платформы и
базы данных, какая степень интеграции приложений устроит заказ-
чика и нужно ли будет в дальнейшем подключать к приложению
дополнительных пользователей, функции и данные.
Тaaeeoa 4.1. Инструментальные наборы для разработки прило-
жений клиент-сервер
Продукт/
компания
Объектно-
ориен-
тированная
ин-
фраструкту
ра
Распреде
ление
приложе-
ний ме-
жду кли-
ентом и
сервером
Поддержка
мониторов
транзакций
CASE
-репо-
зитар
ий
Перенос
при-
ложений
и кон-
троль
версий
JAM
компании
JYACC
нет
да
да
нет
нет
New Era
ком-
паниии
Informix
да
нет
нет
да
да
Developer
2000
компании
Oracle
нет
да
да
да
да
Power
Builder
да
нет
да
да
да
Delphi
компании
Borland
да
нет
да
да
да
MS-
Access
компании
Microsoft
нет
нет
нет
нет
нет
Oracle
Power
Object
компании
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. ВЫВОДЫ ПО ВЫБОРУ ОПЕРАЦИОННОЙ СИСТЕМЫ,
ЯЗЫКА ПРОГРАММИРОВАНИЯ И БАЗЫ ДАННЫХ
Первоочередной задачей является выбор вa?eaiou пino?iaiey
инoi?iaoeiiiuo п?eei?aiee с использованием СУБД. Из рас-
смотренных вариантов сenoaiu n а?oeoaeoo?ie кeeaio-сa?aa? наи-
более эффективная и дешевая для больших баз данных и множества
пользователей, которым нужен доступ к «свежим» данным. В мас-
штабе предприятия вычисления клиент/сервер — представляют со-
бой ни что иное, как распределение обработки в многопользователь-
ской базе данных по нескольким компьютерам (ПК и рабочим стан-
циям).
Что же дает вычисление клиент/сервер по сравнению с тради-
ционной однокомпьютерной средой (с одной большой ЭВМ)? При
корректной реализации системы клиент/сервер получается система
управления информацией с намного лучшим отношением
«цена/производительность», которую можно наращивать и легко
приспосабливать к меняющимся требованиям. Другой причиной
выбора технологии клиент/сервер является то обстоятельство, что
менеджерам уже более не нужно отслеживать сотни, а то и тысячи
программ, нуждающихся в обновлении и перекомпилировании каж-
дый раз при небольшом изменении в базе данных. К плюсам техно-
логии клиент/сервер можно отнести простоту и удобство пользова-
тельских интерфейсов, открытость систем, эффективную среду раз-
работки (особенно при наличии объектно-ориентированных инст-
рументов) и быстроту решений.
На сегодняшний момент только четыре базы являются прием-
лемыми для надежного хранения больших данных и удобства ис-
пользования: Oracle, Informix, Sysbase, Ingres.
Исходя из популярности в России (в ВПК) и на основе прове-
денного анализа по литературе в частности [2],[3],[4] и из опыта ра-
боты компаний «Рос.вооружение», НИИ «Восход», «Инком Банк»
была выбрана база данных Oracle.
Вторая задача это выбор операционной системы. На основа-
нии выводов
в главе 2.5. и таблицы 2.1 была выбрана Novell Netware 4.11 как ос-
новная система для работы базы данных Oracle. Определяющими
параметрами при выборе были: надежность и стабильность работы,
небольшее требование к ресурсам системы и стоимость, возмож-
ность безболезненного переноса на платформу Windows/NT. Ввиду
полномасштабного использования компьютеров типа Pentium и опе-
рационной системы Windows 95, а так же удобством разработки, ис-
пользования проектируемого продукта, работы с отчетными про-
граммами, в качестве клиентских приложений была выбрана Win-
dows 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 - обеспечива-
ют контроль над средой разработки "из вне" и доступ к информации
о проекте.
Рисунок 7.1. Borland Database Engine
6. СТРУКТУРА И ОСНОВНЫЕ ЗАДАЧИ УПРАВЛЕНИЯ ПО
ДЕЛАМ ГРАЖДАНСКОЙ ОБОРОНЫ И ЧРЕЗВЫЧАЙНЫМ
СИТУАЦИЯМ
6.1. Определение ГО
Гражданская оборона - постоянно действующий орган управ-
ления МЧС. Она предназначена для предупреждения возникновения
и развития чрезвычайных ситуаций в мирное и в военное время, а
также для ликвидации чрезвычайных ситуаций при их возникнове-
нии.
Гражданская оборона объединяет:
? городские, окружные и районные органы исполнительной власти
и управления экономикой, коммунальным хозяйством; общест-
венные организации, в компетенцию которых входят функции,
связанные с безопасностью и защитой населения, предупрежде-
нием, реагированием и действиями ЧС;
? организации(объекты), независимо от формы собственности и ве-
домственной принадлежности.
? силы и средства указанных органов управления, организа-
ций(объектов), используемые в целях координации их деятельно-
сти по предупреждению ЧС, защите населения, материальных и
культурных ценностей, окружающей среды, ликвидации ЧС.
6.2. Основные задачи ГО
1. Создание и поддержание в готовности систем управления, сил и
средств, чрезвычайных резервов финансовых и материальных ре-
сурсов.
2. Организация наблюдения и контроля за состоянием окружающей
среды и потенциально опасных объектов, прогнозирование чрез-
вычайных ситуаций.
3. Разработка и осуществление мер направленных на защиту насе-
ления, повышение устойчивости функционирования отраслей
экономики и городского хозяйства в чрезвычайных ситуациях.
4. Совершенствование и обеспечение функционирования системы
подготовки органов управления, специалистов МЧС, обучение
населения действиям в чрезвычайных ситуациях.
5. Оповещения населения о возникновении чрезвычайной ситуации
и порядке действий в сложившейся обстановке.
6. Проведение работ по ликвидации чрезвычайных ситуаций, перво-
очередному жизнеобеспечению населения, в первую очередь по-
страдавшего.
6.3. Схема управления по делам ГО и ЧС
Рисунок 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
домашний телефон руководителя объ-
екта
COMMANDGONAM
E
Ф.И.О. начальника штаба ГО объекта
POSTGO_ID
должность начальника штаба ГО объ-
екта
FK
COMMANDGOWTE
L
рабочий телефон начальника штаба ГО
объекта
COMMANDGOHTE
L
домашний телефон начальника ГО
объекта
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_C
HAR
Наименование
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 - составной уникальный ключ
(MATERIAL_ID, OBJECT_ID)
[pk]
FK
OBJECT_ID
ID - составной уникальный ключ
(MATERIAL_ID, OBJECT_ID)
[pk]
FK
MATERIALNUM
количество
NAMEADD_ID
владелиц
FK
DATEADD
дата ввода
NAMEINS_ID
корректировщик
FK
DATEINS
дата последней коррекции
PRIM
примечание
MATERIAL
Таблица-словарь опасных веществ
MATERIAL _ID
ID - уникальный ключ строки в табли-
це
PK
MATERIAL _CHAR
Наименование опасных веществ
BUILDINGOB
таблица защитных сооружений на объ-
ектах;
BUILDING_ID
ID - составной уникальный ключ
(BUILDING _ID, OBJECT_ID)
[pk]
FK
OBJECT_ID
ID - составной уникальный ключ
(BUILDING_ID,OBJECT_ID)
[pk]
FK
BUILDINGNUM
количество
NAMEADD_ID
владелиц
FK
DATEADD
дата ввода
NAMEINS_ID
корректировщик
FK
DATEINS
дата последней коррекции
PRIM
примечание
BUILDIN
Таблица-словарь защитных сооруже-
ний
BUILDIN _ID
ID - уникальный ключ строки в табли-
це
PK
BUILDIN _CHAR
Наименование опасных веществ
TEHNICAOB
таблица техники на объектах;
TEHNICA_ID
ID - составной уникальный ключ
(TEHNICA _ID, OBJECT_ID)
[pk]
FK
OBJECT_ID
ID - составной уникальный ключ
(TEHNICA_ID,OBJECT_ID)
[pk]
FK
TEHNICANUM
количество
NAMEADD_ID
владелиц
FK
DATEADD
дата ввода
NAMEINS_ID
корректировщик
FK
DATEINS
дата последней коррекции
PRIM
примечание
TEHNICA
Таблица-словарь техники
TEHNICA _ID
ID - уникальный ключ строки в табли-
це
PK
TEHNICA _CHAR
Наименование опасных веществ
FORMIROVOB
таблица формирований на объектах;
FORMIROV_ID
ID - составной уникальный ключ
(FORMIROV _ID, OBJECT_ID)
[pk]
FK
OBJECT_ID
ID - составной уникальный ключ
(FORMIROV_ID,OBJECT_ID)
[pk]
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 - составной уникальный ключ
(MATTEH _ID, OBJECT_ID)
[pk]
FK
OBJECT_ID
ID - составной уникальный ключ
(MATTEH_ID,OBJECT_ID)
[pk]
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 - составной уникальный ключ
(TEMA_ID, CATEGORY_ID)
[pk]
FK
CATEGORY_ID
ID - составной уникальный ключ
(TEMA_ID, CATEGORY_ID)
[pk]
FK
CATTEMANUM
количество часов
PRIM
примечание
TEMA
Таблица-словарь тем обучения
TEMA_ID
ID - уникальный ключ строки в табли-
це
PK
TEMA_CHAR
Наименование темы
GOBASEUSER
таблица пользователей программы
GOBASEUSER_ID
ID - уникальный ключ строки в табли-
це
PK
NAME
Имя пользователя
ORAUSER
таблица соответствия идентификаторов
пользователей программы и базы данных
Oracle
ORAUSER_ID
UID - идентификатор базы данных
Oracle
PK
GOBASEUSER_ID
идентификаторов пользователей про-
граммы
FK
Первичный ключ(PK) - это поле или поля таблицы, которые ис-
пользуются как идентификатор элемента. Подобно идентификатору,
значение первичного ключа таблицы всегда уникально для каждой
записи. Поля, составляющие первичный ключ, используются также
для построения индекса, предназначенного для быстрого доступа к
ее строкам.
Внешний ключ(FK) — это поле или поля таблицы, которые, не
будучи употребленными в качестве идентификатора, часто исполь-
зуются при объединении с другими таблицами. В таблице объектов,
например, поле номера района служит в качестве внешнего ключа.
Поле номера района не уникально определяет конкретные записи
объектов - для одного района может быть несколько объектов.
Таблицы 7.2
OBECONOM
Таблица объектов экономики
Столбец
Тип данных
ра
зм
ер
OBJECT_ID
NUMBER
NOT
NULL
9
OBJECTNO
NUMBER
NOT
NULL
7
OBJECTNAME
VARCHAR2
NULL
10
0
ADDRESS_IND
CHAR
NULL
6
ADDRESS_CHAR
VARCHAR2
NULL
15
0
WORKNUMBER
NUMBER
NULL
7
NRSM
NUMBER
NULL
7
NRSW
NUMBER
NULL
7
DEPORTAMENT_ID
NUMBER
NOT
NULL
7
PECULIAR_ID
NUMBER
NOT
NULL
7
RISK_ID
NUMBER
NOT
NULL
7
REGION_ID
NUMBER
NOT
NULL
7
ACTIVITY_ID
NUMBER
NOT
NULL
7
PROPERTY_ID
NUMBER
NOT
NULL
7
GLAVOBJECT_ID
NUMBER
NOT
NULL
7
DIRECTIONNAME
VARCHAR2
NULL
50
POST_ID
NUMBER
NOT
NULL
7
DIRECTIONWTEL
CHAR
NULL
7
DIRECTIONHTEL
CHAR
NULL
7
COMMANDGONAM
E
VARCHAR2
NULL
50
POSTGO_ID
NUMBER
NOT
NULL
7
COMMANDGOWTE
L
CHAR
NULL
7
COMMANDGOHTE
L
CHAR
NULL
7
ZAMNAME
VARCHAR2
NULL
50
ZAMWTEL
CHAR
NULL
7
ZAMHTEL
CHAR
NULL
7
P1NAME
VARCHAR2
NULL
50
P1WTEL
CHAR
NULL
7
P1HTEL
CHAR
NULL
7
P2NAME
VARCHAR2
NULL
50
P2WTEL
CHAR
NULL
7
P2HTEL
CHAR
NULL
7
P3NAME
VARCHAR2
NULL
50
P3WTEL
CHAR
NULL
7
P3HTEL
CHAR
NULL
7
DUTYTEL
CHAR
NULL
7
DUTY2TEL
CHAR
NULL
7
FAXTEL
CHAR
NULL
7
MODEMTEL
CHAR
NULL
7
NAMEADD_ID
NUMBER
NOT
NULL
7
DATEADD
DATE
NOT
NULL
-
NAMEINS_ID
NUMBER
NOT
NULL
7
DATEINS
DATE
NOT
NULL
-
PRIM
VARCHAR2
NULL
20
0
DEPARTAMENT
Таблица-словарь ведомств
DEPARTAMENT_ID
NUMBER
NOT
NULL
7
DEPARTAMENT_C
HAR
VARCHAR2
NULL
50
PECULIAR
Таблица-словарь деятельностей в ОП
PECULIAR_ID
NUMBER
NOT
NULL
7
PECULIAR_CHAR
VARCHAR2
NULL
50
REGION
Таблица-словарь районов
REGION_ID
NUMBER
NOT
NULL
7
REGION_CHAR
VARCHAR2
NULL
50
RISK
Таблица-словарь степени опасности объек-
тов
RISK_ID
NUMBER
NOT
NULL
7
RISK_CHAR
VARCHAR2
NULL
50
PROPERTY
Таблица-словарь форм собственности
PROPERTY_ID
NUMBER
NOT
NULL
7
PROPERTY_CHAR
VARCHAR2
NULL
50
ACTIVITY
Таблица-словарь рода деятельности объектов
ACTIVITY_ID
NUMBER
NOT
NULL
7
ACTIVITY_CHAR
VARCHAR2
NULL
50
POST
Таблица-словарь гражданских должностей
POST_ID
NUMBER
NOT
NULL
7
POST_CHAR
VARCHAR2
NULL
50
POSTGO
Таблица-словарь должностей по ГО
POSTGO_ID
NUMBER
NOT
NULL
7
POSTGO_CHAR
VARCHAR2
NULL
50
MATERIALOB
Таблица опасных веществ на объектах
MATERIAL_ID
NUMBER
NOT
NULL
7
OBJECT_ID
NUMBER
NOT
NULL
9
MATERIALNUM
NUMBER
NULL
9
NAMEADD_ID
NUMBER
NOT
NULL
7
DATEADD
DATE
NOT
NULL
-
NAMEINS_ID
NUMBER
NOT
NULL
7
DATEINS
DATE
NOT
NULL
-
PRIM
VARCHAR2
NULL
10
0
MATERIAL
Таблица-словарь опасных веществ
MATERIAL _ID
NUMBER
NOT
NULL
7
MATERIAL _CHAR
VARCHAR2
NULL
50
BUILDINGOB
Таблица защитных сооружений на объектах
BUILDING_ID
NUMBER
NOT
NULL
7
OBJECT_ID
NUMBER
NOT
NULL
9
BUILDINGNUM
NUMBER
NULL
9
NAMEADD_ID
NUMBER
NOT
NULL
7
DATEADD
DATE
NOT
NULL
-
NAMEINS_ID
NUMBER
NOT
NULL
7
DATEINS
DATE
NOT
NULL
-
PRIM
VARCHAR2
NULL
10
0
BUILDIN
Таблица-словарь защитных сооружений
BUILDIN _ID
NUMBER
NOT
NULL
7
BUILDIN _CHAR
VARCHAR2
NULL
50
TEHNICAOB
Таблица техники на объек-
тах
TEHNICA_ID
NUMBER
NOT
NULL
7
OBJECT_ID
NUMBER
NOT
NULL
9
TEHNICANUM
NUMBER
NULL
9
NAMEADD_ID
NUMBER
NOT
NULL
7
DATEADD
DATE
NOT
NULL
-
NAMEINS_ID
NUMBER
NOT
NULL
7
DATEINS
DATE
NOT
NULL
-
PRIM
VARCHAR2
NULL
10
0
TEHNICA
Таблица-словарь техники
TEHNICA _ID
NUMBER
NOT
NULL
7
TEHNICA _CHAR
VARCHAR2
NULL
50
FORMIROVOB
Таблица формирований на объектах
FORMIROV_ID
NUMBER
NOT
NULL
7
OBJECT_ID
NUMBER
NOT
NULL
9
READY_ID
NUMBER
NOT
NULL
7
PEOPLENUM
NUMBER
NULL
9
FORMIROVNUM
NUMBER
NOT
NULL
9
NAMEADD_ID
NUMBER
NOT
NULL
7
DATEADD
DATE
NOT
NULL
-
NAMEINS_ID
NUMBER
NOT
NULL
7
DATEINS
DATE
NOT
NULL
-
PRIM
VARCHAR2
NULL
10
0
FORMIROV
Таблица-словарь формирований
FORMIROV _ID
NUMBER
NOT
NULL
7
FORMIROV _CHAR
VARCHAR2
NULL
50
READY
Таблица-словарь готовно-
сти
READY _ID
NUMBER
NOT
NULL
7
READY_CHAR
VARCHAR2
NULL
50
MATTEHOB
Таблица МТС на объектах
MATTEH_ID
NUMBER
NOT
NULL
7
OBJECT_ID
NUMBER
NOT
NULL
9
MATTEH NUM
NUMBER
NULL
9
NAMEADD_ID
NUMBER
NOT
NULL
7
DATEADD
DATE
NOT
NULL
-
NAMEINS_ID
NUMBER
NOT
NULL
7
DATEINS
DATE
NOT
NULL
-
PRIM
VARCHAR2
NULL
10
0
MATTEH
Таблица-словарь МТС
MATTEH _ID
NUMBER
NOT
NULL
7
MATTEH_CHAR
VARCHAR2
NULL
50
SERVIS_ID
NUMBER
NOT
NULL
7
SERVIS
Таблица-словарь служб
SERVIS _ID
NUMBER
NOT
NULL
7
SERVIS _CHAR
VARCHAR2
NULL
50
STUDY
Таблица обучаемых на
УМЦ
STUDY_ID
NUMBER
NOT
NULL
9
OBJECT_ID
NUMBER
NOT
NULL
9
CATEGORY_ID
NUMBER
NOT
NULL
7
NAME
VARCHAR2
NULL
50
SPOST_ID
NUMBER
NOT
NULL
7
WORKTEL
CHAR
NULL
7
LASTDATE
DATE
NULL
-
NEXTDATE
DATE
NULL
-
NAMEADD_ID
NUMBER
NOT
NULL
7
DATEADD
DATE
NOT
NULL
-
NAMEINS_ID
NUMBER
NOT
NULL
7
DATEINS
DATE
NOT
NULL
-
PRIM
VARCHAR2
NULL
20
0
SPOST
Таблица-словарь должностей обучаемых
SPOST _ID
NUMBER
NOT
NULL
7
SPOST _CHAR
VARCHAR2
NULL
50
CATEGORY
Таблица-словарь категорий обучаемых
CATEGORY_ID
NUMBER
NOT
NULL
7
CATEGORY_CHAR
VARCHAR2
NULL
50
CATEGORY_TYPE
NUMBER
NULL
1
CATTEMA
Таблица категорированых
тем
TEMA_ID
NUMBER
NOT
NULL
7
CATEGORY_ID
NUMBER
NOT
NULL
7
CATTEMANUM
NUMBER
NULL
9
PRIM
VARCHAR2
NULL
10
0
TEMA
Таблица-словарь тем обу-
чения
TEMA_ID
NUMBER
NOT
NULL
7
TEMA_CHAR
VARCHAR2
NULL
50
GOBASEUSER
Таблица пользователей программы
GOBASEUSER_ID
NUMBER
NOT
NULL
7
NAME
VARCHAR2
NULL
50
ORAUSER
Таблица соответствия идентификаторов
пользователей программы и базы данных
Oracle
ORAUSER_ID
INTEGER
NOT
NULL
GOBASEUSER_ID
NUMBER
NOT
NULL
7
NOT NULL - должно иметь значение
Рисунок 7.2. Диаграмма потоков данных (взаимосвязь таблиц)
7.6. Создание SQL сценария
После того как таблицы созданы и определена их связь необ-
ходимо составить SQL сценарий для создания базы данных.
7.6.1. Создание базы данных
Перед созданием базы данных ее необходимо спроектировать.
Этап проектирования базы данных включает в себя планирование
ограничений файлов и включение файлов а новую базу данных.
Этап создания состоит в выполнении этого плана с помощью ко-
манды SQL CREATE DATABASE и некоторых сценариев.
Основные задачи включают в себя следующее:
? Определение соответствующих значений в команде CREATE
DATABASE. для параметров ограничений файлов.
? Планирование размера и расположения файлов начальных дан-
ных табличной области SYSTEM новой базы данных.
? Планирование для новой базы данных размера и расположения
групп и членов журнала транзакций.
? Определение набора символов для хранения информации базы
данных.
? Создание файла параметров инициализации и спецификации
имен управляющих файлов базы данных.
Сценарий с файлами инициализации базы данных приведены
в ПРИЛОЖЕНИИ 3.
7.6.2. Создание таблиц
Таблицы создаются с помощью оператора SQL CREATE TA-
BLE.
Фрагмент из ПРИЛОЖЕНИЯ 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,
DBLookupCombo
lc
FindDialog
n_
DBLookupListBox,
DBLookupList
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_
VCFirstImpression
vf
ProgressBar
pr
VCFormulaOne
vo
QRBand
qb
VCSpeller
vs
QRDBCalc
qc
Имена типов в программе начинаются с большой буквы T.
Пример: TBaseForm
В имена констант используются только прописные буквы.
Пример: DEFSQL
7.9. Структура главного меню
Структура главного меню определяет характер работы прило-
жения и дает основные понятия по работе программы.
Главное меню программы состоит из пяти основных пунктов:
«Файлы», «Таблицы», «Отчеты» и «Помощь». (Рис. 7.3.)
Рисунок 7.3. Главное меню программы
Главное меню содержит пять кнопок быстрого запуска:
? Объекты экономики (вызов формы ввода объектов экономики);
? Обучаемые на УМЦ (вызов формы ввода обучаеых на УМЦ);
? Отчеты (вызов формы отчетов, дерева отчетов);
? Справка (вызов справки о программе);
В нижней части главного меню располагается информация:
? о текущем пользователе;
? о текущей версии программы.
7.9.1. Меню «Файлы»
Меню файлы состоит из подменю: установка принтера и вы-
ход.
Подменю установка принтера предназначена для вызова стан-
дартной формы выбора принтера (Рис. 7.4.).
Рисунок 7.4. Форма установки принтера
Подменю выход вызывает процедуры освобождения памяти
занимаемой программы, закрытие файлов и выход из программы.
7.9.2. Меню «Таблицы»
Меню «Таблицы» предназначена для доступа к любой таблице
базы данных. Данное меню состоит из следующих подменю:
? Объекты экономики (вызов подменю)
? Объекты экономики (вызов формы объектов экономики);
? Районы (вызов формы районов);
? Рода деятельности (вызов формы рода деятельности);
? Форма собственности (вызов формы собственности);
? Деятельность в ОП ( вызов формы по таблице-словарю дея-
тельности в особый период);
? Ведомства (вызов формы ведомства);
? Степень опасности (вызов формы степени опасности);
? Должность руководителя (вызов формы возможных долж-
ностей руководителей на объекте);
? Должности по ГО (вызов формы возможных должностей
руководителей штабов ГО на объекте);
? Обучаемые на УМЦ (вызов подменю)
? Обучаемые на УМЦ (вызов формы ввода обучаемых на
УМЦ);
? Категории обучаемых (вызов категории обучаемых на
УМЦ);
? Гражданские должности (вызов формы возможных граж-
данских должностей).
? Темы (вызов подменю)
? Категорированные темы (вызов формы категорированных
тем обучения на УМЦ);
? Темы (вызов формы тем обучения);
? Формирования;
? Степени готовности (степени готовности формирований);
? Защитные сооружения;
? Опасные вещества;
? Техника;
? Службы (службы ГО);
? МТС (вызов формы материально-технического обеспечения);
? Пользователи; (вызов формы ввода пользователей программы.
Только для администратора доступен этот пункт).
7.9.3. Меню «Отчеты»
Данное меню вызывает форму дерева отчетов программы.
Более подробно в пункте 7.13.3.
7.9.4. Меню «Помощь»
Данное меню вызывает гипертекст документации пользовате-
ля программы.
7.10. Проектирование иерархий форм и отчетов
Наметив, какие формы и отчеты необходимы приложению,
можно разработать отдельную иерархию форм и отчетов, чтобы
воспользоваться преимуществами средств поддержки наследствен-
ности визуальных форм Delphi. Другими словами, необходимо ор-
ганизовать формы и отчеты в общие классы, которые строятся друг
на друге.
Например, следует определить для приложения форму верхне-
го уровня, из которой будут происходить все другие формы. Если
позже возникнет необходимость изменять атрибут всех форм при-
ложения, то вносить изменения придется только в одном месте.
7.11. Иерархия форм программы
В программе используется более 28 форм для работы с табли-
цами базы данных и 7 вспомогательных форм для работы с печатью,
помощью и отчетами. В виду такого количества форм необходимо
составить иерархию форм (Рис 7.5.) для облегчения программиро-
вания и уменьшения требовательности к ресурсам ОС и аппаратным
ресурсам.
Рисунок 7.5. Иерархия форм
Формы сетки 1-4 используются для таблиц-справочников.
7.12. Основные органы управления форм программы GOBase
В каждой форме ввода присутствуют:
1. Навигатор по базе данных, который представляет собой деnять
кнопок (Рис 7.6) : «Первая строка в таблице», «Предыдущая стро-
ка», «Следующая строка», «Последняя строка в таблице»,
«Вставка», «Удаление», «Редактирование», «Ввод», «Отмена»,
«Перечитать данные из таблицы»;
2. Кнопка выхода из формы с сохранением данных (OK);
3. Кнопка выхода из формы без сохранения данных (Cancel);
4. Кнопка минимизации окна;
5. Кнопка максимизации окна;
6. Кнопка закрытия окна (аналогична Cancel);
7. Выпадающий список (список строк другой таблицы)
8. Кнопка с темя точками - вызов формы редактирования таблицы,
которая подключена к выпадающему списку.
Рисунок 7.6. Форма ввода формирований на текущем объекте
Любая форма ввода данных в основные таблицы содержит
дополнительную информацию о пользователе, который ввел и ре-
дактировал данную запись в текущей таблице.
Благодаря иерархической структуре программы в каждой
форме ввода присутствуют одинаковые элементы вывода информа-
ции, что позволяет обычному пользователю понять принцип работы
программы за считанные минуты.
7.13. Основные формы программы
Ввиду большего количества форм в программе в данном раз-
деле будут приведены только основные формы программы, которые
позволят понять логику ее работы.
7.13.1. Форма ввода объектов экономики
Форма ввода объектов экономики (Рис 7.7) позволяет произ-
водить вставку, редактирование и удаление информации по текуще-
му объекту. Комбинированные списки позволяют просматривать и
вставлять значения из таблиц-словарей. Кнопки с тремя точками вы-
зывают соответствующие формы редактирования таблиц-словарей.
Кнопки: «Формирования», «Защитные сооружения» и т.д, находя-
щиеся в нижней части меню позволяют вывести дополнительную
информацию по текущему объекту.
Контрольный элемент «Головной объект» позволяет (в отклю-
ченном состоянии) выбрать головной объект из выпадающего спи-
ска головных объектов.
Рисунок 7.7. Форма ввода объектов экономики
В качестве примера дополнительной информации по объекту
(на рис 7.6 смотри выше) показана форма ввода формирований на
текущем объекте. Аналогично построена форма ввода защитных
сооружений, техники, химических веществ.
Кнопка «Материалы» выводит форму по выбору интересую-
щей службы, далее после выбора службы вызывается форма ввода
материально-технических средств данной службы на данном объек-
те (Рис 7.8).
Рисунок 7.8. Материально-технические средства на объекте
Кнопка «Обучаемые» выводит форму о обучаемых в УМЦ на
текущем объекте.
7.13.2. Форма ввода учащихся в УМЦ
Данная форма ведет таблицу обучаемых на УМЦ (Рис 7.9).
Поля «прошлая дата обучения» и «следующая дата обучения» связа-
ны интервалом в три года, т.е. если поле «следующая дата» пустое, а
в поле «прошлая дата обучения» вводится новое число, то происхо-
дит автоматическая корректировка поля «следующая дата».
Для удобства ввода даты создана форма «Выбор даты»
(Рис7.10). Правые верхние кнопки отвечают за выбор месяца, а ле-
вые верхние кнопки отвечают за выбор года.
Рисунок 7.9. Обучаемые на УМЦ
В форме выбора категории обучаемых существует возмож-
ность ввода тем обучения для данной категории с указанием време-
ни обучения. Категории обучаемых подразделяются на две группы:
командиры формирований и другие, соответственно в главной фор-
ме по вводу обучаемых есть флажок «признак категории».
Рисунок 7.10 Выбор даты
7.13.3. Форма отчетов (управления)
Одна из самых главных форм - эта форма отчетов, которая
позволяет выбрать любые данные, практически по любым критери-
ям, из базы данных. (Рис 7.11).
Рисунок 7.11. Форма отчетов программы
Данная форма состоит из двух основных элементов: дерева
отчетов и сетки вывода запроса. Для удобства поиска данных преду-
смотрен выпадающий список «Поле» который ограничивает запрос
выбранным параметром. Так же предусмотрена сортировка по лю-
бым полям таблицы. Данные два поля позволяют создавать с помо-
щью одного запроса комбинацию запросов по выбранным критери-
ям.
В виду того, что не всегда можно предугадать нужные запро-
сы пользователя в форме «отчеты» можно вызвать редактор SQL за-
проса, который позволяет ввести любой запрос в буфер SQL (в бу-
фер можно ввести файл c готовым SQL , так же набранный SQL из
буфера можно сохранить в файл) . Алгоритм работы с формой отче-
тов представлен соответствующих четырех плакатах.
В случае если SQL запрос содержит выборку в каком-либо
временном промежутке, то автоматически подключаются второсте-
пенные органы управления по работе с датами (Рис 7.12)
Рисунок 7.12. Форма отчетов программы (работа с запросами
содержащими даты).
Одна из особенностей этой формы: если запрос связан с объ-
ектами, то двойной щелчок по сетке приводи полную информацию о
текущем объекте. Такая же особенность и с обучающимся на УМЦ.
Кнопка «Excel» позволяет вызвать форму экспорта данных в
Excel. На рисунке 7.13. показан экспорт данных в Excel.
7.14. Экспорт в Excel
Существует множество способов и программ, которые позво-
ляют создавать отчетные документы. Но, как правило, отчеты полу-
ченные стандартными способами или специальными программами
не позволяют гибко менять структуру отчета , а тем более редакти-
ровать его. При решении проблемы с отчетными документами был
выбран стандартный табличный - процессор Excel, как наиболее
гибкая программа для работы с отчетными документами. Excel не
имеет никаких стандартных функций для взаимодействия Delphi-
приложениями. Единственная возможность к доступу ячейкам Excel
и к его командам это использование DDE Windows.
Рисунок 7.13 Экспорт отчета в Excel
Динамический обмен данными (DDE) обеспечивает коммуни-
кационную основу для программ Windows, которая позволяет от-
крыть диалог между приложениями клиента и сервера. Диалог DDE
- это связь между взаимодействующими программами, которая ини-
циируется, а затем закрывается. Для того чтобы DDE-диалог мог
происходить, обе программы должны быть запущены.
Программа, которая инициирует диалог и получает содейст-
вие другой программы, называется клиентом. Программа, которая
обеспечивает содействие клиенту, называется сервером.
DDE-взаимодействие имеет темы (Topics), или категории, ко-
торые полностью зависят от приложения. Наиболее распространен-
ный пример темы это имя файла. Другие темы могут включать по-
нятие system, которое используют приложения Microsoft, когда
нужно запросить через DDE информацию относительно того, какие
форматы Clipbord поддерживаются. В данном случае Topic исполь-
зуется для доступа к листу Excel.
Данные, которые во время диалога перемещаются туда и об-
ратно, называются элементом (item). В данном случае элемент явля-
ется спецификация рядов/колонок диапазона листа Excel.
Примечание: Из руководства по пользованию DDE: К сожалению, нет никакой
систематической возможности найти, какие темы поддерживает приложение. Ваше приложение
должно знать заранее, какие темы поддерживает приложение-сервер.
Исходя из прочитанной литературы в электронных сетях были
установлены основные команды по работе с Excel:
FORMAT(«строка», «r ») - вывод строки в ячейку.
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.
Для правильного выполнения сетевого графика должно вы-
полняться следующее условие : вероятность совершения события в
заданный срок Р (Ткр<Тд) должна удовлетворять следующему соот-
ношению : 0.35 < Р(Ткр<Тд) < 0.65
Из анализа сетевого графика и из таблицы значений парамет-
ров сетевого графика видно, что Ткр<Тд,, так как Ткр = 42 дней, а
Тд=44 дней. Так как условие правильного выполнения сетевого гра-
фика выполняется, то нет необходимости принимать меры по уп-
лотнению графика работ. Следовательно, сетевой график составлен
правильно.
Таблица 8.1. Перечень событий и работ
№
событ
ия
Содержание события
код
ра-
боты
Содержание работы
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Получено задание на
разработку
Утверждено задание
Обобщенный анализ
проведен
Техническое предло-
жение утверждено
База данных и язык
программирования
выбраны
База данных установ-
лена
Физическая база дан-
ных настроена
Связь базы данных с
Delphi установлена
SQL запросы и таб-
лицы баз данных
спроектированы
Взаимосвязь между
таблицами установле-
на
Алгоритм вывода
форм и отчетов и
взаимодействия со-
ставлены
Программа форм и
документация по про-
грамме составлены
Программа отчетов и
документация по про-
грамме составлены
Управляющая про-
грамма с документа-
цией составлена
Модули программы
объединены
Программа форм от-
лажена, документация
скорректирована
Программа отчетов
отлажена, документа-
ция скорректирована
Управляющая про-
грамма отлажена, до-
кументация скоррек-
тирована
Главная программа
отлажена
Программа установки
написана
Документация состав-
лена
Тестирование прове-
дено
Корректировка прове-
дена
Работа завершена
0-1
1-2
2-3
3-4
4-5
4-8
5-6
6-7
8-9
9-10
10-11
10-12
10-13
13-14
14-15
14-16
14-17
17-18
18-19
18-20
18-21
21-22
22-23
Согласование и утвержде-
ние задания
Сбор информации по теме
исследования (изучение ли-
тературы и исходных дан-
ных)
Составление и согласование
технического предложения
Выбор базы данных и языка
программирования
Установка базы данных
Разработка таблиц базы
данных и SQL запросов
Настройка физической базы
данных
Установка связи базы дан-
ных с Delphi
Установка взаимосвязи ме-
жду таблицами (индексы,
ограничения, триггеры)
Разработка алгоритма вы-
вода форм и отчетов и
взаимодействия форм и от-
четов
Разработка программы
форм и составление доку-
ментации
Разработка программы от-
четов и составление доку-
ментации
Разработка управляющей
программы и составление
документации
Объединение модулей про-
грамм в единый блок
Отладка программы форм
Отладка программы отчетов
Отладка управляющей про-
граммы
Отладка всей главной про-
граммы
Написание программы ус-
тановки и составление до-
кументации к ней
Составление руководства
пользователя и другой про-
граммной документации
Тестирование и составление
отчета по тестированию
Корректировка документа-
ции и программы
Компоновка программы и
тиражирование
Таблица 8.2. Результаты расчета параметров сетевого графика
Код рабо-
ты
tож
Ранний
срок
Поздний срок
Резервы времени
рабоч.
Начала
работы
Tрнij
оконча
ния ра-
боты
Tроij
начала
ра-
боты
Tпнij
окончания
работы
Tпоij
полный
Rпij
свобод
ный
Rсij
0-1
1-2
2-3
3-4
4-5
4-8
5-6
6-7
8-9
9-10
10-11
10-12
10-13
13-14
14-15
14-16
14-17
17-18
18-19
18-20
18-21
21-22
22-23
4
3
2
1
1
5
1
2
1
2
6
5
7
5
4
2
3
2
3
2
1
2
1
0
4
7
9
10
10
11
12
15
16
18
18
18
25
30
30
30
34
36
36
36
39
41
4
7
9
10
11
15
12
14
16
18
24
23
25
30
34
32
33
36
39
38
37
41
42
0
4
7
9
11
10
12
13
15
16
19
20
18
25
30
32
31
34
36
37
38
39
41
4
7
9
10
12
15
13
15
16
18
25
25
25
30
34
34
34
36
39
39
39
41
41
0
0
0
0
1
0
1
1
0
0
1
2
0
0
0
2
1
0
0
1
2
0
0
0
0
0
0
0
0
0
1
0
0
1
2
0
0
0
2
1
0
0
1
2
0
0
Рисунок 8.1.
8.4. Оценка издержек на разработку программы.
Подобный программный продукт может быть реализован
в единичном экземпляре либо тиражирован и реализован
некоторому числу спец. заказчиков. Обычно принято прово-
дить расчет экономической эффективности использования
разработки для ее потребителя.
Важным фактором, влияющим на процесс формирования цены,
является конкуренция на рынке, необходимость учета которой со-
вершенно очевидна. В целях повышения конкурентоспособности
продукта может возникнуть необходимость снижения его цены на
рынке. Важно заметить, однако, что целям повышения конкуренто-
способности служит не только снижение цены, но, также, и качество
товара и его выгодные отличительные признаки по сравнению с
аналогичным товаром конкурентов.
Наиболее важным моментом для разработчика, с эконо-
мической точки зрения, является процесс формирования це-
ны. Очевидно, что программные продукты представляют со-
бой весьма специфичный товар с множеством присущих
им особенностей. Многие их особенности проявляются и в
методах расчетов цены на них. На разработку программного
продукта средней сложности обычно требуются весьма не-
значительные средства. Однако, при этом она может дать
экономический эффект, значительно превышающий эффект от
использования достаточно дорогостоящих систем.
Следует подчеркнуть, что у программных продуктов
практически отсутствует процесс физического старения и
износа. Для них основные затраты приходятся на разработ-
ку образца, тогда как процесс тиражирования представляет
собой, обычно, сравнительно несложную и недорогую про-
цедуру копирования магнитных носителей и сопровождающей
документации. Таким образом, этот товар не обладает, по
сути, рыночной стоимостью, формируемой на базе общест-
венно необходимых затрат труда.
Цена на программные продукты устанавливается на
единицу программной продукции с учетом комплексности ее
поставки. Ее цена, обычно, формируется на базе норматив-
ной себестоимости производства и прибыли:
Цп = С + П, где
С — себестоимость единицы продукции, руб.;
П — прибыль, руб.;
Маркетинговые исследования показали, что на рынке нет по-
добных программ в виду их специализации и узкой направленности.
Данная программа предназначена для внутреннего использо-
вания и делается в рамках проекта создания системы оповещения.
8.4.1. Статья I. Оплата труда
Весь процесс создания программных средств может быть раз-
делен на несколько независимых фаз или этапов. Конкретное число
таких этапов и их содержание определяется целями и масштабами
конкретных проектов и разработок. Этапы характерные для разра-
ботки крупных программных продуктов следующие:
1. Анализ требований, предъявляемых к программному изделию;
2. Определение спецификаций;
3. Проектирование изделия;
4. Кодирование;
5. Тестирование и отладка.
Примерное распределение временных затрат на реализацию от-
дельных этапов цикла разработки показано на диаграмме 1.
Диаграмма 8.1. Временные затраты на реализацию цикла раз-
работки программного обеспечения
При организации разработки программного обеспечения необхо-
димо определить сколько времени и затрат труда потребуется на
реализацию проекта.
Статья I включает заработную плату основных инженеров-
программистов. Определение норм времени на операции, и заработ-
ная плата приведена в таблице (8.3).
Таблица 8.3 Заработная плата
№
Наименование
Исполнитель
Трудоемкост
ь
Оклад
Сумма
этапа
ч/дн
ч/мс
тыс.руб./
м
тыс.руб./
м
1
Техническое
задание
Главный
конструктор
2
0.09
800
72
2
Подготовитель
ный
этап
Программист
1 категории
10
0.45
600
270
3
Рабочее
проектировани
е
Программист
1 категории
Программист
2 категории
20
35
0.90
1.58
600
500
540
790
4
Отладка и
тестирование
Программист
1 категории
10
0.45
600
270
5
Технический
отчет
Программист
1 категории
Программист
2 категории
7
5
0.31
0.22
600
500
186
110
6
Сдача темы
Главный
конструктор
2
0.09
800
72
Итого : 2310000 руб.
Размер дополнительной заработной платы составляет 15% от
размера основной, что, в данном случае, будет равно 346500 рублей.
Ст.I =Основная + Дополнительная =2310000+346500=2656500 руб.
8.4.2. Статья II. Материальные ресурсы
Статья II включает стоимость всех видов сырья и материалов,
расходуемых на изготовление продукции, а также транспортно заго-
товительные расходы.
Расчет сырья и материалов приведен в таблице (8.4).
Таблица 8.4 Расчет сырья и материалов
Наименование
Ед. Измере-
ния
Цена,
руб.
Норма
расходов,
шт.
Стоимость
,
руб.
База данных Oracle
v 7.2
шт.
25000000
1
25000000
Язык программиро-
вания
Delphi v 3.0
шт.
6000000
1
6000000
Итого:
31000000
OC?=
OC?=31000000*1%/100%=310000 ?oa.
No.II= +0.1N
o.1
No.II=31000000+310000+265650=31395650 ?oa.
8.4.3. Статья III. Отчисления на социальные нужды
Noaouy III aee??aao a naay io?eneaiey a iaineiiiue oiia
(28%), oiia caiyoinoe (1.5 %), iaaeoeineia no?aoiaaiea (3.6 %),
nioeaeuiia no?aoiaaiea (5.4 %), a oiia ia?aciaaiey (1 %) e o?ainii?oiue
iaeia (1 %).
Anaai 40,5 % io ia?eneaiiie ca?aaioiie ieaou.
No.3=
No.3= = 1075883 ?oa.
8.4.4. Статья IV. Накладные расходы
Noaouy IV aee??aao a naay ?anoiau ia ca?ieaoo aniiiiaaoaeuiui
?aai?ei, iaeaa?eeai, iaoaieeai, noieiinou caianiuo ?anoae, aniiiiaaoaeuiuo
n?aanoa e aii?oecaoe?. 250% io No.1
No.4=2.5*No.1
No.4= 2.5*2656500=6641250 ?oa.
1.4.5. Cao?aou
Iie.Naa.=
Iie.Naa.=2656500+31395650+1075883+6641250 =41769283?oa.
Итого : 41'769'283 руб.
8.5. Цена программного продукта
Пусть в течение некоторого периода времени Т исход-
ные условия остаются неизменными, программный продукт
тиражируется в n=10 экземплярах, затраты на разработку
составляют С, прибыль от использования программного про-
дукта — П = 0.2*C. Тогда цена одного экземпляра тиражируе-
мого продукта равна:
Цп = С/n + П/n + р1 + П1, где
р1 — затраты на копирование, сопровождение и марке-
тинг;
П1 — величина прибыли от реализации одного экземпля-
ра тиража.
Здесь имеется ввиду, что цена на разработку устанав-
ливается исходя из себестоимости и составляет С + П.
Слагаемые (р1 + П1) иногда связывают с ценой одной
адаптации данной программного продукта.
Цп = 41769283/10 +41769283*0.2/10 + 500000=5'512'314 руб.
8.6. Анализ эффективности внедрения программы
Эффективность внедрения программы заключается в том, что
с помощью программы по управлению базой данных объектов эко-
номики можно оперативно собрать все необходимые данные об
объектах экономики округа или города в чрезвычайной ситуации и
тем самым сократить время на сбор информации, которая так необ-
ходима в первые минуты ЧС, когда каждая минута промедления
может стоить жизни людей.
Благодаря тому, что программа написана под операционную
систему Windows 95/NT и соответственно имеет интуитивно понят-
ный программный интерфейс, существенно упрощается процесс
обучения и работы.
Данная база данных и программа по управлению базой дан-
ных
имеет хорошую возможность к масштабированию и расширению.
Путем несущественных изменений программа может работать прак-
тически с любой реляционной базой данных.
Основное преимущество данной программы заключается в
том, что она может работать в локальной вычислительной сети и
тем самым позволяет работать с базой данных множеству пользова-
телей.
Отличие от других аналогичных продуктов состоит в том, что
эта программа поддерживает базы данных построенные на кли-
ент/серверном вычислении. Благодаря этому под сервер выбирается
мощный компьютер (мощный процессор, большой объем памяти),
позволяющий хранить централизованно большой объем данных и
адекватно обрабатывать множество одновременных запросов клиен-
тов. А для выполнения клиентских приложений используются менее
дорогие компьютеры с минимальным объемом памяти. Этот способ
доступа данных обеспечит возможность одновременного использо-
вания информации сразу несколькими пользователями системы. Со-
ответственно резко снижается время на получения результатов и
также снижается стоимость оборудования поддерживающего эту
систему.
Экономия от замены ручной обработки информации на авто-
матизированную образуется в результате снижения затрат на обра-
ботку информации.
Зт = Зр - За,
где Зр - затраты на ручную обработку информации
За - затраты на автоматизированную обработку информации.
Зр = к*(V*Ц)/Нв,
где V - Объем информации, обрабатываемой вручную Mb.
Ц - стоимость одного часа работы.
Нв -норма выработки.
к- коэффициент ,учитывающий дополнительные затраты време-
ни на логические операции при ручной обработке информации.
Зр = 1.1*(100*1000)/0.1=1100000 Руб.
Затраты на автоматизированную обработку информации:
За = ta*Ца +З1 ,
где ta - время автоматизированной обработки
Ца -стоимость одного часа машинного времени
З1 -трудозатраты пользователя
За = 0.3*100000 + 100000 = 400000 руб
Зт = 1100000-400000=700 000 руб
При использовании же старых методов хранения данных
практически не возможно производить поиск по заданным критери-
ям, а тем более сортировку данных (ввиду большого количества са-
мих данных) и оперативно выдать результат.
Так же необходимо держать довольно-таки большой штат
служащих, которые занимались бы поиском нужной информации.
При старом способе хранения данных была бы проблема цен-
трализации данных и доступа к ним.
Также, благодаря дружественному интерфейсу программы,
повысится удобство работы и, соответственно, производительность
труда оператора ЭВМ.
9. МЕРОПРИЯТИЯ, ОБЕСПЕЧИВАЮЩИЕ ОПТИМАЛЬНЫЕ
УСЛОВИЯ ТРУДА ПОЛЬЗОВАТЕЛЯ НА РАБОЧЕМ МЕСТЕ
9.1. Специфика дипломного проекта
Данный дипломный проект посвящен разработке и работе ба-
зы данных с интерфейсом пользователя в рамках создания про-
грамм на языке Delphi под Windows 95/NT для работы с произволь-
ными базами данных на основе персонального компьютера типа
IBM PC AT, предназначенного для проектирования вычислительных
систем.
При разработке программного интерфейса пользователя
ПЭВМ обладает определенными недостатками, а именно: при кон-
струировании интерфейса, при работе с базами данных програм-
мист испытывает значительную нагрузку на глаза, что приводит к
снижению его трудоспособности к концу рабочего дня.
9.2. Обзор вредных особенностей работы, встречающихся при
изготовлении, наладке и эксплуатации программ
9.3.1. Работа с монитором
Электронно-лучевая трубка (ЭЛТ) - это электронная пушка.
Это означает, что ЭЛТ заряжена отрицательно, а, следовательно, вне
ЭЛТ происходит накопление положительно заряженных частиц.
Человек чувствует себя хорошо, когда в окружающей его среде
соотношение положительных и отрицательных ионов почти одина-
ково. Однако перед экраном монитора образуется избыток поло-
жительных ионов. Всегда имеющиеся в воздухе офиса микрочасти-
цы (пыль, дым табака, и т.д.), разгоняются потоком положительно
заряженных ионов и оседают на лице и глазах оператора, сидящего
перед экраном. В результате такой "бомбардировки" у оператора
могут возникать:
- головная боль, бессонница;
- раздражение кожи;
- усталость глаз;
9.3.2. Кресло
Проведенные исследования выявили связь между работой на
компьютере и такими недомоганиями, как астенопия, боли в спине и
шее, запястный синдром. Все выше перечисленные болезни прямо
или косвенно вызваны неправильной посадкой человека перед ком-
пьютером. Форма спинки кресла должна повторять форму вашей
спины. Кресло надо установить на такой высоте, чтобы вы не чувст-
вовали давления на копчик (кресло расположено слишком низко)
или на бедра (кресло расположено слишком высоко). Специалисты
по эргономике считали, что угол между бедрами и позвоночником
должен составлять 90 градусов, однако недавно проведенные ис-
следования показали, что большинство людей предпочитают сидеть
несколько откинувшись.
9.3.3. Клавиатура
Неправильно расположенная клавиатура стимулирует разви-
тие запястного синдрома - болезненного поражения срединного
нерва запястья.
9.3.4. Эффекты отражения и рабочий стол.
Светло окрашенная мебель офиса и большие окна являются
дополнительными источниками света. В очень светлом помещении
плохо видны буквы и цифры на экране монитора. Это вызывает
головную боль, ухудшение зрения, снижения концентрации, а также
приводит к ошибкам в работе из-за некорректного восприятия ин-
формации.
9.3.5. Оригиналодержатель
Часто приходится набивать тексты с листа бумаги, не имея
возможности вводить информацию со сканера. Правильно распо-
ложенный лист бумаги, с которого производится ввод текста,
обезопасит оператора от искажения зрения.
На рабочем месте инженер-системотехник также подверга-
ется воздействию факторов:
- шумы от работающих машин;
- выделение избытков теплоты.
9.3.6. Шумы
Повышенный уровень шума вызывает трудности в распозна-
вании цветовых сигналов, снижает быстроту восприятия цветовых
сигналов, снижает быстроту восприятия цвета, остроту зрения,
зрительную адаптацию, нарушает восприятие визуальной информа-
ции, снижает способность быстро и четко выполнять координиро-
ванные действия, уменьшает на 5-10% производительность труда.
Длительное воздействие повышенного уровня шума с уровнем
звукового давления 90 Дб снижает производительность труда на
30-60%. Медицинские обследования инженеров-программистов
показали, что помимо снижения производительности труда высо-
кие уровни шума при местном действии приводят к утомлению,
ухудшению слуха и тугоухости. Кроме того, при общем действии
повышенный уровень шума вызывает нарушение ритма сердечной
деятельности, изменение кровяного давления, ухудшение органов
дыхания. Источниками шума в помещении являются печатающие
устройства.
9.3.7. Выделение избытков теплоты
Повышенная температура внешней среды приводит к быст-
рому утомлению, снижает быстроту восприятия зрительной и слу-
ховой информации, общей заторможенности человека вследствии
нарушения сердечной деятельности (увеличение быстроты биения
сердца), изменения кровяного давления.
Многие программисты связанны с воздействием таких психо-
физических факторов, как умственное перенапряжение, пере-
напряжение зрительных и слуховых аппаратов, монотонность тру-
да, эмоциональные перегрузки. Воздействие указанных неблагоп-
риятных факторов приводит к снижению работоспособности, вызы-
ваемое развивающимся утомлением. Появление и развитие утомле-
ния связано с изменениями, возникающими в процессе работы
центральной нервной системе, с тормозными процессами в коре
головного мозга.
9.4. Анализ категории тяжести труда инженера-программиста.
К настоящему времени разработаны и утверждены стандарты
на уменьшение информационной нагрузки человека при работе с
компьютером - ГОСТ 12.2.032-78 (введ. 01.01.79).В данных прави-
лах записано, что очень часто используемые средства отображения
информации, требующие точного и быстрого считывания показа-
ний, следует располагать в вертикальной плоскости под углом +15o
от нормальной линии взгляда, идущей на 15o ниже горизонтальной
линии взгляда, и в горизонтальной плоскости под углом +15o от са-
гитальной плоскости.
Часто используемые средства отображения информации, тре-
бующие менее точного и быстрого считывания показаний, следует
располагать в вертикальной плоскости под углом +30o от нормаль-
ной линии взгляда и в горизонтальной плоскости под углом +30o от
сагитальной плоскости.
В залах и кабинетах рабочие места операторов необходимо
располагать в зоне наилучшего видения информационного поля,
которое должно обеспечить однозначное восприятие знаковой ин-
дикации.
Немаловажную роль в работе с программой и утомляемости
является выбранное сочетание цветов фона и знаков.
Московским НИИ гигиены им. Ф.Ф.Эрисмана, проводились
исследования на определение оптимальных сочетаний цветов фо-
на и знаков. Функциональное состояние зрительного анализатора
исследовалось методом определения критической частоты слияния
световых мельканий (КЧССМ) с последующим вычислением коэф-
фициента утомляемости по С.Л.Шаповалову. Опрос проводился до
и после работы на ПЭВМ "Ямаха". Результаты исследований про-
ведены в таблице 9.1.
Таблица 9.1. Результаты исследований
Сочетание
Оценка %
№
цветов
Состояние зрительного анали-
затора
Общее самочувст-
вие
экрана
Глаза
Глаза устали
Немного
Не
и знаков
не уста-
ли
средне
немного
устали
устали
1.
Темно-зеленый фон и
белые знаки
100
-
-
-
100
2.
Темно-зеленый фон и
светло-зеленые знаки
40
-
60
-
100
3.
Черный фон и белые
знаки
57
14
29
-
100
4.
Черный фон и зеле-
ные знаки
50
-
50
-
100
5.
Синий фон и белые
знаки
32
25
43
13
87
6.
Белый фон и черные
знаки
14
43
43
-
100
Наихудшим сочетанием цветов оказался белый фон и черные
знаки, а наилучшим темно-зеленый фон и белые знаки.
При проектировании электронной формы необходимо обра-
тить внимание на следующие факторы, влияющие на информаци-
онную нагрузку человека:
- Выбор цветовой индикации (реакция программы на
ошибки пользователя)
- Угловые размеры символов. Определяются по формуле:
b h a H
tg--- = ---- ; tg--- = ---- ;
2 2L 2 2L
где
a - угол обзора экрана
b - угловые размеры знака
L - расстояние наблюдения
H - высота экрана
h - высота знака
Для знаковой и буквенно-цифровой информации, отображае-
мой на ЭЛТ, рекомендуются размеры: высота знака h 3,5 мм при L
= 0,6 - 0,7 м; ширина знака 0,75 h; межзнаковое расстояние - (0,5-
0,3)h; межстрочное расстояние 0,75h.
Факторы, окружающие инженера-программиста, на рабочем
месте:
1. Напряжение зрения
2. Напряжение внимания
3. Нервно-эмоциональное напряжение
4. Интеллектуальное напряжение
5. Рабочее место, рабочая поза
6. Сменность
7. Продолжительность работы
8. Температура воздуха на рабочем месте
Расчет интегрального показателя условий труда по методу
арифметического усреднения баллов биологически значимых пока-
зателей заключается в следующем. На основании краткой характе-
ристики технологического процесса или вида трудовой деятельно-
сти составляется карта условий труда на рабочем месте (табл.9.2.),
где каждый из факторов получает оценку в баллах.
Таблица 9.2. Карта условий труда на рабочем месте
№
Показатели условий
труда.
Оценка
показателей
Длительность
воздействия
Балл с
учетом
Единицы измерения.
Абс.
Балл
мин
доля
смен
ы
экспозиц
ии.
А. Психофизиологические нагрузки
1
Напряжение зрения :
освещенность РМ, лк
400
2
480
1
2
размеры объекта, мм
1
1
480
1
1
разряд зрительной работы
3-4
2
480
1
2
энтропия зрительной ин-
формации, бит/сигнал
8
1
480
1
1
число информационных
сигналов в час
< 75
1
480
1
1
2
Напряжение слуха :
уровень шума, дБ
< ПДУ
1
480
1
1
соотношение сигнал/шум,
%
70
2
480
1
2
энтропия слуховой инфор-
мации, бит/сигнал
8
1
480
1
1
3
Напряжение внимания :
длительность сосредоточе-
ния внимания, % времени
смены
< 25
1
480
1
1
число важных объектов на-
блюдения
< 5
1
480
1
1
- число движений пальцев в
час
< 360
1
480
1
1
4
Напряжение памяти :
необходимость помнить об
элементах работы
свыше 2-х ч., число эл.
1
2
480
1
2
поиск рассогласований в %
от числа регулируемых па-
раметров
30
2
480
1
2
5
Нервно-эмоциональное на-
пряжение. Экспертная
оценка.
1
1
480
1
1
6
Интеллектуальное напря-
жение. Экспертная оценка.
1
1
480
1
1
7
Статическая нагрузка в
течение смены, кгс*сек :
на одну руку
<
18000
1
480
1
1
- на обе руки
<
43000
1
480
1
1
- на весь корпус
<
61000
1
480
1
1
8
Рабочее место, поза, пере-
мещение в пространстве.
Экспертная оценка.
Поза
свобод
-ная
1
480
1
1
9
Сменность
одна
1
480
1
1
10
Продолжительность работы
в течение суток, ч
8
2
480
1
2
11
Монотонность :
число приемов в операции
10-6
2
480
1
2
длительность повтора опе-
рации, с
-
1
480
1
1
12
Режим труда и отдыха
обосно
ванны
й
гимнас
тика
1
480
1
1
Б. Санитарно-гигиенические условия
13
Температура воздуха на
рабочем месте, С :
теплый период
23-28
3
480
1
3
- холодный период
15-16
3
480
1
3
14
Промышленная пыль,
кратность превышения
ПДК
ПДК
2
480
1
2
15
Ультразвук в воздухе ПДУ
+ превышение, дБ,
< ПДУ
1
480
1
1
16
Тепловое излучение, Вт/см
0
0
480
1
0
17
Ионизирующие излучения,
мр/ч
<ПДУ
1
480
1
1
В. Оценка условий труда
18
Число факторов, форми-
рующих тяжесть труда, n
28
Сумма баллов
40
Усредненный балл
1.4
Рассчитаем интегральную оценку категории тяжести труда
инженера-программиста по формуле :
k =19.7*k - 1.6* k2 ,
где k - усредненный коэффициент, вычисляемый по формуле :
k = 1/n*k ,
где k - баллы рассматриваемых факторов,
n - число факторов.
k =1.4
k = 19.7*1.4-1.6*1.96 =24.444 (балл*10)
Зная величину k, из таблицы находим категорию тяжести труда.
Следовательно, на рабочем месте на человека воздействуют факто-
ры, категория тяжести труда которых равна 2. Для этой категории
тяжести труда характерны: допустимые условия труда, высокая ра-
ботоспособность, отсутствуют функциональные сдвиги по медицин-
ским показателям.
9.5. Анализ освещения на рабочем месте программиста.
Усталость программиста прямо зависит от степени напряжен-
ности процессов сопровождающих зрительное восприятие. Это та-
кие процессы как адаптация, аккомодация и конвергенция.
Адаптация - приспособление глаза к изменению освещения.
Аккомодация - приспособляемость глаза к изменению рас-
стояния.
Конвергенция - свойство глаз сосредотачивать зрение на
предмете.
Всю энергию, излучаемую источниками света, можно разде-
лить на ультрафиолет, видимый свет и инфракрасное излучение.
Часть энергии, воспринимаемая глазом как свет, называется свето-
вым потоком F [люмен]. Сила света (I)-определяется как простран-
ственная плотность светового потока, т.е. отношение светового по-
тока к телесному углу, в котором равномерно распространяется
этот световой поток. Измеряется сила света в канделлах ([Кд]=[лм]
/[срад]). Освещенность (E) - поверхностная плотность светового по-
тока, люкс [лк]:
F
E = --- ,
S
где S - площадь [м ] .
Коэффициент пульсации освещенности (Кп) - имеет значение
при питании ламп переменным током.
Eмах - Емin
Кп = ------------ 100% ,
2 Еср
Искусственное освещение производственных помещений бы-
вает:
- общее;
- комбинированное;
- аварийное.
Помимо искусственного в помещении имеется также естест-
венное освещение из окон. Таким образом, освещение смешанное.
Рассмотрим все перечисленные типы искусственного осве-
щения помещений. Система общего освещения предназначена не
только для освещения рабочих поверхностей, но и для всего поме-
щения в целом. Система комбинированного освещения состоит из
общего и местного освещения: светильники местного освещения
создают большую освещенность на рабочей поверхности, а обще-
го выравнивают яркость в поле зрения. Использование одного ме-
стного освещения не допускается из-за резкого контраста в ярко-
стях. Система аварийного освещения предусматривается в случаях,
когда недопустимы перерывы в рабочем цикле. Для расчета ос-
вещения рабочей поверхности будем пользоваться методом коэф-
фициента использования светового потока.
Коэффициент использования светового потока зависит от
типа светильника, расчетной высоты подвеса светильника над ра-
бочей поверхностью, от размера помещения, коэффициентов отра-
жения потолка и стен. Определим потребное количество светильни-
ков для рассматриваемого помещения .
Краткая характеристика помещения :
- высота потолка H = 3,9 м.
- коэффициент отражения потолка Rп = 70 %
- коэффициент отражения стен Rс = 50 %
- высота рабочей поверхности h = 0,9 м.
- помещение прямоугольной формы, имеющее следующие
размеры
ширина помещения А = 7 м.
длина помещения B = 8 м.
Необходимое количество светильников будем располагать ря-
дами с соответствием с наивыгоднейшим соотношением
L
Л = ---------- = 1,7
( H-h )
где L - расстояние между рядами светильников , [ м ]
H-h - высота подвеса , [ м ]
Для большинства применяемых типов светильников Л=1,5...2,0
==> 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(al
f)));
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.13
4
39.06
8
46.19
6
52.813
4
14.219
19.84
6
24.39
3
28.39
6
32.057
5
10.51
14.37
7
17.43
2
20.08
2
22.478
6
8.31
11.21
1
13.46
5
15.39
8
17.13
7
6.861
9.164
10.93
1
12.43
2
13.769
8
5.839
7.740
9.184
10.40
2
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 Ro-
man.
14. Использование всплывающих подсказок предоставляет пользова-
телю великолепную возможность узнать, что делает данный эле-
мент, не щелкая на нем (это особенно важно для кнопок панели
управления.). Всплывающие подсказки представляют собой ма-
ленькие всплывающие метки, которые отображаются, когда кур-
сор мыши останавливается над определенными значащими эле-
ментами экрана.
15. Включение интерактивной справки. Профессиональные прило-
жения Windows содержат полную справочную базу данных, кото-
рая включает связи между родственными темами. Следует осна-
щать свои формы контекстно-чувствительной справкой. Это мож-
но сделать с помощью свойства HelpContext формы и ее управ-
ляющих элементов. Когда будет затребована справка по элементу
формы, обладающему фокусом ввода, управление справкой Win-
dows автоматически будет передано соответствующей теме вашей
справочной базы данных.
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, ?oiau ioia?a?aou поля описатель-
ного типа, не прибегая к таким насыщенным компонентам, как
список или комбинированный список.
5. Не следует включать в приложение функций, которыми пользова-
тель не сможет воспользоваться. Необходимо избегать серых
(недоступных) команд меню и запрещенных кнопок, присутствие
которых может вызвать недоумение. Если какая-нибудь опция не-
доступна для данного пользователя, устанавливают ее свойство
Visible равным False, что сделает ее невидимой (или совсем уб-
рать ее) вместо того, чтобы просто запретить.
11.4. Интерактивные формы.
Интерактивные формы чаще всего встречаются в приложени-
ях. Они предоставляют средства ввода, редактирования и удаления
данных. Типичный пользователь таких форм, как правило, обладает
высокой компьютерной грамотностью. Интерактивная форма долж-
на быть максимально простой и благоприятной для эффективной
навигации между данными и манипулирования ими.
1. Желательно рассмотреть возможность увеличения и замены кно-
пок навигатора Dilphi стандартными кнопками. Несмотря на мощ-
ность и простоту применения, управляющим элементам DBNavi-
gator недостает таких свойств, как средства поиска и возможность
присваивать клавиши ускоренного доступа или метки их встроен-
ным кнопкам.
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. Используют для проектирования отчетов компоненты QuickRe-
port. Их легче настраивать и использовать, чем внешние построи-
тели отчетов.
2. Для отчетов, которые слишком сложны для компонентов Quick-
Report, используют графические построители отчетов. Особой
популярностью пользуются утилиты ReportSmith, R&R SQL Re-
port 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.
?ac?aaioaiiue i?ia?aiiiue i?iaoeo iaiaoiaeii i?aanoaaeou a aeaa
eniieiyaiuo oaeeia.
П.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;
/
3
дипломный проект
| |
