Comparative analysis of some O-R transforming methods.pdf 1. ПОСТАНОВКА ЗАДАЧИОбъектно-ориентированное проектирование ипрограммирование в настоящее время является самымраспространенным подходом к разработке программ-ного обеспечения. В составе общего производствен-ного процесса разработчики решают множество задач,связанных с различными особенностями данного под-хода. Обычно различные части программной системыразрабатываются в рамках подсистем - достаточнонезависимых компонентов. Одной из таких подсистемявляется подсистема управления данными [1]. Такимобразом, задача проектирования и реализации под-системы хранения данных в объектно-ориенти-рованных системах является актуальной.Существует множество подходов к решению дан-ной задачи: от применения объектно-ориентирован-ных баз данных до создания собственных средствхранения, поддерживающих объектные типы данных.Вообще, под хранением объектов в рамках настоящейработы будем подразумевать сохранение и восстанов-ление их состояния, то есть значений атрибутов, изисточников долговременного хранения информации.В литературе по объектно-ориентированному анализуи проектированию (ООАП) эти операции называютсяматериализацией и дематериализацией объектов.В настоящей работе будем рассматривать задачухранения объектов в реляционной базе данных. В этомслучае выполняется так называемое O - R-преобразо-вание, позволяющее перейти от объектной моделипредметной области к реляционному способу храненияданных. Актуальность этого направления исследова-ний уже неоднократно обсуждалась [2, 3]. В даннойработе рассматривается несколько шаблонных реше-ний этого вопроса, делается их сравнительный анализ.Заранее оговорим, что реализация решений будетрассмотрена «в чистом виде», то есть отдельно отразличных смежных вопросов, таких, как кэширова-ние, блокировка, безопасность, а также без использо-вания шаблонов, связанных с отложенной загрузкой.2. ТЕСТОВЫЙ ПРИМЕР,ТЕХНОЛОГИЧЕСКАЯ БАЗАВ качестве примера реализации анализируемыхподходов рассмотрим справочную информационнуюсистему «Электронный каталог» книжного магазина.В основу положена база данных реального интернет-магазина. Полное описание структуры представлено ввиде диаграммы классов предметной области (рис. 1).База данных содержит информацию о 101 087 эк-земплярах товара, распределенных по 588 разделам, втом числе - 84 287 книг, 6 793 периодических изда-ний, 10 007 наименований кассет. База данных такжесодержит информацию о 5 243 издательствах и 42 857авторах книг.Все методы тестируются на одной технологиче-ской платформе:- в качестве хранилища выбрана база данных фор-мата MS Access 2000;- все операции над базой данных выполняются по-средством запросов SQL;- выполнение запросов производится из приложе-ния, созданного средствами Borland Delphi версии 7.0;- измерение времени выполнения операций произ-водилось на компьютере с процессором Pentium 3,933 МГц, RAM 256 M, под управлением операцион-ной системы MS Windows 2000 Server, причем каждаяоперация была выполнена по 100 раз. Время публику-ется с точностью до сотых долей секунды.Основные измерения будут касаться следующихопераций:- открытия всей базы данных (запуск программы);- выборки всех данных по одному объекту «Кни-га» (максимальное количество атрибутов среди всехтоваров);- выборки всех данных по одному объекту «Кассе-та» (минимальное количество атрибутов среди всехтоваров);- выборки объекта-контейнера (справочника 4КоличествоРис.1. Диаграмма классов предметной областиАвторыidФИОАвторыКнигid Книгиid АвтораИздательстваidНазваниеРазделыidid ВладельцаНазваниеКорзиныidПериодическиеidid РазделаНазваниеЦенаid ИздательстваДатаКнигиidid РазделаНазваниеЦенаid ИздательстваГодТоварывКорзинеid Товараid КорзиныКоличествоКассетыidid РазделаНазваниеЦенаПродолжительностьРис. 2. Схема базы данных модели ROT3. ОБЪЕКТЫ КАК ТАБЛИЦЫ (МОДЕЛЬ ROT)Первым из методов рассмотрим подход, известныйпод названием Representing Objects as Tables (объектыкак таблицы) [5] - ROT. Данный подход являетсянаиболее «естественным» для реляционных баз дан-ных. Суть его заключается в том, что каждому классупредметной области ставится в соответствие однатаблица реляционной базы данных с соответствую-щими атрибутами. Связи реализуются по соответст-вующим правилам ER-проектирования реляционныхбаз данных. При этом таблицы для абстрактных клас-сов не создаются, а атрибуты классов-предков при-сутствуют и в таблицах для классов-потомков.Схема базы данных для примера «Электронныйкаталог» представлена на рис. 2.Реализуемость: подход удобен для быстрой раз-работки программ, так как все операции над базойданных легко реализуются стандартными конструк-циями SQL. Гибкость: очень низкая, практическилюбые изменения в структуре базы данных неизбеж-но приводят к необходимости исправления исходногокода. Особенности: нет необходимости в поддержкеуникальных идентификаторов в пространстве всей ба-зы данных, в принципе, можно обойтись даже безуникальных идентификаторов ветки «Товар». Объембазы данных и время выполнения почти всех опе-раций - минимальные среди всех рассмотренныхподходов.4. МОДИФИКАЦИЯ ROT С УЧЕТОМ НАСЛЕ-ДОВАНИЯМодель ROT напрямую отображает классы пред-метной области в таблицы реляционной базы данных.Однако, как это было показано выше, это приводит ктому, что некоторые общие данные классов, находя-щихся в отношении наследования, оказываются рас-положены в разных таблицах и однотипную обработ-ку данных приходится реализовывать для каждойтаблицы в отдельности (в нашем примере - это класс«Товар» и его наследники).Существует подход, позволяющий решить этупроблему. Суть данного подхода заключается в том,что для суперклассов, имеющих атрибуты или ссылкина другие объекты, создаются соответствующие таб-лицы, а в таблицы наследников помещаются толькоидентификатор и атрибуты, доопределенные в клас-сах-наследниках. При этом между таблицей родителяи таблицей наследника устанавливается связь 1:1.Схема базы данных, основанная на модели ROT сучетом наследования, приведена на рис. 3.АвторыidФИОАвторыКни гid Книгиid АвтораИздательстваidНазваниеКнигиidГодПериодически еidДатаКорзиныidРазделыidid ВладельцаНазваниеКассетыidПродолжительност ьПечатныеidid ИздательстваТоварывКорзин еid Товараid КорзиныТовары Количествоidid РазделаНазваниеЦенаРис. 3. Схема базы данных для модели ROT с учетом наследованияРеализуемость: данный подход в реализации не-много сложнее предыдущего, большинство операцийтакже реализуются заранее подготовленными запро-сами SQL. Гибкость: выше, чем у модели ROT, одна-ко большинство изменений в структуре базы данныхтакже требуют исправления исходного кода програм-мы. Особенности: благодаря выделению таблицы длясуперкласса «Товар» и связей 1:1 между таблицамидля наследуемых классов этой ветки поддержка уни-кальных идентификаторов выполняется легко. Объембазы данных и время выполнения операций - чутьбольше, чем у модели ROT.5. МОДЕЛЬ А. ТЕНЦЕРА «БАЗА ДАННЫХ -ХРАНИЛИЩЕ ОБЪЕКТОВ»Основы данного подхода изложены в [6]. Главнойидеей является неизменность схемы базы данных: посути дела, предложенная в работе схема являетсяуниверсальной и готовой к использованию в любыхобъектно-ориентированных приложениях. К тому жезаранее определена универсальная реализация мето-дов материализации и дематериализации объектов.К сожалению, в упомянутой работе не описанынекоторые нюансы, свойственные объектно-ориенти-рованным системам. В связи с этим ниже оговоримнекоторые важные с точки зрения практической реа-лизации моменты этой модели.Во-первых, в работе отсутствует развернутое опи-сание реализации в модели механизмов наследования.В частности, не ясно нужно ли для наследников в таб-лицах StrDesc, PropDesc и т.д. дублировать свойства,которые были уже приписаны родителю. То же касает-ся и связей в таблице AllowedLinks. Будем считать, чтоописание свойств классов и связей между ними не дуб-лируется у наследников, а восстанавливается благодарязависимости Id-ParentId в таблице ObjType.Во-вторых, не ясно, создаются ли все записи длясвойств нового объекта в таблицах свойств (Strings,Properties и т.д.), даже если они пусты. Будем считать,что у «живого» экземпляра объекта определены всесвойства, и поэтому в упомянутые таблицы вносятсязаписи, соответствующие всем свойствам объекта.В-третьих, в модели Тенцера отсутствует (явно невыражена) возможность создания атрибутов связи. Внашем примере - это атрибут «Количество», значениекоторого определяется только при сочетании одногоконкретного экземпляра класса «Товар» с одним кон-кретным экземпляром класса «Корзина». Реализуемрешение этого вопроса в виде ассоциативного класса«ТоварВКорзине» с атрибутом «Количество» (рис. 4).Товар Корзин0..n 0..n аТоварвКорзинеКоличествоРис. 4. Представление атрибута связив виде ассоциативного классаВ-четвертых, связи (таблицы AllowedLinks иLinks) в этой модели реализованы только бинарные. В«классическом» ER-проектировании баз данных су-ществует возможность представления трех- и болеесторонних связей. Трехстороннюю связь на диаграм-ме рис. 4 преобразуем в две бинарные путем введениядополнительного класса, описывающего связь. В дан-ном случае классом связи может выступить сам ассо-циативный класс, поэтому диаграммуРеализуемость: для реализации в программе дан-ной модели необходимо, в первую очередь, реализо-вать подсистему управления данными, которая «налету» собирает объекты. Подход применим при дол-говременной разработке либо при наличии уже реали-зованной подсистемы управления данными. Гиб-кость: высокая, практически все изменения в пред-метной области требуют внесения исправлений науровне данных (конфигурирования) и не влияют наисходный код. Особенности - для универсальностипрограммы имеется необходимость поддержки уни-кального идентификатора в пространстве всей базыданных. Разделение таблиц для атрибутов по типамприводит к необходимости выборки или поиска повсем таким таблицам. Благодаря полям Code иItemName в таблицах такой базы данных очень удоб-но строить списки элементов (справочники). Объембазы данных и время выполнения операций - дос-таточно высокие, в большинстве тестов - максималь-ные.StrDescIdTypeIdCodeItemNamePropDescIdTypeIdCodeItemNameDTDescIdTypeIdCodeItemNameAllowedLinksIdParentIdChildIdTypeIdLinkTypeIdCodeItemNameObjTypeIdCodeItemNameParentIdStringsIdTypeIdObjectIdValuePropertiesIdTypeIdObjectIdValueDateTimesIdTypeIdObjectIdValueObjectsIdTypeIdItemName LinksIdParentIdChildIdTypeIdРис. 6. Схема базы данных согласно модели Тенцера6. МОДИФИКАЦИЯ МОДЕЛИ ТЕНЦЕРАРассмотрим возможную модификацию моделиТенцера. Внесенные изменения, с одной стороны, вы-званы обобщением подхода: описание атрибутов всехобъектов производится в одной таблице Attributes соструктурой, похожей на XXXDesc в модели Тенцера.Хранение значений всех атрибутов объектов произво-дится в пределах одной таблицы, подобной таблицеStrings, в которой столбец Value имеет тип Variant.Конечно, не все существующие форматы реляцион-ных баз данных поддерживают такой тип столбцов,поэтому на практике можно использовать тип String.При этом возникают естественные проблемы, связан-ные с увеличением объема таких данных и их агрегат-ной обработкой. Однако объем в данном случае явля-ется ценой за универсальность подхода, а агрегатнаяобработка в объектно-ориентированных системах не-посредственно в базе данных обычно не производится(для этого используют сервер приложений [6]).С другой стороны, введение таблицы Containersпродиктовано соображениями, вытекающими изпрактического опыта работы. Дело в том, что наибо-лее часто встречающимся видом ассоциации (кроменаследования) между классами является агрегация.Например, подсистема нормативно-справочной ин-формации любой информационной системы обяза-тельно будет содержать такой вид связи [7].Наконец, другие виды связи в этой модели реали-зуются таким же образом, как и в исходном коде объ-ектно-ориентированных программ - через атрибуты,являющиеся ссылками на другие объекты. В данномслучае эти ссылки представляют собой внешние клю-чи, ссылающиеся на идентификатор соответствующе-го объекта. Значения этих атрибутов также распола-гаются в таблице ObjectData.На рис. 7 представлена схема базы данных дляпредлагаемой модели.AttributesIdClass_IdCaptionDescriptionClassesIdCaptionDescriptionParent_IdObjectDataObject_IdAttribute_IdValueObjectsIdClass_IdCaptionContainersContainer_IdObject_IdРис. 7. Схема базы данных модифицированноймодели ТенцераТаблица Classes содержит описание классов сис-темы. Атрибут Id - уникальный идентификатор,Parent_Id - ссылка на Id предка в этой же таблице,Caption - короткое (возможно, англоязычное - дляисходного кода программы) название класса,Description - подробное описание класса.Таблица Attributes содержит описание атрибутовклассов. Id - уникальный идентификатор атрибута,Class_Id - ссылка на Id класса (в таблице Classes), к ко-торому относится атрибут, Caption и Description - ана-логично предыдущему. Для классов-наследников опи-сание атрибутов не повторяется. Таким образом, дляматериализации описания класса необходимо восста-новить всю структуру наследования «вверх» и выбратьописания всех атрибутов классов этого поддерева.Таблица Objects содержит список экземпляровобъектов. Id - уникальный идентификатор объекта,Class_Id - ссылка на Id класса (в таблице Classes), ккоторому относится экземпляр, Caption - краткое обо-значение объекта (для быстрого вывода в списках),формируется программной системой, обычно соот-ветствует значению одного (или комбинации не-скольких) из свойств.Таблица ObjectData содержит значения свойствобъектов. Object_Id - ссылка на Id объекта (в таблицеObjects), Attribute_Id - ссылка на Id атрибута (в таб-лице Attributes), Value - значение этого атрибута дляданного объекта (тип Variant или, возможно, String).Таблица Containers содержит ключи ассоциацииагрегирования. Здесь Container_Id - ссылка на Id объ-екта-владельца (в таблице Objects), Object_Id - ссылкана Id обекта (там же), содержащегося в контейнере.Сразу оговорим, что агрегирование в данном случаеозначает «содержит ссылку» и не подразумевает пол-ное владение вложенными объектами.Таким образом, таблицы Clsses и Attributes содер-жат описание (метаданные), а остальные таблицы -сами данные.В представленной статье не будем касаться вопро-сов реализации описания типов атрибутов, контроляза совместимостью типов для ссылок и описания ро-лей классов в ассоциациях, так как это не являетсясущественным для производимых измерений.Для нашей модели предметной области (диаграм-мы на рис. 1 и 5) таблицы, содержащие метаданные,следует заполнить следующим образом (табл. 6 - 7).Т а б л и ц а 6Таблица ClassesId Caption Description Parent_Id1 Раздел 02 Товар 03 Корзина 04 ТоварвКорзине Экземпляробъекта-связи 05 Издательство 06 Автор 07 ПечатнаяПродукция Печатнаяпродукция 28 Кассета 29 Книга 710 Периодика Периодическоеиздание 7Т а б л и ц а 7Таблица AttributesId Class_Id Code Description11 1 Название Название раздела12 2 Название Название товара13 5 Название Название издательства14 6 ФИО Фамилия И.О. автора15 2 Цена Цена единицы товара16 4 Количество Количество в корзине17 9 Год Год издания книги18 8 Продолжи-тельностьПродолжительностькассеты19 10 Дата Дата периодическогоиздания20 4 Товар Ссылка на Id товара21 7 Издательство Ссылка на IdиздательстваРеализуемость: аналогично предыдущей моделитребует наличия подсистемы управления данными,облегчает ее реализацию благодаря представлениюданных всех типов в одной таблице и требует лишьприведения типов. Гибкость: очень высокая, измене-ния в предметной области требуют внесения исправ-лений на уровне данных и не влияют на исходный кодпрограммы. Особенности - аналогичны модели Тен-цера, для универсальности программы имеется необ-ходимость поддержки уникального идентификатора впространстве всей базы данных. Однако здесь этупроблему решить проще благодаря меньшему количе-ству таблиц. Объединение всех атрибутов в одну таб-лицу облегчает реализацию поиска и выборки их зна-чений. Объем базы данных и время выполненияопераций - очень высокие.7. СРАВНИТЕЛЬНЫЙ АНАЛИЗРезультаты измерения времени выполнения опе-раций и объема базы данных приведены в табл. 8 и нарис. 8-17.Произведем краткий анализ полученных результа-тов.Открытие всех таблиц базы данных. Суммарноевремя открытия всех таблиц базы данных в моделиТенцера и ее модификации значительно превышаетэтот показатель для ROT и ее модификации (рис. 8).Это связано с «гигантскими» таблицами Objects,Links, Strings, Properties и т.д.Выборка всех данных по одной Книге. На про-ведение выборки данных по одной Книге (рис. 9, 10)не влияет определение типа на этапе выполнения, таккак в любом случае количество атрибутов остаетсяодинаковым - максимальным. Хорошие результатыпоказывает модифицированная модель Тенцера, таккак выборка самих значений производится по однойтаблице ObjectData.Выборка всех данных по одной Кассете. Общаякартина практически не изменяется при универсаль-ном запросе (без определения типа). В случае дина-мического определения типа товара для модели ROTс наследованием и модели Тенцера происходит резкоеуменьшение времени выполнения операции, так как вэтом случае запрос строится по меньшему количествутаблиц.Выборка всех данных по всем товарам. Резуль-татом такой операции31ROT Модиф. ROT Тенцер Модиф.ТенцерРис. 10. Выборка всех данных по одной Книгес определением типа, с6101418ROT Модиф.ROTТенцер Модиф.ТенцерРис. 11. Выборка всех данных по одной Кассетебез определения типа, с0123456ROT Модиф. ROT Тенцер Модиф.ТенцерРис. 12. Выборка всех данных по одной Кассетес определением типа, с60100140180220ROT Модиф. ROT Тенцер Модиф.ТенцерРис. 13. Выборка всех данных по всем товарам, с810121416ROT Модиф. ROT Тенцер Модиф.ТенцерРис. 14. Вычисление суммы товаров в корзине, с00,20,40,6ROT Модиф. ROT Тенцер Модиф.ТенцерРис. 15. Добавление новой Книги, с14710ROT Модиф. ROT Тенцер Модиф.ТенцерРис. 16. Изменение данных по одной Книге, с30405060ROT Модиф. ROT Тенцер Модиф.ТенцерРис. 17. Объем базы данных, МБВЫВОДЫПолученные результаты показывают, что для соз-дания небольших информационных систем, не тре-бующих дальнейшего сопровождения, вполне подхо-дит модель представления классов как таблиц (ROT):она позволяет быстро реализовать все необходимыеоперации над данными, при этом сами операции вы-полняются очень быстро, а размер базы данных полу-чается минимальный. Для придания большей гибко-сти такой системе можно использовать модификациюмодели ROT с наследованием (средние системы). Приразработке сложных информационных систем, тре-бующих длительного сопровождения и предполагаю-щих дальнейшее развитие, рекомендуется использо-вать модифицированную модель Тенцера. При этомосновной объем работ будет посвящен разработкеподсистемы управления данными, оптимизации ско-рости выполнения операций (при проведении тестовзадачи решались «в лоб», без рассмотрения проблемыоптимизации). И хотя время выполнения многих опе-раций в такой модели все равно останется достаточнобольшим, стоимость владения такой сложной инфор-мационной системой будет значительно ниже, чемвыполненной

Скачать электронную версию публикации