Сравнительна характеристика методик объектно-реляцонного преобразования

Описана методика создания объектно-реляционного преобразования с помощью системы C-Gen кодогенерации для автоматического создания уровня сохраняемости основанного на структуре базы данных. Использование текстовых шаблонов времени выполнения позволяет сгенерировать SQL код и API уровня сохраняемости....

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2014
Автор:	Лихацкий, И.А.
Формат:	Стаття
Мова:	Russian
Опубліковано:	Інститут програмних систем НАН України 2014
Назва видання:	Проблеми програмування
Теми:	Моделі і засоби систем баз даних і знань
Онлайн доступ:	http://dspace.nbuv.gov.ua/handle/123456789/113229
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Сравнительна характеристика методик объектно-реляцонного преобразования / И.А. Лихацкий // Проблеми програмування. — 2014. — № 2-3. — С. 174-181. — Бібліогр.: 12 назв. — рос.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-113229
record_format	dspace
spelling	irk-123456789-1132292017-02-05T03:03:46Z Сравнительна характеристика методик объектно-реляцонного преобразования Лихацкий, И.А. Моделі і засоби систем баз даних і знань Описана методика создания объектно-реляционного преобразования с помощью системы C-Gen кодогенерации для автоматического создания уровня сохраняемости основанного на структуре базы данных. Использование текстовых шаблонов времени выполнения позволяет сгенерировать SQL код и API уровня сохраняемости. Проведена сравнительная характеристика системы кодогенерации C-Gen и Entity Framework, а также показана высокая эффективность предложенного подхода. We describe a method to create object-relational transformation components by using code generation system to automatically generate persistence layer based on the database structure. Text template engine is used to generate SQL queries, business classes and APIs to access data from application code. There was done a comparison of the C-Gen system and Entity Framework and demonstrated high efficiency of proposed approach. 2014 Article Сравнительна характеристика методик объектно-реляцонного преобразования / И.А. Лихацкий // Проблеми програмування. — 2014. — № 2-3. — С. 174-181. — Бібліогр.: 12 назв. — рос. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/113229 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 кодогенерации для автоматического создания уровня сохраняемости основанного на структуре базы данных. Использование текстовых шаблонов времени выполнения позволяет сгенерировать SQL код и API уровня сохраняемости. Проведена сравнительная характеристика системы кодогенерации C-Gen и Entity Framework, а также показана высокая эффективность предложенного подхода.
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/113229
citation_txt	Сравнительна характеристика методик объектно-реляцонного преобразования / И.А. Лихацкий // Проблеми програмування. — 2014. — № 2-3. — С. 174-181. — Бібліогр.: 12 назв. — рос.
series	Проблеми програмування
work_keys_str_mv	AT lihackijia sravnitelʹnaharakteristikametodikobʺektnorelâconnogopreobrazovaniâ
first_indexed	2025-07-08T05:24:27Z
last_indexed	2025-07-08T05:24:27Z
_version_	1837055102840471552
fulltext	Моделі і засоби систем баз даних і знань © И.А. Лихацкий, 2014 174 ISSN 1727-4907. Проблеми програмування. 2014. № 2–3. Спеціальний випуск УДК 681.3 СРАВНИТЕЛЬНА ХАРАКТЕРИСТИКА МЕТОДИК ОБЪЕКТНО-РЕЛЯЦОННОГО ПРЕОБРАЗОВАНИЯ И.А. Лихацкий Институт программных систем НАН Украины 03680, Киев, проспект Академика Глушкова,40, корп. 5. E-mail: igor_md@ukr.net Описана методика создания объектно-реляционного преобразования с помощью системы C-Gen кодогенерации для автоматическо- го создания уровня сохраняемости основанного на структуре базы данных. Использование текстовых шаблонов времени выполне- ния позволяет сгенерировать SQL код и API уровня сохраняемости. Проведена сравнительная характеристика системы кодогенера- ции C-Gen и Entity Framework, а также показана высокая эффективность предложенного подхода. We describe a method to create object-relational transformation components by using code generation system to automatically generate per- sistence layer based on the database structure. Text template engine is used to generate SQL queries, business classes and APIs to access data from application code. There was done a comparison of the C-Gen system and Entity Framework and demonstrated high efficiency of pro- posed approach. Введение В настоящее время большинство бизнес-приложений создаются с помощью объектно-ориентированных языков программирования, таких как Java, C#, C++, а хранения данных осуществляется в реляционных базах данных, таких как Oracle, Microsoft SQL Server или MySQL. Как объектно-ориентированная так и реляционная парадигмы предоставляют надежный фундамент для решения прикладных задач. Они поддерживаются много- численными инструментами и методологиями, которые позволяют упростить разработку и улучшить качество программного кода. Тем не менее, модели данных для отображения объектно-ориентированных и реляционных систем суще- ственно различаются. Поэтому разработчики сталкиваются с необходимостью преобразования данных из объ- ектно-ориентированной формы в реляционную. Иногда такое преобразование осуществляется вручную, и в этом случае можно получить более эффективный программный код. Для реализации данного подхода разра- ботчики должны выполнить весьма значительную часть рутинной работы, вручную осуществляя маппинг каж- дого объекта базы данных в их объектное представление. В другом случае использование автоматизированных инструментов (например, ORM систем [1]) может в значительной степени повысить производительность труда разработчиков, но зачастую это происходит в ущерб производительности приложения. Существует необходи- мость в нахождения такого решения, которое сочетало бы в себе производительность подхода ручного кодиро- вания и автоматизацию присущую ORM системам. Актуальность нахождения такого решения сочетается с известными преимуществами реляционных баз данных, таких как:  возможность поддержки наследуемых (legacy) систем, использующих традиционные решения;  простота использования технологии, основанной на понятной табличной модели и математически строгой теории реляционной алгебры;  широкое распространение и тщательная многолетняя апробация предлагаемых на рынке продуктов СУБД;  предоставление естественных для приложения объектно-ориентированных интерфейсов реализованных для популярных языков программирования. В данной статье мы рассмотрим предложенный подход формирования объектного представления реля- ционных данных, целью которой является достижение высокого уровня производительности и значительного уровня автоматизации. В качестве решения данной проблемы предлагается создать объектную форму представ- ления реляционной СУБД, объекты которой отражают сущности предметной области и однозначно связаны с таблицами, представлениями и хранимыми процедурами СУБД. Для автоматизации процесса генерации про- граммного кода использовать текстовые шаблоны T4 времени выполнения [2], которые могут быть использова- ны как для генерации SQL кода, так и объектно-ориентированных интерфейсов для доступа и управления хра- нимыми данными. Существенно, что значительная часть функций по реализации указанных свойств ложится на промежуточный слой (persistent layer), а его создание сопряжено с комплексом проектных решений затрагива- ющих сопровождаемость, производительность, простоту применения клиентским приложением. Объектно-ориентированная и реляционные парадигмы Согласно парадигме объектно-ориентированного программирования, приложения обрабатывают данные которые представлены в памяти в виде графа объектов (коллекции взаимосвязанных объектов). Каждый объект имеет свойства которые могут быть представлены в виде атомарных типов данных либо в виде ссылок на дру- Моделі і засоби систем баз даних і знань 175 гие объекты. Однако объектно-ориентированная парадигма, по умолчанию, не представляет средств для сохра- нения состояния объектного графа в файле или базе данных [3]. В качестве решения проблемы можно использовать реляционные базы данных для сохранения состояния объектной модели. В месте с тем, реляционные базы данных используют другой подход к организации и хране- нию данных. Сущности сохраняются в виде набора таблиц и связей между ними. Простые свойства хранятся в виде полей таблицы, в то время как ссылки хранятся в виде отдельных таблиц связанных между собой реляци- онным отношением. Таблицы могут быть связаны отношениями один-к-одному, один-ко-многим, многие-ко- многим. Поэтому один объект в ООП может быть представлен набором связанных таблиц в реляционном виде. Нарду с этим, в реляционных базах данных не поддерживается основные принципы ООП, такие как инкапсуля- ция, наследование, полиморфизм. Уникальность записей в таблице определяется на основе первичного ключа, в то время как уникальность объекта определяется областью памяти в которой он хранится. Объектная и реляционные модели значительно отличаются по своей структуре. Это несоответствие называется несоответствием парадигмы (paradigm mismatch [4]), таким образом существует необходимость в компонентах которые осуществляли бы преобразование данных из объектного вида в реляционный и наоборот. Одним из подходов решения проблемы несоответствия объектной и реляционной модели данных являет- ся использование подхода ручного кодирования уровня сохраняемости. В данном случае разработчик должен вручную реализовать методы загрузки/выгрузки данных использую запросы SQL, а также низкоуровневые интерфейсы API для доступа к базе данных (например, ADO. NET для Microsoft. NET или JDBC для Java). Пре- имущества данного подхода включают возможность достижения высокой производительности (по сравнению с ORM системами) за счет реализации оптимального кода удовлетворяющего требованиям разрабатываемого приложения, а также полный контроль над процессом загрузки/выгрузки данных и возможность использования расширенных возможностей конкретной СУБД. Основным недостатком данного подхода является большое количество рутинной и подверженной ошибкам ручной работы, как на этапе разработки, так и во время сопро- вождения информационной системы. Другой подход заключается в использовании систем объектно-реляционного отображения (ORM систем) которые автоматически осуществляют преобразование объектного представления данных в реляционное и наоборот, используя формальное описание отображений [5]. Такое отображение может быть автоматически создано как из существующей базы данных, так и на основе объектной модели данных. Кроме того, отображе- ние может быть описано вручную, использую язык XML подобный язык для описания конфигурация отобра- жения. Популярные ORM решения включают Hibernate для Java [5], и NHibernate и Entity Framework [6] для. NET. Преимущества ORM решений заключается в значительном сокращение ручной работы связанной с напи- санием программного кода для доступа к базе данных, а также маппинга реляционных объектов и методов в объектный вид. Наряду с этим ORM решения поддерживают элементы динамического конструирования SQL запросов, что позволяет абстрагироваться от поставщика баз данных (т. е. использовать любой, который под- держивается конкретной ORM системой). Основным недостатком данных систем, является накладные расходы связанные с производительностью. Алгоритмы построения динамических SQL запросов, часто не являются оптимальными. Чтобы решить данные проблемы, разработчики зачастую прибегают к частичной обработки данных внутри приложения: выбирают коллекции объектов и в циклах фильтруют или, используя тот же LINQ над обрабатываемым массивом, порождая новые запросы. Количество таких запросов к СУБД при такой обра- ботке может исчисляться тысячами. Также к недостаткам ORM систем можно отнести и ограничения, накладываемые ими на разработку про- граммного кода, такие как:  наследование от базового класса, предоставляемого ORM системой;  реализация интерфейсов предоставляемых ORM системой;  ограничение на типы коллекций и ассоциаций. Техника реляционно-объектного преобразования В этом разделе мы опишем технику представление реляционно-объектного преобразования, которая мо- жет быть использована для решения проблемы преобразования данных из реляционного в объектно- ориентированный вид и наоборот. Основной задачей реляционно-объектного преобразования является достижение максимальной произво- дительности при взаимодействии приложения с сервером баз данных, а также достижения высокого уровня автоматизации, путем генерации программного кода. Основной принцип реляционно-объектного проектирования заключается в построении информационных систем на основе модели, описанной и спроектированной на сервере баз данных. Была предложена концепция основанная на построении высокопроизводительной структуры базы данных которая отображает разработан- ную модель информационной системы. Предоставляя разработчику полный контроль и управление базой дан- ных (построение индексов, написание нетривиальных хранимых процедур, использование представлений и т. д.), мы решаем один из важнейших вопросов связанным с производительностью. Наряду с этим, использование высокоуровневого декларативного специализированного языка SQL, относящегося к четвертому поколению языков программирования (в отличии от C# и Java, относящихся к третьему поколению императивных языков Моделі і засоби систем баз даних і знань 176 программирования), позволит оптимизировать процесс обработки данных, и производительность системы в целом, по сравнению с обработкой больших массивов данных внутри приложения. В процессе проектирования и построения структуры базы данных можно автоматизировать процесс со- здания так называемых, CRUD хранимых процедур. Структура построения CRUD хранимых процедур имеет строгую типизацию, и отлично укладывается в процесс автоматизации, без риска потери производительности. Для установления соответствия между реляционной и объектной моделями данных будет использована методология "трех проекций" [7]. Эта методология описывает правила преобразования реляционных объектов в объектную форму и наоборот. Четкое определение реляционных объектов и их свойств позволяет представить их в объектно-ориентированном виде. Данный процесс автоматизируется с помощью использования текстовых шаблонов времени выполнения, таким образом, что процесс генерации программного кода происходит автома- тически, на основе спроектированной структуры базы данных. Таким образом процесс генерации кода уровня сохраняемости приложения полностью автоматизирован. На выходе, разработчик получает набор методов и свойств для взаимодействия клиентского приложения с сер- вером баз данных. Реализация данной методики положена в основу системы кодогенерации С-Gen [8]. Сравнительная характеристика ORM и С-Gen В данном разделе на примере модели хранения пользовательских сообщений мы разберем две реализа- ции, первую с использование Entity Framework 5 Code First [9, 10] и вторую с использование системы кодогене- рации С-Gen. Модель данных. В качестве примера будет использована упрощенная модель хранения пользователь- ских почтовых сообщений (рис. 1). Структура организации и хранения данных следующая:  Каждый пользователь может иметь несколько папок с письмами;  В каждой папке может храниться несколько цепочке писем, при этом одна цепочка может храниться в нескольких папках одновременно;  Каждая цепочка может состоять из нескольких писем;  Каждая цепочка может быть доступной любому пользователю, в то время как письма – нет. Рис. 1. Диаграмма базы данных по хранению пользовательских почтовых сообщений Entity Framework Создание модели данных. В случае уже имеющейся базы данных Entity Framework может автоматиче- ски создать модель данных, состоящую из классов и свойств, соответствующих объектам базы данных (таким, как таблицы и столбцы) (рис. 2). Информация о структуре базы, модель данных и маппинг их друг на друга содержится в XML в файле .edmx. Вне зависимости от наличия базы вы можете вручную написать код классов и свойств, соответствующих сущностям в базе и использовать этот код с Entity Framework без использования файла .edmx. Маппинг между объектами базы данных и моделью данных приложения осуществляется на основе соглашений с помощью спе- циального API. Если базы ещё нет, Entity Framework может создать, удалить или пересоздать её в случае изме- нений в модели. Моделі і засоби систем баз даних і знань 177 Рис. 2. Подходы к работе с данными в Entity Framework API доступа к данным, разработанное для Code First, основано на классе DbContext [11]. API может быть использован также и в процессе разработки с подходами Database First и Model First. Выборка данных. Основной операцией в любой информационной систем является операция выборки данных. В Entity Framework все загруженные объекты попадают во внутренний кэш контекста, затем могут быть запрошены из него напрямую (через метод Find). В приведенном примере (рис. 3) метод AsNoTracking отключает кэширование в Entity Framework за по- лучаемых объектов; метод Include – задает связанные объекты, включаемые в результаты запроса, через гене- рацию SQL конструкций в виде INNER JOIN; все остальное – обычный LINQ запрос. Рис. 3. Запрос на чтения данных в Entity Framework В Entity Framework любой запрос кроме метода Find обращается к базе данных. Метод Find выполняет запрос к базе данных лишь в том случае, если объект с необходимыми ключевыми полями не был найден в локальном кэше контекста. Таким образом, из двух вызовов context.Message.Find(1) в одном контексте, лишь первый вызов выполнит запрос к БД, тогда как второй уже получит данные из кэша. То же самое справедливо и для загрузки связанных сущностей. Например, в приведенном ниже коде (рис. 4) владелец сообщения будет получен из кэша. Рис. 4. Получение данных из кэша в Entity Framework Таким образом, выполнение конструкции context.Message.Include(f=>f.Owner).First() для того, чтобы предотвратить ленивую загрузку, лишь снизит производительность. Таким образом, использование метода Include неизбежно обрекает разработчиков постоянно следить за тем, какой SQL генерирует Entity Framework, так как иначе это может серьезно повлиять на производительность приложения. Добавление данных. Добавление данных реализовано довольно просто. Любой объект, добавленный через метод Add, просто добавляется во внутренний кэш контекста со статусом Added. При последующем вызо- ве метода SubmitChanges проходит проверка данных на соответствие, и для всех подобных сущностей генери- руются SQL запрос INSERT которые осуществляет добавление объектов в базу данных.Важно, что все связан- Моделі і засоби систем баз даних і знань 178 ные свойства навигации, которые не были явно добавлены в контекст, так же принимаются как Added и добав- ляются в базу данных, что может послужить источником трудно отлавливаемых ошибок. Модификация и удаление данных. При модификации и удаление данных, одной из главных проблем в Entity Framework является отсутствие поддержки Bulk-операций [12]. То есть, то что в SQL можно легко выра- зить через один запрос, Entity Framework вам понадобиться сделать n запросов, где n – количество записей ко- торые должны быть изменены. Предположим, что в нашем примере необходимо пометить все сообщения в цепочке как прочитанные. В Entity Framework данный запрос будет выглядеть следующим образом (рис. 5): Рис. 5. Обновление данных в Entity Framework В результате выполнения мы получим:  будет выполнена загрузка всех модифицируемых записей в контекст, а затем генерация для каждой из них отдельного;  большое количество сущностей в памяти, повлечет за собой накладные расходы по освобождению этой памяти, а большое количество запросов создаст дополнительную нагрузку на сервер БД;  кроме того, существуют некоторые проблемы с проверкой данных на соответствие (валидацией), ко- торые будут описаны далее. Операция удаления данных аналогична по своей структуре обновлению и имеет те же проблемы с произ- водительностью. Коллекции как свойства навигации. Рассмотрим следующий пример: Предположим, что у нас есть некий список папок сообщений. Возле имени каждой папки необходимо отображать количество цепочек нахо- дящихся в данной папке. Для реализации этой функциональности зачастую используется следующий запрос (рис. 6): Рис. 6. Обход коллекции в Entity Framework Особенность Entity Framework (а также и LinqToSql) заключается в том, что, при вызову метода Count(), или Any(), либо выполнения запроса на коллекции используемой в качестве навигационного свойства, происхо- дит к полной загрузке коллекции в память. Атрибут Required. В Entity Framework атрибут Required указывает на то, что поле в базе данных не мо- жет быть равно NULL. В нашем примере в объекте Message такие свойства как Owner, Sender, Receiver и Thread помечены как Required. Помимо того, что это указывает Entity Framework на то, что поля должны быть помече- ны как NOT NULL, включает на них внутреннюю проверку Entity Framework. Рассмотрим следующий пример, который устанавливает статус сообщения как прочтенное (рис. 7). Рис. 7. Особенности работы с контекстом Entity Framework. Выполнение данного запроса при включенной валидации на только что созданном контексте приведет к появлению исключения. Required атрибут генерирует ошибку валидации, ведь все помеченные им поля были равны NULL, а выполнить ленивую загрузку их он не умеет. Система кодогенерации C-Gen Создание модели данных. Система кодогенерации C-Gen в качестве модели принимает готовую базу данных, на основе которой в программном коде генерируются набор соответствующих объектов и методов, которые отображают маппинг структуры базы на объектную модель. Наряду с маппингом реляционных объек- тов базы данных на объектную модель, в самой базе данных генерируются CRUD хранимые процедуры, через которые осуществляется манипулирование данными (рис 8). Моделі і засоби систем баз даних і знань 179 Рис. 8. Схема взаимодействия компонентов информационной системы с системой кодогенерации C-Gen Выборка данных. Чтобы осуществить выборку данных, с использованием API системой кодогенерации С-Gen, доступно два варианта:  воспользоваться одним из методов сгенерированной системой автоматически;  если функциональности стандартных запросов не достаточно, реализовать SQL запрос в виде храни- мой процедуры, и осуществить перегенерацию API. В результате из кода будет доступен метод который осуще- ствит выборку данных и вернет объект. Для реализации вышеуказанной выборки в С-Gen, необходимо реализовать хранимую процедуру, вы- полняющую выборку данных (рис. 9). Рис. 9. Листинг хранимой процедуры GetMessageList Сгенерированный API предлагает на выбор два метода, для получения результатов выборки:  первый метод в результате выборки вернет объект типа DataReader, из которого в дальнейшем можно вывести типизированный объект (подразумевается написание класса обертки). Данный метод подходит, если результирующий объект будет использован всего один раз и в процессе выборки, необходимо реализовать до- полнительную логику по агрегации данных. Недостатком же данного подхода является то, что разработчик фактически работает динамическим объектом, и в результате изменения структуры возвращаемых данных на стороне сервера баз данных, может привести к ошибке времени выполнения приложения, если пользователь не внесет изменения в клиентском приложении (исключительная ситуация может возникнуть в случае переимено- вания или удаления одного из полей входящих в результат выборки).  второй метод основан на алгоритма "рекурсивного выведения типа". В программном коде будет сгенерирован строго-типизированный объект (в виде класса), отображающий результат выборки. Использовать подобный класс удобно, т. к. не нужно производить дополнительных операций по выведению из DataReader класса соответствующего результату выборки. Однако если в процессе разработки, возникнет необходимость в написании другого метода (SQL запроса), результирующим набором которого должен будет стать объект с теми же полями и свойствами, система создаст для него новый класс, вместо того чтобы использовать уже су- ществующий. Моделі і засоби систем баз даних і знань 180 Для решения проблемы работы в API со строго-типизированными объектами, существует механизм вы- ведения типа объекта через представление. Данный подход подразумевает написание представления, которое будет является отображением результата выборки (рис. 10). Таким образом будет сгенерирован метод, резуль- татом которого является класс построенный на основе полей представления. Рис. 10 Листинг представления vMessageList Данный подход, предполагает агрегацию данных в представлении, а затем выборку их по средствам хра- нимой процедур (рис. 11), однако позволяет использовать один и тот же класс в качестве результата выборки для нескольких хранимых процедур. Рис. 11. Листинг запроса GetMessage В результате, мы получаем метод, который возвращает объект, отображающий результат выборки SQL запроса. Важно понимать, что при взаимодействии со сгенерированным API, разработчик реализовывает только SQL на стороне сервера баз данных, все остальные классы и методы доступа, генерируются автоматически. Таким образом можно достичь высокой производительности за счет использования оптимальных запросов со стороны сервера баз данных, а также высокий уровень автоматизации, за счет генерации API доступа и CRUD автоматически. Добавление данных. Для того чтобы добавить данные в сгенерированном API необходимо создать объ- ект того типа, данные которого необходимо добавить, а затем выполнить метод Save(). Важно отметить, что при необходимости выполнить несколько методов в разрезе одной транзакции, такая возможность существует. Для этого необходимо создать экземпляр класс TransactionManager, а в каждый метод, находящийся в транзакции необходимо передать экземпляр созданного класса (рис. 12). Таким образом в результате возникновения исключительной ситуации, вызов метода Rollback() не внесет изменений в пределах цепочки вызовов методов, помеченных транзакцией. Модификация и удаление данных. В отличии от Entity Framework, API сгенерированной системой кодогене- рации С-Gen поддерживает Bulk-операции, а это значит, что на примере с перебором коллекции и установки в ней писем как прочтенных выполнится всего два запроса к базе данных: первый вернет список всех сообщений. Далее необходимо пройти по списку у становить свойство IsRead = true, а затем выполнить метод Save() в ко- торый передать коллекцию сообщений для сохранения. Тоже справедливо и при удаления данных. Моделі і засоби систем баз даних і знань 181 Рис. 12. Диаграмма класс TransactionManager Выводы В данной статье была рассмотрена проблема преобразования данных из объектно-ориентированного ви- да в реляционный и наоборот. Один из наиболее распространенных подходов реализации такого взаимодей- ствия: использование ORM систем. Были проанализированы преимущества и недостатки использования ORM систем, на основе чего были сформированы требования, которым должна удовлетворять система эффективного преобразования данных из объектного представления в реляционное и наоборот. Исходя из этого, предложена методика реляционно-объектного представления, которая базируется на принципах построения информационных систем на основе модели в базе данных. Данная методика реляцион- но-объектного отображения решает две основные проблемы, характерные для систем подобного рода:  производительность. Оптимальные запросы, написанные SQL разработчиком, оказываются на много более эффективными чем генерируемый ORM SQL код;  автоматизация. Алгоритм генерации программного кода, основанный на методике «трех проекций» позволяет установить соответствие между объектным и реляционным представлением данных, а также предо- ставить разработчику API для доступа к данным. Данная методика, положена в основу системы кодогенерации C-Gen. Сравнительная характеристика, решения проблемы объектно-реляционного преобразования на практическом примере показала, эффектив- ность работы системы кодогенерации С-Gen по сравнению с Entity Framework. Основным недостатком ис- пользования Entity Framework , по сравнению с системой кодогенерации С-Gen является неоптимальный SQL код генерируемый системой. Разработчик должен постоянно следить за тем, какой SQL код был сгенериро- ван системой. Таким образом, без базовых знаний основ реляционной алгебры, невозможно построить си- стему, оптимальную по производительности (хотя предлагаемый подход подталкивает разработчика абстра- гироваться от написания SQL, доверив это ORM системе). При осуществлении операций добавления коллек- ций данных, ORM не поддерживает Bulk операции, поэтому на каждом витке итерации необходимо выпол- нять запрос к серверу баз данных. 1. Russell C. Bridging the Object-Relational Divide. Queue Vol. 6, N 3, May 2008, P. 18–28. 2. Создание кода и текстовые шаблоны T4 http://msdn.microsoft.com/ru-ru/library/bb126445.aspx. 3. Booch G., Maksimchuk R.A., Engle M.W. Object-Oriented Analysis and Design with Applications. Addison-Wesley, 2007/ 4. Russell C. Bridging the Object-Relational Divide. Queue. – Vol. 6, N 3. – May 2008, P. 18–28. 5. Bauer C., King G. Java Persistence with Hibernate. Manning, New York, 2007. 6. O'Neil E.J. 2008. Object/relational mapping 2008: hibernate and the entity data model (edm). In Proceedings of the 2008 ACM SIGMOD international conference on Management of data (SIGMOD '08). – 2008. – P. 1351–135. 7. Лихацкий И.А. Об одной методике формирования объектного представления реляционных данных // Проблеми програмування. – 2013. – № 3. – С. 79–85. 8. Лихацкий И.А. Средства кодогенерации для взаимодействия с базой данных через объекты // Проблеми програмування. – 2012. – № 2– 3. – С. 384–385. 9. Учебный курс. Создание модели данных Entity Framework для приложения ASP.NET MVC http://habrahabr.ru/company/microsoft/blog/133316/ 10. Еще один взгляд на Entity Framework: производительность и подводные камни http://habrahabr.ru/post/164483/ 11. DbContext Class http://msdn.microsoft.com/en-us/library/system.data.entity.dbcontext%28v=vs.113%29.aspx 12. BULK INSERT (Transact-SQL) http://msdn.microsoft.com/en-us/library/ms188365%28SQL.100%29.aspx

Сравнительна характеристика методик объектно-реляцонного преобразования

Репозитарії

Схожі ресурси