О технике реляционно-объектного преобразования

Данная статья посвящена методам отображения прикладных реляционных данных в объектную модель. В ней проводится анализ существующих решений, основанных на методике объектно-реляционного преобразования, а также выделения основных недостатков в использовании данной техники. Предложена техника реляционн...

Ausführliche Beschreibung

Gespeichert in:

Bibliographische Detailangaben
Datum:	2014
1. Verfasser:	Лихацкий, И.А.
Format:	Artikel
Sprache:	Russian
Veröffentlicht:	Інститут програмних систем НАН України 2014
Schriftenreihe:	Проблеми програмування
Schlagworte:	Інструментальні засоби і середовища програмування
Online Zugang:	http://dspace.nbuv.gov.ua/handle/123456789/86739
Tags:	Tag hinzufügen Keine Tags, Fügen Sie den ersten Tag hinzu!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Zitieren:	О технике реляционно-объектного преобразования / И.А. Лихацкий // Проблеми програмування. — 2014. — № 1. — С. 49-54. — Бібліогр.: 16 назв. — рос.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-86739
record_format	dspace
spelling	irk-123456789-867392015-10-01T03:02:01Z О технике реляционно-объектного преобразования Лихацкий, И.А. Інструментальні засоби і середовища програмування Данная статья посвящена методам отображения прикладных реляционных данных в объектную модель. В ней проводится анализ существующих решений, основанных на методике объектно-реляционного преобразования, а также выделения основных недостатков в использовании данной техники. Предложена техника реляционно-объектного преобразования, главная цель – это достижения высокой производительности и достаточного уровня автоматизации генерируемого кода, при взаимодействии с базой данных. В качестве примера реализации методики реляционно-объектного преобразования описана система кодогенерации C-Gen предложенная автором. Приведена краткая характеристика и основные возможности данной системы. 2014 Article О технике реляционно-объектного преобразования / И.А. Лихацкий // Проблеми програмування. — 2014. — № 1. — С. 49-54. — Бібліогр.: 16 назв. — рос. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/86739 51:681.3 ru Проблеми програмування Інститут програмних систем НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Russian
topic	Інструментальні засоби і середовища програмування Інструментальні засоби і середовища програмування
spellingShingle	Інструментальні засоби і середовища програмування Інструментальні засоби і середовища програмування Лихацкий, И.А. О технике реляционно-объектного преобразования Проблеми програмування
description	Данная статья посвящена методам отображения прикладных реляционных данных в объектную модель. В ней проводится анализ существующих решений, основанных на методике объектно-реляционного преобразования, а также выделения основных недостатков в использовании данной техники. Предложена техника реляционно-объектного преобразования, главная цель – это достижения высокой производительности и достаточного уровня автоматизации генерируемого кода, при взаимодействии с базой данных. В качестве примера реализации методики реляционно-объектного преобразования описана система кодогенерации C-Gen предложенная автором. Приведена краткая характеристика и основные возможности данной системы.
format	Article
author	Лихацкий, И.А.
author_facet	Лихацкий, И.А.
author_sort	Лихацкий, И.А.
title	О технике реляционно-объектного преобразования
title_short	О технике реляционно-объектного преобразования
title_full	О технике реляционно-объектного преобразования
title_fullStr	О технике реляционно-объектного преобразования
title_full_unstemmed	О технике реляционно-объектного преобразования
title_sort	о технике реляционно-объектного преобразования
publisher	Інститут програмних систем НАН України
publishDate	2014
topic_facet	Інструментальні засоби і середовища програмування
url	http://dspace.nbuv.gov.ua/handle/123456789/86739
citation_txt	О технике реляционно-объектного преобразования / И.А. Лихацкий // Проблеми програмування. — 2014. — № 1. — С. 49-54. — Бібліогр.: 16 назв. — рос.
series	Проблеми програмування
work_keys_str_mv	AT lihackijia otehnikerelâcionnoobʺektnogopreobrazovaniâ
first_indexed	2025-07-06T14:16:40Z
last_indexed	2025-07-06T14:16:40Z
_version_	1836907392302841856
fulltext	Інструментальні засоби і середовища програмування © И.А. Лихацкий, 2014 ISSN 1727-4907. Проблеми програмування. 2014. № 1 49 УДК 51:681.3 И.А. Лихацкий О ТЕХНИКЕ РЕЛЯЦИОННО-ОБЪЕКТНОГО ПРЕОБРАЗОВАНИЯ Данная статья посвящена методам отображения прикладных реляционных данных в объектную модель. В ней проводится анализ существующих решений, основанных на методике объектно-реляционного преобразования, а также выделения основных недостатков в использовании данной техники. Предло- жена техника реляционно-объектного преобразования, главная цель – это достижения высокой произ- водительности и достаточного уровня автоматизации генерируемого кода, при взаимодействии с базой данных. В качестве примера реализации методики реляционно-объектного преобразования описана си- стема кодогенерации C-Gen предложенная автором. Приведена краткая характеристика и основные возможности данной системы. Введение В условиях бурного развития ин- формационных технологий и стремитель- ной эволюции систем управления данными одной из актуальных задач, возникающей перед разработчиками приложений, явля- ется выбор системы управления базой данных (СУБД), в соответствии с особен- ностями решаемых прикладных задач хра- нения данных и эффективного управления ими. С одной стороны, СУБД должна под- держивать необходимую степень абстрак- ции данных, а с другой – она должна быть ориентирована на структурные особенно- сти их организации и характер использо- вания. В настоящее время широкое рас- пространение получила объектно-ориенти- рованная методология разработки при- кладных систем, а в мире хранения данных доминируют реляционные СУБД. Учиты- вая целесообразное решение, оказывается использование промежуточного слоя про- граммного обеспечения, предоставляюще- го необходимые объектно-ориентиро- ванные интерфейсы для доступа и управ- ления данными, хранимые под управлени- ем реляционной СУБД [1, 2]. Актуаль- ность использования такого подхода соче- тается с известными преимуществами ре- ляционных СУБД, таких как:  возможность поддержки насле- дуемых (legacy) систем, использующих традиционные решения;  простота использования техноло- гии, основанной на понятной табличной модели и математически строгой теории реляционной алгебры;  широкое распространение и тща- тельная многолетняя апробация предлага- емых на рынке продуктов СУБД;  предоставления естественных для приложений объектно-ориентиро- ванных интерфейсов реализованных для популярных языков программирования. Существенно, что значительная часть функций по реализации указанных свойств ложится на промежуточный слой, а его создание сопряжено с комплексом проектных решений, затрагивающих со- провождаемость, производительность, простоту применения между клиентским приложением и сервером. Сокрытие базы данных С появлением на свет реляционных баз данных программистам стал доступен структурированный язык запросов SQL для доступа к данным, тем самым избавив их от необходимости знания ненужных деталей организации физического хране- ния данных. Наряду с этим оказалось, что большинство форматов данных, можно легко описать в виде таблиц и связей меж- ду ними, а наличие строгой математиче- ской теории, которая легла в основу тех- нологии сложно переоценить. Таким обра- зом, эти два фактора предопределили успех реляционных баз данных. Реляционная и объектная модели ортогональны. Это значит, что они моде- Інструментальні засоби і середовища програмування 50 лируют одну и ту же сущность, но с раз- ных сторон: реляционная модель акценти- рует свое внимание на структуре и связях сущностей, объектная на их свойствах и поведении. Реляционная модель использу- ется для информационного моделирова- ния, выделения существенных для нас ат- рибутов, сохранения их значений и после- дующего поиска, обработки и анализа. Объектная модель, в большей степени, ис- пользуется для моделирования поведения, выделения существенных для нас функций и последующего их использования [3]. На практике сложилась ситуация, когда ин- формационные системы разрабатываются в основном с использованием ООП, тогда как данные хранятся в реляционном виде. Таким образом, существует необходи- мость в отображении объектов на реляци- онные структуры и наоборот. Данные ме- тоды активно развиваются в конце вось- мидесятых годов и отражены в многочис- ленных публикациях [4–8]. Компонент программной системы, отвечающий за преобразования данных из объектного в реляционный вид, назы- вается объектно-реляционным проекто- ром (ORM). В технологии отображения объек- тов на РСУБД существует очень важный момент, от понимания которого зависит успех разработки того или иного приложе- ния. Бытует мнение о том, что для слоя сохраняемости (Persistence Layer), который генерируется по средствам ORM, генери- руемый SQL код является аналогом транс- ляции языка высокого уровня в машинный код. Данное утверждение является оши- бочным, а также может привести к созда- нию трудно-сопровождаемых систем, с потенциальными проблемами производи- тельности. Дело в том, что SQL – это высоко- уровневый декларативный специализиро- ванный язык четвертого поколения, в от- личие от Java и C#, относящихся к третье- му поколению императивных языков. Так, один оператор SQL, выполняющий нечто посложнее нежели выборка по ключу, по- требует для достижения того же результа- та на порядок больше строк на языке C# или Java [9]. Такая ситуация приводит разра- ботчиков ORM к необходимости создавать собственный SQL-подобный язык для манипулирования объектами и уже его транслировать в SQL. К числу таких язы- ков можно отнести HQL – Hibernate Query Language – SQL-подобный язык запро- сов, используемый в Hibernate/NHibernate [10], а также компонент .Net Framework – LINQ to SQL, предоставляющий инфра- структуру времени выполнения для управ- ления реляционными данными как объек- тами [11]. Также существует возможность использования динамического преобразо- вания результата SQL запроса в коллек- цию объектов. В противном случае пришлось бы извлекать большие массивы данных из ба- зы данных и впоследствии обрабатывать их непосредственно в своем приложении. Примерно так же обрабатывались данные при отсутствии встроенного SQL языка. Такой подход называется навигационным подходом к манипулированию данными, а также является типичным для сетевых и иерархических СУБД [12]. Тем не менее, получив в распоряжение ORM, мы в ка- кой-то мере возвращаемся к навигацион- ным подходам обработки данных. Таким образом, сложилась тен- денция, в которой разработчики пытают- ся скрыть недостаток знаний РСУБД за дополнительным уровнем абстракций. Не смотря на предоставляемый ORM уро- вень абстракции, и сокращении времени разработки, заставить приложение эф- фективно работать с РСУБД, таким спо- собом, без знания основ SQL практиче- ски невозможно. Недостатки ORM Используя ORM в качестве инстру- мента для обеспечения взаимодействия приложения с сервером баз данных, разра- ботчики зачастую сталкиваются со следу- ющими проблемами. Как только разработчики реализо- вывают CRUD-логику, использовать SQL напрямую становится затруднительно. Это касается стратегий отображения данных и проблем переносимости приложения меж- ду СУБД. По сути, каждый запрос SQL к Інструментальні засоби і середовища програмування 51 СУБД является некой проекцией результа- та выборки на конкретный класс. Учиты- вая это этим разработчикам зачастую при- ходится использовать язык запросов ORM (если он есть). Зачастую такие языки не стандартны и не обладают средствами для отладки и профилирования. Например, в .NET начиная с версии 3.5, есть возмож- ность использовать LINQ, который позво- ляет обнаружить некоторые ошибки на уровне компиляции. В результате оказывается, что язык запросов ORM генерирует далеко не са- мый оптимальный SQL код. Чтобы решить данные проблемы, разработчики зачастую прибегают к частичной обработки данных внутри приложения: выбирают коллекции объектов и в циклах фильтруют или, ис- пользуя тот же LINQ над обрабатываемым массивом, порождая новые запросы. Коли- чество таких запросов к СУБД при такой обработке может исчисляться тысячами. Техника реляционно-объектное представление как альтернатива ORM Исходя из поставленных задач, бы- ла предложена концепция, основанная на построении высокопроизводительной, оп- тимальной структуры базы данных, кото- рая описывает модель разрабатываемой информационной системы. Предоставляя разработчику полный доступ к управле- нию базой данных (построению индексов, написанию сложных SQL запросов, ис- пользованию представлений), мы решаем один из важнейших вопросов, связанных с производительностью. Таким образом, ис- пользование высокоуровневого деклара- тивного специализированного языка SQL, позволит оптимизировать процесс выбор- ки данных и производительность системы в целом, по сравнению с обработкой больших массивов данных в приложении, отчасти возвращаясь к навигационным подходам обработки данных. Естественно, что производительность системы будет зависеть от квалификации специалиста, отвечающего за проектирования структу- ры БД и написания запросов, но с другой стороны мы получаем полный контроль над этим процессом. Исходя из вышесказанного, можно заключить, что для разработки высокопро- изводительного приложения, без знания SQL не обойтись, а реализация сложных структур, таких как нетривиальные SQL запросы, или построение правильных ин- дексов, плохо поддается автоматизации. Однако существует один процесс, который все же может быть автоматизиро- ванным, это процесс написания CRUD хранимых процедур. Генерация CRUD хранимых процедур осуществляется авто- матически для каждого объекта БД (таб- лицы, представления). Особенность данно- го типа хранимых процедур заключается в том, что они имеют четкую структуру, а процесс их генерации может быть легко автоматизирован [13]. В качестве установления соответ- ствия между реляционной и объектной моделями используется методика «трех проекций» [12]. Данная методика описы- вает правила, по которым осуществляет- ся преобразование из реляционной в объ- ектно-ориентированную модель данных. Четкое выделение реляционных объек- тов, а также присущих им свойств, поз- воляет однозначно представить их в объ- ектном виде. Таким образом, процесс генерации кода уровня доступа к данным, является полностью автоматизированным. Разра- ботчик получает полный набор средств API для доступа и управления данными, хранимыми под управлением реляционной СУБД. Система кодогенерации С-Gen Изложенная концепция реляцион- но-объектного представления была реали- зована в системе кодогенерации C-Gen. В данном разделе мы представим основные характеристики данной системы. Система C-Gen генерирует проме- жуточный уровень (уровень сохраяемо- сти), приложения используют в качестве входных параметров структуру базы дан- ных. Входные данные включат в себя набор таблиц, представлений, хранимых процедур, которые описывают объекты предметной области, таким образом, они Інструментальні засоби і середовища програмування 52 могут быть использованы для создания бизнес логики приложения. Система явля- ется однонаправленной, т. е. генерация программного кода происходит только на основе структуры базы данных. В качестве инструмента для кодо- генерации используются шаблоны T4 [14]. Текстовый шаблон T4 представляет собой сочетание блоков текста и логики управ- ления, которое может создать текстовый файл. Логика управления представляет со- бой фрагменты программного кода в Visual C# или Visual Basic. Созданный файл может представлять собой текст лю- бого вида, например, Web-страницу, файл ресурсов или исходный программный код на любом языке. В случае с нашей системой исполь- зуются текстовые шаблоны T4 времени разработки [14], позволяющие создавать программный код и другие файлы. Как правило, шаблоны создаются для того, чтобы менять код, генерируемый на осно- ве данных из модели. Модель – это файл или база данных, которая содержит клю- чевые сведения о требованиях используе- мого приложения. В нашем случае в каче- стве модели используются метаданные, полученные из базы данных, которая по- ступает на вход нашей системы. Процесс генерации кода Процесс генерации начинается с проектирования базы данных. Выше мы подробно описали причины, по которым была выбрана именно концепция, в кото- рой за основу берется спроектированная разработчиком база данных. Когда подготовительные работы завершены и база данных спроектирова- на, мы можем, использовать систему ко- догенерации C-Gen для генерации уровня сохраняемости. Процесс кодогенерации подразумевает создание CRUD хранимых процедур на сервере баз данных, а также объектов и методов в программном коде. Для достижения высокой производитель- ности сервера баз данных, наряду с до- статочным уровнем автоматизации ре- шено поддерживать два вида хранимых процедур.  «Простые хранимые процеду- ры». Структура таких процедур одинако- ва для каждой сущности базы данных. К таким хранимым процедурам отно- сятся CRUD хранимые процедуры. Такие процедуры можно сгенерировать автома- тически.  «Пользовательские хранимые процедуры». Отображают нетривиальные выборки данных, специфические для кон- кретной ситуации, где важна производи- тельность. Разработка таких хранимых процедур полностью контролируется про- граммистом. Таким образом, автоматизация написания CRUD хранимых процедур в сочетании, с одной стороны, с ручным написанием сложных запросов и контроль над базой данных в целом, с другой стороны, позволяет достигнуть высокой производительности и достаточного уро- вня автоматизации при работе с базой данных. Следующим шагом после генера- ции хранимых процедур является созда- ние непосредственно уровня сохраняемо- сти, который является агентом между базой данных и приложением. Для каж- дого объекта в базе данных система C- Gen генерирует соответствующий класс. Для каждой хранимой процедуры гене- рируется метод, с помощь которого осу- ществляется взаимодействие. Параметры и тип возвращаемого значения сгенери- рованного метода зависит от сигнатуры хранимой процедуры. Также стоит обра- тить внимание на тот факт, что код, гене- рируемый C-Gen, инкапсулирует в себе все необходимые свойства и методы, для осуществления взаимодействия с базой данных. После того, как система C-Gen за- вершит процесс генерации, разработчик получает API для работы с базой данных. Логика взаимодействия приложения с ба- зой данных полностью скрыта за сгенери- рованными объектами. После внесения изменений в структуру базы данных, про- цесс генерации необходимо повторить, чтобы внести изменения в API. Інструментальні засоби і середовища програмування 53 Оценка эффективности Чтобы оценить преимущества на- шего подхода, мы сравнили производи- тельность кода генерируемого системой кодогенирации C-Gen, с производитель- ностью кода генерируемого системами NetTiers [15] и Entity Framework 4.0 со- ответственно. За основу была взята база данных небольшого интернет-магазина размером 18 mb. Затем мы измерили производительность на операциях выборки и вставить на различных объемах данных. Измерения проводились на сервере с про- цессором Core i5-2500K 3,3 ГГц, 8 Гб опе- ративной памяти, работающий под управ- лением Windows 7 x64 SP1 и Microsoft SQL Server 2008 R2 x64 Express. Результа- ты представлены на рисунке. Рисунок. Сравнение производительности системы кодогенерации C-Gen c NetTiers и Entity Framework 4.0 На графике видно, что C-Gen гене- рирует более эффективный код. На опера- циях выборки это примерно в 3 раза быст- рее по сравнению с NetTiers и примерно в 5 раз по сравнению с Entity Framework. На операциях вставки – 1,66 раза быстрее, по сравнению с NetTiers и около 3,4 раза по сравнению с Entity Framework. Выводы В данной работе определена акту- альность использования систем обеспечи- вающих взаимодействие между реляцион- ным и объектным представлением данных. Рассмотрен один из наиболее распростра- ненных подходов реализации такого взаи- модействия: использование ORM систем. Также проанализированы преимущества и недостатки использования систем подоб- ного рода, на основе чего поставлены за- дачи, нахождения эффективного способа преобразования данных из объектного представления в реляционное и наоборот. Исходя из этого, предложена мето- дика реляционно-объектного представле- ния, которая базируется на принципах по- строения информационных систем на ос- нове модели в базе данных. Данная мето- дика реляционно-объектного отображения решает две критические проблемы, харак- терные для систем подобного рода:  производительность. Оптималь- ные запросы, написанные SQL разра- ботчиком, оказываются на много более эффективными чем генерируемый ORM SQL код;  автоматизация. Алгоритм гене- рации программного кода, основанный на методике «трех проекций» позволяет установить соответствие между объект- ным и реляционным представлением дан- ных, а также предоставить разработчику API для доступа к данным. Данная методика, положена в осно- ву системы кодогенерации C-Gen [13]. Принципы построения, а также результаты сравнения производительности данной си- стемы детально описаны в [12, 13, 16]. Одной из сфер применения данной методики может стать сфера поддержки и модернизации наследуемых (legacy) си- стем. Например, трудно найти корпорацию Інструментальні засоби і середовища програмування 54 с возрастом больше 25 лет, в которой не использовались бы информационные под- системы, созданные на основе ранних ап- паратно-программных платформ компании IBM. Базы данных таких подсистем со- держат громадные объемы ценной инфор- мации и корпорация просто не может обойтись без их использования. С другой стороны, данный подход может быть использован системами, для которых критично время выполнения приложения, либо есть ограничение в аппаратных ресурсах используемых системой. Например, неоптимальные SQL запросы, или дополнительная обработка данных в приложении может привести к увеличению потребляемых ресурсов, не- обходимых для обслуживания информаци- онной системы. Для небольших систем этот факт может показаться незначитель- ным, но когда дело доходит до промыш- ленных масштабов, а принцип облачного хостинга строится на тарификации процес- сорного времени и расходуемой опера- тивной памяти, экономия может оказаться существенной. 1. Keller W. Object/Relational Access Layers — A Roadmap, Missing Links and More Pat- terns // Proceedings of the 3rd European Con- ference on Pattern Languages of Program- ming and Computing (EuroPLoP). – 1998, http://www.objectarchitects.de/ObjectArchite cts/papers/Published/ZippedPapers/or06_proc eedings.pdf. 2. Иванников В.П., Гайсарян С.С., Антипин К.В., Рубанов В.В. Объектно-ориенти- рованное окружение, обеспечивающее доступ к реляционным СУБД // Труды Института системного программирования РАН. – 2001. – Том 2. – C. 89–114. 3. Обзор средств объектно-реляционной про- екции (ORM) для платформы .NET http://arbinada.com/main/node/33 4. Eggers J. Implementing EXPRESS in SQL. Document ISO TC184/SC4/WG1/N292, Oc- tober 1988. 5. Mead M., Thomas D. Proposed Mapping from EXPRESS to SQL. Technical Report, Ruther- ford Appleton Laboratory, May 1989. 6. Morris K.C. Translating EXPRESS to SQL: A User's Guide. Technical Report NISTIR 4341, National Institute of Standards and Technolo- gy, Gaithersburg, Maryland, May 1990. 7. Sanderson D., Spooner D. Mapping between EXPRESS and Traditional DBMS Models // Proceedings of EUG‘93 – The Third EXPRESS Users Group Conference, Berlin, October 2–3, 1993. 8. Klein L., Stonis A., Jancauskas D. EXPRESS/SQL white paper. Document ISO TC184/SC4/WG11/N144, February 2001. 9. ORM или объектно-реляционный проектор http://habrahabr.ru/company/piter/blog/16532 7/ 10. HQL examples http://docs.jboss.org/hiber- nate/orm/3.3/reference/en/html/queryhql.html #queryhql-examples 11. LINQ to SQL [LINQ to SQL] http://msdn.- msdn.microsoft.com/ru/library- library /bb386976.aspx 12. Лихацкий И.А. Об одной методике фор- мирования объектного представления ре- ляционных данных // Проблеми програ- мування. – 2013. – № 3. – С. 79–85. 13. Лихацкий И.А. Средства кодогенерации для взаимодействия с базой данных че- рез объекты // Проблеми програмування. – 2012. – № 2–3. – С. 384–385. 14. Создание кода и текстовые шаблоны T4 http://msdn.microsoft.com/ru- ru/library/bb126445.aspx. 15. .netTiers Application Framework – http://nettiers.com/ 16. Igor Lihatsky, Anatoliy Doroshenko, Kosti- antyn Zhereb. A Template-Based Method to Create Efficient and Customizable Object- Relational Transformation Components // In- formation Systems: Methods, Models, and Applications. 4th International United Infor- mation System Conference UNISCON 2012, Yalta, Ukraine, June 2012. Revised Selected Papers. Получено 13.08.2013 Об авторе: Лихацкий Игорь Александрович, младший научный сотрудник Института программных систем НАН Украины. Место работы автора: Институт программных систем НАН Украины, 03680, Киев-187, проспект Академика Глушкова, 40. Тел.: +38(095)361 0330. E-mail: igor_md@ukr.net http://arbinada.com/main/node/33 http://habrahabr.ru/company/piter/blog/165327/ http://habrahabr.ru/company/piter/blog/165327/ http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/queryhql.html#queryhql-examples http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/queryhql.html#queryhql-examples http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/queryhql.html#queryhql-examples http://msdn.microsoft.com/ru-ru/library/bb126445.aspx http://msdn.microsoft.com/ru-ru/library/bb126445.aspx

О технике реляционно-объектного преобразования

Institution

Ähnliche Einträge