Um estudo comparativo entre Bancos de Dados Relacionais e Bancos de Dados NoSQL Orientados a Grafos

Prévia do material em texto

Um Estudo Comparativo entre Bancos 
de Dados Relacionais e Bancos de Dados 
NoSQL Orientados a Grafos. 
 Publicado em 12 de dezembro de 2017 
 
Joyce Lima 
Analista de Sistemas na Empresa Sendas Comércio Exterior e Armazéns 
Gerais S.A 
Joyce S. Aquino 
Bacharelado em Ciências da Computação - Centro Universitário Augusto Motta 
(UNISUAM). 
Avenida Paris, Nº 72 – Bonsucesso, Rio de Janeiro – RJ – Brasil. 
joycesaquino@gmail.com 
 Abstract. The constant evolution of applications related to Web environment, the 
growth of heterogeneous data and the need to handle interconnected data providing high 
performance brings a new challenge to the relational environment, the rigid model 
prevents some solutions and the need increasingly constant provide results to the 
market, highlights a new paradigm when it comes to databases. Faced with the need, the 
still emerging concept NoSLQ databases is driven and has matured every day providing 
solutions and becoming increasingly present in large enterprises. This article it is a 
comparative study between relational databases and NoSQL databases oriented graphs, 
bringing aspects of modeling, and giving the advantages and disadvantages between the 
two models. 
 
Resumo. A evolução constante de aplicações voltadas para o ambiente Web, o 
crescimento de dados heterogêneos e a necessidade de se tratar dados interconectados 
provendo altas performances traz um novo desafio para o ambiente relacional, o modelo 
rígido inviabiliza algumas soluções e a necessidade cada vez mais constante em prover 
resultado para o mercado, evidência um novo paradigma no que se trata de bancos de 
dados. Diante da necessidade o conceito ainda emergente de bancos de dados NoSLQ é 
impulsionado e vem amadurecendo a cada dia provendo soluções e se tornando cada 
vez mais presente em grandes empresas. Esse artigo trata-se de um estudo comparativo 
entre bancos de dados relacionais e bancos de dados NoSQL orientado a grafos, 
trazendo aspectos de modelagem, e expondo as vantagens e desvantagens entre os dois 
modelos. 
1. Introdução 
 Com o decorrer dos anos enfrentamos um crescimento considerável no número de 
aplicações e recursos voltados para sistemas computacionais, consequentemente o 
volume de dados provenientes de tais sistemas apresentou um ritmo de crescimento 
exponencial se tornando uma preocupação e gerando novos paradigmas no mercado de 
tecnologia. 
Quando falamos em armazenamento e manipulação de dados, o uso de banco de dados 
relacionais se tornou um ponto focal no mercado, porém com o dinamismo das 
informações e a complexidade das soluções impostas pelo mercado, o ambiente 
relacional, dado aos seus esquemas estáticos e inflexíveis tem se tornado ineficiente 
inviabilizando soluções de alta complexidade, principalmente em casos que existe a 
necessidade de manipulação de dados heterogêneos e seu armazenamento de diversas 
formas. 
De maneira geral um dos principais problemas de bancos de dados relacionais está 
diretamente associado a dificuldade em conciliar o modelo rígido com a crescente 
demanda de escalabilidade, porém tendo visto que no cenário atual os dados crescem 
substancialmente em pouco tempo e o número de usuários não para de aumentar a cada 
dia a escalabilidade e processamento se torna um ponto indispensável para o 
armazenamento e manipulação de dados. 
É neste ponto que entra em cena o conceito de bancos de dados NoSQL “que é 
completamente distinto do modelo relacional, portanto, deveria ser mais 
apropriadamente chamado "NoREL" ou algo que produzisse o mesmo efeito”. [5] 
O termo NoSQL significa “Not Only SQL – Não Somente SQL” e surgiu inicialmente 
no ano de 1998, usado por Carlo Strozzi para definir bancos de dados não relacionais. 
Em 2006, o artigo: BigTable: A Distributed Storage System for Structured Data, 
publicado pelo Google, trouxe novamente o conceito NoSQL à tona e novamente em 
2009 o termo foi re-introduzido por Eric Evans, quando Johan Oskarsson teve a 
intenção de organizar um evento para discutir bancos de dados de código aberto. De 
maneira mais simplista podemos considerar NoSQL como uma maneira de descrever o 
surgimento de um número crescente de banco de dados não relacionais, que em sua 
grande maioria não tem a preocupação de fornecer garantias ACID. 
2. Desenvolvimento 
 2.1 Banco de Dados NoSQL. 
Bancos de dados NoSQL foram criados na tentativa de resolver determinadas soluções 
em que banco de dados relacionais não apresentam total eficiência. Fatores como a 
rigidez e inflexibilidade do modelo relacional, a necessidade de processamento em larga 
escala e alta performance, deram força ao conceito de bancos de dados não relacionais 
que atualmente são apresentados como uma nova alternativa aos bancos de dados 
relacionais, que por muito tempo foi o único modelo aceito no mercado. 
No geral quando modelamos um banco de dados relacional, para que possamos 
assegurar a integridade dos dados é uma premissa que o banco de dados mantenha em 
suas transações quatro propriedades conhecidas pela sigla ACID, descritas a seguir: 
A (Atomicidade): todas as transações devem ser atômicas, ou seja, só podem ser 
consideradas efetivadas se executadas em sua totalidade, logo caso aconteça alguma 
falha no decorrer do processo significa que toda transação será invalidada. 
C (Consistência): tudo deve ser consistente desde o início até o final de determinada 
transação, caso a transação não aconteça o banco de dados garante a integridade dos 
dados retornando ao estado consistente anterior. 
I (Isolamento): as transações só podem acontecer de maneira isolada, nenhuma 
transação pode interferir em outra. 
D (Durabilidade): por último deve ser durável, uma vez que a transação foi concluída os 
dados consequentes da mesma não podem ser perdidos. 
O uso das propriedades ACID trouxe ao modelo relacional, segurança e eficiência, mas 
em contrapartida o tornou de certa forma inflexível pois este conjunto de propriedades é 
demasiadamente restritivo para ambientes de processamento distribuídos de grande 
porte e acaba inviabilizando soluções que necessitam de maior flexibilidade. 
Banco de dados NoSQL são mais flexíveis pois se baseiam em um grupo de 
propriedades denominadas BASE2, definidas a seguir: 
 BA (Basicamente Disponível): prioriza a disponibilidade dos dados 
 S (Estado Leve): o sistema não precisa estar consistente o tempo todo. 
 E (Eventualmente Consistente): é consistente em momento indeterminado. 
 As propriedades BASE de certa forma competem com as propriedades ACID e tornam 
os bancos de dados NoSQL mais recomendados para trabalhar com distribuição de 
processamento e suportar aplicações que contam com um grande volume de dados, 
como Big Data e BI por exemplo, e que por sua vez crescem de maneira significativa 
em pouco tempo como acontece em redes sociais. 
Levando em consideração o crescimento substancial de dados que temos nos dias atuais, 
é extremamente necessário investir na robustez do banco de dados, adicionando 
novas máquinas e distribuindo o processamento, o que chamamos de escalabilidade 
horizontal. Para bancos de dados relacionais a escalabilidade é um problema que não se 
resolve tão facilmente, pois, esse modelo se comporta bem somente usando 
escalabilidade vertical que consiste no aumento de memória e processamento dos 
servidores, o problema é que soluções do tipo além de possuírem alto custo tornam o 
banco dependente exclusivamente dos fornecedores de tecnologias em hardware. 
O uso da escalabilidade horizontal em bancos de dados relacionais se torna inviável pois 
o mesmo aumentaria consideravelmente o tempo de resposta do banco devido ao 
número de acessos a simultâneos das máquinas distribuídas, já os bancos de dados 
NoSQL tratam a questão da escalabilidade com mais facilidade devidoao seu modelo 
flexível e livre de esquemas além de em alguns casos já serem projetados para trabalhar 
com auto- particionamento, aumentando sua capacidade viabilizando seu uso em 
ambientes com grandes volumes de dados. 
Além de contar com propriedades mais flexíveis e serem mais escaláveis, bancos de 
dados NoSQL trabalham com processamento baseado em alguns frameworks como 
MapReduce que foi criado pela Google e é usado como solução para otimizar o 
processamento em larga escala. 
 “Esse modelo para computação distribuída consiste na especificação de uma função de 
mapeamento (map), que processa um conjunto de pares chave/valor e retorna um 
conjunto intermediário de pares chave/valor, e uma função de redução (reduce), que usa 
os conjuntos chave/valor retornados pela função de mapeamento para mesclar todos os 
valores intermediários que possuem a mesma chave disponibilizando assim um 
resultado para uma determinada consulta” [3] 
 Com o intuito de prover ao usuário fácil manipulação dos dados, bancos de dados 
NoSQL contam com APIs para diversas linguagens facilitando o uso de algoritmos para 
manipulação e busca dos dados, alguns bancos de dados NoSQL possuem suas próprias 
query languages geralmente de fácil interpretação assim como é o caso do Neo4J que é 
um banco de dados NoSQL orientado a grafos e o CassandraDB que usa o modelo de 
família de colunas. Os modelos de bancos de dados NoSQL são classificados em quatro 
categorias, chavevalor, os modelos orientados a documentos, os orientados a coluna, e 
os sistemas baseados em grafos conforme representação gráfica abaixo. 
 
 Figura 1. Representação gráfica do quadrante de bancos de dados NoSQL em suas 
estruturas de armazenamento de dados. Fonte: Graph Databases 2º Edição – O’Reilly 
 2.2 Chave-valor. 
 Os bancos de dados NoSQL que utilizam o modelo chave-valor são conhecidos por sua 
arquitetura simples. No geral, armazenam os dados em uma estrutura de tabela hash e 
usam a função hashing para o mapeamento, busca e exclusão de tais dados. 
Os dados são indexados por chaves, e cada chave está associada a um único valor o que 
possibilita uma rápida busca a partir das chaves. 
 
 Figura 2. Exemplo de estrutura dos dados salvos na arquitetura chave e valor. 
 Além do armazenamento simples, outra vantagem do modelo chave-valor é a fácil 
manipulação dos dados, onde comandos simples como get( ) e set( ) são utilizados para 
retornar e capturar os valores. 
 Um exemplo no mercado que podemos usar para o modelo chave-valor é o DynamoDB 
que foi desenvolvido pela Amazon e já possui uma vasta documentação em seu site 
oficial, facilitando para os profissionais que tem a intenção de utilizá-lo, além de possuir 
APIs para plataformas como JAVA, PHP, Ruby e outras linguagens. 
 O Dynamo é um modelo livre de esquemas logo se torna altamente flexível e conta 
com recursos como auto particionamento, escrita dos dados em disco e replicação de 
dados, mantendo assim a consistência e disponibilidade. 
 
 2.3 Banco de dados orientado a documentos. 
 
 Bancos de dados orientados a documentos trabalham com dados semi-estruturados, 
geralmente armazenados como uma coleção de documentos onde cada documento 
possui um identificador único parecido com a arquitetura do modelo chave-valor. Esse 
tipo de modelo é conhecido por ser livre de esquemas rígidos, o que os torna 
extremamente flexível a nível de armazenamento de dados com extensões diversas e sua 
manipulação. 
Como este modelo de dados é livre de esquemas e os documentos geralmente não 
possuem uma estrutura rígida, conseguimos facilmente adicionar novos campos em um 
único documento de uma coleção sem que seja necessário fazer nenhuma alteração nos 
demais documentos. O exemplo abaixo exibe a representação de uma coleção de 
documentos onde cada documento possui sua estrutura única apesar de fazerem parte da 
mesma coleção. 
 
 Figura 3. Exemplo de coleção de documentos com documentos com estruturas 
distintas 
Um exemplo de como poderíamos adicionar novos valores em um único documento 
dentro de uma coleção seria buscando o documento pelo seu ID e adicionando os 
campos e seus respectivos valores, conforme representado. 
 
 Figura 4. Pseudocódigo para adicionar novos valores em um documento buscando pelo 
ID 
Bancos de dados orientados a documentos são os mais maduros no contexto NoSQL e 
apesar de existirem outros, usaremos o MongoDB que conta com uma query language 
nativa e a nível de mercado anda crescendo a cada dia, atualmente já existem exames de 
certificação para MongoDB DBA. 
 O MongoDB assim como outros bancos de dados NoSQL, utiliza a replicação 
mestreescravos usando um nó mestre para processar as atualizações e distribuir pelos 
nós definidos como escravos, é possível trabalhar com dados distribuídos dessa forma 
configurando uma réplica entre nós mestres em diferentes espaços geográficos. É com 
base nesse conceito que bancos de dados NoSQL são conhecidos por consistência 
eventual, pois nem todos os nós estão atualizados todo o tempo, isso vai acontecendo 
eventualmente. Como nem todo sistema é consistente podem acontecer conflitos de 
réplica no caso de dois usuários estarem usando o mesmo documento ao mesmo tempo 
daí temos a tolerância a inconsistência conforme citam as propriedades BASE. Nesse 
caso pode-se optar por uma abordagem pessimista não permitindo que um documento 
possa ser usado por mais de um usuário por vez evitando assim que ocorram conflitos, 
já quando optamos por uma abordagem otimista eliminamos problemas com 
concorrência, mas consequentemente permitimos conflitos, porém, nesse caso são 
utilizados métodos de detecção e correção. 
 Um problema encontrado na utilização de replicação mestre-escravos é que caso o nó 
mestre falhe o sistema só ficará apto para leitura até que o nó mestre seja reestabelecido 
ou que substituído por um escravo. Para evitar esse problema o MongoDB permite que 
mais de um nó seja configurado como mestre. 
 
2.4 Banco de dados de família de colunas. 
 
Devido a simplicidade e praticidade dos bancos de dados que usam arquitetura chave e 
valor, os demais bancos de dados NoSQL acabaram adotando o mesmo conceito. Assim 
como bancos de dados orientados a documentos os bancos do tipo família de colunas 
também usam o conceito de chave e valor, porém tem seus dados organizados de 
maneira diferente. 
Bancos de dados de famílias de colunas foram impulsionados pelo surgimento da 
BigTable, desenvolvido pela Google com a intenção de armazenar dados distribuídos e 
projetado para suportar até petabytes de dados, esse modelo armazena os dados 
agrupados em famílias de colunas, que é de certa forma parecido com a estrutura tabular 
usada em bancos de dados relacionais. A nível de busca esse modelo usa o conceito 
chave e valor usando um hash para cada linha ou cada família, como forma de mapear 
os dados e acessa-los com rapidez e eficiência. 
Dentre os bancos de dados que usam a arquitetura de família de colunas podemos 
destacar o CassandraDB que foi desenvolvido pelo Facebook usando a arquitetura do 
DynamoDB e a estrutura de armazenamento da BigTable, em consequência dessa 
junção o Cassandra consegue ser rápido e altamente robusto em armazenamento pois é 
extremamente escalável, além de contar com uma query language nativa chamada CQL 
(Cassandra Query Language) que muito se aproxima do próprio SQL. 
Ao contrário do armazenamento em tuplas, (atributo e valor) utilizado em modelos 
relacionais, o Cassandra usa o conceito de triplas que consiste em linhas, colunas e a 
propriedade timestamp. 
Cada linha representa uma família de colunas e possui um rowKey ou ID referente 
aquele grupo de colunas, cada coluna possui um nome de identificação e o valor a ser 
salvo, além do timestamp que representa o momento em quedeterminada informação 
efetivamente foi salva no banco de dados, essa propriedade é usada para diferenciar 
múltiplas versões do mesmo dado pois o Cassandra trabalha com o conceito de 
desnormalização visando a alta disponibilidade e rapidez. 
 
 Figura 5. Exemplo de estrutura de armazenamento por famílias de colunas. 
 
 Um ponto importante do Cassandra DB é o conceito de super colunas, usado para 
otimizar buscas para dados agrupados. Uma super coluna é composta por várias famílias 
de colunas agrupadas, geralmente utiliza-se dados que possuem alguma relação entre 
eles. Isso minimiza a busca, levando em consideração que o acesso será filtrado pelo ID 
da super coluna e os dados das sub colunas que compõem a super coluna estariam 
dispostos após uma única busca. 
 Ao contrário do Mongo DB o Cassandra usa consistência P2P onde não existe um nó 
mestre. Todos os nós trabalham em conjunto recebendo e replicando suas atualizações, 
caso um nó apresente falha os demais continuam efetuando suas atualizações e no 
momento em que o nó falho retornar o mesmo recebe os dados dos outros nós. 
 Além do Cassandra existem outros bancos de dados de família de colunas como Hbase, 
HyperTable entre outros. 
 
2.5 – Banco de dados de grafos. 
 
Formalmente, podemos descrever um grafo como um conjunto de vértices e arestas 
interligados entre si. No contesto de bancos de dados um grafo pode possuir N vértices 
também conhecidos como nodos, que representam as entidades, e N arestas interligando 
os nodos e consequentemente criando relacionamentos entre tais nodos, conforme 
representado na imagem abaixo. 
 
 
Figura 6. Representação gráfica da estrutura de um grafo. Fonte: Documentação do 
Neo4J 
 
Os bancos de dados de grafos vêm se disseminando no mercado e já ocupam uma das 
categorias mais importantes no meio NoSQL. Alguns bancos que utilizam esse tipo de 
estrutura são: Neo4J, InfiniteGraph, OrientDB, Titan, InforGrid, HyperGraphDB entre 
outros. 
Geralmente uma dificuldade encontrada na utilização de bancos de dados NoSQL é a 
representação gráfica do modelo, os modelos de grafos são os que mais se aproximam a 
um modelo de entidade e relacionamento, isso torna seu entendimento mais fácil em 
relação aos demais modelos NoSQL. 
Utilizando o modelo de grafos que é extremamente expressivo é possível modelar todo 
tipo de cenário, desde um corpo humano onde os órgãos poderiam ser representados 
pelos nós e as veias seriam suas arestas, até o mapa mundo representando cada 
continente ou cada país e suas fronteiras. Agora vamos imaginar os cenários citados em 
um banco de dados relacional. Seriam inúmeras tabelas, relacionamentos, heranças, 
chaves primárias e estrangeiras, quando em um banco de dados de grafos resumimos 
tudo isso em nós e arestas. 
 Conforme citado anteriormente os bacos de dados NoSQL são potencialmente mais 
rápidos e facilmente manipuláveis e é nesse ponto que grafos são mais eficientes que 
tabelas. Se compararmos uma busca um pouco mais complexa em um banco relacional, 
composta por selects e joins e ao mesmo tempo levarmos em consideração a mesma 
busca utilizando algoritmos voltados para grafos, se torna notória a simplicidade que 
bancos de dados de grafos buscam dados em relação as complexas querys utilizadas em 
bancos de dados relacionais. 
Devido ao modelo de dados os relacionamentos em grafos acontecem de maneira 
simples e natural, de maneira geral criamos relacionamentos entre os nodos e é possível 
percorrer todo o grafo usando os relacionamentos criados para efetuar uma travessia 
desde o nodo 1 até o nodo N do grafo. 
Dentre os modelos citados, o modelo que mais se destaca no mercado atualmente é o 
Neo4J, implementado em Java e lançado em 2010 pela NeoTechnology. 
Diferente da maioria de bancos de dados NoSQL o Neo4J é compatível com as 
propriedades ACID, o que consequentemente o torna tão confiável quanto um banco de 
dados relacional, porém mais flexível devido a sua estrutura de dados. O Neo4J é o 
único dentre os bancos de dados de grafo que possui uma linguagem de consulta 
própria, além de ser código aberto e seu armazenamento físico pode ser feito tanto em 
memória quanto em disco. 
Contando ainda com a maior e mais ativa comunidade de desenvolvimento voltado para 
grafos do mercado, o que contribui para sua constante evolução além de possuir vasta 
documentação e recursos como API’s para diversas linguagens como Java, Python, PHP 
e Ruby. Mediante aos fatos citados usaremos o Neo4J nos exemplos da análise 
comparativa desde artigo. 
 
2.6 Cypher. 
 
 Para efetuar busca em grafos usamos os conceitos de busca em largura e profundidade, 
a maioria dos bancos de dados de grafos utiliza o Gremlin que é uma linguagem usada 
especificamente para percorrer grafos, porém tal linguagem é considerada pouco 
intuitiva. 
Na intenção de prover uma melhor experiência o Neo4J conta com uma linguagem 
específica utilizada para criar e manipular grafos. 
O Cypher, query language do Neo4J é uma linguagem muito expressiva e bem parecida 
com o que usamos no SQL para executar as querys, essa linguagem foi projetada para 
ser facilmente entendida por desenvolvedores e está diretamente associada a maneira 
que descrevemos grafos em sua forma gráfica. 
Utilizando a linguagem SQL trabalhamos com tabelas e registros, com o Cypher 
usamos componentes chamados labels que fazem basicamente o mesmo papel das 
tabelas, outro componente são os nodes que seriam equivalentes aos registros em SQL 
além das relações entre tais nodos que são chamados de relatioship e tem um papel 
muito importante na criação de um grafo, relationships são representados pelos 
relacionamentos em bancos relacionais. 
Assim como em outras linguagens, o Cypher é composto por clausulas também 
conhecidas como palavras reservadas da linguagem, a cláusula MATCH tem a mesma 
importância do SELECT que usamos em SQL e é considerada uma das principais 
cláusulas usadas na linguagem, a cláusula RETURN é usada para retornar nodos, 
relacionamentos e propriedades. 
Outras cláusulas como WHERE, CREATE, DELETE, SET entre outras também são 
utilizadas para manipular grafos e basicamente são familiares em outras linguagens o 
que torna o uso do Cypher muito autoexplicativo para desenvolvedores e profissionais 
de bancos de dados. 
 
 Tabela 1 – Representação dos principais componentes de bancos de dados de grafos e 
bancos de dados relacionais. 
 
2.7 A Modelagem utilizando Grafos. 
 
Uma característica importante de bancos de dados orientados a grafos é o modelo livre 
de esquemas, o que torna o cenário mais amplo e traz mais flexibilidade na modelagem, 
isso se dá devido a facilidade em que bancos de dados de grafos trabalham com 
relacionamentos e a forma como esses relacionamentos são tratados no banco, 
basicamente podemos dizer que bancos de dados de grafos foram feitos para trabalhar 
com relacionamentos. 
Apesar do nome sugestivo, bancos de dados relacionais não trabalham tão bem com 
relacionamentos pois o modelo rígido acaba trazendo certa complexidade tanto na 
modelagem quanto na manipulação dos dados. 
Digamos que precisamos modelar um cenário em que é necessário representar as 
relações entre N pessoas. Em um banco relacional seria necessário criar uma tabela para 
cada tipo de relacionamento conforme representado a seguir. 
 
Baseando-se no modelo representado digamos que gostaríamos de saber quem são os 
amigos de Pedro. É uma pergunta simples, porém gera uma consulta um tanto complexa 
tendo visto que precisaremos trabalhar com duas tabelas e logo usaremos JOINS para 
retornar os valores e depois efetuar o filtro pelo nome e ID da pessoa que nesse caso 
seria Pedro. 
Vejamos a consulta. 
SELECT tabelaPessoaA.ID, tabelaPessoaA.Pessoa 
AS AmigosDePedro 
FROMPessoa tabelaPessoaA JOIN AmigoPessoa 
ON AmigoPessoa.AmigoID = tabelaPessoaA.ID 
JOIN Pessoa tabelaPessoaB 
ON AmigoPessoa.PessoaID = tabelaPessoaB.ID 
WHERE tabelaPessoaB.Pessoa = 'Pedro' AND tabelaPessaB.ID = '1' 
Modelando o mesmo cenário em bancos de dados de grafos trabalhamos com um único 
label que seria equivalente a uma tabela e cada pessoa representa um nó dentro do grafo, 
daí criamos os relacionamentos entre os nós que podem ser unilaterais ou bilaterais. 
 
 
 
Figura 7. Modelagem de um cenário de pessoas e seus relacionamentos. Fonte: Console 
do Neo4J 
 
Partindo do mesmo princípio, queremos saber quem são os amigos de Pedro, vejamos a 
consulta utilizando o Cypher. 
MATCH (p: Pessoa {nome: “Pedro”}) -[relacionamento: AMIGO_DE]-> 
(amigo) 
RETURN type (relacionamento) as Pedro, amigo.nome as Pessoas; 
 
 Ambas as consultas representadas retornam os mesmos valores, porém podemos notar 
a simplicidade da busca usando o Cypher em relação a complexidade da busca feita em 
SQL, analisando do ponto de vista computacional o uso de Joins se torna 
performaticamente caro para o banco porque toda vez que uma query é executada é 
necessário fazer a junção das duas tabelas e a consulta no tempo da query. Quando 
usamos o Neo4J mesmo que a quantidade de dados seja enxuta o banco pré-calcula as 
informações de modo que já se sabe quantos relacionamentos e quais relacionamentos, 
quantos nodos e labels já existem cadastrados, essas informações serão utilizadas para 
otimizar as travessias que serão feitas no grafo retornando os valores com muito mais 
rapidez do que em bancos de dados relacionais. Conforme representado a seguir. 
 
 Figura 8. Resultado da busca de Amigos de Amigos usando Neo4J e Bancos 
Relacionais. Fonte: Graph Database 2º Edição Editora - O’Renlly. 
 
 Se dentro desse mesmo cenário fosse necessário modelar mais um tipo de 
relacionamento, de pessoas casadas por exemplo, precisaríamos de mais uma tabela 
para armazenar os registros e ids de pessoas casadas conforme exemplo a seguir. 
 
 
 
Modelando o cenário com grafos é necessário incluir somente mais um tipo de 
relacionamento utilizando o mesmo label e nodos já existentes. 
 
 
 Figura 8. Modelagem de um cenário de pessoas e seus relacionamentos. Fonte: Console 
do Neo4J 
 
O que podemos notar é que a cada entidade ou relacionamento adicionado o modelo de 
dados relacional se torna mais complexo, dificultando na modelagem e 
consequentemente nas consultas em contrapartida o modelo de grafos é expressivo e 
fácil de ser modelado. 
 
2.8 Transações utilizando Grafos. 
 
O fato do Neo4J fornecer suporte transacional o diferencia dos demais bancos de dados 
NoSQL essa característica o torna mais confiável pois garante a integridade dos dados 
assim como acontece atualmente com bancos de dados relacionais. No momento em que 
se inicia uma transação invocada pelo método BeginTx(), toda operação que for 
relacionada aquele processo se torna parte da transação que só é considerada completa 
no ato de invocação dos métodos success() ou failure() e então é finalizada pelo método 
finish() conforme exemplo abaixo. 
public class CadastraPessoa { 
public static void main(String[] args) { 
GraphDatabaseService db = new EmbeddedGraphDatabase(“/tmp/db”); 
Transaction tx = db.beginTx(); 
try { Node Pessoa = db.createNode(); 
 Pessoa.setProperty(“Nome”,”Pedro”); 
 Pessoa.setProperty(“Profissão”,”Desenvolvedor”); 
 System.out.println(“Nova categoria gravada com id: ” + 
 noCategoria.getId()); 
 tx.success(); 
 } finally { 
tx.finish(); 
} 
 
3. Vantagens e Desvantagens. 
 
 Assim como toda tecnologia emergente, bancos de dados NoSQL ainda estão em 
processo evolutivo em contrapartida bancos de dados relacionais apresentam um 
modelo totalmente maduro, existem outras vantagens e desvantagens no uso de ambas 
as tecnologias, que estão representadas na tabela a seguir. 
 
Tabela 2 – Comparação entre as principais características de ambos os modelos de 
bancos de dados. 
 
4. Conclusão. 
 
 Cada modelo apresentado nesse artigo possui suas particularidades, vantagens e 
desvantagens, bancos de dados relacionais são extremamente funcionais onde a 
consistência e integridade dos dados são indispensáveis, a maturidade do modelo traz 
confiabilidade, sendo assim um fator de extrema importância, o que justifica sua 
permanência e destaque no mercado durante tanto tempo. Apesar da teoria de grafos 
existir a mais de dois séculos, o modelo de grafos, dentro do paradigma de bancos de 
dados, ainda é uma novidade, tão logo, ainda é considerado imaturo, porém, tem se 
mostrado muito funcional em modelagens complexas, processamento, armazenamento e 
manipulação de grandes volumes. 
 É importante ressaltar que a intenção de tecnologias NoSQL não é, e nem possui 
condições de substituir totalmente o modelo relacional. Assim como outras tecnologias 
emergentes no mercado o NoSQL tem a intenção de agregar valor e prover resultados 
eficientes, funcionando como uma alternativa ao modelo relacional e somando para o 
meio tecnológico. Atualmente já é possível encontrar bancos híbridos que usam tanto 
modelo relacional quanto o não relacional na ideia de complementar as défices 
existentes em ambos e provendo um novo conceito denominado NewSQL. 
Levando em consideração os estudos feitos no desenvolvimento deste artigo conclui-se 
que ambos possuem destaque em cenários hora distintos, hora similares e a escolha em 
relação a sua implementação depende diretamente do modelo de negócio proposto. 
 
 5. Referências Bibliográfica. 
 
[1] - Chang, F.; Dean, J.; Ghemawat, S.; Hsieh, Wilson C.; Deborah A.; Mike 
Burrows, W.; Chandra; Fikes, A.; Gruber, Robert E. – 2006 – Google. Bigtable: A 
Distributed Storage System for Structured Data. 
 
[2] – Decandia, G.; Hastorun, D.; Jampani, M.; Kakutapati, G.; Laksman, A.; 
Pilchin, A.; Sivasubramanian, S.; Vosshal, P. e Vogels, W. Dynamo: Amazon’s 
Highly Available Key-value Store. 
 
[3] - ELOY, Leonardo A. de Oliveira. O Estado da Arte em Bancos de Dados 
Orientados a Documentos. 2009. 78f. Trabalho de conclusão de curso (Graduação). 
Universidade de Fortaleza, Ceará. 
[4] - NEO4J. Disponível em [http://www.neo4j.org]. 
[5] - NoSQL Relational Database Management System: Home Page Strozzi.it 
 
[6] - Pramod J. Sadalage e Martin Fowler – 2013 – Novatec. NoSQL Um Guia 
Conciso para o Mundo Emergente da Persistência Poliglota. 
 
[7] - Robinson, I., Webber, J., and Eifrem, E. Graph Database 2º Edição Editora - 
O’Renlly. 
 [8] - SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDURSHAN, S. Sistemas 
de Bancos de Dados.