Семантика баз данных
12.2.2 Полуструктурированные данные
Модель полуструктурированных данных, допускающая необязательные атрибуты, может использоваться для интегрирования данных, полученных их разных источников, и для представления данных с нечетко определенной или меняющейся структурой.
В моделях, допускающих только обязательные атрибуты, схема данных определяется заранее, априорно, и только затем начинается работа с данными. В полуструктурированных моделях используются апостериорные схемы, называемые обычно руководствами по данным (Data Guide). Они могут быть не известны до ввода данных и, уж точно, могут изменяться в процессе работы.
СУБД предназначенные для работы с полуструктурированными моделями данных существуют, но во многих случаях удобнее использовать соответствующие расширения в традиционных СУБД.
Принято выделять тяжеловесные (heavyweight) или легковесные (lightweight) модели полуструктурированных данных. В первых пытаются для работы с хорошо структурированными данными использовать традиционные средства, а для остальных вырабатывать средства специфические для плохо структурированных данных. Легковесные модели не предполагают такого разделения данных и потому хуже оптимизированы.
Мы будем заниматься эмуляцией одной из легковесных моделей OEM (Object Exchange Model), созданной в Стэнфордском университете для СУБД Lore, предполагая, что запросы можно разделять по степени структурированности данных и потому проблемы с оптимизацией запросов для хорошо структурированных данных нет.
Модель OEM представляется ориентированным графом с именованными ребрами. Хранимые объекты, которые могут быть простыми (атомарными) или сложными, представляются вершинами графа, имеющими уникальные идентификаторы. Простые объекты принимают значения одного из базисных типов, но не имеют исходящих ребер, Сложные объекты, наоборот, имеют исходящие ребра, но не имеют значений. Некоторым вершинам приписываются имена, используемые как точки входа в граф. Такую вершину называют еще корнем.
Объект OEM имеет структуру, представленную в таблице 12.2. Object_ID — уникальный идентификатор или NULL, Label — имя объекта, записанное текстовой строкой, Туре — тип данных, Value — значение, записанное текстовой строкой.
Простейший пример полуструктурированной базы в модели OEM представлен на рисунке 12.8. Отображаются два объекта. Это лица, связанные отношениями "быть сыном" и "быть матерью". У объекта "мать" имеется атрибут "цвет волос", отсутствующий у объекта "сын".
Обычно путеводителем по данным (рисунок 12.9) называют граф, который для каждого вида объектов содержит единственный узел, с которым связаны все атрибуты, существующие хотя бы у одного объекта. Будем называть его путеводителем или максимальным путеводителем. Можно считать, что он образован объединением без повторений всех объектов базы.
Добавим еще минимальный путеводитель (рисунок 12.10), образованный пересечением всех объектов базы.
Для реализации модели OEM в Cache необходимо в глобалах, которые могут быть только деревьями, научиться представлять добавленные ветви ссылок, соединяющих узлы одного уровня. Можно ссылки (связи, дополняющие дерево) хранить как компоненты значения узла. Можно ориентированную ссылку, имеющую имя "пате" и действующую из узла ^P(a1,a2, . . . ,аn) в узел ^P(b1,b2, . . . ,bm), хранить как узел ^Р(a1, а2, . . ., аn, "_name", "b1, b2, . . ., bm" ). При этом, его родитель ^Р (a1, а2, . . ., аn, "_name " ) является виртуальным узлом.
На рисунке 12.11 показан пример реализации базы и путеводителя в одном глобале Cache. Имя узла и его номер относительно одноименных узлов хранятся в одном индексе. Виртуальные узлы не выделены.
Можно хранить в индексе не полные имена узлов, а номера их предков. Кроме того, узел путеводителя может хранить количество узлов данных соответствующего типа. Например, на рисунке 12.11 запись ^P("DataGuide", "Person", "аде" )="2;1,2" значит, что в базе есть два свойства "age" у узлов типа "Person", а именно: у узлов ^Р("Person#l") и ^P("Person#2").
В DataGuide можно включить частоту появления некоторого свойства у типа. Она может быть больше 1 (например, у человека может быть несколько номеров телефонов). Можно учитывать сам факт вхождения узлов некоторого типа: при этом из нескольких однотипных потомков учитывается только один.
Мы не будем обсуждать такие важные детали, как реализация автоматически перестраиваемого путеводителя, организация навигации по объектам и по связям, создание индексов на связи между узлами, необходимых для ускорения поиска путей между узлами и поддержания целостности данных.
Обратим внимание на то, что рассмотренная реализация полуструктурированной модели стала возможной в первую очередь благодаря заданию своеобразной семантики элементов представляющего глобала, в частности, за счет использования горизонтальных ссылок.