CC BY
43
с помощью полиморфизма можно организовать систему эффективную систему обмена сообщениями между агентами родственной группы.
Важным аспектом, влияющим на преподавание объектных технологий, является составление учебных планов. Как правило, построение хорошей объектной модели является комплексной задачей, в которой применяются знания из множества учебных дисциплин. Тщательный подбор предметов при составлении учебного плана может помочь изучению и использованию ООП, а плохой подбор - помешать. Так, для успешной работы с экономическими моделями необходимо изучить курсы «Эконометрика», «Имитационное моделирование экономических процессов» с одной стороны и «Информационные системы», «Информационные технологии», «Информатика и программирование» с другой.
Отдельной темой исследования проблем преподавания ООП является вопрос об адекватном выборе программных средств, используемых в учебном процессе. Западное образование выгодно отличается широким использованием свободно-распространяемых программных продуктов, в том числе операционных систем и средств моделирования и разработки. Установив операционную систему linux, пользователь получает свободный и законный доступ к средам разработки программ, компиляторам и отладчикам. Не составляет труда подобрать язык программирования или среду разработки и документирования. При этом все эти продукты совершенно естественным образом стыкуются друг с другом. В нашей стране, особенно в экономических ВУЗах, используются преимущественно проприетарные системы и программы, которые применяются либо в урезанных вариантах, либо в виде старых версий. Переход на свободное программное обеспечение существенно бы упростил изучение ООП, хотя бы в рамках определенного круга дисциплин.
Хочется надеяться, что использование технологий и инструментов ООП в учебном процессе станет не только более распространенным, но и позволит повысить качество обучения будущих специалистов в различных прикладных областях, включая экономику.
Литература
1. Коуд П., Норт Д., Мейфилд М. Объектные модели: Шаблоны и приложения. М.:ЛОРИ, 2008
2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. - М.: Финансы и статистика, 2005.
3. Цисарь И.Ф., Нейман В.Г. "Компьютерное моделирование экономики".
Диалог-МИФИ, 2002, 304 с.
4. Самарский А.А., Михайлов А.П. Математическое моделирование: Идеи. Методы. Примеры. -2-е изд., испр. - М.: ФИЗМАТЛИТ, 2005. - 320 с.
5. Жданов С.А. Экономические модели и методы в управлении.: М. - «Дело и сервис», 1998 г., с. 113.
6. www.openttd.org УДК 004.652
ОБЪЕКТНО-РЕЛЯЦИОННАЯ НАДСТРОЙКА НАД РЕЛЯЦИОННОЙ СУБД
Терещенко Василий Николаевич, к.ф.-м.н., доц., Киевский национальный университет им. Тараса
Шевченко, Украина, Киев, v ter@ukr.net
Волошин Сергей Григорьевич, аспирант, Киевский национальный университет им. Тараса Шевченко, Украина, Киев, volser@apec.com.ua
Введение
При разработке информационных систем для описания объектов предметной области значительно удобней использовать объектно-ориентированный подход (ООП). Самым популярным способом хранения данных есть реляционная система управления базами данных (РСУБД). Проблема состоит в семантическом разрыве между объектноориентированным и реляционным подходами. В частности важным свойством при описании
70
схемы является наследование, которое отсутствует в реляционной модели. Для преодоления этого разрыва удобно использовать объектную базу данных и описывать данные в рамках ООП. Но объектно-ориентированные (ООСУБД) или объектно-реляционной СУБД (ОРСУБД) не имеют четких стандартов, и использование одной с этих СУБД привязывает информационную систему к единственному разработчику базы данных. Поэтому удобнее иметь универсальную надстройку над РСУБД, которая позволит использовать ООП для описаний и манипулирования данными.
1. Анализ последних исследований и публикаций
Для объединения объектно-реляционного подхода и реляционной базы данных последнее время все чаще используется подход под названием ORM (англ. Object-relational mapping, рус. Объектно-реляционная проекция) - технология программирования, которая объединяет РСУБД с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». Большинство публикаций посвящено данному подходу. Ляховец С.В. в своей работе [4] использует идею объектно-реляционного адаптера для геоинформационной системы, что по своей сути мало чем отличается от ORM. Некоторые недостатки ORM подхода описаны в работе [2], где авторы как альтернативу предлагают использовать метод функциональной декомпозиции для построения системы. В работе [3] авторы также изучают вопрос наследования для построений объектнореляционной проекции. Амбер и Скот детально изучаю вопрос объектно-реляционной проекции, и описывают возможные способы реализации наследования [6]. В роботе [7] продолжается изучение и анализируются возможные проблемы таких реализаций. Если не рассматривать недостатки конкретных реализаций ORM, то основными недостатками самого подхода являются: отсутствие динамичности и потеря быстродействия.
1.1. Отсутствие динамичности
Так как суть подхода состоит в генерации программного кода, значит, требуется перекомпиляция самой программы или модулей при внесении изменений. Это лишает систему гибкости. В свою очередь авторы работы [3] предлагают использовать метаданные для динамической генерации класса и описания проекции для ORM систем, но это не позволит изменять систему в реальном времени и требует перезапуска системы.
1.2. Потеря быстродействия
Так как данные конкретного объекта загружаются полностью, то это приводит к избыточным операциям, когда необходимо получить часть атрибутов. В роботе [8] автор пытается избавиться от этого недостатка при помощи частичной загрузки атрибутов. Предлагается 2 метода загрузки атрибутов: загрузка атрибутов одного объекта и загрузка атрибутов коллекции объектов. Но вопрос автоматического выбора метода остается открытым.
2. Постановка задачи и способы реализации
2.1. Постановка задачи
Задача состоит в том, что бы на основе реляционной СУБД разработать объектнореляционную среду. Среда должна обладать следующими свойствами: наследование данных, универсальность, динамичность, быстродействие, метаданные, иметь механизм распределения прав [1].
2.2. Подходы относительно структуры базы данных
Существует несколько способов спроецировать иерархическую структуру классов на реляционную модель [6]:
• Проекция иерархической структуры на одну таблицу
• Проекция каждого класса на свою собственную таблицу
• Проекция каждого конкретного класса на таблицу
71
• Проекция класса на общую структуру таблиц
При условии, что надо иметь одного общего предка, первые 2 подходы идентичны. Решение сводится к созданию одной таблицы со всеми возможными атрибутами. Для большинства информационных систем это абсолютно не подходит, так как в таких системах количество объектов и их атрибутов исчисляется сотнями и тысячами.
Последние 2 подходы подходят, но имею свои преимущества и недостатки. Недостатки первого состоит в том, что для добавления нового класса необходимо изменять структуру базы, что позволяет делать не любая СУБД во время активной работы с базой. К преимуществам такого подхода стоит отнести достаточное быстродействие при получении табличного набора данных. Последний подход является самым универсальным, но имеет большой недостаток: значительная потеря быстродействия при получении табличного набора данных.
Следующий обобщенный подход объединяет в себе преимущества двух предыдущих (Рис. 1). В основе подхода лежат метаданные, которые описывают классы и их поля. Поля делятся на 2 типа: динамические и статические. От типа поля зависит способ хранения и способ работы с ним. Все классы системы наследуются от единого предка. Это позволяет иметь единый уникальный нумератор всех объектов и вынести общие поля в одну общую таблицу. Дальше для статических полей создается таблица со связью 1 к 1 с таблицей предка. Значения всех динамических полей хранятся в одной таблице «Значения поля». В зависимости от типа значения динамического поля данные хранятся в 2-х таблицах: таблица для простых значений и для ссылочных значений. Это обеспечить целостность данных на уровне СУБД. Так как все классы имеют общего предка, то внешний ключ для ссылочного значения будет указывать на таблицу общего класса. Предыдущие 2 варианты являются частными случаями предложенного подхода (Рис.1). Наличие динамических полей позволяет вносить изменения в структуру системы не только специалистам, но и простым пользователям. Этот факт позитивно влияет на результат внедрения такой системы. Для работы со сложной схемой разработчику предоставляться либо SQL подобный язык запросов, либо специализированное программное API. Это скроет сложную схему данных от разработчика и пользователя, позволит манипулировать объектами предметной области.
2.3. Язык запросов
Уже существует несколько языков запросов и программных интерфейсов для объектно-реляционных баз данных. Это таки, например, как OQL[9], JDOQL[10], db4o SODA[11]. По своей сути язык запросов для объектных данных (ObQL - object query language) очень похож на язык запросов SQL и являет собой абстрактную надстройку. Отличие состоит в том, что ObQL оперирует с понятием «объект», а не «реляция». Отлитие в синтаксисе состоит в наличии комплексных атрибутов.
Теорема 1. Язык запросов к объектным данным (ObQL)сводится к SQL.
Для доказательства теоремы достаточно показать реализацию особенностей основных операция ObQL через SQL. Покажем это на следующих примерах операций, представленных на рис. 1.
2.3.1. Операция выборки
Операция выборки в ObQL по сути состоит с нескольких операций: операции соединения, переименования атрибутов и операции выборки.
Пример: Пускай, имеем такие классы: Базовый -> Люди -> Работники ObQL:
SELECT * FROM Работники SQL:
SELECT *, FROM Работники
INNER JOIN Люди ON Люди.ИД = Работники.ИД
INNER JOIN Базовый ON Базовый.ИД = Работники.ИД
72
SQL при наличии динамически полей:
SELECT
*
, ДинПоле1.Значение AS НаименованиеПоля1 , ДинПоле2.Значение AS НаименованиеПоля2
, ДинПолеЫ. Значение AS НаименованиеПоляЫ FROM Работники
INNER JOIN Люди ON Люди.ИД = Работники.ИД INNER JOIN Базовый ON Базовый.ИД = Работники.ИД INNER/LEFT JOIN Значение поля AS ДинПоле1 ON Базовый.ИД = ДинПоле1. Объект_ИД AND Значение поля.НаименованиеПоля = 'ДинПоле1'
INNER/LEFT JOIN Значение поля AS ДинПоле2 ON Базовый.ИД = ДинПоле2.Объект_ИД AND Значение поля.НаименованиеПоля = 'ДинПоле2'
INNER/LEFT JOIN Значение поля AS ДинПолеN ON Базовый.ИД = ДинПоле^Объект_1Д AND Значение поля. НаименованиеПоля = 'ДинПоле^
Рис. 1. Примеры выполнения операций
2.3.2. Комплексные атрибуты
Пример ObQL:
SELECT Компания.Территория.Код FROM Компания Данный запрос преобразовывается в следующий SQL:
SELECT Территория.Код FROM Компания
INNER JOIN Территория ON Территория.ИД=Компания.Территория.ИД SQL при наличии динамических полей:
SELECT ДинПоле1.Значение AS Код FROM Компания
73
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
ПОСТРОЕНИЕ ОНТОЛОГИЧЕСКОГО ПОРТАЛА С ИСПОЛЬЗОВАНИЕМ
ОБЪЕКТНОЙ БАЗЫ ДАННЫХ
Грегер Сергей Эдуардович, доц., Факультет экономики и менеджмента, кафедра информационных технологий, Уральский государственный технический университет - УПИ имени первого Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.), Россия, Нижний Тагил,
segreger@gmail.com
Сковородин Евгений Юрьевич, студент, Факультет экономики и менеджмента, кафедра информационных технологий, Уральский государственный технический университет - УПИ имени первого Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.),
kotnt@bk.ru
Одним из существенных факторов, влияющих на современное общество можно назвать информационные технологии. «Всемирная паутина» - World Wide Web получила широчайшее распространение и стала основным источником оперативной и достоверной информации для миллионов людей. Рост объема информационных потоков породил
74
