Modem information various ways.Тhе relational data model is no longer suficient in а natural dan ecfiient areas are much more convenient to represent in NoSQL modelsШее graph the same agement.One of the possiЫesolutionsto overcome this proЫem is application of а multi-model two-way mapping between the applied data models.Existingpaproaches ping between graph and implement two-way mapping usingan devoted to а two-way mapping between graph and as well as between the relational (SQL) and Взаимное отображение графовой и реляционной моделей данных для мультимодельных баз данных Аннотация. Современные информационные пользуют данные разJШчной структры. статочно реляционной модели данных.Также, концептуальные схемы мно
isting multi-model provided.
Mapping is illusatrted Ьу examples of schemasand queries.Comparison of ex databasesthat implement graph and relational modelsis also
университет им.М.В.Ломоносова, Москва, Россия гих предметных областей значительно удобнее представлять в NoSQL моCopyright © 2020 for this paper Ьу its authors. Use peпnitted under Creative Comons
License Atribution 4.0 Intemational (СС ВУ 4.0). делях, например, в агрфовой модели. Использование в рамках одной ин формационной системы нескольких СУБД, реализующих разные модели данных, приводит к существенному усложнению управления системой. Од ним из возможных решений данной проблемы является использование мультимодельной СУБД. Формальной основой для разработки такой СУБД является взаимное отображение между применяемыми моделями данных. Данная работа посвящена взаимному отображению между схемами графо вой и реляционной моделей данных, а также между языками запросов SQL и Cypher. В настоящее время существует множество подходов к отображе нию графовой модели в реляционную модель и наоборот. Все эти подходы в полной мере реализуют отображение в одну сторону или взаимное отоб ражение с использованием промежуточного рпедставления. Рассмотрены и продемонстрированы на конкретных рпимерах идеи отображения схем и языков запросов. Проведено рсавнение существующих мультимодельных баз данных, реализующих графовую и реляционную модели. лКючевые лсова: интеагрция моделей данных, графовая реляционная модель данных. модель данных, 1
Введение Современные информационные системы одновременно используют данные раз личной структуры. Для их представления уже недостаточно реляционной модели данных. Также, концептуальные схемы многих предметных областей значи тельно удобнее представлять в NoSQL моделях, например, в графовой модели. Использование в рамках одной информационной системы нескольких СУБД, ре лаизующих разные модели данных, приводит к существенному усложнению управления системой.
Одним из возможных решений данной проблемы является использование
мультимодельной СУБД [
Эта работа посвящена теме интеграции реляционной и графовой моделей. Ре ляционная модель является самой популярной в меир и занимает 60% рынка на 2019 год1• Графовая модель естественна для епрдставления некоторых ерпдмет ных областей, например, социальных сетей. Также, из-за отсутствия схемы, воз можно хранить данные разнородных объектов в одном месте.
В настоящее время развиваются мультимодельные СУБД, поддерживающие ргафовую и реляционную модели такие как Agens Grhap, CosmosDB, OrientDB, MarkLogic.
Несмотря на наличие данных СУБД, вопрос интеграции реляционной и графо
вой моделей не решен полностью. Одной из проблем является разнообразие язы
ков манипулирования аргфовыми данными: Cypher, SPARQL, Gremlin, PGQL.
Также ведутся работы по разработке единого стандарта языка запросов hpaGr
1
https://scalegrid.io/Ыog/2019-database-etrnds-sql-vs-nosql-top-databases-single-vsumltiple-database-use/
Query Language (GQL). Стандарт GQL [17] бьm одобрен в сентябре 2019 года, на
него повлияли работы [
Для интеагрции интересующих моделей MaгkLogic и OrientDB отображают данные в промежуточное рпедставление. Agens Graph не епрдоставляют отобра жение моделей друг в удрга, а опрсто хранит данные графовой и реляционной моделей в раздельных хранилищах и для одновременного обращения к этим хра нилищам необходимо производить гибридные запросы.
На данный момент существует множество подходов к отображению графовой
модели в реляционную модель и наоборот. Все эти подходы в полной мере реа
лизуют отображение только в одну сторону или взаимное отображение с исполь
зованием промежуточного представления. Например, в работе [14] предложен
алгоритм трансформации реляционных данных в графовое рпедставление. В ста
тье [
Таким образом, по сведениям автора, в настоящее отсутствуют полноценные подходы к взаимному отображению реляционной и графовой моделей без ис пользования промежуточного представления. Данная работа направлена на объ единение существующих решений и предоставления подхода по взаимному отоб ражению языков запросов и подхода по отображению схем данных реляционной и графовой моделей.
Целью данной работы является разработка взаимного отображения графовой и реляционных моделей для обеспечения возможности обращения на реляцион ном языке запросов к графовым данным и наоборот. Такое отображение может бьrrьприменено в качестве формальной основы для мультимодельной СУБД.
Для достижения данной цели необходимо решить следующие основные за дачи: 1. Произвести обзор существующих мультимодельных баз данных, реализую щих аргфовую и реляционную модели. 2. Определить варианты взаимного отображения схем графовой и реляционной моделей. 3. Определить варианты взаимного отображения языков запросов реляционной и ргафовой моделей. 4. Реализация отображений схем и запросов для конкретных выбранных реляци онной и графовой СУБД. 5. Произвести сравнение эффективности вариантов отображения на тестовых ба зах данных и наборах запросов.
В качестве графового языка запросов выбран Cypher, который близок к GQL, и бьm разработан в компании Neo4j. В 2015 реализация языка была открыта в рамках опреакт openCypher. В качестве реляционного языка запросов выбран SQL, реализованный в большом количестве проприетарных и свободно распро сатрняемых СУБД. Работа выполняется в рамках магистерской диссертации на факультете Вычис лительной математики и кибернетики УМГ им. М.В. Ломоносова, опрагрмма «Большие данные: инфрасуктртуры и методы решения заадч».
В стьате рпиведены результаты первого года исследований: произведен обзор сушествующих мультимодельных СУБД, предложено по одному варианту основ ных идей отображений (i) реляционной схемы в агрфовую схему, (ii) агрфовой схемы в реляционную схему, (iii) запросов Cypher в SQL, (iv) запросов SQL в Cy pher. Все идеи сопровождаются ирпмерами отображений с пояснениями.
Данная статья структурирована следующим образом. В разделе 2 представ лены родственные работы и приведено ркаткое сравнение мультимодельных СУБД. В разделе 3 приведен вариант отображения схем графовых и реляционных баз данных друг в друга. В разделе 4 представлен вариант отображения языков запросов. Варианты отображений проиллюстрированы на примерах. В разделе 5 рпиведено заключение и направления дальнейших работ. 2
Родственные работы
Работа [
В данной работе приведено ркаткое сравнение мультимодельных СУБД Agens Graph1, CosmosDB2, OrientDB3, MarkLogic 4. Сравнение проводилось на основе документации СУБД по следующим критериям: поддерживаемые языки запро сов, модели данных и некоторые аспекты интеграции данных. Информация сгруппирована и представлена в таблице 1. По результатам анализа были сделаны следующие выводы: • В MarkLogic и OrientDB интегриуемые модели отображаются в опрмежуточ ное представление, с которым СУБД умеет работать. Мы же хотим избежать введения промежуточного представления с помощью отображения графовой и реляционной моделей друг в удрга. Это позволит нам предоставлять пользо вателю выбор удобного ему интерфейса для работы с данными. 1 https:/ /Ьitnine.net/documentations/manual/agens 2 https://docs.microsoft.com/m-ru/azure/cosmos-dЫ 3 http://w.orientdb.com/docs/last/index.html 4 https://docs.mark:logic.com _graph
_develope_rmanual_en.html • В AgensGraph отсутствуетвозможностьобращатьсяк графовомухранилищу на реляционномязыке запросов и наоборотП.редоставлениетакойвозможно сти является однимиз результатовданнойработы. • CosmosDB является проприетарной облачнойбазойданных. Этонакладывает оагрничения на использованиеее в проектах, где отсутствуетсвязь с внешним миром. • OrientDB использует в качестве языка запросасвойдиалект SQL. Этонакла дывает ограничение в виде отображениядиалекта и стандарта SQL на мигра цmона данную СУБД или с даннойСУБД. • CosmosDB, OrientDB в качестве агрфового языка запроса используютGremlin, которыйвнес меньший вклад в стандартизацию графового языка запроса, чем Cypher [16].
В течение последнихлет быломножествоработпоповодумиагрции данных с
реляционных баз данных в агрфовые базы данных [
Таблица 1. Сравнение
мультимодельных баз данных AgensGтaph
CosmosDB
MarkLogic
OrientDB п Реляционный запросов Графовый запросов Модели Интеграция модеелй язык язык
SQL к реляционному хранилишv Cypher к ргафовому хранилип v Графовая, реляционная, документоориентированная, ключ-значение SQL исполняется над реляционным хранилищем, Суpher над агрфовым. Интеграцию данных рханилищ можно произвести с помощью гибридных запросов
LQIN Gremlin Графовая, реляционная, документоориентированная,ключ-знаколо
SQL SPARQL Документорие отнрваная, ргафовая, реляционная чение, ночная Позволяет вы- рП и полнять за- ции просы на реля- ков ционном и агр- димо фовом языках запросов над данными представленными в ную формеат JSON.
интеграисточнинеобхоотобраЗИТЬ нитегрируемые данные в промежуточ
схему, назьmаемую Entiy Свой диалект SQL Gremlin Графовая, реляционная, документоориентированная,ключ-значение, объектноориентированная Работает с за-пи сями, которые реалнзуют один из четырех типов: документ, BLOB, ребро, вершина. Записи объединяются в классы, похожне на отношения в реляционной модели. В работе [14] предложен лагоритм ртансформации реляционных данных в ргафовое рпедставление. Представлены идеи, как при обходе отношений выяс нить, что является вершиной, а что ребром. В данной работе слабо заотрнута тема отображения языка запросов.
Neo4j в работе [15] при переходе от реляционного представления дает следующие рекомендации: в графовое 1. Все записи таблиц представляются как вершины с именем сущности, как название таблицы; 2. В качестве ребер берутся внешние ключи или возможные соединения между таблицами.
Представления графов в виде ЕR-диаграммы бьmо предложено в статье [
В работе [
Тема интеграции реляционных и графовых баз данных затрагивается в ра
боте [
Тема отображения Cypher в другие языки запросов не остается без внимания
исследователей. В работе [
В gTop вьщеляется два уровня: абстрактный и реализационный. Абстрактный отвечает за формальное описание вершин и ребер в агрфе, реализационный опи сывает как граф отображается в данной системе с указанием, какие с какими таб лицами описываемая таблица может соединяться. Получается, что пользовеатль этой библиотеки должен сам описать, как в реляционной системе отображается аргф.
Топологический файл помогает при отображении избежать комбинационного взрыва ипр поиске необходимого отображения в другой язык запросов.
Практически реализован функционал по отображению Cypher в язык SQL в виде библиотеки Cytosm.
Работа [
схему, (ii) агрфовой в SQL, (iv) запросов SQL в Cypher 3
Отображения схем данных ставляют новые операторы. Авторы представляют алгоритм по отображению за рпосов в нее. Данная работа не покрывает всего множества языка. Авторы не утверждают, что их адаптация операторов отображается в обычную реляцион уню
алгебру.
Целью магистерской работы является объединение перечисленных решений
для построения
взаимного отображения графовой
и реляционной моделей дан
ных. Идеи отображения схем данных основаны на работах [
(i) отображение схем реляционной модели в схемы графовой модели и (ii) отображение схем графовой модели в схемы реля ционной модели. Отображения иллюстриуются на примерах конкретных схем. Реляционная
модель бьша предложена Коддом в 1970 году [
данных в виде отношений. Отношения состоят из кор тежей, которые в свою очередь состоят из пар (название атрибута, значение ат рибута). В данной работе атриб ту
ы могут рпинимать такие типов, как целочисленный, сотрковый и пр.
лишь атомарные значения, Предполагается, что в каждом отношении R определен
первичный ключ - значение (или совокупность значе ний), которая R имеется атриб ут точно идентифицирует
каждый кортеж в R. Если же в отношении А, который определен в другом отношении S, как первичный ключ, то А является внешним ключом в R.
В качестве структур
графовой модели данных в данной работе используются атриб ут ные агрфы.
Атриб ту ным агрфом няющих их ребер. Вершины и направленные называется множество вершин и соеди ребра которые могут бьпь анноти рованы совокупностью пар (название атрибута, значение атрибута) и меткой (label). Каждое ребро соединяет ровно две вершины.
Основные идеи отображения схем реляционной модели в агрфовую модель со случаи, когда первичный кчшо
состоит из более чем двух элементов или составлен специфичным образом. Например, как композиция внешних ключей, которые в свою очередь состоят из нескольких атрибутов.
Также считается, что внешний ключ состоит из одного ат рибута. Не учитываются функциональные зависимости между типа отношений. Разработка данных аспектов является предметом дальнейшей работы. лДя демонстрации отображения
используем фрагмент базы данных Nohrt Wind [15], схема которого представлена
на рис.1.
Emp loyees
-,.
FirstName LastName РК ProductlD
Products ProductName QuanlityPerUnrt UnrtPrice
Orders РК OrderlD -';,
FK Employeeю
Ord erDat e ShiJ)pedDate ShipVia ShipName ShipCity ShipCountry РК OrderlD
UnitPrice Quanlity Discouлt
Order Deta ils Рис. 1. Фрагмент
схемы базы данных North Wind Огображение данной реляционной схемы в графовую схему конкретизируется следующим образом:
шин с одноименными метками. • Формируются следующие
ребра: • Типы отношений Employees,
Orrdes,
Products отображаются множества вер ee;sID тами OrdeerDtails. - между вершинами с метками lEmpoyees и Ordes - ребра с меткой lEmpoy - между вершинами с метками Products и Orders - ребра с метками и аитрбу На рис. 2 представлена результирующая графовая
схема.
EmployeeilJ Рис. 2. Отображение реляционной схемы в графовую схему
одноименными атриб ут ами кортежей. Первичные ключи вершин представляются
первичными ключами соответствующих типов • Каждая метка ребер отображается в одноименный тип отношения. Ребра пред ставляются кортежами соответствующих типов отношений. Атриб ту ы ребра рпедставляются
одноименными аитрб ут ами кортежей. В качестве составного первичного ключа берут ся первичные ключи типов отношений, полученных лДя иллюстрации вышеприведенного отображения рассмотрим подграф, взя тый из модельного примера, который предоставляет компания Neo4j (см. рис. 3).
- метка ребра с аитрб ут ами, связывающее вершины с метками - метка ребра без атриб ут ов, связывающее вершины с метками • ACTED_IN
Person • DIRECTED
Person и Movie.
и Movie. следующим образом:
Отображение данной графовой схемы в реляционную схему конкретизируется • Вершины с метками Person
отображаются в кортежи одноименного типа от ношения. Первичный ключ типа отношения имеет имя PersonID. • Вершины с метками Movie отобраажются в кортежи одноименного типа отно шения. Первичный ключ типа отношения имеет имя MovieID. • Ребра с меткамиАCTED_IN
отображаются в одноименный тип отношения. Ат рибут ы ребра отображаются в одноименные атриб ут ы отношения. Первичный ключ является составным и состоит из внешних ключей PersonID, MovieID. • Ребра с метками DIRECTED
отображаются в одноиме шый тип отношения. Первичный ключ является составным и состоит из внешних ключей PersonID, MovieID. На рис. 4 представлена результирующая
реляционная схема.
Регsоп РК PersonlD bom name
Movie РК MovielD iltle released tag!ine
ACTED_IN РК MovielD roles
DIRECTED РК Pesron!D РК MovielD Рис. 4. Реляционное представление подграфа. 4
Отображение языков запросов • l с L - возможно пустоеконечное множество меток верпшны. В данной ра
либо пустой,либо состоит из (m, п) Е N u {nil}. • /
интервал, состоящий из минимального и максимального числа ребер, ко торые необходимо пройти для нахождения необходимой вершины. Показатель
имени дает возможность обращаться к Пример 3: Ребро в Cypher
[k: KNOWS * 1..2 {since: 1985}] В примере 3: k имя верпшны;
KNOWS - метка ребра; 1..2 интервал, раз; {since: 1985} - отображение атриб ту а вершины since в 1985. показывающийто, что ребра с данной меткой могут встречаться в пут и от 1 до 2 В примере 4 сначала мы выбираем зуем ее для следующего раздела запроса торых знает 'David'.
вершину с именем 'David', потом исполь МАТСН, где мы ищем всех людей, ко 4.1 Отображение графового языка запросов в реляционный язык запросов Основные идеи отображения запроса на Cypher в SQL состоят в следующем: • Шаблон (вершина)-[ребро]-(верш.и..н-а) -(вершина)в разделе заопрса МАТСН отображается, как набор соединений между отношениями. • Шаблон(вершина)или[ребро]в разделе запроса МАТСН отображается в одно отношение. • При отображении вершин, ребер из раздела запроса МАТСН необходимо учи тывать их шаблоны и отобразить их следующим образом: -Метки вершин, ребер отобразить в разделе запроса FROM реляционного за орпса. -Множество частичных отображений отображаются в предикаты в раздел за орпса НWERE реляционного запроса. • Предикаты из раздела запроса WНERE отображаются в предикаты раздела за орпса НWERE реляционного запроса. • Атриб ут ы результатов запроса в разделе запроса RETURN отображаются в од ноименные атриб ут ы в реляционный раздел запроса SELECT. • Разделы запроса, которые предшествуют разделу запроса IWTH отображаются в вложенный запрос, который соединяется с отображением следующих после IWTH разделов запроса.
Далее рпиведены запросов на Cypher рпимеры запросов берется из рис.2.
к реляционной схеме на рис. 1. Схема для Запрос 1.1. Вывести продавцов, которые продавали шоколад. АМТСН (e:Employees)-[:EmployeeID]-()-[:OrderDetails]-(p:Prod ucts{ProductName:'Chocolade'}) RETURN e.firstName, e.lastName Конкретизируем • В разделе запроса МАТСН указаны марки вершин и ребер, одна из вершин() - анонимная. Из агрфовой схемы, можно определить, что в анонимной вер шине может ипрс ту ствовать только вершина Orders. • Отображаем это в набор соединений между отношениями, учитывая идеи отображения, что ребрами являются внешние ключи и отношения с составным первичным ключом. Некоторые вершины и ребра не имеют имени, то при своим им имя в реляционном отображении. Так ребру ODrdeetails рписваива ется имя od. • Отображение {ProductName: 'Chocolade'} отображается в предикат
aNme = 'Chocolade' реляционного заопрса в разделе WНERE. • Атрибуты в разделе заопрса RETURN отображаются в одноименные атрибуты в раздел заопрса SELECT. p.Product SELECT e.firstName, e.lastName FROM Employees as е JOIN Orders as о ON o.EmployeeID = e.EmployeeID JOIN Order Details as od ON od.orderid=o.orderid JOIN Products as р ON p.productID=od.productID WHERE p.ProductName='Chocolade', Запрос 1.2. Вывести имена и фамилию сотрудников, дату заказа, которые участ вовали в откузгре товара из Сиэтла и их имена начинаются на А. МАТСН (e:Employees) WHERE e.firstName STARTS WITH 'А' WITH е МАТСН (e)-[:EmployeeID]-(o:Orders{shipCity:'Seattle'}) RETURN e.lastName, e.firstName, o.orderDate Конкретизируем SELECT e.lastName, e.firstName, o.orderDate FROM Orders as о JOIN (SELECT е.* FROM Employees as е WHERE e.firstName LIKE 'А%') as е ON(o.EmployeeID=e.EmployeeID) WHERE o.shipCity = 'Seattle' 4.2 Отображение реляционного языка запросов в графовый язык запросов Основные идеи отображения запроса на SQL в Cypher состоят в следующем: • Если в реляционном запросе имеется вложенный заопрс, то вложенный запрос необходимо отобразить запрос на языке Cypher, а результаты запроса передать в основной с помощью раздела запроса WITH. • Раздел запроса FROM, состоящий из перечисления отношений, отображается в названия меток в вершинах и ребрах. При наличии оператора JO,IN соединя емые отношения отображаются в шаблон (вершина)-[ребр]о-(вершина.).-.(вершина). • Предикаты-условияв разделе запроса НWERE отображаются согласно следу ющим идеям: -Если предикат-условие - оператор равенства атрибута какому-тозначе нию, то переносим в оператор МАТСН в вершину или ребро в отображение атрибутов в выражения -Другие рпедикаты-условия отображаем в предикаты условия в графовый раздел запроса WНERE. • Атрибуты результатов запроса в разделе запроса SELECT отображаются в од ноименные атрибуты в реляционный раздел запроса в RETURN.
Далее рпосов приведены примеры запросов на SQL берется из рис. 4.
к агрфовой схеме на рис. 3. Схема для за Запрос 2.1. Выбрать всех актеров, которые снимались в фильме «Маитрца». SELECT p.name FROM Person as р, JOIN ACTED IN as а ON (a.PersonID=p.PersonID), JOIN Movie as m ON (a.MovieID = m.MovieID) WHERE m.title = 'The Matrix' Конкретизируем отображения
данного запроса: • Атрибут в разделе запроса дела запроса RETURN.
SELECT отображается в одноименный атрибут раз • Раздел запроса FROM в связи с наличием оператора JOIN отображается в шаб лон (вершина)-[ребро]-(вершин..а.)--(вершина)П.о агрфовой схеме опреде лим, что Person, Movie - вершины, ACTED_IN - ребро между ними. • Предикат в разделе запроса EНWRE отображается в шаблон вершины Movie, так как является предикатом равенства значению. Результат отображения АМТСН (p:Person)-[:ACTED_IN]->(m:Movie{title: 'The Matrix'}) RETURN p.name Запрос 2.2. Выбрать всех актеров, которые снимались в фильме «Матрица» с ис пользованием вложенного запроса.
SELECT p.name FROM Person as р, WHERE p.PersonID IN SELECT per.PersonID FROM Person as per JOIN ACTED IN as а ON (a.PersonID=per.PersonID), JOIN Movie as m ON (a.MovieID = m.MovieID) WHERE m.title = 'The Matrix') Конкретизируем
отображения данного запроса: • Вложенный заопрс отображается в запрос на языке Cypher, как запрос, опи санный выше. Результатом вложенного запроса является коллекция идентифи коатров. Поэтому результат отобразится в аргумент функции colect. Это все передастся в основной заопрс с помощью WITH. • Предикат 1N в разделе запроса EНWRE отобразится в одноименный предикат в графовый раздел запроса EНWRE. • Атрибут в разделе запроса SELECT основного запроса отображается в одно именный атрибут раздела запроса RETURN. Результат отображения АМТСН (per:Person)-[:ACTED_IN]->(m:Movie{title: 'The Matrix'}) WITH collect(per.PersonID) as l АМТСН (p:Person) WHERE p.PersonID IN l RETURN p.name
Заключение и направления дальнейшей работы В данной работе был рассмотрен воопрс отображения графовых и реляционных моделей данных друг в друга. Приведено краткое сравнение мультимодельных баз данных, которые объединяют эти модели. Рассматриваются основные поня тия реляционной и графовой моделей.
Бьm произведен обзор существующих мультимодельных СУБД, предложено по одному варианту основных идей отображений (i) реляционной схемы в графо вую схему, (ii) агрфовой схемы в реляционную схему, (iii) запросов Chyper в SQL, (iv) запросов SQL в Cypher. Все идеи сопровождаются рпимерами отобра жений с пояснениями.
Результаты данной работы могут бьпь использованы как формальное основа ние для мультимодельной базы данных или системы интеграции ргафовой и ре ляционной моделей.
Основные наапрвления дальнейшей работы выглядят следующим образом: • учет при отображении важных, но не рассмоетрнных понятий реляционной и ргафовой моделей, таких, как функциональные зависимости различного вида, составные внешние ключи и т.д.; • исследование других вариантов отображения между схемами и языками запро сов (например, отображение каждого типа отношения в отдельную вершину ргафа). лПанируется рассмотреть влияние функциональных зависимостей на отображение; • формализация алгоритмов отображения схем и запросов между Cypher и SQL. Языки запросов планируется формализовать с использованием реляционной лагебры и реляционной алгебры над графами, рпедложенной в работе[?]. Для формализации рпавил отображения языков запросов планируется использо вать движимый моделями подход (МDА) и язык отображения моделей ATL1 ; • реализация отображений схем и запросов для конкретных выбранных реляци онной и графовой СУБД; • сравнение эффективности вариантов отображения на тестовых базах данных и наборах запросов. лБагодарности. Автор выражает благодарность опрфессору НИУ ВШЭ в Санкт Петербурге Борису Асеновичу Новикову за идею работы и ассистенту СПБГУ Георгию Алексеевичу Чернышеву за замечания и предложения по улучшению работы. Работа выполняется в рамках магистерской диссертации на факультете Вычислительной математики и кибернетики МГУ им. М.В. Ломоносова под научным руководством С. А. Ступникова, ведущего научного соутрдника Феде рального исследовательского центра «Информатика и управление» Российской Академии Наук. Литература the Fifth Intemational Workshop on Grhap Data-managementExperiences & Sys tems. Association for Computing Machinery, New Уork, NY, USA, Article 4, 16, (2017). https://doi.org/10.l 145/3078447.3078451 13. n0-al, У. , Oguztin, Н.: Migr ation of data from relational database to gr aph database. In Proceedings of the 8th Intemational Conference on Information Sys tems and Technologies. Association for Computing Machinery, New York, NY, USA, Article 6, 1-5 (2018). https://doi.org/10.1145/3200842.3200852 14. Virgilio, R., Maccioni, А., Torlone, R.: Converting relationalto gr aph databases.
In First Intemational Workshop on Graph Data Management Experiences and Systems. Association for Computing Machinery, New Уork, NY, USA, Article 1, 1-6 (2013). https://doi.org/10.1145/2484425.2484426 15. Tutorial: Import Relational Data Into Neo4j, https://neo4j.corn/developer/guide importing-data-and-etl/ 16. SQL ... and now GQL, https://www.opencypher.org/articles/2019/09/12/SQL and-now-GQL/ 17. GQL Standard, https://www.gqlstandards.org