Берите RDF для разработки или интеграции информационных систем

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

«RDF — это слишком сложно». Мы часто это слышим. Мы слышим это от очень умных людей. Буквально на днях мы услышали, как кто-то сказал, что они дважды пробовали RDF в предыдущих компаниях, и оба раза это не удалось. 

RDF означает Resource Description Framework,  который является открытым стандартом W3C, лежащим в основе многих графовых баз данных. 

Трудно убедить такого человека, что ему следует попробовать еще раз. Мы слышим одно и то же от любого из трех лагерей: реляционного лагеря, лагеря JSON и лагеря LPG (Labeled Property Graph). У каждого есть разные причины полагать, что этот материал RDF слишком сложен. Убедить тех, кто столкнулся с неудачами, дать RDF еще один шанс, также непросто. 

В этой статье я рассмотрю нюансы RDF, проливая свет на проблемы и сильные стороны в контексте корпоративной интеграции и разработки приложений.

Мир реляционных таблиц

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

JSON немного интереснее

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

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

Являются ли ключи статическими (то есть могут ли они быть известны конкретно во время кодирования) или они извлекаются динамически из самих данных? Честно говоря, это может оказаться сложным, но, по крайней мере, это только локально. 

Большая часть программирования JSON заключается в превращении чужой структуры в структуру, отвечающую поставленной задаче.

LPG — это JSON поверх графовой базы данных

Один из способов представить LPG — это JSON поверх графовой базы данных. Он обладает большой гибкостью JSON в сочетании с гибкостью обхода графов и аналитики графов. Он решает проблемы, которые трудно решить с помощью реляционного кода или просто JSON, и имеет прекрасную графику «из коробки». 

Каждый из этих подходов позволяет решить широкий круг задач. 

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

Интеграция предприятия — это сложно

Основной вопрос на самом деле не «RDF против LPG (или JSON или реляционные таблицы)», а «разработка приложений против корпоративной интеграции».

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

Янс Осман, генеральный директор Franz, создатель AllegroGraph

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

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

Снижение сложности

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

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

Комбинация всех этих моделей находится далеко за пределами понимания отдельных людей.

Приложения планирования ресурсов предприятия (ERP) и проекты моделирования данных предприятия пролили свет на то, насколько сложной может быть попытка смоделировать все данные предприятия. 

ERP-системы теперь имеют десятки тысяч таблиц и сотни тысяч столбцов. Моделирование корпоративных данных попало в ту же ловушку. 

Большинство усилий было направлено на описание объединения всех используемых моделей приложений. Сложность делала их непригодными для использования.

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

И его можно сопоставить с существующими сложными схемами без потерь. Возможность постулировать эти простые модели обеспечивается RDF (и его старшими братьями OWL и SHACL). 

RDF не гарантирует, что вы создадите простую и понятную модель (существует множество контр-примеров), но, по крайней мере, делает проблему разрешимой.

Обмен концепциями

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

Нам нужен способ узнать, что слова «сотрудник», «работник», «пользователь» и «оператор» относятся к одному и тому же понятию. А если нет, то каким образом они пересекаются.

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

Одним из механизмов, который помогает в этом, является идея о том, что концепции имеют глобальные идентификаторы (URI/IRI), которые можно разрешить. Вам не нужно знать, какое приложение определило концепцию, имя домена (и, следовательно, авторитет источника) находится прямо в идентификаторе и может использоваться во многом как URL-адрес, чтобы раскрыть все, что известно об этой концепции. Это важная особенность корпоративной интеграции.

Интеграция на уровне экземпляра

Дело не только в концепциях. Все экземпляры, упомянутые в прикладных системах, имеют идентификаторы. Но зачастую идентификаторы локальные. То есть «007» относится к Джеймсу Бонду в таблице секретных агентов, но относится к «Сэндвичу с ветчиной» в системе кафетерия компании.

Тот факт, что системы десятилетиями создавали псевдонимы идентификации, является еще одной проблемой, которую необходимо решать на уровне предприятия. Решение состоит не в том, чтобы пытаться, как многие делали в прошлом, внедрить «универсальный идентификатор» в тысячи затронутых систем. Это слишком большая работа, и они все равно не справятся с ней. Кроме того, существует множество проблем с идентификацией, которые были непредсказуемы во время создания систем (кто мог подумать, что некоторые из наших поставщиков также станут клиентами?) и которые еще труднее решить.

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

Хранилище данных, озеро данных и каталог данных — все в одном

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

Хранилища данных (Data Warehouse DW)

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

Но хранилище данных не оптимально по многим направлениям:

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

Озеро данных (Data Lake)

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

Модель RDF позволяет нам сочетать лучшее из всех трех подходов. 

Мы можем согласовать некоторые корпоративные данные (обычно мы рекомендуем все данные объекта, такие как MDM и тому подобное, а также некоторые ключевые данные транзакций). 

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

В конечном итоге это становится отличным решением для таких вещей, как Интернет вещей, где существуют большие объемы данных, доступ к которым требуется только в порядке исключения.

Федерация (объединение) запросов

Мы намекнули на объединение запросов в предыдущем абзаце. Тот факт, что федерация запросов встроена в спецификацию (SPARQL, который является языком запросов для RDF, а также выступает в качестве протокола для федерации), позволяет объединять данные во время запроса из разных экземпляров базы данных, разных поставщиков и даже различные типы баз данных (с отображением в реальном времени реляционные и документные базы данных могут быть объединены в запросы SPARQL).

Где RDF может оказаться излишним

Возможность помочь корпоративной интеграции обходится дорого. Убедиться, что у вас есть действительные, разрешимые идентификаторы, — это большая работа. Гармонизация вашей модели данных с чужой — это тоже большой труд. 

Мышление преимущественно в виде графов — это смена парадигмы. 

Предвидение и учет гибкости схемного моделирования добавляет много накладных расходов. 

Разбираться со странностями рассуждений об открытом мире — это серьезное испытание для мозга.

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

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

Половина всей работы в большинстве ИТ-отделов — это объединение данных, которые были реализованы людьми, которые считали, что решают отдельную проблему.

Заключение

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

И да, теоретически можно было бы перенести решения каждой из вышеперечисленных проблем (и многих других, включая происхождение и детализированную авторизацию) на реляционный формат JSON или LPG. Но это большая работа, и она будет просто переделывать те самые функции, которые разработчики в этих лагерях считают такими трудными.

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

Источник

Курирование и адаптация: Онтограф