П.А. ПОЛЯКОВ ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД ПРИ ПРОЕКТИРОВАНИИ ТЕХНОЛОГИЧЕСКИХ СПРАВОЧНИКОВ

УДК 004.4(06) Технологии разработки программных систем
П.А. ПОЛЯКОВ
Московский инженерно-физический институт (государственный университет)
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД
ПРИ ПРОЕКТИРОВАНИИ ТЕХНОЛОГИЧЕСКИХ
СПРАВОЧНИКОВ
Рассмотрены преимущества объектно-реляционной БД над реляционной БД.
Проанализированы достоинства и недостатки трехзвенной архитектуры.
Представлен один из вариантов реализации технологических справочников с
использованием объектно-реляционной БД.
Имеется задача построения подсистемы, обеспечивающей быстрое и
качественное проектирование технологических справочников, а также
ведение и сопровождение существующих. Целью данного обзора является
представление результатов анализа механизмов объектно-реляционной
БД и одного из вариантов возможной реализации подсистемы
технологических справочников на ее основе.
Классической методикой проектирования баз данных (БД) является
создание отдельной таблицы для каждой описываемой моделью данных
сущности, затем — в процессе нормализации — выделение отдельных
таблиц для хранения атрибутов сущности. Такой подход хорошо работает
для БД с относительно небольшим количеством описываемых объектов и
при несложных и статичных связях между ними. Однако любое
изменение структуры хранимых данных приводит к внесению изменений
в структуру таблиц. В связи с этим встает вопрос: а нельзя ли создать
структуру данных, не требующую модернизации при появлении новых
сущностей и позволяющую хранить произвольную и при этом достаточно
простую и эффективную информацию? Таким вариантом является
объектно-реляционная БД, которая содержит с десяток таблиц для
описания классов и их атрибутов, а также хранения объектов и значений
атрибутов. Такая БД не привязана ни к какой бизнес-модели и позволяет
реализовать «над собой» практически любую бизнес-логику, выделяемую
в отдельный программный слой. В то же время, в силу однообразности
модели хранения, эти объекты довольно легко создаются на основе
базовых классов, инкапсулирующих функциональность по загрузке и
сохранению свойств и связей в БД.
Получая гибкость и объектность, мы также сталкиваемся и с целым
рядом проблем, таких как: ослабленный контроль за целостностью
данных, пониженное быстродействие при выборке данных, сложность в
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 2
27
УДК 004.4(06) Технологии разработки программных систем
понимании структуры и выборке данных, необходимость создания своего
языка запросов для выполнения запросов к объектно-реляционной БД.
Каждая из этих проблем решаема и ни одна проблема не является
камнем преткновения, из-за которого использование объектнореляционной БД является невозможным или неоправданным.
Чаще всего при реализации объектно-ориентированной БД
используется трехзвенная архитектура построения приложения. Новым
звеном, в отличие от двухзвенной архитектуры, здесь является сервер
приложений, на котором реализуется логика работы с данными. Основные
достоинства использования третьего звена – это: сокращение количества
лицензий, используемых для соединения с сервером БД, снижение
трудозатрат при переводе приложения на другой сервер СУБД или
изменения логики работы с данными, снижение требований к
вычислительным ресурсам клиентского ПК. Из недостатков можно
отметить следующее: низкая скорость передачи данных между клиентом
и сервером приложений, трудоемкая реализация сервера приложений.
Данные, полученные в результате проведенного анализа объектноориентированной БД и трехзвенной архитектуры, были учтены при
проектировании подсистемы технологических справочников. Было
решено минимизировать функции сервера приложений и перенести его на
клиентскую сторону. Функции сервера приложений были упрощены, так,
например, формирование SQL запросов для получения объектов уже
выполнял не сервер приложений, а сервер СУБД средствами хранимых
процедур. Сервер приложений только передавал СУБД исходные данные
для выполнения запросов. В ответ СУБД возвращала только список
идентификаторов объектов. Далее значение свойств каждого объекта
запрашивались из СУБД по мере необходимости. Таким образом, перенос
сервера приложений на клиента ликвидирует такие недостатки, как
медленный маршалинг данных по сети и позволяет отказаться от
реализации многопоточного сервера приложений. Также предусмотрен
механизм оповещения клиентов при изменении или удалении данных на
сервере БД. Для этого на стороне сервера БД было предложено
использовать дополнительный COM сервис, который генерирует
соответствующие события. Клиенты, подписавшиеся на эти события,
могут соответствующим образом отреагировать на произошедшие
изменения в объекте.
Список литературы
1.
Анатолий Тенцер. База данных – хранилище объектов, КомпьютерПресс 8’2001
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 2
28
УДК 004.4(06) Технологии разработки программных систем
ISBN 5-7262-0555-3. НАУЧНАЯ СЕССИЯ МИФИ-2005. Том 2
29