Содержание к диссертации
Введение
1 Анализ предметной области 8
1.1. Обзор технологий интеграции информации 8
1.2 Обзор моделей доступа к данным . 10
1.3 Обзор существующих разработок медиаторов XML для реляционных систем 11
1.3.1 Пример 12
1.3.2 XTABLES на базе расширения SQL 17
1.3.3 Microsoft SQLXML : 25
1.3.4 Oracle XML DB 32
1.3.5 XTABLES на базо XQtiery 38
1.4 Выводы 47
2 Архитектура и методы реализации 48
2.1 Анализ требований к виртуальному реиозиторию 49
2.1.1 Общесистемные требования 49
2.1.2 Инициатива XML:DB 50
2.1.3 Функциональные требования 52
2.2 Построение архитектуры 53
2.2.1 Перечень компонент и аспектов архитектуры 53
2.3 Методы реализации 55
2.3.1 Чтение ресурсов: Обработка аннотированной схемы . 55.
2.3.2 Запись ресурсов: Систематический учет зависимостей по данным 58
2.3.3 Работа с частями ресурсов: Двухфазное исполнение запросов 115
2.4 Варианты использования G5
2.4.1 Интеграция гетерогенных источников G5
2.4.2 Реинжиниринг унаследованной системы 66
2.4.3 Генерация реляционных баз данных на основе автоматического аннотирования 66
2.5 Выводы 66
3 Модели иерархических документов в реляционной системе 68
3.1 Вложенные отношения . 69
3.2 Операция вкладывающего соединения 79
3.3 Вложенные последовательности кортежей 83
3.4 Более гибкие схемы 89
3.5 Выводы , 97
4 Анализ эффективности предложенных методов и моделей 98
4.1 Разработка-исследовательского прототипа . 98
4.2 Постановка эксперимента 102
4.3 Анализ результатов экперимепта 107
4.4 Интерпретация результатов эксперимента 111
4.4.1 Линейная зависимость времени обработки от размера результата 111
4.4.2 Падение скорости обработки при росте сложности схемы 113
4.4.3 Различные темпы падения средней скорости обработки у сравниваемых программ 114
4.4.4 Более низкая средняя скорость обработки у прототипа на тестах с несложными схемами 115
4.5 Выводы , 116
Заключение 117
Литература
- Обзор существующих разработок медиаторов XML для реляционных систем
- XTABLES на базе расширения SQL
- Перечень компонент и аспектов архитектуры
- Линейная зависимость времени обработки от размера результата
Введение к работе
Актуальность темы
Одним из ключевых аспектов любой информационной системы является организация хранения данных. Эта роль традиционно отводится специализированным системам управления базами данных (СУБД). В связи с успехом реляционной модели подавляющее большинство информационных систем сегодня пользуются услугами реляционных СУБД. Их доминирование объясняется производительностью, наличием прочного теоретического фундамента в виде реляционной теории, огромным количеством исследовательских работ в этой области и мощной поддержкой со стороны бизнеса.
Теидеции современности, такие как глобализация, рост информационной открытости и усиление роли интеграции в бизнесе;, политике и общественной жизни, ставят новые задачи перед дисциплиной информационных систем. Теперь, наряду с другими, имеет решающее значение такая характеристика систем, как простота обмена данными.
Интеграция информационных сред и их модернизация должны отвечать и другому важному требованию, а именно, поддерживать так называемые "унаследованные" системы (legacy systems). Этим термином обозначают системы, базирующиеся на морально устаревших технологиях, но имеющие; в силу ис-торических причин критическое; значение для существования предприятия или организации.
Роль XML (extensible Markup Language - расширяемый язык разметки) как универсального формата обмена данными и, прежде всего, гибкой технологической платформы широко признана. Разнообразные исследовательские проекты в INRIA, AT&T Labs, IBM Almaden и универсистета Висконсина посвящены проблеме отображения XML на реляционные базы данных. Сегодня все ведущие системы управления реляционными базами данных построены на базе результатов этих исследований и обеспечивают экспорт данных в формате XML в той или иной степени. Многие исследователи сходятся во мнении, что реляционные базы данных в общем не являются идеальными для хранения XML, однако в случае, когда XML данные берут свое начало в реляционной базе данных и не требуется эффективного механизма записи, такой
способ хранения может быть, приемлемым. Значительная часть разработок направлена на решения "с чистого листа" и не пригодна для роинжииириит "унаследованных" систем.
Вопросами интеграции информации в реляционных базах данных па основе XML технологий активно занимаются различные иауные коллективы у нас в стране (Мельников А.В., Миронов В.В., Когаловский М.Р.) и за рубежом (М. Fernandez, D. Florescu, J. Shanmagasundaram, I. Tatarinov, D. Suciu). Однако большинство решений в этой области носит преимущественно эвристический характер.
В связи с этим, разработка моделей и методов интеграции информации из реляционных источников является актуальным направлением исследований.
Цель работы и задачи исследования
Целью работы является разработка теоретического подхода к построению виртуальных репозиториев XML для повышения эффективности информационного обмена. Для достижения этой цели должны быть решены следующие задачи:
разработка общей архитектуры виртуальных репозиториев на базе открытых стандартов;
разработка методов реализации функций виртуального репозитория, таких как чтение ресурсов, запись ресурсов и исполнение запросов;
разработка подходов к интеграции информации, реинжинирингу "унаследованных" систем и генерации баз данных на основе виртуального репозитория;
разработка модели иерархических документов в реляционной системе;
исследование эффективности применения предложенных моделей, методов, подходов на основе вычислительного эксперимента.
Методика исследования
Для решения поставленных в диссертационной работе задач был применен широкий спектр методов. Для анализа функций виртуального репозитория
и.его вариантов использования применялся язык моделирования UML. Для построения архитектуры использовались принципы компонентно-ориентированного и аспектно-ориентироваипого дизайна. Для создания модели иерархических документов в реляционной системе и теоретического подхода, основанного на путевых проекциях,'применены реляционная теория, в том числе иеклассическая, допускающая необязательность первой нормальной формы для отношений, теория регулярных языков, алгебра Клини, дополненная расширенным понятием производных регулярных выражений, общая теория множеств, методы доказательства правильности программ на основе логики, методы структурной индукции. Для описания исследовательского прототипа и его функций использовались элементы структурного анализа и дизайна (SADT).
Результаты, выносимые на защиту
методы реализации главных функций виртуального репозитория;
методы реализации административных вариантов использования виртуального репозитория;
модели иерархических документов в реляционной системе;
алгоритмы взаимного преобразования иерархических документов и их проекций;
результаты практических исследований эффективности предложенных методов, моделей и алгоритмов.
Научная новизна
Новыми являются следующие разработки и исследования автора:
альтернативный метод предотвращения аномалий обновления на основе систематического учета зависимостей;
подход к эффективному исполнению запросов XML на основе двухфазной обработки и понятия сужающих запросов;
подход к моделированию иерархических документов со схемами произвольной структуры (включая рекурсивные) па основе вложенных последовательностей кортежей;
теоретический подход к отображению данных из реляционных систем в форму XML, основанный на путевых проекциях.
Практическая значимость и внедрение результатов
Практическую значимость имеют предложенные и разработанные автором:
основанные на модели путевых проекций алгоритмы построения запросов на языке SQL для публикации документов XML из реляционных баз данных;
предложенные методы повышения эффективности такой публикации на основе повторного использования атрибутов и предварительного вычисления соединений;
исследовательский прототип системы публикации документов XML из реляционных баз данных;
исследовательская платформа для иллюстрации предложенного теор-тетического подхода к моделированию XML в реляционных системах.
Предложенные модели и методы внедрены в отделе информационных технологий Государственного ведомства водных путей Германии в качестве опытного программного обеспечения в совокупности с методикой использования. Результаты работы использованы в ряде проектов Исследовательского Центра Информатики города Карлсруэ (Германия) связанных с интеграцией информации в геоинформационных системах, и информационных системах для защиты окружающей среды.
Результаты использования предложенных моделей и методов в реальных проектах показали эффективность разработанных решений.
Программное обеспечение внедрено в учебный процесс на кафедре Вычислительной математики и кибернетики по специальности "Программное обеспечение иычислителыюй техники и вычислительных систем" в виде лабораторных работ для студентов.
Исследования проводились в рамках федеральной целевой программы "Интеграция науки и высшего образования Российской Федерации на 2002-2006 гг." по проекту "Фундаментальные исследования и новые технологии проектирования сложных технических систем" и частично поддержаны грантом РФФИ 03-07-90242 "Интернет-комплекс поддержки выполнения проектов фундаментальных исследований сложных систем с применением интеллектуальных технологий на базе экспертных систем" (2003-2005 гг.)
Разработанное автором программное обеспечение зарегистрировано в Отраслевом фонде алгоритмов и программ Государствен ного координационного центра.
Апробация работы
Основные положения и результаты работы докладывались па следующих научно-технических конференциях: 3-й международной конференции по проблемам технологий для электронных сервисов VLDB TES'2002 (23-24 августа 2002 г., Гонконг, Китай); 4-й Международной конференции по проблемам информатики и информационных технологий CSIT'2002 (18-20 сентября 2002 г., Патры, Греция); 5-й Международной конференции по проблемам информатики и информационных технологий CSIT'2003 (16-18 сентября 2003 г., Уфа, Россия); 14-й Международной конференции "Информатика в защите окружающей среды" Envirolnfo'2003 (24-26 сентября 2003 г., Коттбус, Германия).
Публикации
Основные материалы диссертационной работы опубликованы в 12 научных трудах, в том числе в виде научных статей в 3-х международных и 2-х российских научных изданиях.
Структура работы
Диссертационная работа состоит из 126 страниц машинописного текста, включающего в себя введение, четыре главы, заключение, рисунки, таблицы и список литературы из 76 наименований.
Обзор существующих разработок медиаторов XML для реляционных систем
Для того, чтобы показать сходства и различия существующих подходов к решению проблемы преобразования реляционных данных в документы XML и наоборот, мы будем в дальнейшем использовать следующий пример. Пусть имеется база данных, храпящая каталог географической метаинформации (43). Каталог состоит из записей, каждая из который соответствует некоторому документу. Документы могут располагаться в различных источниках и содержат информацию, описывающие явления и процессы, связанные с земной поверхностью. Это могут быть очеты географических-экспедиций, модели процессов, например, эрозии почв и другие. Схема каталога метаинформации показана па рисунке 1.1.
Документ, как правило, описывает явления и процессы, ограниченные во времени и пространстве. Поэтому записи каталога содержат такие атрибуты, как временной интервал и регион, заданный географическими координатами. Кроме того, каждый документ имеет тематическую направленность, которая может быть задана набором ключевых слов. Документы могут быть вовлечены в -документооборот, характеризующийся набором временых точек и этапов документооборота, сооветствующих этим точкам. Смысл такого каталога заключается в том, что пользователь получает возможность находить необходимые документы по различным критериям поиска: по временному отрезку, географическому региону, ключевым словам или этапам документооборота. Подробно структура такого каталога описывается стандартом ISO 191 "Geographic Metadata" в 4C. Для упрощения примера мы используем лишь малую часть информационных нолей, предписываемых стандартом. Для хранения вышеописанных записей будет использоваться реляционная база данных со структурой, показанной is таблице 1.1.
Первая таблица, Record, храпит основные атрибуты записей каталога. Таблица Keyword содержит реестр ключевых слов, используемых в каталожных записях. Все ключевые слова пронумерованы уникальными номерами для того, чтобы повысить эффективность поиска. Пользователь, задавая параметры поиска, выбирает ключевое слово из списка или из древовидного тезауруса, вместо того, чтобы вводить его как тест. Это исключает ошибки, связанные с неправильным написанием слов, а также позволяет задействовать такие возможности тезауруса, как поиск по синонимам или связанным терминам. Третья таблица, Keywords, является разверткой отношения "многие к многим", определенного между сущностями, отраженными в таблицах Record и Keyword. Таблица Workflow содержит один или более кортеж на каждую запись в таблице Record, по одному на каждый этап документооборота. Атрибут Stage имеет фиксированный набор значений, таких как "creation" (со здание), "publication" (опубликование), "revision" (пересмотр). Для того, чтобы представить упомянутый выше каталог в виде набора документов XML, необходимо каким-либо образом определить формальную структуру этих документов, а также описать процесс получения документов из таблиц и наоборот. Для определения формальной структуры будет использован язык XML Schema ([72]). Однако, для повышения наглядности мы будем использовать синтаксическую диаграмму вместо текстовой нотации. Диаграмма схемы XML-для документов из примера показана на рисунке 1.2. Определения элементов записываются их именами, заключенными в угловые скобки; определения атрибутов - именами с предшествующим символом "@"; определения типов - именами типов без дополнительных знаков; определения литералов заключены в двойные кавычки. Подписи над линиями обозначают кратность частиц (например, "0.. " обозначает minOccurs—"0" maxOccurs -"unbounded"), а также расширения ("+" - extension) или сужения ("-" - restriction) типов данных. Каждый документ XML, еоответвующий этой схеме, имеет корпе —@id xs:integer - title -—xs:string — temporalCoverage -- spatialCoverage 0.. xs:integer —xs:date -xs: string вой элемент record, который соответствует записи в каталоге. Этот элемент содержит атрибут id, еоответвующий уникальному номеру записи. Внутри элемента record находятся дочерние элементы, сгруппированные в последовательность. Эта последовательность включает себя название документа (элемент title), временной интервал (элемент temporalCoverage с атрибутами start -начало интервала и end - конец интервала), географический элементов keyword с атрибутом zd - уникальный номер ключевого слова и содержимым - текст ключевого слова), этапы документооборота (один или более элементов workflow с двумя дочерними элементами date - временная точка - и stage - название этапа документооборота).
XTABLES на базе расширения SQL
Под общим названием "XTABLES" здесь будет пониматься серия работ, проведенных в исследовательском центре IBM Almaden, которые в итоге привели к появлению проекта XTABLES. Мы остановимся на двух наиболее значимых из них. Первая [44] проводит сравнительный анализ известных подходов к решению задачи формирования XML Документов из реляционных данных. В качестве языка для описания отображения отношений на XML документы используется язык SQL, дополненный необходимыми функциями. Для нашего примера такое описание показано далее. SELECT RECORD (г.ID,г.Title,г.StartDate.r.EndDate, г.WestBL, г.EastBL, г. North, г. South, (SELECT XMLAGG(KEYWORD(k.ID, k.Keyword)) FROM Keyword k, Keywords ks WHERE k.ID = ks.KeywordID AND ks.RecordID = r.ID), (SELECT XMLAGG(WORKFLOW(w.Stage, w.Date)) FROM Workflow, w WHERE w.RecordID = k.ID) FROM Record r;}
В запросе присутствуют так называемые конструкторы (RECORD, KEYWORD и WORKFLOW) и аггрегатная функция XMLAGG. Конструкторы являются сред ством преобразования кортежей, возвращаемых командой SELECT, во фрагменты документов XML. Используя псевдосинтаксис для конструкторов, их можно представить в виде: Define XML Constructor RECORD( recordID: integer, recordTitle: varchar(30), startDate: date, endDate: date, west: float, east: float, north: float, south: float, keywordList: xml, workflowList: xml) AS і record id=$recordID title $recordTitle /title temporalCoverage start=$startDate end=$endDate/ spatialCoverage west=$west east=$east north=$north south=$south/ $keywordList SworkflowList /record } Define XML Constructor KEYWORD"( keywordID: integer, keyword: varchar(20)) AS C keyword id=$keywordID $keyword /keyword Define XML Constructor WORKFLOW( stage: varchar(lO), sDate: date) AS { workflow date $sDate /date stage $stage /stage /workflow }
Функция XMLAGG используется для создания фрагментов XML из отдельных частей. Она подобна стандартным аггрегатным функциям SQL, таким как COUNT, SUM, но вместо арифметических вычислений она производит объединение нескольких фрагментов XML в один. Приведенный SQL запрос лучше всего рассматривать сверху вниз. Запрос верхнего уровня получает записи из таблицы Record. Для каждой записи связанные (кореллированпые) подзапросы выбирают информацию о ключевых словах и этапах документооборота из таблиц Keyword, Keywords и Workflow. Эти подзапросы возвращают фрагменты документов, сформированные функцией XMLAGG.
Теперь обсудим различные способы исполнения приведенного запроса, рассмотренные в 44]. Эти способы сгруппированы в пространство решений, базирующееся на основных отличиях документов XML от реляционных га-блиц, а имеенно, тегах и вложенной структуре, которые приходится добавлять в процессе преобразования. Один из подходов заключается в введении тегов на финальном этапе обработки запроса (позднее добавление тегов), тогда как другой предполагает введение тегов на более ранних этапах (раннее добавление тегов). Похожим образом определяются позднее и раннее структурирование. Третим измерением пространства решений является распределение вычислительной работы между СУБД и промежуточным ПО. Одна группа подходов перекладывает основную часть работы на СУБД ("внутри СУБД"), другая использует СУБД лишь для извлечения данных ("снаружи СУБД"). Нужно заметить, что сочетание раннего добавления тегов и позднего структурирования не возможно по той причине, что документы XML без структуры не имееют смысла. Мы сохраним названия подходов, приведенные в [44], и кратко опишем каждый из них. Хранимая процедура
Это один из самых простых способов структурирования реляционных данных для преобразования их в XML формат, который предполагает отсутствие в СУБД таких механизмов, как возможность создания конструкторов и аггро гатных функций. Он заключается в формировании вложенного множества запросов итеративно следующим образом: г: Кортеж; Для всех г из {SELECT FROM Record) -С Вывести( гесогс1 id= " ,r.ID, " ); BHBecTH(c title ,r.Title, /title ); Вывести C temporalCoverage start= " ,r.StartDate, " end="\r.EndDate, "/ ); BbiBecTH( spatialCoverage west=" .r.WestBL, east=,",r.EastBL, " north= .r.NorthBL, " south= ",r.SouthBL, "/ ); к: Кортеж; Для всех к из (SELECT к. FROM Keyword к, Keywords ks WHERE к.ID = ks.KeywordID AND ks.RecordID = r.ID) і Вывести( keyword id="»,fc.ID, " , k. keyword, /keyword ) Кортеж; Для всех w из (SELECT FROM Workflow w WHERE w.RecordID = r.ID) { BbmecTH( workflow ); BHBecTH( date ,w.Date, /date ); Вывести0 stage . ,w.Stage, /stage ); Вывести( /иогкг"1ои ) ; } Вывести( /record ); }
Название данного подхода объясняется тем, что приведенный выше алгоритм эффективнее всего реализуется в виде хранимой процедуры, написанной на языке, специфичном для конкретной СУБД (таком, как PL/SQL, Transact-SQL). Как видно из алгоритма, этот подход практически реализует вложенный цикл соединения двух отношений, выполняемый за пределами СУБД. Это означает, в частности, что такой подход должен значительно проигрывать в эффективности другим, базирующимся на использовании
Перечень компонент и аспектов архитектуры
Функциональные требования целесообразно разделить на уровни, которые принято называть уровнями соответствия. Первые два уровня соответствия заимствованы из спецификации инициативы XML:DB. Первый уровень был разбит на два подуровня в связи с виртуальным характером репозитория. Следующие уровни являются экстраполяцией первых двух с учетом других функций, описанных в той же спецификации. Уровни соответствия имеют следующее содержание:
1. Концепция виртуального репозитория как иерархии коллекций ресурсов. Концепция коллекции расширена по сравнению со спецификацией XML:DB таким образом, что родительская колекция всегда является генерализацией дочерних. Операция объявления коллекции определена путем задания ее положения в иерархии и схемы ресурсов. Схема ресурсов должна быть согласована со схемой родительской коллекции. Элементы схемы могут дополняться четырьмя видами аннотаций, содержащими инструкции по извлечению, удалению, добавлению и модификации данных источника, а также аннотациями, содержащими ука-. зания по ограничению доступа. Операция-удаления коллекции из репозитория.
(a) Операция извлечения ресурса из коллекции. Так как репозиторий виртуален, данный подуровень имеет смысл даже в отсутствии реализации следующего подуровня, включающего создание ресурсов. Коллекция может оказаться наполненной сразу же после объявления.
(b) Операции создания ресурса в коллекции и удаления ресурса из коллекции.
2. Операция исполнения запроса, сформулированного на языке XPath. Запрос может быть обращен к коллекции ресурсов либо к полученной с помощью другого запроса последовательности результатов.
3. Операция частичного обновления ресурсов внутри коллекции. Один из вариантов протокола, которого следует придерживаться мри реализации - XUpdate, описан в спецификациях XML:DB.
4. Концепция транзакции. Операции начала, завершения и отката транзакции.
В соответствии с [29], указанные уровни соответствия вместе с подуровнями образуют черты (features) системы. Общесистемные требования, такие как отел ежи ваемость и безопасность, также соответствуют чертам, однако их декомпозицию правильнее проводить не на компоненты, как в [29], а на аспекты ([47]). Реализация таких требований компонентами ведет к появлению "вездесущих" компонент и превращению кода остальных компонент в "спагетти" вызовов. Кроме того, некоторые черты реализуются комбинацией из компонент и аспектов (например, поддержка транзакций). Требования расширяемости и развертываемое оказывают влияние на выбор базиса для построения архитектуры. Основой архитектуры вирутального репозитория служит абстрактная компонентная архитектура, описанная в [29]. Посколь-ку одной из целью создания последней была расширяемость, это требование можно считать ложится па реализацию контейнера компонент. Те аспекты, которые могут быть сведены на уровень межкомпонентного взаимодействия, допускают реализацию в контейнере компонент. Например, от-слеживаемость межкомпонентных вызовов, контроль доступа, ведение журнала транзакций. Так как коммуникацией компонент выполненным при корректном использовании. Задача обеспечения развертываемости управляет контейнер, компоненты не обязаны находиться в одном месте, а могут быть распределены. Для обеспечения взаимной коммуникации распределенных контейнеров может использоваться инфраструктура Web-сервисов. На основе сервисов, предоставляемых отдельными компонентами, контейнер способен создавать соответствующие описания в формате WSDL и осуществлять диспетчеризацию межкомпонентных вызовов на основе протокола SOAP. Для идентификации необходимых компонент, а также для целей балансирования нагрузки и снятия отказов, может использоваться система UDDI.
Обобщенный перечень компонент, составляющих архитектуру виртуального репозитория, имеет следующий вид: 1. Менеджер коллекций. 2. Обработчик аннотированных схем (генерирует операционные компоненты). 3. Настраиваемые оболочки чтения, удаления, добавления и модификации данных ресурсов. 4. Модуль проверки на аномальность. 5. Преобразователь запросов. 6. Преобразователь схем. 7. Менеджер транзакций. 8. Модуль контроля доступа. 9. Журнал транзакций.
Реляционные базы данных, обслуживающие реиозиторий, могут находиться под управлением различных СУБД и располагаться на разных узлах вычислительной сети (будь то локальная, корпоративная, глобальная сеть или сеть какого-либо другого типа). Именно данное обстоятельство вкладывается в смысл гетерогенности этих баз данных. Коллекции ресурсов, напротив, являются однородными в том смысле, что способны "отображать" информацию только из одной базы данных1. Ресурсы в коллекции должны соответствовать некой схеме XML. Различные коллекции могут иметь как разные, так и одинаковые схемы - архитектура не накладывает на это никаких ограничений. Схема XML (пока что неаннотированная) выполняет здесь три основные функции:
1. Клиентский формат данных. Приложение, пользующееся репозитори-ем, или какой-либо другой клиент вправе рассчитывать на то, что документы, полученные от него, соответствуют оговоренной схеме XML. Это позволяет разгрузиті, клиента от большей части работы по контролю исходных данных, так как она может быть выполнена стандартными средствами из инструментария платформы XML.
2. Основа для описания отображения реляционных данных в XML форму и наоборот. Применение в этих целях схемы XML как открытого стандарта позволяет снизить время обучения заинтересованных людей работе по созданию таких отображений, а также повысить шансы повторного использования артефактов разработки (очень вероятно, что схемы XML использовались в месте внедрения виртуального репозито-рия XML и ранее для описания структуры данных).
3. Средство поддержки оптимизации запросов. Возможности оптимизации запросов всегда тем шире, чем больше информации имеется о данных, к которым обращен запрос. Самым простым примером оптимизации выполнения запросов XPath при известной схеме XML может служить отсечение путей, заведомо не ведущих ни к одной единице данных (при указании в пути отсутствующих элементов или атрибутов).
Линейная зависимость времени обработки от размера результата
В качестве кандидатов для сравнительного анализа первоначально были выбраны два продукта: SQLXML фирмы Microsoft (является составной частью MS SQL Server 2000) и XMLDB фирмы Oracle (является составной частью СУБД Oracle 9i Release 2 и Oracle 10g). К сожалению, вычислительный эксперимент показал, что продукт XMLDB получает некорректный результат для использованных тестов. Поэтому сравнение производительности выполнялось только между исследовательским прототипом и продуктом SQLXML.
Для того, чтобы иметь возможность проводить вычислительный эксперимент в автоматическом режиме, было разработано соответствующее программное обеспечение. Оно выполняет следующие функции: Для каждой серии тестов генерируются: - Процедура DDL (Data Definition Language) для создания в базе данных необходимых тестовых таблиц и ограничений. При этом каждому типу элемента соответствует одна таблица. Эта таблица содержит ключевой атрибут ID и в случае некорневого типа элемента - атрибут ParentID, ссылающийся на кортеж в таблице родительского типа элемента. Кроме того, для каждого атрибута, содержающегося в типе элемента, присутствует атрибут в таблице. На каждую такую таблицу накладывается ограничение первичного ключа (атрибут ID), и на таблицы некорневых типов элементов - ограничение внешнего ключа, связывающее атрибут Parent ID с атрибутом ID таблицы родительского типа; - Схема XML соответствующей глубины и ширины, аннотированная в соответствии с правилами продукта SQLXML; - Схема XML соответствующей глубины и ширины, аннотированная в соответствии с синтаксисом, принятым в исследовательском прототипе (эта схема отличается от предыдущей только аннотациями); - Процедура DDL для очистки базы данных от тестовых таблиц и ограничений. Для каэюдого теста генерируется набор данных, необходимый для получения тестовых документов. Набор данных производится в виде процедуры DML (Data Manipulation Language), добавляющей кортежи с необходимой информацией в тестовые таблицы. Так как внутри одной серии тесты отличаются лишь размером, для ускорения процедуры тестирования можно каждый раз при переходе к тесту со следующим размером не стирать все данные предыдущего теста и вносить новые, а лишь дополнять их новыми. При этом, в соответствии с описанным выше строением тестового документа, каждый из элементов предыдущего теста (кроме листовых) получает один дополнительный дочерний элемент, а также добавляется один корневой элемент.
Для заданного плана эксперимента производится тестирование по следующему сценарию: 1. Прочитать из входного файла параметры очередной серии: глубина, ширина схемы, начальный и конечный размеры тестов. 2. ТІолучить все необходимые схемы и процедуры для текущей серии. 3. Создать в базе данных необходимые таблицы и ограничения. 4. Выполнять далее для каждого значения размера теста (от начального до конечного) следующее: (a) Получить набор данных для тестового документа текущего размера; (b) Загрузить набор в базу данных; (c) Провести тест с SQLXML, записать время обработки и размер результата в журнал; (d) Провести тест с прототипом, записать время обработки и размер результата в журнал; 5. Очистить базу данных от тестовых таблиц и ограничений; 6. Перейти к следующей серии.
Итак, была разработана система автоматизированного проведения эксперимента по сравнению производительности продукта SQLXML и исследовательского прототипа при решении задачи публикации документов XML из реляционных источников. Каждый тест характеризуется тремя параметрами: глубина, ширина и размер, которые в определенном смысле являются мерами сложности публикуемых документов. Составлен план эксперимента, подходящий для имевшейся в распоряжении компьютерной системы.
В этом разделе проводится анализ результатов поставленного вычислительного эксперимента с целью определения условий, при которых исследовательский прототип превосходит или уступает по производительности продукту, выбранному для сравнения.
Для каждой серии тестов проведенного эксперимента была получена последовательность "пятерок" со следующими компонентами: 1. Размер теста. 2. Время обработки теста продуктом SQLXML (в миллисекундах). 3. Размер текстового файла с результатом, полученным продуктом SQL XML (в байтах). 4. Время обработки теста исследовательским прототипом (в миллисекундах). Пример последовательности пятерок для серии тестов с глубиной схемы 6 и шириной схемы 2 представлен в таблице 4.3. Было установлено, что значения
