Как графовые базы данных ускоряют исследование отношений между людьми по сравнению с многотабличными SQL-запросами на соединение таблиц в реляционных базах данных. Смотрим на примере NoSQL-СУБД Neo4j и ее SQL-подобного языка запросов Cypher.
Что такое Neo4j и как она работает: краткий ликбез
Большинство системных и бизнес-аналитиков хорошо знакомы с реляционными базами данных, информация в которых хранится в таблицах с жестко заданной структурой. Однако, это преимущество строгой типизации полей и табличная организация хранения данных походят не для всех сценариев применения. Поэтому полезно знать и про NoSQL-базы, которые предназначены для хранения больших объемов данных со сложной или изменяющейся структурой. Недавно я писала про одну из таких СУБД на примере документо-ориентированного хранилища MongoDB. Продолжая эту тему про ключевые компоненты архитектуры информационных систем, сегодня рассмотрим другой вид нереляционных баз данных, графовую СУБД Neo4j. Эта система хранит данные в виде графа знаний, который состоит из вершин и соединяющих их ребер. Поэтому Neo4j отлично решает задачи на графах, такие как поиск оптимального пути в логистике, информационных или электротехнических сетях, выявление сообществ и анализ социальных связей. Именно это рассмотрим далее, чтобы сравнить, насколько быстрее и легче задача выявления связей между людьми решается в Neo4j по сравнению с реляционными СУБД.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 января, 2025
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Анализ социальных связей в реляционной СУБД на примере PostgreSQL
Возьмем в качестве примера набор различных взаимоотношений между 9 людьми, сперва представив их в табличном виде.
| Человек 1 | Человек 2 | Отношения |
| Саша | Маша | деловые, работают вместе в отделе продаж |
| Петя | деловые, работают вместе по проектам | |
| Леша | семейные, Саша и Леша братья и живут в одном доме | |
| Кира | дружеские, вместе ходят в клуб любителей йоги | |
| Ира | деловые, работают вместе в отделе продаж | |
| Сережа | Катя | любовные, Катя встречается с Сережей, они живут вместе |
| Костя | дружеские, вместе играют в шахматы в районном клубе | |
| Петя | дружеские, вместе катаются на лыжах | |
| Маша | Костя | любовные, Маша встречается с Костей, они живут вместе |
| Ира | дружеские, вместе ходят в клуб любителей йоги | |
| Кира | Леша | деловые, работают вместе по проектам |
Если хранить данные по этим людям и их взаимосвязям в реляционной базе, потребуется как минимум 4 таблицы для представления схемы в 3-ей нормальной форме:
- таблица person – справочник людей, о которых идет речь в рассматриваемом кейсе;
- таблица relation – справочник видов связей, какие могут быть отношения между людьми (деловые, дружеские, семейные, любовные);
- таблица place – справочник мест, где возникают отношения между людьми (отдел проектов или продаж на работе, дом, клуб, бар и пр.);
- person_relation – таблица с отношениями между парами людей.
Чтобы понять, кто с кем и где встречается, совместно проживает или вместе работает, к реляционной базе придется выполнять многотабличные запросы с несколькими соединениями через оператор JOIN.
Например, следующий запрос покажет список людей, которые связаны деловыми отношениями:
select pers1.per_name as A, pers2.per_name as B, rel_name, pl_name from persons.person_relation as rels join persons.person as pers1 on pers1.per_id=rels.pr_per1 join persons.person as pers2 on pers2.per_id=rels.pr_per2 join persons.relation as rel on rel.rel_id=rels.pr_rel join persons.place as pl on pl.pl_id=rels.rel_pl where rels.pr_rel=1
Этот запрос включает 4 оператора JOIN и выглядит довольно тяжеловесным. Посмотрим, как решить подобную задачу с анализом социальных связей в графовой СУБД Neo4j.
Анализ социальных связей в графовой СУБД
Чтобы построить граф связи в Neo4j, откроем ее веб-консоль по адресу https://console.neo4j.org/ и введем там следующий запрос на создание узлов (людей) и отношений между ними (связей):
create (Sasha:Sales {name: 'Саша'}), (Masha:Sales:Home3 {name: 'Маша'}), (Petya:Projects {name: 'Петя'}), (Lesha:Home1 {name:'Леша'}), (Kira:YogaClub {name: 'Кира'}), (Ira:Sales {name: 'Ира'}), (Serg:Home2:SkiClub {name: 'Сережа'}), (Katya:Home2 {name: 'Катя'}), (Kostya:ChessClub:Home3 {name: 'Костя'}), (Sasha)-[:deals]->(Masha), (Sasha)-[:deals]->(Petya), (Sasha)-[:family]->(Lesha), (Sasha)-[:friend]->(Kira), (Sasha)-[:deals]->(Ira), (Serg)-[:loves]->(Katya), (Serg)-[:friend]->(Kostya), (Serg)-[:friend]->(Petya), (Masha)-[:loves]->(Kostya), (Masha)-[:friend]->(Ira), (Kira)-[:deals]->(Lesha) Сделаем к этому графу социальных связей несколько запросов. Например, выясним, кто с кем связан деловыми отношениями (deals). Для этого следует написать простой запрос сопоставления (MATCH) на внутреннем SQL-подобном языке запросов Cypher, который поддерживает Neo4j:
match (n)-[r:deals]-(m) return n.name, m.name
В ответ вернется таблица сопоставления узлов, которые связаны деловыми отношениями. Усложним MATCH-запрос, добавив фильтрацию. К примеру, найдем, с кем дружит Сережа, т.е. с какими узлами графа узел с этим именем связан отношениями friends. Для этого напишем следующий Cypher-запрос:
match (n{name: 'Сережа'})-[r:friend]-(m) return n.name, m.name 
Разумеется, это далеко не все примеры запросов, которые можно делать в Neo4j с помощью Cypher, анализируя граф социальных связей. Также эта NoSQL-СУБД поддерживает алгоритмы работы со графами, включая определение меры центральности и степени связанности, алгоритм Дейкстры для нахождения оптимального пути и другие инструменты решения графовых задач.
Познакомиться с этой NoSQL-СУБД и другими нереляционными базами данных в рамках изучения основ архитектуры и интеграции информационных систем вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
Источники
