About one technique for forming an object representation of relational data
Prombles in programming 2013; 3: 79-85
Saved in:
| Date: | 2025 |
|---|---|
| Main Author: | |
| Format: | Article |
| Language: | Russian |
| Published: |
PROBLEMS IN PROGRAMMING
2025
|
| Subjects: | |
| Online Access: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/755 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Problems in programming |
| Download file: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-755 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/84/9f411593079059c4a6ec84e27c519384.pdf |
| spelling |
pp_isofts_kiev_ua-article-7552025-06-21T15:30:49Z About one technique for forming an object representation of relational data Об одной методике формирования объектного представления реляционных данных Likhatsky, I.A. UDC 51:681.3 УДК 51:681.3 Prombles in programming 2013; 3: 79-85 Предложена методика формирования объектного представления реляционных данных, направленная на достижение наибольшей производительности генерируемого кода и труда программиста. Методика использует концепцию "трех проекций" представления реляционных данных в объектном коде, на основе которой описывается модель поведения реляционных объектов в объектном коде.Prombles in programming 2013; 3: 79-85 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-06-21 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/755 PROBLEMS IN PROGRAMMING; No 3 (2013); 79-85 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 3 (2013); 79-85 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 3 (2013); 79-85 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/755/807 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-06-21T15:30:49Z |
| collection |
OJS |
| language |
Russian |
| topic |
UDC 51:681.3 |
| spellingShingle |
UDC 51:681.3 Likhatsky, I.A. About one technique for forming an object representation of relational data |
| topic_facet |
UDC 51:681.3 УДК 51:681.3 |
| format |
Article |
| author |
Likhatsky, I.A. |
| author_facet |
Likhatsky, I.A. |
| author_sort |
Likhatsky, I.A. |
| title |
About one technique for forming an object representation of relational data |
| title_short |
About one technique for forming an object representation of relational data |
| title_full |
About one technique for forming an object representation of relational data |
| title_fullStr |
About one technique for forming an object representation of relational data |
| title_full_unstemmed |
About one technique for forming an object representation of relational data |
| title_sort |
about one technique for forming an object representation of relational data |
| title_alt |
Об одной методике формирования объектного представления реляционных данных |
| description |
Prombles in programming 2013; 3: 79-85 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/755 |
| work_keys_str_mv |
AT likhatskyia aboutonetechniqueforforminganobjectrepresentationofrelationaldata AT likhatskyia obodnojmetodikeformirovaniâobʺektnogopredstavleniârelâcionnyhdannyh |
| first_indexed |
2025-07-17T09:58:38Z |
| last_indexed |
2025-07-17T09:58:38Z |
| _version_ |
1850410434507571200 |
| fulltext |
Моделі і засоби систем баз даних та знань
© И.А. Лихацкий, 2013
ISSN 1727-4907. Проблеми програмування. 2013. № 3 79
УДК 51:681.3
И.А. Лихацкий
ОБ ОДНОЙ МЕТОДИКЕ ФОРМИРОВАНИЯ ОБЪЕКТНОГО
ПРЕДСТАВЛЕНИЯ РЕЛЯЦИОННЫХ ДАННЫХ
Предложена методика формирования объектного представления реляционных данных, направленная на
достижение наибольшей производительности генерируемого кода и труда программиста. Методика ис-
пользует концепцию "трех проекций" представления реляционных данных в объектном коде, на основе
которой описывается модель поведения реляционных объектов в объектном коде.
Введение
В настоящее время в мире хранения
данных доминируют реляционные систе-
мы управления базами данных (РСУБД)
[1], тогда как для обработки данных все
чаще используются объектные языки про-
граммирования (ОЯП) [2]. Доля рынка
РСУБД составляет 80% [3] от всего сег-
мента рынка СУБД, а доля рынка ОЯП со-
ставляет 50% от всего сегмента рынка
языков программирования [4, 5].
При разработке информационных
систем, использующих РСУБД, часто воз-
никают проблемы в преобразовании дан-
ных из реляционного вида в объектный и
наоборот. В качестве решения данной про-
блемы предлагается создать объектную
форму представления реляционной БД,
объекты которой отражают сущности
предметной области и однозначно связаны
с таблицами, представлениями и храни-
мыми процедурами БД.
В данной статье предложена мето-
дика формирования объектного представ-
ления реляционных данных, целью кото-
рой является достижение высокого уровня
автоматизации процесса.
Актуальность использования таких
систем обусловлена, с одной стороны
наличием на рынке развитых объектно-
ориентированных технологий, а с другой –
доминированием реляционных баз данных
в мире хранения данных. В результате
возникает необходимость в построении
системы, позволяющей осуществить взаи-
модействие между объектными языками
программирования и реляционными база-
ми данных.
Рассмотрим методику формирова-
ния объектного представления реляцион-
ной базы данных на примере системы ко-
догенерации С-Gen [6]. Данная система на
входе получает структуру базы данных. На
выходе, на стороне сервера БД система ге-
нерирует набор CRUD (Create Retrieve
Update Delete) хранимых процедур, и про-
граммный код на выходном языке про-
граммирования.
1. Проекция реляционной модели
данных в объектно-
ориентированную
Предлагаемая объектная форма
представления реляционной БД позволяет
представить имеющиеся таблицы, пред-
ставления и хранимые процедуры в виде
иерархии объектов, при этом несуще-
ственные для пользователя данные скры-
ты, а объекты и атрибуты имеют названия,
характерные для рассматриваемой пред-
метной области.
Формирование объектного пред-
ставления реляционной БД выполняется в
автоматизированном режиме, на основе
структуры БД.
Для построения объектной формы
будут анализироваться такие объекты БД.
1.1. База данных (DataBase) – со-
вокупность данных, организованных в со-
ответствии с концептуальной структурой,
описывающей характеристики этих дан-
ных и взаимоотношения между ними.
Определим, что на объектном уровне
представления данных, БД это совокуп-
ность объектов (таблицы, представления)
и методов (хранимых процедур) осу-
ществляющих некоторые действия над
объектами.
Моделі і засоби систем баз даних та знань
80
1.2. Таблица (Table) – таблица в
реляционной базе данных (рис. 1).
Рис. 1. Список таблиц БД
Рис. 2. Список объектов
Определим, что на объектном
уровне представления данных, таблица это
некоторый объект (рис. 2) определенного
типа (строго типизированный), а результа-
том выборки данных из таблицы является
либо один объект данного типа, либо спи-
сок объектов данного типа.
1.3. Представление (View) – вир-
туальная таблица, представляющая собой
поименованный запрос, который будет
представлен как подзапрос при использо-
вании представления. Определим, что на
объектном уровне представления данных,
представление также является некоторым
объектом определенного типа (строго ти-
пизированный), а результатом выборки из
представления является либо один объект
данного типа, либо список объектов дан-
ного типа.
1.4. Хранимая процедура (Stored
procedure) – объект базы данных, пред-
ставляющий собой набор SQL-инструк-
ций, который компилируется один раз и
хранится на сервере.
Рис. 3. Список хранимых процедур
Определим, что на объектном уров-
не представления данных, хранима проце-
дура это метод, который выполняет неко-
торые действия над объектами (таблицы,
представления). В зависимости от характе-
ра операции (вставка, выборка, удаление
обновление), метод (хранимая процедура)
может либо возвращать объект, либо воз-
вращать список объектов, либо ничего не
возвращать (рис. 4) . Также определим, что
хранимая процедура обязательно относит-
ся к одному из объектов БД (таблица,
представление). Под отношением понима-
ется абстрактная связь с учетом которой
определяется тип возвращаемых данных.
Рис. 4. Объектное представление храни-
мых процедур относящихся к таблице
CorseSizePrice
Моделі і засоби систем баз даних та знань
81
Например, таблица CourseSizePrise
(рис. 1) в объектном виде представлена в
виде класс CourseSizePrise.cs (рис. 2), а
хранимые процедуры (рис. 3), которые от-
носятся к CourseSizePrise, в объектном ви-
де, представлены в виде соответствующих
методов (рис. 4.)
В рамках рассматриваемой методи-
ки формирования объектного представле-
ния, все хранимые процедуры базы данных
делятся на два типа.
"Простые хранимые процеду-
ры". Данный тип процедур создается для
каждого объекта БД (таблицы, представ-
ления). Он включает в себя набор стан-
дартных CRUD хранимых процедур, а
также процедуру для постраничного отоб-
ражения контента. Отметим, что на объ-
ектном уровне представления данных, ме-
тод, соответствующий данному типу хра-
нимых процедур, всегда будет возвращать
значения того типа объекта, к которому
относится хранимая процедура. А так как
мы определили в пункте 1.4, что хранимая
процедура обязательно относится к како-
му-либо объекту БД, то и тип данных бу-
дет определен однозначно.
"Пользовательские хранимые
процедуры". Данный тип процедур ис-
пользуется для решения нетривиальных
задач по выборке данных, а также реали-
зации выборки, которая не поддерживает-
ся стандартными хранимыми процедура-
ми. "Пользовательские хранимые проце-
дуры" не генерируются автоматически, а
пишутся разработчиком вручную. На объ-
ектном уровне представления данных дан-
ный тип хранимых процедур, может воз-
вращать значения типа отличного от типа
объекта, к которому он относится (более
детально данная особенность будет описа-
на далее).
Так как основная цель данной ме-
тодики формирования объектного пред-
ставления реляционных данных, – дости-
жение высокого уровня производительно-
сти информационной системы в целом и
значительного уровня автоматизации, под-
ход предполагает создание (генерацию)
"простых хранимых" процедур автомати-
чески, перед построением объектной мо-
дели реляционной структуры данных.
К "стандартным хранимым проце-
дурам" относятся следующие хранимые
процедуры:
• Insert – добавляет новую запись
в таблицу (генерируется для таблиц);
• Update – обновляет существую-
щую запись в таблице (генерируется для
таблиц);
• Delete – удаляет запись из табли-
цы (генерируется для таблиц);
• GetTop – возвращает n-записей
из таблицы (генерируется для таблиц и
представлений);
• GetByPrimaryId – в качестве
параметра данная хранимая процедура
получает уникальный первичный ключ
(либо составной первичный ключ, в зави-
симости от структуры таблицы) по кото-
рому осуществляется выборка. (генериру-
ется для таблиц);
• GetPaged – данная хранимая
процедура позволяет делать постранич-
ную выборку контента длинных списков.
(генерируется для таблиц и представле-
ний). Хранимая процедура возвращает
список элементов, которые должны быть
отображены на соответствующей страни-
це, а также общее количество элементов в
списке.
Таким образом, "простые хранимые
процедуры" обеспечивают разработчиков
информационной системы средствами ба-
зового управления данными "из коробки".
2. Первая проекция. Таблицы
реляционных БД
в объектном виде
Исходя из определения, что на объ-
ектном уровне представления данных таб-
лица – объект определенного типа, опре-
делим, что проекция таблицы в объектном
коде представляется в виде класса cущно-
сти (Entity), тип которой соответствует ти-
пу таблицы.
Мы знаем, что работа с таблицами
Моделі і засоби систем баз даних та знань
82
реляционной БД и классами в объектно-
ориентированном программировании
(ООП) отличается существенно [7]. Напри-
мер, в ООП уникальность проверяется по
адресу объекта в памяти, на которую он
ссылается, а в РСУБД уникальность запи-
си можно определить по первичному клю-
чу (либо совокупности ключей). Структура
класса (является проекцией таблицы БД)
объекта в объектном языке, спроектиро-
ванна таким образом, что позволяет про-
граммисту работать с проекцией таблицы,
как с обычным классом в ООП. Вся логи-
ка, которая осуществляет сопоставление
класса объекта в ООП на его реляционное
представление инкапсулирована в базовом
классе. Таким образом, работа с классом
объекта ни чем не отличается от работы с
обычным классом.
Для того, чтобы экземпляр класса
объекта мог быть однозначно сопоставлен
с его реляционным представлением,
необходимо точно идентифицировать, яв-
ляется ли данный экземпляр класса новой
записью по отношению к его реляцион-
ному представлению или нет. Нам из-
вестно, уникальность экземпляра класса и
записи в таблице идентифицируются по
разному.
Предлагаемый алгоритм сопостав-
ления класса в ООП к его реляционному
представлению, основанный на инкапсу-
ляции логики по обработке дополнитель-
ного поля первичного ключа в структуру
класса. Явно программист не может полу-
чить доступ к данному полю или изменить
его. Логика работы заключается в том, что
если экземпляр класса является новой за-
писью по отношению к своему реляцион-
ному представлению, то это поле будет
установлено в null, и наоборот, если эк-
земпляр класса отображает существую-
щую запись в таблице, поле будет содер-
жать уникальный идентификатор данной
записи. Таким образом, неявно осуществ-
ляется сопоставление экземпляра класса к
его реляционному представлению.
3. Вторая проекция.
Представления в объектном виде
Как и таблицы, представления
представляются в объектном коде в виде
классов сущностей (Entity). Так как пред-
ставление это виртуальная таблица, пред-
ставляющая собой поименованный запрос,
то над ним мы можем совершать только
операции выборки, поэтому и на объект-
ном уровне, классы сущностей представ-
лений по своей структуре отличаются от
классов сущностей таблиц.
Теперь мы можем отображать
(представлять) объекты реляционной БД с
помощью первой и второй проекции и со-
здавать/редактировать записи с помощью
первой проекции. Для обеспечения взаи-
модействия (выборка, вставка, удаление,
обновление) экземпляров касса с реляци-
онным представлением необходима третья
проекция – проекция на хранимые проце-
дуры.
4. Третья проекция. Хранимые
процедуры как методы в объект-
ном виде
4.1. "Простые хранимые проце-
дуры". Исходя из определения, что дан-
ный тип хранимых процедур генерируется
автоматически и сопоставляется каждому
объекту БД, с помощью "простых храни-
мых процедур" осуществляются базовые
операции с данными хранящимися в таб-
лицах. На объектном уровне представле-
ния данных, каждой "простой хранимой
процедуре" соответствует метод в объект-
ном коде.
Существует ограничение при ис-
пользовании методов, которые являются
проекциями на хранимые процедуры Insert
и Update. Программист не может вызвать
данные методы напрямую, а должен де-
лать это через метод Save. Поскольку эк-
земпляр класс, являющийся проекцией на
таблицу инкапсулирует логику по уста-
новлению, является ли данный экземпляр
класса новой записью по отношению к
своему реляционному представлению, то и
решение о том, какой метод должен быть
вызван в том или ином случае скрывается
от разработчика. С одной стороны это
предотвращает возможность возникнове-
ния ошибки в связи с вызовом неправиль-
javascript:%20window.location.hash='#outer_page_86'
Моделі і засоби систем баз даних та знань
83
ного метода сохранения, с другой стороны,
делает работу с объектами БД интуитивно
понятной.
Каждый метод принимает тот же
набор параметров, что и соответствующая
ему хранимая процедура, и возвращает
объект, либо список объектов соответ-
ствующего типа сущности к которой от-
носится хранима процедура. Таким обра-
зом взаимодействие объектного кода с БД
происходит через вызовы методов, опери-
рующими строго типизированными объ-
ектами.
4.2. "Пользовательские хранимые
процедуры". Пользовательские хранимые
процедуры отличаются от простых тем,
что тип результата возвращаемого храни-
мой процедурой может отличного от типа
объекта к которому относится хранимая
процедура.
Например, на рис. 5 показан ли-
стинг пользовательской хранимой проце-
дуры GetTopCourses. Хранимая процедура
относится к объекту Course, однако ре-
зультат, возвращаемый процедурой не яв-
ляется объектом типа Course (рис. 6). Как
видно из листинга, хранимая процедура
состоит из двух запросов, результат вы-
полнения которых, должен быть пред-
ставлен в виде класса в объектном виде.
Следовательно был предложен ал-
горитм, позволяющий построить проек-
цию объекта на возвращаемый тип храни-
мой процедурой. Поскольку хранимая
процедура может возвращать несколько
результатов одновременно был предложен
алгоритм "рекурсивного выведения типа
объекта".
1. Выполнить запрос.
2. Если ответ содержит массив ре-
зультирующих наборов данных выполнить
шаг 3 иначе метод возвращает void.
3. Пока есть результирующий на-
бор, на основе метаданных полей описы-
ваем класс.
4. На основе описанного класса
(классов) выводим тип объекта.
Рис. 5. Пользовательская хранимая
процедура GetTopCourses
Рис. 6. Результат выполнения
процедуры GetTopCourses
В результате, метод, который явля-
ется проекцией на пользовательские хра-
нимые процедуры, в качестве результиру-
ющего набора возвращает строго типизи-
рованный объект (рис 7) состоящий из двух
результирующих наборов, представленных
в виде списков классов Course и ResultSet1.
Рис. 7. Класс сгенерированный для храни-
мой процедуры GetTopCourse
Моделі і засоби систем баз даних та знань
84
5. Проекция связей между
таблицами
Одна из самых непростых проек-
ций, это проекция связей между таблицами
в ООП.
Данный подход предполагает нали-
чие следующих двух способов отображе-
ния связей. Все связи, между таблицами
которые необходимо отобразить в объект-
ном виде можно представить одним из
следующий способов.
отображение связи через пред-
ставления. Представление будет отобра-
жать связь между таблицами и/или пред-
ставлениями. На объектном уровне пред-
ставления данных будет сгенерирован со-
ответствующий класс, который является
проекцией на данное представление, а
также два стандартных метода (GetTop,
GetPaged) для взаимодействия с ним. Та-
ким образом, пользователь сможет отобра-
зить конкретную связь в виде представле-
ния, к которому можно получить доступ в
объектном коде через сгенерированный
класс;
отображение связей через
"пользовательские хранимые процеду-
ры". "Пользовательская хранимая проце-
дура", которая также как и представление
отображает связь между таблицами и/или
представлениями, но в отличии от пред-
ставления, для хранимой процедуры, на
объектом уровне будет сгенерирован объ-
ект и соответствующий метод доступа.
Рассмотрим пример проекции свя-
зей между в объектный код (рис. 8), на
примере связи многие-ко-многим между
таблицами Cource и Ingredient. Допустим,
нам необходимо вывести все продукты из
таблицы Ingredient, которые входят в блю-
да из таблицы Course (рис. 9).
Запрос, который необходимо вы-
полнить, чтобы получить результат (рис.
9), как уже было сказано выше, может
быть отображен в виде хранимой проце-
дуры либо же представления. Разница,
заключается в том, что на объектном
уровне представления, для представле-
ния будет построен объект, который будет
в дальнейшем являться типом возвраща-
емых данных для хранимых процедур
связанным с данным представлением и два
Рис. 8. Связь многие-ко-многим
Рис. 9. Результат
метода для доступа к нему (см. пункт 3), а
для пользовательской хранимой процеду-
ры – класс, который будет относиться
только к данной хранимой процедуре (см.
пункт 4.2). Следовательно, если в резуль-
тате, необходимо построить несколько за-
просов, возвращающих один и тот же объ-
ект, но удовлетворяющих разным услови-
ям, целесообразней использовать для этих
целей представления. Иначе, для разовой
выборки – "пользовательские хранимые
процедуры".
Таким образом, осуществляется не-
явная проекция связей таблиц в ООП. Од-
ним из преимуществ данного подхода яв-
ляется то, что в отличии от использования
технологии динамических запросов (таких
как LinQ), данный подход может быть реа-
лизован на любом объектно ориентиро-
ванном языке программирования, в не за-
висимости от того, поддерживает ли он
динамические запросы или нет.
Выводы
В данной работе предложена мето-
дика формирования объектного представ-
ления реляционных данных. Описаны ре-
Моделі і засоби систем баз даних та знань
85
ляционные объекты (таблицы, представле-
ния, хранимые процедуры), а также опре-
делены свойства которыми они обладают
на объектном уровне представления дан-
ных. Введены понятия: "отношения" хра-
нимых процедур с таблицами и представ-
лениями, "пользовательские хранимые
процедуры", "простые хранимые процеду-
ры". Предложена концепция "трех проек-
ций", на основе которой строится объект-
ная модель реляционных данных:
таблицы реляционной БД (первая
проекция);
представления реляционной БД
(вторая проекция);
хранимые процедуры БД (третья
проекция).
Также предложен алгоритм сопо-
ставления экземпляров класса к записям в
таблице, позволяющий сопоставлять реля-
ционное и объектное представление дан-
ных.
В рассмотренной методике, предла-
гается механизм отображения реляцион-
ных связей между объектами БД, а также
два подхода по отображению таких связей
в объектном виде:
отображение связи через пред-
ставления;
отображение связей через "поль-
зовательские хранимые процедуры".
Данный подход позволяет работать
с данными в форме специфических для
домена объектов и свойств, без необходи-
мости обращаться к базовым таблицам и
столбцам базы данных, где хранятся эти
данные. Данный подход дает разработчи-
кам возможность работать с данными на
более высоком уровне абстракции.
Также следует отметить, что данная
методика предполагает формирование
строго типизированных объектов, через
которые осуществляется взаимодействие с
реляционной БД.
Практически, рассмотренная мето-
дика, была реализована в системе кодоге-
нерации С-Gen [6].
1. Буч Г. Объектно-ориентированный анализ
и проектирование с примерами приложе-
ний, 3-е изд.: Пер. с англ. – М.: Издатель-
ский дом "Вильямс", 2008– 987с.
2. Роганов Е.А. Основы информатики и про-
граммирования. – М.: 2001. – 587 с.
3. http://www.tadviser.ru/index.ph
/Статья:СУБД_(мировой_рынок)СУБД
(мировой рынок)
4. http://dou.ua/lenta/articles/programming-
languages-rating-2011-07 Рейтинг языков
программирования.
5. http://habrahabr.ru/post/137833/Индекс по-
пулярности языков программирования за
февраль 2012.
6. Лихацкий И.А. Средства кодогенерации
для взаимодействия с базой данных через
объекты // Проблеми програмування. –
2012. – № 2–3. – 380–387.
7. Bauer C., King G. Java Persistence with Hi-
bernate. – New York: Manning, 2007. –
876 p.
8. Кунгурцев А.Б., Завалин А.А. Методика
формирования объектного представления
реляционной базы данных // Труды Одес-
ского политехнического института, 2004.
Получено 04.01.2013
Об авторе:
Лихацкий Игорь Александрович,
младший научный сотрудник.
Место работы автора:
Институт программных систем
НАН Украины,
03680, Киев-187,
Проспект Академика Глушкова, 40.
Тел.:+38(095)361 0330.
E-mail: igor_md@ukr.net
|