CC BY
32
и должны быть центральными в архитектуре тех Web-приложений, которые вы создаете в Zope.
2.12. Поиск и каталогизация контента
Zcatalog - это встроенный в Zope инструмент поиска. Он позволяет распределять по категориям и искать в Zope объекты всех типов. Можно также использовать его, чтобы находить внешние данные, типа реляционных данных, файлов, и удаленных Web-страниц. В дополнение к поиску можно использовать ZCatalog, для того чтобы организовать коллекции объектов.
Цель лекции. Показать, как осуществлять индексацию и поиск объектов при помощи встроенного поискового средства Zope - объекта каталога ZCatalog. Ввести понятие индексации и обсудить различные примеры внесения в указатель и поиска. Наконец, рассмотреть результаты поиска и метаданные.
2.12. Присоединение реляционной базы данных
При использовании реляционных данных в Zope вы сохраняете все преимущества Zope, включая безопасность, динамическую презентацию и сетевую организацию. Вы можете использовать Zope, чтобы динамически построить доступ к данным, презентацию данных и управление данными.
Цель лекции. Описать, как Zope связывается с внешними реляционными базами данных. Объяснить подход, позволяющий интерпретировать реляционные данные в качестве объектов Zope. Применить методы запросов Z SQL в сочетании с DTML. Затронуть вопросы безопасности и производительности.
Литература
1. Спикльмайр С. и др. Zope. Разработка Web-приложений и управление контентом: Пер. с англ. - М.: ДМК Пресс, 2003. - 464 с.
2. Zope Community. [Электронный ресурс] http://www.zope.org/
3. Amos Latteier, Michel Pelletier, Chris McDonough, ... The Zope2 Book. - Zope Developers Community, 2009. [Электронный ресурс]
3. http://docs.zope.org/zope2/zope2book/
4. Harish Kamath. ZPT Basics. - Melonfire, 2002 [Электронный ресурс]
http://www.devshed.com/c/a/Zope/
5. Harish Kamath. DTML Basics. - Melonfire, 2002. [Электронный ресурс]
www.devshed.com/c/a/Zope/DTML-Basics-part-1/
УДК 004.78
УНИФИЦИРОВАННАЯ МОДЕЛЬ ДЛЯ ТЕСТИРОВАНИЯ ИНСТРУМЕНТОВ ОБЪЕКТНОРЕЛЯЦИОННОГО ОТОБРАЖЕНИЯ
Олейник Павел Петрович, к.т.н., Системный архитектор программного обеспечения, ОАО «Астон»,
Россия, Ростов-на-Дону, [email protected]
Шаблоны проектирования - это многократно используемые решения широко распространённых проблем, возникающих при разработке программного обеспечения. По мере приобретения опыта программисты осознают сходство новых проблем с решаемыми ранее. С накоплением ещё большего опыта приходит осознание того, что решение похожих проблем представляет собой повторяющиеся шаблоны. Зная эти шаблоны, опытные программисты распознают ситуацию их применения и сразу используют готовое решение, не тратя время на предварительный анализ проблемы [1-2].
В настоящее время применение шаблонов (паттернов) проектирования непосредственно связано с их реализацией в объектно-ориентированном языке программирования при помощи объявления иерархии классов и описания ассоциаций. Стоит отметить, что часть паттернов посвящены принципам реализации объектной системы на основе реляционной системы и носит название методов (шаблонов) объектно-реляционного отображения (ОРО) [3]. Т.к. в классической реляционной модели отсутствует
66
понятие наследования (например, наследование отношений), то реализация этой ключевой концепции объектно-ориентированного языка программирования в виде таблиц базы данных является основным назначением группы методов ОРО, позволяющих представить иерархию классов. В настоящее время существует большое количество программных продуктов, позволяющих прозрачно реализовать объектную систему на основе реляционной базы данных, которые получили название инструментов объектно-реляционного отображения [4-5]. Каждая система имеет собственные принципы преобразования классов в набор отношений и большое количество дополнительных сервисов. Несмотря на большую популярность описанных продуктов, отсутствуют единые правила, по которым можно было бы единообразно сравнить, протестировать их функционал и определить те шаблоны отображения, которые реализованы в них. В данной статье представлена единая объектная модель гипотетического приложения, которая может быть использована для тестирования инструментов ОРО.
Рассмотрим основные методы объектно-реляционного отображения, используемые для представления иерархии классов в виде таблиц реляционной базы данных (рис. 1) [3-4]. Метод Наследование с одной таблицей (Single Table Inheritance) физически представляет иерархию наследования классов в виде одной таблицы реляционной базы данных, столбцы которой соответствуют атрибутам всех классов, входящих в иерархию. Описываемый способ позволяет отобразить структуру наследования и минимизировать (а иногда обойтись и вовсе без соединений) количество соединений (естественных внутренних или открытых), которые необходимо выполнить для извлечения информации. В данном методе каждому экземпляру класса соответствует одна строка таблицы. При создании объекта значения заносятся только в те столбцы таблицы, которые соответствуют атрибутам класса, а все остальные остаются пустыми (имеют nun-значения, null-маркеры).
Выполняя загрузку объекта из таблицы в память, необходимо знать имя класса, представляемого в языке программирования. Для этого к таблице добавляется специальное поле. Это может быть имя класса или какое-нибудь идентификационное поле. Перед загрузкой данных необходимо считать код типа класса, чтобы узнать, экземпляр какого производного класса должен быть создан для загрузки объекта. При сохранении объекта в базе данных запись кода типа класса выполняется суперклассом.
Описанный метод Наследование с одной таблицей является одним из вариантов отображения иерархии наследования классов на таблицы реляционной базы данных и имеет следующие ключевые достоинства:
• В структуре БД присутствует лишь одна таблица, представляющая все классы иерархии.
• Для извлечения экземпляров классов иерархии не нужно выполнять соединение таблиц.
• Перемещение полей из базового класса в производный (так же из производного в базовый) не требует внесения изменений в структуру таблицы.
Несмотря на наличие множества достоинств, описанному методу присущи серьёзные недостатки:
• При изучении структуры таблиц БД могут возникнуть проблемы, ведь не все имеющиеся столбцы таблицы предназначены для описания каждого класса предметной области. Это усложняет процесс доработки системы в будущем.
• При наличии глубокой иерархии наследования с большим количеством атрибутов многие столбцы могут иметь пустые значения (nun-маркеры). Это приводит к неэффективному использованию свободного пространства в БД. Однако современные СУБД способны сжимать строки, содержащие большое количество отсутствующих значений.
• Итоговая таблица может оказаться слишком большой и содержать огромное число столбцов. Основной способ оптимизировать запрос (сократить время выполнения) - создать покрывающий индекс. Однако множество индексов и большое количество запросов к одной таблице способно привести к частым блокировкам, что будет оказывать негативное влияние на производительность программного приложения.
Альтернативным решением для описанного является метод Наследование с таблицами для каждого класса (Class Table Inheritance), представляющий иерархию наследования классов,
67
использующий по одной таблице для любого класса. Атрибуты класса отображаются непосредственно на столбцы соответствующей таблицы. При использовании данного метода ключевой является задача соединения соответствующих строк нескольких таблиц БД, представляющих единый объект предметной области. Частым решением выступает применение единого значения первичного ключа во всех таблицах. Поскольку таблица суперкласса содержит по одной строке на каждую строку каждой таблицы производных классов, первичные ключи записей должны быть уникальными в пределах всех таблиц производных классов.
Еще одна важная проблема метода - извлечение данных из множества связанных таблиц. Выполнение по одному запросу к каждой отдельной таблице не является эффективным, поэтому чаще всего выполняется естественное соединение нескольких таблиц по равенству значений первичного ключа. При этом заранее неизвестно, к каким именно таблицам следует применить соединение. Некоторые таблицы будут содержать пустые значения, поэтому для выполнения эффективных соединений с такими таблицами применяется внешнее соединение (правое или левое), которое достаточно медленное.
Метод Наследование с таблицами для каждого конкретного класса
Рис. 1 - Методы объектно-реляционного отображения, используемые для представления иерархии классов в
виде таблиц реляционной базы данных
Наследование с таблицами для каждого класса имеет ряд преимуществ:
• В каждой таблице присутствуют лишь поля, соответствующие атрибутам определённого класса. Поэтому таблицы легки в понимании и занимают мало места на жёстком диске.
• Взаимосвязь между объектной моделью и схемой базы данных проста и понятна.
• Однако описанному методу присущи следующие недостатки:
• При создании экземпляра определённого класса предполагается загрузка данных из нескольких таблиц, что требует их соединения либо множества обращений к базе данных с последующим соединением результатов в оперативной памяти.
• Перемещение полей в производный класс или суперкласс требует изменения структуры нескольких таблиц.
68
• Таблицы суперклассов могут стать слабым местом в вопросах производительности, поскольку доступ к таким таблицам будет осуществляться слишком часто, что приведёт к множеству блокировок.
• Высокая степень нормализации может стать препятствием к выполнению незапланированных заранее запросов.
Метод Наследование с таблицами для каждого конкретного класса (Concrete Table Inheritance) представляет иерархию наследования классов, используя по одной таблице для каждого реализованного (неабстрактного) класса этой иерархии. С практической точки зрения данный метод предполагает, что каждый экземпляр класса (объект), который находится в оперативной памяти, будет отображён на отдельную строку таблицы. При этом каждая таблица содержит столбцы, соответствующие атрибутом как конкретного класса, так всех его предков. Т.е. атрибуты суперкласса дублируются во всех таблицах, представляющих его производные классы.
Преимуществами данного метода является то, что:
• Каждая таблица не содержит лишних полей, вследствие чего ее удобно использовать в других приложениях, в которых не использован инструмент объектно-реляционного отображения.
• При создании объектов определённого класса в памяти приложения и извлечения данных из реляционной базы данных выборка выполнятся из одной таблицы, т.е. не требуется выполнять реляционные соединения.
• Доступ к таблице осуществляется только в случае доступа к конкретному классу, что позволяет снизить количество блокировок, накладываемых на таблицу, и распределить нагрузку на систему.
• Однако описываемому методу отображения присущи следующие недостатки:
• Первичные ключи могут быть неудобны в обработке.
• Отсутствует возможность моделировать отношения (связи) между абстрактными классами.
• Если атрибуты классов перемещаются между суперклассами и производными классами, требуется изменять структуру нескольких таблиц. Эти изменения будут не так часты, как в случае наследования с таблицами для каждого класса, однако их нельзя игнорировать (в отличие от метода Наследование с одной таблицей, в котором эти изменения вообще отсутствовали).
• Если в суперклассе изменить определение хотя бы одного атрибута (например, поменять тип данных), это потребует изменить структуру каждой таблицы, представляющей производный класс, поскольку поля суперкласса дублируются во всех таблицах его производных классов.
• При реализации метода поиска данных в абстрактном классе необходимо просматривать все таблицы, представляющие экземпляры производных классов. Это требует большого количества обращений к базе данных.
После того, как описаны основные методы объектно-реляционного отображения, реализуемые в современных инструментах, рассмотрим унифицированную объектную модель, используемую для тестирования (рис. 2).
Данная иерархия классов позволяет проверить возможности реализации трёх описанных ранее методов объектно-реляционного отображения: 1) Наследование с одной таблицей; 2) Наследование с таблицами для каждого класса; 3) Наследование с таблицами для каждого конкретного класса. Несмотря на то, что для представления должности в гипотетической предметной области выделено три класса, корневым из которых является абстрактный класс Post, а два унаследованных от него -реализованные классы ExperiencePost и StientificPost соответственно, физически атрибуты всех классов будут представлены в виде столбцов одной-единственной таблицы реляционной базы данных.
Для каждого класса (как абстрактного, так и реализованного), представляющего контрагента, (производного от Contragent) должна быть выделена отдельная таблица, которая будет содержать столбцы для каждого атрибута, объявленного только в данном классе (а также поля, необходимые для организации ассоциаций между классами).
Для представления адресов в предметной области выделено три класса: абстрактный класс Address и два реализованных CompanyAddress и EmployeeAddress. При реализации данной иерархии в структуре таблиц базы данных предполагается создать две таблицы (т.к. у нас два реализованных
69
класса), каждая из которых будет содержать столбцы, представляющие атрибуты как абстрактного, так и реализованного классов (а также поля для ассоциаций между классами).
Рис. 2 -Унифицированная модель для тестирования инструментов объектно-реляционного отображения
В данной статье рассмотрена объектная модель иерархии классов, которая может быть использована для тестирования инструментов объектно-реляционного отображения. Дальнейшим развитием данной работы является реализации этой модели с помощью определённого программного продукта, такого как Hibernate [4] или DevExpress XAF [5].
Литература
1. Гамма Э. и др. Приёмы объектно-ориентированного проектирования. Паттёрны проектирования, СПб: Питер, 2001. - 368 с.: ил. (Серия «Библиотека программиста»).
2. Гранд М. Шаблоны проектирования в Java. Пер. с англ. С. Беликовой. - М.: Новое знание, 2004. - 559с.: ил.
3. Флауер М. Архитектура корпоративных программных приложений, Пер. с англ. - М.: Издательский дом «Вильямс», 2004. - 544 с.: ил. - Парал. тит. англ.
4. Bauer C., King G., Hibernate in Action, Manning Publications, 2005, 431p.
5. The fastest way to platform independent business applications, http://www.devexpress.com/Products/NET/Application Framework/
УДК 004.652.4
РАЗРАБОТКА СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ПРИ ВЫБОРЕ МУЗЫКАЛЬНЫХ КОМПОЗИЦИЙ ДЛЯ ТОРГОВЫХ ПОМЕЩЕНИЙ
Шафоростова Елена Николаевна, к.п.н., доцент, Старооскольский технологический институт, Россия, Старый Оскол, [email protected] Ковтун Нелли Игоревна, старший преподаватель, Старооскольский технологический институт, Россия, Старый Оскол, [email protected] Лазарева Татьяна Ивановна, старший преподаватель, Старооскольский технологический институт, Россия, Старый Оскол, [email protected]
70
