делях, например, в графовой модели. Использование в рамках одной ин формационной системы нескольких СУБД, реализующих разные модели данных, приводит к существенному усложнению управления системой. Од ним из возможных решений данной проблемы является использование мультимодельной СУБД. Формальной основой для разработки такой СУБД является взаимное отображение между применяемыми моделями данных. Данная работа посвящена взаимному отображению между схемами графо вой и реляционной моделей данных, а также между языками запросов SQL и Cypher. В настоящее время существует множество подходов к отображе нию графовой модели в реляционную модель и наоборот. Все эти подходы в полной мере реализуют отображение в одну сторону или взаимное отоб ражение с использованием промежуточного представления. Рассмотрены и продемонстрированы на конкретных примерах идеи отображения схем и языков запросов. Проведено сравнение существующих мультимодельных баз данных, реализующих графовую и реляционную модели.

Ключевые слова: интеграция моделей данных, графовая модель данных, реляционная модель данных.

Современные информационные системы одновременно используют данные раз личной структуры. Для их представления уже недостаточно реляционной модели данных. Также, концептуальные схемы многих предметных областей значи тельно удобнее представлять в NoSQL моделях, например, в графовой модели. Использование в рамках одной информационной системы нескольких СУБД, ре ализующих разные модели данных, приводит к существенному усложнению управления системой. Одним из возможных решений данной проблемы является использование мультимодельной СУБД [6]. Формальной основой для разработки такой СУБД является взаимное отображение между применяемыми моделями данных.

Эта работа посвящена теме интеграции реляционной и графовой моделей. Ре ляционная модель является самой популярной в мире и занимает 60% рынка на 2019 год1 • Графовая модель естественна для представления некоторых предмет ных областей, например, социальных сетей. Также, из-за отсутствия схемы, воз можно хранить данные разнородных объектов в одном месте.

В настоящее время развиваются мультимодельные СУБД, поддерживающие графовую и реляционную модели такие как Agens Graph, CosmosDB, OrientDB, MarkLogic.

Несмотря на наличие данных СУБД, вопрос интеграции реляционной и графо вой моделей не решен полностью. Одной из проблем является разнообразие язы ков манипулирования графовыми данными: Cypher, SP ARQL, Gremlin, PGQL. Также ведутся работы по разработке единого стандарта языка запросов Graph Query Language (GQL). Стандарт GQL [17] бьm одобрен в сентябре 2019 года, на него повлияли работы [2] [5]. Запросы в GQL описываются в декларативной форме подобно SQL.

Для интеграции интересующих моделей MaгkLogic и OrientDB отображают данные в промежуточное представление. Agens Graph не предоставляют отобра жение моделей друг в друга, а просто хранит данные графовой и реляционной моделей в раздельных хранилищах и для одновременного обращения к этим хра нилищам необходимо производить гибридные запросы.

На данный момент существует множество подходов к отображению графовой модели в реляционную модель и наоборот. Все эти подходы в полной мере реа лизуют отображение только в одну сторону или взаимное отображение с исполь зованием промежуточного представления. Например, в работе [14] предложен алгоритм трансформации реляционных данных в графовое представление. В ста тье [10] описывается взаимное отображение языков запросов SQL, Cypher в язык запросов, основанный на лямбда-исчислении.

Таким образом, по сведениям автора, в настоящее отсутствуют полноценные подходы к взаимному отображению реляционной и графовой моделей без ис пользования промежуточного представления. Данная работа направлена на объ единение существующих решений и предоставления подхода по взаимному отоб ражению языков запросов и подхода по отображению схем данных реляционной и графовой моделей. В течение последних лет было множество работ по поводу миграции данных с реляционных баз данных в графовые базы данных [7][9] [13]. Данная ситуация обусловлена получением возможностей, которые предоставляются графовыми СУБД, такими, как масштабируемость и явное представление желаемых структур данных в определенных предметных областях. В работе [14] предложен алгоритм трансформации реляционных данных в графовое представление. Представлены идеи, как при обходе отношений выяс нить, что является вершиной, а что ребром. В данной работе слабо затронута тема отображения языка запросов. Neo4j в работе [15] при переходе от реляционного представления в графовое дает следующие рекомендации:

1. Все записи таблиц представляются как вершины с именем сущности, как название таблицы; 2. В качестве ребер берутся внешние ключи или возможные соединения между таблицами.

Представления графов в виде ЕR-диаграммы бьmо предложено в статье [3]. В рамках этой работы было создано приложение, которое на основе построения ЕR диаграммы также строит и граф. В работе [1] описывается процесс переноса свя зей в ЕR-моделе в NoSQL базы данных. Приводится сравнительная характери стика отражения вида связей в различные формы баз данных. Среди них вьщеля ется характеристики графовой базы данных, в которую можно отразить все виды связей.

В работе [9] рассматривается отображение ЕR-диаграмм только в структуру графа с учетом видов связей.

Тема интеграции реляционных и графовых баз данных затрагивается в ра боте [ 11]. В статье описывается опыт по переносу данных о публичном транс порте из реляционной системы хранения в графовую базу данных и использова нии их одновременно. Данные действия обусловлены эффективностью графовых алгоритмов. В статье [10] предлагается схема интеграции данных, язык запросов которой построен на лямбда-исчислении, приводятся примеры перевода его в язык SQL и Cypher.

Тема отображения Cypher в другие языки запросов не остается без внимания исследователей. В работе [12] представлен инструмент, который теоретически мог отображать Cypher в любой язык запросов, при правильном формировании файла топологического отображения gTop.

В gTop вьщеляется два уровня: абстрактный и реализационный. Абстрактный отвечает за формальное описание вершин и ребер в графе, реализационный опи сывает как граф отображается в данной системе с указанием, какие с какими таб лицами описываемая таблица может соединяться. Получается, что пользователь этой библиотеки должен сам описать, как в реляционной системе отображается граф.

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

Практически реализован функционал по отображению Cypher в язык SQL в виде библиотеки Cytosm.

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

Для демонстрации отображения используем фрагмент базы данных North Wind [15], схема которого представлена на рис.1. В разделе запроса МА ТСН перечислен набор вершин и связывающих их ребер. Согласно [5] вершины и ребра имеют следующие шаблоны.

Вершина представляется выражением (а: l {Р}), где:

• а Е А U {nil} -имя вершины в запросе. Наличие имени дает возможность ис пользоваться эту вершину дальше в теле запроса.

• l с L -возможно пустое конечное множество меток верпшны. В данной ра боте состоит из одного элемента. • Р -возможно пустое конечное множество частичных отображений атриб ут ов верпшны в выражения. Выражения накладывают дополнительные ограниче ния, которые должны быть в искомых вершинах.