Поддержка обновления XML-представлений над реляционными базами данных
В статье рассматриваются способы реализации задачи построения механизма обновляемых XML-представлений над реляционными базами данных с использованием техники и предлагаются способы расширения множества поддерживаемых представлений. Приведенные правила построения деревьев запросов для стандартных SQ...
Збережено в:
| Дата: | 2006 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Російська |
| Опубліковано: |
Інститут програмних систем НАН України
2006
|
| Теми: | |
| Онлайн доступ: | https://nasplib.isofts.kiev.ua/handle/123456789/1635 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Поддержка обновления XML-представлений над реляционными базами данных / Н.А. Самохвалов // Проблеми програмування. — 2006. — N 2-3. — С. 445-457. — Бібліогр.: 17 назв. — рос. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859734913698234368 |
|---|---|
| author | Самохвалов, Н.А. |
| author_facet | Самохвалов, Н.А. |
| citation_txt | Поддержка обновления XML-представлений над реляционными базами данных / Н.А. Самохвалов // Проблеми програмування. — 2006. — N 2-3. — С. 445-457. — Бібліогр.: 17 назв. — рос. |
| collection | DSpace DC |
| description | В статье рассматриваются способы реализации задачи построения механизма обновляемых XML-представлений над реляционными базами данных с использованием техники и предлагаются способы расширения множества поддерживаемых представлений.
Приведенные правила построения деревьев запросов для стандартных SQL/XML - конструкций делают возможным реализацию
данного подхода в виде модуля реляционной СУБД. Приводится описание реализации метода деревьев запросов для создания инструмента разработки web-интерфейсов к реляционным данным и обзор возможных областей применения данного подхода.
This paper presents an overview of methods for solving the problem ofcreation of the system supporting updatable XML-views over relational
databases using query trees and proposes further ways to extend the set of views supported. The given rules of query trees creation for
SQL/XML construction make possible the realization of such approach as a module of relational DBMS. In addition, the tool for webinterfaces
development as an example of query trees method implementation is described and short review of possible areas of implementation
of this approach is presented.
|
| first_indexed | 2025-12-01T14:55:39Z |
| format | Article |
| fulltext |
Моделі і засоби систем баз даних і знань
© Н.А. Самохвалов, 2006
ISSN 1727-4907. Проблеми прграмування. 2006. № 2-3. Спеціальний випуск 445
УДК УДК: 004.655.3
ПОДДЕРЖКА ОБНОВЛЕНИЯ XML-ПРЕДСТАВЛЕНИЙ
НАД РЕЛЯЦИОННЫМИ БАЗАМИ ДАННЫХ
Н.А. Самохвалов
Московский физико-технический институт (государственный университет)
141700, Московская область, г. Долгопрудный, Институтский переулок, 9
тел. +7 495 408 5700
В статье рассматриваются способы реализации задачи построения механизма обновляемых XML-представлений над реляционны-
ми базами данных с использованием техники и предлагаются способы расширения множества поддерживаемых представлений.
Приведенные правила построения деревьев запросов для стандартных SQL/XML - конструкций делают возможным реализацию
данного подхода в виде модуля реляционной СУБД. Приводится описание реализации метода деревьев запросов для создания ин-
струмента разработки web-интерфейсов к реляционным данным и обзор возможных областей применения данного подхода.
This paper presents an overview of methods for solving the problem ofcreation of the system supporting updatable XML-views over rela-
tional databases using query trees and proposes further ways to extend the set of views supported. The given rules of query trees creation for
SQL/XML construction make possible the realization of such approach as a module of relational DBMS. In addition, the tool for web-
interfaces development as an example of query trees method implementation is described and short review of possible areas of implementa-
tion of this approach is presented.
Введение
Задачи преобразования данных из реляционной модели данных в модель XML [1] и обратно сегодня
чрезвычайно актуальны. В то время как XML активно используется для обмена данными в Internet, реляцион-
ные СУБД продолжают оставаться основным классом систем хранения данных. Например, типичной можно
считать ситуацию, когда при наличии уже существующей системы, использующей для хранения данных реля-
ционную СУБД, ставится задача создания (или усовершенствования) web-приложения, которое должно по-
ставлять конечному пользователю документы в формате XHTML, WML, RSS и т.п. Таким образом, в общем
случае, web-приложение можно рассматривать как некоторую систему, выступающую в роли «посредника»
между двумя моделями данных – реляционной и XML.
Безусловно, с одной стороны, существующие реализации реляционных СУБД обладают чрезвычайно
важными качествами, среди которых можно отметить богатые возможности поддержки целостности данных,
механизмы обеспечения надёжности хранения, защиты информации. С другой стороны, XML является стандар-
том de facto обмена информацией в Internet. Именно поэтому ведущие производители реляционных СУБД раз-
вивают средства работы с данными типа XML в своих продуктах. Проблема поддержки таких средств состоит
из совокупности задач:
Задача экспорта реляционных данных в виде XML [2, 3]. 14-я часть стандарта SQL:2003 (SQL/XML [4])
описывает расширение оператора SELECT языка SQL конструкциями для получения XML-документов (или их
частей) из реляционных данных.
Хранение XML-данных в реляционной базе. Существуют два различных пути решения этой задачи: хра-
нение XML-данных посредством расширенного типа CLOB и специальная декомпозиция XML-данных с целью
последующего хранения в «разобранном» виде (так называемый shredding) [5-7]. Существующие реализации,
как правило, комбинируют эти два подхода, сохраняя данные в цельном виде и создавая расширенный индекс с
применением техники shredding.
Манипуляционные задачи: осуществление операции выборки XML-данных (например, с помощью неко-
торого расширения языка SQL, поддерживающего XPath-выражения [8]), сохранённых в реляционной базе;
создание эффективных индексов для выполнения операции выборки; возможность осуществления операций
обновления данных.
Стоит заметить, что свойства модели данных XML достаточно глубоко исследованы [2, 3, 7, 9], а основ-
ные коммерческие реализации сегодня предоставляют достаточно мощные средства для решения упомянутых
проблем. Тем не менее не все задачи решаются эффективным образом; кроме того, существуют и вовсе нере-
шённые проблемы. К ним относится универсальная поддержка трансляции обновлений XML-представлений
над реляционными базами (созданных, к примеру, с помощью конструкций SQL/XML) на исходные реляцион-
ные таблицы. Данная задача возникает, например, при потребности производить обновления XML-
представлений удалёнными агентами, от которых должна быть скрыта полная информация о природе данных,
при создании универсального средства для создания web-интерфейсов работы с данными и т.д.
В данной статье рассматривается подход [10, 11], основывающийся на технике сопоставления XML-
представления группе реляционных представлений и трансляции операций обновления XML-документа в на-
бор SQL-выражений обновления над реляционными представлениями. Данный подход позволяет переложить
на плечи реляционной СУБД вопросы возможности проведения самой операции обновления и дальнейшей
трансляции её на исходные таблицы, что существенно упрощает задачу (вообще говоря, задача реализации ме-
ханизма обновления реляционных представлений [12] является нетривиальной, поэтому использование меха-
низмов поддержки операций обновления представлений, которыми обладают текущие РСУБД, представляется
чрезвычайно выгодным). Техника сопоставления XML-представлений группе реляционных представлений ба-
Моделі і засоби систем баз даних і знань
446
зируется на понятии дерева запросов. В данной статье предложено расширение класса поддерживаемых дан-
ным методом XML-представлений. Кроме того, описывается создание деревьев запросов для стандартных
SQL/XML-конструкций, что делает возможным реализацию данного подхода в виде модуля реляционной
СУБД. В заключение приводится обзор областей применения метода деревьев запросов, описание реализации
метода для создания инструмента разработки web-интерфейсов к реляционным данным и анализ возможности
создания обновляемых XML-представлений в ОРСУБД PostgreSQL [13].
Крупнейшие производители СУБД уже несколько лет предлагают механизмы для экспорта данных в
XML и импорта XML-документов в реляционную БД. К сожалению, подходы к реализации данных механизмов
у разных производителей имеют принципиальные различия. Поэтому использование подобных механизмов,
например, в СУБД MS SQL Server [14] (стоит заметить, что данная СУБД поддерживает обновления реляцион-
ных таблиц с помощью XML-пакетов) существенно снизило бы универсальность системы.
Между тем задачу построения системы, поддерживающей операции обновления XML-представлений,
можно решить независимым от СУБД способом – построив соответствие XML-представлений наборам обыч-
ных реляционных представлений [5, 12]. При этом часть ответственности за реализацию операций обновления
перекладывается на плечи реляционной СУБД, что позволяет разработчику целиком сосредоточиться на вопро-
сах определения правильной структуры XML-документов, поставляемых конечному пользователю. Для реали-
зации данного подхода в [5] вводится понятие деревья запросов. Как мы увидим в дальнейшем, использование
деревьев запросов на этапе построения XML-представлений позволяет легко перейти ко второй нормальной
форме
1 XML-документов (что, по сути дела, и делает возможным построение взаимно однозначного соответст-
вия XML-документов и реляционных таблиц), а использование их на этапе отображения операции обновления
частично позволяет отказаться от рассмотрения проблемы возможности осуществления самой операции обнов-
ления, воспользовавшись механизмами обновления представлений, заложенными в реляционную СУБД.
Множество представлений ограничим построенными с помощью операций выборки, ограничения и со-
единения. Что касается XML-документов, сфокусируем внимание на общей форме XML-представлений, разре-
шающих операции вложения, композиции атрибутов, гетерогенные множества и повторяющиеся элементы.
Пример такого представления – View2, (рис.2). В этом XML-представлении узлы phone вложены в узлы
products, узел vendorInfo содержит композицию атрибутов url и state. Узлы products могут содержать корте-
жи из элементов двух типов: phone и pda.
В качестве примера реляционной базы данных рассмотрим БД, схема которой частично изображена в
Приложении A (представление View1 строится на основе отмеченной пунктиром части этой схемы).
Рис. 1 Представление View1 – производители и телефоны
Рис. 2 Представление View2 - производители, телефоны и КПК
1. Деревья запросов
Деревья запросов можно рассматривать как некоторую переходную конструкцию от реляционной БД к
документам XML. Деревья запросов позволяют работать с обновлением представлений, поддерживающих гете-
рогенные множества, в то время как другие решения проблемы обновления XML-представлений такие классы
представлений не рассматривают. Например, подход с использованием алгебры вложенных отношений (NRA,
Nested Relational Algebra), описанный в [12], позволяет работать с представлениями, подобными View1 (см.
рис.1), но не View2. Как увидим ниже, система, основанная на деревьях запросов, поддерживает оба типа пред-
ставлений. Кроме того, использование такой абстрактной системы, а не какого-либо синтаксиса языка запросов
XML удобно по следующим причинам. Во-первых, облегчается задача определения возможности обновления
1 Подробнее о нормальных формах XML-документов см. в [15].
Моделі і засоби систем баз даних і знань
447
представления. Это достигается следующим образом: на основе дерева запросов генерируется набор реляцион-
ных представлений, далее операция обновления XML преобразуется (опять-таки с помощью дерева запросов) в
набор SQL-предложений обновления этих реляционных представлений и далее реляционная СУБД решает, яв-
ляются ли такие операции корректными. Во-вторых, деревья запросов просты для понимания и в то же время
являются достаточно мощными, предоставляя возможность работы с большим классом представлений.
1.1 Определение деревьев запросов. Будем полагать, что D обозначает реляционную БД, над которой
определяются XML-представления; T – множество имен таблиц D; AT - множество атрибутов таблицы T∈T
(множество имен столбцов в Т).
Определение 1 (дерево запросов). Деревом запросов, определенным над базой D, называется дерево с
множеством вершин N и множеством ребер E, в котором верны следующие положения. Множество ребер со-
держит простые ребра и *-ребра. Ребро является простым, если вершине, в которую оно входит, соответствует
ровно один элемент в соответствующем XML-представлении, в противном случае оно является *-ребром. Вер-
шины должны удовлетворять следующим требованиям:
• все вершины имеют имя, соответствующее тегу элемента в итоговом XML-представлении;
• все листовые вершины имеют значения;
• листовые вершины, имена которых начинаются с «@», рассматриваются как XML-атрибуты;
• *-вершины (вершины со входящими *-ребрами) имеют один или более дескрипторов источника, нуль
или более дескрипторов ограничения и нуль или более дескрипторов сортировки.
Вершины могут содержать дескрипторы нескольких типов. Дескрипторы источника связывают пере-
менные с реляционными таблицами (например, [$t := table(“tree”)]), а дескрипторы ограничения содержат огра-
ничения на реляционные таблицы (пример – [where $p/product_price > 300]). В дополнение к этому введем еще
один тип дескрипторов – дескрипторы сортировки, которые указывают, каким образом будет произведена сор-
тировка в результирующем представлении (например, [orderby $p/product_price desc]).
Определение 2 (дескриптор источника). Дескриптор источника s в *-вершине n записывается в виде
$x := table(T), где $x означает переменную, а T∈∈∈∈ T – реляционную таблицу. Будем говорить, что $x связана с T
при помощи s.
Определение 3 (дескриптор ограничения). Дескриптор ограничения в *-вершине n записывается в виде
where $x1/A1 op Z1 AND … AND $xk/Ak op Zk, k ≥ 1, где Ai ∈ ATi и $xi связана с Ti при помощи дескриптора
источника в n или каком-либо предке n. Оператор op – это какой-либо оператор сравнения (=, ≠, >, <, ≤, ≥, LIKE
и т.д.). Zi – либо литеральная константа, либо выражение в форме $y/B, где B ∈ AT и $y связана с T при помо-
щи дескриптора источника в n или каком-либо предке n.
Определение 4 (дескриптор сортировки).1 Дескриптор ограничения в *-вершине n записывается в виде
orderby $x/A [{ asc | desc }], k ≥ 1, где A ∈ AT и $x связана с T при помощи дескриптора источника в n или
каком-либо предке n. Ключевое слово desc является необязательным.
Определение 5 (значение вершины). Значение листовой вершины n записывается в виде $x/A, где A ∈
AT и $x связана с T при помощи дескриптора источника в n или каком-либо предке n.
Пример дерева запросов можно увидеть на рис.3. В этом дереве описаны указания к получению из БД
всех телефонов Samsung, которые продаются по цене более $300. Дерево запросов очень близко по структуре к
результирующему XML-документу. Корневая вершина дерева соответствует корневой вершине результата.
Листовые вершины соответствуют атрибутам реляционных таблиц; ребра, отмеченные звездой, соответствуют
кортежам элементов. Результат данного запроса представлен на рис.3 справа.
Рис. 3 Пример дерева запросов и построенного с его помощью XML-представления
1 Вообще говоря, возможно использование любого условного выражения (см. спецификацию conditional_expression в [2]) в качестве деск-
риптора ограничения. При этом может возникнуть ситуация, когда реляционная СУБД будет не в состоянии произвести операцию обнов-
ления соответствующих реляционных представлений. Здесь намеренно выбрано подмножество условных выражений, позволяющее рас-
сматривать такие реляционные представления, для которых реляционная СУБД почти наверное разрешает проведение операции обновле-
ния; и соответствующее широко встречающимся на практике ситуациям.
Моделі і засоби систем баз даних і знань
448
Легко видеть, что из корня (phones) выходит *-ребро к дочерней вершине phone; это означает то, что в
соответствующем XML-документе у корневого элемента phones может быть несколько дочерних элементов
phone. Простое ребро от вершины phone к вершине name означает, что у элемента phone в XML-представлении
может быть только один дочерний элемент name. Вершине @id в XML-документе соответствует не элемент, а
атрибут. Далее, вершина phone содержит дескрипторы источника и ограничения. Дескрипторы источника свя-
зывают переменную $p с реляционной таблицей Product и переменную $t с реляционной таблицей Tree. Деск-
рипторы ограничения указывают на то, что производится выборка телефонов (tree_id = 2) производителя Sam-
sung (product_vendor_id = 14), задают ограничения значений цены телефонов в представлении снизу величиной
$300 и определяют условие соединения таблиц Product и Tree. Значение вершины @id определяется в виде
$p/product_id, что указывает на то, что содержимое атрибута id в XML-представлении будет определяться зна-
чением столбца product_id таблицы Product.
Рис. 4. Дерево запросов для View2 – qt1
Более сложный пример дерева запросов изображен на рис.4 (смысл обозначений τ в правых нижних уг-
лах вершин будет пояснен ниже). Это дерево запросов извлекает из базы производителей (vendors), для каж-
дого производителя (vendor) его @id, vendorName, url, state и кортежи телефонов (phone) и КПК (pda), ко-
торые включаются в общую «оболочку» products. Корень vendors содержит множество дочерних вершин
vendor (*-ребро). В вершине vendor переменная $v связывается с таблицей Vendor; эта вершина имеет не-
сколько дочерних вершин (@id, vendorName, vendorInfo), которые соединены с ней простыми ребрами и от-
ражают информацию о производителе. Значение атрибута id определяется выражением пути вида
$v/vendor_id, аналогично для вершины vendorName – $v/vendor_name. Вершина vendorInfo устроена не-
много сложнее, она состоит из субвершин url и state.
Вершина products имеет 2 дочерние вершины, с которыми она соединена
*-ребрами – phone и pda. Дескрипторы источника вершины phone связывают переменную $p c таблицей
Product и $t – с Tree, а дескрипторы ограничения соединяют кортежи таблицы Product с кортежами Vendor и
кортежи Product с кортежами Tree (условия соединения), а также ограничивают выборку продуктами-
телефонами ($t/tree_id = 2). Вершина pda описывается аналогично с той лишь разницей, что выборка ограни-
чивается продуктами-КПК ($t/tree_id = 4). Результат работы этого дерева запросов – представление View2, по-
казанное на рис.2.
С этого момента мы будем предполагать, что дерево запросов не пусто, т.е. корневая вершина не являет-
ся единственной.
1.2 Абстрактные типы вершин. Вершины в дереве запросов можно разделить на группы, исходя из их
семантики. Для этого в [5] определяется пять типов вершин: τ, τT, τN, τC и τS. Будем называть их абстрактными
для того, чтобы отличать от типов DTD XML-документов.
Определение 6 (абстрактные типы). Абстрактные типы приписываются вершинам согласно следую-
щим правилам:
• Корень имеет абстрактный тип τ.
• Каждая листовая вершина имеет абстрактный тип τS (Simple).
• Каждая нелистовая вершина с простым входящим ребром имеет абстрактный тип τC (Complex).
• Каждая *-вершина, которая является либо листовой, либо все ее потомки соединены только про-
стыми ребрами, имеет абстрактный тип τN (Nested).
• Все остальные *-вершины имеют абстрактный тип τT (Tree).
Заметим, что все вершины имеют ровно один тип, за исключением *-вершин, которые обладают двумя
типами – τS и τN.
Моделі і засоби систем баз даних і знань
449
В качестве примера рассмотрим дерево запросов, изображенное на рис.4, где рядом с каждой вершиной
указан ее тип. Так как phone и pda являются *-вершинами, а все их потомки – простые вершины, то они имеют
тип τN, а не τT.
Причины введения такого определения абстрактных вершин таковы. Для преобразования операций об-
новлений XML-представления в операции обновления реляционных представлений мы должны выявить соот-
ветствие атрибутов кортежей реляционной базы элементам или атрибутам XML-представления. В идеале такое
соответствие должно оказаться взаимнооднозначным: каждый атрибут кортежа имеет ровно один образ в XML-
представлении и, таким образом, может подвергаться операциям обновления без каких-либо сторонних эффек-
тов в представлении. В общем случае, однако, это отображение типа 1:n. Класс представлений, порождаемый
деревьями запросов, позволяет осуществлять такого рода отображения.
Итак, семантика абстрактных типов вершин деревьев запросов такова:
• Вершинам типов τT/τN соответствуют кортежи в реляционной базе. Вершина типа τT может имеет
дочерние вершины типа τT, т.е. разрешены вложения таких вершин.
• τS описывает реляционные атрибуты (столбцы). Вершина типа τS должна иметь предка типа τT или
τN. Листовые вершины, отмеченные звездой, являются исключением из этого правила: не требует-
ся, чтобы они имели предка такого типа.
τC определяет сложные XML-элементы. Так как они не содержат значений, вершинам такого типа нет
соответствия в реляционной модели. Вершины типа τC вводятся для создания более гибких XML-
представлений, однако они не важны в процессе отображения.
Назовем XML-представления, полученные при помощи деревьев запросов и ассоциированных с ними
абстрактных типов, доброкачественными, ввиду того, что, как будет показано ниже, они могут легко быть ото-
бражены на соответствующие реляционные представления.
Прежде чем переходить к рассмотрению механизма трансляции операций обновления XML-
представлений на реляционные представления, приведём без доказательства1 два очевидных утверждения.
Предложение 1. Существует по крайней мере одна τN-вершина в любом типизированном дереве запро-
сов qt.
Предложение 2. В любом типизированном дереве запросов qt вдоль любого пути от листа к корню есть
не более одной τN-вершины.
Под абстрактным типом элемента будем подразумевать абстрактный тип вершины, использующейся
при получении этого элемента, за которым идет имя элемента. Например, элементу pda представления View2
приписывается абстрактный тип τN(pda), а его DTD-типом является <!ELEMENT pda(pdaName, pdaPrice)>.
1.3 Отображение XML-представлений на множество реляционных представлений. Рассмотрим, как
XML-представление, полученное с помощью дерева запросов, можно преобразовать в набор реляционных
представлений. Как уже упоминалось, это делается для того, чтобы воспользоваться механизмом обновления
представлений, который есть в каждой крупной СУБД, для выяснения корректности операции обновления
XML-представления применительно к реляционной базе и, если операция корректна, переноса этой операции
на базовые реляционные таблицы.
Сначала рассмотрим построение одного реляционного представления для XML-представления, в кото-
ром есть только одна τN-вершина, далее перейдем к более сложным случаям и опишем алгоритм разделения
(расщепления) сложных представлений (несколько τN-вершин) на несколько простых.
Отображение (mapping). Если задано дерево запросов qt с единственной τN вершиной, SQL-предложение
для соответствующего реляционного представления получается следующим образом. Соединяем все таблицы,
которые присутствуют в дескрипторах источника (назовем их таблицами-источниками) данной вершины n в
дереве qt, используя дескрипторы ограничения, которые соответствуют условиям соединений таблиц-
источников n, а точнее, внутренних соединений (INNER JOIN). Если нет условий соединения, используем
«тавтологическое» условие (т.е. 1=1) в качестве условия соединения, результатом чего будет декартово произ-
ведение. Назовем такие выражения выражениями соединенных источников. Спускаясь по дереву от корня к
листьям, соединяем выражения соединенных источников, которые встречаются на пути от корня к вершине с
помощью операции левого внешнего соединения (LEFT OUTER JOIN). Условия для внешних соединений по-
лучаются очевидным образом: если вершина a является предком вершины n и дескриптор ограничения в n оп-
ределяет условие соединения таблицы в n с таблицей в a, то используем это определение как условие соедине-
ния для операции внешнего соединения. Так же, как и в случае с внутренними соединениями, если нет условия
для внешнего соединения, используем выражение вида 1=1. Далее используем оставшиеся дескрипторы огра-
ничения (те, которые не были использованы для построения условий внутренних и внешних соединений) в
предложении WHERE языка SQL и обрабатываем значения листовых вершин. Полученный в результате SQL-
запрос представления является плоской версией XML-представления. Заметим, что в отличие от [5] в условиях
ограничения могут быть не только простые сравнения (операции <, >, =, <=, <=), но и другие выражения, такие
как IS NULL, LIKE exp и т.д.
Примеры выражений соединенных источников:
<source table> AS <source variable> INNER JOIN
<source table> AS <source variable> INNER JOIN ...
1 Доказательства данных утверждений можно найти в [5].
Моделі і засоби систем баз даних і знань
450
ON <inner joincond>
Соответствующее SQL-выражение:
SELECT
<leaf value> AS <leaf name>,
...,
<leaf value> AS <leaf name>
FROM
(<source join expression>
LEFT JOIN <source join expression> ON <outer joincond>)
LEFT JOIN ...
WHERE
<remaining "where" annotation> AND
... AND
<remaining "where" annotation>
Например, реляционное представление, которое соответствует дереву запросов на рис.3, выглядит так:
SELECT
p.product_id AS id, p.product_name AS name, p.product_price AS price
FROM
(Tree AS t
INNER JOIN Product AS p
ON p.product_tree_id = t.tree_id)
WHERE t.tree_id = 2 AND p.product_vendor_id = 14 AND p.product_price > 300
Расщепление (split). Для дерева запросов с более чем одной τN-вершиной описанный процесс некоррек-
тен. Например, рассмотрим дерево запросов qt1 (см. рис.4), которое имеет две τN-вершины (phone и pda). При
попытке применить описанную выше процедуру отображения (mapping) таблица Product будет соединена сама
с собой, в результате получится декартово произведение (точнее, почти декартово произведение: каждый кор-
теж-телефон будет соединен с каждым кортежем-КПК). Это очевидным образом нарушит семантику дерева
запросов. Значит, перед созданием соответствующего реляционного представления необходимо расщепить де-
рево запросов на поддеревья, которые содержат ровно одну τN-вершину. После процесса расщепления на осно-
ве каждого полученного поддерева запросов создается реляционное представление с помощью процедуры
mapping.
Процесс расщепления состоит в изолировании вершины n типа τN в дереве запросов qt и работе с полу-
ченным поддеревом так, как будто ее вершины-предки и неповторяющиеся вершины-потомки (типов τC и τS)
формируют новое дерево qti. Вспомним, что, согласно предложению 1, любое qti должно иметь по меньшей
мере одну τN-вершину.
Рис. 5. Отщепленное дерево запросов для
τN(phone)
Рис. 6. Отщепленное дерево запросов для τN(pda)
Результат работы этого алгоритма над деревом запросов рис.4 показан на рис.5 и 6. Используя данные
отщепленные деревья, получаем следующие реляционные представления ViewPhone и ViewPda (по этим име-
нам будем ссылаться на данные реляционные представления далее):
CREATE VIEW ViewPhone AS p
SELECT
v.vendor_id AS id, v.vendor_name AS vendorName, v.vendor_url AS url,
v.vendor_country AS state, p.product_name AS phoneName, p.product_price AS phonePrice,
p.product_system AS phoneSystem
FROM
(Vendor AS v
LEFT JOIN (Tree AS t
INNER JOIN Product AS p ON p.product_tree_id = t.tree_id)
ON v.vendor_id = p.product_vendor_id)
Моделі і засоби систем баз даних і знань
451
WHERE t.tree_id = 2;
CREATE VIEW ViewPda AS p
SELECT
v.vendor_id AS id,
v.vendor_name AS vendorName,
v.vendor_url AS url,
v.vendor_country AS state,
p.product_name AS pdaName,
p.product_price AS pdaPrice
FROM
(Vendor AS v
LEFT JOIN (Tree AS t
INNER JOIN Product AS p ON p.product_tree_id = t.tree_id)
ON v.vendor_id = p.product_vendor_id)
WHERE t.tree_id = 4;
2. Обновление деревьев запросов
Рассмотрим, как операцию обновления XML-представления можно преобразовывать в совокупность
операций обновления соответствующего ему набора реляционных представлений.
Все операции обновления делятся на три группы: вставки, удаления и модификации. Сначала обсудим
способы описания операций обновления, а потом рассмотрим отдельно каждый из трех классов операций и ме-
тоды преобразования.
2.1 Язык обновлений. Обновления определяются с использованием выражения пути для того, чтобы
указать множество вершин в XML-дереве, которые подлежат обновлению. Для вставок и изменений в операции
обновления также должно быть указано значение ∆, содержащее новые значения.
Определение 7 (операция обновления). Операция обновления u – это тройка <t, ∆, ref>, где t - тип опе-
рации (insert, delete или modify); ∆ – XML-дерево, подлежащее вставке, или, в случае модификации, атомарное
значение (один элемент); ref – простое выражение пути на языке XPath [10], которое обозначает, где именно
должно произойти обновление.
Выражение пути ref применяется от корня дерева и в результате получаем множество вершин, которое
будем называть целевыми вершинами. В случае модификации это должны быть листовые вершины. Ограничим
множество фильтров, используемых в ref конъюнкциями сравнений атрибутов или дочерних элементов с ато-
марными значениями. Будем называть выражение ref, из которого удалены фильтры, абсолютной частью ref. К
примеру, абсолютной частью выражения /vendors/vendor[@id=”01”] является /vendors/vendor.
Определение 8 (корректность выражения пути). Выражение пути ref является корректным по отно-
шению к дереву запросов qt, если абсолютная часть ref полностью применима к этому дереву (т.е. результат
применения всего выражения пути – непустое множество).
К примеру, /vendors/vendor[@id=”01”]/vendorName – корректный путь по отношению к дереву
запросов qt1 (см. рис.4), так как путь /vendors/vendor/vendorName применим к этому дереву.
Во время операции вставки ∆ вставляется как дочернее поддерево к вершине, указанной выражением
ref; для операции модификации значение листовой вершины, указанной в ref, заменяется на ∆; в процессе
удаления поддерево, исходящее из вершины, указанной с помощью ref, удаляется.
Рассмотрим несколько примеров для представления View2 (см. рис.2).
Пример 1. Для вставки нового телефона, продаваемого по цене $430, производитель которого – произ-
водитель с id=”14” (Samsung) надо указать: t = insert, ref =
/vendors/vendor[@id="14"]/products,
∆ = {<phone>
<name>SGH-D410</name>
<price>430</price>
<system>EGSM 900/1800/1900</system>
</phone>}.
Пример 2. Для изменения vendorName производителя с id = “42” c “Trium” на “Mitsubishi” надо указы-
вать: t = modify, ref = /vendors/vendor[@id="42"]/vendorName, ∆ = {Mitsubishi}.
Пример 3. Удаление всех телефонов с названием “1100”: t = delete, ref =
/vendors/vendor/products/phone[name="1100"].
Заметим, что не все операции вставки и удаления имеют смысл, так как получившееся после их приме-
нения XML-представление может не удовлетворять DTD, которое было получено с помощью дерева запросов.
Например, удаление, заданное выражением пути /vendors/vendor/vendorName для представления View2
(см. рис.2 и рис.4), приведет к нарушению DTD, так как vendorName является обязательным дочерним эле-
ментом элемента vendor. Аналогично необходимо проверять корректность операций вставки и модификации.
Определение 9 (корректность операции обновления). Обновление <t, ∆, ref> XML-
представления, построенного с помощью дерева запросов qt, является корректным тогда и только тогда, когда
выполнены следующие условия:
• ref является корректным по отношению к qt;
Моделі і засоби систем баз даних і знань
452
• если t = modify, то абсолютная часть ref, примененная к qt, приводит к вершине типа τS;
• если t = insert, то абсолютная часть ref + корень ∆, примененные к qt, приводят к вершине,
у которой входящее ребро есть *-ребро (т.е. вершина типа τT или τN);
• если t = delete, то абсолютная часть ref, примененная к qt, приводит к вершине, чье входя-
щее ребро есть *-ребро;
• если ∆ не пусто, то оно удовлетворяет DTD элемента, к которому приводит ref.
Рассмотрим операцию удаления, описанную в примере 3. Она корректна, так как phone является дочер-
ней *-вершиной вершины product. Однако удаление, задаваемое выражением пути
/vendors/vendor/vendorName, не является корректным, так как vendorName имеет абстрактный тип τS,
так же, как и, например, удаление, задаваемое некорректным выражением пути /vendors/vendor/pda.
Операция вставки, описанная в примере 1, является корректной, так как вершина phone (к которой при-
водит выражение пути /vendors/vendor/products + корень ∆ - phone) является дочерней *-вершиной
вершины products, DTD для phone есть <!ELEMENT phone (name,price,system)> и ∆ удовлетворяет ей.
2.1 Трансляция XML-обновлений на реляционные представления. Теперь рассмотрим, как коррект-
ные обновления XML-представлений преобразуются в SQL-операции обновления соответствующих реляцион-
ных представлений.
В дальнейших примерах будет использоваться представление View2 (см. рис.2 и рис.4). Реляционные
представления ViewPhone и ViewPda, которые соответствуют этому XML-представлению, были описаны
выше.
Алгоритмы трансляции для операций вставок, удалений и модификаций (doInsert, doDelete и do-
Modify соответственно) предполагают, что операция обновления u является корректной (т.е. проверка на кор-
ректность уже проведена).
2.1.1. Вставка. Для трансляции операции вставки в XML-представление на реляционные представления
делается следующее. Во-первых, абсолютная часть выражения пути ref используется для нахождения той вер-
шины в дереве запросов, где будет произведена вставка. Вместе с ∆ это будет использовано для определения
реляционного представления, подвергаемого обновлению. Во-вторых, формируется SQL-выражение для каждо-
го подвергаемого обновлению реляционного представления с использованием информации в ∆, а также инфор-
мации о метках и значениях в поддеревьях, исходящих из вершин на пути от каждой целевой вершины к корню
XML-документа.
Заметим, что, согласно предложению 2, вдоль пути из любой вершины к корню в дереве запросов есть
только одна вершина типа τN, кроме того, вставки никогда не производятся ниже вершины типа τN, так как все
вершины ниже вершины типа τN по определению должны иметь тип τS или τC.
Рассмотрим трансляцию операции обновления, описанной в примере 1. Безусловная часть выражения
пути /vendors/vendor/products/ применяется к дереву запросов qt1 (см. рис.4), при этом выходит, что
тип целевой вершины– τC(products). Продолжая от τN(products) с использованием структуры ∆, нахо-
дим, что единственная τN-вершина в ∆ – это корень, τN(phone). Реляционное представление, подлежащее опе-
рации обновления, таким образом, – ViewPhone. Далее используем выражение пути ref =
/vendors/vendor[@id=”14”]/products для определения элементов в XML-документе, которые под-
лежат обновлению. В нашем случае это единственный элемент. Таким образом, должно быть сгенерировано
только одно SQL-выражение вставки для ViewPhone.
Для формирования SQL-выражения вставки необходимо найти значения всех атрибутов (столбцов)
представления. Некоторые из этих пар «атрибут-значение» извлекаются из ∆, другие должны быть взяты из
XML-документа, при анализе пути от каждой целевой вершины к корню и получения пар «атрибут-значение»
из листовых вершин поддеревьев, исходящих из вершин этого пути. В примере 1 ∆ задает name=”SGH-
D410”, price=”430”, system=”EGSM 900/1800/1900”. Вдоль пути от целевой вершины к корню мы
находим: id=”14”, vendorName=”Samsung”, url=”http://samsung.com”, state=”KR”. Ком-
бинируя эту информацию, мы создаем следующее SQL-выражение вставки:
INSERT INTO
ViewPhone(id, vendorName, url, state, name, price, system)
VALUES
("14", "Samsung", "http://samsung", "KR", "SGH-D410", "430", " EGSM 900/1800/1900")
2.1.2. Модификация. По определению, модифицировать можно только значения листовых вершин. Для
выполнения операции модификации, необходимо следующее. Во-первых, выражение ref используется для оп-
ределения имени реляционного представлений, над которыми будет произведена попытка выполнения опера-
ции. Это достигается нахождением первого предка вершины, определяемой выражением ref, который имеет тип
τN или τT с последующим поиском всех τT-вершин его поддерева. (По крайней мере одна τN-вершина должна
существовать.) Если целевая листовая вершина и есть эта τN-вершина, то это дает гарантии того, что обновле-
ние будет транслировано только на реляционное представление, соответствующее этой вершине. Во-вторых,
создается SQL-выражение. При этом атрибуты, которые задействованы в ref, комбинируются со значениями из
∆, далее с использованием фильтров в ref вычисляется предложение WHERE SQL-выражения.
Моделі і засоби систем баз даних і знань
453
2.1.3. Удаление. Операция удаления является самой простой из трех. Сначала абсолютная часть исполь-
зуется для нахождения вершины дерева, которую необходимо удалить (это не обязательно листовая вершина –
т.е. возможно удаление поддерева). Затем с использованием дерева запросов определяется, какие реляционные
представления подвергаются операции обновления, и создаются SQL-выражения – по одному для каждого из
соответствующих реляционных представлений.
3. SQL/XML и деревья запросов
В 14 части стандарта SQL:2003 описывается расширение языка SQL (т.н.,SQL/XML) для поддержки
XML в реляционных СУБД: приводятся правила преобразования SQL-данных в XML и обратно и описываются
дополнительные конструкции SQL, позволяющие получать XML-документы (или их части) с помощью расши-
ренного оператора SELECT.
Опишем здесь основные конструкции для получения XML-данных с помощью расширенных SQL-
запросов
1, затем перейдём к рассмотрению правил построения деревьев запросов на основе расширенных пред-
ложений SELECT.
XMLElement и XMLAttributes. XMLElement создаёт элемент документа XML, при этом в качестве опе-
рандов выступают имя и содержимое элемента. Имя указывается в качестве первого аргумента функции, при-
чём перед именем должно стоять обязательное ключевое слово NAME. Далее может идти произвольное количе-
ство операндов, цель которых – перечисление данных (значение, атрибуты и элементы), которые содержит дан-
ный элемент. XMLAttributes служит для создания списка XML-атрибутов соответствующего XML-
элемента. Пример:
SELECT
XMLElement(
NAME phone,
XMLAttributes(p.product_id AS id)
XMLElement(NAME price, p.product_price)
)
FROM ViewPhone AS p
В результате выполнения данного выражения будет создана совокупность из элементов <phone> (по
одному на каждую строку представления ViewPhone), содержащих атрибуты @id и по одному вложенному
элементу <price>, каждый из которых в свою очередь содержит в виде значения цену.
XMLForrest. Функция создаёт последовательность XML-элементов из последовательности перечислен-
ных в качестве операндов имён столбцов. Пример:
SELECT
XMLElement(
NAME phone,
XMLAttributes(p.product_id AS id)
XMLForrest(p.product_name AS name, p.product_price AS price)
)
FROM ViewPhone AS p
XMLConcat. Производит операцию конкатенации, объединяя различные XML-элементы в лес элемен-
тов, образуя единый документ.
XMLAgg. Данная конструкция действует над совокупностью значений, производя лес XML-элементов.
Например, для получения XML-документа, подобного тому, что изображен на рис.1, можно использовать сле-
дующее выражение:
SELECT
XMLElement(
NAME vendor,
XMLAttributes(v.vendor_id AS id),
XMLAgg(
XMLElement(
NAME products
XMLElement(
NAME phone,
XMLForrest(p.product_name AS name, p.product_price AS price)
)
)
)
)
FROM
vendor AS v
JOIN product AS p ON p.product_vendor_id = v.vendor_id
GROUP BY
vendor_id
Правила построения деревьев запросов на основе SQL/XML-выражений. Опишем правила построе-
ния деревьев запросов на основе выражений SELECT, использующих приведенные выше конструкции. Но сна-
1 Здесь приведен неполный список конструкций. Исчерпывающий список, содержащий формальные определения всех функций, можно
найти в тексте стандарта SQL/XML [4].
Моделі і засоби систем баз даних і знань
454
чала необходимо сделать пару замечаний. Во-первых, необходимо отметить, что в общем случае такие выраже-
ния возвращают не один документ, а совокупность XML-элементов. Это значит, что простая конкатенация даст
лес элементов, что не является корректным XML-документом. Проблема легко может быть разрешена введени-
ем корневого элемента-контейнера. Во-вторых, использование такого расширенного оператора SELECT для
определения представлений (CREATE VIEW viewname AS SELECT…) стандартом не предусматривается. Но
тем не менее это представляется возможным, если ввести дополнительные допущения. Будем рассматривать
только те операторы SELECT, которые в списке выборки содержат одну или несколько функций XMLElement
верхнего уровня (иными словами, результат выполнения запроса не содержит не-XML данные). Кроме того,
будем считать, что после выполнения оператора лес XML-элементов подвергается операции конкатенации и
включается в элемент-контейнер с названием, совпадающим с названием представления.
При указанных допущениях правила построения дерева запросов просты. Построение происходит в два
этапа. Первый этап состоит в разборе списка выборки и построения структуры дерева запросов без задания де-
скрипторов источника, ограничения и сортировки. Второй этап – разбор разделов FROM, WHERE и ORDER
BY оператора SELECT, что дает возможность определить дескрипторы и завершить построение дерева запро-
сов.
Корневая вершина дерева имеет название, совпадающее с названием XML-представления. От неё исхо-
дит *-ребро к вершине, описывающей получение XML-элемента верхнего (для оператора SELECT) уровня. За-
тем для каждого описываемого элемента и атрибута определяем вершину в дереве запросов, сохраняя отноше-
ния вложенности. Заметим, что конструкции XMLAttributes и XMLForrest в общем приводят к созданию
нескольких вершин. Конструкция XMLAgg (и только она!) приводит к появлению дополнительных *-ребер. Для
всех листовых вершин необходимо указание источника (при этом дескрипторы на первом этапе не определяют-
ся, но начинают использоваться альтернативные имена источников).
На втором этапе проводится анализ разделов FROM (для построения дескрипторов источника), WHERE
(для построения дескрипторов ограничения) и ORDER BY (дескрипторы сортировки). Для каждой таблицы-
источника в разделе FROM создаётся дескриптор источника и помещается в вершине, которая является общим
предком всех вершин, содержащих обращения к данному источнику. Аналогичные действия производятся с
содержимым разделов WHERE и ORDER BY.
4. Применение техники деревьев запросов
Как уже отмечалось, задача экспорта реляционных данных в формате XML сегодня является чрезвычай-
но актуальной. Конструкции, определенные в 14-й части стандарта SQL:2003, призваны обеспечить такую воз-
можность в реляционных СУБД.
Деревья запросов позволяют, прежде всего, осуществить поддержку XML-представлений в реляционных
СУБД. Задачи таких представлений аналогичны задачам реляционных представлений: интеграция данных и
защита данных. Интеграция достигается за счёт объединения информации из различных таблиц (кроме того,
если реляционная СУБД поддерживает встроенный XML-тип, то возможна интеграция данных различного рода
– реляционного и XML), а решение вопросов защиты информации может быть достигнуто с помощью наложе-
ния ограничений на данные. Именно поэтому задача поддержки обновления таких представлений является ак-
туальной. Возможно построение систем, поставляющих данные в виде XML-представлений удалённым аген-
там, от которых полная информация о природе данных и которым доступна только часть информации. Как ча-
стный случай такой системы можно рассматривать универсальное средство для создания web-интерфейсов ра-
боты с данными, речь о котором пойдет в следующем разделе.
4.1. XViews: система динамического создания интерфейсов работы с данными. Изложенные выше
приемы работы с XML-представлениями над реляционными СУБД были использованы при разработке прило-
жения XViews.
Идея этого приложения заключается в следующем. Большая часть интерфейсов работы с данными (на-
пример, редакторские интерфейсы порталов, интерфейсы для работы с данными о сотрудниках предприятия и
т.п.) по своей структуре представляют собой иерархически организованное множество текстовых полей ввода,
списков выбора, radio-кнопок и других элементов. В то же время, как правило, вся информация хранится в ре-
ляционных базах данных (причины этому обсуждались во введении к данной работе). Поэтому возникла идея
использования теории обновления XML-представлений над реляционными БД для упрощения и ускорения раз-
работки интерфейсов для работы с данными.
В качестве теоретической основы была взята теория деревьев запросов, впервые предложенная в [5]. В
качестве реляционной СУБД использовалась Microsoft SQL Server 2000, основного языка программирова-
ния – PHP5, что дало возможность применения достаточно мощной библиотеки для работы с XML libxml2, а
также стандарта объектного представления XML-документов DOM XML.
Были созданы следующие основные классы:
1. QueryTree – класс, имплементирующий понятие дерева запросов. Само дерево запросов задается
в виде XML-файла, DTD которого представлен в Приложении B. После загрузки XML-файла стро-
ится DOM-дерево, описывающее дерево запросов и определяются типы вершин (τ, τC, τS, τN или
Моделі і засоби систем баз даних і знань
455
τT). После этого процесс создания объекта класса завершается и он готов к дальнейшей работе. В
дополнительные возможности класса входит графическое представление (отрисовка с помощью
библиотеки gd2) в виде единого png-файла полученного дерева (пример – рис.3 - 6).
2. QueryTree_XMLConstructor – класс для создания XML-представления (алгоритм eval).
3. QueryTree_Mapper – класс для отображения XML-представления, созданного с помощью дере-
ва запрсов с одной вершиной типа τN, в одно соответствующее ему реляционное представление
(алгоритм mapping).
4. QueryTree_Splitter расщепляет дерево запросов с несколькими вершинами типа τN и τT в не-
сколько простых деревьев (алгоритм split).
5. QueryTree_Translator – класс для трансляции обновления XML-представления в набор SQL-
выражений обновления соответствующих реляционных представлений.
Таким образом, была построена основа (прототип) для системы динамического создания web-
интерфейсов с древовидной структурой для работы с данными, хранящимися в реляционной БД.
На данный момент поставлены следующие задачи дальнейшей разработки системы.
• Этап построения дерева запросов. Процесс построения дерева запросов заключается в созда-
нии XML-файла экспертом, который должен знать систему, схему БД и конечный вид представле-
ния. Необходимо создать инструментарий, решающий задачу визуального создания дерева запро-
сов. Предполагаемые языки программирования и технологии: Java, libxml2.
• Этап создания интерфейса на основе XML-представления. Создание библиотеки автоматиче-
ского построения front-end систем. Предполагаемые языки программирования и технологии: PHP5,
DHTML, XSLT, Macromedia Flash MX 2004. (На данный момент реализовано на основе Flash MX
2004 для простых видов представлений).
• Теоретические основы. Расширение класса возможных представлений (увеличение поддержи-
ваемых видов описаний ограничений, разрешение простых операций с получаемыми из БД значе-
ниями, констант), введение системы дополнительных связей (для организации списка выбора и
т.п.). Исследование возможности использования ссылочных ограничений целостности для автома-
тического построения шаблонов представлений (мастера построения представлений).
• Использование XMLHttpRequest [16] для создания динамичных интерфейсов (интферейсов,
позволяющих вызывать операции обновления без перегрузки страницы).
Конечная цель разработки данной системы – создание приложения XViews, универсального (неза-
висимого от платформы) инструмента создания удобных web-интерфейсов для работы с данными.
4.2. Поддержка обновляемых XML-представлений в ОРСУБД PostgreSQL. PostgreSQL - это свобод-
но распространяемая объектно-реляционная система управления базами данных, наиболее развитая из откры-
тых СУБД в мире и являющаяся реальной альтернативой коммерческим базам данных. Именно поэтому разви-
тие поддержки XML в целом и XML-представлений в данной СУБД представляется актуальной задачей. На
данный момент XML-поддержка заключается в возможности сохранения XML-данный в виде CLOB-значений
и последующего применения XPath-выражений к таким данным (модуль contrib/xml2). Очевидно, это не обес-
печивает решение всей совокупности задач, описанных выше. Для расширения поддержки XML планируется
осуществление следующих шагов:
• Реализация функций SQL/XML. К сожалению, стандартный синтаксис оказывается очень «не-
удобным» для реализации, в основном по двум причинам: требование ключевого слова NAME в
конструкции XMLElement и возможность указания произвольного числа операндов в некоторых
конструкциях. Именно поэтому реализация с использованием стандартного API для написания
пользовательских функций и операторов представляется невыгодной и было предложено (и час-
тично реализовано) дополнение в виде patch’a. Возможно, данное дополнение будет включено в
версию 8.2.
• Создание встроенного XML-типа. Основные проблемы возникающие при реализации данной за-
дачи таковы: создание индекса для доступа к частям документов; поддержка методов манипуляции
с такими данными.
• Обеспечение возможности создания обновляемых XML-представлений.
Заключение
Решение задачи обновления XML-представлений открывает новые перспективы работы с данными на
стыке двух совершенно разных технологий – XML и реляционных баз данных. Сочетание преимуществ реля-
ционных СУБД и широких возможностей XML в универсальной системе позволяет достичь хороших результа-
тов. Проблема обновления XML-представлений на данный момент не является хорошо изученной. Поэтому
многое еще предстоит исследовать в этой области.
Описанный подход работы с данными с помощью деревьев запросов создает основу для простой работы
с обеими технологиями одновременно. Представляя собой простую для понимания конструкцию, деревья за-
просов позволяют создавать XML-представления, приводить их ко второй нормальной форме, отображать на
множество реляционных представлений, осуществлять преобразование обновлений XML-документа в набор
SQL-выражений.
Моделі і засоби систем баз даних і знань
456
В данной статье был описан подход к решению проблемы обновления XML-представлений, основы ко-
торого изложены в [5]. Предложено расширение класса поддерживаемых представлений за счет поддержки бо-
лее широкого множества ограничений и введения дополнительного типа описаний вершин – описаний сорти-
ровки. На примере приложения XViews была продемонстрирована возможность эффективного применения де-
ревьев запросов для решения задачи автоматизации, упрощения и ускорения построения интерфейсов работы с
данными. В заключение приведен краткий анализ возможности реализации поддержки обновляемых XML-
представлений в СУБД PostgreSQL.
Схема БД web-каталога Приложение A
DTD для описания деревьев запросов в виде XML-файлов Приложение B
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT root (children)>
<!ATTLIST root
name CDATA #IMPLIED
atype (T | TS | TC | TN | TT) #IMPLIED
>
<!ELEMENT node (
source-annotation*,
where-annotation*,
sortby-annotation*,
children
)>
<!ATTLIST node
name CDATA #REQUIRED
edgetype (simple | starred) #REQUIRED
atype (T | TS | TC | TN | TT) #IMPLIED
>
<!ELEMENT children (node | leafnode)*>
<!ELEMENT leafnode EMPTY>
<!ATTLIST leafnode
name CDATA #REQUIRED
edgetype (simple | starred) #REQUIRED
value CDATA #REQUIRED
atype (T | TS | TC | TN | TT) #IMPLIED
>
<!ELEMENT source-annotation EMPTY>
<!ATTLIST source-annotation
var CDATA #REQUIRED
table CDATA #REQUIRED
>
<!ELEMENT where-annotation (#PCDATA)>
<!ELEMENT sortby-annotation>
<!ATTLIST sortby -annotation
var CDATA #REQUIRED
desc CDATA #IMPLIED
>
Все вершины дерева запросов задаются элементами root, node и leaf-node. Ребра дерева описываются по-
средством промежуточных элементов children, которые могут быть дочерними у root или node. Изначально в
XML-файле дерева запросов не задается атрибут “atype” у элементов root, node и leaf-node, соответствующий
абстрактному типу вершины (поэтому он не является обязательным), но обязательно атрибут edgetype, отве-
чающий за тип входящего ребра в дереве запросов.
Моделі і засоби систем баз даних і знань
457
1. Extensible Markup Language (XML) 1.0. W3C Recommendations. (2004).
2. Carey M.; Florescu D.; Ives Z.; Lu Y. XPERANTO: Publishing Object-Relational Data as XML. International Conference on Very Latge Data
Bases, Edinburgh, Scotland, 1999.
3. Date C.; McGoveran D. Updating Views (6 Parts), 1994, 2001.
4. http://www.w3.org/TR/2004/REC-xml-20040204/
5. Braganholo V.; Davidson S.; Heuser C. On The Updatability of XML Views over Relational Databases. Proceedings of WEBDB 2003, San
Diego, SA, USA, 2003.
6. Braganholo V.; Davidson S.; Heuser C. Propagating XML View Updates to a Relational Database. Тесhnical Report RP-341. Universidade
Federal do Rio Grande do Sul, Instituto de Informatica, Porto Alegre, RS, Brazil, 2004.
7. Braganholo V.; Davidson S.; Heuser C. Reasoning about The Updatability of XML Views over Relational Databases. Тесhnical Report MS-
CIS-03-13. University of Pennsylvania, Philadelphia, PA, USA, 2003.
8. SQL:2003. ISO/IEC JTC 1 / SC 32 / Editor: Jim Melton. 2003.
9. Florescu D.; Kossmann D. Storing and Querying XML Data using an RDMBS. IEEE Data Engineering Bulletin 22, 1999.
10. W3C DTD Specification. (1998) - http://www.w3.org/XML/1998/06/xmlspec-report-v21.htm
11. XML Path Language (XPath) Version 1.0. W3C Recommendations, 1999. - http://www.w3.org/TR/xpath
12. XML Schema Part 2: Datatypes. W3C Recommendations, 2001. - http://www.w3.org/TR/xmlschema-2/
13. SQLXML Home, - http://www.sqlxml.org/
14. Lee D.; Chiu W. Schema Conversion Methods between XML and Relational Models, 2002.
15. Malcolm G. Programming Microsoft SQL Server 2000 with XML. ISBN: 0735617740 (12 June, 2002).
16. Новак Л.Г.; Кузнецов С.Д. Свойства данных XML. Труды ИСП РАН, том 4. – 2003.
17. Dynamic HTML and XML: The XMLHttpRequest Object. http://developer.apple.com/internet/webcontent/xmlhttpreq.html
|
| id | nasplib_isofts_kiev_ua-123456789-1635 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Russian |
| last_indexed | 2025-12-01T14:55:39Z |
| publishDate | 2006 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Самохвалов, Н.А. 2008-09-01T13:28:29Z 2008-09-01T13:28:29Z 2006 Поддержка обновления XML-представлений над реляционными базами данных / Н.А. Самохвалов // Проблеми програмування. — 2006. — N 2-3. — С. 445-457. — Бібліогр.: 17 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/1635 004.655.3 В статье рассматриваются способы реализации задачи построения механизма обновляемых XML-представлений над реляционными базами данных с использованием техники и предлагаются способы расширения множества поддерживаемых представлений. Приведенные правила построения деревьев запросов для стандартных SQL/XML - конструкций делают возможным реализацию данного подхода в виде модуля реляционной СУБД. Приводится описание реализации метода деревьев запросов для создания инструмента разработки web-интерфейсов к реляционным данным и обзор возможных областей применения данного подхода. This paper presents an overview of methods for solving the problem ofcreation of the system supporting updatable XML-views over relational databases using query trees and proposes further ways to extend the set of views supported. The given rules of query trees creation for SQL/XML construction make possible the realization of such approach as a module of relational DBMS. In addition, the tool for webinterfaces development as an example of query trees method implementation is described and short review of possible areas of implementation of this approach is presented. ru Інститут програмних систем НАН України Моделі і засоби систем баз даних і знань Поддержка обновления XML-представлений над реляционными базами данных Updatable XML Views Over Relational Databases Article published earlier |
| spellingShingle | Поддержка обновления XML-представлений над реляционными базами данных Самохвалов, Н.А. Моделі і засоби систем баз даних і знань |
| title | Поддержка обновления XML-представлений над реляционными базами данных |
| title_alt | Updatable XML Views Over Relational Databases |
| title_full | Поддержка обновления XML-представлений над реляционными базами данных |
| title_fullStr | Поддержка обновления XML-представлений над реляционными базами данных |
| title_full_unstemmed | Поддержка обновления XML-представлений над реляционными базами данных |
| title_short | Поддержка обновления XML-представлений над реляционными базами данных |
| title_sort | поддержка обновления xml-представлений над реляционными базами данных |
| topic | Моделі і засоби систем баз даних і знань |
| topic_facet | Моделі і засоби систем баз даних і знань |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/1635 |
| work_keys_str_mv | AT samohvalovna podderžkaobnovleniâxmlpredstavleniinadrelâcionnymibazamidannyh AT samohvalovna updatablexmlviewsoverrelationaldatabases |