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



РУБРИКИ	Система управления базой данных объектов гражданской обороны для принятия решений в чрезвычайной ситуации (Диплом)	РЕКЛАМА

Главная

Зоология

Инвестиции

Информатика

Искусство и культура

Исторические личности

Безопасность жизнедеятельности

Бизнес-план

Биология

Бухучет управленчучет

Водоснабжение водоотведение

Военная кафедра

География экономическая география

Законодательство и право

Здоровье

Земельное право

Иностранные языки лингвистика

ПОИСК

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

p> Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.

Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал
(так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций
(undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти.

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

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

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры
БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).

Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц- каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.

Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор
SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.

Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами
(результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.

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

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

Групповые и корпоративные информационные системы и соответствующие приложения могут строиться различными способами:
. многотерминальные централизованные вычислительные системы;
. системы на основе локальной сети ПК (файл-серверные приложения);
. системы с архитектурой клиент-сервер;

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

Типовые компоненты информационных приложений

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

PS (Presentation Services) - средства представления. Обеспечиваются устройствами, принимающими ввод от пользователя и отображающим то, что сообщает ему компонент логики представления PL, плюс соответствующая программная поддержка. Может быть текстовым терминалом или Х-терминалом, а также ПК или рабочей станцией в режиме программной эмуляции терминала или Х- терминала.

PL (Presentation Logic) - логика представления. Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе элемента из списка.

BL (Business or Application Logic) - прикладная логика. Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.

DL (Data Logic) - логика управления данными. Операции с базой данных
(SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для реализации прикладной логики управления данными.

DS (Data Services) - операции с базой данных. Действия СУБД, вызываемые для выполнения логики управления данными, такие как манипулирование данными, определения данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL - предложения.

FS (File Services) - файловые операции. Дисковые операции чтения и записи данных для СУБД и других компонент. Обычно являются функциями ОС.
Можно привести несколько схем построения информационных систем (таблица
3.1.) в зависимости от размещения типовых компонентов приложения по узлам сети.

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

В централизованной системе, характерной для Unix, терминал реализует лишь функции представления данных PS, тогда как остальные функции обеспечивает центральный узел. Центр должен реагировать на каждый запрос пользователя (PL), выполнять логику приложения (BL, DL) и извлекать данные из БД (DS, FS). Имеются две серьезные проблемы для централизованной схемы: трудно обеспечить графический интерфейс; каждый дополнительный пользователь и приложение вносят существенную нагрузку на сервер, теряется масштабируемость.

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

В отличии от централизованной системы архитектура "файл-сервер"
(таблица 3.1 и рисунок 3.1) не имеет сетевого разделения компонентов диалога PS и PL, использует ПК для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на ЦП. Каждый новый клиент добавляет вычислительную мощность к сети.

[pic]

Рисунок 3.1.

Варианты построения файл-серверных приложений.

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля или в виде специального кода для интерпретации.

Однако такая архитектура имеет два основных недостатка: некоторые запросы к БД могут перекачивать всю БД клиенту, загружая сеть и имея непредсказуемое время реакции, тем самым, создавая значительный сетевой график, а также возникающая проблема "толстого клиента" - Windows- интерфейс, коды приложения и СУБД могут перегрузить даже мощный ПК.

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

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

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

Другая отличительная черта серверов БД - наличие словарьа данных, в котором записаны структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются прежде всего реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов для этой БД.

Большинство конфигураций клиент-сервер использует двухзвенную модель, состоящую из клиента, который обращается к услугам сервера (сх. 3-5 в таблице 3.1, рисунок 3.2). Для эффективной реализации такой схемы часто применяют неоднородную сеть. Как минимум, предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Далее возможно разместить компоненты управления данными DS и FS на сервере, а диалог (PS, PL), логику BL и DL на клиенте - сх. 3 в таблице 3.1). Типовое определение архитектуры клиент-сервер - приложение на клиенте, СУБД - на сервере - использует эту схему.

[pic]

Рисунок 3.2.

Варианты построения приложений клиент-сервер.

Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема возлагает дополнительное бремя администрирования приложений, разбросанных по различным клиентским узлам.

Можно сократить нагрузку на клиента и сеть, переместив целиком компонент BL на сервер, при этом вся логика принятия решений оформлена в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура - процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Компиляция повышает скорость исполнения хранимых процедур и сокращает нагрузку на сервер. Но, перегрузив хранимые процедуры прикладной логикой, можно потерять преимущества по производительности. Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность (нет прямого доступа к данным).

Переместив с клиента часть логики приложения на сервер, получим систему клиент-сервер с разделенной логикой. Часть прикладной логики может быть реализована на клиенте, а другая часть логики - в виде обработчиков событий (триггеров) и хранимых процедур на сервере БД. Такая схема при удачном разделении логики приводит к сбалансированной загрузке клиентов и сервера, но при этом затрудняется сопровождение приложений.

[pic]

Рисунок 3.3.

Приложения клиент-сервер на основе многотерминальной системы.

На основе многотерминальной системы в качестве сервера приложений также возможно создание архитектуры клиент-сервер (рисунок 3.3.). В этом случае в многозадачной среде сервера приложений выполняются программы пользователей, а клиентские узлы вырождены и представлены терминалами.

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

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

Среди средств разработки информационных приложений можно выделить следующие основные группы:
. традиционные системы программирования;
. инструменты для создания файл-серверных приложений;
. средства разработки приложений клиент-сервер;

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

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

Традиционные системы программирования представлены средствами создания приложений на языках третьего поколения 3GL: C, Pascal, Basic и др. Среди них по способам подготовки и выполнения программных модулей различают системы компилирующего и интерпретирующего типа. Инструментальные средства программирования могут быть представлены набором отдельных утилит (редактор текстов, компилятор, компоновщик и отладчик) или интегрированной средой программирования.

Процедурные языки программирования являются традиционными, они лишь претерпели изменения от неструктурных до структурных языков программирования. Объектно-ориентированное программирование - сравнительно новое направление, однако оно в концептуальном плане более привлекательно, позволяет рассматривать и реализовывать информационные и функциональные свойства объектов в неразрывной связи.

Свойствами объектно-ориентированных языков, обуславливающими их преимущества, являются сокрытие деталей реализации объекта (инкапсуляция), наследование процедурных и информационных частей от объектов-родителей, полиморфизм как возможность настройки на различные типы данных и др.
Примерами объектно-ориентированных систем программирования являются C++ и
Object Pascal.

Системы программирования 3GL нужны для организации специальных модулей в информационных приложениях, для создания эффективных по быстродействию программ обработки данных. Для создания с помощью систем программирования полноценных информационных приложений необходимо расширить их за счет использования библиотек диалога и доступа к базам данных, а также макросредств встроенного языка структурированных запросов Embeded SQL.

Систему программирования Visual Basic можно использовать для создания простых автономных приложений и компонентов VBX и OCX, для расширения и интеграции функциональных пакетов (Word, Excel, Access), а также как средство программирования для расширения систем документооборота и для создания утилит администрирования.

С момента выхода продано существенно больше копий Delphi, чем Visual
Basic. Применение продукта возможно для создания расчетно-аналитических программ, для разработки DLL, для сопровождения и развития разработок, выполненных на Turbo и Borland Pascal, а также для быстрого прототипирования будущих приложений. В ряде случаев решающим для выбора будут умеренные требования Delphi-приложения к системно-техническому обеспечению.

С++ применяется для расширения системного программного обеспечения, для разработки крупных проектов, специальных приложений, создания библиотек и классов для предметной области, разработки динамических библиотек DLL, создания программного обеспечения для серверов приложений, разработки ОСХ, использования совместно с CASE-системами, обеспечения многоплатформенности и переносимости (по стандарту ANSI).

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

Основой разработки файл-серверных приложений для локальных сетей ПК является инструментальное окружение различных "персональных" СУБД: FoxPro,
Clipper, Paradox, Clarion, Paradox, dBase и т.п. Такие средства, как правило, реализованы в виде диалоговой интегрированной среды, предоставляющих три уровня доступа:
. программирование и создание приложений на языке, сочетающем возможности языка 3GL с некоторыми возможностями языков четвертого поколения 4GL;
. создание и ведение структуры БД и индексов, а также интерактивная генерация макетного приложения и его компонентов (меню, форм или окон, отчетов, запросов и программных модулей);
. использование диалоговой среды и генераторов конечными пользователями для создания, ведения и просмотра БД, а также формирования несложных запросов и отчетов.

Диалоговые среды поддерживают как текстовой для DOS, так и графический интерфейс пользователя для Windows. Внедрение графического интерфейса привело к развитию объектных свойств инструментов, средств визуальной генерации программ и событийного механизма приложений.

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

СУБД для ПК MS Access может использоваться для создания масштабируемых одиночных и групповых информационных приложений и для разработки клиентской части приложений клиент-сервер, а также как средство автоматизации делопроизводства в составе MS-Office.

Традиционные инструментальные средства класса xBase (такие как FoxPro,
Clipper, dBase и др.) теряют рынок (число их продаж значительно сокращается) из-за несоответствия современным требованиям. По мере того, как предприятия все шире используют СУБД MS Access и новые средства разработки, такие как Visual Basic и Delphi, популярность среды Xbase уменьшается. Более того, Microsoft может прекратить поддержку FoxPro, так как эта СУБД с устаревшим языком и сокращающейся рыночной долей не вписывается в долговременную стратегию развития средств разработки, которую
Microsoft строит вокруг Visual Basic и Access. Новые "визуальные" инструменты этого класса (Visual FoxPro, CA-Visual Objects, Visual dBase) пытаются сохранить и расширить прежний ареал. Они могут быть рекомендованы для сопровождения и развития прежних xBase-разработок, для создания масштабируемых одиночных и групповых файл-серверных приложений и для переноса и адаптации приложений в архитектуру клиент-сервер с использованием интерфейса ODBC. Но нужно четко осознавать, что при применении нового инструментария для создания диалога и с переходом на SQL- операторы от прежних xBase-приложений остается ничтожно мало, а, кроме того, существенно меняется подход к разработке, и прежние навыки вряд ли будут востребованы.

Инструментальное средство MS Access хорошо зарекомендовало себя в разработке файл-серверных приложений с возможностью масштабирования, так как оно имеет удобные средства визуального конструирования, отладки и возможности использования как Access Basic, так и SQL. Интерфейс ODBC открывает широкие возможности интероперабельности с различными СУБД. В 1995 г. на долю MS Access пришлось 57% рынка настольных баз данных, а FoxPro и dBase - 9% и 2%, соответственно

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

Группу инструментальных средств для создания информационных приложений с архитектурой клиент-сервер можно разделить на следующие подгруппы:
. среды разработки приложений для серверов баз данных, независимые от СУБД инструменты для создания приложений клиент-сервер;
. средства поддержки распределенных информационных приложений.

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

Среды разработки приложений для серверов БД представляют собой системы программирования четвертого поколения 4GL или инструментальные средства быстрой разработки приложений RAD (Rapid Application Development).
Особенностями этой подгруппы средств являются: реализация удаленного доступа к СУБД по двухзвенной схеме клиент-сервер; связь клиентских приложений с серверами БД с помощью непроцедурного языка структурированных запросов SQL (кроме серверов Btrieve); обеспечение целостности БД, включая целостность транзакций; поддержка хранимых процедур на серверах БД; реализация клиентских и серверных триггеров-процедур; генерация элементов диалогового интерфейса и отчетов.

В качестве примера можно назвать инструменты Informix/4GL,
Oracle*Forms и др. Сейчас новые среды разработки SQL-серверов БД (Informix
NewEra и Oracle Power Objects) развиваются в сторону независимых от СУБД инструментов. Независимые инструментальные средства, ориентированные на многие платформы СУБД, представлены в виде средств быстрой разработки приложений RAD. Для таких средств создания приложений клиент-сервер характерны: возможность распределения приложения на клиентах и/или серверах; создание приложений для разных серверов БД; поддержка спецификации ODBC для доступа к различным серверам БД, включая СУБД для ПК; связь с мониторами транзакций для организации трехзвенной архитектуры приложений клиент-сервер; объектно-ориентированное программирование приложений; визуальный характер генерации приложения; ведение репозитария объектов и их свойств, что облегчает интеграцию со средствами автоматизации проектирования программ CASE; управление проектами и версиями приложений; интеграция приложения с электронной почтой и средствами офисной автоматизации.

Известными примерами независимых инструментальных средств разработки являются: ErWin, SQLWindows, PowerBuilder, JAM и Uniface.

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

Средства поддержки распределенных приложений относятся к категории промежуточного программного обеспечения middleware для организации серверов приложений. Сюда входят разнообразные библиотеки и наборы инструментальных средств: интерфейсы доступа к базам данных ODBC и IDAPI; шлюзы для систем управления базами данных; протоколы и команды мониторов обработки транзакций; почтовые интерфейсы MAPI, VIM, MHS, X.400 и EDI; средства обмена сообщениями MOM; протоколы связывания и включения объектов OLE и динамического обмена данными DDE; протоколы удаленного вызова процедур RPC и именованных конвейеров Named Pipes, средства коммуникационного ввода- вывода BSD Sockets и WinSock.

Инструментальные наборы для разработки приложений клиент-сервер необходимо выбирать, исходя из следующих критериев (см. таблицу 4.1): наличие объектно-ориентированной инфраструктуры, возможности распределения приложений между клиентом и сервером, обеспечена ли поддержка мониторов транзакций, доступность CASE-репозитария, возможность переноса приложений и контроль версий. При этом следует выяснить, насколько опыт разработчиков предприятия соответствует требованиям продукта, важна ли переносимость приложений на другие аппаратные платформы и базы данных, какая степень интеграции приложений устроит заказчика и нужно ли будет в дальнейшем подключать к приложению дополнительных пользователей, функции и данные.

Таблица 4.1. Инструментальные наборы для разработки приложений клиент- сервер
|Продукт/ко|Объектно-ори|Распредел|Поддержка |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. ВЫВОДЫ ПО ВЫБОРУ ОПЕРАЦИОННОЙ СИСТЕМЫ, ЯЗЫКА ПРОГРАММИРОВАНИЯ И БАЗЫ

ДАННЫХ

Первоочередной задачей является выбор варианты построения информационных приложений с использованием СУБД. Из рассмотренных вариантов системы с архитектурой клиент-сервер наиболее эффективная и дешевая для больших баз данных и множества пользователей, которым нужен доступ к
«свежим» данным. В масштабе предприятия вычисления клиент/сервер — представляют собой ни что иное, как распределение обработки в многопользовательской базе данных по нескольким компьютерам (ПК и рабочим станциям).

Что же дает вычисление клиент/сервер по сравнению с традиционной однокомпьютерной средой (с одной большой ЭВМ)? При корректной реализации системы клиент/сервер получается система управления информацией с намного лучшим отношением «цена/производительность», которую можно наращивать и легко приспосабливать к меняющимся требованиям. Другой причиной выбора технологии клиент/сервер является то обстоятельство, что менеджерам уже более не нужно отслеживать сотни, а то и тысячи программ, нуждающихся в обновлении и перекомпилировании каждый раз при небольшом изменении в базе данных. К плюсам технологии клиент/сервер можно отнести простоту и удобство пользовательских интерфейсов, открытость систем, эффективную среду разработки (особенно при наличии объектно-ориентированных инструментов) и быстроту решений.

На сегодняшний момент только четыре базы являются приемлемыми для надежного хранения больших данных и удобства использования: 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. Через уникальный регистрационный номер пользователя определяются его полномочия на работу с базой данных и его имя, которое отображается в соответствующих полях ввода и корректировки.

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

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

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

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

О нормализации таблиц в базе данных нужно заботится на раннем этапе проектирования приложения, так как при «живых» данных довольно трудно менять структуру базы. Иногда процесс нормализации порождает добавочные таблицы, которые были не включены в первоначальный проект. Узнав об этом как можно раньше, не придется зря тратить силы на их разработку.

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

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

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

Поле считается неделимым, если оно содержит только один элемент данных. Например, поле Address, которое содержит не только название улицы, но также и города, почтовый код, не является неделимым. Чтобы соответствовать первой нормальной форме, такие столбцы должны быть разбиты на несколько полей.

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

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

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

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

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

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

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

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

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

Пятая нормальная форма требует, чтобы вы имели возможность перестраивать свои данные в нормализованных таблицах, в которые они были переведены. Это значит, что если вы начинаете с ненормализованных таблиц, то у вас не должно быть препятствий к вырезке и вставке данных и после нормализации. Это осуществимые, если есть гарантия, что в процессе нормализации не будет потери данных.

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

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

Первичный ключ(PK) - это поле или поля таблицы, которые используются как идентификатор элемента. Подобно идентификатору, значение первичного ключа таблицы всегда уникально для каждой записи. Поля, составляющие первичный ключ, используются также для построения индекса, предназначенного для быстрого доступа к ее строкам.

Внешний ключ(FK) — это поле или поля таблицы, которые, не будучи употребленными в качестве идентификатора, часто используются при объединении с другими таблицами. В таблице объектов, например, поле номера района служит в качестве внешнего ключа. Поле номера района не уникально определяет конкретные записи объектов - для одного района может быть несколько объектов.

NOT NULL - должно иметь значение
[pic] Рисунок 7.2. Диаграмма потоков данных (взаимосвязь таблиц)

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

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

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

Перед созданием базы данных ее необходимо спроектировать. Этап проектирования базы данных включает в себя планирование ограничений файлов и включение файлов а новую базу данных. Этап создания состоит в выполнении этого плана с помощью команды SQL CREATE DATABASE и некоторых сценариев.

Основные задачи включают в себя следующее:
. Определение соответствующих значений в команде CREATE DATABASE. для параметров ограничений файлов.
. Планирование размера и расположения файлов начальных данных табличной области SYSTEM новой базы данных.
. Планирование для новой базы данных размера и расположения групп и членов журнала транзакций.
. Определение набора символов для хранения информации базы данных.
. Создание файла параметров инициализации и спецификации имен управляющих файлов базы данных.

Сценарий с файлами инициализации базы данных приведены в ПРИЛОЖЕНИИ 3.

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

Таблицы создаются с помощью оператора SQL CREATE TABLE.
Фрагмент из ПРИЛОЖЕНИЯ 4:
CREATE TABLE ACTIVITY

(

ACTIVITY_ID NUMBER(7) NOT NULL,

ACTIVITY_CHAR VARCHAR2(50) NULL

);
Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

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

Индексы облегчают поиск и сортировку данных. Индексы создаются с помощью оператора SQL CREATE INDEX. Фрагмент из ПРИЛОЖЕНИЯ 4:
CREATE UNIQUE INDEX IPKACTIVITY ON ACTIVITY

(

ACTIVITY_ID ASC

);

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

Добавление определения первичного ключа к существующей таблице:
ALTER TABLE ACTIVITY

ADD ( PRIMARY KEY (ACTIVITY_ID) ) ;
Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

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

Добавление определения вторичного ключа к существующей таблице:
ALTER TABLE OBECONOM
ADD ( FOREIGN KEY (ACTIVITY_ID)

REFERENCES ACTIVITY ) ;
Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

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

Триггер - это скомпилированная программа SQL, которая выполняется, когда в таблице происходит данное событие. С триггером, как правило, связываются три самых распространенных события: вставка, удаление и обновление строки.
CREATE TRIGGER IU_STUDY BEFORE INSERT OR UPDATE ON GO.STUDY

FOR EACH ROW

BEGIN

IF INSERTING THEN

SELECT GOBASEUSER_ID INTO :NEW.NAMEADD_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEADD := SYSDATE;

END IF;

SELECT GOBASEUSER_ID INTO :NEW.NAMEINS_ID

FROM GO.ORAUSER

WHERE ORAUSER_ID=UID;

:NEW.DATEINS := SYSDATE;

END;
Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

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

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

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

CREATE SEQUENCE S_STUDY
Полный сценарий приведен в ПРИЛОЖЕНИИ 4.

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

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

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

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

Соглашение о название компонентов Таблица 7.3
|Компонент |Аббревиатура |Компонент |Аббревиатура |
|AutoObject |ao |QRDBText |qt |
|BatchMove |bm |QRDetailLink |qd |
|Bevel |be |QRGroup |qg |
|BiGauge |bg |QRLabel |ql |
|BiPict |bp |QRMemo |qm |
|Biswitch |bs |QRPreview |qp |
|BitBtn |bb |QRShape |qh |
|Button |bu |QRSysData |qs |
|Calendar |ca |Query |qu |
|ChartFX |ch |QuickReport |qr |
|CheckBox |ck |RadioButton |rb |
|ColorDialog |c_ |RadioGroup |rg |
|ColorGrid |сg |ReplaceDialog |r_ |
|ComboBox |cb |Report |rp |
|Database |db |RichEdit |re |
|DataModule, DBMemo |dm |SaveDialog |s_ |
|DataSource |ds |ScrollBar |sa |
|DBCheckBox |dk |ScrollBox |sx |
|DBComboBox |dc |Session |se |
|DBEdit |de |SpeedButton |sb |
|DBGrid |gr |SpinButton |su |
|DBImage |di |SpinEdit |sd |
|DBListBox |di |StatusBar |st |
|DBLookupComboBox, |lc |FindDialog |n_ |
|DBLookupCombo | | | |
|DBLookupListBox, |ll |Font Dialog |f_ |
|DBLookupList | | | |
|DBNavigator |na |Form |fm |
|DBRadioGroup |dg |Gauge |ga |
|DBText |te |Graphics Server |gs |
|DdeClientConv |cc |GroupBox |gs |
|DdeCI lent Item |ci |Header |he |
|DdeServerConv |sc |HeaderControi |hc |
|DdeServerItem |si |HotKey |hk |
|DirectoryListBox |dy |IBEventAierter |ie |
|DirectoryOutline |do |Image |im |
|DrawGrid |dr |Image List |il |
|DriveCoitiboBox |rc |Label |la |
|Edit |ed |ListBox |lb |
|FileListBox |fl |ListView |lv |
|FilterComboBox |fc |MainMenu |mm |
|MaskEdit |md |StoredProc |sp |
|MediaPlayer |mp |StringGrid |sg |
|Memo |me |TabbedNotebook |tn |
|Notebook |nb |TabControi |tc |
|OleContainer |ol |Table |ta |
|OpenDialog |od |TabSet |ts |
|OutLine |ou |Thread |th |
|PageControl |pc |Timer |ti |
|PaintBox |pb |TrackBar |tb |
|Panel |pa |TreeView |tv |
|PopupMenu |pu |UpdateSQL |us |
|PrintDialog |p_ |UpDown |ud |
|PrinterSetupDialog |i_ |VCFirstImpressio|vf |
| | |n | |
|ProgressBar |pr |VCFormulaOne |vo |
|QRBand |qb |VCSpeller |vs |
|QRDBCalc |qc | | |

Имена типов в программе начинаются с большой буквы T. Пример:
TBaseForm

В имена констант используются только прописные буквы. Пример: DEFSQL

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

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

Главное меню программы состоит из пяти основных пунктов:
«Файлы», «Таблицы», «Отчеты» и «Помощь». (Рис. 7.3.)

[pic]

Рисунок 7.3. Главное меню программы

Главное меню содержит пять кнопок быстрого запуска:
. Объекты экономики (вызов формы ввода объектов экономики);
. Обучаемые на УМЦ (вызов формы ввода обучаеых на УМЦ);
. Отчеты (вызов формы отчетов, дерева отчетов);
. Справка (вызов справки о программе);

В нижней части главного меню располагается информация:
. о текущем пользователе;
. о текущей версии программы.

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

Меню файлы состоит из подменю: установка принтера и выход.

Подменю установка принтера предназначена для вызова стандартной формы выбора принтера (Рис. 7.4.).
[pic]

Рисунок 7.4. Форма установки принтера

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

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

Меню «Таблицы» предназначена для доступа к любой таблице базы данных.
Данное меню состоит из следующих подменю:
. Объекты экономики (вызов подменю)

. Объекты экономики (вызов формы объектов экономики);

. Районы (вызов формы районов);

. Рода деятельности (вызов формы рода деятельности);

. Форма собственности (вызов формы собственности);

. Деятельность в ОП ( вызов формы по таблице-словарю деятельности в особый период);

. Ведомства (вызов формы ведомства);

. Степень опасности (вызов формы степени опасности);

. Должность руководителя (вызов формы возможных должностей руководителей на объекте);

. Должности по ГО (вызов формы возможных должностей руководителей штабов ГО на объекте);
. Обучаемые на УМЦ (вызов подменю)

. Обучаемые на УМЦ (вызов формы ввода обучаемых на УМЦ);

. Категории обучаемых (вызов категории обучаемых на УМЦ);

. Гражданские должности (вызов формы возможных гражданских должностей).
. Темы (вызов подменю)

. Категорированные темы (вызов формы категорированных тем обучения на

УМЦ);

. Темы (вызов формы тем обучения);
. Формирования;
. Степени готовности (степени готовности формирований);
. Защитные сооружения;
. Опасные вещества;
. Техника;
. Службы (службы ГО);
. МТС (вызов формы материально-технического обеспечения);
. Пользователи; (вызов формы ввода пользователей программы. Только для администратора доступен этот пункт).

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

Данное меню вызывает форму дерева отчетов программы.
Более подробно в пункте 7.13.3.

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

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

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

Наметив, какие формы и отчеты необходимы приложению, можно разработать отдельную иерархию форм и отчетов, чтобы воспользоваться преимуществами средств поддержки наследственности визуальных форм Delphi. Другими словами, необходимо организовать формы и отчеты в общие классы, которые строятся друг на друге.

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

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

В программе используется более 28 форм для работы с таблицами базы данных и 7 вспомогательных форм для работы с печатью, помощью и отчетами. В виду такого количества форм необходимо составить иерархию форм (Рис 7.5.) для облегчения программирования и уменьшения требовательности к ресурсам ОС и аппаратным ресурсам.
[pic]

Рисунок 7.5. Иерархия форм

Формы сетки 1-4 используются для таблиц-справочников.

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

В каждой форме ввода присутствуют:
1. Навигатор по базе данных, который представляет собой десять кнопок (Рис
7.6) : «Первая строка в таблице», «Предыдущая строка», «Следующая строка», «Последняя строка в таблице», «Вставка», «Удаление»,
«Редактирование», «Ввод», «Отмена», «Перечитать данные из таблицы»;
2. Кнопка выхода из формы с сохранением данных (OK);
3. Кнопка выхода из формы без сохранения данных (Cancel);
4. Кнопка минимизации окна;
5. Кнопка максимизации окна;
6. Кнопка закрытия окна (аналогична Cancel);
7. Выпадающий список (список строк другой таблицы)
8. Кнопка с темя точками - вызов формы редактирования таблицы, которая подключена к выпадающему списку.

[pic]

Рисунок 7.6. Форма ввода формирований на текущем объекте

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

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

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

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

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

Форма ввода объектов экономики (Рис 7.7) позволяет производить вставку, редактирование и удаление информации по текущему объекту.
Комбинированные списки позволяют просматривать и вставлять значения из таблиц-словарей. Кнопки с тремя точками вызывают соответствующие формы редактирования таблиц-словарей.
Кнопки: «Формирования», «Защитные сооружения» и т.д, находящиеся в нижней части меню позволяют вывести дополнительную информацию по текущему объекту.

Контрольный элемент «Головной объект» позволяет (в отключенном состоянии) выбрать головной объект из выпадающего списка головных объектов.
[pic]

Рисунок 7.7. Форма ввода объектов экономики

В качестве примера дополнительной информации по объекту (на рис 7.6 смотри выше) показана форма ввода формирований на текущем объекте.
Аналогично построена форма ввода защитных сооружений, техники, химических веществ.

Кнопка «Материалы» выводит форму по выбору интересующей службы, далее после выбора службы вызывается форма ввода материально-технических средств данной службы на данном объекте (Рис 7.8).
[pic]

Рисунок 7.8. Материально-технические средства на объекте

Кнопка «Обучаемые» выводит форму о обучаемых в УМЦ на текущем объекте.

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

Данная форма ведет таблицу обучаемых на УМЦ (Рис 7.9). Поля «прошлая дата обучения» и «следующая дата обучения» связаны интервалом в три года, т.е. если поле «следующая дата» пустое, а в поле «прошлая дата обучения» вводится новое число, то происходит автоматическая корректировка поля
«следующая дата».

Для удобства ввода даты создана форма «Выбор даты» (Рис7.10). Правые верхние кнопки отвечают за выбор месяца, а левые верхние кнопки отвечают за выбор года.

[pic]

Рисунок 7.9. Обучаемые на УМЦ

В форме выбора категории обучаемых существует возможность ввода тем обучения для данной категории с указанием времени обучения. Категории обучаемых подразделяются на две группы: командиры формирований и другие, соответственно в главной форме по вводу обучаемых есть флажок «признак категории».

[pic]

Рисунок 7.10 Выбор даты

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

Одна из самых главных форм - эта форма отчетов, которая позволяет выбрать любые данные, практически по любым критериям, из базы данных. (Рис
7.11).

[pic]

Рисунок 7.11. Форма отчетов программы

Данная форма состоит из двух основных элементов: дерева отчетов и сетки вывода запроса. Для удобства поиска данных предусмотрен выпадающий список «Поле» который ограничивает запрос выбранным параметром. Так же предусмотрена сортировка по любым полям таблицы. Данные два поля позволяют создавать с помощью одного запроса комбинацию запросов по выбранным критериям.

В виду того, что не всегда можно предугадать нужные запросы пользователя в форме «отчеты» можно вызвать редактор SQL запроса, который позволяет ввести любой запрос в буфер SQL (в буфер можно ввести файл c готовым SQL , так же набранный SQL из буфера можно сохранить в файл) .
Алгоритм работы с формой отчетов представлен соответствующих четырех плакатах.

В случае если SQL запрос содержит выборку в каком-либо временном промежутке, то автоматически подключаются второстепенные органы управления по работе с датами (Рис 7.12)

[pic]

Рисунок 7.12. Форма отчетов программы (работа с запросами содержащими даты).

Одна из особенностей этой формы: если запрос связан с объектами, то двойной щелчок по сетке приводи полную информацию о текущем объекте. Такая же особенность и с обучающимся на УМЦ.

Кнопка «Excel» позволяет вызвать форму экспорта данных в Excel. На рисунке 7.13. показан экспорт данных в Excel.

7.14. Экспорт в Excel

Существует множество способов и программ, которые позволяют создавать отчетные документы. Но, как правило, отчеты полученные стандартными способами или специальными программами не позволяют гибко менять структуру отчета , а тем более редактировать его. При решении проблемы с отчетными документами был выбран стандартный табличный - процессор Excel, как наиболее гибкая программа для работы с отчетными документами. Excel не имеет никаких стандартных функций для взаимодействия Delphi-приложениями.
Единственная возможность к доступу ячейкам Excel и к его командам это использование DDE Windows.

[pic]

Рисунок 7.13 Экспорт отчета в Excel

Динамический обмен данными (DDE) обеспечивает коммуникационную основу для программ Windows, которая позволяет открыть диалог между приложениями клиента и сервера. Диалог DDE - это связь между взаимодействующими программами, которая инициируется, а затем закрывается. Для того чтобы DDE- диалог мог происходить, обе программы должны быть запущены.

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

DDE-взаимодействие имеет темы (Topics), или категории, которые полностью зависят от приложения. Наиболее распространенный пример темы это имя файла. Другие темы могут включать понятие system, которое используют приложения Microsoft, когда нужно запросить через DDE информацию относительно того, какие форматы Clipbord поддерживаются. В данном случае
Topic используется для доступа к листу Excel.

Данные, которые во время диалога перемещаются туда и обратно, называются элементом (item). В данном случае элемент является спецификация рядов/колонок диапазона листа Excel.

Примечание: Из руководства по пользованию DDE: К сожалению, нет никакой систематической возможности найти, какие темы поддерживает приложение. Ваше приложение должно знать заранее, какие темы поддерживает приложение-сервер.

Исходя из прочитанной литературы в электронных сетях были установлены основные команды по работе с Excel:

FORMAT(«строка», «rc») - вывод строки в ячейку.

READY – готовность Excel. А так же благодаря исследовательским работам в этом направлении удалось вывести алгоритм поиска Excel. (поиск происходит по реестру Windows).

Алгоритм вывода данных в Excel представлен на плакатах 1-2

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

1. IBM PC XT/AT совместимый компьютер;

2. Windows 95 или Windows NT любой версии;

3. 5000Kb свободного пространства на диске;

4. Не менее 8 Mb оперативной памяти

5. При использовании отчетов необходим Microsoft Excel

6. База данных Oracle v7.2 или выше

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

Программа установки находится на первой установочной дискете (всего три диска формата 1.44). Запустите с установочной дискеты программу
SETUP.EXE и укажите тип установки (Полная, выборочная или минимальная); укажите путь для установки программы, далее программа установки автоматически установит программу.

Для корректной работы программы должна быть установлена ЛВС со стандартным IPX или IP протоколом и с сервер базы данных Oracle не ниже 7.2 версии.

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

8.1. Введение

Для наиболее эффективной работы штаба по делам ГО и ЧС необходимо иметь программу (базу данных), содержащую информацию об объектах экономики округа или города, для возможности оперативного реагирования в случаи возникающих чрезвычайных ситуаций.

Для оценки возможной чрезвычайной ситуации офицеры управления и другие ответственные лица должны постоянно иметь свежую и достоверную информацию об объекте, на котором может произойти ЧС.
Возникает необходимость организации управления и создания базы данных таким образом, чтобы обеспечить быстроту и надежность получения различных данных для наиболее четко слаженной работы штаба.

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

Для наиболее слаженной работы различных служб штаба данные удобно держать централизованно на главном компьютере и иметь к ним доступ с других компьютеров (через сеть) с помощью программы по управлению базой данных. Локальные вычислительные сети, позволяют осуществлять связь между различными пользователями этой сети, находящимися на некотором расстоянии друг от друга (обычно, в разных помещениях одного здания). Однако такие базы данных требуют для своей работы соответствующего программного обеспечения, которое могло бы позволять вводить, выводить, искать, а так же производить обработку этих данных. Кроме того, к такому программному обеспечению предъявляются такие требования как удобство доступа к необходимой информации, простота в обращении и защита от несанкционированного доступа к конфиденциальной информации, а также, защита от порчи различного рода программными вирусами.

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

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

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

Данное программное средство выполняет функции в интересах системы оповещения при ЧС.

Данная программа обеспечивает:

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

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

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

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

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

6). уменьшение времени на подготовку списков объектов экономики и списков, обучающихся на УМЦ;

7). контроль однократности учета объектов и обучающихся;

В состав программы входит:

1). задача первоначального ввода информации об объектах экономики;

2). задача первоначального ввода информации об обучаемых на УМЦ;

3). задача формирования и печати списков объектов экономики;

4). задача формирования и печати списков, обучаемых на УМЦ;

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

Для планирования разработки применим сетевой метод, для чего составим перечень событий и работ с учетом нормативных документов НИР. Перечень событий и работ приводится в таблице (8.1). Результаты расчета параметров сетевого графика сведены в таблицу (8.2). Сетевой график показан на (рис.
8.1).

По вышеизложенной методике проведено планирование разработки. Задача, решаемая в дипломном проекте, поставленная перед научной группой из трех человек, должна быть выполнена в течение 2 месяцев (44 дня). Путь, имеющий максимальную продолжительность, равную 42 дням, является критическим. Это путь:
0-1-2-3-4-8-9-10-13-14-15-17-18-19-21-22-23.

Для правильного выполнения сетевого графика должно выполняться следующее условие : вероятность совершения события в заданный срок Р
(Ткр

Страницы: 1, 2