научная статья по теме ПОДДЕРЖКА ЭВОЛЮЦИИ СХЕМ ДАННЫХ В XML-РЕЛЯЦИОННЫХ СИСТЕМАХ БАЗ ДАННЫХ Математика

Текст научной статьи на тему «ПОДДЕРЖКА ЭВОЛЮЦИИ СХЕМ ДАННЫХ В XML-РЕЛЯЦИОННЫХ СИСТЕМАХ БАЗ ДАННЫХ»

ПРОГРАММИРОВАНИЕ, 2008, № 1, с. 23-37

БАЗЫ ДАННЫХ И БАЗЫ ЗНАНИЙ

УДК УДК 004.89

ПОДДЕРЖКА ЭВОЛЮЦИИ СХЕМ ДАННЫХ В ХМЬ-РЕЛЯЦИОННЫХ СИСТЕМАХ БАЗ ДАННЫХ

© 2008 г. А. А. Симановский

ООО "ИнтеллиДжей Лабе" 197342 Санкт-Петербург, ул. Кантемировская, 2а E-mail: asimanovsky@yandex.ru Поступила в редакцию 28.06.2006 г.

Многие XML-реляционные системы, т.е. системы, использующие XML-схему в качестве внешней и реляционную в качестве внутренней схемы уровня представления данных приложения, требуют изменения схем данных со временем. Эволюция схем данных - один из способов поддержки изменения схем данных приложения на уровне СУБД. В настоящее время предложен целый ряд систем поддержки эволюции схем для различных моделей данных. Эволюция схем может быть применена и к изменяющимся схемам, связанным отображением (таким, как схемы XML-реляционных систем), задача трансформации которых также известна как адаптация схем. В данной работе представлен обзор различных подходов к решению означенного круга задач.

1. ВВЕДЕНИЕ

Ряд современных приложений, работающих с базами данных, таких, например, как электронные системы учета медицинской информации [1], CAD-системы, требуют от уровня представления данных приложения возможности модификации (изменения) со временем хранимых данных, а также и схем данных. Процесс изменения схемы данных в подобных системах является неотъемлемой частью жизненного цикла приложения [2]. Таким образом, для производителей СУБД актуальной задачей является поддержка модификаций со временем концептуальной (а также, возможно, внутренней) схемы хранимых данных, так как это уменьшает объем работы при создании внешних схем данных подобных приложений.

Рассматриваемые приложения часто используют XML и такие языки запросов, как XQuery [3], в качестве интерфейса к уровню представления данных, который, в свою очередь, использует мощные промышленные реляционные СУБД в качестве хранилища данных, реализуя логику преобразования работы с моделью данных XML в работу с реляционной моделью

[4-6] и, таким образом, представляя собой XML-реляционные системы. Как следствие, возникает вопрос модификации пары связанных отображением XML- и реляционной схем.

Системы поддержки эволюции схем и контроля версий схем [7] являются одним из решений задачи модификации схемы в рамках СУБД. Они упорядочивают действия при изменении схем, позволяют описывать семантику изменений в предметной области и отражать изменения предметной области, происходящие со временем, в базе данных, распространяя эти изменения на схему хранимых данных и сами данные. Они избавляют от необходимости создания и реализации ad-hoc алгоритмов по изменению схем и данных при каждой модификации. В настоящее время существуют системы поддержки эволюции схем данных для реляционной [8-14], объектно-ориентированной [15-30], XML-моделей данных [31-34].

При описании модификаций взаимозависимых схем также применима эволюция схем [35], а не только исключительно интеграция схем. Целью данной работы является обоснование этого тезиса на основе обзора существующих моделей эволюции схем и преобразований XML-данных в реляционные.

2. СХЕМЫ И МОДЕЛИ ДАННЫХ

Прежде, чем переходить к описанию существующих систем поддержки эволюции схем данных, определим ряд понятий, с точки зрения которых будут анализироваться различные системы. В первую очередь обратимся к схемам и моделям данных. Приложения работают с данными, используя некоторую схему данных.

Схема данных (или просто схема) - это ме-таинформация, описывающая структуру хранимых данных и, возможно, операции над ними.

Модель данных - это описание класса схем данных, позволяющее выразить структуру, правила целостности, языки доступа к данным, удовлетворяющим схемам из этого класса.

Наибольшее распространение в настоящее время имеют реляционные СУБД, для которых накоплен большой объем исследовательских и промышленных достижений. Реляционные СУБД используют реляционную модель данных, первоначально предложенную в [36] и [37].

Реляционная модель1 определяется следующими пятью составляющими:

• семейством скалярных типов, включающим булевский тип;

• генератором реляционных типов с фиксированной интерпретацией реляционных значений, имеющих данные типы;

• способом определения реляционных переменных, имеющих реляционные типы;

• оператором присваивания значений реляционным переменным;

• семейством реляционных операторов, позволяющих получать одни реляционные значения по другим.

Дальнейшие пояснения по каждой из составляющих можно найти в работах [38-40]. В традиционных реализациях для промышленных СУБД эти составляющие реализуются следующими сущностями:

1 Следуя работе [38], мы рассматриваем определение реляционной модели, удобное для изучения темпоральных данных, о которых пойдет речь ниже.

• скалярными типами boolean, integer, varchar (I: integer) и т.д.;

• генератором реляционных типов, задающим тип как упорядоченное произведение скалярных типов и набор имен для них; интерпретацией является предикат, прообразом значения "истина" которого являются кортежи, вошедшие в реляционное значение;

• реляционными переменными, которые определяются именем и могут иметь первичные и внешние ключи;

• операторами присваивания, роль которых играют модифицирующие операторы SQL (UPDATE, DELETE и т.д.);

• реляционными операторами, которыми являются выборка, проекция, декартово произведение, соединения, теоретико-множественные операции, а также их аналоги из SQL (SELECT, JOIN, UNION, INTERSECT, EXCEPT).

Реляционной схемой является набор реляционных переменных. При записи реляционной схемы часто выделяют множества функциональных зависимостей и другие свойства реляционных переменных.

Вместо "отношение/реляционная переменная", "атрибут", "домен" может использоваться терминология "таблица", "столбец", "тип столбца". Это удобно при одновременном упоминании составляющих реляционных и XML-схем.

Для XML был предложен целый ряд моделей данных, например, в работе [41]. Наиболее сложным для исследователей является выбор языка запросов и средств описания ограничений схем, что привело к большому числу стандартов в этих областях (XPath, XQuery, DTD, XMLSchema и т.д. [42]). В настоящее время стандартизованы и широко используются несколько моделей XML, например, XDM (XQuery and XPath Data Model, [43]). Однако, целый ряд вопросов, особенно алгебраическая семантика XML, остаются задачей для исследования [44]. В предлагаемом определении мы выделим один аспект - свойство слабой структурированности

и самоописываемости XML-данных: интерпретация данных зависит от приложения и от значений данных.

Модель данных XML определяется следующими составляющими:

• строковым типом;

• генератором алфавитов имен тэгов и атрибутов;

• генератором DTD (определение DTD дано ниже);

• способом определения XML-документов, соответствующих данному DTD: XML-до-кументом, соответствующим данному DTD, является иерархия имен тэгов и связанных с ним пар (имя атрибута, значение), являющаяся словом в языке, определяемом данным DTD, и удовлетворяющая условию на имена атрибутов;

• интерпретацией XML-документа, соответствующего данному DTD, является предикат, определяемый на декартовом произведении доменов, где домены - это множества, задаваемые отображением из множества имен тэгов. Данное отображение мы назовем синтаксической интерпретацией приложения (или просто интерпретацией приложения);

• языком запросов к XML-документам.

DTD является отображением из алфавита строковых имен тэгов в декартово произведение класса языков над данным алфавитом и множества подмножеств алфавита имен атрибутов.

В XML все данные имеют строковый тип2. Их фактический тип (то, что мы называем синтаксической интерпретацией приложения) задается предметной областью. В данной работе мы делаем предположение о том, как устроено определение фактического типа. Мы предъявляем следующее требование иерархичности

2 Строго говоря, это справделиво только для DTD. В других средствах описания XML-схем, например, XMLSchema [45], введены типы данных. В рамках приведенного определения эти типы данных можно рассматривать как частичную синтаксическую интерпретацию.

к интерпретации приложения. Пусть I - интерпретация приложения, тогда

I(t) = f(h,t2, ■ ..,tk,a\,al,. ..,а^к), (1)

где ti образуют последовательность вложенных (в соответствии с DTD) тэгов, включающих t, а — соответствующие (в соответствии с DTD) этим тэгам атрибуты.

Требование иерархичности означает, что приложение способно интерпретировать значение атрибута, имея информацию о его имени и тэге, в котором он расположен; а интерпретация приложением значения тэга определяется набором тэгов, в которые вложен данный, а также значением его атрибутов и атрибутов объемлющих тэгов. Подобное предположение соответствует неформальным рекомендациям по проектированию XML-данных [46].

В настоящее время в качестве языков запросов к XML используются XSLT, XPath, XQuery. Их отличительной особенностью, которую мы будем использовать, является независимость синтаксического вида запроса от синтаксической интерпретации приложения (именно этим обоснован выбор слова "синтаксическая" в отношении интерпретации приложения). Наоборот, изменение структуры XML-документа приводит к необходимости изменения синтаксиса XPath/XQuery-запроса для сохранения выдаваемого им результата. Подобные модификации мы будем называть семантическими. Заметим, что эта терминология является, до некоторой степени, обратной к терминологии, которую можно было бы ввести с точки зрения приложения, использующего модель данных XML: типовая информация является для приложения семантической, в то время как структурная -большей частью вопросом синтаксиса. Тем не менее, структурная информация может нести с точки зрения приложения и семантическую нагрузку.

При описании модификации данных и схем данных со временем модель данных, реляционную, XML- или какую-либо другую, необходимо расширить средствами выражения временной природы данных и схем. Временная природа данных рассматривается в рамках исследований, посвященных темпоральным базам д

Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.

Показать целиком