OrientDB — простой пример работы с графами для начинающих

OrientDB — взгляд человека, который привык работать с реляционными базами данных.
Напомню, что OrientDB — графовая, документно-ориентированная база данных, реализованная на Java.

Решил написать статью, для новичков, т.к в начале сложнее всего, а на рус. вводых статей с доходчивыми примерами практически нет.

Я думаю рассказывать как скачать orientDB не нужно, но на всякий случай www.orientechnologies.com/download
Про теорию рассказывать в этой статье не хочу, мне кажется многим просто хочется пощупать OrientDB и хоть немного разобраться. Но для тех, кто хочет немного теории на русском, есть недописанная статья.
Ну а мы начнем и первым делом запустим orientDB-сервер:

/programs/orientDB/bin/server.sh

Во вторых зайдем в orientDB-консоль:

/programs/orientDB/bin/console.sh

В третьих, нам нужно узнать рутовый пароль, а прописан он в файле:

/config/orientdb-server-config.xml

поищите строчку с «password» и все сразу поймете.
Зная пароль, можно создать базу данных:

orientdb> create database remote:localhost/people root PASWORD local

напомню синтаксис таков:

create database <database-url> <user> <password> <storage-type> [<db-type>]

Посмотрим информацию о нашей базе данных:

orientdb {people}> info

и видим, что при создании появляются стандартные классы, кластеры и индексы.
 

Vertex — вершины

Создадим класс персон ( Person ):

create class Person extends V

обратите внимание, мы создали класс типа Vertex (вершина)
Добавим в класс строковое свойство name

create property Person.name string 

Создадим две вершины:

create vertex Person set name='Joanie'
create vertex Person set name='Chachie'

EDGE — ребра

В статье которую я собирался перевести, автор создает класс в котором якобы будет указывать связи между этими персонами

create class Loves extends E

на самом деле этот класс не играет никакой роли и его создавать не нужно (пока не нужно).
Добавим одну связь между персонами:

create edge Loves from #11:1 to #11:0

обратите внимание, мы создали связь типа EDGE (ребро).
Итак, мы связали двух персон, проверим нашу работу:
 

orientdb {people}> select from Person

----+-----+-------+--------+---------
#   |@ RID|name   |in_Loves|out_Loves

----+-----+-------+--------+---------
0   |#11:0|Joanie |#11:1   |null     
1   |#11:1|Chachie|null    |#11:0    

----+-----+-------+--------+---------

Заметьте, в классе Person появилось 2 поля:

• in_Loves
• out_Loves

эти поля создаются автоматически, и отказаться от их создания не получится, да и не нужно, т.к. в этих полях можно увидеть связь наших персон ( @ RID ), но что это нам дает? А дает это нам то, что к этим полям можно обращаться как к объектам, например если написать запрос:
 

orientdb {people}> select name, in_Loves.name as in, out_Loves.name as out from Person

----+-----+-------+-------+------
#   |@ RID|name   |in     |out   

----+-----+-------+-------+------
0   |#-2:1|Joanie |Chachie|null  
1   |#-2:2|Chachie|null   |Joanie

----+-----+-------+-------+------

то мы получим не @ RID связей, а данные связанных объектов.
Обратите внимание, т.к. наш класс Person наследуется от класса V, то все данные связи так же будут существовать и в классе V:
 

orientdb {people}> select from V        

----+-----+-------+--------+---------
#   |@ RID|name   |in_Loves|out_Loves

----+-----+-------+--------+---------   
5   |#11:0|Joanie |#11:1   |null     
6   |#11:1|Chachie|null    |#11:0    

----+-----+-------+--------+---------

Кто-то, кто немного изучал OrientDB, может спросить, а как же E (EDGE), почему ребро не прописалась туда?
Все очень просто, чтобы связь прописалась в E, ребру нужно давать имя. Т.е. мы писали:

create edge Loves from #11:1 to #11:0

а нужно было писать:

create edge from #11:1 to #11:0 set MyFieldName = 1

кроме того, можно создать класс Loves (см. выше, мы его пропустили) и создавая связь указывать название класса:

create edge Loves from #11:1 to #11:0 set MyFieldName = 1

таким образом, благодаря указанию имен полей (MyFieldName) мы можем разграничивать виды связей (в одном классе), а благодаря указанию имени класса, можно дополнительно разграничивать виды связей по классам. Однако, в классе Е всегда будут указаны все виды связей, т.к. именно от этого класса мы экстендимся (обратите внимание на то, как мы создавали класс Loves).
Некоторые из Вас скажут: а зачем мне экстендится от класса E, если все равно все данные попадают туда?
Я тоже задался этим вопросом и автор OrientDB мне ответил так: плюс в том, что OrientDB лучше партицируется используя графы, и конечно это влияет на скорость выборки данных.
Напомню, что партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.
Если статья понравилась, то могу подготовить продолжение.
Удачного освоения господа, а если есть вопросы, прошу в комментарии или в группу OrientDB.