Académique Documents
Professionnel Documents
Culture Documents
Orientadora
Coorientador
Brasília
2015
Universidade de Brasília UnB
5. Controle da Corrupção
CDU 004.4
CEP 70910-900
BrasíliaDF Brasil
Dedicatória
v
Agradecimentos
vi
Resumo
Os bancos de dados em grafo vêm se tornando populares juntamente com as demais ini-
ciativas NoSQL
. Porém, os bancos de dados em grafos não possuem uma notação padrão.
NoSQL Baseados em Grafos (MDG-NoSQL), com recursos para agrupar em uma notação
as características dos bancos de dados em grafos. Esse modelo foi validado utilizando a
Licitações e Sociedades). Esse estudo de caso foi direcionado para auxiliar na detecção
de fraudes em processos licitatórios que, além de ser diretamente aplicável a vários órgãos
da Corrupção
vii
Abstract
Currently, Graph Databases are becoming popular along with other NoSQL initia-
tives. Thus, researchers and companies have been developing data models to manipulate
information as graphs However, there is no standard notation involves several features and
structures of the graph databases. This model introduces several notations and concepts
for building a new graph data model, called Data Model for NoSQL Graph Databases
(GDM-NoSQL). The GDM-NoSQL was veried through a database for investigate rela-
tionships between companies and people as well as information about the procurements
that these companies participated in with the Federal Government. This database was de-
signed to facilitate the process of searching for frauds and to be used on multiple contexts,
i.e. several dierent national agencies. Finally, the designed model was implemented in
both a relational and a graph database in order to validate the hypothesis that writing
relationships is simpler and more ecient in graph models than relational databases.
viii
Sumário
1 Introdução 1
1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Licitações e Sociedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
ix
4.3.3 Hipergrafos e Hiperarestas . . . . . . . . . . . . . . . . . . . . . . . 52
6 Conclusão 83
7 Anexos 85
7.1 Anexo I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Referências 91
x
Lista de Figuras
xi
3.20 Exemplo de aresta com tipo. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
de diamante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
atributo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5 Árvore de consulta para duas empresas por sócios até a terceira empresa. . 71
xii
5.6 Destaque do primeiro ramo da árvore de consulta para duas empresas por
sócios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.9 Resultado da consulta para sócios de empresas no Neo4j com menor caminho. 76
xiii
Capítulo 1
Introdução
Grafos são estruturas que permitem evidenciar relacionamentos entre objetos, sejam
eles pessoas, ativos de rede ou mesmo cidades. Eles estão presentes em aplicações como os
recentemente os grafos vem ganhando popularidade como uma forma nativa de arma-
para problemas onde a informação já possui uma estrutura típica de grafos, assim como
realizado nos bancos relacionais. Esse capítulo traz uma contextualização sobre os bancos
1.1 Contextualização
O aparecimento dos bancos de dados NoSQL ( Not Only SQL ) [31] trouxe alterna-
tivas para o gerenciamento dos dados além do tradicional banco de dados baseado no
modelo relacional. Dentre estes novos sistemas, tem-se os bancos de dados em grafos,
arestas.
atributos. Pode-se citar como exemplo as interações entre átomos de proteínas, padrões
pessoas são sugeridas como boas aplicações para implementação em bancos de grafos [4,
18, 33]. Porém, ainda existe uma lacuna sobre como modelar e implementar domínios
1
utilizando essas tecnologias, pois esses sistemas ainda não possuem uma maturidade no
A modelagem é uma etapa fundamental na organização dos dados que devem ser arma-
modelagem em grafos também precisam evoluir, e são movidas principalmente pela ne-
e as necessidade do negócio.
nesse trabalho, foi elaborado para tentar suprir essa lacuna com uma notação para modelar
diagramas mais simples às estruturas de grafos mais complexas. Para validar o modelo,
processo licitatório que podem ser utilizados em investigações de fraudes [17]. Apesar da
maioria dessas informações serem armazenadas em bancos relacionais, estas são analisadas
grafos. Para isso, foram selecionadas algumas questões comuns que utilizam esses dados
como matéria prima, traduzidas em consultas que serviram para avaliar os impactos na
mudança de tecnologia.
1.2 Objetivos
O objetivo geral dessa pesquisa consiste em preencher a lacuna existente de uma
notação formal de modelo de dados que atenda aos bancos de dados NoSQL baseados
2
Capítulo 2: Apresenta a teoria utilizada para elaboração do Modelo de Dados para
3
Capítulo 2
Banco de Dados em Grafos
Este capítulo apresenta uma síntese sobre os bancos de dados em grafos. Inicialmente,
aspectos históricos com as principais iniciativas das décadas de 80 e 90. Por m, a
Seção 2.3 descreve a retomada dos bancos de dados em grafos nos dias atuais, integrando
Esta seção apresenta um resumo das denições utilizadas nesses bancos de dados que
seria E = {(v1 , v2 ), (v1 , v4 ), (v2 , v6 ), ..., (vn−1 , vn )} onde cada subconjunto é chamada de
Também é possível representar um grafo de forma gráca, onde os vértices são pontos
e as arestas linhas ligando-os como mostra a Figura 2.1. No exemplo, os vértices repre-
sentando pessoas distintas são ligadas por arestas que representam os relacionamentos de
amizade entre elas. O exemplo ilustra também como os vértices podem ser apresentados
com rótulo para dar signicado a eles no grafo, assim como às arestas, indicando um tipo
de relação ou mesmo o peso de percorrê-la. Para o grafo de amizade, as arestas não fazem
(vi , vj ) = (vj , vi ).
4
Figura 2.1: Exemplo de grafo.
direcionado ou digrafo [8]. Pode-se citar como exemplo a Figura 2.2 onde se indica que
Isso também implica que para indicar uma relação simétrica, como a de amizade,
seriam necessárias duas arestas ligando os vértices dos indivíduos no qual se quer repre-
sentar a amizade. Poder-se-ia desenhar uma reta com setas em ambos os sentidos para
simplicar o desenho, mas deve-se lembrar que ainda são duas arestas, uma para cada par
ordenado do conjunto E. O grau de cada vértice também pode ser separado em grau de
entrada, com arestas que chegam no vértice, e grau de saída, com arestas saindo do nó.
Um grafo que permite a existência de várias arestas para um par de vértices é chamado
que compartilham os mesmos vértices, mas cada qual com seu conjunto de arestas. Uma
aplicação possível de multigrafo seria representar as diversas estradas que ligam um grupo
de cidades, como apresentado na Figura 2.3 onde a Cidade C pode ser alcançada por dois
caminhos a partir da Cidade A.
Pode-se generalizar os grafos para permitir que uma mesma aresta relacione mais de
dois vértices. Nesse caso, cada arco, chamado de hiperaresta, teria um número variado de
nós indicando a mesma relação entre eles, esses grafos são chamados de hipergrafos [3].
Assim sendo, o grafo passa a ser da forma G(V, H), onde V é o conjunto de vértices
5
Figura 2.3: Exemplo de multigrafo não direcionado.
de V até |V|. A Figura 2.4 apresenta um exemplo de hipergrafo com duas hiperarestas em
uma notação mais comum de ser encontrada para diagramas de instância, embora mais
complicada de desenhar. A Empresa A participa de duas licitações que são indicadas pela
hiperaresta E1. A Empresa B, participa apenas da Licitação Y sendo a hiperaresta que
indica esse relacionamento composta apenas de dois elementos de vértices.
6
Por m, como foi feito para as arestas, pode-se imaginar um agrupamento de diversos
grafos, ou subgrafos, que se relacionam entre si como se fossem vértices. Um grafo agru-
pado se torna um hipernó, sendo tratado como um vértice comum, e o grafo passa a ser
chamado de aninhado [3], ou seja, grafos dentro de grafos. A Figura 2.5 apresenta um
exemplo onde as informações de sociedade de uma empresa são agrupadas para formar
O hipernó desse exemplo pode se vincular a outros como um vértice qualquer do grafo
aninhado, como apresentado na relação entre o subgrafo com sócios de uma Empresa e sua
Declaração de Imposto de Renda. O hipernó no exemplo indica o quadro societário do
ano de competência 2014, ou seja, como uma fotograa de quem atuava na empresa como
sócio no ano em questão, e permite que esse subgrafo seja ligado a outro vértice, como a
foram realizados ao longo das últimas décadas, embora muito pouco tenha sido produzido
durante a primeira década do século XXI [2, 3]. Logo após esse período, com a necessidade
NoSQL, para armazenar grandes volumes de dados, ocorreu uma revitalização nessa área,
ampliando o interesse e aplicação desses sistemas. Esta seção apresenta um breve evolução
dos bancos de dados em grafos, dando ênfase nas características necessárias para esse
trabalho.
7
2.2.1 Diversidade de Modelos
diminuiu nesse tema até o surgimento dos bancos de dados NoSQL [3]. Essas pesquisas
propunham uma forma de organizar a informação, assim como uma notação para o modelo
utilizado e, muitas vezes, a forma de consultar como, por exemplo, o GOOD [12], Gram [1],
Simatic-XT [27], LDM [22], GOAL [15], Hypernode [24], GROOVY [25] e GDM [16].
Dessas iniciativas, destacam-se para esse trabalho as notações utilizadas nos modelos, das
O modelo da Figura 2.6, o Gram - Graph Data Model and Query Language [1], utiliza
um grafo para o esquema onde os vértices são rótulos com o tipo de entidade, assim como
os relacionamentos, que são representados pelas arestas também rotuladas. Sua estrutura
é simples e permite que valores iguais em vértices sejam compartilhados entre as entidades.
(a) Esquema.
(b) Instância.
Em outros modelos, foram criadas notações com formas diferentes para entidades
8
e atributos, como o Graph Data Model [16] apresentado na Figura 2.7. As entidade são
representadas por um quadrado, sendo possível especializá-las utilizando setas mais larga,
como no caso de Manager e Employee. Já os atributos são indicados pelas arestas ligadas
a círculos com o tipo escrito no interior do círculo, como int e str. Na ocorrência de
(a) Esquema.
(b) Instância.
Este também utiliza as arestas e círculos com tipo para indicar atributos, mas os objetos
complexos, como Contract, são representados com retângulos compostos por um losango
interno. As arestas duplas (ou largas) também indicam a herança entre entidades, mas
o GOAL traz também a aresta com seta dupla utilizada para representar atributos mul-
9
tivalorados, derivada de modelos mais antigos [12]. Um exemplo desse tipo de aresta é
(a) Esquema.
(b) Instância.
tado na Figura 2.9, trabalhando com níveis de abstração. Ele possui o conceito de Master
Nodes Master Edges
e que permite agrupar um subgrafo para ser utilizado como vértice
no nível de abstração superior. Apesar da notação não indicar um esquema dos dados,
ela permite idealizar uma forma de representação para agrupamentos de subgrafos, já que
10
o primeiro nível de abstração, como o grafo George, P1 e Jones, pode ser agrupado para
Por m, a Figura 2.10 apresenta o Hypernode Model [24]. Neste, os hipernós são cons-
truídos utilizando um rótulo, nomes de atributos, que inicial com $, e valores atômicos
Os passageiros, por exemplo, são denidos com uma série de atributos ligados a seus
valores (atômicos ou outros rótulos de hipernós), enquanto os voos são apresentados por
um hipernó com seu grafo vinculando os passageiros com linhas aéreas. Sendo assim,
pode-se construir hipernós mais complexos, que também poderão integrar outros grafos
Apesar desses modelos serem os principais que serviram de base para notação, diver-
sos outros foram desenvolvidos, principalmente durante a década de 1990 [3], e que já
traziam conceitos que vêm sendo utilizados atualmente, como hipergrafos [25]. Com o
surgimento dos bancos de dados NoSQL, os modelos de dados utilizando grafos volta-
ram a se destacar como uma solução para problemas de natureza típica dessa estrutura,
onde relacionamentos são tão importantes quanto as entidades envolvidas [35]. Sendo que
bancos de grafos de acordo com propriedades dos vértices, arestas ou mesmo da estrutura
do grafo em si [2].
No entanto, esses modelos de grafos ainda focam apenas em suas estruturas ao apre-
sentarem um modelo de dados, como em Robinson et al . [32], trabalho voltado para uma
solução especíca de banco de dados em grafos que traz alguns conceitos de modelagem,
11
(a) Voos com passageiros e companhias.
(b) Passageiros.
se como base os diagramas dessas iniciativas em bancos de grafos para desenvolver uma
notação generalizada que cobrisse as características atuais desse tipo de banco NoSQL.
12
2.3 Bancos de Dados NoSQL em Grafos
O crescente volume de dados em estruturas distintas e a necessidade de gerar infor-
mação rapidamente vem forçando o estudo de novos modelos de dados além do relacional
mineração de informações, seja de menor porte até as rotuladas como Big Data [18].
Nesse contexto, os chamados bancos NoSQL, muitos derivados dos trabalhos da Ama-
zon [11] e Google [7], vêm ganhando espaço como novas propostas de modelos e sistemas
de bancos de dados para o gerenciamento dessas informações. Pela sua crescente impor-
tema de diversos trabalhos, como Stonebraker [36], Leavitt [23], Hecht e Jablonski [13],
Considerando as diversas propostas de bancos de dados, uma das mais distintas tem
grafos, apesar de descritos como um dos tipos de NoSQL , já são temas de trabalhos mais
cipalmente pela crescente demanda por formas mais ecientes de manipular os dados es-
conforme Srinivasa [35]. Em especial, uma das aplicações adequadas para a utilização de
ações criminosas como apresentados em McIllwain [29], Xu e Chan [38] e Hulst [17].
Com esse novo impulso sobre a pesquisa e utilização dos bancos de dados em grafos,
utilizando combinações de características diferentes dos grafos, e que variam desde uma
API até sistemas cliente/servidor. Essas iniciativas vêm sendo apresentadas em diversos
trabalhos pela comunidade como em Angles [2], com ênfase na estrutura de dados dos
para organizar os dados. Atualmente, esses bancos se dividem em quatro grupos baseados
Os bancos de chave/valor recebem esse nome devido aos dados serem armazenados
utilizando uma chave única no banco, e um respectivo valor. Esse tipo de NoSQL foi
muito inuenciado pelo Dynamo [11], banco desenvolvido pela Amazon para armazena-
13
mento distribuído desse tipo de estrutura. Já os bancos colunares, inuenciados pelo
BigTable [7] do Google, alteram a forma tradicional de organizar os dados de linhas para
colunas, mantendo o valor agrupado, juntamente com o identicador das linhas das quais
ele pertence. Por m, os NoSQL de documentos são bancos que permitem armazenar es-
truturas mais complexas[9], muitas vezes em formato JSON JavaScript Object Notation
( ),
chamados de documentos, que podem ir desde uma chave/valor até várias informações
encadeadas.
simplesmente banco de grafos, que utilizam os conceitos de vértice e aresta para organizar
dados altamente conectados, facilitando consultas típicas dessa estrutura [31]. Alguns des-
1 2
ses bancos são simplesmente uma API, como o Sparksee (ou DEX) e o HypergraphDB .
3 4
Outros sistemas, como o Neo4j e o OrientDB , possuem a opção de executarem como um
também a API.
construiu sua implementação da forma que considerou mais adequada, mas, ainda que nos
documentos. Conforme Angles [2], os bancos NoSQL de grafos podem ser caracterizados
pelos seus tipos de vértice, arestas e também pela natureza do grafo, resumidamente
informações, inclusive atributos de uma entidade, são representadas por nós e arcos;
Hipergrafo: Grafos que permitem que suas arestas possuam mais de dois vértices;
Grafo com atributos: Esses permitem que seus vértices tenham atributos, essa ca-
Grafo aninhado e hipernó: São grafos que suportam outros grafos como nós, ou seja,
todo um grafo pode ser vinculado com outro, como se fosse um vértice.
1 http://www.sparsity-technologies.com/
2 http://www.hypergraphdb.org/
3 http://neo4j.com/
4 http://www.orientechnologies.com/orientdb/
14
Nó rotulado: O nó aceita apenas um rótulo, que também pode ser o ID do vértice;
Aresta com atributos (direcionada ou não): A aresta também pode conter atributos
Em relação ao grafo simples, este considera tudo como vértice e aresta, ou seja, mesmo
dados que seriam atributos dentro de tabelas serão vértices no modelo de dados. Essa
Já os hipergrafos e grafos alinhados podem ser utilizados para vincular de forma mais
Quanto aos grafos com atributos, esses permitem maior velocidade para recuperar
Apesar dos bancos de dados em grafos estarem novamente em destaque, faltam pes-
quisas atuais na área de modelagem de dados em grafos, até onde foi vericado, assim
como uma notação formal que cubra as diversas características desses bancos, tema que
2.4 Conclusão
Foram apresentados nesse capítulo alguns exemplo dos modelos de dados encontrados
existirem desde a década de 80 [3], cada um deles foi utilizado em seu próprio contexto
para problemas especícos. Entretanto, percebe-se que ainda não se elaborou um modelo
de dados padrão consistente como o existente no modelo relacional e que permita trabalhar
Muito das notações apresentadas até o momento foram propostas até meados de 2002
e estas já incorporavam estruturas que estão despontando nos atuais bancos NoSQL ba-
15
alguns modelos de dados, mas como os da literatura, focam apenas em cobrir os pró-
consolidado.
grafos. Pode-se somar à notação também aspectos externos que não foram explorados nos
Relacionamento. A partir dessas ideias, foi criado o Modelo de Dados para Bancos NoSQL
16
Capítulo 3
MDG-NoSQL: Modelagem de Dados
para Bancos NoSQL Baseados em
Grafos
Este capítulo apresenta uma notação para diagramação dos modelos de dados dos
apresentados detalhes da notação e alguns exemplos de utilização para ilustrar cada ele-
consolidada.
NoSQL) é proposto, com o objetivo de cobrir os diversos objetos utilizáveis nas estruturas
de grafo. A construção da notação foi especicada para ser o mais simples possível facili-
tas.
O modelo MDG-NoSQL foi proposto para uso geral, suportando a modelagem dos
principais tipos de grafos, sendo estes o grafo simples, de atributos, hipergrafo e aninhado
(hipervértice). Ele pode ser utilizado em qualquer domínio que se deseje modelar os
dados em grafos, sendo utilizado nesse trabalho para modelar o banco de vínculos como
estudo de caso, apresentando como esse detalhes de modelagem para cada uma das quatro
17
3.2 Vértices Simples e com Atributos
Vértices são comuns de serem representados utilizando-se pontos, retângulos ou gu-
ras circulares. Dessa forma, para denir um modelo de dados em grafos, é importante
ER, o que remete a um conceito de entidade. Já para as instâncias, foi utilizado o formato
circular/elíptico. Dessa forma, como apresentado na Figura 3.1, ca claro quando se está
Bob.
drado de bordas aredondadas para que a entidade possua as informações necessárias para
Figura 3.2, utilizando obrigatoriamente rótulo, além de notações opcionais são incluídas
dentro dos símbolos [ e ], como indicado por Tipo e Atributo: Tipo, quando
identicar uma entidade, como Pessoa, o que permite que alguns bancos de dados em gra-
fos utilizem o rótulo para ltrar os vértices em consultas. Alice, por exemplo, poderá ter
18
um rótulo em sua implementação que remeterá à entidade Pessoa. A Figura 3.3 apresenta
outros exemplos de entidades, indicadas pelos seus rótulos. Como previamente denido,
não se está apresentando uma instância especíca de Pessoa, Empresa, Sociedade, Data
ou Nome, mas a representação da existência de um tipo de vértice relacionado com a en-
tidade indicada no rótulo. A segunda função é denir o domínio de valores que podem
identicar um vértice unicamente, caso o rótulo seja o único atributo permitido no nó.
Para dar suporte a essa característica, o MDG-NoSQL faz uso da notação opcional de
O uso do tipo no rótulo pode ser uma questão de estrutura, como no caso do grafo
simples, onde os atributos também são vértices e cada entidade precisa apontar para os
diversos nós de atributo. A Figura 3.4 demonstra um exemplo para a entidade Nome,
sendo seus vértices compartilhados entre Pessoa e Empresa. Isso implica que instâncias
de ambas as entidades apontarão para algum vértice do tipo Nome que armazenará seu
valor, inclusive podendo Empresa e Pessoa terem o mesmo nome, ainda que incomum.
Porém, nessa situação, encontra-se o problema de como uma entidade será identicada
unicamente no modelo.
como um identicador. Uma Pessoa, por exemplo, poderia ser identicada por vértices
com números sequenciais ou um nome único, como o login . Sendo assim, é importante
especicar qual o tipo de valor que o rótulo aceitará. Fazendo um paralelo com orientação
a objetos, o rótulo funcionaria como o nome da classe e o tipo especicaria qual o domínio
19
A Figura 3.5 apresenta um exemplo do uso do tipo no rótulo para Pessoa, Nome e
Empresa. A entidade Pessoa é indicada como inteiro grande (long). Esse tipo implica que
as instâncias de pessoas serão identicadas por um número como, por exemplo, o Cadastro
de Pessoa Física (CPF). As outras duas entidades, Empresa e Nome, são apresentados com
tipos diferentes, indicando que uma instância de Nome será identicada por uma string
,
como o próprio nome, e Empresa por um char(14), que é uma forma comum de armazenar
o Cadastro Nacional de Pessoa Jurídica (CNPJ) utilizado para identicar empresas no
Governo Federal.
Já para modelos de grafos que permitem atributos, utiliza-se a caixa do vértice com
conforme apresentado na Figura 3.6. No exemplo, Pessoa e Empresa são denidos como
vértices com atributos, permitindo que o nome de ambas as entidades seja colocado como
Ela também permite simplicar o diagrama por não ser necessário desenhar todos os atri-
butos como vértices. Porém, deve-se lembrar que um dos benefícios do grafo é enfatizar
racterística, sendo necessário avaliar o impacto sobre o modelo do que deve ser ou não
evidenciado. Essa discussão é retomada com mais detalhes no estudo de caso do Capí-
Sociedades.
Por m, o modelo pode crescer e dicultar a ligação entre diversas entidades, como não
foi vericado na literatura uma forma de diminuir a sobreposição de arestas, foi elaborada
símbolo de ..., junto ao rótulo do vértice. Ela permite fazer uma ligação com a entidade
já denida, sem precisar passar um arco para outro ponto distante do diagrama, como
apresentado na Figura 3.7. No exemplo, o relacionamento entre Órgão e Pessoa pode ser
20
Figura 3.6: Vértice com atributos.
expressa sem ter que repetir a notação completa da entidade Pessoa no lado oposto do
diagrama. Ao se utilizar essa notação, não se está denindo uma nova entidade, apenas
crescer e tratar diversas entidades, o uso de um vértice como referência a uma entidade
vértices construídos a partir de outros grafos. Eles consistem em indicar grafos ou sub-
grafos dentro de uma fronteira retangular. Esse tipo de notação é similar a já utilizada
no Hypernode Model da Figura 2.10, assim como o uso de limites para agrupar objetos,
presente no modelo Simatic-XT, da Figura 2.9. Porém, esses modelos foram estendidos
O hipervértice é um grafo ao mesmo tempo que um nó. Como vértice, ele pode
compor outros grafos com níveis de abstração mais alto, como no exemplo do Simatic-
XT, da Figura 2.9. Já como um grafo, pode-se imaginar que um conjunto de vértices e
arestas foi marcado para indicar que são parte de uma estrutura maior, o hipervértice, e
21
que possui seus próprios atributos. A notação para hipernós é apresentada na Figura 3.8
e foi diferenciada dos vértices simples pela borda reta do retângulo como o do Hypernode
Model [24]. Dentro do hipervértice, deve ser colocado o modelo de grafo que ele fará
referência.
o número de grafos que se espera dentro de cada hipernó, o tipo do rótulo, para situações
similares aos vértices simples, e quais seus atributos, caso existam, destacados dentro do
retângulo por um símbolo UML ( Unied Modeling Language ) [30] de nota, diferenciado
Para melhor compreensão do hipernó, pode-se imaginar um cenário onde uma cidade
é segmentada em regiões. Cada região dene uma comunidade, com grupos de pessoas
que vivem e possuem uma função especíca dentro dela, seja de morador até líder da
Os valores entre os símbolos <> indicam que existem vários subgrafos em uma
22
uma Região. Como diversas pessoas residem na mesma Região, tem-se vários subgrafos
com essa topologia e esse conjunto forma o hipernó de Comunidade. A Figura 3.10 destaca
apenas um subgrafo. Supondo, por exemplo, que as comunidades interajam com as prefei-
turas de suas cidades, pode-se querer modelá-las também como um hipernó Prefeitura.
De forma simples, pode-se imaginar a Prefeitura com um Gabinete, com o Prefeito e
notação.
23
instâncias, como apresentado na Figura 3.12. Nesse exemplo, como denido no modelo de
está relacionado com as entidades que compõem o hipernó, mas com o subgrafo como um
entidade pode rmar convênios para realização de programas voltados para as comuni-
Departamentos foi detalhado para ilustrar sua composição, assim como o re-
hipervértice
tice pode acontecer tanto com um vértice como com outro hipervértice.
Por m, como nos vértices comuns, o hipervértice também pode utilizar o símbolo
... para indicar que a entidade já foi denida em outro local. Isso é exemplicado em
Gabinete dentro de Prefeitura, supondo que esse já foi descrito em outro local.
24
Figura 3.13: Uso de atributos e relacionamentos entre hipernós e vértices em Prefeitura.
eles utilizando as arestas. Cada aresta deve ter seu rótulo, utilizado para indicar qual o
relacionamento entre os nós. A Figura 3.14 apresenta dois tipos de arestas, direcionada e
não direcionada, para indicar o sentido dos relacionamentos, além da notação do rótulo,
características como cardinalidade, peso, tipos e atributo que serão detalhados ao longo
desta seção.
aresta não direcionada com um rótulo simples. A Figura 3.15 apresenta um exemplo do
que as pessoas são amigas entre si, não é necessário indicar o sentido no segmento de reta
utilizando uma seta, ou, se o grafo for direcionado, deve-se ter duas setas para indicar
instâncias de Pessoa, a aresta é desenhada ligando a entidade nela própria, indicando que
sai de uma instância de Pessoa e chega a outra da qual ela é amiga. Essa estrutura de
esquema já foi utilizada em outros modelos, como o Gram, ilustrado na Figura 2.6.
Pode acontecer de duas entidades se relacionarem por mais de uma forma, como duas
datas para um processo de licitação. Nesse caso, pode-se ter mais de um arco entre as
esquema da Figura 3.16, onde a data de publicação e homologação geram duas arestas
25
Figura 3.15: Exemplo de aresta não direcionada.
no esquema, a instância do processo com número iniciando em 1 possui as duas arestas
segundo processo de licitação ainda não foi homologado e apenas se relaciona com a data
que, mesmo se uma instância pudesse ter a mesma data de publicação e homologação,
seriam duas arestas ligando uma instância de Licitação a uma de Data, cada qual com
relacionamento é assimétrico (uma Pessoa leu um Livro, mas um Livro não pode ler
nesse caso de forma direcionada, e a instância apresenta os dois livros que Alice já leu.
Ressalta-se que grafos direcionados são comumente desenhados através de setas e o modelo
Entretanto, no modelo, não ca claro quantas pessoas ou quantos livros podem es-
Para isso, pode-se utilizar o conceito de cardinalidade já presente no modelo entidade rela-
26
Figura 3.17: Exemplo de aresta direcionada.
de instâncias de uma entidade que pode se relacionar de alguma forma com as tuplas de
com uma outra entidade, como, por exemplo, um departamento que possui apenas
com outra entidade, mas esta segunda participa apenas de uma, como um departa-
com outra entidade, mas diferente de 1:N, a segunda entidade pode participar de
muitas instâncias também, como, por exemplo, projeto e empregado, onde um pro-
um exemplo mais elaborado com livros é apresentado na Figura 3.18, onde ao invés de
registrar a leitura, são registradas as compras dos livros por clientes do tipo Pessoa, sendo
necessário indicar quantas compras foram realizadas por um cliente e quais livros foram
dentro dos símbolos de ( e ) próximos aos vértices indicam as quantidades esperadas
No exemplo da Figura 3.18, uma Pessoa pode ter de zero (0) até qualquer quantidade
de pedidos de Compra (n). Já quando a Compra é iniciada, ela deve ter obrigatoriamente
junto ao vértice da entidade Pessoa. A Compra também deve ter no mínimo um item,
podendo ser adicionados diversos livros, o que implica na cardinalidade de (1..n). Como
27
Figura 3.18: Exemplo de aresta com cardinalidade.
diversas pessoas podem comprar o mesmo título, a cardinalidade para eles é de (0..n), o
que implica também que um Livro pode não ter sido comprado ainda.
cardinalidade junto ao rótulo da aresta pode car confuso, ainda mais em um diagrama
complexo. Sendo assim, para facilitar a leitura, pode-se também desvincular a notação
apresenta um exemplo para o caso de venda de livros. Uma vantagem dessa notação
Importante ressaltar que, apesar da semelhança com o MER, pode-se tratar a car-
dinalidade como a quantidade de arestas que se espera para uma instância da entidade.
Sendo assim, o relacionamento de Compra com Livro implica que poderão existir de um
até diversas arestas saindo de uma instância de Compra com rótulo INCLUI, assim como
para diversas arestas desse tipo chegando em uma instância de Livro, como foi apresen-
28
tado na Figura 3.18, onde Charlie ainda não realizou qualquer aquisição, mas Alice já
possui duas compras de livros, sendo um deles o mesmo título que Bob adicionou em sua
única compra.
Outra característica importante a ser acrescentada nas arestas é um tipo, assim como
nos vértices. Novamente, o rótulo passa a se assemelhar com uma classe, sendo o tipo
o indicador de que valores são permitidos para as instâncias. A Figura 3.20 apresenta
um exemplo de esquema onde a relação de sociedade é dada por uma aresta indicando a
qualicação do sócio (administrador, cotista, acionista, etc.) por uma cadeia de caracteres
indicado logo após o símbolo de :. A instância apresenta uma situação em que Alice
se relaciona com duas empresas, sendo qualicada como diretora em uma e cotista em
Além do tipo do rótulo, as arestas também podem indicar um valor que tenha signi-
cado no relacionamento, muitas vezes chamado de peso. Alguns exemplos são: a distância
em quilômetros entre cidades, a resistência entre dois terminais elétricos, o número de li-
gações telefônicas entre duas pessoas, ou mesmo o número de exemplares do mesmo tipo
na compra de livros. A Figura 3.21 apresenta um exemplo do uso de peso na aresta, onde
no relacionamento entre Pessoa e Empresa, cada sócio entra com uma cota de sociedade,
podendo ir de qualquer valor acima de zero até 100%. Na instância, Alice possui 10%
Figura 3.20, implica que o valor desse pode variar conforme o domínio denido pelo tipo.
Ou seja, Pessoa pode ter uma aresta com rótulo de DIRETOR para uma sociedade e de
Para o peso, o rótulo pode até ser o mesmo, mas cada aresta possui um valor, dentro do
domínio de seu tipo, referente ao que o arco representa, como distância ou cota. No exem-
plo da Figura 3.21, o rótulo entre Pessoa e Empresa é a string constante SOCIO_DE,
29
Figura 3.21: Exemplo de aresta com peso.
não precisando da indicação de tipo no rótulo, mas cada relacionamento possui um valor
relacionamentos, por exemplo, são iguais, indicar apenas peso já seria suciente.
Por m, algumas arestas podem permitir o uso de atributos, assim como os vértices.
sociedade entre Pessoa e Empresa nesse caso utiliza dois atributos na aresta para indicar
qual a data de entrada e saída do sócio no quadro da empresa. Esse tipo de caracterização
em grafos com atributos, como do Neo4j, mas em geral como diagramas de instância.
para simplicar relacionamentos n-ários entre vértices como é apresentado na Seção 3.6.
Uma característica a ser enfatizada é o fato de que o peso pode ser colocado como um
30
atributo da aresta, caso seja possível utilizar atributos, mas devido a sua importância nos
aresta e pertencente ao conjunto de arestas E , de forma que e = {v, u}. Entretanto, pode-
se generalizar a ideia de aresta para um conjunto de dois ou mais vértices permitindo que
e = {v, ..., u}, transformando o grafo em hipergrafo [2]. Isso permite relacionar várias
informações em uma mesma aresta, que passa a ser chamada de hiperaresta ou hiperarco.
De forma menos formal, uma hiperaresta é um conjunto com vários elementos. Esses
elementos podem ser apenas vértices, quando a hiperaresta não for direcionada, ou ser
a Empresa A e os sócios Pessoa B e Pessoa C. Por m, a hiperaresta preta, E3, agrupa
Embora seja possível apresentar os conjuntos de vértices das hiperarestas pelo dia-
grama de instâncias da Figura 3.23, essa representação não abstrai as entidades e relacio-
namentos, forçando a visualização de todos os objetos do grafo, que podem car ilegíveis
com o aumento do número de elementos. Dessa forma, foi elaborada uma notação para
31
a modelagem do esquema utilizando hiperarestas no MDG-NoSQL. Estas utilizam linhas
de reta, característica construída para esse modelo, e com símbolos nas extremidades os
entidade na hiperaresta.
outros modelos que utilizam hiperarestas, como o GROOVY [25], e, portanto, buscou-
se símbolos que remetem a ideia de agregação no modelo UML [30] para construir uma
sem preenchimento. Ambas as notações são utilizadas para indicar que o conjunto da hi-
peraresta aceita mais de uma instância da entidade relacionada em que toca. Entretanto,
a seta sem preenchimento é utilizada apenas no caso da hiperaresta possuir direção, indi-
cando que podem existir múltiplas instâncias da entidade no conjunto de destino. No caso
de se tratar de vértices de origem ou da hiperaresta não ser direciona, a ponta que possuir
32
Sendo assim, para o relacionamento M:N da Figura 3.25, ao invés de se ter diversos
rarestas, estas serão compostas de grupos de empresas e licitações em comuns entre elas,
V
como apresentado na instância do hipergrafo. Dessa forma, para o conjunto de vértices
viesse a participar apenas daLicitação Z, esta não poderia entrar na hiperaresta h_2,
pois a mesma não participa também da Licitação Y, sendo necessário criar uma nova
Ainda que as hiperarestas permitam diversas instâncias de várias entidades no seu con-
junto, essa característica torna mais complexa a manipulação dos dados quando o conjunto
criar uma nova hiperaresta. Sendo assim, pode-se limitar a quantidade de instâncias em
alguns relacionamentos para uma unidade, forçando a simplicação. A Figura 3.26, que
não utiliza o diamante na ligação com Empresa, apresenta um exemplo parecido com o
da Figura 3.25, porém, indicando que o conjunto de cada hiperaresta terá apenas uma
tório. Nota-se que isso é equivalente a manter uma lista de licitações para cada empresa,
33
dades especícas do MDG-NoSQL forçou uma dissociação entre eles. Primeiramente o
símbolo de diamante pode ser utilizado em ambas as pontas, sendo esse caso uma situação
Por m, o diamante não se localiza na UML ao lado da entidade agregada, mas na que
outra ponta, sem diamante, seja representada como participante na hiperaresta com uma
unidade apenas. Assim, se houverem apenas duas entidades e ambas forem resumidas
a uma instância no conjunto, a hiperaresta colapsa para uma aresta, com apenas dois
estar de nenhum (0) a vários (N) relacionamentos do tipo PARTICIPANTES, isso é o que
indica a cardinalidade na hiperaresta. Porém, para enfatizar que uma aresta pode conter
várias instâncias de quaisquer das entidades Empresa e Licitação, além de ser não dire-
cionada, utiliza-se a notação de diamante nas extremidades que tocam cada entidade da
hiperaresta. Nota-se que existe nessa notação de hiperaresta uma semelhança com o MER
lidade é apresentado na Figura 3.27. Cada Licitação possui de uma até diversos itens,
utilizando uma aresta simples, ter-se-ia uma a cardinalidade (1..1) do lado de Licitação
e (1..n) para Item_Licitação, conforme apresentado no exemplo. Entretanto, como as
hiperarestas permitem vários elementos, pode-se colocar todos os itens de uma licitação
em apenas uma hiperaresta, indicado no segundo esquema da Figura 3.27 pela ponta sim-
existirá apenas uma hiperaresta para cada Licitação, onde estarão todos as suas ins-
entidades para (1..1), ou seja, uma Licitação estará apenas em uma hiperaresta, assim
gura 3.28a, onde a hiperaresta se bifurca para ligar as diversas entidades envolvidas no
relacionamento. Nesse exemplo, supondo que cada licitação tenha vários contratos para a
34
Figura 3.27: Exemplo de hiperaresta com a cardinalidade contrastando com a notação de
diamante.
Contrato e Licitação indica que o conjunto da hiperaresta pode ter vários contratos e
a qual licitação, não sendo adequado para um processo de auditoria, por exemplo.
Dessa forma, para especicar a qual Licitação os diversos contratos estão relaciona-
dos, pode-se limitar também a entidade Licitação para uma instância. Isso faz com que
Nota-se que a cardinalidade das entidades permanece como no MER, onde a cardina-
com o conjunto das demais. Sendo assim, cada instância de Contrato se relacionará ape-
35
(a) Hiperaresta modelada com múltiplas instâncias de Contrato e
Licitação para uma Empresa.
assinados pela empresa vencedora, caso ela consiga vencer algum. No segundo modelo, da
várias hiperarestas por Empresa, alterando a cardinalidade para (0..n), pois uma Empresa
poderá estar em mais de um relacionamentos com Licitação/Contrato.
Assim como as arestas, hiperarestas também podem ser direcionadas. Nesse caso, a
hiperaresta será um conjunto com dois subconjuntos como elementos, um deles agirá como
origem e os outro será o destinos. Observando inicialmente o caso onde se tem apenas um
elemento na origem/destino, pode-se ter uma situação como da Figura 3.29, onde uma
contrário, haveria duas instâncias de Empresa na aresta e não seria possível essa distinção.
Basta imaginar a instância no exemplo sem as setas e apenas o rótulo do relacionamento.
36
Figura 3.29: Exemplo de hiperaresta direcionada na origem.
Observa-se no esquema da Figura 3.29 que a hiperaresta possui uma origem com uma
instância (Empresa) e dois tipos de seta, uma para Qualificação, preenchida como nas
arestas, e outra voltando para a Empresa, com a seta sem preenchimento. Isso implica,
como apresentado na instância do hipergrafo, que a hiperaresta terá apenas uma Empresa
na origem, mas, no conjunto de destino, existirão várias empresas das quais a origem
participa como sócio, assim como suaQualificação comum para essas sociedades. Isso
também implica na possibilidade de uma Empresa ter várias hiperarestas, com a lista das
Poder-se-ia utilizar um destino único também, como na Figura 3.30, para identicar
qualCliente comprou junto com outros os mesmos títulos de Livro em uma determi-
nada Loja, agrupando clientes com interesses comuns e provável proximidade geográca.
Pela denição dessa hiperaresta, se tem apenas uma loja no conjunto, mas um grupo
de livros e clientes, não necessariamente separando qual livro foi comprado por qual cli-
ente. Novamente é utilizado o diamante nas pontas das origens para indicar a presença
já que existirá apenas uma Loja para cada hiperaresta. Na instância, são apresentados
os livros que Alice e Bob compraram em conjunto na Loja 1. Pela modelagem, Alice
poderia aparecer novamente em uma hiperaresta, como, por exemplo, agrupando os livros
em comum com outro cliente que não tenha títulos em conjunto com Bob, ou mesmo com
compras em uma segunda loja. O motivo para usar a seta preenchida para indicar apenas
limitadas a uma instância tanto em origem como no destino, se iguale à notação da aresta
simples.
37
Figura 3.30: Exemplo de hiperaresta direcionada no destino.
Por m, pode-se estender a ideia de origem e destino para uma hiperaresta direcionada,
grupo de vértices apontando para outro grupo dentro da hiperaresta como apresentado
na Figura 3.31. Como nesse modelo não há limitação nos conjuntos de origem e destino,
Sendo assim, as diversas instâncias de Pessoa e Empresa que são sócias em comuns
diamante nas entidades de origem, e a seta não preenchida nas de destino, na construção
ingressar no conjunto de origem dessa hiperaresta, deverá fazer parte dessas sociedades
também.
38
3.6 Relações N-árias em grafos
Em certas ocasiões, os grafos precisam utilizar um nó intermediário para indicar o
relacionamento entre mais de uma entidade, ou seja, n-ário. Como esse tipo de relacio-
namento é único apenas quando envolve as diversas instâncias, utiliza-se uma técnica já
presente para grafos que consiste em criar um vértice intermediário para agrupar os relaci-
onamentos [32]. Cada vértice de agrupamento indicará uma situação, como exemplicado
na Figura 3.32 para a posse em um cargo público, onde uma Pessoa pode assumir um
Enfatizando também a Data, como apresentado, ela surge como mais uma dimensão
no relacionamento n-ário. Para essa situação, o vértice central cumpre o papel de indicar
No caso de hipergrafos, o fato de uma aresta poder apontar para vários vértices permite
juntar as informações de forma que o vértice de agrupamento pode ser evitado. Alguns
exemplos de relação n-ária já foram apresentados na Seção 3.5 e a Figura 3.33 apresenta
o exemplo da posse em cargo público onde cada hiperaresta inclui todos as instâncias
apresenta novamente o exemplo de Posse, mas agora utilizando hipernós. Foram jun-
tados Cargo, Órgão e Data em um hipervértice para vincular o trio a uma Pessoa. No
esquema, cada trio representa uma Posse, realizada pelo Órgão para o Cargo em uma
Data especíca. As posses se conectam com as instâncias de Pessoa, que também pode
estar em diversas outras posses, caso tenha assumido outros cargos. A instância apresenta
39
Figura 3.33: Exemplo relacionamento n-ário com hipergrafo.
o exemplo anterior, mas agora utilizando o hipernó com identicador 1 para a posse de
pela utilização de um vértice de agrupamento. Isso pode ser vericado na instância, onde
40
Figura 3.35: Simplicando relações com atributos na aresta.
Como já comentado, cada componente foi denido para atender a modelagem das di-
versas estruturas de grafo. Dessa forma, pode-se construir diagramas desde grafos simples
relacionamento de sociedades em cada uma das outras três estruturas de grafos descritas
no Capítulo 2. Isso porque o grafo de atributos possui uma exibilidade que pode levá-lo
41
de um grafo simples a uma estrutura similar ao modelo relacional, através da forma de
organização dos seus atributos, sendo sua avaliação um bom ponto de partida para a
42
Capítulo 4
Banco de Vínculos Simplicado para
Licitações e Sociedades
Este capítulo apresenta o estudo de caso utilizado nessa pesquisa para comparar os
modelos de grafo e relacional, assim como avaliar diversos diagramas utilizando o MDG-
hierárquica, possui uma diretoria ligada diretamente à Secretaria Executiva que auxilia
(DIE) tem como competência subsidiar com informações de inteligência as diversas áreas
da CGU, colaborando com informações para uma melhor tomada de decisão por parte
dos clientes de seus serviços. Uma das atividades da diretoria é tentar identicar indícios
de fraude em processos de licitação. Para isso a DIE reúne e processa dados para gerar
desses processos se relacionam. Essas informações podem estar nas bases internas do
governo no qual seja garantido acesso aos auditores do órgão, ou mesmo públicas, nos
Pessoas ou empresas podem ser utilizadas como entrepostos para mascarar relaciona-
mentos diretos que seriam, no mínimo, conitantes, prejudicando a licitude dos contratos
43
seria de duas empresas que participam do mesmo processo de compra e possuem sócios
com algum parentesco ou relação indireta. Essa seria, no mínimo, uma situação de risco
para a lisura das licitações no órgão, pois essa relação permitiria que o preço fosse acertado
Atualmente, para dar suporte a essa atividade, a diretoria agrupa os dados em bancos
e grande interesse dos órgãos de Controle. O processo de licitação é utilizado pelo Governo
Lei 8.666/93 que descreve as diversas modalidades de licitação, mas para esse trabalho
apenas uma pequena parte será utilizada, pois o objetivo principal não é elaborar um
sistema para o processo de licitação, mas a aplicação do modelo em uma análise dos
Quando algum órgão do governo necessita realizar uma aquisição, este inicia um pro-
cesso de licitação, descrevendo o que se deseja adquirir assim como as demais informações
legais necessárias para garantir a lisura do processo. Como o processo é um tanto oneroso,
vários itens podem ser licitados em conjunto, formando um documento único que deve
ser amplamente publicado. Dessa forma, mesmo que uma licitação relacione vários itens,
cada um será adquirido com certa independência e permitindo que diferentes empresas se
Uma aquisição, por exemplo, de computadores e ativos de rede, pode ser dividida em
dois itens para contemplar cada um dos tipos de equipamento. A empresa interessada
promover a melhor compra pelo poder público. No entanto isso nem sempre acontece,
às vezes por questões técnicas ou de mercado, mas certas vezes por uso de mecanismos
Por essa razão a análise dos relacionamentos entre empresas, sócios e os processos
suspeitos que coloquem em risco uma aquisição. A partir desses vínculos, pode-se também
processo foi fraudado ou mesmo detectar quadrilhas que atuem nesse tipo de crime.
44
combate ao crime organizado [29, 34]. Nessas redes são colocadas diversas pessoas suspei-
las, como telefones, empresas, contas bancárias, cargos públicos, entre outros [38]. Após
a construção da rede, analistas podem analisá-la buscando indícios baseados nas intera-
ções, ou pontos fortes e fracos da rede com o propósito de desarticulá-la [17]. Apesar da
natureza de grafo, a maior parte das informações estão armazenadas em bancos de dados
tado na Figura 4.1. Começar pelo modelo relacional permite partir de uma base sólida e
bem conhecida para então propor e elaborar o modelo de grafos, avaliando suas diferenças
car Empresas e Pessoas vinculadas, e por isso foi colocada em uma tabela separada, ao
invés de compor o grupo de atributos dessas duas entidades. Como cada instância pode
lações societárias.
para o processo de licitação, o qual pode possuir vários itens em um relacionamento 1:N.
45
Figura 4.1: Modelo relacional para o estudo de caso com sociedades e licitações.
assina o contrato com a administração pública. Essa homologação pode ser assinada
por um servidor diferente do responsável pela licitação. Essas relações serão incluídas
46
4.3 Modelos de Dados Baseado em Grafos para o Banco
de Vínculos Simplicado para Licitações e Socieda-
des
Nesta seção é aplicada o MDG-NoSQL para modelar as relações de sociedades nas
modelo completo apenas para o grafo de atributos. Isso porque, como o grafo de atributos
não é tão complexo quanto o hipergrafo e o grafo aninhado, mas também não tão rígido
quanto o grafo simples, se apresenta como um bom ponto de partida para se elaborar
considerações sobre a modelagem de dados em grafos, assim como uma comparação com o
modelo relacional, do qual ele se aproxima, dependendo de como os atributos são tratados.
Os bancos de grafos simples utilizam apenas vértices e arestas cabendo aos rótulos
para grafos simples, considera entidade, representada pelo seu atributo identicador, e os
47
Nota-se no modelo diversos atributos compartilhados como Nome e Data. Os relacio-
namentos entre de Pessoa e Empresa com Nome tem a mesma natureza e por isso usam o
mesmo rótulo. Já a Data se relaciona de forma distinta, indicando o nascimento de uma
com sua Qualificação. Como uma Empresa pode ter sócios do tipo Pessoa ou Empresa,
essas entidades podem aparecer ligadas a várias Sociedades, mas cada Sociedade terá
com Pessoa e Empresa. Como pode-se ligar vários vértices entre si, não é necessário
qualquer entidade entre eles para estabelecer esse relacionamento, contrastando com o
modelo relacional, onde seria necessário uma tabela associativa, como apresentado na
Figura 4.1.
modelo se torna mais normalizado, pois qualquer atributo que poderia ser duplicado
característica também aumenta a quantidade de conexões entre elas por enfatizar os re-
delo, deixando as consultas mais onerosas, pois deve-se buscar os vértices ligados a uma
que certas informações sejam armazenadas próximas aos nós, facilitando a recuperação
do dado, além de simplicar a diagramação do modelo, pois são necessários menos vér-
tices, caso alguns atributos não sejam utilizados para expressar relacionamentos entre as
instâncias.
internaliza seus atributos e indica seus tipos. Sendo assim, informações como Nome e Data
passam a integrar a estrutura do vértice ao invés de se tornarem outro nó.
48
Um Ministério com várias instâncias de Departamento que pode publicar diversos
nessa última entidade, o relacionamento entre ela e Empresa merece um destaque, com-
mente pelo uso das arestas, sem necessidade de algum tipo de vértice intermediário. Essa
semelhantes com tuplas de tabelas. De fato, o uso de atributos pode trazer o diagrama
Isso porque, se todos os atributos forem mantidos juntos aos nós ou arestas, pode-se
49
perder o benefício de enfatizar os relacionamentos. O Nome, por exemplo, que costu-
mam ser colocados como campos nas tabelas, em determinada situação poderiam servir
Nesse caso, mantê-los como vértices seria mais vantajoso que como atributo, pois não
seria necessário varrer todos os vértices em busca dos nomes semelhantes, mas apenas
Tratá-lo como vértice também facilita criar novos vínculos baseados em nomes de família,
pois seria necessário apenas adicionar uma aresta entre dois nomes similares.
Em outro cenário, onde cada Empresa inicialmente tivesse apenas um Telefone, poder-
se-ia mantê-los juntos aos vértices, mas em uma auditoria, ao se perguntar quais empresas
declararam o mesmo telefone, seria necessário varrer os nós como se fossem tuplas em uma
de decidir quais atributos devem ser mantidos nos vértices ou explicitados como vértices
Para apresentar um cenário diferente aos casos de Nome e Telefone, onde manter
o atributo em uma aresta é melhor que torná-la um vértice, basta analisar a entidade
Qualificação do ponto de vista do trabalho de auditoria. Ela é uma situação onde trazer
atributos, ou até mesmo entidades, para dentro de vértices e arestas, pode beneciar as
consultas.
percebe-se que a Qualificação não contribui muito no modelo, estando separada mais
por uma questão de normalização. A Figura 4.4 apresenta um conjunto de instâncias para
duas sociedades distintas que possuem a mesma Qualificação. Para esse exemplo, será
novamente entre a Pessoa A com Empresa Y e Pessoa B com Empresa X. Esse exemplo
está de acordo com o modelo que evidencia o relacionamento entre sócios que possuem
a mesma qualicação e simplica uma busca pelas sociedades, como as do tipo Cotista.
Porém, a forma como foi modelado o problema aumenta a complexidade do grafo com
um maior quantidade de vértices intermediários e que não traz uma informação realmente
Ao invés disso, essa modelagem pode inundar com dados irrelevantes quem procurar
por vínculos entre empresas e pessoas. Isso porque o fato de duas pessoas serem sócias
de empresas diferentes como cotistas é algo muito comum. Dicilmente ambas as pessoas
50
Figura 4.4: Estudo de caso modelado em um grafo de atributos.
serão conhecidas uma da outra e, portanto, dicilmente estarão em conluio para fraudar
este ainda poderá ser o menor caminho entre eles. Isso signica que se for realizada uma
consulta apenas pelos caminhos mais curtos, serão apresentados somente os que passam
por Qualificação, deixando de fora outros mais relevantes, como Sócio, por exemplo.
Além disso, provavelmente não serão comuns consultas como recuperar todas as empresas
com determinada qualicação, mas sim para vericar as qualicações dos sócios de uma
uma Sociedade do que para localizar um vínculo entre instâncias distintas de Pessoa ou
Empresa.
Essa característica da Qualificação sugere que será mais eciente, visando as con-
sultas por vínculos na identicação de fraudes, mover essa informação para um atributo
em uma aresta de sociedade, ao invés de manter o vértice intermediário entre sócio e em-
presa. Essa alteração é apresentada na Figura 4.5, onde o modelo de grafos de atributos
da Figura 4.3 foi alterado para remover o vértice do relacionamento n-ário por meio da
sendo necessários menos saltos para se chegar de um sócio a outro pelos relacionamentos
realmente relevantes. Também foi removido o caminho entre Pessoa e Empresa criado
por Qualificação, que não trazia uma informação de vínculo útil, deixando apenas os
51
Figura 4.5: Estudo de caso modelado em um grafo de atributos com Qualicação como
atributo.
caminhos que realmente podem levar a um relacionamento suspeito entre essas duas en-
tidades.
Por m, no modelo relacional não se pode realizar essa alteração porque o relaciona-
mento M:N de Pessoa e Empresa impõe a tabela intermediaria similar ao vértice n-ário
de Sociedade, mas no grafo ele pode ser evitado caso não exista uma terceira entidade.
Outro ponto a ressaltar é que um vértice a mais no grafo pode gerar novos caminhos,
PessoasSocios e EmpresasSocios.
Um hipergrafo permite que suas arestas liguem mais de dois vértices. Ou seja, a relação
entre seus vértices não precisa ser binária. Isso permite que em certas situações onde o
mesmo relacionamento ocorre entre várias instâncias seja utilizado apenas um arco. A
foi internalizado na hiperaresta SOCIO_DE. Isso porque, como foi visto no Capítulo 3,
alguns vínculos de natureza n-ária podem ser representados com a hiperaresta, como
52
Figura 4.6: Estudo de caso modelado em um hipergrafo sem atributos.
suas empresas com a mesma Qualificação. Dessa forma, se uma Empresa possuir seis
empresas distintas, onde em quatro delas ela é qualicada como administrador e nas
outras duas como cotista, existirão duas hiperarestas no banco de dados em grafos. A
a sócia novamente, mas com a Qualificação de cotista, além de duas outras empresas
sócios do tipo Pessoa, já que é possível separar quem é o sócio e quais são as empresas.
entre essas duas entidades, a hiperaresta foi modelada para aceitar apenas um Telefone,
e as diversas instâncias de Pessoa e Empresa que compartilhem o mesmo número. Sendo
assim, cada número conterá apenas uma hiperaresta com todas as pessoas e empresas que
o utilizem.
os nomes de empresas dicilmente são iguais aos das pessoas, e por isso a maioria das
interseções seriam vazias. Ainda assim, cada Nome mantém em sua hiperaresta a referência
de todos os vértices homônimos, e uma Pessoa ou Empresa estará indicada em apenas
53
um relacionamento com Nome. Esse caso também mostra a diferença entre o diamante,
indicada como (1..1) junto às entidades, pois cada instância delas só podem aparecer em
Data e Empresa, que é apresentado no modelo como uma hiperaresta sem direção com
múltiplas instâncias em ambas as entidades. Ela é possível nesse modelo, sem precisar
porque ambas tratam de eventos sequenciais. Não se pode ter uma data de encerramento
raresta com todas as instâncias de Empresa que possuem datas em comum, e possível de
Por m, o fato de existirem hiperarestas não exclui a possibilidade da estrutura tam-
bém possuir atributos. A Figura 4.7 apresenta uma modicação no modelo para exempli-
no grafo de atributos.
a análise de quais atributos precisam ser enfatizados ou não, de forma parecida com a
hiperarestas. O modelo da Figura 4.7, por exemplo, foi alterado para que a hiperaresta
SOCIO_DE contenha uma origem com todos os sócios, Empresa ou Pessoa, com a mesma
54
4.3.4 Grafo Aninhado e Hipervértice
que representa um subgrafo. Dessa forma, pode-se agrupar vários vértices e hipervérti-
ces, dando a eles signicados mais amplos, como Pessoa, QuadroSocietario e Empresa,
conforme é apresentado na Figura 4.8.
Para esse modelo, Pessoa e Empresa são construídos como hipervértices. No caso
hipervértice indica que apenas uma subgrafo comporá sua estrutura, e o rótulo dene
que o tipo que identicará o hipervértice será um inteiro. Sendo assim, uma instância de
Pessoa será um hipervértice, com Nome e Data, identicado por um valor inteiro.
também utiliza apenas um subgrafo com essa topologia, assim como um número inteiro
como identicador.
las como se fossem vértices comuns de um grafo. Sendo assim, ambas as entidades fo-
55
ser construído utilizando essas estruturas, como mostra a topologia do hipervértice de
QuadroSocietario.
A função do QuadroSocietario é agrupar todos os subgrafos que descrevem um relaci-
ticador único e todos os sócios, sejam de Pessoa ou Empresa, que compõem o quadro
grafos, que apesar de possuir diversas propostas na literatura, nenhuma buscou atender
a abstração dos conceitos de grafo, mas focou em soluções especícas de suas iniciativas.
Dessa forma, o MDG-NoSQL foi elaborado com o objetivo de ser simples, generalista,
Possui uma notação para uso em grafos de características simples, com atributos,
Suporte à tipagem para atributos e rótulos nos vértices e arestas, além de notação
Suporte à cardinalidade.
antes de iniciar uma implementação, dando ênfase aos esquemas dos dados ao invés de
Embora a notação seja voltada para esquemas, isso não exclui a possibilidade de se
exemplicar utilizando grafos com instância, como utilizado diversas vezes no detalha-
modelo para um nível mais general, e não apenas uma situação especíca.
1 http://dia-installer.de/
56
Dessa forma, apesar dos diagramas serem grafos, o MDG-NoSQL pode ser considerado
um metagrafo, ou seja, um grafo que fala sobre outro grafo, sendo o primeiro a abstração
em grafo. Isso signica que os vértices e arestas da notação denirão as regras do que
será inserido no banco físico, o que inclui tipagem dos dados, tanto dos rótulos como de
atributos, quando existentes. Ele também permite entender como os caminhos no grafo
poderão se formar, já que especica quais entidades estão conectadas e em qual direção.
Porém, nos grafos, ela indica qual a quantidade de arestas se espera que uma instân-
cia tenha para um relacionamento especíco. Ou, detalhando de outra forma, pode-se
vértice.
do modelo de dados.
No modelo relacional, as entidades são mapeadas em tabelas que agrupam seus atri-
único e não nulo que existe como atributo de uma entidade. Quando implementada, cada
tupla pode ser identicada pela sua chave primária. Quando se fala de uma entidade
Pessoa, por exemplo, tem-se a ideia, no modelo relacional, de uma tabela que conterá
uma chave única, um nome e endereço em cada instância. Ao denir uma outra entidade
chamada Empresa, essa também poderá materializar uma tabela com atributos semelhan-
tes. Mesmo que o domínio das chaves seja o mesmo, não ocorrerá colisões, pois cada chave
Em um grafo, os tipos principais das instâncias armazenadas são nós ou arestas. Sendo
assim, antes de uma instância no banco de grafos ser Pessoa ou Empresa, será um vértice
ou aresta. Isso signica que deve-se ter um identicador único para cada instância, inde-
pendente da entidade ao qual ela pertença, ou pode ser necessário adicionar mecanismos
para garantir unicidade nos nós do grafo a ser modelado. A Figura 4.9 exemplica essa
ideia entre os dois tipos de modelagem. Observa-se que as instâncias no modelo relacional
possuem o mesmo identicador, mas a forma de organizar os dados por tabela permite
distingui-las.
57
Figura 4.9: Comparativo entre tuplas de tabelas e vértices.
Na Figura 4.9, cada vértice é identicado pelo campo ID e não se pode trazer os dados
simplesmente aproveitando as chaves para esse campo, pois as mesmas entrariam em con-
ito. Dessa forma, os valores de ID podem ser criados de forma sequencial, por exemplo,
e colocar os campos que eram chave como atributos indexados dentro dos vértices.
Alguns bancos de grafos permitem utilizar os rótulos para separar os vértices como se
fossem tabelas, fazendo com que um rótulo Pessoa em um vértice indique que este está no
grupo dos nós de pessoas. Outros podem utilizar classes da linguagem orientada a objetos.
no banco de grafos.
países ou parentescos entre pessoas. Ligar dois vértices por uma aresta signica indicar
esses relacionamentos. Porém, algumas vezes, esses relacionamentos podem não car
além de uma chave ou rótulo sejam armazenadas junto com os vértices, mas algumas
Por exemplo, para vericar as empresas que são abertas no mesmo ano e mês, pode-se
varrer os vértices de forma similar ao que é feito nas linhas de uma tabela, mas com isso
Sendo assim, o modelo pode ser modicado para remover o atributo ano e mês, criando
um vértice independente de AnoMes, que será ligado a PessoaJuridica por uma aresta
indicando seu relacionamento, como apresentado na Figura 4.11. Isso faz com que a
58
Figura 4.10: Exemplo de vértices com ano e mês da abertura como atributo.
ligação entre as duas instâncias pela data seja evidenciado, formando um caminho entre
elas.
Pode parecer estranho ter um conjunto de vértices no modelo exclusivo para informa-
ções como Data, ou mesmo Nome, já que o mais comum é que essas informações sejam
armazenadas como atributos. Entretanto, como uma das vantagens dos grafos é enfatizar
Dessa forma, ao se procurar por empresas que foram abertas nesse período, pode-
se buscar o vértice de ano e mês desejado, assim como todas as empresas que possuem
arestas apontando para esse vértice de AnoMes. Se for necessário vericar se existe um
relacionamento entre elas por meio da data, também se pode caminhar entre elas por esse
vértices (transformando o atributo em uma ponte). Porém, existem situações onde pode
59
4.4.3 Relações Binárias de M:N em Grafos são Diretas
Uma vez que os vértices podem se conectar a diversos outros nós, um grafo pode
um grafo.
Nesse exemplo de instâncias para sociedade, várias pessoas podem possuir múltiplas
empresas e estas também podem ter diversos sócios, como a Pessoa A que é sócia das
empresas A, B e C. Já a Empresa C possui mais dois sócios, a Pessoa B e Pessoa C,
enquanto a Empresa B tem como sócio a Pessoa A e C. Ou seja, os relacionamentos já
dados em grafos, caso um relacionamento passe de 1:N para M:N, pois signicará apenas
a permissão para que mais de uma aresta do mesmo tipo de relacionamento se conecte
a outra entidade. Diferentemente do modelo relacional onde seria necessário criar mais
Por m, entre as vantagens de se utilizar estruturas de grafos, percorrer caminhos entre
as interligações das instâncias é uma das principais. Muito do estudo de grafos introduz
diversos algoritmos e aplicações para realizar essa caminhada [10]. Como é apresentado
60
modelagem em grafos, a ideia de como os vértices podem ser percorridos deve sempre ser
considerada.
61
Capítulo 5
Implementação do Modelo do Estudo
de Caso
O presente capítulo utiliza uma implementação para análise comparativa entre consul-
de atributos da Figura 4.5 (Subseção 4.3.2). Após a execução e comparação dessas duas
butos utilizando tabelas, ou seja, um banco de dados relacional com uma tabela para
armazenar vértices e outra para arestas, além de duas tabelas utilizadas para manter os
atributos. Esse terceiro modelo permitiu criar uma abstração para implementar a parte
5.1 Escopo
Em relação à escolha do modelo de grafos, a estrutura de grafo de atributos foi escolhi-
sociedades e licitações; permitirem uma comparação mais direta com o modelo relacional;
chamado Neo4j, que implementa o Cypher , uma linguagem declarativa especializada que
Dessa forma, foi preparado um ambiente composto por uma máquina de 64GB de
CentOS 6 para a execução dos dois SGDBs, alternadamente. Para o modelo relacional,
foi utilizado o banco MySQL e a linguagem padrão SQL. Para o banco de grafos, foi
62
escolhido o Neo4j, com uma linguagem também declarativa chamada Cypher orientada
processo de licitação, foram realizadas três consultas em cada um dos bancos. Como as
fraudes nesses processos dependem de coluio entre empresas por meio dos seus sócios, as
questões foram elaboradas para tentar identicar esses vínculos, conforme destacado em
seguida.
A primeira questão procura vericar se o contrato de telefone não está sendo com-
partilhado por mais de uma empresa. Caso seja, provavelmente os sócios das empresas
se conhecem, ou são os mesmos, e podem utilizar ambas as empresas para forjar uma
Essa consulta é uma continuação da questão anterior em uma investigação, pois se fo-
licitações em conjunto.
A última questão procura identicar relacionamentos entre os sócios. Caso não seja
encontrado um vínculo por telefone, os sócios de uma empresa ainda podem estar relaci-
Por m, após as consultas nos bancos com as modelagens selecionadas, foi implemen-
tado no banco relacional o modelo com tabelas de vértices e aresta para vericar como
tos implementado sobre um banco de dados relacional. Por m, foram feitas algumas
lhar sobre tabelas. A questão que surge ao tentar realizar consultas típicas de grafos é se
63
ambos se comportam de forma aceitável para a manipulação dos dados. Pode-se tratar
as duas primeiras consultas do escopo como travessias com apenas dois saltos da origem.
consulta já é uma travessia mais complexa entre os nós do grafo e busca atingir, a partir
Para realizar as consultas, foram gerados dados ctícios para alimentar o modelo a
pessoas assim como algumas centenas de itens de licitação. As relações foram em sua
maioria randomizadas e apenas algumas delas foram inseridas para garantir a existência
de alguns relacionamentos, como empresas ligadas até o terceiro nível de sociedade por
empresas.
Para o comparativo com um banco de grafos, foi escolhido Neo4j. Ele é um banco que
utiliza a estrutura de atributos e possui uma linguagem de consulta chamada Cypher [32].
foi decidido por utilizá-lo para avaliar como uma consulta especializada em grafos pode
Para obter esse relacionamento foi feita a junção ( JOIN ) entre a tabela associativa
está a direita da projeção na consulta, e qual está a esquerda, ligadas pelo relacionamento
de Telefones.
1 SELECT
2 CL . nome_empresa as empresaA ,
3 T. numero_telefone ,
4 CR . nome_empresa as empresaB
5 FROM EmpresasTelefones AS CT01
6 INNER JOIN Empresas AS CL
7 ON CL . pk_empresa = CT01 . fk_empresa
8 INNER JOIN Telefones AS T
9 ON T. pk_telefone = CT01 . fk_telefone
10 INNER JOIN EmpresasTelefones AS CT02
11 ON CT02 . fk_telefone = CT01 . fk_telefone
12 INNER JOIN Empresas AS CR
13 ON CR . pk_empresa = CT02 . fk_company
14 WHERE CT01 . fk_empresa <> CT02 . fk_empresa ;
64
Também foi necessário um alias para juntar os Telefones em comum na linha 10.
Isso porque a primeira referência para essa tabela já estava denida para uma em-
rão linhas onde a empresa da esquerda será igual a da direita, o que pode ser evitado com
para a Empresa A com G, por exemplo. A medida que as outras empresas vão sendo
desenvolvida para o Neo4j, basta especicar a origem, nesse caso uma Empresa qualquer
< e > como setas junto ao hífen no relacionamento. Ou seja, para a consulta dos telefo-
nes de uma Empresa, tem-se pelo modelo um relacionamento com sentido de Empresa para
Telefone, e por isso utiliza-se a estrutura empresaO: Empresas -[r:TEM_NUMERO*1..2]-
> telefoneD: Telefone. Isso implica em buscar esse padrão de grafo (Empresa->Telefone)
e retornar as instâncias correspondentes. Caso fosse escrito com o sentido oposto empresaO:
65
Porém, o Cypher permite que se omita os símbolos de direção da aresta, considerando
relacionamento em bidirecional.
ser avaliados para se chegar a uma empresa. Como temos apenas telefone entre elas para
esse vínculo, serão dois saltos entre uma empresa e outra, indicada na consulta por *1..2.
Por m, o resultado é retornado através da cláusula RETURN , indicando que de-
vem ser obtidos as duas empresas e os relacionamentos entre elas. O resultado nal é
Como foi retornado o grafo de empresas que se relacionam por telefones, a interface
apresenta tanto os vínculos de empresas por telefone, como as sociedades que existem entre
66
essas empresas. Isso porque o banco retornou para a interface de consulta, as empresas e
como os demais relacionamentos que essas instâncias possuem entre si, como no caso de
sociedade. Isso não signica que existam apenas esses sócios, mas que para essas empresas
Como os bancos de grafos já trabalham com essa estrutura de vértices e arestas por
padrão, buscas voltadas para encontrar caminhos nos relacionamentos se tornam mais
simples. Esse exemplo já demonstra como a consulta especializada em grafos pode facilitar
reram juntas?
A Consulta 5.3 é parecida com a Consulta 5.2. Porém, nesse caso, deseja-se todos os
útil porque se elas tiverem algum relacionamento como por telefone ou sócios, a parti-
cipação em conjunto pode indicar uma tentativa de fraudar a licitação utilizando preços
Limitando para duas empresas especícas, estabelece-se uma origem e destino. Essa
restrição é apresentada na linha 18 vindo após a clausula WHERE . Como foi denido o
sentido da relação, as linhas da tabela não serão duplicadas com o caminho inverso.
Na Consulta 5.3 seria possível apenas realizar a junção entre as relações utilizando
empresas aparecem juntas. Porém, para uma maior quantidade de dados, esse trabalho
seria oneroso e algum processamento adicional seria necessário para entregar a informação
nal.
Como o objetivo nessa etapa é utilizar o modelo relacional para apresentar os vínculos
1 SELECT
2 CL . nome_empresa as empresaB ,
3 pk_item_licitacao ,
4 fk_licitacao ,
5 numero_item ,
6 descricao_item ,
7 CR . nome_empresa as empresaC
67
8 FROM Participantes AS A01
9 INNER JOIN Empresas AS CL
10 ON CL . pk_empresa = A01 . fk_empresa
11 INNER JOIN Itens_licitacoes AS PI
12 ON PI . pk_item_licitacao = A01 . fk_item_licitacao
13 INNER JOIN Participantes AS A02
14 ON A02 . fk_item_licitacao = A01 . fk_item_licitacao
15 INNER JOIN Empresas AS CR
16 ON CR . pk_empresa = A02 . fk_empresa
17 WHERE A01 . fk_empresa <> A02 . fk_empresa
18 AND CL . nome_empresa = ' EMPRESA B ' AND CR . nome_empresa = ' EMPRESA C ';
Partindo para o modelo de grafos, similarmente ao que foi visto na Questão 1 para
Telefone, temos um conjunto de elementos que podem vincular duas outras instâncias
68
Consulta 5.4: Busca de empresas relacionadas por itens utilizando o Cypher.
MATCH ( empresaB { nome : ' EMPRESA B '}) -[ r: CONCORRE_POR *1..2] - ( empresaC { nome : '
EMPRESA C '})
RETURN empresaB , r , empresaC
O resultado é uma nuvem de itens com os diversos vínculos entre as duas empresas
como apresentado na Figura 5.4. Ambas as participantes foram colocadas nas extremida-
des opostas do grafo para ressaltá-las, assim como também os itens que elas disputaram.
Sendo assim, ambas as empresas concorreram por 27 itens, o que pode ser um indício de
acordo de preço, caso seja conrmado os vínculos societários entre elas. Da mesma forma
Figura 5.4: Resultado da consulta para empresas por itens de licitação no Neo4j.
e por isso retorna vários vértices e arestas que atendam o padrão, assim como os demais
relacionamentos entre eles. Outra forma de consultar os casos onde se tem origem e
69
destino, é dizer ao banco para procurar pelos menores caminhos entre os dois nós ao invés
de procurar um padrão. Isso pode melhorar o tempo de resposta, já que o banco utilizará
um algoritmo de grafos especíco para essa busca, ao invés de buscar por um padrão de
grafo. A resposta pode ser ainda mais rápida se a necessidade for de localizar apenas um
A Consulta 5.5 realiza a busca pelos menores caminhos e obtém o mesmo resultado
da Figura 5.4, já que todos os caminhos para ambas as consultas tem o mesmo tamanho
de 2 saltos.
Consulta 5.5: Busca de empresas relacionadas por itens utilizando menor caminho.
MATCH p = allShortestPaths (( o: Empresas { nome :" EMPRESA B" }) -[r: CONCORRE_POR *..2] -( d
: Empresas { nome :" EMPRESA C" }) ) RETURN NODES (p )
Para questões de apenas um salto, percebe-se que não existem muitas diculdades em
dade da pesquisa nos relacionamentos, a vantagem de se utilizar grafos ca mais evidente,
O objetivo dessa consulta é identicar se duas empresas estão relacionadas até um certo
dessa consulta e outras da literatura como a de amigos de amigos[32], porém essa leva
Empresa e Empresa-Empresa).
Como uma Empresa pode ter sócios tanto das entidades de Pessoa como Empresa,
ambas as sociedades devem ser utilizadas. Dessa forma, buscamos, a partir de uma
das empresas, seus sócios para então localizar as demais empresas no qual eles também
são sócios. Se uma delas for igual a outra empresa alvo, esse relacionamento deve ser
retornado.
Foi denido que a procura seria feita até o terceiro nível de Empresa para permitir
uma melhor avaliação do problema, mas sem se tornar complexo demais para executar.
Realizar uma busca até o terceiro nível de Empresa signica que se partirá de uma das
empresas alvo, considerada nível raiz, buscando a cada nível de sociedade abaixo da raiz
a segunda empresa alvo até que seja encontrada ou atingido a terceira Empresa na cadeia
de sócios/empresas.
70
A Figura 5.5 apresenta uma árvore com as possibilidades de desdobramentos para
essa questão. Uma empresa alvo é colocada no topo como raiz. Essa pode possuir um
sócio do tipo Pessoa, no ramo esquerdo, ou uma outra Empresa, no ramo direito. Como
uma Pessoa possui relacionamento de sociedade apenas com empresas, o próximo nível do
ramo esquerdo será obrigatoriamente uma Empresa. Já para o ramo direito, uma Empresa
caminho. A árvore então segue até que cada caminho atinja três empresas abaixo da raiz.
Figura 5.5: Árvore de consulta para duas empresas por sócios até a terceira empresa.
A árvore dessa questão demonstra como a busca no banco deverá ser mais complexa
que as outras duas, pois será necessário cobrir vários níveis com alternâncias e junções
diferentes, assim como suas projeções. Observando a Figura 5.6, a parte mais a esquerda
da árvore foi destacada para ilustrar a maior profundidade que a busca pode chegar.
Apesar de serem necessários apenas três empresas após a raiz, esse maior ramo da árvore
Esse ramo mais profundo recupera todos os sócios do tipo Pessoa e as demais Empre-
sas nas quais eles são sócios. Segue-se dessa forma até atingir a terceira empresa ou os seis
níveis de profundidade. Apenas esses ramos podem ser obtido a partir da Consulta 5.6.
71
Figura 5.6: Destaque do primeiro ramo da árvore de consulta para duas empresas por
sócios.
1 SELECT
2 C01 . nome_empresa ,
3 P01 . nome_pessoa ,
4 C02 . nome_empresa ,
5 P02 . nome_pessoa ,
6 C03 . nome_empresa ,
7 P03 . nome_pessoa ,
8 C04 . nome_empresa
9 FROM PessoasSocios AS PP01
10 INNER JOIN Empresas AS C01 -- Inicio das 12 juncoes .
11 ON C01 . pk_empresa = PP01 . fk_empresa
12 INNER JOIN Pessoas AS P01
13 ON P01 . pk_pessoas = PP01 . fk_pessoa_socio
14 LEFT JOIN PessoasSocios AS PP02
15 ON PP02 . fk_pessoa_socio = P01 . pk_pessoa
16 LEFT JOIN Empresas AS C02
17 ON C02 . pk_empresa = PP02 . fk_empresa
18 LEFT JOIN PessoasSocios AS PP03
19 ON PP03 . fk_empresa = C02 . pk_empresa
20 LEFT JOIN Pessoas AS P02
21 ON P02 . pk_pessoa = PP03 . fk_pessoa_socio
22 LEFT JOIN PessoasSocios AS PP04
23 ON PP04 . fk_pessoa_socio = P02 . pk_pessoa
24 LEFT JOIN Empresas AS C03
72
25 ON C03 . pk_empresa = PP04 . fk_empresa
26 LEFT JOIN PessoasSocios AS PP05
27 ON PP05 . fk_empresa = C03 . pk_empresa
28 LEFT JOIN Pessoas AS P03
29 ON P03 . pk_pessoas = PP05 . fk_pessoa_socio
30 LEFT JOIN PessoasSocios AS PP06
31 ON PP06 . fk_pessoa_socio = P03 . pk_pessoa
32 LEFT JOIN Empresas AS C04
33 ON C04 . pk_empresa = PP06 . fk_empresa -- Fim das 12 juncoes
34 WHERE C02 . pk_empresa <> C01 . pk_empresa
35 AND C02 . pk_empresa <> C03 . pk_empresa
36 AND C01 . pk_empresa <> C03 . pk_empresa
37 AND C04 . pk_empresa <> C01 . pk_empresa
38 AND C04 . pk_empresa <> C02 . pk_empresa
39 AND C04 . pk_empresa <> C03 . pk_empresa
40 AND P02 . pk_pessoa <> P01 . pk_pessoa
41 AND P03 . pk_pessoa <> P01 . pk_pessoa
42 AND P03 . pk_pessoa <> P02 . pk_pessoa
43 AND (( C01 . nome_empresa = ' EMPRESA B ' AND C02 . nome_empresa = ' EMPRESA C ')
44 OR ( C01 . nome_empresa = ' EMPRESA B ' AND C03 . nome_empresa = ' EMPRESA C ')
45 OR ( C01 . nome_empresa = ' EMPRESA B ' AND C04 . nome_empresa = ' EMPRESA C '));
mentos recursivamente a partir de um banco de dados relacional. Indo até seis níveis,
tado dessa consulta é apresentado na Figura 5.7, com a Empresa B como raiz no primeiro
campo da projeção da consulta, e a Empresa C podendo aparecer em quaisquer dos outros
campos retornados. Ressalta-se que este é apenas um dos ramos para vericar se existe
duas empresas pelos seus sócios, independente de serem pessoas ou outras empresas. Da
mesma forma que as demais consultas, sociedade e empresa seguem um sentido, e por isso
Como foi apresentado na árvore das Figuras 5.5 e 5.6, pode-se descer até o sexto nível
da árvore, e por isso foi especicado esse nível utilizando-se a restrição E_SOCIO*1..6
na Consulta 5.7. Diferente do modelo relacional, a busca em um grafo permite utilizar
apenas uma consulta para passar por todos os caminhos desejados, retornando sequencias
73
Figura 5.7: Resultado da consulta de sócios para o primeiro ramo no MR.
Consulta 5.7: Busca relacionamentos entre duas empresas por sócio utilizando o Cypher.
MATCH ( empresaB { nome : ' EMPRESA B ' }) -[r: E_SOCIO *1..6] - ( empresaC { nome : '
EMPRESA C ' })
RETURN empresaB , r , empresaC ;
foram postas em lados opostos para facilitar a leitura. Pode-se ver no resultado os ca-
minhos que passam por empresas encadeadas, da mesma forma que alternados entre as
Esse resultado é devido à busca pelo padrão de grafo em que estejam as duas empresas
em até seis saltos de distância entre elas, capturando todos os vértices dos caminhos entre
elas. Embora o resultado traga diversas informações sobre quem está relacionado entre
elas, ao se aumentar o tamanho do grafo pode ser tão trabalhoso para o banco de grafos
trazer esse padrão com todos seus vértices quanto para o relacional realizando as junções.
Porém, pode-se tirar proveito da estrutura de grafos, assim como apresentado na Con-
sulta 5.5. Ao invés de se consultar pelo padrão do grafo, pode-se buscar pelos menores
caminhos entre as Empresas B e C, para identicar como elas se relacionam sem ne-
74
Figura 5.8: Resultado da consulta para sócios de empresas no Neo4j.
Consulta 5.8: Busca de vínculos entre duas empresas por sócio utilizando menores cami-
nhos.
MATCH p = allShortestPaths (( o: Empresas { nome :" EMPRESA B" }) -[r: E_SOCIO *..6] -( d:
Empresas { nome :" EMPRESA C" }) ) RETURN NODES (p)
consulta de Licitações, o grafo retornado foi simplicado a dois nós. Isso porque existe
distância, apenas ele foi retornado, destacando a sociedade direta entre as empresas, que
vantagem para o banco de grafos. Não existe uma função equivalente na linguagem SQL
e dessa forma seria necessário construir uma função ou procedimento que implementasse
essa procura entre as tabelas. Já o banco de grafos pode tratar esse tipo de operação
Das consultas apresentadas, a por sociedade é a que permite visualizar o maior con-
traste entre utilizar o banco relacional com SQL e um banco de grafos com uma linguagem
75
Figura 5.9: Resultado da consulta para sócios de empresas no Neo4j com menor caminho.
zada pode contribuir com a busca de vínculos entre entidade de forma muito mais exível
que o modelo relacional. Ainda que não considerando as questões de forma de armazena-
de grafo, ou seja, utilizando tabelas para armazenar vértices e arestas, supondo que a
abstração das entidades possa simplicar a consulta. Trabalhos como o de Vicknair [37],
Ruin et al [33] e Batra [5] zeram comparativos entre bancos de grafos e relacionais, mas
teriores, foi construído uma abstração dos grafos de atributos, com a mesma estrutura
utilizada no banco de grafos selecionado. Sendo assim, ao invés de criar as relações base-
adas nas entidades do domínio de Pessoas e Empresas, o modelo relacional terá apenas
O objetivo na construção desse modelo é vericar se ele pode simplicar as buscas por
relacionamentos. Entretanto, foi realizada apenas a consulta para a terceira questão, pois
76
considerou-se que esta, por ser mais complexa, já seria suciente para avaliar a adaptação.
A Figura 5.10 apresenta o modelo relacional proposto. Ele possui uma tabela para vér-
tices e outra para as arestas. Ambas possuem uma chave além de um campo para rótulo.
podendo inclusive possuir duas conexões para o mesmo par, considerando a necessidade
tanto dos vértices como das arestas, sendo permitido vários atributos para ambos, desde
Para esse modelo, quando se desejar incluir uma Empresa, essa deve ser inserida na
tabela de vértices, com o atributo de nome na relação de atributos, ligando-as pela chave
rótulo, como sócio administrado, pode-se utilizar os atributos sem necessidade de criar
uma tabela de qualicação. Apesar dos atributos poderem car em uma tabela apenas
utilizando um campo de tipo para separar quais são de vértices e quais são de arestas, foi
e realizada a Consulta 5.9. Observa-se que para essa consulta foi necessário utilizar o ar-
está sempre no atributos fk_vertexA, não teremos pessoas em fk_vertexB, sendo assim,
na passagem do segundo grupo de junções para o terceiro ocorrerá uma exclusão do en-
77
Consulta 5.9: Consulta de sócios utilizando um grafo modelado em banco relacional.
1 SELECT DISTINCT
2 companyStart . pk_vertice AS empresaInicialPk ,
3 companyStart . rotulo AS rotuloEmpresaInicial ,
4 ' E_SOCIO ' AS edgeLabel01 ,
5 VT01 . pk_vertice AS alvo01 ,
6 VT01 . rotulo AS rotulo01 ,
7 E01 . rotulo AS arestaRotulo01 ,
8 VT02 . pk_vertice AS alvo02 ,
9 VT02 . rotulo AS rotulo02 ,
10 E02 . rotulo AS arestaRotulo02 ,
11 VT03 . pk_vertice AS alvo03 ,
12 VT03 . rotulo AS rotulo02
13 FROM vertices AS empresaInicial
14 INNER JOIN arestas AS E00 ON empresaInicial . pk_vertice = E00 . fk_verticeB
15 INNER JOIN verticesatributos AS empresaInicialAtr
16 ON empresaInicialAtr . fk_vertice = empresaInicial . pk_vertice
17 LEFT JOIN vertices AS VT01
18 ON VT01 . pk_vertice = E00 . fk_verticeA
19 LEFT JOIN verticesatributos AS VATTT01
20 ON VATTT01 . fk_vertice = VT01 . pk_vertice
21
22 LEFT JOIN arestas AS E01
23 ON ( VT01 . pk_vertice = E01 . fk_verticeA OR VT01 . pk_vertice = E01 . fk_verticeB )
24 LEFT JOIN vertices AS VT02
25 ON ( VT02 . pk_vertice = E01 . fk_verticeA OR VT02 . pk_vertice = E01 . fk_verticeB )
26 LEFT JOIN verticesatributos AS VATTT02
27 ON VATTT02 . fk_vertice = VT02 . pk_vertice
28
29 LEFT JOIN arestas AS E02
30 ON ( VT02 . pk_vertice = E02 . fk_verticeA OR VT02 . pk_vertice = E02 . fk_verticeB )
31 LEFT JOIN vertices AS VT03
32 ON ( VT03 . pk_vertice = E02 . fk_verticeA OR VT03 . pk_vertice = E02 . fk_verticeB )
33 LEFT JOIN verticesatributos AS VATTT03
34 ON VATTT03 . fk_vertice = VT03 . pk_vertice
35
36 WHERE empresaInicial . rotulo = ' EMPRESAS '
37 AND empresaInicialAtr . valor = ' EMPRESA B '
38 AND ( VATTT01 . valor = ' EMPRESA C '
39 OR VATTT02 . valor = ' EMPRESA C ' OR VATTT03 . valor = ' EMPRESA C ')
40 AND VT02 . pk_vertice <> VT01 . pk_vertice
41 AND VT03 . pk_vertice <> VT01 . pk_vertice
42 AND VT03 . pk_vertice <> VT02 . pk_vertice ;
Se for utilizada uma junção após o segundo grupo para pessoas, a consulta perderá
sua generalização para se aproximar da Consulta 5.6, onde uma forma de se evitar essa
78
bidirecionais, o que seria equivalente a manter duas arestas para representar a bidireci-
que nessa situação não se precise criar uma consulta para cada ramo da Figura 5.5.
armazená-lo como tabelas, além da necessidade de manter dois registros para indicar a
uma modelagem e implementação mais adequada e vantajosa para domínios que possam
mas utilizando apenas a Consulta 5.6, referente ao ramo mais longo da árvore ilustrada
na Figura 5.6.
grafos Neo4j, utilizados alternadamente para evitar concorrências de recursos entre eles.
no MySQL foi realizada utilizando um programa proprietário para ETL de dados. Ela foi
Já para o Neo4j, foi necessário exportar os dados de sociedades para um arquivo e quebrá-
caso de arquivos, pode-se também ler uma coleção de arquivos com a mesma estrutura,
diminuindo o uso da memória. Através desse sistema foi possível carregar as informações
Figura 5.11. Ele descreve a estrutura de grafo que será carregada, denindo, além da
79
origem e destino das informações, que campos que comporão a estrutura dos vértices e
arestas. Os relacionamentos são indicados nas arestas a partir dos rótulos dos vértices
de origem e destino. Dessa forma, cada campo de uma linha carregada é utilizada na
O programa foi desenvolvido para facilitar a carga e funciona com o conceito de tarefa.
quatro tags : destino (destination), fonte de dados (source), vértice (vertex) e aresta
(edge). A tag de destino indica para qual banco serão transferidas as informações, a
ideia é permitir a carga em diferentes bancos de dados em grafo. Para o Neo4j, deve-
consultada as informações. Como a fonte pode possuir muitos registros e não permitir
a carga de uma vez por questões de memória física da máquina, o arquivo pode ser
criado sem cabeçalho e desmembrado em diversos outros arquivos com a mesma estrutura.
Isso permite o uso das opções de múltiplos arquivos (multiFiles) e cabeçalho (header)
indicando, respectivamente, que deverão ser lidos todos os arquivos do diretório com o
Para o mapeamento dos nós, a tag vértice (vertex) é utilizada, já indicando seu rótulo
e quais serão os atributos. Caso se tenha que denir dois vértices da mesma entidade,
como apresentado na Figura 5.11, o rótulo deverá assumir outro valor, referenciado pos-
teriormente para as arestas, utilizando-se a opção aliasFor para indicar o rótulo real
da entidade. Já para os arcos, a tag arestas (edge) mapeia quais são os relacionamentos
80
entre os vértices, utilizando a opção label para indicar o relacionamento, assim como
como para as arestas, a tag mapa (map) é utilizada para especicar os atributos, que podem
Depois dos dados carregados em ambos os bancos, foi realizada a consulta com o banco
frio, ou seja, logo após a inicialização do SGDB para evitar inuência do cache. Foram
escolhidas duas empresas que apresentaram uma quantidade aproximada de 400 vínculos
72.608,949 s
societários para realizar a consulta utilizando-as como origem e destino.
nou um relacionamento com seis saltos de profundidade. Ele foi o único vínculo alternando
entre os sócios Pessoa e Empresa, utilizando-se até seis saltos. Sendo assim, a busca no
banco de dados em grafo deve retornar ao menos esse resultado quando consultado.
padrão do grafo como na Consulta 5.7, o mesmo não conseguiu realizá-la retornando
localizar todas as ligações possíveis que podem estar entre as duas empresas (Empresa-*-
se existe relação entre duas empresas em até seis saltos, não sendo necessário trazer todo
menores caminhos entre elas. Dessa forma, foi realizada a pesquisa por menor caminho
369 ms
obtendo-se o resultado da Figura 5.12, referente ao mesmo vínculo retornado no banco
busca de vínculos.
também que pesquisas que seriam complexas de se realizar em uma estrutura podem ser
do uso de grafos.
81
Figura 5.12: Resultado da consulta de sócios no Neo4j.
82
Capítulo 6
Conclusão
Esta pesquisa apresentou o Modelo de Dados para Bancos NoSQL Baseados em Grafos
atende o modelo de dados para grafos simples, de atributos, hipergrafos e aninhados. Para
isso, ele dene uma notação principal para os elementos de vértice e aresta, além de suas
de diagramação, sendo que, para a construção dos diagramas desse trabalho, foi utilizada
entendimento.
Após sua apresentação, o MDG-NoSQL foi utilizado para modelar Banco de Víncu-
comparação das duas abordagens permitiu vericar como cada modelo se comporta a al-
outro em grafos. Esses dados permitiram avaliar, qualitativamente, como podem ser
foram limitadas a três situações comuns no contexto do estudo de caso. Após a análise
dessas consultas, foi possível perceber a vantagem do banco de dados em grafos para
buscar vários sócios entre duas empresas, caram mais simples no ambiente de grafos,
83
Também foram avaliadas algumas características de carga e consulta sobre as imple-
mentações de grafo e relacional, utilizando uma massa de dados reais. Apesar do processo
de carga ter sido simples no banco relacional, para o banco de dados em grafo foi neces-
sário o desenvolvimento de um programa para facilitar a carga dos dados, devido a falta
programa utiliza o conceito de tarefa, descrita em um arquivo XML, que mapeia vértices
Finalizada a carga dos dados, foi possível vericar algumas diferenças de desempenho
entre as duas abordagens, assim como na forma de construção das consultas para busca
Por m, percebe-se que diversas pesquisas ainda podem ser realizadas a partir do
e alternando para proposta dos bancos NoSQL de tratar quantidades de dados cada vez
volumes cada vez maiores de informações, que no contexto de grafos, se reete em vértices
tecnologias.
84
Capítulo 7
Anexos
7.1 Anexo I
Consulta 7.1: Consulta de empresas que concorreram a licitações.
1 SELECT
2 C01 . company_name ,
3 P01 . name_person ,
4 C02 . company_name ,
5 P02 . name_person ,
6 C03 . company_name ,
7 C04 . company_name
8 FROM people_partners AS PP01
9 INNER JOIN companies AS C01
10 ON C01 . pk_company = PP01 . fk_company
11 INNER JOIN people AS P01
12 ON P01 . pk_person = PP01 . fk_person_partner
13 INNER JOIN people_partners AS PP02
14 ON PP02 . fk_person_partner = P01 . pk_person
15 INNER JOIN companies AS C02
16 ON C02 . pk_company = PP02 . fk_company
17 LEFT JOIN people_partners AS PP03
18 ON PP03 . fk_company = C02 . pk_company
19 LEFT JOIN people AS P02
20 ON P02 . pk_person = PP03 . fk_person_partner
21 LEFT JOIN people_partners AS PP04
22 ON PP04 . fk_person_partner = P02 . pk_person
23 LEFT JOIN companies AS C03
24 ON C03 . pk_company = PP04 . fk_company
25 LEFT JOIN companies_partners AS CP05
26 ON CP05 . fk_company_partner = C03 . pk_company
27 LEFT JOIN companies AS C04
28 ON C04 . pk_company = CP05 . fk_company
29 WHERE C02 . pk_company <> C01 . pk_company
30 AND C02 . pk_company <> C03 . pk_company
85
31 AND C01 . pk_company <> C03 . pk_company
32 AND C04 . pk_company <> C01 . pk_company
33 AND C04 . pk_company <> C02 . pk_company
34 AND C04 . pk_company <> C03 . pk_company
35 AND P02 . pk_person <> P01 . pk_person
36 AND (( C01 . company_name = ' COMPANY B ' AND C02 . company_name = ' COMPANY C ')
37 OR ( C01 . company_name = ' COMPANY B ' AND C03 . company_name = ' COMPANY C ')
38 OR ( C01 . company_name = ' COMPANY B ' AND C04 . company_name = ' COMPANY C '));
#############################################################################
1 SELECT
2 C01 . company_name ,
3 P01 . name_person ,
4 C02 . company_name ,
5 C03 . company_name ,
6 P02 . name_person ,
7 C04 . company_name
8 FROM people_partners AS PP01
9 INNER JOIN companies AS C01
10 ON C01 . pk_company = PP01 . fk_company
11 INNER JOIN people AS P01
12 ON P01 . pk_person = PP01 . fk_person_partner
13 LEFT JOIN people_partners AS PP02
14 ON PP02 . fk_person_partner = P01 . pk_person
15 LEFT JOIN companies AS C02
16 ON C02 . pk_company = PP02 . fk_company
17 LEFT JOIN companies_partners AS CP03
18 ON CP03 . fk_company_partner = C02 . pk_company
19 LEFT JOIN companies AS C03
20 ON C03 . pk_company = CP03 . fk_company
21 LEFT JOIN people_partners AS PP04
22 ON PP04 . fk_company = C03 . pk_company
23 LEFT JOIN people AS P02
24 ON P02 . pk_person = PP04 . fk_person_partner
25 LEFT JOIN people_partners AS PP05
26 ON PP05 . fk_person_partner = P02 . pk_person
27 LEFT JOIN companies AS C04
28 ON C04 . pk_company = PP05 . fk_company
29 WHERE C02 . pk_company <> C01 . pk_company
30 AND C02 . pk_company <> C03 . pk_company
31 AND C01 . pk_company <> C03 . pk_company
32 AND C04 . pk_company <> C01 . pk_company
33 AND C04 . pk_company <> C02 . pk_company
34 AND C04 . pk_company <> C03 . pk_company
35 AND P02 . pk_person <> P01 . pk_person
36 AND (( C01 . company_name = ' COMPANY B ' AND C02 . company_name = ' COMPANY C ')
37 OR ( C01 . company_name = ' COMPANY B ' AND C03 . company_name = ' COMPANY C ')
38 OR ( C01 . company_name = ' COMPANY B ' AND C04 . company_name = ' COMPANY C '));
#############################################################################
86
1 SELECT
2 C01 . company_name ,
3 P01 . name_person ,
4 C02 . company_name ,
5 C03 . company_name ,
6 C04 . company_name
7 FROM people_partners AS PP01
8 INNER JOIN companies AS C01
9 ON C01 . pk_company = PP01 . fk_company
10 INNER JOIN people AS P01
11 ON P01 . pk_person = PP01 . fk_person_partner
12 LEFT JOIN people_partners AS PP02
13 ON PP02 . fk_person_partner = P01 . pk_person
14 LEFT JOIN companies AS C02
15 ON C02 . pk_company = PP02 . fk_company
16 LEFT JOIN companies_partners AS CP03
17 ON CP03 . fk_company_partner = C02 . pk_company
18 LEFT JOIN companies AS C03
19 ON C03 . pk_company = CP03 . fk_company
20 LEFT JOIN companies_partners AS CP04
21 ON CP04 . fk_company_partner = C03 . pk_company
22 LEFT JOIN companies AS C04
23 ON C04 . pk_company = CP04 . fk_company
24 WHERE C02 . pk_company <> C01 . pk_company
25 AND C02 . pk_company <> C03 . pk_company
26 AND C01 . pk_company <> C03 . pk_company
27 AND C04 . pk_company <> C01 . pk_company
28 AND C04 . pk_company <> C02 . pk_company
29 AND C04 . pk_company <> C03 . pk_company
30 AND (( C01 . company_name = ' COMPANY B ' AND C02 . company_name = ' COMPANY C ')
31 OR ( C01 . company_name = ' COMPANY B ' AND C03 . company_name = ' COMPANY C ')
32 OR ( C01 . company_name = ' COMPANY B ' AND C04 . company_name = ' COMPANY C '));
#############################################################################
1 SELECT
2 C01 . company_name ,
3 C02 . company_name ,
4 P01 . name_person ,
5 C03 . company_name ,
6 P02 . name_person ,
7 C04 . company_name
8 FROM companies_partners AS CP01
9 INNER JOIN companies AS C01
10 ON C01 . pk_company = CP01 . fk_company_partner
11 LEFT JOIN companies AS C02
12 ON C02 . pk_company = CP01 . fk_company
13 LEFT JOIN people_partners AS PP02
14 ON PP02 . fk_company = C02 . pk_company
15 INNER JOIN people AS P01
16 ON P01 . pk_person = PP02 . fk_person_partner
17 LEFT JOIN people_partners AS PP03
18 ON PP03 . fk_person_partner = P01 . pk_person
87
19 LEFT JOIN companies AS C03
20 ON C03 . pk_company = PP03 . fk_company
21 LEFT JOIN people_partners AS PP04
22 ON PP04 . fk_company = C03 . pk_company
23 LEFT JOIN people AS P02
24 ON P02 . pk_person = PP04 . fk_person_partner
25 LEFT JOIN people_partners AS PP05
26 ON PP05 . fk_person_partner = P02 . pk_person
27 LEFT JOIN companies AS C04
28 ON C04 . pk_company = PP05 . fk_company
29 WHERE C02 . pk_company <> C01 . pk_company
30 AND C02 . pk_company <> C03 . pk_company
31 AND C01 . pk_company <> C03 . pk_company
32 AND C04 . pk_company <> C01 . pk_company
33 AND C04 . pk_company <> C02 . pk_company
34 AND C04 . pk_company <> C03 . pk_company
35 AND P02 . pk_person <> P01 . pk_person
36 AND (( C01 . company_name = ' COMPANY B ' AND C02 . company_name = ' COMPANY C ')
37 OR ( C01 . company_name = ' COMPANY B ' AND C03 . company_name = ' COMPANY C ')
38 OR ( C01 . company_name = ' COMPANY B ' AND C04 . company_name = ' COMPANY C '));
#############################################################################
1 SELECT
2 C01 . company_name ,
3 C02 . company_name ,
4 P01 . name_person ,
5 C03 . company_name ,
6 C04 . company_name
7 FROM companies_partners AS CP01
8 INNER JOIN companies AS C01
9 ON C01 . pk_company = CP01 . fk_company_partner
10 LEFT JOIN companies AS C02
11 ON C02 . pk_company = CP01 . fk_company
12 LEFT JOIN people_partners AS PP02
13 ON PP02 . fk_company = C02 . pk_company
14 INNER JOIN people AS P01
15 ON P01 . pk_person = PP02 . fk_person_partner
16 LEFT JOIN people_partners AS PP03
17 ON PP03 . fk_person_partner = P01 . pk_person
18 LEFT JOIN companies AS C03
19 ON C03 . pk_company = PP03 . fk_company
20 LEFT JOIN companies_partners AS CP04
21 ON CP04 . fk_company_partner = C03 . pk_company
22 LEFT JOIN companies AS C04
23 ON C04 . pk_company = CP04 . fk_company
24 WHERE C02 . pk_company <> C01 . pk_company
25 AND C02 . pk_company <> C03 . pk_company
26 AND C01 . pk_company <> C03 . pk_company
27 AND C04 . pk_company <> C01 . pk_company
28 AND C04 . pk_company <> C02 . pk_company
29 AND C04 . pk_company <> C03 . pk_company
30 AND (( C01 . company_name = ' COMPANY B ' AND C02 . company_name = ' COMPANY C ')
31 OR ( C01 . company_name = ' COMPANY B ' AND C03 . company_name = ' COMPANY C ')
88
32 OR ( C01 . company_name = ' COMPANY B ' AND C04 . company_name = ' COMPANY C '));
#############################################################################
1 SELECT
2 C01 . company_name ,
3 C02 . company_name ,
4 C03 . company_name ,
5 P01 . name_person ,
6 C04 . company_name
7 FROM companies_partners AS CP01
8 INNER JOIN companies AS C01
9 ON C01 . pk_company = CP01 . fk_company_partner
10 INNER JOIN companies AS C02
11 ON C02 . pk_company = CP01 . fk_company
12 LEFT JOIN companies_partners AS CP02
13 ON CP02 . fk_company_partner = C02 . pk_company
14 LEFT JOIN companies AS C03
15 ON C03 . pk_company = CP02 . fk_company
16 LEFT JOIN people_partners AS PP03
17 ON PP03 . fk_company = C03 . pk_company
18 LEFT JOIN people AS P01
19 ON P01 . pk_person = PP03 . fk_person_partner
20 LEFT JOIN people_partners AS PP04
21 ON PP04 . fk_person_partner = P01 . pk_person
22 LEFT JOIN companies AS C04
23 ON C04 . pk_company = PP04 . fk_company
24 WHERE C02 . pk_company <> C01 . pk_company
25 AND C02 . pk_company <> C03 . pk_company
26 AND C01 . pk_company <> C03 . pk_company
27 AND C04 . pk_company <> C01 . pk_company
28 AND C04 . pk_company <> C02 . pk_company
29 AND C04 . pk_company <> C03 . pk_company
30 AND (( C01 . company_name = ' COMPANY B ' AND C02 . company_name = ' COMPANY C ')
31 OR ( C01 . company_name = ' COMPANY B ' AND C03 . company_name = ' COMPANY C ')
32 OR ( C01 . company_name = ' COMPANY B ' AND C04 . company_name = ' COMPANY C '));
#############################################################################
1 SELECT
2 C01 . company_name ,
3 C02 . company_name ,
4 C03 . company_name ,
5 C04 . company_name
6 FROM companies_partners AS CP01
7 INNER JOIN companies AS C01
8 ON C01 . pk_company = CP01 . fk_company_partner
9 INNER JOIN companies AS C02
10 ON C02 . pk_company = CP01 . fk_company
11 LEFT JOIN companies_partners AS CP02
12 ON CP02 . fk_company_partner = C02 . pk_company
89
13 LEFT JOIN companies AS C03
14 ON C03 . pk_company = CP02 . fk_company
15 LEFT JOIN companies_partners AS CP03
16 ON CP03 . fk_company_partner = C03 . pk_company
17 LEFT JOIN companies AS C04
18 ON C04 . pk_company = CP03 . fk_company
19 WHERE C02 . pk_company <> C01 . pk_company
20 AND C02 . pk_company <> C03 . pk_company
21 AND C01 . pk_company <> C03 . pk_company
22 AND C04 . pk_company <> C01 . pk_company
23 AND C04 . pk_company <> C02 . pk_company
24 AND C04 . pk_company <> C03 . pk_company
25 AND (( C01 . company_name = ' COMPANY B ' AND C02 . company_name = ' COMPANY C ')
26 OR ( C01 . company_name = ' COMPANY B ' AND C03 . company_name = ' COMPANY C ')
27 OR ( C01 . company_name = ' COMPANY B ' AND C04 . company_name = ' COMPANY C '));
#############################################################################
90
Referências
ACM
Comput. Surv.
[3] Renzo Angles and Claudio Gutierrez. Survey of Graph Database Models.
, 40(1):1:11:39, 2008. xi, 5, 7, 8, 11, 15
First
[4] Renzo Angles, Arnau Prat-Pérez, David Dominguez-Sal, and Josep-Lluis Larriba-
[7] Fay Chang, Jerey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach,
[8] Gary Chartrand. Introductory Graph Theory . Dover Publications, New York, una-
bridged edition edition, December 1984. 4, 5
Introduction to Algorithms
[10] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Cliord Stein.
. The MIT Press, Cambridge, Mass, third edition edition
edition, July 2009. 60
91
Proce-
edings of Twenty-rst ACM SIGOPS Symposium on Operating Systems Principles
and Werner Vogels. Dynamo: Amazon's Highly Available Key-value Store. In
,
'07, pages 205220, New York, NY, USA, 2007. ACM. 13
2011
International Conference on Cloud and Service Computing (CSC)
[13] Robin Hecht and Stefan Jablonski. evaluation: A use case oriented survey. In
, pages 336341,
2011. 4, 13
[14] Carlos Alberto Heuser. Projeto de banco de dados . Sagra Luzzatto, 1998. 27
[18] O'Reilly Media Inc. Big Data Now: 2012 Edition . O'Reilly Media, 2 edition edition,
October 2012. 1, 13
2012 SC Companion:
forms. In
, pages 13061309, November 2012. 13
[21] Karamjit Kaur and Rinkle Rani. Modeling and querying data in NoSQL databases.
pages 17. IEEE, October 2013. 13
ACM Transactions
on Database Systems (TODS)
[22] Gabriel M. Kuper and Moshe Y. Vardi. The logical data model.
, 18(3):379413, 1993. 8
[23] Neal Leavitt. Will NoSQL Databases Live Up to Their Promise? Computer , 43(2):12
14, February 2010. 13
92
IEEE
Transactions on Knowledge and Data Engineering
[24] M. Levene and G. Loizou. A graph-based data model and its ramications.
, 7(5):809823, October 1995. xi,
8, 11, 12, 22
[26] David Loshin. Business Intelligence: The Savvy Manager's Guide . Morgan Kauf-
mann, Amsterdam ; Boston, 1 edition edition, July 2003. 44
Proceedings
[28] Robert Campbell McColl, David Ediger, Jason Poovey, Dan Campbell, and David A.
Crime, Law
and Social Change
[29] Jerey Scott McIllwain. Organized crime: A social network approach.
, 32(4):301323, December 1999. 13, 45
[30] Russ Miles and Kim Hamilton. Learning UML 2.0 . O'Reilly Media, Beijing ; Sebas-
topol, CA, 1 edition edition, May 2006. 22, 32
[32] Ian Robinson, Jim Webber, and Emil Eifrem. Graph Databases . O'Reilly Media,
Sebastopol, Calif., 1 edition edition, June 2013. 11, 39, 64, 70
Social Networks
[34] Malcolm K. Sparrow. The application of network analysis to criminal intelligence:
An assessment of the prospects. , 13(3):251274, 1991. 45
[37] Chad Vicknair, Michael Macias, Zhendong Zhao, Xiaofei Nan, Yixin Chen, and Dawn
ference
Provenance Perspective. In
, SE '10, pages 42:142:6, New York, NY, USA, 2010. ACM. 76
Commun. ACM
[38] Jennifer Xu and Hsinchun Chen. Criminal Network Analysis and Visualization.
, 48(6):100107, June 2005. 13, 45
93