Vimos no artigo anterior que uma base de dados de grafos possui dois objetos principais: vértice, também conhecido como nó, e aresta, que é o relacionamento e propriedades, em ambos. Nossas propriedades são cada uma um par chave valor. Mas ficou faltando como modelar nosso banco de dados de grafos.

A primeira coisa que devemos fazer é observar nosso domínio e visualizar quais são os vértices e as arestas. Aquela sua tabela que possui dados sobre uma ação feita entre duas outras entidades (tabelas, possivelmente) é uma candidata a ser uma aresta.

Um exemplo: temos um tipo de vértice pessoa. E um tipo de vértice item. E um tipo de relacionamento ligando os dois chamado de pedido. Uma pessoa relaciona-se com muitos itens com a qual fez pedido e um item tem muitos relacionamentos com muitas pessoas que fizeram pedido deles.

Não é para tudo que você vai usar um modelo de grafos. Dados estruturados de forma rígida estaria melhor, possivelmente, em um banco relacional ou baseado em colunas. Uma base de dados de grafos é indicada quando temos muitos relacionamentos em estruturas complexas, como multi levels.

“Graph modeling naturally fits with the way we tend to abstract the salient details from a domain using circles and boxes, and then describe the connections between these things by joining them with arrows. (…) What is particularly interesting about such graph models is the fact that they not only communicate how we think things are related, they also clearly communicate the kinds of questions we want to ask of our domain”. Do livro Graph Database por  Ian Robson, Jim Webber e Emil Eifren.

Premissa básica

Nós são coisas; relacionamentos são estrutura. Seus relacionamentos podem possuir direção também, se quiser. João é amigo de Pedro, esse é um relacionamento bi-direcional (joke: na maioria dos casos). João indica Pedro, esse é um relacionamento que possui direção, do primeiro ao segundo. Podemos guardar a data de início da amizade. Talvez guardar o local em que se conheceram.

Mas relacionamentos são a parte fundamental de uma estrutura de grafos. Dar propriedades pode ajudar a identificar tipos diferentes de relacionamentos, mas quanto mais propriedades, mais operações de IO. O banco usará as informações dos relacionamentos para caminhar entre os nós e diferenciar relacionamentos. É bom pensar em ser conciso nessa hora.

Itens complexos

Como as estruturas de dados são do tipo chave valor você pode sentir falta de um dado complexo, como endereço. Nesse caso você pode usar um outro tipo de vértice para representar o endereço e ter um relacionamento entre seu vértice pessoa (por exemplo) e o vértice endereço.

Entity-Relationship Diagram

Para descrever seu modelo em forma de diagrama você pode usar o Entity-Relationship Diagram. O ER-Diagram não é especifico para banco de dados de grafos, há anotações para foren-keys por exemplo, mas é um diagrama que se encaixa no nosso tipo de modelo.

Itens que iremos usar do ER-Diagram

• Entidade- VerticeNo ER-Diagrama você possui as entidades, são nossos vertices. Uma entidade é descrita como um retângulo e por convenção são usados substantivos.

• RelacionamentoUm relacionamento, nossas arestas, possuem o formato de losango. Por convenção é usado o nome de um verbo.

• AtributoAtributos são nossas propriedades, sao representadas por elipses.

No ER-Diragram também temos a cardinalidade (um para um, um para muitos e muitos para muitos) que não iremos usar. A linhas que irão ligar nossos itens podem indicar direção, por isso pode ser usado uma seta.

Ferramentas para modelar um ER-Diagram

De modo geral as ferramentas usadas para um ER-Diragam são as usadas para desenhar modelos de bancos de dados SQL.

Uma pequena lista fornecida pela Wikipédia:

Proprietary ER diagramming tools are Avolution,  ER/Studio, ERwin, DeZign for Databases, MagicDraw, MEGA International, ModelRight, Navicat Data Modeler,OmniGraffle, Oracle Designer, PowerDesigner, Rational Rose, Software Ideas Modeler, Sparx Enterprise Architect, SQLyog, System Architect, Toad Data Modeler, and Visual Paradigm.

Free software diagram tools just draw the shapes without having any knowledge of what they mean, nor do they generate SQL. These include Creately, yEd, LucidChart, Calligra Flow, and Dia.

Referências:

• Livro: Graph Databases – editora O’Relly – 2013 – autores: Ian Robson, Jim Webber e Emil Eifren
• Artigo: Modeling Categories in Graph Databases do blog do Neo4J
• Wikipédia: Entity-Relationship Model
• Minhas próprias lembranças
• Fonte desse artigo: MayogaX Dev Blog