Сайт Информационных Технологий Недорого купить розетки электрические с доставкой.

Каталог >> Интернет >> XML >> ТЕХНОЛОГИЯ XML – НОВАЯ СТРАНИЦА В РАЗВИТИИ СУБД

ТЕХНОЛОГИЯ XML – НОВАЯ СТРАНИЦА В РАЗВИТИИ СУБД

Веселов В.В. Долженков А.Н.

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

Изменение требований привело к попыткам создания технологии объектно-ориентированных БД, которую к настоящему моменту нельзя назвать завершенной. Перспективы ее завершения вызывают серьезные сомнения, поскольку наиболее быстро развивающейся сегодня, а значит и наиболее перспективной завтра, является технология XML.


Семантическое сравнение языков - реляционного и XML
Объектные модели реляционной и объектно-ориентированной БД
Объектная модель XML
Интерфейс объектной модели XML и интерфейсы физического хранения
Выводы
Литература


Семантическое сравнение языков - реляционного и XML

В предыдущей нашей статье [1] мы уже сравнивали язык XML с реляционным и обратили Ваше внимание на два следующих важных момента, которые необходимо напомнить в более четкой формулировке:

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

Во-вторых, любые реляционные данные могут непосредственно быть отображены в XML, но не наоборот. Конкретно:

1.XML поддерживает упорядоченное хранение данных, а реляционное представление его не поддерживает. Например, с реляционной точки зрения это одно и тоже: <A/><B/><A/> или <B/><A/><A/>

2.Между реляционными таблицами связи могут быть только на уровне записей, но не на уровне значений. Например, для этого тега нужна отдельная таблица: <A Ref1=”#1”>a1</A>

3.Запись в реляционной таблице не может содержать нескольких значений для одного реквизита. Например, тег A не может быть представлен реквизитом (требуется таблица), но это нарушит однородность тегов A и B: <Tab1><A>a1</A><A>a2</A><B>b1</B> </Tab1>.

Для того чтобы вышесказанное не осталось для менее искушенного читателя голой абстракцией, проследим, к чему это приводит. Для этого приведем простой пример. Рассмотрим некий документ с входящим номером 51, который представлен в виде XML следующим совершенно прозрачным образом:

<Документ Номер="51" Тип=”Предложение”>
<Содержание>Мы, ваши сотрудники</Содержание>
<Автор>Иванов Иван</Автор>
<Автор>Петрова Мария</Автор>
<Содержание>предлагаем Вам ...</Содержание></Документ>

Если мы хотим полностью отразить содержимое этой простой служебной записки в реляционной БД, то нам потребуется создать целых три (!) таблицы следующего вида (рис. 1):

Таблица 1: “Документ”

Номер

Тип

51

Предложение

Таблица 2: “Автор”

Номер

Автор

Позиция

51

Иванов Иван

2

51

Петрова Мария

3

Таблица 3: “Содержание

Номер

Позиция

Содержание

51

1

Мы, Ваши сотрудники

51

4

предлагаем Вам...

Рис. 1.

Для того чтобы мы могли автоматически воссоздать документ в своем первоначальном виде, необходимо сохранить в БД порядок следования значений реквизитов. Для этого в таблицы 2 и 3 добавлен служебный реквизит "Позиция". Сделанное преобразование семантически полное, "реляционно-безупречное" и очень неудобное для использования. Попробуем подойти несколько иначе - уберем таблицу 3, а вместо служебного реквизита "Позиция" сделаем в таблице 1 реквизит "ПолныйТекст" (рис. 2):

Таблица 1: “Документ”

Номер

Тип

ПолныйТекст

51

Предложение

Мы, Ваши сотрудники Иванов Иван, Петрова Мария предлагаем Вам...

Таблица 2: “Автор”

Номер

Автор

51

Иванов Иван

51

Петрова Мария

Рис. 2.

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

1. В предыдущем варианте часто встречающийся бюрократический штамп "Мы, ваши сотрудники" был значением реквизита, соответственно он мог быть индексирован и по нему пользователь мог выполнять выборку в БД определенного типа документов, а теперь нет.

2. БД приобрела так называемую "вредную избыточность" по реквизиту "Автор". Если "Петрова" сменит фамилию на "Сидорова", и Вы захотите откорректировать соответствующие записи в БД, то Вас ждет большая работа - фамилии в значениях реквизита "ПолныйТекст" придется менять "вручную".

Дальнейшее "улучшение" структуры БД можно сделать, если ликвидировать таблицу 2, а вместо нее в таблице 1 создать реквизит "Автор" и записать в его единственное значение сразу обоих авторов (рис. 3):

Таблица 1: “Документ”

Номер

Заголовок

Автор

ПолныйТекст

51

Предложение

Иванов Иван Петрова Мария

Мы, Ваши сотрудники Иванов Иван, Петрова Мария предлагаем Вам...

Рис. 3.

Теперь мы получаем более тонкий, но не менее неприятный недостаток, связанный с типом данных. По здравому смыслу реквизит "Автор" относился раньше к типу данных упорядоченный список из двух элементов: первый элемент - фамилия, второй - имя. Теперь он, наверное, просто текст, со всеми вытекающими отсюда последствиями, связанными с индексацией и поиском.

В конце концов, можно вообще убрать реквизит "Автор" и перейти к неструктурированному хранению содержимого документа только в виде реквизита “ПолныйТекст”, но при этом сама БД теряет смысл как таковая. К сожалению, в современных реляционных БД при хранении подобных документов часто именно такая картина и наблюдается.

Объектные модели реляционной и объектно-ориентированной БД

Объектно-ориентированные БД, с первого взгляда, можно принять просто за результат объектного описания реляционной модели данных. Действительно:

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

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

Этот вопрос тесно связан с вопросом способа описания связей между таблицами или классами. Такая сущность как "связь" принципиально отсутствует в реляционной модели по причине ее логической избыточности [3]. Вместо нее используются понятия "первичный ключ" и "ссылочный ключ", не отягощающие логику реляционной алгебры дополнительными построениями. Причем ссылочный ключ находится в дочерней таблице и ссылается на первичный ключ, находящийся в родительской таблице.

Вернемся к нашему старому примеру (рис. 1). Таблица 1 является родительской, таблицы 2 и 3 по отношению к ней дочерними. Первичными ключами в таблице 1 являются значения реквизита "Номер", в таблице 2 - "Номер" и "Позиция", в таблице 3 - "Номер" и "Автор". Ссылочными ключами в таблицах 2 и 3 являются значения реквизита "Номер".

Объектный подход описывает эти связи совершенно иначе. "Связь", как сущность, также отсутствует, вводятся понятия "Идентификатор" (объекта) и "Ссылка" (на этот идентификатор). В отличие от реляционной модели, ссылка находится не в дочернем, а родительском классе, идентификатор же, напротив, в классе дочернем, а не в родительском.

Если изобразить этот объектный подход в виде табличек, то получим рис. 4. Ссылочные ключи в классах 2 и 3 стали не нужны, и мы их удалили (в рамках объектного подхода ссылочный ключ часто рассматривают как одно или несколько свойств объекта, наследуемых от родительского). Первичные ключи не потеряли своей значимости, поскольку они используются не только для организации связей, но и для обеспечения уникальности объектов. В классе 2 "Автор" уникальность объекта определяется не автоматически присваиваемым системой идентификатором, а именно значением свойства "Автор". По смыслу этого примера, двух "Иванов Иван" в одной докладной записке быть не может, даже если у них разные идентификаторы.

Класс 1: “Документ”

Идентификатор

Номер

Тип

Автор (ссылка)

Содержание (ссылка)

1

51

Предложение

1, 2

1, 2

Класс 2: “Автор”

Идентификатор

Автор

Позиция

1

Иванов Иван

2

2

Петрова Мария

3

Класс 3: “Содержание”

Идентификатор

Позиция

Содержание

1

1

Мы, Ваши сотрудники

2

4

предлагаем Вам...

Рис. 4.

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

Таким образом, это нововведение идет в разрез с реляционной алгеброй, а значит, требует существенной переработки логико-математического аппарата, которая, на текущий момент времени, не является завершенной.

К достижениям объектно-ориентированной технологии относят также интегрирование поведенческого и структурного аспектов [2]. К этому вопросу нужно относиться с осторожностью - что именно интегрируется и куда.

Если речь идет о методах реляционной алгебры (или, если угодно, "объектной алгебры"), то они, очевидно, должны быть общими для всех классов в БД, а значит, унаследованы из одного специального системного класса и, разумеется, не инкапсулированы в конкретные классы. Если речь идет о методах логики работы конкретного приложения (бизнес-логики), то их также имеет смысл размещать в конкретном специальном классе, связанном с этим приложением - приложений может быть много и они меняются, а структура БД остается.

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

Объектная модель XML

Объектная модель XML построена существенно иначе [4]. Существует два основных класса - XML-документ, каждый из объектов которого описывает какой-либо документ в целом, и XML-узел, каждый из объектов которого описывает каждый из узлов иерархического дерева этого документа. Несколько упрощая, можно сказать, что класс XML-узел, не считая идентификатор, имеет пять основных свойств - Тип, Имя, Значение, Дети (ссылка на дочерние узлы кроме атрибутов) и Атрибуты (ссылка на них как на дочерние узлы).

Свойство "Тип" может принимать целое значение от 1 до 12, то есть на сегодняшний день всего существует 12 типов узлов. Из них мы кратко рассмотрим четыре: 9 - Документ, 1 - Элемент, 2 - Атрибут элемента, 3 - Текст. Из названных типов узлов индивидуальное имя имеют 1 и 2, значением обладают 2 и 3, ссылками на идентификаторы дочерних узлов - 9, 1, 2, ссылками на атрибуты –1.

В отличие от рассмотренной выше объектной модели, ссылка на дочерние узлы представляет собой не неупорядоченный, а упорядоченный список. Этот список может содержать идентификаторы узлов типа - 1, 2, 3. Свойство “Атрибуты” представляет собой неупорядоченный список атрибутов и содержит идентификаторы узлов типа 2. Если изобразить наш пример в виде таблички, то получим следующее (рис. 5):

Класс: “XML-узел”

Идентификатор

Тип узла

Имя узла

Значение узла

Дети (ссылка)

Атрибуты (ссылка)

1

9

(#document)

-

2

-

2

1

Документ

-

7,9,11,13

3,5

3

2

Номер

51

4

-

4

3

(#text)

51

-

-

5

1

Тип

Предложение

6

-

6

3

(#text)

Предложение

-

-

7

1

Содержание

-

8

-

8

3

(#text)

Мы, Ваши сотрудники

-

-

9

1

Автор

-

10

-

10

3

(#text)

Иванов Иван

-

-

11

1

Автор

-

12

-

12

3

(#text)

Петрова Мария

-

-

13

1

Содержание

-

14

-

14

3

(#text)

предлагаем Вам...

-

-

Рис. 5.

Отметим любопытный момент - значения узлов с идентификаторами 3 и 4, а также 5 и 6 дублируют друг друга, что говорит о незавершенности объектной модели как таковой (конкретно - не установлена окончательно модельная роль атрибута). Вообще говоря, модель имеет определенную логическую избыточность (например, по количеству типов узлов), обусловленную причинами исторической преемственности, однако избыточность скомпенсирована унификацией представления.

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

Ограниченность набора низкоуровневых операций позволяет представить преобразование одного XML-документа в другой в виде данных - опять же в виде XML-документа. Грубо говоря, бизнес-логика может быть построена как преобразование одних XML-документов в другие при помощи третьих. Описания данных (метаданные) разложены в ту же объектную модель, описания описаний - тоже. Таким образом, XML-ориентированная БД полностью сама себя описывает.

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

Интерфейс объектной модели XML и интерфейсы физического хранения

В большинстве случаев БД, для организации физического хранения данных на диске, используются либо индексно-последовательные файлы, либо B*-деревья. B*-деревья обеспечивают весьма быстрый доступ к хранимым данным, сортировку данных в момент их записи, сжатие ключей и т.д. Конкретная реализация B*-деревьев - это секрет фирмы-разработчика. Внешний интерфейс этого программного ядра секретом как таковым не является. Однако разработчику приложений, обычно, в сервисном виде этот низкоуровневый доступ не предоставляется, а предоставляются высокоуровневые реляционный и объектный интерфейсы, с помощью которых он и создает логику приложения.

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

Представление B*-деревьев в интерфейсе прямого доступа называется в Cache глобалом. Глобал - это хранимый на диске рассортированный по строковым индексам массив произвольной размерности вида:

^G(Ind1,Ind2,...,IndN)=Text,

где G – имя глобала, индексы Ind1,Ind2,...,IndN и значение Text - любые строки текста, 1,2,...,N - уровень иерархии индекса, N - произвольно.

XML-документ непосредственно отображается в структуру глобала, причем не единственным способом. В простейшем варианте в нечетный индекс попадает тип и имя узла, а в четный - его позиция в списке других дочерних элементов его родителя:

^G(Name1,Pos1,Name2,Pos2,...,NameN,PosN)=Value,

где Name1,...,NameN - тип и имя узла, Pos1,...,PosN - его позиция по порядку, 1,2,...,N - уровень их вложенности, Value - значение узла.

Применительно к нашему примеру, глобал может иметь следующий вид:

^DataBase(Документ,51,@Тип)=Предложение
^DataBase(Документ,51,Содержание,1)=Мы, Ваши сотрудники
^DataBase(Документ,51,Содержание,4)=предлагаем Вам...
^DataBase(Документ,51,Автор,2)=Иванов Иван
^DataBase(Документ,51,Автор,3)=Петрова Мария

В данном, наиболее простом варианте, учтено, что теги “Содержание” и “Автор” содержат только текст, причем в виде единственного узла. Если бы, например, “Петрова” и “Мария” представляли собой два разных текстовых узла относящихся к общему родителю ”Автор”, то вместо последней строки необходимо было бы использовать более полную запись:

^DataBase(Документ,51,Автор,3,#text,1)=Петрова
^DataBase(Документ,51,Автор,3,#text,2)=Мария

Индексы глобала, возникшие из атрибутов, помечены первым символом “@”, а индексы, возникшие из узлов с фиксированными именами – “#”. Атрибут номер удален, поскольку его значение представляет собой уникальный позиционный код тега “Документ”.

Для иллюстрации соответствия логики интерфейсов прямого доступа Cache и объектной модели XML приведем простой пример. Откроем базу данных и получим на нее ссылку. Далее найдем документ 51, найдем его первый дочерний узел, найдем следующий за ним и присвоим ему значение “Сидоров Сидор” вместо “Иванов Иван”.

В варианте XML:

MyActXObj = new ActiveXObject("Microsoft.XMLDOM");
RefDB = MyActXObj.load(“database.xml”);
RefDoc = RefDB.selectSingleNode(“/Документ[@Номер=’51’]”);
RefFirstCh = RefDoc.firstChild;
RefNextSb = RefFirstCh.nextSibling;
RefNextSb.value = “Сидоров Сидор”;

В варианте Cache:

Set RefDB=$Name(^DataBase)
Set RefDoc=$Name(@RefDB@(”Документ”,51))
Set RefFirstCh=$Name(@RefDoc@($Order(@RefDoc@(“”))))
Set RefNextSb=$Name(@RefDoc@($Order(@RefFirstCh)))
Set @RefNextSb=“Сидоров Сидор”

Выводы

Подведем краткий итог всему вышесказанному:

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

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

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

4.В конкурентной борьбе на рынке технологий СУБД преимуществами будут обладать те фирмы, которые уже имеют технологические преимущества в рамках тенденций развития ситуации. Фирме InterSystems не нужно “с нуля” разрабатывать ядро XML-ориентированной базы – оно у нее уже есть.

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

Литература

  1. Веселов В., Долженков А. XML и технологии баз данных. – “Открытые Системы”, №05-06/1999.
  2. Кузнецов С. Объектно-ориентированные базы данных - основные концепции, организация и управление: краткий обзор. -
  3. Кузнецов С. Анализ вклада Кодда в Великий спор. – там же.
  4. Бумфрей Ф. и др. XML. Новые перспективы WWW. Пер. с англ. – М.:ДМК, 2000. –688 с.
  5. Сайт фирмы InterSystems -

Site of Information Technologies
Designed by  inftech@webservis.ru.