Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Разработка электронной базы данных по дисциплинам "Пожарная безопасность в строительстве" и "Здания, сооружения и их устойчивость при пожаре"

Разработка электронной базы данных по дисциплинам "Пожарная безопасность в строительстве" и "Здания, сооружения и их устойчивость при пожаре"

Общие сведения и классификация баз данных. Нормативное обеспечение технического регулирования в области пожарной безопасности. Описание информационной базы, построенной с использованием программных средств "Microsoft HTML Help Workshop" и "HTM2CHM".

Рубрика	Программирование, компьютеры и кибернетика
Вид	дипломная работа
Язык	русский
Дата добавления	15.11.2015
Размер файла	146,6 K

посмотреть текст работы

скачать работу можно здесь

полная информация о работе

весь список подобных работ

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

1.3 Постановка цели и задач исследования

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

Информация, содержащаяся в них, может обновляться с применением информационных систем "Консультант Плюс", "Гарант", с использованием сайтов МЧС и тематических электронных изданий.

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

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

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

Для достижения поставленной цели решаются следующие задачи:

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

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

- определить структуру (рубрикацию) и содержание базы данных;

- заполнить базу данных основополагающими документами;

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

2. Общие сведения и классификация баз данных

2.1 Общие сведения и классификация баз данных

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

Основные возможности электронных баз данных:

- хранение данных;

- обеспечение быстрого доступа к данным;

- вставка в базу объектов разных типов, включая графические объекты;

- сортировка документов по разным признакам;

- фильтрация данных с применением разных фильтров;

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

- дополнение и обновление данных;

- создание элементов управления для улучшения интерфейса;

На сегодняшний день можно выделить следующие основные типы баз данных [51]:

- реляционная база данных (использует табличное представление данных);

- иерархическая база данных (использует структуру данных в виде деревьев);

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

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

Схема сетевой модели приведена на рис. 2.1.

Рис. 2.1. Схема сетевой модели данных

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

В реляционной модели реализуются связи между объектами по принципу каждый с каждым (рис. 2.2).

Рис. 2.2. Схема реляционной модели данных

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

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

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

Современная СУБД обеспечивает возможность работы с БД в глобальных и локальных сетях. Широко используются следующие базы данных[53]:

- электронные библиотечные каталоги;

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

Для работы с базой данных СУБД должна обеспечивать:

- возможность внесения и чтения информации;

- работу с большим объемом данных;

- быстроту поиска данных;

- целостность данных (их непротиворечивость);

- защиту от разрушения, уничтожения ( не только при случайных ошибках пользователя), от несанкционированного доступа;

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

К числу наиболее известных представителей систем, основанных на инвентированных списках можно отнести Datacom/DB от компании Applied Data Research, Inc. (ADR) [52]. Организация доступа к данным, основанная на инвертированных списках, очень распространена и применяется практически во всех современных реляционных СУБД. В этих системах пользователи не имеют непосредственного доступа к инвертированным спискам (то есть к индексам). Общие правила для ограничения целостности отсутствуют.

Типичным представителем иерархических систем является Information Management System (IMS) фирмы IBM. Первая версия этого продукта вышла в свет ещё в 1968 году [54]. Чтобы понять иерархическую модель СУБД, можно представить себе дерево (представляет собой структуру данных) со всеми его ветками и выросшими от него другими деревьями. При этом к каждому листочку (сегменту структуры) можно добраться только по одному определенному пути, который начинается от корней (корневого сегмента). Для этой модели существуют некоторые базовые правила. Никакая запись-"потомок" не может существовать без записи единственного "предка".

Типичным представителем сетевых СУБД является Integrated Database Management System (IDMS), созданная в компании Cullinet Software, Inc. [55]. Отличие таких СУБД от разработанных с помощью иерархического подхода кроется в особенностях сетевой структуры данных: потомок может иметь больше одного предка.

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

Локальными или настольными называют СУБД типа Access, Paradox и т.д. [55]. В них уже есть свой формат данных, который учитывает параллельное выполнение операций, возможность доступа к БД нескольких пользователей и т.д. (в принципе, в клиент-серверных операционных системах баз данных тоже часто хранятся в файлах на диске, к которым идет доступ средствами операционной системы (ОС), за исключением гигантов типа Oracle, где есть своя файловая система). Однако это менее эффективно, чем в клиент-серверных СУБД. Недостатки становятся очевидными не сразу, а по мере увеличения количества данных и числа пользователей, и проявляются снижением производительности и возникновением сбоев. Объяснить это можно довольно просто: при выполнении какого-либо запроса от клиента программе необходимо прочитать некоторую часть БД из памяти (вся база в память не считывается, так как это было бы слишком неэффективно), произвести какие-то действия (в зависимости от запроса), затем снова записать в память. Реальными минусами настольных СУБД являются: неэффективное расходование сетевого трафика и низкая эффективность при большом количестве пользователей. Однако решение этой проблемы есть. На помощь приходит одна из самых известных и распространенных сейчас технологий - "клиент-сервер".

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

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

2.2 Требования к разрабатываемой базе данных

2.2.1 Характеристика содержания базы данных

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

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

Дисциплина ПБС начинается у курсантов УрИ ГПС МЧС России на четвертом курсе и продолжает преподаваться до конца обучения, то есть до конца пятого курса. Цель изучения дисциплины: приобретение курсантами необходимые теоретических знаний и практических навыков по нормативно-технической работе, достаточных для разработки технических решений по обеспечению требуемого уровня пожарной безопасности зданий и сооружений.

2.2.2 Нормативное обеспечение дисциплин "Пожарная безопасность в строительстве" и "Здания, сооружения и их устойчивость при пожаре"

Для удобства курсантов очного обучения и слушателей заочного обучения, в рабочих учебных программах по каждой дисциплине [56],[57] приведены перечни нормативных документов, используемых в учебном процессе. Некоторые документы дублируются в списке обеих дисциплин, что не удивительно, учитывая профильное направление дисциплин и преемственность: при изучении дисциплины "Пожарная безопасность в строительстве" используются знания, полученные на предмете "Здания, сооружения и их устойчивость при пожаре"; эти знания расширяются и углубляются.

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

Таблица 2.1

Нормативное обеспечение дисциплин "Здания, сооружения и их устойчивость при пожаре" и "Пожарная безопасность в строительстве"

Нормативные документы	Дисциплина
Федеральные законы
№ 123-ФЗ "Технический регламент о требованиях пожарной безопасности"	ПБС, ЗДиС
№ 384-ФЗ " Технический регламент о пожарной безопасности зданий и сооружений"	ПБС, ЗДиС
№ 69-ФЗ "О пожарной безопасности"	ПБС
Постановления Правительства Российской Федерации
Постановление Правительства Российской Федерации № 272 "О порядке проведения расчетов по оценке пожарного риска"	ПБС
Постановление Правительства Российской Федерации № 304 "Об утверждении правил оценки соответствия объектов защиты (продукции) установленным требованиям пожарной безопасности путем независимой оценки пожарного риска"	ПБС
Приказы МЧС
Приказ МЧС РФ от 30.06.2009 г. № 382 "Об утверждении методики определения расчетных величин пожарного риска в зданиях и сооружениях различных классов функциональной пожарной опасности"	ПБС
Приказ МЧС РФ от 10.07.2009 г. № 404 "Об утверждении методики определения расчетных величин пожарного риска на производственных объектах"	ПБС
Своды правил
СП 1.13130.2009. "Системы противопожарной защиты. Эвакуационные пути и выходы"	ПБС
СП 2.13130.2009. "Системы противопожарной защиты. Обеспечение огнестойкости объектов защиты"	ПБС, ЗДиС
СП 4.13130.2009. "Системы противопожарной защиты. Ограничение распространения пожара на объектах защиты. Требования к объемно-планировочным и конструктивным решениям"	ПБС, ЗДиС
СП 7.13130.2009. "Отопление, вентиляция и кондиционирование. Противопожарные требования"	ПБС
СП 12.13130.2009. "Определение категорий помещений, зданий и наружных установок по взрывопожарной и пожарной опасности"	ПБС, ЗДиС
Национальные стандарты
ГОСТ 12.1.004-91. "Система стандартов безопасности труда. Пожарная безопасность. Общие требования"	ПБС, ЗДиС
ГОСТ 12.1.033-81*. "Пожарная безопасность. Термины и определения"	ЗДиС
ГОСТ 12.1.044-89. "Система стандартов безопасности труда. Пожаровзрывоопасность веществ и материалов. Номенклатура показателей и методы их определения"	ЗДиС
ГОСТ 30244-94. "Материалы строительные. Методы испытаний на горючесть"	ЗДиС
ГОСТ 30402-96. "Материалы строительные. Метод испытания на воспламеняемость"	ЗДиС
ГОСТ 30444-97. "Материалы строительные. Метод испытания на распространение пламени" (ГОСТ Р 51032-97)	ЗДиС
ГОСТ 30247.0-94. "Конструкции строительные. Методы испытаний на огнестойкость. Общие требования"	ЗДиС
ГОСТ 30247.1-94. "Конструкции строительные. Методы испытаний на огнестойкость. Несущие и ограждающие конструкции"	ЗДиС
ГОСТ 30247.2-97. "Конструкции строительные. Методы испытаний на огнестойкость. Двери и ворота"	ЗДиС
ГОСТ 30247.3-2002. "Конструкции строительные. Методы испытаний на огнестойкость. Двери шахт лифтов"	ЗДиС
ГОСТ 30403-96. "Конструкции строительные. Метод определения пожарной опасности"	ЗДиС
ГОСТ 31251-2008. "Стены наружные с внешней стороны. Метод испытаний на пожарную опасность" Актуализированная редакция ГОСТ 31251-2003	ЗДиС
ГОСТ Р 53292-2009. "Огнезащитные составы и вещества для древесины и материалов на ее основе"	ЗДиС
ГОСТ Р 53295-2009. "Средства огнезащиты для стальных конструкций. Общие требования. Метод определения огнезащитной эффективности"	ЗДиС
ГОСТ Р 53300-2009. "Противодымная защита зданий и сооружений. Методы приемосдаточных испытаний".	ПБС
ГОСТ Р 53301-2009. "Клапаны противопожарные вентиляционных систем. Метод испытаний на огнестойкость"	ПБС
ГОСТ Р 53302-2009. "Оборудование противодымной защиты зданий и сооружений. Вентиляторы. Метод испытаний на огнестойкость"	ПБС
ГОСТ Р 53303-2009. "Конструкции строительные. Противопожарные двери и ворота. Метод испытаний на дымогазопроницаемость"	ПБС, ЗДиС
ГОСТ Р 53304-2009. "Стволы мусоропроводов. Метод испытания на огнестойкость"	ПБС
ГОСТ Р 53305-2009. "Противодымные экраны. Метод испытаний на огнестойкость"	ПБС
ГОСТ Р 53307-2009. "Конструкции строительные. Противопожарные двери и ворота. Метод испытаний на огнестойкость"	ПБС, ЗДиС
ГОСТ Р 53308-2009. "Конструкции строительные. Светопрозрачные ограждающие конструкции и заполнения проемов. Метод испытаний на огнестойкость"	ПБС, ЗДиС
ГОСТ Р 53309-2009. "Здания и фрагменты зданий. Метод натурных огневых испытаний. Общие требования"	ПБС, ЗДиС
ГОСТ Р 53296-2009. "Установка лифтов для пожарных в зданиях и сооружениях. Требования пожарной безопасности"	ПБС
ГОСТ 21.1101-2009. "СПДС. Основные требования к проектной и рабочей документации"	ПБС
ГОСТ Р 53778-2010. "Здания и сооружения. Правила обследования и мониторинга технического состояния"	ПБС
Строительные нормы
СН 502-77 Инструкция по определению площади легкосбрасываемых конструкций (утратил силу)	ПБС
Стандарт СЭВ
СТ СЭВ 383-87. "Пожарная безопасность в строительстве. Термины и определения" (утратил силу)	ПБС, ЗДиС
Строительные нормы и правила
СНиП 21-01-97. "Пожарная безопасность зданий и сооружений" Взамен СНиП 2.01.02-85*. "Противопожарные нормы"	ПБС, ЗДиС
СП 42.13330.2011. "Градостроительство. Планировка и застройка городских и сельских поселений" СНиП 2.07.01-89* Актуализированная ред.	ПБС
СП 44.13330.2011. "Административные и бытовые здания" СНиП 2.09.04-87* Актуализированная редакция	ПБС, ЗДиС
СП 55.13330.2011. "Дома жилые одноквартирные" СНиП 31-02-2001 Актуализированная редакция	ПБС, ЗДиС
СП 54.13330.2011. "Здания жилые многоквартирные" СНиП 31-01-2003 Актуализированная редакция	ПБС, ЗДиС
СНиП 31-06-2009. "Общественные здания и сооружения" СНиП 2.08.02-89* Актуализированная редакция	ПБС, ЗДиС
СП 54.13330.2011. "Газораспределительные системы" СНиП 42-01-2002 Актуализированная редакция	ПБС
СНиП 31-05-2003. "Общественные здания административного назначения"	ПБС, ЗДиС
СП 56.13330.2011. "Производственные здания" СНиП 31-03-2001 Актуализированная редакция	ПБС, ЗДиС
СНиП 31-04-2001. "Складские здания"	ПБС, ЗДиС
СНиП 2.09.03-85*. "Сооружения промышленных предприятий"	ПБС, ЗДиС
СНиП 41-01-2003. "Отопление, вентиляция и кондиционирование"	ПБС
СНиП 2.10.03-84*. "Животноводческие, птицеводческие и звероводческие здания и помещения"	ПБС
СНиП 2.10.05-85. "Предприятия, здания и сооружения по хранению и переработке зерна"	ПБС
СНиП 10-01-94. "Система нормативных документов в строительстве. Основные положения" (Признан не действующим на территории РФ постановлением Госстроя России от 10.09.2003 г. № 164)	ПБС
СНиП 11-01-2003. "Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство предприятий, зданий и сооружений" Взамен СНиП 11-01-95	ПБС
СП 18.13330.2011. "Генеральные планы промышленных предприятий" СНиП II-89-80 Актуализированная редакция	ПБС
СП 19.13330.2011. "Генеральные планы сельскохозяйственных предприятий" СНиП II-97-76 Актуализированная редакция	ПБС
Пособие по определению пределов огнестойкости конструкций, пределом распространения огня по конструкциям и групп возгораемости материалов (к СНиП II-2-80)	ПБС, ЗДиС
Правила пожарной безопасности
ППБ 01-03 "Правила пожарной безопасности в Российской Федерации"	ПБС
Нормы пожарной безопасности
НПБ 105-03 "Определение категорий помещений, зданий и наружных установок по взрывопожарной и пожарной опасности"	ЗДиС

2.2.3 Требования к актуализированной базе данных

Успешное функционирование БД может быть осуществлено только при выполнении ряда требований к ее организации. К таким основным требованиям можно отнести следующие [58].

1. Расширяемость базы данных.

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

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

б) введения в БД новых типов объектов или новых типов взаимосвязей, например, между объектами "учебный предмет" и "студент" вводятся связи "оценка".

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

2. Простота работы с базой данных.

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

а) структура данных была логичной и ясной;

б) операции доступа к данным обладали ясными и четко очерченными функциями;

в) без больших трудозатрат выполнялись различные обслуживающие операции (копирование, перепись с носителя на носитель, расширение базы и др.).

3. Целостность базы данных.

Под целостностью базы данных в общем случае понимается ее готовность к работе. Целостность базы данных - сложное понятие, имеющее много аспектов. Укажем на следующие из них:

а) физическая целостность, т.е. сохранность информации на магнитных носителях и корректность форматов данных;

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

в) актуальность данных, т.е. соответствие данных реальному положению вещей.

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

4. Секретность данных.

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

Любой доступ к данным базы осуществляется через СУБД.

2.2.4 Структура СУБД

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

1. Описание данных

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

2. Манипулирование данными

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

3. Загрузка базы и формирование отчетов

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

4. Язык запросов

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

5. Диалоговые средства

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

В настоящее время существует множество различных СУБД.

Рынок корпоративных серверных СУБД представлен пакетами Oracle, MS SQL, DB2, Sybase и InterBase.

Первой коммерческой реляционной СУБД была Oracle, поддерживающая язык SQL, который впоследствии де-факто стал стандартом. Первая версия продукта появилась на свет в 1979 году. В наши дни компания является лидером рынка производителей коммерческих СУБД и, как написано на сайте [59], крупнейшим в мире поставщиком корпоративного программного обеспечения.

MS SQL - продукт известной всем фирмы Microsoft [60]. Первая версия была разработана совместно с Sybase в 1988 году и предназначалась только для платформы OS/2. Следующие версии этого продукты были созданы для NT-based систем и тесно интегрированы с ОС, что не удивительно. Для компании гораздо выгоднее, чтобы ее СУБД использовались на ее же операционной системе - так совместимость лучше.

DB2 Universal Database - это детище IBM [61], которое представляет собой серию продуктов для различных систем. Впервые проект появился на рынке в 1996 году. При переносе DB2 на другую платформу компания старается максимально эффективно использовать возможности этой платформы.

Изначально компания Sybase разрабатывала серверную СУБД совместно с Microsoft. В 1994 году компании разошлись и стали разрабатывать свои программные продукты независимо друг от друга. В результате у Sybase получился продукт под названием Adaptive Server Enterprise. Продукт существует под разные оси и предназначен для применения на крупных предприятиях. Существует еще одна линия серверных продуктов Sybase, которая ведет свое начало от СУБД Watcom SQL Anywhere [62]. Этот продукт называется SQL Anywhere Studio, отличается своей компактностью и простотой администрирования. Предназначен в основном для обслуживания небольших групп пользователей. Также существуют версии для применения в мобильных устройствах.

InterBase [63],[64] (продукт компании Borland Inc.) - это довольно компактная, устойчивая и производительная СУБД, способная работать на различных ОС. Визитная карточка системы - отсутствие острой необходимости напрягаться при разработке БД. Так как в другие пакеты этой фирмы (например, Delphi) встроены весьма удобные средства для разработки приложений на базе Interbase. Продукт стал популярным вследствие того, что долгое время распространялся бесплатно вместе со средствами разработки. Но вскоре проект Interbase стал платным.

Существует также немало бесплатных СУБД. Особого внимания достойны два представителя этого вида (как наиболее распространенные): MySQL и PostgreSQL [65]. Обе СУБД довольно динамично развиваются и повсеместно используются, так как не просят за себя денег. Продолжаются и еще не скоро утихнут бурные споры о том, какая СУБД лучше. Обе системы очень стабильны, гибки и производительны. У каждой есть свои плюсы и минусы.

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

PostgreSQL - мощная и "тяжелая" система, отвечающая всем современным стандартам СУБД. Она больше подходит для серьезных проектов, требующих сложных баз данных. По скорости работы PostgreSQL уступает MySQL. При этом администрирование PostgreSQL является трудоемким. PostgreSQL относится к группе это реляционно-объектных СУБД; она имеет некоторые расширения для работы с таблицами, на которые можно легко отображать иерархии объектов. Но это еще не совсем объектная СУБД.

Выбор СУБД существенно зависит от поставленной задачи. Ассортимент услуг, которые предлагают описанные выше СУБД, в основном приходится на "клиент-серверную" архитектуру. Но кроме больших корпораций, которым необходима серверная технология СУБД, существуют еще и маленькие фирмы, которым нет смысла ставить дорогостоящий сервер в одном углу офиса, а компьютер-клиент - в другом. Для этого и используют локальные (настольные) СУБД. Основные представители этого рынка: Microsoft Access, Paradox, Visual FoxPro и dBase [66],[67],[68],[69].

Сходства и различия. Изначально компании сами создавали свои форматы файлов баз данных и свои языки программирования для работы с этими БД. Однако вскоре пользователи и разработчики стали ощущать потребность в стандартизации. Производителям пришлось сделать свои интерфейсы открытыми (типа ADO, BDE, ODBC, JDBC и т.д.). Другими словами, ко всем СУБД можно получить доступ по одному и тому же интерфейсу. Стандартным языком для БД стал SQL 92. Каждый производитель вносил в него свои изменения и улучшения, но любая СУБД поддерживает классический SQL. На данный момент этот язык не полностью удовлетворяет требованиям разработчиков, так как он не объектный, а процедурный. Существует еще язык QBE, который тоже поддерживают современные СУБД и является языком запросов по образцу. Проще говоря, в этом языке запросы формируют визуально. В SQL же запросы пишутся в текстовом формате.

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

Наиболее ярким примером реального проекта является Open Source - форум phpBB [70]. Многие крупные компании (например, Greenball Corporation, Fujitsu Siemens Computers) используют в своей работе различные СУБД. Базы данных имеют все крупные финансовые учреждения (банки).

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

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

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

2.2.5 Алгоритм создания электронной базы данных

Для создания электронной базы данных в работе использовались две бесплатные программы: Microsoft HTML Help Workshop и HTM2CHM. HTM2CHM - небольшая авторская программа [71]. Она обладает русским интерфейсом и интуитивно понятна. С помощью данной программы можно преобразовывать не только отдельные HTML страницы со всевозможными изображениями, но и целые сайты в единый CHM, либо ITS файл. Данные файлы открываются стандартными службами Windows и весят несколько меньше HTML-файлов с аналогичным содержанием.

CHM - это расширение файла в формате Compressed HTML Help. Формат был разработан Microsoft для гипертекстовых справочных систем. Для просмотра CHM файлов достаточно наличия в системе Internet Explorer. У CHM файлов, как правило, есть Содержание - отдельная панель со списком статей для упрощения навигации. В наличии содержания, пожалуй и заключается главное отличие CHM файлов от использовавшихся ранее HLP файлов справки Windows.

В настоящей работе применен следующий алгоритм создания электронной базы:

- выбор электронной оболочки;

- создание и редактирование HTML файлов;

- определение содержания;

- создание и генерация содержания;

- создание нового проекта;

- заполнение проекта HTML файлами;

- настройка внешнего вида CHM файла;

- редактирование настроек закладок;

- создание индекса (указателя);

- компиляция в программе HTM2CHM;

- создание CHM файла.

Данная программа HTM2CHM дает возможность достаточно быстро и обходя проблемы совершать конвертацию файлов в Compiled HTML (CHM). Такой вид формата достаточно удобен тем, что он мал по объемам и его гораздо проще просмотреть, в отличии от формата PDF. Используемый интерфейс в программе достаточно прост и почти лишен исполнения дизайна. Все доступные функции, выполняемые HTM2CHM представляют собой компилирование HTML файлов. А качество выполнения функций программы является достаточно высоким. При детальном рассмотрении, файлы, которые планируется конвертировать в CHM, необходимо перевести в формат HTML. При этом подходит не любой HTML: в веб-странице без фильтра программа не сможет увидеть некоторые страницы. Для создания гипертекстовых разделов (HTML-страниц) проекта использовался HTML-редактор (Microsoft FrontPage 2003). Frontpage позволяет вам создавать страницы профессионального качества, при этом, не требуя от вас знания тонкостей HTML. Работа в Редакторе Frontpage весьма похожа на работу с текстовым процессором, подобным Microsoft Word. Также легко создаёт гиперссылки. Одна из главных достоинств программы заключается в ее умении представлять страницы в режиме WYSIWYG (what you see is what you get - что видите, то и получаете). Это означает, что в браузере они будут выглядеть так же, как и в Редакторе. Frontpage позволяет одновременно открывать несколько страниц. Редактор также позволяет скопировать страницу (вместе со всем кодом HTML) из Internet и отредактировать ее. Это удобно, когда вы хотите быстро получить информацию с различных сайтов.

Изложенное ниже Руководство по применению (Приложение 1) применимо к созданию любого CHM файла, обладающего древовидной структурой отображения страниц в содержании, индексом, полнотекстовым поиском с поддержкой логических операторов и возможностью добавления страниц в избранное. Предполагается, что все HTML страницы, которые необходимо включить в CHM, уже подготовлены: в них работают все внутренние ссылки и отображаются картинки и прочие объекты. Описание касается создания и компиляции CHM файла.

3. Разработка электронной базы данных для изучения дисциплин "Пожарная безопасность в строительстве" и "Здания, сооружения и их устойчивость при пожаре"

3.1 Преимущества использования предлагаемой модели создания электронной базы документов

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

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

- простота выполнения базовых операций;

- оперативный доступ к электронным документам;

- создание каталога документов с определенной иерархией;

- распределение информации по типу документов;

- удобное хранение документов в электронном виде;

- поиск документа по каталогу;

- стабильная скорость работы с документами;

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

- пополнение новыми документами и замена актуализированными версиями документов;

- возможность расширения базы документов.

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

3.2 Основные этапы создания базы данных

Основные этапы создания базы данных изложены в форме Руководства по применению программных средств (приложение 1), которое имеет следующую структуру:

- создание содержания;

- генерация содержания;

- создание нового проекта;

- добавление HTML файлов и файла содержания;

- настройка внешнего вида CHM файла;

- изменение свойств проекта;

- создание индекса;

- компиляция программой HTM2CHM;

- создание CHM файла.

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

- запуск стартовой страницы;

- переход к тексту документа;

- поиск документов;

- использование дополнительных функций.

4. Экономическая часть

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

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

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

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

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

4.1.1 Расчет сетевого графика хода выполнения дипломной работы

Расчет сетевого графика выполнения дипломной работы включает два последовательных этапа:

- определение содержания и перечня работ, выполнение которых позволит достичь цели исследования. Перечень должен охватывать весь процесс выполнения исследовательской работы;

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

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

Таблица 4.1

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

Код события	Наименование события	Код работы	Наименование работы
1	2	3	4
1	Задание на диплом выдано	1 - 2	Ознакомление с заданием
2	Выбор метода и определение вида научно-исследователь- ской работы	2 - 3	Разработка и согласование сетевого графика выполнения исследования
3	Сетевой график разработан	3 - 4	Изучение литературы по теме исследования
4	Анализ литературы завершен	3 - 5	Написание литобзора
5	Литобзор написан	5 - 6 4 - 6	Исследование методов создания электронных баз данных. Фиктивная работа
6	Процесс исследования методов завершен	6 - 7 4 - 7	Разработка структуры электронного каталога для базы. Продолжение изучения
7	Структура электронного каталога разработана	7 - 8	Опробование работы электронной базы
8	Опробование работы базы завершено	7 - 9 8 - 9	Заполнение электронной базы данными. Фиктивная работа
9	Электронная база заполнена	9 - 10	Разработка инструкции пользователя
10	Инструкция пользователя разработана	10 - 11	Оценка затрат на выполнение работы по созданию электронной базы данных
11	Затраты на выполнение работы по созданию электронной базы данных оценены	11 - 12	Оформление пояснительной записки
			Проверка пояснительной записки консультантами и руководителем
12	Пояснительная записка написана	12 - 13	Проверка пояснительной записки консультантами и руководителем
13	Пояснительная записка проверена	13 - 14	Подготовка к докладу, изготовление слайдов
14	Слайды к докладу подготовлены	14 - 15	Подготовка к предварительной защите
15	Работа к предварительной защите готова	15 - 16	Рецензирование работы
16	Рецензия на работу получена	15 - 17 16 - 17	Подготовка к защите
17	Работа к защите на ГЭК готова	-	-

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

, (4.1)

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

i предшествующее событие (i = 1, 2, ..., n - 1);

j последующее событие (j = 1, 2, 3, ..., n);

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

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

Любая предварительная оценка содержит некоторый риск, степень которого определяется среднеквадратичным отклонением (дисперсией):

. (4.2)

Величина дисперсии отражает неопределенность оценки.

Для расчетов режим работы курсанта принимается семичасовой при шестидневной рабочей неделе.

Результаты временной оценки приведены в таблице 4.2.

Таблица 4.2

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

Код работы i - j	Наименование работы	Временная оценка длительности работы, дни	Ожидаемое время выполнения работы , дни	Дисперсия

1 - 2	Ознакомление с заданием	2	3	2	0,028
2 - 3	Разработка и согласование сетевого графика выполнения исследования	2	3	2	0,028
3 - 4	Изучение литературы по теме исследования	8	9	8	0,028
3 - 5	Написание литобзора	4	5	5	0,028
5 - 6	Исследование методов создания электронных баз данных.	4	5	5	0,028
4 - 6	Фиктивная работа	0	0	0	0
6 - 7	Разработка структуры электронного каталога для базы.	5	6	6	0,028
4 - 7	Продолжение изучения	9	10	10	0,028
7 - 8	Опробование работы электронной базы	2	3	2	0,028
7 - 9	Заполнение электронной базы данными.	15	16	16	0,028
8 - 9	Фиктивная работа	0	0	0	0
9 - 10	Разработка инструкции пользователя	14	15	15	0,028
10 - 11	Оценка затрат на выполнение работы по созданию электронного каталога	3	4	4	0,028
11 - 12	Оформление пояснительной записки	4	5	5	0,028
12 - 13	Проверка пояснительной записки консультантами и руководителем	4	5	5	0,028
12 - 14	Подготовка к докладу, изготовление слайдов.	6	7	7	0,028
13 - 15	Фиктивная работа	0	0	0	0
14 - 15	Подготовка к предварительной защите	2	3	3	0,028
15 - 16	Рецензирование работы	3	4	4	0,028
15 - 17	Подготовка к защите	4	5	5	0,028
16 - 17	Фиктивная работа	0	0	0	0

По данным таблицы 4.2 строится сетевой график выполнения дипломной работы (рисунок 4.1). Длительность отдельных работ в днях указана над стрелками.

tкр = 75 дней

Рисунок 4.1 - Сетевой график выполнения дипломной работы

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

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

Параметры сетевого графика:

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

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

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

. (4.3)

Время раннего начала последующей работы (j k) равно времени раннего окончания предшествующей (i j):

. (4.4)

Если данной работе предшествует несколько операций, то время раннего начала равно максимальному времени раннего окончания предшествующих работ.

Время раннего окончания последней работы сетевой модели характеризует путь наибольшей длины между начальным и конечным событиями и называется критическим путем (tкр), а лежащие на нем работы - критическими.

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

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

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

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

. (4.5)

Частный резерв времени - время, в пределах которого можно увеличить продолжительность операции без изменения раннего срока начала любой из работ, следующих за данной, - равен разности между временем раннего начала следующей операции (j k) и ранним окончанием данной работы (i - j):

. (4.6)

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

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

На рисунке 4.1 критический путь выделен жирными стрелками.

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

Таблица 4.3

Расчет параметров сетевого графика

Количество предшествующих работ	Код работы	Продолжительность работы , дни	Ранние сроки, дни	Поздние сроки, дни	Резервы времени, дни

0	1 - 2	2	0	2	0	2	0	0
1	2 - 3	2	2	4	2	4	0	0