ПРОГРАММИРОВАНИЕ, 2009, № 3, с. 22-34
БАЗЫ ДАННЫХ И БАЗЫ ЗНАНИЙ
УДК 681.3.06
АЛГОРИТМЫ ИНТЕГРАЦИИ СУБД PostgreSQL С СЕМАНТИЧЕСКИМ ВЕБ
© 2009 г. Д. В. Левшин, А. С. Марков
0,10 ницэвт
117545 Москва, Варшавское шоссе, 125 E-mail: levshin@nicevt.ru, markov@nicevt.ru Поступила в редакцию 11.04.2008 г.
В данной статье рассматривается интеграция СУБД PostgreSQL с семантическим веб. Предлагаются алгоритмы интеграции, основанные на использовании возможностей СУБД и не предполагающие внесения изменения в SQL. Представлена реализация интеграции на основе одного из алгоритмов, поддерживающая основные форматы семантического веб. Предложенные алгоритмы могут быть реализованы в других СУБД, поддерживающих триггеры (или правила), табличные функции и индексирование.
1. ВВЕДЕНИЕ
Данная статья посвящена интеграции PostgreSQL [1] - разработанной Калифорнийским университетом в Беркли открытой объектно-реляционной системы управления базами данных (СУБД) - с семантическим веб.
Автором идеи семантического веб [2] считается Тим Бернерс-Ли. С 1999 года проект семантической паутины развивается под эгидой W3C. Семантический веб становится все более популярным: концепция активно пропагандируется и внедряется как многими проектами с открытым исходным кодом, так и крупными компаниями.
Семантический веб определяется как расширение Всемирной паутины (World Wide Web), такое, что в нем информация снабжена точно определённым смыслом, благодаря чему взаимодействие людей с компьютерами становится еще успешнее. Внедрение семантического веб предоставит широкие возможности для машинной обработки информации. В частности, семантический веб позволит поисковым системам получать ответы на запросы более сложные, чем доступные сегодня, увеличит эффективность выполняемого поиска.
Основные форматы семантического веб считаются трудными для понимания рядовыми пользователями Интернета, поэтому актуальной задачей является разработка программ, упрощающих пользователю использование возможностей семантического веб. В то же время в большинстве распространенных СУБД, включая PostgreSQL, нет возможностей для работы с данными семантического веб, что и послужило основной причиной исследований и реализаций, представленных в данной работе.
Для проведения исследований по интеграции СУБД с семантическим веб была выбрана PostgreSQL, так как она считается наиболее развитой из открытых СУБД и при этом позволяет достаточно легко добавлять новые возможности. При разработке алгоритмов интеграции было принято решение, что SQL и стандарты не модифицируются, требуется внедрять данные семантического веб с использованием тех возможностей, которые уже имеются в PostgreSQL.
В статье кратко описаны существующие решения для работы с семантическим веб, использующие СУБД, и возможности PostgreSQL для выполнения интеграции. После чего представлены разработанные алгоритмы интеграции PostgreSQL с семантическим веб и вопросы реализации.
1.1. Форматы семантического веб
Приведем кратко сведения об основных форматах семантического веб, позволяющих пользователям выражать информацию и правила вывода. В феврале 2004 г. в качестве стандарта W3C для создания понятного компьютеру описания ресурсов в семантической паутине был утвержден формат RDF [3] (Resource Description Framework).
В RDF все утверждения описывается в виде триплетов (троек) вида "предмет (субъект)-свойство (глагол) - значение свойства (объект данного утверждения)". Использование триплетов позволяет определять выражения произвольной сложности, но в форме, достаточно простой для понимания машиной. Для однозначного понимания данных выражений различными приложениями решено было использовать для обозначения ресурсов URI (Uniform Resource Identifier). В каждом триплете субъект и предикат являются ресурсами, а объект может быть или ресурсом, или литералом в формате UNICODE.
RDF является основой семантического веб, представляя только базовые возможности. Более богатые возможности доступны при использовании расширений RDF. Расширение RDF -RDF Schéma (RDFS) [4] - предоставляет возможности определения специфичных для приложений классов и свойств, иерархии классов, указания того, какой тип должны иметь субъект и объект для данного свойства. Эта информация может восприниматься как ограничения на классы и свойства или же средство для вывода новых утверждений. Язык веб-он-тологий OWL (Web Ontology Language) [5] может использоваться, чтобы явно представлять значения терминов и отношения между этими терминами в словарях. SWRL (Semantic Web Rule Language) [6] является расширением OWL, добавляя возможность определения правил, подобных хорновским. Предлагаемые правила имеют вид импликации между предпосылкой (телом) и следствием (заголовком), состоящими из нуля или более унарных и бинарных атомов.
2. ОБЗОР СУЩЕСТВУЮЩИХ РЕШЕНИЙ
Создание программных средств для работы с семантическим веб ведется очень активно. В данном разделе особо отметим те из них, кото-
рые позволяют использовать СУБД или основаны на них.
Полезным для освоения семантического веб является программное средство с открытыми кодами Protégé [7]. Его коммерческим аналогом является TopBraid Composer [8], определяемый как профессиональная среда разработки для RDF, RDFS, OWL, SWRL и языка запросов SPARQL [9] в соответствии со стандартами W3C и предоставляющий полный набор возможностей для покрытия всего жизненного цикла разработки семантических приложений. При рассмотрении схемы Protégé [10] можно выделить 2 основные части: представления и модельную. Модель разработана таким образом, что позволяет достаточно просто ее расширять, в частности, добавить возможности работы с OWL. Модель Protégé содержит собственный API, использующий Jena API.
Jena [11] - это открытая Java-среда для создания приложений семантического веб. Среда Jena предоставляет программное окружение для RDF, RDFS, OWL и SPARQL, а также включает основанный на правилах движок логического вывода. Она включает RDF и OWL API, чтение и запись RDF в форматах RDF/XML, N3 и N-Triples, хранение в памяти и в базах данных, а также движок запросов SPARQL.
В [12] приводятся схемы хранения RDF-дан-ных, используемые в Jenal и Jena2 (втором поколении Jena). В Jenal используется нормализованная схема, предполагающая, что все триплеты хранятся в единой таблице утверждений в виде троек целых чисел, ссылающихся на таблицы ресурсов и литералов. Данная схема является эффективной с точки зрения использования пространства, но в Jena2 она была заменена на ненормализованную с целью уменьшения времени выполнения запросов. Ее отличием является то, что литералы и URI, длина которых как строк не превосходит некоторого заданного предела, хранятся в таблице утверждений напрямую, что уменьшает число операций соединения при выполнении запросов. Чтобы сократить используемое при данном подходе пространство, вводятся таблица префиксов, таблицы свойств, а установление нулевого предела длины приводит схему Jena2 к нормализованной.
Sesame [13] является родовой архитектурой для хранения и выполнения запросов к RDFS-данным, а не конкретной реализацией такой системы. Для поддержания различных возможностей хранения (в том числе в реляционных СУБД), а также выполнения логического вывода выделяется SAIL-уровень. Функциональные модули Sesame, включая движок RQL-запросов, выполнены как клиенты SAIL-уровня. Для поддержки различных способов взаимодействия с функциональными модулями в различных средах используются обработчики различных протоколов (HTTP, SOAP и др.). Возможность добавления собственных обработчиков протоколов и реализаций SAIL-уровня делает данную архитектуру достаточно гибкой. Оборотной стороной такой гибкости является то, что в Sesame не используются возможности оптимизации запросов, предоставляемые используемыми СУБД: оптимизация выполнения RQL-за-просов производится соответствующим модулем Sesame.
Решения, указанные выше, основаны на использовании специально определенных API, языков запросов, опираются на использование Java. В [14] указан ряд недостатков такого подхода и предлагается решение, основанное на использовании SQL и избегающее этих проблем. Для хранения RDF-данных используется схема, похожая на используемую в Jenal. Для выполнения запросов к RDF-данным вводится специальная табличная функция, одним из аргументов которой является шаблон требуемого графа. Результаты этой функции могут использоваться в запросах к другим данным в базе. При выполнении данной функции полученный шаблон преобразуется в запрос с самосоединениями к таблицам, содержащим RDF-данные. Предложенный в [14] подход поддерживает логический вывод на основе RDFS и простые пользовательские правила без произвольной рекурсии и может быть реализован в любой реляционной СУБД, где поддерживаются табличные функции, материализованные представления на соединения и В-деревья.
Отметим, что в большинстве рассмотренных решений для хранения RDF-данных в реляционных базах данных используется нормализованная схема с различными модификациями. В [13] приводится иная схема, предполагающая со-
здание отдельных таблиц для каждого имеющегося класса и использование подтаблиц. Отмечается, что она имеет ряд недостатков, а ее использование позволяет получить производительность хуже, чем при применении нормализованной схемы.
3. ИССЛЕДОВАНИЕ СПЕЦИФИКИ ВОЗМОЖНОСТЕЙ СУБД PostgreSQL ДЛЯ ВЫПОЛНЕНИЯ ИНТЕГРАЦИИ
Стоит остановиться на некоторых возможностях PostgreSQL, которые могут быть полезны при выполнении интеграции. Для выполнения запросов к RDF-дaнным может быть полезным использование табличных функций, эффективный доступ к данным может быть обеспечен с помощью индексных структур. Табличные функции и функции триггеров могут быть написаны на языке С или одном из процедурных языков. Для более наглядного отражения содержимого базы данных могут использоваться представления.
Для того чтобы СУБД смогла выполнять логический вывод утверждений на основе загруженных правил и онтологий, можно использовать два механизма - триггеры и систему правил. Триггер позволяет указать, что определенная функция буд
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.