Содержание к диссертации
Введение
Глава 1 Активные СУБД 9
1.1 Активные СУБД и триггеры 9
1.1.1 Триггеры 10
1.1.2 Общая форма определения триггеров 11
1.1.3 Язык определения триггеров 11
1.1.4 Семантика выполнения триггеров 16
1.1.5 Архитектура активных СУБД 22
1.1.6 Основные аспекты реализации активных СУБД 29
1.2 Триггеры в реляционных СУБД 33
1.2.1 Триггеры в стандарте SQL 33
1.2.2 Методы реализации триггеров в РСУБД 38
1.3 Выводы 44
Глава 2 Проблемы и задачи реализации поддержки активного поведения XML-СУБД 45
2.1 Платформа XML 45
2.1.1 Расширяемый язык разметки XML 45
2.1.2 Язык запросов XQuery 47
2.1.3 Язык модификаций XML-данных 51
2.2. Аспекты реализации XML-СУБД 53
2.2.1 Связи между узлами XML-документа в XML-СУБД 54
2.2.2 Описывающая схема 54
2.2.3 Нумерующая схема 55
2.3 Триггеры для баз XML-данных: формирование требований и анализ применимости существующих методов реализации 56
2.3.1 Анализ применимости методов реализации триггеров РСУБД 58
2.3.2 Существующие методы реализации XML-триггеров 61
2.4 Выводы 63
Глава 3 Язык определения и семантика выполнения XML-триггеров 65
3.1 XML-триггеры на модификацию данных 65
3.1.1 Инициирующие события 66
3.1.2 Выполнение, ориентированное на экземпляр, и выполнение, ориентированное на набор экземпляров 68
3.1.3 Действия 69
3.1.4 Выполнение нескольких XML-триггеров одной группы 72
3.1.5 Видимость изменений данных 72
3.1.6 Пример 73
3.2 XML-триггеры на выборку данных 77
3.2.1 Инициирующие события 78
3.2.2 Действия 79
3.2.3 Взаимодействие с операциями модификации 80
3.2.4 Выполнение нескольких XML-триггеров 81
3.2.5 Пример 81
3.3 Выводы . 83
Глава 4 Методы реализации XML-триггеров для XML-СУБД 85
4.1 Методы реализации XML-триггеров на модификацию данных 85
4.1.1 «Наивный» метод реализации XML-триггеров на модификацию данных 86
4.1.2. Метод реализации XML-триггеров на модификацию данных, основанный на использовании фиксаторов на описывающей схеме 95
4.1.3 Метод реализации XML-триггеров на модификацию, основанный на объединении планов выполнения путевых выражений 103
4.1.4 Экспериментальная оценка методов реализации XML-триггеров на модификацию данных 116
4.2. Методы реализации XML-триггеров на выборку данных 121
4.2.1. «Наивный» метод реализации XML-триггеров на выборку данных... 122
4.2.2. Метод реализации XML-триггеров на выборку данных, основанный на использовании теневого механизма 124
4.3 Выводы 129
Заключение 130
Литература 131
- Основные аспекты реализации активных СУБД
- Анализ применимости методов реализации триггеров РСУБД
- Метод реализации XML-триггеров на модификацию, основанный на объединении планов выполнения путевых выражений
- Метод реализации XML-триггеров на выборку данных, основанный на использовании теневого механизма
Введение к работе
Актуальность темы
Широкое использование языка XML в качестве основного средства для представления слабоструктурированных данных привело к росту объемов XML-данных, которыми необходимо эффективно управлять. Это послужило толчком к появлению нового класса систем управления базами данных, изначально спроектированных с учетом XML-модели данных, так называемых XML-СУБД.
На сегодняшний день XML-СУБД достигли определенного этапа зрелости, однако в них все еще отсутствуют многие развитые механизмы, аналогичные тем, что успешно используются в индустриальных реляционных СУБД. Одним из таких механизмов является поддержка активного поведения XML-СУБД. Основным средством определения и реализации активного поведения СУБД являются триггеры. Триггеры предоставляют единообразную и удобную основу, которая может быть использована как для реализации внутренних функций СУБД - поддержки ограничений целостности, представлений, авторизации, сбора статистик, мониторинга и оповещения; так и для внешних приложений. Яркими примерами внешних приложений, построенных с использованием активного поведения СУБД, являются экспертные системы, перерабатывающие большие объемы данных, и системы управления потоками задач.
Существующие механизмы триггеров реляционных СУБД неприменимы для XML-СУБД, поскольку не учитывают слабоструктурированную природу и иерархичность XML-данных. Таким образом, поддержка активного поведения XML-СУБД требует разработки новых XML-триггеров, учитывающих специфику XML-модели данных, а также эффективных методов их реализации в XML-СУБД. Необходимость в решении этих задач и определяет актуальность диссертационной работы.
Цель и задачи работы
Целью диссертационной работы является исследование и разработка методов поддержки активного поведения XML-СУБД. Достижение этой цели определяет необходимость решения следующих задач:
Разработка языка определения XML-триггеров, основанного на XML-модели данных.
Разработка семантики выполнения XML-триггеров, учитывающей специфику XML-модели данных.
3. Разработка методов реализации XML-триггеров в системах управления базами XML-данных.
Научная новизна
Научной новизной обладают следующие результаты диссертационной работы:
Разработан язык определения XML-триггеров на модификацию данных и XML-триггеров на выборку данных.
Разработана семантика выполнения XML-триггеров на модификацию данных и XML-триггеров на выборку данных.
Разработаны методы эффективной реализации XML-триггеров на модификацию данных: метод, основанный на использовании фиксаторов на описывающей схеме, и метод, основанный на объединении планов выполнения путевых выражений.
Разработан метод эффективной реализации XML-триггеров на выборку данных, основанный на использовании теневого механизма.
Практическая значимость
Разработанные язык определения и семантика выполнения XML-триггеров могут служить основой для реализации поддержки активного поведения систем управления базами данных, которые обладают поддержкой XML.
Разработанные методы могут быть использованы для реализации предложенных XML-триггеров в XML-СУБД.
На основе предложенных методов реализации XML-триггеров на модификацию данных разработана подсистема поддержки XML-триггеров на модификацию данных в промышленной XML-СУБД Sedna, разрабатываемой в ИСП РАН.
Апробация работы и публикации
По теме диссертации опубликовано восемь работ [1-8]. Основные положения работы докладывались на следующих конференциях и семинарах:
на первом и втором весенних коллоквиумах молодых исследователей в области баз данных и информационных систем (SYRCoDIS) (2004 и 2005 гг);
на семинаре шестнадцатой международной конференции по базам данных и экспертным системам (DEXA), посвященном логическим аспектам и приложениям ограничений целостности (LAAIC)(2005 г);
на семинаре семнадцатой международной конференции по базам данных и экспертным системам (DEXA), посвященном средствам управления XML-данными (XANTEC) (2006 г);
на двенадцатой международной конференции студентов, аспирантов и молодых ученых «Ломоносов-2005»;
на семинаре «Проблемы современных информационно-вычислительных систем» под руководством д.ф.-м.н, профессора ВасенинаВ.А. (2005 г);
на сто тринадцатом семинаре Московской Секции ACM SIGMOD (2006 г);
на семинаре двадцать четвертой британской национальной конференции по базам данных, посвященном управлению данными в Интернет (BNCODWebim) (2007 г).
Структура и объем диссертации
Основные аспекты реализации активных СУБД
Оценка условий и выполнение действий триггеров в случае встроенной архитектуры часто реализуется через подсистемы выполнения запросов СУБД, а в случае многоуровневой архитектуры - посредством передачи определенных команд на выполнение СУБД. Таким образом, используются механизмы управления параллельным выполнением операций СУБД, от них не требуется дополнительной специальной функциональности. Однако для управления параллельным выполнением команд, выполняемых менеджером триггеров (см. выше), могут потребоваться дополнительные возможности механизмов управления параллельным выполнением операций СУБД. Тем не менее, дополнительной специальной функциональности не потребуется, если триггеры являются объектами схемы базы данных наравне с другими объектами (например, индексами), или трактуются как объекты первого класса базы данных (см. подраздел 1.1.3).
Особого внимания требует процесс мониторинга возникновения инициирующих событий. Если мониторинг происходит на более высоком уровне, чем механизм управления параллельным выполнением операций (это возможно в многоуровневой или (реже) встроенной, архитектуре с обработкой триггеров на стадии выполнения операций), то для выявления возникновения инициирующего события часто требуется выполнение дополнительных запросов к базе данных. Для избежания блокировки большого количества элементов данных (и, как следствие, снижения пропускной способности системы) необходимо при мониторинге возникновения инициирующих событий минимизировать количество таких запросов.
Восстановление после сбоев в традиционных СУБД обычно происходит при помощи системного журнала, что гарантирует учет работы всех зафиксированных до сбоя транзакций в состоянии базы данных после ее восстановления. Активная СУБД может следовать таким же основным принципам, но с учетом некоторых особенностей. При несвязанном выполнении транзакций сбой может произойти во время выполнения инициированной транзакции. К этому моменту исходная транзакция уже зафиксирована. Процесс восстановления после такого сбоя должен учитывать связь исходной и инициированной транзакций, например, не восстанавливать работу исходной транзакции, если нет возможности перезапустить инициированную транзакцию. Это может быть реализовано посредством расширения системного журнала.
В активной базе данных создание, удаление, модификация, активация и деактивация триггеров должны контролироваться компонентом, ответственным за авторизованное выполнение операций, то есть, необходима авторизация операций работы с триггерами. Обычно авторизация подразумевает наделение пользователей привилегиями, необходимыми для выполнения той или иной операции. Таким образом, набор возможных привилегий должен быть расширен привилегиями, необходимыми для работы с триггерами. Отметим, что проверка условий и выполнение действий триггеров также должно быть авторизовано. Поскольку условия и действия триггеров часто представляют собой операторы языка базы данных, для авторизации их выполнения не требуется дополнительная специальная функциональность компонента, ответственного за авторизованное выполнение операций.
В активных СУБД при выполнении триггеров возможно возникновение ошибок, которые, как и любые ошибки, возникающие при работе СУБД, должны быть обработаны определенным образом. Ошибки при выполнении триггеров могут возникать по следующим причинам. Элементы данных, необходимые для проверки условия или выполнения действия, были удалены. Такие ошибки невозможны, если активная СУБД контролирует зависимость существующих триггеров от элементов данных. Пользователь, от имени которого происходит проверка условия или выполнение действия триггера, не обладает необходимыми привилегиями. В условии или действии триггера ошибка генерируется при выполнении соответствующих команд базы данных. Количество обработанных триггеров превышает установленный в системе предел - максимальное количество обрабатываемых триггеров при очередном запуске алгоритма выполнения (см. замечания о завершение выполнения в подразделе 1.1.4). Эта ошибка невозможна, если в активной СУБД не устанавливается такой предел. Если же триггеры, инициируя взаимный запуск, образуют бесконечный цикл, возможно возникновение некоторой системной ошибки, например, по причине нехватки памяти. Откат транзакции, в рамках которой происходит проверка условия или выполнение действия триггера, по причине возникновения тупиковой ситуации одновременно выполняющихся в системе транзакций. Наиболее частой реакцией на указанные ошибки активной СУБД является откат транзакции, в рамках которой происходила обработка триггера. Однако, в случае несвязанного выполнения, реакция должна быть более сложной, например, откат инициированной и исходной транзакций. Мониторинг выполнения триггеров Возможности мониторинга выполнения триггеров могут быть полезны, как при разработке приложений активной СУБД, так и для мониторинга активности триггеров во время работы приложения активной СУБД. Такой мониторинг может включать: возможность трассировки проверки условий и выполнения действий триггеров; отображение набора триггеров, сработавших на данный момент; возможность определения события, инициировавшего срабатывание определенного триггера, а также происхождение этого события; возможность мониторинга переходных значений определенного триггера. Оптимизация процесса проверки условий
Часто процесс проверки условий триггеров и выполнение действий требуют значительных накладных расходов. Как проверка условия, так и выполнение действия триггера может представлять собой выполнение ресурсоёмких операций над базой данных, вызов «дорогих» процедур. Однако операции или процедуры, специфицированные в действии триггеров, являются неотъемлемой их частью -посредством выполнения этих процедур и достигается специфицированное активное поведение. В то же время выполнение операций или процедур при проверке условий триггеров можно оптимизировать.
Среди методов оптимизации процесса проверки условий триггеров в активных СУБД особое внимание заслужило применение методов жкрементного вычисления условий. Эффективность вычисления условия инкрементными методами достигается за счет использования результатов предыдущего вычисления данного условия и анализа модификаций базы данных, произошедших с момента последнего вычисления этого условия. С учетом того, что при очередном запуске алгоритма выполнения триггеров одно и то же условие может проверяться несколько раз, инкрементное вычисление при проверке условия может значительно повысить производительность системы. Применение методов инкрементного вычисления для оптимизации/работы активных СУБД подробно рассмотрено в [19].
Анализ применимости методов реализации триггеров РСУБД
В завершении этого обзора отметим, что в стандарте не запрещается определение нескольких триггеров, ассоциированных с одной предметной таблицей, относящихся к одной и той же категории (BEFORE или AFTER) И срабатывающих по одному и тому же событию. Таким образом, при возникновении события, инициирующего срабатывание всех таких триггеров, система должна выбрать порядок, в котором они будут выполняться. В стандарте принято решение упорядочивать все триггеры, ассоциированные с одной предметной таблицей, относящиеся к одной и той же категории (BEFORE или AFTER) И срабатывающие по одному и тому же событию, на основе временных меток, зафиксированных для каждого триггера при его определении (при выполнении оператора CREATE TRIGGER). В стандарте не специфицируется точность временной метки. Таким образом, порядок выполнения триггеров с неразличимыми временными метками определяется реализацией.
В проекте под руководством М. Стоунбрейкера по разработке РСУБД POSTGRES [15] поддержка активных правил на уровне управляющего ядра системы являлась одной из ключевых задач при проектировании и разработке системы. Таким образом, в POSTGRES подсистема поддержки активных правил является внутренней основой для многих других компонентов системы, одновременно предоставляя мощные функциональные возможности пользователям. Изучение методов реализации активных правил в POSTGRES в контексте данной работы представляет интерес еще и потому, что в POSTGRES поддерживаются два вида правил. Первый из них представляют правила, срабатывание которых может быть инициировано операцией модификации {append, delete или replace) указанного отношения или столбца отношения. Ко второму виду относятся правила, срабатывающие при операциях выборки из некоторого отношения или столбца отношения.
Языком РСУБД POSTGRES является POSTQUEL. Язык определения активных правил в POSTQUEL во многом служил прототипом при создании спецификации триггеров, вошедшей позже в стандарт SQL. Следует, однако, отметить, что синтаксис и семантика выполнения триггеров POSTQUEL и триггеров стандарта SQL имеют некоторые различия (в частности, в SQL отсутствует возможность устанавливать срабатывание триггера при операциях выборки).
Событием (event) может быть одна из операций языка POSTQUEL: выборка данных (retrieve); вставка кортежа (append); удаление кортежа (delete) и замена кортежа. Объектом (object), выборка данных из которого, или модификация которого приводит к срабатыванию правила, может являться отношение или столбец отношения. Условием (qualification) является предикат, выраженный на языке POSTQUEL. Действием (action) является последовательность команд языка POSTQUEL, причем операции выборки данных возможны только в правилах, срабатывание которых происходит при выборке данных. Если в определении правила присутствует ключевое слово instead, то при срабатывании правила должны быть выполнены только команды действия правила. В противном случае должны быть выполнены как операция, инициирующая срабатывание, так и команды действия правила. Внутри условия и действия правила допускается использование переходных значений NEW И CURRENT. Выполнение правил является немедленным, возможен рекурсивный вызов правил.
В POSTGRES существуют две альтернативные реализации правил. Первая реализация - подсистема поддержки правил на уровне кортежей (Tuple Level System) - обрабатывает правила динамически во время обращения к конкретным кортежам. Архитектура такой реализации является встроенной, с поддержкой правил на стадии выполнения операций. Вторая реализация - подсистема поддержки правил посредством перезаписи запросов (Query Rewrite Subsytem) -основана на анализе и перезаписи команд пользователя на стадии их компиляции и представляет собой пример встроенной архитектуры с обработкой правил на стадии компиляции операций. В определении триггера ключевые слова tuple и rewrite определяют одну из двух подсистем выполнения правил, посредством которой данное правило должно поддерживаться.
Подсистема поддержки правил на уровне кортежей Подсистема поддержки правил на уровне кортежей (ППК) состоит из модуля определения правил и модуля, называемого менеджером правил. Работа подсистемы ППК основана на использовании специальных объектов базы данных: фиксаторов правил и заглушек правил. Фиксаторы правил При определении нового правила модуль определения правил записывает необходимую информацию в системные таблицы и расставляет соответствующие фиксаторы правил. Фиксаторы правил - долговременные объекты, хранящиеся на диске. Наличие фиксатора правила в кортеже означает, что при возникновении соответствующего события для этого кортежа должно сработать правило, соответствующее этому фиксатору. Фиксатор содержит следующую информацию: имя правила; тип фиксатора; идентификатор плана выполнения правила. Существуют два типа фиксаторов правил: фиксаторы уровня кортежей и фиксаторы уровня отношения. Фиксаторы правил уровня кортежей хранятся в кортежах отношения. Фиксаторы уровня отношения хранятся в единичном экземпляре в заголовке отношения.
При определении нового правила модуль определения правил расставляет фиксаторы правил на кортежи отношения на основании частичного вычисления условия правила. Вычисляется та часть условия, которая зависит от значения атрибутов данного отношения и/или констант, а любые соединения в условиях правил при расстановке фиксаторов игнорируются. Фиксаторы правил расставляются на кортежи отношения, удовлетворяющие этой вычисленной части правила. Таким образом, при определении правила «помечается» надмножество кортежей, удовлетворяющих условию правила, а при срабатывании правила происходит вычисление остальной части условия с целью определить, полностью ли удовлетворяет условию данный кортеж. Причина такой расстановки фиксаторов на надмножество кортежей состоит в том, что если бы расстановка фиксаторов происходила на основании полного вычисления условия, включая соединения (то есть фиксаторы правил расставлялись бы на точное множество кортежей, удовлетворяющих условию правила), то поддержание корректности фиксаторов при модификациях отношений, на основании которых вычисляется условие, было бы слишком дорогостоящим.
Метод реализации XML-триггеров на модификацию, основанный на объединении планов выполнения путевых выражений
В этом разделе представлен третий из предлагаемых в данной работе методов реализации XML-триггеров на модификацию - метод, основанный на объединении планов выполнения путевых выражений (далее - метод с общим выполнением). Данный метод позволяет эффективно осуществлять поиск XML-триггеров, инициируемых некоторой операцией модификации, за счет следующих двух механизмов. Во-первых, на стадии компиляции на основе анализа операции модификации и имеющихся в системе XML-триггеров происходит сужение набора рассматриваемых XML-триггеров. Во-вторых, для OF-выражений суженного набора XML-тригтеров и XPath-выражения, определяющего целевые узлы изменения в операции модификации, специальным образом строится объединенный план выполнения (процесс построения такого объединенного плана детально описан ниже). Такой объединенный план выполнения позволяет вычислить последовательность целевых улов изменения и при этом - в процессе выполнения плана - определить инициируемые XML-триггеры и узлы, для которых они должны сработать.
В отличие от предыдущего метода, данный метод позволяет реализовать XML-триггеры с произвольными XPath-выражениями (в том числе и содержащими предикаты). Однако и этот метод имеет ограничение, а именно - он применим только для операций модификации, целевые узлы изменений которых задаются посредством XPath-выражений. Причина такого ограничения заключается в том, что построение объединенного плана для произвольных XQuery-выражений является значительно более сложной задачей, рассмотрение которой выходит за рамки данной работы.
Отметим, что ограничение описываемого метода является вполне допустимым. Причина в том, что в подавляющем большинстве XUpdate-выражений, встречающихся на практике, для задания целевых узлов изменения используется только подмножество языка XQuery - язык XPath. Как уже было отмечено ранее, именно XPath предназначен для адресации частей XML-документа, в то время как XQuery расширяет XPath возможностями, необходимыми для преобразования документов, такими как сортировка, построение элементов и атрибутов и другими. Таким образом, использование только XPath-выражений при задании целевых узлов изменения в операциях модификации, в частности, позволяет избежать ошибок времени выполнения, когда изменяемым узлом оказывается узел временного хранения (что возможно только при использовании конструкторов элементов языка XQuery).
Как и в случае метода с фиксаторами, здесь мы подразумеваем, что метод с общим выполнением основывается на «наивном» методе, изменяя при этом следующие части «наивного» метода: определение XML-триггеров; оба алгоритма поиска инициируемых XML-триггеров (алгоритм 4.9 и алгоритм 4.10); процедура вычисления целевых узлов изменения. Во всем остальном метод с общим выполнением не отличается от «наивного».
Метод с общим выполнением выдвигает такие требования к прирожденной XML-СУБД как поддержка в прирожденной XML-СУБД описывающей схемы, а также наличие возможности расширения модели выполнения XQuery-запросов следующим образом. Объекты, полученные как промежуточный результат выполнения XQuery-запроса, могут быть «помечены» некоторыми метаданными. Такие метки необходимы, для того чтобы по ходу выполнения XPath-выражения, определяющего целевые узлы изменения, помечать те узлы, модификация которых инициирует срабатывание XML-триггера. При описании метода с общим выполнением будем использовать понятия логического плана выполнения путевого выражения и логической операции. Логический план выполнения путевого выражения представляет собой композицию двух типов логических операций. К их числу относятся логические операции, осуществляющие переход по оси, и логические операции, осуществляющие фильтрацию узлов, заданную соответствующим предикатом. Набор логических операций, используемых в данной работе, реализован в прирожденной XML-СУБД Sedna и описан в [50]. Трансляция путевого выражения в соответствующий ему план выполнения представляет собой логически прозрачный процесс. Об этом свидетельствует результат трансляции на примере (рис 4.3.) Путевое выражение: Логический план: Путевое выражение и соответствующий ему логический план выполнения В логическом плане на рис 4.3 операции child и descendant осуществляют переход по соответствующим осям; операция select выбирает узлы, у которых значение атрибута ISBN равно 1-55860-304-2; операции element и attribute выбирают узлы соответствующие заданному тесту. Метод с общим выполнением требует расширения набора логических операций путем введения двух новых логических операций markl и mark2, а также с помощью изменения семантики выполнения операции child. Операция markl (unmarked_seq, predicate, trigger_name) Принимает на вход последовательность узлов без меток unmarked_seq, проверяет для каждого узла последовательности unmarked_seq выполнимость предиката predicate и, если узел удовлетворяет предикату, записывает в него метку, содержащую trigger_name. Операция возвращает последовательность узлов unmarked_seq, некоторые из которых содержат метки. Операция mark2 (marked_seq, predicate, trigger_name) принимает на вход последовательность узлов marked_seq, некоторые из которых могут содержать метки. Для тех узлов последовательности, которые помечены метками С trigger_name, проверяется ВЫПОЛНИМОСТЬ предиката predicate и, если узел не удовлетворяет предикату, метка удаляется, иначе метка остается в узле. Операция возвращает последовательность узлов marked_seq, некоторые из которых содержат метки. Операция child(node_seq, element attribute (name)) осуществляет переход к дочерним узлам с последующей выборкой элементов или атрибутов с заданным именем. При этом операция должна выполняться таким образом, что если некоторый узел последовательности node_seq содержит метку, то такая же метка записывается во все полученные дочерние узлы этого узла.
Как и метод с фиксаторами, метод с общим выполнением основывается на «наивном» методе с пересмотром таких его частей как определение XML- триггеров; вычисление целевых узлов изменения (первый этап выполнения операции модификации); оба алгоритма поиска инициируемых XML-триггеров. Кроме того, у этого метода имеется дополнительный этап - построение объединенного плана выполнения. Этот этап выполняется на стадии компиляции операции модификации (то есть до вычисления целевых узлов изменения). Этап построения объединенного плана выполнения является наиболее важным, так как именно на этом этапе применяется ключевая техника метода, поэтому рассмотрение метода мы начнем с него.
Метод реализации XML-триггеров на выборку данных, основанный на использовании теневого механизма
Преимуществом «наивного» метода является его простота реализации. Однако, очевидно, что копирование XML-документов каждый раз при выполнении операции выборки приводит к неприемлемым на практике накладным расходам. Необходим более эффективный метод, позволяющий избежать подобного копирования. Далее автором предлагается метод реализации XML-триггеров, позволяющий эффективно поддерживать XML-триггеры без накладного копирования XML-документов.
Избежать ресурсоёмкого копирования при выполнении XML-триггеров на выборку оказалось возможным на основе использования идеи теневого механизма, на котором и основан предлагаемый в данном разделе метод.
Теневой механизм впервые был предложен в ранних работах по восстановлению базы данных после сбоев и поддержки многоверсионности [51]. Его основная идея состоит в том, что при модификации данных система физически не изменяет эти данные, а сохраняет новые (вставляемые или новые при операции замены) элементы данных в определенном месте на диске, устанавливая при этом соответствие между существующими и новыми элементами данных. Поскольку исходные данные остаются неизменными, существует две версии данных, при этом исходная версия данных становится так называемой «тенью» для новой версии.
В методе, предлагаемом в данном разделе, XQuery-выражение действия XML-триггера специальным образом преобразуется в transform-выражение . При выполнении операции выборки, инициирующей срабатывание XML-триггера, теневой механизм используется для эффективного выполнения построенного /гати/огтя-выражения XML-триггера. По окончании выполнения операции выборки и обработки всех инициированных ею XML-триггеров, происходит возвращение к исходной «теневой» версии данных.
Метод применим для прирожденных XML-СУБД, в которых узлы хранящихся XML-документов связаны между собой по ссылке, что, как показано в подразделе 2.2.1 Главы 2, является вполне оправданным требованием. Рассмотрим подробно, как происходит определение новых XML-триггеров в системе и обработка XML-триггеров при выполнении операции выборки с использованием метода, основанного на использовании теневого механизма. Определение XML-триггеров Определение и отмена определений XML-триггеров происходят при выполнении триггера создается соответствующая этому XML-триггеру описательная структура данных так же, как и при использования «наивного» метода, описанного в предыдущем разделе. Исключением является тот факт, что XQuery-выражение действия XML-тригтера преобразуется в /raws/or/я-выражение и уже в таком виде сохраняется в описательной структуре. XUpdate-выражения и XQuery-выражение действия XML-триггера преобразуются в набор выражений, состоящий из XUpdate-выражений и одного /гаж/отти-выражения как это показано на рис. 4.7. В transform-выражении после ключевого слова сору переменная $сору связывается с узлами-документами трансформируемых документов XML-триггера. OF-выражения XML-триггера переносятся в конструкцию for, заданную после ключевого слова modify. В Ггаия/оття-выражения были описаны в подразделе 2.1.3 Главы 2. операции replace, заданной после ключевого слова do, используется XQuery-выражение действия XML-триггера для построения новых узлов при замене. Переменная $copy, заданная после ключевого слова сору, связывается с узлом-документом doc ( lib ). Узлы, которые адресуются XPath-выражениями, заданными в конструкции for после ключевого слова modify, будем называть исходными узлами. После ключевого слова do задана операция replace. Новые узлы, вставляемые при замене операцией replace, будем называть узлами подмены. Обработка XML-триггеров при выполнении операции выборки Операция выборки выполняется по следующему алгоритму. Алгоритм 4.12 (выполнения операции выборки с поддержкой XML-триггеров при методе, основанном на использовании теневого механизма) Задача. Выполнить операцию выборки Q, обработав при этом XML-триггеры, инициируемые операцией Q. Содержание алгоритма в общем изложении может быть представлено в виде следующей схемы. 1. На стадии компиляции операции выборки Q определить набор XML-документов D, которые адресуются операцией Q. 2. Определить набор XML-триггеров Т, трансформируемые документы которых входят в набор D. Упорядочить набор Т в соответствии с алфавитным порядком имен XML-триггеров. 3. Выполнить XUpdate-выражения из построенного набора выражений действия XML-триггеров Т. 4. Все transform-выражения XML-триггеров Г выполнить по очереди таким образом, что /гал /огт-выражение очередного XML-триггера /; выполняется над XML-документом, являющимся результатом предыдущего transform-выражения. Transform-выражение каждого XML-триггера Ц выполнить следующим образом. ? Организовать данные при выполнении transform-выражения с использованием теневого механизма показанного на рис. 4.8. ? Вычислить OF-выражения (XPath-выражения в конструкции for построенного transform-выражения). Результатом вычисления является набор исходных узлов. ? Для каждого исходного узла во временном хранилище СУБД построить соответствующие ему jtf-Ш подмены . ? Все указатели на исходные узлы (от родителей, от ближайших соседей) перенести на узлы подмены. Ссылки узлов подмены аналогично связываются с узлами документа.
