Manipulação de Dados no Modelo Orientado a Grafos com
Neo4J
Ronaldo Carmargos Freitas, Marcos Alberto Lopes da Silva
Instituto de Informática – Centro Universitário do Triângulo (UNITRI) Caixa Postal 309 – 38.411-106 – Uberlândia – MG – Brasil
ronaldocf1721@yahoo.com.br, malopes21@gmail.com
Resumo. Diversas empresas estão adotando formas alternativas para
manipulação dos dados, pois cada vez mais estão necessitando de mais performance em suas aplicações, devido a esta necessidade surgiu o movimento NoSql, que vem ganhando força. O objetivo deste artigo acadêmico será expor seus principais modelos, suas principais vantagens, abordar o modelo orientado a grafos utilizando o SGBD (Sistema de Gerenciamento de Banco de Dados) Neo4J, contextualizar o grafo, explorar o SGBD teoricamente e desenvolver um estudo de caso para ilustrar seus recursos, será disponibilizado fragmentos do código para melhor compreensão.
1. Introdução
O movimento NoSql tem ganhado força nos últimos anos, pois foi identificado a necessidade de utilizar formas alternativas para tratar persistência de dados (armazenamento de dados), visto ter uma grande demanda em relação a performance (desempenho) e escalabilidade pelas aplicações.
Com este movimento deu origem a modelos, que foram utilizados para desenvolvimento de ferramentas alternativas, possibilitando a criação dos SGBDs NoSql, que está propiciando algumas vantagens, visando uma melhor solução a persistência de dados em cenários específicos. Dentre os vários modelos NoSql, pode-se citar o modelo orientado a grafos, neste modelo se enquadra o SGBD Neo4J, ferramenta que será utilizada para o estudo de caso.
Este artigo acadêmico tem como objetivo contextualizar o movimento NoSql, seus modelos e suas vantagens, posteriormente explorar o SGBD Neo4J, demonstrar suas funcionalidades, propor um estudo de caso para ilustrar seus recursos. Serão expostas configurações necessárias para a criação do banco de dados e fragmentos de código para melhor compreensão da ferramenta.
2. Movimento NoSql
Antes de compreender o modelo orientado a grafos, deve-se compreender sua origem, que se deu através do movimento denominado NoSql abreviação de Not Only SQL (não apenas SQL). O movimento NoSql teve inicio em 1998 por Carlo Strozzi, que inicialmente sugeriu denominar como NoREL, pois o movimento daria origem a um banco de dados de código aberto sem a interface SQL. O movimento foi criado sem a intenção de substituir o modelo relacional como um todo, mas suprir as necessidades que o modelo relacional não estava sendo tão eficaz, devido ao grande volume de dados que estava em crescimento constante necessitando cada vez mais recursos das aplicações por performance, e na demanda por escalabilidade que se torna cada vez
mais frequente. Com o movimento NoSql foram desenvolvidos sistemas com fatores que propiciam a escalabilidade, alta performance, replicação de dados, disponibilidade, livre de esquemas (estrutura do banco de dados) [Brito 2014].
O movimento NoSql ganhou força em 2004 com a empresa Google, que criou uma das primeiras implementações de um grande sistema para solução realmente não relacional, denominado de BigTable, um banco de dados orientado a colunas, cujo objetivo era promover maior disponibilidade e escalabilidade, um sistema de alta performance. Em 2007 surgiu o sistema DynamoDB, um banco de dados orientado a par chave e valor criado pela Amazon Web Services com a característica de ter alta disponibilidade, e com arquitetura não relacional, utilizado pela própria Amazon em seus web services [Brito 2014].
No ano de 2008 surgiu o sistema Cassandra, um banco de dados orientado a colunas, criado pelo Facebook para suportar o grande volume de dados, um sistema de banco de dados distribuídos portador de alta disponibilidade. Em 2009 surgiu o sistema MongoDB, um banco de dados orientado a documentos, projetado para ser altamente escalável, livre de esquemas, com alta performance. Em 2010 surgiu o sistema CouchDB, um banco de dados orientado a documentos, livre de esquemas [Brito 2014, NoSql 2011].
Visto anteriormente que o movimento NoSql foi adotado por para suprir suas necessidades de aplicações, principalmente em performance, resultando em ferramentas poderosas de manipulação de dados que atendem a diversas formas de implementação.
2.1. Vantagens obtidas por SGBDs NoSql
Nesta subseção serão abordadas as principais vantagens obtidas pelos SGBDs NoSql, estes sistemas promovem alta disponibilidade e melhor escalabilidade, a maioria dos modelos são livres de esquemas, e possuem mecanismo para replicação de dados.
Escalabilidade: característica que consiste na capacidade de atender as demandas sem perder as qualidades que lhe agregam valor, ou seja, suportar um crescente volume de dados constante sem afetar a disponibilidade das informações. Ressaltando que pode ser escalabilidade horizontal que consiste em incluir mais maquinas ao cluster (número de terminais, dispositivos ou posições de memória agrupadas em um local trabalhando para o mesmo objetivo), ou escalabilidade vertical que consiste em melhorar o hardware já existente, ou seja, acrescentar mais memórias ou disco rígido. Para um melhor entendimento da forma que os SGBDs NoSql tratam a escalabilidade, pode utilizar o teorema de CAP (Consistency, Availability, Partition Tolerance), apresentado pelo norte americano Eric Brewer no ano 2000, através do teorema CAP prova que é possível implementar somente duas das três características em qualquer sistema distribuído, sendo as características [Lobo 2013]:
1. Consistência: característica que garante a integridade dos dados após a
transação, garantindo a mesma informação a todos os nós (servidores) do sistema;
2. Disponibilidade: característica que garante que todas as requisições
solicitadas ao sistema terão um retorno; e
3. Tolerância a falhas: característica que garante o funcionamento do
sistema, impedindo que o mesmo pare de funcionar, sempre estará em funcionamento mesmo que um de seus nós estejam com problemas [Lobo 2013].
Mas muitos SGBDs NoSql estão ignorando momentaneamente as características da consistência, com isso criando outro padrão, denominado de BASE (Basically
Avaliable, Soft State, Eventually Consistent), que seria uma forma alternativa do
padrão ACID (Atomicity, Consistency, Isolation, Durability). No padrão ACID a consistência é forçada a cada transação, porém no BASE, a inconsistência é aceitável em determinados momentos, alcançando a disponibilidade através do tratamento de falhas, garantindo que uma falha local não se ampliará para o restante do sistema, caso uma máquina pare de funcionar, existiram outras garantindo a disponibilidade do sistema para que o mesmo não pare de funcionar totalmente [Farias 2011, Brito 2014, Lobo 2013]; e
Disponibilidade: consiste na capacidade de garantir que o sistema esteja sempre online, sempre estará disponível para atender as requisições, ressaltando que esteja dentro do prazo estabelecido por seus desenvolvedores; e
Livre de Esquemas: a maioria dos SGBDs NoSql é livre de esquemas, este fator implica diretamente na manipulação dos dados, pois não há necessidade de determinar o tipo do dado (inteiro, float, decimal, string) durante as operações, normalmente quando é feito a inclusão de um registro no SGBD é incluso uma chave e vinculado um valor a mesma, esta que pode ser de qualquer tipo, string ou binário. Um modelo NoSql que se enquadra neste tipo de orientação é denominado de par chave/valor. Seguindo esta característica de ser livre de esquema nota-se que na maioria das implementações para os SGBDs NoSql o responsável por definir o tipo de dado, tamanho e regras de validações é o sistema, diferente dos SGBDs relacionais que são responsáveis por definir o tipo de dado, tamanho e regras de validação [Farias 2011, Lobo 2013]; e
Replicação de dados: Replicação de dados consiste em fazer cópia dos dados contidos em um determinado banco de dados e replicar para outros bancos de dados, executando este processo aumenta o nível de recuperação de dados. Podem ser aplicados dois tipos de replicação:
1. Multi – Máster: ocorre quando aumentamos o numero de banco de
dados principais (Master), neste processo tem um Master que serve de referência para os outros Masters, o principal coleta as informações dos demais, permitido uma melhor recuperação de falhas; e
2. Máster – Slave: ocorre quando um banco de dados principal (Master)
faz replicação em bancos secundários (Slave), todas as escritas executadas no Master são replicados ao Slave, este processo se faz necessário para ganhar melhor desempenho da leitura, pois distribui a carga das operações de consultas entre os Slave [Farias 2011].
2.2. Modelos NoSql
Nesta subseção serão abordados os principais modelos NoSql e suas características. Os modelos abordados serão os orientados a par chave/valor, colunas, documentos e grafo. Atualmente existem vários modelos que não serão abordados neste trabalho acadêmico, dentre eles, os modelos orientados à: Multi-Modelos, Objetos, XML, Multidimensionais, MultiValor, entre outros [NoSql 2011].
Chave/Valor: O modelo orientado a par chave/valor é considerado o mais simples, este modelo utiliza uma chave única e faz associação a um valor numérico. O processo de consulta consiste em repassar ao SGBD a chave, posteriormente o mesmo irá repassar a uma função que transformará a chave em
um valor numérico que representa a posição do endereçamento de memória onde o dado está localizado. O SGBD utiliza apenas a chave identificadora para as consultas que são feitas através de uma tabela hash, sem a necessidade de otimização de consultas, pois utiliza a chave identificadora (única) passando para a função transformadora que normalmente é um algoritmo rápido na execução do processo. Alguns dos SGBDs que foram implementados neste modelo destaca se: Redis, Memcached, SimpleDB e Infinispan, também existe o DynamoDB utilizado pela rede social Formspring. Na Figura 1 nota-se a representação do processo de consulta do modelo par chave/valor, primeiramente tem se a chave identificadora “pessoa”, depois faz uso da função transformadora que irá converter a chave em um endereço de armazenamento onde está localizado o dado (Farias 2011, Lobo 2013);
Figura 1. Processo de consulta do Modelo Chave/Valor.
Colunas: O modelo orientado a colunas é um pouco mais complexo que o baseado em par chave/valor, neste modelo os dados são indexados por linha, coluna e timestamp, as linhas e colunas são identificadas por chaves, e o timestamp é responsável por diferenciar as versões do mesmo dado, uma característica particular deste modelo é o agrupamento de dados que contenham o mesmo valor, esses são guardados em outra coluna denominando super coluna. Este modelo permite particionar os dados, distribuindo os dados através de vários servidores. Neste modelo destacam o SGBD BigTable utilizado pela Google, e o Cassandra utilizado pela rede social Facebook [Farias 2011];
Documental: O modelo orientado a documentos trabalha com uma coleção de objeto, com objetivo de agrupar as informações com mesma categoria, possui uma identificação única, neste modelo o que seria um registro é tratado como um documento que contém um conjunto de atributos que na grande maioria e representado no formato JSON (JavaScript Object Notation), estes atributos podem ser documentos aninhados, strings ou listas. Neste modelo as consultas são mais similares ao modelo relacional podendo ser escritas de modo declarativas conforme é feito na linguagem SQL. Os SGBD mais conhecidos são o MongoDB e CouchDB. Na Figura 2 nota-se a representação de um documento no formato JSON utilizado pelo modelo orientado a documentos [Lobo 2013]; e {id: 30 Nome:“notebook”, Tipo:”computador”, Memoria:”8GB”, Alocador:{Tipo:”Funcionário”, Código:”1234” }}
Figura 2. Representação de um documento no formato JSON. pessoa
pessoa
Transforma
Transforma 111000101111000101 LocalizaLocaliza
Nome:Ronaldo Idade:25 Nome:Ronaldo Idade:25
Grafos: O modelo orientado a grafos tem uma estrutura focada no relacionamento entre objetos (entidades), esta modelagem se torna necessária quando há relacionamento entre dois objetos ou mais, a persistência dos dados neste modelo é feita através do grafo, estrutura utilizada para armazenar e manipular os dados e realizar consultas. Um grafo é composto por duas partes (vértice e aresta), o vértice representa as entidades, e a aresta representa o relacionamento existente entre as entidades. Os SGBDs mais destacados neste modelo são OrientDB, e Neo4J. Observando a Figura 3, nota-se a representação de um grafo composto por duas entidades e um relacionamento [Farias 2011, Lobo 2013].
Figura 3. Representação de um Grafo.
3. Neo4J: Modelo Baseado em Grafos
Antes de explanar o SGDB orientado à grafos, e consequentemente, o banco de dados Neo4J, deve-se entender o surgimento da teoria dos grafos que serviu de inspiração para o modelo orientado à grafos, logo abaixo será descrito como surgiu a teoria do grafo.
A teoria de grafos surgiu em 1736, desenvolvida pelo matemático suíço Leonhard Euler, que abstraiu um problema de sua época transformando em um grafo, denominando Pontes de Königsberg. O problema consistia em fazer um trajeto para percorrer todo o percurso composto por sete pontes, passando somente uma vez por cada ponte. Euler desenvolveu a teoria e provou que não seria possível percorrer todo o trajeto passando apenas uma única vez por cada ponte, fez uso de um diagrama no qual associava os vértices e arestas, possivelmente criando o primeiro grafo [Oswaldo, e Jurkiewicz (2009)].
Este conceito pode ser utilizado na criação de modelos para a resolução de problemas identificados na criação de diversos sistemas, como sistemas geoespaciais, sistemas de recomendação, rede social, processos de logística e processos industriais, vide Figura 4, a representação do grafo Euleriano [Neo4J Case (2015)].
Figura 4. Representação do Grafo Euleriano. Vértice
Vértice VérticeVértice
Aresta Aresta
Para um melhor esclarecimento da aplicabilidade de um grafo, observe a Figura 5, onde é demonstrado um relacionamento de uma família, integrada por três pessoas (pai, mãe, filho). Através da Figura 5 nota-se que Tiago é filho de Paulo e Sara, e Sara é casada com Paulo que também tem a mesma ligação do casamento. Ao observar, nota que em sua aresta informa o tipo de relacionamento e o tempo que se conhecem, pois o grafo também pode ter atributos em sua aresta, e nos vértices tem os atributos que identificam as pessoas através do nome.
Figura 5. Representação gráfica familiar.
O modelo de grafos tem algumas características, dentre elas se destacam como principais, conter vértice e aresta. Os vértices representam as entidades e contém propriedade (atributos), arestas representam os relacionamentos entre os vértices, as arestas também podem ter atributos. Nota-se que o modelo de grafos é de fácil entendimento e bastante intuitivo [Neo4J 2014].
3. 1. Neo4J
Neo4J é um banco de dados orientado à grafo, foi desenvolvido pela empresa Neo Technology, atualmente está na versão 2.2.1, disponibiliza duas versões, a versão
Enterprise Edition direcionada para o ambiente empresarial, disponibilizando suporte a
ferramenta, esta versão é paga, a outra versão é a Community Edition direcionada a aprendizagem, não disponibiliza suporte, esta versão não é paga. Neo4J se trata de uma ferramenta com alta performance de cache, backups em tempo real, escalonamento horizontal, open source. Os dados são gravados no disco com uma estrutura otimizada para uma rede de grafo, é compatível com as transações ACID, desenvolvido em Java, portador de algoritmos tradicionais para grafo, por exemplo o de caminho mais curto, o de todos os caminhos, o algoritmo de Dijkstra [Neo4J 2015, Hunger 2010].
Neo4J é portador de uma gama de ferramentas que auxiliam no desenvolvimento de aplicações. Sua API possibilita a comunicação com diversas linguagens de programação, dentre elas, Ruby, Scala, PHP, Goovy, Phyton. Também faz uso de algumas ferramentas para otimizar os processos [Neo4J 2015, Hunger 2010], dentre elas:
Neoclipse: Neoclipse se trata de um plugin utilizado na IDE Eclipse, este proporcia uma interface visual para navegação dos grafos;
Online Backup: Online Backup possibilita executar uma cópia de uma instância do banco Neo4J, mesmo que esteja em execução;
Shell: Shell é utilizado para interpretar os comandos de navegação escritos na linguagem Cypher, e manipulação dos grafos.
Neo4J disponibiliza uma API REST (Representational State Transfer), que possibilita utilizá-lo como servidor viabilizando a transmissão de dados e transações via protocolo HTTP (Hypertext Transfer Protocol), esta API REST do Neo4J trabalha com
Tiago Tiago Sara
Sara MãeMãe Pai Pai PauloPaulo
Cônjuge, 32 anos
a notação JSON para troca e representação dos dados, a cada solicitação HTTP pode incluir uma lista de declarações com solicitação de inicialização ou confirmação para as transações. Também possibilita utilizar as bibliotecas do Neo4J na aplicação criando uma instância do banco de dados embarcada [Neo4j 2015].
Neo4J utiliza para o desenvolvimento de consultas algumas linguagens específicas, dentre elas destaca a Gremlin considerada como uma linguagem para grafo de baixo nível, pois utiliza uma sintaxe compacta e expressiva, se tornando de difícil entendimento. Como melhoria para o Neo4J, foi lançado a linguagem Cypher, para possibilitar consultas declarativas e textuais, mais semelhante ao SQL, e possibilita criar cláusulas, como filtros, operações, agregação [Neo4j 2015]. As principais cláusulas da linguagem Cypher são:
Where: Define os critérios (filtro);
Create: Executa a criação de nós, propriedades e relacionamentos; Remove: Executa a remoção de nós, propriedades e relacionamentos; Match: Define as combinações do grafo;
Return: Define os elementos do resultado da consulta; e Set: Define os valores para as propriedades.
Outra forma de manipulação de dados utilizada no Neo4J é denominada
Traversal API, pode ser implementada em Java, proporcionando a navegação entre as
relações dos nós do grafo, obedecendo a um conjunto de restrições que permite navegar entre os nós do grafo, restrições que são definidas pelo desenvolvedor, podendo ser pelo tipo de relacionamentos existente no grafo.
4. Estudo de Caso: Usina Hidrelétrica no Brasil
Com o objetivo de exemplificar e demonstrar na prática o desenvolvimento de aplicações fazendo uso dos recursos proporcionados pela ferramenta Neo4J, nesta seção será utilizado a relação de usinas hidrelétricas existentes no país (Brasil) fazendo uso de dados fictícios, será desenvolvido uma aplicação para demonstrar a manipulação dos dados fazendo uso das principais operações, e disponibilizando fragmentos do código para propiciar um melhor entendimento da mesma, a ideia do estudo de caso envolvendo usinas hidrelétricas surgiu de uma palestra [Tavante, 2015].
4.1. Ferramentas utilizadas no desenvolvimento da aplicação
Para o ambiente de desenvolvimento da aplicação foi utilizado o sistema operacional
Windows 7 Ultimate, para programação a linguagem Java utilizando a IDE Eclipse,
para o banco de dados o SGBD Neo4j Community.
Utilizado a linguagem Cypher para manipulação dos dados e consultas, e para visualização do banco de dados será utilizado o próprio servidor de aplicação fornecido pela instalação do Neo4j Community (Figura 6).
Para download das ferramentas (Tabela 1).
Tabela 1. Ferramentas para desenvolvimento do estudo de caso.
Eclipse Luna Luna
Release http://www.eclipse.org/downloads/download.php?file/technology/epp/downloads/release/luna/SR2/eclipse-= java-luna-SR2-win32.zip Java 8 http://www.java.com/pt_BR/ Neo4j Community Release 2.2.1 http://neo4j.com/download-thanks/? edition=community&flavour=windows&release= 2.2.1&_ga=1.181722151.1498330026.1432395222 4.2. Desenvolvimento da aplicação
Logo após fazer a instalação do SGBD Neo4j Community de forma correta, o serviço do mesmo pode ser iniciado, e criado o banco de dados pelo seu próprio servidor de aplicação conforme consta na Figura 6, que também possibilita a manipulação dos dados, desde a criação (nós, relacionamentos), alteração dos dados e execução de consultas através da linguagem Cypher, vide Figura 8.
O Neo4j Community possibilita informar o caminho do banco de dados a ser criado, ao clicar no botão Start é feito a criação do banco de dados e iniciado o serviço do SGBD, no momento que ocorre a inicialização do serviço e verificado a existência do banco de dados no diretório informado, caso não exista banco de dados é criado um novo, caso exista a aplicação irá fazer uso do mesmo, para acessar o servidor da aplicação basta clicar no link http://localhost:7474/ ou acessar via browser.
Figura 6. Inicialização do banco de dados Neo4J.
Com o Neo4J instalado corretamente é possivel desenvolver o projeto na IDE Eclipse para a manipulação dos dados do banco, pois disponibiliza as bibliotecas para integrar ao projeto. Com o projeto devidamente criado pode ser incorporado ao mesmo as bibliotecas do Neo4J atavés do build path. Conforme consta na Figura 7, inicialmente é declarado a variavel Neo4J_DBPath a qual é atribuído o caminho do banco de dados, posteriormente é criado o método criarBancoDados que instancia a variavel
graphDataService do tipo GraphDatabaseService da classe GraphDatabaseFactory que
faz uso do método newEmbeddedDatabase(Path), este recebe o diretorio para criação do banco de dados caso não exista, caso exista faz uso da instância do mesmo.
private static final String Neo4J_DBPath =
"/Users/RONALDOCF/Downloads/neo4j-community-2.2.1/db";
void criarBancoDados() {
newEmbeddedDatabase(Neo4J_DBPath); }
Figura 7. Criação do banco de dados em Java.
Na Figura 8 é demonstrado o método inserirDadosCypher, este é responsável pela criação de nós e relacionamentos no banco de dados para este estudo de caso, foi utilizado a linguagem Cypher, nota-se que inicialmente é declarado a variável
transaction do tipo Transaction, que faz a chamada do método beginTx que pertence a
classe GraphDatabaseService, este possibilita abrir a transação, logo após é utilizado o método execute que deriva da mesma classe GraphDatabaseService, é permite executar comandos utilizando Cypher.
Para exemplo, pode-se observar a criação de 2 nós rotulados de “Pais” que tem a propriedade Nome, e outros nós rotulados de Estado, Usina, Cidade e ambos tem suas propriedades definidas, após a criação dos nós é feito a criação dos relacionamentos, nos quais é possível definir a direção do relacionamento, por exemplo o primeiro relacionamento é entre os nós rotulados de Estado com a propriedade Nome: “Pará” e “Pais” com propriedade Nome: “Brasil”, observe que o relacionamento do tipo Pertence tem a direção no sentido do Estado para Pais, e todos os nós e relacionamentos permitem um alias (apelido).
Ao final é informado ao usuário que os dados foram inseridos, e feito o uso dos métodos transaction.success(), transaction.close(), que permite finalizar a transação garantindo que a mesma seja salva no banco de dados e encerrar a transação corrente.
private void inserirDadosCypher() {
Transaction transaction = graphDataService.beginTx(); try { graphDataService
.execute("create (br:Pais {Nome:'Brasil'})"
+ "create (pa:Pais {Nome:'Paraguai'})" + "create (es:Estado {Nome:'Pará'})" + "create (et:Estado {Nome:'Paraná'})"
+ "create (ef:Estado {Nome:'São Paulo'})"
+ "create (a:Usina {Nome:'Usina Hidrelétrica de "+ "Itaipu',ProducaoMW:14000,Rio:'Rio
Paraná',Status:'Ativa'})"
+ "create (b:Usina {Nome:'Usina Hidrelétrica de Belo "+
"Monte',ProducaoMW:11233,Rio:'RioXingú',Status:'Ativa'})"
+ "create (c:Usina {Nome:'Usina Hidrelétrica de "+ "Tucuruí',ProducaoMW:8370,Rio:'Rio
Tocantins',Status:'Ativa'})"
+ "create (d:Usina {Nome:'Usina Hidrelétrica de Ilha" + "Solteira',ProducaoMW:3444,Rio:'Rio
Paraná',Status:'Ativa'})"
+ "create (e:Cidade {Nome:'Santa Terezinha de "+ "Itaipu',ConsumoMW:900,Populacao:20834})"
+ "create (f:Cidade {Nome:'São Miguel do "+ "Iguaçu',ConsumoMW:1130,Populacao:26570})"
+ "create (g:Cidade {Nome:'Altamira',ConsumoMW:2100,Populacao:106768})"
+ "create (h:Cidade {Nome:'Belém',ConsumoMW:3650,Populacao:1432844})"
+ "create (i:Cidade {Nome:'São Paulo',ConsumoMW:4800,Populacao:44035304})"
(es)-[aa:Pertence]->(br)" + "create (et)-[bb:Pertence]->(br)" + "create (ef)-[xx:Pertence]->(br)" + "create (a)-[rr:Pertence]->(pa)" + "create (a)-[l:Pertence]->(et)" + "create (b)-[m:Pertence]->(es)" + "create (c)-[n:Pertence]->(es)" + "create (d)-[o:Pertence]->(ef)" + "create (e)-[p:Pertence]->(et)" + "create (e)-[q:Utiliza{DistanciaKM:'33,6'}]->(a)" + "create (f)-[r:Pertence]->(et)" + "create (f)-[s:Utiliza{DistanciaKM:'52,7'}]->(a)" + "create (g)-[t:Pertence]->(es)" + "create (g)-[u:Utiliza{DistanciaKM:'0'}]->(b)" + "create (h)-[v:Pertence]->(es)" + "create (h)-[x:Utiliza{DistanciaKM:'445'}]->(c)" + "create (i)-[y:Pertence]->(ef)" + "create (i)-[w:Utiliza{DistanciaKM:'668'}]->(d)");
System.out.println("Dados inseridos utilizando Cypher"); transaction.success(); }
finally { transaction.close(); }}
Figura 8. Inserção de dados (nós), e relacionamentos, utilizando Cypher.
Após finalizar as transações com a instância do banco de dados é aconselhado fazer o encerramento da conexão com o mesmo, observe na Figura 9 que demonstra através do método encerrarConexao, neste método faz o uso da classe
GraphDatabaseService utilizando o método shutdown(), que é responsável pelo
encerramento da conexão, e posteriormente emite uma mensagem ao usuário avisando que a conexão foi encerrada.
void encerrarConexao() {
graphDataService.shutdown(); System.out.println("Encerrado conexão com Banco de dados");}
Figura 9. Encerrar conexão com banco de dados Neo4J.
Conforme citado anteriormente o Neo4J disponibiliza o servidor de aplicação (Figura 10), após ter criado o banco de dados e inserido dados, foi executado a consulta
match n return n, está consulta é responsável por retornar todos os dados do banco, na
Figura 10. Ilustração de parte dos dados, incluso no banco de dados.
Para fazer a exclusão de um nó e de seu relacionamento, observe na Figura 11, o método removerDadosCypher, neste método inicialmente é aberto a transação, posteriormente é feito o uso do método execute, passado a query (MATCH (n:Pais {Nome:'Paraguai'})-[r]-() DELETE n, r), note que esta query localiza o nó rotulado como Pais com a propriedade Nome: “Paraguai”, localiza o relacionamento vinculado ao nó, e posteriormente deleta o nó e seu relacionamento, depois emite mensagem para o usuário informando da exclusão e encerra a transação, nesta query não foi passado direção para o relacionamento, visto que a intenção é fazer a exclusão do nó e todos os relacionamentos vinculados ao mesmo.
private void removerDadosCypher() {
Transaction transaction = graphDataService.beginTx();
try {
graphDataService.execute("MATCH (n:Pais {Nome:'Paraguai'" +"})-[r]-() DELETE n, r"); System.out.println("Removendo Dados utilizando Cypher"); transaction.success(); } finally { transaction.close(); } }
Figura 11. Removendo nó e relacionamento no banco de dados Neo4J.
Imaginando que uma usina foi desativada, através da Figura 12 nota-se que o método alterarDadosCypher, inicialmente abre a transação, posteriormente executar a
query (match n where (n.Nome='Usina Hidrelétrica de Belo Monte') set n.Status =
'Desativada') que é responsável por localizar o nó com a propriedade Nome = “Usina Hidrelétrica de Belo Monte” e alterar a propriedade Status para Desativada, note que foi
utilizado a cláusula where para filtrar o nó desejado, posteriormente é emitido a mensagem para o usuário informando que houve alterações, e finaliza a transação. private void alterarDadosCypher() {
Transaction transaction = graphDataService.beginTx();
try {
graphDataService.execute("match n where (n.Nome='Usina Hidrelétrica" +" de Belo Monte') set n.Status = 'Desativada'"); System.out.println("Alterando Dados utilizando Cypher"); transaction.success(); } finally { transaction.close(); } }
Figura 12. Alterando propriedade do nó no banco de dados Neo4J.
Anteriormente, foi informado que a usina Usina Hidrelétrica de Belo Monte foi desativada, neste caso é necessário saber qual a usina mais próxima ativa para suprir a demanda da atual desativada, através da Figura 13 nota-se o método consultaDadosCypher, que inicialmente abre a transação, logo após faz o uso do método execute(), o resultado da query é gravado na variável do tipo ExecutionResult e posteriormente é feito um laço para mostrar os dados da consulta, e depois é finalizado a transação. O resultado da consulta foi (Usina: “Usina Hidrelétrica de Tucuruí”; Estado: “Pará”;). A query inicialmente localiza os nós rotulados de Estado e Usina com Status
(Ativa e Desativada), na cláusula where filtra os nós percorrendo através de seus relacionamentos, depois retorna o nome da Usina (Ativa) e do estado, utilizando alias.
private void consultaDadosCypher() {
Transaction transaction = graphDataService.beginTx(); try {
Result result = graphDataService. execute("match(u:Usina{Status:'Ativa'}), (e:Estado),(us:Usina{Status:'Desativada'})"
+ "where(us)-[]->(e)<-[]-(u) return u.Nome as Usina,e.Nome as Estado"); while (result.hasNext()) {
Map<String, Object> row = result.next();
for (Entry<String, Object> column : row.entrySet()) { System.out.println(column.getKey() + ": " + column.getValue() + "; "); } } transaction.success(); } finally { transaction.close(); } }
Figura 13. Query para retornar Usina ativa, que esteja dentro do estado que contenha alguma desativada.
5. Conclusão
Diante das informações contextualizadas neste artigo acadêmico, conforme consta nos textos referenciados, nota-se que o movimento NoSql ganhou força pois proporciona alta performance e escalabilidade, e promove novos modelos de dados, em alguns casos disponibiliza melhor flexibilidade para o desenvolvimento de aplicação por ser livre de esquema.
O Neo4J é um SGBD que possui API para integração com várias linguagens de programação, propiciando ao desenvolvedor fazer escolha de qual linguagem lhe atende melhor, em Java possibilita a criação de aplicações incorporando as bibliotecas do Neo4J para desenvolvimento de forma embarcada, e caso tenha a necessidade de desenvolver uma aplicação cliente/servidor é disponibilizada a API REST, que pode ser utilizada para trafegar os dados via HTTP fazendo uso da notação JSON.
Para as consultas e manipulação dos dados o Neo4J dispõe da linguagem
Cypher que pode ser executada em Java fazendo o uso das classes do Neo4J, e
utilizando o servidor de aplicação para visualização gráfica dos dados. Também pode fazer o uso da linguagem de consulta Traversal API, que pode ser implementada em Java.
A linguagem Cypher é de fácil compreensão, se assemelha ao SQL, dentre os modelos citados acima é utilizada apenas em grafos, disponibilizada somente para o SGBD Neo4J. A documentação (manual) disponibilizada através do site do Neo4J é de fácil compreensão para uso da mesma, contém exemplos da utilização dos comandos e formas de implementar, em alguns exemplos o site disponibiliza a execução dos scripts no mesmo e permite a visualização da representação gráfica, disponibilizando o aprendizado sem a dependência de instalação da ferramenta.
Uma característica que pode ser citada como desvantagem é o controle da instância do SGBD, ao fazer uso da implementação de forma embarcada não é possível conexão simultânea com a instância do banco de dados, para uma conexão ao banco de dados é necessária à verificação de conexões pendentes por parte de outra aplicação e caso exista e necessário encerrá-las.
Ao decorrer do desenvolvimento do trabalho acadêmico foi encontrado dificuldade em obter informações de confiança que estivesse com conteúdo mais atual e no idioma Português.
Para sugestão de trabalhos futuros, pode ser desenvolvido um estudo com foco na criação de uma aplicação fazendo o uso da linguagem Traversal API ou explorar a linguagem Gremlin, e utilizando a API REST, para manipular os dados em um ambiente cliente/servidor.
6. Referencias Bibliográficas
Brito, Ricardo (2014), Banco de dados NoSql x SGBDs Relacionais: Analise Comparativa. Disponível em: <http://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdf>. Acesso em: 1 ago. 2014.
Farias, Bernadette; Rodrigues, Hélio; César, Jonas (2011), NoSql no desenvolvimento
<http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdf>. Acesso em: 1 ago. 2014.
Hunger, Michael (2010), Neo4j - Base de dados NoSQL baseada em Java. Disponível em: <http://www.infoq.com/br/news/2010/03/neo4j-10>. Acesso em: 10 set. 2014. Lobo, Henrique (2013), Entendendo NoSql, Sql Magazine, edição 111.
Neo4J Case (2015), Use Cases. Disponível em: < http://neo4j.com/use-cases/>. Acesso em: 10 jan. 2015.
Neo4J (2014), Graph Concepts. Disponível em: <http://neo4j.com/guides/graph-concepts/>. Acesso em: 9 set. 2014.
Neo4J (2015), The Neo4j Manual v2.2.1. Disponível em: <http://neo4j.com/docs/2.2.1/>. Acesso em: 23 abr. 2015.
NoSql (2011), Your Ultimente Guide to the Non-Relational Universe. Disponível em: < http://nosql-database.org/ >. Acesso em: 1 ago. 2014.
Oswaldo, Paulo e Jurkiewicz, Samuel (2009), Grafos. Introdução e Prática, edição 1, editora Edgard Blucher.
Tavante, Hanneli (2015), Neo4j - sua vida com grafos!. Disponível em: <http://www.infoq.com/br/presentations/neo4j-sua-vida-com-grafos?
utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedCont ent_news_clk>. Acesso em: 23 abr. 2015.
