CC BY
112
Литература
1. E.F. Codd. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM,
Volume 13, Number 6, June, 1970.
Перевод на русский язык: Е.Ф. Кодд. Реляционная модель данных для больших совместно используемых банков данных.
2. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management — 3-е изд. — М.: Вильямс, 2003.
3. Аршинов В.И. Событие и смысл в синергетическом измерении. В кн:.Событие и смысл. Синергетический опыт языка (под ред. Киященко Л.П.,ТищенкоП.Д.) М.:ИФ РАН 1999. С. 11 37.
4. Аршинов В.И. Синерегетика как феномен постнеклассической науки. М.:ИФРАН 1999.
5. 5. А.Е.Васильев Развитие логических моделей данных.
6. С.Д. Кузнецов, М.Н. Гринев Ландшафт области управления данными: аналитический обзор. Институт системного программирования РАН
7. С.Д. Кузнецов Объектно-реляционные базы данных: прошедший этап или недооцененные возможности? Труды Института системного программирования, т. 13, часть 2, М., ИСП РАН, 2007,стр. 115-140.
8. Микляев И.А., Матричная универсальная объектно-реляционная база данных, Материалы I Международной научно-практической конференции «Объектные системы - 2010», Россия, Ростов-на-Дону, 10-12 мая 2010г, стр. 34-39.
9. Микляев И.А., Свидетельство ОФЕРНиО №15405 (Объединённого фонда электронных ресурсов «Наука и образование») "Универсальный тип данных баз данных", 2010.
УДК 004.652.5
ORM КАК АНТИПАТТЕРН
Шитов Николай Андреевич, бакалавр информационных технологий, магистрант 1 курса, Ивановский государственный химико-технологический университет, Россия, Иваново,
niko 1989@inbox.ru
Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, galiaskarov@isuct.ru
Введение
Проблема хранения информации была издавна известна человечеству, и за всю историю было найдено множество решений для хранения информации в том или ином виде, пока в 50-х годах прошлого века проблема не вышла на новый уровень - уровень компьютерных технологий. В качестве решения были предложены новые средства хранения данных - базы данных [1], которые в 70-х годах пришли в своем развитии к самому популярному в наше время виду баз данных (БД) - реляционным. Однако появление и последующее развитие объектных средств проектирования и разработки потребовало от разработчиков СУБД адекватной реакции. В результате появилось несколько направлений развития БД:
• создание объектных и объектно-ориентированных БД,
• создание объектных надстроек над реляционными БД (объектно-реляционные БД),
• а также разработка методов объектно-реляционного отображения (ORM).
Рассмотрим последнее направление более подробно.
ORM (англ. Object-relational mapping, рус. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектноориентированных языков программирования, создавая «виртуальную объектную базу данных» [2]. Потребность в этой технологии, как уже говорилось выше, может возникнуть в случае применения объектного подхода при написании приложения и использовании при
72
этом реляционной БД в качестве хранилища данных. В данном случае возникает проблема преобразования программных объектов, которые представляют собой объекты реального мира, в форму, которая будет подходящей для хранения в БД и которая затем позволит извлечь эти объекты с сохранением отношений между ними. Решение проблемы преобразования данных между объектно-ориентированным видом и реляционной формой за время параллельного существования реляционных БД и объектно-ориентированного программирования привело к созданию шаблонов (паттернов), избавляющих программистов от написания большого количества кода [2].
Однако существует мнение, что за время своего существования технология ORM превратилась в антипаттерн:
• во-первых, несмотря на достоинства, ORM имеет довольно существенные недостатки,
• во-вторых, есть более удобные и лишенные этих недостатков технологии: объектноориентированные базы данных [3], хранилища вида «ключ-значение», документоориентированные БД и другие виды NoSql, которые пытается заменить ORM.
Сравним ORM c объектно-ориентированными БД по нескольким критериям.
1. Объем исходного кода
Реализовать ORM в своем приложении можно несколькими способами, но независимо от способа придется создавать структуры, поддерживающие преобразование объектов в таблицы. В случае самостоятельной реализации с использованием паттернов, которых на данный момент описано более 10 [2], это, скорее всего, будут дополнительные классы и методы, а при использовании сторонних разработок (например, библиотеки Nhibemate [4]) это будут файлы мэппинга, которые обеспечивают соответствие между структурой классов и таблицами БД.
«ORM Persistabie» People 1 pet «ORM Persistabie» Pet
-ID : ini -FIO : String -adress: String -telephone ; String -ID :int -rick i String -breed ; String -age : int
people 0,,#
0.’
toy
pel
G..*
«ORM Persistabie»
_________toy_________
•id: ini
•name i ini
Рис. 1 - Диаграмма классов приложения
People
? ID int{10)
0 FIO varchar(255)
0 adress varchar(255)
0 telephone varchar(255)
! Pet ^
1? ID int(10)
PeoplelD int(10)
3 Nick varchar(255)
3 breed varchar(255)
3 age intci o)
V J
2
J2L
f Id int(10)
0 Name int(10)
Toy Entity ^
ЧХ
%Toyld int(10) %PettD int(10)
Рис. 2 - Физическая модель БД
73
При работе с ООБД программист от такой дополнительной информации избавлен, ему достаточно создать нужный класс, а затем произвести сохранение объекта в БД. Объем исходного кода в этом случае заметно меньше, а сам код становится гораздо более прозрачным и читаемым.
Рассмотрим пример приложения, созданного с использованием Nhibernate. На рис.1 приведена диаграмма программных классов, на рис.2 приведена физическая модель БД. Приложение предназначено для хранения информации о домашних питомцах (таблица “Pet”), которые имеют хозяина (таблица “People”). Также в базе можно сохранить информацию об игрушках питомца (таблица “Toy”). Одной и той же игрушкой могу с удовольствие играть сразу несколько питомцев (связь «многие-ко-многим»).
Для хранения связи «многие-ко-многим», программно реализуемой с помощью коллекций объектов, в БД создается специальная промежуточная таблица, в которой хранится соответствие идентификаторов объектов.
Пример мэппинга (класс “People”):
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
<class name="People, untitled" table="People" lazy="false">
<id name="ID" column="ID" type="Int32" unsaved-value="0">
<generator class="native"/>
</id>
<property name="FIO"
type="String"
length="255"
not-null="true"/>
<property name="Adress"
column="adress"
type="String"
length="255"
not-null="true"/>
<property name="Telephone"
column="telephone"
type="String"
length="255"
not-null="true"/>
<set name="Pet"
lazy="true"
cascade="save-update"
inverse="true">
<key column="PeopleID"/>
<one-to-many class="Pet, untitled"/>
</set>
</class>
</hibernate-mapping>
Поскольку использовалась библиотека Nhibernate, работа по созданию классов упростилась, но в итоге к компилируемому коду были в нагрузку получены файлы разметки (по одному на класс), которые при внесении изменений в структуру классов и/или таблиц требуют дополнительной верификации во избежание трудно исправляемых ошибок несоответствия данных. Также создается отдельный файл, содержащий структуру БД в виде XML.
2. Скорость обработки информации
За счет того, что в случае ORM между классами и БД присутствует внушительная прослойка, фактически ориентированная на преобразование каждого объекта в запись таблицы БД, скорость совершения действий с сохраненными в БД объектами уменьшается. В объектных базах помимо сохранения структуры объекта используются производительные алгоритмы для обработки списочных, древовидных и иных часто встречающихся структур
74
данных, что позволяет не заниматься преобразованием объектов из одной формы в другую и быстро выполнять с ними различные операции.
На рисунках 3-7 приведены результаты сравнения скоростей выполнения операций (чтение, запись, выполнение запросов, удаление, обновление) для представителей различных видов БД по данным opensource проекта PolePosition [5].
Тестирумые БД:
NOSQL [6]:
• mongoDB - документоориентированная БД;
• Versant [3] - объектно-ориентированная БД;
• db4o [7] - объектно-ориентированная БД;
SQL:
• JDBC/MySQL - реляционная БД, для подключения используетсяд драйвер JDBC;
• JDBC/PostgreSQL - реляционная БД, для подключения используется драйвер JDBC;
SQL + ORM:
• Hibernate/MySQL - реляционная БД + библиотека Hibernate (для языка Java) для реализации ORM;
• Hibernate/PostgreSQL - реляционная БД + библиотека Hibernate (для языка Java) для реализации ORM;
selects=500, objects=5, depth=6
mongoDB/1.8.2 I 742ms JDO/Versant/VOD-8.0.1.6 | 1050ms db4o C/S TCP/6.0.174.15231 JDBC/MySQL-5.1.4 Hibernate/MySQL-5.5.13 JDBC/PastgreSQL-3.4.4 H ibernate/PostgreSQL-9.0.4
mongoDB/1.8.2 JDO/Versant/VOD-8.0.1.S db4o C/S TCP/8.0.174.15231 JDBC/MySQL-5.1.4 JDBC/PostgreSQL-S.4.4 Hibernate/MySQL-5.5.13 Hibernate/PostgreSQL-9.0.4
selects=500, objects=5, depth=6
614ms
615ms
4507ms
12287 ms Я 12441ms
20236ms
32487ms
Рис. 3 - Оперция записи
Рис. 4 - Оперция чтения
Iselects=500, objects=5, depth=6 954ms 1339ms
db4o C/S TCP/8.0.174.15231 JDBC/PostgreSQL-3.4.4 JDBC/MySQL-5.1.4 Hibernate/MySQL-5.5.13 Hibernate/PostgreSQL-9.0.4
5871ms
16883ms 17261ms | 24021ms
37329ms
Рис. 5 - Выполнение запросов
Рис. 6 - Удаление объектов
selects=500, objects=5, depth=6
JDO/Versant/VOD-8.0.1.6 | 337ms 1023ms 2510ms
db4o C/S TCP/8.0.174.15231 mongoDB/1.8.2 JDBC/PostgreSQL-8.4.4 Hibernate/MySQL-5.5.13 JDBC/MySQL-5.1.4 Hibernate/PostgreSQL-9.0.4
3977 ms 4447ms 4953ms 7226ms
Рис. 7 - Обновление объектов
Как видно из графиков, NOSQL БД являются в разы более призводительными, чем суррогатные решения с использованием технологии ORM, однако им присущи следующие недостатки:
75
1. Вероятность допущения ошибки. Чем больше объем исходного кода, чем больше преобразований выполняется над объектом, прежде, чем он попадет в БД, тем более вероятно совершение ошибки или появление узкого места, в котором будут появляться трудно отлавливаемые ошибки. А в случае некомпилируемых файлов мэппинга, которые, как правило, создаются в XML формате, работа усложняется, поскольку не всегда легко понять, при описании какой же структуры возникла ошибка, особенно, если класс имеет большое количество структурных элементов.
2. Сложность поддержки проекта. Этот критерий тесно связан с объемом исходного кода и вероятностью ошибки — и то, и другое усложняет поддержку и замедляет разработку.
Выводы
Хотя из проведенного обзора видно, что реляционные БД, а тем более решения на основе ORM, уступают NOSQL БД по многим параметрам, они еще не скоро сдадут свои позиции в силу нескольких факторов:
• в реляционных БД реализованы возможности, которые присутствуют далеко не во всех NOSQL БД;
• при решении некоторых видов задач правильнее, удобнее и быстрее работать с данными, хранящимися в таблицах, а не в виде объектов;
• большое количество коммерческих продуктов используют реляционные БД.
Литература
1. Дейт К. Дж. Введение в системы баз данных / К. Дж. Дейт. - 8-е изд. - М.: Вильямс, 2005. -1328 с.
2. Фаулер М., Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series). -СПб.: Издательский дом "Вильямс", 2006. - 404 с.: ил
3. Grehan R. Introduction to ODBMS. The Resource Portal for Education and Research. - [Internet resource]. - URL: http://www.odbms.org/Introduction/
4. Bauer C. Hibernate in Action: Practical Object/Relational Mapping / C. Bauer, G. King. - Manning Publications, 2004. - 400 p.
5. Poleposition open source database benchmark. - [Internet resource]. - URL: http://www.polepos.org.
6. List of NOSQL Databases. NoSQL Archive. - [Internet resource]. - URL: http://nosal-database.om/.
7. Paterson J. The Definitive Guide to db4o / J. Paterson, S. Edlich, H. Horning, R. Horning. - Apress, 2006. -512 p.
УДК 004.048
АНАЛИЗ ВЫСКАЗЫВАНИЯ ПОЛЬЗОВАТЕЛЯ В ДИАЛОГОВЫХ СИСТЕМАХ НА
ОСНОВЕ НЕЧЕТКОЙ ЛОГИКИ1
Зинченко Денис Сергеевич, бакалавр информационных технологий, магистрант 1 курса, Ивановский государственный химико-технологический университет, Россия, Иваново,
denamorado@mail.ru
Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, galiaskarov@isuct.ru
Введение
В современном мире перед различными организациями очень часто встает задача автоматизации предоставления консультационных услуг. Степень автоматизации может
1 Лауреат специальной номинации "Лучший доклад о нечетких системах". Автор доклада награждается книгой Конышевой Л.К. и Назарова Д.М. "Основы теории нечетких множеств. Учебное пособие"
76
