Немаловажной особенностью сервера 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 Проектирование и реализация базы данных
Разрабатываемая база данных предназначена для хранения информации о гигиенических нормативах химических веществ. Информация представляет собой совокупность характеристик, предельных показателей по содержанию и описания веществ в различных средах, а также нормативной документации, справочной литературы и ссылок на них. Подразумевается возможность изменения некоторой информации с течением времени. База данных носит характер справочной информационной системы и должна выдавать однозначные сведения на поставленные запросы. Конечными пользователями базы данных являются инженеры по охране труда и работники всевозможных экологоохранных организаций. Вследствие этого учтена возможная неосведомленность пользователей в вопросах администрирования и поддержания баз данных в актуальном состоянии. Результатом является прозрачность всех алгоритмов доступа, поиска и администрирования. Программный интерфейс полностью лишен DDL составляющей языка для определения и объявления объектов базы данных, а DML составляющая для обработки таких объектов представлена с учётом требований к целостности и непротиворечивости данных. Специфичность структур данных и отсутствие наработок в исследуемой области делает бессмысленным осуществление алгоритмов позволяющих импорт/экспорт и конвертирование данных из других программных продуктов. Однако, существует необходимость осуществить возможность дополнения базы данных обновленной информацией из других экземпляров этой же базы данных. Также были предъявлены следующие требования к проекту:
- предоставление общей информации о веществе. Это название вещества, его химическая формула, номер в международной таблице элементов CAS, а также синонимы названия вещества;
- пополнение списка веществ базы данных;
- удаление веществ из списка базы данных;
- изменение и дополнение информации по конкретному веществу;
- возможность сортировки предоставляемых данных по названию веществ, номерам таблицы CAS или их химическим формулам;
- возможность выборки данных по заданию фиксированных значений характеристик вещества;
- возможность распечатки информации о веществе;
- наличие справочной информации различного рода, нормативных актов и утверждающих документов.
Инфологическая модель данных в терминах трехуровневой архитектуры является некой реализацией концептуального уровня.
Анализ определённых выше задач позволяет выделить следующие объекты проектируемой базы данных и построить следующую её модель на языке « таблицы – связи ».
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-диаграммы
Как видно из схемы, первичные ключи сущностей «Элементы» и «Синонимы» играют важную роль не только в однозначной идентификации записей в данных сущностях, но и выполняют связующую роль в организации связей типа «один-ко-многим» и «многие-к-одному» между таблицами.
Данная инфологическая модель легко отображается в реляционную даталогическую модель, при этом каждая сущность отображается в одноименную таблицу с сохранением зависимостей и первичных ключей. Такой состав таблиц позволяет выполнять все возложенные задачи, поскольку он выведен из инфологической модели, проектируемой исходя из требований конечных пользователей.
В данном случае таблицы базы данных не до конца нормализованы, что обусловлено требованиями простоты доступа к данным и учета «связи с будущим». Это накладывает некоторые требования на процедуры поддержания базы данных в целостном состоянии, но даёт возможность “безболезненных изменений” в программном коде, что может существенно сократить время разработки в дальнейшем. Процедуры по поддержанию целостности реализованы в программном коде прозрачными для конечного пользователя.
База данных организованна в популярном формате клиент-серверных баз данных InterBase. Этот формат для организации реляционных баз данных довольно распространен, поскольку обладает наиболее развитой системой хранимых типов данных и возможностями индексирования полей. Это позволяет получать доступ к данным за минимальное время. Также реализованы функции по обеспечению ссылочной целостности между реляционными таблицами, что позволяет разработчику минимизировать временные затраты на создание базы данных, а конечному пользователю затраты на поддержание целостности хранимых данных и получения из базы данных самих хранимых данных. Поскольку базы данных InterBase - реляционные базы данных, то запросы к данным осуществляются с помощью реляционного языка запросов SQL. Благодаря развитой системе определения ключевых полей и индексов при создании таблиц запросы будут выполняться с минимальными временными затратами. Этот фактор для локальных баз данных не является ключевым, однако, при клиент-серверной архитектуре и предполагаемом росте объема хранимых данных именно скорость выполнения запросов стала решающим фактором при выборе формата баз данных.
Страницы: 1, 2, 3, 4, 5, 6, 7
