Требование близости интерфейса доступа к терминологии предметной области

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

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

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

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

Здесь необходимо отметить, что представленные на рынке системы интеграции данных [DB2UD, DVDP] используют реляционную схему в качестве интерфейса доступа. Но эти системы ориентированы на решение несколько отличных задач: во-первых, они не предназначены для глобальной интеграции с неограниченным масштабированием, и, во-вторых, они ориентированы на специалистов в ИТ. В нашем случае, в условиях глобальной системы интеграции, использование реляционной схемы в качестве интерфейса доступа, как уже отмечалось выше, не рационально - необходим подход, позволяющий использовать понятия предметных областей для доступа к данным.

Тогда на каких принципах должен быть основан интерфейс доступа, чтобы можно было работать с данными посредством понятий предметной области? Прежде всего, в основе интерфейса доступа должна стоять модель данных (информации), формализующая предметную область через ее понятия. Для этого может быть использовано одно из двух основных решений - применить одну из моделей онтологий (RDFS [RDFS], OWL [OWL], и т.п.), как предлагается, например, в работах [WVV01, JAP06], или семантически полную модель SCM [Ov04, Ov06-2, Ov06-3].

Мы выбрали вариант SCM и вот почему. Прежде всего, языки запросов к онтологиям (SPARQL [SPARQL], RDQL [RDQL], и др.) обладают существенно меньшей наглядностью, чем SCQL [Ov04, Ov05, Ov06-1] - язык запросов к SCM, что важно в условиях, когда с данными работают специалисты различных предметных областей, не только ИТ. Например, запрос "получить все задачи, решаемые компанией Fusionsoft, в которых задействованы люди старше 50 лет" формулируется с помощью SCQL как:
SELECT Task, Person FROM
(Company~Project~Task~Person~Age), (Company = "Fusionsoft"), (Age>50)
Если сравнить этот запрос с его аналогами в SPARQL или RDQL, то используемые там конструкции будут гораздо более многоэтажными, даже в случае простых запросов, типа "получить для каждого человека все задачи, над которыми он работает", что в SCQL выглядит просто как "(Person~Task)".

Конечно, вы можете задать вопрос, почему бы тогда не использовать язык SCQL поверх онтологий, ведь для онтологий есть масса открытых стандартов, тогда как для SCM - нет? Дело в том, что SCQL эксплуатирует уникальное свойство семантической полноты SCM, которым онтологии не обладают, а поэтому SCQL не может быть построен поверх онтологий в принципе. Это свойство формулируется следующим образом: связь между одной и той же группой понятий может описываться с помощью только одной ассоциации. Или другими словами - не может существовать альтернативных ассоциаций, построенных на одних и тех же понятиях, либо на множествах понятий, включенных одно в другое. Данное свойство не приводит к ограничению выразительных способностей модели, как может показаться с первого взгляда [Ov04, Ov05, Ov06-1].

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

Более того, отсутствие альтернативных ассоциаций также приводит к тому, что ассоциации больше не нуждаются в собственных именах - достаточно перечислить понятия, на которых построена ассоциация, чтобы сослаться на нее (именно этот факт позволил создать язык запросов для SCM с уникальными свойствами - SCQL). А раз ассоциациям не нужны имена, то их не надо запоминать. В условиях глобальной системы интеграции эта особенность становится очень важной, так как количество имен, которые надо было бы запомнить в обратном случае, было бы безгранично.

Таким образом, специалисту, работающему с данными через интерфейс доступа в виде SCM, достаточно знать понятия, существующие в интересующей его предметной области, и факты наличия ассоциаций (связей) между ними - без их имен. Этой информации достаточно не только для понимания структуры информации, но и для формулирования сложных запросов к ней. Такой подход кардинально отличается от других: реляционного - где надо запоминать названия таблиц и колонок, возможно аббревиатурные; онтологий - где надо владеть названиями всех слотов, и др.