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 – Главное окно утилиты BDE Administrator
Библиотека объектов содержит набор визуальных компонент, значительно
упрощающих разработку приложений для СУБД со всевозможной архитектурой. Объекты
инкапсулируют в себя нижний уровень - 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 также имеется
достаточно удобная утилита для доступа и администрирования баз данных – Interactive SQL, позволяющая одинаково эффективно использовать достоинства данной СУБД
как при работе с локальными базами, так и с базами, располагающимися на
удаленных серверах.
Немаловажной
особенностью сервера 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. Официальный сайт Минздрава
России http://www.ecolportal.ru
ПРИЛОЖЕНИЕ А
Создание базы данных в
терминах языка 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);