Статьи

Переосмысление схем баз данных с помощью RDF и онтологий

Сентябрь 15, 2017

Когда я присоединился к индустрии 10 лет назад, в моем первом проекте использовалась реляционная база данных. После этого в моем следующем проекте также использовалась реляционная база данных. И, как вы можете догадаться, в следующих моих следующих проектах также использовались реляционные базы данных. Это продолжалось так долго, что я почти забыл, что таблица — это всего лишь один формат для хранения данных.

Я заинтересовался другими видами баз данных только четыре года назад, когда моя компания постепенно перешла на анализ больших данных и управление знаниями. За эти годы знакомство с RDF и Ontology побудило меня пересмотреть и переосмыслить подход и принцип построения базы данных.

В рамках этой статьи я сосредоточусь исключительно на роли схемы базы данных. Пожалуйста, не беспокойтесь, если термины RDF и Ontology покажутся вам незнакомыми. Я сделаю все возможное, чтобы представить эти концепции в этой статье.

Фон

График как база знаний

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

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

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

Структура описания ресурса

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

В попытке найти некоторые общие стандарты нам удалось найти Resource Description Framework, спецификацию W3C для моделирования информации в веб-ресурсах. Кажется, это лучший выбор для нас, потому что Resource Description Framework поставляется с очень простым механизмом для описания привязки ресурсов. Единственный побочный эффект, что каждый ресурс должен быть идентифицирован по URI.

Например, чтобы описать, что Apple производит iPhone 5, который продается за 600 долларов, нам нужно сгенерировать две тройки, как показано ниже:

<http://example.org/Apple> <http://example.org/produce> <http://example.org/iPhone5>

<http://example.org/iPhone5> <http://example.org/price> '600 USD'@en

Мы не заинтересованы в использовании URI в качестве идентификатора ресурса, но все еще должны сделать это, чтобы соответствовать стандарту. Однако мы не можем винить RDF, потому что он был изобретен для Интернета. У автора есть прекрасная мечта, где мы можем следовать по URI ресурса, чтобы получить его. Очевидно, эта идея не осуществилась.

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

select ?phone ?price where {

       <http://example.org/Apple> <http://example.org/produce> ?phone .

       ?phone <http://example.org/price> ?price

}

Тем не менее, RDF это просто концепция. Чтобы использовать RDF и SPARQL, нам все еще нужно найти достойный API или реализацию, желательно на Java. Это привело нас к двум популярным вариантам: Сезам и Апач Йена. Оба API широко распространены и имеют несколько реализаций поставщиков. Более того, некоторые поставщики предоставляют реализации для них обоих.

онтология

В приведенном выше примере легко увидеть, что для создания значимого запроса нам необходимо знать, как выглядят данные. Таким образом, мы все равно должны иметь некоторые виды схем данных. Однако эта схема должна действовать скорее как метаданные, а не как определение данных. Как правило, нам не нужно предварительно определять схему перед вставкой данных.

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

While the first approach only tackles describing possible relationship among resources, the second approach attempts to describe resources as well. For example, to describe the resources in the previous example, we can define a class named smart phone and a class named manufacturer. After this, we can specify that a manufacturer can produce a phone.

<http://example.org/Apple> <http://example.org/type> <http://example.org/Manufacturer>

<http://example.org/iPhone5> <http://example.org/type> <http://example.org/Phone>

<http://example.org/Manufacturer> <http://example.org/produce> <http://example.org/Phone>

Those triples above form an Ontology. Compared with vocabulary, we found Ontology has a more descriptive way of describing data schema because it can tell us which kind of relationship is applicable to which kind of resource. Therefore, we will not waste time figuring out whether iPhone 5 produces Apple or Apple produces iPhone 5.

Ontology plus RDF is a good choice to build knowledge database. While the repository can be an RDF store which can take in any triple, we can build another ontology in a separate space to model the knowledge in main repository.

From our point of view, it is better to use ontology to form query rather than data validation because it will help to slightly decouple data and schema. In practice, it is perfectly acceptable to insert data that does not fit Ontology, as long as they does not contradict.

For example, with the Ontology defined earlier, we should allow inserting knowledge like

<http://example.org/Apple> <http://example.org/produce> <http://example.org/iPod>

<http://example.org/Apple> <http://example.org/produce> <http://example.org/iPad>

but we can reject any knowledge like

<http://example.org/iPhone5> <http://example.org/produce> <http://example.org/Apple>

With this approach, we can allow importing data first, then modelling them later.

Database Schema

A Refreshing Thought

Relating our approach on buildinga  knowledge database with a relational database made me feel that the requirement of defining data schema before data insertion is driven by implementation. If we can temporarily forget practical concerns like data indexing, it is possible to insert data first and define data schema later.

This also brought me another thought of whether it is feasible to have more than one data schema for the same piece of data. The idea may sound awkward at first but quite realistic if we look at the daunting task of modelling the world. For example, if we think of Obama as the US president, we may care about the time when he started serving abd when will he leave office. But if we think of Obama as any other US citizen, then we care more about date of birth, residential area, security number,… In this way, the schema is serving as a perspective for us to inspect and modify resource.

So, if I can travel back to the time people discussing a common query language for database, I would suggest adding some features to SQL to enrich it, or to introduce a new kind of query language that is less strict:

  • Allow insertion without table definition. Automatically create table definition following insertion command parameters.
  • Make the id of record unique per database rather than unique per table. A record can appear in many tables with the same id. An insertion command need to specify which field is the id for the record.
  • The data definition is more generic without size constrain (varchar and int instead of varchar(255) or int(11)).
  • The select command must comply to the table definition. 
  • It is possible to share a field between two tables for the same record.

Before wrapping up this article, let try to do an quick exercise of building an database that can implements these extended features. The underlying storing system can be any schema-less engine but we can use RDF store for simplicity.

Requirements

  • Insert Obama into US citizen table with name and age and gender. The identifier field is name.
  • Insert Obama into US president table with name, age and elected year. The identifier field is name.
  • Define US citizen table with field name and age.
  • Define US president table with name, age and elected year.
  • Select record from US citizen table will only show name and age as gender is not defined in table definition.
  • Update Obama record in US President table with new age will affect the age in US citizen table because it is a sharing field.

Implementations

Step 1

  • SQL: insert into citizen(name, gender, age) value (‘Barack Obama’, ‘Male’, 53)
  • Triples:
    • <Barack Obama> <type> <citizen>
    • <Barack Obama> <name> ‘Barrack Obama’
    • <Barack Obama> <gender> ‘Male’
    • <Barack Obama> <age> 53

Step 2

  • SQL: insert into president(name, elected_year) value (‘Barrack Obama’, ‘Male’, 53)
  • Triples:
    • <Barack Obama> <type> <president>
    • <Barack Obama> <elected_year> 2009

Step 3

  • SQL: create table citizen (‘name’ varchar, ‘age’ int, primary key (‘name’) )
  • Triples:
    • <citizen> <field> <name>
    • <citizen> <field> <age>
    • <citizen> <primary_key> <name>

Step 4

  • SQL: create table president (‘name’ varchar, ‘elected_year’ int, primary key (‘name’) )
  • Triples:
    • <president> <field> <name>
    • <president> <field> <elect_year>
    • <president> <primary_key> <name>

Step 5

  • SQL: select * from citizen
  • SPARQL: select ?record ?field_name ?field_value where {
    • ?record <type> <citizen>
    • <citizen> <field> ?field_name
    • ?record ?field_name ?field_value
  • }

 Step 6

  • SQL: update president set age=54 where name=’Barack Obama’
  • Overwrite <Barack Obama> <age> 53 with <Barack Obama> <age> 54

Conclusions

I think some of the ideas above a bit hard to digest if audiences are not familiar with RDF or Ontology. Still, I hope it can raise some more thoughts on bridging the gap between relational database and knowledge database.

32
Share: