Когда я присоединился к индустрии 10 лет назад, в моем первом проекте использовалась реляционная база данных. После этого в моем следующем проекте также использовалась реляционная база данных. И, как вы можете догадаться, в следующих моих следующих проектах также использовалась реляционная база данных. Это продолжалось так долго, что я почти забыл, что таблица — это всего лишь один формат для хранения данных.
Я заинтересовался другими видами баз данных только 4 года назад, когда моя компания постепенно перешла на анализ BigData и управление знаниями. За эти годы знакомство с RDF и Ontology побудило меня вновь посетить и переосмыслить подход и принцип построения базы данных.
В рамках этой статьи я сосредоточусь исключительно на роли схемы базы данных. Пожалуйста, не беспокойтесь, даже если вам незнакомы термины RDF и Ontology, я постараюсь представить эти понятия в этой статье.
Фон
График как база знаний
Как всем известно, создание реляционной базы данных начинается с определения схемы базы данных. Неважно, какую базу данных мы выберем, нам все равно нужно определить таблицы, столбцы и любой внешний ключ перед вставкой данных. Очевидно, нам нужно решить, как будут выглядеть данные, прежде чем их делать.
Тем не менее, этот подход не подходит для нас при создании базы знаний. Поскольку система предполагает хранить будущие знания, а не текущие знания, невозможно понять, как будут выглядеть данные. Поэтому мы переключили наше внимание на реляционную базу данных и искали другие решения.
Существует множество баз данных NoSQL, которые могут поддерживать данные без схемы, но большинство из них не соответствуют нашим требованиям, поскольку мы хотим хранить связанные данные. Следовательно, графическая база данных кажется самым сенсационным выбором для нас.
Структура описания ресурса
Круг покупок на рынке вызывает у нас чувство беспокойства, так как нет общепринятого стандарта языка запросов. Если мы выберем графическую базу данных, мы можем в конечном итоге написать реализацию, специфичную для поставщика, что не кажется хорошей стратегией для начала.
В попытке найти некоторые общие стандарты нам удалось найти Resource Description Framework, спецификацию W3C для моделирования информации в веб-ресурсах. Кажется, это лучший выбор для нас, потому что Resource Description Framework поставляется с очень простым механизмом для описания привязки ресурсов. Единственный побочный эффект, что каждый ресурс должен быть идентифицирован по URI.
Например, чтобы описать, что Apple производит iPhone 5, который продается за 600 долларов США, нам нужно сгенерировать 2 тройки, как показано ниже.
|
1
2
|
<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, запрос должен быть:
|
1
2
3
4
|
select ?phone ?price where { ?phone <http://example.org/price> ?price} |
Тем не менее, RDF это просто концепция. Чтобы использовать RDF и SPARQL, нам все еще нужно найти достойный API или реализацию, желательно на Java. Это привело нас к двум популярным вариантам: Сезам и Апач Йена. Оба API широко распространены и имеют несколько реализаций поставщиков. Более того, некоторые поставщики предоставляют реализации для них обоих.
онтология
В приведенном выше примере легко увидеть, что для создания значимого запроса нам необходимо знать, как выглядят данные. Таким образом, мы все равно должны иметь некоторые виды схем данных. Однако эта схема должна действовать скорее как метаданные, а не как определение данных. Как правило, нам не нужно предварительно определять схему перед вставкой данных.
Для решения этой проблемы есть две стратегии. Люди начали с определения общего словаря для RDF. Поскольку в большинстве случаев мы уже знаем отношения между ресурсами, но не знаем самих ресурсов, словарь должен быть достаточно хорошим, чтобы помочь в формировании запроса SPARQL. Тем не менее, из-за широкого спектра описания мира, словарного запаса недостаточно для полного выражения каждой области. Таким образом, существует множество предметных словарей.
В то время как первый подход касается только описания возможных взаимосвязей между ресурсами, второй подход также пытается описать ресурсы. Например, чтобы описать ресурсы в предыдущем примере, мы можем определить класс с именем смартфон и класс с именем производитель. После этого мы можем указать, что производитель может производить телефон.
|
1
2
3
|
<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> |
Эти тройки выше образуют онтологию. По сравнению с лексикой, мы нашли онтологию более описательным способом описания схемы данных, потому что она может сказать нам, какой тип отношений применим к какому-либо виду ресурса. Поэтому мы не будем тратить время на выяснение того, производит ли iPhone 5 Apple или Apple 5.
Онтология плюс RDF — хороший выбор для создания базы знаний. Хотя хранилище может быть хранилищем RDF, которое может принимать любую тройку, мы можем построить другую онтологию в отдельном пространстве для моделирования знаний в основном хранилище.
С нашей точки зрения, для формирования запроса лучше использовать онтологию, а не проверку данных, поскольку это поможет слегка отделить данные и схему. На практике вполне допустимо вставлять данные, которые не соответствуют онтологии, если они не противоречат.
Например, с онтологией, определенной ранее, мы должны разрешить вставку таких знаний, как
|
1
2
|
<http://example.org/Apple> <http://example.org/produce> <http://example.org/iPod><http://example.org/Apple> <http://example.org/produce> <http://example.org/iPad> |
но мы можем отказаться от любых знаний, таких как:
|
1
|
<http://example.org/iPhone5> <http://example.org/produce> <http://example.org/Apple> |
При таком подходе мы можем сначала разрешить импорт данных, а затем моделировать их.
Схема базы данных
Освежающая мысль
Отношение нашего подхода к созданию базы данных знаний с реляционной базой данных заставляет меня чувствовать, что требование определения схемы данных перед вставкой данных обусловлено реализацией. Если мы можем временно забыть о практических проблемах, таких как индексация данных, можно сначала вставить данные, а затем определить схему данных.
Это также навело меня на мысль о том, возможно ли иметь более одной схемы данных для одного и того же фрагмента данных. Поначалу идея может показаться неловкой, но вполне реалистичной, если мы посмотрим на сложнейшую задачу моделирования мира. Например, если мы считаем Обаму президентом США, мы можем заботиться о том, когда он начал служить, когда он покинет свой пост; но если мы думаем об Обаме как о любом другом гражданине США, то мы больше заботимся о дате рождения, жилом районе, номере безопасности … Таким образом, схема служит для нас перспективой для проверки и изменения ресурса.
Итак, если я могу вернуться к тому времени, когда люди обсуждают общий язык запросов для базы данных, я бы предложил добавить некоторые функции в SQL для его обогащения или ввести новый тип языка запросов, который менее строг:
- Разрешить вставку без определения таблицы. Автоматически создавать определение таблицы в соответствии с параметрами команды вставки.
- Сделайте идентификатор записи уникальным для каждой базы данных, а не уникальным для каждой таблицы. Запись может появляться во многих таблицах с одинаковым идентификатором. Команде вставки необходимо указать, какое поле является идентификатором записи.
- Определение данных является более общим без ограничения размера (varchar и int вместо varchar (255) или int (11)).
- Команда выбора должна соответствовать определению таблицы.
- Можно разделить поле между двумя таблицами для одной и той же записи.
Прежде чем закончить эту статью, давайте попробуем выполнить быстрое упражнение по созданию базы данных, которая может реализовать эти расширенные функции. Базовая система хранения может быть любым механизмом без схемы, но мы можем использовать RDF-хранилище для простоты.
Требования
- Вставьте Обаму в таблицу граждан США с именем, возрастом и полом. Поле идентификатора — имя.
- Вставьте Обаму в таблицу президента США с именем, возрастом и годом выборов. Поле идентификатора — имя.
- Определите таблицу граждан США с именем поля и возрастом.
- Определите таблицу президента США с именем, возрастом и выбранным годом.
- Выбор записи из таблицы граждан США будет отображать только имя и возраст, поскольку пол не определен в определении таблицы.
- Обновление записи Обамы в таблице президента США с новым возрастом повлияет на возраст в таблице граждан США, потому что это поле для общего доступа.
Реализации
Шаг 1
- SQL: вставить в значение гражданина (имя, пол, возраст) («Барак Обама», «Мужской», 53)
- троек:
- <Барак Обама> <тип> <гражданин>
- <Барак Обама> <имя> «Барак Обама»
- <Барак Обама> <пол> «мужчина»
- <Барак Обама> <возраст> 53
Шаг 2
- SQL: вставить в значение президент (name, selected_year) («Барак Обама», «Мужской», 53)
- троек:
- <Барак Обама> <тип> <президент>
- <Барак Обама> <selected_year> 2009
Шаг 3
- SQL: создать таблицу Citizen (‘name’ varchar, ‘age’ int, первичный ключ (‘name’))
- троек:
- <гражданин> <поле> <имя>
- <гражданин> <поле> <возраст>
- <гражданин> <primary_key> <имя>
Шаг 4
- SQL: создать таблицу президента (‘name’ varchar, ‘selected_year’ int, первичный ключ (‘name’))
- троек:
- <президент> <поле> <имя>
- <президент> <поле> <избранный_год>
- <президент> <первичный_ключ> <имя>
Шаг 5
- SQL: выберите * из гражданина
- SPARQL: выберите? Запись? Имя_поля? Поле_значения где {
- ? запись <тип> <гражданин>
- <гражданин> <поле>? field_name
- ? record? field_name? field_value
- }
Шаг 6
- SQL: обновленный президент установил возраст = 54, где имя = ‘Барак Обама’
- Перезаписать <Барак Обама> <возраст> 53 с <Барак Обама> <возраст> 54
Выводы
Я думаю, что некоторые из представленных выше идей немного трудно усвоить, если аудитория не знакома с RDF или Ontology. Тем не менее, я надеюсь, что это может вызвать еще больше мыслей о преодолении разрыва между реляционной базой данных и базой знаний.
| Ссылка: | Переосмысление схемы базы данных с помощью RDF и Ontology от нашего партнера по JCG Тони Нгуена из блога Developer Corner . |