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

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

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

к различным БД, для создания аналитических систем, для создания одиночных и

групповых приложений, критичных по времени выполнения.

Все три средства - JAM, Oracle Power Object и Delphi - пригодны для

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

иметь определенные достоинства.

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

ДАННЫХ

Первоочередной задачей является выбор варианты построения

информационных приложений с использованием СУБД. Из рассмотренных вариантов

системы с архитектурой клиент-сервер наиболее эффективная и дешевая для

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

«свежим» данным. В масштабе предприятия вычисления клиент/сервер —

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

многопользовательской базе данных по нескольким компьютерам (ПК и рабочим

станциям).

Что же дает вычисление клиент/сервер по сравнению с традиционной

однокомпьютерной средой (с одной большой ЭВМ)? При корректной реализации

системы клиент/сервер получается система управления информацией с намного

лучшим отношением «цена/производительность», которую можно наращивать и

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

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

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

обновлении и перекомпилировании каждый раз при небольшом изменении в базе

данных. К плюсам технологии клиент/сервер можно отнести простоту и удобство

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

разработки (особенно при наличии объектно-ориентированных инструментов) и

быстроту решений.

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

надежного хранения больших данных и удобства использования: Oracle,

Informix, Sysbase, Ingres.

Исходя из популярности в России (в ВПК) и на основе проведенного

анализа по литературе в частности [2],[3],[4] и из опыта работы компаний

«Рос.вооружение», НИИ «Восход», «Инком Банк» была выбрана база данных

Oracle.

Вторая задача это выбор операционной системы. На основании выводов

в главе 2.5. и таблицы 2.1 была выбрана Novell Netware 4.11 как основная

система для работы базы данных Oracle. Определяющими параметрами при выборе

были: надежность и стабильность работы, небольшее требование к ресурсам

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

Windows/NT. Ввиду полномасштабного использования компьютеров типа Pentium и

операционной системы Windows 95, а так же удобством разработки,

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

качестве клиентских приложений была выбрана Windows 95.

На основании главы 4.3.2. и таблицы 4.1, а так же прочитанной

литературы [5],[6],[7],[8] и опыта программистов фирм: «Формоза-центр»,

«Инком Банк», «Рос.вооружение» был выбран язык программирования Delphi, как

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

плане перевода локальных баз данных на архитектуру клиент/сервер. Данный

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

современного языка программирования.

Одно направление - объектно-ориентированный подход, хорошо

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

системы.

Другое направление, возникшее во многом благодаря объектной

ориентации, - визуальные средства быстрой разработки приложений (RAD -

Rapid Application Development), основанные на компонентной архитектуре.

Третья тенденция - использование компиляции, а не интерпретации. Это

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

десятки раз лучше, чем у систем, использующих интерпретатор. При этом

повышается легкость отчуждаемости готовых систем, так как отпадает

необходимость "таскать за собой" сам интерпретатор (run-time), выполненный

обычно в виде динамической библиотеки и занимающий в лучшем случае

несколько сотен килобайт (а большинстве случаев - два-три мегабайта).

Отсюда и меньшая ресурсоемкость у скомпилированных систем.

Четвертая тенденция - возможность работы с базами данных

универсальными (единообразными) методами. Если мы попытаемся оценить

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

информации (как для внутрикорпоративного использования, так и для

коммерческого или иного распространения), то окажется, что цифра 60- 70%

может представлять лишь нижнюю границу. Важным свойством средств

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

возможность не только количественного, но и качественного роста системы.

Например, обеспечение перехода от локальных ,в том числе, файл-серверных

данных к архитектуре клиент-сервер или тем более к многоуровневой N-tier

схеме.

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

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

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

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

Delphi использует язык 3-го поколения Object Pascal, обладающий полной

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

наследование, полиморфизм), поддержкой RTTI-RunTime Type Information и

встроенной обработкой исключительных ситуаций (Exception handling).

Компонентная архитектура Delphi является прямым развитием поддерживаемой

объектной модели. Все компоненты являются объектными типами (классами), с

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

PME-модель (Property, Method, Events), позволяющую изменять поведение

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

Компоненты Delphi 2.Delphi 2 Client/Server Suite включает систему

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

(Data Dictionary) и Репозитарием объектов (Object Repository). Среда

визуальной разработки Delphi позволяет единообразно работать как с

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

разрабатываются на том же языке (Object Pascal), на котором создаются и

конечные приложения.

Borland Database Engine (BDE) обеспечивает единообразную работу с

локальными данными (Paradox, dBase) и серверами БД (Oracle, Sybase, MS SQL

Server, InterBase и т.д.), за счет применения навигационных методов доступа

к серверным СУБД (двунаправленные курсоры, закладки и т.п.) и SQL - к

локальным форматам (подмножество Local SQL).

Компилятор Delphi является самым быстрым; имеет общий генератор кода с

Borland C++ (Delphi 2 & BC++ 5). Компилятор Delphi (точнее, Object Pascal)

является продолжением линии компиляторов Turbo Pascal / Borland Pascal.

Открытые интерфейсы Delphi - Open Tools API - обеспечивают контроль

над средой разработки "из вне" и доступ к информации о проекте.

[pic]

Рисунок 7.1. Borland Database Engine

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

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

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

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

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

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

ситуаций при их возникновении.

Гражданская оборона объединяет:

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

экономикой, коммунальным хозяйством; общественные организации, в

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

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

. организации(объекты), независимо от формы собственности и ведомственной

принадлежности.

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

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

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

ликвидации ЧС.

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

1. Создание и поддержание в готовности систем управления, сил и средств,

чрезвычайных резервов финансовых и материальных ресурсов.

2. Организация наблюдения и контроля за состоянием окружающей среды и

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

3. Разработка и осуществление мер направленных на защиту населения,

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

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

4. Совершенствование и обеспечение функционирования системы подготовки

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

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

5. Оповещения населения о возникновении чрезвычайной ситуации и порядке

действий в сложившейся обстановке.

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

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

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

[pic]

Рисунок 6.1. Схема управления по делам ГО и ЧС

Из существующей схемы управления по делам ГО и ЧС видно, что

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

Первоочередной задачей для каждого отдела является оценка

складывающейся обстановки в возникшей ЧС. Соответственно каждому отделу

нужна информация об объекте (наличие опасных веществ, наличие защитных

сооружений, общая численность людей и т.д.) на котором возникла данная ЧС и

информация о близлежащих объектах для возможной эвакуации людей или

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

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

необходимы данные о количестве хранимых веществ на объекте; отделу

технического обеспечения оснащенность ближайших объектов техникой и т.д.

Данный проект позволяет вести необходимую информацию о объектах ГО и

оценить в ЧС складывающеюся обстановку.

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

ОБЪЕКТОВ ГО.

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

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

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

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

обеспечивающего:

. автоматизацию процесса подготовки к принятию решений при возникших ЧС;

. регистрацию объектов экономики и составление списка характеристик

объекта;

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

. техники;

. защитных сооружений;

. химически опасных веществ;

. материально-технических средств;

. формирований на объекте;

. снижение расходов на подготовку и уточнения списков объектов;

. учета готовности объекта к ЧС;

. учета проведения занятий с обучающимися в УМЦ.

. уменьшение времени на подготовку списков объектов экономики и списков

обучающихся на УМЦ по различным критериям;

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

Ведение данных:

. объектов экономики;

. защитных сооружениях;

. опасных веществах;

. техники;

. материально-технических средств;

. формирований;

. обучаемых на УМЦ;

Формирование списков:

. объектов экономики;

. защитных сооружениях;

. опасных веществах;

. техники;

. материально-технических средств;

. формирований;

. обучаемых на УМЦ;

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

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

Рассмотрев определенные выше задачи можно спроектировать основные

таблицы базы данных. Для реализации данных задач потребуются следующие

таблицы:

1. таблица объектов экономики;

2. таблица-словарь территориальной принадлежности объектов;

3. таблица-словарь степени опасности объектов;

4. таблица-словарь характера деятельности в опасный период;

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

6. таблица-словарь формы собственности объектов;

7. таблица-словарь рода деятельности объектов;

8. таблица-словарь гражданских должностей руководителей объектов;

9. таблица-словарь должностей по ГО начальников ГО объектов;

10. таблица опасных веществ на объектах;

11. таблица-словарь опасных веществ;

12. таблица защитных сооружений на объектах;

13. таблица-словарь защитных сооружений;

14. таблица технических средств на объектах;

15. таблица-словарь технических средств;

16. таблица формирований на объектах;

17. таблица-словарь формирований;

18. таблица-словарь степени готовности формирований;

19. таблица-словарь служб ГО;

20. таблица материально-технических средств на объектах;

21. таблица-словарь материально-технических средств;

22. таблица обучаемых на УМЦ;

23. таблица-словарь должностей обучаемых;

24. таблица-словарь категории обучаемых;

25. таблица тем обучения по категориям;

26. таблица-словарь тем обучения;

27. таблица пользователей программы;

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

данных Oracle;

Этот список строился из следующей цепи рассуждений:

Первая из основных задач приложения - регистрация объектов экономики.

Очевидно, что для того, чтобы хранить эту информацию, понадобится таблица

объектов экономики. Но даже после введения этой таблицы придется

регистрировать одну и туже информацию, к примеру, о районе при вводе

объектов одного и того же района. Чтобы избежать постоянного ввода названия

района, к которому принадлежит объект необходимо создать дополнительную

таблицу-словарь по районам (по территориальной принадлежности). По этой же

причине созданы и другие таблицы-словари.

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

примеру, о хранимых материально-технических средствах на объекте. Все эти

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

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

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

технических средств на объекте для каждого отдела. Но это не удобно, так

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

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

отдела(службы). Именно по этой причине создана отдельная таблица, в которой

содержится информация о всех хранимых МТС с ссылкой на название отдела.

Соответственно дополнение к таблице объектов экономики служат

таблицы:

. опасных веществ на объектах;

. защитных сооружений на объектах;

. технических средств на объектах;

. формирований на объектах;

. материально-технических средств на объектах;

. обучаемых на УМЦ;

В свою очередь каждая такая таблица имеет таблицу-словарь(и) на

которую она ссылается.

В данной базе данных предусмотрена защита информации, т.е. любые

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

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

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

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

уникальный номер в системе GOBASE и его имя.

Так же существует дополнительная таблица соответствия идентификаторов

пользователей программы и базы данных Oracle. Каждому идентификатору

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

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

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

отображается в соответствующих полях ввода и корректировки.

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

кто и в какое время ввел данные в таблицу. Это поля:

|DATEADD |Дата ввода информации |

|NAMEADD_ID |Идентификатор пользователя, который ввел данные |

|DATEINS |Дата последней коррекции |

|NAMEINS_ID |Идентификатор пользователя, который изменил |

| |данные |

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

поле PRIM.

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

данных.

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

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

нормализацией[9]. Говоря проще, нормализация - это удаление избыточных

данных из каждой таблицы в базе данных. У нормализации двойная цель -

удалить лишние копии данных и обеспечить максимальную гибкость как в

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

будущих изменений в базах данных.

О нормализации таблиц в базе данных нужно заботится на раннем этапе

проектирования приложения, так как при «живых» данных довольно трудно

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

таблицы, которые были не включены в первоначальный проект. Узнав об этом

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

Нормализация обычно подразделяется на пять форм или стадий— от первой

нормальной формы по пятую нормальную форму. То есть просто пять установок

реляционного критерия, который либо обнаруживает таблицу, либо нет. Каждая

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

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

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

данных.

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

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

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

никаких повторяющихся групп.

Поле считается неделимым, если оно содержит только один элемент

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

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

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

на несколько полей.

Повторяющаяся группа — это поле, которое повторяется внутри

определения записи с целью хранения нескольких значений для атрибута.

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

Для того чтобы привести таблицу ко второй нормальной форме, нужно,

чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и

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

полей. Это значит, что каждое не ключевое поле должно уникально

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

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

Для того чтобы таблица была приведена к третьей нормальной форме,

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

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

нормальной формы добавляется требование независимости каждого не ключевого

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

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

Четвертая нормальная форма запрещает хранить независимые элементы в

одной и той же таблице, когда между этими элементами существуют

взаимоотношения типа многие-ко-многим. Четвертая нормальная форма требует,

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

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

взаимоотношениями типа многие-ко-многим.

Конечно же, поскольку два столбца находятся во взаимоотношении многие-

ко-многим, то они уже не являются независимыми, и тем самым уже нарушают

третью нормальную форму. По этой причине четвертая нормальная форма

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

третьей нормальной формой.

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

Пятая нормальная форма требует, чтобы вы имели возможность

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

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

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

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

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

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

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

выбрасывать из таблиц элементы данных. Но тем не менее, пятая нормальная

форма призвана застраховать вас от такого несчастного случая.

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

Таблицы 7.1

|OBECONOM |Таблица объектов экономики |

|Столбец |Наименование |Ключ|

|OBJECT_ID |ID - уникальный ключ строки в таблице|PK |

|OBJECTNO |регистрационный номер объекта | |

|OBJECTNAME |наименование объекта | |

|ADDRESS_IND |почтовый индекс | |

|ADDRESS_CHAR |адрес объекта | |

|WORKNUMBER |количество работающих | |

|NRSM |наибольшая работающая смена в мирное | |

| |время | |

|NRSW |наибольшая работающая смена в военное| |

| |время | |

|DEPORTAMENT_ID |ведомственная принадлежность |FK |

|PECULIAR_ID |характер деятельности в особый период| |

| |(FK) | |

|RISK_ID |степень опасности |FK |

|REGION_ID |территориальная принадлежность |FK |

|ACTIVITY_ID |род деятельности |FK |

|PROPERTY_ID |форма собственности |FK |

|GLAVOBJECT_ID |подчиненность объекта |FK |

|DIRECTIONNAME |Ф.И.О. руководителя объекта | |

|POST_ID |занимаемая должность руководителя |FK |

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10