Информационная база данных по гигиеническим нормативам химических веществ

Примечаниеот автора: На защите сказали косяки с ЕР диаграммой
Загрузить архив:
Файл: ref-23880.zip (79kb [zip], Скачиваний: 49) скачать

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

Государственное образовательное учреждение

высшего профессионального образования

«КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

Кафедра математического моделирования

                                                                                                                                                             

КУРСОВАЯ РАБОТА

Информационная база данных по гигиеническим нормативам химических веществ

Автор курсовой работы _________________________________ Чубасов М.В.

Группа 33 факультет прикладной математики, спец. 010501 «Прикладная математика и информатика»

Научный руководитель_______________________________ Павлова А.В.

канд. физ.- мат. наук, доцент

Краснодар 2006

Реферат

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

Работа состоит из 44 страниц, содержит 3 рисунка, 10 таблиц, приложение и библиографический список из 10 источников.

Ключевые слова: загрязняющие вещества, нормативы, СУБД, экомониторинг, реляционность, модель данных.

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

Разработка приложения производилась в среде визуального программирования Delphi 7 с использованием InterBase 6.0 в качестве СУБД с локальным сервером. Реализованы функции комплексного редактирования содержания базы и печати необходимой информации.

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


Содержание

TOC o "1-3" p " " h z u Введение . 4

1 Базы данных. Основные понятия. 7

1.1 Общие сведения. 7

1.2 Реляционная модель данных. 11

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

1.4 Основные требования к организации баз данных.............................. 16

1.5 Трехуровневая архитектура................................................................ 18

2 Используемые средства программирования 21

2.1 Среда программирования Delphi21

2.1 СУБД InterBase24

3 Проектирование и реализация базы данных 29

3.1 Предметная область и задачи проекта29

3.2 Инфологическая модель данных. 30

3.3Физическая модель данных33

3.4 Реализация информационной базы данных36

Заключение.................................................................................................... 37

Библиографический список . 39

ПРИЛОЖЕНИЕ АСоздание базы данных в терминах языка SQL.. 40

Введение

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

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

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

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

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

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

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


1Базы данных. Основные понятия

1.1 Общие сведения

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

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

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

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

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

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

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

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

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

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

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

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

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

SHAPE* MERGEFORMAT

Приложение

Невизуальные компоненты для работы с БД

Визуальные компоненты для работы с БД

    База данных

Ядро СУБД

Рисунок 1 – Общая структура работы приложения и СУБД

1.2 Реляционная модель данных

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

В ответ на неправильное использование термина "реляционный" Кодд в 1985 году написал статью, где сформулировал 12 правил (Таблица 1), которым должна удовлетворять любая база данных, претендующая на звание реляционной.

Таблица 1 – Требования к реляционным базам данных

1

Многомерное представление данных

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

2

Прозрачность

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

3

Доступность

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

4

Согласованная производительность

Производительность практически не должна зависеть от количества Измерений в запросе.

5

Поддержка архитектуры клиент-сервер

Средства должны работать в архитектуре клиент-сервер.

6

Равноправность всех измерений

Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными).

7

Динамическая обработка разреженных матриц

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

8

Поддержка многопользовательского режима работы с данными

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

9

Поддержка операций на основе различных измерений

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

10

Простота манипулирования данными

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

11

Развитые средства представления данных

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

12

Неограниченное число измерений и уровней агрегации данных

Не должно быть ограничений на число поддерживаемых Измерений.

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

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

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

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

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

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

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

-      объединения таблиц;

-      пересечения таблиц;

-      взятия разности таблиц;

-      прямого произведения таблиц.

Специальные реляционные операции включают:

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

-      проекцию таблицы;

-      соединение таблиц;

-      деление таблиц.

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

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

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

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

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

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

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

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

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

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

1.4 Основные требования к организации базы данных

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

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

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

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

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

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

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

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

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

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

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

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

1.5 Трехуровневая архитектура

Архитектура ANSI/SPARCвключает в себя три уровня:

-      внутренний, наиболее близкий к физическому хранению информации;

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

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

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

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

Внешний уровень представлен для различных пользователей различными языками общения: для программиста – это какой-либо язык программирования, для конечного пользователя – язык запросов или специализированный язык, основанный на формах и меню. Вне зависимости от типа, каждый из них включает подъязык данных, связанный только с объектами баз данных. В большинстве случаев это SQL. Любой подъязык данных является комбинацией как минимум двух подчиненных языков – языка определения данных (DDL), поддерживающего объявление объектов базы данных, и языка обработки данных (DML), поддерживающего обработку таких объектов.

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

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

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

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


2 Используемые средства программирования

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

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

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

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

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

Все инструментальные средства баз данных Borland - Paradox, DBase, Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или DBase, “наследуются” BDE, и поэтому этими же особенностями обладает и Delphi. Главное окно утилиты настройки BDE имеет вид, изображенный на рисунке 2.

Рисунок 2 – Главное окно утилиты BDEAdministrator

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

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

Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер InterBase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в оффлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины, может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер.

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

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

Источник данных (data source) представляет собой промежуточный элемент, который применяется для связи набора данных с визуальными компонентами. Получается как бы цепочка: «набор данных — источник данных — визуальный компонент». Для этой цели в Delphi служит компонент datasource.

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

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

2.2 СУБД InterBase

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

В пакет Delphi входит однопользовательская версия InterBase для Windows - Local InterBase. Используя Local InterBase можно создавать и отлаживать приложения, работающие с данными по схеме клиент-сервер, без подключения к настоящему серверу. В дальнейшем потребуется только перенастроить используемый псевдоним (алиас) базы данных, и программа будет работать с реальной базой без перекомпиляции. Кроме того, Local InterBase можно использовать в приложениях для работы с данными вместо таблиц Paradox и dBase.

СУБД InterBase отличается чрезвычайно низкими системными требованиями и при этом сравнительно высокой производительностью (Таблица 2), а также легкостью администрирования относительно других программных продуктов. InterBase является кроссплатформенным продуктом, поддерживающим большое количество различных операционных систем, при этом допускается работа с InterBase, используя несколько сетевых протоколов: TCP/IP, NetNEUI, IPX/SPX.

Таблица 2 – Примерное время выборки данных с использованием различных СУБД.

СУБД

Время выполнения SQL-запроса, мс.

Время линейного поиска, мс.

InterBase 6.0

0.2 – 0.7

3.5

Paradox + MS ODBC

~ 5 – 28

~ 104

Access + MS Jet 4.0

0.2 – 1.0

~ 80

DBISAM 2.04

3.0 – 3.5

2.0 – 3.0

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

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

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

Немаловажной особенностью сервера InterBase является возможность расширения стандартного набора SQL-функций при помощи пользовательских библиотек – User Defined Functions, обеспечивающие следующие возможности:

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

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

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

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

База данных реализованная средствами InterBase состоит из различных объектов, таких как таблицы, виды, домены, сохраненные процедуры, триггеры. Объекты базы данных содержат всю информацию о её структуре и данных (метаданные). Информацию о метаданных хранится в специальных таблицах, которые называются системными таблицами (system tables). Системные таблицы имеют специальные столбцы, которые содержат информацию о типе метаданных в этой таблице. Имена всех системных таблиц начинаются с "RDB$". Пример системной таблицы - RDB$RELATIONS, которая содержит информацию о каждой таблице в базе данных.

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

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

Типы данных, хранимые в таблицах InterBase, очень разнообразны. Это и символьные значения, и разнообразные типы числовых значений, числа в двоичном и двоично-десятичном формате, логические типы, специальные форматы для хранения значений даты, времени и денежных сумм, графические типы для хранения графических изображений в самых популярных форматах, а также строковые значения неограниченной длины (в том числе и форматированные в формате rtf) и даже типы поддерживаемые технологией OLE (Object Linking and Embedding) фирмыMicrоsoft. Такое разнообразие типов данных отвечает самым изысканным задачам, которым призвана служить создаваемая современная реляционная база данных и без сомнения подходит для решения круга задач возложенного на базу данных гигиенических нормативов.


3 Проектирование и реализация базы данных

3.1 Предметная область и задачи проекта

Разрабатываемая база данных предназначена для хранения информации о гигиенических нормативах химических веществ. Информация представляет собой совокупность характеристик, предельных показателей по содержанию и описания веществ в различных средах, а также нормативной документации, справочной литературы и ссылок на них. Подразумевается возможность изменения некоторой информации с течением времени. База данных носит характер справочной информационной системы и должна выдавать однозначные сведения на поставленные запросы. Конечными пользователями базы данных являются инженеры по охране труда и работники всевозможных экологоохранных организаций. Вследствие этого учтена возможная неосведомленность пользователей в вопросах администрирования и поддержания баз данных в актуальном состоянии. Результатом является прозрачность всех алгоритмов доступа, поиска и администрирования. Программный интерфейс полностью лишен DDLсоставляющей языка для определения и объявления объектов базы данных, а DMLсоставляющая для обработки таких объектов представлена с учётом требований к целостности и непротиворечивости данных. Специфичность структур данных и отсутствие наработок в исследуемой области делает бессмысленным осуществление алгоритмов позволяющих импорт/экспорт и конвертирование данных из других программных продуктов. Однако, существует необходимость осуществить возможность дополнения базы данных обновленной информацией из других экземпляров этой же базы данных. Также были предъявлены следующие требования к проекту:

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

- пополнение списка веществ базы данных;

- удаление веществ из списка базы данных;

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

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

- возможность выборки данных по заданию фиксированных значений характеристик вещества;

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

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

3.2 Инфологическая модель данных

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

Анализ определённых выше задач позволяет выделить следующие объекты проектируемой базы данных и построить следующую её модель на языке « таблицы – связи ».

1. Элементы (Номер1, Название, №CAS, Формула)

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

2. Синонимы (Номер2, Номер1, Синоним)

Эта сущность предназначена для обеспечения возможности навигации по базе данных при помощи синонимов названий веществ. В силу того, что название вещества может иметь несколько синонимов, первичный ключ этой сущности состоит из двух атрибутов: « Номер2 » - это уникальный в рамках данной сущности числовой идентификатор, присваиваемый каждой создаваемой записи; и « Номер1 » - это атрибут, определенный в сущности « Элементы » и показывающий какой записи в этой сущности соответствует создаваемый синоним. Таким образом, однозначная идентификация осуществляется путем указания порядкового номера синонима в сущности и номера вещества названию которого он соответствует. В программном интерфейсе реализована система поиска по синонимам.

3. ВоздухРЗ (Номер1, Данные, ПДК, ОБУВ, Состояние, Класс, Действие, Примечания)

4. ВоздухНМ (Номер1, Данные, ПДКмакс, ПДКсред, Лимит, Класс, ОБУВ, Примечания)

5. Вода (Номер1, Данные, ПДК, Лимит, Класс, ОДУ, Примечания)

6. Почва (Номер1, Данные, ПДКфон, ОДК, Лимит, Метод, Примечания)

7. Рыбхоз (Номер1, Данные, ПДК, ОБУВ, Документ, Дополнения, Лимит, Класс, Метод, Примечания)

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

8. Справка (Номер3, Раздел, Ссылка)

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

На рисунке 3 приведена ERдиаграмма инфологической модели базы:

Рисунок 3 – Инфологическая модель данных в виде ER-диаграммы

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

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

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

3.3 Физическая модель данных

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

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

В таблице 3 («Elements») представлена информация о веществе общего характера.

Таблица 3 – Elements

Имя поля

Тип поля

Назначение

Num1

Integer                

Порядковый номер записи вещества (ключ)

#CAS

Char[10]

Номер вещества согласно таблицы CAS

Formula

VarChar[30]

Формула вещества

Name

VarChar[200]

Название вещества

В таблице 4 («Synonyms») представлена информация о синонимах названия вещества

Таблица 4 – Synonyms

Имя поля

Тип поля

Назначение

Num2

Integer

Порядковый номер записи синонима (ключ)

Num1

Integer

Порядковый номер записи вещества (внешний ключ)

Synonym

VarChar[200]

Название вещества

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

Таблица 5 – Workzone

Имя поля

Тип поля

Назначение

Num1

Integer

Порядковый номер записи вещества (ключ)

Data

SmallInt

Признак наличия данных

Class

Integer

Класс опасности

PDK

Decimal(4,3)

Предельно допустимая концентрация

OBUV

Decimal(4,3)

Ориентировочный безопасный уровень воздействия

Condition

VarChar[30]

Преимущественно агрессивное состояние

Influence

VarChar[500]

Особенности действия на организм

Additions

VarChar[500]

Примечания

В таблице 6 («Livezone») представлена детальная информация о гигиенических нормативах содержания вещества в воздухе населенных мест.

Таблица 6 – Livezone

Имя поля

Тип поля

Назначение

Num1

Integer

Порядковый номер записи вещества (ключ)

Data

SmallInt

Признак наличия данных

Class

Integer

Класс опасности

PDKm

Decimal(4,3)

Максимальная предельно допустимая концентрация

PDKd

Decimal(4,3)

Среднесуточная предельно допустимая концентрация

OBUV

Decimal(4,3)

Ориентировочный безопасный уровень воздействия

Limit

VarChar[30]

Лимитирующий показатель вредности

Additions

VarChar[500]

Примечания

В таблице 7 («Water») представлена детальная информация о гигиенических нормативах содержания вещества в воде водных объектов хозяйственно-питьевого и культурно-бытового водопользования.

Таблица 7 –Water

Имя поля

Тип поля

Назначение

Num1

Integer

Порядковый номер записи вещества (ключ)

Data

SmallInt

Признак наличия данных

Class

Integer

Класс опасности

PDK

Decimal(4,3)

Предельно допустимая концентрация

ODU

Decimal(4,3)

Ориентировочный допустимый уровень

Limit

VarChar[30]

Лимитирующий показатель вредности

Additions

VarChar[500]

Примечания

В таблице 8 («Ground») представлена детальная информация о гигиенических нормативах содержания вещества в воздухе населенных мест.

Таблица 8– Ground

Имя поля

Тип поля

Назначение

Num1

Integer

Порядковый номер записи вещества (ключ)

Data

SmallInt

Признак наличия данных

PDKf

Decimal(4,3)

Предельно допустимая концентрация с учетом ФОН

ODK

Decimal(4,3)

Ориентировочная допустимая концентрация

Limit

VarChar[30]

Лимитирующий показатель вредности

Method

VarChar[500]

Ссылка на литературу по методам определения

Additions

VarChar[500]

Примечания

В таблице 9 («Fishing») представлена детальная информация о гигиенических нормативах содержания вещества в воде водных объектов хозяйственно-питьевого и культурно-бытового водопользования.

Таблица 9 – Fishing

Имя поля

Тип поля

Назначение

Num1

Integer

Порядковый номер записи вещества (ключ)

Data

SmallInt

Признак наличия данных

Class

Integer

Класс опасности

PDK

Decimal(4,3)

Предельно допустимая концентрация

OBUV

Decimal(4,3)

Ориентировочный безопасный уровень воздействия

Limit

VarChar[30]

Лимитирующий показатель вредности

Doc

VarChar[500]

Документ утверждения

Updates

VarChar[500]

Дополнения к документу

Method

VarChar[500]

Ссылка на литературу по методам определения

Additions

VarChar[500]

Примечания

В таблице 10 («Help») представлены ссылки на справочную информацию по соответствующему разделу.

Таблица 10 – Help

Имя поля

Тип поля

Назначение

Num3

Integer                

Порядковый номер записи синонима (ключ)

Topic

Char[10]            

Раздел справки (соответствует таблицам)

Link

BLOB

Ссылка на файл, содержащий информацию

3.4 Реализация информационной базы данных

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

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

Заключение

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

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

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

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

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

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


Библиографический список

1. Дейт К. Дж. «Введение в системы баз данных». : Пер. с англ. – 6-е изд. – К.: Диалектика, 1998. – 784 с.

2. Фленов М. Е. «Библия Delphi». – СПб.: БХВ-Петербург, 2004. – 880 с.

3. Макарова А. С. диссертация «Разработка метода оценки и управления рисками, возникающими при обращении с веществами и материалами». – М.: РХТУ им. Д. И. Менделеева, 2001. – 144 с.

4. ГОСТ 12.01.007-76. ССБТ. Вредные вещества. Классификация и общие требования безопасности.

5. Codd S.B. Codd C.T. «Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate». – CA.: E.F.Codd & Associates, 1993. – 851 p.

6. Дюбуа П. «MySQL». – М.: Издательский дом Вильямс, 2004. – 1056 с.

7. Borland Delphi 7 Help: Developing Database Applications, IBExpert Reference

8. InterBase Documentation: Data Definition Guide, Developer’s Guide

9. Официальный сайт Минздрава России

10. Законодательные документы в области экологии


ПРИЛОЖЕНИЕ А

Создание базы данных в терминах языка SQL

CREATE DATABASE 'E:NORM.GDB'

USER 'MAX' PASSWORD '129'

PAGE_SIZE = 8192

DEFAULT CHARACTER SET WIN1251;

CREATE DOMAIN TBOOLEAN AS

SMALLINT

NOT NULL

CHECK (VALUE=0 OR VALUE=1);

CREATE DOMAIN TDIGIT AS

SMALLINT

CHECK (VALUE>0 AND VALUE<5);

CREATE DOMAIN TINTEGER AS

INTEGER

NOT NULL

CHECK (VALUE>0);

CREATE DOMAIN TREAL AS

DECIMAL(8,4)

CHECK (VALUE>0);

CREATE DOMAIN TSTRING10 AS

CHAR(10) CHARACTER SET WIN1251

COLLATE WIN1251;

CREATE DOMAIN TSTRING200 AS

VARCHAR(200) CHARACTER SET WIN1251

NOT NULL

COLLATE PXW_CYRL;

CREATE DOMAIN TSTRING30 AS

VARCHAR(30) CHARACTER SET WIN1251

COLLATE WIN1251;

CREATE DOMAIN TSTRING500 AS

VARCHAR(500);

CREATE GENERATOR COUNTER1;

SET GENERATOR COUNTER1 TO 1;

CREATE GENERATOR COUNTER2;

SET GENERATOR COUNTER2 TO 1;

CREATE GENERATOR COUNTER3;

SET GENERATOR COUNTER3 TO 1;

SET TERM ^ ;

CREATE PROCEDURE COUNTER1VALUE

RETURNS (

    NUM INTEGER)

AS

begin

NUM = GEN_ID(COUNTER1, 1);

suspend;

end

^

SET TERM ; ^

DESCRIBE PROCEDURE COUNTER1VALUE '';

SET TERM ^ ;

CREATE PROCEDURE COUNTER2VALUE

RETURNS (

    NUM INTEGER)

AS

begin

NUM = GEN_ID(COUNTER2, 1);

suspend;

end

^

SET TERM ; ^

DESCRIBE PROCEDURE COUNTER2VALUE '';

SET TERM ^ ;

CREATE PROCEDURE COUNTER3VALUE

RETURNS (

    NUM INTEGER)

AS

begin

NUM=GEN_ID(COUNTER3, 1);

suspend;

end

^

SET TERM ; ^

DESCRIBE PROCEDURE COUNTER3VALUE '';

CREATE TABLE ELEMENTS (

    NUM1 TINTEGER NOT NULL,

    NAME TSTRING200 NOT NULL,

    CAS TSTRING10,

    FORMULA TSTRING30);

alter table ELEMENTS

add constraint PK_ELEMENTS

primary key (NUM1);

CREATE TABLE SYNONYMS (

    NUM2 TINTEGER NOT NULL,

    NUM1 TINTEGER NOT NULL,

    SYNONYM TINTEGER);

alter table SYNONYMS

add constraint PK_SYNONYMS

primary key (NUM2,NUM1);

alter table SYNONYMS

add constraint FK_SYNONYMS_1

foreign key (NUM1)

references ELEMENTS(NUM1)

on update CASCADE;

CREATE TABLE WORKZONE (

    NUM1 TINTEGER NOT NULL,

    DATA TBOOLEAN NOT NULL,

    CLASS TDIGIT,

    PDK TREAL,

    OBUV TREAL,

    CONDITION TSTRING30,

    INFLUENCE TSTRING500,

    ADDITIONS TSTRING500);

alter table WORKZONE

add constraint PK_WORKZONE

primary key (NUM1);

alter table WORKZONE

add constraint FK_WORKZONE_1

foreign key (NUM1)

references ELEMENTS(NUM1);

CREATE TABLE LIVEZONE (

    NUM1 TINTEGER NOT NULL,

    DATA TBOOLEAN NOT NULL,

    CLASS TDIGIT,

    PDKM TREAL,

    PDKD TREAL,

    OBUV TREAL,

    LIMIT TSTRING30,

    ADDITIONS TSTRING500);

alter table LIVEZONE

add constraint PK_LIVEZONE

primary key (NUM1);

alter table LIVEZONE

add constraint FK_LIVEZONE_1

foreign key (NUM1)

references ELEMENTS(NUM1);

CREATE TABLE WATER (

    NUM1 TINTEGER NOT NULL,

    DATA TBOOLEAN NOT NULL,

    CLASS TDIGIT,

    PDK TREAL,

    ODU TREAL,

    LIMIT TSTRING30,

    ADDITIONS TSTRING500);

alter table WATER

add constraint PK_WATER

primary key (NUM1);

alter table WATER

add constraint FK_WATER_1

foreign key (NUM1)

references ELEMENTS(NUM1);

CREATE TABLE GROUND (

    NUM1 TINTEGER NOT NULL,

    DATA TBOOLEAN NOT NULL,

    PDKF TREAL,

    ODK TREAL,

    LIMIT TSTRING30,

    METHOD TSTRING500,

    ADDITIONS TSTRING500);

alter table GROUND

add constraint PK_GROUND

primary key (NUM1);

alter table GROUND

add constraint FK_GROUND_1

foreign key (NUM1)

references ELEMENTS(NUM1);

CREATE TABLE FISHING (

    NUM1 TINTEGER NOT NULL,

    DATA TBOOLEAN NOT NULL,

    CLASS TDIGIT,

    PDK TREAL,

    OBUV TREAL,

    LIMIT TSTRING30,

    DOC TSTRING500,

    UPDATES TSTRING500,

    METHOD TSTRING500,

    ADDITIONS TSTRING500);

alter table FISHING

add constraint PK_FISHING

primary key (NUM1);

alter table FISHING

add constraint FK_FISHING_1

foreign key (NUM1)

references ELEMENTS(NUM1);

CREATE TABLE HELPS (

    NUM3 TINTEGER NOT NULL,

    TOPIC TSTRING10,

    LINK BLOB SUB_TYPE 0 SEGMENT SIZE 80 NOT NULL);

alter table HELPS

add constraint PK_HELPS

primary key (NUM3);