CC BY
52
INNER/LEFT JOIN Значение поля AS ДинПоле1 ON Компания.
Территория _ИД = ДинПоле1.Объект_ИД AND Значение поля.
НаименованиеПоля = 'Код'
Заключение
В работе рассмотрена проблема объединения объектно-ориентированной и реляционной моделей. Проанализированы последние работы на эту тематику. Показаны недостатки существующих решений, в частности ORM. Сделан обзор существующих схем данных для хранения объектно-ориентированных иерархических данных и
проанализированы их преимущества и недостатки. Предложена собственная обобщенная схема и показаны ее преимущества. Предложена модификация языка запросов SQL для удобной работы с объектными данными.
Литература
1. Терещенко В., Волошин С. Розподш прав доступу в облшових системах, Вюник Кшвського ушверситету, випуск №3, 2008, серiя: фiзико-математичнi науки, с.180-184
2. Бойко, Ю.В.; Погорший, С.Д.; Коваленко, О.В. Формування лопки внутршньо! мiжрiвневоl взаемодн в багатоланковш систему Проблеми програмування, 2008, № 2-3
3. А.Д. Чупрыни, И.Б. Гавсиевич, В.В. Казимир, Использование Метаданных для динамического расширения, Вюник хмельницького нацюнального ушверситету
4. Ляховец С.В. Сопряжение объектно-ориентированной ГИС с реляционной базой данных // Сб. науч. трудов 9-й Междунар. научной конф. "Теория и техника передачи, приема и обработки информации". - Харьков: ХНУРЭ. - 2003. - С. 268 - 269.
5. Касаткина Н.В., Танянский С.С., Чапланова Е.Б. Об Одном подходе к построению объектнореляционной модели данных, Збiрник наукових праць Вшськового шституту Кшвського нацюнального ушверситету iменi Тараса Шевченка, 2009, випуск 20
6. Ambler, Scott (2006). Mapping Objects to Relational Databases: O/R Mapping in Detail.
7. Ryan Somma, The O/R Problem: Mapping Between Relational and Object-Oriented Methodologies, Strategic Planning for Database Systems, 2010
8. Jan SUCHAL, Transparently Mapping Objects to Relational Databases with AspectJ, IIT.SRC 2007, Bratislava, April 18, 2007, pp. 1-8.
9. R. G. G. Cattell, D. K. Barry, M. Berler, J. Eastman, D. Jordan, C. Russell, O. Schadow, T. Stanienda, and F. Velez, editors. The Object Data Standard ODMG 3.0. Morgan Kaufmann, January 2000.
10. C. Russell. Java Data Objects (JDO) Specification JSR-12. Sun Microsystems, 2003.
11. db4objects web site. http://www.db4o.com
УДК 681.3
ПОСТРОЕНИЕ ОНТОЛОГИЧЕСКОГО ПОРТАЛА С ИСПОЛЬЗОВАНИЕМ
ОБЪЕКТНОЙ БАЗЫ ДАННЫХ
Грегер Сергей Эдуардович, доц., Факультет экономики и менеджмента, кафедра информационных технологий, Уральский государственный технический университет - УПИ имени первого Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.), Россия, Нижний Тагил,
Сковородин Евгений Юрьевич, студент, Факультет экономики и менеджмента, кафедра информационных технологий, Уральский государственный технический университет - УПИ имени первого Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.),
Одним из существенных факторов, влияющих на современное общество можно назвать информационные технологии. «Всемирная паутина» - World Wide Web получила широчайшее распространение и стала основным источником оперативной и достоверной информации для миллионов людей. Рост объема информационных потоков породил
74
смещение в сторону разработки крупных информационных систем — корпоративных порталов, электронных библиотек и т.п. В [1,6] дается следующее определение портала: «Портал — это сетевой узел или комплекс узлов, подключенных к Интернету по высокоскоростным каналам, обладающий развитым пользовательским интерфейсом и предоставляющий единый с концептуальной и содержательной точки зрения доступ к широкому спектру информационных ресурсов и услуг, ориентированных на определённую аудиторию». Наиболее часто встречаются корпоративные порталы, основной задачей которых является предоставление удобного способа публикации информации и организации доступа к ней. Управление накопленной информацией и обеспечение доступа к ней представляют существенные трудности.
Процесс разработки требует больших трудозатрат. Эффективной методикой разработки портала в настоящее время является разработка портала на основе модели предметной области. В ходе разработки портала создается ряд моделей, учитывающих отношения в предметной области, спецификацию функциональных требований и алгоритмов их реализаций, с последующим их преобразованием в конкретную структуру сайта. Одним из существенных недостатков такого подхода является необходимость повторной разработки сайта при модификации используемой модели предметной области, изменений требований к функциональности или добавлении новой предметной области. Такое положение дел особенно неприемлемо в порталах, поскольку они по своей специфике ориентированы на широкую аудиторию, и в ходе работы пользователи должны иметь возможность изменять и добавлять новые предметные области, тем самым расширяя портал.
Для повышения эффективности порталов необходимо иметь возможность автоматизированного создания и поддержания чёткой информационной и навигационной структуры сайтов. Эти структуры определяют способ построения навигационной модели портала. Традиционные методы разработки и сопровождения сайтов требуют от их владельцев серьёзных затрат при внесении изменений в эти структуры.
Одним из способов решения указанных проблем при проектировании, реализации и сопровождении порталов является использование семантических моделей на базе онтологии - разработка семантических порталов. Подходы, предложенные для разработки семантических порталов, базируются на создании онтологии предметной области, использовании логической машины запросов к онтологии и автоматической генерации интерфейса пользователя на основе результатов запросов. Описание онтологической модели производится на одном из XML-подобных языков описания онтологий, таких как RDF и OWL, а качестве реализации обычно выбирают средства, предоставляемы платформой Java. По сравнению с другими способами описания онтологий язык OWL обладает рядом преимуществ:
Спецификация языка веб-онтологий OWL (Ontology Web Language) [7] предоставляет возможность создавать машиночитаемые описания классов и отношений между ними, присущими для веб-документов и приложений;
Позволяет организовать три различных уровня выразительности, предоставляя пользователю возможности от создания иерархии объектов и несложных ограничений до практически неограниченной синтаксической свободы и выразительности;
Определяет способ представления знаний и предоставляет возможность делать новые выводы на основе текущих знаний;
Онтология, построенная для определенной предметной области, может быть применима для целого ряда систем. Такое решение позволяет в несколько раз сократить количество информации и в достаточной степени избежать дублирования её.
Кроме задачи создания онтологии предметной области, ключевыми задачами в процессе разработки семантического портала является выбор и реализация способа хранения онтологии и автоматизация процессов создания и сопровождения портала, организации их навигационной структуры, обеспечении адаптации представления портала с учётом потребностей пользователя. В процессе реализации таких задач онтологическая модель
75
представляется как минимум в трех форматах - в формате используемой системы хранения, в формате компонент реализации используемой среды реализации и в формате компонент интерфейса пользователя.
Таким образом, от задачи последовательной разработки нескольких связанных моделей - модели данных, модели приложения, навигационной модели и модели интерфейса пользователя, присущей методологии разработки на основе модели предметной области, мы пришли к задачи отображения единой онтологической модели в разных семантиках - задаче реализации пучка семантик над онтологией.
Одним из путей, позволяющих упростить решение этой задачи, является построение семантического портала с системой управления содержимым сайта Plone [4] (позволяет создавать сайты самых различных типов - от простых сайтов-визиток до корпоративных порталов). Рассматриваемая система использует сервер приложений ZOPE (Z Object Publishing Environment) и объектную базу ZODB [5]. Одной из отличительных особенностей Plone является использование компонентной архитектуры, позволяющей разрабатывать новые и интегрировать существующие компоненты хранения и обработки данных и компоненты реализации пользовательского интерфейса.
Идея реализации веб-онтологии с использованием объектной базы данных показалась нам достаточно перспективной. Конечно, связать платформу Java - де-факто являющимся стандартом реализации семантических информационных систем, с Plone (Zope) - можно, но не эффективно. Тем более задача представляется актуальной, поскольку выбранная нами система является наиболее ярким представителем CMS и широко используется для построения корпоративных порталов.
В ZODB хранение данных организовано в виде разветвленного дерева объектов, реализующих различные типы (контент-типы), как поставляемых в составе Plone, так и дополнительно разработанных.
Функционирование семантического портала обеспечивается взаимодействием двух уровней приложения. Для реализации первого уровеня разработан набор компонент, обеспечивающих представление концептов языка OWL, таких как Class, Data Property, Object Property и их атрибутов. Использование таких компонент позволяет построить модель онтологии, не включающую в себя семантические концепты Individuals, и реализовать часть интерфейса пользователя.
Второй уровень портала предназначен для хранения индивидуальных объектов онтологии и может быть реализован двумя способами.
Первый способ предполагает создание дополнительного компонента, представляющего концепт Individuals спецификации OWL. Реализация компонента совместно с компонентами первого уровня позволяет строить модель онтологии в объектной базе данных, и обладает наибольшим уровнем общности, поскольку позволяет строить онтологическую модель для любой предметной области. Такая реализация способу позволяет строить «истинную» онтологию, сохраняемую в объектной базе данных. Реализация задач уровня приложения и уровня интерфейса пользователя обеспечивается набором соответствующих сервисов портала.
Второй способ предполагает создание группы компонентов, где каждый компонент предназначен для представления реализации концепт Individuals в контексте концепта Class, который он реализует. Реализация такого набора компонент зависит от предметной области. По существу, такой набор не отличается от компонент, разрабатываемых в случае реализации обычного, не семантического портала, в среде Plone. Реализация по второму способу позволяет специфицировать реализацию и представление каждой отдельной сущности предметной области.
На рис. 1 представлена UML - модель компонентов, реализующих первый уровень портала и представляющих концепты языка OWL.
Для построения модели компонентов и их генерации нами была использован CASE-редактор ArgoUML и генератор компонентов ArchGenXML, позволяющего экспортировать
76
UML диаграмму, построенную с использованием соответствующего UML-профиля, в пакет расширения Plone.
Рис. 1. Модель реализации спецификации
Создаваемый нами семантический портал предназначен для решения задач организации учебного процесса в системе дистанционного обучения. Нами разработан компонентный набор, специфичный для предметной области «Образование» и реализующий второй способ построения соответствующего уровня портала. [3].
В развитии данной темы предполагается разработать онтологии и соответствующие компоненты, позволяющие реализовать слои приложения и интерфейса пользователя. В конечном итоге, это даст возможность пользователю перестраивать структуру и реализацию портала «на лету», меняя онтологии через соответствующий интерфейс.
Литература
1. М.В.Булгаков, А.Д.Иванников, М.С.Ковальский, В.П.Носов, А.А.Рогачев, А.Н.Таран. Федеральный портал по научной и инновационной деятельности. В сб. научн. ст. "Интернетпорталы. Содержание и технологии", вып.4, М.: Просвещение, 2007, с. 323-345.
2. Грегер С.Э. Разработка дополнительных компонентов для обеспечения информационной поддержки образовательного процесса для учебного портала на базе CMS Plone. Новые образовательные технологии в вузе: сборник материалов седьмой международной научнометодической конференции, 8 - 10 февраля 2010 года. В 2-х частях. Часть 1. Екатеринбург: ГОУ ВПО «УГТУ-УПИ имени первого Президента России Б.Н.Ельцина», 2010. С.97-100
3. Грегер С.Э. Пакет компонентов обеспечения информационной поддержки образовательного процесса для учебного портала на базе CMS Plone. Тезисы докладов V конференции «Свободное программное обеспечение в высшей школе» . М:Институт логики 2010г. с.15-17
4. Грегер С.Э. Администрирование и интерфейс пользователя CMS Plone (монография) Федер. Агентство по образованию, ГОУ ВПО "УГТУ-УПИ им.первого Президента России Б.Н.Ельцина". Нижнетагил. технол. ин-т (фил.). -Нижний Тагил: НТИ(ф) УГТУ-УПИ, 2009. -140с
5. Грегер С.Э. Сервер приложений «Zope». Учебное пособие для вузов. М.:Горячая линия -Телеком, 2009.-256 с.:ил
6. Тихонов А.Н., Иванников А.Д., Гридина Е.Г., Куракина Н.И., Симонов А.В., Чиннова И.И. Комплексный анализ системы федеральных образовательных порталов. // В сборнике
77
научных статей "Интернет-порталы: содержание и технологии". Выпуск 2. / Редкол.: А.Н. Тихонов (пред.) и др.; ГНИИ ИТТ "Информика". - М.: Просвещение, 2004. - С. 192-226.
7. OWL2 Web Ontology Language Structural Specification and Functional-Style Syntax. http://www.w3.org/2007/OWL/wiki/Synta
УДК 004.652.5
ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ДАННЫХ О ЦИФРОВОЙ ТРАНСПОРТНОЙ СЕТИ СВЯЗИ
Саенко Игорь Борисович, д.т.н., проф., ведущий научный сотрудник, Санкт-Петербургский институт информатики и автоматизации Российской академии наук, Россия, Санкт-Петербург,
Невров Алексей Александрович, к.т.н., научный сотрудник, Санкт-Петербургский институт информатики и автоматизации Российской академии наук, Россия, Санкт-Петербург Салами Мохамад Юнес, инженер-исследователь, Сирийская Арабская республика
Создание объектно-ориентированной модели представления данных о цифровой транспортной сети связи (ЦТСС) имеет цель разрешить противоречие между данными мониторинга связи на технологическом уровне и представлением состояния ЦТСС и ее элементов на оперативно-техническом уровне. Противоречие обусловлено различием информационных моделей, подлежащих учету на указанных уровнях. Разрешение этого противоречия в рамках объектного подхода связывается с реализацией базы данных (БД) ЦТСС на объектно-ориентированной концепции [1].
Основными требованиями к модели являются обеспечение согласования технологической и оперативно-технической информационных моделей, полный охват сетевых устройств и протоколов управления и расширяемость. Эффективность модели оценивается по возможности отображения объектов сети любой сложности без потери информативности о состоянии их элементов.
Исходными данными для моделирования являются множества типов объектов учета и контролируемых параметров для каждого типа, а также множество видов взаимосвязей между объектами.
Объектно-ориентированная модель представления данных о ЦТСС включает структурную, динамическую и функциональную части (модели).
Построение структурной модели ЦТСС включало этапы [2]: определение классов; составление словаря данных; определение зависимостей между классами; уточнение атрибутов; построение иерархии классов; исследование и усовершенствование модели.
При определении классов был проведен анализ технической документации по ЦТСС и предъявляемых к ней требований. Из общего списка возможных классов были исключены ненужные: избыточные, нерелевантные, нечетко определенные и т.д. Оставшиеся классы образовали множество базовых классов, родительских для классов-потомков.
При подготовке словаря данных было обращено внимание на то, чтобы он содержал четкие и недвусмысленные определения всех объектов (классов), атрибутов, операций, ролей и других сущностей, рассматриваемых в проекте.
При определении зависимостей между классами осуществлялось исключение атрибутов-ссылок на другие классы и их замена зависимостями. Имена возможных зависимостей были получены из глаголов или глагольных оборотов, встречающихся в документации. По предложенным критериям были убраны из общего списка ненужные или неправильные зависимости.
Выявление зависимостей, существующих между классами объектов ЦТСС, показало, что основными видами таких зависимостей являются (рис. 1):
1. "целое - часть целого", означающая, что объект может быть компонентом и/или контейнером для одного и более других объектов;
78
