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

Министерство образования и науки Российской Федерации

Федеральное агентство по образованию

ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра Автоматизированных систем

Дипломный проект

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

Иркутск 2008

Реферат

Данный дипломный проект содержит 133 страницы, 25 рисунков, 10 таблиц и состоит из следующих разделов:

1.      Введение, которое содержит в себе вводную информацию о предметной области и поставленной задаче.

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

3.      Во второй главе выполнен анализ существующих подходов для обновления структуры пространственно распределённых БД. Рассмотрена общая характеристика современной теории баз данных. Рассмотрены существующие технологии.

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

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

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

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

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

Оглавление

Раздел 1. Анализ предметной области

1.1 Краткая характеристика ТПС энергетики

.2 ТПС как объект моделирования

1.2.1 Задачи моделирования

1.2.1.1 Синтез

.2.1.2 Анализ

.2.1.3 Управление

1.2.2 Области применения методов моделирования

1.2.2.1 Проектирование ТПС

.2.2.2 Эксплуатация

.2.2.3 Диспетчерское управление

.2.2.4 Исследовательские и обучающие цели применения

1.3 Информационно вычислительный комплекс "Ангара" для компьютерного моделирования ТПС

1.3.1 Назначение ИВС "Ангара"

.3.2 Функции ИВС "Ангара"

.3.3 Организация БД

1.4 Постановка вопросов

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

Раздел 2. Анализ существующих подходов для обновления структуры пространственно распределённых БД

2.1 Общая характеристика современной теории баз данных

2.1.1 Реляционные СУБД

.1.2 Объектно-ориентированные СУБД

.1.3 Объектно-реляционные СУБД

2.2 Существующие технологии

2.2.1 Генерации SQL скрипта структуры БД

.2.2 Microsoft SQL Server 2005

.2.3 SQL-запросы

.2.4 Средства программного доступа к структуре баз данных

2.2.4.1 OLE DB

.2.4.2 ADO (Active Data Objects)

.2.4.3 ADOX (ADO Extension for DDL and Security)

Раздел 3. Описание разработки

3.1 Основные системно-концептуальные соглашения

.2 Блок схема

.3 Характеристика реализации

3.3.1 Назначение

.3.2 Условия выполнения

.3.3 Порядок генерации SQL-скрипта

.3.4 Порядок переноса данных

.3.5 Ограничения

.3.6 Описание интерфейса пользователя и его режимы генерации

.3.7 Присоединение к БД

.3.8 Режимы генерации структуры SQL БД

.3.9 Настройки

3.3.10 Выполнение программы

3.4 Перенос структуры БД

.5 Перенос данных

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

4.1 Характеристика условий труда программиста

.2 Требования к производственным помещениям

4.2.1 Производственный микроклимат

.2.2 Освещение

.2.3 Шум

4.2.3.1 Расчет уровня шума

4.2.4 Электромагнитное и ионизирующее излучения

4.3 Эргономические требования к рабочему месту

.4 Окраска и коэффициенты отражения

.5 Режим труда и отдыха

.6 Электробезопасность

.7 Пожарная безопасность

4.7.1 Действия персонала в условиях ЧС

Раздел 5. Экономическая часть

5.1 Анализ технико-экономических показателей разработки программного продукта на основе "актуализация структур баз данных при расчётах и оптимизации трубопроводных систем"

5.1.1 Краткая характеристика разработки и её назначение

.1.2 Определение затрат на создание программного продукта

Заключение

Список литературы

Приложение

компьютерный моделирование скрипт программный

Введение

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

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

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

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

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

Исследования в работе производились на примере информационно вычислительной системы (ИВС) "Ангара" разработанной ИСЭМ СО РАН и предназначенной для решения разнообразных задач расчёта ТПС и использующейся на практике во многих организациях страны.

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

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

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

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

Раздел 1. Анализ предметной области

1.1    Краткая характеристика ТПС энергетики

Трубопроводные системы тепло-, водо-, нефте-, газоснабжения - это крупномасштабные, сложные инженерно-технические сооружения, представленные широким спектром объектов, которые отличаются своим назначением, размерами, принципами построения и условиями функционирования [1]. Формированию таких систем способствовал целый ряд причин:

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

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

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

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

Приведем некоторые цифры, характеризующие ТПС. Трубопроводный транспорт газа, нефти, нефтепродуктов занимает важное место в ТЭК России. Созданная еще в СССР единая система газоснабжения (ЕСГ) включает газовые промыслы, газотранспортные системы с подземными хранилищами и множество потребителей: городов и населенных пунктов, предприятий всех отраслей промышленности. Газотранспортная система ОАО "Газпром" ЕСГ составляет 155 тыс. км. В нее входят 268 компрессорных станций с общей мощностью газоперекачивающих агрегатов в 44,8 млн. кВт. На 2004 год эксплуатировалось около 64 тыс. км магистральных нефтепроводов.

Пропускная способность ЕСГ в настоящее время составляет около 600 млрд. куб. м. В состав ЕСГ сегодня включены 25 подземных хранилищ газа.

Тепловое хозяйство включает в себя 485 ТЭЦ, около 6,5 тыс. котельных мощностью более 20 Гкал/час, более 100 тысяч мелких котельных, около 600 тысяч автономных индивидуальных теплогенераторов, 183 тыс. км тепловых сетей. Это наиболее энергоемкая отрасль ТЭК, расходующая до 50% добываемого в стране топлива, что в 1,6 раза превышает затраты на выработку электроэнергии. Современные системы теплоснабжения (ТСС) обеспечивают тепловой энергией жилые, административные здания, промышленные предприятия и представляют собой сложные технические сооружения. Технологические связи в них ограничиваются, как правило, масштабами города или крупного промышленного предприятия, в этом смысле они носят локальный характер. Структура ТСС может быть, как простой разветвленной, так и сложной многоконтурной. Протяженность магистральной тепловой сети г. Иркутска составляет 120 км, распределительных сетей - более 300 км, магистральных ТСС г. Москвы - более 2000 км.

Годовое потребление воды в России составляет порядка 500 км³. Системы водоснабжения призваны обеспечить водой питьевого качества население и промышленные предприятия. Протяженность водопроводных сетей составляет порядка 523 тыс. км. Вместе с тем ресурсы воды распределены неравномерно, что вызывает необходимость в создании систем, транспортирующих воду на большие расстояния от ее источников до удаленных потребителей. Такими системами являются системы групповых водопроводов (СГВ) - чрезвычайно сложные и дорогостоящие объекты с протяженными магистральными сетями большого диаметра. Например, Казахстано-Сибирская система водоснабжения охватывает территорию 18 млн. га с протяженностью магистральных водопроводов более 13 тыс. км, снабжая водой более 2600 городов и поселков с населением более 2 млн. человек.

В настоящее время в нефтяной промышленности для повышения темпов отбора нефти из залежей используются системы поддержания пластового давления. В мировой практике наиболее широкое распространение получил метод, основанный на закачивании в пласт воды через нагнетательные скважины, расположенные в комплексе с нефтяными в определенном порядке. Многочисленные долговременные экспериментальные исследования показывают, что наилучшей средой для закачивания в нефтяные пласты является подземная минерализованная вода. При этом достигается не только основная задача - поддержание пластового давления, - но и повышается нефтеотдача. В 1990 году в протяженность таких систем, находящихся в эксплуатации, составляла более 2,5 тыс. км. Особенностью СППД является большой расход воды (300-400 тыс. м³ в сутки) и высокое давление (до 200 атм.), наличие нескольких источников, работающих на общую сеть. Потребление электроэнергии в СППД составляет до 30%-40% от общего ее потребления в нефтедобыче. Развитие добычи и экспорта нефти и нефтепродуктов требует соответствующего развития инфраструктуры трубопроводного транспорта нефти и нефтепродуктов. В настоящее время система трубопроводного транспорта включает около 350 тыс. км трубопроводов технологического назначения (нефтесборные, по доставке воды для поддержания пластового давления, для транспортировки подготовленной нефти), около 2,5 тыс. км магистральных трубопроводов, принадлежащих нефтяным компаниям, в том числе иностранным (трубопроводы Уса-Ухта, Сахалин - Де-Кастри, КТК), а также 50 тыс. км трубопроводов, принадлежащих ОАО "АК "Транснефть", которая обеспечивает экспортные поставки нефти и доступ к трубопроводным мощностям, регулируемый государством. В системе функционируют 355 станций по перекачке нефти, 861 резервуар для хранения нефти общей емкостью около 14 млн. кубометров. Прирост мощностей за счет комплекса работ по расширению действующей системы магистральных нефтепроводов в период 2003- 2005 гг. составил около 16 млн т, а с учетом выполняемых работ в 2006 г. - 23 млн т.

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

1.2    ТПС как объект моделирования

 

1.2.1 Задачи моделирования

 

1.2.1.1        Синтез

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

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

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

3) Для постановки и решения задачи синтеза сложных ТПС необходим системный подход, в связи с чем требуются совместные усилия специалистов в конкретной технической области, исследователей операций, математиков-"оптимизаторщиков" и специалистов по системному анализу.

1.2.1.2        Анализ

Анализ как проектная задача заключается в определении выходных параметров системы при ее фиксированной функционально-структурной модели и по заданным значениям всех остальных (кроме выходных) переменных. Иными словами, полученные на этапе синтеза структура и параметры элементов системы подвергаются анализу на их соответствие законам природы, функциональному назначению и свойствам ТПС.

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

1.2.1.3        Управление

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

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

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

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

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

·    изменение уровня добычи или производства транспортируемой среды;

·        изменение структуры и объемов потребления транспортируемой среды;

·        плановые ремонтно-профилактические работы;

·        аварийный выход из строя, износ и старение оборудования ТПС;

·        перебои в работе смежных систем (электроэнергетических, топливоснабжающих и др.);

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

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

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

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

·        обточку рабочих колес, применение сменных роторов, изменение конструкции лопаток насосных агрегатов;

·        переключения на сетях с целью их зонирования или секционирования;

·        установку дросселирующих устройств (штуцеров, шайб), регуляторов у потребителей или на участках ТПС.

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

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

·        изменения схем соединения оборудования внутри основных элементов ТПС, например переключение насосов и внутренней обвязки насосов на источнике или насосной станции (НС) приводящие к дискретным изменениям характеристик элементов.

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

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

1.2.2 Области применения методов моделирования

 

1.2.2.1        Проектирование ТПС

Проектирование ТПС можно рассматривать с двух сторон:

·        Компьютерное проектирование ТПС;

·        Технологическое проектирование ТПС.

Сложившиеся в настоящее время традиционные процессы проектирования ТПС различного назначения имеют много общего. Эта общность проявляется в первую очередь в расчленении процесса проектирования на отдельные части и дальше - на отдельные проектные операции, причем большую долю этих частей и операций составляют процедуры, связанные с составлением и оформлением различного рода документации, что характерно для большинства технических систем. Анализ этого положения свидетельствует о том, что при проектировании сложного объекта 30-40 % времени тратится на согласование отдельных частей проекта, 50-60 % - на выполнение эскизов, чертежей, счетов, составление проектной документации и лишь порядка 10 % для создания единого проекта между отдельными его частями.

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

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

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

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

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

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

Блок-схема проектирования технологических трубопроводных систем (ТТС) представлена на рис. 1. Разбивка на этапы имеет условный характер, для упрощения на схеме показаны не все связи между этапами.

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

Рисунок 1 Блок-схема проектирования ТТС

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

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

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

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

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

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

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

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

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

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

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

Рисунок 2 Структура программного обеспечения автоматизированного проектирования ТПС

Структура программного обеспечения автоматизированного проектирования ТТС приведена на рис. 2.

1.2.2.2        Эксплуатация

Во временном аспекте выделяются уровни развития и эксплуатации (функционирования). Управление развитием в свою очередь включает этапы:

а)перспективного проектирования на период 10-15 лет;

б)текущего проектирования на период до 5 лет.

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

Управление эксплуатацией ТПС, включает этапы:

а)реконструкции (долгосрочное управление);

б)наладки (среднесрочное управление);

в)оперативного управления (в масштабе реального времени).

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

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

В силу локальности ТПС в качестве территориальных уровней управления здесь рассматриваются:

а) ТПС в целом;

б) подсистемы ТПС - источники теплоты, тепловые сети, системы, теплопотребления;

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

. Центральное - на источниках теплоты;

. Районное - на контрольно распределительных пунктах;

. Групповое - на центральных тепловых пунктах;

. Местное - на индивидуальных тепловых пунктах;

. Пофасадное - на индивидуальных тепловых пунктах;

. Индивидуальное - на отопительном приборе.

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

1.2.2.3        Диспетчерское управление

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

1.2.2.4        Исследовательские и обучающие цели применения

Научно-методические исследования по вопросам автоматизации ТСС развиваются в трех относительно самостоятельных направлениях [10].

Первое направление связано с принципами построения теплоснабжающих систем и с их адаптацией к требованиям, предъявляемым автоматизированными системами управления режимами. Эффективность функционирования ТСС, как известно, во многом определяется схемой и параметрами тепловых сетей и системой распределения сетевой воды, включающей размещение и схему контрольно-распределительных пунктов [4]. Первые работы по рациональному построению тепловых сетей были выполнены в рамках разработки схемы теплофикации г. Москвы. В ней предлагалось сооружение кольцевой схемы тепловых сетей, что обеспечивало двусторонние снабжение потребителей, тепловой энергией. Однако реальное развитие ТСС пошло по другому пути, по пути сооружения разветвленных (без колец) схем тепловых сетей. Исследования по резервированию и надежности функционирования тепловых сетей были продолжены на новом этапе в Институте систем энергетики имени Л. А. Мелентьева (ИСЭМ) [7-9, 11]. В этих работах были предложены основные принципы резервирования тепловых сетей с учетом возможной совместной работы источников, гидравлических режимов и надежности теплоснабжения потребителей. Рассматривалось нагруженное и ненагруженное резервирование. Был сделан вывод, о том, что обеспечение надежности теплоснабжения потребителей невозможно без сооружения автоматизированных узлов распределения теплоносителя и дистанционного управления ими. Научно-методические разработки, выполненные в ИСЭМ, получили практическое применение при решении вопросов теплоснабжения гг. Новосибирска, Киева, Омска, Тюмени, Салавата, Ишимбая, Стерлитамака и других. Вопросы построения тепловых сетей с учетом размещения и особенностей схем автоматизированных узлов управления (КРП, ЦТП) рассматриваются в монографии Громова И.К. [1]. Фактически в ней сформулированы принципы построения ТСС, определены мощности и схемы контрольно-распределительных пунктов.

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

Второе направление исследований связано с разработкой структуры систем управления режимами работы ТСС. Они включают уровни управления технологическим процессом, их функциональное назначение, структуру диспетчерского управления и ее связь с теплоснабжающей системой. Эти работы ведутся в Научно-исследовательском институте гидромеханизации санитарно-технических и специальных строительных работ (ВНИИГС), Научно-исследовательском проектном институте энергетической промышленности (ВНИПИ Энергопром), Сибтехэнерго [12, 13]. Каждой из этих организаций предложена своя структура системы управления. Наиболее сложная и идеализированная схема управления функционированием ТСС предложена ВНИПИ Энергопромом. Работы ВНИИГС и Сибтехэнерго в большей мере соответствуют сложившейся организационной структуре управления теплоснабжением городов страны.

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

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

Для идентификации параметров ТСС в ИСЭМ разработан метод "математического расходомера" [14]. Он предназначен для определения установившихся расходов теплоносителя, коэффициентов гидравлического сопротивления на множестве участков и у потребителей в многоконтурных теплоснабжающих системах без массового применения расходомеров. Кроме того, на основе этого метода можно в рамках автоматизированной обработки данных измерений на ЭВМ расчетным путем устанавливать факты аварийных ситуаций и локализовать места аварий. В качестве основного источника информации для работы метода служат данные многократной манометрической съемки в узлах сети и показатели расходомеров, фиксирующие только отдельные расходы в системе. Эти работы в ИСЭМ получили дальнейшее развитие [15], что позволило расширить области применения этого метода и перейти к более сложной задаче идентификации режимов функционирования ТСС.

Заканчивая краткий анализ основных направлений исследования в области АСУ теплоснабжением можно сделать следующие выводы:

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

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

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

1.3    Информационно вычислительный комплекс "Ангара" для компьютерного моделирования ТПС

Информационно-вычислительная среда "АНГАРА" (рис.3) (в дальнейшем ИВС), разработанна в лаборатории трубопроводных и гидравлических систем Института систем энергетики им. Л.А Мелентьева, позволяет решать, как информационные, так и расчетно-аналитические прикладные задачи в рамках единого интерфейса пользователя.

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

Основное назначение ИВС "АНГАРА" состоит в том, чтобы освободить пользователя от необходимости знания программирования, методов расчета и математического моделирования, - позволяя решать содержательные инженерные задачи непосредственно на расчетных схемах, оперируя привычными понятиями и объектами. Таким образом, ИВС обеспечивает возможность создания и работы с компьютерной графической моделью реальной трубопроводной системы.

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

Рисунок 3 Вид основного интерфейса при работе со схемой.

1.3.1 Назначение ИВС "Ангара"

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

1.3.2 Функции ИВС "Ангара"

ИВС обеспечивает возможности работы с:

1)      графическими изображениями схем ТПС;

2)      данными по элементам схем ТПС;

)        планом местности;

)        расчетно-аналитическими задачами.

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

1.3.3 Организация БД

При разработке ИВС закладывались следующие основные принципы:

)        моделируемая ТПС может состоять из множества расчетных схем различных типов (схемы сетей, насосных станций, источников и т.д.);

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

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

)        реальный элемент ТПС (например, источник) может быть представлен как элементом какой-либо схемы, так и собственной расчетной схемой;

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

)        все элементы определенного типа имеют одинаковый состав числовых и символьных параметров;

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

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

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

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

За настройку ИВС на конкретный тип ТПС и автоматическую поддержку указанных взаимосвязей отвечает ядро реляционной БД, состоящее из "системных" таблиц, рис. 4.

Рисунок 4 Схема ядра БД

Результатом настройки ИВС на конкретный тип ТПС является состав и структура "пользовательских" таблиц, соответствующих определенным типам элементов со своим набором параметров. Состав этих параметров (полей пользовательских таблиц) определяется составом исходных данных и результатов расчетных задач. Таким образом, структура пользовательских таблиц ставится в соответствие прикладным программно-вычислительным комплексам.

Совокупность системной и пользовательской информации о схемах, параметрах и плане конкретной ТПС, которая формируется с помощью ИВС, - составляет проект, которому в стандартном случае соответствует единый файл с БД в формате MS Access.

Выводы по проведённому анализу:

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

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

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

1.4    Постановка вопросов

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

Для успешной реализации данной задачи необходимо выполнить следующие этапы:

1.     Анализ предметной области:

·        Краткая характеристика ТПС энергетики;

·        ТПС как объект моделирования (задачи моделирования, области применения методов моделирования);

·        Информационно вычислительный комплекс "Ангара" для компьютерного моделирования ТПС

2.     Анализ возможностей современных информационных технологий;

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

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

1.      Работа в операционной системе Windows 2000, Windows XP, Windows Vista

.        Использование в качестве "шаблона" БД MS Access 2003.

.        Обновление БД MS Access (2003,2007); MS SQL Server 2000/2005.

4.      Обновляемые объекты: таблицы, поля таблиц, связи, данные.

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

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

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

.        Управление программным средством должно осуществляться манипулятором типа "мышь" и/или с клавиатуры.

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

Раздел 2. Анализ существующих подходов для обновления структуры пространственно распределённых БД

 

2.1    Общая характеристика современной теории баз данных

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

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

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

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

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

2.1.1 Реляционные СУБД

Реляционные СУБД основаны на реляционной модели, которая бала разработанная Э.Коддом в 1970 году. Реляционная модель позволяет представлять информацию в виде набора двумерных таблиц, связанных между собой посредством совместно используемых полей данных, называемых ключами. Реляционные базы данных предоставляют более простой доступ к данным и обеспечивают повышенную надежность и целостность благодаря отсутствию избыточной информации [16].

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

Отношение двумерная таблица специального вида, обладающая следующими свойствами:

• все значения атрибутов атомарны;

• отсутствуют одинаковые строки;

• столбцам однозначно присвоены имена;

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

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

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

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

Внешний ключ используется для ссылки на кортежи другого отношения, содержащие соответствующие значения первичного ключа [19].

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

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

.1.2   Объектно-ориентированные СУБД

Разработка систем объектно-ориентированных баз данных началась в середине 80-х годов в связи с необходимостью удовлетворения требований приложений, отличных от тех, которые обслуживаются системами реляционных баз данных [16].

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

Каждый объект характеризуется состоянием и поведением. Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Взаимодействие между объектами производится на основе передачи сообщений и выполнении соответствующих методов.

Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Класс, объекты которого могут служить значениями атрибутов объектов другого класса, называется доменом этого атрибута. Допускается порождение нового класса на основе уже существующего класса - наследование. В этом случае новый класс, называемый подклассом существующего класса (суперкласса), наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Различаются случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного суперкласса, во втором случае суперклассов может быть несколько. Если в системе поддерживается единичное наследование классов, набор классов образует древовидную иерархию. При поддержании множественного наследования классы связаны в ориентированный граф [20].

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

2.1.3 Объектно-реляционные СУБД

Реляционные СУБД, в отличие от объектно-ориентированных СУБД, имеют реально работающие стандарты - стандарты на язык запросов SQL. Кроме того, существует огромная база заказчиков, которые пока не готовы отказаться от реляционной технологии. Поэтому производители реляционных СУБД пошли по пути внедрения объектной технологии в отработанную и популярную технологию реляционных СУБД. Эта модель является частью последнего стандарта SQL, называемого SQL-99 (или SQL:1999, а также SQL3), и представляет собой вариант расширения обычной реляционной модели за счет формализации многих общепринятых концепций объектно-ориентированного проектирования. Указанный стандарт служит основой для построения объектно-реляционных систем баз данных [16].

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

• инкапсуляцию (сокрытие деталей реализации внутри типа);

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

• позднее связывание (определение реального типа объекта в момент исполнения);

• расширяемость (возможность определить новый тип);

• наследуемость типов (возможность определить новый тип на основе существующего);

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

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

2.2    Существующие технологии

 

2.2.1 Генерации SQL скрипта структуры БД

Программа (или script) на языке SQL представляет собой простой текстовый файл. Написанный SQL-скрипт запускаем через WI_SQL (IB_SQL). Преимущество SQL скрипта не только в его простоте. Во-первых, что все действия фиксируются, как в нормальной программе, второе - WI_SQL записывает в отчет ошибки выполнения SQL команд. И в-третьих, пока проект находится на стадии идеи, не требуется разработка каких-либо дополнительных средств.

Рисунок 6 Структура БД

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

В этой базе данных запустить следующий SQL script (рис.6):

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[FK_A_Detail_A_Master]') and OBJECTPROPERTY(id, N'IsForeignKey') = 1)TABLE [dbo].[A_Detail] DROP CONSTRAINT FK_A_Detail_A_Masterexists (select * from dbo.sysobjects where id = object_id(N'[dbo].[FK_A_Master_A_MasterName]') and OBJECTPROPERTY(id, N'IsForeignKey') = 1)TABLE [dbo].[A_Master] DROP CONSTRAINT FK_A_Master_A_MasterNameexists (select * from dbo.sysobjects where id = object_id(N'[dbo].[A_Detail]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)table [dbo].[A_Detail]exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[A_Master]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)table [dbo].[A_Master]exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[A_MasterName]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)table [dbo].[A_MasterName]TABLE [dbo].[A_Detail] (

[A_Detail_ID] [int] IDENTITY (1, 1) NOT NULL ,

[A_Master_ID] [int] NOT NULL ,

[A_DetailData] [varchar] (50) COLLATE Cyrillic_General_CI_AI NOT NULL ,

[A_DetailSM] [float] NOT NULL

) ON [PRIMARY]TABLE [dbo].[A_Master] (

[A_Master_ID] [int] IDENTITY (1, 1) NOT NULL ,

[A_MasterCod] [varchar] (20) COLLATE Cyrillic_General_CI_AI NOT NULL ,

[A_MasterName_ID] [int] NOT NULL ,

[A_MasterName_ID1] [int] NOT NULL,

[Perc] [float] NOT NULL

) ON [PRIMARY]TABLE [dbo].[A_MasterName] (

[A_MasterName_ID] [int] IDENTITY (1, 1) NOT NULL ,

[A_MasterName] [varchar] (50) COLLATE Cyrillic_General_CI_AI NOT NULL

) ON [PRIMARY]TABLE [dbo].[A_Master] WITH NOCHECK ADD[PK_A_Master] PRIMARY KEY CLUSTERED

(

[A_Master_ID]

) ON [PRIMARY]TABLE [dbo].[A_MasterName] WITH NOCHECK ADD[PK_A_MasterName] PRIMARY KEY CLUSTERED

(

[A_MasterName_ID]

) ON [PRIMARY]TABLE [dbo].[A_Master] WITH NOCHECK ADD[IX_A_Master] UNIQUE NONCLUSTERED

(

[A_MasterCod]

) ON [PRIMARY]TABLE [dbo].[A_MasterName] WITH NOCHECK ADD[IX_A_MasterName] UNIQUE NONCLUSTERED

(

[A_MasterName]

) ON [PRIMARY]TABLE [dbo].[A_Detail] ADD[FK_A_Detail_A_Master] FOREIGN KEY

(

[A_Master_ID]

) REFERENCES [dbo].[A_Master] (

[A_Master_ID]

)TABLE [dbo].[A_Master] ADD[FK_A_Master_A_MasterName] FOREIGN KEY

(

[A_MasterName_ID]

) REFERENCES [dbo].[A_MasterName] (

[A_MasterName_ID]

)TABLE [dbo].[A_Master] ADD[FK_A_Master_A_MasterName1] FOREIGN KEY

(

[A_MasterName_ID1]

) REFERENCES [dbo].[A_MasterName] (

[A_MasterName_ID]

)

GO

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

2.2.2 Microsoft SQL Server 2005

Microsoft SQL Server 2005- это законченное решение для управления и анализа данных, позволяющее оперативно развертывать масштабируемые Web-приложения нового поколения. SQL Server 2005 - ключевой компонент поддержки электронной коммерции, интерактивных деловых приложений и хранилищ данных, обеспечивающий масштабируемость, необходимую для поддержки развивающихся, динамических сред. В SQL Server 2005 предусмотрена широчайшая поддержка ХМL (Extensible Markup Language) и других форматов, функций производительности и доступности, гарантирующих своевременное решение поставленных задач, а также развитой функциональности управления и настройки, позволяющей автоматизировать выполнение рутинных задач и снизить совокупную стоимость владения. Кроме того, SQL Server 2005 в полном объеме использует преимущества Windows 2000, а так же поддерживает до 32 процессоров и до 64 гигабайт (Гб) оперативной памяти. SQL Server 2005 - это реляционная СУБД, которая использует язык Transact SQL для пересылки сообщений между компьютером клиента и компьютером, на котором работает SQL Server 2005 [26].

В состав SQL Server 2005 входит множество инструментов и функций, упрощающих процесс установки, развертывания, управления и использования баз данных. SQL Server 2005 предоставляет администраторам баз данных полный набор инструментов, необходимых для тонкой настройки SQL Server 2005 в составе промышленных онлайновых систем. SQL Server 2005 также эффективно работает в небольших однопользовательских системах, при этом издержки на администрирование минимальны. Установка или обновление SQL Server 2005 происходит под управлением приложения, которое направляет действия пользователя при вводе сведений, необходимых программе установки. Программа установки автоматически определяет наличие ранней версии SQL Server. После завершения установки можно запустить мастер обновления (SQL Server 2005 Upgrade wizard), под руководством которого будет быстро выполнен процесс обновления. Таким образом, весь процесс установки или обновления завершается быстро, причем пользователю приходится вводить минимум информации [27].

Механизм баз данных SQL Server 2005 представляет собой надежный сервер, способный управлять базами данных терабайтного объема, к которым одновременно обращаются тысячи пользователей. В то же время при работе с параметрами по умолчанию SQL Server 2005 поддерживает такие функции, как динамическая самонастройка. SQL Server 2005 автоматически и динамически меняет свою конфигурацию в процессе работы. По мере роста числа пользователей, подключенных к SQL Server 2005, он может динамически выделять необходимые ресурсы, например память. При снижении загруженности SQL Server 2005 освобождает ресурсы и возвращает их системе. Если на сервере одновременно запускаются другие приложения, SQL Server 2005 обнаружит выделение для них дополнительной виртуальной памяти и уменьшит объем используемой им виртуальной памяти, чтобы снизить издержки на подкачку страниц. SQL Server 2005 также способен автоматически увеличивать или уменьшать размер базы данных по мере добавления или удаления информации. Некоторые функции SQL Server 2005 увеличивают масштабируемость системы. Например, SQL Server 2005 динамически регулирует степень дробления блокировок для каждой таблицы, на которую ссылается запрос, в него также входит оптимизированная поддержка высокоскоростных операций для больших объемов данных. Кроме того, SQL Server 2005 способен планировать параллельное исполнение, при котором обработка оператора SQL разделяется на несколько частей. Каждая часть может быть выполнена на отдельном процессоре, в этом случае формирование полного результирующего набора осуществляется быстрее, чем в том случае, когда отдельные части операторов выполняются последовательно [26, 28].

Доступны различные редакции SQL Server 2005, способные удовлетворить самые разные требования заказчиков (организаций и отдельных лиц) к производительности, исполняющей среде и стоимости [28].

Enterprise Edition. Эта редакция - полный вариант SQL Server, наиболее часто предлагаемый организациям. Enterprise Edition отличается развитыми возможностями масштабируемости и надежности, необходимыми для решения важных задач интерактивного ведения бизнеса и Интернет-приложений. Эта редакция в полном объеме использует преимущества наиболее совершенного аппаратного обеспечения, поддерживая до 32 процессоров и 64 Гб ОЗУ. Кроме того, SQL Server 2005 Enterprise Edition включает дополнительные функции анализа.

Standard Edition. Этот вариант могут позволить себе средние и небольшие организации, которым не требуются сложные возможности масштабируемости и доступности, а также полный набор функций анализа, которые имеются в SQL Server 2005 Enterprise Edition. Standard Edition применяют в многопроцессорных системах, в которых установлено до 4 процессоров и до 2 Гб ОЗУ.

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

Desktop Engine (MSDE). В эту редакцию входят базовые функции механизма баз данных SQL Server 2005, однако не входят пользовательский интерфейс, управляющие инструменты, функции анализа, лицензии на доступ клиентов, библиотеки разработчика и электронная документация. Здесь также ограничен размер базы данных и уровень загруженности при работе с пользователями. Редакция Desktop Engine требует меньше всего ресурсов по сравнению с остальными редакциями SQL Server 2005, поэтому она идеально подходит для реализации автономного хранилища данных.

Windows CE Edition. Эта редакция представляет собой версию SQL Server 2005 для устройств под управлением Windows CE. Она программно совместима с другими редакциями SQL Server 2005. Это позволяет разработчикам с помощью уже имеющихся у них навыков и приложений расширять функциональность реляционного хранилища данных решениями, работающими на новых классах устройств.

SQL Server 2005 состоит из ряда компонентов, которые формируют полнофункциональную реляционную СУБД [27].

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

Репликация - важная и мощная технология распределения данных и некоторых типов объектов баз данных (хранимых процедур, представлений и пользовательских функций) по всему предприятию. В репликации SQL Server используется принцип "публикации и подписки". Издатель (владелец) данных, подлежащих репликации, определяет статьи (аналогичные таблицам базы данных), которые надо сделать доступными для подписчиков (или для адресов, получающих копии оригинальной публикации) [26].

Data Transformation Services (DTS). Многим организациям для более эффективного принятия решений требуется централизация данных. Однако данные можно хранить в самых разнообразных форматах и в нескольких различных местах. DTS в SQL Server позволяет создавать хранилища и киоски данных путем интерактивного или автоматического импорта и передачи данных из нескольких источников по расписанию. DTS SQL Server 2005 существенно повышает эффективность процесса создания хранилищ данных для оперативной аналитической обработки (Online Analytical Processing, OLAP). Кроме того, он предоставляет средства для тонкой настройки обширных баз данных для оперативной обработки транзакций (Online Transaction Processing, OLTP), в результате чего можно увеличить число одновременно работающих пользователей, активно добавляющих и модифицирующих данные. Структура баз данных OLTP такова, что они регистрируют подробности каждой транзакции. SQL поддерживает извлечение данных из одного источника и выполнение сложных преобразований с последующим сохранением итоговых преобразованных данных в другом источнике данных. Этот компонент в значительной степени упрощает процесс извлечения данных из нескольких систем OLTP и создания на основе извлеченных данных хранилища или киоска данных для OLAP.

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

English Query помогает создавать приложения, способные автоматически настраиваться в соответствии со специальными вопросами, которые задают пользователи. Администратор определяет для обработчика English Query все логические связи между таблицами и столбцами базы данных. Затем пользовательское приложение может вывести специальное окно, в котором пользователю достаточно набрать символьную строку с вопросом (записанным на английском языке), касающимся данных в базе. Приложение передает эту строку обработчику English Query, который анализирует ее с учетом связей, определенных между таблицами. После этого English Query возвращает приложению SQL-запрос, при исполнении которого будет получен ответ на заданный пользователем вопрос. Посредством English Query разработчики могут преобразовывать реляционные базы данных в приложения English Query, которые позволяют конечным пользователям вместо формирования запроса с помощью оператора SQL, задавать вопросы на английском языке [26].

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

Books Online - это электронная документация, которая поставляется с SQL Server 2000 и представляет собой набор справочных файлов в формате НТМL, для просмотра которых необходим Microsoft Internet Explorer версии 5.0 или более поздней.

В состав SQL Server 2005 входит множество утилит. Они предназначены для пользователей, программистов и администраторов и позволяют решать широкий круг задач, в том числе [28]:

• администрировать и конфигурировать SQL Server;

• конструировать и тестировать запросы;

• копировать, импортировать, экспортировать и преобразовывать данные;

• выводить диагностическую информацию;

• запускать и останавливать SQL Server.

Информация обо всех инструментах подробно описана в Books Online.

SQL Server Enterprise Manager основной инструмент администрирования SQL Server 2005, позволяющий решать ряд административных задач:

• определять группы серверов, работающих под управлением SQL Server;

• регистрировать отдельные серверы в группе;

• настраивать любые параметры SQL Server для всех зарегистрированных серверов;

• определять и исполнять все административные задачи SQL Server на каждом зарегистрированном сервере;

• интерактивно конструировать и тестировать операторы SQL, пакеты и сценарии, вызывая SQL Query Analyzer;

• вызывать различные мастера SQL Server.

SQL Server Agent отвечает за решение следующих задач:

• запуск заданий SQL Server, запланированных для исполнения в определенное время или по истечении определенного периода времени;

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

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

SQL Profiler - это инструмент для записи событий SQL Server 2005. События сохраняются в файле трассировки, который впоследствии можно проанализировать или использовать для повтора некоторой последовательности действий при диагностировании возникшей проблемы. SQL Profiler применяется для:

• пошагового исполнения проблемных запросов и определения источника проблемы;

• поиска и диагностики медленных запросов;

• записи последовательностей SQL-операторов, приводящих к возникновению проблем;

• мониторинга производительности SQL Server и регулирования его загруженности.

SQL Profiler также поддерживает аудит действий, выполненных с экземплярами SQL Server. Информация о действиях, имеющих отношение к безопасности, сохраняется для последующего просмотра администратором, отвечающим за безопасность [26].

Client Network используется для управления клиентскими библиотеками Net-Libraries и определения псевдонимов серверов. Большинству пользователей утилита Client Network никогда не понадобится. Для подключения к SQL Server 2005 им достаточно указать сетевое имя сервера, на котором работает SQL Server, и (что не обязательно) имя экземпляра SQL Server.

Server Network Utility. Утилита Server Network применяется для управления серверными библиотеками Net-Libraries, а также позволяет задавать:

• стеки сетевых протоколов, используемые экземпляром SQL Server 2005 для прослушивания клиентских запросов;

• последовательность, в которой серверные библиотеки Net-Libraries определяют, не устанавливает ли приложение соединение;

• новые сетевые адреса для прослушивания запросов экземпляром SQL Server 2005.

Большинству администраторов утилита Server Network также никогда не понадобится. Они могут задать серверные библиотеки Net-Libraries во время установки сервера [28].

SQL Server Service Manager предназначен для запуска, остановки и приостановки серверных компонентов SQL Server 2005. Эти компоненты работают как службы в Microsoft Windows NT или Windows 2000, а в Windows 95 и Windows 98 - как отдельные исполняемые программы.

Окно Service Manager может быть скрыто и представлено значком в системной области панели задач. Чтобы вывести меню со списком задач, которые поддерживает Service Manager, необходимо щелкнуть правой кнопкой значок на панели задач [28].

SQL Query Analyzer - это инструмент, предназначенный для решения множества различных задач:

• создания запросов и сценариев SQL, а также исполнения их с базами данных SQL Server;

• создания часто используемых объектов баз данных в стандартных сценариях;

• копирования существующих объектов баз данных;

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

• отладки хранимых процедур;

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

• поиска объектов в базах данных, а также просмотра и работы с объектами;

• добавления, обновления и удаления строк в таблице;

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

• добавления часто используемых команд в меню Tools. Встроенные мастера. В состав SQL Server 2005 входит несколько мастеров, помогающих администраторам и программистам решать сложные административные задачи, а также всем пользователям просматривать и модифицировать информацию в базах данных SQL Server. Подробное описание этих мастеров хранится в SQL Server Books Online.

2.2.3 SQL-запросы

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

Достоинства SQL

·        независимость от конкретных СУБД;

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

·        переносимость с одной вычислительной системы на другую;

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

·        наличие стандартов;

Официальный стандарт языка SQL был опубликован Американским национальным институтом стандартов (American National Standards Institute - ANSI) и Международной организацией по стандартизации (International Standards Organization - ISO) в 1986 году, расширен в 1989 году, а затем - в 1992 и 1999 годах. Кроме того, SQL является федеральным стандартом США в области обработки информации (FIPS - Federal Information Processing Standard) и, следовательно, соответствие ему является одним из основных требований, содержащихся в больших правительственных контрактах на разработки в компьютерной промышленности. В течение последних десяти лет многие другие международные, правительственные и промышленные группы вносили свой вклад в стандартизацию различных составляющих SQL, таких как интерфейсы программирования и объектно-ориентированные расширения. Со временем многие из подобных инициатив стали составной частью стандарта ANSI/ISO. Все эти стандарты служат как бы официальной печатью, одобряющей SQL, и ускорили завоевание им рынка.

·        поддержка со стороны компании Microsoft (протокол ODBC);

Компания Microsoft рассматривает подсистему доступа к базам данных как важную часть своей операционной системы Windows. Стандартом этой компании по обеспечению доступа к базам данных является протокол ODBC (Open Database Connectivity - открытый доступ к базам данных) - программный интерфейс, основанный на SQL. Протокол ODBC поддерживается наиболее распространенными Windows-приложениями (электронными таблицами, текстовыми редакторами, базами данных и т. п.), разработанными как самой компанией Microsoft, так и другими ведущими поставщиками. Поддержка ODBC обеспечивается также всеми ведущими реляционными СУБД. Позднее Microsoft реализовала объектно-ориентированные надстройки над ODBC, в частности технологии OLE DB и ADO. Когда в конце 1980-х компания приступила к превращению системы Windows в жизнеспособную серверную операционную систему, был предложен собственный продукт Microsoft на базе SQL - SQL Server. Сегодня SQL Server остается ведущим продуктом Microsoft и ключевым компонентом ее архитектуры .NET для Web-сервисов.

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

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

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

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

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

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

·        возможность различного представления данных;

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

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

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

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

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

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

Недостатки SQL

·        Несоответствие реляционной модели данных

ü  Повторяющиеся строки

ü  Неопределённые значения (nulls)

ü  Явное указание порядка колонок слева направо

ü  Колонки без имени и дублирующиеся имена колонок

ü  Отсутствие поддержки свойства

ü  Использование указателей

ü  Высокая избыточность

·        Сложность

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

·        Отступления от стандартов

Несмотря на наличие международного стандарта ANSI SQL-92, многие компании, занимающиеся разработкой СУБД (например, Oracle, Sybase, Microsoft, MySQL AB, Borland), вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом появляются специфичные для каждой конкретной СУБД диалекты языка SQL. В частности, для управления планом выполнения запроса в некоторые реализации SQL добавлены подсказки.

·        Сложность работы с иерархическими структурами

Ранее SQL не предлагал стандартного способа манипуляции древововидными структурами. Некоторые поставщики СУБД предлагали свои решения. Например, Oracle использует выражение "CONNECT BY". В настоящее время в качестве стандарта принята рекурсивная конструкция "WITH".

2.2.4 Средства программного доступа к структуре баз данных

 

2.2.4.1        OLE DB

При работе с любым приложением обработки данных всегда является актуальным вопрос, как использовать те данные, которые уже были накоплены раньше другими программными средствами и, следовательно, имеют другой формат.позволяет решить эту проблему стандартным способом - путем импорта существующей таблицы базы данных, рабочего листа электронной таблицы или текстового файла, созданных приложениями MS-DOS или Windows, во внутренний формат базы данных Access (MDB). Естественно, что Access может также экспортировать данные из таблиц базы данных формата MDB в любой формат, из которого можно импортировать данные.

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

Помимо файлов баз данных, Access может работать непосредственно с файлами электронных таблиц, текстовыми файлами, документами HTML, адресными книгами или импортировать данные из этих файлов и документов XML.

Для этого используются либо встроенные драйверы ISAM (Index-Sequential Access Method- Индексно-последовательный метод доступа), либо драйверы ODBC (Open Database Connectivity - Открытый доступ к данным), либо поставщики данных OLE DB.

Все встроенные драйверы устанавливаются автоматически в процессе инсталляции Access. Из драйверов ODBC в комплект поставки Microsoft Access входят три драйвера- Microsoft SQL Server ODBC driver (Sqlsrv32.dll), FoxPro ODBC driver (vfpodbc.dll) и Oracle ODBC driver (msorcl32.dll). Кроме того, устанавливаются еще четыре провайдера OLE DB (Microsoft Jet 4.0 OLE DB Provider, Microsoft OLE DB Provider for SQL Server, OLE DB Provider for ODBC Drivers, OLE DB Provider for Oracle).

OLE DB - набор интерфейсов, основанных на COM, которые позволяют приложениям обращаться к данным, хранимым в разных источниках информации или хранилищах данных с помощью унифицированного доступа. Хотя OLE DB является очень мощным интерфейсом для работы с данными, этот интерфейс является низкоуровневым. Для удобства работы с OLE DB, так же как и для ODBC, была разработана объектная модель, которую назвали ADO (ActiveX Data Objects). Сетевая библиотека для источника данных может быть установлена с помощью параметра Data Sources (ODBC) на панели управления. Установленная сетевая библиотека для одного подключения становится библиотекой, используемой по умолчанию, для всех последующих подключений и для любого подключения без источника данных, которые может использовать приложение.

Рисунок 5 Свойства связи с данными

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

2.2.4.2 ADO (Active Data Objects)

Благодаря абстракциям OLE DB и объектной структуре объектная модель ADO и ее интерфейсы остаются одними и теми же независимо от типа обрабатываемых данных. Характеристики ADO перечислены в следующем списке.

·        Простая объектная модель для потребителей данных OLE DB.

·        Может использоваться из VBScript, JScript, Visual Basic, Java, C#, C++.

·        Единый стандарт Microsoft для доступа к данным.

·        Объекты доступа к данным остаются одними и теми же для всех типов данных OLE DB.

Объектная модель ADO, является надстройкой к объектной модели OLE DB. Соединение (объект Connection) - это первый объект ADO, который необходимо создать и который является основой для всех остальных. Из соединения разработчик может создать один или несколько наборов записей (объект RecordSet) и одну или несколько команд (объект Command). Все ошибки, которые генерируются в процессе создания любого из этих объектов и работы с ним, ADO будет помещать в специальную коллекцию Errors.

Каждый объект RecordSet имеет коллекцию полей (Fields); каждое поле (объект Field) в этой коллекции соответствует столбцу в наборе записей. Кроме того, каждая команда имеет коллекцию параметров (Parameters), элементы которой представляют переданные команде параметры.

Таблица 1 компоненты, входящие в состав db Go

Компонент dbGo	Описание	Эквивалент из комплекта BDE
ADOConnection	Подключение к базе данных	База данных
ADOCommand	Исполняет команду SQL	Нет эквивалента
ADODataSet	Многоцелевой наследник TDataSet	Нет эквивалента
ADOTable	Инкапсулирует таблицу	Table
ADOQuery	Инкапсулирует SQL SELECT	Query
ADOStoredProc	Инкапсулирует сохраненную процедуру (stored procedure)	StoredProc
RDSConnection	Подключение Remote Data Services	Нет эквивалента

Четыре компонента наборов данных Delphi (ADODataSet, ADOTable, ADOQuery и ADOStoredProc) фактически полностью реализованы общим для них базовым классом TCustomADODataSet. Этот компонент несет ответственность за выполнение большинства функций, присущих набору данных. Производные компоненты являются тонкими оболочками, которые делают доступными для внешнего мира те или иные возможности базового компонента. Таким образом, компоненты обладают множеством общих черт. Компоненты ADOTable, ADOQuery и ADOStoredProc предназначены для упрощения адаптации кода, ориентированного на BDE. Однако следует иметь в виду, что эти компоненты нельзя считать полностью идентичными эквивалентами аналогичных компонентов BDE.

Когда используется компонент ADOTable, он создает свой собственный компонент соединения с БД. Однако вовсе не обязательно использовать именно это соединение. В общем случае нужно создать свое собственное соединение при помощи компонента ADOConnection, который, по сути, является эквивалентом компонента SQLConnection из библиотеки dbExpress и компонента Database из библиотеки BDE. Компонент ADOConnection позволяет должным образом настроить процедуру аутентификации, контролировать транзакции, напрямую выполнять команды, адресованные БД, кроме того, он позволяет сократить количество подключений, существующих в рамках приложения.

В ADO для получения информации о схеме используется метод OpenSchema компонента ADOConnection. Этот метод принимает четыре параметра:

·        Тип данных, которые будут возвращаться методом OpenSchema. Это значение типа TSchemaInfo: набор из 40 значений, включая перечни таблиц, индексов, столбцов, представлений и сохраненных процедур.

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

·        GUID для запроса, специфичного для провайдера. Этот параметр используется, только если первый параметр равен значению siProviderSpecific.

·        Компонент ADODataSet, в составе которого будут возвращены данные. Этот параметр иллюстрирует распространенную в рамках ADO тему: если метод возвращает некоторое количество данных, он заносит эти данные в Recordset или, в терминологии Delphi, - в компонент ADODataSet.

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

ADOConnection1.OpenSchema(siPrimaryKeys, EmptyParam, EmptyParam, ADODataSet1);

Каждому полю в составе первичного ключа соответствует одна строка в результирующем наборе данных. Таким образом, если таблица обладает первичным ключом, состоящим из двух полей, в результирующем наборе данных такой таблице будут соответствовать две строки. Значение EmptyParam указывает на то, что параметру присваивается пустое значение, значит, параметр игнорируется.является общей программной моделью для работы с данными различных типов. Она разрабатывалась специально для того, чтобы заменить все другие интерфейсы работы с данными. Впервые она была реализована в Internet Information Server (IIS), где успешно работала вместе с Active Server Pages.

Модель включила ряд возможностей других известных объектных моделей (DAO и RDO), хотя и не полностью.

Так как ADO реализована на базе СОМ-объектов, то она может быть использована в любом языке, который может работать с СОМ-объектами, в том числе и в VBA.обеспечивает доступ к любому OLE DB источнику данных, для которого имеется OLE DB провайдер, и, более того, она позволяет расширить функциональность провайдера.реализована таким образом, чтобы минимизировать сетевой трафик в интернет-приложениях и сократить число промежуточных слоев между фронтальным (клиентским) приложением и источниками данных. Это требуется для того, чтобы сделать интерфейс как можно более легким и высокопроизводительным.обеспечивает объектно-ориентированный интерфейсный доступ в источники данных ODBC. Используя ADO, разработчики могут реализовать простые объекты, представляющие соединения с базой данных, команды (такие как операторы SQL или хранимые процедуры) и наборы записей, аналогичные курсорам клиента и обладающие в значительной степени такими же функциональными возможностями, как курсоры баз данных сервера. Когда ADO связывается с базой данных, работа происходит через сетевую библиотеку. Выбор сетевой библиотеки определяется поставщиком данных и конфигурацией системы, он может оказать существенное влияние на скорость доступа к базе данных. (рис.5) Например, если обращаются к данным из базы данных Microsoft SQL Server, скорость доступа, в общем случае, будет выше, если использовать сетевую библиотеку TCP/IP

2.2.4.3 ADOX (ADO Extension for DDL and Security)

ADOX - это дополнительная технология ADO, которая позволяет вам получать и изменять информацию о схеме. В SQL эквивалентом ADOX является язык DDL (Data Definition Language), то есть выражения CREATE, ALTER, DROP и DCL (Data Control Language), то есть выражения GRANT, REVOKE. В рамках dbGo технология ADOX напрямую не поддерживается, однако можно импортировать библиотеку типов ADOX и использовать ее в приложениях Delphi.Extension for DDL and Security (ADOX) применяется для решения различных задач, недоступных с помощью обычных объектов ADO. Например, используя объекты ADOX, можно извлекать метаданные из баз данных и, следовательно, переносить структуру данных из одной базы данных в другую (в том числе и иного типа). Вторая возможность, предоставляемая этим расширением, - манипулирование сведениями о безопасности. Например, с помощью ADOX можно получать информацию о пользователях базы данных и группах пользователей, а также создавать новых пользователей и группы. ADOX расширяет объектную модель ADO десятью новыми объектами, которые можно использовать как отдельно, так и вместе с другими объектами ADO, в частности можно применять объект ADO Connection для соединения с источником данных и извлекать метаданные из него.

Метаданные представляют собой описания объектов базы данных (таблиц, полей, индексов, ключей, представлений, хранимых процедур и прочих объектов). В подавляющем большинстве современных СУБД метаданные определяются с помощью языка SQL (Structured Query Language). До появления ADOX единственным программным способом извлечения метаданных из источников данных с помощью ADO был метод OpenSchema объекта ADO Connection. Для создания новых объектов в базе данных применялся язык Data Definition Language (DDL) - подмножество языка SQL, а также объект ADO Command.предоставляет более универсальный способ манипуляции метаданными, не требующий знания SQL для того, чтобы получить структуру базы данных или даже создать новые объекты. Обратите внимание на то, что ADOX работает далеко не со всеми базами данных - его функциональность ограничена Microsoft Access и Microsoft SQL Server, а также несколькими другими СУБД.обладает собственной объектной моделью, состоящей из 10 объектов, перечисленных в таблице 2. Эти объекты образуют иерархию, представленную на рис. 7.

Таблица 2. Описание объектов ADOX

Объект	Описание
Connection	Применяется для установки соединения с базой данных
Catalog	Представляет схему базы данных и обеспечивает доступ к коллекциям всех таблиц, процедур, пользователей и групп в базе данных
Table	Обеспечивает доступ к таблице в базе данных и доступ к полям, индексам и ключам
Column	Обеспечивает доступ к полю таблицы или полям, на основе которых создан индекс или ключ
Index	Обеспечивает доступ к индексу в таблице. Содержит коллекцию объектов Column, представляющих поля, на которых основан индекс
Key	Обеспечивает доступ к ключу в таблице. Содержит коллекцию объектов Column, представляющих поля, на которых основан ключ
View	Обеспечивает доступ к представлению (виртуальной таблице, view)
Procedure	Обеспечивает доступ к хранимой процедуре или запросу
User	Обеспечивает доступ к пользователю базы данных (user account)
Group	Обеспечивает доступ к группе пользователей базы данных

Рис. 7 Объектная модель ADOX

Иерархия объектов ADOX начинается с объекта Catalog. Этот объект содержит коллекции таблиц, представлений, процедур, пользователей и групп и может быть использован для открытия существующей базы данных (с помощью объекта ADO Connection), а также для создания новой.

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

Объекты Column, Index и Key обладают немалым количеством свойств, в таблице 3 приведены их краткие описания.

Таблица 3 Описание объектов

Column
Attributes	Содержит характеристики поля
DefinedSize	Содержит максимальный размер поля
NumericScale	Содержит сведения о положении десятичной точки для числового поля
ParentCatalog	Указывает на имя каталога, к которому принадлежит поле
Precision	Содержит максимальную точность данных в поле
RelatedColumn	Для ключевых полей содержит имя связанного поля
SortOrder	Указывает порядок сортировки в данных для поля
Type	Содержит тип данных, хранящихся в поле
Index
Clustered	Указывает, является ли индекс кластерным
IndexNulls	Указывает, как обрабатываются значения Null
PrimaryKey	Указывает, реализует ли данный индекс первичный ключ
Unique	Указывает, должен ли быть уникальным ключ, реализованный в данном индексе
Key
DeleteRule	Указывает, каким образом обрабатывается удаление записи, содержащей первичный ключ
RelatedTable	Для внешнего ключа указывает имя связанной таблицы
Type	Содержит тип ключа
UpdateRule	Указывает, как производится обновление записи, содержащей первичный ключ

Выводы по проведённому анализу:

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

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

В реализованной программе для доступа к данным применяется ADO. С помощью ADO можно получить доступ к данным, но нельзя считывать структуру БД. Для этого, применяется ADOX с помощью которого, можно решать различные задачи, недоступные с помощью обычных объектов ADO. SQL Script дополняет и создаёт БД.

Раздел 3. Описание разработки

 

.1 Основные системно-концептуальные соглашения

Как правило, на предприятиях тепловых сетей в качестве основной операционной системы обычно выбирают Microsoft Windows XP, в качестве СУБД SQL Server, поэтому при проектировании и реализации баз данных необходимо ориентироваться на её возможности. Также необходимо учитывать, что все компьютеры на предприятии объединены в локальную вычислительную сеть, использующую стек протоколов ТСР/IР.

В процессе будут применяться компоненты ADO (Active Data Objects) для доступа к данным; ADO Extension for DDL and Security - для доступа к структуре баз данных.

Обмен информацией между программой и БД обеспечивается с помощью механизмов ADO, благодаря чему БД может хранится в формате любой современной СУБД от MS Access, до SQL Server в зависимости от потребностей пользователя. Это, в том числе, позволяет использовать программу в локальных вычислительных сетях.

Среда разработки приложений Borland Delphi 7, СУБД- SQL Server 2005.

На сегодня Microsoft SQL Server является одним из самых популярных СУБД, представленных на рынке.

3.2 Блок схема

Рис. 8 Блок схема алгоритма

 

.3 Характеристика реализации

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

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

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

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

3.3.1 Назначение

Программа предназначена для автоматизации обновления структуры баз данных программного обеспечения ТПС. Основное назначение программы состоит в том, что бы максимально освободить пользователя от необходимости знания программирования и теории систем БД, а также позволить решать конкретные задачи в области расчёта и оптимизации ТПС.

3.3.2 Условия выполнения

Для работы системы обработки оперативной информации необходим следующий состав программных и аппаратных средств:

·        Процессор Intel Pentium (или аналогичный) с частотой 700 МГц;

·        128 МБ оперативной памяти;

·        8 МБ видеопамяти;

·        20 МБ свободного места на жёстком диске;

·        Операционная система Windows 2000, Windows XP;

·        СУБД Microsoft SQL Server 2005;

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

3.3.3 Порядок генерации SQL-скрипта

1.      Генерируем скрипт для создания таблиц с полями и автоматически запускаем его. (CREATE TABLE [название таблицы] [наименование поля данных] …)

.        Генерируем скрипт для создания первичных ключей (Primary Key) и автоматически запускаем его. (ALTER TABLE [наименование таблицы] ADD CONSTRAINT [наименование ключа] PRIMARY KEY [наименование ключа])

.        Генерируем скрипт для создания вторичных ключей (Foreign Key) и автоматически запускаем его. (ALTER TABLE [наименование таблицы] ADD CONSTRAINT [мигрирующий ключ] PRIMARY KEY [мигрирующий ключ])

3.3.4 Порядок переноса данных

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

.        Переносим данные из зависимых таблиц

3.3.5 Ограничения

1.      Первичный ключ - идентификатор (Primary Key) должен быть первым полем в таблице

.        Вторичные ключи (Foreign Key) должны быть мигрирующими, то есть наименование поля (FK) в главной таблице должен совпадать с наименованием поля в зависимой таблице.

Например: (FK_T_1_T_2 FORENKEY(id_1) REFERENCES T_1(id_1)) , как видно из примера в таблице T_2 наименование вторичного ключа "id_1" = наименованию ключа "id_1" в таблице T_1

3.      Haименование таблиц должно выглядеть как: T_[название таблицы], в связи с идентификацией таблиц созданных пользователем, т.к. MS SQL Server в свою очередь, в каждой базе данных создаёт целый ряд системных таблиц и процедур для внутреннего использования.

3.3.6 Описание интерфейса пользователя и его режимы генерации

Внешний вид интерфейса пользователя программы приведён на рис.9.

Рис. 9 Вид основного интерфейса при работе с программой

 

.3.7 Присоединение к БД

Рис.10 Пример списка таблиц проекта

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

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

3.3.8 Режимы генерации структуры SQL БД

Рис. 11 режимы генерации

1.      Автоматический режим - полностью переносит структуру БД. 

«Сверить структуру БД» - проверяет структуру между двумя присоединёнными базами.

«Перенести структуру БД» - переносит структуру  с одной базы в другую.

«Перенести данные» - переносит данные с одной базы в другую.

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

«Создать таблицу» - переносит выбранную таблицу  с одной базы в другую.

«Создать Primary Key» - переносит первичный  ключ с одной базы в другую.

«Создать Foreign Key» - переносит внешние  ключи с одной базы в другую.

«Добавить поле» - добавляет поле.

«Создать отчёт SQL» - создаёт отчёт в виде кода по всем произведённым действиям.

3.3.9 Настройки

Основные параметры генерации задаются в окне настроек (рис.12). При выборе режима генерации структуры SQL открывается окно настройки генерации, где необходимо выбрать нужное действие.

Рис. 12 Форма для настройки генерации

.        "Перенести всё (таблицы (с полями), PK, FK)" - переносит структуру выбранной БД в БД Access.

.        "Перенести (PK)(FK)" - переносит первичные и внешние ключи из выбранной БД в БД Access.

.        "Перенести только таблицы (с полями)" - переносит таблицы с полями из выбранной БД в БД Access.

.        "Перенести только PK" - переносит только первичные ключи из выбранной БД в БД Access.

.        "Перенести только FK (только если PK уже создан)" - переносит внешние ключи из выбранной БД в БД Access, если первичный ключ уже создан.

3.3.10 Выполнение программы

Для того что бы начать работу с программой, пользователю необходимо произвести подключение к базе данных. Первое диалоговое окно позволяет выбрать основную БД, откуда требуется обновить структуру (рис.13). Во втором открывшемся окне подключения необходимо выбрать БД для обновления структуры (рис. 14).

Рисунок 13 Подключение к БД SQL Server

Рисунок 14 Подключение к БД Access

В случае если пользователь при подключении к БД SQL Server выбрал не существующую базу, ему будет разрешён только просмотр данных. При подключении к БД Access база данных создаётся сама, необходимо только указать путь создания БД и имя БД.

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

3.4 Перенос структуры БД

Рисунок 15 Подключение к БД

Рисунок 16 Перенос структуры БД

Рисунок 17 Подключение к БД

Рисунок 18 Сверка структуры БД

Рисунок 19 Перенос структуры в Access

3.5 Перенос данных

Export 2007 for SQL ServerData Export for SQL Server - это мощный инструмент, предназначенный для быстрого экспорта данных из баз данных Microsoft SQL в любой из 19 доступных форматов, включая MS Access, MS Excel, MS Word (RTF), HTML, XML, PDF, TXT, CSV, DBF, ODF и другие. Data Export for SQL Server располагает удобным мастером настройки для визуальной установки параметров экспорта для каждой таблицы (конечные имена файлов, экспортируемые поля, форматы данных и многое другое) и консольной утилитой для быстрого экспорта данных из таблиц и запросов.

Ключевые особенности:

·        Экспорт данных в 19 форматов: MS Excel, MS Access, MS Word, RTF, HTML, PDF, XML, TXT, DBF, CSV, ODF, SYLK, DIF, LaTeX, SQL, буфер обмена и другие

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

·        Поддержка Unicode

·        Выбор полей для экспорта и изменение их порядка

·        Настраиваемые параметры экспорта для каждой таблицы, а также множество настроек экспорта для каждого формата данных

·        Возможность сохранения всех параметров экспорта активной сессии в файл конфигурации

·        Консольная утилита для автоматизации экспорта данных с помощью файла конфигурации

·        Поддержка новейших версий SQL Server

Рисунок 15 Data Export 2007 for SQL Server шаг 1

Рисунок 16 Data Export 2007 for SQL Server шаг 2

Рисунок 17 Data Export 2007 for SQL Server шаг 3

Рисунок 18 Data Export 2007 for SQL Server шаг 4

Рисунок 19 Data Export 2007 for SQL Server шаг 5

Рисунок 20 Data Export 2007 for SQL Server шаг 6

Рисунок 21 Data Export 2007 for SQL Server шаг 7

Рисунок 22 Data Export 2007 for SQL Server шаг 8

 

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

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

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

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

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

Данный раздел дипломного проекта посвящен рассмотрению следующих вопросов:

·   определение оптимальных условий труда инженера - программиста;

·   эргономика рабочего помещения.

 

4.1    Характеристика условий труда программиста

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

В настоящее время компьютерная техника широко применяется во всех областях деятельности человека. При работе с компьютером человек подвергается воздействию ряда опасных и вредных производственных факторов: электромагнитных полей (диапазон радиочастот: ВЧ, УВЧ и СВЧ), инфракрасного и ионизирующего излучений, шума и вибрации, статического электричества и др. [29]

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

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

4.2    Требования к производственным помещениям

 

4.2.1 Производственный микроклимат

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

Вычислительная техника является источником существенных тепловыделений, что может привести к повышению температуры и снижению относительной влажности в помещении. В помещениях, где установлены компьютеры, должны соблюдаться определенные параметры микроклимата. В санитарных нормах СанПин 2.2.4.548-96 [30] установлены величины параметров микроклимата, создающие комфортные условия. Эти нормы устанавливаются в зависимости от времени года, характера трудового процесса и характера производственного помещения (табл. 4).

Объем помещений, в которых размещены работники вычислительных центров, не должен быть меньше 20 м³/человека с учетом максимального числа одновременно работающих в смену. Нормы подачи свежего воздуха в помещения, где расположены компьютеры, приведены в табл. 5 Воздух рабочей зоны должен соответствовать санитарно-гигиеническим требованиям, утверждённым в ГОСТ 12.1.005-88 [31]

Таблица 4 Оптимальные параметры микроклимата для помещений с ПВЭМ

Период года	Параметр микроклимата	Величина
Холодный	Температура воздуха в помещении Относительная влажность Скорость движения воздуха	22…24°С 40…60% до 0,1м/с
Теплый	Температура воздуха в помещении Относительная влажность Скорость движения воздуха	23…25°С 40…60% 0,1…0,2м/с

Таблица 5 Оптимальные нормы подачи свежего воздуха в помещения с ПВЭМ

Характеристика помещения	Объемный расход подаваемого в помещение свежего воздуха, м3 /на одного человека в час
Объем до 20м3 на человека 20…40м3 на человека Более 40м3 на человека	Не менее 30 Не менее 20 Естественная вентиляция

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

4.2.2 Освещение

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

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

Согласно СанПин 2.2.1/2.1.1.1278-03 [32] в помещений вычислительных центров необходимо применить систему комбинированного освещения.

При выполнении работ категории ΙΙΙ высокая зрительная точность (наименьший размер объекта различения 0,3…0,5мм) величина коэффициента естественного освещения (КЕО) должна быть не ниже 1,5%, а при зрительной работе средней точности (наименьший размер объекта различения 0,5…1,0 мм) КЕО должен быть не ниже 1,0%. В качестве источников искусственного освещения обычно используются люминесцентные лампы типа ЛДЦ с улучшенной светопередачей, которые попарно объединяются в светильники, которые должны располагаться над рабочими поверхностями равномерно по системе общего освещения.

Требования к освещенности в помещениях с ПЭВМ, следующие: при выполнении зрительных работ высокой точности общая освещенность должна составлять 300лк, а комбинированная - 750лк; аналогичные требования при выполнении работ средней точности - 200 и 300лк соответственно.

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

4.2.3 Шум

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

Согласно СН 2.2.4/2.1.8.562-96 [33] предельные уровни звука в зависимости от категории тяжести и напряженности труда, являющиеся безопасными в отношении сохранения здоровья и работоспособности (табл. 6).

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

Категория напряженности труда	Категория тяжести труда
	I. Легкая	II. Средняя	III. Тяжелая	IV. Очень тяжелая
I. Мало напряженный	80	75	75
II. Умеренно напряженный	70	70	65	65
III. Напряженный	60	60	-	-
IV. Очень напряженный	50	50	-	-

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

4.2.3.1 Расчет уровня шума

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

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

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

где L_i - уровень звукового давления i-го источника шума;

n - количество источников шума.

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

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

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

Источник шума	Уровень шума, дБ
Жесткий диск	40
Вентилятор	45
Монитор	17
Клавиатура	10
Принтер	45
Сканер	42

Обычно рабочее место программиста оснащено следующим оборудованием: винчестер в системном блоке, вентилятор(ы) систем охлаждения ПК, монитор, клавиатура, принтер и сканер.

Подставив значения уровня звукового давления для каждого вида оборудования в формулу , получим:

_∑=10·lg(10⁴+10^4,5+10^1,7+10¹+10^4,5+10^4,2)=49,5 дБ

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

4.2.4 Электромагнитное и ионизирующее излучения

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

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

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

Таблица 8 Допустимые значения параметров неионизирующих электромагнитных излучений (соответствуют с СанПиН 2.2.2/2.5.1340-03 [34] и СанПин 2.2.2.542-96 [35])

Наименование параметра	Допустимые значения
Напряженность электрической составляющей электромагнитного поля на расстоянии 50см от поверхности видеомонитора	10В/м
Напряженность магнитной составляющей электромагнитного поля на расстоянии 50см от поверхности видеомонитора	0,3А/м
Напряженность электростатического поля не должна превышать: для взрослых пользователей для детей дошкольных учреждений и учащихся средних специальных и высших учебных заведений	20кВ/м  15кВ/м

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

4.3    Эргономические требования к рабочему месту

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

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

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

Главными элементами рабочего места программиста являются стол и кресло. Основным рабочим положением является положение сидя.

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

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

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

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

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

ДИСПЛЕЙ размещается в зоне а (в центре);

СИСТЕМНЫЙ БЛОК размещается в предусмотренной нише стола;

КЛАВИАТУРА - в зоне г/д;

"МЫШЬ" - в зоне в справа;

СКАНЕР в зоне а/б (слева);

ПРИНТЕР находится в зоне а (справа);

ДОКУМЕНТАЦИЯ: необходимая при работе - в зоне легкой досягаемости ладони - в, а в выдвижных ящиках стола - литература, неиспользуемая постоянно.

На рис. 24 показан пример размещения основных и периферийных составляющих ПК на рабочем столе программиста.

- сканер, 2 - монитор, 3 - принтер, 4 - поверхность рабочего стола,

- клавиатура, 6 - манипулятор типа "мышь".

Для комфортной работы стол должен удовлетворять следующим условиям согласно СанПиН 2.2.2/2.5.1340-03 [34] и СанПин 2.2.2.542-96 [35]):

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

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

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

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

·   высота рабочей поверхности рекомендуется в пределах 680-760мм. Высота поверхности, на которую устанавливается клавиатура, должна быть около 650мм.

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

Необходимо предусматривать при проектировании возможность различного размещения документов: сбоку от видеотерминала, между монитором и клавиатурой и т.п. Кроме того, в случаях, когда видеотерминал имеет низкое качество изображения, например заметны мелькания, расстояние от глаз до экрана делают больше (около 700мм), чем расстояние от глаза до документа (300-450мм). Вообще при высоком качестве изображения на видеотерминале расстояние от глаз пользователя до экрана, документа и клавиатуры может быть равным.

Положение экрана определяется:

·   расстоянием считывания (0,6…0,7м);

·   углом считывания, направлением взгляда на 20° ниже горизонтали к центру экрана, причем экран перпендикулярен этому направлению.

Должна также предусматриваться возможность регулирования экрана:

·   по высоте +3 см;

·   по наклону от -10° до +20° относительно вертикали;

·   в левом и правом направлениях.

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

·   голова не должна быть наклонена более чем на 20°,

·   плечи должны быть расслаблены,

·   локти - под углом 80°…100°,

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

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

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

Существенное значение для производительной и качественной работы на компьютере имеют размеры знаков, плотность их размещения, контраст и соотношение яркостей символов и фона экрана. Если расстояние от глаз оператора до экрана дисплея составляет 60…80 см, то высота знака должна быть не менее 3мм, оптимальное соотношение ширины и высоты знака составляет 3:4, а расстояние между знаками - 15…20% их высоты. Соотношение яркости фона экрана и символов - от 1:2 до 1:15.

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

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

.4      Окраска и коэффициенты отражения

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

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

В зависимости от ориентации окон рекомендуется следующая окраска стен и пола:

окна ориентированы на юг: - стены зеленовато-голубого или светло-голубого цвета; пол - зеленый;

окна ориентированы на север: - стены светло-оранжевого или оранжево-желтого цвета; пол - красновато-оранжевый;

окна ориентированы на восток: - стены желто-зеленого цвета;

пол зеленый или красновато-оранжевый;

окна ориентированы на запад: - стены желто-зеленого или голубовато-зеленого цвета; пол зеленый или красновато-оранжевый.

В помещениях, где находится компьютер, необходимо обеспечить следующие величины коэффициента отражения: для потолка: 60…70%, для стен: 40…50%, для пола: около 30%. Для других поверхностей и рабочей мебели: 30…40%.

4.5    Режим труда и отдыха

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

В табл. 9 представлены сведения о регламентированных перерывах, которые необходимо делать при работе на компьютере, в зависимости от продолжительности рабочей смены, видов и категорий трудовой деятельности с ВДТ (видеодисплейный терминал) и ПЭВМ (в соответствии с СанПиН 2.2.2 542-96 [35]

Таблица 9 Время регламентированных перерывов при работе на компьютере

Категория работы с ВДТ или ПЭВМ	Уровень нагрузки за рабочую смену при видах работы с ВДТ			Суммарное время регламентированных перерывов, мин
	Группа А, количество знаков	Группа Б, количество знаков	Группа В, часов	При 8-часовой смене	При 12-часовой смене
I	до 20000	до 15000	до 2,0	30	70
II	до 40000	до 30000	до 4,0	50	90
III	до 60000	до 40000	до 6,0	70	120

Примечание. При несоответствии фактических условий труда требованиям СанПин 2.2.2.542-96 [35] время регламентированных перерывов следует увеличить на 30%.

В соответствии со СанПиН 2.2.2 542-96 [35] все виды трудовой деятельности, связанные с использованием компьютера, разделяются на три группы:

группа А: работа по считыванию информации с экрана ВДТ или ПЭВМ с предварительным запросом;

группа Б: работа по вводу информации;

группа В: творческая работа в режиме диалога с ЭВМ.

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

4.6    Электробезопасность

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

токоведущие проводники, корпуса стоек ЭВМ и прочего оборудования, оказавшегося под напряжением в результате повреждения (пробоя) изоляции, не подают каких-либо сигналов, которые предупреждают человека об опасности. Реакция человека на электрический ток возникает лишь при протекании последнего через тело человека. Исключительно важное значение для предотвращения электротравмотизма имеет правильная организация обслуживания действующих электроустановок, проведения ремонтных, монтажных и профилактических работ. При этом под правильной организацией понимается строгое выполнение ряда организационных и технических мероприятий и средств, установленных в ГОСТ 12.1.038-82 ССБТ.[36] В зависимости от категории помещения необходимо принять определенные меры, обеспечивающие достаточную электробезопасность при эксплуатации и ремонте электрооборудования. В помещениях с повышенной опасностью электроинструменты, переносные светильники должны быть выполнены с двойной изоляцией или напряжение питания их не должно превышать 42 В. К таким помещениям могут быть отнесены помещения для размещения сервисной и периферийной аппаратуры. В особо опасных же помещениях напряжение питания переносных светильников не должно превышать 12 В, а работа с электротранспортируемым напряжением не выше 42 В разрешается только с применением СИЗ (диэлектрических перчаток, ковриков и т.п.).

В соответствии с ПТЭ и ПТВ потребителям и обслуживающему персоналу электроустановок предъявляются следующие требования :

·        лица, не достигшие 18-летнего возраста, не могут быть допущены к работам в электроустановках;

·        лица не должны иметь увечий и болезней, мешающих производственной работе;

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

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

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

4.7    Пожарная безопасность

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

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

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

Для большинства помещений (ИСЭМ) СО РАН установлена категория пожарной опасности В согласно НПБ 105-03. [37].

Одной из наиболее важных задач пожарной защиты является защита строительных помещений от разрушений и обеспечение их достаточной прочности в условиях воздействия высоких температур при пожаре. Учитывая высокую стоимость электронного оборудования, а также категорию его пожарной опасности, здания для (ИСЭМ) СО РАН и части здания другого назначения, в которых предусмотрено размещение ЭВМ должны быть 1 и 2 степени огнестойкости.

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

В зданиях (ИСЭМ) СО РАН пожарные краны устанавливаются в коридорах, на площадках лестничных клеток и входов. Вода используется для тушения пожаров в помещениях программистов, вспомогательных и служебных помещениях. При этом количество воды должно быть минимальным, а устройства ЭВМ необходимо защитить от попадания воды, накрывая их брезентом или полотном. Для тушения пожаров на начальных стадиях широко применяются огнетушители.

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

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

4.7.1 Действия персонала в условиях ЧС

При возникновении пожара нужно:

. Вызвать пожарную охрану;

. Организовать вывод на улицу тех, кому нужна помощь;

. Тушить пожар первичными средствами пожаротушения ( огнетушителями, водой, песком, плотной мокрой тканью, от внутренних пожарных кранов);

. Отключить электроэнергию.

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

. Сообщитеь пожарным об оставшихся в помещении людях.

Эвакуация согласно плана (рис 25.)

Рис. 25 План эвакуации людей при пожаре

Условные обозначения:

 − огнетушитель

− пожарный кран

Выводы по разделу:

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

Раздел 5. Экономическая часть

 

5.1    Анализ технико-экономических показателей разработки программного продукта на основе "актуализация структур баз данных при расчётах и оптимизации трубопроводных систем"

 

.1.1 Краткая характеристика разработки и её назначение

Разработка данного программного продукта направлена на исследование возможных подходов и разработки программных средств, для обновления структуры баз данных для расчёта и оптимизации ТПС.

.1.2 Определение затрат на создание программного продукта

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

З_спп = З^зп_спп + З^мв_спп + З_ПО +З_общ ,

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

З^зп_спп - затраты на оплату труда разработчика программы;

З^мв_спп - затраты на оплату машинного времени;

З_ПО - затраты на приобретение ПО;

З_общ - общие затраты;

. Расходы на оплату труда разработчика программы

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

З^зп_спп=t * T_час.

Трудоёмкость разработки программного продукта можно определить следующим образом:

 = t_о+ t_а + t_б + t_п + t_д + t_от ,

_о - затраты труда на подготовку описания задачи;

t_а - затраты труда на разработку алгоритма решения задачи;

t_б - затраты труда на разработку блок-схемы алгоритма решения задачи;

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

t_д - затраты труда на подготовку документации задачи;

t_от - затраты труда на отладку программы на ЭВМ при комплексной отладке задачи;

Составляющие затрат, в свою очередь можно вычислить через условное число программистов Q. В нашем случае число программистов в отлаженной программе Q ≈ 1500.

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

_и = Q * B /(75...85 * K),

где

B - коэффициент увеличения затрат труда вследствие недостаточного описания задачи, уточнений и некоторой не доработки, B=1,2...5;

K - коэффициент квалификации разработчика, для работающих до 2 лет К=0.8;

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

Таким образом, получим

_о = 1500 * 3/(80 * 0.8) = 70,5 (час).

Затраты труда на разработку алгоритма решения задачи:

_а = Q/(60...75 * K) = 1500/(65*0.8) = 28,8 (час).

Затраты труда на разработку блок-схемы алгоритма решения задачи вычислим следующим образом:

_б = Q /(60...75 * K) = 1500/(65*0.8) = 28,8 (час).

Затраты труда на составление программы по готовой блок-схеме вычислим по формуле:

_п = Q/(60...75 * K) = 1500/(65*0.8) = 28,8 (час).

Затраты труда на отладку программы на ЭВМ при комплексной отладке задачи:

_от = 1.5 * t^A_от ,

^A_от - затраты труда на отладку программы на ЭВМ при автономной отладке одной задачи;

t^A_от = Q/(40...50 * K) = 1500/(45*0.8) = 41,7 (час).

Отсюда t_от = 1.5*41,7 = 62,5 (час).

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

_д = t_др + t_до ,

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

t_до - затраты на редактирование, печать и оформление документации;

_др = Q/(150...200 * K) = 1500/(175*0.8) = 10,7 (час);

t_до = 0.75 * t_др = 0.75*10,7 = 8 (час);

Отсюда t_д = 10,7 + 8 = 18,7 (час).

Итак, общую трудоёмкость программного продукта можем рассчитать:

 = 70,5+28,8+28,8+28,8+41,7+62,5 = 261 (час).

Средняя зарплата программиста в современных рыночных условиях может варьироваться в широком диапазоне. Для расчёта возьмём среднюю часовую оплату труда, которая составляет Т_час = 60 руб/час, что составляет 10560 руб/мес при 8-ми часовом рабочем дне и 5-ти дневной рабочей неделе. Эта цифра близка к реальной заработной плате программиста в г. Иркутске.

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

1 пенсионный фонд (29%),

2 медицинское страхование (3.6%),

3 социальное страхование (5.4%),

4 фонд занятости (1.5%),

5 сбор на образование (1%).

Итого отчисления на социальные нужды составляют 40,5%. Отсюда затраты на оплату труда программиста составляют:

З^зп_спп = 261 * 60 + ((261 * 60) * 40,5%) = 22000 руб.

2. Затраты на оплату машинного времени

Затраты на оплату машинного времени при отладке программы определяются путём умножения фактического времени отладки программы на цену часа арендного времени:

З^мв_спп = С_час * t _эвм,

С_час - цена часа арендного времени, руб/час;

t_эвм - фактическое время отладки программы на ЭВМ;

Фактическое время отладки вычислим по формуле:

_эвм = t_п + t_до + t_от;

t_эвм = 28,8 +62,5 +8= 99,2 часа.

Цену машино-часа найдём по формуле:

С_час = З_эвм/Т_эвм ,

З_эвм - полные затраты на эксплуатацию ЭВМ в течении года;

Т_эвм - действительный годовой фонд времени ЭВМ, час/год;

Расчёт годового фонда времени работы ПЭВМ IBM PC ATЖ

Общее количество дней в году - 365.

Число праздничных и выходных дней - 119.

Время простоя в профилактических работах определяется как еженедельная профилактика по 4 часа.

Итого годовой фонд рабочего времени ПЭВМ составляет:

Т_эвм = 8*(365-119) - 52*4 = 1760 часа.

Полные затраты на эксплуатацию ЭВМ можно определить по формуле:

З_эвм = (З_зп + З_ам + З_эл + З_вм + З_тр + З_пр),

З_зп - годовые издержки на заработную плату обслуживающего персонала, руб/год;

З_ам - годовые издержки на амортизацию, руб/год;

З_эл - годовые издержки на электроэнергию, потребляемую ЭВМ, руб/год;

З_вм - годовые издержки на вспомогательные материалы, руб/год;

З_тр - затраты на текущий ремонт компьютера, руб/год;

З_пр - годовые издержки на прочие и накладные расходы, руб/год;

. Амортизационные отчисления

Сумма годовых амортизационных отчислений определяется по формуле:

З_ам = С_бал * Н_ам ,

С_бал - балансовая стоимость компьютера, руб/шт;

Н_ам - норма амортизации, %;

Согласно постановления совета министров СССР от 22 октября 1990 года № 1072 "#G0О единых нормах амортизационных отчислений на полное восстановление основных фондов народного хозяйства СССР" Н_ам = 12.5%.

Балансовая стоимость ПЭВМ включает отпускную цену, расходы на транспортировку, монтаж оборудования и его наладку:

С_бал = С_рын + З_уст ;

С_рын - рыночная стоимость компьютера, руб/шт.,

З_уст - затраты на доставку и установку компьютера, руб/шт.

Компьютер, на котором велась работа, был приобретен по цене С_рын = 19000 руб, затраты на установку и наладку составили примерно 10% от стоимости компьютера

З_уст = 10% * С_рын = 0.1 * 19000 =1900 руб.

С_бал = 19000 + 1900 = 20900 руб./шт.,

З_ам = 20900 * 0.125= 2612.5 руб/год.

4.Расчёт затрат на электроэнергию

Стоимость электроэнергии, потребляемой за год, определяется по формуле:

З_эл = Р_эл * Т_эвм * С_эл * А,

Р_эвм - суммарная мощность ЭВМ,

С_эл - стоимость 1кВт*ч электроэнергии,

А - коэффициент интенсивного использования мощности машины.

Согласно техническому паспорту ЭВМ Р_эвм = 0.35 кВт, стоимость 1кВт*ч электроэнергии для предприятий С_эл = 0.848 руб., интенсивность использования машины А = 0.98.

Тогда расчётное значение затрат на электроэнергию:

З_эл = 0.35*1760*0.848*0.98 = 512 руб.

5. Расчёт затрат на текущий ремонт

Затраты на текущий и профилактический ремонт принимаются равными 5% от стоимости ЭВМ:

З_тр = 0.05 * С_бал = 0.05*20900 = 1045 руб.

6.Расчёт затрат на вспомогательные материалы

Затраты на материалы, необходимые для обеспечения нормальной работы ПЭВМ составляют около 1% от стоимости ЭВМ:

З_вм = 0.01*20900 = 209 руб.

7. Прочие затраты по эксплуатации ПЭВМ

Прочие косвенные затраты, связанные с эксплуатацией ПЭВМ, состоят из амортизационных отчислений на здания, стоимости услуг сторонних организаций и составляют 5% от стоимости ЭВМ:

З_пр = 0.05*20900 = 1045 руб.

8. Годовые издержки на заработную плату обслуживающего персонала

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

З_зп = З^осн_зп + З^доп_зп + З^отч_зп .

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

З^осн_зп = 12*åЗⁱ_окл

где Зⁱ_окл - тарифная ставка i-го работника в месяц, руб.;

В штат обслуживающего персонала должны входить инженер-электронщик с месячным окладом 3000 руб. и электрослесарь с окладом 1500 руб.

Тогда, издержки на основную заработную плату обслуживающего персонала составят:

З^осн_зп = 12*(2500 + 1500) = 48000 руб.

Сумма дополнительной заработной платы составляет 60% от основной заработной платы:

З^доп_зп = 0.6*48000 = 28800 руб.

Сумма отчислений на социальные нужды составляет 40.5% от суммы дополнительной и основной заработных плат:

З^отч_зп = 40.5*(48000 + 28800) = 48240 руб.

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

З_зп = 48000 + 28800 +48240= 125040 руб.

9. Полные затраты на эксплуатацию ЭВМ

Полные затраты на эксплуатацию ЭВМ в течение года составят:

З_эвм = 125040+2612,5+512+209+1045+1045= 130463,5 руб.

Тогда цена часа арендуемого времени составит

С_час = 130463,5 / 1760 = 74 руб.

А затраты на оплату машинного времени составят:

З^мв_спп = 74 * 99,2 = 7340,8 руб.

. Расчёт расходов на приобретение программного обеспечения

Таблица 10 Расчет расходов на ПО.

№	Наименование ПО	Кол-во	Стоимость за единицу	Общая стоимость
1	Borland Delphi	1 шт.	31000 руб.	31000 руб.
2	MS SQL Server 2005	1 шт.	39000 руб.	39000 руб.

Итого: 60000 руб.

З_ПО = 60000 руб.

. Расчёт общих расходов

Общие расходы это расходы на освещение, отопление, коммунальные услуги и т.п. Они принимаются равными одной трети основой зарплаты разработчика программы т.е. З_общ = 7333 руб.

Тогда затраты на создание программного продукта составят:

З_спп = 22000 + 7340,8 + 60000 + 7333= 96673,8 руб.

Выводы по разделу:

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

·        повышение производительности труда;

·        улучшения качества ввода;

·        снижение требований к персоналу при устройстве на работу.

 

Заключение

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

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

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

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

Наиболее подходящей СУБД для решения данной задачи является Microsoft SQL Server. Для манипуляции с данными, используется язык SQL. SQL обеспечивает независимость от конкретных СУБД, что является одной из наиболее важной причиной его выбора, также язык SQL является простым и лёгким для изучения. В подавляющем большинстве современных СУБД метаданные определяются с помощью языка SQL (Structured Query Language). В реализованной программе для доступа к данным применяется ADO. С помощью ADO можно получить доступ к данным, но нельзя считывать структуру БД. Для этого, применяется ADOX с помощью которого, можно решать различные задачи, недоступные с помощью обычных объектов ADO. SQL Script дополняет и создаёт БД.

5.        Произведено обоснование выбора инструментальных средств, рассмот рена характеристика реализации. Разработана программа для автоматизации обновления структуры баз данных программного обеспечения ТПС. Назначение программы состоит в том, что бы максимально освободить пользователя от необходимости знания программирования и теории систем БД, а также позволяет решать конкретные задачи в области расчёта и оптимизации ТПС. Обновлять структуру БД, а также данные.

 

Список литературы

1. Громов Н. К. Городские теплофикационные системы. М. :Энергия, 1974.

. Сафонов А. П. Автоматизация систем централизованного теплоснабжения. -М., 1974.

. Соколов Е. Я. Теплофикация и тепловые сети, 4 изд. - М., 1975.

. Зингер И. М. Гидравлические и тепловые режимы теплофикационных систем. -М.: Энергия, 1976.

. Чистович С.А., Аверьянов В.К., Темпель Ю.Я. и др. Автоматизированные системы теплоснабжения и отопления. Л.: Стройиздат., 1987.

. Горская Н. И. Автоматизация выявления повреждений в тепловых сетях. - Новосибирск: Наука, 1987.

. Сеннова Е. В., Сидлер В. Г. Математическое моделирование и оптимизация развивающихся теплоснабжающих систем. - Новосибирск: Наука, 1987.

. Сеннова Е.В. Оптимизация развития и реконструкции теплоснабжающих систем. - Новосибирск: Наука, 1987.

. Меренков А. П., Сеннова Е. В., Сумароков С. В. и др. Математическое моделирование и оптимизация систем тепло-, водо-, нефте- и газоснабжения. - Новосибирск: ВО Наука, 1992.

. Разработка и развитие методических основ и алгоритмической базы для комплексного решения задач управления функционированием современных трубопроводных систем энергетики. Отчет о комплексной научно-исследовательской работе; руководитель А. П. Меренков, ответственный исполнитель Н. Н. Новицкий. Иркутск: ИСЭМ СО РАН, 1993.

11. Сеннова Е. В., Каганович Б. М., Ощепкова Т. Б. Исследование надежности при оценке различных принципов построения теплофикационных систем// Методические вопросы исследования надежности больших систем энергетики. -1975.

12. Разработать научно-методические материалы по разработке ТЗ на АСУТП систем теплоснабжения. Научный отчет. М.: ВНИПИЭнергопром, 1988.

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

. Сидлер В. Г. Линейная и нелинейная модели для оценивания параметров гидравлических сетей. - Иркутск: ИСЭМ СО РАН, 1977.

. Сидлер В. Г., Новицкий Н. Н. Идентификация трубопроводных систем как гидравлических цепей с переменными параметрами. - Иркутск: ИСЭМ СО РАН, 1984.

. Гарсия-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс: Пер. с англ. - М.: Вильяме, 2003. - 1088 с.

. Дейт К. Введение с системы баз данных. Шестое издание. Киев: Диалектика, 1998. - 784 с.

. Мартин Дж. Организация баз данных в вычислительных системах. - М.: Мир, 1980. - 662 с.

. Массель Л.В., Болдырев Е.А., Горнов А.Ю. Интеграция информационных технологий в системных исследованиях энергетики. - Новосибирск: Наука, 2003. - 320 с.

. Харриштон Д. Проектирование объектно-ориентированных баз данных: Пер. с англ. - М.: ДКМ Пресс, 2001. - 272 с.

. http://www.intersystems.ru

. Сборник научных трудов института проблем моделирования в энергетике им. Г.Е. Пухова. Информационные технологии в энергетике. - Киев: Диалектика, 2004. - 105 с.

23. Урман Ск. Огас1е9i. Программирование на языке PL/SQL. Пер. с англ. -М.: Лори, 2004. - 528 с.

24. Луни К., Терьо М. Огас1е9i. Настольная книга администратора: Пер. с англ. - М.: Лори, 2003. - 766 с.

. Эбби М., Кори М., Абрамсон И. Первое знакомство: Основы баз данных Огас1е9i: Пер. с англ.-М.:Вилъямс, 2003. -518с.

. Пирогов В. MS SQL Server 2000: управление и программирование. Спб.: БХВ-Петербург, 2005,- 598 с,

. Гарсиа М., Рединг Дж., Уолен Э., ДеЛюк С, Microsoft SQL Server 2000. Справочник администратора. - Спб.: СП ЭКОМ, 2004. -976 с.

28. Мамаев Е. Microsoft SQL Server 2000. Наиболее полное руководство. -Спб.: БХВ-Петербург, 2004, - 1280 с.

. Бавдик Н.В. Электромагнитная безопасность человека. -Иркутск: Изд-во ИрГТУ. - 2002. -92 с.

. СанПиН 2.2.4.548-96. Гигиенические требования к микроклимату производственных помещений.

. ГОСТ 12.1.005-88 ССБТ. Воздух рабочей зоны. Общие санитарно-гигиенические требования.

. СанПиН 2.2.1/2.1.1.1278-03. Естественное и искусственное освещение.

. СН 2.2.4/2.1.8.562-96. Шум на рабочих местах в помещениях жилых общественных зданий и на территории жилой застройки.

. СанПиН 2.2.2/2.5.1340-03. Гигиенические требования к персональным электронно-вычислительным машинам и организация работ.

. СанПиН 2.2.2.542-96. Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организация работы.

. ГОСТ 12.1.038-82 ССБТ. Электробезопасность. Общие требования безопасности.

.        НПБ 105-03. Определение категорий помещений, зданий и наружных установок по взрывопожарной и пожарной опасности.

Приложение

Автоматический режим

1.1    Сверка структуру БД

procedure TFDiplomADOX.BCheckStrucClick(Sender: TObject);,j,IZcount,Vcount,IZlevel:integer;,Vtext:string;(PM.Handle);.Cursor:= crHourGlass;.Items.BeginUpdate;.FullExpand;.FullExpand;:=TVIZ.Items.Count;:=TVV.Items.Count;:=IZcount-1;(IZcount > 1) and (Vcount > 1) thenwhile i <> 1 doTVIZ.Items.Item[i].Selected:=true;:=TVIZ.Items.Item[i].Text;:=TVIZ.Items.Item[i].Level;:=Vcount-1;j <> 1 doTVV.Items.Item[j].Selected:=true;:=TVV.Items.Item[j].Text;(IZlevel = 4) and (GetStrItemsName(IZtext) = Vtext) then.Items.Item[i].Delete;; end; dec(j); end; dec(i); end; end;:=TVIZ.Items.Count;:=TVV.Items.Count;:=IZcount-1;(IZcount > 1) and (Vcount > 1) thenwhile i <> 1 do.Items.Item[i].Selected:=true;:=TVIZ.Items.Item[i].Text;:=TVIZ.Items.Item[i].Level;:=Vcount-1;j <> 1 do.Items.Item[j].Selected:=true;:=TVV.Items.Item[j].Text;(IZlevel = 3) and ((IZtext = 'Columns') or (IZtext = 'Keys')) and (not TVIZ.Items.Item[i].HasChildren) then.Items.Item[i].Delete;; end; dec(j); end; dec(i); end; end;:=TVIZ.Items.Count;:=TVV.Items.Count;:=IZcount-1;(IZcount > 1) and (Vcount > 1) thenwhile i <> 1 do.Items.Item[i].Selected:=true;:=TVIZ.Items.Item[i].Text;:=TVIZ.Items.Item[i].Level;:=Vcount-1;j <> 1 do.Items.Item[j].Selected:=true;:=TVV.Items.Item[j].Text;(IZlevel = 2) and GetStrTable(IZtext) and (not TVIZ.Items.Item[i].HasChildren) then.Items.Item[i].Delete;; end; dec(j); end; dec(i); end; end;:=TVIZ.Items.Count;.Items.Item[1].Selected:=true;.Items.EndUpdate;(0);.Cursor:= crDefault;IZcount <= 2begin Struc:=true;not checkapplication.MessageBox('Различий в структурах БД не обнаружено','Внимание',MB_OK+MB_ICONINFORMATION).MessageBox('Структура БД перенесена успешно, Различий в структурах БД не обнаружено','Внимание',MB_OK+MB_ICONINFORMATION);:= false; end; endbegin

Struc:=true; end; end;

1.2   
Перенос структуры БД

procedure TFDiplomADOX.BGenerateStrucClick(Sender: TObject);,i,j:integer;:string;.ShowModal;(st >= 0) and (fin >= 0) then:=FAlSE;(TVIZ.Handle);.Cursor:= crHourGlass;:=TVIZ.Items.Count;i := st to fin doj := 1 to Count - 1 do.Items.Item[j].Selected:=true;:=TVIZ.Items.Item[j].Text;GetStrTable(text) then(i = 0) and (not FLAGC) then BCreateTClick(Sender);(i = 1) and (not FLAGC) then BAlterTPKClick(Sender);(i = 2) and (not FLAGC) then BAlterTFKClick(Sender);;;;.FullCollapse;TVIZ.Items.Count > 2 then.Items.Item[2].MakeVisible else.Items.Item[1].MakeVisible;:=TRUE;.Lines.SaveToFile('SQLReport.sql');.Lines.Clear;Click(Sender);(0);.Cursor:= crDefault;:=true;TVIZ.Items.Count < 1000 then(Sender);;;

1.3    Перенос данных БД

procedure TFDiplomADOX.BReportDataClick(Sender: TObject);FileExists('MsExport.exe')winexec(pchar('MsExport.exe'),1)application.MessageBox('Файл "\MsExport.exe" не найден','Ошибка',MB_OK+MB_ICONERROR);;TFDiplomADOX.ExecSQLClick(Sender: TObject);:= CoCatalog.Create;FileExists(pDS)E0.Text:='OK'CatalogD.Create(DS);.Close;.ConnectionString:=DS;.Open;.Lines.Add(E.Text);.SQL.Text:=E.Text;.ExecSQL();.Close;.Caption:='';.Clear;;

Ручной режим

1.4    Создание таблицы

procedure TFDiplomADOX.BCreateTClick(Sender: TObject);,ai,ailc,i:integer;:boolean;:=1;:=1;:=TVIZ.Items.Count;(count <=2) or (TVIZ.Selected.Level <> 2) then.MessageBox('Выберите в дереве (слева) название таблицы которую хотите создать','Ошибка',MB_OK+MB_ICONERROR);;;(tviz);:=TVIZ.Items.Count;:=TVIZ.Selected.AbsoluteIndex;:=TVIZ.Items.Item[ai].GetLastChild.AbsoluteIndex;.Items.Item[ailc+i].Selected:=true;TVIZ.Selected.Parent.Text = 'Columns' do(tviz);(i);:=true;ailc+i <> countTVIZ.Items.Item[ailc+i].Selected:=truebreak;;Field then(Sender);:=false;e.Text := 'Нет полей!';FLAGC then MenuConnect2Click(Sender);.Items.Item[ai].Selected:=true;.SetFocus;;

1.5    Создание Primary Keys

procedure TFDiplomADOX.BAlterTPKClick(Sender: TObject);,ai,aifc,i:integer;:string;:boolean;:=1; Gen:=2;:=TVIZ.Items.Count;(count <=2) or (TVIZ.Selected.Level <> 2) then.MessageBox('Выберите в дереве (слева) название таблицы в которой есть PK','Ошибка',MB_OK+MB_ICONERROR);.Caption:='Внимание! PK может быть создан только после создания всех таблиц (с полями)';

exit; end;(tviz);:=TVIZ.Selected.AbsoluteIndex;:=TVIZ.Items.Item[ai].getFirstChild.AbsoluteIndex;.Items.Item[aifc+i].Selected:=true;(TVIZ.Selected.Parent.Text = 'Keys') doText:=TVIZ.Selected.Text;(GetStrPK_Keys(Text) = 1) then(tviz);:=TRUE;;(i);aifc+i <> countTVIZ.Items.Item[aifc+i].Selected:=truebreak;;PK then(Sender);:=false;

else e.Text := 'Нет идентификационных ключей!';

if FLAGC then MenuConnect2Click(Sender);.Items.Item[ai].Selected:=true;.SetFocus; end;

1.6    Создание Foreign Keys

procedure TFDiplomADOX.BAlterTFKClick(Sender: TObject);,ai,aifc,i:integer;:string;:boolean;:=1;:=2;:=TVIZ.Items.Count;(count <=2) or (TVIZ.Selected.Level <> 2) then.MessageBox('Выберите в дереве (слева) название таблицы в которой FK','Ошибка',MB_OK+MB_ICONERROR);.Caption:='FK может быть создан только после создания всех таблиц (с полями) и PK';

exit;;(tviz);:=TVIZ.Selected.AbsoluteIndex;:=TVIZ.Items.Item[ai].getFirstChild.AbsoluteIndex;.Items.Item[aifc+i].Selected:=true;(TVIZ.Selected.Parent.Text = 'Keys') do:=TVIZ.Selected.Text;(GetStrFK_Keys(Text) = 2) then(tviz);:=TRUE;; inc(i);aifc+i <> countTVIZ.Items.Item[aifc+i].Selected:=truebreak; end;FK then(Sender);:=false; else e.Text := 'Нет внешних ключей!';

if FLAGC then MenuConnect2Click(Sender);.Items.Item[ai].Selected:=true;.SetFocus; end;

1.7    Добавление поля

procedure TFDiplomADOX.BAlterColClick(Sender: TObject);,ai,aifc,i:integer;:boolean;:=1;:=3;:=TVIZ.Items.Count;not Struc then

LMess.Caption:='Поле может быть создано только после сверки структур БД';

exit;;(count <=2) or (TVIZ.Selected.Level <> 2) then

application.MessageBox('Выберите в дереве (слева) название таблицы в которой есть поле для создания','Ошибка',MB_OK+MB_ICONERROR);

exit; end;(tviz);:=TVIZ.Selected.AbsoluteIndex;:=TVIZ.Items.Item[ai].getLastChild.AbsoluteIndex;.Items.Item[aifc+i].Selected:=true;(TVIZ.Selected.Parent.Text = 'Columns') do(tviz);(i);:=TRUE;aifc+i <> countTVIZ.Items.Item[aifc+i].Selected:=truebreak;;Col then(Sender);:=false;

else e.Text := 'Нет дополнительных полей!';

if FLAGC then MenuConnect2Click(Sender);.Items.Item[ai].Selected:=true;.SetFocus; end;

1.8    Создание отчёта SQL

procedure TFDiplomADOX.BCreateRClick(Sender: TObject);M.Lines.Count > 0 then.Lines.SaveToFile('SQLReport.sql');FileExists('SQLReport.sql') then.MRep.Clear;.Caption:='SQLReport.sql';.MRep.Lines.LoadFromFile('SQLReport.sql');.ShowModal;;;