В предыдущей нашей статье [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" Тип=”Предложение”>

<Содержание>Мы, ваши сотрудники</Содержание>

<Автор>Иванов Иван</Автор>

<Автор>Петрова Мария</Автор>

<Содержание>предлагаем Вам ...</Содержание></Документ>

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

Рис. 1.

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

Рис. 2.

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

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

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

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

Рис. 3.

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

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

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

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

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

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

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

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

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

Рис. 4.

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

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

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

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

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

Объектная модель 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):

Рис. 5.

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

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

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

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

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

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

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

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

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

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

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

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

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

Для иллюстрации соответствия логики интерфейсов прямого доступа 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=“Сидоров Сидор”