П.А. ПОЛЯКОВ Научный руководитель – В.Г. ЕЛИСЕЕВ, к.т.н., доцент ПРОЕКТИРОВАНИЕ ПОДСИСТЕМЫ СПРАВОЧНИКОВ

УДК 001(06) Инновационные проекты, студенческие идеи, проекты, предложения.
П.А. ПОЛЯКОВ
Научный руководитель – В.Г. ЕЛИСЕЕВ, к.т.н., доцент
Московский инженерно-физический институт (государственный университет)
ПРОЕКТИРОВАНИЕ ПОДСИСТЕМЫ СПРАВОЧНИКОВ
НА БАЗЕ ОБЪЕКТНО-РЕЛЯЦИОННОЙ БД
Рассмотрены преимущества объектно-реляционной БД над реляционной БД.
Проанализированы достоинства и недостатки трехзвенной архитектуры.
Представлен один из вариантов реализации технологических справочников с
использованием объектно-реляционной БД.
Была поставлена задача: спроектировать подсистему справочников,
которая позволит пользователям создавать справочники произвольной
структуры и связывать их с уже существующими. Одними из основных
требований к данной подсистеме были:
1. Поддержка проектируемой подсистемой трех видов SQL сервера:
Firebird, Oracle и MSSQL
2. Создание справочника в проектируемой подсистеме, не должно
сопрягаться со знанием основ баз данных или каких-либо средств СУБД,
пользователем.
3. Подсистема должна обеспечивать три режима работы: пользователя,
оператора и администратора. Пользователям данные справочников
доступны только для чтения. Для оператора данные справочников
доступны на чтение и запись. Администратор может создавать и
связывать справочники между собой.
Выполнение первого и второго требования при использовании
классической методики, когда для каждой описываемой сущности
необходимо создать свою таблицу, является невозможной, так как это
потребует больших трудозатрат на реализацию интерфейсного модуля
позволяющего пользователю, быстро и удобно создавать таблицы и
связывать их между собой. При этом данный модуль должен работать со
всеми перечисленными видами SQL серверов. В связи с этим встает
вопрос: а нельзя ли создать структуру данных, не требующую создания
таблиц для каждой описываемой сущности. Один из вариантов такой
структуры данных это объектно-реляционная база данных. Только с
помощью нее можно описать любую сущность и при этом иметь строго
фиксированный набор таблиц. Для того чтобы выяснить подходит данный
вариант или нет, необходимо провести его обзор и анализ.
100
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 11
УДК 001(06) Инновационные проекты, студенческие идеи, проекты, предложения.
Основные принципы, на которых строится объектно-реляционная БД,
это:
1. Каждая сущность, информация о которой хранится в БД, — это объект
2. Каждый объект уникален в пределах БД и имеет уникальный
идентификатор
3. Объект имеет свойства (строковые, числовые, временные,
перечислимые), которые описывают атрибуты сущности
4. Объекты могут быть связаны между собой произвольным образом.
Связь характеризуется связанными объектами и типом связи.
Например, сотрудник фирмы может быть связан с отделом, в котором
он работает, связью типа «сотрудник в отделе» и т.п. Связь в
определенном смысле аналогична понятию ссылки на таблицусправочник в традиционной модели БД
5. Объект может быть хранилищем. В этом случае допускается хранение
в нем других объектов (например, товара на складе).
Такая БД не привязана ни к какой бизнес-модели и позволяет
реализовать «над собой» практически любую бизнес-логику. Логика
выделяется в отдельный программный слой и, как правило, реализуется
на сервере приложений, где по запросу клиента создаются объекты,
загружающие информацию о себе из БД и реализующие «поведение»
объектов реального мира. В то же время, в силу однообразности модели
хранения, эти объекты довольно легко создаются на основе базовых
классов, инкапсулирующих функциональность по загрузке и сохранению
свойств и связей в БД.
Использование объектно-реляционной БД обеспечит чрезвычайную
гибкость и настраиваемость подсистемы справочников. Но при этом
использование объектно-реляционной БД придется столкнуться с такими
проблемами как:
1) Ослабленный контроль за целостностью данных. Разбив данные об
одном объекте по нескольким таблицам, мы теряем возможность на
декларативном уровне контролировать правильность ввода данных.
Так, нельзя указать серверу не позволять вводить объект при
незаполненном атрибуте либо при неуказанной связи с другим
объектом. Таким образом, на разработчика и администратора ложится
дополнительная работа по программированию проверки ограничений
и по недопущению прямой работы пользователей с БД.
2) Пониженное быстродействие при выборке данных. Хранение
атрибутов в различных таблицах требует аккуратности при
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 11
101
УДК 001(06) Инновационные проекты, студенческие идеи, проекты, предложения.
программировании выборки множества объектов. Так, чтобы получить
одновременно несколько атрибутов, придется написать запрос вида:
SELECT O.Id, S1.Value AS Family, S2.Value AS FirstName,
S3.Value AS LastName, H.ItemDate AS BirthDate
FROM Objects O
INNER JOIN ObjType OT ON OT.Id = O.TypeId
LEFT JOIN Strings S1 ON O.Id = S1.ObjectId
LEFT JOIN StrDesc SD1 ON S1.TypeId = SD1.Id
LEFT JOIN Strings S2 ON O.Id = S2.ObjectId
LEFT JOIN StrDesc SD2 ON S2.TypeId = SD2.Id
LEFT JOIN Strings S3 ON O.Id = S3.ObjectId
LEFT JOIN StrDesc SD3 ON S3.TypeId = SD3.Id
LEFT JOIN History H ON O.Id = H.ObjectId
LEFT JOIN Status S ON H.TypeId = S.Id
WHERE OT.Code = ‘PEOPLE’
AND SD1.Code = ‘FAMILY’
AND SD2.Code = ‘FIRSTNAME’
AND SD3.Code = ‘LASTNAME’
AND S.Code = ‘BIRTHDATE’
Кроме неудобства в написании такой запрос может привести еще и к
медленному выполнению на сервере.
3) Сложность в понимании структуры и выборке данных. Структура БД,
не ориентированная на бизнес-логику, часто бывает затруднительной
для понимания. Часто, даже достаточно квалифицированным
разработчикам требуется некоторое время, чтобы понять принципы
хранения объектов и связи между ними. Еще хуже обстоит дело с
конечными пользователями, которым бывает не нужен нестандартный
доступ к хранящейся в БД информации для ее анализа.
4) Создание своего языка запросов для выполнения запросов к объектнореляционной БД.
Кроме того, использование объектно-реляционной БД потребует
реализации трехзвенной архитектуры приложения, которая также имеет
свои достоинства и недостатки.
102
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 11
УДК 001(06) Инновационные проекты, студенческие идеи, проекты, предложения.
Основные достоинства трехзвенной архитектуры:
1) Снижение стоимости подсистемы. Одним из важных факторов при
продаже проектируемой подсистемы является его стоимость. Одна из
составляющих этой стоимости - это стоимость лицензий приобретаемых
для подключения клиентов к серверу БД. При использовании двухзвенной
архитектуры количество клиентских лицензий требовалось бы ровно
столько, сколько планировалось подключить клиентов к серверу БД. При
использовании трехзвенной архитектуры, количество лицензий
сокращается в несколько раз.
2) Снижение трудозатрат при переводе подсистемы на новый сервер
СУБД или изменения логики работы с данными. В двухзвенной
архитектуре логика работы с данными может реализовываться как на
стороне сервера, так и на стороне клиента. В случае перевода приложения
на другой сервер СУБД или изменения логики работы с данными,
потребуется модернизация не только клиентской части, но и серверной. В
случае трехзвенной архитектуры вся бизнес-логика концентрируется в
среднем звене, а именно на сервере-приложений, соответственно и
управлять этой логикой становится намного проще.
3) Клиент всегда остается "тонким", т.е. в клиенте реализуется только
отображение данных полученных от сервера-приложений. Как следствие
требование к вычислительным ресурсам ПК снижаются.
Недостатки трехзвенной архитектуры:
1) Низкая скорость маршалинга данных. Для передачи объектов от
сервера приложений к клиенту потребуется использовать технологию
DCOM, которая отличается довольно низкой скоростью маршалинга
данных. Для частичного устранения данного недостатка чаще всего на
стороне клиента реализуется так называемая отложенная загрузка, т.е.
загрузка данных объекта по мере необходимости.
2) Реализация с нуля на сервере приложений механизмов кэширования,
приоритетов, обработки запросов пользователя и т. д.. Т. е. то, чем раньше
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 11
103
УДК 001(06) Инновационные проекты, студенческие идеи, проекты, предложения.
занимался сервер СУБД в той или иной степени потребуется переписать
для сервера приложений.
3) При разработке кода для сервера приложений необходимо обеспечить
его многопоточность.
Использование трехзвенной архитектуры для объектно-реляционной
БД есть необходимость. Только сервер приложений сможет решить такие
проблемы объектно-ориентированной БД как:
 контроль целостности данных,
 формирование SQL запросов к ОРБД,
 подготовка объектных данных для отображения в клиенте.
Данные, полученные в результате проведенного анализа объектноориентированной БД и трехзвенной архитектуры, были учтены при
проектировании подсистемы технологических справочников. Для
устранения таких недостатков как:
 низкая скорость маршалинга данных,
 пониженное быстродействие при выборке данных из объектной БД,
 необходимость реализации многопоточного сервера приложений,
 реализация с нуля на сервере приложений механизмов кэширования,
приоритетов, обработки запросов пользователя и т. д.,
было предложено перенести сервер приложений на клиентскую сторону
как отдельный подключаемый модуль. Таким образом, отпадает
необходимость реализации многопоточного сервера приложений,
реализации механизмов кэширования и использования технологии
DCOM. На реализацию такого сервера приложений будет потрачено
гораздо меньше времени и при этом сохранены все достоинства объектнореляционной БД и трехзвенной архитектуры.
104
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 11
УДК 001(06) Инновационные проекты, студенческие идеи, проекты, предложения.
Для ускорения выборки и загрузки данных с сервера БД было
предложено реализовать механизм отложенной загрузки, который
позволил бы загружать на сервер приложений только те данные, которые
необходимо отобразить на клиенте. Суть такого механизма заключается в
следующем: сервер приложений никогда не будет загружать объект
полностью. При получении каких-либо результатов выборки, сервер
приложений получит не набор данных в виде таблицы, где каждая запись
содержит значения свойств объекта, а только список их идентификаторов.
Значения свойств объекта будут загружаться только по мере обращения к
ним. Данный механизм позволит отказаться от выполнения сложных SQL
запросов.
Также предусмотрен механизм оповещения клиентов в случае
изменения или удаления данных в серверной БД. Для его реализации
было предложено реализовать на стороне сервера СУБД дополнительный
COM сервис, который генерирует соответствующее событие. Клиенты,
подписанные на эти события, начинают получать их. В результате клиент
может либо разрешить, либо запретить выполняемое действие над
объектом и в случае необходимости перечитать его свойство(а).
1.
2.
Список литературы
Анатолий Тенцер, База данных – хранилище объектов, КомпьютерПресс 8’2001
Елманова Н., Трепалина С., Тенцер А., DELPHI 6 и технология COM, Санкт-Петербург
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 11
105