Организация сложных объектов в XSQL
Под сложным объектом базы данных, следуя идеологии разработчиков XSQL, мы понимаем совокупность кортежей одного или нескольких отношений базы данных, совместно содержащих информацию об одном реальном объекте предметной области.
В начале работ по развитию System R в направлении инженерных приложений в них активно участвовал известный специалист в области реляционных систем баз данных В.Ким (который в дальнейшем перешел в MCC и в настоящее время, видимо, отошел от этих работ). Мы подчеркиваем этот факт по той причине, что, пожалуй, лучшей публикацией о сложных объектах в System R является [61], список авторов которой он возглавляет.
Напомним, что при организации памяти для хранения баз данных в System R был выбран подход, при котором эффективность доступа определялась в основном кластеризованностью одного или нескольких отношений по одному или нескольким полям. Под кластеризованностью понимается физическое размещение кортежей одного или нескольких отношений, обладающих одинаковым значением выделенных атрибутов, в одной или смежных физических страницах внешней памяти.
Кластеризация одного отношения позволяет наиболее эффективно осуществлять выборки в соответствии с указаниями значений полей кластеризации. Совместная кластеризация нескольких отношений (допустимая, но не используемая в последних версиях System R) обеспечивает потенциальную возможность эффективного выполнения соединения этих отношений по полям кластеризации. Эффективность выполнения операций может быть обеспечена за счет существования индекса на полях кластеризации (при совместной кластеризации можно было бы использовать аппарат связей или мультииндексов).
В принципе, такая организация уже дает возможность эффективно управлять сложными объектами, поскольку необходимые соединения нескольких отношений становятся ненакладными. Но при этом семантика сложного объекта остается неизвестной системе. В частности, необходимо отдельно от описания структуры объекта указывать необходимые условия целостности, и невозможно автоматически проверить их достаточность.
Второй деффект такого подхода мы уже отмечали - избыточность и неудобство работы на прикладном уровне с плоскими представлениями выбранных в оперативную память объектов.
Напрашивается решение ввести структуру сложного объекта на уровне хранения. Физические возможности для организации ссылок между кортежами обеспечиваются уровнем управления памятью System R - каждый кортеж получает на время своего существования уникальный идентификатор (tid), по которому возможен прямой доступ к кортежу. Но такое решение повлекло бы два следствия. Во-первых, нужно было бы переделывать подсистему управления памятью, перегружая ее информацией, по сути дела, логического уровня. Во-вторых, наличие между кортежами физических ссылок вызвало бы усложнение операции копирования сложного объекта как единого целого.
Подход, выбранный в XSQL, решает проблемы управления сложными объектами на логическом уровне СУБД с использованием средств кластеризации отношений, предоставляемых физическим уровнем (сам физический уровень, т.е. RSS, при этом не меняется по сравнению с System R).
Все отношения, кортежи которых входят в сложный объект, расширяются одним полем - суррогатом или логическим идентификатором кортежа. Ссылки между кортежами сложного объекта - это тоже явно указанные поля отношений на физическом уровне, и значения ссылок есть суррогаты кортежей. Структура сложного объекта (а тем самым и правила кластеризации составляющих его отношений и условия целостности сложного объекта) описывается на расширенном SQL. Конструкции расширенного SQL, предназначенные для определения структуры сложного объекта, довольно громоздки, и формальное описание синтаксиса языка в публикациях не приводится.
Отношение, кортежи которого являются корнями иерархий сложных объектов, расширяется еще одним большим по объему полем, которое содержит таблицу приписки суррогатов кортежей, составляющих данный сложный объект, к их физическим идентификаторам. Таким образом, для того, чтобы полностью выбрать сложный объект (или его указанный подобъект) достаточно найти каким-либо образом его корневой кортеж и пройти по ссылкам.
Кластеризация кортежей сложного объекта делает эту операцию эффективной. Заметим по этому поводу, что хотя при реализации прототипа XSQL использовался тот же вариант RSS, что и в System R (точнее, в SQL/DS), в этой реализации используются возможности RSS по части совместной кластеризации кортежей нескольких отношений (в описанном в Разделе 2 интерфейсе RSS мы не упоминали эту возможность, поскольку она не использовалась в System R).
Возможны два пути указания подобъектов сложного объекта. Если наиболее важным фактором является эффективность выборки, то общие подобъекты нескольких сложных объектов физически копируются. Это не создает проблем с их физической согласованностью, потому что на уровне SQL модификация отношений происходит в соответствии с условием модификации и потому просто невозможно выполнить модификацию только одной копии кортежа (различающие их суррогаты не видны на уровне SQL). Но, конечно, при такой организации операция модификации может стать дорогостоящей.
Второй допустимый способ - физическое разделение общего подобъекта несколькими объектами. В этом случае ссылка становится несколько более сложной, но сохраняется логической. При таком способе организации, вообще говоря, теряется эффективность выборки, но модификации дешевы.
Наличие логических ссылок и таблицы приписки позволяет после выборки сложного объекта в основную память образовать обычную списковую структуру, заменив логические ссылки в кортежах на указатели по оперативной памяти. Такая структура сложного объекта в оперативной памяти очень удобна для последующей обработки на прикладном уровне. Наличие таблицы приписки, устанавливающей соответствие логических идентификаторов кортежей с их tid'ами, позволяет легко реализовать операцию копирования сложного объекта. При этом нужно модифицировать только одно поле (содержащее таблицу приписки) корневого кортежа объекта.
Появление новой управляющей структуры - таблицы приписки сложного объекта добавляет возможности при выборе способа пути доступа в оптимизаторе СУБД.Как подчеркивается в [61], бывает полезно использовать таблицу приписки (своего рода индекс) не только при выборке сложных объектов.
Диалект SQL, используемый в XSQL, содержит несколько расширений, относящихся в средствам выборки. Все они, естественно, отражают специфику работы со сложными объектами и составляющими их кортежами. Вообще говоря, язык в результате в некоторой степени утратил свою простоту, но зато достаточно сложные запросы можно формулировать лаконично. Соответствующим образом расширены и операторы занесения, удаления и модификации кортежей, входящих в сложные объекты.
| |
