=Paper=
{{Paper
|id=Vol-2022/paper33
|storemode=property
|title=
Спецификация и реализация разномодельных правил интеграции данных
(Specification and Implementation of Multimodel Data Integration Rules)
|pdfUrl=https://ceur-ws.org/Vol-2022/paper33.pdf
|volume=Vol-2022
|authors=Sergey Stupnikov
|dblpUrl=https://dblp.org/rec/conf/rcdl/Stupnikov17a
}}
==
Спецификация и реализация разномодельных правил интеграции данных
(Specification and Implementation of Multimodel Data Integration Rules)
==
https://ceur-ws.org/Vol-2022/paper33.pdf
Спецификация и реализация разномодельных правил
интеграции данных
© С. А. Ступников
Институт проблем информатики ФИЦ ИУ РАН,
Москва
sstupnikov@ipiran.ru
Аннотация. В работе рассматривается подход к спецификации правил интеграции данных с
использованием рекомендации W3C - логического диалекта RIF-BLD. Это позволяет использовать в
одном правиле сущности из разных коллекций, представленных в разных моделях данных.
Логическая семантика RIF-BLD также позволяет однозначным образом интерпретировать
спецификации рассматриваемых правил интеграции. Предложен подход к реализации правил RIF-
BLD в языке HIL: это позволяет компилировать правила интеграции в программы вычислительной
модели MapReduce и исполнять их в распределенных инфраструктурах, основанных на Hadoop.
Ключевые слова: интеграция данных, модели данных, логические правила, реализация
правил
Specification and Implementation of Multimodel Data
Integration Rules
© Sergey Stupnikov
Institute of Informatics Problems, Federal Research Center “Computer Science and Control” of
the Russian Academy of Sciences,
Moscow
sstupnikov@ipiran.ru
Abstract. The paper considers an approach for specification of data integration rules using RIF-BLD
logic dialect that is a recommendation of W3C. This allows us to reference entities defined in different
collections represented using different data models in the same rule. Logical semantics of RIF-BLD
provides also unambiguous interpretation of data integration rules. The paper proposes an approach for
implementation of RIF-BLD rules using HIL language. Thus data integration rules are compiled into
MapReduce programs and can be executed over Hadoop-based distributed infrastructures.
Keywords: data integration, data models, logic rules, rule implementation
Ввиду роста неоднородности источников
1 Введение данных, их количества и объемов данных,
актуальными остаются вопросы разработки методов
Хранилища данных в настоящее время являются спецификации и реализации интеграции данных в
одной из основных составляющих инфраструктур масштабируемых инфраструктурах распределенного
поддержки систем бизнес-аналитики. Данные хранения и обработки данных, подобных Apache
извлекаются из различных коллекций, Hadoop [1].
преобразуются к схеме хранилища, интегрируются и
Традиционные промышленные решения по
загружаются в хранилище. Над хранилищем
интеграции данных и разработке хранилищ
выстраивается слой приложений, осуществляющих
(например, IBM InfoSphere Information Server [2])
анализ данных (например, при помощи методов
предлагают визуальные средства проектирования
математической статистики, машинного обучения и
потоков работ интеграции данных, оперирующие,
др.) и выдающих результат пользователю в
преимущественно, понятиями и операциями
необходимой форме.
реляционной модели и порождающие программы
трансформации и интеграции данных на языке SQL.
Труды XIX Международной конференции Отдельно выделяются визуальные средства
«Аналитика и управление данными в областях с сопоставления схем исходных коллекций данных и
интенсивным использованием данных» схемы хранилища (целевой схемы), например,
(DAMDID/RCDL’2017), Москва, Россия, 10-13
октября 2017
197
InfoSphere FastTrack [2], позволяющие интеграции неоднородных коллекций данных по
автоматически порождать части потоков работ Арктической зоне в хранилище информации,
интеграции данных. Для обеспечения интеграции нацеленной на поддержку поисково-спасательных
данных, представленных в различных моделях операций. Были выбраны неоднородные коллекции
данных, такие средства предоставляют отдельные данных, подлежащие интеграции [16] и разработана
компоненты, позволяющие преобразовывать единая схема хранилища [20]. В данной статье в
исходные данные к реляционной модели (например, качестве примеров рассматриваются коллекции,
компонент преобразования XML в IBM InfoSphere представленные в реляционной модели, XML,
DataStage [3]). документной модели MongoDB, графовой модели
Параллельно промышленным решениям, Neo4j. Схема хранилища представлена в
проводятся исследования методов формальной реляционной модели. В дальнейшем предполагается
спецификации правил интеграции данных. использование результатов работы в различных
Классическим примером работы в данном проектах, предусматривающих интеграцию данных.
направлении является подход обмена данными [9]. Структура статьи выглядит следующим образом.
Подход позволяет описывать интеграцию данных В разделах 2-4 иллюстрируются подход к
реляционной модели с использованием логических спецификации правил интеграции данных,
правил, которым сообщается формальная семантика представленных в различных моделях (раздел 2 –
в логике предикатов первого порядка. XML и реляционная модель, раздел 3 – документная
В данной статье рассматривается подход к модель, раздел 4 – графовая модель) с
спецификации правил интеграции данных с использованием диалекта RIF-BLD и подход к
использованием рекомендации W3C - логического реализации правил в языке HIL. В разделе 5
диалекта RIF-BLD [6]. RIF-BLD является диалектом обобщаются применяемые принципы спецификации
каркаса логических диалектов RIF-FLD формата и реализации правил интеграции.
обмена правилами RIF [5], нацеленного на
унификацию синтаксиса и семантики языков 2 Спецификация и реализация правил
логических правил. RIF-BLD включает достаточно интеграции данных XML и реляционной
широкий спектр возможностей спецификации, в модели с разрешением конфликтов
частности, позиционные термы и термы с
именованными аргументами (обобщающие понятие В данном разделе рассматриваются два примера
терма в логике первого порядка), фреймовые термы правил интеграции данных, оперирующих
(выражающие утверждения о структуре объектов), сущностями XML и реляционной модели.
классификационные термы, термы равенства, В первом примере рассматривается правило
внешние термы (использующиеся для ссылок на преобразования данных из XML к реляционной
сущности, рассматриваемые как «черные ящики» в схеме хранилища (целевой схеме) с разрешением
пределах спецификации). Это позволяет структурных конфликтов, конфликтов имен и
использовать в одном правиле сущностей из разных значений.
коллекций, представленных в разных моделях Во втором примере рассматривается правило
данных. Рассматриваются правила, в голове преобразования данных из соединения двух
которых могут присутствовать лишь предикаты, коллекций, одна из которых представлена в XML,
соответствующие сущностям целевой схемы, а в другая – в реляционной модели.
теле – предикаты, соответствующие сущностям
исходных схем.
2.1 Интеграция данных о маршрутах объектов
Логическая семантика RIF-BLD позволяет
однозначным образом интерпретировать В левом столбце таблицы 1 приведен пример
спецификации рассматриваемых правил интеграции данных в формате XML о маршруте объекта,
и допускает их реализацию с использованием полученных из системы мониторинга, учета и
различных языков – от декларативных (например, классификации судов КИИС «МоРе» [18]. Маршрут
SQL) до императивных (например, Java). В данной (элемент ISSKOI_Track) состоит из маршрутных
работе рассматривается подход к реализации точек (ISSKOI_TrackPoint). В каждой точке заданы
логических правил RIF-BLD в языке высокого значения координат (pos), времени (Time) и высоты
уровня HIL [10][7], разработанного компанией IBM, (BarAltitude). Данные о других маршрутах имеют ту
и поставляемого в составе Hadoop-решения же структуру элементов и отличатся значениями
BigInsights 3.0 [11], а также как часть InfoSphere Big элементов и атрибутов.
Match for Hadoop [12]. Распределенное исполнение В правом столбце таблицы приведены элементы
программ на HIL в среде Hadoop достигается путем целевой схемы, соответствующие исходным
их компиляции в программы на Java, которые, в данным. Так, элемент ISSKOI_Track соответствует
свою очередь, исполняются с использованием отношению целевой схемы Track, вложенный
средств поддержки в Hadoop вычислительной элемент Id соответствует первичному ключу (PK)
модели MapReduce [14]. Track.trackId, вложенный элемент TrackName –
Подходы к спецификации и реализации правил атрибуту Track.name. Элемент ISSKOI_TrackPoint
интеграции иллюстрируются на примерах соответствует отношению целевой схемы
198
TrackPoint, атрибут элемента id соответствует Forall в правиле обозначает квантор
первичному ключу TrackPoint.pointId, вложенные всеобщности, знак «:-» обозначает импликацию –
элементы Time и BarAltitude – атрибутам логическое следование формулы-головы правила из
TrackPoint.time и TrackPoint.height соответственно, формулы-тела правила, операция AND обозначает
вложенный элемент pos – атрибутам конъюнкцию. Идентификаторы вида ?X обозначают
TrackPoint.logtitude и TrackPoint.latitude. переменные.
В правиле используется три вида предикатов. В
Таблица 1 Данные о маршруте объекта и голове правила используются предикаты с
соответствующие элементы целевой схемы именованными аргументами [6] Track и TrackPoint,
Пример данных в исходной модели Элементы соответствующие отношениям целевой схемы.
(XML) целевой В теле правила используются предикаты
схемы членства [6] (например, предикат
(реляционная ?Track#ISSKOI_Track, обращающийся в истину,
модель) когда переменная ?Track принимает значение
Track( произвольного элемента ISSKOI_Track) и
56473 PK trackId, фреймовые предикаты [6], отражающие структуру
copter-1 name)
XML-элементов исходных данных. Так, предикат
?pos] обращается в истину на таких
id="uuid-2b7ca14"> PK pointId, парах значений переменных ?Point и ?pos, что
FK path, элемент – значение переменной ?Point имеет
time,
33.8957 246.37 height, вложенный элемент pos и его значение есть ?pos.
latitude, Конъюнкция предикатов в теле правила полностью
longitude) задает структуру вложенных элементов и атрибутов
2016-12-12
T13:33:11
произвольного элемента ISSKOI_Track.
533.89 Связь значений атрибутов отношений в голове
правила и значений элементов и атрибутов в теле
108.1
2 правила задается при помощи переменных, таким
образом разрешаются конфликты имен и
структурные конфликты.
Конфликты значений могут быть разрешены при
помощи функций (например, get_latitude),
В рассмотренном примере, как и в других представляемых в RIF-FLD как внешние термы
примерах, приведенных ниже, приведена лишь (External). Их семантика в рамках RIF-FLD
часть элементов, составляющих исходные данные и напрямую не определяется и уточняется при
целевую схему. реализации (например, семантика функции
Очевидно, что при спецификации правила get_latitude состоит в том, чтобы вернуть первое
интеграции данных о маршрутах необходимо число, входящее в исходную строку).
разрешить конфликты имен (например, элемент Рассмотренное правило имеет естественную
BarAltitude и атрибут height имеют одинаковую логическую семантику: для всех наборов значений
семантику, но разные имена), структурные подкванторных переменных, обращающих в истину
конфликты и конфликты значений (элемент pos, все предикаты тела правила на исходной коллекции,
содержащий широту и долготу, соответствует двум отношения хранилища должны содержать кортежи,
отдельным атрибутам logtitude, latitude). соответствующие предикатам головы правила с тем
С использованием диалекта RIF-BLD же набором значений переменных. Для
необходимое правило интеграции описывается рассмотренного примера хранилище должно
следующим образом: содержать кортежи Track(trackId: 56473, name:
“copter-1”), TrackPoint(pointId: “uuid-2b7ca14”,
Forall ?Track ?Id ?TrackName ?TrackPoints path: 56473, time: “2016-12-12T13:33:11”, height:
?TrackPoint ?Position ?Time ?Height ?Point ?pos
( AND( Track(trackId->?Id name->?TrackName)
533.89, latitude: 33.8957, longitude: 246.37).
TrackPoint(pointId->?pid path->?Id Вышеописанное правило может быть
time->?Time height->?Height реализовано в языке HIL следующей программой:
latitude->External(get_latitude(?pos))
longitude->External(get_longitude(?pos)) )) declare ISSKOI_Track: ?;
:- declare Track: ?;
AND(?Track#ISSKOI_Track declare TrackPoint: ?;
?Track[Id->?Id TrackName->?TrackName
TrackPoints->?TrackPoint] declare get_latitude:
?TPoint#ISSKOI_TrackPoint function string to double;
?TPoint[id->?pid Position->?Position declare get_longitude:
Time->?Time BarAltitude->?Height] function string to double;
?Position#Position ?Position[Point->?Point]
?Point#Point ?Point[pos->?pos])) @jaql{
get_latitude = fn($s) convert(substring(
$s, 0, strPos($s, ' ')-1), schema double);
199
get_longitude = fn($s) convert(substring( найдены данные об одних и тех же судах (судно
$s, strPos($s, ' ')+1, strLen($s)),
schema double);
идентифицируется по названию и позывному).
} Кроме того, коллекции содержат различные
взаимодополняющие данные о судах.
insert into Track
select [ trackId: t."Id",name: t."TrackName"]
from ISSKOI_Track t; Таблица 2 Данные о судах и соответствующие
элементы целевой схемы
insert into TrackPoint
select [ path: t."Id", time: p."Time", Пример данных в исходных моделях Элементы
height: tpt."BarAltitude", (XML, реляционная) целевой
hSpeed: tpt."HSpeed", vSpeed: tpt."VSpeed", схемы
course: tpt."Course",
latitute: get_latitude(pt."pos"), (реляционная
longitude: get_longitude(pt."pos") ] модель)
from ISSKOI_Track t, t."TrackPoints" tpt, SARUnit(
tpt."Position" ps, ps."Point" pt; 64694571 beginDuty,
мвс Ростов Великий endDuty,
В программе объявляются (declare) исходная UBZG5 vehicle)
сущность (внешний элемент ISSKOI_Track) и
целевые сущности, соответствующие отношениям 2017-01-08 Vessel(
PK
(Track, TrackPoint). Знак «?» в объявлении означает, 2017-01-09 vehicleId,
что структура сущностей не задана при name,
определении, а выводится из программы. call,
country,
Объявляются функции разрешения конфликтов [{ FK owner,
(get_latitude, get_longitude) и их сигнатуры. "Platforma_nazvanie": imoNumber)
Реализация функций производится с "мвс Ростов Велкий",
"Strana_naimenovanie": LegalEntity(
использованием языка Jaql [4] (директива @jaql) и "Россия", PK
его функций работы со строками substring, strPos. "Organizaciya_nazvanie": entityId,
"ФГУП Балтийское БАСУ –
Для целевых отношений Track, TrackPoint Сахалинский филиал",
name)
определяются операторы insert, порождающие "Pozyvnoj": "UBZG5",
кортежи этих отношений. В секции from операторов "nomer_IMO": "9586796"
insert объявляются исходные сущности, каждому }]
предикату членства в теле правила RIF-BLD
(например, ?Track#ISSKOI_Track) соответствует В правом столбце таблицы приведены элементы
объявление с точностью до имени переменной целевой схемы, соответствующие исходным
(например, ISSKOI_Track t). данным. Данные, соответствующие судну, как
Атрибуты целевых отношений и выражения транспортному средству, сосредоточены в
порождения их значений определяются в секции отношении Vessel; как спасательной единице – в
select в соответствии с предикатами в голове отношении SARUnit; как юридической сущности - в
правила и фреймовыми предикатами в теле правила. отношении LegalEntity.
Например, предикату головы Track(trackId->?Id) и С использованием диалекта RIF-BLD
фреймовому предикату тела ?Track[Id->?Id] необходимое правило интеграции описывается
соответствует определение trackId: t."Id" в секции следующим образом:
select оператора insert into Track. Forall ?Id ?name ?call ?beginDuty ?endDuty
Заметим, что язык HIL оперирует данными в ?country ?ownerName ?imoNumber
( Exists ?owner (
формате JSON [13], поэтому для применения AND( SARUnit(beginDuty->?beginDuty
рассмотренного правила на языке HIL для endDuty->?endDuty vehicle->?Id )
преобразования данных о маршрутах в целевую Vessel(vehicleId->?Id
схему необходимо преобразовать исходные XML- name->External(normalize(?nazv))
call->?call Country->?country
документы в JSON при помощи встроенной owner->?owner imoNumber->?imoNumber) )
функции xmlToJson языка Jaql [4]. Полученные на LegalEntity(entityId->?owner
выходе HIL-программы JSON-документы затем name->?ownerName) ))
:-
загружаются в реляционное хранилище над Hadoop AND( ?ERRTableShips#ERRTableShips
(например, Hive [15]). ?ERRTableShips[Id->?Id Name->?name
Callsing->?call Dates->?Dates]
2.2 Интеграция данных о судах ?Dates#Dates
?Dates[StartDate->?beginDuty
В левом столбце таблицы 2 приведен пример EndDate->?endDuty]
Ship("Platforma_nazvanie"->?nazv
данных о судах в формате XML, полученный из "Pozyvnoj"->?call
системы «Поиск-Море» (ERRTableShips) [19]; а "Strana_naimenovanie"->?country
также пример данных о судах в реляционной "Organizaciya_nazvanie"->?ownerName
модели, полученный из системы ЕСИМО [17] "nomer_IMO"->?imoNumber)
External(compareShipName(?name, ?nazv)) ))
(данные получены в формате CSV и преобразованы
в JSON). В обеих исходных коллекциях могут быть
200
Аналогично примеру, описанному в предыдущем s."Platforma_nazvanie" and
подразделе, в голове правила конъюнкцией sl.Callsing_Name.Callsing = s."Pozyvnoj";
соединяются предикаты, соответствующие Соединение сущностей исходных коллекций
отношениям целевой схемы. Кроме того, производится с использованием оператора
конъюнкция в голове правила заключена под разрешения сущностей create link. В секции from
квантор существования (Exists) по переменной оператора указываются соединяемые коллекции
?owner 1, значение которой (не определенное в (ERRTableShips, Ship), в секции select – составные
исходных данных) является первичным ключом ключи (Callsing_Name,
entityId в кортеже отношения LegalEntity и внешним Pozyvnoj_Platforma_nazvanie), однозначно
ключом в кортеже отношения Vessel. идентифицирующие исходные сущности, правило
В теле правила конъюнкцией соединяется сопоставления сущностей rule1 (совпадение
предикат Ship, соответствующий отношению из позывных и соответствие имен с точностью до
системы ЕСИМО, предикаты членства и фреймовые функции compareShipName).
предикаты, соответствующие структуре XML- Как и в примере, описанном в предыдущем
документов из системы «Поиск-Море». подразделе, для каждого отношения целевой схемы
Отдельной особенностью правила является то, в программе определен оператор insert. Особенность
что при соединении сущностей из исходных данной программы состоит в том, что целевые
коллекций происходит проверка на соответствие отношения пополняются на основании только тех
имен судов с некоторой точностью (возможны сущностей, которые связаны оператором create link.
варианты записей и ошибки) при помощи функции Квантор всеобщности реализуется с
compareShipName. использованием функции get_id, порождающей
уникальный идентификатор, и, тем самым,
Вышеописанное правило может быть означивающей подкванторную переменную ?owner.
реализовано в языке HIL следующей программой Значение порожденного идентификатора
(объявления сущностей и функций опущены): присваивается первичному ключу
LegalEntity.entityId и внешнему ключу Vessel.owner.
create link ShipLink as
select [
Callsing_Name: 3 Спецификация и реализация правил
интеграции данных документной модели
[Callsing: es.Callsing, Name: es.Name],
"Pozyvnoj_Platforma_nazvanie":
["Pozyvnoj": s."Pozyvnoj",
"Platforma_nazvanie": s."Platforma_nazvanie"]] В данном разделе рассматривается пример
from ERRTableShips es, Ship s правила интеграции данных, оперирующего
match using сущностями документной модели. Исходная
rule1: es.Callsing = s."Pozyvnoj" and
compareShipName(es.Name,
коллекция содержит сообщения о происшествиях в
s."Platforma_nazvanie"); Арктической зоне из социальных сетей и сущности
(персоны, суда, географические локации и т.д.),
insert into SARUnit извлеченные средствами анализа текстов из
select [ vehicle: s.Id,
beginDuty: d.StartDate, сообщений [8]. Данные хранятся в документной
endDuty: d.EndDate СУБД MongoDB и экспортируются для дальнейшей
] интеграции в файлах в формате JSON.
from ShipLink sl, ERRTableShips s, s.Dates d
where sl.Callsing_Name.Name = s.Name and В левом столбце таблицы 3 приведен пример
sl.Callsing_Name.Callsing = s.Callsing; данных о сообщении (Messages) и данных о
сущностях, извлеченных из сообщения (Entites).
insert into Vessel
select [ vehicleId: s.Id,
Связь сообщений и сущностей, извлеченных из них,
name: normalize(s."Platforma_nazvanie"), устанавливается на основании значения составного
call: s."Pozyvnoj", ключа id. В правом столбце таблицы приведены
country: s."Strana_naimenovanie", элементы целевой схемы, соответствующие
owner: get_id(s."Organizaciya_nazvanie"),
imoNumber: s."nomer_IMO"] исходным данным.
from ShipLink sl, Ship s
where sl.Callsing_Name.Callsing = s."Pozyvnoj" Таблица 3 Данные о сообщениях и
and sl.Callsing_Name.Name = соответствующие элементы целевой схемы
s."Platforma_nazvanie";
Пример данных в исходной Элементы
insert into LegalEntity
select [ модели (документная) целевой схемы
entityId: get_id(s."Organizaciya_nazvanie"), (реляционная
name: s."Organizaciya_nazvanie"] модель)
from ShipLink sl, Ship s {"Messages": [{ Document(
where sl.Callsing_Name.Name = "id": {"coll_id": "8002", documentId,
"res_id": { collection,
"site_id": "9b290c9f3bda", source,
1
Строго говоря, квантор всеобщности в голове "doc_id": "3649a5559a62"}}, content,
правила выходит за границы диалекта RIF-BLD, "annotation": "Chinese time,
однако входит в каркас RIF-FLD. seismic vessel aimed for language,
201
Russian #Barents Sea oil at author) token: e."s_token",
logistics port #Kirkenes", tag: e."s_tag",
"metafields": { ExtractedEntity( begin: e."s_begin",
"mf203": "2016-4-30", entityId, end: e."s_end"]
"mf205": "eng", document, from Entities ext, ext."id" eid,
"mf200": "iceblogger"} token, eid."res_id" eres, ext.entities e;
}]} tag,
begin Для обоих отношений целевой схемы в
{"Entities": [{ end) программе определен оператор insert.
"id": {"coll_id": "8002",
"res_id": {
"site_id": "9b290c9f3bda", 4 Спецификация и реализация правил
"doc_id": "3649a5559a62"}},
"entities": [
интеграции данных графовой модели
{ "s_token": "Barents Sea", В данном разделе рассматривается пример
"s_tag": "I-ALOC",
"s_end": 53, правила интеграции данных, оперирующего
"s_begin": 42}, сущностями графовой модели. Исходная коллекция
{ "s_token": "Kirkenes", содержит данные о спасательных операциях, данные
"s_tag": "I-ALOC",
"s_end": 85,
хранятся в графовой СУБД Neo4j и экспортируются
"s_begin": 77} для дальнейшей интеграции в файлах в формате
]}] } JSON.
В левом столбце таблицы 4 приведен пример
С использованием диалекта RIF-BLD правило данных о спасательных операциях. Данные
интеграции данных о сообщениях описывается содержат три вида вершин (Nodes): спасательная
следующим образом: операция (SarOperation), координационный центр
Forall ?m ?ext ?doc ?coll ?src ?cont (CoordCenter), координатор операции (Coordinator);
?time ?lang ?auth ?mid ?mres ?mf ?eid ?eres и два вида ребер (Relationships): rCoordCenter
( Exists ?ent( AND(
(ребра, связывающие операцию и центр),
Document(documentId->?doc collection->?coll
source->?src content->?cont time->?time rCoordinator (ребра, связывающие операцию и ее
language->?lang author->?auth) координатора).
ExtractedEntity(entityId->?ent document->?doc
token->?tok tag->?tag begin->?beg
end->?end) )) Таблица 4 Данные о спасательных операциях и
:- соответствующие элементы целевой схемы
AND( ?m#Messages ?ext#Entities
?m[id->?mid annotation->?cont metafields->?mf] Пример данных в исходной Элементы
?mid[coll_id->?coll res_id->?mres] модели (графовая) целевой схемы
?mres[site_id->?src doc_id->?doc] (реляционная
?mf[mf203->?time mf205->?lang mf200->?auth]
?ext[id->?eid entities->?ents] модель)
?eid[coll_id->?coll res_id->?eres] {"Nodes": SAROperation(
?eres[site_id->?src doc_id->?doc] [{"id":"12", PK
?ext#?ents "labels":["SarOperation"], operationId,
?ext[s_token->?tok s_tag->?tag "properties":{ FK
s_begin->?beg s_end->?end] )) "OperationID":"5824", coordCenter,
"OperationDate": FK
Аналогично примерам, приведенным в "2016-09-15T00:00:00", coordinator,
предыдущем разделе, в голове правила "OperationName": country,
"Arctic Sunrise Sinking", creationTime,
конъюнкцией соединяются предикаты, "countrycode":"643"} }, name)
соответствующие отношениям целевой схемы. В {"id":"13",
теле правила при помощи предикатов членства и "labels":["CoordCenter"], CoordinationCen
фреймовых предикатов отражена структура "properties":{
"CoordCenterID":"mrcc667340",
ter(
PK centerId,
документов, соответствующих сообщениям и "Name":"MRCC Dikson"} name)
извлеченным сущностям. Правило может быть },
реализовано в языке HIL следующей программой: {"id":"14", Person(
"labels":["Coordinator"], PK personId,
"properties":{ name)
insert into Document "Name": "Schurov V. A.",
select [ documentId: mres."doc_id", "CoordinatorID": "5773"}
collection: mid."coll_id", }]}
source: mres."site_id",
content: m."annotation", { "Relationships":
time: mf."mf203", [{"id":"4",
language: mf."mf205", "type":"rCoordCenter",
author: mf."mf200"] "startNode":"12",
from Message m, m."id" mid, mid."res_id" mres, "endNode":"13"},
m."metafields" mf; {"id":"9",
"type":"rCoordinator",
insert into ExtractedEntity "startNode":"12",
select [ entityId: get_id(strcat( "endNode":"14"}] }
eres."site_id", eres."doc_id")),
document: eres."doc_id",
202
В правом столбце таблицы приведены элементы creationTime: prp."OperationDate",
целевой схемы, соответствующие исходным name: prp."OperationName",
country: prp."countrycode",
данным. coordCenter: prp1."CoordCenterID",
С использованием диалекта RIF-BLD интеграция coordinator: prp2."CoordinatorID"]
from Nodes n, n."properties" prp,
данных о спасательных операциях описывается n."labels" lbl,
совокупностью следующих правил: Relationships r1, Relationships r2,
Forall ?pid ?name ?lbl ?prp( Nodes n1, Nodes n2
Person(personId->?pid name->?name) :- where
AND( ?n#Nodes array_includes(lbl, "SarOperation") and
?n[labels->?lbl properties->?prp] n."id" = r1."startNode" and
"Coordinator"#?lbl r1."type" = "rCoordCenter" and
?prp[CoordinatorID->pid Name->?name])) n1."id" = r1."endNode" and
n."id" = r2."startNode" and
Forall ?cid ?name ?lbl ?prp( r2."type" = "rCoordinator" and
CoordinationCenter(centerId->?cid n2."id" = r2."endNode";
name->?name) :-
AND( ?n#Nodes Каждое из правил представляется отдельным
?n[labels->?lbl properties->?prp] оператором insert. Предикаты проверки типа
"CoordCenter"#?lbl вершины (например, "Coordinator"#?lbl)
?prp[CoordCenterID->cid Name->?name])) реализуются с использованием функции
Forall ( array_includes:
SAROperation(operationId->?opid @jaql{ array_includes = fn(a, e)
creationTime->?time name->?name if (not exists(a->filter $ == e)) false
country->?country coordCenter->?cntr else true; }
coordinator->?coord)
:-
AND( ?n#Nodes ?n[id->?id] 5 Общие принципы спецификации
?n[properties->?prp labels->?lbl]
?r1#Relatioships ?r2#Relatioships
правил интеграции данных с
?n1#Nodes ?n1[id->?id1] использованием RIF-BLD и их
?n2#Nodes ?n2[id->?id2]
"SarOperation"#lbl
реализации в языке HIL
?r1[type->"rCoordCenter" Основные принципы спецификации правил
startNode->?id endNode->?id1]
?r2[type->"rCoordinator" интеграции данных с использованием RIF-BLD,
startNode->?id endNode->?id2] примененные в данной работе, можно обобщить
)) следующим образом:
Каждому отношению целевой схемы • правила интеграции имеют вид импликации,
соответствует свой тип вершин, например, посылка которой называется телом, а
отношению SAROperation соответствуют вершины с заключение – головой;
меткой "SarOperation" (атрибут labels). Поэтому для • голова и тело правил представляют собой
каждого отношения удобно определить свое формулы, связывающие предикаты операциями
порождающее правило. Предикаты, конъюнкции или дизъюнкции;
соответствующие отношениям целевой схемы, • в теле правила допускаются предикаты,
составляют головы правил. В телах правил при соответствующие сущностям только исходных
помощи предикатов членства и фреймовых схем, в голове – только целевой схеме;
предикатов отражены структуры данных, • для описания свойств кортежей,
соответствующие вершинам и ребрам графа. принадлежащих отношениям реляционной
Правила могут быть реализованы в языке HIL модели, в правилах используются предикаты с
следующей программой: именованными аргументами [5];
insert into Person • для описания свойств структур данных
select [ произвольной степени вложенности (при
personId: prp."CoordinatorID", помощи которых представляются данные
name: prp."Name"]
from Nodes n, n."properties" prp, различных нереляционных моделей – XML,
n."labels" lbl документной, графовой и т.д.) используются
where фреймовые предикаты и предикаты членства
array_includes(lbl, "Coordinator");
[5];
insert into CoordinationCenter • связь значений атрибутов сущностей исходных
select [ и целевой схем осуществляется при помощи
centerId: prp."CoordCenterID", переменных;
name: prp."Name"]
from Nodes n, n."properties" prp • свободные переменные, использующиеся в теле
n."labels" lbl правила, связываются внешним квантором
where всеобщности;
array_includes(lbl, "CoordCenter");
• свободные переменные в голове правила, не
insert into SAROperation встречающиеся в теле (фактически, они
select [ соответствуют данным, не определенным явно в
operationId: prp."OperationID",
203
исходных коллекциях), связываются квантором целевых отношений.
существования;
• нетривиальные предикаты-условия (отличные 6 Заключение
от равенства) и функции разрешения
конфликтов определяются как внешние термы В работе рассматривается подход к
[5]. спецификации правил интеграции данных с
использованием рекомендации W3C - логического
диалекта RIF-BLD. Широкий спектр возможностей
Основные принципы реализации правил спецификации RIF-BLD позволяет использовать в
интеграции данных на RIF-BLD в языке HIL, одном правиле сущности из разных коллекций,
примененные в данной работе, можно обобщить представленных в разных моделях данных.
следующим образом: Рассматриваются правила, в голове которых могут
• сущности исходных и целевой схем, функции присутствовать лишь предикаты, соответствующие
разрешения конфликтов и нетривиальные сущностям целевой схемы, а в теле – предикаты,
предикаты-условия объявляются при помощи соответствующие сущностям исходных схем.
директивы declare; для функций определяется Логическая семантика RIF-BLD позволяет
их сигнатура; однозначным образом интерпретировать
• функции реализуются на языке Jaql в отдельных спецификации рассматриваемых правил интеграции
секциях программы, либо на языке Java во и допускает их реализацию с использованием
внешних файлах; различных языков. В данной работе
• для каждой сущности (отношения) в голове рассматривается подход к реализации логических
правила создается отдельный оператор insert, правил RIF-BLD в языке высокого уровня HIL,
порождающий кортежи этих отношений: разработанного компанией IBM. Путем компиляции
o в секции from объявляются исходные программ на HIL в программы вычислительной
сущности, каждому предикату с модели MapReduce достигается распределенное
именованными переменными или предикату исполнение правил интеграции в среде Hadoop.
членства в теле правила соответствует К дальнейшим направлениям работы можно
объявление с точностью до имени отнести вопросы интерпретации и реализации
переменной; логических программ на RIF-BLD, в телах правил
o в секции select указываются атрибуты которых допускаются предикаты целевой схемы.
целевых отношений (в соответствии с их Это требует адаптации, в частности, процедуры
названиями в предикатах головы правила) и погони [9]. Другим направлением является
выражения порождения их значений; реализация автоматического преобразования
выражения формируются в соответствии с спецификаций RIF-BLD в программы,
термами в предикатах головы правила либо с компилируемые и исполняемые на распределенных
термами во фреймовых предикатах тела вычислительных инфраструктурах (например, на
правила; языке HIL).
o в секции where указываются предикаты,
отражающие способы соединения исходных
Поддержка. Работа выполнена при поддержке
сущностей (формируемые на основании
Министерства образования и науки Российской
совпадения имен переменных во фреймовых
Федерации (уникальный идентификатор проекта
предикатах тела) и их отбора
RFMEFI60717X0176).
(соответствующие предикатам, налагающим
условия на данные отдельных исходных
коллекций в теле правила); Литература
• если соединение сущностей исходных [1] Apache Hadoop Project. 2016.
коллекций в теле правила осуществляется с http://hadoop.apache.org/
использованием нетривиальных предикатов и [2] Ballard, C., Alon, T., Dronavalli, N., Jennings, S.,
функций (отличных от равенства атрибутов), Lee, M., Toratani, S. IBM InfoSphere Information
предварительное соединение сущностей Server Deployment Architectures.
производится с использованием оператора ibm.com/redbooks (2012)
разрешения сущностей create link:
[3] Bar-Or, A., Choudhary, S. Transform XML using
o в секции from указываются соединяемые
the DataStage XML stage. IBM developerWorks
коллекции;
(2011)
o в секции select указываются составные
ключи, однозначно идентифицирующие [4] Beyer, K.S., Ercegovac, V., Gemulla, R., Balmin,
исходные сущности; A., Eltabakh, M., Kanne, C.-C., Ozcan, F.,
o в секции match указываются правила Shekita, E.J.: Jaql: A Scripting Language for Large
сопоставления сущностей; Scale Semistructured Data Analysis. In: 37th
o коллекция пар сопоставленных сущностей International conference on very large data bases
затем используется в качестве входной в VLDB, pp. 1272-1283. Curran Associates, New
операторах insert, порождающих кортежи York (2011)
204
[5] Boley, H., Kifer, M. (eds.): RIF Framework for [12] InfoSphere Big Match for Hadoop. Technical
Logic Dialects. W3C Recommendation, 2nd edn. Overview. - https://goo.gl/0TMqvw
(February 5, 2013) [13] Introducing JSON. - http://www.json.org/
[6] Boley, H., Kifer, M. (eds.): RIF Basic Logic [14] Miner, D. MapReduce Design Patterns: Building
Dialect. W3C Recommendation, 2nd edn. Effective Algorithms and Analytics for Hadoop
(February 5, 2013) and Other Systems. O'Reilly Media (2012)
[7] Burdick, D., Hernández, M. A., Ho, H., Koutrika, [15] The Apache Hive data warehouse software. -
G., Krishnamurthy, R., Popa, L., Stanoi, I.R., http://hive.apache.org/
Vaithyanathan, S., Das, S.: Extracting, Linking [16] Брюхов, Д. О., Скворцов, Н. А., Ступников, С.
and Integrating Data from Public Sources: A А. Методы интеграции
Financial Case Study. IEEE Data Eng. Bull., разноструктурированных данных по
34(3):60–67 (2011) Арктической зоне для извлечения информации,
[8] Devyatkin, D., Shelmanov, A. Text Processing нацеленной на поддержку поисково-
Framework for Emergency Event Detection in the спасательных операций. Системы высокой
Arctic Zone. In: Kalinichenko L., Kuznetsov S., доступности. Т. 13, № 2. М.: Радиотехника
Manolopoulos Y. (eds) Data Analytics and (2017) Принято к публикации.
Management in Data Intensive Domains. [17] Единая государственная система информации
DAMDID/RCDL 2016. Communications in об обстановке в мировом океане. -
Computer and Information Science, vol 706, pp. http://portal.esimo.ru/portal
74-88. Springer (2017)
[18] Комплексная интегрированная
[9] Fagin, R., Kolaitis, P., Miller, R., Popa, L.: Data информационная система «МоРе». -
exchange: semantics and query answering. http://www.marsat.ru/ciis-more
Theoretical Computer Science, 336(1):89–124
[19] Программный комплекс «Поиск-Море». -
(2005)
http://map.geopallada.ru/
[10] Hernandez, M., Koutrika, G., Krishnamurthy, R.,
[20] Скворцов, Н. А., Брюхов, Д. О. Разработка
Popa, L., Wisnesky, R.: HIL: A high-level
схемы хранилища информации для поддержки
scripting language for entity integration. In: 16th
поисковых действий в Арктической зоне.
Conference (International) on Extending Database
Системы высокой доступности. Т. 13, № 2. М.:
Technology Proceedings EDBT 2013, pp. 549–560
Радиотехника (2017). Принято к публикации.
(2013)
[11] IBM InfoSphere BigInsights Version 3.0
Information Center. https://goo.gl/lZpEQd
205