Базы данных в Семантической паутине

Уже два десятилетия назад было ясно, что экспоненциальный рост объема данных, хранимых в WWW, приведет
к невозможности их обработки традиционными методами с участием человека. Впоследствии это стимулировало интерес к идее Semantic Web, предлагающей ряд форматов для хранения информации и прежде всего RDF (Resource Description Framework). Использование RDF сейчас поощряют поисковые гиганты: вслед за Yahoo! и компания Google недавно объявила о поддержке структурированных данных (RDF и микроформаты) для повышения информативности результатов поиска.

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

Большинство нынешних СУБД основаны на реляционной модели данных, а формат RDF, по сути, также является определением модели данных, но удобной для автоматической машинной обработки и нацеленной прежде всего на использование в WWW. В RDF информация представлена не в таблицах, а в наборах троек «субъект-свойство-объект». Каждый из элементов тройки является ресурсом, которому присвоен идентификатор Uniform Resource Identifier, объект также может быть литералом в формате Unicode. Используя URI, отдельные тройки могут сливаться в единые RDF-графы, что упрощает интеграцию распределенных источников информации. RDF-графы могут включать не только явно записанные, но и логически выведенные тройки. Эту возможность обеспечивают расширения RDF – RDF Schema и OWL (Web Ontology Language). Доступ к RDF выполняется с помощью языка запросов SPARQL (SPARQL Protocol and RDF Query Language), некоторые аспекты которого схожи с SQL.

Означает ли распространение RDF отказ от привычных баз данных? Положительный ответ мог бы расцениваться как большое препятствие на пути Semantic Web, но, к счастью, внедрение RDF не только не отвергает принятые сегодня базы данных, но и может получить от них выгоду. Теоретически при создании новой информационной системы можно каждый раз решать, как хранить RDF-данные, однако одним из преимуществ RDF является наличие различных средств хранения данных, как в основной памяти, так и на дисках, а также программных интерфейсов, упрощающих создание таких хранилищ.

На заре Semantic Web задача обработки больших наборов RDF-данных не стояла так остро, как проблема их публикации, и неудивительно, что первые появившиеся программные средства были нацелены на работу с RDF-данными, целиком помещающимися в основную память. Разработчиков больше привлекали вопросы организации логического вывода информации для выражений языка OWL, основанные на методах, традиционных в дескриптивных логиках. В числе таких инструментов можно, например, назвать коммерческий RacerPro, предлагаемый компанией Franz, и открытый Pellet. Также появилась среда Jena, предоставляющая программный интерфейс, упрощающий создание семантических приложений. Этих средств уже было достаточно для быстрого создания небольших информационных приложений, однако оставался нерешенным вопрос масштабирования, вызванный предчувствием появления во Всемирной паутине больших объемов RDF-данных. Как следствие, появились коммерческие и открытые RDF-хранилища.

В среде Jena начиная с версии 1.3 поддерживается долговременное хранение моделей в реляционных базах данных, эта же возможность имеется и в открытой среде Sesame. В названных средствах предполагается, что обработка данных и логический вывод выполняются в основной памяти, что означает слабую связанность с базой данных, но лучшая эффективность и масштабируемость выполнения запросов достигаются при использовании средств, опирающихся на возможности СУБД для логического вывода новых фактов. Например, в набор средств и хранилищ HAWK (swat.cse.lehigh.edu/projects/index.html#hawk) включены различные модели хранения в памяти или в базе данных, с логическим выводом или без него. В их число входит использующая базы данных и выполняющая вывод на основе дескриптивных логик модель DLDB (Description Logic Data Base), позволяющая хранить RDF-данные в Microsoft Access, PostgreSQL или MySQL, покрывая часть конструкций OWL. Другим примером делегирования задачи логического вывода СУБД является система Owlgres, использующая PostgreSQL. Ускорение запросов достигается за счет нескольких факторов, включая сокращение передач данных между базой данных и приложением, а также минимизацию использования плохо пригодных для ответа на запросы традиционных алгоритмов дескриптивных логик.

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

Стоит, однако, понимать, что разработчикам RDF-хранилищ приходится находить компромисс между выразительностью поддерживаемых диалектов OWL и эффективностью, масштабируемостью хранения и доступа к RDF-данным. Обычно средства, слабо связанные с базой данных, поддерживают больше конструкций OWL, но для более ограниченных наборов данных, чем более тесно связанные или интегрированные решения. Выбор хранилища может производиться на основе потребностей конкретной задачи и имеющейся СУБД. Помочь в выборе может сравнение средств на основе контрольных задач, таких как LUBM (Lehigh University Benchmark) или SP2Bench (SPARQL Performance Benchmark).

Наполняя Семантическую паутину

На ранних этапах развития Semantic Web важнейшей задачей была публикация RDF-данных, и благодаря строгой структуре реляционные базы данных рассматривались как отличный источник RDF. Кроме того, к реляционным данным, представленным в RDF, применимы различные семантические технологии, в частности решается задача интеграции разнородных баз данных, рассматриваемая в Oracle в качестве варианта использования Semantic Web на уровне предприятия. Также может быть решена проблема поисковой доступности информации из Deep Web – контента, доступного только динамически через Web-формы и неиндексируемого поисковыми движками.

Актуальность публикации RDF-данных из реляционных таблиц подчеркивает создание в рамках W3C специальной группы RDB2RDF (Relational Database to RDF Mapping), в задачи которой входит исследование, классификация и стандартизация методов отображений. Группа в начале 2009 года представила подробный обзор существующих методов.

В большинстве методов таблицы отображаются в классы OWL, свойства которых определяются столбцами таблицы. Некоторые таблицы также могут представляться в виде свойств, а не классов, если они задают отношения между строками других таблиц. Элементы классов и значения свойств могут генерироваться один раз при отображении (такой метод называют RDF-дампом) или по требованию, то есть при выполнении запроса. В последнем случае результатом отображения является не физический, а виртуальный RDF-граф. Каждый из методов обладает и достоинствами, и недостатками:

• RDF-дампы могут использоваться в дальнейшем независимо от СУБД или же служить в качестве резервной копии базы данных;
• выполнение запросов к RDF-дампам осуществляется быстрее, чем к виртуальным графам, но зато труднее отслеживать их соответствие текущему содержимому базы данных при ее изменениях.

Существуют и другие характеристики, по которым различаются методы. Например, в том, как классы ставятся в соответствие таблицам: создаются ли новые классы или берутся из некоторой OWL-онтологии. Отображение источников в существующую глобальную онтологию сложнее, чем создание локальных онтологий, но полезно при интеграции разнородных источников информации. Между локальными и глобальной онтологиями также может быть установлено соответствие для обеспечения интеграции информации.

Приведем несколько примеров. Декларативный язык D2RQ используется в сервере D2R Server (Database to RDF) для доступа к виртуальным RDF-графам. В сервере Virtuoso компании OpenLink Software реализована функциональность автоматизированной публикации RDF по базе данных. В SPASQL, название которого образовано слиянием аббревиатур SPARQL и SQL, предпринималась попытка реализации запросов SPARQL над базами данных MySQL. Существующие методы отображений в основном являются научными разработками, однако их количество, а также интерес к данному вопросу со стороны W3C дают надежду на то, что методы будут развиваться. В число вопросов, которые должны решаться при этом, входят следующие: как обеспечивать права доступа к RDF-данным, полученным из таблиц; как учитывать при отображении ограничения целостности? Ограничения могут быть полезны в различных случаях, включая семантическую оптимизацию запросов SPARQL и создание резервных копий баз данных. Однако их создание связано с трудностями, которые проявляются при моделировании.

Моделирование

Язык OWL был спроектирован специально для описания произвольной предметной области, однако различные отрасли знаний зачастую предъявляют противоречащие друг другу требования к формальному языку своего представления. В частности, такой конфликт возник между допущениями, принятыми во Всемирной паутине, для которой предназначен OWL, и в базах данных. В Semantic Web не делается используемое в базах данных предположение о закрытости мира, согласно которому любая не включенная в базу информация считается неверной. Оно неприменимо для Всемирной паутины, в которой документы могут быть временно недоступны или не найдены, что вовсе не означает их ошибочности. Также в базах данных часто предполагается уникальность имен объектов, но запрет идентификации одинаковых ресурсов различными URI сделал бы практически невозможной децентрализованную распределенную публикацию информации и интеграцию различных ее источников.

Этот конфликт не сказывается, когда нужно представить в RDF только данные из таблиц, но влияет при использовании в отображениях информации, заключенной в ограничениях баз данных, или при использовании OWL для моделирования баз данных. На первый взгляд кажется, что достаточно представить таблицы как классы OWL, их столбцы – как свойства, а для спецификации типов значений столбцов использовать типы данных XML Schema. Даже то, что стандарт OWL и большинство реализующих его систем поддерживают только два обязательных типа данных – строковый и целочисленный, не является серьезной проблемой, так как в OWL 2 их список планируется расширить.

Рассмотрим, как сказывается конфликт при моделировании. Пусть, например, проектируется база данных системы резервирования авиабилетов, в которой определены две таблицы, Заказ и Клиент. Пусть действует ограничение, что любой заказ сделан одним клиентом. Данное ограничение затем может быть реализовано как внешний ключ между таблицами, а в UML оно определяется созданием ассоциации между классами и указанием для нее кратности соответствующей роли, равной единице. В OWL также есть возможность определения так называемых ограничений свойств, в том числе ограничений кардинальности. В частности, в классе Заказ может быть определено свойство забронирован, соответствующее аксиоме:

SubClassOf(Заказ intersectionOf(restriction(забронирован cardinality(1)) restriction(забронирован allValuesFrom(Клиент)))

Данная аксиома задает условие, по которому все элементы класса Заказ имеют ровно одно значение свойства забронирован, которое в свою очередь принадлежит классу Клиент. Аксиома, казалось бы, моделирует желаемое ограничение, но здесь скрыты подводные камни. Пусть бронь123 – элемент класса Заказ, имеющий два значения свойства забронирован – Михаил и Майкл. Проектировщик баз данных, записавший вышеуказанную аксиому, может ожидать, что такая ситуация недопустима. Однако, поскольку в OWL не делается допущение об уникальности имен, вместо обнаружения ошибки будет сделан вывод, что Михаил и Майкл идентифицируют одного и того же клиента. Более того, аксиома не препятствует и наличию объектов класса Заказ, для которых неизвестно значение свойства забронирован; в данном случае исходя из открытости мира будет предполагаться, что существуют безымянные объекты класса Клиент, которые являются такими значениями.

Исключить такое неожиданное поведение можно только сменой парадигмы OWL или архитектуры Semantic Web, но подобные изменения будут противоречить природе Всемирной паутины и потому имеют мало шансов на успех. Однако проблема с моделированием может решаться на более высоком уровне архитектуры, на уровне Правил либо с помощью языка запросов SPARQL. В частности, можно сформулировать запрос на поиск всех заказов, забронированных более чем одним клиентом или незабронированных вовсе. Наличие таких заказов означает несогласованность базы данных.

Взгляд в будущее

Использование технологий Semantic Web не означает отказа от привычных реляционных баз данных, однако разработка семантических технологий не обязана ограничиваться только технологиями традиционных СУБД, тем более что привычные таблицы, хранящие информацию по строкам, не всегда являются лучшим выбором для Web. В частности, для электронной коммерции или новостных порталов лучше может подходить вертикальная схема хранения данных в виде таблицы с тремя столбцами, соответствующими идентификатору объекта, имени и значению его атрибута.

Майкл Стоунбрейкер заявляет, что со времен появления System R, от которой берут начало современные СУБД, произошли существенные изменения в аппаратуре, целевых рынках и интерфейсах доступа, но архитектура СУБД с тех пор не пересматривалась. Традиционная модель данных уже перестает быть решением всех проблем, и наступает время для активных исследований новых моделей данных, предназначенных не для общих целей, а для использования в отдельных сегментах рынка. Нельзя исключать, что в будущем на смену RDF-хранилищам, основанным на традиционных СУБД, придут специализированные RDF-СУБД, называемые в числе необходимых инструментов реализации интеллектуальных агентов в Semantic Web.

Переход на RDF-СУБД обещает быть безболезненным для пользователей и разработчиков, и основная проблема здесь – обеспечение работоспособности приложений, созданных для доступа к SQL-ориентированным СУБД, при взаимодействии с новыми RDF-хранилищами. Стандартным языком доступа к RDF является SPARQL, поэтому решение данной проблемы может заключаться в создании надстройки над RDF-СУБД, преобразующей SQL-запросы в SPARQL, а получаемые ответы – обратно в таблицы. Эта идея реализуется в системе R2D. Использование надстроек, подобных R2D, позволит пользователям выполнять доступ к RDF-данным как с помощью нового языка SPARQL, так и посредством привычного SQL.

* * *

Применение семантических технологий не требует отказа от существующих, хорошо знакомых и широко используемых. Более того, барьер на пути внедрения Semantic Web помогает преодолеть опора на такие технологи, как реляционные базы данных, SQL. Когда нет никаких средств хранения RDF-данных, логичным представляется использовать методы и технологии, которые зарекомендовали себя как эффективное и масштабируемое решение этой проблемы в различных областях. В свою очередь, семантические технологии помогут увеличить доступность и функциональность традиционных баз данных и Web-форм. Это не означает, что семантические форматы должны использоваться на всех этапах жизненного цикла базы данных: например, UML лучше подходит для их проектирования, чем OWL в нынешнем его состоянии. Хотя в семантических приложениях используются существующие базы данных, не стоит исключать, что распространение Semantic Web приведет к появлению и популярности специализированных RDF-хранилищ, которые будут совместимы с приложениями, созданными для традиционных СУБД. n

Дмитрий Левшин (levshin@nicevt.ru) – сотрудник ОАО НИЦЭВТ, аспирант МГУ им. М.В. Ломоносова (Москва).