Анализ среды программирования Delphi

 

Введение

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

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

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

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

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

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

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

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

Другие фирмы идут по пути создания мощных по своим возможностям инструментальных оболочек, с помощью которых можно в довольно сжатые сроки создать большое количество электронных учебников, наполняя "пустую" оболочку текстовыми и графическими материалами. Современные оболочки предусматривают возможность доступа к внешним ресурсам Интернет (выход в поисковые системы и базы данных, работу с тематическими сайтами), участия в телеконференциях и чатах с преподавателями. Значительное место в подобных учебниках занимает тестирование. Очень важным является то, что при использовании инструментальных оболочек удается организовать одновременную работу с ними большого количества обучаемых, что является затруднительным при использовании WWW-технологий. В настоящее время подобные инструментальные оболочки создаются практически в каждом российском университете, занимающемся развитием системы дистанционного обучения с использованием Интернет-технологий (например, в известном Московском государтвенном университете экономики, статистики и информатики, МЭСИ). Также созданием подобных инструментальных оболочек-программ занимаются уже несколько лет такие известные фирмы-разработчики программного обеспечения как Oracle, Lotus, IBM, Maris Multimedia и др.



1. Основные идеи положенные в основу программы


Основанием для разработки программы послужила идея создания некоторого гибрида между просмотрщиком (BROWSERом) документов и базой данных для их структурированного хранения, поиска необходимой информации по тематическим разделам и ключевым словам. Также было признано необходимым включить в просмотрщик особый элемент интерфейса облегчающий навигацию внутри документа. В качестве такого элемента решено использовать иерархическое дерево заголовков - пунктов документов. Пример подобного дерева можно увидеть в стандартном «проводнике» операционной системы Windows (рис. 1.1), где оно используется для навигации по дискам и директориям компьютера.


Рис. 1.1 Проводник Windows


Интерфейс программы было решено разделить на две части:

  • Интерфейс пользователя
  • Интерфейс администратора

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

Языком программирования, на котором реализовано приложение, выбран продукт фирмы Borland - Delphi 5 обоснование выбора и описание языка приведены в главе 2. СРЕДА ПРОГРАММИРОВАНИЯ DELPHI.

Посредником между приложением и базой данных используется стандартный процессоре баз данных Borland Database Engine 4 описание которого приведено в главе 4. ПРОЦЕССОР БАЗ ДАННЫХ ФИРМЫ BORLAND.

Полученное в результате разработки приложение и связанная с ним база данных описаны в главе 5. ОПИСАНИЕ ПРОГРАММЫ.



2. Среда программирования Delphi

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


2.1 Основные характеристики продукта

- это комбинация нескольких важнейших технологий:

  • Высокопроизводительный компилятор в машинный код
  • Объектно-ориентированная модель компонент
  • Визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов
  • Масштабируемые средства для построения баз данных
  • Компилятор в машинный код
  • Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в архитектуре "клиент-сервер". Этот компилятор в настоящее время является самым быстрым в мире, его скорость компиляции составляет свыше 120 тысяч строк в минуту на компьютере 486DX33. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода (хотя это возможно).
  • В процессе построения приложения разработчик выбирает из палитры компонент готовые компоненты как художник, делающий крупные мазки кистью. Еще до компиляции он видит результаты своей работы - после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде. В этом смысле проектирование в Delphi мало чем отличается от проектирования в интерпретирующей среде, однако после выполнения компиляции мы получаем код, который исполняется в 10-20 раз быстрее, чем то же самое, сделанное при помощи интерпретатора. Кроме того, компилятор компилятору рознь, в Delphi компиляция производится непосредственно в родной машинный код, в то время как существуют компиляторы, превращающие программу в так называемый p-код, который затем интерпретируется виртуальной p-машиной. Это не может не сказаться на фактическом быстродействии готового приложения.
  • 2.2 Объектно-ориентированная модель программных компонент
  • Основной упор этой модели в Delphi делается на максимальном реиспользовании кода. Это позволяет разработчикам строить приложения весьма быстро из заранее подготовленных объектов, а также дает им возможность создавать свои собственные объекты для среды Delphi. Никаких ограничений по типам объектов, которые могут создавать разработчики, не существует. Действительно, все в Delphi написано на нем же, поэтому разработчики имеют доступ к тем же объектам и инструментам, которые использовались для создания среды разработки. В результате нет никакой разницы между объектами, поставляемыми Borland или третьими фирмами, и объектами, которые мы можем создать.
  • В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. Для начала - неплохо. Но если возникнет необходимость в решении какой-то специфической проблемы на Delphi, прежде чем попытаться начинать решать проблему "с нуля", желательно просмотреть список свободно распространяемых или коммерческих компонент, разработанных третьими фирмами, количество этих фирм в настоящее время превышает число 250, хотя, я не обо всех знаю. Скептики, возможно, не поверят мне, когда я скажу, что на Delphi можно одинаково хорошо писать как приложения к корпоративным базам данных, так и, Например, игровые программы. Тем не менее, это так. Во многом это объясняется тем, что традиционно в среде Windows было достаточно сложно реализовывать пользовательский интерфейс. Событийная модель в Windows всегда была сложна для понимания и отладки. Но именно разработка интерфейса в Delphi является самой простой задачей для программиста.
  • 2.3 Быстрая разработка работающего приложения из прототипов
  • Конечно, на разработку серьезной информационно-поисковой системы в архитектуре клиент-сервер может уйти гораздо большее время, чем на разработку программы-игрушки. Тем не менее многие коллеги, до Delphi программировавшие на других языках, утверждают, что на Delphi скорость изготовления сложного проекта выше раз в 10.
  • Cреда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений (RAD - rapid application development), поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных. VCL - библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление DDE и OLE. Единственное, что можно поставить в вину Delphi, это то, что готовых компонент, поставляемых Borland, могло бы быть и больше. Однако, разработки других фирм, а также свободно распространяемые программистами компоненты уже восполнили этот недостаток. Подобное было в Visual Basic.
  • Соответствующий стандарт компонент назывался VBX. И этот стандарт так же поддерживается в Delphi. Однако, визуальные компоненты в Delphi обладают большей гибкостью. Вспомним, в чем была проблема в VB. Прикладной программист программировал, вообще говоря, в среде языка бэйсик. А компоненты в стандарте VBX готовили ему коллеги - профессиональные программисты на языке С++.
  • VBX-компоненты поставлялись, "как есть", и ни исправить, ни добавить ничего было нельзя.
  • Для изготовления VBX надо было осваивать язык C++. В Delphi визуальные компоненты пишутся на Object Pascal, на том же «паскале», на котором пишется алгоритмическая часть приложения. И визуальные компоненты Delphi получаются открытыми для надстройки и переписывания.
  • 2.4 Масштабируемые средства для построения баз данных
  • Объекты баз данных (БД) в Delphi основаны на языке SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к системам управления базами данных (СУБД) Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме (т.е. в режиме без использования сети). Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (Например, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер.
  • Вот она - масштабируемость на практике - одно и то же приложение можно использовать как для локального, так и для более серьезного клиент-серверного вариантов.
  • 2.5 Delphi - два варианта поставки
  • Теперь можно перейти к описанию собственно продукта. Что лежит внутри в коробке, и чем может воспользоваться программист при разработке прикладной системы? Выпущены две версии Delphi - одна (Delphi Client-Server) адресована для разработчиков приложений в архитектуре "клиент-сервер", а другая (Delphi for Windows) предназначена для остальных программистов. Приложения, разработанные при помощи Delphi, можно использовать без выплаты процентов и без оплаты лицензий.
  • 2.5.1 Клиент-серверная версия Delphi
  • Она адресована корпоративным разработчикам, желающим разрабатывать высокопроизводительные приложения для рабочих групп и корпоративного применения.
  • Клиент-серверная версия включает в себя следующие особенности:
  • SQL Links: специально написанные драйвера для доступа к Oracle, Sybase, Informix, InterBase
  • Локальный сервер InterBase: SQL-сервер для Windows 3.1. СУБД для разработки в корпоративных приложений на компьютере, не подключенном к локальной сети.
  • ReportSmith Client/server Edition: генератор отчетов для SQL-серверов
  • Team Development Support: предоставляет версионный контроль при помощи PVCS компании Intersolve (приобретается отдельно) или при помощи других программных продуктов версионного контроля
  • Visual Query Builder - это средство визуального построения SQL-запросов
  • исходные тексты всех визуальных компонент
  • 2.5.2 Delphi для Windows
  • Delphi для Windows представляет из себя подмножество Delphi Client-Server и предназначен для разработчиков высокопроизводительных персональных приложений, работающих с локальными СУБД типа dBase и Paradox.Delphi Desktop Edition предлагает такую же среду для быстрой разработки и первоклассный компилятор как и клиент-серверная версия (Client/Server Edition). Эта среда позволяет разработчику быстро изготавливать персональные приложения, работающие с персональными СУБД типа dBase и Paradox. Delphi позволяет также создавать разработчику DLL, которая может быть вызвана из Paradox, dBase, C++ или каких-нибудь других готовых программ.
  • В Delphi for Windows, как и в Delphi Client-Server, входят:
  • компилятор Object Pascal (этот язык является расширением языка Borland Pascal 7.0)
  • среда визуального построителя приложений
  • библиотека визуальных компонент
  • Локальный сервер InterBase
  • В этом обзоре стоит упомянуть еще один продукт, выпущенный компанией Borland для Delphi. Это учебник по Object Pascal, интерактивный отладчик самой последней версии, Borland Visual Solutions Pack (набор VBX для реализации редакторов, электронных таблиц, коммуникационные VBX, VBX с деловой графикой и т.п.), Resource WorkShop для работы с ресурсами Borland Pascal 7.0, а также дельфийский эксперт для преобразования ресурсов BP 7.0 в формы Delphi.
  • 2.6 Для кого предназначен Delphi
  • В первую очередь Delphi предназначен для профессионалов-разработчиков корпоративных информационных систем. Может быть, здесь следует пояснить, что конкретно имеется в виду. Не секрет, что некоторые удачные продукты, предназначенные для скоростной разработки приложений (RAD - rapid application development) прекрасно работают при изготовлении достаточно простых приложений, однако, разработчик сталкивается с непредвиденными сложностями, когда пытается сделать что-то действительно сложное. Бывает, что в продукте вскрываются присущие ему ограничения только по прошествии некоторого времени.
  • Delphi такие ограничения не присущи. Хорошее доказательство тому - это тот факт, что сам Delphi разработан на Delphi. Однако Delphi предназначен не только для программистов-профессионалов.
  • Руководители предприятий, планирующие выделение средств на приобретение программных продуктов, должны быть уверены в том, что планируемые инвестиции окупятся. Поэтому одним из оцениваемых факторов должен быть вопрос - а легко ли найти специалиста по Delphi и сколько будет стоить его обучение, сколько времени специалист затратит на овладение продуктом. Ответ здесь получить весьма просто - любой программист на языке Pascal способен практически сразу профессионально освоить Delphi. Специалисту, ранее использовавшему другие программные продукты, придется труднее, однако самое первое работающее приложение он сможет написать в течение первого же часа работы на Delphi. И, конечно же, открытая технология Delphi является мощным гарантом того, что инвестиции, сделанные в Delphi, будут сохранены в течение многих лет.
  • 2.7 Некоторые особенности Delphi
  • 2.7.1 Локальный сервер InterBase
  • Этот инструмент предназначен только для автономной отладки приложений. В действительности он представляет из себя сокращенный вариант обработчика SQL-запросов InterBase, в который не включены некоторые возможности настоящего сервера InterBase. Отсутствие этих возможностей с лихвой компенсируется преимуществом автономной отладки программ.
  • 2.7.2 Team Development Support
  • Средство поддержки разработки проекта в группе. Позволяет существенно облегчить управление крупными проектами.
  • Высокопроизводительный компилятор в машинный код. В отличие от большинства Pascal -компиляторов, транслирующих в p-код, в Delphi программный текст компилируется непосредственно в машинный код, в результате чего Delphi- приложения исполняются в 10-20 раз быстрее (особенно приложения, использующие математические функции). Готовое приложение может быть изготовлено либо в виде исполняемого модуля, либо в виде динамической библиотеки, которую можно использовать в приложениях, написанных на других языках программирования.
  • 2.7.3 Открытая компонентная архитектура
  • Благодаря такой архитектуре приложения, изготовленные при помощи Delphi, работают надежно и устойчиво. Delphi поддерживает использование уже существующих объектов, включая DLL, написанные на С и С++, OLE сервера, VBX, объекты, созданные при помощи Delphi. Из готовых компонент работающие приложения собираются очень быстро. Кроме того, поскольку Delphi имеет полностью объектную ориентацию, разработчики могут создавать свои повторно используемые объекты для того, чтобы уменьшить затраты на разработку.
  • Delphi предлагает разработчикам - как в составе команды, так и индивидуальным - открытую архитектуру, позволяющую добавлять компоненты, где бы они ни были изготовлены, и оперировать этими вновь введенными компонентами в визуальном построителе.
  • 2.7.4 Two-way tools
  • Однозначное соответствие между визуальным проектированием и классическим написанием текста программы. Это означает, что разработчик всегда может видеть код, соответствующий тому, что он построил при помощи визуальных инструментов и наоборот.
  • Визуальный построитель интерфейсов (Visual User-interface builder) дает возможность быстро создавать клиент-серверные приложения визуально, просто выбирая компоненты из соответствующей палитры.
  • 2.7.5 Библиотека визуальных компонентов
  • Эта библиотека объектов включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление DDE и OLE.
  • 2.7.6 Структурное объектно-ориентированное программирование
  • Delphi использует структурный объектно-ориентированный язык (Object Pascal), который сочетает с одной стороны выразительную мощь и простоту программирования, характерную для языков 4GL, а с другой стороны эффективность языка 3GL. Программисты немедленно могут начать производить работающие приложения, и им не придется для этого изучать особенности программирования событий в Windows. Delphi полностью поддерживает передовые программные концепции включая инкапсуляцию, наследование, полиморфизм и управление событиями.
  • 2.8 Delphi: настраиваемая среда разработчика
  • 2.8.1 Палитра компонент
  • После запуска Delphi в верхнем окне горизонтально располагаются иконки палитры компонент. Если курсор задерживается на одной из иконок, под ней в желтом прямоугольнике появляется подсказка (рис.2.1).
  • Палитра компонент.
  • Рис.2.1
  • Из этой палитры компонент можно выбирать компоненты, из которых можно строить приложения. Компоненты включают в себя как визуальные, так и логические компоненты. Такие вещи, как кнопки, поля редактирования - это визуальные компоненты; а таблицы, отчеты - это логические.
  • Понятно все эти компоненты имеют свое графическое представление в поле форм для того, чтобы можно было бы ими соответствующим образом оперировать. Но для работающей программы видимыми остаются только визуальные компоненты. Компоненты сгруппированы на страницах палитры по своим функциям. Например, компоненты, представляющие исполняемые диалоги Windows все размещены на странице палитры с названием "Dialogs".
  • Delphi позволяет разработчикам настроить среду для максимального удобства. Можно легко изменить палитру компонент, инструментальную линейку, а также настраивать выделение синтаксиса цветом.
  • Заметим, что в Delphi можно определить свою группу компонент и разместить ее на странице палитры, а если возникнет необходимость, перегруппировать компоненты или удалить неиспользуемые.
  • 2.8.2 Интеллектуальный редактор
  • Delphi обладает мощнейшим, встроенным в редактор графическим отладчиком, позволяющим находить и устранять ошибки в коде. Можно установить точки останова, проверить и изменить переменные, при помощи пошагового выполнения в точности понять поведение программы. Если же требуются возможности более тонкой отладки, можно использовав Turbo Debugger, проверить ассемблерные инструкции и регистры процессора.(рис.2.2 и рис.2.3).
  • Редактор кода.
  • Рис.2.2
  • Рис. 2.3. Turbo Debugger
  • 2.8.3 Инспектор объектов
  • Этот инструмент представляет собой отдельное окно, где мы можем в период проектирования программы устанавливать значения свойств и событий объектов (рис.2.4).
  • Рис. 2.4. Инспектор объектов
  • 2.8.4 Менеджер проектов
  • Дает возможность разработчику просмотреть все модули в соответствующем проекте и снабжает удобным механизмом для управления проектами.
  • Менеджер проектов показывает имена файлов, время/дату выбранных форм и пр. (рис.2.5).
  • Рис. 2.5 Менеджер проектов
  • Можно немедленно попасть в текст или форму, просто щелкнув мышкой на соответствующее имя.
  • 2.8.5 Эксперты
  • Это набор инструментальных программ, облегчающих проектирование и настройку Ваших приложений.
  • Есть возможность подключать самостоятельно разработанные эксперты. Потенциально это та возможность, при помощи которой третьи фирмы могут расширять Delphi CASE-инструментами, разработанными специально для Delphi.
  • Включает в себя:
  • Эксперт форм, работающих с базами данных
  • Эксперт стилей и шаблонов приложений
  • Эксперт шаблонов форм

.9 Написание кода программы


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

Такая синхронизация и делает Delphi two-way-инструментом, обеспечивая полное соответствие между кодом и визуальным представлением. Как только мы добавим новый объект или код, Delphi устанавливает т.н. "кодовую синхронизацию" между визуальными элементами и соответствующими им кодовыми представлениями.

Например, необходимо добавить обработчик событий, чтобы показывать окно сообщения по нажатию кнопки. Описание обработчика появляется, если дважды щелкнуть мышкой непосредственно на объект Button в форме или дважды щелкнуть мышью на строчку OnClick на странице Events в Инспекторе объектов. В любом случае Delphi создаст процедуру или заголовок метода, куда можно добавить код.


procedure TForm1.Button1Click(Sender: TObject);

begin;

Cоздавая этот код, Delphi автоматически формирует декларацию объекта TForm1, которая содержит процедуру ButtonClick, представляющую из себя собственно обработчик события.


TForm1 = class (TForm): Tbutton;1Click(Sender: TObject);


Конечно, можно решить после получения этого кода, что автоматически созданные имена нас не устраивают, и заменить их. Например, Button1 на Warning. Это можно сделать, изменив свойство Name для Button1 при помощи Инспектора объектов. Как только мы нажмем Enter, Delphi автоматически произведет соответствующую синхронизацию в коде. Так как объект TForm1 существует в коде, мы свободно можем добавлять любые другие поля, процедуры и функции. Например, мы можем дописать в коде свою собственную процедуру, обрабатывающую событие, а не делать это визуальным методом.

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


TForm1 = class(TForm): TButton;: TButton;WarningClick(Sender: TObject);NewHandler(Sender: TObject);

{ Private declarations }

{ Public declarations };


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


2.9.1 Добавление новых объектов

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

Последовательность введения новой компоненты состоит из трех шагов:

  1. наследование из уже существующего типа компоненты
  2. определение новых полей, свойств и методов
  3. регистрация компоненты

Это все делается через меню Install Components


.9.2 Делегирование

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

Такая модель в некоторых случаях значительно упрощает программирование. Например, когда мы добавляем кнопку в форму и прикрепляете код, обрабатывающий нажатие, вы фактически используете делегирование кода для ассоциирования кода с событием OnClick. Такая ассоциация происходит для вас автоматически. Если проверить страницу Events в Инспекторе объектов для вашего приложения, можно увидеть ассоциированные с событиями процедуры.

2.9.3 Ссылки на классы

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


.9.4 Обработка исключительных ситуаций

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

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

Обработка исключений реализована в виде exception-handling blocks (также еще называется protected blocks), которые устанавливаются ключевыми словами try и end. Существуют два типа таких блоков: try...except и try...finally.

Общая конструкция выглядит примерно так:


try

{ выполняемые операторы }exception1 do statement1;

{ реакция на ситуации }exception2 do statement2;

else

{ операторы по умолчанию };


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


{ выполняемые операторы }

{ операторы, выполняемые безусловно };


2.10 О составе Delphi


В составе Delphi входит 5 интерактивных обучающих систем, документация в электронном виде и около 10 Мб справочной информации:

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

3. Базы данных


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

Мы будем рассматривать только реляционные базы данных: во-первых, реляционные базы получили наибольшее распространение в мире; во-вторых, они наиболее «продвинуты» в научном плане; а в-третьих, ядро баз данных Borland Database Engine, на основе которого работают все последние продукты компании Borland, предназначено именно для работы с реляционными базами данных.

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

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


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


Итак, хорошо спроектированная база данных:

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

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

Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более «прозрачными» и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.

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

Следующие пункты представляют основные шаги проектирования базы данных:

  • Определить информационные потребности базы данных.
  • Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности «деталь» характеристиками могут быть «название», «цвет», «вес» и т.п.) и сформировать их список:
  • Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной СУБД.
  • Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
  • Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
  • Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.
  • 3.2 Основные концепции реляционных баз данных
  • В реляционной теории одним из главных является понятие отношения. Математически отношение определяется следующим образом. Пусть даны n-множеств D1,D2,...,Dn. Тогда R есть отношение над этими множествами, если R есть множество упорядоченных наборов вида <d1,d2,...,dn>, где d1 - элемент из D1, d2 - элемент из D2, ..., dn - элемент из Dn. При этом наборы вида <d1,d2,...,dn> называются кортежами, а множества D1,D2,...,Dn - доменами. Каждый кортеж состоит из элементов, выбираемых из своих доменов. Эти элементы называются атрибутами, а их значения - значениями атрибутов (рис.3.1).

  • Рис. 3.1. Отношение
  • Легко заметить, что отношение является отражением некоторой сущности реального мира (в данном случае - сущности «деталь») и с точки зрения обработки данных представляет собой таблицу. Поскольку в локальных базах данных каждая таблица размещается в отдельном файле, то с точки зрения размещения данных для локальных баз данных отношение можно отождествлять с файлом. Кортеж представляет собой строку в таблице (запись). Атрибут же является полем в записи. Домен же представляется неким обобщенным типом, столбцом таблицы, который для типов полей в записи. Таким образом, следующие тройки терминов являются эквивалентными:
  • отношение, таблица, файл (для локальных баз данных)
  • кортеж, строка, запись
  • атрибут, столбец, поле.
  • Реляционная база данных представляет собой совокупность отношений, содержащих всю необходимую информацию и объединенных различными связями.
  • Атрибут (или набор атрибутов), который может быть использован для однозначной идентификации конкретного кортежа (строки, записи), называется первичным ключом. Первичный ключ не должен иметь дополнительных атрибутов. Это значит, что если из первичного ключа исключить произвольный атрибут, оставшихся атрибутов будет недостаточно для однозначной идентификации отдельных кортежей. Для ускорения доступа по первичному ключу во всех системах управления базами данных (СУБД) имеется механизм, называемый индексированием. Индекс представляет собой инвертированный древовидный список, указывающий на истинное местоположение записи для каждого первичного ключа. Естественно, в разных СУБД индексы реализованы по-разному (в локальных СУБД - как правило, в виде отдельных файлов), однако, принципы их организации одинаковы.
  • Возможно индексирование отношения с использованием атрибутов, отличных от первичного ключа. Данный тип индекса называется вторичным индексом и применяется в целях уменьшения времени доступа при нахождении данных в отношении, а также для сортировки. Таким образом, если само отношение не упорядочено каким-либо образом и в нем могут присутствовать строки, оставшиеся после удаления некоторых кортежей, то индекс (для локальных СУБД - индексный файл), напротив, отсортирован.
  • Для поддержания ссылочной целостности данных во многих СУБД имеется механизм так называемых внешних ключей. Смысл этого механизма состоит в том, что некоему атрибуту (или группе атрибутов) одного отношения назначается ссылка на первичный ключ другого отношения; тем самым закрепляются связи подчиненности между этими отношениями. При этом отношение, на первичный ключ которого ссылается внешний ключ другого отношения, называется master-отношением, или главным отношением; а отношение, от которого исходит ссылка, называется detail-отношением, или подчиненным отношением. После назначения такой ссылки СУБД имеет возможность автоматически отслеживать вопросы «ненарушения» связей между отношениями, а именно:
  • если попытаться вставить в подчиненную таблицу запись, для внешнего ключа которой не существует соответствия в главной таблице (например, там нет еще записи с таким первичным ключом), СУБД сгенерирует ошибку;
  • если попытаться удалить из главной таблицы запись, на первичный ключ которой имеется хотя бы одна ссылка из подчиненной таблицы, СУБД также сгенерирует ошибку.
  • если попытаться изменить первичный ключ записи главной таблицы, на которую имеется хотя бы одна ссылка из подчиненной таблицы, СУБД также сгенерирует ошибку.
Существует два подхода к удалению и изменению записей из главной таблицы:

  1. Запретить удаление всех записей, а также изменение первичных ключей главной таблицы, на которые имеются ссылки подчиненной таблицы.
  2. Распространить всякие изменения в первичном ключе главной таблицы на подчиненную таблицу, а именно:
  3. если в главной таблице удалена запись, то в подчиненной таблице должны быть удалены все записи, ссылающиеся на удаляемую;
  4. если в главной таблице изменен первичный ключ записи, то в подчиненной таблице должны быть изменены все внешние ключи записей, ссылающихся на изменяемую.
  5. Итак, после того как мы ознакомились с основными понятиями реляционной теории, можно перейти к детальному рассмотрению шагов проектирования базы данных, которые мы перечислили ниже.
  6. 3.3 Шаги проектирования базы данных
  7. 3.3.1 Определение информационных потребностей базы данных
  8. Включает в себя опрос будущих пользователей для того, чтобы понять и задокументировать их требования. Следует выяснить следующие вопросы:
  9. сможет ли новая система объединить существующие приложения или их необходимо будет кардинально переделывать для совместной работы с новой системой;
  10. какие данные используются разными приложениями; смогут ли приложения совместно использовать какие-либо из этих данных;
  11. кто будет вводить данные в базу и в какой форме; как часто будут изменяться данные;
  12. достаточно ли будет для предметной области одной базы или потребуется несколько баз данных с различными структурами;
  13. какая информация является наиболее чувствительной к скорости ее извлечения и изменения.
  14. 3.3.2 Анализ объектов реального мира
  15. Анализируются объекты, которые необходимо смоделировать в базе данных.
  16. Формирование концептуальной модели базы данных включает в себя:
  17. идентификацию функциональной деятельности предметной области. Например, если речь идет о деятельности предприятия, то в качестве функциональной деятельности можно идентифицировать ведение учета работающих, отгрузку продукции, оформление заказов и т.п.
  18. идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс «ведение учета работающих» идентифицирует такие сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.
  19. идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата.
  20. идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.
  21. 3.3.3 Создание таблиц базы данных
  22. Установление соответствия между сущностями и характеристиками предметной области; отношениями и атрибутами в нотации, выбранной СУБД. Поскольку каждая сущность реального мира обладает некими характеристиками, в совокупности образующими полную картину ее проявления, можно поставить им в соответствие набор отношений (таблиц) и их атрибутов (полей).
  23. Перечислив все отношения и их атрибуты, уже на этом этапе можно начать устранять излишние позиции. Каждый атрибут должен появляться только один раз; и мы должны решить, какое отношение будет являться владельцем какого набора атрибутов.
  24. 3.3.4 Определение первичных ключей
  25. Определяются атрибуты, которые уникальным образом идентифицируют каждый объект. Это необходимо для того, чтобы система могла получить любую единичную строку таблицы. Мы должны определить первичный ключ для каждого из отношений. Если нет возможности идентифицировать кортеж с помощью одного атрибута, то первичный ключ нужно сделать составным - из нескольких атрибутов. Хорошим примером может быть первичный ключ в таблице работников, состоящий из фамилии, имени и отчества. Первичный ключ гарантирует, что в таблице не будет содержаться двух одинаковых строк. Во многих СУБД имеется возможность помимо первичного определять еще ряд уникальных ключей. Отличие уникального ключа от первичного состоит в том, что уникальный ключ не является главным идентифицирующим фактором записи и на него не может ссылаться внешний ключ другой таблицы. Его главная задача - гарантировать уникальность значения поля.
  26. 3.3.5 Выработка правил поддерживающих целостность данных
  27. Будучи определенными, такие правила в клиент-серверных СУБД поддерживаются автоматически - сервером баз данных; в локальных же СУБД их поддержание приходится возлагать на пользовательское приложение.
  28. Эти правила включают:
  29. определение типа данных
  30. выбор набора символов, соответствующего данной стране
  31. создание полей, опирающихся на домены
  32. установка значений по умолчанию
  33. определение ограничений целостности
  34. определение проверочных условий.
  35. 3.3.6 Установление связи между таблицами и столбцами
  36. Каждый из различных типов связей должен быть смоделирован в базе данных.
  37. Существует несколько типов связей:
  38. связь «один-к-одному»
  39. связь «один-ко-многим»
  40. связь «многие-ко-многим».
  41. Связь «один-к-одному» представляет собой простейший вид связи данных, когда первичный ключ таблицы является в то же время внешним ключом, ссылающимся на первичный ключ другой таблицы. Такую связь бывает удобно устанавливать тогда, когда невыгодно держать разные по размеру (или по другим критериям) данные в одной таблице. Например, можно выделить данные с подробным описанием изделия в отдельную таблицу с установлением связи «один-к-одному» для того чтобы не занимать оперативную память, если эти данные используются сравнительно редко.
  42. Связь «один-ко-многим» в большинстве случаев отражает реальную взаимосвязь сущностей в предметной области. Она реализуется уже описанной парой «внешний ключ-первичный ключ», т.е. когда определен внешний ключ, ссылающийся на первичный ключ другой таблицы. Именно эта связь описывает широко распространенный механизм классификаторов. Имеется справочная таблица, содержащая названия, имена и т.п. и некие коды, причем, первичным ключом является код. В таблице, собирающей информацию - назовем ее информационной таблицей - определяется внешний ключ, ссылающийся на первичный ключ классификатора. После этого в нее заносится не название из классификатора, а код. Такая система становится устойчивой от изменения названия в классификаторах. Имеются способы быстрой «подмены» в отображаемой таблице кодов на их названия как на уровне сервера БД (для клиент-серверных СУБД), так и на уровне пользовательского приложения. Но об этом - в дальнейших уроках.
  43. Связь «многие-ко-многим» в явном виде в реляционных базах данных не поддерживается. Однако имеется ряд способов косвенной реализации такой связи, которые с успехом возмещают ее отсутствие. Один из наиболее распространенных способов заключается во введении дополнительной таблицы, строки которой состоят из внешних ключей, ссылающихся на первичные ключи двух таблиц. Например, имеются две таблицы: КЛИЕНТ и ГРУППА_ИНТЕРЕСОВ. Один человек может быть включен в различные группы, в то время как группа может объединять различных людей. Для реализации такой связи «многие-ко-многим» вводится дополнительная таблица, назовем ее КЛИЕНТЫ_В_ГРУППЕ, строка которой будет иметь два внешних ключа: один будет ссылаться на первичный ключ в таблице КЛИЕНТ, а другой - на первичный ключ в таблице ГРУППА_ИНТЕРЕСОВ. Таким образом, в таблицу КЛИЕНТЫ_В_ГРУППЕ можно записывать любое количество людей и любое количество групп.
  44. Очень важная операция для исключения избыточности данных - нормализация таблиц. После определения таблиц, полей, индексов и связей между таблицами следует посмотреть на проектируемую базу данных в целом и проанализировать ее, используя правила нормализации, с целью устранения логических ошибок. Важность нормализации состоит в том, что она позволяет разбить большие отношения, как правило, содержащие большую избыточность информации, на более мелкие логические единицы, группирующие только данные, объединенные «по природе». Таким образом, идея нормализации заключается в следующем. Каждая таблица в реляционной базе данных удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное значение, и никогда не может быть множества таких значений.
  45. После применения правил нормализации логические группы данных располагаются не более чем в одной таблице. Это дает следующие преимущества:
  46. данные легко обновлять или удалять
  47. исключается возможность рассогласования копий данных
  48. уменьшается возможность введения некорректных данных.

Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ). С практической точки зрения, достаточно трех первых форм - следует учитывать время, необходимое системе для «соединения» таблиц при отображении их на экране. Этот процесс включает:

  • устранение повторяющихся групп (приведение к 1НФ)
  • удаление частично зависимых атрибутов (приведение к 2НФ)
  • удаление транзитивно зависимых атрибутов (приведение к 3НФ).

Рассмотрим каждый из этих процессов подробней.


.3.7 Приведение к первой нормальной форме

Когда поле в данной записи содержит более одного значения для каждого вхождения первичного ключа, такие группы данных называются повторяющимися группами. 1НФ не допускает наличия таких многозначных полей. Рассмотрим пример базы данных предприятия, содержащей таблицу ОТДЕЛ (табл. 3.1) со следующими значениями (атрибут «Номер_отдела» является первичным ключом):


Таблица 3.1

ОТДЕЛНомер_отделаНазваниеРуководительБюджетРасположение100продаж0001000000Москва100продаж0001000000Зеленоград600разработок1201100000Тверь100продаж0001000000Калуга

Для приведения этой таблицы к 1НФ мы должны устранить атрибут (поле) «Расположение» из таблицы ОТДЕЛ и создать новую таблицу РАСПОЛОЖЕНИЕ_ОТДЕЛОВ (табл. 3.2), в которой определить первичный ключ, являющийся комбинацией номера отдела и его расположения (Номер_отдела+Расположение). Теперь для каждого расположения отдела существуют различные строки; тем самым мы устранили повторяющиеся группы.


Таблица 3.2

РАСПОЛОЖЕНИЕ_ОТДЕЛОВНомер_отделаРасположение100Москва100Зеленоград600Тверь100Калуга

3.3.8 Приведение ко второй нормальной форме

Следующий важный шаг в процессе нормализации состоит в удалении всех неключевых атрибутов, которые зависят только от части первичного ключа. Такие атрибуты называются частично зависимыми. Неключевые атрибуты заключают в себе информацию о данной сущности предметной области, но не идентифицируют ее уникальным образом. Например, предположим, что мы хотим распределить работников по проектам, ведущимся на предприятии. Для этого создадим таблицу ПРОЕКТ (табл.3.3)с составным первичным ключом, включающим номер работника и идентификатор проекта (Номер_работника+ИД_проекта).


Таблица 3.3

ПРОЕКТНомер _работникаИД_проектаФамилияНазв_проектаОписание_проектаПродукт28БРЖИвановБиржа<blob>программа17ДОКПетровДокументы<blob>программа06УПРСидоровУправление<blob>адм.меры

В этой таблице возникает следующая проблема. Атрибуты Назв_проекта, Описание_проекта и Продукт относятся к проекту как сущности и, следовательно, зависят от атрибута ИД_проекта (являющегося частью первичного ключа), но не от атрибута Номер_работника. Следовательно, они являются частично зависимыми от составного первичного ключа. То же самое можно сказать и об атрибуте Фамилия, который зависит от атрибута Номер_работника, но не зависит от атрибута ИД_проекта. Для нормализации этой таблицы (приведения ее в 2НФ) удалим из нее атрибуты Номер_работника и Фамилия и создадим другую таблицу (назовем ее РАБОТНИК_В_ПРОЕКТЕ), которая будет содержать только эти два атрибута, и они же будут составлять ее первичный ключ.


3.3.9 Приведение к третьей нормальной форме

Третий этап процесса приведения таблиц к нормальной форме состоит в удалении всех неключевых атрибутов, которые зависят от других неключевых атрибутов. Каждый неключевой атрибут должен быть логически связан с атрибутом (атрибутами), являющимся первичным ключом. Предположим, например, что мы добавили поля Номер_руководителя и Телефон в таблицу ПРОЕКТ, находящуюся в 2НФ (первичным ключом является поле ИД_проекта). Атрибут Телефон логически связан с атрибутом Номер_руководителя, неключевым полем, но не с атрибутом ИД_проекта, являющимся первичным ключом (табл.3.4).


Таблица 3.4

ПРОЕКТ(2)ИД_проектаНомер _руководителяТелефонНазв_проектаОписание _проектаПродуктБРЖ022-21Биржа<blob>ПрограммаДОК122-43Документы<blob>ПрограммаУПР082-56Управление<blob>адм.меры

Для нормализации этой таблицы (приведения ее в 3НФ) удалим атрибут Телефон, изменим Номер_руководителя на Руководитель и сделаем атрибут Руководитель внешним ключом, ссылающимся на атрибут Номер_работника (первичный ключ) в таблице РАБОТНИКИ. После этого таблицы ПРОЕКТ и РАБОТНИКИ будут выглядеть следующим образом (табл. 3.5 и табл. 3.6 соответственно).


Таблица 3.5

ПРОЕКТ(3)ИД_проектаРуководительНазв_ проектаОписание_проектаПродуктБРЖ02Биржа<blob>ПрограммаДОК12Документы<blob>ПрограммаУПР08Управление<blob>адм.меры

Таблица 3.6

РАБОТНИКИНомер _работ.ФамилияИмяОтчествоНомер _отделаКод _профес.ТелефонЗарплата04ИвановИванИванович100Инж2-69-5008ПетровПетрПетрович200Мндж2-10-0023СидоровИванПетрович200Мндж2-48-00

Теперь, когда мы научились проводить нормализацию таблиц с целью устранения избыточного дублирования данных и группирования информации в логически связанных единицах, необходимо сделать ряд замечаний по вопросам проектирования баз данных. Необходимо четко понимать, что разбиение информации на более мелкие единицы с одной стороны, способствует повышению надежности и непротиворечивости базы данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя) на обратное «соединение» таблиц при представлении информации на экране. Иногда для достижения требуемой производительности нужно сделать отход от канонической нормализации, при этом ясно осознавая, что необходимо обеспечить меры по предотвращению противоречивости в данных. Поэтому всякое решение о необходимости того или иного действия по нормализации можно принимать только тщательно проанализировав предметную область и класс поставленной задачи. Может потребоваться несколько итераций для достижения состояния, которое будет желаемым компромиссом между четкостью представления и реальными возможностями техники. Здесь уже начинается искусство.


3.3.10 Вопросы надежности и секретности

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

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

4. Процессор баз данных фирмы borland


Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). В принципе, сейчас не различают эти два названия (BDE и IDAPI) и считают их синонимами. BDE позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC.

Все инструментальные средства баз данных Borland - Paradox, dBase, Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или dBase, «наследуются» BDE, и поэтому этими же особенностями обладает и Delphi.


4.1 Псевдоним пути к таблицам базы данных


Таблицы сохраняются в базе данных. Некоторые СУБД сохраняют базу данных в виде нескольких отдельных файлов, представляющих собой таблицы (в основном, все локальные СУБД), в то время как другие состоят из одного файла, который содержит в себе все таблицы и индексы (InterBase). Например, таблицы dBase и Paradox всегда сохраняются в отдельных файлах на диске. Директорий, содержащий dBase .DBF файлы или Paradox .DB файлы, рассматривается как база данных. Другими словами, любой директорий, содержащий файлы в формате Paradox или dBase, рассматривается Delphi как единая база данных. Для переключения на другую базу данных нужно просто переключиться на другой директорий. Как уже было указано выше, InterBase сохраняет все таблицы в одном файле, имеющем расширение .GDB, поэтому этот файл и есть база данных InterBase.

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

Для создания алиаса необходимо запустить утилиту конфигурации BDE (программу BDECFG.EXE), находящуюся в директории, в котором располагаются динамические библиотеки BDE.

При установке Delphi BDECFG.EXE инсталлируется по умолчанию.

Главное окно утилиты настройки BDE имеет вид, изображенный на рис.4.1.




Рис. 4.1. Главное окно настройки BDE


Для создания алиаса необходимо выбрать пункт меню «Object / New…». В появившемся диалоговом окне выберите его тип (тип базы данных) из выпадающего списка. Тип алиаса может быть стандартным (STANDARD) для работы с локальными базами в формате dBase или Paradox или соответствовать наименованию SQL-сервера (InterBase, Sybase, Informix, Oracle и т.д.).

После создания нового алиаса его имя появится в списке алиасов на той же страничке «All Databases Aliases». Однако просто создать алиас не достаточно. Нам нужно указать дополнительную информацию, содержание которой зависит от типа выбранной базы данных. Например, для баз данных Paradox и dBase (STANDARD) требуется указать лишь путь доступа к данным:


Таблица 3.1

Дополнительная информация для баз данных STANDARDTYPESTANDARDPATHc:\users\data

SQL-сервер InterBase требует задания десяти параметров, многие из которых можно оставить установленными по умолчанию (кроме, обычно, параметров SERVER NAME и USER NAME):


Таблица 3.2

Дополнительная информация для баз данных InterBaseTYPEINTRBASEPATHSERVER NAMEMyserv:g:\users\contacts.gdbUSER NAMESYSDBAOPEN MODEREAD/WRITESCHEMA CACHE SIZE8LANGDRIVERPdox ANSI CyrillicSQLQRYMODESQLPASSTHRU MODESHARED AUTOCOMMITSCHEMA CACHE TIME-1

В этом примере база данных CONTACTS.GDB размещается в директории USERS, находящемся на диске G Windows NT сервера, называющегося MYSERV. Имя пользователя при связи с базой данных по этому алиасу - SYSDBA. Остальные параметры - LANGDRIVER, SQLQRYMODE, SQLPASSTHRU MODE, SCHEMA CACHE SIZE и SCHEMA CACHE TIME рассмотрим подробней.

Параметр LANGDRIVER определяет языковый драйвер для доступа к базе данных. Для правильной работы с русскими буквами при работе с базой данных формата dBase нужно выбрать значение «dBASE RUS cp866», при работе с базами данных формата Paradox и SQL-серверами (в том числе InterBase) - «Pdox ANSI Cyrillic». Кроме того, на этапе создания базы данных InterBase необходимо указать CHARACTER SET (набор символов) WIN1251.

Параметр SQLQRYMODE появляется только в случае, если установлен Borland SQL Links для связи с SQL-серверами. Он определяет режим передачи SQL-запросов и может иметь три значения:(пустая строка - режим по умолчанию) - запрос сначала посылается на SQL-сервер. Если сервер не может выполнить запрос, последний обрабатывается локально (это актуально для распределенных баз данных);- запрос посылается на SQL-сервер. Если сервер не может выполнить запрос, генерируется ошибка;- запрос всегда выполняется на рабочей станции.

Параметр SQLPASSTHRU MODE определяет, могут ли запросы, передаваемые для выполнения на сервер и стандартные вызовы BDE обрабатываться в одном и том же сеансе соединения с базой данных - быть «SHARED». Он также может иметь три значения:AUTOCOMMIT (значение по умолчанию) - для каждой операции по одной строке таблицы автоматически стартует неявная транзакция, которая, в случае успеха, завершается оператором COMMIT (закрепляющим произведенные изменения). Такой подход наилучшим образом подходит для работы с локальными базами, но неэффективен для SQL-серверных баз данных, так как стартующие каждый раз новые транзакции значительно загружают сетевой трафик.NOAUTOCOMMIT - приложение должно явно стартовать и завершать транзакцию. Эта установка может привести к конфликтам в многопользовательской среде, где большое количество пользователей пытаются обновить одну и ту же строку таблицы.SHARED - означает, что запросы, передаваемые для выполнения на сервер (переход с SQL), и стандартные вызовы BDE (методы Delphi) используют раздельные соединения с базой данных. Для управления транзакциями через « переход с SQL « необходимо устанавливать именно это значение, иначе « переход с SQL « и методы Delphi могут интерферировать друг с другом, что, в свою очередь, может привести к непредсказуемым результатам.

В параметре SCHEMA CACHE SIZE указывается число таблиц базы данных, информация о структуре которых будет кэшироваться, обеспечивая быстрый доступ к метаданным. Значение этого параметра может быть целым числом от 0 до 32. По умолчанию установлено число 8.

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

(значение по умолчанию) - информация из таблиц кэшируется до самого закрытия базы данных;

- информация из таблиц вообще не кэшируется;

- 2,147,483,647 - информация из таблиц кэшируется в течение указанного времени (в секундах).

Установки по умолчанию параметров SQLQRYMODE, SQLPASSTHRU MODE, SCHEMA CACHE SIZE и SCHEMA CACHE TIME обеспечивают достаточно оптимальный режим работы с базой данных. Экспериментировать с ними для достижения наибольшей эффективности работы с конкретной базой данных желательно только после накопления некоторого опыта работы с BDE.

Остановимся подробней на задании такого важного параметра, как SERVER NAME. В нем нужно указать не только имя сервера (на котором находится Ваша база данных) и полный путь доступа к базе, но и сетевой протокол. Создатели утилиты настройки BDE не сочли нужным выделять протокол в отдельный параметр, поэтому необходимо использовать следующие выражения:

  • для доступа по протоколу TCP/IP - IB_SERVER:PATH\DATABASE.GDB. Например, путь к базе на Windows NT сервере будет выглядеть следующим образом - mynt:c:\ib\base.gdb, а к базе на UNIX-сервере - myunix:/ib/base.gdb;
  • для доступа по протоколу IPX/SPX - IB_SERVER@PATH\DATABASE.GDB. (Например: mynw@sys:ib\base.gdb)
  • для доступа по протоколу NETBEUI - \\IB_SERVER\PATH\DATABASE.GDB. (Например: \\mynt\c:\ib\base.gdb)

В этих примерах mynt - имя сервера Windows NT, myunix - имя сервера UNIX-системы, mynw - имя сервера Novell NetWare, sys - имя тома NetWare, ib - директорий, в котором находится база данных, base.gdb - имя базы данных InterBase. Для того чтобы правильно указать имя сервера Oracle, нужно писать имя по правилам Oracle - перед именем поставить @.

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


4.2 Системная информация утилиты настройки BDE


Итак, мы познакомились с наиболее важной возможностью утилиты настройки BDE - созданием и редактированием алиасов, определяющих параметры доступа к базам данных. Однако, утилита настройки BDE позволяет специфицировать не только алиасы, но и драйверы для доступа к базам данных, а также различную системную информацию, составляющую операционное окружение этих самых алиасов. Системная информация располагается на странице Configuration в пунктах «Date», «Time», «Number». Рассмотрим их подробнее.



4.2.1 Пункт Date

Определяет установки, используемые при преобразовании строковых значений в дату и обратно. Основаны на значениях, устанавливаемых для каждой страны и зафиксированных в файле WIN.INI (секция [intl]). Однако, все параметры формата даты, времени и чисел BDE берет не из конфигурационного файла BDE, куда попадают данные установки, а из соответствующих переменных модуля SysUtils. По-видимому, эта ситуация произошла по недосмотру разработчиков.

Среди параметров даты имеются следующие:

  • SEPARATOR - символ, используемый для разделения дня, месяца и года в дате. Ему соответствует переменная DateSeparator (Char*). Обычно имеет значения ., -, /. Значение по умолчанию берется из параметра sDate секции [intl] файла WIN.INI.
  • MODE - управляет порядком следования месяца, дня и года в дате и может иметь значения: 0 - для MDY (месяц-день-год), 1 - для DMY (день-месяц-год), или 2 - для YMD (год -месяц-день). Прямого соответствия переменным модуля SysUtils не имеет. Вместо него, а также вместо параметров FOURDIGITYEAR, YEARBIASED, LEADINGZEROM и LEADINGZEROD используются переменные ShortDateFormat (string[15]) и LongDateFormat (string[31]). В этих переменных могут применяться только символ-разделитель дат (DateSeparator) и символьные выражения типа m, mm, d, dd, yy и yyyy, определяющие месяц, день и год. Например, формат «короткой» даты может выглядеть как «dd.MM.yy», а формат «длинной» даты - как «d MMMM yyyy 'г.'«. Значения по умолчанию берутся из параметров sShortDate и sLongDate секции [intl] файла WIN.INI. Здесь уместно сделать небольшое замечание. При отображении даты и времени в качестве символа-разделителя можно использовать любой символ, в том числе и отличный от символа DateSeparator (или TimeSeparator). Однако при попытке вставить в таком формате дату или время BDE «выдаст» ошибку, связанную с неправильным форматом даты/времени. Поэтому для корректной вставки данных в таблицы необходимо, чтобы в переменной ShortDateFormat символ-разделитель совпадал с символом DateSeparator, а в переменной LongTimeFormat (и ShortTimeFormat) - с символом TimeSeparator.

4.2.2 Пункт Time

Определяет установки, используемые при конвертации строковых значений во время и обратно. Также основаны на значениях, устанавливаемых для каждой страны и зафиксированных в файле WIN.INI (секция [intl]). Аналогично дате, для формата времени совместно с ShortDateFormat используются переменные LongTimeFormat (обращаем внимание - именно LongTimeFormat, а не ShortTimeFormat) и TimeSeparator. Значения по умолчанию вычисляются по параметрам iTime и iTLZero секции [intl] файла WIN.INI. Кроме указанных переменных, для форматирования можно использовать переменные TimeAMString (основана на параметре s1159 секции [intl]) и TimePMString (основана на параметре s2359 секции [intl]).


4.2.3 Пункт Number

Описывает трактовку чисел BDE. В частности, определяет символ для десятичной точки (переменная DecimalSeparator, основана на параметре sDecimal секции [intl]), разделитель для тысяч (переменная ThousandSeparator, основана на параметре sThousand секции [intl]), количество знаков после запятой (переменная CurrencyDecimals, основана на параметре sCurrDigits секции [intl]) и наличие лидирующих нулей.


4.2.4 Дополнительно о системной информации

Как уже отмечалось выше, утилита настройки BDE сохраняет всю конфигурационную информацию в файле IDAPI.CFG. Этот файл с предустановленными ссылками на драйверы и некоторыми стандартными алиасами создается при установке Delphi.



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


.1 Интерфейс пользователя


Главное окно программы «Магистр», которое появляется при запуске представлено на рис. 5.1.

Главное окно программы «Магистр»


Рис. 5.1


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

  • Главного меню;
  • Панели Поиск документов;
  • Панели Навигация по документу;
  • Окна навигации;
  • Окна отображения текста.

5.1.1 Главное меню

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


.1.1.1 Пункт Файл

Пункт меню Файл


Рис. 5.2


Команды «Открыть файл» и «Сохранить файл» не требуют особых пояснений, заметим лишь, что они доступны только администратору, а пользователь их не видит. Команда «Администратор» вызывает появление диалогового окна ввод пароля после которого появляется окно администратора (подробнее в пункте 5.2 Интерфейс администратора).

Команда «Выход» закрывает приложение. Как видно на рис. 2.2 ей назначена горячая клавиша F10


.1.1.2 Пункт Правка

Пункт меню Правка


Рис. 5.3

Команды этого пункта стандартны для всех текстовых редакторов и не требуют пояснений. Пункт меню «Правка» дублируется всплывающим меню, которое появляется при нажатии правой кнопки мыши в окне редактирования (просмотра) текста.


5.1.1.3 Пункт Вид

Пункт меню Вид



Рис. 5.4


Как видно на рисунке (рис. 5.4) команды Документы и Поиск являются бинарными переключателями (обычный стиль Windows когда результат действия команды зависит от ее предыдущего состояния). В данном случае команды отвечают за наличие (отсутствие) панелей инструментов, если флажок перед командой присутствует, то соответствующая панель есть. Иначе нет.

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

Команда Показать администратора служит для переключения между окнами просмотрщика и администратора (она бывает удобна если они перекрывают друг на друга и нет возможности сделать активным нужное окно с помощью щелчка мыши). Этой команде присвоена комбинация «горячих» клавиш Ctrl+W.


5.1.1.4Пункт Поиск


Пункт меню Поиск


Рис. 5.5

Команда «Найти документ» запускает поисковое окно (рис. 5.6) в котором предоставляется список документов, в которых обнаружено искомое словосочетание. Тема запроса (группа файлов, в которых будет проводиться поиск) выбирается с помощью выпадающего списка. Опция Искать позволяет произвести поиск по всей базе данных.

Поиск документов


Рис. 5.6


Команда Найти в документе запускает стандартный диалог поиска в документе (рис. 5.7).



Диалоговое окно поиск


Рис. 5.7


5.1.1.5 Пункт Навигация

Пункт меню Навигация


Рис. 5.8


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

Команда Выбрать документ открывает окно позволяющее просмотреть распределенные по темам документы (рис. 5.9) и выбрать один из них.

Команды: Предыдущий документ и Следующий документ используются соответственно для перехода к предыдущему и последующему документу. Если переходить некуда (текущий документ открыт первым или последним) то эти подпункты меню становятся неактивными.

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

Выбор документа


Рис. 5.9


.1.1.6 Пункт Справка

Пункт меню Справка


Рис. 5.10


В этом пункте меню находятся две команды: Помощь и О программе. Первый открывает файл помощи, который описывает программу, а второй запускает окно О программе (рис. 5.11)



О программе


Рис. 5.11


5.1.2 Панели инструментов

Кнопки на панелях инструментов частично дублируют команды главного меню (наиболее часто используемые из них), поэтому повторно не описываются. Также на панелях присутствуют выпадающие списки. В первом отображается открытый документ и тема к которой он приписан, а во втором активированный пункт содержания открытого документа. Эти списки аналогичны используемому в Internet Explorer, и также как и там с их помощью можно выбрать наиболее часто использовавшиеся документы.

Панели инструментов


Рис. 5.12


5.1.3 Окно текста

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

5.1.4 Окно навигации

Этот элемент интерфейса представляет собой иерархическое дерево, где заголовок верхнего уровня является родительским узлом заголовков более нижнего уровня (рис. 5.13).

Окно навигации


Рис. 5.13


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

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

5.2 Интерфейс администратора


Для получения доступа к интерфейсу администратора необходимо запустить программу «Магистр» и выполнить команду Файл ® Администратор (можно просто нажать клавишу F1). После чего появиться окно ввода пароля (рис. 5.14).


Рис. 5.14. Ввод пароля


Далее необходимо ввести правильный пароль. Если пароль введен неверно, то появиться соответствующее сообщение (рис. 5.15). Оно реализованно стандартной функцией Windows - MessageBox.


Рис. 5.15. Ошибка


После введения верного пароля появиться рабочее окно администратора (рис. 5.16).


Окно администратора


Рис. 5.16


В рабочей зоне окна находятся следующие объекты:


.2.1 Главное меню


.2.1.1 Команда Сменить пароль

Производиться вызов соответствующего диалогового окна (рис. 5.17а). После введения правильного пароля оно преобразовывается в другое (рис. 5.17б) куда и вводиться пароль и его подтверждение

пароля (1)


Рис. 5.17а

Рис. 5.17б. Изменение пароля (2)


.2.1.2 Команда Связать

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


.2.1.3 Команда Закрыть

Закрывает форму администратора.


5.2.1.4 Команда Показать главное окно

Переключает на главное окно (аналогична команде просмотрщика

Вид ® Показать администратора Ctrl+W).


5.2.2 Кнопки

Дублируют соответствующие команды меню.


.2.3 Панель навигации

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


.2.4 Таблицы

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


5.3 Структура базы данных


База данных состоит из пяти таблиц формата *.dbf и подключена к приложению через BDE с псевдонимом Browser. Доступ к ней осуществляется с помощью модуля данных DM (рис. 5.18). Он создается в оперативной памяти при запуске программы, и находиться там, невидимый оператору, все время ее работы. В отличие от него остальные окна создаются динамически (по мере надобности) и разрушаются, когда они больше не нужны. Что экономит ресурсы компьютера.


Рис. 5.18 Модуль данных


В первой таблице (1.dbf один кортеж ADMIN, одна запись) находиться пароль доступа к окну администрирования. Обращение к этой таблице производиться из окон ввода пароля и при замене пароля.

Во второй таблице (2.dbf рис. 5.16 слева) один столбец SUBJECT в котором содержаться все темы имеющиеся в наличие.

В третьей таблице (3.dbf табл. 5.1) три столбца:

  • уникальные имена файлов FILE_NAME;
  • имена текстов TEXT_NAME;
  • темы к которым принадлежат тексты SUBJECT.
  • Таблица 5.1

Таблица номер триFILE_NAMETEXT_NAMESUBJECT213434545Программирование в среде TurboPascal 7.0Программирование114545454DELPHI 5Программирование455454545C++ Builder 5 Средство разработчика.Программирование545522155Программирование в среде TURBOPASCAL 7.0Программирование155452254C++ BUILDERПрограммирование

  • В четвертой таблице (4.dbf табл. 5.2) два столбца:
  • уникальные имена файлов FILE_NAME;
  • заголовки пунктов текста формируемые при внесении документа в базу данных из окна навигации.
  • Таблица 5.2

Таблица номер четыреFILE_NAMETITLE213434545Ядро программы114545454Модуль455454545Модуль545522155Библиотека155452254Стандарты

  • В пятой таблице (5.dbf табл. 5.3) два столбца:
  • ключевые слова из документа (определяются по частоте включения в текст) WORD;
  • файлы в которых содержаться данные слова FILES.

Таблица 5.3

Таблица номер пятьWORDFILSEделфи213434545@635745634@238943054@4756445745@паскаль114545454@754574849@оператор455454545@403896596@230248556@0432548558@переменная545522155@434747685@475456855@8695865966@константа155452254@943758675@856756756@

Схема связей между таблицами приведена на рисунке 5.19.


Рис. 5.19. Связи между таблицами базы данных



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


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

Безопасность функционирования химически опасных объектов (ХОО) зависит от многих факторов: физико-химических свойств сырья, полупродуктов и продуктов, от характера технологического процесса, от конструкции и надежности оборудования, условий хранения и транспортирования химических веществ, состояния контрольно-измерительных приборов и средств автоматизации, эффективности средств противоаварийной защиты и т. д. Кроме того, безопасность производства, использования, хранения и перевозок АХОВ в значительной степени зависит от уровня организации профилактической работы, своевременности и качества планово-предупредительных ремонтных работ, подготовленности и практических навыков персонала, системы надзора за состоянием технических средств противоаварийной защиты.

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

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

Необходимо отметить, что на промышленных объектах обычно сосредоточено значительное количество различных легковоспламеняющихся веществ, в том числе АХОВ. Кроме того, многие АХОВ взрывоопасны, а некоторые хотя и негорючи, но представляют значительную опасность в пожарном отношении. Это обстоятельство следует учитывать при возникновении пожаров на предприятиях. Более того, сам пожар на предприятиях может способствовать выделению различных ядовитых веществ.

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

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

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

В связи с этим защита от АХОВ организуется по возможности заблаговременно, а при возникновении аварий проводится в минимально возможные сроки.

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

Комплекс мероприятий по защите от АХОВ включает:

  • инженерно-технические мероприятия по хранению и использованию АХОВ;
  • подготовку сил и средств для ликвидации химически опасных аварий;
  • обучение их порядку и правилам поведения в условиях возникновения аварий;
  • обеспечение средствами индивидуальной и коллективной защиты;
  • обеспечение безопасности людей и использование ими средств индивидуальной и коллективной защиты;
  • повседневный химический контроль;
  • прогнозирование зон возможного химического заражения;
  • предупреждение (оповещение) о непосредственной угрозе поражения АХОВ;
  • временную эвакуацию из угрожаемых районов;
  • химическую разведку района аварии;
  • поиск и оказание медицинской помощи пострадавшим;
  • локализацию и ликвидацию последствий аварии.

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

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

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

В разделе организационных мероприятий плана защиты от АХОВ отражаются:

  • характеристика объекта, его подразделений (цехов), имеющихся на объекте АХОВ;
  • оценка возможной обстановки на объекте в случае возникновения аварии;
  • организация выявления и контроля химической обстановки на объекте в повседневных условиях и при аварии, порядок поддержания сил и средств химической разведки и химического контроля;
  • организация оповещения персонала объекта;
  • организация укрытия персонала объекта в защитных сооружениях, имеющихся на объекте, порядок поддержания их в постоянной готовности к укрытию людей;
  • организация эвакуации персонала объекта при необходимости;
  • порядок оснащения и применения невоенизированных формирований Гражданской обороны на объекте для ликвидации последствий аварии;
  • организация оцепления очага поражения, порядок оказания медицинской помощи, привлекаемые для этой цели силы и средства;
  • организация управления силами и средствами объекта при ликвидации аварии и её последствий, порядок использования сил и средств, прибывающих для оказания помощи в ликвидации последствий аварии;
  • порядок представления донесений о возникновении химически опасной аварии и ходе ликвидации её последствий;
  • организация обеспечения персонала объекта и невоенизированных формирований Гражданской обороны средствами индивидуальной защиты и ликвидации последствий аварии, порядок и сроки их накопления и хранения;
  • организация транспортного, энергетического и материально-технического обеспечения работ по ликвидации последствий аварии.

В разделе инженерно-технических мероприятий плана защиты от АХОВ отражаются:

размещение (оборудование) устройств, предотвращающих утечку АХОВ в случае аварии (клапаны-отсекатели, клапаны избыточного давления, терморегуляторы, перепускные или сбрасывающие устройства и т.д.);

планируемое усиление конструкций ёмкостей и коммуникаций со АХОВ или устройства над ними ограждений для защиты от повреждения обломками строительных конструкций при аварии (особенно на пожаро- и взрывоопасных предприятиях);

размещение (строительство) под хранилищами со АХОВ аварийных резервуаров, чаш, ловушек (аварийных амбаров) и направленных стоков;

рассредоточение запасов АХОВ, строительство для них заглублённых или полузаглублённых хранилищ;

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

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

По мере необходимости план защиты объекта от АХОВ корректируется.

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

На ХОО заблаговременно создаются локальные системы оповещения персонала объектов.

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

  • для отдельных подразделений (цехов) ХОО;
  • для всего ХОО.

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

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

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

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

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

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

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

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

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

В каждом цехе предприятия, связанном с производством или потреблением АХОВ, имеются нештатные аварийные команды (группы).

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

Комплекс мероприятий по ликвидации последствий химически опасных аварий включает:

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

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

Выявление последствий аварии осуществляется проведением химической и инженерной разведки. Состав сил и средств, привлекаемых для выполнения задач разведки, зависит от её характера и масштабов. Данные разведки собираются в штабе руководства ликвидации аварии (чрезвычайной комиссии). На их основе производится оценка последствий аварии, разрабатывается план их ликвидации.

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

Ликвидация химического заражения проводится путём дегазации (нейтрализации) оборудования, зданий, сооружений и местности в районе аварии, заражённых АХОВ, и осуществляется с целью снижения степени их заражения и исключения поражения людей.

Специальная обработка техники и санитарная обработка людей проводится на выходе из зон заражения и осуществляется с целью предотвращения поражения людей АХОВ.

Эффективность этих мероприятий зависит от своевременности и качества их проведения.

Медицинская помощь поражённым оказывается с целью уменьшения угрозы их здоровью, ослабления воздействия на них АХОВ.

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

При химически опасной аварии руководитель работ по ликвидации её последствий обязан:

  • оценить химическую обстановку, определить границы зоны заражения, принять меры по её обозначению и оцеплению;
  • выявить людей, подвергшихся воздействию АХОВ, и организовать оказание им медицинской помощи;
  • разработать план ликвидации последствий аварии, в котором в зависимости от масштабов и характера химического заражения изложить: краткую характеристику последствий аварии и выводы из оценки химической обстановки; очерёдность работ и сроки их выполнения; способы дегазации (нейтрализации) АХОВ; организацию контроля за полнотой дегазации (нейтрализации) местности, техники, зданий, сооружений и транспорта; организацию медицинского обеспечения; требования безопасности; организацию управления и порядок представления донесений о ходе работ.

Как правило работы начинаются с рекогносцировки района аварии, в ходе которой определяются:

  • масштаб аварии и общий порядок её ликвидации;
  • возможные масштабы распространения жидкой и паровой фаз АХОВ;
  • противопожарное состояние района предстоящих работ;
  • объём работ по эвакуации;
  • потребное количество сил и средств для проведения работ;
  • места сосредоточения сил и средств ликвидации последствий аварии;
  • задачи по расчистке путей подхода и подъезда к месту аварии;
  • метеорологические условия и места организации базы, пунктов управления, выдачи средств защиты, питания и т.д.

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

  • выявление и контроль зоны распространения паров АХОВ;
  • оповещение и эвакуация из зоны заражения;
  • оказание медицинской помощи поражённым;
  • организация оцепления зоны аварии и распространения опасных концентраций АХОВ;
  • ликвидация пожаров, обеспечение взрыво- и пожаробезопасности проводимых работ;
  • расчистка и освобождение подходов и подъездов к месту аварии;
  • устранение или ограничение течи АХОВ из повреждённых ёмкостей и их растекания на местности;
  • перекачка или сбор АХОВ в резервные ёмкости;
  • организация дегазации (нейтрализации) АХОВ в очаге аварии;
  • организация дегазации (нейтрализации) техники, участвовавшей в работах;
  • санитарная обработка лиц, принимающих участие в работах.

Для руководства силами и средствами, принимающими участие в ликвидации последствий химически опасной аварии, создаётся система связи.

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

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


Компьютеризация России сегодня охватывает практически все стороны не только производственной, но и личной жизни граждан. В индустриальном обществе по прогнозам более 70% работающих будут использовать компьютеры. Таким образом, очевидна актуальность проблемы обеспечения эргономической безопасности компьютеризации. На сегодняшний день создано несколько систем стандартов решающих эту проблему.


7.1 Требования стандарта MPR II


Это первая система стандартов, регламентирующих ограничения на излучение от электростатических, электрических и магнитных полей для компьютерной и офисной техники, разработанных Национальным департаментом стандартов Швеции. MPR II также включает рекомендуемые руководящие принципы. Эти руководящие принципы базируются на концепции о том, что люди живут и работают в местах, где уже есть магнитные и электрические поля, поэтому устройства, которые мы используем, такие как монитор, не должны создавать электрические и магнитные поля, большие, чем те, которые уже существуют. В 1987 году был разработан стандарт MPR I, не получивший широкого распространения. В 1990 году появился стандарт MPR II, который в том же году был утвержден в странах ЕЭС в качестве основного. Требования MPR II учитываются при разработке комплексных стандартов TCO. Большинство современных мониторов сегодня выполняется в соответствии с рекомендациями MPR II или стандарта TCO. Было принято, что при использовании экрана с MPR II поля, генерируемые монитором, будут иметь относительно малый уровень по сравнению с полями, генерируемыми другим электрическим и канцелярским оборудованием. Ограничения на электро-магнитные поля вводимые стандартом MPR II представлены в таблице 7.1 (примечание: поверхностный электростатический потенциал не более 500 В)


Таблица

Таблица 7.1Ограничения на излучение от электростатических, электрических и магнитных полей по стандарту MPR IIЭлектрические поляДиапазон частотДопустимые значения5 Гц - 2 кГцНе более 25 В/м2 кГц - 400 кГцНе более2,5 В/мМагнитные поляДиапазон частотДопустимые значения5 Гц - 2 кГцне более 200 нТл2 кГц - 400 кГцне более 25 нТл

Также стандартом MPR II нормируются следующие визуальные параметры:

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

Ведутся разработки следующей версии стандарта - MPR III.


7.2 Требования стандарта TCO


Аббревиатура «TCO» расшифровывается как Шведская Федерация Профсоюзов. Стандарты TCO разработанные с целью гарантировать пользователям компьютеров безопасную работу. Сначала был создан стандарт TCO'91, но он не получил широкого распространения. Сегодня в состав разработанных TCO рекомендаций входят три стандарта: TCO'92, TCO'95 иTCO'99. Большинство измерений во время тестирований на соответствие стандартам TCO проводятся на расстоянии 30 см спереди от экрана, и на расстоянии 50 см вокруг монитора. Для сравнения во время тестирования мониторов на соответствие другому стандарту MPRII все измерения производятся на расстоянии 50 см спереди экрана и вокруг монитора. Это объясняет то, что стандарты TCO более жесткие, чем MPRII (см. таблицу 7.1).


Таблица 7.2

Ограничения на излучение от электростатических, электрических и магнитных полей по стандарту TCO99Электрические поляДиапазон частотДопустимые значения5 Гц - 2 кГцне более 10 В/м2 кГц - 400 кГцНе более 1 В/мМагнитные поляДиапазон частотДопустимые значения5 Гц - 2 кГцНе более 200 нТл2 кГц - 400 кГцНе более 25 нТл

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

Стандарт TCO'95 распространяется на весь персональный компьютер, т.е. на монитор, системный блок и клавиатуру и касается эргономических свойств, излучений (электрических и магнитных полей, шума и тепла), режимов энергосбережения и экологии (с требованием к обязательной адаптации продукта и технологического процесса производства на фабрике). Стандарт TCO'95 существует наряду с TCO'92 и не отменяет последний. Требования TCO'95 по отношению к электромагнитным излучениям мониторов не являются более жесткими, чем по TCO'92. В отношении эргономики TCO'95 предъявляет более строгие требования, чем международный стандарт ISO 9241. Отметим, что LCD и плазменные мониторы также могут быть сертифицированы по стандартам TCO'92 и TCO'95, как, впрочем, и портативные компьютеры. TCO'99 предъявляет более жесткие требования, чем TCO'95 в следующих областях: эргономика (физическая, визуальная и удобство использования), энергия, излучение (электрических и магнитных полей), окружающая среда и экология, а также пожарная и электрическая безопасность. Также TCO'99 предполагает новые методы проведения тестов. Стандарт TCO'99 распространяется на традиционные CRT мониторы, плоско панельные мониторы, портативные компьютеры, системные блоки и клавиатуры. Спецификации TCO'99 содержат в себе требования, взятые из стандартов TCO'95, ISO, IEC и EN, а также из EC Directive 90/270/EEC и Шведского национального стандарта MPR 1990:8 (MPRII) и из более ранних рекомендаций TCO.

Все требования TCO'99 объединены в семь групп:

  1. визуальные эргономические требования: требования к четкости изображения;
  2. визуальные эргономические требования: требования к стабильности изображения;
  3. факторы внешнего воздействия;
  4. требования к излучениям и энергосбережению;
  5. требования к электрической безопасности;
  6. экологические требования;
  7. дополнительные характеристики.

7.2.1 Линейность

Погрешность измерений не более ±0,2%. Нелинейность не более 1% по горизонтали и вертикали. Метод измерения: линейность должна определяться при помощи передвижного микроскопа (или эквивалентного прибора), при помощи которого можно определить длину измеряемой части экрана относительно измерительной шкалы. Микроскоп (или прибор) должен быть выровнен параллельно испытательной таблице, которая должна заполнить активную область экрана на максимально возможную величину.


.2.2 Ортогональность

Погрешность измерений не более ±0,2%. Неортогональность не более 2% по горизонтали и вертикали и не более 3% по диагонали.


.2.3 Уровень яркости

Уровень яркости - не более 100 кд/м2. Рекомендовано - не более 125 кд/м2. Погрешность измерений не более ±10%).


7.2.4 Равномерность яркости

Равномерность яркости измеряется в пределах всей активной области экрана. Равномерность яркости - это отношение максимальным значения яркости к минимальному. (Погрешность измерений не более ±10%).


7.2.5 Периодическое изменение яркости

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


7.2.6 Контрастность

Максимальное и минимальное значения яркости измеряются при вертикальном сканировании буквы "е" (шрифт "Arial", 12 пунктов) передвижным микрометром. (Погрешность измерений не более ±10%).

7.2.7 Разрешение


Таблица

Таблица 7.3Зависимость оптимального разрешения монитора от его размеров.Размер диагонали, дюймовЧастота вертикальной развертки, ГцРазрешение14-1585800 x 60017851024 x 76819-21851280 x 1024более 21851280 x 1024

Рекомендация: частота вертикальной развертки не менее 100 Гц (Погрешность измерений не более ±2% от измеряемой частоты).


7.2.8 Нестабильность изображения (флуктуация)

При напряженности магнитного поля 200нТ и частоте вертикальной развертки 80 Гц дрожание линий на экране не должно превышать 0,10 мм. Рекомендация - не более 0,08 мм. (Погрешность измерений не более ±10%).


.2.9 Рентгеновское излучение

Рентгеновское излучение - не более 5000 Гр/ч (Грей в час). Рекомендация - не более 300 Гр/ч. (Погрешность измерений не более ±10%).


.2.10 Электростатический потенциал

Эквивалентный поверхностный потенциал - не более ±0,5 кВ.


7.2.11 Переменное электрическое поле

Полоса I: 5 Гц-2 кГц, - не более 10 В/м (на расстоянии 30 см перед экраном, 50 см вокруг). Полоса II: 2 кГц-400 кГц, - не более 1.0 В/м (на расстоянии 30 см перед экраном, 50 см вокруг).

7.2.12 Переменное магнитное поле

Полоса I: 5 Гц-2 кГц, - не более 250 нТ (на расстоянии 30 см перед экраном, 50 см вокруг). Полоса II: 2 кГц-400 кГц, - не более 25 нТ (на расстоянии 30 см перед экраном, 50 см вокруг).


7.3 Требования стандарта СанПиН 2.2.2.542-96


В целях обеспечения безопасности здоровья пользователей в Российской Федерации действуют "Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы: Санитарные правила и нормы", утвержденные постановлением Госкомсанэпиднадзора России от 14 июля 1996 г. Цель Санитарных норм - определить такие нормированные величины факторов воздействия, чтобы их вред был минимальным, а условия труда - комфортными. Все ранее разработанные и находящиеся в эксплуатации типы отечественных и зарубежных мониторов должны быть испытаны на соответствие этим правилам.

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

Яркость изображения нормируется для того, чтобы облегчить приспособление глаз к самосветящимся объектам. Известно, что уровень яркостной адаптации зрения имеет решающее функциональное значение. Световая среда в рабочем помещении должна обеспечивать условия дневного зрения. Пониженная освещенность помещения снижает эффективность зрительного процесса. В тоже время естественно, что чем светлее в помещении, тем больше должна быть яркость экрана монитора. Для обеспечения комфортных условий работы с монитором его яркость должна быть не менее 90 кд/м2. Ограничены также (в пределах 25%) и колебания яркости. Нормируется внешняя освещенность экрана (100 - 250 лк). Исследования показали, что при более высоких уровнях освещенности экрана зрительная система утомляется быстрее и в большей степени. Весьма часто фактором, способствующим быстрому утомлению глаз, становится и контраст. Контраст - это показатель, характеризующий различие яркостей изображения и фона. Согласно нормам, контраст не должен быть менее 3:1, и только для предельно мелких деталей допускается величина 1,5:1 Человеческий глаз не может долго работать с мелкими объектами, потому нормируются размеры знаков на экране. Например, угловой размер знака должен быть в пределах от 16 до 60 угловых минут, что составляет от 0,46 до 1,75 см, если пользователь смотрит на экран с расстояния 50 см (минимальное расстояние, рекомендуемое гигиенистами).

СанПиН включает несколько параметров, определяющих допустимую форму и размеры знака. В частности, нормируется отношение ширины знака к высоте (0,5-1,0, лучше 0,7-0,9), т. е. знаки не должны быть ни слишком узкими, ни слишком широкими.

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

Таблица 7.4

Ограничения на излучение от электростатических, электрических и магнитных полей по стандарту СанПиН 2.2.2.542-96Электрические поляДиапазон частотДопустимые значения5 Гц - 2 кГцне более 25 В/м2 кГц - 400 кГцНе более 2,5 В/мМагнитные поляДиапазон частотДопустимые значения5 Гц - 2 кГцНе более 250 нТл2 кГц - 400 кГцНе более 25 нТл

Мощность экспозиционной дозы рентгеновского излучения на расстоянии 0,05 м вокруг видеомонитора 100 мкР/час

Поверхностный электростатический потенциал не более 500 В

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


7.4 Требования стандарта ГОСТ


Постановлением Госстандарта России от 11 сентября 1996 года №576 приняты и с 1 июля 1997 года введены в действие ГОСТ Р 50948-96. "Средства отображения информации индивидуального пользования. Общие эргономические требования и требования безопасности" и ГОСТ Р 50949-96. "Средства отображения информации индивидуального пользования. Методы измерений и оценки эргономических параметров и параметров безопасности". Постановлением Председателя Госстандарта России №248 от 16.07.97 В связи с вводом в действие ГОСТ Р 50948-96 и ГОСТ Р. 50949-96 прекращено применение ГОСТ 27016-86. "Дисплеи на электронно-лучевых трубках. Общие технические условия" и ГОСТ 27954-88. "Видеомониторы персональных вычислительных машин. Типы. Основные параметры Общие технические требования".

С 1 октября 1998 года все дисплеи, компьютеры и устройства, использующие средства отображения информации индивидуального пользования, по Постановлению Госстандарта России № 5 от 23 февраля 1998 г. подлежат обязательной сертификации на соответствие ГОСТ Р 50948-96 и ГОСТ Р 50949-96. Требования разделов 4 "Требования к визуальным эргономическим параметрам" и 5 "Требования к параметрам излучений дисплеев" ГОСТ Р 50948-96 являются обязательными при проведении сертификации. Итак, сейчас на территории Российской Федерации действуют следующие государственные стандарты по эргономической безопасности дисплеев: ГОСТ Р 50923-96 "Дисплеи. Рабочее место оператора. Общие эргономические требования и требования к производственной среде. Методы измерения». Принят постановлением № 451 от 10.07.96. Дата введения 10.07.97. Код ОКС - 13.180. "Область применения - настоящий стандарт распространяется на индивидуальное рабочее место оператора, снабженное средствами отображения информации на электронно-лучевых трубках (дисплей, видеомонитор, видеомодуль, видеодисплейный терминал (далее - дисплей)). Стандарт устанавливает эргономические требования к рабочему месту оператора при выполнении работы сидя, требования к производственной среде, а также методы измерения и оценки эргономических параметров и факторов производственной среды на рабочем месте. Стандарт не распространяется на рабочее место с дисплеем для управления технологическим процессом, транспортным средством, на рабочее место специального назначения и на рабочее место для учащегося". ГОСТ Р 50948-96 "Средства отображения информации индивидуального пользования. Общие эргономические требования и требования безопасности". Это первый российский ГОСТ, устанавливающий нормы эргономической безопасности дисплеев и других средств отображения информации. Принят 11.09.96, введен с 01.07.97. ГОСТ Р. 50948-96 гармонизирован с международными и европейскими стандартами, в том числе соответствует требованиям шведского стандарта MPR-II. Впервые в ГОСТе применена интегральная оценка визуальных эргономических параметров. В настоящее время Госстандартом РФ проводится доработка ГОСТ Р 50948-96 с целью гармонизации его с ИСО 9241-8:1998. ГОСТ Р 50949-96 "Средства отображения информации индивидуального пользования. Методы измерения и оценки эргономических параметров и параметров безопасности". В настоящее время также проводится доработка с целью гармонизации с ИСО 9241-8:1998.




8. Расчет затрат на разработку программы-оболочки электронного учебника


Затраты на разработку программного продукта складываются из:

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

8.1 Затраты на оплату труда и отчисления на социальные нужды


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


Таблица 8.1

Трудоемкость основных видов работ, человеко-дниНаименование работыКатегория работниковОбщая трудоемкостьСтарший научный сотрудникИнженер без категорииВыдача технического задания112Подбор литературы156Анализ существующих аналогов11011Разработка программы-2525Отладка программы-1515Составление док. на программу22528ИТОГО58186

Затраты на оплату труда определим прямым расчетом на основании данных о трудоемкости работ. Результаты расчета основной заработной платы сведены в табл. 8.2. Премия составляет 10% от должностного оклада, а доплаты по районному коэффициенту - 15% от оклада и премии. Фонд заработной платы на весь объем работ представляет собой месячный фонд заработной платы с учетом трудоемкости в человеко-месяцах. Трудоемкость в человеко-месяцах определяется делением трудоемкости в человеко-днях на количество рабочих дней в месяце (21 день).




Таблица 8.2

Расчет основной заработной платыНаименование категории работниковТрудоемкостьДолжностной окладПремии и доплаты, р.Месячный фонд заработной платы, р.Фонд заработной платы на весь объем работ, р.Человеко-дниЧеловеко-месяцыПремииДоплатыСтар. научный сотруд.50,2430003004953895910,8Инженер без категории813,861900190313,52403,59288,51ИТОГО10188,31

Дополнительная заработная плата устанавливается в процентах к основной:



Сз. ос - величина основной заработной платы;

Кдоп - коэффициент, зависящий от удельного веса отпускного времени в рабочем:



tотп - количество дней очередного отпуска (принято 24);


tр - количество рабочих дней в году (принято 305).

Общий фонд заработной платы определяется выражением:


,(8.3)


Определим общий фонд заработной платы:


;

р.;

р.;


В данной организации отчисления на социальное страхование принимается в размере 35,8 % от общего фонда заработной платы:


р.


8.2 Расходы по содержанию и эксплуатации оборудования


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

Общая сумма затрат на амортизацию определяется:



Кд - первоначальная стоимость ПК «Pentium II»,

Кд = 16500 р.;

Ку - первоначальная стоимость монитора,

Ку = 3500 р.;

q - норма амортизированных отчислений, которая для вычислительной техники составляет 20%;

Фр - количество рабочих часов в году;

Тр - время работы ПК и монитора;

Фр при шестидневной рабочей неделе в году составляет 251 дней по 8 часов и с учетом простоя оборудования в ремонте примет значение:


ч.


Тр составляет 81 день по 8 часов:


ч.


Таким образом, затраты на амортизацию составляют:


р.


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



k - коэффициент спроса, учитывающий загруженность машины в сутки,


k = 0,8;

Pуст = 250 Вт.

Вт.


Общий расход электроэнергии:


,


Ц - цена за единицу электроэнергии;

Ц = 0,82 (р/кВт×ч);

h - коэффициент загрузки оборудования по времени,

h = 0,8.

Таким образом, затраты на электроэнергию составляют:


р.


8.3 Накладные расходы


Кроме затрат на оплату труда и социальные нужды, на амортизацию, обслуживание и оплату потребленной электроэнергии необходимо учесть накладные расходы (затраты на содержание управленческого аппарата и вспомогательных рабочих) 12,5% от прямых затрат и плановые накопления (прибыль) 11,11% от суммы всех затрат. Данные о затратах на исследования и разработку приведены в табл. 8.3.

Таблица 8.3

Затраты на исследования и разработкуСтатья расходовСумма, р.Основная заработная плата10188,31Дополнительная заработная плата855,84Отчисления на социальные нужды3958,44Расходы на амортизацию оборудования818,13Расходы на электроэнергию65,32Накладные расходы1982,99Плановые накопления1982,8ИТОГО19829,83

Таким образом, общие затраты составили 19829,83 рублей.



Заключение


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

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

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



Список использованных источников


.Гражданская оборона: Учебник для вузов/ Атаманюк В.Г., Ширшев Л.Г., Акимов Н.И. Под ред. Д.И. Михайлика. - М.: Высшая школа, 1986. - 207 с.

.Топоров И.К. Основы безопасности жизнедеятельности. - М.: Просвещение, 1996. - 158 с.

.Технико-экономические обоснования инженерных решений в дипломных проектах: Метод.указания/ Г.И. Акользина, Л.Г. Архипова, В.Г. Воронин, М.Н. Ларина. Омск. гос. ун-т путей сообщения. - 1992. - 44 с.



Приложение 1


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


unit Unit1;

interface, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,, ActnList, ToolWin, ComCtrls, StdCtrls, ImgList, ExtCtrls, StdActns,, DBCtrls, Db, DBTables, Grids, DBGrids, Buttons, OleCtnrs, Unit2,, Unit3;RebuildRecords();RebuildPMs();= record:string;:string;;= array[0..21] of TNavig;= array[0..21,0..21] of integer;= array[0..1,0..21] of integer;= class(TForm): TMainMenu;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TOpenDialog;: TSaveDialog;: TMenuItem;: TAction;: TStatusBar;: TAction;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TAction;: TMenuItem;: TAction;: TMenuItem;: TMenuItem;: TAction;: TMenuItem;: TMenuItem;: TAction;: TPanel;: TMenuItem;: TMenuItem;: TImageList;: TPanel;: TSplitter;: TTreeView;: TRichEdit;: TCoolBar;: TToolBar;: TToolButton;: TPopupMenu;: TPopupMenu;: TToolButton;: TAction;ExitExecute(Sender: TObject);aboutExecute(Sender: TObject);SaveFileExecute(Sender: TObject);AdminExecute(Sender: TObject);TreeBuildExecute(Sender: TObject);FormCreate(Sender: TObject);LookExecute(Sender: TObject);BackGoExecute(Sender: TObject);ForwardGoExecute(Sender: TObject);BackPMOnClickExecute(Sender: TObject);ForwardPMOnClickExecute(Sender: TObject);TreeNodeSelectExecute(Sender: TObject);TreeViewChange(Sender: TObject; Node: TTreeNode);NViewAdminWindowClick(Sender: TObject);TreeBackClick(Sender: TObject);TreeForwardClick(Sender: TObject);ToolButton3Click(Sender: TObject);ToolButton4Click(Sender: TObject);;: TBrowser;:TRecords;:TNavigInTree;, MaxIndex:byte;:boolean;:TIndex;about, Password, Admin;= record:integer;;= ^TParagrafData;:TParData;

{$R *.DFM}Inscription(i: word):string;:=Copy(Browser.RichEdit.Lines[i],Pos('@@@',Browser.RichEdit.Lines[i])+4,Length(Browser.RichEdit.Lines[i]))

end;


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

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ